Talk:High Efficiency Image File Format

Licensing?

Nothing about intellectual monopolies and licensing? -Reagle (talk) 21:28, 5 June 2017 (UTC)

The silence is deafening – all we know so far is a priori knowledge. We know:

• Set theory: HEVC patents that apply to HEIF ⊆ HEVC patents
• Patents are patents: You don't escape them by using them in a new product, reimplementing or even reinventing them. → The use of HEVC patents in HEIF, if any, is bound to comply with the relevant patent holders' demands. For what patent law is concerned, they may demand whatever.
• Rules of ISO/ITU-T: Contributors must offer patent licensing under FRAND terms (i.e. not demand whatever). The demands of patent holders in the case of HEVC is patent licenses. → The use of HEVC patents in HEIF, if any, is specifically bound by HEVC patent licensing, unless otherwise permitted by patent holders.

I tried (not as rigorously as this), but it got reverted[1] as "original research"… Is a priori knowledge (e.g. "a human on Mars would not be weightless because of this thing called gravity") original research? 84.208.177.88 (talk) 20:45, 14 June 2017 (UTC)

HEIF is a container format. It stores images which are compressed using HEVC. So of course HEVC patents may apply to the compression and decompression steps (depending on the HEVC patents... some features may not be supported in an HEIF image). In general, such a section on a Wikipedia article could be construed as legal guidance, or legal advice (something only lawyers should engage in). You won't find a lot of articles giving any definitive guidance at this point. The patent situation around HEVC is still being sorted out by all of the companies and organizations involved. Tvaughan1 (talk) 21:02, 14 June 2017 (UTC)

For anyone interested in a fair judgement of pros and cons, I think it would be dishonest of us to say "no, the cons are for lawyers only". In my opinion, this essay has a neutral point of view (excellently covers both pros and cons).84.208.177.88 (talk) 03:21, 4 July 2017 (UTC)

Hi, I was the person who originally removed the section ([2]). I did this because it was unsourced, and additionally a piece of original research. I now see some sources are supplied. As long as the article text only states what the sources say (and no more), there shouldn't be a problem with it. Stickee (talk) 01:30, 1 August 2017 (UTC)

Nokia is claiming it has patents on the HEIF container format itself, and those are not royalty-free. You can get a royalty-free license for non-commercial purposes (see [3]), but for commercial purposes, as far as I understand you still need to license HEIF even if you only intend to use it with an AV1 or JPEG payload, or risk a patent infringement lawsuit from Nokia (which might be bogus because it's "just a container", but that's for the judge to decide and you'll have to pay lawyers first anyway). So I think the claim in the article that "HEIF itself is a container that is not subject to royalty fees." is potentially untrue.

In my opinion HEIF not "just a container" since it also contains some nontrivial functionality like grid compositions, rotation, etc. It's not just a simple wrapper. I don't think any of that functionality is novel (it's not doing anything that wasn't already possible in e.g. XCF or PSD, for example, so there is clear prior art), so I think patent claims would not hold up. But still, Nokia has clearly NOT given a full royalty-free license (including for commercial purposes), and even if their patents may not hold up in court, they can still use them to troll. — Preceding unsigned comment added by 2A02:1811:241F:D700:5C4F:7468:D5F9:6AAE (talk) 08:19, 7 May 2020 (UTC)

Patent issues

Clearer statement of the patent implications for programs that work with HEIC files is needed.

I read the article and some of the references, and concluded that HEIC (which I understand to mean HEVC-encoded images in a HEIF container) is encumbered by patents. But Gimp on Debian 10 (from the main, i.e. free, repository) can create HEIC files. Generally the Debian people are very careful about patent issues, so this suggests that HEIC is not encumbered by patents. Obviously I'm confused. For many users, this is the single most important point about HEIC, and the article should state the position with crystal clarity. Sayitclearly (talk) 15:08, 3 December 2019 (UTC)

First, as I understand it, HEIF is simply a container format. There are 2 or 3 codecs already defined for usage in the container. But there's also a separate specification to store AV1 in the same container AV1#AV1 Image File Format (AVIF). The container itself is not believed to be patent encumbered, so you implement support for the container. I don't think there's any real doubt that even the subset of HEVC required for decoding HEIF with HEVC appears to be affected by patents see e.g. [4] [5]. As to what's happened with Debian, I guess either someone at Debian screwed up, or there's something about Debian's stance that you're not understanding. Nil Einne (talk) 14:43, 14 March 2020 (UTC)

Supported Bit Depth?

What are the bit depths supported by HEIC and AVIF?--2A02:810A:86C0:6590:E16C:EDE7:4D98:EEFC (talk) 22:55, 11 July 2020 (UTC)

Half the storage space?

While the (non-technical) refs quote "half" the storage space, the comparison image shows 9.08kb to 9.15/9.16kb - hardly half. I'm suspecting the HEIF is more efficient for animations or videos, but seems to me that the assertion of half is misleading. Thoughts? peterl (talk) 16:20, 8 July 2021 (UTC)

I assume it means half the storage space at a comparable quality level. In the comparison image, the fixes are of comparable sizes, but the HEIC image is much higher quality. --Ahecht (TALK
PAGE) 03:01, 12 November 2021 (UTC)

The image is a visual indication of the improved compression efficiency the format brings. "Same quality at half the storage space" and "twice the quality at the same storage space" are just two sides of the same coin. The format can give you one or the other, or some of both, but for the purposes of a visual comparison it makes more sense to normalize the file size instead of the quality. Because if you normalize the quality, you'd just be showing row of similar-looking images, which is kind of pointless for a visual comparison. --Veikk0.ma 03:53, 12 November 2021 (UTC)

Biased comparison photos

The JPG versions of the original image are all purposely encoded at a bad quality, IMO, to falsely highlight why HEIC is better. When I saved the original as JPG using Paint Shop Pro 7.02's default JPG quality, it was basically indistinguishable from the original. Compare my tests: https://i.imgur.com/HxC6D0b.png (image saved as PNG from the original image, my saved JPG, and the article's purposely low-quality JPG image). Or to toggle between both, open these two images in two browser tabs and flick between them: https://i.imgur.com/qdMYPhX.png (original), https://i.imgur.com/sswomAX.jpg (my JPG). Not much difference, right? My JPG looks infinitely better than all JPGs in the comparison shots. The article comparisons are obviously biased and not neutral. — Preceding unsigned comment added by 117.20.69.166 (talk) 23:28, 11 November 2021 (UTC)

Your JPEG is 55 kB, whereas the original comparison is of images at around 9 kB each. Read the caption! — kashmīrī ^TALK 23:46, 11 November 2021 (UTC)

I can see the captions say 9 KB (approx), so? That just further proves the JPG images were saved at a crap quality. A real test is of JPG at its default quality, like I did. — Preceding unsigned comment added by 117.20.69.166 (talk) 00:18, 12 November 2021 (UTC)

@117.20.69.166: You've misunderstood the purpose of the comparison. It visualizes the bandwidth/storage space advantage of newer formats by normalizing the file size, which is a common way of comparing the efficiency of image formats. It shows how much more visual information other formats are able to provide in the same amount of space.

The other way of doing a comparison would be trying to normalize quality, which is difficult to do because the various objective quality metrics (like SSIM) don't do a good job of measuring what actually looks good to the human eye. Furthermore, such a comparison wouldn't make sense in image form because you'd just be showing essentially similar-looking images side-by-side.

Also, there's no such thing as "default quality" for JPEG. Some applications or libraries may decide to encode JPEG images in certain ways, but the JPEG standard doesn't define a default quality setting of any kind. And as a side note, the 0-100 quality scale seen in various applications is also completely arbitrary and not defined in the JPEG standard, so different applications can produce drastically different results when creating a JPEG at the "same" setting. --Veikk0.ma 03:43, 12 November 2021 (UTC)

History - needs cleanup

This sentence sucks:

On some systems, pictures stored in the HEIC format are converted automatically to the older JPEG format when they are sent outside of the system, although incompatibility has led to problems such as US Advanced Placement test takers failing due to their phones uploading unsupported HEIC images by default, leading the College Board to request students change the settings to send only JPEG files.

It appears to be contradictory, since if the "pictures stored in the HEIC format" are converted automatically, the phones should not be "uploading unsupported HEIC images by default".

125.168.70.113 (talk) 07:43, 27 December 2023 (UTC)

Hei igjen Aillar cimza 176.52.35.232 (talk) 17:46, 20 July 2024 (UTC)