[Gimp-developer] Interoperability problems between GIMP and other high bit depth image editors

[Elle Stone <ellestone ninedegreesbelow com>]

There are interoperability problems between high bit depth GIMP and 
other high bit depth image editors.

Much of what follows relates to bug 751553, "Linear precision doesn't 
display the image correctly" 
(https://bugzilla.gnome.org/show_bug.cgi?id=751553), which is a first 
step in fixing the problems described below.

I'm assuming for the sake of argument that all GIMP editing operations 
that currently do request RGBA, really should request RGBA (that is, for 
radiometrically correct results, the operation ought to be performed on 
linearized RGB), and this assumption is mostly true. These operations 
include, for example, Gaussian blur, scaling, Channel Mixer, and 
converting to black and white using mono-mixer or Luminance.

The same cannot be said for GIMP editing operations that currently 
request R'G'B'A:

* For radiometrically correct results, Curves, Levels, Auto-Stretch, 
Invert and etc, should be performed on linearized RGB.
* Drawing a radiometrically correct gradient requires using linearized RGB.
* Almost all of the Layer blend modes, including Normal, Multiply, 
Divide, Addition, and Subtract, should be performed on linearized RGB. 
The same is true for painting using these Layer blend modes. The layer 
blend modes and corresponding painting modes do currently request RGBA 
when using linear precision, but not when using gamma precision.

To illustrate the interoperability problem, think of a Krita user who 
uses Krita to paint digital images, using the linear gamma sRGB color 
space to avoid the various artifacts that result from painting and 
blending colors using the regular sRGB color space.

Let's say the Krita user exports a high bit depth linear gamma sRGB png 
or tiff from Krita, so she can work on the image using high bit depth GIMP:

When using Krita to edit her linear gamma image, all operations were 
done on linear RGB. Here's what happens when she tries to edit the image 
using GIMP:

Upon opening the linear gamma sRGB tif or png, the image will 
automatically be at gamma precision. As long the Krita user remains at 
gamma precision, some editing operations will produce completely wrong 
results, and some will produce radiometrically correct results:

* If the Krita user performs a Gaussian blur, or scales the image, or 
draws a gradient, or paints or blends layers together, or converts the 
image to black and white or uses Channel Mixer or performs  any other 
operation that by default requests RGBA, results will be wrong, which is 
to say, results won't be radiometrically correct, because the already 
linear gamma RGB data is automatically "linearized" by "correcting" a 
non-existent sRGB TRC encoding.

* Also the LCH blend modes won't work because LCH blend modes require 
operating on linearized RGB, which means babl applies a TRC correction 
to data that presumably is encoded using the sRGB TRC, which turns the 
previously linearly encoded RGB to data that's encoded using 
approximately the gamma=0.45 TRC.

* However, if the Krita user draws a gradient while at gamma precision, 
she'll get a radiometrically correct linear gamma gradient, as no doubt 
she expects to get if she's been using Krita to edit linear gamma sRGB 
images.

* And if the Krita user does a Curves or Levels operation (or any other 
operation that by default currently requests R'G'B'A when for 
radiometrically correct editing RGBA should be requested), again, she'll 
be operating on linear gamma RGB and results will be exactly as 
expected, which is to say, radiometrically correct.

* And for the Krita user who opens a linear gamma sRGB image that she 
exported from Krita, all the layer blend modes such as Normal, Multiply, 
Addition, Subtract, Divide, that ought to work on linearized RGB to 
produce radiometrically correct results, will in fact produce 
radiometrically correct results, because at gamma precision, the 
babl/GEGL/GIMP code *doesn't* request linearized RGB for any of the 
blend modes.

* This applies to painting also, so the Krita user can paint on her 
(already linear gamma) image using high bit depth GIMP without any gamma 
artifacts.

So as GIMP is currently coded, the Krita user who opens a linear gamma 
sRGB image with GIMP and stays at gamma precision will get 
radiometrically correct results for a whole lot of editing operations 
that currently produce incorrect results for GIMP users who open a 
regular sRGB image.

But if the Krita user tries to use Gaussian blur or scaling or any other 
editing operation for which RGBA is currently requested, she'll get 
incorrect results, because the babl/GEGL/GIMP code applies an "anti-sRGB 
TRC 'gamma' correction" before performing these operations. Applying an 
"anti-sRGB TRC 'gamma' correction" produces RGB that's encoded using a 
gamma of approximately 0.45, which is just as far from linear as 
gamma=2.2, but in the opposite direction.


Now let's say the Krita user changes the image precision to linear 
precision:

* All the Layer blend modes will still work using linearized RGB, 
because currently GIMP will (try to) automatically convert the image to 
a color space with the user's original color space primaries, and a 
linear gamma TRC (which of course is how the image data was already 
encoded when the Krita user exported the image to disk in a linear gamma 
sRGB color space). So at this point the Krita user's image data is 
encoded using a linear gamma TRC, exactly as it was when she exported 
the image to disk from Krita. And the Layer blend modes work using 
linearized RGB, exactly as they did before the Krita user switched from 
"gamma" precision to "linear" precision. Painting also will continue 
working on linear RGB.

* The LCH blend modes will work correctly, as will all the other editing 
operations that request RGBA.

* However, now drawing a gradient is done using RGB data encoded using 
the sRGB TRC (R'G'B'A), so the Krita user can no longer draw a 
radiometrically correct gradient.

* And Curves/Levels/Invert/etc will also by default be done using 
R'G'B'A, so results will no longer be radiometrically correct.

Now let's say the Krita user, still editing the image in high bit depth 
GIMP, changes the image precision from linear precision back to gamma 
precision:

* Suddenly Gaussian blur, the LCH operations, and all the other editing 
operations that by default request RGBA, that upon opening the image 
produced *in*correct results, now produce correct results. This is 
because the RGB data is now encoded using the sRGB TRC, and babl 
linearized this TRC to produce linearized RGB, which of course only 
works if the RGB data really is encoded using the sRGB TRC.

* And all the editing operations that currently by default request 
R'G'B'A, but ought to by default request RGBA, such as Normal, Multiply, 
Divide, Addition, and Subtract blend modes, and painting using any of 
these blend modes, and Levels/Curves/Auto-Stretch/Invert, suddenly 
produce radiometrically *in*correct results, because now they are being 
performed on nonlinear RGB. So if she tries to paint on the image at 
gamma precision, she'll get all the gamma artifacts that are the result 
of painting in nonlinear color spaces. And if she draws a gradient, it 
will be radiometrically incorrect because it will be drawn using data 
encoded using the sRGB TRC.


Let's say the Krita user wants to export the edited image to disk to 
continue editing it using Krita. Exporting the modified image back to 
disk becomes very problematic:

If the Krita user keeps the image at gamma precision, and never switches 
to linear precision, the exported image will be in the original linear 
gamma sRGB color space that it was in when she exported the image to 
disk using Krita, and all is good, except that critically important 
editing operations produced wrong results while she was editing with GIMP.

If, while editing the image using GIMP, the Krita user had switched from 
gamma precision to linear precision, there are two possible outcomes (in 
addition to wrong results from various editing operations):

* If she exports the image from GIMP while still at linear precision, 
the embedded ICC profile will have a linear gamma TRC, when actually the 
RGB data exported from GIMP will be encoded using the sRGB TRC. The user 
workaround, upon opening the image with Krita,would be to assign a 
profile with the same primaries as the originally embedded ICC profile, 
but the sRGB TRC, which is to say, assign the regular sRGB profile. 
Unfortunately Krita doesn't currently provide for assigning a new ICC 
profile, so the unsuspecting Krita user - who assumed she could exchange 
image files with GIMP - will be left with no easy options. If she 
manages to figure out what happened to her supposedly linearly encoded 
RGB data, she'll have to close the image, open it with another image 
editor, assign the correct regular sRGB profile, convert to a true 
linear gamma sRGB color space, export to disk, and open the image with 
Krita.

* If she converts from linear precision back to gamma precision, and 
then exports the image to disk,  the exported image's embedded ICC 
profile has the sRGB TRC, and so will require doing an ICC profile 
conversion (with possible attendant data loss) before the Krita user can 
get the image back into the linear gamma sRGB color space that it was in 
before she opened it with GIMP. But the Krita user will no doubt expect 
that the exported image is still in the linear gamma sRGB color space 
that the image was in when she exported the image to disk from Krita and 
opened the image using GIMP, and she will have some serious doubts as to 
what, exactly, GIMP did to her original linear gamma sRGB image, as 
indeed she should have a whole lot of doubts.


My assumption is that all GIMP editing operations ought to produce 
radiometrically correct results. So I've been going through the 
babl/GEGL/GIMP code trying to ensure that all the operations that ought 
to operate on linearized RGB by default, do operate on linearized RGB by 
default, and filing bug reports as appropriate. This is not an easy task 
(there are a lot of GIMP editing operations), so I've been focussing on 
what seems to me to be the most important editing and painting 
operations. See the following bug reports:

* Drawing a radiometrically correct gradient 
(https://bugzilla.gnome.org/show_bug.cgi?id=735897)
* Curves and Levels should operate by default on linear RGB and present 
linear RGB Histograms (https://bugzilla.gnome.org/show_bug.cgi?id=757444)
* Clone should operate on linear RGB by default 
(https://bugzilla.gnome.org/show_bug.cgi?id=757685)
* There is no easy way to do a radiometrically correct invert operation 
(https://bugzilla.gnome.org/show_bug.cgi?id=757686)
* Several additional blend modes should by default blend using 
linearized RGB (https://bugzilla.gnome.org/show_bug.cgi?id=757485 ()

Unfortunately for users of other software that export images to disk in 
linear gamma color spaces because they are trying to obtain 
radiometrically correct editing results, currently every GIMP operation 
that correctly requests linearized RGBA, will be *incorrect* when done 
on imported images that are already encoded using linear gamma RGB, 
until the user has switched from gamma precision to linear precision and 
back.

Possible solutions (there might be other solutions, but these are the 
solutions I've thought of):

1. Upon import, convert all images to unbounded regular sRGB. We've 
discussed problems with this approach at length 
(http://ninedegreesbelow.com/photography/unbounded-srgb-as-universal-working-space.html).

2. Upon import, convert all images to a color space that has the 
original primaries and the sRGB TRC. There are problems associated with 
this approach:

* This only works for well-behaved ICC RGB working space profiles, and 
so itself needs a fallback other than converting to unbounded sRGB.

* Also, even for well-behaved ICC RGB working space profiles, currently 
GIMP uses hard-coded sRGB primaries for critically important editing 
operations such as converting to LAB, LCH, and Luminace black and white, 
and for making grayscale images, including layer masks. So these 
operations produce incorrect results unless the color space primaries 
are the sRGB primaries (as was assumed the case for the hypothetical 
Krita user).

A better fallback option would be if GIMP fully supported at least two 
color spaces: sRGB and the much larger gamut Rec.2020, and gave the user 
the option to convert their image to one of the fully supported 
well-behaved RGB working space profiles.

An even better option would be if babl/GEGL/GIMP had code that allowed 
converting to LAB/LCH and black and white, grayscale, etc to be done 
properly for any well-behaved ICC RGB working space, plus at least two 
built-in RGB working spaces for use by users who open their images in 
color spaces that aren't well-behaved.

It would also be nice if users had the option to completely disable the 
babl flips, which would allow users who do open images in odd RGB color 
spaces to edit their images without the image RGB values being modified 
by the babl flips. The user should be warned that a lot of editing 
operations won't produce correct results. My assumption is that at least 
some of these users actually do know what they are doing and will limit 
their editing appropriately.

Elle
--
http://ninedegreesbelow.com
Color management and free/libre photography