3 ms·
It’s getting better, and this trend has seriously accelerated in the last months – my anecdotal observations. libvips has now good support for jxl, it has (sin
by illiac786 2y ago
It’s getting better, and this trend has seriously accelerated in the last months – my anecdotal observations.
libvips has now good support for jxl, it has (since 8.16) support for EXIF data in jxl files as well. All FOSS projects can now use this to kickstart their jxl support.
In the corporate world, well, we’re all waiting for Google (Chrome) and microsoft (Windows) basically. I think the rest is on board, Apple, Adobe, etc.
- BlackFingolfin 2y agoChrome removed support for JPEG XL last year, see e.g. https://arstechnica.com/gadgets/2023/04/free-software-group-decries-google-dropping-space-saving-jpeg-xl-format/ https://arstechnica.com/gadgets/2023/04/free-software-group-...
- illiac786 2y agoSept. 3rd: > 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 https://github.com/mozilla/standards-positions/pull/1064 https://github.com/mozilla/standards-positions/pull/1064
- thisislife2 2y agoShame that Mozilla is giving in to Google. It just looks like a delaying tactic - they don't want JPEG-XL to become popular because once JPEG-XL reaches a particular threshold of adoption, other similar encoding formats won't be able to compete with it.
- illiac786 2y agoI agree on the “shame” part, also I do not get why it has to be yet another encode, there already is one Rust even, jxl-oxide. Why not take this one and expand it or improve it?… On the delaying tactic, you might be right, I want to be cautiously optimistic =)