Live data from Hacker News

HEIF – High Efficiency Image File Format

nokiatech.github.io

41–50 of 122 posts

Re: HEIF – High Efficiency Image File Format

#41
post #33

Earlier quoted context omitted.

> Why don't we store a url to the decoder inside images and other compressed files for maximum flexibility? Image formats are already some of the biggest attack surface of modern systems, "executable" image formats (hello PDF) have an absolutely ghastly track record there. And not being able to open an image if you don't have an internet connection sounds dreadful.

But, as I already implied, if we can safely run arbitrary "binary" code of the internet (see WASM), why can't we run arbitrary code of a decoder?

The things that make it safe to run that code will significantly negatively impact image decoding speed right now. That's not necessarily a fundamental problem with the universe, but it's a true statement at the moment.

And that's accepting that WASM is safe, which I do not axiomatically accept. History suggests that I am very safe in claiming that most implementations will end up with some catastrophic-level security vulnerabilities in them before all's said and done.

Re: HEIF – High Efficiency Image File Format

#42
post #20

This seems conceptually most similar to Fabrice Bellard's proposal 'BPG' [1], which was essentially a lightweight wrapper around an HEVC I-frame. The format got small amounts of attention in encoding circles, but didn't pick up mainstream traction. The image encoding layer of HEIF is the same HEVC, but the container is MPEG-4 Part 12 (the Quicktime-descendant ISO Base Media Format; the core behind .mp4, .3gp, etc.),…

At last for the web (which is what WebP targets mostly, right?) you don't need broad support. We have the new element where the UA selects the most appropriate image from a list of options. So Chrome will prefer webp, other browsers will pick jpeg, png or whatever else they support at the moment.

The problem is, content delivered over the web "leaks out" in standard usage and interfaces with the overworld, unless prevented by DRM. People save files, sometimes using contrived workflows, and content that was transferred to a browser for display (such as WebP) will eventually be downloaded, shared, and reposted somewhere else. Facebook once famously migrated serving most images as WebP and had to back out because people were downloading images, only to end up with .webp files that are unsupported in other programs [1].

In the past, I articulated, on the topic of 'Ask HN: Software for writing a diary that will be around in 20 years from now' [2]:

I'd be wary of the archival potential of formats that are solely used on the Web with little usage on tangible physical hardware by major commercial publishers -- the Web of today moves very fast and technologies come and go. Google is pushing WebP, WebM, but work is already under way on a big consensus format called AV1. When AV1 comes out, new VP8/VP9 content will likely no longer be produced. Browsers periodically prune older features, 20 years is almost as long as the web has been around, and given enough time support for the format may only be available in software that make format coverage an explicit goal (ffmpeg, libav, VLC). Opus is being made a mandatory audio codec for WebRTC, teleconferencing is usually ephemeral -- will there be lots of .opus files sitting on disks in the future? Too early to tell, not worth gambling on.

The context of this was choosing formats for the express purpose of long-term archival, but our incidental usage of formats today will shape the sort of files that will be naturally around in our future.

[1] https://news.ycombinator.com/item?id=5589206 [2] https://news.ycombinator.com/item?id=12979854#12980359

Re: HEIF – High Efficiency Image File Format

#43
post #6
post #3

What benefits does this have over PNG, farbfeld, etc. ?

PNG is a lossless format, it's pretty much pointless for photos. IDK about farbfelt but it seems like a TIFF competitor more than anything else. This is an (significant) improvement over JPEG.

> a lossless format [is] pretty much pointless for photos

Why is that? Every edit you make to that photo means that the photo will degrade in quality. I always thought JPEG artifacts and compression lossage was a bad thing for photos, not a good thing?

Re: HEIF – High Efficiency Image File Format

#44
post #5
post #3

What benefits does this have over PNG, farbfeld, etc. ?

If you bothered just navigating the site you would have found this page with a table (table II): https://nokiatech.github.io/heif/technical.html

A lot of the items on that table really aren't very self-explanatory (Derived image, for example, obviously has a clearly defined meaning in this context, and it appears to be contrary to what I expect it to be). They assume a background that I don't have, and at the moment I don't feel that I have the time to spend obtaining it. I was asking for more of a layperson's comparison of the differences. Read it as "Why should I prefer HEVC over PNG, when they appear to be mostly identical".

Re: HEIF – High Efficiency Image File Format

#45
post #41
post #33

Earlier quoted context omitted.

But, as I already implied, if we can safely run arbitrary "binary" code of the internet (see WASM), why can't we run arbitrary code of a decoder?

The things that make it safe to run that code will significantly negatively impact image decoding speed right now. That's not necessarily a fundamental problem with the universe, but it's a true statement at the moment. And that's accepting that WASM is safe, which I do not axiomatically accept. History suggests that I am very safe in claiming that most implementations will end up with some catastrophic-level securit…

> The things that make it safe to run that code will significantly negatively impact image decoding speed right now.

Okay, but as I said before, for specific cases we can still do things the old way. I.e., upon decoding we detect that the url points to a known format, and we run the fast+safe decoder. For unknown formats, we download the slow decoder and use that. This way, we have more than what we would otherwise have (flexibility). And in the future, WASM will be faster anyway. I only see benefits. Of course, the sandbox should be formally proved correct first.

Re: HEIF – High Efficiency Image File Format

#46
post #43
post #6

Earlier quoted context omitted.

PNG is a lossless format, it's pretty much pointless for photos. IDK about farbfelt but it seems like a TIFF competitor more than anything else. This is an (significant) improvement over JPEG.

> a lossless format [is] pretty much pointless for photos Why is that? Every edit you make to that photo means that the photo will degrade in quality. I always thought JPEG artifacts and compression lossage was a bad thing for photos, not a good thing?

[deleted]

Re: HEIF – High Efficiency Image File Format

#47

It's really sad that Apple decided to support the proprietary H.265 and this image format instead of the royalty-free WebP and WebM.

I think you're confused. WebM is a container not a codec.

And either way VP9 and AV1 are simply inferior codecs to H.265 in almost every way. And as for royalty free well that's because MPEG-LA has't ever sued but they did give a royalty free license to Google for patents infringed by VP9. And since Google accepted it does indicate that AV1 is likely to also be patent encumbered.

We would all like a royalty free codec but it isn't happening anytime soon. And so failing that I would prefer to go with the codec with the best support which by far is H.265.

Re: HEIF – High Efficiency Image File Format

#48

It's really sad that Apple decided to support the proprietary H.265 and this image format instead of the royalty-free WebP and WebM.

Maybe WebP has some scary patent grant a la Facebook React that made Apple conclude paying MPEG licenses is cheaper than a potential Google suit.

Re: HEIF – High Efficiency Image File Format

#50
post #43
post #6

Earlier quoted context omitted.

PNG is a lossless format, it's pretty much pointless for photos. IDK about farbfelt but it seems like a TIFF competitor more than anything else. This is an (significant) improvement over JPEG.

> a lossless format [is] pretty much pointless for photos Why is that? Every edit you make to that photo means that the photo will degrade in quality. I always thought JPEG artifacts and compression lossage was a bad thing for photos, not a good thing?

The compromise is that with lossy compression, you can significantly shear the filesize used for retrieval, which granted isn't an issue of speed (but still is for bandwidth consumption).
Post reply on HN