Decoding out of image::io::Reader directly into user-controlled buffer about image HOT 4 CLOSED

0.25.0 is now released!

from image.

This is actually being addressed in the 0.25 release! The ImageDecoder trait is being changed to be object safe, at which point we can add a io::Reader::into_decoder method:

let decoder = Reader::open("path/to/image.png")?.into_decoder()?;
let size = decoder.total_bytes();
decoder.read_image(&mut buf[..size])?

I'll tack on to the end here that we currently use a Cursor over a &[u8] to construct an io::Reader, which feels a little odd. Is there a nicer way to get with_guessed_format without having to go via an I/O trait when you have the image in a buffer already, or is this the intended way?

If you only need to know the format, you can call guess_format which directly takes a slice of bytes. But if you're going to be decoding the image anyway, you already need to have a Cursor<&[u8]> so might as well use it for guessing the format. And with_guessed_format is pretty simple: it reads the first 16-bytes, looks them up in a table of magic bytes for different formats, and then seeks back to the start.

from image.

There's currently a 0.25.0-preview.0 release out. Assuming no glaring issues are found with it, a full 0.25.0 should be at most a few weeks away.

As far as taking advantage of the whole image being in memory, that's actually something that's been discussed in the context of the png crate (which is one of the few decoders fast enough for it to possibly matter). The strategy we're investigating there is using the methods provided by the BufRead trait. In particular, the implementation of Cursor::fill_buf returns the the entire remainder of the slice. If you are curious there's currently a draft PR and more discussion here.

from image.

Amazing! Do you have a rough ETA for 0.25 (like, is it a few weeks away, a few months, or a few years)?

For the PS, I was more wondering whether there was a way to decode something that is in a &[u8] without a Cursor in the first place (I could imagine some impls could be faster when the whole image is in memory maybe?). But if that's not the case, that's fine — just wanted to check if there was a part of the API I had missed!

from image.