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
Tracking issue: Remove libwebp dependency #1984
Comments
We (as the original contributors of WebP encoding support) would be disappointed to see a removal of lossy WebP encoding support. We're using lossy WebP support exactly because we feel it provides a good trade-off between image size and quality, whereas lossless WebP images do not seem to do as well on that particular trade-off. Maybe the C-based WebP encoding support could be retained for lossy encoding only? |
I was also using lossy webp encoding, for the smaller encoding size compared to JPEG. |
Just added a code sample to the original post showing how to use the do lossy encoding by calling into the |
We were looking at AVIF earlier, but it looks like browser support might not be quite where we'd want it to be. |
Oh, thanks for sharing that! Looks like the last holdout is Edge, which is getting support in version 121 and should be released in about two weeks (then it's just however long it takes for people to upgrade from older versions) |
We also use lossy webp. Same reason as others said. |
We use lossy webp because it allows pages to load much faster. |
We use lossy webp as a carefully considered tradeoff between image size and image quality (in a context where this trade-off is of significant financial importance). |
we also use the lossy encoding since we create preview pictures from pdf files and we do not need high image quality and more like "good enough" quality with a small size |
Thanks for the responses! It would be helpful to know whether the lossy encoding must be part of the |
I think it would confuse people to have a partial implementation in image-rs. Not sure what others might think, though. |
I see two downsides to having the C libwebp around:
I am not particularly concerned about CVEs in the encoding step. Historically it has proven much easier to get right than decoding. The hassle of dealing with C dependencies, however, is very real, and bites you before you even touch WebP - it blocks access to installing the I think hiding |
Unfortunately, as long as rust libwebp is incomplete, keeping libwebp around is kind of unavoidable. It at the very least needs to be documented that the rust encode function is always lossless. |
Doesn't AVIF also depends on C library libdav1d? |
AVIF encoding uses the Rust-based ravif library. Decoding does however require libdav1d. |
I'm going to go ahead and close this now that 0.25.0 is released. There is a place in the Rust ecosystem for a crate that simply provides safe wrappers around the C/C++ reference implementations of all the image formats. However, that has never been the goal of this crate or the broader image-rs org. From the discussion, it sounds like a pure-Rust lossy WebP implementation wouldn't actually be a suitable replacement in current use cases unless it were able to achieve compression ratios on-par or better than libwebp. But perfect feature parity isn't the criteria we use for other codecs, and I don't think it can be the standard we use to decide when to drop a native dependency either |
I would argue that we aren't really looking for "perfect feature parity", just something that allows the format to work as advertised- which is with high compression ratios. |
Now that a pure-Rust encoder implementation is being added in #1978, we're planning on removing usage of
libwebp
which is written in C.Our encoder is very fast, but lacks support for writing lossy files and the output files it produces generally aren't quite as small. If you are relying on one of those features, please comment on this issue to explain your use case!
Note: regardless of changes to the
image
crate, thewebp
crate will continue to provide Rust bindings tolibwebp
. Switching should only be a couple lines of code:The text was updated successfully, but these errors were encountered: