WebP encoding performance

[Yoav]

Hi,

I've conducted some naïve benchmarking of PNG24->WebP vs. PNG24->JPG
encoding times, where I used ImageMagick to perform the JPG
conversion.
I observed that WebP conversion seems to be 4-5 times slower than JPG
conversion.
I have a few questions regarding that:
* Are there any official encoding performance benchmark numbers?
* Are there any planned encoding speed optimization efforts in the
near future?
* Is there an option to compile WebP only to latest processors using
SSE4 Intel processor instructions in order to improve speed?
* What is WebP's algorithmic performance goal? Is it possible that it
will reach JPG encoding speed in the future?

Thanks!
Yoav

[Pascal Massimino]

Hi Yoav,

Some remarks:

On Tue, Jan 3, 2012 at 3:05 AM, Yoav <yoav.w...@gmail.com> wrote:

Hi,

I've conducted some naïve benchmarking of PNG24->WebP vs. PNG24->JPG
encoding times, where I used ImageMagick to perform the JPG
conversion.
I observed that WebP conversion seems to be 4-5 times slower than JPG
conversion.

I guess it's with default settings. There is a '-m' option in cwebp to control

a little the trade-off between speed and compression quality. Not sure about

the equivalent in ImageMagick.

Also: Imagemagick is using RGB internally, not YUV. In some application

cases (like direct JPEG <-> WebP recoding scenario), one can stay in

YUV(J) color space and avoid the (rather expensive) transform.

I have a few questions regarding that:
* Are there any official encoding performance benchmark numbers?

4-5x slower is about correct order. Decoding is more on the 2x-3x range.

cwebp/dwebp are instrumented to report raw timing info when using the '-v' option.

  

* Are there any planned encoding speed optimization efforts in the
near future?

Yes, especially on ARM platforms. Regarding SSE2, there are still

few functions that could be optimized. It's pretty easy/fun to do with

intrinsics.

There's also some unfinished higher-level attempt at reducing (or shortening)

the number of analysis passes done during encoding. For instance: using

more memory for storing coefficients token (while the optimal distribution

of probabilities is being recorded) and avoid re-doing the last pass. Pretty

much like libvpx is doing.

Parallel multithreaded analysis pass could be useful, too.

 

* Is there an option to compile WebP only to latest processors using
SSE4 Intel processor instructions in order to improve speed?

SSE4 instructions are likely not bringing much compared to SSE2.

The default is to compile libwebp with SSE2 enabled, as detected during

./configure. I guess that's what ImageMagick is using.

* What is WebP's algorithmic performance goal? Is it possible that it
will reach JPG encoding speed in the future?

Probably not JPEG speed. JPEG has very few encoding decisions to make,

where VP8 has a lot of possible prediction modes to try for each macroblocks.

Still, some heuristics are possible, to cut the complexity. Also, due to the smaller

4x4 transform, overhead is a bigger fixed cost.

I'd say 2.5x-4x slower encoding with reasonable settings (that is: still providing better compression)

is achievable...

hope it helps...

skal

Thanks!
Yoav

--
You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
To post to this group, send email to webp-d...@webmproject.org.
To unsubscribe from this group, send email to webp-discuss...@webmproject.org.
For more options, visit this group at http://groups.google.com/a/webmproject.org/group/webp-discuss/?hl=en.