ASWF TAC Meeting - September 22, 2021

Video Conference Link

Voting member attendance

Other Attendees

John Mertic, Linux Foundation
Andrew Grimberg, LF Release Engineering
JT Nelson, Pasadena Open Source consortium / SoCal Blender group
Scott Wilson, Rust WG
Matthew Low, DreamWorks Animation
Shannon Deoul, RazPR (PR for ASWF)
Deke Kincaid, Digital Domain
Trevor Thomson, Intel
Patrick Hodoul, Autodesk / OCIO

Apologies

Brian Cipriano, Google & OpenCue Representative
Roy C Anthony, DNEG
Sean C McDuffee, Intel Corporation
Carol Payne, Netflix / D&I WG
Rachel Rose, ILM / D&I WG

Agenda

Quick callout for the README article
- Magazine / Blog from GitHub, there’s an article on us: How open source software powers modern filmmaking Has a number of contributors from ASWF. Shannon: will be pushed out on ASWF social channels.
Project updates
- OSL: Chris. New logo has been accepted, https://github.com/mariovario/OSL_rebrand including flavors for various uses.
- OpenEXR: Cary: another stab at integrating OpenEXR 3 into OpenVDB, seems to be closer to what the project needs. Stands out as highest priority to make sure that OpenVDB doesn’t run into any issues with their upgrade path before VFX Platform deadline, so that’s moving the process forward. Issue raised by Kimbal: OpenEXR has always had a policy / mechanism of embedding the entire library in a namespace that is optionally but by default named by minor release. So for instance OpenEXR3_1 namespace. So an app can link 2 versions at once, but every release is ABI incompatible since all symbols in a new namespace. Discussion about “how to split the difference” and how to use namespaces in the context of an evolving library, while being able to release a new version without forcing all clients to recompile. On the backburner as a point of contention. Get pleading comments from various downstream distribution packagers to not be constantly changing the ABI. Chris: tools to check the ABI compliance. tools to check ABI compliance Larry: guidance from VFX Platform is that we should support 3 years back, which can be difficult to do. So it can be attractive that if there’s a problem with OpenEXR 2.4, the solution could be to upgrade to 3.1 with all the fixes without breaking anything else. Kimball has proposed a complex way to address this by preserving old APIs as we add new things so we could do substitution without breaking Maya plugins still looking for older symbols. Still compatibility walls when retiring old APIs. If executed well, could eliminate the need to support very old versions, where “upgrade to get the fixes” could be the solution. Kimball: so we would maintain ABI backwards compatibility for 3 years. We have played with ABI compliance checker before? Cary: don’t recall. Gordon: we run that checked on Maya for those reasons. What about TBB? They have a name space for forward / backward compatibility? Kimball: TBB has a C core and a lot of inline headers, similar to new core in OpenEXR. Gordon: could be a good idea to write a best practice white paper. Cary: nothing truly unique with OpenEXR in this respect, except that it is used in many applications. Kimball: time to assume the fact that OpenEXR needs to be a stable library. Good idea to write a summary / white paper. Chris: https://lvc.github.io/abi-compliance-checker/
- Rust WG: Scott: tomorrow, talking with OpenEXR project to double check what are the conditions for moving the bindings to the project, and working with ASWF PR to create an announcement for this project. Kimball: do we have ownership of the crates? Scott: yes, it’s been sorted out.
- OTIO: Josh: no major updates
- OCIO: Michael: have a WG working on next gen ACES config, in the process of trying to get the studio config in process, “color pipeline in a box”. One of the aspects is planning to work with camera vendors to provide input xforms in Common LUT Format. Will present at ACES IDT WG meeting, to collaborate with ACES on this. Having lots of camera formats in CLF format would benefit more than OCIO. At TSC meeting, discussed moving default to C++ 14, since OSL and OIIO have moved to that. Also discussing GitHub Packages to do artefact storage accessible from GitHub Actions. Would like to have pre-built binaries for common platforms. It helps when services live within the same ecosystem, but can look into Artifactory as well (GitHub Packages may be a free tier + paid options?). Larry: can change internal build mode to C++ 14, while preserving an external C++ 11 external ABI.
- Assets Repo: Eric: had TSC meeting last week. Discussed procedural issues, several potential assets in the pipeline, looking to get them cleaned up. Intel has volunteered cloud data and 3D scene, Dreamworks interested in providing data demonstrating pipelines, AWS short film “Spanner” can contribute character rig, Michael talking to ASC StEM, some concern about licensing of downstream modified versions of the material. Wave: owe the producer an email on this topic. Not clear if we’re the right fit for the level of control they want to have over the material. Eric: would like to plug what assets projects would like to have to test, please add your needs to the list: https://wiki.aswf.io/display/ARW/Wish+List . Need to build web site and landing page.
- USD WG: Cory. Had meeting last week with new chair. Presentation from Apple on proposal for HTML model element, support for ARKit. Robust discussion, detailed notes in the minutes.
- D&I: Carol / Rachel, no major updates (conflict)
- CI WG now has an official repo. VFX Platform 2022 containers are up, work continues on supporting Conan via JFrog Artifactory to store pre-built packages. Discussions on automated ChangeLog generation from PR comments (“Conventional Commits”). Impact of Travis CI credentials leaks on ASWF projects that might have once used it and still have a live Travis organization with secrets. Kimball: for 2022 containers, something that came up in OpenEXR, how do we want to maintain the build matrix of all the things we compile again (gcc vs clang vs VFX platform years). Could this matrix somehow be centralized for access by other projects?
- Review WG: Larry: there are 2 tracks, the player / review tool we’ve been discussed since the beginning. Proposal from Imageworks to make interchangeable modules that collectively make up a playback and review tool, also modules from DNEG, trying to line up people in different timezones and legal requirements. Also a track on the topic of how annotations should work for media, there’s an interesting discussion under way on that topic.
Eric: Color management is a topic coming up everywhere, discussed in OSL, MaterialX, etc, so wanted to raise a “heads up”. In OSL, observation that needs of large studios are quite different from needs of small studios, rigid and elaborated color management policies, everything is linear by the time the renderer sees it, whereas smaller studios may need more flexibility. There are valid questions about where a DCC should let you “shoot yourself in the foot” vs restricting choice. Unrelated to the Asset project, but have been hearing those conversations in different project contexts. Kimball: how to get input textures into OSL. Chris: coming from MaterialX side, they have decided to expose some flexibility in texture lookups to chose your color space, similarly USD wants to tag color parameters with color space, which can lead to a proliferation of color transforms in different places. JT: game engines and VR also starting to get into it, color issues are more important as shaders become more physically based and complex. Invited someone from Open3D game engine to discuss with OSL. Convergence between the different media production fields. Michael Min: use color workflows as an example of who manages the .ocio file, how does it get customized per shot. Michael Dolan: primary objective of WG is to create a collection of standard-ish OCIO configs that can be used by studios (not necessarily verbatim). Tools to generate configs from base configs, and providing examples of how studios can use them. Hopefully these can be useful tools. Chris: is there guidance about how color management concepts should be exposed in DCCs? If you have a texture node in your shader, should it have a color space drop down? Kimball: whenever you get a JPEG, you don’t really know what color space it’s in, even if you have a menu of choices, you don’t really know which to pick. Michael: working on developing a document in ASWF wiki will be UX guidelines around OCIO, and how to implement color management in different aspects of an application. Ongoing / in progress project, still has ways to go. Chris: have to be aware of places where UX guidance can bleed into a file format. Eric: if there’s a colorspace stored in a file and a colorspace option in the texture fetch, how do these combine? Does the texture fetch operator have both “from” and “to” color space args?
Scott: a group of people are interested in creating a Pipeline working group, so would be interesting to talk about color management in the context of a pipeline, so potentially another avenue to tackle color management. Larry: what’s the scope of “pipeline” here? Scott: main scope is to actually define what is a pipeline is, what’s an asset, what’s a shot, and from there create a reference implementation of that spec. Initial idea is to create the spec, a bare bones implementation, and then build upon that, and hopefully get to the point where a new pipeline could be adopted by a new studio. Larry: does that include versioning, publishing… Could be all encompassing? Scott: still lots of discussions about “where the interest lies”. Gordon: is that somewhere we can read up on this? Scott: all under the #pipeline channel in ASWF Slack, some documents have been set up to start a conversation. Have 1 or 2 people working on a proposal to send to the TAC.
Python 3 WG as a lifecycle review item. Kimball: we should celebrate and wrap up the Python 3 WG, we may not have quorum for that today. JT: have been talking part, worked on some deliverables, things are being done in studios. Ashley could articulate this the best. Kimball: people are starting to convert to Python 3, Weta has a couple of environments running Python 3. JT: there should be an announcement of what the WG came up with, need to publicize the work that was done. Kimball: do you feel that the group has run its course, and it’s time to “celebrate” the work that got done? JT: the group isn’t meeting regularly right now except on ad hoc basis. Kimball: Python3 WG on the ASWF web site is pointing to the CI WG. If we want to take on more working groups such as Pipeline or Virtual Production tooling, we should possibly not form more and more, but instead finish up some of the existing ones.