Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve WebP compression #5

Open
vrabaud opened this issue Sep 10, 2024 · 3 comments
Open

Improve WebP compression #5

vrabaud opened this issue Sep 10, 2024 · 3 comments

Comments

@vrabaud
Copy link

vrabaud commented Sep 10, 2024

Hi,

WebP maintainer here. Thank you for sharing https://purplesyringa.moe/blog/webp-the-webpage-compression-format/ !

There is something you might try to get even better compression: in lossless, the method goes from 0 to 6 and tries more and more approaches as the method increases. The wrongfully named quality, is basically how much you try the different algorithms.

But there is actually a special mode: for method 6 and quality 100, it is actually a cruncher mode that tries different methods all the way, and keep the smallest image. You might get the same results but it might be worth trying!

@purplesyringa
Copy link
Owner

Interesting! I noticed method 6 took a lot more time than 5, but didn't realize it's a cruncher.

To my surprise, method 6 + quality 100 gives worse results than method 5 + quality 100. Would this be considered a bug or does the cruncher not cover all permutations by design?

@vrabaud
Copy link
Author

vrabaud commented Sep 10, 2024

Well it does consider all permutations but it still has some early exits to still have a practical cruncher. Which might be wrong ... Usually, if they are wrong, it is not by much. If they are always better, it might be because you always deal with 1 x something images. Between 5 and 6, the only impact is here: https://github.com/webmproject/libwebp/blob/40e4ca60ea5bdd754195928f8bf6efe76b6f315d/src/enc/vp8l_enc.c#L237

Can you please attach the image where the different is the biggest ? I am curious now :)

@purplesyringa
Copy link
Owner

You're right, I had a small bug in my test suite. Indeed, most size increases are now on 1xN images only (not always 1 exactly, but a small integer anyway).

The largest absolute increase (586 bytes) is when compressing fireworks.jpeg (so basically an incompressible blob):

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants