Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

image/jpeg: Decode valid JPEG from guetzli returns error "invalid JPEG format: bad Th value" #19913

Closed
tylerchr opened this issue Apr 10, 2017 · 5 comments
Closed

image/jpeg: Decode valid JPEG from guetzli returns error "invalid JPEG format: bad Th value" #19913

tylerchr opened this issue Apr 10, 2017 · 5 comments
Labels
FrozenDueToAge help wanted NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Go1.9Maybe

Comments

@tylerchr
Copy link

Please answer these questions before submitting your issue. Thanks!

What did you do?

Passed a guetzli-encoded JPEG stream (https://dl.dropboxusercontent.com/u/337227/bees.jpg) to jpeg.Decode:

(quick example; downloads bees.jpg over HTTP—but play.golang.org can't do that)

https://play.golang.org/p/93iPWkz4U4

What did you expect to see?

When using the above-mentioned bees.jpg image:

$ go run main.go
2017/04/10 12:19:11 (0,0)-(444,258)

What did you see instead?

$ go run main.go
2017/04/10 12:19:11 jpeg: invalid JPEG format: bad Th value
panic: jpeg: invalid JPEG format: bad Th value

Additional details

I first discovered this problem with the sample bees.png image from the Guetzli project, which I had encoded with guetzli to a JPEG using default settings (see https://github.com/google/guetzli#using; bees.png is the "sample high quality image"):

$ curl -o bees.png https://github.com/google/guetzli/releases/download/v0/bees.png
$ guetzli bees.png bees.jpg
# now we have bees.jpg
# my bees.jpg is https://dl.dropboxusercontent.com/u/337227/bees.jpg

This doesn't happen with all guetzli-encoded JPEGs. I don't know anything about image compression, but grayscale images and normal line-drawing, solid-color PNGs that are guetzli-encoded to JPEG, for example, don't appear to exhibit this problem. I can generate "broken" images fairly reliably by converting color JPEG photographs to PNGs (via sips, comes with macOS) and then back to JPEGs using guetzli:

main.go:

package main

import (
	"image/jpeg"
	"log"
	"os"
)

// USAGE: go run program.go path/to/some.jpg

func main() {

	file, err := os.Open(os.Args[1])
	if err != nil {
		panic(err)
	}
	defer file.Close()

	// decode the JPEG
	img, err := jpeg.Decode(file)
	if err != nil {
		log.Panicf("jpeg: %s\n", err)
	}

	// print the image dimensions
	log.Println(img.Bounds().String())

}
$ sips -s format png ~/Downloads/some-image.jpg --out image.png
$ guetzli image.png guetzli-image.jpg
$ go run main.go guetzli-image.jpg
2017/04/10 12:19:11 jpeg: invalid JPEG format: bad Th value
panic: jpeg: invalid JPEG format: bad Th value

Does this issue reproduce with the latest release (go1.8.1)?

Yes, this issue reproduces with:

System details

go version devel +26c2926 Mon Apr 10 17:40:01 2017 +0000 darwin/amd64
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/tylerchr/golang"
GORACE=""
GOROOT="/Users/tylerchr/golang/src/github.com/golang/go"
GOTOOLDIR="/Users/tylerchr/golang/src/github.com/golang/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="/usr/bin/clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/1j/5gtkgfks7tx8t86dj84hjdkr0000gn/T/go-build668999938=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="/usr/bin/clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOROOT/bin/go version: go version devel +26c2926 Mon Apr 10 17:40:01 2017 +0000 darwin/amd64
GOROOT/bin/go tool compile -V: compile version devel +26c2926 Mon Apr 10 17:40:01 2017 +0000 X:framepointer
uname -v: Darwin Kernel Version 16.0.0: Mon Aug 29 17:56:20 PDT 2016; root:xnu-3789.1.32~3/RELEASE_X86_64
ProductName:	Mac OS X
ProductVersion:	10.12
BuildVersion:	16A323
lldb --version: lldb-buildbot-2015-12-01 (LLDB cf05a10ea0, LLVM 46be9ff861, Clang 4deb154edc, Swift-2.2 778f82939c)
@bradfitz bradfitz added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Apr 10, 2017
@bradfitz bradfitz added this to the Go1.9Maybe milestone Apr 10, 2017
@bradfitz
Copy link
Contributor

/cc @nigeltao @robpike

@kennygrant
Copy link
Contributor

The problem occurs at line 104 of image/jpeg/huffman.go

https://github.com/golang/go/blob/master/src/image/jpeg/huffman.go#L104

Changing the line to simply check for th > maxTh instead resolves the problem for this test image and other tests still pass.

@gopherbot
Copy link

CL https://golang.org/cl/41831 mentions this issue.

@Exlsunshine
Copy link

Exlsunshine commented Feb 26, 2018 •
edited

Does it mean that the only way to solve this problem is to upgrade Golang to the latest version?

@bradfitz
Copy link
Contributor

Yes.

@golang golang locked and limited conversation to collaborators Feb 26, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge help wanted NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Go1.9Maybe
Development

No branches or pull requests
6 participants
@bradfitz @kennygrant @tylerchr @Exlsunshine @nigeltao @gopherbot