[Gimp-developer] Attempt to summarize the discussion of my examples of what doesn't work in unbounded sRGB

[Elle Stone <ellestone ninedegreesbelow com>]

I've been trying to summarize the discussion of whether some operations 
don't work in unbounded mode sRGB, and if they really don't work, what 
can be done to fix the problem.

Is the following a fair summary of the BABL/GEGL/GIMP code?

The BABL/GEGL/GIMP code is based on three centrally important premises:

Premise 1: Any image in any source RGB color space can be losslessly 
converted to the unbounded mode sRGB chromaticities.

Premise 2: To provide consistent editing results, all editing should be 
done using the sRGB chromaticities. An important side benefit of using 
the sRGB chromaticities is that the performance impact of using LCMS for 
color space conversions is thereby eliminated.

Premise 3: For any given editing/compositing operation, there is only 
one correct color space in which that operation should be performed (for 
example, linear light unbounded mode sRGB vs perceptually uniform 
unbouded mode sRGB).

"Code-driving" conclusions follow from these three premises:

Conclusion 1: For the sake of coding efficiency and consistent editing 
results, images should be losslessly converted to the sRGB 
chromaticities before editing the image.

Conclusion 2: All required editing/compositing color spaces should be 
hard-coded. The currently available editing/compositing color spaces 
include:
     a. unbounded sRGB with the perceptually uniform TRC.
     b. unbounded sRGB with the linear gamma TRC.
     c. CIELAB (the buffer is converted from unbounded sRGB to CIELAB)
     d. HSL, HSV, Gray, etc (the buffer is converted from unbounded 
sRGB to HSL, HSV, Gray etc).
     e. ? (more can be added as needed).

Conclusion 3: Every editing/compositing operations should be hard-coded 
to use the correct editing/compositing color space for that operation.

Hopefully the above summary isn't too far off the mark.

Premise 1 is absolutely correct. Any image in any source color space can 
be losslessly converted to any other color space as long as unbounded 
mode ICC profile conversions are used.

I have been trying to show that even though Premise 1 is correct, some 
editing operations fail after an image is converted from the source 
color space to unbounded mode sRGB 
(http://ninedegreesbelow.com/gimpgit/unbounded-srgb-what-works-what-does-not.html).

Some of the GIMP developers seem to agree that some editing operations 
do seem to fail after an image is converted from the source color space 
to unbounded mode sRGB.

The proposed solution seems to be to modify the code that follows from 
Conclusions 2 and 3:

* Add code that remembers the source color space metadata. This way the 
source color space chromaticities can be used to add to the list of 
color spaces that are available for various editing/compositing operations.

* When one of the affected editing operations is invoked, automatically 
convert, or else provide the UI option to convert, the buffer to the 
source color space chromaticities.

The arguments *against* adding an editing color space based on the 
source color space chromaticities can be summarized as follows:

1. My demonstrations of where editing in the unbounded mode sRGB color 
space fails are all *corner cases*, variously described as involving:

     * Highly image-specific colors (quoting from IRC, "an example of 
highly input data dependent photo that with other colors would not have 
the striking amount of data in the blue channel").

     * A highly image-specific workflow (quoting from IRC, "workflow is 
highly scene/data dependent; and might not make general sense")

     * Extreme, hence meaningless editing moves.

2. An unacceptably large amount of new and complicated code and UI 
modifications would be required to accomodate the corner cases where 
unbounded mode sRGB image editing fails.

3. When considered from the point of view of colors located in XYZ 
space, HDR colors and out-of-gamut colors are essentially the same 
thing. So many/most/all of the corner cases that I posted as examples of 
operations that fail in the unbounded mode sRGB color space will be 
handled by code modifications that are required anyway to enable GIMP to 
handle HDR images.

Is this a fair summary of the discussion so far about operations that 
don't work in the unbounded mode sRGB color space?

Elle