image/color: tweak the YCbCr to RGBA conversion formula again.
The 0x10101 magic constant is a little more principled than 0x10100, as the rounding adjustment now spans the complete range [0, 0xffff] instead of [0, 0xff00]. Consider this round-tripping code: y, cb, cr := color.RGBToYCbCr(r0, g0, b0) r1, g1, b1 := color.YCbCrToRGB(y, cb, cr) Due to rounding errors both ways, we often but not always get a perfect round trip (where r0 == r1 && g0 == g1 && b0 == b1). This is true both before and after this commit. In some cases we got luckier, in others we got unluckier. For example, before this commit, (180, 135, 164) doesn't round trip perfectly (it's off by 1) but (180, 135, 165) does. After this commit, both cases are reversed: the former does and the latter doesn't (again off by 1). Over all possible (r, g, b) triples, there doesn't seem to be a big change for better or worse. There is some history in these CLs: image/color: tweak the YCbCr to RGBA conversion formula. https://go-review.googlesource.com/#/c/12220/2/src/image/color/ycbcr.go image/color: have YCbCr.RGBA work in 16-bit color, per the Color interface. https://go-review.googlesource.com/#/c/8073/2/src/image/color/ycbcr.go Change-Id: Ib25ba7039f49feab2a9d1a4141b86db17db7b3e1 Reviewed-on: https://go-review.googlesource.com/36732 Run-TryBot: Nigel Tao <nigeltao@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rob Pike <r@golang.org>
Showing
Please register or sign in to comment