2023-06-12

Owned by Carol Payne
Jun 20, 2023
3 min read

June 12, 2023

Host: Carol Payne

Secretary: Carol Payne

Attendees:

Rémi Achard (TSC) - DNEG
Mark Boorer (TSC) - Industrial Light & Magic
Mei Chu (TSC) - Sony Pictures Imageworks
Sean Cooper (TSC ACES TAC Rep) - ARRI
Michael Dolan (TSC) - Epic Games
Patrick Hodoul (TSC) - Autodesk
Zach Lewis (TSC) - Method Studios
Thomas Mansencal (TSC) - WetaFX
John Mertic - Academy Software Foundation / Linux Foundation
Carol Payne (TSC Chair) - Netflix
Mark Titchener (TSC) - Foundry
Carl Rand (TSC) - Weta Digital
Doug Walker (TSC Chief Architect) - Autodesk
Kevin Wheatley (TSC) - Framestore
Jonathan Stone (MaterialX Chair) - Lucasfilm

Apologies:

  • Remi Achard

OCIO TSC Meeting Notes

  • SIGGRAPH / OSD planning

  •  

    • Virtual town hall scheduled for Weds Aug 2 @ 8am PT. Will be recorded. Let us know if you’d like to present something/participate

  • MaterialX / OCIO interop

  •  

    • For MatX, color transforms and their definitions has been a core aspect from the beginning of the library

    • Solution so far is to take the ACES 1.2 ocio config colorspaces and generate code for the shader languages

    • Would prefer to have a solution that doesn’t require staying in sync manually

    • Possibly some format that OCIO can output, which MatX can ingest and output shader graphs for such that all the GPU shader languages supported in MatX can be used without issue or direct dependency on OCIO

    • Doug:

    •  

      • The OCIO config file is central to all of this. It’s been really successful to have a compact user-defined document to exact describe what colorspaces exist is and how they are named and then how they are defined (what exactly are the transforms)

      • Ideal world: one which an OCIO config could always be used in conjunction with a MaterialX document

      • What are the roadblockers to this? Would like to understand this first

      • Second, what is this set of colorspaces? How are they prioritized and tracked currently?

      • As long as there are different groups (especially in OS for VFX/Anim and in the ASWF) there will be mismatches

    • Jonathan: we want to stop maintaining colorspaces in MatX. For sure.

    • MatX doesn’t just support DCCs - it supports lightweight libraries just as three.js and Apple’s new VisionOS. Big selling point is that it is incredibly lightweight and therefore dependencies on OCIO is a non-starter

    • Kevin: our company doesn’t have a single OCIO config that is completely standard. Concern is two different modes of operating: pre-canned minimalistic config that is static and default, and custom support for any OCIO config out there

    • Jonathan:

    •  

      • Definitely they are separate. Start with the static set of common, and go from there.

    • Carol: so if a user doesn’t have access to OCIO, they are “stuck” with the set of colorspaces as defined in the version of MatX that they are using.

    • Doug: is there an API on the materialX side that can do this?

    • Jonathan: there would need to be a new API needed to convert the format from OCIO to MatX Graphs

    • Kevin: so we’re really talking about a small bridging library that depends on both OCIO and MatX

    • Carol: what are the explicit reasons MatX can’t depend on OCIO?

    • Jonathan: OCIO doesn’t support all the shading languages that MatX does currently. 

    • Jonathan: also, versions come into play - and OS integrations, etc

    • Also, some DCCs use non-public shading languages (such as Houdini)

    • Kevin: we’d need to figure out what MatX can/should support vs. what OCIO supports, and how to make sure the user can get what they need.

    • Jonathan: we can only support what shading languages universally support

    •  

      • So, no lookup tables (maybe in the future)

    • Doug: we are also looking at OCIO in a web browser possibilities independently of MatX - been speaking on that for awhile. And a thing we will likely do regardless

    • Jonathan: if OCIO was a javascript library, that would definitely change the calculus. It would need to be well integrated and supported, but it would definitely be more of an option. 

    • Carol: we want to be the best partner to the other projects in the ecosystem and prioritize our roadmap to suit those needs. 

  • PR 1762, ok to merge?

  •  

    • Disallow 1D Textures

    • Not merged yet because it will be a 2.3 feature, had been focusing on getting one more 2.2.x release out

    • Doug wants Patrick’s input on the changes to the GPU API, but will definitely be out for 2.3 

    • Will follow up with Eric Renaud-Houde separately