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

[Elle Stone <l elle stone gmail com>]

A technically correct luminance-based conversion to black and white is
done using this formula:

L = R*Yr + G*Yg + B*Yb

where R, G, and B are the image RGB values for any given pixel and Yr,
Yg, and Yb are the Y values from the image's actual ICC profile. If
the profile white point isn't D50, the Y values are always adapted Y
values. The image must be in a linear gamma version of the color
space.

So far I'm repeating what I've already said. Below are concrete
examples showing that using the **un**adapted sRGB Y values results in
the wrong Luminance values:

Consider an image with a color block of the sRGB "reddest possible
red" 16-bit integer color: (65535, 0, 0).

Convert the sRGB image to a different ICC profile using relative
colorimetric intent and the RGB values will change but the **meaning**
of the RGB values will be the same. In other words, the new RGB values
will point to the same XYZ coordinates as the previous sRGB RGB values
pointed to. Here are some examples:

According to the argyllcms xicclu utility, sRGB values (65535, 0, 0)
are the same as XYZ (0.435837, 0.222366, 0.013916).

Convert the sRGB image to WideGamut:
Widegamut RGB values (38832, 6228, 766) are the same as XYZ (0.435838
0.222362 0.013910)

Convert the sRGB image to ProPhoto:
ProPhoto RGB values (34671, 6442, 1105) are the same as XYZ (0.435843
0.222371 0.013910)

Convert the sRGB image to the Identity profile:
Identity RGB values (29623 14573 1106) are the same as XYZ (0.435837
0.222370 0.013921)

Notice that for each profile's equivalent-to-sRGB-reddedst-red,  the
XYZ "Y" value is almost identical to the sRGB ADAPTED Y value. The
color's coordinates in XYZ space don't change upon converting the
image from one color space to another using relative colorimetric
intent (unless there is gamut clipping, but then only the clipped
values are affected; I didn't mention black point compensation because
for working spaces with 0 black points, using or not using blackpoint
compensation makes no difference, and if it does, there' a problem in
the code).

The "Y" in a color's equivalent XYZ values  **is** a color's
Luminance. If your method of calculating Luminance gives something
other than the color's "Y" value in XYZ space, your method of
calculating Luminance is wrong.

Back to the formula for calculating Luminance:

sRGB-unadapted: 65535 * 0.21265600 + 0 * 0.71515800 + 0 * 0.07218600 = 13936.4

sRGB-adapted: 65535 * 0.22236633 + 0 * 0.71704102 + 0 * 0.06059265 = 14572.8

WideGamut: 38832 * 0.25871277 + 6228 * 0.72470093 + 766 * 0.01658630 = 14572.5

ProPhoto: 34671 * 0.28804016 + 6442 * 0.71195984 + 1105 * 0.00000000 = 14573.1

Identity: 29623 * 0.00000000 + 14573 * 1.00000000 + 1106 * 0.00000000 = 14573.0

In the above equations, the RGB values for the color of red specified
by the reddest possible sRGB red were determined by eye droppering a
red color block after doing the appropriate ICC profile conversions.
As you can see, the "Luminance" value calculated by the UNadapted sRGB
"Y" values is out of line with the other four calculated values.
Notice that 14573/65535 is 0.22237, the ADAPTED red Y value for sRGB.
If you did the same calculations for bluest sRGB blue and greenest
sRGB green, you'd get the ADAPTED sRGB blue and green Y values.

The actual eye droppered grayscale values for my four color test image
(reddest sRGB red, bluest sRGB blue, and greenest sRGB green against
an 18% gray background), after converting to black and white using
Luminance, are as follows (ICC profile conversions done at 32-bit
floating point, which is how I did the conversions, are more accurate
than working with 16-bit values as given above):

Profile         WtPt                      Red block   Green block    Blue
block   18% Gray
sRGB D65-unadapted   13936             46868             4731             12094 
sRGB D65-adapted       14573             46991             3971
      12094
WideGamut D50            14573              46991            3971
         12094
ProPhoto D50                14573              46991            3971
            12094
Identity D50                     14573              46991
3971               12094

The 18% gray value is the same for all five conversions because the
ONLY thing that determines the value of a neutral patch in an RGB
image is the profile's TRC. And a technically correct Luminance
conversion must always be done in a linear gamma color space.

For neutral R=G=B starting "color image" values like 18% gray, correct
OR incorrect Y values gives the same black and white R=G=B value after
the Luminance conversion (it's always the same RGB values as before
the conversion). But the more saturated the color is, the more wrong
the results are using the UNadapted Y values.

A technically correct Luminance conversion to black and white should
give the same resulting black and white image ***regardless*** of the
RGB working space the image happens to be in (this is not true of most
methods of converting an image to black and white).

Your incorrect use of the unadapted "Y" values makes the Luminance
conversion dependent on the image profile's white point. But Luminance
is determined by the value of Y in the color's XYZ coordinates. And
those coordinates are determined using the adapted Y values from the
actual image ICC profile. Those values don't change just because you
converted the image from one color space to another, as long as you
use relative colorimetric intent to do the conversion.

The **un**adapted sRGB Luminance values for red, blue and green are
different from the adapted values because the unadapted values use the
wrong "Y" values. The Luminance values calculated using the unadapted
"Y" values don't correspond to the equivalent "Y" value in XYZ space
for the color before the conversion to black and white.

You can download the test image and the four ICC profiles from this web page:
http://ninedegreesbelow.com/photography/luminance-black-white.html

Elle