Re: [Gimp-developer] Don't make an architectural mistake based on a groundless premise

[Elle Stone <ellestone ninedegreesbelow com>]

On 10/08/2014 04:20 PM, Øyvind Kolås wrote:
> On Wed, Oct 8, 2014 at 9:49 PM, Elle Stone
> <ellestone ninedegreesbelow com> wrote:
> > > On Wed, Oct 8, 2014 at 4:25 PM, scl <scl gplus gmail com> wrote:
> > > The we have to juggle a large set of different types of pixel formats
> > > already? The initial thinking was that linear working in RGB and HDR
> > > was sufficient, that is what the current babl is sufficient for, one
> > > uses ICC based conversions to get into the internal formats which are
> > > supposed to have efficient management, programming naming and
> > > conversions. And uses an external CMS for interacting with the
> > > outside. As Elle has repeatedly pointed out, that is not sufficient;
> > > and the scope of what is considered natively juggled pixel formats
> > > must be extended.
> >
> > The babl/GEGL/GIMP code base has a relatively short list of places where
> > hard-coded sRGB parameters are used. I've already identified most such code.
> > Most of it uses sRGB Y values.
>
> Each location that says babl_format("RGBA foo") or babl_format
> ("R'G'B'A foo") or babl_format ("RaGaB..) etc. is a location that
> requests a specific format. It is not the places in the code that
> implements the sRGB primaries which is in question.
>
> > To generalize such code to work with all RGB working spaces, replace
> > hard-coded sRGB Y values with Y values retrieved by LCMS from the user's
> > chosen RGB working space colorant XYZ values. The Y values can be retrieved
> > upon opening an image and again upon switching images for users who have
> > several images open at once.

To somewhat simply, ICC RGB working space profiles are characterized by:

1. The profile Red, Green, and Blue colorant XYZ values, aka "primaries".

2. The profile Tone Reproduction Curve, "TRC" for short.

Right now, when a user opens a regular ProPhotoRGB image, the primaries 
AND the TRC are not what the babl/GEGL/GIMP code expects (the regular 
ProPhotoRGB TRC is Gamma=1.8). The only operations that *don't* produce 
wrong results are operations that don't use sRGB primaries AND don't 
linearize the sRGB TRC.

You can make an ICC profile using any primaries and any TRC. For 
example, a profile can be made using the ProPhotoRGB primaries and the 
sRGB TRC. So here is one way to make the current hard-coded sRGB 
TRC-based transforms between linear and perceptually uniform RGB work:

Upon opening an image, use LCMS to make a profile using the user's 
chosen primaries and the sRGB TRC, and convert the image to this new 
profile. Once. Not repeatedly back and forth.

And of course replace all the code that uses hard-coded sRGB primaries.

I have two questions about the linear-to-perceptual "babl TRC flips" code:

1. Is it acceptable to mess with a user's RGB data by keeping the 
primaries intact and "only" modifying the TRC? A user who expects their 
data is encoded using the ProPhotoRGB gamma=1.8 TRC will not fail to 
notice that data encoded using the sRGB TRC gives different results.

The "babl TRC flips" code could be modified to give the user a choice of 
TRCs for encoding perceptually uniform RGB.

2. Does the repeated linear-to-perceptual-to-linear "babl TRC flips" 
required by the current architecture impose a loss of precision? How 
much loss, after how many flips?

> What you are describing is exactly what I outlined API for elsewhere.
> You would..
> babl_set_named_rgb_chromaticities (babl, "hack", colorants..
> and you would get what you want by having replacing all occurences of
> "RGBA float" and "R'G'B'A float" with "hack:RGBA float" and
> "hack:R'G'B'A float", and the same for u8 and u16.

I'm not proposing that you use "sRGB as PCS" and then hack the code to 
fix the resulting problems. I'm proposing that you eliminate "sRGB as 
PCS" altogether. It's a broken model for RGB editing.

The VFX people understood with *one* multiply example that there can be 
no universal RGB working space. The best working space depends on the 
artistic intent plus the device(s) that produced the colors, and 
eventually on the device(s) on which the colors will be displayed.

Adobe-centric advice implies that color gamut is the only consideration 
when choosing an RGB working space. Adobe has hard-coded ProPhotoRGB 
primaries into their raw processing software. It is distressing to see 
GIMP follow Adobe's lead by writing code on the assumption that the sRGB 
primaries are suitable for editing all images.

> But the "R'G'B'A
> u8" and u16 and similar better be left alone because they have been
> written with the assumption that their data is sRGB.

If there is code for 8-bit and 16-bit integer images that uses sRGB 
*primaries*, that code needs to be rewritten or removed. It makes no 
sense in the context of a high end, high bit depth image editor.

> Globally
> switching it upon switching images does not work for copy and paste
> between images and other forms of work where different spaces might be
> at play.

Copy-paste/drag-drop do require converting the pixels from the source 
layer stack's ICC profile to the destination layer stack's ICC profile. 
That's what properly color-managed image editors do. Krita does this. 
Surely GIMP can also do this.

> > The babl conversion to XYZ uses the sRGB D65 color space xy values and the
> > D65 white point to convert to XYZ. This results in wrong results even for
> > sRGB images in a D50-adapted ICC profile color-managed workflow. The right
> > thing to do is retrieve the user's chosen profile's colorant XYZ values and
> > ferry that to babl. This takes the place of the hard coded (and wrong) D65
> > sRGB xy values. The equations for converting from XYZ to LAB are well known.
>
> Babl has no XYZ format and thus in a sense no conversion to XYZ. The
> CIE Lab implementation which came from GIMP does however contains an
> internal conversion to XYZ; you are saying the CIE Lab code is broken.

My apologies, I meant to type "RGB to XYZ to LAB". You can't get 
directly from RGB to LAB. You have to go through XYZ. You get from RGB 
to XYZ by using the illuminant-adapted profile colorants.

Also, proper "color temperature change" code requires converting to XYZ 
to do Bradford/CATO2/etc chromatic adaptation. So a function that 
converts from RGB to XYZ really is necessary. The current temperature 
change code is hard-coded for sRGB images and although it does produce 
pleasing results for sRGB images, those results are not colorimetrically 
correct.

With respect,
Elle Stone