Better sRGB to greyscale conversion

October 13th, 2025

A common approach to convert a gamma-corrected sRGB color (R', G', B') to greyscale is to take a weighted sum of its components:

Y' = 0.2126 \cdot R' + 0.7152 \cdot G' + 0.0722 \cdot B'.

The weights are given in the Rec. 709 HDTV standard and are used to compute what they call a “luminance signal”, a measure of perceived brightness. It’s also subtly wrong.

See those tiny prime marks after each symbol? It’s an obscure notation to mean the components are gamma-corrected. So actually, in this case the precise term for Y' is “luma”, not “luminance”. But if we look at the source of the weights in question, it turns out they are meant to be used to map linear RGB to CIEXYZ color space’s Y component¹, the actual relative luminance.

In other words, the standard recommends you compute a gamma-corrected grey value with gamma-corrected RGB inputs using coefficients meant for linear space. Yikes! I’m not familiar with the history of that unfortunate decision, but at least I know how to do greyscale conversion right:

1. First linearize the sRGB gamma-corrected color,
2. compute Y (note the missing prime) with the above weights in linear space, and
3. then map Y back to gamma space to get the final grey value.

It’s three steps instead of one but at least in shader programming you get the linearization for free when sampling sRGB textures, so it’s easy to do the right thing.

Learning about this debacle naturally got me thinking that it would be interesting to try to fit better coefficients for the gamma-space formula. I didn’t expect there to be much difference so I never got around actually doing it.

A couple of weeks later I was idly leafing through a stack of computer graphics books in the local library, as one does, until I was greeted by this page:

It says:

In this case, the RGB components must first be linearized to obtain the correct luminance values with the above weights.

Hey, these dudes get it! The exact weights they show are from the older “BT.709-1” spec, though. Anyway, there’s an intriguing reference “p. 109 of Vol. 2”, offering “a different set of weights” optimized for nonlinear aka gamma-corrected values. At home, I found the relevant chapter on Google Books and it shows us the new coefficients:

So the alternative greyscale, or “luma”, formula for a gamma-corrected (R', G', B') color is

Y' \approx 0.309 \cdot R' + 0.609 \cdot G' + 0.082 \cdot B'.

I didn’t research how exactly it was derived. The citation [58] in the snippet above is to the first edition of Charles Poynton’s 2003 textbook Digital Video and HDTV Algorithms and Interfaces. Poynton has also written extensively on the subject of video engineering on his website.

Does it actually work any better?

Let’s use as an example this incredible photo that I found on Wikipedia’s article on “Lightness”:

Below is a comparison of the Y' formula with the proper “gamma→linear→greyscale→gamma” pipeline (“Linear sRGB”), the same but without linearization (“Gamma sRGB”), the lightness component of a CIELAB color (“CIELAB L^*”), and the supposedly better alternative formula calculated in gamma space. (Code for this experiment.)

Linear sRGB	Gamma sRGB
CIELAB L^*	Alternative Gamma sRGB (new)

It’s pretty difficult to spot any differences, at least for me. But the face region seems dimmer in the “Gamma sRGB” case; let’s zoom in closer.

Yep, looks like there’s a difference. Here’s an error map with “Linear sRGB” as the ground truth:

Using the error map as a guide, I can now spot some things that are slightly closer to the linear formula in the alternative result, such as the fire breather’s right shoulder at the center. It’s dimmer in the “Gamma sRGB” image. Overall, the alternative formula does seem to work a bit better on this image.

---

Interestingly, back in Wikipedia, a user “jacobolus” makes an observation that Adobe Photoshop uses the older “Rec. 601” coefficients for the above formula (and probably also without linearizing first):

[–] Y′ has been calculated using the weightings from Rec. 601. Since sRGB does not use NTSC primaries, this is actually an incorrect calculation of Luma, which should use Rec. 709 weightings instead, but it is the calculation Adobe Photoshop uses for its “Luminosity”, “Color”, “Hue”, and “Saturation” blend modes, regardless of an RGB image’s color space. –jacobolus, 4 February 2010

Which one is worse: using weights of an older standard or of the newer one that are subtly off anyway? The answer seems to be that slightly incorrect greyscale calculations may not be such a big deal after all.

I’m writing a book on color quantization. Sign up here if you’re interested.

---

1. If you want to learn more about standard color spaces, I can highly recommend Paul Malin’s 2018 talk HDR display in Call of Duty.↩︎