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

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! :) ).


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]