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