On Sunday 25 January 2009 21:53:54 Martin Nordholts wrote:

Hi

I have attached a patch to "Bug 74224 – Add support for 16 bits per channel" [1] that makes it possible to use GIMP for opening, color correcting and saving 16-bits-per-channel PNGs using the operations under the Colors menu that are ported to GEGL such as Color Balance or Levels. For a technical description of the patch, refer to the bug report.

This was a weekend hack and raises an interesting question: shall we go for some kind of 16-bit support for GIMP 2.8? I think we should as I am confident we will be able to come up with something useful in the realm of high bit depths for 2.8. I don't think it will be hard to add support for loading some additional 16-bit image formats, allowing creation of 16-bit images and adding 16-bit capabilities to a set of basic tools. Even if we certainly won't be able to completely port everything to 16-bit in one release cycle it would show that we are making progress in this area. Just being able to color correct 16-bit PNGs covers one use case already.

I think Martin's proposal has merit. I know that comparisons to Photoshop are to some extent considered off topic here but in this case I will do it because the history of Photoshop has some parallels. The approach that Martin is advocating (IE. having high bit depth support for loading, saving and some color correction operations) is how the first versions of Photoshop with high bit depth support worked. This started with version 6 I believe and the support for high bit depth images improved with each follow on version until it was complete. Even though these earlier versions were somewhat frustrating because only some operations were supported for high bit depth images it was none the less a significant step forward and this progress was well received by it's users. I am sure that that would also be the case for GIMP users.

To convince yourself of that the patch actually makes GIMP do stuff in high bit depth:

1. Apply the patch, requires SVN trunk of GIMP, GEGL and babl.

2. Open a 16-bit PNG with a white-to-black gradient such as this [2] one I created using Krita.

3. Enable GEGL for the projection and color tools, the legacy code can't handle 16-bit image data. View -> Use GEGL and Colors -> Use GEGL.

4. Use Colors -> Levels and map the entire range of input to the output range [120, 135]. This will make the image look completely gray. Apply.

5. Use Colors -> Levels and map the input range [120, 135] to the full output range [0, 255]. Apply.

After doing 5 the gradient will look intact if you do this on the 16-bit PNG with GEGL. If you do this on 8-bit data using the 8-bit legacy code paths the results will look terrible.

Welcome to the start of the 16-bit GIMP era ;)

BR, Martin

Just curious. Since GEGL has support for more high bit depth formats than just 16 bit int/channel how much more work would be needed to support a wider range of formats? For example tif files can use a number of different representations including 32 bit int/channel and 32 and 64 bit float/channel as well as 8 and 16 bit int/channel and probably some other representation formats. Once 16 bit int/channel is working how much additional work is needed to support these other image formats? Or is this trivial to implement and therefore almost free at that point?

Hal

Von: "Hal V. Engel"

I think Martin's proposal has merit. I know that comparisons to Photoshop are to some extent considered off topic here but in this case I will do it because the history of Photoshop has some parallels. The approach that Martin is advocating (IE. having high bit depth support for loading, saving and some color correction operations) is how the first versions of Photoshop with high bit depth support worked.

"We do not want the frustrating partial support of Photoshop, we want everything from the start" has been the decision in the last discussion about this topic, IIRC.

HTH, Michael

Hi,

On Tue, Jan 27, 2009 at 7:35 PM, Hal V. Engel wrote:

On Sunday 25 January 2009 21:53:54 Martin Nordholts wrote: Just curious. Since GEGL has support for more high bit depth formats than just 16 bit int/channel how much more work would be needed to support a wider

For proper 16bit support, levels/colors/etc dialogs need to talk in terms of 0..65535 range rather than 0..255 when they are working on 16bit data, and so should then be able to talk in terms of 0..4294967295 for 32bit int.
If I understand this patch correctly, once a system for working with 'native' ranges is implemented and the basic system implemented by the patch is proven, support for 32bit int/channel should be relatively simple. Whether floating point support would require more work, I do not know.

There are also various rough spots to consider; we should be able to enter hex colors with 16bit or even 32bit per channel precision, if we can edit 16bit images.

Sadly I haven't been able to try this patch yet -- my GIMP doesn't want to compile, due to babl/gegl synchronization issues.

David

Hi,

there are two issues with your patch that we should try to solve. The first is that your approach doesn't follow the roadmap we've set for this. Our decision was not to introduce high bit depths before we haven't changed all tools, all core operations and at least provide an API for plug-ins to work in higher bit depths. But then you are probably right that we need to start somewhere...

The other problem I see with your approach is that image loading is done by the core. That is something that we should try to avoid by all means. I suggest that we add a plug-in API that allows file loaders to pass the location of a disk-backed GeglBuffer to the core. That should be a reasonable way to get layer data to the core without the risk of crashing the core due to some problem in the file loader.

It would be nice if you could keep us up-to-date with regard to your hacking. Perhaps you could send an updated patch to the list?

Sven

Hi,

On Sat, 2009-01-31 at 21:51 +0100, Martin Nordholts wrote:

* Elementary load/save support for formats that support higher bit depths such as PNG, TIFF and OpenEXR.

As far as I can see GEGL does not have a TIFF load and save operation yet. So anyone who is interested in being able to load and save TIFF files in higher bit depths should consider to contribute that code to GEGL.

There is likely support for other file formats missing in GEGL. It would be nice if this could be improved. Interested developers, please join the gegl-developer mailing-list...

Sven