On that demo page if I switch between the original, jpeg, webp, and avif tabs, the colors shift visibly. I have an AdobeRGB wide-color-gamut monitor configured in 10-bit mode, use Firefox with color-management enabled, and I have the AdobeRGB profile correctly set in Windows.

It is incredible to me that in 2021 the web makes it impossible to get even vaguely correct colours onto a screen.

I don't know who's to blame here: Web standards bodies, Mozilla, or the specific AVIF decoder.

But I do know that color-blind people are creating the next generation of imaging standards.

Hey! Leave us out of it. I can see the differences, too. The folks to blame aren’t colorblind. They are color indifferent. :-)

Huh, must depend what type of colour-blindness, and/or how severe, as I can't tell any difference in colour whatsoever.

I am red-green colorblind. I was able to see the changes on the yellow car drawn by SVG. If there were lots of other changes, I couldn’t see those.

Given the original (lossless AVIF) and AVIF tabs match up and the others differ, I wonder if things went wrong with converting to the other formats? I don't have the time to look into the detail here right now, but it could simply be a case of the conversion between the formats losing the the colour space data from the image?

The one group highly unlikely to blame here is web standards bodies, who don't have anything to do with how image formats are rendered (it gets as far as defining the default colour space when none is provided, but that's it). But I'd guess it's likely an image file problem rather than a display problem.

> The one group highly unlikely to blame here is web standards bodies

I'm pretty sure I can blame a web standards body for not standardising colour management for the web!

The colour space of embedded images is no longer the only concern, and is not separate from the colours as defined in CSS, SVG, and Canvas to name a few.

Not to mention that even greyscale images need colour management because Macs, PCs, and Televisions all use different gamma curves.

W3C's efforts have been so underwhelming that Apple, the "bastion" of web standards support has been forced to come up with a non-standard extension: https://webkit.org/blog/10042/wide-gamut-color-in-css-with-d...

Of course, their extension supports exactly two colour spaces: sRGB and Display P3, because fuck everyone else who isn't using an iDevice or a Mac, am I right?

If I sound salty, it's because I'm a photographer, and as such it grinds my gears that it is literally impossible to use wide-gamut images on the web for any purpose without degrading quality for a substantial fraction of the viewers. I fully expect this to be resolved satisfactorily some time in the 2030s, perhaps the 2040s. Any decade now...

As a former photographer, I agree.

I found this article on fidelity vs appeal handy, especially to illuminate the problems with AVIF's algorithm when you are showing off photos.

https://cloudinary.com/blog/what_to_focus_on_in_image_compre...

I'm waiting for JPEG-XL. And then color management after that.

W3C? Isn't WHATWG the standard that everybody follows?

Yes but also sort of no? It's a whole can of worms, which Web standard is done by who

I think we need a standard to specify which standards organisation to use.

Let's start with a working group

Might be worth filling a bug with Mozilla. I'm pretty sure the files I used don't carry colour profile info that would cause this difference, but I've been wrong before.

I think this one is it? I've kept my eye on it for a while, but it doesn't look like there's been any movement for some time.

https://bugzilla.mozilla.org/show_bug.cgi?id=1634741

That does seem to be the issue!

The other image formats are colour-managed, so they look relatively desaturated on my WCG monitor. The AVIF images look "stretched" to the full gamut, making them garishly oversaturated.

Test in other browsers; I know of at least two bugs related to color accuracy in Firefox. They get brought up all the time in support forums like r/Firefox.

I'm safari on a iPhone 11 I'm not seeing a difference between the car images in different tabs at all.

Me neither...i guess to test it you need to click on it and compare the zoomed frames

Whatever happened to jpeg2k? I was making PDFs of comics; discovered that pdf supports jpeg2k, and the subjective quality was so much better than jpeg, to the point of text being legible at about 5x smaller size, and in addition the artifacts it introduces are far less unpleasant; jpeg introduces massive amounts of ringing in high contrast areas, while jp2 seems to just end up with lower contrast

JPEG2000 is used in some industries, but was too patent-encumbered to succeed in general. AVIF and WebP should be better for most things, and AVIF is freely licensed.

I know you used past-tense, but at this point, the core patents should be mostly expired, right?

Internet Explorer didn't support it, so it was dead from the start. By the time other browsers gained significant market share, it was already buried six feet deep so nobody even bothered.

>Whatever happened to JPEG2000?

its shipping in RED cameras under the name REDCODE ;)

on a per device licensing cost, the patent encumberance of JPEG2000 is probably not a problem. But for widespread adoption, it's too problematic.

The wikipedia page make it seem like PNG is "better".

That paragraph is poorly written and doesn't warrant a standalone heading at all. JPEG2000 is mainly a lossy format, comparing its rarely used lossless mode to other lossless formats is pointless.

While JPEG2000 doesn't catch on, it's still used moderately in some fields, particularly medical imaging and some other scientific imagings. And the use of wavelet-transform based algorithms in compression is adopted in lots of other formats too.

I recently learned that movies get delivered these days in a format called Digital Cinema Packages[1] - which is mostly JPEG 2000 images for each frame and PCM audio.

[1] https://en.m.wikipedia.org/wiki/Digital_Cinema_Package

Indeed. And studios are rapidly adopting the use of JPEG2000 lossless as a replacement for their mezzanine master via a similar standard called IMF (Interoperable Master Format). So yes Hollywood is very well committed to j2k and has been for over a decade.

Generally speaking wavelet-based image / video compression are computation expensive, comparatively speaking. But they fit certain type of Lossless /Extreme High Quality usage.

Good question though time to revisit jp2.

This part was a little hidden and hopefully will get better, but it's pretty rough...

> At an 'effort' of 2, it takes a good few seconds to encode. 'Effort' 3 is significantly better, but that can take a couple of minutes. 'Effort' 10 (which I used for images in this article) can take over 10 minutes to encode a single image.

Two sentences later:

> The command line tools are orders of magnitude faster

and from the previous sentence:

> Encoding AVIF takes a long time in general, but it's especially bad in Squoosh because we're using WebAssembly, which doesn't let us use SIMD or multiple threads

Also, since I wrote that article, we shipped wasm to Squoosh that makes use of threads. We aren't there with SIMD yet (for AVIF, we have it for some other codecs), but tooling is getting better.

That's awesome. Do you have a rough value on what the best case effort=10 encoding is right now (in CLI, decent computer), compared to the 10m number given above? Will it be 10x faster? 100x faster?

The first "At equal file sizes" heading (for the racecar) is telling.

Looks surprisingly good for vector images, but I'm not sure if the size comparison is fair: you'd gzip this content and it will probably work well with text/SVG, and probably won't work at all with AVIF. Not to mention in the first case it's truly lossless, and in the second case it's... well, not bad.

For F1 image, if you compare 20KB JPEG vs 18KB AVIF, there's no doubt AVIF is better. But if this picture is the content of page, not some useless decorations, I'd rather be served with 70KB JPEG in this example, it isn't really a close competition. So I wonder if 40-50-60 KB AVIF would look as good or better than 70 KB JPEG. Then it would be impressive. Otherwise, it isn't really a drop-in replacement and I wonder what the correct use-case strategy should be.

Jake’s point was to compare the minimum acceptable qualities, showing that when you take things to extremes, AVIF is way better than the alternatives in surprisingly many fields. But the trouble is that JPEG starts destroying parts of the F1 image a good deal earlier, and so you have to have parts of the image at a much higher quality than would seem necessary, lest other parts of the image be ruined. Similar happens with MP3 compression artefacts and Opus/MP3 comparisons.

It would have been good if the article also included an AVIF image increased in quality to match the JPEG’s DDSIM score, or at least indicated what that quality level was. I’d expect that 30KB would be sufficient, quite possibly even 25KB.

The reference image on the sight was 18kb AVIF vs 79kb JPEG at (as far as I could tell on my phone) identical perceptual quality.

The JPEG is markedly higher quality in many details, as Jake discusses:

> In fact, when I showed this article to Kornel Lesiński (who actually knows what he's talking about when it comes to image compression), he was unhappy with my F1 comparison above, because the DDSIM score of the JPEG is much lower than the others, meaning it's closer in quality to the original image, and… he's right.

> I struggled to compress the F1 image as JPEG. If I went any lower than 74 kB, the banding on the road became really obvious to me, and some of the grey parts of the road appeared slightly purple in a noticeable way, […]

> The fine detail of the road is lost in all of the compressed versions, which I'm ok with. However, you can see the difference in detail Kornel was talking about. Look at the red bodywork in the original, there are three distinct parts – the mirror, the wing connecting the bargeboard, and the top of the sidepod. In the AVIF, the smoothing removes the division between these parts, but they're still mostly there in the JPEG, especially the 74 kB version.

The SVG sizes I talk about include minification and brotli.

Although he does seem to be comparing images at incredibly high compression rates, to the point that the full sized versions don't look anywhere near acceptable (which is subjective I suppose).

Yep, and "quality" isn't always the only control you have, i.e. chroma Sub Sampling is an option for JPEG (and maybe others?) as well, which sometimes has to be played around with in my experience if you really care about high-fidelity JPEGs (i.e. full screen photos).

I really wish something existed (or was even built-in to image format encoders in some way, although I recognise that would arguably be bloat) to "bisect" what the optimum settings are per format without degrading quality based off perceptual pixel differences...

I've written a basic thing myself I use to work out the chroma sub sampling (whether 444 is needed, or if 422 can be used) for JPEG encoding photos, and it can do a fair level of "quality" bisection as well, but it's far from perfect, but still useful.

Some of the examples use subsampling, some don't, depending on if I felt it needed it visually. From memory, I think I disabled subsampling for all the illustration images. Except in WebP where you can't disable it. For WebP I used its "sharp YUV" mode instead.

There's a use case where JPEG is better, scroll down to "Progressive rendering" :

https://jakearchibald.com/2020/avif-has-landed/

https://jakearchibald.com/c/progressive-5f94067c.mp4

A (small) thread about that post at the time: https://news.ycombinator.com/item?id=24407241

It would be actually pretty neat if HN was automatically linking to any relevant discussion for any link that was posted by a member here. Something as simple as superscripts would do.

That "Flat illustration" lossy AVIF case seems to have subtle but noticeable color shift on large pure color areas where webP doesn't have (check the background of the second row, third col figure). What causes this?

Really? I don't see any difference, except I do see a pixel shift if I switch between uncompressed/AVIF.

This could happen due to DC shifts (one pixel gets quantized, the rest are coded as a difference from it), or a mistake in the post-decoding pipeline (gamma/colorspace correction).

I just modified my comment to make it more clear what I meant.

But you're right, probably just error due to compression/quantization etc. in DC shift or in colorspace conversion. It seems to happen in low quality JPEG too after I did some quick tests myself.

Pity that it doesn't really support progressive loading.

When I found this out about jpeg, I was quite amazed. Things could look okay pretty much right away, then get sharper if you give it a second. Shorter loading times and a reasonable image pretty much no matter the size.

In practice, I never really used it. I toyed with it once or twice, I turn it on every time because with jpg it often yields marginally lower file sizes anyway (in gimp you can preview file size and looks), but never heard anyone say "what was that magic" and whenever I see it on websites I think to myself "yeah okay that 20x20 pixel image, it could have saved a render cycle, this is useless and looks terrible" before it downloads to 100% before the next render cycle.

So I'm not sure it will really be missed, even if you saddened my inner nerd. I really do like the feature, it's really neat to just load as much as you wish and get however much 'quality' fits within that data size.

It was really nice in the nineties when we had dial-up and large jpeg images (>100 Kbyte) were loading a bit slower so you didn't have to wait before getting an impression. Now it's important in mobile networks, but you can also opt to turn off images. Who needs images anyway while reading, toddlers?

Progressive use is up since mozjpeg and some other tools (CDNs perhaps?) started defaulting to it. My guesswork is that during the last eight years of format development the biggest winner is progressive JPEG (from 8 % to 25 % of JPEG use). The 'green men' problem and interpolation of progressive JPEG have been fixed recently.

It seems that progressive/interlacing techniques increase the final size. https://blog.codinghorror.com/progressive-image-rendering/

It seems likely that that blog post is wrong in that detail, given that pretty much everyone else says that making JPGs progressive reduces the file size.

All I know (if I remember correctly, I'm fairly certain but won't rule out that I'm mixing things up) is that GIMP has a toggle for it and when it's enabled, it sometimes saves a tiny amount but never seems to get larger. Perhaps the toggle doesn't do what it says on the tin?

The video itself is funny, because it looks like JPG is the first to finish by far, but in reality it still is getting more detail, but more most people that detail is not visible, and by the time they look more closely, it may have already finished loading.

> most people that detail is not visible, and by the time they look more closely, it may have already finished loading

I guess it depends at what point it does the first render. I rarely see images load progressively in the first place, but when I do it's usually with an initial render that looks like 1967 needs their image back. My guess is that it's busy downloading the many/largeish js/css files that prevent it from getting very far on images before the DOM is ready for initial render.

Or maybe, you only notice that one because it's obvious, but most of the time when you see a JPG which you think has finished loading, it's actually still not done but it looks like it's done, as in the example above.

I honestly could not tell it was still going after the 2nd progressive layer.

I kind of dislike progressive loading; certainly the type that's used as an (hypothetical) example in the article. The squashed blurry bad-quality image isn't all that useful, and you're never actually sure if it is or isn't loading a better version in the background. I'm not so sure if it's really better UX, because either 1) you care about the image quality in your use case and a blurry version just won't do, or 2) the image quality isn't all that important and you should be serving smallish images anyway (like the Guardian), possibly clickable to load a high-res version for those who desire it.