2023-11-07
November 7, 2023
Host: Carol Payne
Secretary: Carol Payne
Attendees:
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