8 ms·

For those wondering why they should care about yet another image format: https://jakearchibald.com/2020/avif-has-landed/ https://jakearchibald.com/2020/avif-ha

For those wondering why they should care about yet another image format: https://jakearchibald.com/2020/avif-has-landed/ https://jakearchibald.com/2020/avif-has-landed/ This is incredible.

deleted 6y ago
[deleted]
rkagerer 6y ago
The first "At equal file sizes" heading (for the racecar) is telling.
contravariant 6y ago
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).
- berkut 6y ago
  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.
  - jaffathecake 6y ago
    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.
- BlueTemplar 6y ago
  There's a use case where JPEG is better, scroll down to "Progressive rendering" : https://jakearchibald.com/2020/avif-has-landed/ https://jakearchibald.com/2020/avif-has-landed/ https://jakearchibald.com/c/progressive-5f94067c.mp4 https://jakearchibald.com/c/progressive-5f94067c.mp4
amelius 6y ago
Pity that it doesn't really support progressive loading.
- lucb1e 6y ago
  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.
  - ehsankia 6y ago
    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.
    - lucb1e 6y ago
      > 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.
      - 6y ago
fireattack 6y ago
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?
- astrange 6y ago
  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).
  - fireattack 6y ago
    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.
krick 6y ago
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.
- chrismorgan 6y ago
  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.
  - vlovich123 6y ago
    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.
    - chrismorgan 6y ago
      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.
jiggawatts 6y ago
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.
- Hnrobert42 6y ago
  Hey! Leave us out of it. I can see the differences, too. The folks to blame aren’t colorblind. They are color indifferent. :-)
  - GordonS 6y ago
    Huh, must depend what type of colour-blindness, and/or how severe, as I can't tell any difference in colour whatsoever.
    - Hnrobert42 6y ago
      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.
- gsnedders 6y ago
  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.
ehsankia 6y ago
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.
- darkfirefly 6y ago
  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
  - jaffathecake 6y ago
    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.
    - ehsankia 6y ago
      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?
aidenn0 6y ago
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
- cl0ckt0wer 6y ago
  The wikipedia page make it seem like PNG is "better".
  - fireattack 6y ago
    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.
    - realityking 6y ago
      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 https://en.m.wikipedia.org/wiki/Digital_Cinema_Package
      - matt-attack 6y ago
        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.
- 6y ago
dang 6y ago
A (small) thread about that post at the time: https://news.ycombinator.com/item?id=24407241 https://news.ycombinator.com/item?id=24407241
- cromka 6y ago
  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.
deleted 6y ago
[deleted]

For those wondering why they should care about yet another image format: https://jakearchibald.com/2020/avif-has-landed/ https://jakearchibald.com/2020/avif-has-landed/ This is incredible.

deleted 6y ago

[deleted]

rkagerer 6y ago

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

contravariant 6y ago

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).

berkut 6y ago
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.
- jaffathecake 6y ago
  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.
BlueTemplar 6y ago
There's a use case where JPEG is better, scroll down to "Progressive rendering" : https://jakearchibald.com/2020/avif-has-landed/ https://jakearchibald.com/2020/avif-has-landed/ https://jakearchibald.com/c/progressive-5f94067c.mp4 https://jakearchibald.com/c/progressive-5f94067c.mp4

amelius 6y ago

Pity that it doesn't really support progressive loading.

lucb1e 6y ago
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.
- ehsankia 6y ago
  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.
  - lucb1e 6y ago
    > 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.
    - 6y ago

fireattack 6y ago

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?

astrange 6y ago
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).
- fireattack 6y ago
  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.

krick 6y ago

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.

chrismorgan 6y ago
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.
- vlovich123 6y ago
  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.
  - chrismorgan 6y ago
    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.

jiggawatts 6y ago

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.

Hnrobert42 6y ago
Hey! Leave us out of it. I can see the differences, too. The folks to blame aren’t colorblind. They are color indifferent. :-)
- GordonS 6y ago
  Huh, must depend what type of colour-blindness, and/or how severe, as I can't tell any difference in colour whatsoever.
  - Hnrobert42 6y ago
    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.
gsnedders 6y ago
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.

ehsankia 6y ago

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.

darkfirefly 6y ago
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
- jaffathecake 6y ago
  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.
  - ehsankia 6y ago
    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?

aidenn0 6y ago

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

cl0ckt0wer 6y ago
The wikipedia page make it seem like PNG is "better".
- fireattack 6y ago
  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.
  - realityking 6y ago
    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 https://en.m.wikipedia.org/wiki/Digital_Cinema_Package
    - matt-attack 6y ago
      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.
6y ago

dang 6y ago

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

cromka 6y ago
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.

deleted 6y ago

[deleted]