delta/go-git.git/src/image, branch dev.debug

image/gif: fix writeImageBlock with SubImages

2017-06-16T05:45:48+00:00

If an image has been cropped horizontally, writeImageBlock detects that
its width and Stride differ and acts accordingly.

However, if an image has been cropped vertically, trimming from the
bottom, the whole original image will be written in place.  This results
in more data in the LZW stream than necessary, and many decoders
including image/gif's itself will fail to load.

Fixes #20692

Change-Id: Id332877e31bcf3729c89d8a50c1be0464028d82e
Reviewed-on: https://go-review.googlesource.com/45972
Run-TryBot: Emmanuel Odeke 
Run-TryBot: Nigel Tao 
TryBot-Result: Gobot Gobot 
Reviewed-by: Nigel Tao

image/gif: don't panic on large or nil-containing color.Palettes.

2017-05-06T00:37:43+00:00

Fixes #20249

Change-Id: I5dceaef31de96345f8e6c155e12775dc4cc31bfb
Reviewed-on: https://go-review.googlesource.com/42790
Reviewed-by: Brad Fitzpatrick

image/jpeg: fix extended sequential Huffman table selector (Th).

2017-04-27T03:48:40+00:00

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

all: remove some unused parameters in test code

2017-04-25T14:38:10+00:00

Mostly unnecessary *testing.T arguments.

Found with github.com/mvdan/unparam.

Change-Id: Ifb955cb88f2ce8784ee4172f4f94d860fa36ae9a
Reviewed-on: https://go-review.googlesource.com/41691
Run-TryBot: Daniel Martí 
TryBot-Result: Gobot Gobot 
Reviewed-by: Ian Lance Taylor

image/png: decode Gray8 transparent images.

2017-03-17T07:50:05+00:00

Fixes #19553.

Change-Id: I414cb3b1c2dab20f41a7f4e7aba49c534ff19942
Reviewed-on: https://go-review.googlesource.com/38271
Reviewed-by: Brad Fitzpatrick

image/gif: handle an extra data sub-block byte.

2017-03-02T23:49:32+00:00

This changes the decoder's behaviour when there is stray/extra data
found after an image is decompressed (e.g., data sub-blocks after an LZW
End of Information Code). Instead of raising an error, we silently skip
over such data until we find the end of the image data marked by a Block
Terminator. We skip at most one byte as sample problem GIFs exhibit this
property.

GIFs should not have and do not need such stray data (though the
specification is arguably ambiguous). However GIFs with such properties
have been seen in the wild.

Fixes #16146

Change-Id: Ie7e69052bab5256b4834992304e6ca58e93c1879
Reviewed-on: https://go-review.googlesource.com/37258
Reviewed-by: Nigel Tao 
Run-TryBot: Nigel Tao 
TryBot-Result: Gobot Gobot

image/png: reduce memory allocs encoding images by reusing buffers

2017-02-12T05:40:47+00:00

This change allows greatly reducing memory allocations with a slightly
performance improvement as well.

Instances of (*png).Encoder can have a optional BufferPool attached to
them. This allows reusing temporary buffers used when encoding a new
image. This buffers include instances to zlib.Writer and bufio.Writer.

Also, buffers for current and previous rows are saved in the encoder
instance and reused as long as their cap() is enough to fit the current
image row.

A new benchmark was added to demonstrate the performance improvement
when setting a BufferPool to an Encoder instance:

$ go test -bench BenchmarkEncodeGray -benchmem
BenchmarkEncodeGray-4                 	    1000	   2349584 ns/op	 130.75 MB/s	  852230 B/op	      32 allocs/op
BenchmarkEncodeGrayWithBufferPool-4   	    1000	   2241650 ns/op	 137.04 MB/s	     900 B/op	       3 allocs/op

Change-Id: I4488201ae53cb2ad010c68c1e0118ee12beae14e
Reviewed-on: https://go-review.googlesource.com/34150
Reviewed-by: Nigel Tao 
Run-TryBot: Nigel Tao 
TryBot-Result: Gobot Gobot

image/color: tweak the YCbCr to RGBA conversion formula again.

2017-02-10T22:57:50+00:00

The 0x10101 magic constant is a little more principled than 0x10100, as
the rounding adjustment now spans the complete range [0, 0xffff] instead
of [0, 0xff00].

Consider this round-tripping code:

y, cb, cr := color.RGBToYCbCr(r0, g0, b0)
r1, g1, b1 := color.YCbCrToRGB(y, cb, cr)

Due to rounding errors both ways, we often but not always get a perfect
round trip (where r0 == r1 && g0 == g1 && b0 == b1). This is true both
before and after this commit. In some cases we got luckier, in others we
got unluckier.

For example, before this commit, (180, 135, 164) doesn't round trip
perfectly (it's off by 1) but (180, 135, 165) does. After this commit,
both cases are reversed: the former does and the latter doesn't (again
off by 1). Over all possible (r, g, b) triples, there doesn't seem to be
a big change for better or worse.

There is some history in these CLs:

image/color: tweak the YCbCr to RGBA conversion formula.
https://go-review.googlesource.com/#/c/12220/2/src/image/color/ycbcr.go

image/color: have YCbCr.RGBA work in 16-bit color, per the Color
interface.
https://go-review.googlesource.com/#/c/8073/2/src/image/color/ycbcr.go

Change-Id: Ib25ba7039f49feab2a9d1a4141b86db17db7b3e1
Reviewed-on: https://go-review.googlesource.com/36732
Run-TryBot: Nigel Tao 
TryBot-Result: Gobot Gobot 
Reviewed-by: Rob Pike

image: fix the overlap check in Rectangle.Intersect.

2017-02-10T05:05:59+00:00

This is a re-roll of a previous commit,
a855da29dbd7a80c4d87a421c1f88a8603c020fa, which was rolled back in
14347ee480968c712ea885a4ea62779fd8a0dc44.

It was rolled back because it broke a unit test in image/gif. The
image/gif code was fixed by 9ef65dbe0683634a2e8a557d12267d0309ae1570
"image/gif: fix frame-inside-image bounds checking".

The original commit message:

image: fix the overlap check in Rectangle.Intersect.

The doc comment for Rectangle.Intersect clearly states, "If the two
rectangles do not overlap then the zero rectangle will be returned."
Prior to this fix, calling Intersect on adjacent but non-overlapping
rectangles would return an empty but non-zero rectangle.

The fix essentially changes
if r.Min.X > r.Max.X || r.Min.Y > r.Max.Y { etc }
to
if r.Min.X >= r.Max.X || r.Min.Y >= r.Max.Y { etc }
(note that the > signs have become >= signs), but changing that line to:
if r.Empty() { etc }
seems clearer (and equivalent).

Change-Id: I2e3af1f1686064a573b2e513b39246fe60c03631
Reviewed-on: https://go-review.googlesource.com/36734
Reviewed-by: Rob Pike 
Run-TryBot: Nigel Tao 
TryBot-Result: Gobot Gobot

image/gif: fix frame-inside-image bounds checking.

2017-02-10T03:31:09+00:00

The semantics of the Go image.Rectangle type is that the In and
Intersects methods treat empty rectangles specially. There are multiple
valid representations of an empty image.Rectangle. One of them is the
zero image.Rectangle but there are others. They're obviously not all
equal in the == sense, so we shouldn't use != to check GIF's semantics.

This change will allow us to re-roll
a855da29dbd7a80c4d87a421c1f88a8603c020fa "image: fix the overlap check
in Rectangle.Intersect" which was rolled back in
14347ee480968c712ea885a4ea62779fd8a0dc44.

Change-Id: Ie1a0d092510a7bb6170e61adbf334b21361ff9e6
Reviewed-on: https://go-review.googlesource.com/36639
Run-TryBot: Nigel Tao 
TryBot-Result: Gobot Gobot 
Reviewed-by: Rob Pike