Adding fast paths for concrete dst and src image types will be follow-up
changes.
Change-Id: Ib23e3cc46d9c7a52ebd5eddfbad09177b0b421af
Reviewed-on: https://go-review.googlesource.com/5417
Reviewed-by: Rob Pike <r@golang.org>
This is just a copy/paste/rename in anticipation of automatically
generating fast-path code for specific dst-image types and src-image
types, a la the standard library's image/draw package.
Change-Id: If6385b347cb5e1d134b0ce841ef38ed4450a6fef
Reviewed-on: https://go-review.googlesource.com/5252
Reviewed-by: David Symonds <dsymonds@golang.org>
This fixes all three lossy_alpha*.webp conformance tests.
The test data was generated by cwebp/dwebp version 0.4.1:
cwebp yellow_rose.png -o yellow_rose.lossy-with-alpha.webp
dwebp yellow_rose.lossy-with-alpha.webp -pgm -o tmp.pgm
convert tmp.pgm yellow_rose.lossy-with-alpha.webp.nycbcra.png
LGTM=pascal.massimino, r
R=r, pascal.massimino
CC=golang-codereviews
https://golang.org/cl/154350043
This fixes the lossy_extreme_probabilities.webp conformance test.
LGTM=pascal.massimino, r
R=r, pascal.massimino
CC=golang-codereviews
https://golang.org/cl/145600043
compatibility with the C libwebp implementation.
Current status:
104 PASS, 5 FAIL, 109 TOTAL
Of those 5 failures, 3 are because Go doesn't support lossy-with-alpha
yet, and the other 2 (lossless_vec_2_13.webp,
lossy_extreme_probabilities.webp) look like genuine bugs.
LGTM=r
R=r, pascal.massimino
CC=golang-codereviews
https://golang.org/cl/150000043
This makes the Go code match the libwebp C code's output on
blue-purple-pink-large.*-filter.lossy.webp
Also make the various WEBP benchmarks all decode a similar image,
the image at http://blog.golang.org/gophercon/image01.jpg, to make
it more meaningful to e.g. compare the simple filter's numbers with
the normal filter's numbers.
Also fix a "go vet" warning in webp/decode.go.
The test data was generated by:
wget http://blog.golang.org/gophercon/image01.jpg -O blue-purple-pink-large.jpeg
convert blue-purple-pink-large.jpeg blue-purple-pink-large.png
cwebp -lossless blue-purple-pink-large.png -o blue-purple-pink-large.lossless.webp
cwebp -q 80 -f 0 blue-purple-pink-large.png -o blue-purple-pink-large.no-filter.lossy.webp
cwebp -q 80 -strong blue-purple-pink-large.png -o blue-purple-pink-large.normal-filter.lossy.webp
cwebp -q 80 -nostrong blue-purple-pink-large.png -o blue-purple-pink-large.simple-filter.lossy.webp
dwebp -pgm blue-purple-pink-large.no-filter.lossy.webp -o tmp.pgm && convert tmp.pgm blue-purple-pink-large.no-filter.lossy.webp.ycbcr.png && rm tmp.pgm
dwebp -pgm blue-purple-pink-large.normal-filter.lossy.webp -o tmp.pgm && convert tmp.pgm blue-purple-pink-large.normal-filter.lossy.webp.ycbcr.png && rm tmp.pgm
dwebp -pgm blue-purple-pink-large.simple-filter.lossy.webp -o tmp.pgm && convert tmp.pgm blue-purple-pink-large.simple-filter.lossy.webp.ycbcr.png && rm tmp.pgm
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/106230044
This change seems to restore performance to
the level before CL 108140045.
benchmark old ns/op new ns/op delta
BenchmarkDecodeVP8SimpleFilter 796416 784394 -1.51%
BenchmarkDecodeVP8NormalFilter 4931138 4693078 -4.83%
BenchmarkDecodeVP8L 7820030 7821796 +0.02%
LGTM=nigeltao, r
R=nigeltao, r
CC=golang-codereviews
https://golang.org/cl/107340047
The benchmarks are a little slower, but the code is shorter.
benchmark old ns/op new ns/op delta
BenchmarkDecodeVP8SimpleFilter 621950 644184 +3.57%
BenchmarkDecodeVP8NormalFilter 4045745 4269431 +5.53%
LGTM=r
R=r, minux, ruiu
CC=golang-codereviews
https://golang.org/cl/108140045
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
code.google.com/p/vp8-go
This is a straight copy, followed by import path updates.
LGTM=r
R=r, mirtchovski, oleku.konko
CC=golang-codereviews
https://golang.org/cl/79320043
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
