View Full Version : HEIC color volume properties
zambelli
13th January 2022, 19:59
When encoding still images in HEVC for storage in HEIF, what are the expected color range, primaries and matrix? HEIC brand restricts HEVC to Main profile, which in turn constrains it to 8-bit 4:2:0, but is it supposed to be TV or PC range? BT.601 or BT.709 color matrix? I suppose EOTF doesn't matter as much since it's identical for 601 and 709, and color primaries are close enough to also be somewhat interchangeable, but the choice of default range and matrix seems pretty important to getting the right output.
rwill
13th January 2022, 20:05
That information is stored in the VUI parameters in the stream headers. The default should be all 'undefined'.
Balling
2nd February 2022, 21:29
EOTF for still images is sRGB, not BT.709. Wow. You can use TV or full.
benwaggoner
2nd February 2022, 21:52
EOTF for still images is sRGB, not BT.709. Wow. You can use TV or full.
sRGB and 709 have identical color primaries, right? They are functionally interchangeable other than RGB<>YUV.
I need to try making a Rec.2100 PQ HEIC and seeing if my iPhone shows it properly as HDR. It's frustrating that we've had HDR video for years now, and still don't have an interoperable HDR still image format.
PQ and 2020 are based on still image research! We already know they are very well suited for images and photography.
kasper93
3rd February 2022, 07:59
It's frustrating that we've had HDR video for years now, and still don't have an interoperable HDR still image format.
Some time about I was playing with AVIF and it works fine, if it's supported. Chrome tone maps it correctly for example. Native Windows photo viewer also supports them correctly. And many more...
Since ffmpeg doesn't support avif, need to manually convert in two steps, but it works.
AVIF_COLOR_PRIMARIES_BT2020 = 9,
AVIF_TRANSFER_CHARACTERISTICS_SMPTE2084 = 16,
AVIF_MATRIX_COEFFICIENTS_BT2020_NCL = 9,
ffmpeg -ss 00:10:00 -i input.mkv -frames:v 1 -strict -1 hdr_avframe.y4m
avifenc hdr_avframe.y4m hdr.avif --lossless --cicp 9/16/9
Screenshots for HDR video content is an issue, because while you can do like above, I feel like there is not much interest to make it more streamlined.
HEIF and AVIF support in ffmpeg is open topic. And I feel until it is supported there it won't get more popular.
https://trac.ffmpeg.org/ticket/7621
https://trac.ffmpeg.org/ticket/6521
Balling
5th February 2022, 20:43
sRGB and 709 have identical color primaries, right? They are functionally interchangeable other than RGB<>YUV.
I need to try making a Rec.2100 PQ HEIC and seeing if my iPhone shows it properly as HDR. It's frustrating that we've had HDR video for years now, and still don't have an interoperable HDR still image format.
PQ and 2020 are based on still image research! We already know they are very well suited for images and photography.
Primaries yes, transfer NO. It is even completly different type of it. sRGB is display referred and BT.709 is scene reffered, just like PQ vs HLG.
There are AVIF pq samples from Netflix. And they work perfectly in Chrome. https://github.com/AOMediaCodec/av1-avif/tree/master/testFiles/Netflix/avi
Blue_MiSfit
7th February 2022, 22:48
I was under the impression that BT. 709 did not define an EOTF at all, just an OETF?
Balling
8th February 2022, 05:48
I was under the impression that BT. 709 did not define an EOTF at all, just an OETF?
The color managment happens with inverse OETF, not using its EOTF BT.1886. ON SCENE linear light, not display linear light. Then you apply OETF again and then you decode using (usually in display, but not always, like on Apple devices) EOTF depending on display and room, that is with D65 10 lux light and OLED screen can be 2.4 gamma. But on LCD BT.1886 is 2.2 gamma and of course with light room also the peek luminace is increased to 200 nits from 100 nits. If you show in perfect black environment you can use 2.6 gamma with 48 nits.
And back then BT.709 technically assumed 2.35 gamma of CRT. So when move to LED happened it became 2.4.
BTW, linear part of the transfer function really only matters for OETF, not EOTF (or otherwise part of black codepoints will be not used at all, simple math), but of course sRGB assumes display will do linear part in EOTF too (which most of them do not). And yes if you just get YCbCr values from a movie it should use BT.709 and BT.1886 and it should use primaries and matrix from that movie, HEIF allows that. sRGB inverse OETF is the EOTF.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.