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

111–120 of 122 posts

Re: HEIF – High Efficiency Image File Format

#111

Post by [deleted] »

fao_ wrote: post #44
agentgt wrote: post #5

Earlier quoted context omitted.

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 sh…

[deleted]

Re: HEIF – High Efficiency Image File Format

#112

Post by vetinari »

jpap wrote: post #102
zerocrates wrote: post #21

Earlier quoted context omitted.

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…

HEIF is actually very closely related to MP4 (or really, the ISO Base Media File Format (BMFF); and historically, QuickTime which is what they are both based on). You are right -- the main difference is that BMFF was originally designed for time-based media (video, audio) but isn't in itself well suited towards media that isn't time based, like images and their associated metadata (e.g. Exif). HEIF extends the ISO BM…

> Think of HEIF as a versatile, extensible, standardized container format. The media coding scheme is separable. This is a big deal for the future of image/media coding because we're no-longer locked into "yet another format" that's tied to the codec.

There were similar approaches in the past and they failed. Electronic Art's IFF, or later TIFF, were also designed as extensible containers. The vast majority of the software handling these formats handles only the most popular codecs, the fringe one pushing it forward will get ignored.

Re: HEIF – High Efficiency Image File Format

#114

Post by cflat »

throwasehasdwi wrote: post #58

Nokia owns several HEVC patents, in fact I think they're currently suing apple about it. This is a veiled attempt to get everyone to use their patented tech so we can relive the mp3/mp4 clusterfuck. You would be a fool to use this for anything. What's so bad about WebP? It's not the best thing in the universe but it beats JPEG and PNG and has a wide support base. With a shim it has native support in most browsers any…

>What's so bad about WebP?

* Lack of clear spec ("The code is the spec")

* Lack of versioning of spec (at least 3 major versions with different capabilities/features of which not all degrade nicely)

* Forced 4:2:0 chroma subsampling

* 8bit-channel only (no support for 10bit+ aka wide-gamut images)

Re: HEIF – High Efficiency Image File Format

#116

Post by Dylan16807 »

astrange wrote: post #90
Dylan16807 wrote: post #84

Earlier quoted context omitted.

What's your threshold for significance on image decoding speed? I bet making it 4x slower would be negligible in the vast majority of cases. The computational power you need for image decoding is extremely narrow and easy to make safe. You need some mathematical operations and some loops. You don't need any APIs or data structures. Mask off all the pointers and you can have have a provably safe interpeter/compiler th…

Remember that 4x slower means (at least) 4x worse battery drain on a phone. In the modern internet there basically is never any excuse to waste resources.

But it's also on a phone where saving data transfer can give you huge battery benefits. And it's not intentional waste; having this fallback doesn't stop browsers from adding native decoders.

Re: HEIF – High Efficiency Image File Format

#117

Post by nomel »

TheCoreh wrote: post #93
zokier wrote: post #39

Earlier quoted context omitted.

I think the significance of compatibility is increasingly diminishing due the effect of "clouds" and other walled gardens that handle your data in a more integrated manner. With the advent of wasm etc it is not completely unreasonable to ship your own image decoder with the application, and optionally a JPEG encoder for on-demand client side re-encoding for exporting images. There is just less expectations to be able…

Shipping a JPEG encoder is not necessary: all browsers support encoding images via toDataURL('image/jpeg') and toBlob(...)

I think he meant non-standard, and if not, his point still stands: with webasm, you might not have to worry about silly client side things like codecs.

Re: HEIF – High Efficiency Image File Format

#118

Post by niutech »

jpap wrote: post #109
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.),…

> This format doesn't really blaze new ground (EDIT: it does in the sense that it defines a container format to express image-y constructs like still images and sequences of images in an ISO media container, but see my other comment that asks how this is similar but different to video [3]), but if this repackaging and the resulting code donation and political clout helps it gain traction, we still would gain a lot. Y…

TIFF and Exif (which JPEG is based on) are not tied to any particular codec and are extensible, so HEIF is not a game changer.

BTW: Did you know that you can embed LPCM/μ-Law PCM/ADPCM audio data in JPEG/Exif?

Re: HEIF – High Efficiency Image File Format

#119

Post by bengotow »

bengotow wrote: post #83
TD-Linux wrote: post #59

The license in the provided implementation seems to be a custom, non-commercial, non-OSI-approved license [1]. It also includes a patent grant, but excludes codec patents, making it even more useless (Nokia can't license other people's HEVC patents, of course). It's based on the LGPL-licensed libde265 library. [1] https://github.com/nokiatech/heif/blob/master/LICENSE.TXT

License notwithstanding, has anyone tried to create a HEIF file? There are a few samples on this site, but even given the code they've provided on GitHub I can't seem to create a HEIF image from another image format. Their code seems to take an H265 HEVC bytestream as input, which is fine, but I can't find anything that will build an HEVC bytestream for an image rather than a video...

Update: I figured out how to do this and posted my findings here: http://jpgtoheif.com/

Re: HEIF – High Efficiency Image File Format

#120

Post by jpap »

niutech wrote: post #118
jpap wrote: post #109

Earlier quoted context omitted.

> This format doesn't really blaze new ground (EDIT: it does in the sense that it defines a container format to express image-y constructs like still images and sequences of images in an ISO media container, but see my other comment that asks how this is similar but different to video [3]), but if this repackaging and the resulting code donation and political clout helps it gain traction, we still would gain a lot. Y…

TIFF and Exif (which JPEG is based on) are not tied to any particular codec and are extensible, so HEIF is not a game changer. BTW: Did you know that you can embed LPCM/μ-Law PCM/ADPCM audio data in JPEG/Exif?

> TIFF and Exif (which JPEG is based on) are not tied to any particular codec and are extensible, so HEIF is not a game changer.

TIFF is a great format but its ability for extensibility is limited. You can't readily contain in a video track in addition to a photo, or a burst sequence that utilizes intra-frame prediction.

> BTW: Did you know that you can embed LPCM/μ-Law PCM/ADPCM audio data in JPEG/Exif?

Yes; I once owned point-and-shoot cameras that did this. The audio was pretty poor quality because they didn't employ compression and wanted to keep the file sizes small.

However you're limited to the 64k maximum JPEG marker segment size for non-image metadata; or ugly hacks like chaining segments (e.g. ICC profiles). Exif is strictly limited to being contained within 64k. How big is your audio track again? ;-)

JPEG has had its time as a wildly successful format but has also held back the imaging world from adopting a standardized way to cater for new applications; burst above, mixed media (photo + video + audio), depth maps, stereo images, alpha (that's not a hack), lossless, etc., etc. HEIF has all the key ingredients, including extensibility, to support these modern applications and grow as the universal container format for decades to come.

Post reply on HN