Aurelia Molzer

In the meantime, we do have _some_ evidence that in-place transformations (or rather in-allocation) are generally desirable: https://github.com/image-rs/image/discussions/2650. I think more people stumbled upon it but simply did not ask...

I would have assumed us to be targetting `1.61` already, but CI should be investigated regardless. It's truly puzzling. The toolchain job reports setting `1.34.2` as the default and then...

@reneleonhardt Closed issues are not shown by default in that view, so that may be confusing. Also one major open issue with an API break is related to limits, but...

The two largest classes of non-`Pixel` buffers: - Planar layouts, potentially subsampled as Yuv, layouts where each color unit is not a contiguous part of memory. (#2010 , #1272, #1866)...

Sure, compatibility with `DynamicImage`/`open`/`save` are the main design constraints for a metadata/color-aware buffer type. I have a good deal of potential solutions that hopefully fit together, you'll see in the...

Cool. I think we're on the same page. This covers quite exactly the types I want to go for: 1. The new `ImageBuffer` to be provided with the `metadata.rs` information....

> In my implementation, I support decoding at 1/nth of resolution, so at this level my images have a separate notion of a logical size (the full size it would...

> This is because there's a tension between being able to accurately represent any useful pixel format & layout vs forcing every downstream user to match against all the weird...

> If the conversion happened later and/or was optional, then internal code would have to handle way more cases. (I'd really like to avoid something like resize raising an unimplemented!()...

I think now we're veering off this PR. The question that imo needs to be answered with the concrete buffer purposes that we agree on: is this buffer for purpose...