On Fri, Oct 10, 2014 at 9:38 PM, Elle Stone <ellestone@xxxxxxxxxxxxxxxxxxxx> 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. _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
