zune-jpeg VS zune-image

Congrats, but you dropped this.

Alternatively, you can round up the array length to the nearest power of 2 and use cheap bitmasking instead of branching bounds checks. If it goes wrong, it will access the wrong element but will not result in any code execution vulnerabilities. Here's an example of this in zune-jpeg.

gif, png, zune-jpeg are on par with their C counterparts in terms of performance

here

Based on some experience writing a jpeg decoder library, I'd like to give my two cents worth of information

Answer pretty fast

Thanks to the zune-image library, serde-numpy is now supporting PNG and JPEG. Enabling faster io for neural net training loops and other image processing in python

It has been extensively tested on 600,000 real world images, as well as fuzzed in various ways, and is now ready for production use!

I might have misunderstood what you've written, but is there a reason you can't use https://github.com/etemesi254/zune-image as a JPEG decoder? It has minimal use of unsafe and is performant.

It uses SIMD for colorspace conversion and IDCT, the code can be found here and here.

You can see a Github Action that zune-inflate uses here, it's mostly self-explanatory.

I've just added a roundtrip fuzzer to the Rust translation of it so that we can start weeding out the bugs: https://github.com/etemesi254/zune-image/pull/13 Right now it finds some decoding failures in a few seconds.