optimize webp encoding times?

1,443 views
Skip to first unread message

Yonatan Dorman

unread,
Dec 20, 2015, 8:27:44 AM12/20/15
to WebP Discussion
Hello,

I'm considering webp as a compression format for radiology images.
I did a very basic benchmark - tried to encode a bulk of images as both lossy & lossless, comparing to the default encoding algorithm of .Net (to JPEG and PNG).
The results look promising on the compression side (up to 50% on some images), however encoding times are very slow - x5 slower on lossy, x10 for lossless compression.
For lossy I'm using compression quality of 85 (as it yields similar PSNR result to that of the default .Net JPEG encoding).
For the webp compression I used the basic API's WebPEncodeRGB and WebPEncodeLosslessRGB.
Also tried to encode with cwebp -v, to make sure nothing is wrong with my measurements, and it produces similar results.

Some web resources (mostly from 2012) indicate this was the original encoding performance of webp.
I'm wondering if any there were any improvements since then.
Is there any way to optimize encoding times so they match up to other compression algorithms?

Any help will be appreciated!

Yonatan

Pascal Massimino

unread,
Dec 22, 2015, 7:40:18 AM12/22/15
to WebP Discussion
Hi Yonatan,

On Sun, Dec 20, 2015 at 2:27 PM, Yonatan Dorman <ydo...@gmail.com> wrote:
Hello,

I'm considering webp as a compression format for radiology images.
I did a very basic benchmark - tried to encode a bulk of images as both lossy & lossless, comparing to the default encoding algorithm of .Net (to JPEG and PNG).
The results look promising on the compression side (up to 50% on some images),

Great!
 
however encoding times are very slow - x5 slower on lossy, x10 for lossless compression.

That's not unusual ratio, indeed.
 
For lossy I'm using compression quality of 85 (as it yields similar PSNR result to that of the default .Net JPEG encoding).
For the webp compression I used the basic API's WebPEncodeRGB and WebPEncodeLosslessRGB.
Also tried to encode with cwebp -v, to make sure nothing is wrong with my measurements, and it produces similar results.

Some web resources (mostly from 2012) indicate this was the original encoding performance of webp.
I'm wondering if any there were any improvements since then.
Is there any way to optimize encoding times so they match up to other compression algorithms?

Over the various releases, WebP has indeed improved in speed. I'd recommend sticking to the latest release [1], or even better
to the latest code in the git repository.

That being said, you might try some alternative compression options:
  * multithreading ('cwebp -mt ...') might help
  * using a lower 'method' setting. For instance: "cwebp -m 3 ...". These methods are designed to change the speed/compression trade-off
    during encoding. The default is method 4 (-m 4). By using method 3, you will get faster encoding, albeit with potentially fewer compression.
  * For *lossless* encoding, you may try to change the 'quality', in addition to the method. For instance, using -q 25 or -q 30 may yield some
     speed-up, again at the expense of lower compression efficiency. Of course, the result remains lossless, it's just the speed/file-size trade-off
     which is changed.

All these options have their equivalent in the 'advanced' encoding API (that uses the WebPConfig). See [2].
 
hope it helps,
skal/


Reply all
Reply to author
Forward
0 new messages