JPEG XL found in wincodec.h – suggesting coming Windows support(twitter.com)
twitter.com
JPEG XL found in wincodec.h – suggesting coming Windows support
https://twitter.com/teroalhonen/status/1750957377292062735
8 comments
Why can’t Jpeg come up with a new standard that’s so much better than the current ones that people will have to adopt it instead of something that’s maybe slightly better in some circumstances…
Jpeg XL is the so much better codec. It's not being adopted everywhere because the guy behind webp format blocked it from Chrome.
I'd like to propose that Chrome removed JPEG XL because of the reasons that they wrote about at the time of the removal.
---cut---
Helping the web to evolve is challenging, and it requires us to make difficult choices. We've also heard from our browser and device partners that every additional format adds costs (monetary or hardware), and we’re very much aware that these costs are borne by those outside of Google. When we evaluate new media formats, the first question we have to ask is whether the format works best for the web. With respect to new image formats such as JPEG XL, that means we have to look comprehensively at many factors: compression performance across a broad range of images; is the decoder fast, allowing for speedy rendering of smaller images; are there fast encoders, ideally with hardware support, that keep encoding costs reasonable for large users; can we optimize existing formats to meet any new use-cases, rather than adding support for an additional format; do other browsers and OSes support it?
After weighing the data, we’ve decided to stop Chrome’s JPEG XL experiment and remove the code associated with the experiment. We'll work to publish data in the next couple of weeks.
For those who want to use JPEG XL in Chrome, we believe a WebAssembly (Wasm) implementation is both performant and a great path forward.
---cut---
---cut---
Helping the web to evolve is challenging, and it requires us to make difficult choices. We've also heard from our browser and device partners that every additional format adds costs (monetary or hardware), and we’re very much aware that these costs are borne by those outside of Google. When we evaluate new media formats, the first question we have to ask is whether the format works best for the web. With respect to new image formats such as JPEG XL, that means we have to look comprehensively at many factors: compression performance across a broad range of images; is the decoder fast, allowing for speedy rendering of smaller images; are there fast encoders, ideally with hardware support, that keep encoding costs reasonable for large users; can we optimize existing formats to meet any new use-cases, rather than adding support for an additional format; do other browsers and OSes support it?
After weighing the data, we’ve decided to stop Chrome’s JPEG XL experiment and remove the code associated with the experiment. We'll work to publish data in the next couple of weeks.
For those who want to use JPEG XL in Chrome, we believe a WebAssembly (Wasm) implementation is both performant and a great path forward.
---cut---
They did. It's called JXL. JXL is clearly technically superior to WebP and AVIF and the decisions from the Chromium team (not even Google as a whole, since they have a Google Research team working on JXL encoders/decoders) have faced a ton of criticism because they're vague and mostly false and seem to be based on internal politics and Chromium being able to dictate web standards due to having de facto control over the browser engine market.
Looks like it maybe gives 10% better quality? Meh... that's the reason why nothing will come of this in the end. Come back when you have something 50% better
I mean, you realize that there are mathematical limits to how much you can compress information, right? And WebP/AVIF didn't achieve anywhere near 50% and were adopted by the Chromium team without issue because a few of them actually MADE those codecs/formats.
JXL has better compression than AVIF (by 10-15% on average) and WebP (by 20-25% on average and the latest JPEG encoders like MozJPG (by 30-35%). It also encodes well (even the AVIF devs admitted that JXL was "faster across the board with single-core encode and decode speeds and is more parallelizable than AVIF" in a since-deleted official blog post), which is extremely important.
You can convert existing JPEGs for ~20% savings and the process is lossless and reversible. You can also lossily convert existing JPEGs for even more while still targeting a visually-lossless quality.
It also has progressive decode, which is extremely valuable to anyone hosting web images since JXL can deliver a full-image preview thumbnail from the sole, full-quality JXL file by only sending 15-20% of the total size. This can be tuned to target things like faces or foreground objects. WebP and AVIF do not support progressive decode and thus a separate, additional, low-quality thumbnail copy must be encoded + stored + delivered.
It has 4099 additional channels (vs. WebP's 4 and AVIF's 5) which can be used for things like selection masks, spot colors, etc. There have been posts from researchers in other interesting fields such as bio/medical tech for storing additional imagining data in these channels.
The max resolution limits are over a billion pixels on each side, whereas WebP is 16k and AVIF has either a) surprisingly low limits if being used in lossless mode or b) lower limits than JXL but at least more reasonable if you're willing to suffer visual artifacting on the boundaries of some tiling technique it uses.
JXL has a max bit depth of 32 vs. WebP's 8 (no HDR support) or AVIF's 12.
Support for overlays/layers, depth maps, 4:4:4 lossy (AVIF can do these but WebP cannot).
Much better generation loss resistance than JPEG/WebP/AVIF.
The tiniest header (12 bytes, smaller than AVIF/WebP/JPEG/PNG/GIF with AVIF being easily the worst of them all at 298 bytes).
> That's why nothing will come of this in the end.
I highly doubt that, considering the incredible level of support and interest it's received from large corporations even though it only finished standardization a bit over a year ago. Codec adoption doesn't happen overnight, but JXL has progressed WAY faster than WebP or AVIF did in my experience. It already has support in macOS/iOS/Safari, Adobe products, Serif Affinity products, GIMP, Krita, Paint.NET, Darktable, ffmpeg, ImageMagick, libvips, the entire Qt/KDE ecosystem, basically every Linux distro. Samsung added partial support like a week or two ago for the S24 line (you can save using its RAW format and compression and the Samsung Gallery app can obviously decode and view those) and Windows is apparently adding support to WIC based on leaks from like a week ago, which means native support in Windows (including Explorer and the default Image Viewer, although basically every third party viewer of note has also had JXL support for over a year now).
There are forks of Chromium (Thorium) and Firefox (Waterfox and Pale Moon) with support that seems very solid from my basic testing on it months ago. And senior engineers from big web-oriented companies like Facebook, Shopify, and Cloudinary and other tech companies like Intel and nVidia expressed their support for JXL and disappointment with the Chromium team's poorly-justified decision to abandon JXL support.
All that and Google Research has people actively working on JXL encoders/decoders. It really is just the Chromium team blocking things (and Firefox saying they're neutral and just sitting there on the sidelines because no serious website is going to deliver JXL content without Chromium's dominant userbase having support and Mozilla doesn't necessarily have the resources to spend on what would solely be a political statement).
(sorry for ranting, but I actually feel like JXL is actually the next "universal image format" for years to come in a way that I never did about shit like JPG2000, WebP, or HEIF/HEIC or AVIF, once the rest of the tech industry gets around to removing the Chromium teams' head from their ass)
JXL has better compression than AVIF (by 10-15% on average) and WebP (by 20-25% on average and the latest JPEG encoders like MozJPG (by 30-35%). It also encodes well (even the AVIF devs admitted that JXL was "faster across the board with single-core encode and decode speeds and is more parallelizable than AVIF" in a since-deleted official blog post), which is extremely important.
You can convert existing JPEGs for ~20% savings and the process is lossless and reversible. You can also lossily convert existing JPEGs for even more while still targeting a visually-lossless quality.
It also has progressive decode, which is extremely valuable to anyone hosting web images since JXL can deliver a full-image preview thumbnail from the sole, full-quality JXL file by only sending 15-20% of the total size. This can be tuned to target things like faces or foreground objects. WebP and AVIF do not support progressive decode and thus a separate, additional, low-quality thumbnail copy must be encoded + stored + delivered.
It has 4099 additional channels (vs. WebP's 4 and AVIF's 5) which can be used for things like selection masks, spot colors, etc. There have been posts from researchers in other interesting fields such as bio/medical tech for storing additional imagining data in these channels.
The max resolution limits are over a billion pixels on each side, whereas WebP is 16k and AVIF has either a) surprisingly low limits if being used in lossless mode or b) lower limits than JXL but at least more reasonable if you're willing to suffer visual artifacting on the boundaries of some tiling technique it uses.
JXL has a max bit depth of 32 vs. WebP's 8 (no HDR support) or AVIF's 12.
Support for overlays/layers, depth maps, 4:4:4 lossy (AVIF can do these but WebP cannot).
Much better generation loss resistance than JPEG/WebP/AVIF.
The tiniest header (12 bytes, smaller than AVIF/WebP/JPEG/PNG/GIF with AVIF being easily the worst of them all at 298 bytes).
> That's why nothing will come of this in the end.
I highly doubt that, considering the incredible level of support and interest it's received from large corporations even though it only finished standardization a bit over a year ago. Codec adoption doesn't happen overnight, but JXL has progressed WAY faster than WebP or AVIF did in my experience. It already has support in macOS/iOS/Safari, Adobe products, Serif Affinity products, GIMP, Krita, Paint.NET, Darktable, ffmpeg, ImageMagick, libvips, the entire Qt/KDE ecosystem, basically every Linux distro. Samsung added partial support like a week or two ago for the S24 line (you can save using its RAW format and compression and the Samsung Gallery app can obviously decode and view those) and Windows is apparently adding support to WIC based on leaks from like a week ago, which means native support in Windows (including Explorer and the default Image Viewer, although basically every third party viewer of note has also had JXL support for over a year now).
There are forks of Chromium (Thorium) and Firefox (Waterfox and Pale Moon) with support that seems very solid from my basic testing on it months ago. And senior engineers from big web-oriented companies like Facebook, Shopify, and Cloudinary and other tech companies like Intel and nVidia expressed their support for JXL and disappointment with the Chromium team's poorly-justified decision to abandon JXL support.
All that and Google Research has people actively working on JXL encoders/decoders. It really is just the Chromium team blocking things (and Firefox saying they're neutral and just sitting there on the sidelines because no serious website is going to deliver JXL content without Chromium's dominant userbase having support and Mozilla doesn't necessarily have the resources to spend on what would solely be a political statement).
(sorry for ranting, but I actually feel like JXL is actually the next "universal image format" for years to come in a way that I never did about shit like JPG2000, WebP, or HEIF/HEIC or AVIF, once the rest of the tech industry gets around to removing the Chromium teams' head from their ass)
[deleted]
It's good to see Jpeg XL support in Windows, but unfortunately it probably won't become a widespread standard until it becomes available in Chrome (again)
[1]: https://learn.microsoft.com/en-us/windows/win32/api/wincodec... [2]: https://learn.microsoft.com/en-us/windows/win32/api/_wic/