search

purplesyringa / site

My website
https://purplesyringa.moe/
20 stars 3 forks source link

Improve WebP compression #5

Open vrabaud opened 1 week ago

vrabaud commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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):