WebP Decoding Performance on Android

[rdcoo...@gmail.com]

Hi,

I work on Android app that displays a lot of images.  We are looking at moving from jpg to webP.  Years ago a developer who is no longer with the company did an investigation into converting and found that webP took significantly longer to decode, enough so that jpg was clearly the better decision.  I intend to do my own profiling next week but I wanted to reach out to the community to see if this is a known issue that has been fixed, possibly the result of profiling or anything else I should be aware of before I go into profiling to see if webP will work better for our app.

Thanks,

-Ryan

[Jyrki Alakuijala]

Profiling decoding is a very complex topic. Here some ideas on it:

Images compressed with lower quality decode faster -- to be able to profile decoding one has to first find out what constitutes the same quality level for an application. In my experience webp lossy has lower quality in the higher range of quality settings and a better quality at the lowest range, i.e., to match jpeg quality 85 you might need webp lossy quality 90, but to match jpeg quality 30 you might be ok with webp quality 20. These differences can have a significant effect on decoding speed.

WebP allows for two new ways of encoding, webp near lossless and delta palettization. The near losslessly compressed images decode faster than full lossless, and are often 30-40 % smaller -- and the quality remains still much higher than with WebP lossy. The more experimental 'delta palette' mode only allows for non-alpha images to be compressed. They are more bloated than WebP lossy, but have typically less compression artefacts and decode twice as fast. Delta palettization is likely not worth your time to test, but near lossless might be.

Last, there is a new really slow jpeg encoder for high quality images, guetzli. When you compare WebP images against jpeg you might try with guetzli -- it generates jpegs that can be 30 % smaller than respective quality images with other methods (such as mozjpeg and libjpeg). Also, guetzli generates non-progressive jpegs, i.e., they decode really fast. Guetzli itself is hideously slow in encoding, but the resulting jpegs decode about 30 % faster than jpegs of respective quality non-progressive jpegs generated with other means -- and possibly 2-3x faster than progressive jpegs. Guetzli is available at https://github.com/google/guetzli

--
You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss+unsubscribe@webmproject.org.
To post to this group, send email to webp-d...@webmproject.org.
Visit this group at https://groups.google.com/a/webmproject.org/group/webp-discuss/.
For more options, visit https://groups.google.com/a/webmproject.org/d/optout.

[Pascal Massimino]

Hi Ryan,

On Fri, Feb 3, 2017 at 10:51 PM, <rdcoo...@gmail.com> wrote:

Hi,

I work on Android app that displays a lot of images.  We are looking at moving from jpg to webP.  Years ago a developer who is no longer with the company did an investigation into converting and found that webP took significantly longer to decode, enough so that jpg was clearly the better decision.  I intend to do my own profiling next week but I wanted to reach out to the community to see if this is a known issue that has been fixed, possibly the result of profiling or anything else I should be aware of before I go into profiling to see if webP will work better for our app.

there's a lot of moving parts here: are you using 'lossy' compression (i assume yes)? which target architecture? (v7a? v8a? arm64?)

The jpg library used will matter too, of course.

Anyway, i've whipped out a crude script to test the decoding speed of various release, on any set of pictures you're willing

to test. See attachment.

The script to run is 'run_me.sh', it's pretty simple and basic, and i encourage you to read the sources before running it.

On a set of lossy pictures, here are the timings i got (ndk13, on a Galaxy Nexus).

 version 0.4.1 Elapsed: 20471.04 ms
 version 0.4.2 Elapsed: 20367.74 ms
 version 0.4.3 Elapsed: 20405.24 ms
 version 0.4.4 Elapsed: 20380.01 ms
 version 0.5.0 Elapsed: 16082.58 ms
 version 0.5.1 Elapsed: 16037.20 ms
 version 0.5.2 Elapsed: 15958.59 ms
 version 0.6.0 Elapsed: 13795.35 ms

YMMV. Not sure at which version you tested last time, but you get an idea of the

speed evolution along successive releases.

Feel free to hack the script further!

hope it helps,

skal/

[Pascal Massimino]

Hi Ryan,

On Sat, Feb 4, 2017 at 12:39 PM, Pascal Massimino <pascal.m...@gmail.com> wrote:

Hi Ryan,

On Fri, Feb 3, 2017 at 10:51 PM, <rdcoo...@gmail.com> wrote:

Hi,

I work on Android app that displays a lot of images.  We are looking at moving from jpg to webP.  Years ago a developer who is no longer with the company did an investigation into converting and found that webP took significantly longer to decode, enough so that jpg was clearly the better decision.  I intend to do my own profiling next week but I wanted to reach out to the community to see if this is a known issue that has been fixed, possibly the result of profiling or anything else I should be aware of before I go into profiling to see if webP will work better for our app.

there's a lot of moving parts here: are you using 'lossy' compression (i assume yes)? which target architecture? (v7a? v8a? arm64?)

The jpg library used will matter too, of course.

Anyway, i've whipped out a crude script to test the decoding speed of various release, on any set of pictures you're willing

to test. See attachment.

Sorry, there was a problem with the patch in the previous script.

The new 002 archive attached should be better.

skal/

[rdcoo...@gmail.com]

Hi Skal + jyrki,

Thanks for the answers!  This is super interesting, haven't tried the script yet, but will be looking into it in a day or two.

-Ryan

[Pascal Massimino]

Ryan,

On Sun, Feb 5, 2017 at 10:46 AM, Pascal Massimino <pascal.m...@gmail.com> wrote:

Hi Ryan,

On Sat, Feb 4, 2017 at 12:39 PM, Pascal Massimino <pascal.m...@gmail.com> wrote:

Hi Ryan,

On Fri, Feb 3, 2017 at 10:51 PM, <rdcoo...@gmail.com> wrote:

Hi,

I work on Android app that displays a lot of images.  We are looking at moving from jpg to webP.  Years ago a developer who is no longer with the company did an investigation into converting and found that webP took significantly longer to decode, enough so that jpg was clearly the better decision.  I intend to do my own profiling next week but I wanted to reach out to the community to see if this is a known issue that has been fixed, possibly the result of profiling or anything else I should be aware of before I go into profiling to see if webP will work better for our app.

there's a lot of moving parts here: are you using 'lossy' compression (i assume yes)? which target architecture? (v7a? v8a? arm64?)

The jpg library used will matter too, of course.

Anyway, i've whipped out a crude script to test the decoding speed of various release, on any set of pictures you're willing

to test. See attachment.

Sorry, there was a problem with the patch in the previous script.

The new 002 archive attached should be better.

For simplicity, i've set up the sub-directory:

  https://github.com/webmproject/libwebp-demo/tree/master/android_webp_test

as part of the libwebp-demo github.

This directory contains an infrequently updated version of the script, the latest assembled archive [1], and some minimal doc.

Thanks for starting this discussion, it was a great reminder about the usefulness of having such measurement tools be made public!

hope it helps,

skal

[1] https://github.com/webmproject/libwebp-demo/blob/master/android_webp_test/android_webp_test_003.tar.gz