Foundry CDL Effect Proposal

[reinecke]

At the August 14th, 2024 TSC Meeting, the team from Foundry presented their schema enhancement proposal for CDL effects (slides).

The Proposed JSON version of the effect schema would look like this:

{
  "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,
  "working_space": "scene_linear"
}

Related issues: #858 #857 #688 #1050

Let's have a discussion here to iterate and find a consensus schema!

[reinecke]

For reference, the CMX 3600 and ALE adapters put the following dictionary under the cdl key in the metadata dict for Clip objects:

{
  "asc_sop": {
    "slope": [
      1.1549,
      1.1469,
      1.1422
    ],
    "offset": [
      -0.0678,
      -0.0555,
      -0.0323
    ],
    "power": [
      1.1325,
      1.1351,
      1.1221
    ]
  },
  "asc_sat": 1.2988
}

Dropping the asc_ prefix from the key names and flattening the slope, offset, and power arrays seems totally reasonable. Also the addition of working space will be a welcome one. I think this modeling makes sense overall, we just need to define the semantics for:

• When a working space isn't present (like when converting from ALE or EDL)
• What string should be used in working_space

I've put some feelers out to folks in the OpenColorIO and ACES communities to see if there is guidance we can use on a canonical list of colorspace identifiers.

[KevinJW]

There is no full canonical list of spaces that could be the colour space to apply the effect in, the subset that the colour interop forum have so far worked upon are likely not the ones you need within VFX productions for instance - this is because that list purposefully does not include camera encodings, which are historically the ones grading information would originate in from on set.

Also worth noting any list so produced would not be "complete" in the sense that productions, studios, etc can all have workflows that specify non-standard spaces, so the best we are hoping for when using the interop names is to agree on the spelling of specific well standardised colour spaces, avoiding sRGB, SRGB, srgb, etc.

[camkerr]

Does order of colour operations need to be specified or will it be inferred by the order of the effects? In the future when there are (hopefully) more colour effects (File Transforms for Show LUTs or Input LUTs for example) we want to make sure the order of operations is correct.

[reinecke]

From the Application Integrator's guide, Effects should be applied in the order they are stored on the clip:

The effects list allows stacking of multiple effects on a clip where the media is transformed in order of the effects list. For instance, a video clip could have a 100% desaturation applied as the first effect in the list and a tint with a brown hue as the second effect to add color back and achieve a "sepia" effect.

I think that should make sure the order of operations are explicit, right?

[camkerr]

Yep, agreed.

[kenmcgaugh]

Regarding the “working_space” and coming from a VFX/OCIO perspective, I would want to use “color_timing”, or whatever colourspace the “color_timing” role resolves to. I’m not suggesting this be the default instead of “scene_linear”, but rather as an argument that perhaps this value should have no default and the implementation could reason an appropriate value from the environment in this situation.

[reinecke]

In an OpenColorIO based workflow, this makes a lot of sense - your OCIO config would define how to apply actual color transformations for a given named colorspace. I think my biggest concern about these is if you author an edit, export it, then send it on to a finishing house, how does their software know explicitly how to resolve out that name.

[KevinJW]

In our workflows it is quite common for the stack/list of the colour edits (CDL/grade change/etc) to each have their own colour space in which they should be applied. This maps out to our different pipeline steps each having a slightly different image state. The image state being something like "neutrally balanced" or "client graded" which the colour edit is part of that transformation into that state so our CDLS might model that transformation and in some cases they are actually the inverse transformation to move out of that state.

[reinecke]

@KevinJW and @kenmcgaugh - mind taking a look at #1805 to see how this addresses some of these finer points?

[reinecke]

The biggest sticking point on this proposal is the colorspace naming. After a bit of a deep dive, there doesn't seem to be a canonical list of colorspace names. The best I can find is the OpenColorIO-Config-ACES studio config. These seem to be derived from the ACES transform collection transforms.

My current feeling on this: We suggest where possible that the colorspace names line up with names from the OpenColorIO ACES studio config which will stay highly-aligned with both OpenColorIO and ACES, but give some wiggle room. I'm not sure if we can provide a recommendation for applications about what to do when a named colorspace isn't recognized by their app, resolving that may be specific to their application domain.

[KevinJW]

@doug-walker @carolalynn This is where the colour interop forum might be able to help.

[doug-walker]

Indeed, thanks Kevin. At various CIF meetings we mentioned wanting to expand the list to a wider set of color spaces. Perhaps this could be a goal for next year. In the meantime, I have a few comments:

• I agree with Ken that if the working_space is empty or missing, the default behavior should be no color space conversion (just apply the CDL transform). It should not have a fixed default such as "scene_linear", though as Ken wrote, an application might allow users to use a custom default for a specific timeline.
• There are two commonly used implementations of CDL that either clamp (per the ASC) or do not clamp (as is common in VFX). The Common LUT Format representation of CDLs has a "style" attribute to specify this aspect of the processing. The spec for that is here.
• OCIO uses the term "process_space", which might be somewhat more descriptive than "working_space"? In any case, if you want to align with OCIO, that would be the name to use.
• As was mentioned in the presentation, the color space name on its own may be ambiguous and it usually needs to be paired with a config (or similar) to serve as a namespace to interpret it within. Whether that should best go in the effect schema or at a higher level (for the track or timeline) is hard to say. However, if a timeline is built up from a lot of shots, it would not be unheard of to have various CDLs referencing more than one config. OCIO configs have a "name" attribute that is intended to be used for this purpose. This might be interesting as an optional schema element.
• In order for a color management system to convert to the process/working space, it will also need to know the color space of the clip itself. Is there a standard way to have clips in different color spaces, or is the assumption that the whole timeline is in one color space?

[reinecke]

Great feedback @doug-walker - I think a bunch of this may now be addressed in #1805.