2025-04-28 TSC Meeting notes

Random things

• VFX Reference platform 2025 docker containers ready, JF created an issue

• TAC revised working groups procedure to include long term working groups - D&I and USD are now long-term. This change includes a voting seat on the TAC.

• Security audits for MaterialX, OpenEXR still ongoing, will provide another update when finished

Dev Days

• Thursday, May 15, 2025

• One day only

• Please be prepared to answer questions in slack channels & review PRs a bit more quickly than normal

External references – continued design conversation

• Deck: https://docs.google.com/presentation/d/1k1vA_DS33_fah-j_lQczs4CTJvZVbXI_W7VBEm0h7-k/edit?usp=sharing

• Number of requests to map a color space to some external piece of info - ICC, CICP, AMF, OS-level enum, etc etc

• Color Interop Forum would define the display color spaces, similar to texture asset color spaces from last year

• We would support ICC Profile name, AMF transform ID, and a “unique ID” for display color space names

• For ICC - should we allow a list of names to account for differences between OS’s?

  • Doug will follow up with Adobe on this, but group has no issue with list instead of single string in general

• For AMF transform ID

  • Moving what’s currently in the config descriptions to its own attribute

  • Description can go back to original purpose, cleaner to maintain and debug

• Unique ID

  • Using OCIO color space names (both user facing and compact) to be stable over time

  • Will mean elevating the compact name to separate it from the rest of the aliases

  • This will also be useful for the openEXR metadata project (what compact name/alias to use)

  • Not sure unique ID is the right name - open to ideas

    • Remi - standard_name?

    • Can’t use canonical, already in use in the api

    • interop_name?

    • name tag? tagging colorspace?

    • Please help us brainstorm!

  • Michael - we need to be careful of what we guarantee operationally - there is still room for error and misinterpretation - documentation needs to be solid around expectations

  • Remi - we should try to avoid introducing names/dependencies on external things - example OS level enums - into the OCIO library. Such that we need a library update when OS changes the list, etc.

    • Group agrees, at least for this initial version - limit scope, get feedback, move from there