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

[Øyvind Kolås <pippin gimp org>]

On Sat, Oct 11, 2014 at 1:18 AM, Elle Stone
<ellestone ninedegreesbelow com> wrote:
> 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.

We will try to do what makes sense and helps us achieve what we need
to achieve efficiently; while keeping what works well, working well.

> "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.

For the same reason XYZ is involved (or not, depending on how the CMM
does it) in an ICC workflow.

> > 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 not about how images with no embedded profile are handled.
sRGB derived 8bit (and to a lesser degree 16bit) formats are used for
many other things than images with no embedded profile. These pixel
formats are crucical for integrating with existing file formats and
libraries; and we want these conversions to be as fast as possible -
even if it might have an impact on the conversion speed for CIE Lab,
though that does not have to be the case either. Choosing any PCS
*but* linear sRGB would tend to make these important conversions
slower.

> 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.

We will do what makes most sense and is neccesary when we get there, I
suspect each RGB model with have an associated Y and YA model. Due to
how the existing BablModels interact with components and vocabulary
used to address them in babl; potential support for different TRCs is
even vaguer; we'll know when we have more code.

Maybe we have more code by the time of LGM, if not that would be an
excellent place to elaborate; until then I prefer IRC.

/pippin