search

ISDCF / registries

Metadata registries of the ISDCF
Other
8 stars 9 forks source link

Content Modifier - Barco HDR #941

Open SteveLLamb opened 3 weeks ago

SteveLLamb commented 3 weeks ago

Recent CPL created for Barco HDR Light Steering, DCI HDR doesn't fit, as per JZ: "Yes, the difference to other HDR standards is that we are going for PQ 300nits and Rec2020... I agree HDR1 is too generic".

For this project we opted for using the CTT Code: BarcoHDR And extention:

<cpl-meta:ExtensionMetadata scope=http://www.dcimovies.com/schemas/2018/HDR-Metadata>
  <cpl-meta:Name>Image Encoding Parameters</cpl-meta:Name>
  <cpl-meta:PropertyList>
    <cpl-meta:Property>
      <cpl-meta:Name>EOTF</cpl-meta:Name>
      <cpl-meta:Value>ST 2084</cpl-meta:Value>
    </cpl-meta:Property>
    <cpl-meta:Property>
      <cpl-meta:Name>Color Processing</cpl-meta:Name>
      <cpl-meta:Value>Barco</cpl-meta:Value>
    </cpl-meta:Property>
  </cpl-meta:PropertyList>
</cpl-meta:ExtensionMetadata>

Open to other suggestions, perhaps HDR2. For discussion.

palemieux commented 3 weeks ago

The scope attribute should use a Barco-specified URI since this is presumably different than DCI HDR

radford-for-smpte commented 3 weeks ago

This is interesting, since it does use PQ and it is constrained to 300nit.

Interestingly, the other constraints it has that are specific to Barco HDR (limited APL, etc.) would not actually be relevant to an HDR1 capable system. They are however important to know for a Barco HDR system (so that it would presumably refuse to play DCPs lacking such constraints).

But related to what Pierre wrote, the Color Processing field should not be under the DCI namespace.

So in general, I think representing the content as precisely HDR1 is correct since it's a) technically indistinguishable, and b) would look 100% correct on an HDR1 system. But it should have non-DCI metadata indicating the Barco-specific constraints.