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
- AMF can be flexible - ex: IDT can be an ACES ID, can point to a LUT, etc
Overview
Content Tools