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>
I somehow missed this in the previous change. Not sure how.
Change-Id: Ib9277944418a73cda6acc07fc308d846b4064b9e
Reviewed-on: https://go-review.googlesource.com/11321
Reviewed-by: Nigel Tao <nigeltao@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>
There is no code changes in this CL, just a copy/paste and some
wordsmithing.
Change-Id: I418e8aed5ab997fad4214e8049287cac4bce8bf6
Reviewed-on: https://go-review.googlesource.com/11274
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
This CL has no code changes. Future CLs will modify the code to
implement TIFF's LZW instead of the standard LZW.
LGTM=bradfitz
R=djd, bradfitz
CC=golang-codereviews
https://golang.org/cl/105750044
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
TIFF6.0 Spec:
Page 31: ExtraSamples can only included in RGB mode image.
Page 39, SamplesPerPixel is usually 1 for bilevel, grayscale, and palette-color images.
Page 64, Currently Predictor field is used only with LZW.
Fixesgolang/go#6421.
R=bsiegert, nigeltao, gbulmer
CC=golang-dev
https://golang.org/cl/13779043
No functional change at the moment but it will allow choosing
the compression type.
This is an incompatible, user-visible change. To get the old
behavior, callers of tiff.Encode need to add ", nil" as the
last parameter.
R=nigeltao
CC=golang-dev
https://golang.org/cl/6479044
Performance for an RGBA image:
benchmark old ns/op new ns/op delta
BenchmarkEncode 1633495 7897 -99.52%
benchmark old MB/s new MB/s speedup
BenchmarkEncode 37.83 7824.96 206.85x
NRGBA images are now encoded as such, the spec calls it
"unassociated alpha".
R=nigeltao, rsc
CC=golang-dev
https://golang.org/cl/6308049
The idea is to see whether it is worthwhile to implement special cases.
On my Mac Book Pro:
BenchmarkEncode 1000 1689656 ns/op 36.69 MB/s
R=nigeltao, minux.ma
CC=golang-dev
https://golang.org/cl/6278050
The basic functionality works. Features to add in future CLs:
- compression
- fast paths for image formats that can be directly expressed in TIFF,
such as RGBA, NRGBA and maybe Gray and Paletted.
R=nigeltao
CC=golang-dev
https://golang.org/cl/5694051
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
