/
2023-04-17

2023-04-17

Owned by Carol Payne
Apr 17, 2023
3 min read

April 17, 2023

Host: Carol Payne

Secretary: Carol Payne

Attendees:

Rémi Achard (TSC) - DNEG
Mark Boorer (TSC) - Industrial Light & Magic
Mei Chu (TSC) - Sony Pictures Imageworks
Sean Cooper (TSC ACES TAC Rep) - ARRI
Michael Dolan (TSC) - Epic Games
Patrick Hodoul (TSC) - Autodesk
John Mertic - Academy Software Foundation / Linux Foundation
Carol Payne (TSC Chair) - Netflix
Mark Titchener (TSC) - Foundry
Carl Rand (TSC) - Weta Digital
Doug Walker (TSC Chief Architect) - Autodesk
Kevin Wheatley (TSC) - Framestore
Zach Lewis - Method Studios

Apologies:

  • Remi Achard

OCIO TSC Meeting Notes

  • Find interchange color space PR:

    • Adds IdentifyBuiltinColorSpace & IdentifyInterchangeSpace, improves on PR #1710

    • Heuristics have not changed since what was released in 2.2. Uses a processor to compare RGB values, uses a threshold to determine match

    • If configs have interchange roles defined, heuristics are not used. So 2.2+ uses the roles, but a lot of 1.0 configs will need the heuristics

    • Kevin, Mark - would prefer if applications did not do anything behind the scenes - up front knowledge etc of what exactly is going on. 

      • TSC agrees - but Doug points out that applications in many instances have taken matters into their own hands to prevent abject failures, etc. We hope these added features will prevent applications from taking their own paths, etc. and move to this "recommended" workflow. 

    • Kevin: if we need a fully defined sRGB space, do we need a new role to truly define this? And if so, do we need a way to hide roles?

    • Mark: also, this isn't foolproof - the heuristics can still fail.

    • Doug - goal is to be able to handle configs that don't have interchange roles set, which can happen up to OCIO 2.2 when we made them required.

    • Please take a look at the PR and add comments and review if possible

  • CMake sub-project PR:

    • New PR from new contributor, please take a look if you have experience with CMake's FetchContent feature

    • Kevin: seems sensible if it's clean and simple to add, would not object if so

    • Ex: use fetch content of OCIO's cmake code from say, within OIIO

    • Please review if you have time!

  • Config merge feature, continued discussion:

    • Doug has added config merge examples:

    • Kevin: these examples are good, they show the mechanics, but what happens at scale? When applications pick slightly  different things? 

    • Talking about the #include statement options:

      • Complicated due to how to override, etc

      • See slides for more details

    • Doug: for use case #2 - would rather publish exactly what the application is attempting to do, and needs to add. And then you can run the merge on your own as well, see the results, add the colorspaces on your own, or accept what the applications need

    • This is an encouragement of best practices, rather than something super novel

    • There are different stakeholders & scales at play here, and we need to figure out how to make them play together. 

    • Main concern from most is the ability for applications to add things to the config at run-time without the ability to opt-out

    • Please continue to add thoughts to the slides (Doug has been updating them) or to the GH issue. We'll also discuss further in the next configs meeting, to keep the discussion going so we can hopefully move forward & get signoff at the next TSC.

Related content