My apologies for the delay in responding.

I've known since 2012 that the plan for GIMP was to eventually force all editing to be done in the unbounded mode sRGB color space.

I never liked the idea of unbounded mode sRGB image editing, but I did assume it would work. I even prepared a couple of demonstrations showing that editing in the unbounded mode sRGB color space produced the same results as editing in any other well behaved RGB working space.

Unfortunately the demonstrations that I prepared only happened to use operations like addition, scaling, and gaussian blur. These operations produce exactly the same results in *any* linear gamma unbounded mode color space.

So I ignored the whole "unbounded mode sRGB" thing, coded up for my own use a version of BABL/GEGL/GIMP that doesn't do the background conversions between regular ("perceptual") and linear gamma ("linear light") sRGB, and substituted the hard-coded XYZ values of my preferred working space for the hard-coded sRGB XYZ values. That way I could edit my interpolated raw files in the true linear gamma color space of my choice.

As GIMP progressed toward 2.10, it seemed like more in-depth testing of unbounded mode sRGB image editing might be in order, especially as a couple of people wrote to me privately and told me that they didn't think editing in unbounded mode sRGB would work.

When I tried to present to these people evidence that unbounded mode sRGB does really work, the suggestion was made that I try an editing operation that used channel data. So I did. I started with the yellow cone flower, which immediately tripped over the problem of drastically shifted channel data.

I continued testing and found that many other editing operations don't work in unbounded mode sRGB.

I feel like I should be apologizing right and left for not having thoroughly tested unbounded mode sRGB a year ago. Or two years ago. But like I said, I thought it would work.

In the last couple of months I've been studying the problem. There are many problems with unbounded mode sRGB image editing. Two problems in particular are insurmountable:

1. Multiplying out of gamut RGB values produces meaningless results:

http://ninedegreesbelow.com/gimpgit/unbounded-srgb-multiply-produces-meaningless-results.html

The result of multiplying colors in unbounded mode sRGB depends on whether or not one or both colors are out of gamut with respect to the bounded sRGB working space chromaticities.

When multiplying an out-of-gamut color with an in-gamut color, and when multiplying two out-of-gamut colors, the resulting color might be:

* A color that's too bright and has the wrong hue.

* A color that's not only out of gamut with respect to the bounded sRGB chromaticities, but also out of gamut with respect to the image's source color space (multiplying in-gamut colors in any RGB working space never produces out of gamut colors).

* A physically impossible color that's technically in gamut with respect to the bounded sRGB chromaticities, but has a negative Luminance.

* A physically impossible and completely imaginary color that has a negative Luminance.

You can't edit images without multiply. So any image editing model that produces meaningless results multiply is flawed and should be abandoned.

If GIMP really is going to force all editing to be done using the sRGB chromaticities, then there are only two options that avoid the production of meaningless colors from using multiply during image editing:

* Either GIMP should be patched to remove every single editing operation that makes use of multiplication. This is a terrible path to take, but the alternative with unbounded mode sRGB is error compounding upon error as editing proceeds.

* Or else the "unbounded" part of "unbounded mode sRGB only" should be removed from GIMP, and the user should only be allowed to edit *bounded* sRGB images. This also is not a good option in this day and age of wide gamut displays and digital cameras that shoot raw and easily capture real world colors that don't fit within the very small bounded sRGB color gamut.

2. Multiplying two colors produces different results in different color spaces, depending on the color space chromaticities. This inescapable mathematical reality affects any editing operation that involves multiply. Perhaps the most centrally important result from the point of view of the working photographer who might like to use GIMP is that a color cast created in a wider gamut color space simply cannot be properly corrected in the unbounded mode sRGB color space:

http://ninedegreesbelow.com/gimpgit/unbounded-srgb-color-correction-fails.html

A color cast is created by multiplying an image layer by a particular color (R,G,B). That same color cast is removed by multiplying the image layer by the inverse of that same color (1/R, 1/G, 1/B).

Colors do have the same locations in XYZ space before and after an image is converted from some other color space to unbounded mode sRGB. But the channel values are different. This has the perhaps unexpected consequence that a color cast that is created in some other color space can't be correctly removed in the unbounded mode sRGB color space. The problem, of course, is that the result of multiplying two colors depends on the chromaticities of the color space in which the multiply operation is performed.

There are many excellent open source image editing programs. But GIMP is the single most crucially important open source image editing software for photographers. Color management in GIMP needs to be perfect. Results of editing operations in GIMP need to be perfect. Photographers who use masks and layers in an RGB workflow don't have a suitable open source replacment.

Unbounded mode sRGB will produce erroneous results every single time a photographer uses an editing operation that depends on multiply, except in the limiting case of only editing bounded mode sRGB images. This isn't what anyone intended, but it *is* a mathematical consequence of converting images to unbounded mode sRGB:

(1)Multiplying out of gamut colors produces meaningless colors. (2)Results of multiplying colors depends on the color space chromaticities.

The results of my investigations into unbounded mode sRGB are here: http://ninedegreesbelow.com/gimpgit/unbounded-srgb-what-works-what-does-not.html

If the developers can show that I'm wrong about unbounded mode sRGB, that's great!

In case the developers decide that unbounded mode sRGB really won't work, here's a patch to remove most of the BABL/GEGL/GIMP dependence on hard-coded sRGB and instead allow editing in any RGB working space:

http://ninedegreesbelow.com/gimpgit/unbounded-srgb-any-rgb-working-space-patch.html

I have very much enjoyed working with the GIMP developers over the last two years. I've learned far more from you all than the little bits that I've managed to contribute in return. I hope to continue working with all of you for the next two years. But unbounded mode sRGB is a flawed model for image editing.

Best and warmest regards,

Elle Stone

On 05/24/2014 01:26 PM, Øyvind Kolås wrote:

I've been thinking about how different color-space aware workflows could work in our future GEGL powered GIMP. In particular about the on-going theme of how to deal with "slight HDR" images, that have a gamut including colors that are slightly outside the 0.0-1.0 range for linear sRGB.

I'm not sure what you mean by '"slight HDR" images, that have a gamut including colors that are slightly outside the 0.0-1.0 range for linear sRGB'.

Converting a display-referred ProPhotoRGB image that has colors that exceed the very small bounded sRGB color gamut, from ProPhotoRGB to unbounded mode sRGB, doesn't create a "slight HDR" image.

The dynamic range of the display-referred ProPhotoRGB image colors doesn't change when the image is converted to unbounded mode sRGB. Just the chromaticities used to encode the RGB data change.

In the unbounded mode sRGB color space the relationship between channel values and intensity is broken. The resulting image is neither display-referred nor magically made into "high dynamic range" scene-referred.

See "Unbounded mode sRGB is neither display-referred nor scene-referred",
http://ninedegreesbelow.com/gimpgit/unbounded-srgb-display-scene-bounded.html

The primary goal will still be adapting channel displays; histograms etc. to encompass/translate to show the 1.0 values; in relation to a defined target/output profile. A hybrid linear-centric approach might also work well.

Is the "target/output profile" to which you are referring the *source* profile, meaning the ICC profile that the image was in before it gets forcibly converted to unbounded mode sRGB?

Or is the "target/output profile" the ICC profile to which the user intends to eventually convert the image, such as perhaps a printer profile?

What do you mean by "hybrid linear-centric approach"?

If we on import linearise the data (using the RGB primaries of the source color space), and then scale values down based on the magnitude of the most intense primary, and pretend that the resulting data is "RGBA float"; there will neither be cross component contamination nor "out-of-ui-range" values.

If you are talking about scaling the data so that any possible color in the source color space would fit into the very small bounded sRGB color gamut, that a pretty large scale factor for ProPhotoRGB.

I have not done actual experiments - to see the impact doing this would have on the visual result,

I did an experiment. I downloaded Bruce Lindbloom's RGB16Million test image (http://brucelindbloom.com/index.html?RGB16Million.html), bumped the precision to 32-bit floating point, assigned the regular gamma=1.80 ProPhotoRGB ICC profile, and converted the image to linear gamma ProPhotoRGB.

Then I set Preferences/Color Management/Mode of operation to Print simulation, set the Print simulation profile to a linear gamma sRGB profile, and chose "Mark out of gamut colors".

Then I used Levels and moved the Output lower and upper sliders to 33.00 and 67.00, which just made the out of gamut colors disappear. The image was very desaturated with the dynamic range cut to a third.

Repeating the same procedure with actual images likewise produces extremely desaturated colors. And the channel data is *still rearranged*.

If you don't want to rearrange the channel data and you do want the image to be in the unbounded mode sRGB color space, you can *assign* the sRGB profile, in which case the channel data is preserved and the colors are completely wrongly interpreted.

it gives up some aspect of color
management -

Why should people who use GIMP be expected to give up any aspect of color management? The whole point of a color-managed workflow is to be able to see the image colors to the extent that the monitor profile's color gamut allows.

but deal correctly with the tone-response curves.

Could you explain what you mean?

I
suspect the dominant side effect will be a slight loss in luminance.

If there is code you would like tested or an experiment with images that you'd like to see done, but you don't have time to do the testing yourself, let me know and I'll try to do the testing for you.

Elle