-
Notifications
You must be signed in to change notification settings - Fork 2
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
Comments
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? |
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 Can you please attach the image where the different is the biggest ? I am curious now :) |
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): |
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 namedquality
, is basically how much you try the different algorithms.But there is actually a special mode: for
method
6 andquality
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!The text was updated successfully, but these errors were encountered: