Jonathan Behrens

Thanks for looking into this! To be clear, there's two transforms that are relevant here: the **color transform** (8.5% of total time) and the **subtract green transform** (2.2% of total...

Honestly, there's nothing wrong with just looping through the coordinates calling `get_pixel_mut` or `get_pixel + put_pixel`. The optimizer is pretty smart and should be able to generate quite fast code...

Would using the [`ImageDecoder` trait](https://docs.rs/image/0.20.0/image/trait.ImageDecoder.html) directly work better for your use case?

I'm not sure I follow. Couldn't you do something like: ```rust fn create_texture_from(decoder: D)->Result{ let (width, height) = decoder.dimensions()?; let format = match decoder.colortype()? { ColorType::RGB(8) => GL_RGB, ColorType::RGBA(8) =>...

Yeah, the issue with just numbers of bits is that there are a bunch of other formats that can't be described that way, including compresesd images, images that have palettes,...

This functionality seems completely reasonable to add. `ImageBuffer::dimensions` already exists with a different return type, so it may be better to pick another name. I also don't love using usize...

If anyone is interested in working on this, [`fdeflate` uses a different strategy](https://github.com/image-rs/fdeflate/blob/c365c7e6ffa81feb2e1fb762eed7299f05c9b0ca/src/huffman.rs#L5) based on `libdeflate`. It keeps the codeword in bit-reversed form, and uses more complicated arithmetic to increment...

Is this a common operation for some use case?

Are there safe intrinsics for converting a slice to/from SSE or NEON vectors?

One place that might benefit from explicit SIMD is the [subtract_green transform](https://github.com/image-rs/image-webp/blob/main/src/lossless_transform.rs#L375). I saw a modest end-to-end improvement just by adding a `std::simd` implementation via [this patch](https://github.com/image-rs/image-webp/commit/a6229c737e246321ca5bdd60b619069122f01e06).