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

[Elle Stone <ellestone ninedegreesbelow com>]

On 10/10/2014 04:08 PM, Øyvind Kolås wrote:
> On Fri, Oct 10, 2014 at 9:38 PM, Elle Stone
> <ellestone ninedegreesbelow com> wrote:
> > You cannot get from "sRGB as PCS" to LAB without first converting from "sRGB
> > as PCS" to XYZ. LAB is a mathematical transform of XYZ, not sRGB.
> >
> > This is the normal path from User_RGB to LAB: User_RGB -> XYZ -> LAB. Two
> > conversions.
> >
> > You want to take this path, yes? User_RGB -> XYZ -> "sRGB as PCS" -> XYZ ->
> > LAB. Four conversions, going through XYZ twice.
> >
> > Why is the second path preferable?
>
> Forget about CIE Lab

I really don't want to forget about LAB. The plan is that "sRGB as PCS" 
will be used for "something". I'm trying to figure out what exactly 
"something" covers. So I have two specific questions. The first question 
is about converting to LAB. The second question (which I haven't asked 
yet) has to do with Y.

"sRGB as PCS" is linear gamma unbounded sRGB. I think it's reasonable to 
ask why a conversion to unbounded sRGB should be involved in a 
conversion from User_RGB to LAB.

> , and consider RGB spaces - which is what we are
> most concerned about. When transforming between linear RGB spaces
> there will be no conversion to XYZ.

By "transforming between linear RGB spaces", do you mean converting 
between User_RGB and unbounded sRGB, both encoded linearly?

If you plan to convert from User_RGB to unbounded sRGB, how do you do 
the conversion without a conversion to XYZ?

> In the end when things are rigged
> up propertly, this will be performed in a single step with a single
> transformation matrix; which is cached nearby in the code doing the
> copy.

Does this mean you will get the User_RGB colorants and cache a 
conversion from User_RGB to XYZ to unbounded sRGB into a concantenated 
matrix transform?

> Existing code written with assumptions of sRGB, whether in GIMP and
> GEGL that we control or in XPM, GTK, GDK, or elsewhere that has sRGB
> assumed will continue to work. We take the existing architecture which
> is following general guidelines of assuming sRGB where none is
> specified.

Assigning sRGB to images with no embedded profile is done because you 
can't display images in an ICC profile color-managed workflow until an 
ICC profile is assigned. How images with no embedded profile are handled 
is irrelevant to the question of why a conversion from User_RGB to LAB 
needs to involve unbounded sRGB.

> This is what I mean by sRGB/the PCS being Celcius in the
> temperature analogy. A lot of the buffers that GIMP ends up for
> drawing its user interface are all things that are expected to be
> passed as sRGB data.

Whatever happens to the user interface is irrelevant to the question of 
why a conversion from User_RGB to LAB needs to involve unbounded sRGB.

> (most bits of GTK outside actual image windows;
> which we should be communicating with the system compositor in opting
> out of global color corrections the it already should be doing of the
> pixels from sRGB->display profile.).

Opting out of global color corrections is not a reason to stick 
unbounded sRGB in the middle of a conversion to LAB.

I can move on to my question about Y and unbounded sRGB. But I still 
don't understand why unbounded sRGB should be involved in a conversion 
from User_RGB to LAB.

With respect,
Elle Stone