Jonathan Behrens

The DXT codec used to be public, but [was deprecated and removed](https://github.com/image-rs/image/issues/1623) in favor of recommending the (much better) texpresso crate instead.

To be clear, the existing `ImageDecoder` trait is dyn-compatible. Otherwise it wouldn't be possible to use with a `Box`. The design has the downside that you can only call `read_image`...

I think it would be helpful to start by talking through what changes would be made to `ImageReader` and then we can figure out what would have to be different...

Another option is to use `with_format`/`set_format` and rename the existing methods: * `with_format` -> `with_builtin_format` * `set_format` -> `set_builtin_format` Not entirely sure how I feel about that though, since it...

Looking at this again, I think we should first try a scalar version that operates on 64-byte blocks. If LLVM isn't able to suitably auto-vectorize it, then that really starts...

I see mixed results on my Zen 5 CPU. On the bpp=3 case, throughput regresses 13% from 9.2 GB/s to 8.0 GB/s with the default target-cpu and regresses to 6.4...

I think we should consider what information lands "above the fold" at the start of the readme. Right now that's the couple pointless sentences that "`image` is an image library",...

Yeah, the samples in each row between `width * CHANNELS` and `row_stride` would not actually be part of the sub-image. That's not ideal, but I didn't see a good way...

I'm not sure I follow what the distinction is. If we exposed `GenericImage::view` instead, then: * `img.view().samples()` and `img.view().image_slice()` would return exactly what `img.buffer()` did. * `img.view().flat().layout.height_stride` would be exactly...

I think some sort of `peek_trailing_metadata` on the `png` crate is probably the least-bad approach. We could call it lazily only if the user asked for metadata we haven't seen...