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


  • No labels