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

High compression ratio mode for lossless WebP #2221

Open
Shnatsel opened this issue Apr 30, 2024 · 2 comments
Open

High compression ratio mode for lossless WebP #2221

Shnatsel opened this issue Apr 30, 2024 · 2 comments

Comments

@Shnatsel
Copy link
Contributor

WebP remains the lossless format with the highest compression ratio that is widely adopted.

"Lossless" AVIF is not truly lossless due to the use of a custom non-RGB colorspace, conversion into which loses some data, while JPEG XL is still far from widespread adoption.

#1978 has added support for writing lossless WebP. While the current code is fast, the compression ratio is not very high.

It would be great to implement more compression strategies from libwebp, and provide an option to use them and trade some CPU time for actually utilizing the high compression ratio the format can provide.

@fintelia
Copy link
Contributor

fintelia commented May 1, 2024

To be clear "not very high" is relative to what WebP is capable of. I just did a quick benchmark using the image from image-rs/image-webp#71. I converted the image to lossless form so everything would be using an identical baseline and then compressed with a bunch of different encoders:

Compression Ratio Time Encoder
51% 0.2 seconds image-png (fast)
45% 11 seconds image-png (best)
42% 24 seconds oxipng
38% 0.2 seconds image-webp
32% 14 seconds cwebp (default lossless settings)

Of course, using only a single image doesn't tell the whole story. image-webp's hard-coded encoding parameters make it vulnerable to edge cases and so forth, but it shows that the encoder is overall quite respectable.

@fintelia
Copy link
Contributor

fintelia commented May 1, 2024

The key change needed to achieve higher compression is to sweep over compression parameters and select the set that produces the best output. libwebp uses various heuristics that cut down on the number of candidate parameter options to pick from, so that's probably worth looking into. Heuristics are particularly important for the faster compression settings that don't have time to consider all the options

As far as changes to the encoder itself, the biggest is probably added support for varying the huffman codes used across the image. Since storing the huffman trees takes up space, you have to bin regions of the image that have similar entropy distributions to reduce the total number of trees used. At the moment I don't fully understand this process for deciding which regions should share the same codes

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

No branches or pull requests

2 participants