For Lighten only, Darken only, Multiply, Divide, and some of the other blend modes, results are *highly dependent* on the color space in which the blending is done. Removing clipping code doesn't fix the problem.

If the artist uses any of the color-space dependent blend modes:

* Editing an image in a large gamut color space such as ProPhotoRGB produces one set of colors.

* Converting the image to unbounded mode sRGB before editing it necessarily produces different colors - sometimes very different colors.

For concrete examples showing how Lighten only and Darken only are color-space dependent, see
http://ninedegreesbelow.com/gimpgit/unbounded-srgb-lighten-darken.html

Can this problem be fixed? Is there a workaround such that an image can be converted from its source color space to unbounded mode sRGB, and then use the color-space dependent blend modes to produce the same colors that would have been produced if the image had been edited in the source color space instead of in unbounded mode sRGB?

Elle Stone

On 04/09/2014 06:36 PM, Elle Stone wrote:

For Lighten only, Darken only, Multiply, Divide, and some of the other blend modes, results are *highly dependent* on the color space in which the blending is done. Removing clipping code doesn't fix the problem.

If the artist uses any of the color-space dependent blend modes:

* Editing an image in a large gamut color space such as ProPhotoRGB produces one set of colors.

* Converting the image to unbounded mode sRGB before editing it necessarily produces different colors - sometimes very different colors.

For concrete examples showing how Lighten only and Darken only are color-space dependent, see
http://ninedegreesbelow.com/gimpgit/unbounded-srgb-lighten-darken.html

Can this problem be fixed? Is there a workaround such that an image can be converted from its source color space to unbounded mode sRGB, and then use the color-space dependent blend modes to produce the same colors that would have been produced if the image had been edited in the source color space instead of in unbounded mode sRGB?

I put up two more examples - not blend mode examples, rather channel mixing and blending examples:

1. Channel blending when converting to black and white http://ninedegreesbelow.com/gimpgit/unbounded-srgb-channel-blend-convert-black-white.html

The example concludes:

My envisioned conversion to black and white was simple to achieve in my custom RGB working space: make a luminance-based conversion to black and white, pull over the blue channel and set it to multiply blend mode, season to taste.

Converting the image to unbounded mode sRGB made my envisioned conversion to black and white completely impossible.

Worse, if I hadn't examined the blue channel data before the conversion to the unbounded mode sRGB color space, I never would have seen the original blue channel data. As the original blue channel contained all the interesting information in this particular image, I would not have been inspired to convert the image to black and white. No doubt no loss to art! but that is not the point. The point is that a conversion to unbounded mode sRGB radically rearranges channel data, which in turn radically alters the information the artist has to work with.

2. Using Channel Mixer to decrease saturation http://ninedegreesbelow.com/gimpgit/unbounded-srgb-channel-mixer-decrease-saturation.html

The example concludes:

Channel data is radically rearranged when a saturated image is converted from a wider gamut color space to the unbounded mode sRGB color space. A consequence is that many crucially important editing tools no longer function properly. Channel mixing is one such tool.

In the custom RGB color space using Channel Mixer to desaturate the yellow cone flower worked exactly as expected.

In the unbounded mode sRGB color space using Channel Mixer to desaturate the yellow cone flower failed completely. The flower wasn't actually desaturated, and excessive amounts of the blue channel polluted the image's original colors.

Thanks in advance for looking at the examples.

Elle

On 04/10/2014 08:39 PM, Przemyslaw Golab wrote:

Isn't that expected? You don't change color space, for it to have the same results.

You choose best color space for the job and use it from beginning to the end,
or if you know what you are doing convert it in middle of work to do the thing
you want to do.
If all color spaces look the same whats the point of using them.

I agree 100% with what you just said. When editing an image, choose the best color space for the job.

But it seems that the current plan is that when GIMP 2.10 is released, all image editing will be done in the unbounded mode sRGB color space. Quoting from the post Gez mentioned:

Re: [Gimp-developer] Three questions about opening an image and converting it to linear light RGB

On 04/02/2014 04:38 PM, Michael Henning wrote:>

On Wed, Apr 2, 2014 at 9:31 AM, Elle Stone wrote:

My understanding is that in the future:

1. The user will open an image with GIMP and maker sure the right ICC profile has been assigned.

2. Before actual image editing can begin, the image will be converted to extended sRGB/linear light RGB "behind the scenes" without the user necessarily even knowing that this has happened, though a little warning/user education/notes in the GIMP documentation might explain the sudden appearance of negative RGB values and/or RGB values that are greater than 1.0.

We will need a way for users to change the incoming icc profile on import, just in case it has the wrong embedded profile. There will be some level of user awareness, but I don't know how much.

3. All subsequent image editing will be done in the extended sRGB/linear light RGB color space.

Yes. To clarify this point: Users will have the ability to choose to edit in different bitdepths and (probably) also the option between editing with the layers stored as a linear or a perceptual (sRGB TRC) color space (which only really affects the way layer modes work, along with things that depend on layer modes like painting).

Also, gegl operations can request to do their work in different color spaces, so depending on the operation being performed, the editing may actually happen in other color spaces. This is transparent to the user.

My understanding is that the phrase "gegl operations can request to do their work in different color spaces" does *not* refer to different color spaces such as ProPhotoRGB, AdobeRGB1998 or Rec 2020. Rather it means "work in sRGB converted to CIELAB", "work in sRGB converted to HSL", "work in sRGB converted to CMYK", and so forth. I asked about this point in the previous email, but so far no one has clarified whether my understanding is correct or not. So I'm asking again. Please? Anyone? Is my understanding correct?

It seems that the plan for GIMP going forward is firmly in the direction of converting all images to unbounded mode sRGB before editing can begin. So I've been testing to see what it will be like to edit images in the sRGB color space instead of my preferred color spaces.

Some editing operations work already in unbounded mode sRGB, meaning these operations are actually *completely independent* of the linear gamma color space in which they are performed, assuming unbounded mode ICC profile conversions. Other editing operations will work once clipping code is removed.

For example I'm pretty confident that scaling, gaussian blur, unsharp mask, normal blend mode, Addition blend mode, and Subtract blend mode give exactly the same results regardless of what linear gamma (or "gamma corrected") RGB color space the operation is performed in, assuming clipping code is removed as appropriate.

However, some editing operations are *highly dependent* on the RGB color space chromaticities. These operations give odd, wrong, unexpected, unwanted and sometimes completely unuseable results after an image is converted from wider gamut color spaces to unbounded mode sRGB.

I'm not merely speculating about what "might work" and what "might not work". I've providing concrete examples.

I encourage everyone on this list who shoots raw to output your images in a larger color space like ProPhotoRGB, pick some of the more saturated images, and compare what happens when editing in the larger gamut color space vs editing in the unbounded mode sRGB.

Your testing will be made somewhat complicated by the fact that GIMP does background TRC conversions between the sRGB TRC and the linear gamma TRC. The workaround is to output your interpolated raw file images as ProPhotoRGB with the sRGB TRC. RawTherapee allows you to do this very easily. Just pick "RT_Large_gsRGB" as the "Output Profile".

Open the image with GIMP from git, and change the precision to 32-bit floating point linear precision.

Then go back to the unedited image, change the precision to 32-bit floating point linear precision, *convert to unbounded mode sRGB* (the built-in GIMP sRGB profile), and repeat the edits.

Compare the two resulting images and see whether you think editing all images in the unbounded mode sRGB color space will work for you.

Perhaps I'm making mistakes in my tests, but I don't think so. Perhaps there is a workaround for the examples I've posted, but I think the only realistic workaround is to not convert the image to the unbounded mode sRGB color space in the first place.

Elle Stone

On 04/11/2014 09:15 AM, Elle Stone wrote:

Open the image with GIMP from git, and change the precision to 32-bit floating point linear precision.

Then go back to the unedited image, change the precision to 32-bit floating point linear precision, *convert to unbounded mode sRGB* (the built-in GIMP sRGB profile), and repeat the edits.

Drat, typos. Above should read:

Open the image with GIMP from git, and change the precision to 32-bit floating point linear precision. Stay in the RT_Large_gsRGB and edit as usual.

Then go back to the unedited image, change the precision to 32-bit floating point linear precision, *convert to unbounded mode sRGB* (the built-in GIMP sRGB profile), and repeat the edits.

Sorry!

Elle

On 04/09/2014 06:36 PM, Elle Stone wrote:

For Lighten only, Darken only, Multiply, Divide, and some of the other blend modes, results are *highly dependent* on the color space in which the blending is done. Removing clipping code doesn't fix the problem.

Here's another blend mode example, this time for the Divide blend mode: http://ninedegreesbelow.com/gimpgit/unbounded-srgb-divide-blend-mode.html

Conclusion:

The Divide blend mode assumes the image RGB values are in fact bounded by 0.0 and 1.0, which means technical uses of Divide fail completely after converting a saturated image from its original wider gamut color space to unbounded mode sRGB.

For example, dividing an image by the reddest possible red should send the green and blue channels of all the pixels to 1.0, leaving behind only varying shades of cyan. So after converting a saturated image from its original camera-sized RGB color space to the unbounded mode sRGB color space, dividing by 100% saturated red ("camera red" or sRGB red) failed.

Artistic use of Divide blend mode produces different colors after converting an image to unbounded mode sRGB. In a line drawing produced in the ProPhotoRGB color space, the space between the lines was almost white. In the unbounded mode sRGB color space, the same procedure produced a line drawing with a yellow color cast over much of the image.

Elle

On 04/09/2014 06:36 PM, Elle Stone wrote:

To make it easier for people to test and see for themselves how unbounded mode sRGB doesn't work for all editing operations, in the following posts I put up links to the test files:

http://ninedegreesbelow.com/gimpgit/unbounded-srgb-lighten-darken.html

http://ninedegreesbelow.com/gimpgit/unbounded-srgb-divide-blend-mode.html

http://ninedegreesbelow.com/gimpgit/unbounded-srgb-channel-blend-convert-black-white.html

http://ninedegreesbelow.com/gimpgit/unbounded-srgb-channel-mixer-decrease-saturation.html

On 04/12/2014 06:45 PM, Øyvind Kolås wrote:

On Fri, Apr 11, 2014 at 11:54 PM, Elle Stone wrote:

On 04/09/2014 06:36 PM, Elle Stone wrote:

For Lighten only, Darken only, Multiply, Divide, and some of the other blend modes, results are *highly dependent* on the color space in which the blending is done. Removing clipping code doesn't fix the problem.

You seem to be under the impression that all processing whatever the operation is done going to happen in one color space/pixel format a "working space". In a GEGL processing world; it is the individual operations that have working spaces; there is no global working space that things happen in. (NB: having gamma toggles in blending modes of GIMP is according to this model making things confusing, compositing in different color spaces should be _different_operations_).

I think you might be using the phrases "color space" and "working space" in a way that, although technically correct, perhaps might be confusing to a lot of people.

My understanding of what you mean by "color space/working space" is as follows:

In the strongly color-managed world of BABL and GEGL, the only *RGB* color space/working is *s*RGB, either the linear gamma/light sRGB or the more perceptually uniform regular sRGB with its not quite gamma=2.2 TRC.

And then there is:

sRGB converted to CIELAB. sRGB converted to HSL.
sRGB converted to HSV.
sRGB converted to CMY(K).
sRGB converted to Gray.
sRGB converted to YCbCr.
sRGB converted to some other model of color space, such as XYZ or CIELUV, for which code might be written at some point in the future.

The key point is that the chromaticities of the *RGB* color space, that might be converted to some other *model* of color space, are *always* the *s*RGB chromaticities.

Is what I just wrote accurate? if yes, please confirm, If not, please explain where my understanding has gone awry.

I've asked this question of what is actually meant by "color space/working space" in the world of BABL and GEGL twice before now, and no one has answered. But it's a pretty important point, so I'm asking again.

Thanking you in advance for confirmation/clarification of what "color space/working space" means when discussing *BABL/GEGL* color spaces/working space,

Elle

On 04/13/2014 06:41 AM, pippin@gimp.org wrote:

On Sun, Apr 13, 2014 at 06:18:08AM -0400, Elle Stone wrote:

In the strongly color-managed world of BABL and GEGL, the only *RGB* color space/working is *s*RGB, either the linear gamma/light sRGB or the more perceptually uniform regular sRGB with its not quite gamma=2.2 TRC.

There is no linear gamma *or* perceptually uniform choice at import. There is a conversion to one of the babl-managed pixel formats; and after that GEGL operations are free to convert between any of the unbounded babl formats.

I didn't mean to imply that there was a choice of which TRC to choose upon import. The plan seems to be that when GIMP 2.10 is released the image will be converted from its source color space to a color space with the sRGB chromaticities.

Whether that sRGB color space is actually linear gamma sRGB or sRGB with the regular sRGB tone reproduction curve is a separate question. You are saying that which TRC is used depends on the operation in questions. For example currently heal and drawing a gradient are done using the sRGB TRC. And Scale, Gaussian blur, and Unsharp Mask are done using the linear gamma TRC. Yes?

The point is that when GIMP 2.10 is released, regardless of what happens to the TRC upon import, the *chromaticities* used for all further processing will be the sRGB chromaticities, NOT the chromaticities of the source color space. This point has been confirmed several times.

GIMP is making things more confusing by letting an arbitrary extra parameter change the behavior of compositing ops; this "feature" is something I consider a bug, it shouls also be considered bugs to do operation in linear space if the algortihm of a GEGL op behaves incorrectly/really unexpectedly unless it works in a more perceptual space.

OK, so in the interests of consistency, the limited current choice between allowing an operation to happen in the linear gamma sRGB color space vs the more perceptually uniform regular sRGB color space should be eliminated, yes? You consider this UI user choice to be a bug, yes?

I've asked this question of what is actually meant by "color space/working space" in the world of BABL and GEGL twice before now, and no one has answered. But it's a pretty important point, so I'm asking again.

Thanking you in advance for confirmation/clarification of what "color space/working space" means when discussing *BABL/GEGL* color spaces/working space,

Not sure if this is a clarification; I do not know what you mean by the terms either and can only tell you what the intended architecture of GEGL is

sRGB converted to CIELAB.
sRGB converted to HSL.
sRGB converted to HSV.
sRGB converted to CMY(K).
sRGB converted to Gray.
sRGB converted to YCbCr.
sRGB converted to some other model of color space, such as XYZ or CIELUV, for which code might be written at some point in the future.

In the folder babl/extensions, see ycbcr.c, naive-CMYK.c, grey.c, HSV.c, HSL.c, CIE.c. These conversion are between the sRGB RGB color space and various other color space models, namely CIELAB, HSL, HSV, CMY(k), Gray, and YCbCr.

The sRGB TRC is assumed in many places in the BABL code. To see what I mean, do a command line search in the babl source code folder:

find -name "*.c" -or -name "*.h" | xargs grep -H "gamma_2_2" {} \;

The sRGB chromaticities are assumed in various places in BABL, GEGL, and GIMP. Do a search for the word LUMINANCE, although some places have the values hard-coded.

The key point is that the chromaticities of the *RGB* color space, that might be converted to some other *model* of color space, are *always* the *s*RGB chromaticities.

There is no provision for converting from some other RGB color space to these other color models. The only provision is for converting from sRGB to these other color space models.

On 04/12/2014 06:45 PM, yvind Kols wrote:>

You seem to be under the impression that all processing whatever the operation is done going to happen in one color space/pixel format a "working space". In a GEGL processing world; it is the individual operations that have working spaces; there is no global working space that things happen in. (NB: having gamma toggles in blending modes of GIMP is according to this model making things confusing, compositing in different color spaces should be _different_operations_).

I do think I understand what you are saying. Gaussian blur, Unsharp Mask, and Scale are examples of operations that give technically incorrect results when done in a nonlinear RGB color space. So you are saying GEGL/GIMP shouldn't allow the choice to perform these operations in the regular sRGB color space with its almost perceptually uniform TRC, yes? Rather they should only be done in linear gamma space, which is actually how it works right now.

And if the operation is better done in in some other color space *model*, not RGB but rather perhaps CIELAB or HSL or whatever, then the conversion is now and will always be from *sRGB* to CIELAB, HSL or whatever, yes?

Elle

On 04/13/2014 09:30 AM, Elle Stone wrote:

On 04/13/2014 07:54 AM, Teo Mazars wrote:

Hello,

In the strongly color-managed world of BABL and GEGL, the only *RGB* color space/working is *s*RGB, either the linear gamma/light sRGB or the
more perceptually uniform regular sRGB with its not quite gamma=2.2 TRC.

And then there is:

sRGB converted to CIELAB. sRGB converted to HSL.
sRGB converted to HSV.
sRGB converted to CMY(K).
sRGB converted to Gray.
sRGB converted to YCbCr.
sRGB converted to some other model of color space, such as XYZ or CIELUV, for which code might be written at some point in the future.

The key point is that the chromaticities of the *RGB* color space, that
might be converted to some other *model* of color space, are *always* the *s*RGB chromaticities.

I am not the expert but this is how I understand the thing too.

Thanks! Teo, it's nice to know that my understanding isn't completely off the wall.

Though
HSL, HSV and babl's naive CMY(K) are not relevant here since these are non-absolute color spaces.

HSL, HSV are defined relative to the RGB color space the image happens to be in, which I think is what you mean by "non-absolute" color spaces.

So if you use LCMS to convert from an RGB color space to HSL or HSV, then the resulting HSL/HSV values depend entirely on the source RGB color space. Changing the source color space changes the resulting HSL/HSV colors. I don't think there's any LCMS code for naive CMY where C=1-R, M=1-G, etc, but if there were, it also would produce different results depending on the source RGB color space.

However, if you use the BABL code to convert to HSL, HSV, etc, the resulting values are only correct if the image has the sRGB chromaticities. The same is true for converting to Gray, YCbCr, etc.

Also, I am not quite sure about seeing it as sRGB centric:

In other words,
we could easily say the same thing replacing "linear sRGB" by "XYZ" or even "CIELab".

As an important aside, CIELAB is an *adjunct* to RGB editing, a very important and useful adjunct, but not a wholesale replacement for *any* RGB operation. Any image editor that, for example, limits tonality changes to manipulating the CIELAB L* curve is crippled as an RGB image editor.

The problem would be then that most GEGL operations ask for either linear or regular "sRGB", and thus may expect the chromaticities to be those of sRGB.

From what I've seen and based on testing, the BABL/GEGL/GIMP operations that depends on the regular sRGB almost gamma=2.2 *tone reproduction curve* -- apart from any dependence on the sRGB chromaticities -- will work perfectly with, for example data that has the ProPhotoRGB chromaticities and the sRGB tone reproduction curve ("TRC"). Those portions of the code are completely dependent on the sRGB TRC (or else the "gamma corrections" won't work correctly). But they are not dependent on the sRGB chromaticities.

The portions of the code that depend on the sRGB *chromaticities* have to do with calculating Luminance (converting to gray using Luminance, some of the noise reduction algorithms) and with converting from sRGB to other color spaces such as CIELAB, HSV, HSL.

even though
conversions are done internally through linear sRGB, the fact that this is an invertible linear transformation of the XYZ color space makes it mathematically equivalent in terms of gamut.

All that to say that technically babl is not stuck with sRGB chromaticities,

Technically BABL may not be stuck with sRGB chromaticities, but it uses them in an awful lot of code.

but that some GEGL's operations expect them. Also, as a side note and as far as I know, there is no gamut mapping algorithm currently in babl nor GEGL.

Gamut mapping would be useful for soft proofing, but I'm not sure what the relevance is in the current context.

The problem with converting all images to use the sRGB chromaticities instead of the source color space chromaticities is as follows:

*Many editing operations work just fine regardless of the color space chromaticities.
*Many other operations fail completely, and/or don't work as well, resulting in arbitrary color changes when the color space chromaticities are arbitrarily changed from the source color space to the sRGB color space.

It's the chromaticities change that causes problems, not the TRC. The TRC can be modified and gamma corrected.

Elle

On 04/13/2014 09:34 AM, Michael Henning wrote:

You are correct in the sense that *right now*, most of the babl color spaces are based on the sRGB chromaticities. There is nothing preventing us from adding different color spaces in the future, including ProPhoto RGB.

Can you add my custom RGB color space that works best with my interpolated raw files? And the next person's custom RGB working space? I've done a lot of experimenting with RGB color spaces over the years. Editing my interpolated raw files in my camera-sized RGB working space space gives the best results. The colors stay the truest. All channel data is available and can be manipulated without having the channel data contaminated by converting the image to another RGB color space with different chromaticities.

And if the operation is better done in in some other color space *model*, not RGB but rather perhaps CIELAB or HSL or whatever, then the conversion is now and will always be from *sRGB* to CIELAB, HSL or whatever, yes?

No, not always. Gimp already has the option of storing your image in a linear or perceptual gray color space, as well as different indexed formats. As above, new formats can be added easily.

If there is a way to input the chromaticities of my chosen RGB color space, and do ALL editing using those chromaticities, that would be wonderful. The thing is, without a way for the user to input his or her chosen chromaticities, you are severely limiting the user's creative use of different color spaces. Not all color spaces are equally suited for all editing purposes.

On 04/13/2014 09:34 AM, Michael Henning wrote:

Can I ask: what
difference does it make? If I convert an image from ProPhoto to CIELAB, or if I convert from sRGB to CIELAB, I will get the same result. The gegl operation doesn't care how the data is stored; it only cares what format it receives the data in.

On 04/12/2014 06:45 PM, yvind Kols wrote:

Some GEGL operations make most sense in linear color spaces others make most sense in perceptual color spaces. For consistency in behavior operations should always be made in the same space regardless of whichever source space the images originated.

On 04/13/2014 07:54 AM, Teo Mazars wrote:

even though
conversions are done internally through linear sRGB, the fact that this is an invertible linear transformation of the XYZ color space makes it mathematically equivalent in terms of gamut.

Assume unbounded mode ICC profile conversions from one linear gamma color space to another (and putting aside all concern with things like exporting to jpeg, which apparently does require a perceptually uniform TRC):

The following operations are (probably, I'm still testing some of them) *completely independent* of the RGB color space chromaticities:

1. Multiplying and dividing by gray, black, or white. 2. Adding and subtracting.
3. Any blend modes that makes use of adding and subtracting, including grain merge, grain extract, difference. 4. Normal blend mode.
5. Levels upper sliders (which produce the same result as dividing or multiplying by gray).
6. Gaussian blur.
7. Unsharp Mask.
8. Scaling.

The following operations are *highly dependent* on the RGB color space chromaticities:

1. Multiplying and dividing by any color other than gray, black, or white. 2. Any blend mode that involves multiplying or dividing, including burn, dodge, soft light, hard light.
3. The lighten only, darken only, hue, saturation, color, and value blend modes.
4. Channel mixer.
5. Any editing move that involves pulling over an individual channel and using it as a blending layer in a layer stack.

As long as you limit your edits to the chromaticity *in*dependent set of editing operations, you get absolutely consistent results *regardless* of what unbounded mode color space you convert to. The chromaticities don't matter.

As soon as you employ any of the chromaticity *dependent* operations, then you have problems. Lettuce turns yellow when using Divide to make a line drawing. Channel mixer can't be used desaturate a saturated yellow flower. The blue channel in that same yellow flower can't be used as a blending layer in a conversion to black and white. And so on.

Elle

On 04/13/2014 11:26 AM, Gez wrote:

El dom, 13-04-2014 a las 00:45 +0200, Øyvind Kolås escribió:

I think that what Elle is asking is about the RGB operations that break with ubounded sRGB chromaticity values. Several operations don't seem to be suitable for chromaticity values beyond the 0,1 range.

Yes, some operations break because they weren't designed to work with RGB values less than 0 or greater than 1.

But even if the image is clipped to the sRGB color gamut such that no RGB values are less than 0 or greater than 1, forcing the conversion to sRGB rearranges the channel data radically, depending on the source color space and also the image color gamut. Consequently fundamental editing operations like Channel Mixer and channel blending no longer work as expected.

And even if the image is clipped to the sRGB color gamut, the results of divide, multiply, lighten only, darken only, hue, saturation, color, value, etc are altered by the conversion, and not in a good way.

Elle

On 04/13/2014 11:49 AM, Elle Stone wrote:

Forcing the conversion to
sRGB rearranges the channel data radically, depending on the source color space and also the image color gamut. Consequently fundamental editing operations like Channel Mixer and channel blending no longer work as expected.

I would ask the GIMP developers to please take a look at this link:

http://ninedegreesbelow.com/gimpgit/unbounded-srgb-channel-blend-convert-black-white.html

The test file can be downloaded. The profiles are also available.

The black and white conversion that I envisioned and accomplished with trivial simplicity in the custom RGB working space *can't be done* in the sRGB color space, unbounded ICC profile conversion notwithstanding.

Thanks in advance to anyone who reads the post and tries the conversion to black and white in the sRGB color space.

Elle

On 04/13/2014 12:16 PM, Teo Mazars wrote:

HSL, HSV are defined relative to the RGB color space the image happens
to be in, which I think is what you mean by "non-absolute" color spaces.

So if you use LCMS to convert from an RGB color space to HSL or HSV, then the resulting HSL/HSV values depend entirely on the source RGB color space. Changing the source color space changes the resulting HSL/HSV colors. I don't think there's any LCMS code for naive CMY where
C=1-R, M=1-G, etc, but if there were, it also would produce different results depending on the source RGB color space.

Regarding programming in the ability for the user to specify chromaticities, and/or hard-coding in specific RGB color spaces like ProPhotoRGB, why not just remove *all* the chromaticitiy-specific (mostly luminance-calculating) code and replace it with appropriate calls to LCMS?

However, if you use the BABL code to convert to HSL, HSV, etc, the resulting values are only correct if the image has the sRGB chromaticities. The same is true for converting to Gray, YCbCr, etc.

Exactly, babl only knows about absolute color spaces so far, and non-absolute ones are hard-wired using sRGB, which is wrong.

The conversion to CIELAB is also hardwired to use the sRGB (unadapted) chromaticities, currently also to clip a and b channels:

MAKE_CONVERSIONS (u16_ab, -128.0, 127.0, 0x00, 0xffff)

This means some real colors are clipped upon conversion to CIELAB (real violet blues, real blue greens, real yellow greens, greens, and orange yellows).

See http://brucelindbloom.com/index.html?LabGamutDisplayHelp.html, section on integer encoding of CIELAB.

The current code also clips to 100.0 on the L* axis, which means if one is using unclipped RGB data for HDR values, they also will be clipped upon conversion to LAB:

MAKE_CONVERSIONS (u16_l, 0.0, 100.0, 0x00, 0xffff)

LCMS can make unbounded mode conversions to CIELAB, without clipping the data. The BABL code also could be rewritten to do unbounded mode floating point conversions to CIELAB. I made a quick stab at it, but haven't yet figured out all the moving parts.

In any event, converting from any source color space to unbounded mode sRGB and then to CIELAB theoretically should give the same results as converting from the source color space directly to CIELAB. The same would be true of conversion to XYZ.

About the general topic, the point would be that babl's RGB format should have arbitrary chromaticities instead of fixed ones? Not sure about implications of that... Operations should be then able to request some data about the color space given, like coordinates of primaries, and use them instead of the traditional [0.0,1.0]³. Operations should still be able to know absolute values, and to request either a perceptual or a linear light color space with those chromaticities. If I am not completely off, how this should be done is unclear to me.

Sometimes I think there might be some confusion over what it takes to edit an image in a linear gamma color space. *All* you really need is a high bit depth image editor and the linear gamma color space of your choice.

You don't *need* all the background "stuff" that BABL/GEGL/GIMP has programmed in to guide code to use or not use "gamma corrected" or "perceptually uniform" RGB values. All that background "stuff" presumes the image color space has the sRGB TRC. You could eliminate that code and just open an image that's already in a linear gamma color space.

If *all* the BABL code that converts back and forth between the sRGB TRC and linear gamma were simply removed, along with *all* the BABL/GEGL/GIMP code that currently codes choices and paths between gamma-corrected and not gamma-corrected operations:

*The code would be simpler.

*The user could *choose* to use a linear gamma color space with the chromaticities of his or her choice. Or they could *choose* to edit in the more perceptually uniform color space of their choice.

I'm not merely speculating about the code simplification. I keep a copy of BABL/GEGL/GIMP modified to eliminate the background conversions, just so I can edit my linear gamma images in my linear gamma color space of choice. Every now and again I take a stab at eliminating some more code, just to see how far I can take it.

One remaining issue in my modified BABL/GEGL/GIMP is the hard-coded sRGB luminance values. I took the easy route and replaced the sRGB values with the luminance values from my custom RGB working space. But the right way to deal with this issue is to use LCMS to retrieve the color space chromaticities.

Having said all that, the BABL conversions back and forth between sRGB TRC (almost perceptually uniform) and linear gamma provide the obvious advantage of being able to allow the user to choose to switch at will between "gamma" corrected and linear RGB values. All the user would need is a color space that has the sRGB TRC, along with whatever chromaticities the user wants.

Except right now some operations (for example Unsharp Mask, Scale, Gaussian blur) are programmed to "always" gamma correct, which takes choice away from the user and also prohibit editing an image that is already in a true linear gamma color space.

Also, I am under the impression that it conflicts slightly with the "each operation ask for the color space it needs" idea.

I am confused as to why this choice of whether to operate on linear RGB data or more perceptually uniform RGB data should be taken away from the user and hard-coded into BABL/GEGL/GIMP.

It seems to me that the better approach would be to write some good documentation and allow the user to make his/her own choice about whether to operate on "gamma" corrected RGB values or not.

What if the user really wants to operate on data that isn't "gamma corrected"? What if the user really wants paint strokes to have dark edges? What if they do want gray rather than yellow between red and green when they do a Gaussian blur, for some specific artistic intent or because that's what they've always done?

Choice is good. Right now there is some very limited user choice about what to gamma correct and what to not gamma correct. I think the choice should extended to *all* operations.

Back to the hard-coded BABL conversions between linear gamma and the sRGB TRC. Those conversions do serve the very nice purpose of allowing the user to switch back and forth between working with linear data and perceptually uniform data.

As currently coded those conversions can be used with *any* color space chromaticities, as long as the source color space has the sRGB TRC, which profiles are easy to make.

A proposed course of action:

1. Leave the BABL conversions back and forth between linear and the sRGB TRC.

2. Distribute commonly used ICC profiles with the same TRC that the BABL conversions are using (the sRGB TRC, but it might just as well be gamma=2.2 or lstar). RawTherapee already allows to output in a color space with the ProPhotoRGB chromaticities and the sRGB TRC.

3. Keep the GIMP distinction between "GAMMA" and "LINEAR" precision.

4. "Gamma" correct *all* operations that are done using LINEAR precision.

5. Remove *all* "gamma" corrections from operations that are done using GAMMA precision.

4 and 5 together give the user three choices:

* They can open a true linear gamma image and edit it at GAMMA precision (sounds confusing, but that's what would be required). But they won't benefit from the option to switch back and forth between linear and "gamma" corrected RGB values.

*Or they can open an image in a perceptually uniform color space, keep it at GAMMA precision, and not have anything at be "gamma" corrected.

* Or they can open an image in the color space of their choice, as long as the TRC for that color space is the TRC that BABL is using, currently the sRGB TRC, and then have the option to switch back and forth between operations done in linear and perceptually uniform RGB values.

6. Write up the code that calls on LCMS to retrieve chromaticities from the image color space to take the place of hard-coded sRGB Luminance values.

7. Write up documentation explaining to the user how everything all hangs together.

Anyway, that's my proposed solution. I can help with items 6 and 7.

Elle

Going beyond blend modes, the Levels upper and lower sliders work in unbounded mode sRGB, but the gamma sliders do not:

http://ninedegreesbelow.com/gimpgit/unbounded-srgb-levels-gamma-slider.html

Here's a link to all the tests that I've put up so far:

http://ninedegreesbelow.com/gimpgit/unbounded-srgb-what-works-what-does-not.html

I outlined the testing procedures and included links to the test files. So anyone can duplicate the results and/or find errors in my testing.

If I have made errors in my testing, feedback and correction is very welcome.

Elle