CDL Color Transform Effect

[reinecke]

There is a continuum of color management that can potentially be included in OTIO (see #1805). Based on discussions in that thread and #1793 we feel like we know enough to implement a CDL effect schema.

The Schema should be:

{
  "OTIO_SCHEMA": "CDLEffect.1",
  "metadata": {},
  "offset": [
    0.0,
    0.0,
    0.01
  ],
  "power": [
    0.5,
    0.5,
    0.51
  ],
  "slope": [
    1.0,
    1.0,
    1.0
  ],
  "saturation": 0.0,
  "process_space": "ACEScct"
}

This would be a subclass of the otio Effect schema.

By practice - process_space should be a name from the OCIO studio config.

[BrandonBussinger]

while this has value on its own, I would just note that CDL is typically one operation in a larger stack that may be defined piecemeal, or as part of larger description like an OCIO config (likely in a VFX context) or an ACESclip (camera originated pipeline) and may stack differently in different parts of the pipeline (other effects may be added at different points in the stack). Worth keeping this scope in mind since it may mean having links to other effects to reference a common source (the OCIO etc...).

Also curious how one might declare if a media reference represents the clip or composition with the effect applied or not. In theory one could apply color to a clip, nest that then place a media reference on the nested object but that may not be a super intuitive way to handle it (and this remains a problem in ALE based workflows etc... with things like resolution and other media specific considerations like what ODT was used)

[shidarin]

Would this replace the CDL data currently standardized in metadata, or would it be possible to be in both places, duplicated?

[camkerr]

For use cases where CDL information is read from a separate file (.cdl, .ccc or .cc for example), should file path and cccid be part of the schema?

[shidarin]

ccid is a required part of the CDL XML specification, but the ID is not present in the official specifications for ALE, CMX3600 or Flex, and I've never seen it present in any EDL. CMX3600 could technically support it because the specification allows for the CDL references in CMX3600 to be present in a sidecar XML file, which would have it.

I haven't been expecting cc id to exist in OTIO files (cdl_convert docs), but I could easily start supporting it if it started being included. It's also not included in the Foundry proposal.

[camkerr]

I can see arguments for and against. I was just curious what everyone's thoughts are.

If the host application wants to include it in the metadata of the CDLEffect, they could easily do that too.

[reinecke]

Would this replace the CDL data currently standardized in metadata, or would it be possible to be in both places, duplicated?

We'll have to give this some thought.
Some things we could do:

• On deserialization in the version this lands, use the schema upgrade mechanism to pull the value up into an effect. When serializing to an older schema version, remove the effect and place the values in the metadata.
• Offer a first-party provided post-load hook script to duplicate the data into the old metadata field
• Add some convenience functions to fetch the CDL data that will look in the various places it might live

The cleanest thing from a forward-looking perspective would be to just do the deserialization/serialization thing and say that once you're running on that library version, you may need to write files out with an older schema version for older software. Part of developers adopting the new version would be to look in the new place for the CDL values - they won't have to look in both places if it's automatically up-converted by the deserializer.

This may not be totally pragmatic though. Open to thoughts.