Schema support for color transformations

The only color transformation support currently modeled in OTIO right now is CDL info. This is stored in a metadata dictionary. Color transformations should be modeled as otio.schema.Effect.

This might include:

• ASC CDL (Saturation and slope, offset, power)
• CUBE LUTs
• (your suggestion here!)

[reinecke]

Thanks @vvzen for keeping this discussion going.

We’ve been implementing new schema in C++ but the ideas and approach are most important to work out. A lot of times I’ll build experiments in python and then port to C++ when I feel like things are more locked down. Feel free to use whatever language you’re most comfortable with and if C++ isn’t in your comfort zone we can collaborate on porting the code once we have consensus on approach.

On to your proposal, I think it’s looking pretty good! For the effect_name it may be best to use something a bit more explicit like ASCCDLTransformation. This will differentiate from other types of color transforms and allow us to match what was authored in a given NLE. For instance, if there were a simple “Desaturate” filter in an NLE we’d most likely want to try maintain a “Desaturate” filter when the file is round-tripped rather than upconvert to a CDL filter.

I got together with our color scientist @mrd489 and looked at how we model CDL data in some of our systems. It’s pretty close to what you’re showing, in json terms we like to do something like:

{
  "slope": {
    "red": 0.0,
    "green": 0.0,
    "blue": 0.0
  },
  "offset": {
    "red": 0.0,
    "green": 0.0,
    "blue": 0.0
  },
  "power": {
    "red": 0.0,
    "green": 0.0,
    "blue": 0.0
  },
  "saturation": 0.0
}

The main point is to make the modeling as explicit as possible (avoid the position-based encoding of red, green, and blue).

One other discussion we has was around what precision we should be targeting for the float/double values. We weren’t sure what precision is considered noticeable for these values. @mrd489 referenced ST 2065 and noted matrix transforms with 10-digits precision.

It may be worth consulting with OCIO people on this as well.

Overall, I like your first stab at this a lot, just those few extra thoughts for discussion.

[jminor]

Hi @vvzen, I don’t think anyone has worked on this yet. The only recent related work was #621 which aligned the metadata CDL between some adapters. If you would like to propose an Effect subclass or schema change to support CDL better, we would be happy to discuss more. There are some CDL workflows that vary across the industry, so we should make sure there is plenty of room for people to discuss pros/cons of any proposed change. Promoting CDL from convention-based metadata to a real OTIO schema would be a great step forward.