
How to use the next-gen open-sourced .Avif image format, 50% smaller than JPEG - tomhanlon
https://reachlightspeed.com/blog/using-the-new-high-performance-avif-image-format-on-the-web-today/
======
wonderlg
Years ago I remember seeing a progressive image format that was supposed to
solve the resolution issue. The loader could stop loading as soon as it
figured it had enough quality. This meant that you could have a single, large
image file, that could weigh a few KB when displayed as a thumbnail.

It’s 2020 and its mind-boggling that this isn’t a standard behavior already.

Imagine right-clicking on a thumbnail and being able to natively save a 4MB
file from it.

Imagine having a single <img> that can be zoomed in all the way to 100% just
like your phone’s Photos app can do, without loading the whole image
beforehand.

~~~
SahAssar
That argument ignores everything that new formats and container formats can
allow for. And if the argument is to put older formats "first" then you need
to download older formats first to get the features of new formats and need to
figure out the order of competing modern formats (like JPEGXR vs JPEG2000 vs
WEBP).

This is basically a solved problem when people use mime types properly for
formats. For sizes we'd need a similar way to mime types to ask for a size,
html solves this for images with srcset but I'd rather it be within the
transport mechanism rather than in the markup.

Requesting an image should be requesting a image, not a specific
representation of that image. The representation should be part of the content
negotiation that is already a part of the protocol.

~~~
wonderlg
I think you completely misunderstood.

> Requesting an image should be requesting a image, not a specific
> representation of that image.

This is exactly what I’m saying. The image is one, it’s the browser that
decides how much of it to load.

It’s the current picture/srcset-based situation that is “a specific
representation of that image”

> For sizes we'd need a similar way to mime types to ask for a size

Now _that_ is complicating things. Suddenly the server has to produce/return
different resources based on a header. The solution I described could be
delivered by any _dumb_ HTTP2 server, without preprocessing.

Technically what I’m describing is already possible with any progressive
format like JPEG; The only missing part is that the browser should
pause/resume the loading as it sees fit.

All I want for Christmas is:

    
    
        <img src="you.jpg" progressive>
    

The obvious advantage is that if the window size changes, the browser only has
to fetch the missing data, not a whole new file.

------
ortusdux
Ironically, the avif demo image they use in this write-up is larger then the
failover jpg (137kb vs 110kb).

[https://reachlightspeed.com/img/blog/post-using-avif-
images-...](https://reachlightspeed.com/img/blog/post-using-avif-images-today-
support.avif)

[https://reachlightspeed.com/img/blog/post-using-avif-
images-...](https://reachlightspeed.com/img/blog/post-using-avif-images-today-
no_support.jpg)

~~~
tomhanlon
Good catch! We were moving quickly trying to get this blog post out before the
standard was implemented. We've updated this and it's now a smaller file size.

~~~
dimitar
But what happened?

~~~
tomhanlon
The .avif file in the example was accidentally saved as larger than the JPEG
file which makes it a poor use case. We compressed the .avif file with the
correct compression quantizer with avifenc to higlight the difference.

The JPEG file is 112kb and the .avif file is now 55kb.

------
hkmaxpro
I look forward to JPEG XL that is ever better than AVIF.

See the ImageCon slides and the summary from the top comment in [0], or watch
the video there.

JPEG XL’s strengths: better image quality, responsive decoding, totally
royalty-free (unlike HEIF container in AVIF [1]), legacy-friendly (easy
conversion from JPEG, PNG, GIF).

JPEG XL standardization should be complete by the end of 2021 [1].

[0]
[https://news.ycombinator.com/item?id=21612708](https://news.ycombinator.com/item?id=21612708)

[1]
[https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im...](https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs)

~~~
bscphil
One thing that's really great about JPEGXL is that it seems to be intended for
use at the high end, e.g. larger files, more bits / pixel. Most of these newer
codecs are based on the intra frame of video codecs, which are all optimized
to look good at the lowest possible bitrate. (And even high bitrate video is
usually much lower quality than what we use for static images.) I suspect
there are a lot of easy gains to be had here, and actually I wish someone
would look at doing a high quality royalty free _video_ codec with the intent
to target high bitrate applications. (It's noteworthy that a lot of
professional applications like DCP use an image codec, JPEG2000.)

For anyone looking for some image comparisons between AV1 and JPEGXL, someone
updated the classic "image format comparison" on Github and added it. [1]
Important to note that all these are a little unfair to JPEGXL, because it's
explicitly targeting higher bitrates than most of the quality levels you see
here, and it still comes out looking pretty good at the higher bitrates.

[1] [https://afontenot.github.io/image-formats-
comparison/#abando...](https://afontenot.github.io/image-formats-
comparison/#abandoned-factory&webm=m&jxl=m)

~~~
tormeh
AV1 comes out on top of all of the comparisons to my eye. Seems to be half a
step above JPEGXL, i.e. small AV1 is almost as good as medium JPEGXL

~~~
bscphil
I find JPEGXL much better at medium and large sizes for the sorts of artifacts
that bother me, on most images. For example in this [1] comparison, AV1 is
clearly degrained, losing the very fine detail.

Note that achieving high quality results at low bitrates is not really a goal
of JPEGXL, or the codecs it's based on. For example the PIK readme contains
the following note:

> It prioritizes authenticity, a faithful representation of the original, over
> aesthetics achievable by by hallucinating details or 'enhancing' (e.g.
> sharpening/saturating) the input.

So as I noted in the OP, it's not a very fair comparison with bitrates this
low, but I think JPEGXL holds its own.

[1] [https://afontenot.github.io/image-formats-
comparison/#eaglef...](https://afontenot.github.io/image-formats-
comparison/#eaglefairy&webm=m&jxl=m)

------
FullyFunctional
It's a missed opportunity that we can't just one 1 frame AV1 files as images.
Had this been anticipated we wouldn't have to push two standards and two
implementations everywhere.

~~~
sli
There are already a few formats that work just like JPEG but for modern video
formats. Some of them even compress better (FLIF). They just haven't caught on
at all. JPEG just has _so_ much momentum.

Those other formats weren't developed by huge corporations who can force it
into browsers through pure hegemony. That's probably a factor.

~~~
FullyFunctional
I was apparently not clear enough.

The missed opportunity is that AV1 _is_ arriving everywhere and with tiny bit
of foresight they could have made that include a new image standard which
everyone would then have as well with essentially no additional support
needed. Instead we now have to convince all browser vendors and more to
support yet another image format that has no widespread adoption.

------
tomhanlon
We're really excited about this image format -- for the same image quality
.AVIF compresses 50% smaller than JPEG, 20% smaller than WebP and is free to
use.

------
nicoty
How does it compare with FLIF? What use cases would it excel on/have that the
other wouldn't/doesn't?

~~~
tomhanlon
FLIF seems to compress higher but to my knowledge there is no major browser
support. AVIF support is scheduled for Firefox 80 and Chrome 85 by the end of
this month (August 25).

~~~
kjeetgill
Knowing nothing about the formats, why the difference in adoption?

~~~
tomhanlon
The format was co-developed by some big tech players: Netflix, Google,
Microsoft, Facebook, Mozilla

Further reading: [https://www.cnet.com/news/google-mozilla-av1-photo-format-
co...](https://www.cnet.com/news/google-mozilla-av1-photo-format-could-outdo-
aging-jpeg/)

------
beagle3
How are the compression and decompression speeds compared to e.g. turbojpeg?

Is there a poly fill js/warm decoder for older browsers?

~~~
tomhanlon
Not sure on the compression/decompression speeds.

There is a polyfill for old browsers but our recommendation would be to use
the graceful degradation of the <picture> tag which falls back to <img> if
.avif or .webp is not supported.

------
StellarTabi
[https://caniuse.com/#feat=avif](https://caniuse.com/#feat=avif)

Only supported by Chrome ATM.

~~~
tomhanlon
Slated for release in Firefox 80 in less than three weeks (8/25)

~~~
marci
And if you want to test it in current Firefox, in the about:config page,
search for avif and enable it.

------
mchusma
We use gumlet to serve avid, webp, jog images based on what the browser
supports. I recommend it.

