Re: [Gimp-developer] Adapted and unadapted sRGB luminance values

[Elle Stone <l elle stone gmail com>]

On 9/21/13, Michael Henning <drawoc darkrefraction com> wrote:
> Both babl's RGB format and Y format are currently defined with a white
> point of D65. Because of this, I believe the code's current luminance
> values are correct.

> In other words, I think that the whitepoints are all currently
> correct, because the constants in code are for converting between two
> color spaces with D65, and the icc profile is relative to D50.
When converting between linear gamma sRGB and regular sRGB, the only
thing that ought to happen is that the image red, blue, and green
values are modified by the babl/babl/base/util.h functions
"gamma_2_2_to_linear" and "gamma_2_2_to_linear" (which aren't "gamma"
transforms, but rather sRGB companding functions). So is there some
other place in the babl/gegl/gimp code where there is an actual
hard-coded matrix transform between two D65 color spaces? If so, which
two D65 color spaces?

On 9/21/13, Michael Henning <drawoc darkrefraction com> wrote:
> Those conversion factors are attempting to get a D65 Y from D65 RGB.
>
> So, we currently do a conversion like this, using unadapted values:
> D65 Y = 0.212656 * D65 Red + 0.715158 * D65 Green + 0.072186 * D65 Blue
>
> And you want us to do this, using the adapted values:
> Y = 0.222491 * D65 Red + 0.716888 * D65 Green + 0.060621 * D65 Blue

Well, what I really want babl/gegl/gimp to do is stop using sRGB as
the "one space to rule them all" and instead, if there has to be a
single internal color space, make it the D50 Identity color space, in
which case equations for calculating the luminance of an image would
simplify to Y=Green and you also wouldn't have to deal with RGB values
less than 0 and greater than 1 resulting like they do when you convert
more saturated images from larger color spaces to sRGB. It would make
coding up proper soft proofing a lot easier, too.

However, that wasn't what you were asking about. So, to answer the question:

D50 has two uses in an ICC profile: the profile illuminant and also
the profile white point for profiles with D50 white points.

D65 has only one use, that being as a profile white point, as the ICC
hasn't approved other illuminants besides D50. So a D65 whitepoint ICC
profile like sRGB still has a D50 illuminant. That's why you need the
Bradford-adapted XYZ primaries, hence the Bradford-adapted "Y".

So there really is no unadapted "D65" red, green, and blue, not in the
actual sRGB images that Gimp creates and not in any sRGB images that
Gimp opens that were created by digital cameras or by properly color
managed image editors.

Assuming I understand Poynton correctly, the babl/gegl/gimp code uses
Y values that are appropriate for sending RGB values to a CRT that's
been ***calibrated to match sRGB***, in a *non*-color-managed context.
The Poynton values don't have any place in a color-managed application
when sending the appropriate RGB values to the monitor (lcms takes
care of that), or when doing ICC profile transforms (lcms does that),
or when calculating image Luminance values from image RGB values. For
calculating Luminance you need the adapted Y values.

As an aside, you can't assume that any of today's LCD monitors are
calibrated to match sRGB or even to have a D65 white point - the
native white point of LCD monitors seems to be around 5800K and not
everyone is willing to trade the largest possible color gamut and the
smoothest possible gray scale for the sake of calibrating an LCD
monitor to have a more or less imperfectly achieved D65 white point,
just to match the white point of an sRGB-calibrated CRT manufactured
in the 1990s. Different times, different technology.

> Isn't the second (adapted) transform going to give us a D50 Y instead
> of a D65 Y?

Yes, it will, and that's precisely what you want if you want to
correctly calculate an sRGB image's Luminance values from its RGB
values.


-- 
Elle Stone
http://ninedegreesbelow.com

Just because it's a standard, doesn't mean it's right.