It seems to me that AV1 (the codec used in AVIF) has seen a lot more development in recent years, by virtue of being widely adopted for video. JPEG XL has not seen comparably massive adoption, perhaps owing in large part to Chrome rejecting it on dubious grounds (in spite of eagerly forcing the adoption of both WebP and AVIF earlier on). The pace of the reference implementation’s development has grown very slow, and most of the modest attention it’s been getting seems to have recently moved to the new Rust decoder, once the browsers finally made up their mind that’s what they wanted from the devs.
That considered, I don’t think it’s a fair comparison between the codecs. JPEG XL used to be far more impressive than AVIF; it’s great people (author included) have managed to push AVIF forward, but until similar efforts have been made for JPEG XL in earnest, I don’t feel like a comparison between their encoders says much about the codecs themselves. The author does take a guess on how much the JXL encoder could be improved, but that’s just that: a guess. It won’t be know until it’s been tried. And especially given the whole unfortunate history, I think JPEG XL really, really deserves a try.
It is getting its try, actively, in libjxl. People like to pretend AV1 got infinite resources; the reality is myself and one other contributor produced the vast majority of the image gains. I built Iris-WebP and aperture-alpha myself, from scratch. As a compression engineer, I think JXL is way, way harder to work with, and it would've taken me a lot longer. libjxl has community contributors, it is just an uphill battle with a codec like that. Same as WebP is an uphill battle due to its format restrictions.
That’s the thing, though: libjxl development hasn’t seemed all that active in recent years. The community contributors you mention seem quite far from driving the development, and some of them say that the usual devs have been busy with other projects (including jxl-rs as of recently).
> People like to pretend AV1 got infinite resources
I would not suggest that, but in another comment here you yourself say that SVT-AV1 (which you compare to JXL favourably in your article) has seen active involvement from ‘Meta, Netflix, Intel, independent contractors, and others’ – not to the community fork SVT-AV1-PSY and its successors contributing their improvements back upstream.
I can believe that JXL may very well be more difficult to work with, but am I wrong to assume you’ve been able to continuously focus on your own encoder (and apply your experiences from your earlier work on SVT-AV1)?
I think libjxl's development is stalled because the format is hard to work with. It wasn't super hard to drive meaningful improvements to AVIF.
Yes, SVT-AV1 received and continues to receive development efforts from devs at big companies, but the number of core contributors has always been somewhat small. Definitely more resources, but the entirety of the original AVIF work was done by two people.
I'm able to utilize my experiences generally in image coding to work on my encoders. This should translate to JPEG XL, but I feel held back by how algorithmically complex compelling implementations of the coding tools would be, and how to make those implementations fast. I think if the JPEG XL spec was incredibly intuitive, community contributions would have gotten it a lot further. Heck, my own efforts may have gone to it instead of SVT-AV1-PSY's AVIF encoding.
Wasn't that also basically one guy from the VLC/ffmpeg community that drove that effort? I think they got funding from Netflix to do it again on ARM after demonstrating the benefits on desktop.
We can reevaluate when and if improvements are made. The problem with statements like this, is its really easy to miss the showstoppers when imagining what something could be. All plans are amazing until you have to actually do them in the real world.
As the saying goes: Never fall in love with potential.
The stated reason for Chrome was not ‘we need a memory-safe implementation’. It was ‘there is not enough interest’ and ‘there is not enough improvement over AVIF’. At the time, there was interest and there was improvement over AVIF (which Google has decided to support regardless of memory safety, interest, or seemingly any deeper consideration).
Memory safety as a condition for adoption was brought up only years later, and by Mozilla rather than Google. The JPEG XL devs, who’d offered to work on it if there was interest, got to work as soon as interest was proclaimed. You might say it’s a good thing for Chrome to have held off adoption until then, but that’s completely incidental, not because they cared. Near-zero efforts to be fair and responsible were made.
That considered, I don’t think it’s a fair comparison between the codecs. JPEG XL used to be far more impressive than AVIF; it’s great people (author included) have managed to push AVIF forward, but until similar efforts have been made for JPEG XL in earnest, I don’t feel like a comparison between their encoders says much about the codecs themselves. The author does take a guess on how much the JXL encoder could be improved, but that’s just that: a guess. It won’t be know until it’s been tried. And especially given the whole unfortunate history, I think JPEG XL really, really deserves a try.