Re: [Gimp-developer] Possible approach for some non-sRGB GEGL/GIMP color workflows

[Elle Stone <ellestone ninedegreesbelow com>]

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