Comment by CharlesW | Hacker News Reader

Comment by CharlesW | Hacker News Reader

Parent Full thread

JXL's war is not with AVIF, which is already a de-facto standard which has near-universal browser support, is enshrined as an Apple image default, will only become more popular as AV1 video does, etc. It's not going anywhere.

That's not to say that JXL is bad or going away. It currently has poor browser support, but it's now finding its footing in niche use cases (archival, prosumer photography, medical), and will eventually become ubiquitous enough to just be what the average person refers to as "JPEG" 10 years from now.

To address selected claims made in the post:

• "AVIF is 'homegrown'" – AVIF is an open, royalty-free AOMedia standard developed by the Alliance for Open Media (Google, Microsoft, Amazon, Netflix, Mozilla, etc.).

• "AVIF is 'inferior'" – AVIF is significantly better than JPEG/WebP in compression efficiency at comparable quality, and comparable with JXL in many scenarios.

• "AVIF is ridiculous in this aspect, capping at 8,193×4,320." — JXL's theoretical maximum image size is bigger. The author cites AVIF's Baseline profile (think embedded devices), but AVIF supports 16,384×8,704 per tile. It HEIF container format supports a grid of up to 65,535 tiles (so logical images sizes up to 1,073,725,440 wide or 283,111,200 tall).

So, JPEG XL is good. Yes, it's far behind AVIF in terms of adoption and ecosystem, but that will improve. AVIF is likely to erase any current JXL quality advantages with AV2, but both JXL and AV1/AV2 encoders will get better with time, so they're likely to be neck-and-neck in quality for the foreseeable future.

Yes AVIF is better at compressing than jpeg and even webp, that should be taken for granted given its a newer format. But no its not remotely competitive with JXL, the only benchmarks it trades blows are ones with laughably low quality settings beyond what any user would ever use. Real world usage paints a very different picture.

JXL not only has better compression rates at equivalent qualities for sane settings, it does so with faster encoding and decoding, while also supporting progressive decoding leveraging image saliency.

AV2 might bring it closer on par with JXL in compression but to suggest they're at all equal is a joke.

> Yes AVIF is better at compressing than jpeg and even webp, that should be taken for granted given its a newer format.

Yes, and it turns out that "somewhat better compression efficiency" basically doesn't matter. The ecosystem matters a lot, though — Apple's support of JXL in ProRAW moved the needle 1,000× more than whatever efficiency advantages JXL may have.

A couple ecosystem challenges for JXL that I see is that (1) it has no video story and (2) it's five years behind AV1 in terms of having a hardware encode/decode story (I'm assuming it will have one), and by that time it'll be competing with AV2.

> AV2 might bring it closer on par with JXL in compression but to suggest they're at all equal is a joke.

They're apples and oranges, which is part of my frustration about the post we're discussing. The industry has clearly aligned behind AV1 as a universal, open, royalty-free image/video distribution format, and is now working on version 2 (AV2). That all happens regardless of JXL's fortunes.

I firmly believe that JXL will find "conscious success" as an authoring and intermediate file format, but that makes it more of a TIFF competitor. For distribution, JXL's "unconscious success" as a distribution format looks like another output format for Cloudflare Images, Cloudinary, Fastly Image Optimizer, etc.

>Real world usage paints a very different picture.

You don't even know how bad is real world usage of image formats. https://preview.redd.it/wga92ab6li4g1.jpeg?width=828&format=...

> But no its not remotely competitive with JXL, the only benchmarks it trades blows are ones with laughably low quality settings beyond what any user would ever use.

At 1080p, a 100k AVIF image is good enough to serve on a webpage. The same image as a 100k JXL will (probably) look unacceptible.

Source: every year or so, I compile the latest encoders and play around with encoding my blog's images with AVIF and JXL. Smaller AVIF images look ok, but the equivalently sized JXL images look way worse, so I gladly serve AVIF. (And before you accuse me of re-encoding lossy to lossy images, most images I test with are game screenshots stored as PNGs.)

I seem to recall that a large part of the stated rationale at the time the Chrome Team decided to deprecate support for JXL was that they had support for both AVIF and JXL, and AVIF was good enough.

This might be the origin of the "competition" in the context of this Google decision/reversal.

> is enshrined as an Apple image default

What? iPhones and other Apple devices take HEIF photos, where does Apple claim AVIF as its image default?

> JXL's theoretical maximum image size is bigger.

This is all fine and good until you actually try encoding such an image with libjxl. What an absolute garbage codebase. I'm sure it's gotten better since I've last used it, but it's impressive how unoptimized, memory hungry, and of course wildly unsafe/crashy it was. Many of the options just completely didn't work, either due to exponential performance, crashes, or weird special-casing that breaks the moment you encode anything that's dissimilar from the sample images used in the sham benchmark made by the libjxl creators. I don't even think a high resolution image had ever been successfully encoded on higher effort levels, since I doubt that anyone trying to do so had the terabytes of RAM required.

I was genuinely flabbergasted when there was mass support for reviving it a couple years ago. I don't think anyone advocating for it has actually used libjxl at all and were just internet hypemen. That seems to happen all too often nowadays.

This all being said, I'm mildly optimistic for a retry with jxl-rs. However, seeing much of the same contributors from libjxl on jxl-rs does make me quite cautious.

I have no idea what you are talking about. I archive petabytes of space imagery with libjxl on maximum compression, effortlessly.

Reply on news.ycombinator.com