{"push_id":726219661,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"c2023a07915cccff1ffba9b96e160f444f77aeae","before":"5a4cc600b79075d8ad6304809c70a7d94da628cd","commits":[{"sha":"c2023a07915cccff1ffba9b96e160f444f77aeae","author":{"email":"58ae08b3356928ff9c67562b4719487d54fe8348@golang.org","name":"Nigel Tao"},"message":"image/color: tweak the YCbCr to RGBA conversion formula.\n\nBefore, calling the RGBA method of YCbCr color would return red values\nin the range [0x0080, 0xff80]. After, the range is [0x0000, 0xffff] and\nis consistent with what Gray colors' RGBA method returns. In particular,\npure black, pure white and every Gray color in between are now exactly\nrepresentable as a YCbCr color.\n\nThis fixes a regression from Go 1.4 (where YCbCr{0x00, 0x80, 0x80} was\nno longer equivalent to pure black), introduced by golang.org/cl/8073 in\nthe Go 1.5 development cycle. In Go 1.4, the +0x80 rounding was not\nnoticable when Cb == 0x80 && Cr == 0x80, because the YCbCr to RGBA\nconversion truncated to 8 bits before multiplying by 0x101, so the\noutput range was [0x0000, 0xffff].\n\nThe TestYCbCrRoundtrip fuzzy-match tolerance grows from 1 to 2 because\nthe YCbCr to RGB conversion now maps to an ever-so-slightly larger\nrange, along with the usual imprecision of accumulating rounding errors.\n\nAlso s/int/int32/ in ycbcr.go. The conversion shouldn't overflow either\nway, as int is always at least 32 bits, but it does make it clearer that\nthe computation doesn't depend on sizeof(int).\n\nFixes #11691\n\nChange-Id: I538ca0adf7e040fa96c5bc8b3aef4454535126b9\nReviewed-on: https://go-review.googlesource.com/12220\nReviewed-by: Rob Pike <r@golang.org>","distinct":true,"url":"https://api.github.com/repos/golang/go/commits/c2023a07915cccff1ffba9b96e160f444f77aeae"}]}