20

My original question

I read that to convert a RGB pixel into greyscale RGB, one should use

r_new = g_new = b_new = r_old * 0.3 + g_old * 0.59 + b_old * 0.11

I also read, and understand, that g has a higher weighting because the human eye is more sensitive to green. Implementing that, I saw the results were the same as I would get from setting an image to 'greyscale' in an image editor like the Gimp.

Before I read this, I imagined that to convert a pixel to greyscale, one would convert it to HSL or HSV, then set the saturation to zero (hence, removing all colour). However, when I did this, I got a quite different image output, even though it also lacked colour.

How does s = 0 exactly differ from the 'correct' way I read, and why is it 'incorrect'?

Ongoing findings based on answers and other research

It appears that which luminance coefficients to use is the subject of some debate. Various combinations and to-greyscale algorithms have different results. The following are some presets used in areas like TV standards:

  • the coefficients defined by ITU-R BT.601 (NTSC?) are 0.299r + 0.587g + 0.114b
  • the coefficients defined by ITU-R BT.709 (newer) are 0.2126r + 0.7152g + 0.0722b
  • the coefficients of equal thirds, (1/3)(rgb), is equivalent to s = 0

This scientific article details various greyscale techniques and their results for various images, plus subjective survey of 119 people.

However, when converting an image to greyscale, to achieve the 'best' artistic effect, one will almost certainly not be using these predefined coefficients, but tweaking the contribution from each channel to produce the best output for the particular image.

Delan Azabani
  • 79,602
  • 28
  • 170
  • 210
  • This isn't really a programming question, but I'm not sure which site it belongs on... It's really an artistic or scientific question. – derobert Mar 15 '11 at 16:27
  • 3
    That may be true, but I'm asking this question in the context of writing a function that does greyscale conversion. – Delan Azabani Mar 16 '11 at 01:02
  • The BT.709 coefficients are the ones you want to use, BUT, you need to linearize the sRGB values first. This is a common enough issue that I put the information on my profile page here. – Myndex Jun 18 '22 at 14:55

4 Answers4

10

Although these transformation coefficients exist, nothing binds you to using them. As long as the total intensity of each pixel is unchanged, the contributions from each channel can be anything, ranging from 0 to 100%.

Photographers converting images to grayscale use channel mixers to adjust levels of each channel (RGB or CMYK). In your image, there are many reds and greens, so it might be desirable (depending on your intent) to have those channels more highly represented in the gray level intensity than the blue.

This is what distinguishes "scientific" transformation of the image from an "artistic" combination of the bands.

An additional consideration is the dynamic range of values in each band, and attempting to preserve them in the grayscale image. Boosting shadows and/or highlights might require increasing the contribution of the blue band, for example.

Benjamin
  • 11,560
  • 13
  • 70
  • 119
5

An interesting article on the topic here.... "because human eyes don't detect brightness linearly with color".

http://www.scantips.com/lumin.html

JNadal
  • 408
  • 2
  • 8
  • OK, to specifically answer the question that was asked, it's wrong because: the luminance between greys in the s=0 version does not match the luminance between the colors in the original image. This manifests itself visibly through the stalks (stamen? if I remember 3rd grade) at the flower's center aren't as distinguishable in the s=0 version. – JNadal Mar 15 '11 at 13:04
  • Here's the original derivation of your given coefficients: http://www.cis.rit.edu/mcsl/research/broadbent/CIE1931_RGB.pdf – JNadal Mar 15 '11 at 13:34
  • Another great article exploiting the s=0 method, trying to make an image that completely washes out when converting to grayscale: http://www.realtimerendering.com/blog/constant-luma-palette/ – JNadal Mar 15 '11 at 13:40
4

Looks like these coefficients come from old CRT technology and are not well adapted to today's monitors, from the Color FAQ:

The coefficients 0.299, 0.587 and 0.114 properly computed luminance for monitors having phosphors that were contemporary at the introduction of NTSC television in 1953. They are still appropriate for computing video luma to be discussed below in section 11. However, these coefficients do not accurately compute luminance for contemporary monitors.

Couldn't find the right conversion coefficient, however.

See also RGB to monochrome conversion

Community
  • 1
  • 1
CharlesB
  • 86,532
  • 28
  • 194
  • 218
3

Using s = 0 in HSL/HSV and converting to RGB results in R = G = B, so is the same as doing r_old * 1/3 + g_old * 1/3 + b_old * 1/3.

To understand why, have a look at the Wikipedia page that describes conversion HSV->RGB. Saturation s will be 0, so C and X will be, too. You'll end up with R_1,G_1,B_1 being (0,0,0) and then add m to the final RGB values which results in (m,m,m) = (V,V,V). Same for HSL, result will be (m,m,m) = (L,L,L).

EDIT: OK, just figured out the above is not the complete answer, although it's a good starting point. RGB values will be all the same, either L or V, but it still depends on how L and V were originally calculated, again, see Wikipedia. Seems the program/formulas you've used for converting used the 1/3 * R + 1/3 * G + 1/3 * B solution or one of the other two (hexcone/bi-hexcone).

So after all, using HSL/HSV just means you'll have to decide which formula to use earlier and conversion to RGB grayscale values later is just isolating the last component.

schnaader
  • 49,103
  • 10
  • 104
  • 136