Talk:High Efficiency Image File Format

Computing: Software / Free and open-source software Low‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Software.
	This article is supported by Free and open-source software.

Technology

This article is within the scope of WikiProject Technology, a collaborative effort to improve the coverage of technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.TechnologyWikipedia:WikiProject TechnologyTemplate:WikiProject TechnologyTechnology

Archives

Archive 1

This page has archives. Sections older than 30 days may be automatically archived by .

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

Split required

This article seems to conflate two unrelated file formats: HEIF (the open container/metadata format) and HEIC (the proprietary image format based on HEVC). The information about HEIC should be split into a new article, or possibly moved into HEVC (since it looks like HEIC is just the special case where the "video" you're storing only includes a single frame). – Closed Limelike Curves (talk) 01:24, 14 July 2025 (UTC)[reply]