delta/go-git.git/src/image/decode_example_test.go, branch dev.inline github.com: golang/go image/color: tweak the YCbCr to RGBA conversion formula. 2015-07-15T05:29:00+00:00 Nigel Tao nigeltao@golang.org 2015-07-15T04:55:02+00:00 c2023a07915cccff1ffba9b96e160f444f77aeae 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> 
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>
build: move package sources from src/pkg to src 2014-09-08T04:08:51+00:00 Russ Cox rsc@golang.org 2014-09-08T04:08:51+00:00 c007ce824d9a4fccb148f9204e04c23ed2984b71 Preparation was in CL 134570043. This CL contains only the effect of 'hg mv src/pkg/* src'. For more about the move, see golang.org/s/go14nopkg. 
Preparation was in CL 134570043.
This CL contains only the effect of 'hg mv src/pkg/* src'.
For more about the move, see golang.org/s/go14nopkg.