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

 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

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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]