Comment by pornel | Hacker News Reader

Comment by pornel | Hacker News Reader

Parent Full thread

The format is incredibly complex kitchen-sink of features and legacy ISO specs. There is an open-source library for it, but it's written in C++, and issues filed about it make it look like it's insecure (i.e. a large complex C++ codebase written by less than an expert) and not even entirely compatible with Apple's implementation.

So I think it's fine to leave HEIF as basically an internal format of Apple's camera app, and for everything else export to formats more suitable for interchange (e.g. BPG which uses same the compression scheme, but is a simple lightweight container).

I dunno, I think the container format sounds pretty reasonable, at least at a high level (I haven’t tried to implement it or anything). Many of those features [choice of lossy or lossless compression; extensible embedded metadata; multiple images per file; animation; transparency; embedded thumbnail; non-destructive indication of preferred crop/rotation; choice of color spaces and bit depth; ...] are extremely useful, but currently are only supported (in conjunction) by completely proprietary app-specific formats like PSD or the like.

I can imagine at least a dozen use cases for this format that current formats don’t serve at all.

See this post implementing it in ffmpeg: https://ffmpeg.org/pipermail/ffmpeg-devel/2017-August/215003...

I guess the main possibilities are (1) use an existing openly specified format, for which there is already at least some published working code, even if it isn’t perfect, or (2) invent a brand new format, and hope you don’t screw it up somehow by overlooking something important. I’m not entirely convinced #2 would have been any better (does Apple have a good reputation for inventing data serialization formats?), and inre #1 I’m not sure if there’s any extant choice better than this new format with support for all of the uses Apple cares about.

Considering that all the widely supported formats throughout the industry have various severe limitations so that it’s impossible to cover the typical use cases (even for just web images, say) using less than 3 or 4 completely different formats, it’s not clear that anyone else has figured out how to really solve this one either.

Too bad that the world couldn’t find someone with good taste, extensive experience, and a forward-looking vision to make a more future-compatible image format about 15–20 years ago.

In this particular case, (1) and (2) were pretty much the same, as the format that became HEIF was drafted up in 2013 and finished in 2015, by Nokia, as a contribution to the proceedings of the joint MPEG/ITU-T JCT-VC working group working on the standard MPEG-H; it was accepted.

Previously, with Apple 'live photos', having two separate files sitting on the disk was good enough.

HEIF is very new, but it's now blessed by the premier standardization organizations in this space as a component of the next wave of media coding. Aside from the the innate value of standards in which industry players agree on common formats and semantics, Apple's move needs to be seen in context of the rival 'Alliance for Open Media' [1], which includes many big names working on future open media codecs outside of the usual MPEG / ITU-T / contributors' patent pool combo. Apple's adoption of an MPEG standard is also signalling its commitment to that particular brand of standardization.

[1] http://aomedia.org/about-us/

It was over engineered from a Image format perspective, but it is very likely Apple has a lot of things in mind and things like Live Photos or whatever they are making.

Webp supports most of those features actually, iirc. I mean HEIF is to HEVC as WEBP is to VP8, right?

Not that webp is as incredible as Google claimed, but that was always a given with the inferior codec it’s based upon.

Reply on news.ycombinator.com