Luca Versari

Let me clarify my position: I am against this change, unless we know that the fraction of such JPEGs actually in the wild is high enough.

I might be able to give the libvips code a look sometime in the near future. To comment on your questions above... We are in the process of implementing a...

Now that the chunked encode API is ready, it might be time to think about chunked decoding :-) JPEG XL is somewhat incompatible with scanline-based decoding - the format internals...

JXL *is* internally tiled :) (well, mostly, $things happen at tile boundaries) I don't know yet how such an API will look like. However, libjxl can and will use threading...

I assume libvips has a thread pool abstraction somewhere for its own threads? In that case, you can simply provide a parallel runner that uses the libvips thread pool to...

> The libvips threadpool is auto-sizing, so it watches mutexes and grows and shrinks depending on lock contention (using that as a proxy for available parallelism). I think we'd need...

Hey, sorry for the delay. The fjxl code is mostly here: https://github.com/libjxl/libjxl/blob/main/lib/jxl/enc_fast_lossless.cc The decoding code is here: https://github.com/libjxl/libjxl/blob/main/lib/jxl/modular/encoding/encoding.cc I have thought in the past about using SIMD to decode multiple...

FWIW I really like this proposal, and I think it has a lot of potential for safe low-level SIMD. I am taking a stab at implementing it to see how...

> There are a little bit of differences in higher efforts, but lower efforts are more pronounced, but probably fast enough to not be noticed. > > [0x0.st/H7us.txt](https://0x0.st/H7us.txt) Would you...

What CPU are you running this on?