]> Cypherpunks repositories - gostls13.git/commit
image/color: tweak the YCbCr to RGBA conversion formula.
authorNigel Tao <nigeltao@golang.org>
Wed, 15 Jul 2015 04:55:02 +0000 (14:55 +1000)
committerNigel Tao <nigeltao@golang.org>
Wed, 15 Jul 2015 05:29:00 +0000 (05:29 +0000)
commitc2023a07915cccff1ffba9b96e160f444f77aeae
treeeef9b6a62e8fee1a22d0fe9d95466858acb4010e
parent5a4cc600b79075d8ad6304809c70a7d94da628cd
image/color: tweak the YCbCr to RGBA conversion formula.

Before, calling the RGBA method of YCbCr color would return red values
in the range [0x0080, 0xff80]. After, the range is [0x0000, 0xffff] and
is consistent with what Gray colors' RGBA method returns. In particular,
pure black, pure white and every Gray color in between are now exactly
representable as a YCbCr color.

This fixes a regression from Go 1.4 (where YCbCr{0x00, 0x80, 0x80} was
no longer equivalent to pure black), introduced by golang.org/cl/8073 in
the Go 1.5 development cycle. In Go 1.4, the +0x80 rounding was not
noticable when Cb == 0x80 && Cr == 0x80, because the YCbCr to RGBA
conversion truncated to 8 bits before multiplying by 0x101, so the
output range was [0x0000, 0xffff].

The TestYCbCrRoundtrip fuzzy-match tolerance grows from 1 to 2 because
the YCbCr to RGB conversion now maps to an ever-so-slightly larger
range, along with the usual imprecision of accumulating rounding errors.

Also s/int/int32/ in ycbcr.go. The conversion shouldn't overflow either
way, as int is always at least 32 bits, but it does make it clearer that
the computation doesn't depend on sizeof(int).

Fixes #11691

Change-Id: I538ca0adf7e040fa96c5bc8b3aef4454535126b9
Reviewed-on: https://go-review.googlesource.com/12220
Reviewed-by: Rob Pike <r@golang.org>
src/image/color/ycbcr.go
src/image/color/ycbcr_test.go
src/image/decode_example_test.go
src/image/draw/draw_test.go
src/image/internal/imageutil/gen.go
src/image/internal/imageutil/impl.go