clovercoderNot every format decodes in place
`TryDecodeInto` in Sdcb.SimdCodecs fills your buffer directly for JPEG, PNG and WebP. TIFF, GIF and JPEG 2000 decode a whole frame first. Its own 1600x1200 lossless JPEG 2000 test: 433 ms vs libopenjp2's 221 ms, same machine.
sdcb/SimdCodecs
Sdcb.SimdCodecs is a pure managed image codec library for .NET 10. Its README says the JPEG decoder beats libjpeg-turbo, and for the tuned formats that holds up. The catch is in docs/known-gaps.md, which the README links to.
Two paths behind one call
SimdCodecs.TryDecodeInto(file, buffer, stride, format) looks the same for every format. It is not. JPEG, PNG and WebP write straight into the buffer you pass, with no RGBA frame in between. The known-gaps file says the other formats take a plainer route: decode one complete image, convert the whole frame to the target pixel format, and allocate a full frame on the way.
The list of untuned formats there is TIFF, JBIG2, GIF and EXIF. JPEG 2000 has a benchmark project now, but arithmetic decoding and concurrency work have not started.
What the benchmark shows
The README table for 1600x1200 JPEG 2000 puts libopenjp2 at 221 ms for lossless and 49 ms for lossy. This library takes 433 ms and 99 ms, about twice as long. Decoded pixels are exact for lossless and 84 dB PSNR for lossy, so the output is right, just slower.
Who this hits
Anyone decoding many TIFF or GIF frames, or JPEG 2000 scans from PDFs, through the facade. If the work is mostly JPEG, PNG, WebP, BMP or QOI, none of it applies. The project is open about it: the file exists so readers can judge fit before using the library.