summaryrefslogtreecommitdiff
path: root/src/image
Commit message (Collapse)AuthorAgeFilesLines
* image/png: implement grayscale transparency.Nigel Tao2016-10-287-43/+350
| | | | | | Change-Id: Ib9309ee499fc51be2662d778430ee30089822e57 Reviewed-on: https://go-review.googlesource.com/32143 Reviewed-by: Rob Pike <r@golang.org>
* image/png: implement truecolor transparency.Nigel Tao2016-10-2729-57/+2185
| | | | | | Change-Id: I99b9a51db29d514ebaa9c1cfde65c0b5184c0f42 Reviewed-on: https://go-review.googlesource.com/32140 Reviewed-by: Rob Pike <r@golang.org>
* image/png: allow tRNS chunk without a PLTE chunk.Nigel Tao2016-10-271-1/+5
| | | | | | | | | | | | | | While https://www.w3.org/TR/PNG/#5ChunkOrdering says that tRNS's ordering constraint is "After PLTE; before IDAT", it is legal for a tRNS chunk to occur without a PLTE chunk at all, for greyscale and truecolor transparency as opposed to palette-based transparency. See https://www.w3.org/TR/PNG/#11transinfo Fixes #17511. Change-Id: I047b0b01d78a1cda65e00eeac229bb972cda431d Reviewed-on: https://go-review.googlesource.com/32139 Reviewed-by: Rob Pike <r@golang.org>
* image/color: improve speed of RGBA methodsMartin Möhrmann2016-10-252-37/+115
| | | | | | | | | | | | | | | | | | | | Apply the optimizations added to color conversion functions in https://go-review.googlesource.com/#/c/21910/ to the RGBA methods. YCbCrToRGBA/0-4 6.32ns ± 3% 6.58ns ± 2% +4.15% (p=0.000 n=20+19) YCbCrToRGBA/128-4 8.02ns ± 2% 5.89ns ± 2% -26.57% (p=0.000 n=20+19) YCbCrToRGBA/255-4 8.06ns ± 2% 6.59ns ± 3% -18.18% (p=0.000 n=20+20) NYCbCrAToRGBA/0-4 8.71ns ± 2% 8.78ns ± 2% +0.86% (p=0.036 n=19+20) NYCbCrAToRGBA/128-4 10.3ns ± 4% 7.9ns ± 2% -23.44% (p=0.000 n=20+20) NYCbCrAToRGBA/255-4 9.64ns ± 2% 8.79ns ± 3% -8.80% (p=0.000 n=20+20) Fixes: #15260 Change-Id: I225efdf74603e8d2b4f063054f7baee7a5029de6 Reviewed-on: https://go-review.googlesource.com/31773 Run-TryBot: Martin Möhrmann <martisch@uos.de> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Nigel Tao <nigeltao@golang.org>
* image/color: tweak the formula for converting to gray.Nigel Tao2016-10-202-3/+25
| | | | | | | | | | | | | | | | | | | | This makes grayModel and gray16Model in color.go use the exact same formula as RGBToYCbCr in ycbcr.go. They were the same formula in theory, but in practice the color.go versions used a divide by 1000 and the ycbcr.go versions used a (presumably faster) shift by 16. This implies the nice property that converting an image.RGBA to an image.YCbCr and then taking only the Y channel is equivalent to converting an image.RGBA directly to an image.Gray. The difference between the two formulae is non-zero, but small: https://play.golang.org/p/qG7oe-eqHI Updates #16251 Change-Id: I288ecb957fd6eceb9626410bd1a8084d2e4f8198 Reviewed-on: https://go-review.googlesource.com/31538 Reviewed-by: Rob Pike <r@golang.org>
* image/gif: check handling of truncated GIF filesJeff R. Allen2016-10-052-29/+71
| | | | | | | | | | | | | | | | | All the prefixes of the testGIF produce errors today, but they differ wildly in which errors: some are io.EOF, others are io.ErrUnexpectedEOF, and others are gif-specific. Make them all gif-specific to explain context, and make any complaining about EOF be sure to mention the EOF is unexpected. Fixes #11390. Change-Id: I742c39c88591649276268327ea314e68d1de1845 Reviewed-on: https://go-review.googlesource.com/17493 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* image/png: improve compression by skipping filter for paletted imagesOliver Tonnhofer2016-09-271-1/+4
| | | | | | | | | | | | | | Compression of paletted images is more efficient if they are not filtered. This patch skips filtering for cbP8 images. The improvements are demonstrated at https://github.com/olt/compressbench Fixes #16196 Change-Id: Ie973aad287cacf9057e394bb01cf0e4448a77618 Reviewed-on: https://go-review.googlesource.com/29872 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* image/png: add Encode and Decode examplesSuyash2016-09-211-0/+77
| | | | | | | | | | partially addresses #16360 Change-Id: I8274825b9ca6aec46294c8513b4795b0eb3062a2 Reviewed-on: https://go-review.googlesource.com/28992 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* image/draw: add FloydSteinberg Drawer exampleBrad Fitzpatrick2016-09-211-0/+48
| | | | | | | | | | Updates #16360 Change-Id: I80b981aa291a8e16d2986d4a2dfd84d3819bf488 Reviewed-on: https://go-review.googlesource.com/29443 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
* image/draw: optimize drawFillOver as drawFillSrc for opaque fills.Nigel Tao2016-09-092-7/+11
| | | | | | | | | | | | | | | | | | | Benchmarks are much better for opaque fills and slightly worse on non opaque fills. I think that on balance, this is still a win. When the source is uniform(color.RGBA{0x11, 0x22, 0x33, 0xff}): name old time/op new time/op delta FillOver-8 966µs ± 1% 32µs ± 1% -96.67% (p=0.000 n=10+10) FillSrc-8 32.4µs ± 1% 32.2µs ± 1% ~ (p=0.053 n=9+10) When the source is uniform(color.RGBA{0x11, 0x22, 0x33, 0x44}): name old time/op new time/op delta FillOver-8 962µs ± 0% 1018µs ± 0% +5.85% (p=0.000 n=9+10) FillSrc-8 32.2µs ± 1% 32.1µs ± 0% ~ (p=0.148 n=10+10) Change-Id: I52ec6d5fcd0fbc6710cef0e973a21ee7827c0dd9 Reviewed-on: https://go-review.googlesource.com/28790 Reviewed-by: David Crawshaw <crawshaw@golang.org>
* image/gif: accept an out-of-bounds transparent color index.Nigel Tao2016-04-292-32/+63
| | | | | | | | | | | This is an error according to the spec, but Firefox and Google Chrome seem OK with this. Fixes #15059. Change-Id: I841cf44e96655e91a2481555f38fbd7055a32202 Reviewed-on: https://go-review.googlesource.com/22546 Reviewed-by: Rob Pike <r@golang.org>
* image/gif: be stricter on parsing graphic control extensions.Nigel Tao2016-04-282-1/+7
| | | | | | | | | See Section 23. Graphic Control Extension of the spec: https://www.w3.org/Graphics/GIF/spec-gif89a.txt Change-Id: Ie78b4ff4aa97e1b332ade67ae4fa25f7c0770610 Reviewed-on: https://go-review.googlesource.com/22547 Reviewed-by: Rob Pike <r@golang.org>
* image/color: optimize RGBToYCbCrMartin Möhrmann2016-04-272-19/+53
| | | | | | | | | | | | | | | | | | | | Apply optimizations used to speed up YCbCrToRGB from https://go-review.googlesource.com/#/c/21910/ to RGBToYCbCr. name old time/op new time/op delta RGBToYCbCr/0-2 6.81ns ± 0% 5.96ns ± 0% -12.48% (p=0.000 n=38+50) RGBToYCbCr/Cb-2 7.68ns ± 0% 6.13ns ± 0% -20.21% (p=0.000 n=50+33) RGBToYCbCr/Cr-2 6.84ns ± 0% 6.04ns ± 0% -11.70% (p=0.000 n=39+42) Updates #15260 Change-Id: If3ea5393ae371a955ddf18ab226aae20b48f9692 Reviewed-on: https://go-review.googlesource.com/22411 Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com> Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ralph Corderoy <ralph@inputplus.co.uk>
* image/draw: remove some bounds checks from DrawYCbCrJosh Bleecher Snyder2016-04-172-20/+31
| | | | | | | | | | | | | | | | | | | It’d be nicer to write just _ = dpix[x+3] but the compiler isn’t able to reason about offsets from symbols (yet). image/draw benchmark: YCbCr-8 722µs ± 3% 682µs ± 3% -5.54% (p=0.000 n=50+50) Change-Id: Ia1e399496ed87c282bf0f9ca56c0b2d4948a0df9 Reviewed-on: https://go-review.googlesource.com/22146 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* image/color: order color computation to match rgbMartin Möhrmann2016-04-153-48/+48
| | | | | | | | | | | The order of computation was switched unintentionally in https://go-review.googlesource.com/21910. Revert the order to first compute g then b. Change-Id: I8cedb5e45fbad2679246839f609bcac4f9052403 Reviewed-on: https://go-review.googlesource.com/22016 Reviewed-by: Nigel Tao <nigeltao@golang.org>
* all: remove unnecessary type conversionsMatthew Dempsky2016-04-152-13/+13
| | | | | | | | | | | | | cmd and runtime were handled separately, and I'm intentionally skipped syscall. This is the rest of the standard library. CL generated mechanically with github.com/mdempsky/unconvert. Change-Id: I9e0eff886974dedc37adb93f602064b83e469122 Reviewed-on: https://go-review.googlesource.com/22104 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
* image/color: optimize YCbCrToRGBMartin Möhrmann2016-04-123-96/+193
| | | | | | | | | | | | | | | | | | | | | | | | | Use one comparison to detect underflow and overflow simultaneously. Use a shift, bitwise complement and uint8 type conversion to handle clamping to upper and lower bound without additional branching. Overall the new code is faster for a mix of common case, underflow and overflow. name old time/op new time/op delta YCbCr-2 1.12ms ± 0% 0.64ms ± 0% -43.01% (p=0.000 n=48+47) name old time/op new time/op delta YCbCrToRGB/0-2 5.52ns ± 0% 5.77ns ± 0% +4.48% (p=0.000 n=50+49) YCbCrToRGB/128-2 6.05ns ± 0% 5.52ns ± 0% -8.69% (p=0.000 n=39+50) YCbCrToRGB/255-2 5.80ns ± 0% 5.77ns ± 0% -0.58% (p=0.000 n=50+49) Found in collaboration with Josh Bleecher Snyder and Ralph Corderoy. Change-Id: Ic5020320f704966f545fdc1ae6bc24ddb5d3d09a Reviewed-on: https://go-review.googlesource.com/21910 Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com> Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
* image/color: add YCbCrToRGB benchmarkJosh Bleecher Snyder2016-04-111-0/+23
| | | | | | | Change-Id: I9ba76d5b0861a901415fdceccaf2f5caa2facb7f Reviewed-on: https://go-review.googlesource.com/21837 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* image/jpeg: reconstruct progressive images even if incomplete.Nigel Tao2016-03-315-49/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes #14522. As I said on that issue: ---- This is a progressive JPEG image. There are two dimensions of progressivity: spectral selection (variables zs and ze in scan.go, ranging in [0, 63]) and successive approximation (variables ah and al in scan.go, ranging in [0, 8), from LSB to MSB, although ah=0 implicitly means ah=8). For this particular image, there are three components, and the SOS markers contain this progression: zs, ze, ah, al: 0 0 0 0 components: 0, 1, 2 zs, ze, ah, al: 1 63 0 0 components: 1 zs, ze, ah, al: 1 63 0 0 components: 2 zs, ze, ah, al: 1 63 0 2 components: 0 zs, ze, ah, al: 1 10 2 1 components: 0 zs, ze, ah, al: 11 63 2 1 components: 0 zs, ze, ah, al: 1 10 1 0 components: 0 The combination of all of these is complete (i.e. spectra 0 to 63 and bits 8 exclusive to 0) for components 1 and 2, but it is incomplete for component 0 (the luma component). In particular, there is no data for component 0, spectra 11 to 63 and bits 1 exclusive to 0. The image/jpeg code, as of Go 1.6, waits until both dimensions are complete before performing the de-quantization, IDCT and copy to an *image.YCbCr. This is the "if zigEnd != blockSize-1 || al != 0 { ... continue }" code and associated commentary in scan.go. Almost all progressive JPEG images end up complete in both dimensions for all components, but this particular image is incomplete for component 0, so the Go code never writes anything to the Y values of the resultant *image.YCbCr, which is why the broken output is so dark (but still looks recognizable in terms of red and blue hues). My reading of the ITU T.81 JPEG specification (Annex G) doesn't explicitly say that this is a valid image, but it also doesn't rule it out. In any case, the fix is, for progressive JPEG images, to always reconstruct the decoded blocks (by performing the de-quantization, IDCT and copy to an *image.YCbCr), regardless of whether or not they end up complete. Note that, in Go, the jpeg.Decode function does not return until the entire image is decoded, so we still only want to reconstruct each block once, not once per SOS (Start Of Scan) marker. ---- A test image was also added, based on video-001.progressive.jpeg. When decoding that image, inserting a println("nComp, zs, ze, ah, al:", nComp, zigStart, zigEnd, ah, al) into decoder.processSOS in scan.go prints: nComp, zs, ze, ah, al: 3 0 0 0 1 nComp, zs, ze, ah, al: 1 1 5 0 2 nComp, zs, ze, ah, al: 1 1 63 0 1 nComp, zs, ze, ah, al: 1 1 63 0 1 nComp, zs, ze, ah, al: 1 6 63 0 2 nComp, zs, ze, ah, al: 1 1 63 2 1 nComp, zs, ze, ah, al: 3 0 0 1 0 nComp, zs, ze, ah, al: 1 1 63 1 0 nComp, zs, ze, ah, al: 1 1 63 1 0 nComp, zs, ze, ah, al: 1 1 63 1 0 In other words, video-001.progressive.jpeg contains 10 different scans. This little program below drops half of them (remembering to keep the "\xff\xd9" End of Image marker): ---- package main import ( "bytes" "io/ioutil" "log" ) func main() { sos := []byte{0xff, 0xda} eoi := []byte{0xff, 0xd9} src, err := ioutil.ReadFile("video-001.progressive.jpeg") if err != nil { log.Fatal(err) } b := bytes.Split(src, sos) println(len(b)) // Prints 11. dst := bytes.Join(b[:5], sos) dst = append(dst, eoi...) if err := ioutil.WriteFile("video-001.progressive.truncated.jpeg", dst, 0666); err != nil { log.Fatal(err) } } ---- The video-001.progressive.truncated.jpeg was converted to png via libjpeg and ImageMagick: djpeg -nosmooth video-001.progressive.truncated.jpeg > tmp.tga convert tmp.tga video-001.progressive.truncated.png rm tmp.tga Change-Id: I72b20cd4fb6746d36d8d4d587f891fb3bc641f84 Reviewed-on: https://go-review.googlesource.com/21062 Reviewed-by: Rob Pike <r@golang.org>
* image/png: ignore trailing IDAT chunksTilman Dilo2016-03-242-0/+34
| | | | | | | | | | | | | Ignore superfluous trailing IDAT chunks which were not consumed when decoding the image. This change fixes decoding of valid images in which a zero-length IDAT chunk appears after the actual image data. It also prevents decoding of trailing garbage IDAT chunks or maliciously embedded additional images. Fixes #14936 Change-Id: I8c76cfa9a03496d9576f72bed2db109271f97c5e Reviewed-on: https://go-review.googlesource.com/21045 Reviewed-by: Nigel Tao <nigeltao@golang.org>
* Rewrite leftover references to plan9.bell-labs.com to 9p.io.Muhammed Uluyol2016-03-062-2/+2
| | | | | | Change-Id: Iadb4aa016a7b361d01827787dbc59164d5d147f2 Reviewed-on: https://go-review.googlesource.com/20291 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* all: single space after period.Brad Fitzpatrick2016-03-022-2/+2
| | | | | | | | | | | | | | | | | | | | The tree's pretty inconsistent about single space vs double space after a period in documentation. Make it consistently a single space, per earlier decisions. This means contributors won't be confused by misleading precedence. This CL doesn't use go/doc to parse. It only addresses // comments. It was generated with: $ perl -i -npe 's,^(\s*// .+[a-z]\.) +([A-Z]),$1 $2,' $(git grep -l -E '^\s*//(.+\.) +([A-Z])') $ go test go/doc -update Change-Id: Iccdb99c37c797ef1f804a94b22ba5ee4b500c4f7 Reviewed-on: https://go-review.googlesource.com/20022 Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Dave Day <djd@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* all: make copyright headers consistent with one space after periodBrad Fitzpatrick2016-03-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | This is a subset of https://golang.org/cl/20022 with only the copyright header lines, so the next CL will be smaller and more reviewable. Go policy has been single space after periods in comments for some time. The copyright header template at: https://golang.org/doc/contribute.html#copyright also uses a single space. Make them all consistent. Change-Id: Icc26c6b8495c3820da6b171ca96a74701b4a01b0 Reviewed-on: https://go-review.googlesource.com/20111 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
* all: fix typos and spellingMartin Möhrmann2016-02-241-1/+1
| | | | | | | | Change-Id: Icd06d99c42b8299fd931c7da821e1f418684d913 Reviewed-on: https://go-review.googlesource.com/19829 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* image/color: have NYCbCrA.RGBA work in 16-bit color.Nigel Tao2015-12-242-9/+53
| | | | | | | | | | This makes NYCbCrA consistent with YCbCr. Fixes #13706. Change-Id: Ifced84372e4865925fa6efef9ca2f1de43da70e0 Reviewed-on: https://go-review.googlesource.com/18115 Reviewed-by: Rob Pike <r@golang.org>
* image: add NYCbCrA types.Nigel Tao2015-10-113-13/+174
| | | | | | | | Fixes #12722 Change-Id: I6a630d8b072ef2b1c63de941743148f8c96b8e5f Reviewed-on: https://go-review.googlesource.com/15671 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* image/png: integer underflow when decodingNathan Otterness2015-09-212-0/+15
| | | | | | | | | | | | | | | | This change addresses an integer underflow appearing only on systems using a 32-bit int type. The patch addresses the problem by limiting the length of unknown chunks to 0x7fffffff. This value appears to already be checked for when parsing other chunk types, so the bug shouldn't appear elsewhere in the package. The PNG spec recommends the maximum size for any chunk to remain under 2^31, so this shouldn't cause errors with valid images. Fixes #12687 Change-Id: I17f0e1683515532c661cf2b0b2bc65309d1b7bb7 Reviewed-on: https://go-review.googlesource.com/14766 Reviewed-by: Nigel Tao <nigeltao@golang.org>
* image/png: reject zero-width and zero-height images.Nigel Tao2015-09-091-2/+2
| | | | | | | | | | | | | http://www.w3.org/TR/PNG/#11IHDR says that "Zero is an invalid value". This change only affects the decoder. The encoder already checks non-positive instead of negative. Fixes #12545. Change-Id: Iba40e1a2f4e0eec8b2fbcd3bbdae886311434da7 Reviewed-on: https://go-review.googlesource.com/14411 Reviewed-by: Rob Pike <r@golang.org>
* image/gif: map/slice literals janitoringDidier Spezia2015-09-041-5/+5
| | | | | | | | | Simplify slice/map literal expressions. Caught with gofmt -d -s, fixed with gofmt -w -s Change-Id: Iefd5f263c4f89a81da9427a7b9d97f13c35ab64f Reviewed-on: https://go-review.googlesource.com/13838 Reviewed-by: Andrew Gerrand <adg@golang.org>
* image/draw: optimize out some bounds checks.Nigel Tao2015-09-011-25/+25
| | | | | | | | | | | | | | | | | | | We could undoubtedly squeeze even more out of these loops, and in the long term, a better compiler would be smarter with bounds checks, but in the short term, this small change is an easy win. benchmark old ns/op new ns/op delta BenchmarkFillOver-8 1619470 1323192 -18.29% BenchmarkCopyOver-8 1129369 1062787 -5.90% BenchmarkGlyphOver-8 420070 378608 -9.87% On github.com/golang/freetype/truetype's BenchmarkDrawString: benchmark old ns/op new ns/op delta BenchmarkDrawString-8 9561435 8807019 -7.89% Change-Id: Ib1c6271ac18bced85e0fb5ebf250dd57d7747e75 Reviewed-on: https://go-review.googlesource.com/14093 Reviewed-by: Rob Pike <r@golang.org>
* image/gif: avoid unused assignmentTarmigan Casebolt2015-08-241-1/+1
| | | | | | | | Change-Id: Iaaecd8be9268c923f40cf0e5153cbf79f7015b8d Reviewed-on: https://go-review.googlesource.com/13892 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* image/color: fix format typo in the tests.Nigel Tao2015-07-161-2/+2
| | | | | | Change-Id: I6f79d201aa4e8c0e3be8d965f14ed36518536036 Reviewed-on: https://go-review.googlesource.com/12281 Reviewed-by: Rob Pike <r@golang.org>
* image/color: tweak the YCbCr to RGBA conversion formula.Nigel Tao2015-07-156-47/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* image/jpeg: don't unread a byte if we've already taken bits from it.Nigel Tao2015-07-142-6/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This rolls back most of golang.org/cl/8841, aka 2f98bac310, and makes a different fix. It keeps the TestTruncatedSOSDataDoesntPanic test introduced by that other CL, which obviously still passes after this CL. Fixes #11650, a regression (introduced by cl/8841) from Go 1.4. The original cl/8841 changed the image/jpeg not to panic on an input given in #10387. We still do not panic on that input, after this CL. I have a corpus of over 160,000 JPEG images, a sample of a web crawl. The image/jpeg code ran happily over that whole corpus both before and after this CL, although that corpus clearly didn't catch the regression in the first place. This code was otherwise tested manually. I don't think that it's trivial to synthesize a JPEG input that happens to run out of Huffman data at just the right place. The test image attached to #11650 obviously has that property, but I don't think we can simply add that test image to the repository: it's 227KiB, and I don't know its copyright status. I also looked back over the issue tracker for problematic JPEGs that people have filed. The Go code, after this CL, is still happy on these files in my directory: issue2362a.jpeg issue3916.jpeg issue3976.jpeg issue4084.jpeg issue4259.jpeg issue4291.jpeg issue4337.jpeg issue4500.jpeg issue4705.jpeg issue4975.jpeg issue5112.jpeg issue6767.jpeg issue9888.jpeg issue10133.jpeg issue10357.jpeg issue10447.jpeg issue11648.jpeg issue11650.jpeg There were other images attached in the issue tracker that aren't actually valid JPEGs. They failed both before and after this CL: broken-issue2362b.jpeg broken-issue6450.jpeg broken-issue8693.jpeg broken-issue10154.jpeg broken-issue10387.jpeg broken-issue10388.jpeg broken-issue10389.jpeg broken-issue10413.jpeg In summary, this CL fixes #11650 and, after some automated and manual testing, I don't think introduces new regressions. Change-Id: I30b67036e9b087f3051d57dac7ea05fb4fa36f66 Reviewed-on: https://go-review.googlesource.com/12163 Reviewed-by: Rob Pike <r@golang.org>
* image/png: don't read filter bytes for empty interlace passes.Nigel Tao2015-07-134-1/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes #11604 The gray-gradient.png image was created by a Go program: ---- package main import ( "image" "image/color" "image/png" "log" "os" ) func main() { f, err := os.Create("a.png") if err != nil { log.Fatal(err) } defer f.Close() m := image.NewGray(image.Rect(0, 0, 1, 16)) for i := 0; i < 16; i++ { m.SetGray(0, i, color.Gray{uint8(i * 0x11)}) } err = png.Encode(f, m) if err != nil { log.Fatal(err) } } ---- The equivalent gray-gradient.interlaced.png image was created via ImageMagick: $ convert -interlace PNG gray-gradient.png gray-gradient.interlaced.png As a sanity check: $ file gray-gradient.* gray-gradient.interlaced.png: PNG image data, 1 x 16, 4-bit grayscale, interlaced gray-gradient.png: PNG image data, 1 x 16, 8-bit grayscale, non-interlaced Change-Id: I7700284f74d1ea30073aede3bce4d7651787bdbc Reviewed-on: https://go-review.googlesource.com/12064 Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* all: link to https instead of httpBrad Fitzpatrick2015-07-113-3/+3
| | | | | | | | | | | | | The one in misc/makerelease/makerelease.go is particularly bad and probably warrants rotating our keys. I didn't update old weekly notes, and reverted some changes involving test code for now, since we're late in the Go 1.5 freeze. Otherwise, the rest are all auto-generated changes, and all manually reviewed. Change-Id: Ia2753576ab5d64826a167d259f48a2f50508792d Reviewed-on: https://go-review.googlesource.com/12048 Reviewed-by: Rob Pike <r@golang.org>
* image/draw: fix double-draw when the dst is paletted.Nigel Tao2015-07-032-1/+24
| | | | | | | | | | | | | The second (fallback) draw is a no-op, but it's a non-trivial amount of work. Fixes #11550. benchmark old ns/op new ns/op delta BenchmarkPaletted-4 16301219 7309568 -55.16% Change-Id: Ic88c537b2b0c710cf517888f3dd15cb702dd142f Reviewed-on: https://go-review.googlesource.com/11858 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* image/gif: accept LZW encodings that do not have an explicit end marker.Nigel Tao2015-06-301-3/+12
| | | | | | | | | | The spec says this is invalid, but it matches giflib's behavior. Fixes #9856 (together with https://go-review.googlesource.com/11661). Change-Id: I05701f62a9e5e724a2d85c6b87ae4111e537146b Reviewed-on: https://go-review.googlesource.com/11663 Reviewed-by: Rob Pike <r@golang.org>
* image/gif: set default loop count to 0 when app ext. is not presentAndrew Bonventre2015-06-232-1/+21
| | | | | | | | | | | It was otherwise not being preserved across specific Decode->Encode->Decode calls. Fixes #11287 Change-Id: I40602da7fa39ec67403bed52ff403f361c6171bb Reviewed-on: https://go-review.googlesource.com/11256 Reviewed-by: Nigel Tao <nigeltao@golang.org>
* image/gif: re-enable some invalid-palette tests.Nigel Tao2015-06-191-18/+14
| | | | | | | | | | | | | | | | | | | | These tests were broken by https://go-review.googlesource.com/#/c/11227/ which fixed the LZW encoder to reject invalid input. For TestNoPalette, the LZW encoder with a litWidth of 2 now rejects an input byte of 128, so we change 128 to 3, as 3 <= (1<<2 - 1). For TestPixelOutsidePaletteRange, the LZW encoder similarly rejects an input byte of 255. Prior to golang.org/cl/11227, the encoder (again with a litWidth of 2) accepted the 255 input byte, but masked it with (1<<2 - 1), so that the 255 test case was effectively the same as the 3 test case. After that LZW CL, the 255 input byte is simply invalid, so we remove it as a test case. The test still tests pixels outside of the palette range, since 3 >= the length of the global palette, which is 2. Change-Id: I50be9623ace016740e34801549c15f83671103eb Reviewed-on: https://go-review.googlesource.com/11273 Reviewed-by: David Symonds <dsymonds@golang.org>
* image/gif: return an error on missing paletteJeff R. Allen2015-06-182-1/+4
| | | | | | | | | | | | A frame that tries to use the global palette when it has not been given should result in an error, not an image with no palette at all. Fixes #11150. Change-Id: If0c3a201a0ac977eee2b7a5dc68930c0c5787f40 Reviewed-on: https://go-review.googlesource.com/11064 Reviewed-by: Nigel Tao <nigeltao@golang.org>
* image/gif: (temporarily) disable broken tests.Nigel Tao2015-06-181-0/+12
| | | | | | | | | | The compress/lzw encoder now rejects too-large input bytes, as of https://go-review.googlesource.com/#/c/11227/, so we can't generate bad GIFs programatically. Change-Id: I0b32ce8e1f1776cd6997869db61e687430464e45 Reviewed-on: https://go-review.googlesource.com/11270 Reviewed-by: Nigel Tao <nigeltao@golang.org>
* all: switch to the new deprecation conventionShenghou Ma2015-06-181-1/+1
| | | | | | | | | While we're at it, move some misplaced comment blocks around. Change-Id: I1847d7f1ca1dbb8e5de737203c4ed6c66e112508 Reviewed-on: https://go-review.googlesource.com/10188 Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
* image/gif: allow encoding a single-frame image whose top-left cornerNigel Tao2015-05-062-2/+37
| | | | | | | | | | | | isn't (0, 0). Also fix a s/b.Min.X/b.Max.X/ typo in bounds checking. Fixes #10676 Change-Id: Ie5ff7ec20ca30367a8e65d32061959a2d8e089e9 Reviewed-on: https://go-review.googlesource.com/9712 Reviewed-by: Rob Pike <r@golang.org>
* image/gif: be consistent wrt "color map" or "color table" names.Nigel Tao2015-05-052-29/+28
| | | | | | | | | The spec at http://www.w3.org/Graphics/GIF/spec-gif89a.txt always says "color table" and not "color map". Change-Id: I4c172e3ade15618cbd616629822ce7d109a200af Reviewed-on: https://go-review.googlesource.com/9668 Reviewed-by: Rob Pike <r@golang.org>
* image/gif: don't encode local color tables if they're the same as theNigel Tao2015-05-042-22/+82
| | | | | | | | global color table. Change-Id: Ia38f75708ed5e5b430680a1eecafb4fc8047269c Reviewed-on: https://go-review.googlesource.com/9467 Reviewed-by: Rob Pike <r@golang.org>
* image/gif: check that individual frame's bounds are within the overallNigel Tao2015-04-293-9/+74
| | | | | | | | | | | | | GIF's bounds. Also change the implicit Config Width and Height to be the Rectangle.Max, not the Dx and Dy, of the first frame's bounds. For the case where the first frame's bounds is something like (5,5)-(8,8), the overall width should be 8, not 3. Change-Id: I3affc484f5e32941a36f15517a92ca8d189d9c22 Reviewed-on: https://go-review.googlesource.com/9465 Reviewed-by: Rob Pike <r@golang.org>
* image/gif: encode disposal, bg index and Config.Nigel Tao2015-04-283-73/+222
| | | | | | | | | | The previous CL implemented decoding, but not encoding. Also return the global color map (if present) for DecodeConfig. Change-Id: I3b99c93720246010c9fe0924dc40a67875dfc852 Reviewed-on: https://go-review.googlesource.com/9389 Reviewed-by: Rob Pike <r@golang.org>
* image/png: don't silently swallow io.ReadFull's io.EOF error when itNigel Tao2015-04-232-0/+24
| | | | | | | | | | lands exactly on an IDAT row boundary. Fixes #10493 Change-Id: I12be7c5bdcde7032e17ed1d4400db5f17c72bc87 Reviewed-on: https://go-review.googlesource.com/9270 Reviewed-by: Rob Pike <r@golang.org>
* image/jpeg: have the LargeImageWithShortData test only allocate 64 MiB, not 604Nigel Tao2015-04-231-8/+8
| | | | | | | | | | | MiB. Fixes #10531 Change-Id: I9eece86837c3df2b1f7df315d5ec94bd3ede3eec Reviewed-on: https://go-review.googlesource.com/9238 Run-TryBot: Nigel Tao <nigeltao@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
View Lorry Controller Status