aboutsummaryrefslogtreecommitdiff
path: root/src/image/jpeg
AgeCommit message (Collapse)Author
2026-03-31image/jpeg: reject RGB and non-standard chroma subsamplingNigel Tao
This fixes a possible panic introduced a few months ago by "image/jpeg: add support for non-standard chroma subsampling ratios" (CL 738280). Fixes #78368 Change-Id: I1f181582b7dc1e2955e3ec26c3aa24bc0f4159df Reviewed-on: https://go-review.googlesource.com/c/go/+/760701 Auto-Submit: Nigel Tao <nigeltao@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Nigel Tao <nigeltao@google.com>
2026-03-05image/jpeg: make decoder.receiveExtend branchlessNigel Tao
On linux/amd64: name old speed new speed delta DecodeBaseline-8 76.4MB/s ± 0% 84.3MB/s ± 0% +10.38% (p=0.008 n=5+5) DecodeProgressive-8 51.0MB/s ± 1% 52.6MB/s ± 0% +3.20% (p=0.008 n=5+5) Thanks to David Le Corfec for the suggestion. Updates #24499 Change-Id: I749102ff0b50044dfd6a73172a1aa03f89ad97bd Reviewed-on: https://go-review.googlesource.com/c/go/+/750900 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Nigel Tao <nigeltao@google.com>
2026-03-04image/jpeg: add support for non-standard chroma subsampling ratiosTaichi Maeda
Add "flex mode" decoding for JPEG images with non-standard YCbCr subsampling ratios that do not match the predefined YCbCrSubsampleRatio values. This includes cases where: 1. Cb and Cr components have different sampling factors 2. The Y component does not have the maximum sampling factors Such images were previously rejected with "unsupported luma/chroma subsampling ratio" but should be valid according to the JPEG specification: https://www.w3.org/Graphics/JPEG/itu-t81.pdf Flex mode allocates a YCbCr444 backing buffer and manually expands pixels according to each component's sampling factors relative to the maximum. This approach mirrors the implementation in kovidgoyal/imaging. Fixes #2362 goos: darwin goarch: arm64 pkg: image/jpeg cpu: Apple M4 Max │ old.txt │ new.txt │ │ sec/op │ sec/op vs base │ FDCT-16 576.9n ± 1% 578.9n ± 1% ~ (p=0.565 n=10) IDCT-16 550.1n ± 0% 573.6n ± 3% +4.27% (p=0.000 n=10) DecodeBaseline-16 520.6µ ± 4% 523.8µ ± 2% ~ (p=0.796 n=10) DecodeProgressive-16 767.9µ ± 3% 747.0µ ± 10% ~ (p=0.123 n=10) EncodeRGBA-16 7.869m ± 3% 8.485m ± 6% +7.82% (p=0.001 n=10) EncodeYCbCr-16 8.761m ± 6% 8.021m ± 2% -8.45% (p=0.001 n=10) geomean 143.5µ 143.8µ +0.18% │ old.txt │ new.txt │ │ B/s │ B/s vs base │ DecodeBaseline-16 113.2Mi ± 4% 112.5Mi ± 2% ~ (p=0.796 n=10) DecodeProgressive-16 76.75Mi ± 3% 78.90Mi ± 10% ~ (p=0.123 n=10) EncodeRGBA-16 148.9Mi ± 3% 138.1Mi ± 7% -7.25% (p=0.001 n=10) EncodeYCbCr-16 100.3Mi ± 7% 109.6Mi ± 2% +9.23% (p=0.001 n=10) geomean 106.7Mi 107.7Mi +0.86% │ old.txt │ new.txt │ │ B/op │ B/op vs base │ DecodeBaseline-16 61.55Ki ± 0% 61.55Ki ± 0% ~ (p=1.000 n=10) ¹ DecodeProgressive-16 253.6Ki ± 0% 253.6Ki ± 0% ~ (p=0.124 n=10) EncodeRGBA-16 4.438Ki ± 0% 4.438Ki ± 0% ~ (p=1.000 n=10) ¹ EncodeYCbCr-16 4.438Ki ± 0% 4.438Ki ± 0% ~ (p=1.000 n=10) ¹ geomean 23.55Ki 23.55Ki +0.00% ¹ all samples are equal │ old.txt │ new.txt │ │ allocs/op │ allocs/op vs base │ DecodeBaseline-16 5.000 ± 0% 5.000 ± 0% ~ (p=1.000 n=10) ¹ DecodeProgressive-16 13.00 ± 0% 13.00 ± 0% ~ (p=1.000 n=10) ¹ EncodeRGBA-16 7.000 ± 0% 7.000 ± 0% ~ (p=1.000 n=10) ¹ EncodeYCbCr-16 7.000 ± 0% 7.000 ± 0% ~ (p=1.000 n=10) ¹ geomean 7.512 7.512 +0.00% ¹ all samples are equal Co-authored-by: Kovid Goyal <kovidgoyal@gmail.com> Change-Id: Ic7353ce6a0b229cb6aa775bb05044d6bcded7ab2 Reviewed-on: https://go-review.googlesource.com/c/go/+/738280 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Nigel Tao <nigeltao@golang.org> Reviewed-by: Nigel Tao <nigeltao@google.com>
2025-09-25image/jpeg: replace fdct.go and idct.go with new implementation in dct.goRuss Cox
The fdct.go and idct.go files were derived from the MPEG-SSG and JPEG-IJG reference code and therefore carry licenses specific to those groups. Various license checkers flag these files as potentially problematic. The code is also not terribly well documented. This CL fixes the license problem by adding a new, from-scratch implementation using a different algorithm. As a bonus, the new code is both faster and more accurate than the old encumbered code. On speed, the new code is up to 20% faster; benchmarks below. On accuracy, in the set of blocks used in the test, we can measure the number of output values that are off-by-one from the exact rounded answer. The old FDCT was off in 8.6% of values; the new one is off in 2.5%. The old IDCT was off in 1.4% of values; the new one is off in 1.2%. goos: darwin goarch: arm64 pkg: image/jpeg cpu: Apple M3 Pro │ old │ new │ │ sec/op │ sec/op vs base │ FDCT-12 619.6n ± 3% 586.5n ± 1% -5.34% (p=0.000 n=10) IDCT-12 752.4n ± 4% 628.0n ± 1% -16.54% (p=0.000 n=10) goos: linux goarch: amd64 cpu: Intel(R) Xeon(R) CPU @ 2.30GHz │ old │ new │ │ sec/op │ sec/op vs base │ FDCT-16 1.817µ ± 0% 1.542µ ± 0% -15.11% (p=0.000 n=10) IDCT-16 1.897µ ± 0% 1.514µ ± 0% -20.22% (p=0.000 n=10) goos: linux goarch: arm64 cpu: whatever gotip-linux-arm64 has │ old │ new │ │ sec/op │ sec/op vs base │ FDCT-8 1.844µ ± 0% 1.847µ ± 0% +0.14% (p=0.000 n=10) IDCT-8 2.127µ ± 0% 1.973µ ± 0% -7.26% (p=0.000 n=10) Change-Id: Ie6d14103c8478ba5a779f234da84f345828eb925 Reviewed-on: https://go-review.googlesource.com/c/go/+/705518 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Alan Donovan <adonovan@google.com> Auto-Submit: Russ Cox <rsc@golang.org> Reviewed-by: Nigel Tao <nigeltao@google.com>
2025-09-25image/jpeg: correct and test reference slowFDCT and slowIDCTRuss Cox
The reference implementations slowFDCT and slowIDCT were not rounding correctly, making the test not as good as it could be. Before, the real implementations were required to always produce values within ±2 of the reference; now, with no changes, the real implementations produce values within ±1 of the (corrected) reference. Also tighten the test to return an error not just on a single value exceeding tolerance but also on too many values at exactly that tolerance. Change-Id: I3dd6ca7582178fef972fb812d848f7a0158a6ed8 Reviewed-on: https://go-review.googlesource.com/c/go/+/705517 Auto-Submit: Russ Cox <rsc@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Alan Donovan <adonovan@google.com>
2025-09-25image/jpeg: prepare for new FDCT/IDCT implementationsRuss Cox
Preparation for a new unencumbered implementation of fdct.go and idct.go. - Change benchmark not to allocate O(b.N) storage. - Make tests point out where differences are. - Parameterize differ tolerance. Change-Id: Id5dfee40f86de894bad72dd6178ba61ec81ea2da Reviewed-on: https://go-review.googlesource.com/c/go/+/705516 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Alan Donovan <adonovan@google.com>
2024-11-06image/jpeg: initialize dct_test constants at compile timeNigel Tao
Doing so is slightly more accurate than calculating at run time (because of float64 rounding errors): https://go.dev/play/p/hrOzHDLjd5K Having these more accurate values isn't necessary for tests to pass, but it's helpful if doing printf-debugging or stepping through the code. Change-Id: I07a65678936e4db05b11f9d8d952b32b2acd51a8 Reviewed-on: https://go-review.googlesource.com/c/go/+/624716 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Nigel Tao <nigeltao@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-11-03image/jpeg: add more theHuffmanSpec commentsNigel Tao
Change-Id: I2c68dde6e968e0643109161e52a76189e48b4d19 Reviewed-on: https://go-review.googlesource.com/c/go/+/624715 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Nigel Tao <nigeltao@golang.org> Reviewed-by: Nigel Tao <nigeltao@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
2024-04-25image/jpeg: ignore garbage bytes before a RST markerNigel Tao
Well-formed JPEG images will not have garbage bytes. However, for corrupted JPEG images, the RST (restart) mechanism is specifically designed so that a decoder can re-synchronize to an upcoming restartable MCU (Minimum Coded Unit, e.g. 16x16 block of pixels) boundary and resume decoding. Even if the resultant image isn't perfect, a 98%-good image is better than a fatal error. Every JPEG marker is encoded in two bytes, the first of which is 0xFF. There are 8 possible RST markers, cycling as "0xFF 0xD0", "0xFF 0xD1", ..., "0xFF 0xD7". Suppose that, our decoder is expecting "0xFF 0xD1". Before this commit, Go's image/jpeg package would accept only two possible inputs: a well-formed "0xFF 0xD1" or one very specific pattern of spec non-compliance, "0xFF 0x00 0xFF 0xD1". After this commit, it is more lenient, similar to libjpeg's jdmarker.c's next_marker function. https://github.com/libjpeg-turbo/libjpeg-turbo/blob/2dfe6c0fe9e18671105e94f7cbf044d4a1d157e6/jdmarker.c#L892-L935 The new testdata file was created by: $ convert video-001.png a.ppm $ cjpeg -restart 2 a.ppm > video-001.restart2.jpeg $ rm a.ppm Fixes #40130 Change-Id: Ic598a5f489f110d6bd63e0735200fb6acac3aca3 Reviewed-on: https://go-review.googlesource.com/c/go/+/580755 Reviewed-by: Ian Lance Taylor <iant@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Joedian Reid <joedian@google.com>
2024-03-11image: use built-in clear to simplify codeapocelipes
Change-Id: Id34936a115baaf61e4268582c6d9a2027494c385 GitHub-Last-Rev: 5fe455b7d24e3e3b871c8999c5bb534f3e1e3ab5 GitHub-Pull-Request: golang/go#66244 Reviewed-on: https://go-review.googlesource.com/c/go/+/570555 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Keith Randall <khr@golang.org>
2023-10-19image: add available godoc linkcui fliter
Change-Id: I2839ecb091c4f0b30d0dcee708bf9e9a55e3672a Reviewed-on: https://go-review.googlesource.com/c/go/+/535196 Auto-Submit: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: shuang cui <imcusg@gmail.com>
2023-08-07encoding/xml, image/jpeg, image/png: use the builtin min functionapocelipes
Change-Id: I9bafc7aa4e20e7cd994b75e7576156ca68f4fc8b GitHub-Last-Rev: e037f689bddd0ef03a6ad38982fe98b4c26aaede GitHub-Pull-Request: golang/go#61746 Reviewed-on: https://go-review.googlesource.com/c/go/+/515855 Run-TryBot: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com>
2023-08-03image/jpeg, image/png: replace Fatal with Error in testsHiro
Replaced t.Fatalf with t.Errorf for non-critical errors to footprint more failing test cases for better analysis of the error. Change-Id: I6f51d21e37a4ddb95d239d8afed2154f3ef52d31 GitHub-Last-Rev: d56aa49bced80c80f1177ae4b9ce038265ead551 GitHub-Pull-Request: golang/go#60524 Reviewed-on: https://go-review.googlesource.com/c/go/+/499336 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: David Chase <drchase@google.com>
2023-02-24image/jpeg: return io.ErrUnexpectedEOF on truncated dataAlexander Yastrebov
Decoder calls fill from readFull, ignore and readByte and readByte did not check returned io.EOF. This change moves io.EOF translation inside fill. name old speed new speed delta DecodeBaseline-8 67.4MB/s ± 0% 67.3MB/s ± 0% -0.20% (p=0.000 n=16+19) DecodeProgressive-8 43.7MB/s ± 0% 43.6MB/s ± 0% -0.06% (p=0.013 n=17+19) Fixes #56724 Change-Id: Ia0d5cc561f3c2050e25ec3f2b5e6866c3b4941c7 GitHub-Last-Rev: 470154373bc1452dffc5293d9a840e972749a76d GitHub-Pull-Request: golang/go#56863 Reviewed-on: https://go-review.googlesource.com/c/go/+/452335 Run-TryBot: Rob Pike <r@golang.org> Reviewed-by: Nigel Tao <nigeltao@golang.org> Reviewed-by: Nigel Tao (INACTIVE; USE @golang.org INSTEAD) <nigeltao@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-09-27image/gif,image/jpeg,image/png: skip FuzzDecode in testing short modeJoel Sing
The image/gif.FuzzDecode takes an excessive amount of time to run on various builders - skip these in testing short mode. Likewise for image/jpeg and image/png. Fixes #55839 Change-Id: I1049d06b9dcbbc7dbc4f53d3c49b64e2254eabbd Reviewed-on: https://go-review.googlesource.com/c/go/+/435175 Reviewed-by: Roland Shoemaker <roland@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Bryan Mills <bcmills@google.com>
2022-09-06image/jpeg: use strings.Buildercuiweixie
Change-Id: I0a51aa9e7800689c123ce3eaf74742a4641b7681 Reviewed-on: https://go-review.googlesource.com/c/go/+/428261 Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-07-12image/jpeg: increase TestLargeImageWithShortData timeout by an order of ↵Bryan C. Mills
magnitude Also dump goroutines on failure. The original bug report in #10413 reported a hang of “several minutes”. An apparently-spurious failure was observed in https://build.golang.org/log/e5ac3ce3fb7d04ec13e5bbfadea8bb5869a4dd1e, with a delay of only 3.64s. Moreover, if the test does fail due to a regression, we will want a goroutine dump to diagnose where it got stuck. The current call to t.Fatalf does not produce such a dump, so is not nearly as useful if the failure only occasionally reproduces. Updates #10413. Change-Id: I6ab9d112f14f438a0c54e02ec95934627acdc64b Reviewed-on: https://go-review.googlesource.com/c/go/+/408355 Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Yuval Pavel Zholkover <paulzhol@gmail.com> Reviewed-by: Robert Findley <rfindley@google.com> Auto-Submit: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-04-11all: gofmt main repoRuss Cox
[This CL is part of a sequence implementing the proposal #51082. The design doc is at https://go.dev/s/godocfmt-design.] Run the updated gofmt, which reformats doc comments, on the main repository. Vendored files are excluded. For #51082. Change-Id: I7332f099b60f716295fb34719c98c04eb1a85407 Reviewed-on: https://go-review.googlesource.com/c/go/+/384268 Reviewed-by: Jonathan Amsterdam <jba@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2022-01-13all: add a handful of fuzz targetsRoland Shoemaker
Adds simple fuzz targets to archive/tar, archive/zip, compress/gzip, encoding/json, image/jpeg, image/gif, and image/png. Second attempt, this time we don't use the archives in testdata when fuzzing archive/tar, since those are rather memory intensive, and were crashing a number of builders. Change-Id: I4828d64fa4763c0d8c980392a6578e4dfd956e13 Reviewed-on: https://go-review.googlesource.com/c/go/+/378174 Trust: Roland Shoemaker <roland@golang.org> Run-TryBot: Roland Shoemaker <roland@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-01-12Revert "all: add a handful of fuzz targets"Bryan Mills
This reverts CL 352109. Reason for revert: causing OOM failures on several builders, and may cause OOMs for end users with small machines as well. Change-Id: I58308d09919969d5a6512ee5cee6aa5c4af6769b Reviewed-on: https://go-review.googlesource.com/c/go/+/377934 Trust: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Katie Hockman <katie@golang.org> Trust: Katie Hockman <katie@golang.org>
2022-01-12all: add a handful of fuzz targetsRoland Shoemaker
Adds simple fuzz targets to archive/tar, archive/zip, compress/gzip, encoding/json, image/jpeg, image/gif, and image/png. Change-Id: Ide1a8de88a9421e786eeeaea3bb93f41e0bae347 Reviewed-on: https://go-review.googlesource.com/c/go/+/352109 Trust: Katie Hockman <katie@golang.org> Reviewed-by: Katie Hockman <katie@golang.org> Trust: Roland Shoemaker <roland@golang.org> Run-TryBot: Roland Shoemaker <roland@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2021-02-24image: resolve the TODO of doc comment styleAndy Pan
Change-Id: Ic7701a9e4635fe1a331c9a1df776ed580759eb9d Reviewed-on: https://go-review.googlesource.com/c/go/+/268758 Reviewed-by: Nigel Tao <nigeltao@golang.org> Reviewed-by: Rob Pike <r@golang.org> Trust: Nigel Tao <nigeltao@golang.org> Trust: Alberto Donizetti <alb.donizetti@gmail.com> Trust: Rob Pike <r@golang.org>
2020-12-09all: update to use os.ReadFile, os.WriteFile, os.CreateTemp, os.MkdirTempRuss Cox
As part of #42026, these helpers from io/ioutil were moved to os. (ioutil.TempFile and TempDir became os.CreateTemp and MkdirTemp.) Update the Go tree to use the preferred names. As usual, code compiled with the Go 1.4 bootstrap toolchain and code vendored from other sources is excluded. ReadDir changes are in a separate CL, because they are not a simple search and replace. For #42026. Change-Id: If318df0216d57e95ea0c4093b89f65e5b0ababb3 Reviewed-on: https://go-review.googlesource.com/c/go/+/266365 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2020-10-20all: update references to symbols moved from io/ioutil to ioRuss Cox
The old ioutil references are still valid, but update our code to reflect best practices and get used to the new locations. Code compiled with the bootstrap toolchain (cmd/asm, cmd/dist, cmd/compile, debug/elf) must remain Go 1.4-compatible and is excluded. Also excluded vendored code. For #41190. Change-Id: I6d86f2bf7bc37a9d904b6cee3fe0c7af6d94d5b1 Reviewed-on: https://go-review.googlesource.com/c/go/+/263142 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
2020-04-29image/jpeg: accept "\xff\x00" before a RST markerNigel Tao
Fixes #28717 Change-Id: I0a1e4ef1583fff89b6f46ef647fb6e4499bdf999 Reviewed-on: https://go-review.googlesource.com/c/go/+/230122 Run-TryBot: Nigel Tao <nigeltao@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rob Pike <r@golang.org>
2019-04-02image/jpeg: reduce bound checks from idct and fdctAgniva De Sarker
Before - $gotip build -gcflags="-d=ssa/check_bce/debug=1" fdct.go idct.go ./fdct.go:89:10: Found IsInBounds ./fdct.go:90:10: Found IsInBounds ./fdct.go:91:10: Found IsInBounds ./fdct.go:92:10: Found IsInBounds ./fdct.go:93:10: Found IsInBounds ./fdct.go:94:10: Found IsInBounds ./fdct.go:95:10: Found IsInBounds ./fdct.go:96:10: Found IsInBounds ./idct.go:77:9: Found IsInBounds ./idct.go:77:27: Found IsInBounds ./idct.go:77:45: Found IsInBounds ./idct.go:78:7: Found IsInBounds ./idct.go:78:25: Found IsInBounds ./idct.go:78:43: Found IsInBounds ./idct.go:78:61: Found IsInBounds ./idct.go:79:13: Found IsInBounds ./idct.go:92:13: Found IsInBounds ./idct.go:93:12: Found IsInBounds ./idct.go:94:12: Found IsInBounds ./idct.go:95:12: Found IsInBounds ./idct.go:97:12: Found IsInBounds ./idct.go:98:12: Found IsInBounds ./idct.go:99:12: Found IsInBounds After - $gotip build -gcflags="-d=ssa/check_bce/debug=1" fdct.go idct.go ./fdct.go:90:9: Found IsSliceInBounds ./idct.go:76:11: Found IsSliceInBounds ./idct.go:145:11: Found IsSliceInBounds name old time/op new time/op delta FDCT-4 1.85µs ± 2% 1.74µs ± 1% -5.95% (p=0.000 n=10+10) IDCT-4 1.94µs ± 2% 1.89µs ± 1% -2.67% (p=0.000 n=10+9) DecodeBaseline-4 1.45ms ± 2% 1.46ms ± 1% ~ (p=0.156 n=9+10) DecodeProgressive-4 2.21ms ± 1% 2.21ms ± 1% ~ (p=0.796 n=10+10) EncodeRGBA-4 24.9ms ± 1% 25.0ms ± 1% ~ (p=0.075 n=10+10) EncodeYCbCr-4 26.1ms ± 1% 26.2ms ± 1% ~ (p=0.573 n=8+10) name old speed new speed delta DecodeBaseline-4 42.5MB/s ± 2% 42.4MB/s ± 1% ~ (p=0.162 n=9+10) DecodeProgressive-4 27.9MB/s ± 1% 27.9MB/s ± 1% ~ (p=0.796 n=10+10) EncodeRGBA-4 49.4MB/s ± 1% 49.1MB/s ± 1% ~ (p=0.066 n=10+10) EncodeYCbCr-4 35.3MB/s ± 1% 35.2MB/s ± 1% ~ (p=0.586 n=8+10) name old alloc/op new alloc/op delta DecodeBaseline-4 63.0kB ± 0% 63.0kB ± 0% ~ (all equal) DecodeProgressive-4 260kB ± 0% 260kB ± 0% ~ (all equal) EncodeRGBA-4 4.40kB ± 0% 4.40kB ± 0% ~ (all equal) EncodeYCbCr-4 4.40kB ± 0% 4.40kB ± 0% ~ (all equal) name old allocs/op new allocs/op delta DecodeBaseline-4 5.00 ± 0% 5.00 ± 0% ~ (all equal) DecodeProgressive-4 13.0 ± 0% 13.0 ± 0% ~ (all equal) EncodeRGBA-4 4.00 ± 0% 4.00 ± 0% ~ (all equal) EncodeYCbCr-4 4.00 ± 0% 4.00 ± 0% ~ (all equal) Updates #24499 Change-Id: I6828d077b851817503a7c1a08235763f81bdadf9 Reviewed-on: https://go-review.googlesource.com/c/go/+/167417 Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Nigel Tao <nigeltao@golang.org>
2018-10-13jpeg: simplify 'x = x op ...' to 'x op= ...'avsharapov
Change-Id: Id431969e42f0d9bd28bbf163d10378a6de2416f2 Reviewed-on: https://go-review.googlesource.com/c/141999 Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Iskander Sharipov <iskander.sharipov@intel.com>
2018-07-06all: clean up some Deprecated commentsBrad Fitzpatrick
Change-Id: Ie801fe6a2883d79229ee2955e26948c1b4964802 Reviewed-on: https://go-review.googlesource.com/122496 Reviewed-by: Russ Cox <rsc@golang.org>
2018-06-01all: update comment URLs from HTTP to HTTPS, where possibleTim Cooper
Each URL was manually verified to ensure it did not serve up incorrect content. Change-Id: I4dc846227af95a73ee9a3074d0c379ff0fa955df Reviewed-on: https://go-review.googlesource.com/115798 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org>
2017-10-07image/gif: add BenchmarkDecode.Nigel Tao
Also add some b.ReportAllocs calls to other image codec benchmarks. Change-Id: I0f055dc76bffb66329c621a5f1ccd239f0cdd30b Reviewed-on: https://go-review.googlesource.com/68390 Reviewed-by: Jed Denlea <jed@fastly.com> Reviewed-by: Nigel Tao <nigeltao@golang.org>
2017-04-27image/jpeg: fix extended sequential Huffman table selector (Th).Nigel Tao
Previously, the package did not distinguish between baseline and extended sequential images. Both are non-progressive images, but the Th range differs between the two, as per Annex B of https://www.w3.org/Graphics/JPEG/itu-t81.pdf Extended sequential images are often emitted by the Guetzli encoder. Fixes #19913 Change-Id: I3d0f9e16d5d374ee1c65e3a8fb87519de61cff94 Reviewed-on: https://go-review.googlesource.com/41831 Reviewed-by: David Symonds <dsymonds@golang.org>
2017-02-01image/jpeg: improve performance when encoding *image.YCbCrThomas Bonfort
The existing implementation falls back to using image.At() for each pixel when encoding an *image.YCbCr which is inefficient and causes many memory allocations. This change makes the jpeg encoder directly read Y, Cb, and Cr pixel values. benchmark old ns/op new ns/op delta BenchmarkEncodeYCbCr-4 43990846 24201148 -44.99% benchmark old MB/s new MB/s speedup BenchmarkEncodeYCbCr-4 20.95 38.08 1.82x Fixes #18487 Change-Id: Iaf2ebc646997e3e1fffa5335f1b0d642e15bd453 Reviewed-on: https://go-review.googlesource.com/34773 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Nigel Tao <nigeltao@golang.org>
2016-03-31image/jpeg: reconstruct progressive images even if incomplete.Nigel Tao
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>
2015-07-14image/jpeg: don't unread a byte if we've already taken bits from it.Nigel Tao
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>
2015-06-18all: switch to the new deprecation conventionShenghou Ma
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>
2015-04-23image/jpeg: have the LargeImageWithShortData test only allocate 64 MiB, not 604Nigel Tao
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>
2015-04-22image/jpeg: ensure that we can't unread a byte if we didn't read a byte.Nigel Tao
Fixes #10413 Change-Id: I7a4ecd042c40f786ea7406c670d561b1c1179bf0 Reviewed-on: https://go-review.googlesource.com/8998 Reviewed-by: Rob Pike <r@golang.org>
2015-04-14image/jpeg: don't assume that an ensureNBits failure implies that we canNigel Tao
call unreadByteStuffedByte. If ensureNBits was due to an io.EOF that was translated to jpeg.errShortHuffmanData, then we may have read no bytes, so there is no byte-stuffed-byte to unread. Fixes #10387 Change-Id: I39a3842590c6cef2aa48943288d52f603338b44d Reviewed-on: https://go-review.googlesource.com/8841 Reviewed-by: Rob Pike <r@golang.org>
2015-04-09image/jpeg: reject multiple Start-Of-Frame markers.Nigel Tao
Fixes #10389 Change-Id: Id1c687122751f9317041d9e425d03b267a26c6de Reviewed-on: https://go-review.googlesource.com/8681 Reviewed-by: Rob Pike <r@golang.org>
2015-03-23image/internal/imageutil: new package, used by image/draw and image/jpeg.Nigel Tao
The imageutil.DrawYCbCr function lives in an internal package because it is needed by both the image/draw and image/jpeg packages, but it doesn't seem right for one of those two to depend on the other. It could eventually go into the image package, but that would require committing to an API for the rest of Go 1.x. Change-Id: I7b12555c970d86409365e99eef9360702aaffa30 Reviewed-on: https://go-review.googlesource.com/7925 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Rob Pike <r@golang.org>
2015-03-13image/jpeg: reject bad Tq values in SOF data.Nigel Tao
Fixes #10154 Change-Id: Ibb8ea9bcf512e7639c57a6f17afbe4495fa329cd Reviewed-on: https://go-review.googlesource.com/7494 Reviewed-by: Minux Ma <minux@golang.org>
2015-03-11image/jpeg: support chroma hv values other than 0x11.Nigel Tao
The testdata was generated by: convert video-001.png tmp1.tga cjpeg -quality 100 -sample 2x2,1x2,1x2 tmp1.tga > video-001.221212.jpeg djpeg -nosmooth -targa video-001.221212.jpeg > tmp2.tga convert tmp2.tga video-001.221212.png rm tmp1.tga tmp2.tga Change-Id: Ica241dfc19b3eb47ade150bf0432373c6006c38a Reviewed-on: https://go-review.googlesource.com/7264 Reviewed-by: Rob Pike <r@golang.org>
2015-03-09image/jpeg: support RGB JPEG images.Nigel Tao
The testdata was generated by: convert video-001.png tmp1.tga cjpeg -rgb -sample 2x2,1x1,1x1 tmp1.tga > video-001.rgb.jpeg djpeg -nosmooth -targa video-001.rgb.jpeg > tmp2.tga convert tmp2.tga video-001.rgb.png rm tmp1.tga tmp2.tga Change-Id: I5da0591b9005c1c75e807311f157d385e0e20a38 Reviewed-on: https://go-review.googlesource.com/6910 Reviewed-by: Rob Pike <r@golang.org>
2015-03-04image/jpeg: check for component uniqueness and total sampling factors.Nigel Tao
Change-Id: I83de9d83708edc8d196bbcfdc7d2ba7ffaff50d2 Reviewed-on: https://go-review.googlesource.com/6586 Reviewed-by: Rob Pike <r@golang.org>
2015-03-03image/jpeg: when following component selectors, only consider validNigel Tao
components. This fixes decoding JPEG images where the component selector is 0. Such images are rare, but not impossible. Change-Id: I6d221bce01cce8cc0440e117543233371782ca22 Reviewed-on: https://go-review.googlesource.com/6421 Reviewed-by: Rob Pike <r@golang.org>
2015-03-02image/jpeg: distinguish between FormatError and UnsupportedError whenNigel Tao
encountering unknown markers. Change-Id: Ica86013308d69da2f5b486119235ff693135b2f1 Reviewed-on: https://go-review.googlesource.com/6393 Reviewed-by: David Symonds <dsymonds@golang.org> Run-TryBot: David Symonds <dsymonds@golang.org>
2015-02-26image/jpeg: support 4:1:1 and 4:1:0 chroma subsampling.Nigel Tao
The test data was generated by: convert video-001.png tmp.tga cjpeg -quality 50 -sample 4x2,1x1,1x1 tmp.tga > video-001.q50.410.jpeg cjpeg -quality 50 -sample 4x1,1x1,1x1 tmp.tga > video-001.q50.411.jpeg cjpeg -quality 50 -sample 4x2,1x1,1x1 -progressive tmp.tga > video-001.q50.410.progressive.jpeg cjpeg -quality 50 -sample 4x1,1x1,1x1 -progressive tmp.tga > video-001.q50.411.progressive.jpeg rm tmp.tga Change-Id: I5570389c462360f98c3160f3c6963d9466d511de Reviewed-on: https://go-review.googlesource.com/6041 Reviewed-by: Rob Pike <r@golang.org>
2015-02-19image/jpeg: support 16-bit quantization tables and Extended SequentialNigel Tao
frames. Fixes #9888. Change-Id: I60f1d843e72e1b7bc77ab984f149c9ddb5258a06 Reviewed-on: https://go-review.googlesource.com/5251 Reviewed-by: Rob Pike <r@golang.org>
2015-02-16image/jpeg: remove the (temporary) dependency on image/draw.Nigel Tao
Change-Id: Idd66f9c3c9eaa4ff1f950fb90e4800dc625dec08 Reviewed-on: https://go-review.googlesource.com/4916 Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
2015-02-16image/jpeg: support decoding CMYK and YCbCrK images.Nigel Tao
The new testdata was created by: convert video-001.png -colorspace cmyk video-001.cmyk.jpeg video-001.cmyk.jpeg was then converted back to video-001.cmyk.png via the GIMP. ImageMagick (convert) wasn't used for this second conversion because IM's default color profiles complicates things. Fixes #4500. Change-Id: Ibf533f6a6c7e76883acc493ce3a4289d7875df3f Reviewed-on: https://go-review.googlesource.com/4801 Reviewed-by: Rob Pike <r@golang.org>
generated by cgit v1.3 (git 2.53.0) at 2026-04-16 02:57:19 +0000