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?
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?
kiicia•1h ago
homebrewer•1h ago
Maybe there's a reason they're not bothering with supporting xl besides misplaced priorities or laziness.
Retric•1h ago
Google citied insufficient improvements which is a rather ambiguous statement. Mozilla seems more concerned with the attack surface.
formerly_proven•7m 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•1h 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•1h ago
mistercow•1h ago
masklinn•43m ago
OneDeuxTriSeiGo•30m 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•1h ago
mistercow•1h ago
kouteiheika•57m ago
archerx•39m ago
OneDeuxTriSeiGo•34m ago
mistercow•28m 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•20m ago
OneDeuxTriSeiGo•36m ago
That's a perfectly reasonable stance.
demetris•57m 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...
AlienRobot•1h ago