I'm only casually following JPEG-XL and my impression from previous reading here on HN was that JPEG-XL was the best solution available for a wide variety of usecases, but it looks like numbers dont match that claim?

▲

adrian_b 5 hours ago | parent | next [-]

JPEG-XL is not the best solution if you want small low-quality images, to reduce your costs for hosting some Web site. AVIF seems appropriate for that goal.

JPEG-XL seems to be the best solution for storing and distributing high-quality images. For myself, I want high-quality images, so JPEG-XL is what matters, both for new images and for compressing the old archives of JPEG images.

While I have my own Web server, it is for private use and not for commercial purposes, so I have no interest in using AVIF to achieve the smallest image sizes, but at a lower quality than I want.

▲

jaffathecake 5 hours ago | parent [-]

Please read the article. All of the comparisons default to "high" quality, according to JXL's own metric.

▲

adrian_b 5 hours ago | parent [-]

Most of the comparisons are not about what I would call "high quality" images.

And the article supports what I have said.

Quotation from the article:

> But JPEG XL catches up at very high quality. Around SSIMULACRA2 85, libjxl's default matches AVIF's default, and at maximum efforts, jixel 'extraslow' is ~6% smaller than AVIF s0. jixel 'slow' is 10–13% smaller than AVIF's default from SSIMULACRA2 80 upwards.

	▲	JyrkiAlakuijala 3 hours ago \| parent \| next [-]
		I believe that: ssimulacra2 85 is rather close to median quality in the internet ssimulacra2 90-95 is rather close to high quality in the internet ssimulacra2 98+ is close to camera quality
	▲	jaffathecake 3 hours ago \| parent \| prev [-]
		'high quality' and 'very high quality' are different things.

▲

mdasen 3 hours ago | parent | prev | next [-]

I think many people disliked Google's control of Chrome blocking JPEG XL rather than it being able to compete on its merits.

JPEG XL also has some big benefits for many use cases like lossless re-encoding and supporting higher resolution. AVIF images have a max size of 8192x4352 last I checked. That's not a problem for web images almost all of the time, but there's certainly uses where you might want more. I think AFIV might be limited to 12bit overall while JPEG XL can do 32bit. Again, is that something many will take advantage of on the web? No, but if it's something you care about it might be really meaningful to you.

Also, if you care about the 90% quality level, JPEG XL often outshines AVIF, but when I'm putting images on the web it's often well below that.

Some of it was bad information. I saw some people saying JPEG XL being way less computationally intensive (even less than WebP) and offering much better compression. Some of it was selective data - do you only test things at 95% quality level and declare a winner?

But I think the big thing is that a lot of people wanted the two formats to succeed or fail based on their merits. I think a lot of people don't like AVIF because it isn't well supported outside of browsers - and there can be a hope that the JPEG name would mean JPEG XL would get the kind of adoption JPEG did.

And it's hard to truly compare formats - or benchmark in general. As the article shows, different JPEG XL encoders offer vastly different performance. And when we're dealing with lossy compression, sometimes it can be a bit of personal preference. At some point, people started enjoying the way that MP3 garbled symbols (the instrument) and that was the sound they expected a symbol to make.

▲

jaffathecake 3 hours ago | parent [-]

> AVIF images have a max size of 8192x4352

This isn't true btw. The format supports up to 64k x 64k, although browser decoders currently fail beyond 16k x 16k.

Not sure when you'd serve something like that on a web page though.

	▲	gary_0 6 minutes ago \| parent \| next [-]
		> coded image items compliant to the AVIF Baseline profile may not have a number of pixels greater than 8912896, a width greater than 8192 or a height greater than 4352. https://aomediacodec.github.io/av1-avif/#profiles I'm assuming if both the encoder and decoder support more than the baseline profile, then higher resolutions up to 64k x 64k are possible, although I would worry the file would be incompatible with some software.
	▲	pixelesque 2 hours ago \| parent \| prev [-]
		It's been a few years since I last tried, so hopefully no longer an issue, but trying to encode 8192 × 5464 images from a Canon R5 a few years ago with libavif, and avifEncoderAddImage() would return a generic error. If I reduced the res a bit, then it worked, so there did seem to be a limit there somewhere. height and width are stored as u32s internally though, so yes, the format itself technically supports it... I never looked into it more, so might have been a libavif issue, or maybe the way I was using it (maybe it has defaults or profiles?)

▲

kps 4 hours ago | parent | prev | next [-]

> for a wide variety of usecases

For a wide variety of usecases, not for every isolated usecase. Today, AVIF is better for showing people ads^W^W^W web content delivery. This article is titled “JPEG XL vs. AVIF for web use-cases”. The other article recently discussed¹ is subtitled “Investigating JPEG XL's place as a Web image codec” and ends:

> JPEG XL isn't useless; it is genuinely compelling technology for use cases beyond the Web.

¹ https://news.ycombinator.com/item?id=49690554

(Either way, can we agree to take webp out behind the barn?)

▲

jaffathecake 6 hours ago | parent | prev | next [-]

Claims around JPEG XL have always been wild. E.g. this from one of the creators https://x.com/jyzg/status/1592811472073416704

	▲	bitpush 6 hours ago \| parent [-]
		That's.. horrific. How can someone be this out of touch?

▲

throw0101c 6 hours ago | parent | prev | next [-]

JPEG-XL can be a quick win since it is possible to do a transcode of all of your existing ('classic') JPEG files with zero (visual) losses in quality.

▲

venusenvy47 3 hours ago | parent | next [-]

I always think of transcode and lossless as opposites. How is this achieved in this format?

	▲	ksec 3 hours ago \| parent [-]
		It extracts the already quantized DCT coefficients and related data from the JPEG bitstream and re-encodes them with JPEG XL’s more efficient entropy coding and container, Think of it as zip compression that is specially designed for JPEG and putting the JPEG data in a different/better container.

▲

bitpush 6 hours ago | parent | prev [-]

If you're transcoding why wont you go to avif or another one? If jpeg -> jpeg-xl uniquely better?

	▲	pwg 6 hours ago \| parent [-]
		JPEG is a lossy format. JPEG -> AVIF adds a second loss operation. JPEG to JPEG-XL is lossless but with a smaller file size. So one does not further degrade the jpegs beyond what they were already degraded in creating them in the first place.

▲

ksec 3 hours ago | parent | prev [-]

AVIF ( or even AV1 itself ) has had massive increase in quality improvements over the past 6 years. JPEG XL was close to release in 2020 and finalised in 2021. A lot of the sentiments hold true back then.

JPEG XL has always been targeting high quality encoding metric first before the lower end low BPP images, which AV1 excels at with or without the last 6 years of improvements.

The current top comments about MP3 and LAME is again about how encoder extract maximum potential. JPEG XL was may be the best in 2021, but has been fighting for survival since then.

There a lot of different images that JPEG XL encode better. Screenshots with text is known to be not something they have optimised for or think it could be good at. Lossless mode may be better. Edit: As one of the other comment here proved my point.

Had all of these, even just a hint of AVIF improvement be told, may be the sentiments would have been a little different. But then again I am not one who would trust the same people who sold me WebP and AOM roadmaps.

But at least AV2 is coming. And JPEG XL is finally in every browser. Hopefully we can all have something even better in the future.