Re: [Gimp-developer] Possible approach for some non-sRGB GEGL/GIMP color workflows

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:

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:

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:

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:

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]