Tracking issue: Remove libwebp dependency

[fintelia]

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, the webp crate will continue to provide Rust bindings to libwebp. Switching should only be a couple lines of code:

fn encode_lossy_webp(img: DynamicImage, quality: f32) -> Vec<u8> {
    let img = img.to_rgba8();
    let (width, height) = img.dimensions();
    webp::Encoder::new(&*img, webp::PixelLayout::Rgba, width, height)
        .encode(quality)
        .to_vec()
}

[djc]

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?

[randomairborne]

I was also using lossy webp encoding, for the smaller encoding size compared to JPEG.

[fintelia]

Just added a code sample to the original post showing how to use the do lossy encoding by calling into the webp crate. I'd also be curious to hear whether anyone has experimented with AVIF and/or mozjpeg? Sources online claim that those options achieve as good or better size and quality to WebP

[djc]

We were looking at AVIF earlier, but it looks like browser support might not be quite where we'd want it to be.

https://caniuse.com/avif

[fintelia]

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)

[omid]

We also use lossy webp. Same reason as others said.

[bakhtiyarneyman]

We use lossy webp because it allows pages to load much faster.

[timleslie]

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

[schmitch]

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

[fintelia]

Thanks for the responses! It would be helpful to know whether the lossy encoding must be part of the image crate? If we go ahead with the planned removal, is there a reason the code snippet above would not be sufficient?

[randomairborne]

I think it would confuse people to have a partial implementation in image-rs. Not sure what others might think, though.

[Shnatsel]

I see two downsides to having the C libwebp around:

1. The risk of memory safety vulnerabilities due to inherently unsafe C code
2. More complicated build process (incl. cross-compilation)

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 image crate in general.

I think hiding libwebp dependency behind a non-default feature flag is sufficient. I figure exposing the lossy encoding interface through image might make it a little more convenient, but then there's the question of how to expose two different lossless encoders in a way that isn't a footgun.

[randomairborne]

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.

[neckaros]

Just added a code sample to the original post showing how to use the do lossy encoding by calling into the webp crate. I'd also be curious to hear whether anyone has experimented with AVIF and/or mozjpeg? Sources online claim that those options achieve as good or better size and quality to WebP

Doesn't AVIF also depends on C library libdav1d?

[fintelia]

Doesn't AVIF also depends on C library libdav1d?

AVIF encoding uses the Rust-based ravif library. Decoding does however require libdav1d.

[fintelia]

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

[randomairborne]

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.