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

81–90 of 122 posts

Re: HEIF – High Efficiency Image File Format

#81

Post by agentgt »

sprash wrote: post #32
agentgt wrote: post #17

Earlier quoted context omitted.

It looks like FLIF doesn't really support lossy well (its sort of fake lossy). "FLIF does not have a lossy mode, but interlaced files can be decoded progressively so we can simply use something like dd if=lossless.flif of=lossy.flif bs=1024 count=5" You can see this in the examples where BPG does well in stream loading: https://nokiatech.github.io/heif/technical.html HEIF would probably be similar to BPG in performan…

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

Re: HEIF – High Efficiency Image File Format

#82

Post by Dylan16807 »

abritinthebay wrote: post #75
Veratyr wrote: post #67

Earlier quoted context omitted.

> As I listed above there are at least 100+ more companies supporting H.265 than AoM. AV1 isn't finalized yet . Of course HEVC is being shipped in more stuff, it's being shipped at all. I'm not debating this, there's no debate. At present HEVC has more support than a codec that isn't yet finished. H.264 had more support when VP9 was being developed too, that doesn't make VP9 inferior to H.264. > broadcast standard fo…

> AV1 isn't finalized yet. You keep saying that as if it solves anything. Released > Unreleased. Is that a criticism of the format's potential ? No! But it may as well not exist until it is finalized... so it can't be a competitor to a format that has been .

If it doesn't exist, then it can't have poor vendor support.

It will have good vendor support when it exists.

Re: HEIF – High Efficiency Image File Format

#83

Post by bengotow »

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

Re: HEIF – High Efficiency Image File Format

#84

Post by Dylan16807 »

jerf wrote: post #41
amelius wrote: 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…

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 that runs pretty fast.

Re: HEIF – High Efficiency Image File Format

#85

Post by Dylan16807 »

fao_ wrote: post #43
masklinn wrote: 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?

Generation loss is not inherent to lossy compression. The blame lies mostly or entirely on encoders. Here's an example of doing it right:

https://www.youtube.com/watch?v=IheZzcYUV9w https://www.youtube.com/watch?v=w7vXJbLhTyI

Re: HEIF – High Efficiency Image File Format

#86

Post by astrange »

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

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

Re: HEIF – High Efficiency Image File Format

#87

Post by astrange »

jacobolus wrote: post #37
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.

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

Re: HEIF – High Efficiency Image File Format

#88

Post by astrange »

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…

WebP should not have been released. It was created by skal right before Google released VP8, and nobody had any time to work on the actual format or even see it before it was frozen. You could easily beat it in quality by now.

Re: HEIF – High Efficiency Image File Format

#89

Post by Veratyr »

abritinthebay wrote: post #75
Veratyr wrote: post #67

Earlier quoted context omitted.

> As I listed above there are at least 100+ more companies supporting H.265 than AoM. AV1 isn't finalized yet . Of course HEVC is being shipped in more stuff, it's being shipped at all. I'm not debating this, there's no debate. At present HEVC has more support than a codec that isn't yet finished. H.264 had more support when VP9 was being developed too, that doesn't make VP9 inferior to H.264. > broadcast standard fo…

> AV1 isn't finalized yet. You keep saying that as if it solves anything. Released > Unreleased. Is that a criticism of the format's potential ? No! But it may as well not exist until it is finalized... so it can't be a competitor to a format that has been .

> VP9 and AV1 are simply inferior codecs to H.265 in almost every way.

This was your claim.

Let me sum up the entirety of my position so we're on the same page:

- In terms of compression, AV1 is competitive with or beats HEVC, despite not being finalized.

- AV1 has support from everyone but of import save Apple when it comes to the web.

- Apple's support is not necessary for a codec to be successful (see VP9).

- AV1 is not finalized. There's more work to do. Particularly, I don't expect the present encoder/decoder implementations to be competitive with the HEVC encoders when it comes to CPU efficiency.

- HEVC has solid adoption in some areas (the more "traditional" areas like video cameras, TVs, broadcast) but has zero adoption when it comes to the web and this is extremely unlikely to change due to the patent mess.

- As members of the AoM, it's near certain that Microsoft, Google and Mozilla will add AV1 support to their browsers, which, depending on the particular source you look at, cover roughly 70% of the total browser market.

- Due to AoM support and HEVC not being an option, AV1 will be the primary successor to H.264/VP9 on the web.

- Due to its likely widespread availability from streaming services on the web and support from hardware vendors, AV1 will be prolific in other kinds of hardware.

- Due to the support of Apple and the broadcast industry, HEVC will likely not go away anytime soon.

- I agree that HEVC is not currently a viable alternative to HEVC, it not being finalized yet and all, however despite that, there are already aspects in which it is already superior, namely compression and likelihood of being supported on the web.

Re: HEIF – High Efficiency Image File Format

#90

Post by astrange »

Dylan16807 wrote: post #84
jerf wrote: post #41

Earlier quoted context omitted.

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…

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.
Post reply on HN