July 10, 2023
Host: Doug Walker
Secretary: Doug Walker
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
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
Apologies:
- Carol Payne
- Mei Chu
OCIO TSC Meeting Notes
- Python Wheel PR:
- Great progress by Remi and Jean-Christophe on PR #1802. Now that the command-line apps are included, moving from static to dynamic linking to reduce size.
- The group discussed issue #1785 (related to our fix to work around the issue caused by the change to the Python library path on Windows). We all agree improvements are needed and that it should be separate from PR #1802, but more investigation is needed on the best approach.
- Great progress by Remi and Jean-Christophe on PR #1802. Now that the command-line apps are included, moving from static to dynamic linking to reduce size.
- Config change detection:
- Doug: There has been discussion in previous meetings about the desire to detect undesired changes in configs. E.g., if someone has modified the official config for a production to modify an existing color space or add a new color space. This could be considered an "anti-tampering" feature but it could also be used just to audit/monitor/QC configs.
- Doug: I envision the way this could work is there would be a checksum added to the YAML that would be calculated based on the contents of the rest of the config. This could then be verified when the config is loaded. An application could then take some action, either giving a warning, or even going so far as to refuse to proceed.
- Kevin: When I brought this up in an earlier meeting I was thinking of it more in terms of diagnostic tools rather than anti-tampering. The checksum should be able to detect changes that would impact the images but ignore changes to description text, whitespace, variations in equivalent YAML syntax, etc.
- Mark / Kevin: Doing a diff between a pair of configs is a related use-case.
- The group discussed the challenges of comparing transforms. For example, there could be alternate ways of representing equivalent transforms (built-in transform vs. the same thing represented as component transforms). And of course floating-point comparisons are always problematic. An exact comparison would be easiest but perhaps not that robust. Alternatively, allowing a comparison with a tolerance doesn't lend itself to a checksum based approach.
- Kevin: I just wrote a Python script to simplify comparing the various optimization flags. It may be possible to prototype something in Python using the existing cacheID strings that are available from many of the classes.
- There is already an issue in GitHub to discuss this topic, Issue #1666.
- Doug: There has been discussion in previous meetings about the desire to detect undesired changes in configs. E.g., if someone has modified the official config for a production to modify an existing color space or add a new color space. This could be considered an "anti-tampering" feature but it could also be used just to audit/monitor/QC configs.
- Choice of Display P3 sRGB transfer function for updated ACES configs:
- Doug: There has been some discussion on ACES Central recently about whether Apple's Display P3 uses the piecewise curve for its sRGB transfer function or a pure power function. Dhruv Govil's Display P3 implementation for MaterialX uses the piecewise curve but Remi and Nick Shaw have measured the pure power function on Apple hardware (at least in some scenarios).
- Doug: ACES transforms have always used the piecewise curve for sRGB. And some of Apple's published test material for the traditional sRGB color space uses the piecewise curve, so it would be nice for consistency if they use it for Display P3's usage of sRGB too.
- Doug: I want to raise it to the group for visibility that I've reached out to Apple but our current plan is to use the piecewise curve in the Display P3 color spaces that we are adding to the ACES configs (both as a texture and as a display) for the upcoming release.
- Kevin / Mark / Mark: Sounds correct, we also use the piecewise curve for sRGB color spaces.
- Doug: There has been some discussion on ACES Central recently about whether Apple's Display P3 uses the piecewise curve for its sRGB transfer function or a pure power function. Dhruv Govil's Display P3 implementation for MaterialX uses the piecewise curve but Remi and Nick Shaw have measured the pure power function on Apple hardware (at least in some scenarios).
- SIGGRAPH plans:
- At the next TSC meeting we need to finalize our presentation for the virtual town-hall to be recorded for YouTube the week before SIGGRAPH. Please let us know if you would like to present something.
- Carol and Doug will try to organize a get together for OCIO people to connect while in LA. If you have a suggestion for which evening, please let us know. (ASWF Beers of a Feather is Sunday evening.)
Overview
Content Tools