WebP encode and decode performance compared to JPEG and PNG

[Shogo Sensui]

WebP's slower performance about encode and decode compared to other image formats 

was mentioned on a session some years ago. How about this for now?

As the study implicated improvements on encoding and decoding, 

don't we need to care about WebP (en|de)coding cost and performance?

[Jai Krishnan]

Hi Shogo,

WebP lossy encode and decode have certainly improved since a few years ago. 

Pascal shared some information (and a script / tool for you to try yourself) about speed improvements in decode earlier this year. We'll look and see if there's additional data we can share publicly either as a study on the site or emailed to the list.

Thanks,

Jai

--
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 https://groups.google.com/a/webmproject.org/group/webp-discuss/.
For more options, visit https://groups.google.com/a/webmproject.org/d/optout.

[Vincent Rabaud]

Hi Shogo,

you are totally right: a good codec is about finding the right trade-off between many factors: not only compression ratio but also (en|de)coding speed, RAM, features, support ...

As you noticed, I recently updated the lossless study to reflect the improvements made in the past 5 years in lossless compression speed and ratio. Those happened continuously over time and were algorithmic improvements, C improvements, platform tuning (like SSE and NEON) and specialization for certain kinds of images (binary, low number of colors ...).

As Jai mentioned, it's not always easy to provide clear benchmarks and datasets, especially with the growing list of JPEG/PNG encoders. That's why we also release tools to see how WebP is being used (like https://github.com/webmproject/webp-highlighter) and make sure it is easily usable with the latest needs in image compression (e.g. for Android APK generation as detailed in https://developer.android.com/studio/write/convert-webp.html).

On Sun, Aug 20, 2017 at 9:11 AM, 'Jai Krishnan' via WebP Discussion <webp-d...@webmproject.org> wrote:

Hi Shogo,

WebP lossy encode and decode have certainly improved since a few years ago. 

Pascal shared some information (and a script / tool for you to try yourself) about speed improvements in decode earlier this year. We'll look and see if there's additional data we can share publicly either as a study on the site or emailed to the list.

Thanks,

Jai

On Sat, Aug 19, 2017 at 11:50 PM Shogo Sensui <shogo....@gmail.com> wrote:

WebP's slower performance about encode and decode compared to other image formats 

was mentioned on a session some years ago. How about this for now?

As the study implicated improvements on encoding and decoding, 

don't we need to care about WebP (en|de)coding cost and performance?

--
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.

--

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.