image/color: are the coefficients for grayModel correct?

[lgg]

https://github.com/golang/go/blob/master/src/image/color/color.go#L249

For now there are coefficients for NTSC, not sRGB.

See sRGB table: http://www.brucelindbloom.com/index.html?WorkingSpaceInfo.html
Or point 9 here: http://www.poynton.com/notes/colour_and_gamma/ColorFAQ.html

[lgg]

The formula using to calculate relative luminance (or brightness):
Y = 0.299 R + 0.587 G + 0.114

But it is correct in NTSC (1953) color space only. This formula is deprecated and legacy.
Actual color space sRGB significantly different: chromacity diagram.

Correct formula is:
Y = 0.2126 R + 0.7152 G + 0.0722 B

The proof of numbers
Source — Bruce Lindbloom site
See also — Charles Poynton Color FAQ

A lot of work or refactoring is not required. We can simply replace this coefficients.

[nigeltao]

We're currently in code freeze for the upcoming Go 1.7 release. I'll take a look at it for Go 1.8.

[bradfitz]

Ping @nigeltao.

[rsc]

ping @nigeltao, @robpike

[robpike]

It's fine with me to change to sRGB normalization but I'm sure it will break something.

[nigeltao]

Note that the NTSC formula is also used by https://github.com/golang/go/blob/master/src/image/color/ycbcr.go#L10 based on the JFIF specification.

Changing the grayModel function to use the sRGB coefficients instead of the NTSC coefficients would break the nice property that, in theory, converting an image.RGBA to an image.YCbCr and then taking only the Y channel is equivalent to converting an image.RGBA directly to an image.Gray. In practice, the two use slightly different formulae (the ycbcr.go one uses a shift instead of a divide), but we could harmonize them.

We could conceivably change the ycbcr.go formulae to do something compatible with the sRGB coefficients, but that has larger knock-on effects, and we are then also disregarding the JFIF spec.

I appreciate that there are arguments for sRGB over NTSC, but I think this is a situation where everything has trade-offs, and there being multiple competing standards, instead of there being a single 'correct' answer. I'm happy with the trade-off that the image/color package makes.

You are of course free to write your own function that takes an image.RGBA and produces an image.Gray based on the sRGB coefficients.

Sorry for the delay in replying.

[gopherbot]

CL https://golang.org/cl/31538 mentions this issue.

[nigeltao]

That commit harmonized the two NTSC implementations. As for replacing NTSC with sRGB coefficients, as I said, I'm not convinced that we should do that.