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
* 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
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
* 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
* 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
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
* 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
* 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
* 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
* 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
* There is no easy way to do a radiometrically correct invert operation
* 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
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
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 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
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.
Color management and free/libre photography
gimp-developer-list mailing list
List address: email@example.com
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list