Overview of JPEG XL | Hacker News Reader

Overview of JPEG XL

jpeg.org

17 pointsRafelMri8 comments

I'm a big supporter of JPEG-XL. It has something very unique that has not been seen in an image file format before: An option for Lossy compression that isn't DCT-based. So you can't get ringing or blocking, because there are is no DCT at all. The actual artifacts you do get are not at all like what you get with JPEG. Instead, you are likely to see things like slight pixellation or banding when your quality level is too low.

In order to get the non-DCT lossy compression, you need to request "Modular Mode" in the program that compresses the image. But for some reason I don't know, Irfanview is literally hiding that checkbox from you, and you can enable the feature by editing the dialog resource and making the checkbox no longer hidden.

---

Meanwhile, I still prefer WEBP for lossless compression, because the decompression code is so fast. In terms of who has the best lossless compression, WEBP and JXL easily beat AVIF, and JXL usually beats WEBP, but not always. In one case, I saw a grayscale BMP file getting better compression with FLAC (!) than JXL.

WEBP's lossy format is just not that good, AVIF and JXL beat the hell out of it, sometimes the JPEG even looks better. But WEBP's lossless format is excellent.

JPEG 2000 is completely wavelet based, no DCT either, and it’s been around for a while. It’s used a bit in medical imaging where ringing artifacts are a big no no.

>I saw a grayscale BMP file getting better compression with FLAC (!) than JXL.

I thought FLAC are for audio only or am I missing something?

Compared to other Lossless I thought JXL was quite computational heavy, even with the very recent optimisation. HALIC (High Availability Lossless Image Compression) is still unbelievably good. Except it is not open source ( yet ).

Hopefully we will see work on image quality improvement at below BPP 1.0 this year.

FLAC is meant for audio only. But you can open a BMP file as raw audio (8-bit unsigned mono) using a sound-editing tool, then save it as a FLAC file. Since FLAC is lossless, you get your original data back when you decompress it.

It just happened to work particularly well on a certain grayscale image. Because only an 8-bit grayscale image could potentially be similar to 8-bit mono unsigned audio, I wouldn't try any other image format.

Didn't the Chromium team repeatedly close the JPEG XL feature request without comment, and the beta support was removed by devs who work for WEBP?

[1] https://news.ycombinator.com/item?id=36213330 (2024)

[2] https://news.ycombinator.com/item?id=39250938 (2023)

Related: https://jpegxl.info/

And why this format should be more-supported than currently: https://jpegxl.info/why-jxl.html

Considering how much stuff it seems to want to support, I wonder how much software will actually support it correctly to specification. This seems like the USB-C of image file formats.

Some people want to work exclusively with classic 8-bit-color-depth SRGB. And other people need the HDR and color space stuff.

Combining both use cases into one format makes the API more complicated. There are some footguns in the compression API for people trying to do the most basic task (SRGB to YCbCr Lossy VarDCT), where if you specify the wrong value in a struct somewhere (I think it was the "Use Original Profile" flag), you get poor quality compression, as it stores the image as RGB rather than going to YCbCr first. Yes, I know I used the API incorrectly.

WEBP had a much simpler API. You just call a few functions to get the dimensions of the image, then you allocate a 24-bit or 32-bit buffer (either RGB or BGR byte order) to load the image into.

Reply on news.ycombinator.com