2022-06-21

Owned by Carol Payne
Jun 21, 2022
2 min read

June 21, 2022

Host: Doug Walker

Secretary: Carol Payne

Attendees: 

Doug Walker (TSC Chief Architect) - Autodesk
Carol Payne (TSC Chair) - Netflix
Thomas Mansencal - WetaFX
Sean Cooper (TSC) - ARRI
Kevin Wheatley (TSC) - Framestore

Apologies:

  • Michael Dolan

OCIO Config Working Group Meeting Notes

  • Camera Vendor Updates

    • Sony - confirmed they can make the CLFs for us to contribute, Carol will be sending the python example code from the RED clf, the OCIO library's built in transforms for Sony, and how it's working currently in the configs repo. Will just be doing SLog3.sgamut3 and the .cine variation (and also the venice variant?

    • Carol will follow up with Panasonic to make sure they are moving along, too

  • Texture category/contents

    • HP will be at the next meeting

    • Thomas pointed out they use commonly a space with acescg primaries and the srgb transfer function for textures and things for Unreal. Also common in Framestore/ILM pipeline for slightly different use cases in texturing

  • ARRI CLF PR:

    • https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES/pull/54

    • Matrix precision: Sean wants to get as close as possible with ARRI's SDK for LogCv3. He will dive in and get some resolution on ACES Central.

    • ARRI LogC4 CLF will have hard-coded double precision matrix coefficients in the python code for generation. Sean will update the PR. 

    • Only IE800 for ARRI LogC3 - fine as long as we have the disclaimer. Would prefer to have the other IE's around, but understand not wanting to put them in the config. 

    • Fine with not clamping on the CLF, which is a slight deviation from the white paper. 

    • On naming: for ARRI LogC4 - that encompasses both the primaries and the log encoding curve. We don't need ArriWideGamut. It's meant to be more explicit about that than V3. But group agrees that if we drop it from LogC4, we should also drop it from LogC3. 

    • Agree we should add ARRI LogC4 as a built-in transform.

    • If we have both a CLF and a built-in transform, we should use the built-in first, CLF as a backup, clarify what is happening, and allow for updates quicker than the core OCIO library built-in transforms. 

    • Kevin: it's also a way for us to be more immediate - if a new camera comes out, we aren't waiting on an OCIO lib update and subsequent VFX platform application releases etc etc

    • Sean: is there a tie-in to the ACES IDT work - should these CLFs live there? Group says eventually yes, but for right now it's a little more divide and conquer attitude with hopes for reunion in the future 

  • Prefix/Suffix colorspace naming conventions:

    • https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES/issues/57

    • On the camera vendor prefix - should be in the family name, but is it clear in contexts where you don't have access to the family name? Should we keep it?

    • What about apps that don't have hierarchical menus?

    • Carol: my opinion is to only have what we need in the colorspace names, and see how it goes

    • Sean: opinion is to leave it as is, as there's not a ton of benefit other than visual clutter to remove it