I think it reads better that way.
Change-Id: I770fdb6362d2a281f7c62cabade186725daced9b
Reviewed-on: https://go-review.googlesource.com/7714
Reviewed-by: Rob Pike <r@golang.org>
These code paths aren't actually fast yet. That will be a follow-up
change.
Change-Id: I814992573cc6af422e49d0ddf336003e662897a5
Reviewed-on: https://go-review.googlesource.com/7791
Reviewed-by: Rob Pike <r@golang.org>
See golang.org/cl/4131 for context.
Change-Id: If30a8f22fe02ef58e94ee3c90afc065d9cd954d0
Reviewed-on: https://go-review.googlesource.com/7723
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Before/after:
$ go test
PASS
ok golang.org/x/image/draw 1.173s
$ go test
PASS
ok golang.org/x/image/draw 0.225s
Change-Id: I5b4742f045870db9353da1d85b0677be992cb347
Reviewed-on: https://go-review.googlesource.com/7712
Reviewed-by: Rob Pike <r@golang.org>
Also fix the NN and ABL fast paths to only apply if we can access the
Pix elements without src-bounds checking.
Change-Id: Ie9fc96b28e0665df49d00c4c53cb81385faee4db
Reviewed-on: https://go-review.googlesource.com/7675
Reviewed-by: Rob Pike <r@golang.org>
I simply forgot to do this in the previous change.
Change-Id: I0ea5d6bb0a09154cb995a665476ffceb155bd49e
Reviewed-on: https://go-review.googlesource.com/7651
Reviewed-by: Rob Pike <r@golang.org>
Just stub implementations for now. Actual implementations will be
follow-up changes.
Change-Id: Id21d9042a2073c2dc0f78c9977c4940f000a41df
Reviewed-on: https://go-review.googlesource.com/6805
Reviewed-by: Rob Pike <r@golang.org>
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
