webp frames iterator is now ending iteration if no more frames are decodable

[EmiOnGit]

Fixes #2226

The iterator returns None as soon as a DecodingError::NoMoreFrames is found.

Debatable

The current implementation returns every Frame only once regardless of the specified LoopCount. I believe this is what most people would expect, especially since LoopCount::Forever is the most used variant.

It would be a bit more performant to return the iterator at the start since the allocation of one RgbaImage/RgbImage can be saved.
(Thank you for this awesome project btw :))

[HeroicKatora]

There are probably existing images applicable as a test here, e.g. this one.

Would you mind expanding the regression test suite for this behavior?

[EmiOnGit]

Changes to the iterator

After benchmarking the iterator on DecodingError::NoMoreFrames again returning early I found that the early return is constantly around 8-10 percent faster on a webp animation with 6 frames (tested on two machines and 10_000 iterations). Therefore I changed the implementation to check at the start using a internal counter.

Testing

I also implemented a simple test which is checking against the internal framecount of the image_webp::WebPDecoder::num_frames(). The test is run against the 3 files in webp/extended_images which I believe to be a good representation of the expected behaviour.

advertises_rgba_but_frames_are_rgb.webp: returns the first two frames and the rest as a EOF decoding error. The iterator still exists after the specified frame-count of 12 .
anim.webp returns all frames.
lossy_alpha.webp: (not animated webp) returns one frame.

Let me know if something else should be implemented let me now. We could also check the first returned frame against the image returned by image::open, which would also be expected to be for all inputs. I wasn't sure if more tests are welcomed.

(Also I'm not sure about the clippy check failing. It also fails on my computer on the main branch so I assume it's not my fault)

[HeroicKatora]

LGTM

[HeroicKatora]

(Also I'm not sure about the clippy check failing. It also fails on my computer on the main branch so I assume it's not my fault)

clippy is linting that there are some cfg-options that do not correspond to actual features we have in Cargo.toml. Huh, weird, but definitely not your fault.