Embeddable colorspace metadata for media exports.

[codycuellar]

One big gap in OCIO that is not easily solvable without external tooling and secondary processes (prone to error) is a way for config authors to specify embeddable metadata that describes a colorspace, most importantly display colorspaces, for output media destined for non-OCIO apps and workflows.

For example, when exporting a still image from a Nuke write node I can chose to use a display/view transform. The config author should be able to provide an ICC profile that describes that display characteristics, and if OCIO provided an API, Nuke could ask OCIO for the ICC profile associated with the user selected display colorspace.

While the list of possible metadata types might be long and difficult to implement in all cases, ICC, and perhaps CICP seems like a good place to start and should be relatively easy to implement. I propose something along the lines of this:

 - !<ColorSpace>
    name: Rec.2100-PQ - Display
    aliases: [rec2100_pq_display]
    family: Display
    equalitygroup: ""
    bitdepth: 32f
    description: Convert CIE XYZ (D65 white) to Rec.2100-PQ
    isdata: false
    categories: [file-io]
    encoding: hdr-video
    allocation: uniform
    embeddableColorMetadata:
      icc: Rec.2100-PQ.icc
      cicp:
        transferFunction: 16
        colorPrimaries: 9
        matrixCoefficients: 14
    from_display_reference: !<BuiltinTransform> {style: DISPLAY - CIE-XYZ-D65_to_REC.2100-PQ}

The config author would then put the icc profiles in the search path, just like any LUT reference, and OCIO would provide APIs to extract the desired metadata type from a colorspace depending on the file type it's trying to write out.

struct CICPMetadata {
  uint8 transferFunction;
  uint8 colorPrimaries;
  uint8 matrixCoefficients;
}

// fully resolved path to ICC for app to read/embed for ICC compatible file types.
const char* Colorspace::getColorMetadataICC(); 

// the standardized CICP tag data for CICP compatible file types.
CICPMetadata Colorspace::getColorMetadataCICP();

With an API like this - applications can rely on config authors to provide the correct metadata for file types destined for non-OCIO applications and workflows. Without something like this, an application is forced to either:

• Not embed any metadata at all
• Provide an arbitrary list of possible metadata for the user to associate with their chosen colorspace
• Jump through hoops trying to guess the appropriate metadata

My initial thoughts are to just create data representations of various metadata types OCIO would want to support, and leave it up to the app to properly embed it in the file it's writing.

[nick-shaw]

Not just for rendered files. If an app supports SDI/HDMI output then metadata in OCIO would allow it to use the appropriate Y'CbCr matrix and set the VPID.

[doug-walker]

Thanks for posting this Cody. As Nick wrote, this could additionally be used for video output. And furthermore, it could be used when importing media to know which OCIO color space it is in based on knowledge of one of these external metadata items.

In addition to ICC and CICP, there are a couple of similar use-cases that have been discussed recently. Kevin Wheatley mentioned adding ST2086 support. And similarly, Mark Boorer and myself have both been wanting to add the corresponding macOS and Windows color space identifiers that correspond to an OCIO color space. (The latter is especially relevant since macOS and Windows, understandably, seem to not be using ICC for HDR/EDR display color management.) Finally, we have an initiative to within the ASWF Color Interop Forum to define standard color space names for use in tagging media files, so there is some overlap with that as well.

Regarding ICC support, I understand from the Slack thread that you're primarily thinking that the ICC profile would be included somewhere on the search_path. However, given that the trend is to have stand-alone configs without a LUTs directory, it would be nice to be able to leverage profiles already installed on the system in standard locations. Perhaps if looking on the search_path fails, OCIO could look in a few predefined locations on each platform?

Regarding CICP support, as was discussed on Slack, there is an unfortunate amount of variation in how different products interpret this information (e.g., what does "1-1-1" actually mean?). I'm wondering if, rather than simply specify CICP enums, we should instead specify equivalent information that is defined in an unambiguous way? That way, the application could translate this to or from CICP using the interpretation they prefer. For example, if we have a way to say "this is Rec.1886/Rec.709 video", then the application could either write "1-1-1" or "1-2-1" with a gama atom, as they see fit.

[doug-walker]

One of the interesting comments from the discussion at the OCIO TSC today was about adding a unique ID to the ICC information. The ICC profile format has an MD5 hash in the header which is calculated based on the contents of the profile. This might be nice to include and could potentially unblock the ability for OCIO to look other places beyond the search_path, since there would be no concern over possibly loading the wrong one.

[KevinJW]

Types of metadata we have used to embed into output files:

• CICP/H.273 style triples for transfer curve, primaries and decoding matrix
• Explicit gamma values for GAMA Atom
• Narrow vs Full range
• Mastering Display Colour Volume (ST2086)
• Content Light Level (CTA-861.3)

Probably worth mentioning we are only talking about static metadata as we have no current way to deal with dynamic ones.

As I mentioned in the call, I think we need to decide on how involved the library should be, I think it makes sense to support something, so for myself the thought process would be to have a minimal extension to the core library to support adding metadata to the display referred colour spaces, basically to allow for it to exist and pass validation but without full parsing. then to add an extension library/helpers which don't fall under the core library versioning requirements which could define the metadata in a to be determined way.

I don't think we should leave it up to each application to determine the schema, so support the goal of config authors being able to decide, but it should be optional.