image/color: are the coefficients for grayModel correct? #16251
Comments
bradfitz
changed the title
|
The formula using to calculate relative luminance (or brightness): But it is correct in NTSC (1953) color space only. This formula is deprecated and legacy. Correct formula is: The proof of numbers A lot of work or refactoring is not required. We can simply replace this coefficients. |
|
We're currently in code freeze for the upcoming Go 1.7 release. I'll take a look at it for Go 1.8. |
|
Ping @nigeltao. |
quentinmit
added
the
NeedsFix
|
It's fine with me to change to sRGB normalization but I'm sure it will break something. |
|
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. |
|
CL https://golang.org/cl/31538 mentions this issue. |
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: https://play.golang.org/p/qG7oe-eqHI Updates #16251 Change-Id: I288ecb957fd6eceb9626410bd1a8084d2e4f8198 Reviewed-on: https://go-review.googlesource.com/31538 Reviewed-by: Rob Pike <r@golang.org>
|
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. |
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
The text was updated successfully, but these errors were encountered: