| Age | Commit message (Collapse) | Author |
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Fixes #10413
Change-Id: I7a4ecd042c40f786ea7406c670d561b1c1179bf0
Reviewed-on: https://go-review.googlesource.com/8998
Reviewed-by: Rob Pike <r@golang.org>
|
|
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>
|
|
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>
|
|
Fixes #9127.
LGTM=r
R=bradfitz, r
CC=golang-codereviews, nigeltao
https://golang.org/cl/178120043
|
|
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.
|