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

91–100 of 122 posts

Re: HEIF – High Efficiency Image File Format

#91

Post by bengotow »

astrange wrote: post #86
bengotow wrote: post #83

Earlier quoted context omitted.

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

You can easily turn an image into a video, or into HEVC, with ffmpeg.

Haha thanks - I didn't think it supported H265 but it looks like I just have to build it from source (https://trac.ffmpeg.org/wiki/Encode/H.265). Suppose that's still fairly "easily" ;-)

Re: HEIF – High Efficiency Image File Format

#92

Post by [deleted] »

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

[deleted]

Re: HEIF – High Efficiency Image File Format

#93

Post by TheCoreh »

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

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

Re: HEIF – High Efficiency Image File Format

#94

Post by jacobolus »

astrange wrote: post #87
jacobolus wrote: post #37

Earlier quoted context omitted.

If possible, I’d much prefer having a single format that is widely supported, hardware accelerated, and with a state-of-the-art codec. Making content authors create multiple different files in different formats—some with deficient feature support—sounds like a pain in the butt for everyone. If we can get everyone to agree on a format that handles layers, exposure bracketing, transparency, animation, high bit depth, d…

If your format handles everything it isn't a format, it just is everything. (The one you want is TIFF though.)

The point is that you want support for those features (certainly the core codecs, etc.) in the spec, so if you send someone a file you can be sure they can read it.

TIFF is not useful if you want to use a state-of-the-art lossy codec and get hardware-accelerated decoding on an arbitrary mobile device, or if you want to display an animated image with transparency on a web page.

Re: HEIF – High Efficiency Image File Format

#95

Post by [deleted] »

agentgt wrote: post #81
sprash wrote: post #32

Earlier quoted context omitted.

> It looks like FLIF doesn't really support lossy well I don't know what you mean by well. As far as I'm concerned lossy FLIF beats JPEG easily. Here is a comparision: http://flif.info/lossy-artifacts.html

Whoops looks like I pasted the wrong link. Here is the correct link: http://flif.info/example.html And yes "well" is relative and what I meant by that is that its not readily easy for a normal user to do it. BTW I think Flif is damn good particularly progressive decoding. Its unclear how good HEIF progressive decoding is.

[deleted]

Re: HEIF – High Efficiency Image File Format

#97

Post by ika_ »

pornel wrote: post #60
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? WebP is based on VP8, which is now obsolete. It was meant to be a H.264 competitor, a generation behind H.265 and VP9/VP10. WebP compression efficiency is much closer to JPEG than H.265. This format beats WebP by a margin wider than WebP was smaller than JPEG.

>This format beats WebP by a margin wider than WebP was smaller than JPEG.

I have been looking for this, do you know where to find a comparison between HEIF and WEBP?

Re: HEIF – High Efficiency Image File Format

#98

Post by astrange »

jacobolus wrote: post #94
astrange wrote: post #87

Earlier quoted context omitted.

If your format handles everything it isn't a format, it just is everything. (The one you want is TIFF though.)

The point is that you want support for those features (certainly the core codecs, etc.) in the spec, so if you send someone a file you can be sure they can read it. TIFF is not useful if you want to use a state-of-the-art lossy codec and get hardware-accelerated decoding on an arbitrary mobile device, or if you want to display an animated image with transparency on a web page.

But can you actually get people to implement it if you make it that complicated? Images are pretty hard, hardware support is /actually/ really hard.

That's why it's best to accept whatever format is already out there and author to it - the only thing that matters is that it actually works when it's out there.

Actually I'm surprised there's still no good way to do animations with transparency, but maybe nobody wants to use it?

Re: HEIF – High Efficiency Image File Format

#99

Post by i336_ »

dom0 wrote: post #15
roywiggins wrote: post #10

Earlier quoted context omitted.

How many websites don't already re-encode most of the JPEGs they're handed? Facebook does- Flickr does, though sometimes you can request the original file specifically. Imgur probably does.

Imgur very much does, with a visible loss of quality.

This can be disabled in account settings though.

Re: HEIF – High Efficiency Image File Format

#100

Post by ovao »

niftich wrote: post #42
wereHamster wrote: post #29

Earlier quoted context omitted.

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

This is why many tend to consider only uncompressed/lossless formats viable for archival usage. Doubling down on those doesn't really address what you were talking about — something that you make today being viewable in browsers of the future — but with the original content itself preserved in a way that maintains its full quality, the 'deliverable' formats can be updated periodically from the original masters in a way that the content will be viewable with software 20 years from now, and without degrading quality each time.

We had similar problems in the past with physical media, and still do to some extent, but in the purely digital domain this problem is somewhat more tractable (content negotiation helps facilitate these transitions for those willing to work that into build pipelines and maintain those over time, for example.)

Post reply on HN