# image v0.25: performance improvements, production-ready WebP

The [`image`](https://crates.io/crates/image) crate, Rust's most popular image handling library, is out with a new release! It brings speedups and other enhancements for a variety of image formats.

## JPEG

This release switches from [`jpeg-decoder`](https://crates.io/crates/jpeg-decoder) to [`zune-jpeg`](https://crates.io/crates/zune-jpeg) crate for decoding JPEG images. This brings a **massive performance improvement.**

[`zune-jpeg`](https://crates.io/crates/zune-jpeg)'s performance is on par with [`libjpeg-turbo`](https://libjpeg-turbo.org/), an extensively optimized library that has more assembly in it than C. Matching that performance in pure Rust is an outstanding achievement!

Because of this change, the obscure "lossless JPEG" format used almost exclusively in medical imaging is no longer supported. If you need to handle lossless JPEG, we recommend using [`jpeg-decoder`](https://crates.io/crates/jpeg-decoder) directly.

This change also allows proper support for memory limits. `jpeg-decoder` could allocate potentially unbounded amounts of memory, while `zune-jpeg` allows setting memory limits.

## PNG

The `png` crate has seen **performance improvements**, in large part thanks to the [ongoing effort to use it for PNG decoding in Chromium](https://github.com/image-rs/image-png/discussions/416).

To make it happen, the `png` crate needs to be not just as fast as [`libpng`](http://www.libpng.org/pub/png/libpng.html) (which is has been for a while), but also match the speed of Chromium's SIMD-optimized fork of `libpng`. We are making good progress and getting really close!

One of the optimizations (Paeth unfiltering for images without transparency) required explicit SIMD and could not be implemented with auto-vectorization. To avoid introducing `unsafe` code, it is implemented using the [Portable SIMD API](https://doc.rust-lang.org/stable/std/simd/index.html). Please use a nightly compiler and the `unstable` feature on the `png` crate if you need maximum performance.

## GIF

On top of performance improvements (yes, here too - and it was plenty fast already!), the API now allows decoding and encoding frames [in parallel](https://github.com/image-rs/image-gif/blob/master/examples/parallel.rs) in animated GIFs, letting you take performance to a whole new level.

This release also features lower memory usage, removes the last of `unsafe` code, and makes the API more friendly by making `Decoder` implement `Iterator` over frames, among [other enhancements](https://github.com/image-rs/image-gif/blob/master/Changes.md#v0130).

## WebP

The pure-Rust WebP **decoder** is now ready for production use!

It has been the default in `image` for a while, but it resulted in incorrect decoding in certain edge cases. It has now been tested on thousands of real-world images and all remaining divergences have been fixed. Its output usually matches `libwebp` bit for bit.

If you have been using `libwebp` previously because of correctness concerns, you can now switch to `image-webp` and never again have to deal with [devastating buffer overflows exploited in the wild](https://www.bleepingcomputer.com/news/security/google-assigns-new-maximum-rated-cve-to-libwebp-bug-exploited-in-attacks/)!

While correctness should be excellent, the decoder's performance is still not as good as `libwebp` with assembly optimizations. PRs for improving performance are very welcome!

The **lossy encoder** has relied on `libwebp` and has been removed in this release. You can still encode images loaded by the `image` crate using the `webp` crate, see [here](https://github.com/jaredforth/webp/blob/main/examples/convert.rs).

`image` now also includes a memory-safe **lossless encoder** for WebP. Compression is very fast, but the generated files are larger than those created by `libwebp` (even though they beat PNG already). Contributions of [even higher compression ratio modes](https://github.com/image-rs/image/issues/2221) would also be very welcome.

## API changes

Added `BufRead + Seek` bound on many decoders. This lets us avoid copying the data that is already in memory before decoding starts, and unlocks further optimizations in the future.

Incremental decoding has been removed. Only a small subset of decoders ever supported it. Removing it allowed us to make the `ImageDecoder` trait object-safe.

For other, relatively minor changes please see the [full changelog](https://github.com/image-rs/image/blob/main/CHANGES.md).

## Get involved!

There are lots of ways to contribute, from addressing small [issues](https://github.com/image-rs/image/issues) (not just on the `image` repo but on the [entire organization](https://github.com/image-rs/)) to adding features such as [higher compression ratio for WebP encoding](https://github.com/image-rs/image/issues/2221) or [adopting the latest research to improve quality of JPEG images](https://github.com/image-rs/image/issues/2202).

But the greatest challenge the `image` crate faces is **maintenance** - that is, investigating reported [issues](https://github.com/image-rs/image/issues) and reviewing incoming pull requests. Due to how central `image` has become to the Rust ecosystem, the maintenance load has increased considerably, and it is difficult for the existing maintainers to keep up. It may not seem glamorous, but it is necessary to keep the big features and performance improvements coming!

You can subscribe to the [image repository](https://github.com/image-rs/image) (or other repos under the image-rs umbrella) to get notified about new issues and pull requests. There is also a backlog of issues that need triage or fixing - starting with these is a good way to familiarize yourself with the codebase.

Finally, if your company benefits from the `image` crate, please consider setting aside some of your employees time to help maintain `image` and enable the project to keep advancing the state of the art in memory-safe image processing!