Academy Software Foundation - Technical Advisory Council (TAC) Meeting - May 1, 2024

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

Voting Representative Attendees

Premier Member Representatives

Project Representatives

Carol Payne - OpenColorIO Representative
Cary Phillips - OpenEXR Representative
Chris Kulla - Open Shading Language (OSL) Representative
Jonathan Stone - MaterialX Representative
Ken Museth - OpenVDB Representative

Industry Representatives

Jean-Francois Panisset - Visual Effects Society

Non-Voting Attendees

Non-Voting Project and Working Group Representatives

LF Staff

David Morin - Academy Software Foundation
Emily Olin - Academy Software Foundation
John Mertic - The Linux Foundation
Tom Slanda - The Linux Foundation
Yarille Ortiz - The Linux Foundation

Other Attendees

Joe Bryant, Open 3D Engine Foundation
JT Nelson, Pasadena Open Source consortium / SoCal Blender group
Lee Kerley, Sony Imageworks
Matthew Cong
Tyler Furby, Wabi Foundation
Timothy Porter
Ben Giles, Calligra
Deke Kincaid, Digital Domain
Doug Walker, OCIO / Autodesk
Rabih

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. 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 / Notes

General Updates
- Volunteer for SLP 2024! #645
  - Carol: last call for volunteers, done with review, close to having selected group of participants
  - Looking to pair with mentors soon, now is the time to volunteer
  - This batch of learners is the most technical we’ve had so far, so messaging towards software development / technical side is working, almost every applicant are CS majors or double majors
  - If you are interested in mentoring, and getting into “nitty gritty”: they want to learn about Maya, Houdini, what is a pipeline TD
  - Carol: Link to Volunteer
- Open Source Days 2024 #650
  - Emily: CFP closes on May 12th for talks
  - Projects who want to do a talk above a BoF, let us now
  - If you are not sure a talk is appropriate, reach out to Emily to help figure it out
  - Still need 2 people for program committee, would love to have input from this community, please help determine the content
  - DigiPro: working to put together a submission for that, if you are planning to go to DigiPro and may want to be a speaker, please reach out to Emily. Several TAC members will be at Digipro
- Implications of xz Backdoor #652
  - JC: thanks for everyone that joined, we are going to work on the items in issue #652
  - John: will turn these into “programs” for the projects
  - Kimball: it’s not a per project problem anymore, but we will pull binary assets from DPEL, or should this be another project? Have we thought about someone embedding something malicious in DPEL? John: not sure we got to this level of detail. Kimball: OpenEXR is relying on pulling test images, could be an attack vector. Larry: it’s hard to imagine that going away, but may be different from blobs getting incorporated into software builds? Kimball: XZ attack unpacked malicious payload from test data. We can have policies for individual projects, but thinking about the cross project policies. John: a worthwhile next discussion. Larry: OIIO has a lot of images in its own test suite, they are binary, but also some images are from regression test suite from fuzz tests, so they are malicious by design. Kimball: we should have a follow up conversation. John: yes, there are actionable items we need to work on.
- Dev Days 2024 Participation #662
  - Finalized project participation form, can be shared later today.
  - Carol: we will share soon, will put out the form, deadline is going to be around mid June. You will have to submit the form by mid June so we can have everything ready to announce at SIGGRAPH.
- Operationalizing the TAC Roles plan #665
- Clarify policy on incorporating Zoom chat to TAC meeting notes #667
- ReadtheDocs Inventory #672
OpenImageIO Review #509
- OpenImageIO TAC Review Slides
- Larry / Daniel: Not just the TAC annual Review, but also our 1yr Anniversary
- Mission
  - OpenImageIO is a toolset for reading, writing, and manipulating image files of any image format relevant to VFX / animation via a format-agnostic API with a feature set, scalability and robustness needed for feature film production
- Major Components
  - CLI tools
  - Python bindings: ImageBufAlgo, ImageBuf
  - Image format plugins
- Ecosystem role
  - Founded by Larry Gritz in 2008k joined ASWF in 2023
  - TSC: SPI, Weta, Blender, ARRI, Disney TV, Animal Logic, Autodesk, Laika
  - Dependency of ASWF+ OSL, OCIO, MaterialX, OpenUSD
  - Depends on OpenEXR, OpenColorIO, OpenVDB
  - Embedded in: Maya, Houdini, Katana, Blender, Arnold, 3Delight, Gaffer…
  - Used in approximately all studio pipelines…
- First ASWF year highlights
  - 334 git commits, 41 contributors, 29 of which are first time contributors
  - Licensing change to Apache-2.0: 99.86% LOC, 93% of files
  - OpenImageIO 2.5 release
    - Improved color management, especially with OCIO 2.2
    - oiiotool –parallel-frames
    - TextureSystem color management
    - Hundreds of fixes and enhancements
  - Dev Days: 8 contributions
  - OpenSSF: 100% passing, 87% silver, 65% gold
- Eric: how did you get so many first time contributors? Larry: we were shocked by the stats, looked at the logs, seems to be right. We get a lot of diverse contributions. Daniel: it “snuck up” as we were putting the stats together.
- Roadmap: 3.0 release this fall
  - New mins: C++17. gcc9, python 3.7, OpenEXR 3.1, more
  - Deprecate a lot of old cruft (3.0 == can break compat)
  - Got rid of boost!
  - Self-build many dependencies if missing
    - We have a wide range of dependencies to wrangle, downstream builds can be tricky, especially on Windows.
  - Rust bindings, Python wheel (we hope?)
    - Python wheel: Another simple way to get a “one line” install
    - Rust bindings: almost all the way there
  - New file formats: JXL, RED
    - From new contributors
  - Hundreds of other improvements from the past year
    - Many back ported to existing releases
- Readmap: Long-term goals
  - Color management improvements
    - Collab with OCIO + color interop forum
  - Metadata strategy cleanup
  - GPU:
    - CUDA / OptiX implementation of TextureSystem
    - Direct read of images into GPU mem (collab with OpenEXR?)
  - Get our security act together
    - Leverage work from OpenEXR
  - Overdue overhauls of: RAW, Movie files, HEIC
- What’s working?
  - Used as extensively as ever, growing
  - Essential part of the VFX software ecosystem
    - Hard to find a DCC or studio pipeline that doesn’t use it
  - New features still being added / improved
  - TSC / meetings / extra eyes and hands
- Engineering Contributions
  - Lots of “drive-by” contributions (OIIO has > 200 contributors)
  - Very few people with sustained, dedicated time
  - What percentage of “fully resourced” are we?
    - 30-50% maybe?
    - There are features people are waiting for we can’t get to
- Specific shortfalls (all part-time, 10-20% FTE)
  - Ongoing part-time
    - Support, issue investigation, dependency wrangling, CI, security, releasing (ongoing)
    - Windows
  - Short term more work, then less ongoing:
    - Metadata strategy cleanup
    - Color management
    - DSLR raw overhaul
  - Several months of big work, then less ongoing?
    - GPU stuff
- Parting wish: Mackerel!
  - “Secret” catch phrase for when an issue comes up which doesn’t need to be addressed by Larry (“teach someone to fish” analogy)
  - Not asking for entire FTEs
  - If 5-6 big companies who use OIIO extensively…
    - Each had just 1 person dedicate consistent 20% time to OIIO…
    - Mostly doing things their own company will use (plus a little maintenance)…
  - That would probably double or triple the development velocity of OpenImageIO
- Open Discussion
  - JF: did joining ASWF meet expectations? Larry: “a solid B”. TSC really helps, more people answering questions, contributing things that would have waited for me before. More eyeballs and reviews helps as well. Only place we fall short is that I end up still doing a lot of heavy lifting, as well as some small things. Too many commits still from me, but sometimes it’s just 1 line commits, day to day maintenance. Would be good to have more people contributed consistently. We are doing surprisingly well, but wish we had a few more people with dedicated time from their organizations. Overall a big net positive. Larry: my specific fear was that we would join ASWF and I would still carry full load + extra meeting and overhead, and would end up a net drain. That was not the case, and was a net positive. Happy it’s in ASWF, helps stabilize its future. But there’s a sober assessment that I’m still doing the lion’s share of the work on my own time.
  - Chat: Joe Bryant: O3DE also sees surprise contributions from the larger chip manufacturers in APAC. Ben Giles: Not a Rust person— does the work for creating bindings there help for creating FFI bindings generally (LuaJIT for a random example? Scott: I can answer that (I’m building the Rust bindings for OIIO). Short answer is no, because we’re using a binding generator called CXX, which does the C++ -> C -> Rust dance behind the scenes. However, Anders has been working on a C++ to C tool that is in an interesting spot, but probably not production ready yet. Ben: Awesome, thanks Scott, that was far more appropriate than the LLM’s response. I may hit you up on Slack if that’s cool. No hurry in responding! Scott: Yeah, go for it! Feel free to ask any questions you have, and I’ll answer as soon as I can. Ben: As the FFI I do is typically Lua (or variants) and Python, I now understand why Rust is different. My question around the validity of Swift WG was “why not make it easy to FFI with any language” which is basically providing FFI friendly (C) headers. But I now see I I may have been naive. Scott: Yeah, C++ to C is not very trivial. If you want to do automatic binding generation, then that’s really, really hard. Anders has gone through maybe 3-4 attempts at his tool before he got to where he’s at. Tyler: I can answer on Swift related stuff — The way that Swift interop works is automatic generation of the Swift (object oriented) code of the existing C++ codebase. But it never enters “pure-C” land if that makes sense. Going the other way; the headers automatically generated from Swift can be included in C++ but not “pure-C” as well. Ben: That’s very helpful, thank you. I believe mojolang is the same. I take back my questioning of whether a broader effort is better— we have Lua clients, so perhaps I was being selfish. I prefer naive. I wonder what SWIG would say? It would be paragraph after paragraph in Esperanto flavoured English Tyler: I can reach out on slack and show you some of the generated Swift code and/or generated C++ headers if you’re interesting in seeing how some of the resulting product looks. Ben: We have the weight to push clients using Lua (and variants) to Swift on Linux if makes for better ergonomics on all sides.
  - Chat: Joe: So being a part of ASWF has helped organization, but possible not with contributions? Larry: There are definitely contributions. But I think a project like this has two different classes of contributions: (1) tactical: individual fixes or even features that scratch their own itch but then don’t necessarily come back until they or their org has another specific itch, and (2) strategic: sustained time that allows long term engineering improvements. I think we are currently very healthy on the tactical side, and I have no doubt that this improved as we jointed the ASWF. But the strategic contributions are still harder to come by. Joe: Thanks, I am still new to being an ED for O3DE, and absorbing how some of the larger open source projects and foundations are run, their challenges, etc. I have found that foundation/academy members tend to provide the more strategic contributors, and the general public tends to provide the more tactical contributors. Ben: I’m sure OIIO is used in science, medicine, and engineering. I used GDAL in a previous life and am happy to have moved on… I hope it’s easy to keep your focus while accommodating contributions from STEM more generally. In my experience (say, 10-bit colour in Wayland, or shader writing for the compositor)… tech artists, TDs, researchers, industry are all able to work together. We use a lot of ASWF projects even though we support more than M&E. ASWF products tend to be at the upper end of capability, so it “just works” elsewhere. USD is proof of that!
- Motion to renew
  - Kimball proposes, Carol seconds
  - Renewed for another year!
USD Working Group Review #518
- Alexander / Nick
- USD WG TAC Review Slides
- USD WG is not a project, we’re a community WG for USD. While we discuss lots of technical details, this is a place for ASWF to come around topics related to USD. Showcase work done, highlight proposals that come up on USD proposals repository, educate on topics around USD, and have 5 sub WGs that dig into technical details.
- 1060+ members on Slack
- 11 Active Chairs running main WG + 5 sub WGs, thank you!
- 90+ meetings a year across all groups
- 35 presentations in main USDWG in the past 12 months, many published on Wiki: recordings can be watched
- 14 whitepapers
- 1 bake-off: over Xmas / New Years baked USD cakes
- 245 assets in assets WG, plus 60-70 additional files that document behaviors
- 1 dancing potato
- Work Products Showcase 2023
  - The Assets effort has become a valuable and often referenced library
    - Shadeball is in USD format, chess game, fully fledged detailed assets
  - Port GLTF tests to USD
  - The Camera group has fledged a formal proposal
    - Schema to represent physical camera in USD
  - Neutral platform to bring together other bodies; the work in camera brought together VES, ASC, ASWF and SMPTE in a joint forum
    - Various issues around metadata
- Alliance for OpenUSD (AOUSD)
  - ASWF and AOUSD are complementary
    - ASWF represents a talented and focused constituency
    - AOUSD is the place where that knowledge is formalized and integrated into the larger USD ecosystem
  - ASWF-AOUSD liaison agreement in place fosters that collaboration
  - The first concrete collaboration is the ASWF MaterialX + AOUSD Materials WG
  - More to come, stay tuned
- USD-WG Tightening Scope
  - We are discovering the clear value adds of our efforts
  - Neutral platform to bridge communities
  - A place for the ASWF community to share triumphs
  - Practical reference for best practices
  - Continuous exploration of automation, quality control, expectations of consistency
  - Pushing boundaries of what can be done
    - To generate proposals and consensus on direction
  - Less focus on broadening scope and more focus on bringing value to scoped areas we’ve adopted
  - Specification of MaterialX in USD has shifted to AOUSD
  - Detailed implementation on deployment to the web is shifting to other forums such as GitHub PRs against the OpenUSD repo by the involved vendors. A consistent WebAssembly build of USD that can run in browser. Being merged into USD repo over time.
- USD-WF Direction for 2024
  - Focus the working groups on work products
  - Showing up in person as we did for Open Source Days
  - Represent diverse voices
    - Bringing Cultural Heritage and Conservation to the table
    - Other story telling modalities
  - Represent diverse abilities
    - Accessibility as technological need in USD (alt text on the web)
    - Accessibility to the work products of the WGs
  - CBB: we should have stood up for the Summer Program
    - Lots of people in our groups, interesting projects. Some have a high workload, might be too late?
- Call for Participation
  - Some of our work applies more broadly than just to USD
    - Text & Accessibility
    - Contribution from Autodesk
  - We have security things to think about
    - On several levels; it’s tricky to think about
  - We heavily leverage automation and infrastructure
  - DPEL
    - Opportunity to coordinate on vetting content
    - Opportunity…
  - Presentations and demos always welcome!
  - Bake-off 2025
- Proposal to renew?
  - Matt Low Proposes
  - Kimball Seconds
  - All in favor, WG renewed for a year
- Questions?
  - JC: asking for help on security, what area are you looking at? OpenUSD, assets, ? Alexander: OpenUSD side, we’re not a ASWF project for the code, so we are different, but would like a conversation there.