aboutsummaryrefslogtreecommitdiff
path: root/src/image/jpeg/reader_test.go
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-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>
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>
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-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>
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-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>
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>
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-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>
2014-11-22image/jpeg: handle Read returning n > 0, err != nil in d.fillRuss Cox
Fixes #9127. LGTM=r R=bradfitz, r CC=golang-codereviews, nigeltao https://golang.org/cl/178120043
2014-09-08build: move package sources from src/pkg to srcRuss Cox
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.
generated by cgit v1.3 (git 2.53.0) at 2026-04-16 09:20:07 +0000