Closed jamesbikes closed 8 years ago
I think the DecodeRGBA***
is the better name than DecodeScaled
,
same as DecodeRGBA
and DecodeGray
.
func DecodeRGBAToSize(data []byte, width, height int) (m *image.RGBA, err error);
then we can add simalir api for Gray and RGB:
func DecodeGrayToSize(data []byte, width, height int) (m *image.Gray, err error);
func DecodeRGBToSize(data []byte, width, height int) (m *RGBImage, err error);
Thanks for your work.
That sounds good to me. I made those updates, let me know what you think. Thanks!
Seems good to me.
some other suggest:
webpEncodeGray
(it use WebPEncodeRGB
), the best way is use YUV style encode API(may be in new PR).Thanks.
Thanks for the feedback. I made these changes. Also, in a separate commit, I added a large lossy image to better show the benchmark improvements. I don't know if you want to include such a large file in the repo.
The results on my machine are:
$ go test -bench photo_lossy
testing: warning: no tests to run
PASS
BenchmarkDecode_photo_lossy_chai2010_webp-8 20 89326742 ns/op
BenchmarkDecode_photo_lossy_x_image_webp-8 5 265046500 ns/op
BenchmarkDecode_photo_lossy_chai2010_webp_tosize-8 20 63967415 ns/op
ok github.com/chai2010/webp/bench 6.565s
We deployed this change to our production environment and are seeing even more dramatic improvements there, due to the elimination of a separate resize operation. For example, average times to resize this photo.lossy.webp
image to 256x192px dropped from about 900 ms to about 200 ms.
BTW, don't mind helping with webpEncodeGray
but would prefer to do that separately
Uses the advanced decoding API to scale an image while decoding. Saves a lot of memory and CPU time compared to decoding and then resizing.
Our use case: load original size WEBP -> resize -> encode to JPEG
Old method:
webp.Decode
->nfnt/resize
->jpeg.Encode
New method:
webp.DecodeScaled
->jpeg.Encode
Benchmarks, with source file 3264x2448px, output file 256x192px: