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

[Øyvind Kolås <pippin gimp org>]

On Fri, Apr 18, 2014 at 4:22 PM, Elle Stone
<ellestone ninedegreesbelow com> wrote:
> 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.

Not entirely right as a premise; the premise is that
editing/processing in ops should default to being done
relative to XYZ; in pixel formats specifiable with babl (we control
babl; and can decide how we extend it).

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

As Alan Kay says, "simple things should be simple, complex things
should be possible". Local; manual overrides of pixel format used
would probably permit more complex workflows than global working-space
overrides provides.

> "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.

the sRGB chromaticities; or CIE Lab, or any other babl defined format.
With a potential future babl lcms2 extension; the original pixels
could even be kept in the layers raster storage.. doing so would have
no effect on display of the pixels or processing of them since things
are converted _on_demand_ to the pixel formats requested by the
operations. Doing this would for the user not be functionally
different in any way; apart from a risk of things being slower.

> 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.

Yes; this could also possibly be done in specific group of pixelformats :]

> 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.

At least some of them do - and not seeing out of gamut colors in the
histogram in headroom/footroom on the sides are UI bugs. Apart from
maybe color selectors GIMP-2.9 is a 8bit image editing UI with backend
capabilities for more. Picking a different flower with other hues;
would make redistribution among the components less of an issue.

> 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.

Or put differently; allowing the user to override processing globally
at will - effectively _destroys_ actual color management, making
whether things are color managed or plain wrong a highly likely choice
in user configuration. As far as I have seen work has barely started
in GIMPs UI with dealing with >8bpc images.

> 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?

Or from my point of the view I summarise it as stubborn
operators/developers that want to be able to manually
misconfigure/override color management like they are used to instead
of dependable color management and consistency of operations. There
are ways of achieving the goals that Elle is trying to achieve in the
examples; that can fit into GEGLs strongly color managed internal
architecture. Globally overriding the "working-format" is the approach
that is most contrary to the architecture and removes the benefits it
is meant to bring.

/pippin