So 2^32 bit depth? 4 bytes seems an overkill.
Sorry I missed. How is the "floating point" stored in .jxl files?
Float32 has to be serialized one way or another per pixel, no?
The crudest is downsampling the chroma channel, which makes no sense whatsoever for digital formats.
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?
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 don't know if JPEG XL constrains solutions to be smooth.
kiicia•2h ago
homebrewer•2h ago
Maybe there's a reason they're not bothering with supporting xl besides misplaced priorities or laziness.
Retric•2h ago
Google citied insufficient improvements which is a rather ambiguous statement. Mozilla seems more concerned with the attack surface.
formerly_proven•1h ago
For the same reason it would be good if a future revision of PDF/A would include JPEG XL, since it doesn't really have any decent codecs for low-loss (but not losless) compression (e.g. JPEG sucks at color schematics/drawings and losless is impractically big for them). It did get JP2 but support for that is quite uncommon.
OneDeuxTriSeiGo•2h ago
Mozilla is more than willing to adopt it. They just won't adopt the C++ implementation. They've already put into writing that they're considering adopting it when the rust implementation is production ready.
https://github.com/mozilla/standards-positions/pull/1064
masklinn•2h ago
mistercow•2h ago
masklinn•1h ago
OneDeuxTriSeiGo•1h ago
> To address this concern, the team at Google has agreed to apply their subject matter expertise to build a safe, performant, compact, and compatible JPEG-XL decoder in Rust, and integrate this decoder into Firefox. If they successfully contribute an implementation that satisfies these properties and meets our normal production requirements, we would ship it.
That is a perfectly clear position.
m-schuetz•2h ago
mistercow•1h ago
kouteiheika•1h ago
archerx•1h ago
OneDeuxTriSeiGo•1h ago
mistercow•1h ago
This sounds a lot like how I used to think about unit testing and type checking when I was younger and more naive. It also echoes the sentiments of countless craftspeople talking about safety protocols and features before they lost a body part.
Safety features can’t protect you from a bad programmer. But they can go a long way to protect you from the inevitable fallibility of a good programmer.
drob518•1h ago
kouteiheika•3m ago
[1] - https://www.chromium.org/Home/chromium-security/memory-safet...
OneDeuxTriSeiGo•1h ago
That's a perfectly reasonable stance.
demetris•1h ago
Some links from my notes:
https://www.phoronix.com/news/Mozilla-Interest-JPEG-XL-Rust
https://news.ycombinator.com/item?id=41443336 (discussion of the same GitHub comment as in the Phoronix site)
https://github.com/tirr-c/jxl-oxide
https://bugzilla.mozilla.org/show_bug.cgi?id=1986393 (land initial jpegxl rust code pref disabled)
In case anyone is curious, here is the benchmark I did my reading for:
https://op111.net/posts/2025/10/png-and-modern-formats-lossl...
gcr•12m ago
AlienRobot•1h ago