This means that only Kernel values have a NewScaler method, which
re-uses computation when scaling multiple images of the same dst and src
dimensions. The NearestNeighbor and ApproxBiLinear scalers don't get any
pre-computation to re-use, so don't need a NewScaler method just to
satisfy the previous Interpolator interface. As a small bonus, NN.Scale
and ABL.Scale should no longer allocate on the fast paths.
This change is consistent the upcoming Transformer method, so that the
Interpolator interface will be
type Interpolator interface {
Scale(etc)
Transform(etc)
}
instead of
type Interpolator interface {
NewScaler(etc) Scaler
Transform(etc)
}
I don't have a good theory for why the "func (ablInterpolator)
scale_RGBA_RGBA" benchmark is such a dramatic improvement, but at least
it's in the right direction. I'm calling the other benchmark changes as
noise.
benchmark old ns/op new ns/op delta
BenchmarkScaleLargeDownNN 3233406 3169060 -1.99%
BenchmarkScaleLargeDownAB 12018178 12011348 -0.06%
BenchmarkScaleLargeDownBL 1420827834 1409335695 -0.81%
BenchmarkScaleLargeDownCR 2820669690 2795534035 -0.89%
BenchmarkScaleDownNN 866628 869241 +0.30%
BenchmarkScaleDownAB 3175963 3216041 +1.26%
BenchmarkScaleDownBL 26639767 26677003 +0.14%
BenchmarkScaleDownCR 51720996 51621628 -0.19%
BenchmarkScaleUpNN 42758485 43258611 +1.17%
BenchmarkScaleUpAB 156693813 156943367 +0.16%
BenchmarkScaleUpBL 69511444 69621698 +0.16%
BenchmarkScaleUpCR 124530191 124885601 +0.29%
BenchmarkScaleSrcGray 8992205 9129321 +1.52%
BenchmarkScaleSrcNRGBA 9807837 9894466 +0.88%
BenchmarkScaleSrcRGBA 1333188 1104282 -17.17%
BenchmarkScaleSrcUniform 1147788 1162488 +1.28%
BenchmarkScaleSrcYCbCr 12164542 12305373 +1.16%
Change-Id: I2aee6c392eb7437e843260775aed97ce145b4d47
Reviewed-on: https://go-review.googlesource.com/6556
Reviewed-by: Rob Pike <r@golang.org>
This will lessen the diff in a follow-up change.
Change-Id: I67257b935e4b5fc6fcc462c83910a3f09f26702f
Reviewed-on: https://go-review.googlesource.com/6554
Reviewed-by: David Symonds <dsymonds@golang.org>
Optimizing this code path will be follow-up changes.
Change-Id: Ifece6c7d3685bb8f2d20cf8828a121c9ff346434
Reviewed-on: https://go-review.googlesource.com/6238
Reviewed-by: Rob Pike <r@golang.org>
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
