Jonathan Behrens

Another possible item would be adding `BufRead` and/or `Seek` bounds for the decoder. The _image_ crate already requires them, so no further breakage would be required there. * Discussion of...

We really should get a bug-fix release out to address #546, but after that I think it would be good to decide what we want to include in 0.18 and...

Thanks for raising this issue! The real requirement on `write_image` is that the provided byte slice length is precisely what's expected given the color type. We probably need to write...

The pair of `Pixel` and `PixelBuffer` does make sense to me, so I'm potentially open to this renaming. But I'd want to understand more about what a non-Pixel image representation...

The important thing for me is that whatever our main image representations are, they should integrate with the rest of the functionality we provide. Things like calling `image::open` (or similar)...

Would most users start using the new type in all the places they currently use `ImageBuffer`? Or in most cases would they have to change their code to use `PixelBuffer`...

I think that our ability to convert to a smaller supported set of image representations is a very powerful way we can (and currently do) cut down complexity. For the...

I don't think we should add a new type named `ImageBuffer` that isn't for (4) or isn't largely interchangeable for current code that uses `ImageBuffer`. I'd rather start by adding...

The `OutputInfo` object is only returned from `next_frame` so it seems harmless to have all public fields. Though it is a bit awkward that it gets returned at the same...

Seems reasonable to `assert!` that the provided palette doesn't exceed the maximum size allowed by the PNG spec. Want to make a PR?