JPEG XL and Google's War Against It
vale.rocks
vale.rocks
The JPEG XL authors make claims about it's superiority over formats like AVIF, but there is no support or even timeline for hardware encode or decode on important platforms like mobile.
By contrast, Qualcomm is adding support for AV1 encoding to Snapdragon X (https://www.qualcomm.com/products/mobile/snapdragon/pcs-and-...) which could lead to efficient encoding of AVIF photos and animations.
I have updated the article with more details about their involvement for transparency.
If you have any information you can share with further information regarding Google's input, I'd open to hear it as evidence of their input as a company beyond preliminary stages has been difficult to find.
---
Regarding JPEG XL's mobile support, it makes sense it would see limited development if the company that manages one of the biggest mobile players has been the greatest restriction on their success. The lack of support also disincentivises manufacturers to prioritise support.
There was literally no involvement from any hardware vendor in the standardization of JPEG XL. It went from a Call for Proposals in Sept 2018 to Committee Draft in Aug 2019 with very little time for industry feedback. Contrast this with AV1 which had involvement from hardware vendors Intel, NVIDIA, Arm, AMD, Broadcom, Amlogic from the beginning as well as companies who ship media on hardware at scale such as Cisco, Netflix, Samsung and yes Google. These companies reviewed and provided significant feedback on the format that made it suitable for hardware implementation.
https://news.ycombinator.com/threads?id=JyrkiAlakuijala is a lead on the project and a Google employee, and active in JPEG XL development https://github.com/libjxl/libjxl/commits?author=jyrkialakuij...
AV1, however, is first and foremost a video format. A very popular one at that. It's perfect for video, and that explains the great industry support. The fact it is the most promising option for video is why it's seen hardware vendor support, not because AVIF is ideal. JPEG XL unfortunately doesn't have this luxury, but still could have done better. This doesn't mean that JPEG XL can't see support now, though, and there are plenty of opportunities for hardware support now it's been proven viable.
While there are certainly employees at Google that have contributed to JPEG XL recently, I'm still yet to see any evidence that the company itself has provided any direct support lately.
Image decoding is nice to have, but less important. When you are deciding to put custom hardware into a device, that's a huge investment in something only useful for that one task. Being compatible with a video format so you can share that hardware between the two tasks is a huge win for hardware manufacturers who get two-for-one, and for the rate of adoption.
With AV1 already very efficient and rolled out in a lot of hardware already, it just has a huge advantage.
AVIF certainly gets the hardware support advantage, but it fails in other regards where JPEG XL shines. Looking at it either way, JPEG XL is far from slow, and I'd argue that the other benefits outweigh that single shortcoming. Bandwidth should also be treated as a consideration, as you mentioned, and JPEG XL generally leads to smaller file sizes.
Realistically, this boils down to AVIF being largely worse than JPEG XL, with the exception of performance. Performance that could be improved for JPEG XL should hardware vendors choose to provide better support.
It feels to me like JPEG XL's advantages are mostly hypothetical, and practically AVIF is the format that has more value. I'm no expert on this, to be clear, but I have yet to be convinced despite all the JPEG XL hype on HN.
The radio(network) on phones can consume more power than the SoC(CPU). Thus smaller size can translate into energy savings.
As to hypothetical advantage, we are talking about HW _potentially_ being used for image decode. AFAIK this does not happen in practice, despite WebP non-lossless being a VP8 frame and the hardware being plentifully available.
As evidence for the advantages of JPEG XL being real, consider the fact that it is increasingly being adopted in serious SW including ACR, Darktable, Krita, and Lightroom.
I can 100% see JXL being adopted in production tools, where the motivations are different, I was mainly talking about the web adoption perspective for end users (which is the context of Google's supposed war on it, of course).
What features are these? You have not named a single concrete advantage. The places where AVIF out-performs JPEG XL are exactly where it make sense as an image format for the web: high fidelity images with bit rates at or below 1 bit/pixel. Nobody is browsing the web on a 16-bit panel and AVIF supports 12bpc images anyway.
Unfortunately, JPEG XL authors chose not include AVIF when they performed a subjective image comparison in 2020 under controlled viewing conditions (https://research.google/pubs/benchmarking-jpeg-xl-lossylossl...), but previous subjective studies showed AVIF outperforming PIK and FUIF over the evaluated bit-rates.
Have you seen this more recent data that includes AVIF? https://cloudinary.com/labs/cid22
The graph from Cloudinary uses libaom to do the encoding at speed preset 7 (aom s7), which is far from speed preset 0 and disables many AVIF coding tools. I do not know why this was chosen by the author, but it does not reflect AVIF performance. According to https://github.com/AOMediaCodec/libavif/issues/440#issuecomm... speed preset 8 loses 20-35% compression efficiency.
Note: the 20-35% is BDrate, which in this context likely(?) involves some form of PSNR, which has almost nothing to do with human perception and IMO should not be used to guide such decisions.
I agree, PSNR is a terrible measure of quality. The study "Benchmarking JPEG XL lossy/lossless image compression" (https://research.google/pubs/benchmrking-jpeg-xl-lossylossle...) which you are an author on included a controlled subjective evaluation done by EPFL using an ITU recommend methodology. The subjective results concluded:
"HEVC with SCC generally results in better rate/distortion performance when compared to JPEG XL at low bitrates (< 0.75), better preserving sharp lines and smooth areas"
It is known that AVIF performs better than HEVC. Can you say why it was not included in your 2020 subjective evaluation? It would be nice to not need to speculate on the relative quality of AVIF v JPEG XL at web bitrates.
Glad we can agree on that. Unfortunately many evals use that or plain SSIM, which is still L2 at heart.
> Encoding speed is not really a concern for web uses
hm, in many discussions with Jon of Cloudinary, I did not get the impression that this is the case. Imagine their enthusiasm about 100x-ing their compute costs.
> Can you say why it was not included in your 2020 subjective evaluation?
The paper's comment on this is: "The selection of anchors is based on the general popularity of the codecs and the availability of the software implementations. We only intended to use codecs which are standardized internationally."
> using an ITU recommend methodology
While this has some helpful guidance on viewing conditions, it is unfortunately still subjective (what parts are observers looking at, what counts as "annoying") and is more useful for detecting severe artifacts, which less relevant in practice because that's hopefully not the quality range people are using.
Also, these results are quite old and both encoders have changed since then.
> need to speculate on the relative quality of AVIF v JPEG XL at web bitrates.
No need to speculate :) Just to first agree on what are actual web bitrates. From Chrome metrics, IIRC it was over 1bpp. Here's some newer data: https://discuss.httparchive.org/t/what-compression-ratio-ran... Even for AVIF, the median is 0.96 and q3 is 1.79(!).
Jon has written several articles on comparisons, including https://cloudinary.com/blog/contemplating-codec-comparisons and https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front#med....
how very convenient, looks like politics outweigh any benchmarking
I have no game in the matter, but as a large website provider perspective, handling millions of images and processing thousands per day, I am glad not to have to deal with yet another format that would double our cache costs and force eternal support on the web. Not everybody has infinite google money to afford any kind of image format existing on the planet, and google can get only so much leeway after poisoning the web with webp.
j2c
Huh? Isn't Apple pro-JPEG XL?
Efficient in what sense? HW encoders usually only explore a fraction of the search space, and in the case of JPEG often result in 3..5 bit per pixel images.
Other people and organizations can disagree with your arguments in ways that you don't think are logical or sound, but that doesn't mean they aren't just based on different weights and criteria. It's not useful to assume the decision criteria, because it becomes too easy to declare yourself right yet be confused why other people don't recognize it.
Never simply attribute to malice what can be explained by incompetence, but also never simply attribute to incompetence what can be explained by disagreement.
I don't see any assumptions about Mozilla's motive, or think it would be relevant to assume motive one way or another. The assumption is that Mozilla has power to help fuel JPEG XL adoption, so that pressure wouldn't simply be wasted.
Now, I'm not sure it has this power given its 3% browser market share. This might invalidate the particular argument.
That said, there are many valid reasons to give Mozilla execs grief, and many valid reasons to work to deconstruct Mozilla's leadership. So I don't mind if people do it over JPEG-XL, even if Mozilla's had zero power to affect JPEG-XL.
They do have support in Firefox Nightly behind a flag, but it is disappointing they don't take a stronger stance. Firefox is really a shell of its former self due to Mozilla's handling of it in recent years, which is a real shame.
Bullshit. You have zero hard evidence to back that up.
WebP has been created in the rush of wild optimism after Google has freed the VP8 video format (WebM). VP8 has been strategically important for them (and YouTube), because before then Web video has been at mercy of Flash, Silverlight, and threatened by H.264 patent royalties.
The WebP format has been rushed. It didn't go through a usual standards process. The VP8 codec turned out to be not so great, especially poor for still images. VP8 has lost to H.264, and meanwhile Cisco has found a loophole to sponsor H.264 royalties for all browsers.
Other vendors have rejected WebP, partly because it was a non-standard Google's own thing (uncool move at a time when WHATWG was at its peak), but mainly because it just wasn't good enough, compared to optimized JPEG (Mozilla created MozJPEG to prove the point). Their bar for adoption is very high, since they're worried about maintaining things forever, bug-compatibility issues from a single implementation, increased code size, and attack surface.
Mozilla and Safari have been resisting adoption of WebP for about 10 years. They've relented not because WebP got a "stable release" (total nonsense in the article), but because their bug trackers kept getting reports of Chrome-only websites and buggy HTTP content-negotiation that kept serving them "broken" images, to the point it started hurting their compatibility and costing them users.
----
With AVIF we've had the repeat of the video rush. Web has been once again been threatened by commercial H.265, with even messier and more expensive licensing, and no Cisco loophole this time. Browser vendors have banded around and adopted AV1 format ASAP to prevent dominance of H.265 on the Web.
And just like WebP has been riding adoption of VP8, AVIF was riding on adoption of AV1. And once again, a video codec turned ot to be suboptimal for still images. Browsers didn't really care about adopting any image format. They cared about adoption of AV1 video, and AVIF got a pass only because it was almost for "free" (it's basically a 1-frame video file).
(BTW, AV1 is based on VP10 + contributions from other vendors. This kinda makes it a descendant of WebP.)
So from the perspective of browser vendors not really wanting any new image format, and getting one anyway, and AVIF being good enough to not need an urgent replacement, there's simply no appetite left for adopting yet another format. Browser vendors still don't like adding more code, and are still afraid of compatibility issues and attack surface.
The conspiracies about money and power are hilarious.