2023-11-07

November 7, 2023

Host: Carol Payne

Secretary: Carol Payne

Attendees: 

Carol (TSC Chair)
Doug Walker (TSC Chief Architect) - Autodesk
Remi Achard (TSC) - DNEG
Kevin Wheatley (TSC) - Framestore

Apologies:

  • Thomas Mansencal

OCIO Config Working Group Meeting Notes

  • New Meeting time

    • Carol will create a poll to make sure we get a slot for December with all relevant attendees

    • Hoping for Mondays at 11am PST.

  • CanonLog2

    • Had an email chain with Canon about adding CanonLog2, we should reply to the chain and let them know. Doug will take care of it.

  • Github Projects

    • Carol showed a POC for a project board for the configs repo, mostly to demonstrate possibilities for the main repo

    • Kevin: have to decide what the focus of the board is -  is it for a team, for a project, etc

    • Fewest number of statuses possible

    • overall good start, keep going in this direction after TSC discussion around the wider project

  • AMF Support

    • Right now, OCIO has a prototype "pyocioamf" - takes an amf file and converts to ctf, and whatever has not been applied is what gets put into the ctf 

    • We need to decide actually what needs to go into the c++ api - and it likely isn't actually what is in the prototype

    • It likely needs to convert and AMF into a Config instead

    • Doug showed a proposed config file that would get generated

      • AMF can be flexible - ex: IDT can be an ACES ID, can point to a LUT, etc

        • if it's an ACES ID, should map to the builtin that it is already in OCIO

        • if it points to an external LUT, a new colorspace would need created

          • what to call that colorspace?

          • Would probably have to be generic, as there isn't really metadata we could rely on. So something like input_colorspace_AMFID

        • Output would be similar to input

        • Looks are more complicated

          • Should each thing have its own look?

          • or should it be one look for everything that isn't yet applied?

          • Carol: should probably be at least two looks by default - one pre workingLocation and another for after the workingLocation

          • Kevin: that might not even work for all scenarios - might need more flexibility even per cdl/sequence/etc

          • Remi: likely every item in the AMF should be in the config as a look - whether or not its already been applied

          • Doug - yes, complicated per look per view per display, but also how to merge, and account for per-shot etc cdls and how those get named and created

          • We haven't before dictated per-shot workflows, but we will start to need to

          • Kevin notes that we will have in short order big scalability problems with uncontrollable amounts of looks in a config which is untenable

        • Remi:

          • input colorspace

          • colorspace to indicate what has been applied

          • can then combine that with the full view/display

          • each look should be represented individually

          • and then concatenated into a single view transform that applies everything after the workingLocation

      • API should return a Config, a tag of clip and transforms applied up to the working space, and what output transform was used in the AMF

      • Support bare minimum for this MVP, with knowledge that we will need more down the road and not every workflow will be supported with this version