Feature request: JPEG decoding

[o-l-a-v]

Got the idea from:

• 2023-04-19 jxl-oxide feature request: Feature request: support JPEG decoding tirr-c/jxl-oxide#4

For more context: mozilla/standards-positions#522 (comment)

Regarding maintenance / code size / attack surface / binary size, I want to point out that potentially a JPEG XL decoder could also be used as a JPEG decoder (libjxl currently doesn't do that yet, but it does contain all the code needed to do that), which means the dependency that browsers have on libjpeg-turbo could potentially be dropped.
If the numbers from android chrome are an indication (see https://chromium-review.googlesource.com/c/chromium/src/+/2932498): libjpeg_turbo weighs in at 151 KiB, libjxl currently weighs in at 191 KiB, but plausibly libjpeg-turbo could be dropped and the jxl decoder could be used instead also for jpeg decoding, which brings the net binary size overhead down to ~40 KiB. So it does come at a cost in maintenance / code size / attack surface / binary size, but arguably the net cost is not huge, e.g. compared to libwebp (165 KiB), and probably quite comparable to the net cost of AVIF (i.e. implementing the HEIF functionality on top of an AV1 decoder that is and presumably will remain 'free' in the sense of 'available anyway').

[TPS]

Is this a request to port in jpegli for its decoding, like in libjxl? Or some other implementation?

[CrushedAsian255]

I think the idea is more to have jxl-rs also be able to decode baseline JPEGs

[TPS]

Yes, of course. But why should this crate do it? There're already many. Imho, the only sensible reason to have 1 here is b/c libjxl does, which originated jpegli, so ifF anything, that's what should be here, though there's an independent implementation for rust already.

[CrushedAsian255]

But why should this crate do it?

The main reason would be so that any software that wants to support JPEG XL can use the same code path with JPEG and JPEG XL