Allow using `zune-jpeg` for JPEG decoding about image HOT 9 OPEN

Note that development has moved from https://github.com/etemesi254/zune-jpeg to https://github.com/etemesi254/zune-image repository, and the decoder is now always single-threaded. There have been API changes as well, so please take a look at the zune-image repository.

I'll defer the rest of the questions to the author, @etemesi254

from image.

Sounds good with regards to maturity. There's some API details for implementation:

• multithreading, we need to not spawn threads on wasm targets for instance. Maybe switch to not-zune-jpeg on these targets?
• the ImageDecoder interfaces in image assumes that the buffer information (size and color space) is available before the main decoding loop is entered. How should the API be used here?
• we'll can replace (JpegDecoder::scale) with downsampling but it's odd
• the image interface assumes a Reader, zune-jpeg takes byte slice fully in memory. The buffering shouldn't be too much of a problem itself, but we need to be able to effectively stop reading from the underlying reader at the end-of-stream marker. How best to implement this? Decoding the image to decide what data consistitutes the full encoded buffer is obv. non-sensical.

from image.

• we'll can replace (JpegDecoder::scale) with downsampling but it's odd

I assume some combination of downsampling and plain old resizing will do the trick. For example, downsample only to 2x of the requested size in all dimensions, and let the user then run the final resizing step. This will save a lot of memory on huge images without degrading the output quality much.

• the image interface assumes a Reader, zune-jpeg takes byte slice fully in memory. The buffering shouldn't be too much of a problem itself, but we need to be able to effectively stop reading from the underlying reader at the end-of-stream marker. How best to implement this?

Unless image already provides an API for decoding multiple image from the same stream without knowing where one ends and the other starts, then simply ignoring the marker and reading till EOF doesn't break anything. It will use more memory when decoding rarJPEGs, but I don't see a way around this without a streaming parser.

from image.

the ImageDecoder interfaces in image assumes that the buffer information (size and color space) is available before the main decoding loop is entered. How should the API be used here?

All decoders in zune provide a decode_header interface. These provide colorspace infromation, depth information, width height, etc before decoding, from jpeg to ppm, you can call decode_header to decode this information, and the other get_ methods to get the information.

the image interface assumes a Reader, zune-jpeg takes byte slice fully in memory. The buffering shouldn't be too much of a problem itself, but we need to be able to effectively stop reading from the underlying reader at the end-of-stream marker. How best to implement this? Decoding the image to decide what data consistitutes the full encoded buffer is obv. non-sensical.

This is a bit trickier. When we hit the EOF marker, there are instances where we may request extra bytes from the decoder (aggressive refill), but the underlying bytestream on having no bits usually returns 0, which the huffman decoder treats as a no-op(to match libjpeg-turbo),in case there are extra bytes, then those will be read.
But as @Shnatsel pointed out, I haven't seen multiple images defined within a single reader

from image.

The concern isn't so much multiple images in a single reader, but that buffering all the available data beyond the image presents a change in semantics that has somewhat unknown consequences. Just not sure about it and if it's cheap I'd rather terminate the reading properly.

from image.