2021-07-20

July 20, 2021

Host: Michael Dolan

Attendees: 

OCIO Config Working Group Meeting Notes

• CG config generator overview:

  • Carol: Non-ACES color spaces will be pulling from CLFs that we'll host

  • Doug: A lot of interest on MatX in the CG config. Right now their spec says ACES config.

  • Thomas: Overview of CG config:

    • Two main directories, config and CLF. At some point may be good to extract CLF into its own repo. Set of builtin CLF, currently not taking too much space, but may grow. Includes CLF transforms and code to generate them.

    • Similar work to discovery code for CTL transforms, but also generates the transform. CLF discovery code tracks and classifies transforms.

    • Naming conventions subject to change, trying to follow current ACES conventions, but can change.

    • cg module includes csv generated from spreadsheet. Has ACEStransformID for spaces generated from CTF. Additional transforms have CLFTransformID. Process follows same as for reference config. 

    • Filters to filter transform data from reference config, then cleanup work. then takes CLF transforms and adds them into the config.

  • Michael: Like adaptors and mutations on reference config.

  • Thomas: PR has example of generated config. Only thing missing is working CLF transforms (stand-in for now).

  • Michael: Others can contribute CLF content.

  • Thomas: Structure could change some in future, but good way to start. Studio config impl should be straightforward with this foundation. Everything can be serailized to JSON. Structure used to filter things. Could be done with OCIO directly, but hard to attach metadata. Could change in future.

  • Doug: OCIO allows you to access CLF metadata and create metadata.

  • Michael: Good for incrementally building studio config. Maybe could ask vendors to provide CLF.

  • Kevin: Good question to determine is how do we populate the matrices. Could use ever growing colour library, but it's a large dependency.  Any other options?

    • Thomas: Could output them from colour and keep hard-coded somewhere.

    • Kevin: How do we decide which matrix to use? Different approaches to creating them.

    • Carol: Since it's config repo, shouldn't be as much of a problem. Just generating configs, not a dependency of all of OCIO.

    • Thomas: The builtins are not generated live, so are in version control. Originally generated them on the fly, but when you do that it's harder to discover them, since they need to be generated for the user to see what's available.

    • Doug: For situations where there is builtin transform, good to use that for consistency with other configs.

    • Michael: Feed from colour or hard-code? Can include script and hard-coded result.

    • Thomas: Yes, that's how it is now. Matrices generated before config generation.

    • Kevin: sounds ideal in that sense. Decoupling the two.

    • Thomas: Will change dependencies to be optional except python

  • Michael: Could ask vendors for CLF. Include cameras that provide it or allows to create it.

    • Thomas: Currently relying on string ID. No spec for that, except what I made. Need to discuss about that. Maybe we can recycle ACES transform ID format. Need new spec. I can make a small explainer.

    • Carol: Like that a lot. Easy for people and everything is the same and easy contribution.

    • Doug: Also be good to have a whitepaper or something. Just a file with numbers may not be clear what it's going from and two.

    • Michael: Could give standard output ACES2065-1

    • Doug: CLF has input and output descriptor elements.

    • Michael: Does OCIO honor that?

    • Doug: Yes. Input and output descriptors intended for color space name. Could come up with a template of what we'd be looking for from vendor. Think a paper would be good explaining where they got the numbers and how the camera space is defined.

    • Kevin: If they are adapting from one whitepoint to another, how are they doing that, etc. 3x3 matrices are not the problem. More an issue when they give you a giant cube. Might want to discourage that.

    • Carol: Yes, having a spec that goes beyond the transform ID will be something to discuss. Are we going to accept IDTs that aren't to the ACES spec?

    • Kevin: Depends what the spec is. Usually a bunch of code, but in this case with CLF, how do you represent fancier transforms without a cube?

    • Doug: Even 1D LUT, would prefer they use CameraLogTransform. Might not be aware we have a parametric description.

    • Kevin: could suggest if they need an alternate form, to reach out and we can help.

    • TODO: Group will work on spec for CLF contribution guidelines.

    • Doug: Minimizing size of ask will increase chance of success. Unclear what the blockers are. Many vendors have provided something, but not IDTs. Probably different issues with contributing to ACES. Might need to find out how to get the information publicized in a way that works for them.

    • Michael: Can provide options

    • Carol: Good to get people familiar with CLF. A lot of wins from that.

    • Doug: Other angle is if want to be in ACES metadata file, need CLF. Will be needed for this upcoming important industry workflow.

    • Carol: Yes, hopefully be a good change to rally around these standards.

    • Doug: Can work with ACES to come at this from multiple angles.

    • Carol: If you go out of the meetings and talk to vendors personally, has worked well.

• Items for next meeting agenda:

  • Discuss vendor CLF contribution spec.