GNOME.org
 

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

On 04/20/2014 11:03 AM, Øyvind Kolås wrote:

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?




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).
I'm not sure what you mean by "done relative to XYZ" - that processing is done using sRGB chromaticities which make one of the infinite number of possible RGB color spaces that can be defined relative to XYZ? 


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.
I'm not sure what the difference is between global and local overrides. What's the practical or perhaps UI? difference? An example of one vs the other? 



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.




* 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 :]
I posted to GIMP bugzilla sample LCMS code for pulling XYZ colorants from an ICC profile. The sample code just uses a profile from disk, how to get a profile from memory is probably beyond my coding skills. As you mentioned a babl lcms extension, perhaps I should have sent that code to babl instead of GIMP? 



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.
It seems like what you are saying is that the less saturated the image colors, the less of a problem channel redistribution will cause upon conversion to sRGB chromaticities. Which of course is 100% true.
But surely GIMP users other than myself will occasionally photograph colorful flowers and such? For example, after interpolating a raw file and applying the input profile, upon conversion to unbounded mode sRGB: 

* The green channel of red flowers is likely to be negative.
* The blue channel of yellow flowers and bright green leaves is likely to be negative. 
* The red channel of saturated cyan is likely to be negative. And so on.
The sRGB bounded gamut holds only 35% of all real colors, and not exactly a judiciously chosen 35%, being dictated by phosphors used in consumer grade CRTs from the 1990s rather than anything intrinsically meaningful to film, print, digital cameras when shooting raw, or current and future advances in display technology.
But even if the conversion were to some larger gamut unbounded mode color space, those channel redistributions still would cause problems for *some* editing operations. 



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.
Choosing the appropriate RGB working space for a given editing task is an essential part of the creative process. It's part of "the right tool for the right job". 


As far as I have seen work has barely started
in GIMPs UI with dealing with >8bpc images.
I apologize if it's too soon to be worried about UI problems. But it does seem logical that if a user is working on a Rec. 2020 image, reddest Rec. 2020 red should be (1,0,0), not the linear gamma sRGB equivalent (1.660581, -0.124595, -0.018144). Unless perhaps there is a way to communicate visually to the user which colors lie entirely in the Rec. 2020 color gamut.
Perhaps a chromaticity diagram on which the user can choose to overlay various color space triangles, including but not limited to the source color space xy coordinates? Such a tool wouldn't be as precise as dialing in exact values. 



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.
Do you mean things like Channel Mixer, Levels, Gradients, and Invert, which currently use the regular sRGB TRC instead of linear light?
I hadn't realized that Channel Mixer isn't using linear light. But when I tried using Channel Mixer to desaturate the yellow cone flower in my modified BABL/GEGL/GIMP that disables all the background TRC switches, in a true linear gamma sRGB color space, it worked!
Resulting saturation and value are slightly different in my custom camera space vs unbounded mode linear light sRGB, most noticeable in saturated reds. But hue is constant and at least the results are believable.
So I was wrong about Channel Mixer desaturation not working in unbounded mode sRGB. Desaturation using Channel Mixer does give "close to the same results" as the source color space in unbounded mode sRGB, but *not* in perceptually uniform sRGB, rather *only* in linear light sRGB.
Similar issues are easy to demonstrate with Levels upper and lower sliders, Gradients, Invert. These really need to be linear light operations. 

Is there a list of the operations that don't currently use linear light?


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.



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