Re: [Gimp-developer] [Gimp-user] User's Guide to High Bit Depth GIMP 2.9

[Elle Stone <ellestone ninedegreesbelow com>]

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