2025-02-24 Color Interop Forum Notes
Date
Feb 24, 2025
Participants
Carol Payne (OCIO) - Apple
Doug Walker (OCIO) - Autodesk
Brecht Van Lommel - Blender
Chris Clark - Netflix
Eric Reinecke (OTIO) - Netflix
Peter Hillman (OpenEXR) - Weta
Scott Dyer - AMPAS
Soufiane Khiat
Stefan Luka - WDAS
Cary Phillips (OpenEXR) - ILM
Joseph Goldstone
Matthias Scharfenberg - ILM
Nick Porcino (USD, OpenEXR) - Pixar
Rémi Achard (OCIO) - DNEG
Sam Richards (ORI) - Walt Disney Imagineering
Zach Lewis (OCIO)
Jim Geduldick
Meeting Summary:
Quick Recap
The group explored the topic of color management within open EXR and its potential links with OpenColorIO, OpenUSD, and MaterialX, with a proposal for a recommendation document for reading and writing color managed OpenEXR files. The conversation ended with discussions on the challenges and potential solutions for handling color space metadata in EXR files, and the implications for non-OCIO applications and hardware players.
Detailed Summary
Doug proposed that the next deliverable for the Color Interop Forum would be a recommendation document for reading and writing color managed OpenEXR files. He suggested adding two new attributes to the OpenEXR header:
OCIOColorSpace
OCIOConfigName
The deck presented in the meeting is here:
https://docs.google.com/presentation/d/1sY55UHYi2AJF6EPYDYY-mvaJUCzZCkWisrj-a9yhg2w/edit?usp=sharing
These attributes would formalize the use of proprietary strings in EXR headers and help disambiguate color space names. Doug also discussed the importance of ensuring that editing applications do not forward stale information, and the potential for file rules to map image path names to color spaces. He mentioned the set of standard color spaces for texture assets and computer graphics usage, which would be the most used choices for EXR color interchange. Doug also discussed the use of built-in configs in the OCIO library, which provide a large set of commonly used color space names beyond the core rendering set. He emphasized the need for the proposal to be useful for both OpenColorIO users and non-users.
Doug discussed the use of OpenEXR for storing non-linear images, despite its intended purpose for scene-linear images. He proposes a recommendation to not use chromaticities in OpenEXR files for simplicity, except in the case of SMPTE ST 2065-4 specification. Doug suggests that if both chromaticities and OCIO color space are present in a file, the OCIO color space should take precedence. He notes that this proposal aims to simplify the process for software developers working with OpenEXR files.
Doug and Eric discussed the handling of color spaces in different projects. Eric raised a question about the necessity of having an OCIO config for these EXRs to be correctly interpreted in addition to the files, to which Carol responded that it depends on the version of OCIO being used. She explained that modern versions of OCIO have built-in configs, but if a custom color space not in standard configs is used, the color space name and its config would be needed for correct translation. Eric agreed with Carol's opinion that the trust in the chromaticities metadata field was broken and agreed a separate solution was probably necessary. Carol stated that their time might be better spent on a separate solution rather than trying to fix the chromaticities field.
Doug discussed the process of determining the color space of an openEXR file in an OCIO-enabled application. He outlined several steps, including checking for color space information from other sources, examining the OpenEXR metadata in the header, and using custom OpenEXR attributes. If none of these methods work, a new function called "get color space from chromaticities" would be added to OpenColorIO to build an OCIO color space from the chromaticities. Doug also mentioned the possibility of providing example Python code or a more formal process in the OCIO library to assist with this process. Eric raised a concern about potential conflicts with other color space configurations, to which Matthias responded that as a config author, he would want the authority to override such conflicts if necessary. The team agreed on the need for a sensible solution moving forward, rather than remedying every bad chromaticity in every ancient EXR file. The goal is to create a system that will work for future use, while considering backwards compatibility.
Matthias discussed the need to redefine color spaces in certain situations, such as when working with specific camera conditions or lighting types. He emphasized the importance of maintaining flexibility in their systems to allow for such adjustments. Carol agreed, stating that the proposed system should be flexible enough to accommodate these requirements and ensuring that pipeline developers can solve their problems without excessive work. Doug raised a related issue about color spaces having multiple names, emphasizing the need for a function to convert these into a generic, widely supported name for use in file headers.
Doug discussed the need to ensure application developers validate the non-forwarding of outdated metadata. He proposed adding a function to OpenColorIO to build a color space for a given config using chromaticities, which would only work if OCIO can deduce the reference space of a given config. Carol raised concerns about the lack of trust in chromaticities, suggesting a feature to ignore them even if they exist. Matthias questioned the practical use of chromaticities, as he had only seen the AP0 chromaticities in EXRs. Joseph shared that the ARRI tools use chromaticities when writing out linear AWG 3 or AWG 4. Peter suggests using these new attributes to restore trust in chromaticities, while others debate the necessity of chromaticity data if OCIO information is present. The group discusses the implications for non-OCIO applications and hardware players, and considers ways to validate or correct chromaticity data.
Next Steps
All participants to add their thoughts and feedback on the Github issue: https://github.com/AcademySoftwareFoundation/ColorInterop/issues/4
Doug and Carol to regroup and plan a follow-up discussion for the next meeting.
All participants to continue thinking about and discussing the proposed changes to OpenEXR color management in the #color-interop-forum Slack channel or Github issue.
OpenColorIO team to consider adding new utility functions for handling color space conversions for chromaticity data.
Doug to update the proposal based on feedback received during the meeting and in subsequent discussions.