Re: [Gimp-developer] Maintaining buffers in a custom format in GIMP for EXR support

[Elle Stone <ellestone ninedegreesbelow com>]

On 02/26/2015 04:55 AM, Mukund Sivaraman wrote:
> Because babl has no support for chromaticities, GIMP would need to
> provide extension code to babl, that can convert these custom formats to
> a working space by maintaining a map from the format's name to a struct
> chromaticities and registering additional conversions with every format,
> where the format name is passed as user data. Such extensions may last
> for the lifetime of the app process.
>
> When babl gets support for creating formats with chromaticities as in
> the roadmap, this last step can be removed.

The proposed approach will work for linear gamma OpenEXR files that have 
embedded chromaticities, but only if the chromaticities are correct.

Here's a counter-proposal that cleanly separates importing RGB data from 
processing RGB data:

For now:

1. Forget about OpenEXR metadata; deal with this as time permits.

2. Change the plug-in to treat OpenEXR as "gamma" rather than "linear" 
and treat the file as an untagged image.

3. GIMP will assign the built-in sRGB profile, which almost certainly 
will be wrong. Or else GIMP could make and assign the linear gamma sRGB 
profile to OpenEXR images, which would be right for many OpenEXR images 
that the user might open.

4. Then if the "auto-assigned" profile is wrong, the user can assign the 
correct ICC profile, which for actual linear gamma sRGB images (tiff or 
OpenEXR or otherwise) will be the linear gamma sRGB profile.

5. Distribute a set of ICC profiles with GIMP. At least distribute the 
regular and linear gamma sRGB profiles matching GIMP's built-in 
primaries, because there are too many bad sRGB profiles floating around 
out there.

Now the image has been assigned the correct ICC profile. So the next 
problem is that the RGB data might not be in the regular sRGB color 
space. This is a problem for two reasons:

    i. The babl flips assume the image RGB data is encoded using the 
sRGB TRC.

   ii. A handful of editing operatons assume the image's color space 
has the sRGB Y or XYZ values. Also masks are currently drawn using the 
sRGB Y values.

There are several interim ways to deal with these two problems that fall 
short of writing full support for chromaticities into babl.

If the RGB data isn't already regular sRGB data, you can:

1. Write GIMP code that automatically makes a profile that has the sRGB 
TRC and the user's chosen XYZ values. Then convert the image to this 
newly-made profile.

2. Write code that allows the user to disable the babl flips and then 
leave the data in the user's chosen RGB working space.

   The problem with the first two approaches is that the babl/GEGL/GIMP 
editing operations that assume the sRGB Y or XYZ values will give the 
wrong results.

As nobody expects 2.10 to provide perfect color management, either or 
both of the above options seem like really good options to me.

The next two approaches are more problematic:

3. Write GIMP code that automatically converts the image to bounded 
sRGB. There are two problems with this approach:

    i. The user really might need to edit the RGB values in the 
original color space, because many editing operations (including 
multiply) are chromaticity-dependent.

   ii. Image colors might be clipped.

4. As was mentioned recently on IRC (not by me!), for the 2.10 release 
write GIMP code that automatically converts the image to unbounded sRGB.
   The many reasons why the fourth option is not a good idea have 
already been covered at length on this mailing list, so I don't plan to 
rehearse them yet again (all you people over there cheering loudly, 
that's not nice! :) ).

Elle