Aurelia Molzer

> Ord is mostly useful for BTreeMaps, that's why I usually derive it even if it "doesn't make sense". I feel that if you are using an `ImageError` or `io::Error`...

Indeed, the design of `ImageBuffer` is quite dated and large portions of it haven't been changed motivated by compatibility and effort. The most glaring issues are that it hadn't been...

> I can't find any reference online, but is it perhaps possible to implement a wrapper struct that takes an AsyncRead and implements Read? No. `async fn` is not composable...

Seems like a problem similar to `Limits` for decoder but for the encoders.

Depending `alloc` in a `#[no_std]` crate was stabilized only in `1.36`. It's not completely unlikely that we'll run into some MSRV problem. That could defer completion until the next major...

It's not just the methods but even the ubiquitous [`Error` type uses `std::io::Error`](https://docs.rs/image/0.23.3/image/error/enum.ImageError.html#variant.IoError) and thus is on its own currently incompatible with `no_std`. This then 'bleeds' into many other interfaces...

Supporting byte slices in a separate interface is definitely a possible avenue for `no_std`/no-`alloc`. I had hoped to find a good a replacement for `io::{Read,Write}` (and indeed there exists [`core_io`](https://docs.rs/core_io/0.1.20190701/))...

> We may not use core_io, but define a special trait for image crate, which may rely on other possible API designs for no_std environments. Yep, the important part would...

As an additional remark, we _could_ make a major version bump for this feature. However, we shouldn't make more than one imo. That is, any design that requires a major...

> Is this something that has been investigated at this point? The non-io portion of passing images in memory is indeed being investigated in [`image-canvas`](https://github.com/image-rs/canvas). Please have a look, and...