2021-03-08

Owned by Mark Titchener
Mar 11, 2021
6 min read

March 8th, 2021

Host: Doug Walker

Secretary: 

Attendees:

Mark Boorer (TSC) - Industrial Light & Magic
Mei Chu (TSC) - Sony Pictures Imageworks
Sean Cooper (TSC ACES TAC Rep) - ARRI
Michael Dolan (TSC Chair) - Epic Games
Patrick Hodoul (TSC) - Autodesk
John Mertic - Academy Software Foundation / Linux Foundation
Carol Payne (TSC) - Netflix
Mark Titchener (TSC) - Foundry
Carl Rand (TSC) - Weta Digital
Doug Walker (TSC Chief Architect) - Autodesk
Kevin Wheatley (TSC) - Framestore
Chris Clark - Netflix
Zach Lewis - Method
Christophe Brejon -Illumination Mac Guff
Thomas Mansencal - Weta
Remi Achard - DNEG
Alessandra Tomassi - ILM
J Schulte - ILM

Apologies:

  • Michael Dolan

OCIO TSC Working Group Meeting Notes

  • CMake export issue:

    • Mark B: There’s still a problem with CMake export, currently can’t do FindPackageOCIO.

    • There are hacks in OIIO to workaround this at the moment.

    • Don’t have a complete fix yet.

    • Touches on old problem of statically linking to libraries as we create them.

    • Tried to find a way to merge everything for all platforms but export targets a bit hard to use in CMake.

    • Doug - Do we have this as an issue on GitHub?

    • TODO Mark B to write up an issue.

  • Remove CMake option to omit some builtin transforms?:

    • Mark B: I think we should have one setup and remove as many of the options as possible.

    • Doug: Brendan Bolles ran into this problem with his Photoshop plugins because he’s not using CMake.

    • Doug: I think we’re All in agreement that this option could be removed. It was only intended as a temporary option.

    • Doug: Are there any other CMake options that we think we should remove?

    • Mark B : Use SSE?

    • Doug: We need SSE

    • Mark B: Does it have to be an option? Is this for building on ARM?

    • Doug: We added this as an option, possibly for the M1 Macs as they don’t have emulation for SSE.

    • Patrick: I think we should keep it (on by default).

    • Zach: Should we remove the option to build Nuke plugins for now?

    • Mark T: I think we should. They don’t build currently. Think there are currently problems building plugins against newer versions of Nuke.

    • Mark B: We have our own fork of the plugins and can build with newer versions of Nuke.

    • Mark B: We should have a GitHub issue for the Nuke plugins to investigate and then make a decision.

    • Mark B: I checked and fixed build options prior to OCIO v2.0

    • Zach: Remove Java option?

    • Doug: Should we perhaps create separate issues for each?

    • Patrick: We could add a basic README in bindings and vendor to list what is up to date and works and what is not? Just a few lines so we can provide a clear indication for users, currently there is nothing.

    • Zach: Good idea.

    • Zach: Will adding a README “explode” the docs build process?

    • Doug: Hopefully not. We’ll need to investigate.

  • Where does the ACES Metadata File (AMF) fit?:

    • Carol: This is something Chris Clark and I have been discussing.

    • Chris C: There are various ways an AMF could be useful, one example could be creating an OCIO config from the AMF.

    • Chris C: AMF is released but its implementation has been limited to only a few products so far. We hope this can expand out to a wider group of products/users and we thought the OCIO group might be a good place to start. We are currently working on an implementers handbook, which essentially contains all of the useful info that didn’t belong in the AMF spec.

    • Doug: We have some related support already. OCIOCLF converts a LUT into CLF and includes an option to create an ACES compliant Look Modification Transform (LMT) that may be referenced from an ACES Metadata File. https://opencolorio.readthedocs.io/en/latest/guides/using_ocio/using_ocio.html#ociomakeclf

    • Mark B: How do you see AMF working with OCIO? For my needs/studio it doesn’t seem to offer many benefits.

    • Chris C: Primarily fits into apps that are upstream in the pipeline that don’t support OCIO e.g. on set color. See Look development as a big opportunity, where AMF can be used instead of passing LUTs around.

      • Pulse system could take an AMF and create an OCIO config from it.

      • Import AMF into Nuke and auto config your viewing pipeline.

    • Carol: Bigger VFX studios have own solutions so may not see benefit of AMF in short term but smaller houses should. Not sure AMF should be a core aspect of OCIO but maybe it could be supported as auxiliary scripts? That's one of the big questions we've been discussing where does it fit? OCIO? ACES?

    • Mark B: We are creating the ACES studio config to help standardise workflows so how does AMF sit alongside this? Wouldn’t AMF create more work for smaller studios without dedicated colour people/teams i.e. importing files, checking result is correct etc

    • Carol: It would need to link with the ACES studio config. At first it would probably be kind of generic e.g. what’s the ACES version, are there shot specific looks.

    • Kevin : For us, the main problem is grading is not static. I can see it being useful for initial import and export but doesn’t help solve the problem of multiple revisions in between.

    • Zach: Does AMF have a notion of history?

    • Chris C: Yes, you can store an archived pipeline but it’s currently an optional (advanced) feature for implementers.

    • Zach: For QC it would be really useful to have an end to end processor in the file transform.

    • Doug: What’s the link between global OCIO config and shot specific AMF. Would there be one AMF to create the OCIO config or lots of AMFs?

    • Carol: I see it as two scripts. One AMF to create the global config and second that is fed a bunch of AMF’s to create CLF’s or CDL’s per shot.

    • Zach: Sounds pretty useful to me.

    • Mark B: So in the AMF you have a chain of things but how could a CLI make sense of that? Would you have to fill in the blanks after?

    • Carol: It could give you slots in your views/displays at least for standard ACES CSCs. With the order of operations laid out.

    • Mark B: What about a FileTransform that assumes reference space and does all of the AMF things in one? Is that useful?

    • Doug: You probably want to get to a working space. Need to figure out how the AMF maps to OCIO

    • Mark B: There are useful processes in VFX that might not match up to upstream AMF decisions e.g. adjust white balance in camera space.

    • Sean: Seems to me the easiest thing would be an AMF FileTransform but not sure that’s useful. I find the notion of converting AMF into an OCIO config odd. The biggest problem will be to figure out how to split it up. Automation would probably get it wrong.

    • Chris C: Good point but I think having a single file transform would still be useful.

    • Mark B: Do you know input space?

    • Carol: It’s an ACES format so we are assuming that for now. We have defined blocks that map e.g. camera to AP0. It gets kind of murky in the middle with LMTs/shot specific Looks but having the input and output defined would be useful as a first step.

    • Kevin: Going from A to B is 90% of the work i.e. figuring out what they did on set (often in an almost ACES workflow). All sorts of things can happen internally as long as you can provide the same expected output back to the client. We have at least four grading steps in our own pipeline that are not happening on set. So where do things map? I can see that smaller houses could benefit though.

    • Mark B: How are things named in the AMF? Is it defined or arbitrary?

    • Chris: Use ACES terminology e.g. Input Transom, Look Modification Transform, Output Transform. There’s currently no indication if a transform is global or shot specific. The order of operations is the order in the AMF XML. You can add arbitrary metadata though e.g. neutral_look

    • Chris: Showed an example AMF generated by Pomfort https://drive.google.com/file/d/1-G0zrMqjMO9IMRItdpU74XuBrinPbe1P/view?usp=sharing

    • Mark B: Semantic blocks are stuck inside the LMT section but a lot of VFX tasks need to be outside of that.

    • Mark B: Is CLF embedded in the AMF or just referenced?

    • Chris C: It references the external CLF file.

    • Mark B: We could create an OCIO exporter for AMF similar to Doug’s ocioclf.

    • Zach: Is there a way to indicate where a working space should be? Like a bookmark?

    • Kevin: Would be good to have this, often “VFX goes here” scribbled somewhere.

    • Chris C: In the context of AMF the working space is considered to be AP0 which is intentional. Had lots of discussion on whether arbitrary spaces should be supported but decided against it for now.

    • Chris C: Focussed on use case of trying to match QuickTime from set, glad to hear this would be useful.

    • Kevin: OCIO or AMF are tracking image states e.g. neutral grades, balance grades, avid grade. We don’t have a consistent way to define these in our industry. We all have similar workflows but subtle differences are likely. Camera RAW > on set grade could be different state to VFX, as internally we might have balanced the shots in a different way.

    • Thomas: We should have a standard practice for these things i.e. white balance, neutral grades etc

    • Mark B: Isn’t that ACES?

    • Thomas: But it doesn’t cover these.

    • Mark B: Issue is people don’t want to work in the same space e.g. grade

    • Kevin: Had cases where CDLs were applied before the output transform /and/ after on different parts of the same show. It was an accident but they liked the look!

    • Thomas: Doesn’t mean we shouldn’t try to create best practices, it can take time.

    • Kevin: Should OCIO and/or ACES solve this problem? OCIO doesn’t fix grading problem for Framestore. Would it be better to keep it separate?

    • Sean: From my point of view the coarse steps for AMF is the getting from A to B use case with a file transform that allows you to specify which parts to enable. It doesn’t solve higher workflow problems though.

    • Mark B: Are the sections well defined within the AMF format?

    • Chris C: Yes. Agree with Sean about next steps.

    • Mark B: I assume people would want to use these outside of ACES configs?

    • Chris C: Focus is on ACES workflow for now.