Hacker News Reader

Comment by niftich | Hacker News Reader

This is a format combining HEIF as the container with AV1 I-frames as the payload.

HEIF is the Nokia-developed, MPEG and ISO-blessed container for image sequences and transforms, which is published as MPEG-H Part 12, and is based on the good-old ISOBMFF, which you typically recognize as the ".MP4 container". HEIF's most wide deployment right now is on Apple iPhones, where it's the new default capture format for still images and 'live' images (effectively, a short video on either side of a high-res still).

AV1 is the AOMedia-developed, Google/ex-On2/Xiph.Org/Cisco consensus video format that's the evolution of the VP8/VP9 line and Daala.

This format takes the nice royalty-free state-of-the-art MPEG container and puts a royalty-free payload in it, making it a useful best-of-both-worlds.

View on HN

Comparing HEVC-based and AV1-based: there's a tech demo (that I've posted here...a lot now heh) at https://people.xiph.org/~tdaede/av1stilldemo/. Both AV1 and x265 intra look great. If the artifacts when you compare to originals bug you, remember this is just a test at a level where JPEG is painfully blocky, and you can go higher!

Visually, I think AV1 adds less DCT-ish noise, but tends to blur small, low-contrast details a little more than x265. (Compare the ends of tree branches on the default image, Crepuscular Rays, or faraway tiles and details in Mercado dos Lavradores. Haven't done objective measurements though--you may disagree.) I, personally, like AV1's tradeoffs better, at least from what I see there. Patches of ringing draw attention, whereas slight blurring is something we're used to ignoring since it comes from lots of things besides codecs; natural vision and camera images aren't completely sharp either. (Dunno why AV1's that way, but might be that it does more aggressive deringing with that filter Monty's posting about next.)

The photo caption on the comparison in this story suggested the same conclusion re the detail vs. noise tradeoff, for what it's worth: https://www.cnet.com/news/google-mozilla-av1-photo-format-co...

The paper on the deringing filter included subjective tests, and it suggests that test subjects liked its results more consistently than you might guess from the changes in objective metrics--small sample size though: https://arxiv.org/pdf/1602.05975.pdf

Sometimes you may want x265's bias towards more detail; in the Tiger image, AV1 "cuts" the whiskers near the top of the image shorter than x265 does. Tricky to 'teach' encoders that some detail is more important than others despite both being equally low size or contrast.

Given they're both a ton better than JPEG, the big advantage to AV1 for a random developer is the openness; we can use it w/out needing to either take a legal risk or lean on the implementation of some company that's dealt with the HEVC patent mess for us.

To my eyes and preference, both x265 and AV1's stills are far less blocky and far too smoothed than I'd like, but then again I've been an unabashed proponent of less smoothing [1], having lived through early H.264 encoders' blurry messes.

Once I get past that, some of the test images look better on AV1, and some look better on x265. Some of them kill detail here, some of them kill detail there. I think this is a victory -- both of them perform really well, considering, and allocating a bit more bits to get it looking nice is always an option.

It's good to have a royalty-free codec that's actually good, and with much more profile and fanfare than just a weird garage-band secret project like VP9 was. And with widespread hardware support, it may actually make a dent in JPEG's marketshare.

[1] https://hn.algolia.com/?query=niftich%20fake%20sharpness&sor...

I'm with you - I find both AV1 and x265 to be over-smoothed. On the other hand, at these compression ratios, you don't get something for nothing, and I certainly appreciate the lack of block artifacts.

Uppermost tree branches almost disappear with both AV1 and X265 when background is the cloud. Jpeg manages to display them.

Jpeg still trims the trees, just not as much.

In your demo, how are the images chosen for each image and algorithm combination? I mean how do you choose the compression level for each, to keep the comparison fair? I would hope you have a budget in KB and go as high quality as you can without going over that KB limit.

Not my demo, it's from someone at Mozilla, but, yes, the usual practice for comparisons is to match the size of the compressed content. I don't have context for that page, so I can't actually cite anything here.

Isn't HEIF the payload and HEIC the container? (also C seems to stand for container in HEIC...).

It's confusing how people seem to use HEIF to mean container. And if HEIF is actually the container, then what is the payload in Apple's case, and what exactly is HEIC?

HEIF is the name of the container [1][2].

HEIC is an ISOBMFF 'brand' to be used inside the container to indicate that the payload's codec is HEVC (in 'Main' profile or 'Main Still Picture' profile), and that it's one still-image and not a sequence [1].

In most of the cases where the payload is the HEVC codec, the corresponding file extension is encouraged to be .heic and the MIME-type follows as well. Apple has a note about this in their transcript at WWDC 2017 [3].

[1] https://nokiatech.github.io/heif/technical.html [2] https://mpeg.chiariglione.org/standards/mpeg-h/image-file-fo.... [3] https://developer.apple.com/videos/play/wwdc2017/513

Reply on news.ycombinator.com