Aurelia Molzer

The `bytemuck` crate provides `pod_collect_to_vec` as a safe method to get a `Vec`, if required. With some insight on the state of Rust graphics programming—including the sentiment derived from `wgpu`:...

> to the point I'm panicking if I get L16. That definitely does not sound right. Can you expand? Is this a panic within `jpeg-decoder` or outside caused by some...

> It's safe and zero-copy to cast &[u16] into &[u8], but no the other way round. Not zero-cost but one `alloc+memcpy`, yes. Although all but the simplest case will incurr...

When you call `read_info`, constructing the reader, you get an [`OutputInfo`](https://docs.rs/png/0.16.7/png/struct.OutputInfo.html) struct as byproduct. Is there any information missing from that struct?

In `png` those are per-frame and thus availabe in [`Reader::info`](https://docs.rs/png/0.16.7/png/struct.Reader.html#method.info). It seems the opposite is the case, the encoder doesn't offer a way to transfer that information per frame. (But...

A getter `fn (&self) -> Option` would be cleaner, I think. But sure, I'd be happy to accept a PR for that. Be sure to target the `version-0.16` branch if...

Items yielded by an iterator must be independent from the iterator itself and can't borrow from the decoder. Hence we would have to clone or reference count all shared information...

> encoder.write_header().unwrap().into_stream_writer_with_size(2); The `with_size` refers to the internal encoding buffer for `IDAT` so `2` is definitely far too small. However it should still not loop. The problem appears to be...

There is no actual minimum size just a very inefficient size. Improving the documentation could definitely help here, noting that the provided size is the number of bytes of _content_...

No, but looks like the leaf functions are dominantly in the `inflate` crate, not within this one. Instead of a screenshot, can you attach an archive of the actual `perf`...