libjxl VS qoi

https://github.com/libjxl/libjxl/blob/main/doc/format_overvi... is a pretty detailed but good overview. The highlights are variable size DCT (up to 128x128), ANS entropy prediction, and chroma from luminance prediction. https://github.com/libjxl/libjxl/blob/main/doc/encode_effort... also gives a good breakdown of features by effort level.

They're available at https://github.com/libjxl/libjxl/releases/ for linux and windows.

For JPEG XL, refer to its format overview [1]. In short its lossless mode uses a combination of multiple techniques: the rANS coding with an alias table, LZ77, reversible color transforms, a general vector quantization that subsumes palettes, a modified Haar transform and a learnable meta-adaptive decision tree for context modelling.

One good thing about JPEG XL is that its lossy mode also largely uses the same tool, with a major addition of specialized quantization and context modelling for low- and high-frequenty components.

[1] https://github.com/libjxl/libjxl/blob/main/doc/format_overvi...

The problem is that the instructions for actually running the WASM file are not that clear... the docs the author mentions shows how to compile to WASM, which is easy enough, but then here's the instructions to make that actually work in the browser:

https://github.com/libjxl/libjxl/blob/main/tools/wasm_demo/R...

Yeah, you need some mysterious Python script, a JS service worker at runtime, choose whether you want the WASM or WASM_SIMD target, use a browser that supports Threads and SIMD if you chose that, make sure to serve everything with the appropriate custom HTTP headers... just reading that, I can see that to get this stuff working on non-browser WASM targets would likely require expertise in WASM, which is the point of the OP. WASM's UX is just not there yet.

https://github.com/libjxl/libjxl#usage

> Specifically for JPEG files, the default cjxl behavior is to apply lossless recompression and the default djxl behavior is to reconstruct the original JPEG file (when the extension of the output file is .jpg).

But you look at your image viewer that could have the lossless indicator? (and there is an issue open to add this indicator to the jxl files)

https://github.com/libjxl/libjxl/issues/432

You might want to use libjxl directly, e.g. for visually lossless images: cjxl --effort 9 --brotli_effort 11 --distance 1.0 --num_threads (nproc) --lossless_jpeg 0 input.png output.jxl on linux (if you're on windows/mac, just replace the (nproc) with the number of cpu threads you have, e.g. --num_threads 16).

One thing that doesn't really get mentioned is that libjxl has official .deb packages for Debian and Ubuntu users. You can just download the appropriate archive from the libjxl releases section (packages are available for Ubuntu 18.04, 20.04, and 22.04), do a sudo dpkg -i *.deb, and now your file manager has support for .jxl thumbnailing. And at least my distro's default image viewer (xviewer) gained viewing support just from installing the debs.

One of the most interesting things to me is that JPEG-XL is under an open Patent License, unlike the original JPEG.

https://en.wikipedia.org/wiki/JPEG_XL

Also, Google contributed quite a bit to it's development. As the patent grants show:

https://github.com/ImageMagick/jpeg-xl/blob/main/PATENTS

https://github.com/libjxl/libjxl/blob/main/PATENTS

Microsoft seemed to have gotten a patent on part of it's implementation (which Google also tried to get). Not sure if Google will pay to invalidate that patent, but I have a feeling they are more likely to defend AVIF.

https://www.theregister.com/2022/02/17/microsoft_ans_patent/

Google's control is a little concerning, but I do feel there are bigger fish to fry then choosing between two free formats. Like H.264 and H.265 patents.

source: https://github.com/libjxl/libjxl/graphs/contributors

And people are really nice about asking for ceasing its use too..

How do you know it's not a problem for the people who work with computer vision? Let's take this for example - sure, the request itself was presented very unprofessionally, but this is still an example of someone in a computer vision-adjacent field stating in no uncertain terms that they have a problem with the image.

I don't know about CUDA, however I've made an AVX2 based encoder a few months ago : https://github.com/phoboslab/qoi/pull/143

I intend to create an AVX2 based decoder but I had absolutely no time to work on side projects in the past three months.

You might also want to take a look at this streaming encoder if you want to encode large files with a tiny memory footprint : https://github.com/MKCG/php-qoi/blob/main/src/FFI/lib/qoi.c

The spec finalization was extended to Dec 20.

What exactly do you mean with "edge cases"? For what it's worth, the decoder has been fuzzed[1] and the benchmark suite[2] with 2800 images en-/ and decodes without losing any pixels, as checked by qoibench[3].

[1] https://github.com/phoboslab/qoi/blob/master/qoifuzz.c

[2] https://qoiformat.org/benchmark/

[3] https://github.com/phoboslab/qoi/blob/master/qoibench.c#L440...

Here is link number 1 - Previous text "QOI"