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
