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