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.
This makes grayModel and gray16Model in color.go use the exact same
formula as RGBToYCbCr in ycbcr.go. They were the same formula in theory,
but in practice the color.go versions used a divide by 1000 and the
ycbcr.go versions used a (presumably faster) shift by 16.
This implies the nice property that 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.
The difference between the two formulae is non-zero, but small:
Reviewed-by: Rob Pike <email@example.com>