image-rs
Make the `Frame` struct `Pixel`-agnostic?
The Frames returned by AnimationDecoder are hardcoded to contain Rgba8Images, which is generally suboptimal when working with animated PNG or WEBP images:
- if the source image has no alpha channel, this imposes an extra conversion;
- 16-bit APNGs are unsupported because of this.
Would it make sense to have Frame contain a DynamicImage instead of a Rgba8Image, despite the fact that this is a breaking change? Existing users of the API could easily upgrade by doing the conversion to Rgba8 manually with .into_buffer().into_rgba8() or similar.
It would be nice to have.
It might be doable in a backwards-compatible way by adding a new method next to into_frames, like into_frames_dynamic().
However, I don't think it has practical utility besides optimization for opaque RGB8. AFAIK WebP doesn't have 16-bit coding — lossless is 8-bit-only, and VP8 implementations don't even use full range in 8 bits. PNG compression is pretty bad in 16 bits.
You're right that this would be mostly for optimization purposes; another theoretical use-case would be grayscale APNGs, but I'd be surprised if they actually exist in the wild ^^
For unsupported color layouts, #2522 should be the general direction. It's probably fine to convert the color while encoding. At least truncating the depth was a sought after compatibility adjustment to be made. Color space treatment such as rgba->luma might be a different beast but it's not a likely problem for most common formats. Event though some formats can not encode a CICP indication, they are currently just wrong and I imagine fidelty with conversion would be better than wrong.
