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

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

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

> From the mental model of how babl and BablFormats are used; all of
this is however implementation details. The important thing is that a
pointer to a single unique BablFormat is all we need to be sure about
the colorimetric values of the pixel. Which is the role of an ICC
profile in color management between applications and devices. We can
combine this with other BablFormats that we want to read or write the
data in. As well as create buffers that store their content in any
BablFormat.

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

/Øyvind K.