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)
HEIC is barely used and seems very cherry-picked to find something that IS still royalty encumbered.
>Pretty much all modern video/audio/image codecs are
The exact opposite is true. The most popular modern codecs are almost all royalty-free. WebP, AVIF, JXL are all royalty-free. VP9/AV1 are royalty-free. Opus is royalty-free.
I'm not sure why you didn't bother looking this up before commenting but JPEG XL is royalty-free and open source. There were some concerns raised well over a year ago about some specific subset of JXL's compression and they were completely settled and it's a non-issue. Google's decisions have nothing to do with paying royalties or licensing fees.
The commit to add the flag saying JXL was being removed soon was reviewed and approved by James Zern, who also created and authored the commit that actually ripped out the JXL code from Chromium. Zern is one of the co-authors of WebP and is the primary contributor to libwebp.
Firefox has next to zero marketshare (unfortunately and despite my best efforts to get people to use FF). There was never any chance that Mozilla was going to waste their very limited resources attempting to be the early adopters of an image codec when nobody is going to use it on the web until the browser engine with de facto control over the market starts supporting it.
>never any chance that Mozilla was going to waste their very limited resources
Mozilla is many things, but "limited resources" Mozilla is not.
That is if they would stop paying their CEO their entire coffer, anyway.
>be the early adopters of an image codec when nobody is going to use it on the web until the browser engine with de facto control over the market starts supporting it.
The exact opposite mentality was how Firefox and then Chrome usurped the throne from Internet Explorer. Firefox is never going to usurp anything again so long as Mozilla is content to play second and third fiddle.
I'm confused where you got "it was available for years and ignored in popular software" from? Most of the ISO standard was only published last year, with the last bit being published in October 2022. IIRC AVIF is almost ~4 years old by the same standards and WebP is over a decade old.
Adobe has partial support (in Camera RAW) with presumably further support coming considering their website recommends JXL alongside AVIF for HDR images. It's also supported by Affinity Photo 2, Krita, Darkroom, GIMP, ffmpeg, ImageMagick, Paint.net, anything Qt/KDE-based via plugin, Pale Moon, libvips, and almost every third-party image viewer that I've ever used or heard of (nomacs, Irfanview, ImageGlass, xnView, etc.). It also has had vocal support from senior engineers at a variety of companies like Facebook, Shopify, Cloudinary, Intel, Flickr, etc.
My first thought when I heard about JXL several months ago was "oh, a new JPEG-2000?" but I've quickly become a JXL evangelist after reading more about it and then playing around with libjxl myself.
Aside from JPEG 2000, which did in fact gain traction in a few verticals, the grandparent might have also confused it for JPEG-LS (1999), JPEG XR (2009), JPEG XT (2015), or JPEG XS (2019).
Honestly I think the biggest risk to adoption of JPEG XL might be this prior brand dilution.
LOL well that makes much more sense. Hopefully JXL doesn't go the way of JPEG2000 (based on how things have gone thus far and its impressive featureset, I think it might be safe).
More accurately, their justification was based on discredited benchmarks (which used a fairly old-even-at-the-time version of libjxl and IIRC created by the AVIF team)... and the commit to remove support was created by a co-author of WebP who gives talks on WebP and is the primary contributor to libwebp.
The Chromium issue where they made this decision is full of "hardware and software vendors" (Adobe, Serif/Affinity, Krita, Facebook, Shopify, Cloudinary, Intel, Nvidia, the VESA DisplayHDR Chairman) telling them they're making a terrible decision and is one of the most-starred and most-commented-on issues of all time for Chromium.
You certainly have an opinion, but you do also keep leaving out facts that don't particularly support it, both here, and elsewhere.
"and the commit to remove support was created by a co-author of WebP who gives talks on WebP and is the primary contributor to libwebp."
Google also employs two of the co-authors of JPEG XL, who give talks on JPEG XL, and was were two of the primary contributors to libjxl.
The main authors of the JPEG XL specification are Jyrki Alakuijala, Jon Sneyers, and Luca Versari. Jyrki is a Googler. Jon is at Cloudinary. Luca is also at Google.
If you are going to try to come up with a silly conspiracy about this being WebP related, it probably would help if this wasn't the case.
Maybe consider that they do in fact have the expertise necessary to decide whether JPEG-XL is something they want to do?
I mean, seriously. You can disagree with the decision, but your argument that they have no idea what they are doing WRT to JPEG-XL seems pretty silly - the only company who arguably has any better idea would be cloudinary.
Phrasing this like "well Google must know best because they employ some subset of the people that worked on JXL" when the entire rest of the industry has been very overwhelmingly pro-JXL isn't very convincing.
Also my point wasn't "Google doesn't know what they're doing", it's that internal politics at Google are probably a factor in them basically being the only opposition to a standard that has been gaining support significantly faster than WebP or AVIF (both much older formats at this point) ever did.
»they do in fact have the expertise necessary to decide whether JPEG-XL is something they want to do?«
The problem is that they do have the people with expertise but those were not asked. For example, the AVIF team at Google does not have the expertise — they have proven that publicly (there was a AVIF vs JXL comparison thing that got put out) and later on an response they gave to Sneyers (the response got shared on Discord).
"Thank you everyone for your comments and feedback regarding JPEG XL. We will be removing the JPEG XL code and flag from Chromium for the following reasons:
- Experimental flags and code should not remain indefinitely
- There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL
- The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default
- By removing the flag and the code in M110, it reduces the maintenance burden and allows us to focus on improving existing formats in Chrome"
The issue on the Chromium tracker is now one of the most-starred and most-commented-on of all time because people from all over came to tell Google that they're insane, from Intel to Adobe to Facebook to Krita to Cloudinary to Shopify to Serif/Affinity to the VESA DisplayHDR Chairman.
It may also be worth noting that the author of commit to remove support from Chromium appears to be a WebP co-author, having given talks about WebP and being the primary contributor to libwebp.
WebP and libwebp/cwebp is such a clusterfuck. Lossless mode isn't even visually lossless because cwebp doesn't understand how PNGs encode color space information. Default lossy settings are extremely garbage for darker (parts of images) images - a problem that has plagued video codecs (which is what webp is based on) for a long time. Animated webp is ridiculously inefficient compared to webm and really shouldn't be a thing at all in favor of allowing silent+looping videos in image tags. And of course initial webp browser implementations don't even support animated webp but still claim support for image/webp so you can't even do progressive enhancement from gif to animated webp without hardcoding which browsers support what.
At this point it should really just be deprecated in favor of JPEG XL. And let's skip AVIF completely please.
100% agree. I'd say JXL is going to be the closest thing we get to a universal image format for quite some time. Almost completely superior to JPEG/PNG/GIF/WebP/etc. and clearly superior to AVIF in basically every way except very low bitrates and animation (which... just use HTML5 video with AV1 webms, what are you even doing?).
Oh, and adoption rates, but considering JXL's standard was finalized less than a year ago and it's already gotten support in so many things and from so many large companies, I really don't see any way that it fails other than Google abusing their monopolistic position in the browser engine space. The people arguing against adding support for a brand new codec because it doesn't magically have 100% support is circular reasoning and feels very disingenuous considering WebP and AVIF were never held to the same standard.
