image/color: Go 1.5 unexpected change in color.YCbCr.RGBA()

[pierrre]

My code: https://play.golang.org/p/AslT5NMUiU

Go 1.4: 0 0 0 65535
Go 1.5: 128 128 128 65535

[pierrre]

color.YCbCr.RGBA() uses:

• in Go 1.4 : color.YCbCrToRGB() with 8 bits color
• in Go 1.5: custom code with 16 bits color

[ianlancetaylor]

Leaving to Nigel to decide whether this needs to be documented or fixed.

[nigeltao]

Yes, this was a deliberate change: https://go-review.googlesource.com/8073

As for whether this needs calling out in the Go 1.5 release notes, I'll leave that decision up to @robpike.

[robpike]

Someone was bitten so an item in the release notes would be good. Words please @nigeltao?

[nigeltao]

The conversion of a color.YCbCr to RGBA now has finer detail. The RGBA method has always returned 16-bit color, but prior to Go 1.5, the low 8 bits equalled the high 8 bits. The following code:

var c color.YCbCr = etc
r, g, b, a := c.RGBA()
fmt.Println("Red (in the range [0-255]):", uint8(r))

has always been incorrect, but coincidentally printed the right number prior to Go 1.5. The correct code replaces "uint8(r)" with "uint8(r >> 8)". Even so, the number printed can differ slightly between Go 1.5 and previous versions.

[nigeltao]

Also, if you are converting an image.YCbCr full of many YCbCr colors, then consider using the image/draw package (http://blog.golang.org/go-imagedraw-package) instead of explicitly calling the RGBA method on each pixel. Once again, the resultant RGBA image can differ slightly between Go 1.5 and previous versions.

[pierrre]

color.YCbCr{Y: 0, Cb: 128, Cr: 128} is black, right?

This code:

func main() {
    c := color.YCbCr{Y: 0, Cb: 128, Cr: 128}
    r, g, b, a := c.RGBA()
    fmt.Println(r, g, b, a)
}

Prints 0 0 0 65535 with Go 1.4 and 128 128 128 65535 with Go 1.5.
color.RGBA64{128, 128, 128, 65535} is not black!
It's between color.YCbCr{Y: 0, Cb: 128, Cr: 128} and color.YCbCr{Y: 1, Cb: 128, Cr: 128}
(it's black if you convert it to RGBA with uint8(i >> 8))

[pierrre]

I understand the "finer detail" improvement with 16-bit color.

But I don't understand:

but prior to Go 1.5, the low 8 bits equalled the high 8 bits. The following code:

var c color.YCbCr = etc
r, g, b, a := c.RGBA()
fmt.Println("Red (in the range [0-255]):", uint8(r))

has always been incorrect, but coincidentally printed the right number prior to Go 1.5. The correct code replaces "uint8(r)" with "uint8(r >> 8)".

It was done correctly in Go 1.4.
See:
https://github.com/golang/go/blob/release-branch.go1.4/src/image/color/ycbcr.go#L97
https://github.com/golang/go/blob/release-branch.go1.4/src/image/color/ycbcr.go#L86
https://github.com/golang/go/blob/release-branch.go1.4/src/image/color/color.go#L172

[pierrre]

I just saw the release note:

Previously, the low 8 bits were just an echo of the high 8 bits;
now they contain more accurate information.

Does 128 128 128 65535 contains more accurate information?
I honestly don't understand.

[nigeltao]

Yes, it is more accurate.

Those numbers (0 vs 128) are integers. Here's a floating point analogy: you can think of red, green, etc. values being between 0 (no red) and 1 (fully saturated red). In the equivalent of Go 1.4, converting a particular YCbCr color to RGBA would yield something like '0.1 red'. In the equivalent of Go 1.5, it would yield something like '0.102 red'. The actual number is different; it is more accurate.

[nigeltao]

Separately, you're right that color.YCbCr{Y: 0, Cb: 128, Cr: 128} should be black. Go 1.5 returns 128 instead of 0 because it adds one half (of 256) to round to nearest instead of round down. Perhaps it shouldn't. I'll think about this.