Assorted optimizations for GStreamer's image-rs plugin

[amyspark]

Hi,

This is a MR to add a few things for feature parity in my GStreamer reader plugin:

• PNG: iCCP chunk's profile name
• AVIF: speed up the reader by delaying actual decoding until read_image

Both require upstream work, so marking as draft until those are landed: image-rs/image-png#679, mozilla/mp4parse-rust#446

[fintelia]

Are there formats other than PNG which do store names for the embedded profiles?

[amyspark]

That's the only one. I introduced this API, however, because I didn't know how to downcast from impl ImageDecoder to PngDecoder (and so access a decoder specific API).

[197g]

We may need a novel mechanism for this. Downcast ties it to the png version which conflicts with the requirement of being able to bump it (through breaking changes). On the other hand a new API on the trait is also rather awkward. Maybe something similar to Error::provide would fit the bill in letting us translate types provided by version-encumbered crates to stable types defined in image directly (that we then only let include the 'stable' options / data from the formats). The converse holds for encoder, another unsatisfied user ask.

[fintelia]

You're trying to cast between a Box<dyn ImageDecoder> and a image::codecs::png::PngDecoder, right?

For that, I think we might just be able switch to a Box<dyn ImageDecoder + Any> or make Any a super-trait of ImageDecoder?

[197g]

Any does not really solve the problem. It only makes the dependency problem a runtime error but I'd consider that worse than a breaking change everytime we bump dependencies. There's no reasonable way to use Any::downcast right here for downstream—they'd have to add fallback cases for potentially unpublished versions of our dependencies preemptively to avoid functionality breaking and that just pollutes the dependency graph greatly.

[fintelia]

No, if I'm understanding correctly, the goal isn't to downcast to the decoder struct from the png crate but rather to cast to the PngDecoder struct in this crate

[amyspark]

No, if I'm understanding correctly, the goal isn't to downcast to the decoder struct from the png crate but rather to cast to the PngDecoder struct in this crate

Correct, I already have to do something similar when dealing with image-extras formats that do not support guessing. It is also required when accessing the animation API IIRC, because only explicitly typed instances of AnimationDecoder allow calling into_frames.

[RunDevelopment]

make Any a super-trait of ImageDecoder?

Any requires Self: 'static. Decoders are generic over readers and some useful readers (e.g. &[u8]) aren't 'static. So ImageDecoder: Any would be a major limitation.

It's also unclear to me how the downcast would even work. Say we did require ImageDecoder: Any, you can't downcast unless you know the exact reader type. E.g. image_decoder.downcast_ref::<images::codecs::PngDecoder<Reader>>(). Would that even be useful?

only explicitly typed instances of AnimationDecoder allow calling into_frames.

In 0.25.x, yes, but this will change soon with the new decoding API. ImageDecoder will handle single images, sequences, and animations. #2672

[fintelia]

Hm, yeah the 'static requirement does make that less workable