ASWF TAC Meeting - October 20, 2021

Video Conference Link

Voting member attendance

Other Attendees

John Mertic, Linux Foundation
Andrew Grimberg, LF Release Engineering
Shannon Deoul, RazPR
Jim Helman, MovieLabs
Carol Payne, Netflix / D&I WG
JT Nelson, Pasadena Open Source consortium / SoCal Blender group
Scott Wilson, Rust WG
Mitch Prater, Laika
Patrick Hodoul, Autodesk / OCIO
Matthew Low, DreamWorks Animation
Ashley Whetter, Python 3 WG
Erik Strauss, Netflix
Deke Kincaid, Digital Domain

Apologies

Michael Min, Netflix

Agenda

VFX Platform 2022, Nov 1st Cutoff date
- OpenEXR: Cary: all in the clear, helping OpenVDB with their work, seems to be over the hurdle now. Should be in good shape.
- OpenVDB: Ken: everything in 9 is there, except for one small thing that will be detailed. NanoVDB, OpenEXR 3, template instantiation (faster builds), a few other improvements. New TSC member, Richard Jones from DNeg, Nick now representing WETA. Had interesting meeting with a company on the East Coast doing extremely high resolution printing of human organs, heavy OpenVDB users. Probably highest resolution sparse volumes we’ve seen. Using OpenVDB bindings inside Mathematica, very impressive demonstration, they are considering contributing these bindings. Could ask they present to TAC? What is DLP 3D Printing? The Complete Digital Light Processing (DLP) 3D Printing Guide
- OCIO / Michael: ready to go for VFX Platform 2022. Looking for opinions on switching default branch from master to main to follow GitHub best practices and promote inclusiveness, have other projects done this? GitHub supports branch renaming, remapping links. Jonathan: MaterialX did this 6 months ago, it was a smooth process, just have to get over muscle memory of typing “master”. Michael: will implement soon. About to release 2.1.1 and 2.1.2, ongoing discussion about long term issue of local-specific parsing of floating point numbers, especially when reading LUTs. So for instance a comma instead of a dot for floating point numbers. Considering use of fastfloat open source library which implements support from C++17 back to C++11, looking for any opinions on this. Larry: OSL had this issue a couple of years ago, saved files read in different locales would be interpreted differently. Had to root through the code base (did OIIO as well), discovered how many things in the C/C++ standard libraries depend on locale in subtle ways. Didn’t have to look at fastfloat, most output through format library, which is locale independent. Michael: looking at fastfloat as interim solution (header only, so also faster parsing). Could switch to native support when C++17 becomes baseline. Performance impact not so crucial when just reading LUts. Will make a call at next TSC meeting. New TSC member, Remi Achard from DNeg, actively contributing for some time, now a committer on the project, can help manage PRs. Kimball: can you write up notes on master to main conversion? Had talked about doing this in OpenEXR but haven’t gotten around to it, so could use some notes. Cary: this has fallen off our radar, was waiting for official support from GitHub
- OTIO Joshua: planning to do master to main last week but got delayed, seems to be seamless from what we hear. For VFX Platform 2022, all CI building wheels on 2022 version, need to double check builds against VFX Platform versions we say we support. Taking guidance to support current + 3 previous years, but need clarification on what “current” means. Working towards a release, a few small issues remaining, it’s been over a year since the main previous release, will be good to have an official release out there. Good conversations with Blender (film) project to get sample assets, they are generating lots of revisions of their work, looking forward to having access to this data.
- OSL Chris: discussing with Animal Logic their fork of OSL from a few years ago, looking at moving back to the official release, how to merge their changes back in (which also span OCIO). How to bring those improvements back into the release. Larry: some of those are really good ideas, the fact these are getting contributed back has inspired new ideas that build on those, an example of a “triumph of open source”. Some are large performance improvements and interesting new ways to look at problems. Thanks to Animal Logic for contributing these changes back, it will be very beneficial. Chris: will also do the master to main rename, it had fallen off the radar, but will take it on with GitHub official support. GitHub Renaming Existing Branches
- MaterialX Jonathan: clear of any VFX Platform 2022 issues, need to make sure we support the required previous versions. Released MaterialX 1.38.2 with Shader Translation Graph work from last 6 works, something from Renderman, visual improvements from GGX and (something) Sheen. Subgroup from USD WG to discuss USD and MaterialX integration and alignment, first meeting last week, seems promising, a lot of interesting ideas coming out of that. Continuing to contribute with glTF Shading Model and Adobe Standard Shader model.
- Asset Repository: Eric: Defining our process, putting together a submission form, 1 or 2 paragraphs, why is this important / useful. Want to balance not burdening generous donors so we make sure we “know why we’re doing what we’re doing”.
- Rust WG: Scott: had official blog post and made announcement on Rust community channels, thank you Shannon. Got more interest in Rust WG, will see what happens at the next TSC meeting. Binding work is chugging away.
- D&I Carol: had meeting working with the Board on term limit, self identification survey for board members, deciding what’s important to track. Starting with the Board, hopefully at some point moving on to TAC and TSCs, should hear more about this in next couple of weeks. Participants in Summer Learning Program should have gotten their swag! Thank you for your participation, was a successful program, will present to the board as to the accomplishments of the program.
- Review & Playback: Erik: in a bit of a “reboot”, trying to reschedule recurring meeting in a time which is friendlier to Europe and India contributors, likely 9AM Pacific time, hoping to get something out some time this week. Both Sony & DNeg interested in contributing to an Open Source project, also the ftrack people may be interested in contributing some of the cinesync code they recently released. Working around the paperwork required for these companies to exchange their code. Second track is standardization and encoding, lead by Sam Edwards, reaching out to industry to look at standards for encoding (ffmpeg), how to exchange media, metadata and color information. Is Open Annotation the right vehicle to standardize this work? Not a ton of activity in the last month due to legal stage paperwork between companies and contributor vacations.
- CI: Andrew: GitHub Actions haven’t released custom instances yet (Ken asking about TPU support), so will be able to do GitHub Actions on GPU instances for instance. M1 builders are still coming, but don’t know when. Ken: NanoVDB will use GPUs. Michael: GPU builds don’t work from PRs due to GitHub secrets sharing, so run it once merged (GPU builds through Amazon Codebuild). Update from JF about VFX Platform 2022 containers, looking at support for GitHub Actions standard build matrix.
Python 3 working group closure
brain-storming session - bring your thinking caps!
- Have a few different topics, so will keep it mysterious
- Next Year Goals collaborative document
- How do expand our base so it’s not always the same people working on projects
- Is there a better way for the TAC to go over projects and WGs
- How do expand the base of projects, become a wider community
- Added a couple of starting points in the document
- Larry: it’s been a long time since we’ve asked if all the members are allocating their engineering contributions to projects? Do we know what the status is? In the first couple of years, we said we would be lax about it, are all the premier members fully allocating their FTEs? Kimball: not sure we have a good answer, it has come up in the governing board, if there are ideas on how to do this, it could go under project lifecycle review. Erik: think we are “doing the right thing” at Netflix, not being tracked super closely, but “sounds about right”. Larry: that’s more than sufficient, was more wondering if there are companies that haven’t found a way to contribute? We don’t need a formal accounting of it. Wave: everything we contribute has to go through a formal process, OpenEXR, OpenCIO, have “situational awareness” of contributions since we have a more formal process for code contributions, need to get legal involved. John: LFX Insights can be a tool for keeping track of this. Looking at organization commit diversity, gives you a sense of who is active and who is not. Can be a good tool to understand footprint? Larry: those numbers, they don’t seem off? John: that’s possible, there may be some git artifacts. Gordon: contributed a huge internal component to OCIO v2 that could have been attributed to a single person? There are some large sample LUT files. John: all projects are different, some people do lots of single line commits, vs one large squashed commit. So LFX Insight may not be accurate, but it’s a good starting point. Patrick: at some point we pushed lots of unit tests with LUT files to have parity between OCIO and SyncColor, so that made the number of changes not relevant. Larry: a lot of prolific contributors seem to only have a few Ks of contributions reflected in the LFX Insights numbers? Patrick: lots of PR doesn’t mean it’s a lot of work…
- Larry: sometimes it feels its still the same small group of people touching our projects, there has to be other people. Kimball: we don’t necessarily want to deal with cross industry and remain focussed on M&E, but do we need to do this to grow our user base, even if it’s different areas of M&E? Carol: there is a lot work internally we could do to set baselines to make it easier for new contributors to start, projects have done a lot of work, but it can be hard to get new developers up and running, since our projects are still very much niche. Discussion in D&I group on how to set baseline across the board expectations on documentation and how to get a new contributor up and running, we aren’t in a bad spot, but it’s still challenging to attract new contributors.
- Ashley: a lot of open source only have one or two main maintainers, difficult to find the people who will be consistently dedicated to a project. Kimball: is this driven out of excitement? Is this someone’s personal itch to scratch? Ashley: when you start a project on your own, it’s “your thing” and you want to stick with it. Sometimes after a while someone else can pick it up. It’s hard to start on something that’s already quite bit / established. Scott: when starting on a C++ project, can take quite a while to get environment set up. In Rust WG, creating a Visual Studio container system so you can get going on development as quickly as possible. Make it really easy for someone to just pick up and start developing. Have systems and documentation in place to allow this to happen. Ashley: after you start as a new developer on a project, can be hard to move on to the “intermediate” stage after you’ve worked through some “good first issues”. Scott: when handing over maintenance to a new person, how to deal with more demanding users. Larry: our projects seem to have a pretty reasonable / kind set of users? Erik: also the issue with volume and frequency of contributions, can be hard for a small group of core contributors to get overwhelmed. Ashley: IM / Slack does help a lot.
- Cary: interesting to explore why we do this. We do it because it’s fun, we need it in our day job, small step to be involved with the community. Also a sense of stewardship, don’t want a project to fail. Comes out of a sense of ownership, can be hard to cultivate. Have made several attempts to draw other people in, a lot of my contributions are administrative, things that anybody could do, but you have to want to. It’s not easy to transfer that kind of desire for stewardship to someone else. Eric: does it help to know the context / use cases, why something is done the way its done? Or are there plenty of people who understand it but feel it’s not their problem? Cary: outstanding issue is to transfer TSC meeting notes from GitHub to Confluence, it’s not an interesting task, but for the health of the project and organization, has to be done. Hard to find someone to do this. Larry: can be the other way around, where there are people working on the code and interesting puzzles, they get interested in the health of the project, so they may be motivated to do some of the more administrative stuff. It’s not the other way around, you don’t go from administrative tasks to being enthusiastic about the project.
- Scott: all ASWF projects are “boring in a good way”, foundational components that you typically don’t think about unless you need to. Most of the really interesting projects are layers built on top of projects like ASWF projects, the type of people interested in these projects have to be interested in the “full stack” of what you need to build fun / interesting projects.
- Ashley: handing off bug triaging is one thing larger projects can hand off these tasks that core contributors may not want to do, and can be a good way for newer people to get to learn the code.
- Kimball: many of us are working on things that have IP issues attached to them, should we be doing more reference implementations of important industry standards? That way we don’t have to worry about IP issues so much. Do we have a list of such standards that could use a VFX-friendly implementation? Scott: when you join a new studio, what are the things you need to build from scratch? There’s a pre-WG on pipeline tasks, figuring out what they want to send to the TSC.
- Kimball: would like to continue thinking about this as we near the end of the year, figure out how as ASWF we grow, expand and stay relevant
Current state of Next Year Goals document:

Expand our developer base (new ideas, growth)?

D&I Ambassador Program
Expand tech to appeal to other industries? Sometimes yes, sometimes no
New baselines for projects to make it easier to get going
- Python wheels
- Documentation
- How a contributor gets going
How do we make projects enticing
- Smaller projects may be more interesting
- Once someone has done a “good for a starter” issue, how do they transition to the next level
Dependencies are hard to get people set up
- Visual studio container system
Volume / frequency issue? Feature development / requests outstrips supply of developers
It’s what we do, community is a small step
- Stewardship
- Knowing the context: why it’s important / the way it is
- Need to get people contributing to code, then the ownership grows

Manage our project / WG lifecycle review?

Want to make sure projects:
- aren’t feeling left out
- ARE supported
Keep things fun
One / month for now?
Review FTE requirements?
- Are people struggling to find projects to contribute to

Expand project base?

Examine standard / reference implementation efforts?
- Standards that lack implementations currently?
New forms of media / entertainment - support / frameworks?
Review and playback may trigger a few?
What are the next layers - we have core libraries
Starting a new studio: what do you have to build