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

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

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

On 04/21/2014 04:47 AM, Teo Mazars wrote:

----- Mail original -----

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?

Yes, grep for "R'" or "Y'" in the operation directory.

Thanks!

But... are you really saying that Gradient should be implemented using a non-perceptual color space?

Yes, to be technically correct.

See http://ninedegreesbelow.com/gimpgit/gimp-srgb/gradients/gradients.png

I think gradient is a good simple example. How this operation should be implemented exactly?

We want people to be able to draw perceptually linear gradient right?

I completely agree with you that people should be able to draw a gradient in a perceptually uniform color space if they want to.

But any such gradient is not technically correct. Colors don't mix properly in the almost perceptually uniform regular sRGB color space.

So any color mixing in the regular sRGB color space is technically incorrect. For example, you get dark lines at the edges of soft brush strokes. The same thing happens with gradients, except the darkening artifact is spread out across the gradient and so doesn't look as obviously technically incorrect.

How do we achieve that, both from UI and GEGL point of view.

I have two proposed solutions:

Solution one:

*Drop* the insistence that all processing be done in a color space defined by the sRGB chromaticities and let people choose whatever RGB color space they want to work in.

Don't presume people are incapable of understanding and taking charge of their own color management decisions. Yes, many people will make mistakes. So what?

Also drop the whole "gamma-correction" business.

Code would be greatly simplified.

In this scenario you could choose to work in the regular sRGB if you want the technically incorrect gradients that everyone is used to. You could choose to work in a linear gamma version of sRGB if you want technically correct gradients. You could choose to work in linear gamma Rec 2020 or linear gamma ProPhoto or regular ProPhoto, etc.

The results you get would be technically correct or incorrect depending on whether you choose a linear gamma color space or not.

All RGB values would be represented in the user's chosen color space.

The UI wouldn't need to accomodate things like +1.6 or -0.2 just to represent a shade of red in some color space other than sRGB.

There wouldn't need to be any hacks to make histograms or color picker or color selector work.

Values greater than 1.0 would always mean intensity rather than "redder than sRGB red" or "greener than sRGB green".

There would be no RGB values less than 0 unless Subtract is unclipped and the user chose to use Subtract. The result would be under the user's control.

Solution two:

Keep the insistence on the sRGB-TRC and keep the code that "gamma" corrects the sRGB-TRC.

Better yet, change that "gamma" correction code to work with true gamma=2.2 (mathematically simpler code) or else to work with the truly perceptually uniform lstar TRC.

But *drop* the insistence on the sRGB chromaticities. Let the user choose their RGB working space but tell them it needs to have either the sRGB-TRC (or gamma=2.2 or lstar as appropriate to the code), and explain the consequences of the choice.

Make ALL "Gamma" precision operations happen using the perceptually uniform TRC (*nothing* is "gamma" corrected) and make ALL "Linear" precision operations happen using the linear gamma TRC (*everything* is "gamma" corrected).

The advantage is that:

All RGB values would be represented in the user's chosen color space.

The UI wouldn't need to accomodate things like +1.6 or -0.2 just to represent a shade of red in some color space other than sRGB.

There wouldn't need to be any hacks to make histograms or color picker or color selector work.

Values greater than 1.0 would always mean higher intensity rather than "redder than sRGB red" or "greener than sRGB green".

The user can easily switch from linear to perceptual processing and back again.

Elle

On 04/21/2014 06:05 AM, Elle Stone wrote:

On 04/21/2014 04:47 AM, Teo Mazars wrote:

But... are you really saying that Gradient should be implemented using a non-perceptual color space?

Yes, to be technically correct.

See http://ninedegreesbelow.com/gimpgit/gimp-srgb/gradients/gradients.png

Making the code draw gradients *in the unbounded mode sRGB color space* rather than the RGB color space of the artist's choice means:

1. A gradient drawn from sRGB red to sRGB green is drawn technically incorrectly but also looks the way many people are used to seeing the gradient look.

2. A gradient drawn from Rec. 2020 red to Rec. 2020 green is drawn technically incorrectly and also the result is something no one in their right mind would want the gradient to look like (barring corner case artistic intentions). This is because "perceptual" gradients just don't work in unbounded mode sRGB if the artist wants to use colors that are outside the sRGB color gamut.

More generally speaking, if all RGB editing operations *must* use the sRGB chromaticities, with no user choice, then most and probably *all* RGB operations should be done in linear light:

1. If the UI *does* give the user the choice to pick "perceptual", but the code insists on the sRGB *chromaticities*, then the "perceptual" choice is useful *only* to users who want to work exclusively in the sRGB color space.

2. A user who opens a wider gamut image won't be able to take advantage of the choice to use "perceptual". This is because for many RGB editing operations, if the image is converted to unbounded mode sRGB then results using "perceptual" are not just *technically* wrong, but also visually, obviously, horribly wrong and strange.

Elle

On 04/21/2014 07:07 AM, Teo Mazars wrote:

Hmm, I understand, then the default black-to-white gradient would be non perceptually linear, which is more surprising than the color-to-color gradient. I think I am now convinced this is correct, but it will probably be puzzling to use.

BTW, "gradient" is not such a good example because it's not related to chromaticities, "Invert" would be a better one.

I don't understand what you are trying to say. How is drawing a gradient from most saturated red to most saturated green in any given color space not related to chromaticities?

The color space chromaticities are what determine the most saturated possible colors in any given color space.

Aren't the negative RGB values required to draw a gradient in unbounded mode sRGB from Rec. 2020 reddest red to Rec. 2020 greenest green exactly what makes the gradient so horribly wrong when drawn in perceptual rather than linear? It's the effect of the perceptual TRC that sends the "out of bounded sRGB gamut" colors to strange places.

Elle

On 04/21/2014 07:35 AM, Teo Mazars wrote:

Hmm, I understand, then the default black-to-white gradient would be non perceptually linear, which is more surprising than the color-to-color gradient. I think I am now convinced this is correct, but it will probably be puzzling to use.

BTW, "gradient" is not such a good example because it's not related to chromaticities, "Invert" would be a better one.

I don't understand what you are trying to say. How is drawing a gradient
from most saturated red to most saturated green in any given color space
not related to chromaticities?

Well, a gradient operation doesn't have to know what are the coordinates of chromaticities. The two colors used for a particular gradient are given by the user, if he want the "from most saturated red to most saturated green", he just have to send the coordinates of the red and the green to the operation, which could be the scaled/translated [1.0, 0.0, 0.0], [0.0, 1.0, 0.0] for a GIMP user. Since we just say that the operation have to work in a linear color space, there is no issue with out-of-gamut values.

Is that correct? If so, that's why "Gradient" is not a good example.

Ah, I see what you mean.

I wasn't saying that gradient uses chromaticities information directly, rather that the chromaticities of a color space determine what the equivalent unbounded mode sRGB RGB values are, to colors that were chosen in the source color space.

Gradient is an operation that *should* produce the same result in any unbounded mode color space. The actual chromaticities should be irrelevant. But gradient does only works in unbounded mode sRGB when operating on linear values.

Linear gamma unbounded sRGB Rec. 2020 red and green: reddest red: 1.660581 -0.124595 -0.018144 greenest green: -0.587709 1.132939 -0.100573

Regular (perceptual) unbounded mode sRGB Rec. 2020 red and green: reddest red: 1.248251 -1.609913 -0.234435 greenest green: -7.593863 1.056319 -1.299524

Those negative RGB values after converting to unbounded mode *perceptual* sRGB are what make the resulting gradient from Rec. 2020 red to Rec. 2020 green look so awful.

"Invert" needs to know what are the chromaticities because it uses them to compute the "inverted" colors.

You mean "Value Invert"? If done in a linear gamma version of sRGB, regular Invert does work (and should work, it's the same as swapping the lower left and right Levels sliders) in unbounded mode sRGB, but Value Invert does not.

As the Value Invert code uses the chromaticities, that nicely explains why Value Invert doesn't work even in a true linear gamma version of sRGB.

Elle