Re: [Gimp-developer] Missing from the roadmap

[Elle Stone <ellestone ninedegreesbelow com>]

On 01/12/2016 01:26 AM, Sven Claussner wrote:
> Hi,
>
> just for a better understanding:
> - Is it for something that goes beyond assigning and converting to
> other color spaces?

Yes.

> I think of native support of larger gamut color
> spaces than sRGB in Babl, GEGL and GIMP, am I right?

Yes. Different RGB working spaces have different RGB primaries 
(different XYZ locations for the color space's "reddest red, greenest 
green, and bluest blue" - 
http://ninedegreesbelow.com/photography/xyz-rgb.html#RGB).

Many of GIMP's editing operations make use of the color space's RGB 
primaries (for example, converting to black and white using Luma or 
Luminance, decomposing to LAB/LCH/YCbCr, the LCH blend modes, some of 
the noise reduction algorithms). These operations give wrong results for 
images in color spaces other than sRGB.

Many other editing operations *don't* make use of the color space 
primaries (for example, Levels, Curves, USM, Gaussian blur, scaling and 
other transforms). However, for radiometrically correct results, many of 
these "independent of the primaries" editing operations require being 
done on linearized RGB. So as explained below, in GIMP these operations 
also produce incorrect results for images other than sRGB images:

> - What exactly means 'supporting gamma-encodings other than the sRGB
> TRC'

Different RGB working spaces have different Tone Reproduction Curves 
(TRCs, http://ninedegreesbelow.com/photography/xyz-rgb.html#TRCs), and 
many RGB working spaces have TRCS that are more or less perceptually 
uniform (for example, gamma=2.2, gamma=1.8, and the sRGB TRC).

To produce radiometrically correct editing results, many GEGL and GIMP 
editing operations will request that the operation be done on linearized 
RGB.

Code in babl does the actual linearization and this babl code is 
hard-coded to linearize the sRGB TRC. So the only time the resulting 
"linearized" RGB values are actually linear is if the user really is 
editing an image that's encoded using the sRGB TRC.

sRGB is the only standardly-used RGB working space that uses the sRGB 
TRC. So results for images in other color spaces will be wrong.

There is code in GIMP that partially mitigates this problem by trying to 
make an RGB working space that has the user's RGB primaries and the sRGB 
or linear gamma TRC as required. But this code only works with images 
that were originally in RGB working spaces that already use the linear 
gamma TRC.

> - Is it something that happens only in GEGL and Babl or would also
> GIMP's code need to be touched?

As explained in the babl roadmap 
(https://git.gnome.org/browse/babl/tree/docs/roadmap.txt), currently 
babl is hard-coded only to support the sRGB primaries and the sRGB TRC.

To support other RGB working spaces, new babl formatters will need to be 
written.

Also new GEGL and GIMP code will need to be written that will call on 
the new babl formatters.

Elle