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
_______________________________________________
gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list
