9 ms·

AVIF for Next-Generation Image Coding

161 points by dedalus 7y ago

gok 7y ago
That 420 vs. 440 comparison animation is rather problematic. GIF can only represent 256 colors. Most of the artifacts in those images are due to GIF-specific dithering. also, previously: https://news.ycombinator.com/item?id=22327480 https://news.ycombinator.com/item?id=22327480
- Dylan16807 7y ago
  Should have used apng, sure, but the difference is still very visible on those hard color lines.
- bmn__ 7y ago
  https://webmasters.stackexchange.com/q/304/true-color-gif https://webmasters.stackexchange.com/q/304/true-color-gif https://enwp.org/GIF#True_color https://enwp.org/GIF#True_color
oconnore 7y ago
Shouldn't this be benchmarked against WebP instead of (obviously much worse) JPEG?
- LeoPanthera 7y ago
  Or indeed HEIC. A lot of so-called "next generation" codecs are really "current-generation" now.
  - roca 7y ago
    Benchmarks against HEVC and WebP are included in the metrics section of the article.
  - berkut 7y ago
    Does any browser support HEIC yet? To my knowledge, even Safari doesn't.
- daef 7y ago
  or flif... https://flif.info/ https://flif.info/
- mkl 7y ago
  It is benchmarked here against WebP, HEVC, and JPEG2000, as well as JPEG. That's what all the graphs are. AVIF wins quite convincingly on the metrics they've used.
rytill 7y ago
I don't see compression speed / performance / time mentioned anywhere in the article.
- aidenn0 7y ago
  I'm guessing that Netflix compares not at all about compression time for this; the most used assets are probably downloaded millions of times and change rarely.
  - Dylan16807 7y ago
    And honestly if you're not designing a camera then there's extremely little chance you care about still image compression time.
londons_explore 7y ago
As far as I can see, there is no support in any web browsers yet, despite the format being finalized a year ago... Whats the holdup?
- niftich 7y ago
  AVIF support Firefox issue [1]; Chromium issue [2]. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1443863 https://bugzilla.mozilla.org/show_bug.cgi?id=1443863 [2] https://bugs.chromium.org/p/chromium/issues/detail?id=960620 https://bugs.chromium.org/p/chromium/issues/detail?id=960620
  - qwerty456127 7y ago
    For some weird reason browser manufacturers strongly oppose adding support for any new media formats. They will only accept a new format once they decide that's a good political move. If I were Google/Mozilla I'd add support for everything ffmpeg and imagemagick support.
    - londons_explore 7y ago
      As soon as they support something, they can never drop support for it because some sites will have started using it, and some sites will never stop using it. Look at how hard it has been to deprecate Flash. By enabling support, they are commiting to maintain same-or-better compatibility pretty much forever. Thats a big commitment if your code is based of someones 'for lolz' patch to ffmpeg...
      - bawolff 7y ago
        Heck, it took until firefox 3.6 to remove xbm support, and that is an utterly terrible image format for a web browser.
        qwerty456127 7y ago
        > it took until firefox 3.6 to remove xbm support Why would it be a problem to remove if only a small number of little-known sites used it?
roca 7y ago
It's been a slow process, and hence perhaps underappreciated, but it's very gratifying that over the last 15 years patent-unencumbered media codecs have won. The companies that contributed to this --- Google, Mozilla, Cisco, and others --- and especially Xiph that got the ball rolling --- deserve a lot of credit.
- greggman3 7y ago
  They have? Are we talking images only because in video mp4 and .h264 and .h265 are pretty much it. Apple/Safari still doesn't support vp8/vp9/webm/av1 for video or ogg for audio
  - jasondclinton 7y ago
    Mobile Safari is about 20-35% of all mobile web traffic. Desktop Safari is about 5-15% of all desktop web traffic. Source: https://en.wikipedia.org/wiki/Usage_share_of_web_browsers https://en.wikipedia.org/wiki/Usage_share_of_web_browsers
  - est31 7y ago
    > Are we talking images only because in video mp4 and .h264 and .h265 are pretty much it. Apple/Safari still doesn't support vp8/vp9/webm/av1 for video or ogg for audio h265 is doomed because of the multiple patent pools that have formed and the extreme price hikes compared to h264. It's a risky technology to build on. That's the best ad that AV1 can have, and many members joined the alliance for open media for that reason after it became clear that the patent pool situation wouldn't resolve. As for your browser support question, yes, Safari has traditionally been anti-ogg, but a few years ago Apple joined the alliance for open media and added opus support to their browsers (although only in the caf container, for some weird unexplainable reason). Open codecs have won in the lossless audio domain (flac). There is no reason they can't win in the lossy video and lossy audio domains too (not sure about lossless videos but FFV1 seems to have lots of support by archivists who want open technology).
    - p0nce 7y ago
reggieband 7y ago
I worked on a team responsible for image assets. I recall the web team asking for webp support from our image server. I suppose nowadays using `srcset` you can get some optimization in the ratio between file size and quality while still providing fallback for unsupported browsers. Given our image service was dynamic (e.g. it generated then cached images at different sizes, qualities, etc from a single high-res source) adding a new format wasn't that difficult. It meant that the image heavy pages would display more quickly which was a concern especially for mobile. So I am a big supporter for more and better formats. That being said, this AV1 vs. HEVC / AVIF vs. HEIF stuff feels eerily similar to HLS vs. DASH. It's not like these formats have drastically different properties (e.g. GIF vs. JPG vs. PNG) - they are all quite similar. I just want to fast-forward time until whichever one is going to win is standard. It's like VHS vs. Betamax or Blueray vs. HD-dvd. Please just get it over with.
- MikusR 7y ago
  The difference is that HEVC/HEIF has at least three different patent licensing organizations that all want to be paid. While AV1/AVIF is supposed to be "patent free"
  - reggieband 7y ago
    I heard the same about h.264 vs VP9 and it turned out that patent licensing wasn't a long-term issue. For a while you got that license from Flash (if y'all remember when Flash was the way Youtube worked, and I recall mention that it was one of the primary reasons Flash Player was never opened sourced). Then the license for h.264 it was included in every copy of Windows 8 (IIRC). Nowadays no one even mentions the h.264 license. I'm no expert on the new license but it seems the restrictions on HEVC are relatively light. I'm pretty sure it is free to compress and distribute media but the license affects hardware and software encoders/decoders. So maybe your HEVC enabled video card with built-in decoder will be a dollar more expensive. I know that every Apple device shipped comes with HEVC hardware standard for the last few years. I would wager most Android devices too.
    - niftich 7y ago
shmerl 7y ago
Why use HEIF container for AVIF, instead of something derived from Matroska for example, like WebP does? Is HEIF free to use?
- giantrobot 7y ago
  The HEIF and HEVC container are the same. So if they use the HEIF container they already have libraries on devices that can handle the format, metadata, etc. I don't believe Netflix is delivering any Matroska content so they have no media pipeline or tooling for the format. It's the same reason they didn't base the container format on RIFF or ASN.1.
  - shmerl 7y ago
    Since they are proposing it as a common standard, I don't think it should matter what they already use, in comparison with something that's actually free to use. If HEIF is free, then fine. But MPEG stuff is not created free by design, so it has to be stated somewhere.
    - giantrobot 7y ago
      The HEIF container is the MPEG-4 Part 12 ISO container, the same used for MP4 video and JPEG2000. This lets it fit inside existing workflows and media stacks. AVIF just ends up and additional codec in a familiar container. Anyone needing to pay license fees for MPEG-4 Part 12 format patents (if they exist) is already covered by usage for video or HEIF. Anyone not needing to pay licenses will continue to not need to pay licenses in they use AVIF.
      - shmerl 7y ago
        Not sure what that means. Sounds like some still might need to pay for it. That's an unacceptable approach for a standard proposed by AOM which stresses the royalty free focus (in contrast with MPEG), which was exactly my point above.
        7y ago
jiggawatts 7y ago
I'm going to put my cynical hat on for a bit and notice that the company behind this format, Netflix, has a walled garden. They have a streaming service that is consumed only through a handful of apps that they are in full control of. They're not doing this for the community, for web standards, or the greater good. They're making this format simply to save some bandwidth for themselves, in a way that won't translate to the general community. The second picture in the linked blog article is literally a diagram of this garden. (Titled: "Compressed image assets destined for various client devices...") I had a similar comment about the JPEG XL format (mostly developed by Google) and the CSS "Display P3" colour space extension (Apple), both recently featured on YCombinator. These mega-corporations are building an ecosystem where in 2020, the future, it's impossible to send a wide-gamut, 10-bit, or HDR still image to anyone via any of the following: web standards, chat, email, or document exchange formats. The best you can do is send an 8-bit SDR sRGB image and hope for the best. PC monitors, tablets, and most phones have no consistent support for colour management, 10-bit, or HDR. Televisions are leaving the entire PC and Mobile ecosystem in the dust. The closest approximation we PC peasants have is to upload a HDR YouTube video, send a link to it, and hope the viewer uses an newish iPhone. That's just sad, isn't it? The stewardship of web standards by Microsoft (#2 biggest company), Apple (#3), and Alphabet Group (#4) have led to this. Now Netflix (#50) wants to throw their unnecessary format into the fray, almost completely ignoring the presence of JPEG XL and HEIC. They mention these alternatives in passing, and then notably don't compare image quality, features, or the compression ratio of those to their own format. You see, JXL is a Google's thing, HEIC is an Apple thing, and AVIF is a Netflix thing. So we're going to end up with as many image formats as there are walled gardens. I bet you too can't wait for whatever image format Facebook comes up with specifically to reduce their CDN bandwidth utilisation of Instagram pictures... only. Notice also that their "idea" of making an image format readily available is a docker container, which is the most insane thing I've ever seen. Where's the Photoshop plugin? The Lightroom plugin? The Windows 10 image codec? Oh wait.. those are Adobe and Microsoft things, so... nowhere to be seen. Netflix Pty Ltd is not in this game to help someone else's walled garden. No still image interchange for you peasant! Sit down, stay in the garden, and stream that content...
- ksec 7y ago
  First, Jpeg XL is not a Google thing, and neither is HEIC an Apple thing. Nor the AVIF part. AVIF is from Open Media which is indeed a Google Thing. Netflix just happen to take side with OM. JPEG XL is done by a Google Employees as well as other contributors put forward to the JPEG committee. i.e It is not a Google only format. HEIC is really just HEVC Codec in an image format developed by Nokia and submitted to MPEG ( Not to be confused with MPEG-LA ). So really JPEG XL isn't a walled garden. And support everything you described including HDR. The problem is Jpeg XL doesn't do so well in small image size as compared to HEIF or AVIF.
colbyn 7y ago
Interesting. Personally, I’ve been using VMAF extensively in my imager.io project. With regards to only testing the luma channel, someone submitted a PR for such some time ago yet it’s never been merged; I was under the impression that the UV channel isn’t significant (in practice). Personally, I think VMAF is great for images. For me, the biggest downside of VMAF (implementation wise) is that it’s not currently thread-safe.
pornel 7y ago
This is a major improvement. It's better than WebP by a bigger margin than WebP was better than JPEG. Lossy WebP couldn't even match JPEG in some aspects, like full-resolution color (4:2:0 only, not even full 8-bit depth). In terms of quality or features AVIF doesn't have such "buts". It can support HDR and high depth we're likely to want in the near future. AV1 has palette blocks, so it's no longer all-or-nothing choice of lossy vs lossless formats. I am worried that the AVIF spec is complex (like HEIF, it's a bag of image-related features, more like a PowerPoint file than an image), but probably only commonly-used features will survive out of it. Early JPEG also used to have many more modes than are usable today. If you like questionable hacks, you can use AV1 codec today in Firefox and Chrome by embedding <video> element with a 1-frame AV1 "video".
- chungy 7y ago
  > It's better than WebP by a bigger margin than WebP was better than JPEG. Depending on certain definitions of better. Image quality is certainly superior in JPEG than in (lossy) WebP.
- ec109685 7y ago
  The JPEG images in the article are much worse than what you can achieve with JPEG export in Preview.app. While they don't look like AVIF, they aren't nearly as trash as the article makes JPEG's out to be.
herf 7y ago
I'm no fan of 4:2:2 (2:1 chroma subsampling), but the comparison looks a lot better for JPEG when you use 4:2:2 (which is the usual JPEG default). Using 4:4:4 instead drives the blocking artifacts way up, and isn't fair to JPEG.
chubs 7y ago
I spent some time searching for a JS shim that enables AVIF files to be used in the browser, is anyone aware of one?
- niftich 7y ago
  The official avif github [1] references Kagami/avif.js [2]. It's intended as a server-side component to be installed, and uses service workers to on-the-fly repack AVIF images as AV1 videos. The code is licensed CC0, and is easy to read, so you can tweak it to your needs. If the browser can't natively decode AV1 videos, it calls dav1d.js [3] to decode, which is a webassembly port of dav1d [4]. [1] https://github.com/AOMediaCodec/av1-avif/wiki https://github.com/AOMediaCodec/av1-avif/wiki [2] https://github.com/Kagami/avif.js https://github.com/Kagami/avif.js [3] https://github.com/Kagami/dav1d.js https://github.com/Kagami/dav1d.js [4] https://code.videolan.org/videolan/dav1d https://code.videolan.org/videolan/dav1d
JyrkiAlakuijala 7y ago
encode.su forum posts compare image quality of JPEG XL, AVIF, WebP, MozJPEG and HEVC: https://encode.su/threads/3108-Google-s-compression-proje%D1%81ts/page3 https://encode.su/threads/3108-Google-s-compression-proje%D1... The most comprehensive comparison: https://medium.com/@scopeburst/mozjpeg-comparison-44035c42abe8 https://medium.com/@scopeburst/mozjpeg-comparison-44035c42ab... "... according to my personal visual tests, starting from 0.4–0.5 bpp it [JPEG XL] usually wins most other formats."

161 points by dedalus 7y ago

gok 7y ago

That 420 vs. 440 comparison animation is rather problematic. GIF can only represent 256 colors. Most of the artifacts in those images are due to GIF-specific dithering. also, previously: https://news.ycombinator.com/item?id=22327480 https://news.ycombinator.com/item?id=22327480

Dylan16807 7y ago
Should have used apng, sure, but the difference is still very visible on those hard color lines.
bmn__ 7y ago
https://webmasters.stackexchange.com/q/304/true-color-gif https://webmasters.stackexchange.com/q/304/true-color-gif https://enwp.org/GIF#True_color https://enwp.org/GIF#True_color

oconnore 7y ago

Shouldn't this be benchmarked against WebP instead of (obviously much worse) JPEG?

LeoPanthera 7y ago
Or indeed HEIC. A lot of so-called "next generation" codecs are really "current-generation" now.
- roca 7y ago
  Benchmarks against HEVC and WebP are included in the metrics section of the article.
- berkut 7y ago
  Does any browser support HEIC yet? To my knowledge, even Safari doesn't.
daef 7y ago
or flif... https://flif.info/ https://flif.info/
mkl 7y ago
It is benchmarked here against WebP, HEVC, and JPEG2000, as well as JPEG. That's what all the graphs are. AVIF wins quite convincingly on the metrics they've used.

rytill 7y ago

I don't see compression speed / performance / time mentioned anywhere in the article.

aidenn0 7y ago
I'm guessing that Netflix compares not at all about compression time for this; the most used assets are probably downloaded millions of times and change rarely.
- Dylan16807 7y ago
  And honestly if you're not designing a camera then there's extremely little chance you care about still image compression time.

londons_explore 7y ago

As far as I can see, there is no support in any web browsers yet, despite the format being finalized a year ago... Whats the holdup?

niftich 7y ago
AVIF support Firefox issue [1]; Chromium issue [2]. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1443863 https://bugzilla.mozilla.org/show_bug.cgi?id=1443863 [2] https://bugs.chromium.org/p/chromium/issues/detail?id=960620 https://bugs.chromium.org/p/chromium/issues/detail?id=960620
- qwerty456127 7y ago
  For some weird reason browser manufacturers strongly oppose adding support for any new media formats. They will only accept a new format once they decide that's a good political move. If I were Google/Mozilla I'd add support for everything ffmpeg and imagemagick support.
  - londons_explore 7y ago
    As soon as they support something, they can never drop support for it because some sites will have started using it, and some sites will never stop using it. Look at how hard it has been to deprecate Flash. By enabling support, they are commiting to maintain same-or-better compatibility pretty much forever. Thats a big commitment if your code is based of someones 'for lolz' patch to ffmpeg...
    - bawolff 7y ago
      Heck, it took until firefox 3.6 to remove xbm support, and that is an utterly terrible image format for a web browser.
      - qwerty456127 7y ago
        > it took until firefox 3.6 to remove xbm support Why would it be a problem to remove if only a small number of little-known sites used it?

roca 7y ago

It's been a slow process, and hence perhaps underappreciated, but it's very gratifying that over the last 15 years patent-unencumbered media codecs have won. The companies that contributed to this --- Google, Mozilla, Cisco, and others --- and especially Xiph that got the ball rolling --- deserve a lot of credit.

greggman3 7y ago
They have? Are we talking images only because in video mp4 and .h264 and .h265 are pretty much it. Apple/Safari still doesn't support vp8/vp9/webm/av1 for video or ogg for audio
- jasondclinton 7y ago
  Mobile Safari is about 20-35% of all mobile web traffic. Desktop Safari is about 5-15% of all desktop web traffic. Source: https://en.wikipedia.org/wiki/Usage_share_of_web_browsers https://en.wikipedia.org/wiki/Usage_share_of_web_browsers
- est31 7y ago
  > Are we talking images only because in video mp4 and .h264 and .h265 are pretty much it. Apple/Safari still doesn't support vp8/vp9/webm/av1 for video or ogg for audio h265 is doomed because of the multiple patent pools that have formed and the extreme price hikes compared to h264. It's a risky technology to build on. That's the best ad that AV1 can have, and many members joined the alliance for open media for that reason after it became clear that the patent pool situation wouldn't resolve. As for your browser support question, yes, Safari has traditionally been anti-ogg, but a few years ago Apple joined the alliance for open media and added opus support to their browsers (although only in the caf container, for some weird unexplainable reason). Open codecs have won in the lossless audio domain (flac). There is no reason they can't win in the lossy video and lossy audio domains too (not sure about lossless videos but FFV1 seems to have lots of support by archivists who want open technology).
  - p0nce 7y ago

reggieband 7y ago

I worked on a team responsible for image assets. I recall the web team asking for webp support from our image server. I suppose nowadays using `srcset` you can get some optimization in the ratio between file size and quality while still providing fallback for unsupported browsers. Given our image service was dynamic (e.g. it generated then cached images at different sizes, qualities, etc from a single high-res source) adding a new format wasn't that difficult. It meant that the image heavy pages would display more quickly which was a concern especially for mobile. So I am a big supporter for more and better formats. That being said, this AV1 vs. HEVC / AVIF vs. HEIF stuff feels eerily similar to HLS vs. DASH. It's not like these formats have drastically different properties (e.g. GIF vs. JPG vs. PNG) - they are all quite similar. I just want to fast-forward time until whichever one is going to win is standard. It's like VHS vs. Betamax or Blueray vs. HD-dvd. Please just get it over with.

MikusR 7y ago
The difference is that HEVC/HEIF has at least three different patent licensing organizations that all want to be paid. While AV1/AVIF is supposed to be "patent free"
- reggieband 7y ago
  I heard the same about h.264 vs VP9 and it turned out that patent licensing wasn't a long-term issue. For a while you got that license from Flash (if y'all remember when Flash was the way Youtube worked, and I recall mention that it was one of the primary reasons Flash Player was never opened sourced). Then the license for h.264 it was included in every copy of Windows 8 (IIRC). Nowadays no one even mentions the h.264 license. I'm no expert on the new license but it seems the restrictions on HEVC are relatively light. I'm pretty sure it is free to compress and distribute media but the license affects hardware and software encoders/decoders. So maybe your HEVC enabled video card with built-in decoder will be a dollar more expensive. I know that every Apple device shipped comes with HEVC hardware standard for the last few years. I would wager most Android devices too.
  - niftich 7y ago

shmerl 7y ago

Why use HEIF container for AVIF, instead of something derived from Matroska for example, like WebP does? Is HEIF free to use?

giantrobot 7y ago
The HEIF and HEVC container are the same. So if they use the HEIF container they already have libraries on devices that can handle the format, metadata, etc. I don't believe Netflix is delivering any Matroska content so they have no media pipeline or tooling for the format. It's the same reason they didn't base the container format on RIFF or ASN.1.
- shmerl 7y ago
  Since they are proposing it as a common standard, I don't think it should matter what they already use, in comparison with something that's actually free to use. If HEIF is free, then fine. But MPEG stuff is not created free by design, so it has to be stated somewhere.
  - giantrobot 7y ago
    The HEIF container is the MPEG-4 Part 12 ISO container, the same used for MP4 video and JPEG2000. This lets it fit inside existing workflows and media stacks. AVIF just ends up and additional codec in a familiar container. Anyone needing to pay license fees for MPEG-4 Part 12 format patents (if they exist) is already covered by usage for video or HEIF. Anyone not needing to pay licenses will continue to not need to pay licenses in they use AVIF.
    - shmerl 7y ago
      Not sure what that means. Sounds like some still might need to pay for it. That's an unacceptable approach for a standard proposed by AOM which stresses the royalty free focus (in contrast with MPEG), which was exactly my point above.
      - 7y ago

jiggawatts 7y ago

I'm going to put my cynical hat on for a bit and notice that the company behind this format, Netflix, has a walled garden. They have a streaming service that is consumed only through a handful of apps that they are in full control of. They're not doing this for the community, for web standards, or the greater good. They're making this format simply to save some bandwidth for themselves, in a way that won't translate to the general community. The second picture in the linked blog article is literally a diagram of this garden. (Titled: "Compressed image assets destined for various client devices...") I had a similar comment about the JPEG XL format (mostly developed by Google) and the CSS "Display P3" colour space extension (Apple), both recently featured on YCombinator. These mega-corporations are building an ecosystem where in 2020, the future, it's impossible to send a wide-gamut, 10-bit, or HDR still image to anyone via any of the following: web standards, chat, email, or document exchange formats. The best you can do is send an 8-bit SDR sRGB image and hope for the best. PC monitors, tablets, and most phones have no consistent support for colour management, 10-bit, or HDR. Televisions are leaving the entire PC and Mobile ecosystem in the dust. The closest approximation we PC peasants have is to upload a HDR YouTube video, send a link to it, and hope the viewer uses an newish iPhone. That's just sad, isn't it? The stewardship of web standards by Microsoft (#2 biggest company), Apple (#3), and Alphabet Group (#4) have led to this. Now Netflix (#50) wants to throw their unnecessary format into the fray, almost completely ignoring the presence of JPEG XL and HEIC. They mention these alternatives in passing, and then notably don't compare image quality, features, or the compression ratio of those to their own format. You see, JXL is a Google's thing, HEIC is an Apple thing, and AVIF is a Netflix thing. So we're going to end up with as many image formats as there are walled gardens. I bet you too can't wait for whatever image format Facebook comes up with specifically to reduce their CDN bandwidth utilisation of Instagram pictures... only. Notice also that their "idea" of making an image format readily available is a docker container, which is the most insane thing I've ever seen. Where's the Photoshop plugin? The Lightroom plugin? The Windows 10 image codec? Oh wait.. those are Adobe and Microsoft things, so... nowhere to be seen. Netflix Pty Ltd is not in this game to help someone else's walled garden. No still image interchange for you peasant! Sit down, stay in the garden, and stream that content...

ksec 7y ago
First, Jpeg XL is not a Google thing, and neither is HEIC an Apple thing. Nor the AVIF part. AVIF is from Open Media which is indeed a Google Thing. Netflix just happen to take side with OM. JPEG XL is done by a Google Employees as well as other contributors put forward to the JPEG committee. i.e It is not a Google only format. HEIC is really just HEVC Codec in an image format developed by Nokia and submitted to MPEG ( Not to be confused with MPEG-LA ). So really JPEG XL isn't a walled garden. And support everything you described including HDR. The problem is Jpeg XL doesn't do so well in small image size as compared to HEIF or AVIF.

colbyn 7y ago

Interesting. Personally, I’ve been using VMAF extensively in my imager.io project. With regards to only testing the luma channel, someone submitted a PR for such some time ago yet it’s never been merged; I was under the impression that the UV channel isn’t significant (in practice). Personally, I think VMAF is great for images. For me, the biggest downside of VMAF (implementation wise) is that it’s not currently thread-safe.

pornel 7y ago

This is a major improvement. It's better than WebP by a bigger margin than WebP was better than JPEG. Lossy WebP couldn't even match JPEG in some aspects, like full-resolution color (4:2:0 only, not even full 8-bit depth). In terms of quality or features AVIF doesn't have such "buts". It can support HDR and high depth we're likely to want in the near future. AV1 has palette blocks, so it's no longer all-or-nothing choice of lossy vs lossless formats. I am worried that the AVIF spec is complex (like HEIF, it's a bag of image-related features, more like a PowerPoint file than an image), but probably only commonly-used features will survive out of it. Early JPEG also used to have many more modes than are usable today. If you like questionable hacks, you can use AV1 codec today in Firefox and Chrome by embedding <video> element with a 1-frame AV1 "video".

chungy 7y ago
> It's better than WebP by a bigger margin than WebP was better than JPEG. Depending on certain definitions of better. Image quality is certainly superior in JPEG than in (lossy) WebP.
ec109685 7y ago
The JPEG images in the article are much worse than what you can achieve with JPEG export in Preview.app. While they don't look like AVIF, they aren't nearly as trash as the article makes JPEG's out to be.

herf 7y ago

I'm no fan of 4:2:2 (2:1 chroma subsampling), but the comparison looks a lot better for JPEG when you use 4:2:2 (which is the usual JPEG default). Using 4:4:4 instead drives the blocking artifacts way up, and isn't fair to JPEG.

chubs 7y ago

I spent some time searching for a JS shim that enables AVIF files to be used in the browser, is anyone aware of one?

niftich 7y ago
The official avif github [1] references Kagami/avif.js [2]. It's intended as a server-side component to be installed, and uses service workers to on-the-fly repack AVIF images as AV1 videos. The code is licensed CC0, and is easy to read, so you can tweak it to your needs. If the browser can't natively decode AV1 videos, it calls dav1d.js [3] to decode, which is a webassembly port of dav1d [4]. [1] https://github.com/AOMediaCodec/av1-avif/wiki https://github.com/AOMediaCodec/av1-avif/wiki [2] https://github.com/Kagami/avif.js https://github.com/Kagami/avif.js [3] https://github.com/Kagami/dav1d.js https://github.com/Kagami/dav1d.js [4] https://code.videolan.org/videolan/dav1d https://code.videolan.org/videolan/dav1d

JyrkiAlakuijala 7y ago

encode.su forum posts compare image quality of JPEG XL, AVIF, WebP, MozJPEG and HEVC: https://encode.su/threads/3108-Google-s-compression-proje%D1%81ts/page3 https://encode.su/threads/3108-Google-s-compression-proje%D1... The most comprehensive comparison: https://medium.com/@scopeburst/mozjpeg-comparison-44035c42abe8 https://medium.com/@scopeburst/mozjpeg-comparison-44035c42ab... "... according to my personal visual tests, starting from 0.4–0.5 bpp it [JPEG XL] usually wins most other formats."