2021-03-30

Owned by Michael Dolan
Apr 05, 2021
4 min read

March 30, 2021

Host: Michael Dolan

Attendees: 

Michael Dolan (TSC Chair) - Epic Games
Carol Payne (TSC) - Netflix
Doug Walker (TSC Chief Architect) - Autodesk
Christophe Brejon
Zach Lewis - Method
Kevin Wheatley (TSC) - Framestore
Thomas Mansencal - Weta Digital
Stela Espindola
Alex Forsythe - A.M.P.A.S.

OCIO Configs Working Group Meeting Notes

  • Reference config ready to merge?

    • Zach: Tried it out in Nuke 13 OCIO v2 alpha. Some observations:

      • Some roles Nuke expects are missing in the config.

      • Display color spaces don't have a family, so are not as organized.

      • ACES family and CSC families are both present. Should move the CSC spaces to the respective families.

      • Awesome overall.

    • Michael: Any objection to merging the current PR? Additional changes can be made in follow up PRs.

    • Group agrees to merge and follow up with needed changes.

    • Thomas: Let's do alpha release, helpful for official discussions.

    • Zach: Also put creation date in description.

    • Thomas: In config can add description with date and git commit hash.

    • Doug: Also name attribute at config level could be set.

    • Zach: Can tackle adding those and getting release ready.

    • Zach: Should we consider adding linear Rec. 709?

    • Thomas: Need to resist temptation to make it production friendly. Intended as aces-dev reference.

    • Doug: Think the "reference" config name could be confusing. Easy to think it is a successor to current ACES config. It's a strict aces-dev implementation. Not intended for uses other than color scientist testing. Should we choose a more technical name?

    • Carol: When we get to documentation that will be a big part of it. What this is and what it's intended for.

    • Doug: Could have a note in the config description too to clarify.

    • Kevin: Something to make sure you only use it if you know what you're doing. Minimal implementation, etc.

    • Michael: Can put something in GH readme for now too.

  • Dev approach for building studio config on top of reference config:

    • Michael: What direction should we take? Import existing code into new module? Or add a new function?

    • Thomas: In python package there is a reference module, and planned to make studio one beside it. Current generator outputs config structure as dictionary. We can hook into that and add to it.

    • Zach: Yes, think that makes sense. Use dictionary instead of OCIO objects.

    • Carol: Think that makes sense too. Gives people idea of how to make modifications and reference it. More examples.

    • Michael: A studio can then likewise extend studio config in same way.

  • Christophe: Which config to ship with product. reference or studio?

    • Carol: Studio probably, but depends on application. Could do both as well.

    • Doug: If it's a render engine, may be able to do a simpler config than even the reference config. Possibility for third config at some point.

      • Thomas: VES delivery guidelines references ACES config color space. Spaces become normative. Something to think about. If you provide config missing some of this stuff, it could be problem.

      • Alex: This is what we were talking about when rolling some of these spaces into ACES itself. Don't want people to feel like they can't use other conversions.

      • Zach: Wonder if we should have normative ACES names, specified by ACES.

      • Alex: That's the goal of the transform IDs.

    • Christophe: Can I use current reference config for implementation?

    • Kevin: Good as implementation aid, but not as a config to use in production.

    • Doug: There's also a demo config in OCIO documentation.

  • Inclusion of camera vendor spaces policy

    • Need some legal advice on this from LF, but proposed direction is to write up list of camera IDTs that could be included in studio config, and for those without public papers on their color science, reach out to manufacturer for an implementation or permission. Implementations in ACES repo should be ok to use with ACES license. Asking manufacturers can also help advocate for inclusion of more cameras in ACES. Some cameras have many different variations of color science initially, which are later consolidated. These cases are more difficult to share and support since there are many variations. Images can be analyzed to fit curves for unofficial support, but we will prefer on-the-record requests first. We can then make it explicit why something is missing.

  • ACES 1.3 and existing config license status:

    • Alex: 1.3 RC in April. Release in May?

    • Alex: Is a PR needed to set the license for the current ACES OCIO configs?

    • Michael: Yes. We have been assuming it falls under the ACES license since it was commissioned by AMPAS, but needs a PR to set the license to confirm that. We could then merge the 1.1 and 1.2 configs from the colour-science fork back to the main repo.

    • Thomas: Would be good to solve it. Could then archive those configs in GH. Not sure about updating the OCIO v1 configs for ACES 1.3.

    • Carol: Need to talk in gamut mapping implementation group. Would need to be a special shaper and LUT for backward compatibility.

    • Michael: Can use ACES 1.3 to push towards new config in OCIO v2.

  • LMT example approach:

    • Following more discussion, group agrees to not include LMT drop-in in studio config. Config setup is only a portion of the setup work needed to use the workflow in a studio, and there are multiple approaches. Instead we will document the recommended way(s) to implement LMTs as looks, with examples. Studios can use documentation to extend the config to add looks. Would be great to support this in the future, but it can be a stretch goal to pursue later.