Jonathan Behrens

Thanks for this PR. Since it is a breaking change, it'll have to wait for the next major release.

Uh, not any immediate plans. There's a number of API changes I'd like to make at the same time, but it'll probably be a while before I have a chance...

No, we do tend to be overly hesitant to do breaking changes. Part of it is not getting a ton of user feedback beyond things like download counts which show...

I wonder if this is related to https://github.com/image-rs/image-png/pull/456. Before that PR it might have been possible to get to the `parse_ztxt` function with `self.info` still being `None`.

> Currently, the spec requires that all IDAT chunks be contiguous. But some of the extra image data should be interleaved within the IDAT data. We need to investigate if...

If making backwards-incompatible changes are in-scope, then another possibility is changing the IDAT bitstream format. The additional channels could be directly interleaved into the pixel data, and it would also...

Another idea is to use something like the `pLLD` from #54 but have it also apply to the extra-data chunks. That way, while the IDAT chunks wouldn't be interleaved with...

Another intermediate option would be to have the just array of enum values in this chunk and then anything that needs more metadata could add additional chunks. That would mirror...

The Pixel trait already having a lot of functions is a reason to avoid adding more. Could you share a bit more on what cases these methods would be needed...

Yes there are other ways to get as good, if not better, performance. The trait exposes the underlying components and if you don't need to be generic over all implementations...