Schema support for color transformations

[jminor]

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!)

[quelsolaar]

Aren't all effect information housed in meta data in the effect schema at the moment?

[ssteinbach]

Correct, @jminor is proposing we promote the CDL one into its own effect class as a way to feel out how that process would work for effects.

[jminor]

Yes, and further, we want to separate the parameters to each Effect from the generic metadata, so it is clear which properties OTIO understands (the parameters) versus the metadata which is just carried around blindly.

[vvzen]

Hi! Is there any work done on this? I think it could be a very nice addition since it would provide a more meaningful container than just metadata and would help shape color workflows : maybe one could subclass the Effect class to handle color related logic (finding color files, symlinking, etc..) more easily than how you would do with just the metadata dictionary.

Thanks!

PS: I could jump on this myself : )

[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.

[vvzen]

Have you moved completely to C++ for opentimelineio, and if so, should I make an initial proposal in C++? I remember looking at the Siggraph BoF and seeing that you were leaving only the adapters code in python, or something like that. :)

Just to start a little bit of discussion around this addition, I was imagining something like this (in Python):

class CDL(opentimelineio.schema.effect.Effect):

    effect_name = 'ColorTransformation'
    name = 'CDL'

    # The metadata could be further customised by each studio adopting OTIO.
    # It could keep track of the version,
    # source client/vendor that provided it,
    # in which date was received and other studio specific variables
    metadata = {}

    def __init__(self):
        self._slope = None
        self._offset = None
        self._power = None
        self._saturation = None

    @property
    def slope(self):
                #TODO
        pass

    @property
    def offset(self):
        #TODO
        pass

    @property
    def power(self):
        #TODO
        pass

    @property
    def saturation(self):
        #TODO
        pass

    @property
    def checksum():
        # A checksum of all the values
        # Could be very useful when checking new versions,
        # finding mismatches, checking on how many shots the same cdl is used, etc..
        pass

    @slope.setter
    def slope(self, value):
                #TODO
        pass

    @offset.setter
    def offset(self, value):
        #TODO
        pass

    @power.setter
    def power(self, value):
        #TODO
        pass

    @saturation.setter
    def saturation(self, value):
        #TODO
        pass

Thanks!

Valerio

[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.