Add zune-jpeg as an alternative backend for JPEG decoding

[Shnatsel]

This is an initial implementation to get the ball rolling. I've implemented a decoder but it's not yet wired up to decoder selection based on format, or any other machinery. Haven't tested it either.

Right now this buffers the entire input in memory, but this requirement may be relaxed soon..

It also parses headers twice, because zune_jpeg::JpegDecoder accepts a lifetime parameter and putting it into the same struct as the input data would create a self-referential struct. This should not be a big deal because it is offset by the efficiency gains over jpeg-decoder.

Fixes #1845 once complete

---

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

[Shnatsel]

Depends on etemesi254/zune-image#98 upstream, that must be merged and released first

[Shnatsel]

Question to maintainers: what should this be integrated into on top of just providing a Decoder struct, if anything?

[HeroicKatora]

Question to maintainers: what should this be integrated into on top of just providing a Decoder struct, if anything?

I'd say the important part is choosing between the decoder implementations in load_decoder: https://github.com/image-rs/image/blob/master/src/io/free_functions.rs#L45

That should be pretty much it, in terms of decoder, that's the central translation from a file format to its decoder. One possible concept for dynamically choosing this would be to pass a preference hash map for each format and falling back to the current choice when no preference is given.

[fintelia]

I haven't thought it through fully, but my initial reaction is that if we use zune-jpeg it should probably replace our current use of jpeg-decoder for decoding JPEGs.

[Shnatsel]

I haven't thought it through fully, but my initial reaction is that if we use zune-jpeg it should probably replace our current use of jpeg-decoder for decoding JPEGs.

Do you mean it should be set as the decoder to be used by default, but keep jpeg_decoder around to avoid an API break by removing it? Or do you mean remove jpeg_decoder entirely and try to contort the zune-jpeg wrapper into the same API (can probably be arranged with liberal use of PhantomData)? Or do you mean an API break that removes jpeg_decoder entirely and switch to the API proposed in this PR?

[fintelia]

I haven't thought it through fully, but my initial reaction is that if we use zune-jpeg it should probably replace our current use of jpeg-decoder for decoding JPEGs.

Do you mean it should be set as the decoder to be used by default, but keep jpeg_decoder around to avoid an API break by removing it? Or do you mean remove jpeg_decoder entirely and try to contort the zune-jpeg wrapper into the same API (can probably be arranged with liberal use of PhantomData)? Or do you mean an API break that removes jpeg_decoder entirely and switch to the API proposed in this PR?

I mean removing jpeg_decoder entirely while exposing the same API if possible, or doing an API break if not.

[Shnatsel]

It should be possible to stuff zune-jpeg behind a compatible API. The jpeg_decoder wrapper is strictly more restrictive. I'm going to continue working in a separate Decoder struct for now, but I'll switch over to a hostile takeover of the JpegDecoder struct once everything settles, provided @HeroicKatora is OK with it.

[Shnatsel]

I've opened #1877 to show what outright replacing jpeg_decoder with zune-jpeg looks like.

[HeroicKatora]

I'll switch over to a hostile takeover of the JpegDecoder struct once everything settles, provided @HeroicKatora is OK with it.

Sounds good to me, once the dust settles to have a period in which unanticipated feedback can arrive.

[Shnatsel]

I'm going to go ahead and close this in favor of #1877