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

[Elle Stone <ellestone ninedegreesbelow com>]

 On 10/09/2014 07:52 PM, Michael Henning wrote:
> On Thu, Oct 9, 2014 at 7:22 PM, Elle Stone
> <ellestone ninedegreesbelow com> wrote:

> > > Ie, babl will support your suggestion (user-chosen primaries with
> > > either linear or sRGB TRC) in addition to sRGB, instead of replacing
> > > sRGB.

> > Does "in addition to sRGB" mean duplicate code files side by side, one set
> > of files hard-coded for just sRGB images and one using Y and XYZ values
> > retrieved from the user's chosen primaries?

> We don't need to recreate every single transformation. . .the
> core of babl always converts to linear sRGB as an intermediate. This
> is what we mean when we say "sRGB as PCS": all of the color formats
> are defined in terms of linear sRGB, so if a given transformation
> hasn't been coded specifically, we can use linear sRGB as an
> intermediate.

I'm trying to visualize how "sRGB as PCS" might be used in conversions 
to reference spaces such as XYZ and LAB.

Assume an image is being edited in an RGB working space that was made 
with the user-chosen colorants. Also assume the user chooses an 
operation that requires a conversion to LAB.

You can't get to LAB directly from RGB. First you have to convert from 
User_RGB to XYZ, which is simple:

1. Linearize the RGB values and scale them so display-referred RGB white 
is (1.0, 1.0, 1.0).
2. Arrange the working space colorants as the matrix "M" (no 
calculations required, just copy).
3. Multiply the RGB values by "M". Now you are in XYZ and you can 
convert to LAB.

So where in the conversion to XYZ and then to LAB (or any other 
reference color space) will "sRGB as PCS" fit in?

Of course you could convert from User_RGB to XYZ, from XZY to "sRGB as 
PCS", from "sRGB as PCS" back to XYZ, and then, finally, to LAB. But I 
don't see the point of doing such an odd sequence of conversions.

Kind regards,
Elle Stone