Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HEIF – High Efficiency Image File Format

nokiatech.github.io

Post reply on HN
Print view View original

21–30 of 122 posts

Re: HEIF – High Efficiency Image File Format

#21

Post by zerocrates »

niftich wrote: 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.),…

It mentions that it supports not only sequences but inter-frame prediction (so P- and possibly B- frames I assume), which is sort of surprising to me but of course makes sense especially given Apple's "image burst" usage. I'm also suprised to learn that WebP apparently supports P-frames in its animations.

What's really different between this and the existing usages of the MP4 container for images, though? Is it just the packaging as an "image" format, or specification of more image-y metadata?

Re: HEIF – High Efficiency Image File Format

#22

Post by dawnerd »

0x0 wrote: post #8
frik wrote: post #2

iOS11 now takes photos in HEIF instead of JPEG by default. I think that's why it's posted here.

Wonder how this will work with random websites' photo upload features. Will all other browsers break because they are serving HEVC user-uploaded content? Or will iOS transcode to JPEG on upload (triggering double lossy encoding?)

They mentioned you can share the photos like normal so I assume they'll do on the fly conversion.

Re: HEIF – High Efficiency Image File Format

#25

Post by niftich »

tehabe wrote: post #13

So HEIF is for HEVC what WebP is for VP9.

Roughly, BPG [1] is for HEVC as what WebP is for VP8 or VP9, in the sense that you take an I-frame out of a video format and stuff it into an established, classic image container.

Compared to this, HEIF is a different way of packaging HEVC frames; namely into ISOBMFF (MPEG-4 Part 12), the most basic level of MPEG container. This comes with benefits [2] that come along with using that particular container, but also drawbacks, because with some of the advanced features of HEIF you're essentially describing a sequence of frames -- which is almost like video -- but you're doing it in a way incompatible with the way you'd describe video. I'd be curious if the two "representations" are losslessly convertible, for example.

[1] https://bellard.org/bpg/ [2] https://nokiatech.github.io/heif/technical.html

Re: HEIF – High Efficiency Image File Format

#26

Post by zokier »

While the basic idea of using HVEC for still image compression is good, I'm somewhat concerned on how complex the whole format, especially the container, for HEIF is. It is kinda cute and from one viewpoint pragmatic to reuse existing container format, but I'm afraid the flexibility might have unforeseen and undesirable side-effects. And of course there is the problem of different implementations supporting different subsets and extensions of the format.

Re: HEIF – High Efficiency Image File Format

#27

Post by hutattedonmyarm »

0x0 wrote: post #8
frik wrote: post #2

iOS11 now takes photos in HEIF instead of JPEG by default. I think that's why it's posted here.

Wonder how this will work with random websites' photo upload features. Will all other browsers break because they are serving HEVC user-uploaded content? Or will iOS transcode to JPEG on upload (triggering double lossy encoding?)

They said you can share it as jpg. I assume it works like live photos: If the receiving app (or website) doesn't explicitely say it supports HEIF it'll receive a jpg

Re: HEIF – High Efficiency Image File Format

#28

Post by TD-Linux »

amluto wrote: post #7

It's based on HEVC. I wonder how bad the patent situation is.

Pretty bad.

https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#P...

If you choose to implement this format, I hope you enjoy negotiating licenses with at least four different entities so that you can display pictures.

Re: HEIF – High Efficiency Image File Format

#29

Post by wereHamster »

niftich wrote: 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.

Re: HEIF – High Efficiency Image File Format

#30

Post by repsilat »

masklinn wrote: post #18
amelius wrote: post #16

Why don't we store a url to the decoder inside images and other compressed files for maximum flexibility? I mean, looking at WASM, sandbox technology is sufficiently strong. And performance and availability aren't really an issue either, because for specific cases we can fall back to what we are doing now.

> 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.

> not being able to open an image if you don't have an internet connection sounds dreadful

Caching the decoder smells like having already downloaded the image library. Mostly just different in that "first run time" is now always the same thing as "install time".

Post reply on HN