---
parent: Meetings
title: "2024-06-12"
---

# Academy Software Foundation - Technical Advisory Council (TAC) Meeting - June 12, 2024

Join the meeting at [https://zoom-lfx.platform.linuxfoundation.org/meeting/97880950229?password=81d2940e-c055-43b9-9b5a-6cd7d7090feb](https://zoom-lfx.platform.linuxfoundation.org/meeting/97880950229?password=81d2940e-c055-43b9-9b5a-6cd7d7090feb)

## Voting Representative Attendees

### Premier Member Representatives

- [ ] Brian Cipriano - Google LLC
- [ ] Cory Omand - The Walt Disney Studios
- [x] Eric Enderton - NVIDIA Corporation
- [x] Eric Reinecke - Netflix, Inc.
- [ ] Erik Niemeyer - Intel Corporation
- [ ] Gordon Bradley - Autodesk
- [ ] Greg Denton - Microsoft Corporation
- [ ] Guido Quaroni - Adobe Inc.
- [x] Jean-Michel Dignard - Epic Games, Inc
- [x] Kimball Thurston - Wētā FX Limited
- [x] Larry Gritz - Sony Pictures Imageworks
- [x] Matthew Low - DreamWorks Animation
- [x] Michael B Johnson - Apple Inc.
- [ ] Milind Damle - Advanced Micro Devices (AMD)
- [ ] Ross Dickson - Amazon Web Services, Inc.
- [ ] Scott Dyer - Academy of Motion Picture Arts and Sciences

### Project Representatives

- [ ] Carol Payne - OpenColorIO Representative
- [x] Cary Phillips - OpenEXR Representative
- [ ] Chris Kulla - Open Shading Language (OSL) Representative
- [x] Diego Tavares Da Silva - OpenCue Representative
- [x] Jonathan Stone - MaterialX Representative
- [ ] Ken Museth - OpenVDB Representative

### Industry Representatives

- [x] Jean-Francois Panisset - Visual Effects Society

## Non-Voting Attendees

### Non-Voting Project and Working Group Representatives

- [ ] Alexander Forsythe - RAW to ACES Utility Representative
- [ ] Alexander Schwank - USD Working Group Representative
- [x] Daniel Greenstein - OpenImageIO Representative
- [x] Erik Strauss - Open Review Initiative Representative
- [x] Gary Oberbrunner - OpenFX Representative
- [x] Jean-Christophe Morin - Rez Representative
- [x] Nick Porcino - USD Working Group Representative
- [ ] Rachel Rose - D&I Working Group Representative
- [x] Scott Wilson - Working Group for Rust Bindings Representative
- [x] Stephen Mackenzie - Rez Representative

### LF Staff

- [x] David Morin - Academy Software Foundation
- [ ] Emily Olin - Academy Software Foundation
- [x] John Mertic - The Linux Foundation
- [x] Yarille Ortiz - The Linux Foundation

### Other Attendees

- Tyler Furby - Wabi Foundation / Language Interop WG
- Timothy Porter - Mod Tech Labs
- Spencer Stephens - MovieLabs / ZeoTrust WG
- Lee Kerley - Apple
- Doug Walker - Autodesk / OCIO
- Bill Ballew - Dreamworks
- Robin Rowe - CinePaint

## Antitrust Policy Notice

Linux Foundation meetings involve participation by industry competitors, and it
is the intention of the Linux Foundation to conduct all of its activities in
accordance with applicable antitrust and competition laws. It is therefore
extremely important that attendees adhere to meeting agendas, and be aware of,
and not participate in, any activities that are prohibited under applicable US
state, federal or foreign antitrust and competition laws.

Examples of types of actions that are prohibited at Linux Foundation meetings
and in connection with Linux Foundation activities are described in the Linux
Foundation Antitrust Policy available at
[linuxfoundation.org/antitrust-policy](https://www.linuxfoundation.org/antitrust-policy).
If you have questions about these matters, please contact your company counsel,
or if you are a member of the Linux Foundation, feel free to contact Andrew
Updegrove of the firm of Gesmer Updegrove LLP, which provides legal counsel to
the Linux Foundation.

## Agenda

- General Updates
- Open Source Days 2024 [#650](https://github.com/AcademySoftwareFoundation/tac/issues/650
- Sponsorships are still available; more details at https://events.linuxfoundation.org/open-source-days/sponsor/
- Register your project to be part of the Virtual Town Halls and/or BOFs at [2024 Virtual Town Hall & SIGGRAPH BoF Schedule](https://docs.google.com/spreadsheets/d/1BPqnpX9aAGLxe1ShG14RgqVynwRzaa3xtmYpYjlllos/edit#gid=67361683)
- Sponsorships are still available; more details at [Open Source Days Sponsorship registration](https://events.linuxfoundation.org/open-source-days/sponsor/)
- Dev Days 2024 [#662](https://github.com/AcademySoftwareFoundation/tac/issues/662)
- Application for projects closes on Friday
- We mostly need from projects to register interest to be part of it, don't need to have all your materials in place
- https://github.com/AcademySoftwareFoundation/tac/issues/new/choose
- MaterialX, OpenEXR, OSL and OIIO (OCIO?)
- Larry: encourage other projects to do it, projects who did it last year got value and wanted to repeat. Overhead of registering is minimal, OCIO has a good wiki page. We have a few months to do rest of prep
-
- Clarify policy on incorporating Zoom chat to TAC meeting notes [#667](https://github.com/AcademySoftwareFoundation/tac/issues/667)
- Engineering Contribution Matrix
- Project leads: please update
- PyPI account: please add aswf-pypi user to your project, same as ReadTheDocs. Will put link on Slack channel
- Zoom polling for TAC votes: https://github.com/AcademySoftwareFoundation/tac/issues/702
- John: PCC has a voting feature, but it would be offline voting, we've done this from time to time, maybe TAC wants to go that way. Otherwise it's the consensus voting.
- JF: no support in Zoom polling to designate who has voting rights
- Zoom comments: OK to include? https://github.com/AcademySoftwareFoundation/tac/issues/667
- Kimball: seems OK, especially if editorialized
- OpenFX Annual Review - Gary [#514](https://github.com/AcademySoftwareFoundation/tac/issues/514)
- Stephen (Chat): Sometimes it's nice to be able to add a comment to the conversation for consideration, but not require the spotlight to do so, especially as speaking into a room of 25+ people, it can be tricky to get a word in edgewise.
- [OpenFX Annual Review Slide Deck](./OpenFX_ASWF_TAC_Update_June_2024.pdf)
- First full year as ASWF member, overall things have been quite good, seeing benefits of being ASWF member.
- Still challenges
- Moving to a 1.5 release for SIGGRAPH, our last 1.4 release was 10 years ago, so we're definitely making stronger progress
- Organization Status
- Stats
- Contributors
- 8-10 people attend every TSC, sometimes we get 10-12
- Only 3 GitHub committers & 4-6 GitHub reviewers - need more!
- GitHub users: up 2x since last year
- GitHub visitors: up 2x since last year
- Git stats
- Commits up 87%
- Contributors down 6%
- Forks up 60%, starts up 15% (380 vs 321)
- Monthly TSC meetings are solid, reliable, helpful and well attended
- Mailing list: 50+ members
- Slack: 148 members (this is our primary communication channel now)
- Up from 98 in June 2023
- Discord: 50 members
- Updates
- New website is live
- 1.5 is coming by SIGGRAPH 2024: color, OpenGl, GPU, new properties
- Organization Status: Discussion
- We are starting to move much faster than we did pre-ASWF. Monthly meetings help a lot, and the ASWF's resources really help offload the admin work, as well as helping set direction and give us goals to reach for
- But we'd like to go even faster if we can
- We will always be slower than some open source projects because we have major commercial users, and because OpenFX is a mature plugin standard, so we need to get buy-in from both hosts and plugins before committing a change to the standard. But we can do better around release engineering and support libs
- We're trying to pull people together and get consensus on how to extend OpenFX both into new areas and deeper into existing use cases, to ensure OpenFX is the standard for visual effects for many years
- Color management (headline feature for 1.5) is a great case study: being part of ASWF has enabled us to work more closely with OCIO to define how effects and host apps should communication color information. We hope to do the same thing with OTIO to help transport effect definitions in timelines in a portable way.
- Project Status
- Tech
- Gpu support for Metal, OpenCL in addition to CUDA: complete (98%)
- Vulkan support is on the list
- Overlay drawing support for non-OpenGL hosts: complete
- Conan & Auto CI builds
- In process
- Automated release process
- Color Management: use OCIO
- Improved spatial clip management
- Outreach
- Working wiht other ASWF groups: OTIO, OpenCOlorIO, CI working group
- OTIO: helping define effects definition schema
- OCIO: using that to specify clip color spaces in OpenFX
- CI: helping set up CI and Conan
- Non-ASWF groups: ASC and SMPTE re: "frame decision lists"
- Open standard for recording framing decisions, analogous to EDLs but for spatial framing (cropping, pan&scan etc)
- Outlook
- Focus Areas
- Adding color management - our top priority right now
- Adding plugin and host example and test code for all new features
- Solid CI and release process
- Helping everyone migrate away from OpenGL (GPU buffers and DrawSuite)
- Support Vulkan image buffers, as demand grows
- Supporting OTIO's effect definition standard
- Needs
- More contributors / committers / reviewers
- More input from new people
- More git and github expertise amount the TSC
- Help to support our example polugins, and pluin and host support libs
- Better documentation of host feature support
- Ideas
- Would folks be interested in ASWF open source events at NAB or IBC?
- Since we're in the 2D post space, most of our users and contributors are more likely to attend NAB than SIGGRAPH
- David: want to move this forward, let's set up a meeting with Emily to figure out what to do at NAB next year. Start thinking about what that could be. Gary: I have plenty of good ideas. NAB is now actively promoting open source, had dedicated space in South Hall
- David: are you aware of Dev Days? Do you intend to participate? Gary: haven't been able to get someone in TSC to volunteer to do the ground work. David: would be interested in hearing if Dev Days would fit, or not. If not, what would be the mechanism? We have evidence from last year that it works, but may not be for all the projects. How can we help you to get more engagement, we can take this offline.
- Could we create a job board to match projects with developers?
- Questions?
- Larry: curious about lack of familiarity with Git / GitHub? Are you drawing from a different population, less familiar with open source processes? Usually we see this with people new to working on a project with other developers. There are resources we could point you to, tutorials, perhaps where other projects could help? Gary: I do have a collection of these resources I draw upon and send to people. Everyone on the TSC is on GitHub, but we are drawing from a "traditionally closed source" population, people who grew up with CVS and Subversion, and have made Git work like that, in a centralized way in their organization. So trying to drag them into the 21st century! It's working, getting more PR from group members. Larry: we have some of those issues on other projects as well. Gary: also more a question a time, having people submit PRs instead of sending patches via email. People on TSC see the benefits of the CI process provided by GitHub. So we're getting there.
- Eric: we've talked about OTIO in the past, all sorts of overlap between projects. At the TAC level, have we talked about some kind of "cross project summit" so we can hammer out issues at the ecosystem level? How do we create a nice hand off between projects. How can the ASWF facilitate that, a meeting of the minds for a day. Gary: we had a subcommittee working on color, there were some TAC level decisions that forked off nanocolor group, how do we define a well known set of colorspaces that everyone can use. So that process has worked out well. Eric: maybe it makes sense to keep things things more topic focussed? But OpenFX schema denition has overlap with OTIO, have been working with ACES Metadata File (AMF), places where that overlaps with a lot of the domains with work in. Not sure what's the best way to create cross project alignment. Gary: maybe that is the right way, we identify the needs, and then get people together to do it. This group (TAC) isn't going to figure out the right set of color spaces. Larry: but this group is the right place to indicate that this topic exists, you have everyone's ear! Now you can take it off to a separate group. Eric: haven't been paying close attention to color interop forum due to personal interests, but how do we communicate what the color pipeline is so we can repro in various pieces of software. Maybe I should have been paying more attention there?
- Larry (chat): Dev Days can be (it is hoped) one way to attract new people. It's also a forcing function for the project to get its contributor docs and process into decent shape.
- Stephen (chat): A "Cross-Project Request Board" sounds like a great way to get dev talent to cross-pollinate on projects outside of Dev Days. ASWF bounty board? JC (chat): Like [Clotributor?](Like https://clotributor.dev/search?foundation=aswf?) What would be different? Doug: We have an initiative called the ASWF Color Interop Forum that is working on cross-project color topics. Stephen: I think of it as different sides of an awareness coin. Sure, I can go seek out specific issues if I know what I'm looking to go solve for someone, but I don't know what a project really needs that isn't accurately decomposed into GitHub issues, and many issues don't decompose that neatly. Not knowing that a project needs help with a conan issue, I'm not likely to go looking for conan issues, or know what project has posted up such an issue. Eric: Maybe related, if OTIO binds Imath and OpenEXR binds Imath, how do we make sure I can pass v2f from one to the other?
- Eric: Ffmpeg only takes PRs through mailing lists
- We don't have quorum (11 of 23) for a vote to renew, will do offline

- New Working Group Proposal - ASWF Language Interop WG Tyler / Scott
[#704](https://github.com/AcademySoftwareFoundation/tac/issues/704)
- [Language Interop WG Slide Deck](./ASWF_Language_Interop_WG.pdf)
- Languages: dedicated to providing C++ interop, and between various programming languages, each as a sub working group
- C
- Python
- Rust
- Swift
- Other languages to be identified by the TAC / TSC...
- Goals
- Collaboration with the ASWF in the mission to allow all of its existing projects and libraries to interop with these other programming languages, following eah respective language's best practices and standard
- Through the availability of plugins and other tooling...
- Non-goals
- Existing C++ libraries should not be modified, or modified very little
- Not rewriting existing C++ libraries into these other languages
- Responsibilities
- ASWF language interop WG
- Organize sub projects / WGs and make sure we're all on the same page with general design decision, communication etc
- Decide if a language is going to be included as an interop target (project will likely start with C, Python and Rust, with Swift being the first language that will likely be accepted as well depending on how we decide to set the bar...)
- Deliverables
- OpenEXR, OIIO, Ptex and USD for Rust
- OpenTimelineIO for Swift
- USD for Swift
- Subsequent products to be identified by TAC / TSC
- Questions?
- JF: is language specific in scope? Tyle / Scott: I think it is, for instance if a project has figured out how to do it with CI, we want to spread it to other languages. Since every project uses Python, the sub WG for Python can share that knowledge. Similarly with Rust.
- Kimball: OpenEXR is heading towards ABI stability, make it so our library is more reliable so you don't have to recompile every year. Have you had thoughts around ABI compatibility? Tyler: speaking generally? Swift is not currently ABI stable on Linux, it is on Mac, they are working towards ABI stability on Linux, but not there yet. Swift generates its own Swift code looking at C++ headers, works for most code. There are extensions one might want to provide, and require manual effort for a "safe" API, Swift is different in this case, whereas for Rust you would write the C wrapper. Rust might be the more stable / fuller API. Kimball: you can use SWIG to generate bindings, not sure it's a great solution, but if you run against new version of OpenEXR, could generate different bindings, so how to make sure the bindings are stable. Tyler: versioning the bindings to the respective versions of the library, may be able to use multiple versions of the bindings. Definitely doable in Swift, the API is creates can be based on a namespaced version of a C++ API. There should be a lot of focus on that, preserving the previous versions of a library, consistent with the versions of a binding.
- Eric E: there's sometimes a tension between making the API isomorphic to C++, and making it idiomatic to the target language. Rust wants memory safe, Python wants object oriented... Tyler: it should relate to the API be targeted, and shouldn't be a playground for language specific tools. Oriented towards the use case of the library, before going too far into the feature of a language, let's get the vanilla features of the bindings work. Rust can get more intricate with memory management, but we should be able to provide the standard, base API. Scott: the goal is that it should "feel familar" in the language, with some exceptions like error handling, where C++ can do it in many different ways, whereas Rust does it in a single way. Eric E: is the audience someone who knows the library and wants to learn a new language, or already know the language and want to learn a new library. Scott: both could be satisfied, Rust uses traits for object oriented inheritance. Would need to be figured out.
- Michael: I really like the framing of this WG, this is a challenge that ASWF has had since the beginning, people who have a passion for specific languages, picking a couple of languages, do it as a single effort, and allow people from different languages to collaborate. These languages all tend to have a package manager that people agree on (Rust, Python, Swift), so part and parcel of the bindings is a policy for the package manager. To Eric's point: I will offer the example of USD, if you look at the SDF API (one of the lower level libraries in USD), it's a very Pythonic API, but made the USD Python API a one to one mapping to C++ API, so there are examples to study. The Swift bindings for OTIO are rather idiomatic for Swift.
- Larry: there was a comment in non-goals, don't want to introduce a bunch of heavy PRs in the projects without having to change the projects. I think it's a good non-goal, but don't be shy about making suggestions to the projects. If you find yourself thinking that a design decision in a project makes some bindings hard, don't hesitate to communicate this. Putting Rust bindings on these libraries is a good goal, and there are Rust concepts that make C++ safer, so could improve life for C++ folks as well. So that kind of feedback is good, don't be shy to make it. Tyler: for Swift it requires built in Clang attributes, to see difference between a mutable reference vs a shared reference. Would these attributes be acceptable?
- John: we are at time, we can continue offline. Meeting at next TAC meeting. Kimball: yes bring it up at next one.
- Kimball: is it a WG or a project?
- Eric (Chat): Maybe related, if OTIO binds Imath and OpenEXR binds Imath, how do we make sure I can pass v2f from one to the other? KimbalL: That is less “maybe” and more “definitely” related to my question - and to be clear, do not expect an answer day one, just didn’t see it clearly in the goals, so wanted to point that out as a thought... JC: They’d probably have to be bound using the same tool (pybind, nano bind) and the tool’s version they were built with would need to have a compatible ABI. For example, pybind11 exposes an ABI that will affect the generated libraries.
- Eric (chat): OTIO leans into idiomatic bindings - there are a lot of pluses and minuses. The maintenance overhead is high, but they’re quite nice to use. Michael: In the general Swift/CXX interop tooling that Apple has made available lean into what Larry is talking about - essentially annotate the C++ code to get better bindings.
- Eric (chat): +1 to Larry - OTIO’s original design wanted to use a memory management model that made it easier to bind. (Our success level on that goal is open for debate)