Aurelia Molzer

We can also bump MSRV for a perf win, it's not a set-in-stone restriction. Bump here and as indicated in the comment to do it with the PR: https://github.com/image-rs/image/blob/master/Cargo.toml#L7-L8

> Add a method to the ImageDecoder trait called palette that returns an option with the palette(this matches the behavior of icc) That sounds like a decent match in terms...

I'm not sure if the usecase actually fits what is there. In particular, if I understand properly, it requires us _not_ implicitly converting the palette and keeping the palette available....

Generally, yes, but I don't think this is one of the cases that adds complexity. * every user of ImageDecoder has to handle every possible variant: of _extended_ color types,...

The conceptual difference: `imageops::grayscale` does an external loop over pixels, `convert` is the interior iteration version of this loop. Due `imageops` being generic it can't statically know the best iteration...

One comment I want to add outside the workflow of the PR review: If we _need to_ get rid of a core buffer data structure, rewrite the `DecoderTrait`, etc. completely....

There's a small detail easily missed: `DynamicImage` is `non_exhaustive`. The macro does not create any fallback match arm. It would thus not work in its current state outside the crate...

That interface has no form of SemVer compatibility. There's no describably type interface and minute changes to the *internal* types will break upstream dependencies. It would completely subvert the extensibility...

If anyone comes up with a good SemVer story for such a macro, we can definitely do it though! The need for abstraction and comfort are definitely there.

We shouldn't forget fixing [`ImageBuffer::get_pixel`](https://docs.rs/image/latest/image/struct.ImageBuffer.html#method.get_pixel), same for `DynamicImage`, with these. It just makes sense and the current state is definitely a compromise between churn and different APIs having established different...