The specifications are available in parts (see https://stackoverflow.com/questions/8560571/where-can-i-get-free-specifications-of-jpeg-jfif-exif-etc)
For defining “good enough”, we have a few dimenions:
- Does it decode all files that mozjpeg can decode? If not, it’s a bug.
- Does it report decode errors descriptively? If not, it’s a bug.
- Does it encode files with the same resultant quality (DSSIM) as mozjpeg? If not, there’s a math bug somewhere.
- Does it decode and encode quickly, within 20% of the speed of mozjpeg? If not, it’s a bug.
As far as API surface and functionality exposed, I think that will be driven by:
- Speed. We want zero-cost abstraction in both syncronous and async usage contexts. Decoding from buffered or contiguous memory, memory-mapped file, file descriptor, or IO descriptor (struct with read/seek/pos/write fnptrs) would be important. Also, mozjpeg is currently single-threaded. With a Rust codebase it would be much easier to reason about parallel encoding or decoding.
- File size. We would want to match mozjpeg’s encode features.
- Backwards compatibility - It would be quite nice to have backwards compatibility with the libjpeg API, even if as a C shim. This is optional, but would expand the potential user base significantly.
I think that a function-by-function review makes sense, but that significant refactoring would be required - too much for a function-by-function translation to work as-is.
We currently have two donors putting up $18k USD, but perhaps we could find more. This is a big project.