The proposed fix updates the x axis offset variable in case the tile
surpasses the limits of the destination image.
Fixesgolang/go#24657
Change-Id: I6bc52274a05dc41b058f6a6f1d0a304f1b20152d
Reviewed-on: https://go-review.googlesource.com/104295
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The spec says that these images are invalid. Add a test with an invalid
tiff generated by go-fuzz.
Fixesgolang/go#10549
Change-Id: I3fd3ae5e607202b41735a2d930f55cb7997f7a9b
Reviewed-on: https://go-review.googlesource.com/9377
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Make all occurrences of "not enough pixel data" refer to the
same one.
Change-Id: Iecff9f22eba7a8852174ba18d1e68226c76f84c6
Reviewed-on: https://go-review.googlesource.com/11030
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Fuzzing detected that an invalid tile size could cause a
panic. Fix a typo in the range check to solve it.
Fixesgolang/go#10712.
Change-Id: I88a5a7884d98f622cc89ed6e394becebb07c6e60
Reviewed-on: https://go-review.googlesource.com/11020
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Fuzzing detected a divide by zero in images with 0 bits
per sample. Instead of panicing, return an error. Do more
validation of bits per sample so that the package only
supports what we've actually tested.
Fixesgolang/go#10711.
Change-Id: Ib41b5cd798c32b06429164c9bc471f5f321d88c5
Reviewed-on: https://go-review.googlesource.com/10943
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Return a zero width or zero height image of the appropriate type.
Fixesgolang/go#10393.
Change-Id: I3aa7b6125447726600fb072ce1e8682373ce2a57
Reviewed-on: https://go-review.googlesource.com/9182
Reviewed-by: Nigel Tao <nigeltao@golang.org>
The blue-purple-pink.lzwcompressed.tiff image was created by
"bmp2tiff -c lzw".
LGTM=djd
R=djd
CC=bsiegert, golang-codereviews
https://golang.org/cl/105750045
no_compress.tiff is no_rps.tiff that was read in by go.image/tiff and written out again (with a hack to avoid creating the Compression tag on the way out).
$ tiffdump no_compress.tiff
no_compress.tiff:
Magic: 0x4949 <little-endian> Version: 0x2a
Directory 0: offset 968 (0x3c8) next 0 (0)
ImageWidth (256) SHORT (3) 1<16>
ImageLength (257) SHORT (3) 1<15>
BitsPerSample (258) SHORT (3) 4<8 8 8 8>
Photometric (262) SHORT (3) 1<2>
StripOffsets (273) LONG (4) 1<8>
SamplesPerPixel (277) SHORT (3) 1<4>
RowsPerStrip (278) SHORT (3) 1<15>
StripByteCounts (279) LONG (4) 1<960>
XResolution (282) RATIONAL (5) 1<72>
YResolution (283) RATIONAL (5) 1<72>
ResolutionUnit (296) SHORT (3) 1<2>
ExtraSamples (338) SHORT (3) 1<2>
LGTM=bsiegert, nigeltao
R=bsiegert, nigeltao
CC=golang-codereviews
https://golang.org/cl/95930044
In case the image is read via a tiff.buffer, avoid copying the
data strip before decoding it. Remove corresponding TODO.
Speeds up reading uncompressed images (which is the common case)
and uses much less memory.
benchmark old ns/op new ns/op delta
BenchmarkDecodeCompressed 4619438 4630774 +0.25%
BenchmarkDecodeUncompressed 260809 219875 -15.70%
R=nigeltao
CC=golang-dev
https://golang.org/cl/5683050
Manual edits to README.
Moved from main Go repository, deleted Makefiles.
Tested with go test code.google.com/p/go.image/...
Fixesgolang/go#2797.
R=rsc, rsc, r
CC=golang-dev
https://golang.org/cl/5593053
