2021-03-16

Owned by Michael Dolan
Last updated: Mar 18, 2021
4 min read

March 16, 2021

Host: Michael Dolan

Attendees: 

Mark Boorer (TSC) - Industrial Light & Magic
Michael Dolan (TSC Chair) - Epic Games
Carol Payne (TSC) - Netflix
Doug Walker (TSC Chief Architect) - Autodesk
Kevin Wheatley (TSC) - Framestore
Zach Lewis - Method
Dennis Adams - Sony
Scott Dyer - A.M.P.A.S.

OCIO Configs Working Group Meeting Notes

  • Review reference config PR:

    • Should ACES2065-1 be under CSC or ACES?

      • Group agrees that even though the CSC prefix adheres to aces-dev, it's not intuitive for users. CSC camera transforms should be included, but with the "Input - " prefix. Core ACES spaces (like ACES2065-1) should have the "ACES - " prefix. The fact that they live under CSC in aces-dev is more of an implementation detail. Ultimately it's the URNs being included in descriptions that will link back to the CTL, so names can be more flexible for improved usability. These prefixes should be used both in color space name and family.

      • As a rule going forward, group agrees that any camera focused transform will be treated as an IDT or Input space.

    • Any other adjustments needed to generator before merging #11?

    • TODO: Michael will follow up with comments in PR.

  • Studio config scope:

    • See updated spreadsheet: https://docs.google.com/spreadsheets/d/1GB0LTJhf67NYb0GSc3yluac90yIY0bW2O58SWQxHts8/edit?usp=sharing

    • After discussing which spaces could be made "optional" per studio config build arguments, the group shifted toward a new approach for limiting scope of the config:

      • Spaces currently marked "exclude" will be excluded, but spaces marked "optional" will be changed to "include". Additional review of the excluded spaces is welcome. Please comment in the sheet when modifying these for clarity.

      • Instead of relying on the config generator for limiting config scope, we will instead lean on color space categories and the OCIO supported OCIO_USER_CATEGORIES env var, which can have it's default defined in the OCIO config.

      • The config generator can support the user specifying which categories should be included (or excluded), and build that into a default OCIO_USER_CATEGORIES value in the config context section. The config contents would not change, but the exposed color spaces would. This can then be easily overridden or modified through the environment of through modifying this minimal aspect of the config.

  • New color spaces for studio config:

    • Carol: There are some new color spaces to add that aren't in the 1.2 config. Resolve gamut, BaseLight interoperability, GoPro, etc.

    • Kevin: Also DGI and Nikon log.

    • Carol: If they are in colour-science library, should they be here?

    • Kevin: Like BlackMagic spaces.

    • Carol: The studio config goes out of just ACES world. Superset.

    • Kevin: Do we need input from more than just VFX world? Unreal Engine for example?

    • Michael: Games are primarily using sRGB and linear Rec. 709, along with HDR encodings. Virtual production is more similar to VFX workflows. Should we get input from community for other spaces to add or wait?

    • Doug: If we're going to send anything to community for review, will be good to have proposed spaces to drop. 

    • TODO: Group will contribute needed spaces to the "New Color Spaces" sheet in the above spreadsheet. Once we have compiled a list, the spreadsheet can be formalized into a separate proposal to share with the wider community for feedback.

  • Considerations for the inclusion of camera spaces:

    • Mark: We have long list of cameras, etc. What is the source for our values? colour-science is handy, but it's up to that team to make those decisions. Some camera manufacturers may not want us to reverse engineer their specs.

    • Kevin: If a paper is published, can use that. If you want an equation instead of LUT, may need to do fitting.

    • Michael: We could establish a policy to leave unknown algorithms for camera manufacturers to contribute.

    • Carol: Some vendors aren't going to provide transforms. Do we remove them for this reason? Could add existing implementations for backwards compatibility.

    • Mark: Don't think some vendors will want us to throw in their numbers if incorrect.

    • Doug: Some papers are under NDA.

    • Kevin: What's the definition of publicly available?

    • Mark: Should include where we sourced the data from?

    • Kevin: Also worry about wrong implementations breaking user images.

    • Michael: Users can always implement these themselves from other configs if we exclude them.

    • Carol: Is it worth adding them?

    • Michael: We can reach out to LF's lawyer for input if needed. We could contact each vendor and explain the project, inviting contribution. If they don't participate we could leave out those transforms, allowing users to implement them if needed, from a previous ACES config or through a custom implementation.

    • TODO: Follow up on this topic with LF.

  • LMT workflow:

    • Mark: The studio config should have an LMT slot ready to drop in an LMT from a show. Avoid users hacking in looks.

    • Kevin: Multiple ways of doing that. May want to show one method.

    • Mark: Even just a file transform with no path. Good enough to let them be dropped in.

    • Doug: There is blue light fix and older ACES emulations. Is that enough of a template?

    • Carol: Could include how-to/guidelines for setting up look transform in config.

    • Mark: The problem we can't solve is inconsistency with how LMTs are applied. Can give one slot with input and output expecting ACEScct, and if you have CDL from ACES show can just drop it in.

    • Doug: So add look where process space is ACEScct?

    • Kevin: Yes, but then need to provide file transform as example. Show how blue light fix could go there, but could be whatever. Variable names as well.

    • Mark: Do we expect users to edit search path? Or should it come with search path and a LUTs directory where files can be dropped.

    • Kevin: I would create LMT directory to use in the same way.

    • Mark: Can be implemented in looks, but some users will use views instead.

    • Kevin: Or reference looks from views.

  • Items for next meeting agenda:

    • Continue discussion about inclusion of camera spaces and project responsibility.

    • Continue discussion on LMT example/drop-in implementation