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

[tylerchr]

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:

• Go 1.8
• Go 1.8.1
• Go tip 26c2926

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]

/cc @nigeltao @robpike

[kennygrant]

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]

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

[Exlsunshine]

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

[bradfitz]

Yes.