HDR10+ And Dolby Vision Theory - SDR conforming

[demoboy]

I only have experience with Dolby Vision 8.4 by Apple iPhone protocol. When I drop images into PP, the clip looks great, and I like the already baked image from the iPhone. I’m not interested in color grading or color correction. My white balance is measured to 97-99% “accuracy” for my tests, calibrating for skin tones of course, and locking the WB.

So my question is, since I’m not interested in HDR publishing, can’t I just set the working color space to Rec.709? Premiere offers SDR conforming in various codecs, so is it fine or do I always have to be in Rec2100 in my sequence settings?

I ask because I’ve done various renderings by others when publishing the HDR metadata. YouTube is able to collect the metadata just fine, but I notice color changes in skin tone when I haven’t done any color grading or manipulation. For example when I play a Filmic Pro clip via HDMI cable from iPhone the Dolby Vision is translated correctly.

One thing I don’t like abou the iPhone technology is the dynamic range stretching done in real-time in low light scenes whenever a brighter are is presented. There’s no way around that even Soderbergh griped about it.

 

[Tom Roper]

So my question is, since I’m not interested in HDR publishing, can’t I just set the working color space to Rec.709? Premiere offers SDR conforming in various codecs, so is it fine or do I always have to be in Rec2100 in my sequence settings?

With the disclaimer that I use Resolve, Rec.2100 is just a recommendation. If you want to be compliant with it or HDR10, HDR10+, HLG then yes, you need to be using 2100 color space which is the same as bt.2020. On the other hand, if you don't care about compliance to the recommendation and just want color to be properly displayed on every HDR10, HDR10+, HLG supporting device, it's enough to just specify 709 as the color space in your st2086 static metadata. This is generally done in HEVC with syntax --colorprim bt709 --transfer 16. Colorprim and transfer are thus the two essential pieces of static metadata needed to switch the device's EOTF and WCG modes. It's not necessary to be compliant with rec.2100 to put the device into modes that properly display EOTF and WCG, which could be ST2084 or ARIB STD-B67, and 709 or P3 or 2020.

But if you want compliance specifically with HDR10, HDR10+, HLG and DV, then yes you need to use 2100 (or 2020) gamut space. Since 709 and P3 are color spaces fully contained within the 2020 RGB primary endpoints, you can elect to use 2020 for your gamut with 2020 coordinates that correspond to the 709 boundaries contained within. If you rolled out some cookie dough and cut a shape out of the middle with a cookie cutter, the you would be defining the new shape by a subset of 2020 coordinates, and thus your color space is just a 709 limited subset of 2020 but still using 2020 coordinate system. That gives you rec.2100, HDR10, HDR10+, DV compliance and your metadata syntax could then be specified --colorprim bt2020 --transfer 16.

What you don't want to do, is anything that remaps 709 RGB endpoints to 2020 or vice versa.

Use the 2020 coordinate system to point to the 709 subset contained within the 2020 colorspace boundaries and use --colorprim bt2020 syntax in the metadata, or use the 709 coordinate system and use --colorprim bt709 syntax in the metadata.

 

[demoboy]

With the disclaimer that I use Resolve, Rec.2100 is just a recommendation. If you want to be compliant with it or HDR10, HDR10+, HLG then yes, you need to be using 2100 color space which is the same as bt.2020. On the other hand, if you don't care about compliance to the recommendation and just want color to be properly displayed on every HDR10, HDR10+, HLG supporting device, it's enough to just specify 709 as the color space in your st2086 static metadata. This is generally done in HEVC with syntax --colorprim bt709 --transfer 16. Colorprim and transfer are thus the two essential pieces of static metadata needed to switch the device's EOTF and WCG modes. It's not necessary to be compliant with rec.2100 to put the device into modes that properly display EOTF and WCG, which could be ST2084 or ARIB STD-B67, and 709 or P3 or 2020.

But if you want compliance specifically with HDR10, HDR10+, HLG and DV, then yes you need to use 2100 (or 2020) gamut space. Since 709 and P3 are color spaces fully contained within the 2020 RGB primary endpoints, you can elect to use 2020 for your gamut with 2020 coordinates that correspond to the 709 boundaries contained within. If you rolled out some cookie dough and cut a shape out of the middle with a cookie cutter, the you would be defining the new shape by a subset of 2020 coordinates, and thus your color space is just a 709 limited subset of 2020 but still using 2020 coordinate system. That gives you rec.2100, HDR10, HDR10+, DV compliance and your metadata syntax could then be specified --colorprim bt2020 --transfer 16.

What you don't want to do, is anything that remaps 709 RGB endpoints to 2020 or vice versa.

Use the 2020 coordinate system to point to the 709 subset contained within the 2020 colorspace boundaries and use --colorprim bt2020 syntax in the metadata, or use the 709 coordinate system and use --colorprim bt709 syntax in the metadata.

Thank you sir. I'm studying your info carefully.