image-webp
image-webp copied to clipboard
image-rs
Decoding this file with `image-webp` is 1.8x slower than `dwebp -noasm -nofancy`: [Puente_de_Don_Luis_I,_Oporto,_Portugal,_2019-06-02,_DD_29-31_HDR.webp.gz](https://github.com/image-rs/image-webp/files/15171492/Puente_de_Don_Luis_I._Oporto._Portugal._2019-06-02._DD_29-31_HDR.webp.gz) ([source: wikipedia](https://commons.wikimedia.org/wiki/Commons:Picture_of_the_day#/media/File:Puente_de_Don_Luis_I,_Oporto,_Portugal,_2019-06-02,_DD_29-31_HDR.jpg), converted to lossy WebP using `imagemagick`) Profiling with `samply` shows [`image_webp::vp8::BoolReader::read_bool`](https://github.com/image-rs/image-webp/blob/ef0a23f0581f915bd11ce1a2112aa22af0dcbdfc/src/vp8.rs#L702-L744) being responsible for 47%...
The current lossless webp decoding logic does a branch for almost every single _bit_ in the file: https://github.com/image-rs/image/blob/038bc30b9b9b1daf809452523b557db58f9e781b/src/codecs/webp/huffman.rs#L189-L192 Switching to a more efficient huffman implementation would likely be orders of...
We should audit the decoder to ensure it is properly enforcing memory limits.
In https://github.com/image-rs/image/issues/1872, @Shnatsel identified WebP images decoded improperly. We should test those images again and root-cause any differences found. If licenses are compatible, it would also be nice to add...
- Extract shared `clip` and `mulhi` functions outside of `Frame` member functions - Rearrange the order of clamping operations to enable better auto-vectorization - Remove no-op returning branch value in...
This changes a bunch of the decoding logic to operate on RGBA ordered byte slices rather than owned `Vec`'s with ARGB ordering.
A recent clippy lint suggests using clamp instead of manual clamping. However, using `Ord::clamp` produces worse vectorized code than the manual clamp. Prefer using manual clamps in loops and especially...
Track a couple changes we'll want to do in the next MSRV. Leaving this as draft because it'll be a while before 1.80 is old enough for us to drop...
In image v0.25.4 and image-webp v0.2.0, decoding the attached animated WebP is 4x slower than using `libwebp-sys` + `webp-animation`: [sample.zip](https://github.com/user-attachments/files/17482915/sample.zip) ### image ```rust use std::error::Error; use image::{codecs::webp::WebPDecoder, AnimationDecoder, ImageReader}; fn...
Part of the gap observed in #119 is due to `webp-animation` using multi-threading. `libwebp` also has a multi-threading option for still images. But right now `image-webp` is single-threaded. I think...