Hacker News Reader

Comment by ChrisArchitect | Hacker News Reader

Don't you mean JPEG XL?

JPEG XL vs. AVIF for web use-cases

https://news.ycombinator.com/item?id=50120224

I thought it was pretty well established that JXL has a big room for improvement when it comes to encoders. There are some fundamental limitations wrt the absolute lowest bitrates, but that the room for improvement in encoders is rather substantial, especially with things like rate-distortion search heuristics.

The comparison is more about who has had the most man-hours and megadollars put into encoders quality than about the inherent limitations about the format.

With that said, I use AVIF, but I do have what can be said to be an irrational preference for JXL.

> but I do have what can be said to be an irrational preference for JXL.

Is it irrational to follow the collective "one format to rule them all" dream? Sure, the codec itself needs work, but seeing how long we've been stuck with the JPEG/PNG/GIF trio (even with better encoders like mozjpeg/jpegli or optipng/zopfli) with TIFF as a catch-all backup, getting the format right once and for all really matters.

I'm still weirded by the low amount of workforce in libjxl/jxl-rs; sure, too many cooks do ruin the broth, but too few too, in that domain.

Jpeg-XL's key win was only lossless translation of existing jpeg to a modern format. Mostly for archives where you don't want a lossy translation.

In terms of picture quality for given size, AVIF has it solidly beat.

You could make an argument that we should have AVIF everywhere on the web. But if you want a single image format to be everywhere, I think JPEG-XL is just better suited. AVIF has restrictions on resolutions and number of planes, and doesn't do lossless very well. It's competitive with AVIF on lossy image quality (even though yes, AVIF does seem like it tends to consistently have the advantage there).

Image formats goes in era, and there's no need for monoculture. But given we're talking exabytes of data, for this era, the author rightly articulates why AVIF should win. Should JPEGXL2 beat it in the future then it can take over for a decade. We seem to essentially have gone through like 4 formats so far: gif, jpg, PNG and webp. On vector side, SVG has no real competition - it's solid.

The author is explicitly arguing for an AVIF monoculture. AVIF isn't an appropriate format for an image format monoculture, but JPEG-XL could be.

"We should use AVIF for most web images" is a different statement which I have no problem with.

> But given we're talking exabytes of data, for this era, the author rightly articulates why AVIF should win.

I'm not sure this is the right conclusion to draw...

1) The author's pain point (use case) is hardware pricing - presuming that goes down (as either AI demands drops/and or production increases), this does not speak to a demand for size, instead, it is about doing more with less...

2) I'm not certain that the exabytes of demand (assuming it comes) will be from AVIF. Rather, if data is important, I think the demand will be a different format entirely (archives, for instance). Demand for more (quality) data might paradoxically call for less compression and less cpu-intensive qualities - uncompressed, raw data, for instance. If is faster and cheaper than bothering with complex algorithms, then simpler formats should be more prevalent.

Building on 1 and 2, a more capable image format, like JPEG-XL, becomes a more logical choice, not the one that can compress the best or is the smallest (in an exa-byte-as-the-norm world).

AVIF supports a higher resolution at 2^32-1 pixels per dimension, vs JPEG-XL's 2^30-1 pixels. But really it doesn't matter since something is going to impose an arbitrarily smaller limit on either before letting you try to allocate more RAM than any computer can address. Yes, plenty of comparison websites confuse AV1 limits (sometimes AV1 profile limits!) with AVIF limits.

For arbitrary planes, AVIF calls them auxiliary images. Unless you mean encoding non-RGB data to start with like how DNG uses JPEG-XL. At which point you're outside the scope of any standard interpretation of JPEG-XL data.

> Jpeg-XL's key win was only lossless translation of existing jpeg to a modern format.

Huh?

JpegXL is the only widely supported format (once it comes to the various browser as is planned) that can store true HDR linear images in floating point (fp16 and fp32) formats.

AVIF can only do 10 bit integer ranges, sure that HDR compared to 8bit but it is not sufficient for useful extended range color spaces.

The format is widely supported, but I'd be very surprised if linear HDR becomes widely supported outside of image editors. JPEG-XR supported fp32 linear HDR way earlier anyway, and no one cared because no one cares about linear HDR after editing.

Also AVIF supports up to 12 bits.

> I'd be very surprised if linear HDR becomes widely supported outside of image editors

I added support to ThreeJS last month because Chrome supports linear Jpeg XL with the experimental flag on. The other browsers are expected to follow:

https://threejs.org/examples/webgpu_loader_jpegxl

I don’t feel like the difference matters all that much. Both AVIF and jpeg xl produce reasonably sized files for your personal photo library. What you really care about is capabilities for things like HDR and expanded color spaces which both formats seem to have excellent support for.

Just about anything is better than jpeg these days.

Agree, though I do miss the clarity of if an image is lossy or lossless just by extension. (Obviously a png could be produced from a heavily compressed jpg, but it is still a handy heuristic in my image pipelines)

I think we should come up with a convention for this

Aside from maybe .bmp, that never really existed (though .bmp has palletized colours, I guess?).

Just like you can assume most PNGs to be lossless (despite supporting pallettes, which pngquant uses to "compress" them) and non-animated (despite APNG being over 22 years old), you can assume most AVIF and WebP images are lossy. Same with JXL. HEIF requires a bit of special care (it's only produced by devices with HDR support so your pipeline needs to fit that) but that's pretty much it.

You may get surprised by an accidental, huge lossless AVIF/WebP/HEIF file, but most sources where you can even get these files are all lossy. Unless you recompress your photo library yourself, of course, but then you have full control over the entire process and can decide whether or not you want lossy or lossless.

Reply on news.ycombinator.com