I posted a "User's Guide to High Bit Depth GIMP 2.9" to my website.

Some of the GIMP 2.9 code still uses hard-coded "sRGB-only" parameters.

Consequently, if you use GIMP 2.9 to edit images in wider gamut RGB working spaces such as ProPhotoRGB or AdobeRGB1998, the affected editing operations produce incorrect results.

The "User's Guide" tells you which editing operations to watch out for and also provides some workarounds.

Some of the workarounds are simple, and some require making small modifications to the source code and then recompiling babl/GEGL/GIMP.

Here's the link: http://ninedegreesbelow.com/photography/users-guide-to-high-bit-depth-gimp.html

The Guide talks about color management and so gets a bit technical in places. So if anyone has questions, please ask and I'll do my best to answer them.

Best regards,
Elle Stone

http://ninedegreesbelow.com
Color management and free/libre photography

On 11/02/2014 08:35 AM, Partha Bagchi wrote:

Elle,

What are your thoughts on the 64-bit precision now in Gimp?

At some point in the not too distant past I asked about the 64-bit precision options. As I recall, the answer was that 64-bit precision options are to accomodate (I think) the FITS file format, which can be at 64-bit precision. But the actual GEGL calculations are at 32-bit floating point.

Also, (I know, I shouldn't ask :) ) are the patches already in the current trunk?

My apologies, I'm not sure which patches you are asking about. The openexr patch? I filed a bug report but don't remember if I attached a patch or not. The patch to retrieve Y and XYZ info from the image ICC profile? I did attach a patch to the bug report. Some other patch?

Elle

Thanks,
Partha

On Sat, Nov 1, 2014 at 7:40 AM, Elle Stone wrote:

I posted a "User's Guide to High Bit Depth GIMP 2.9" to my website.

Some of the GIMP 2.9 code still uses hard-coded "sRGB-only" parameters.

Consequently, if you use GIMP 2.9 to edit images in wider gamut RGB working spaces such as ProPhotoRGB or AdobeRGB1998, the affected editing operations produce incorrect results.

The "User's Guide" tells you which editing operations to watch out for and also provides some workarounds.

Some of the workarounds are simple, and some require making small modifications to the source code and then recompiling babl/GEGL/GIMP.

Here's the link: http://ninedegreesbelow.com/photography/users-guide-to-high-bit-depth-gimp.html

The Guide talks about color management and so gets a bit technical in places. So if anyone has questions, please ask and I'll do my best to answer them.

Best regards,
Elle Stone
--
http://ninedegreesbelow.com
Color management and free/libre photography _______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list

On 11/02/2014 09:08 AM, Partha Bagchi wrote:

Yes, the openexr patch, the modified util.h, and the 7 files that need to be modified. I can do it locally, but would be nice if they were in git.

I added the openexr patch to a bug report. With this patch, the user really does need to assign an appropriate linear gamma ICC profile to the openexr file, as the GIMP built-in sRGB profile assumes nonlinear data. All the patch does is revert to the original openexr code, from before the latest openexr commits were made: https://bugzilla.gnome.org/show_bug.cgi?id=316646

On the one hand, the modified util.h file isn't really something that any of the devs would like to see as a patch, as it basically destroys the functionality of the babl/GEGL "linear vs perceptually uniform" code.

On the other hand, it's very possible that some of the people who use your excellent builds might like the "linear vs perceptually uniform" functionality removed until such time as the UI options are not so confusing.

On a related topic, awhile back I wrote patches that remove all of the "(linear)" vs "(gamma)" precision options, plus all the supporting linear/gamma precision switching code. It was very nice to use high bit depth GIMP without seeing such a long list of precision options. But those patches won't work with the latest git versions of babl/GEGL/GIMP (I could update the patches if anyone really wanted to use them).

This bug report: https://bugzilla.gnome.org/show_bug.cgi?id=737778 has a patch that retrieves the RGB working-space-specific Y and XYZ parameters, and also specifies where the information needs to go to take the place of the current hard-coded sRGB parameters. Unfortunately I don't have sufficient coding skills to write code that would ferry the retrieved information to the places in the code base that need the information.

As far as the "7 files" go, modifying those files requires knowing what RGB working space the user actually wants to use. This is why I currently run three side-by-side installations of GIMP 2.9, one per RGB working space that I'm currently using. If I knew how to write the Y/XYZ "ferrying" code, there would be no need to resort to running three side-by-side versions of babl/GEGL/GIMP.

No doubt just about any of the GIMP devs would be able to write the "ferrying" code without much trouble, which is why I suggested that perhaps a "proper ICC profile color management" branch of babl/GEGL/GIMP could be set up.

Elle

On 11/02/2014 10:03 AM, Elle Stone wrote:

On a related topic, awhile back I wrote patches that remove all of the "(linear)" vs "(gamma)" precision options,

Leaving, of course, the ability to choose 8/16/32 bit precision. That probably wasn't clear.