Netflix Now Exploring AVIF For Image Compression

[shmerl]

Isn't HEIF container patent encumbered? It was developed by MPEG. So this development doesn't sound good to me. There should be free containers for that.

https://en.wikipedia.org/wiki/High_E...ge_File_Format

[bug77]

AFAIK is HEIF more like the container and AVIF is AV1 as a single image, like a AV1 video can be used in mkv/webm or mp4 container

That makes sense, but still begs the question: why would this new format be using an existing container? I mean, they should be independent of each other, shouldn't they? (pardon the confusion, formats and container are blurry in my head to the point I couldn't tell why an image format would ever need a container)

[pkese]

There's already progsive jpeg - how widely is this used, and what does that say about real world damand?

Jpeg is just progressive. XL also has responsiveness built in: there's additional metadata at the beginning of the file describing how much needs to be served for required image size and/or quality. So browsers can request required image size and the server can stream just the right amount of data. This is not available for jpeg.

Somehow, I doubt that this is what your _typical_ website does.

Most SPA websites nowadays do that - it is just a matter of adding a plugin to Webpack. Netflix certainly does it.

As for Browser compatibilty - this certainly was a huge concern back in the day, when Internet Explorer took years to be phased out. But today, there are fewer browser engines, rolling releases, and general planned obsolescence - so a new format like isn't blocked by lack up browser updates for long.

It still matters on phone browsers quite a lot. Most vendors offer limited time updates to software on phones, and most people have older phones than most geeks.

Feel free to compare these space savings with the space and bandwith used for videos.

Then why does Netflix want better image compression anyway...

[Teggs]

These are very shiny features and amazing tech, execpt that we're talking about _images_ and it's 2020, so storage and bandwidth concerns are not like in the 80s.

When I think of how many images Netflix must serve in its menus, I don't wonder at all they want to optimise them. Then most other websites are text and still images, with limited animation or video, and I don't see a reason for that to change. Reducing bandwidth, and, yes, storage space for images would be huge on the scale of the entire net. ...if people adopt the new 'standard'.

[Marsu42]

These are very shiny features and amazing tech, execpt that we're talking about _images_ and it's 2020, so storage and bandwidth concerns are not like in the 80s.

1) progressive decoding for responsive web images
-> consequently on low-resolution devices, browsers can download just part of the file

There's already progsive jpeg - how widely is this used, and what does that say about real world damand?

2) reversible compression of existing jpeg images
-> consequently a web server can on-the-fly serve a .jpeg version of .jpeg-xl in case browser doesn't support the latter.

I have to admit they've pulled a rabbit out of the hat with this, though it tookes decades after the original jpeg and failed jpeg2k

For web developers and CDNs that is actually a HUGE differe
It's not just how good the compression is, but how many files you need to produce and carry around.
A typical responsive website will need to render images in several resolutions:

Somehow, I doubt that this is what your _typical_ website does.

As for Browser compatibilty - this certainly was a huge concern back in the day, when Internet Explorer took years to be phased out. But today, there are fewer browser engines, rolling releases, and general planned obsolescence - so a new format like isn't blocked by lack up browser updates for long.

Feel free to calculate the space-saving.

Feel free to compare these space savings with the space and bandwith used for videos.

Another advantage of heif/avif is that multiple codecs are supported, and new codecs like VP2 will be supported for images, too. These will probably deliver some space savings for images, again... not that this would really matter vs. video codec use.

[pkese]

JPEG-XL ist too little, too late

Compared to AVIF, JPEG-XL supports :
1) progressive decoding for responsive web images
-> consequently on low-resolution devices, browsers can download just part of the file
2) reversible compression of existing jpeg images
-> consequently a web server can on-the-fly serve a .jpeg version of .jpeg-xl in case browser doesn't support the latter.

If compression quality is comparable, I'd choose JPEG-XL any day over AVIF just based on these two features.

Edit:

For web developers and CDNs that is actually a HUGE difference.
It's not just how good the compression is, but how many files you need to produce and carry around.
A typical responsive website will need to render images in several resolutions:
-> 1) retina.avif, 2) hi-res.avif, 3) med-res.avif, 4) low-res.avif, 5) thumb.avif
Now double that and produce both .avif and .jpeg for the transition period until all browsers support avif:
-> 1) retina.avif, 2) hi-res.avif, 3) med-res.avif, 4) low-res.avif, 5) thumb.avif
-> 6) retina.jpeg, 7) hi-res.jpeg, 8) med-res.jpeg, 9) low-res.jpeg, 10) thumb.jpeg

All of that can be replaced with a single JPEG-XL.
Feel free to calculate the space-saving.

[wswartzendruber]

JPEG-XL ist too little, too late - and the JPEG brand is tainted by low image quality and hacks like JPEG-XR. WebP has very good lossless compression, but mediocre lossy compression sinde it's based on the outdated VP8. As most of the industry is behind AV1, I guess it'll be .avif from now on - and it's contain further codec updates like AV2, AV3, ...

Google is behind JPEG XL. All of their work on Pik has been folded into it. Given the advantages it has for losslessly repacking existing JPEGs, I would be very hesitant to write it off. The industry has shown us time and time again that it values compatibility more than anything.

It's cool to see proper video compresison being used for images. I hope it will be used for animated images kind of like how webp can be used.

[Marsu42]

They mentioned JPEG XL very briefly, which is the next-gen image codec I believe will have the most traction. It has great lossy and lossless compression, and a great upgrade path from standard jpeg in that in can losslessly recompress jpeg into the JPEG XL format with a 20% size reduction. It is currently in late stage standardization, which I suppose means it should be standardized within this month.

JPEG-XL ist too little, too late - and the JPEG brand is tainted by low image quality and hacks like JPEG-XR. WebP has very good lossless compression, but mediocre lossy compression sinde it's based on the outdated VP8. As most of the industry is behind AV1, I guess it'll be .avif from now on - and it's contain further codec updates like AV2, AV3, ...

[Toggleton]

So is it a file format or is it using a pre-existing format? It can be both at the same time, can it?

AFAIK is HEIF more like the container and AVIF is AV1 as a single image, like a AV1 video can be used in mkv/webm or mp4 container

In the area of image coding formats, the Moving Picture Experts Group (MPEG) has standardized a codec-agnostic and generic image container format: ISO/IEC 23000–12 standard (a.k.a. HEIF). HEIF has been used to store most notably HEVC-encoded images (in its HEIC variant) but is also capable of storing AVC-encoded images or even JPEG-encoded images.