HN Reader

> JPEG XL’s Radical Solution: Float32 + Perceptual Intent

So 2^32 bit depth? 4 bytes seems an overkill.

The original JPEG XL requirements were relational colors, where colors are an issue external to the codec. I was able to sufficiently convince the rest of the jpeg committee that we can achieve similar interoperability with absolute color, and particularly my xyb color space, and the absolute color storage giving us more opportunity to psychovisual optimization. Also, I was behind not having 8, 10, 12 bit modes, but just a single mode, and always yuv444 — to simplify operation and creating less confusion and less hard additional quality boundaries. Some of this "beauty" such as no yuv420 we needed to backtrack from for adding the lossless jpeg1 recompression support.

Yes, this is great, but why don't we make the same argument for resolution too? I think we should!

When exporting images from Lightroom Classic in JPEX XL you can choose the percent of compress or choose lossless which disable that of course. But also default to 8bit, but an option for 16bit which of course results in a much larger file. And color profile setting. So curious what they mean by it ignores bit depth?

Did some sample exports comparing JXL 8bit lossless vs JPG and JXL was quite a bit bigger. Same for doing lossy 100 comparison or 99 comparison of both. When setting JXL to 80%, 70% see noticeably savings but had thought the idea was JXL full quality essentially for much smaller sizes.

To be fair the 70% does look very similar to 100% but then again the JPEG 70% vs 100% also look very similar on an Apple XDR Monitor. the 70% or 80% etc on both jpeg and jpeg xl i do see visual differences in areas like on shoes where there is mesh.

JXL comes with lots of compatibility challenges since while things were picking up with Apple's adoption it seems to have halted since and apps like Evoto, and Topaz not adding support among many others. And Apple's still not full support and no progress on that. So unless Chrome does a 180 again, think AVIF and JXL will both end up stagnating and most sticking with JPG. For Tiff though noticed significant savings lossless jxl compared to tiff so that would be a good use case except tiffs more likely ones to be edited by third party apps that most likely won't support the format.

Working with single fixed bit depth is imho different than being bit-depth agnostic. Same argument could be made about color spaces too.

jpeg xl is fantastic, yet autocratic google wants to force inferior format

Interesting approach. It doesn't even introduce an extra rounding error, because converting from 32-bit XYB to RGB should be similar to converting from 8-bit YUV to RGB.

However, when decoding an 8-bit-quality image as 10-bit or 12-bit, won't this strategy just fill the two least significant bits with noise?

I think the article could be better and get the point across with half the length and without the second half of it being full of ai generated list of advantages, or using that space to give some more technical information

So they "ignore" bit depth by using 32 bits for each sample. This may be a good solution but it's not really magic. They just allocated many more bits than other codecs were willing to.

It also seems like a very CPU-centric design choice. If you implement a hardware en/decoder, you will see a stark difference in cost between one which works on 8/10 vs 32 bits. Maybe this is motivated by the intended use cases for JPEG XL? Or maybe I've missed the point of what JPEG XL is?