July 26, 2021
Host: Michael Dolan
Attendees:
Mark Boorer (TSC) - Industrial Light & Magic
Mei Chu (TSC) - Sony Pictures Imageworks
Sean Cooper (TSC ACES TAC Rep) - ARRI
Michael Dolan (TSC Chair) - Epic Games
Patrick Hodoul (TSC) - Autodesk
John Mertic - Academy Software Foundation / Linux Foundation
Carol Payne (TSC) - Netflix
Mark Titchener (TSC) - Foundry
Carl Rand (TSC) - Weta Digital
Doug Walker (TSC Chief Architect) - Autodesk
Kevin Wheatley (TSC) - Framestore
- Name - Organization
Apologies:
- Patrick Hodoul
- Mark Titchener
OCIO TSC Working Group Meeting Notes
- OCIO conformance program:
- John: All OSS projects are available under a license. While that license puts into place the downstream IP pieces, it doesn't consider areas where projects are aiming to drive an ecosystem. How vendors implement projects can be really inconsistent despite advertising support for a lib. Idea is to give community ability to define what it means to be in alignment with and compatible with a project. Might be APIs that need to be implemented, or specify how to interact with the project in a certain way. Helps customers identify which vendors help them achieve their goals. Vendors have to follow criterion defined by community and LF handles evaluation. Create a set of marks allowing vendors to say that they are conformant with the project and which specific versions. Can define downstream requirements for use in the ecosystem, to promote compatibility in upstream project.
- Mark: Specific things driving this consideration?
- Kevin: Helps with identifying features that an app must support for a complete implementation.
- Carol: Can also guide how to handle data, working in 32-bit float for example. Make sure implementations are handling data properly. Also UX/UI stuff. How often does this fall into UX vs programmatic side?
- John: There are different approaches. Can have series of tests to put app through. Including UX alignment. There's a lot of latitude on what you can do. Important to make sure there is clarity downstream, and be clear about how a vendor can evaluate this on their own.
- Kevin: Someone could claim to be OCIO v2 compliant, but only implement v1-style GPU rendering. Those things would be good in a compliance program. Could have acceptable threshold levels for image output and comparison.
- John: Yes, those are exactly how projects are implementing this. Some items can be optional. Doesn't stop anyone from implementing things their own way, just creates a standard.
- Kevin: If someone is implementing ACES through OCIO, we need a way to verify that too, to honor ACES.
- Mark: Software can be patched and used in many ways. Don't see a current problem needing this, but open to it. Will be up to the DCC wanting the label. Apps can continue to implement things their own way.
- Carol: Can see it as a program to help DCCs, not as a restriction from using OCIO. For those implementing OCIO for the first time, this specifies a baseline, and a recommended approach, which is helpful. Some implementations are very varying right now. Different usages may also have different implementations, but the more prevalent OCIO gets, we should have a baseline of features to implement correctly.
- Michael: How long to set something like this up?
- John: Biggest task is coming up with criterion and getting alignment around that. Need to walk through the legal side of things too, and handle things like evaluations and forms, etc. Doesn't take too long though - a couple months overall. Typically with this program, there is a program fee in place, but most projects wave it for those involved in the project. Ensures the vendor is getting a benefit from meeting standards.
- Carol: Makes sense as a next step for the project. Goes beyond supported app page on website.
- John: Other side of conformance programs is that they are run as a self-conformance program. Projects will make this available so outside parties can indicate when apps aren't following guidance.
- Carol: Self service make sense.
- Doug: How do you handle new versions?
- John: Project makes set of marks for a version, which are lasting. If a new version is released, new marks are added and vendors need to resubmit. Existing conformance is kept though.
- Doug: One of the problems with ACES v1 is that they put the bar very high (needed to implement ACES clip, etc.) and I don't think any software companies ever got the logo (although camera companies did). The other problem ACES had was they needed to have different sets of requirements for different types of products. Not sure we would have the same problems (e.g. no OCIO cameras or monitors).
- Mark: Maybe good first step is to list things like looks which need to implemented certain ways.
- Kevin: Yes, like a feature matrix. If vendors are leaning on this for ACES compliance, also need images for verifying quality, and to what level (preview, production, etc)
- John: In response to Doug, yes having too many sets of requirements for different uses can be problematic. Good to start smaller with lower complexity.
- TODO: Proposed making this the next step following UX guidelines completion.
- Review of 2.1 milestone:
- Michael: Python wheel test successful. Next steps are to create non-test PyPI account for release. This doesn't necessarily affect the 2.1 release so could be delivered after.
- Kevin: Regarding Imath 3 support, Imath 3.1 is out now with optimized half/float conversion with SSE instruction sets.
- TODO: Michael will bump dependency in PR since OCIO 2.1 and Imath 3.1 will both exist in VFX ref CY2022.
- Doug: Patrick is working on OSL support. Planning to have preliminary version of that by end of august. May need to drop it, but will leave it in milestone for now.
- Michael: Issue #1317 still needs a fix. I can work on that, adding missing Python bindings for ICC support.
- Mei: I can put in unit test for the ICC fix.
- TODO: Michael and Mei will collaborate on #1317 fix.
Overview
Content Tools