WebP lossless decoding performance, two times slower than PNG ?

[Rodrigo Benenson]

tl;dr reading the same images in webp is twice as slow as in png, why ?

Dear WebP community,

I currently have a speed critical piece of code that I am trying to optimize.

(related to post http://stackoverflow.com/questions/16610318 )

The pixels processing side is now fast enough to make the disk I/O the core bottleneck.

I have just implemented a test where I replace my image reading module from png images, to reading a sequence of webp images.

The ~1000 png images take 350 Mb of disk, while the equivalent webp images take only 214 Mb.

I used "cwebp  -preset photo -lossless", because I should not have compression artifacts in my input images, and the images are photos.

Based on the table 3 of https://developers.google.com/speed/webp/docs/webp_lossless_alpha_study I expected the WebP decoding to be faster or comparable to PNG.

Having less bits to read from disk and faster decoding, I expected to see a gain in speed overall.

My current results are: reading the same images is twice as slow using webp rather than png.

I have validated this on two different machines (a work station and a high end laptop with SSD), obtaining the similar results.

Both versions are single core, sequential "read and decode".

I have tried to inspect if my PNG code (based on boost gil io extension) is reading the disk in a "smart way", however it seems to pass the file descriptor directly to libpng.

On the webp side I have implemented the file reading using ifstream, fread, and mmap, without obtaining a significant difference overall.

http://lemire.me/blog/archives/2012/06/26/which-is-fastest-read-fread-ifstream-or-mmap/#comments

I am using the precompiled library binaries from the webp website (linux, 64 bits) to be comparable with the .deb packages for libpng (recompiling webp with -O3 and -arch=native would give an unfair advantage).  

Does anyone have an idea of what is going on ?

Should I convert the png files in a special way to webp to still enjoy the speed gain ?

Thank you very much for your comments and suggestions.

Regards,

rodrigob.

[Rodrigo Benenson]

I do not know if it matters, I am reading my images using WebPGetInfo (to get the image size), followed by WebPDecodeRGBInto (to avoid unnecessary image copies).

regards,

rodrigob.

[oX Triangle]

try cwebp -mt -q 100
instead of lossless

[Pascal Massimino]

Rodrigo,

On Wed, Jun 12, 2013 at 11:56 AM, Rodrigo Benenson <rodrigo....@gmail.com> wrote:

I do not know if it matters, I am reading my images using WebPGetInfo (to get the image size), followed by WebPDecodeRGBInto (to avoid unnecessary image copies).

Calling WebPDecodeRGBInto() implies the extra step of dropping the transparency information (which is always present in lossless mode).

Could you try calling WebPDecodeRGBAInto() instead? (don't forget to allocate 32bits/pixels, and no longer 24bits/pixel).

This would give an indication whether the extra RGBA32 -> RGB24 conversion step is costly or not.

Another test that would be useful to figure out the bottleneck: try to compress a (large) pure-black image in both PNG and WebP.

The decoding complexity should be the same for both cases (roughly). So you'd be left with measuring your system's speed

and not the decompression speed. Just in case.

hope it helps,

skal

regards,

rodrigob.

--
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...@webmproject.org.
To post to this group, send email to webp-d...@webmproject.org.
Visit this group at http://groups.google.com/a/webmproject.org/group/webp-discuss/?hl=en.
For more options, visit https://groups.google.com/a/webmproject.org/groups/opt_out.
 
 

[Rodrigo Benenson]

Thanks all for your feedback.

I have a hard time believing that dropping one image channel has any significant speed impact (unless very poorly implemented).

I did try "cwebp -mt -q 100", the files got significantly smaller (~2x), but decompression is not significantly faster (about 30% faster).

Notice however that -q 100 is _not_ equivalent to -lossless, and some minor artefacts might be introduced (as shown but the drastic file size change).

I have concluded my "quest for fast images reading" by posting my results at

http://stackoverflow.com/questions/16610318

you might find them interesting.

Out of the box, webp is _not_ faster than png. 

Webp images are clearly more compact, but you pay the price at decoding time.

I wonder where did the table 3 of https://developers.google.com/speed/webp/docs/webp_lossless_alpha_study came from, but I cannot reproduce such results.

Thanks again skal and oX for your suggestions..

Regards,

rodrigob.

[Jyrki Alakuijala]

Rodrigo,

Thank you for reporting your conclusions about decoding speed. This is very helpful!

In https://developers.google.com/speed/webp/docs/webp_lossless_alpha_study I used ImageMagick convert vs cwebp. I didn't compile convert myself, but used it as it was installed on my Ubuntu distro. Either compilation options or the internals of convert seem to have been unfair for png decoding speed. My colleague Pascal Massimino developed a benchmark that uses the library interfaces directly for both libpng and libwebp, and it gives similar results to what you report.

For a photographic image I clocked 38 MB/s (WebP) vs. 78 MB/s (PNG). Graphical images are about the same speed with WebP and PNG, ranging from 150 MB/s to 600 MB/s and WebP being often slightly (just a few percent) faster, possibly because its backward references are always 4-byte-aligned in memory.

Inspired by your findings I'm working on speeding up the decoder so that we could perhaps close this performance gap for the photographic and other high entropy images.

best regards,

Jyrki

[Rodrigo Benenson]

> Thank you for reporting your conclusions about decoding speed. This is very helpful!

Well, now thank _you_ for giving such interesting details.

>My colleague Pascal Massimino developed a benchmark that uses the library
> interfaces directly for both libpng and libwebp, and it gives similar
> results to what you report.

This reassures me.

> Inspired by your findings I'm working on speeding up the decoder so that we
> could perhaps close this performance gap for the photographic and other high
> entropy images.

Well thanks for the hard work of the WebP team.
Trying to make "the best image file format ever" is not a small task.
Already obtaining such great compression rates is no small feat.
Also having top decoding speed would make it a "flawless format".

Best regards,
rodrigob.

> --
> You received this message because you are subscribed to a topic in the

> Google Groups "WebP Discussion" group.

> To unsubscribe from this topic, visit
> https://groups.google.com/a/webmproject.org/d/topic/webp-discuss/FPOfZs2cCS4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> webp-discuss...@webmproject.org.
> To post to this group, send email to webp-d...@webmproject.org.
> Visit this group at

> http://groups.google.com/a/webmproject.org/group/webp-discuss/.

[oX Triangle]

which PNG compressionlevel u use? 0-9?

Am Mittwoch, 12. Juni 2013 20:52:25 UTC+2 schrieb Rodrigo Benenson:

[Rodrigo Benenson]

how can I check a posteriori ?

File were created using opencv "default values".

regards,
rodrigob.

[oX Triangle]

For PNG, it can be thecompression level ( CV_IMWRITE_PNG_COMPRESSION ) from 0 to 9.

Am Mittwoch, 12. Juni 2013 20:52:25 UTC+2 schrieb Rodrigo Benenson:

[Jyrki Alakuijala]

I used pngout (best of -f5 and -f0 runs) to compress the pngs for all my decoding speed tests (should have used ZopfliPNG now). My experience is that the higher the compression level, the faster the decoding is. However, the change in decoding speed for compression level is typically <3 %, not 50+ % like we see here.

[Pascal Massimino]

Hi,

On Mon, Jun 17, 2013 at 1:57 PM, Rodrigo Benenson <rodrigo....@gmail.com> wrote:

> Thank you for reporting your conclusions about decoding speed. This is very helpful!

Well, now thank _you_ for giving such interesting details.

>My colleague Pascal Massimino developed a benchmark that uses the library
> interfaces directly for both libpng and libwebp, and it gives similar
> results to what you report.

This reassures me.

Actually, this whole discussion triggered remembrance of an optimization that we had in store

but that was left untuned. Well, here it is, merged in the HEAD tree (not in 0.3.1. Too fresh for that).

-> https://gerrit.chromium.org/gerrit/#/c/59389/

Speed-up may vary depending on source's type (photo or graphics), but is on average 20%.

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...@webmproject.org.

[Rodrigo Benenson]

Cool !
I am glad opening this thread has such an effect.
20% faster is great, but that would still not match PNG's speed.

Regards,
rodrigob.

[oX Triangle]

VP8/9 possible hardware acceleration

http://www.tomsguide.com/us/hardware-acceleration-Google-WebM,news-9723.html

png stay by software speed...

[Pascal Massimino]

Hi,

On Thu, Jun 20, 2013 at 9:20 AM, Rodrigo Benenson <rodrigo....@gmail.com> wrote:

Cool !
I am glad opening this thread has such an effect.
20% faster is great, but that would still not match PNG's speed.

https://gerrit.chromium.org/gerrit/#/c/59716/ should help further in that direction :)

[geo...@visby.io]

Hi Ricardo,

I came across your study for fast image reading in stackoverflow, and found it very helpful. I'm trying to get a speedup as well, and would want to try loading the images from an uncompressed tar as well.

You mentioned you used custom code:

Please note that I used custom code to read the images in the tar file, the file is read from disk "image by image".

Do you still have that code by any chance, and if so, would you mind sharing it with me? 

Thank you very much,

george 

[Jyrki Alakuijala]

The scenarios related to decoding speed are complex. In many scenarios, lossless decodes faster, but not always. Near-losslesss decodes faster than lossless. Delta palettization or palettized lossless decode even faster than -near_lossless.

These are the rough numbers, you may want to benchmark with your own data.

1. lossless noisy photograph 50 MB/s

2. near_lossless noisy photograph 100 MB/s

3. lossy photograph 150 MB/s

4. lossless graphics, photos without noise 150 MB/s, (up to ~600 MB/s for simpler graphics)

5. near_lossless graphics, photos without noise 200 MB/s, (up to ~600 MB/s for simpler graphics)

6. 8 bit delta palettization for photograph 300 MB/s (delta palettization is an experimental option in the lossless encoder, but supported by the normal decoder)

7. 8 bit palettization for photograph 350 MB/s. WebP encoders do not contain a palettization algorithm, so you may want to use another program for that first. WebP lossless encoder chooses typically (but not always) the palette mode if there are less than or equal to 256 unique RGBA combinations in the image.

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.

[Rodrigo Benenson]

> Do you still have that code by any chance, and if so, would you mind sharing it with me? 

No code available anymore. 

But it was just a custom tar file reader based on the tar file definition; nothing too fancy.

Should not be too hard to implement on your own (if you are comfortable playing with  bytes in files)

regards,

rodrigob.

[Luke Taylor]

Out of interest, did any optimisation of webp encoding/decoding speed come out of this conversation? Is it still the case that encoding/decoding webp is slower than png for photograph-like images? Does running on a modern cpu in 2023 change the situation?