Jonathan Behrens

If you can figure out what crate specifically is spawning these threads, I'd suggest filing an issue there. I don't think `image` is ever requesting multithreaded operation for AVIF

It sounds like a lot of the problem is that there's a bunch of threads being spawned even when the image is tiny. If we instead only spawned threads when...

We switched to an entirely different jpeg decoder in the 0.25 release. Might be worth seeing if the problem still happens there?

In that case, you could try opening an issue against https://github.com/etemesi254/zune-image (the error you are seeing is coming from the `zune-jpeg` crate). That error looks suspiciously like there might actually...

Maybe also have a `data: [1, 2, 3, 4, 5, ...],` field? Enough to show the actual values of a few pixels but not overwhelm the output

I've thought about the `buf_independent` test some more, and I think there's still and additional case this PR doesn't handle. The problem is when the final bytes of the zlib...

The underlying `tiff` crate understands arbitrary color types, but the `image` crate only supports a specific list of them: https://github.com/image-rs/image/blob/1ed88e44e9acf5f08ac5236deda9b1ebeedc6054/src/codecs/tiff.rs#L74-L106

I suppose if we make this change we might also consider changing `guess_format` to return a file extension

Yeah, that line of thinking was why I initially treated built-in formats and extensions separately. But now I'm wondering if it matters? The _only_ formats this would apply to is...

Formats added via hooks always operate on a `BufReader` objects, while the built-in decoders get the actual reader implementation passed by the user. We had to do it that way...