Academy Software Foundation Technical Advisory Council (TAC) Meeting - July 8, 2026

Join the meeting at https://zoom-lfx.platform.linuxfoundation.org/meetings/aswf?view=list&projects=aswf

Voting Representative Attendees

Premier Member Representatives

Project Representatives

Carol Payne - OpenColorIO Representative
Cary Phillips - OpenEXR Representative
Chris Kulla - Open Shading Language Representative
Daniel Greenstein - OpenImageIO Representative
Diego Tavares Da Silva - OpenCue Representative
Jonathan Stone - MaterialX Representative
Karen Ruggles - Diversity & Inclusion Working Group Representative
Ken Museth - OpenVDB Representative
Nick Porcino - Universal Scene Description Working Group Representative

Industry Representatives

Jean-Francois Panisset - Visual Effects Society

Non-Voting Attendees

Non-Voting Project and Working Group Representatives

LF Staff

David Morin - Individual - No Account
Emily Olin - Academy Software Foundation
John Mertic - The Linux Foundation
Yarille Ortiz - The Linux Foundation

Other Attendees

Tony Micilotta - Autodesk
JT Nelson - Pasadena Open Source consortium / SoCal Blender group
Doug Walker - Autodesk / OCIO
Lorna Dumba - Framestore / OpenQMC
Olga Avramenko - SPI / DNA
Jim Helman - MovieLabs
Lee Kerley - Apple

Meeting Assets

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

General Updates
- OSD: Project Fast Forward #1385
- Vulnerapocalypse #1403
Add Guide #1105
Annual Review: Academy Color Encoding System (ACES) #1091
Annual Review: OpenEXR #483

Notes

General Updates
- OSD: Project Fast Forward #1385
  - TAC meeting cancelled in 2 weeks, replaced by SIGGRAPH leadership meeting on Monday.
  - Please fill out your slot! Will start pinging individuals tomorrow if you haven’t finished
  - Slide set
- Open Source Days - Emily
  - 2 weeks away, don’t forget to register, opensourcedays.aswf.io
  - Members could register for free before July 1st, if you missed it, reach out to Emily
  - We will live stream through Zoom, recordings to YouTube
  - We will roll out recordings in phases, but private links available
  - Main program hasn’t changed from last week, full schedule
  - Please share!
  - Also BoF schedule on Monday, 2 tracks
    - We will have AV (sounds, mics)
    - Will be recorded and posted to YouTube!
    - OSD deck template
    - Jonathan (chat): For the MaterialX and OpenPBR Birds of a Feather, one of our speakers is a student who prefers that we not record and publish the event, so we should chat off-line to see how best to meet their needs.
  - OSD schedule is posted, BoFs on SIGGRAPH side
- Vulnerapocalypse #1403
  - Larry: we need to have a longer discussion on this topic, so can’t do this in 8 minutes.
  - Carol: we have been talking in last year about our security vuln process. A couple of projects went through an audit, but this was before the recent onslaught brought on by LLM-assisted vuln scanning. See TAC issue submitted by Larry, base level thoughts. OIIO and OpenEXR are the two projects being hit the most, any other projects getting a large volume of these? Let us know.
  - Carol: for OCIO, we’ve gotten our first vulns reported this year, so even though this is new, it’s not a lot so far. But it takes a lot of work to solve, when they were really bugs rather than vulns, in the code since version 1. Doesn’t mean they couldn’t be exploited.
  - What can we do as a foundation to make sure our maintainers don’t drown, given our limited resources.
  - Larry: especially interested in perspective of member companies, software vendors who incorporate these projects. What do they need from the project, what are vulns that required coordinated release, embargos… If we can treat everything as a normal bug, that’s great, but we don’t want to put you in a bad situation.
  - Carol: if your company has security expertise willing to participate in discussions, that would be great.
  - Gordon: at Autodesk, for our products we have to do an analysis of every issue. Security frameworks flag every issue. Sometimes we find issues that look horrible, but maybe you can do a lot worse with an API. So there’s no “rule” for classification, we do this manually based on the context. A dialog is the best way to do it. Our projects will know the context of how they use components. When it’s not clear, would be good to have a way to get a representative from the project and the stakeholders, “vote” on what is “super important”.
  - Larry: I would love help with a group like that. But looking at things individually is out of date when you’re getting a dozen a day. We need to shoot for more general guidance. Gordon: that is fair. I have not looked at the “onslaught” and how we could do a rule based approach.
  - Carol: we’ll get this on a coming TAC schedule, company reps / project leads should look at OIIO and OpenEXR queues, how often they need to do releases. Cary / Larry could share privately lists of reports.
  - Cary: in my workflow, I look at the email, look at the repo, see the vuln, and several pages of the problem, reproduction, analysis, sometimes a fix. Usually I point Claude at the URL and have it analyze it. Something to watch out is whether this can be triggered by an EXR file read into a reader, or does it require a sequence of calls in the API? If it can be triggered just be reading a file, that should be taken seriously. Otherwise takes more expertise to decide what to do with it. I’ll apply the fix, submit the PR, accept the advisory. If it warrants a CVE, I’ll request it. Then I pester Kimball / Peter to review PR, then it goes into the queue for next release. I wait until I’ve gotten the CVE ID to do the release. I have some where I’ve been waiting for two weeks, which bogs down the process. I’m waiting for a response before I can push out the release. Once the release has gone out, the release notes mention the CVEs resolved, at which point I can click “published” which in turn makes the report public on GitHub. You can only see the ones where the fix has been published. But I have several in various stages of the pipeline.
  - Cary: after I publish the advisory, GitHub does the publishing to mitre.org, which refers back to the published advisory page. But is the right information there for the people consuming the info? I don’t have a good sense if the information getting consumers the info they need to make decisions.
Add Guide #1105
Annual Review: Academy Color Encoding System (ACES) #1091
- Scott Dyer
- Presentation Slides
- Paperwork signed in July, but we didn’t start meeting until October
- ACES is a widely-used, standards based framework for capturing, processing, exchanging, and archiving scene-referred imagery (based around SMPTE ST2065-1).
- TSC: 7 members
  - Scott Dyer
  - …
  - Meet every 2 weeks
- ACES Project
  - ACES has its own Github org, aces-aswf
  - A number of repos
  - ACES consists of “code” and “not code”
    - SMPTE standards, specifications, best practices…
    - CTL repos:
      - aces-core
      - aces-input-and-colorspaces
      - aces-output
      - aces-look
    - C/C++:
      - CTL
    - XML: aces-aml
    - Python
      - aces-amf-lib
      - aces-amf-utils
      - aces-transform-registry
      - aces-common
    - Markdown
      - aces-docs
    - C/C++
      - aces-container (ARCHIVED), now point to OIIO
    - idt calculator is not ready for prime time and needs more resources
- Roadmap
  - Github project roadmap (WIP)
    - Need to get initiatives broken down into issues so we can more thoroughly fill out roadmap, communicate priorities, and track progress
  - Mostly been getting “settled in”
    - Transferred repos, set up community health files
    - Systems and information a bit scattered and broad
      - Consolidate to one place and simplify, wherever possible
      - Add automation to help manage complex infrastructure
      - Been working through permissions - Github, Github tokens, and PyPI
    - Keep running things through transition - manage legacy processes, e.g. implementers “Logo Program”
  - TSC discussion to align on project mission, vision, goals
- Contributions
  - 67% contributions from Scott
  - Mike Smith 18% from CTL repository, our most “software package” repo
  - 216 commits
  - Many stars / followers, but not a lot of contributors
  - OpenSSF badge: 94%
    - A bit misleading
      - CTL has CI and unit tests
      - Core ACES components, built using CTL, do not
    - Should these have separate OpenSSF badges?
  - Commit Activity
    - A bit misleading
      - Mostly cleanup, very few substantive commits
      - However, major new contributions on the horizon
  - Organizations
    - Mostly AMPAS
- Organizations contributing and/or using in production
  - Dozens currently using
  - Active participation down, but several past contributors
  - Studios: Netflix, Disney, Universal, Paramount Skydance, Sony
  - Cameras: Apple, ARRI, Blackmagic, Canon, DJI, Leica, Oppo, Panasonic, RED, Sony, Vivo, Xiaomi
  - Post production: Blackmagic, Colorfront…
- Getting more contributions
  - A bit of a chicken and egg problem
  - Have companies involved, but mostly only for their pieces
    - Transitioning to them “owning” and maintaining their pieces
  - We can make things easier, it just takes time
  - No good first issues - we’re still defining what those might look like for the different project components
    - Transforms - eg implementer submissions, or looks
    - Docs - eg usage guides, summaries (i.e. LLM summations then edits of long forum threads), product/application specific guides
    - CTL?
- Project Engineering Contribution
  - Updated, 0% to 3%, not meeting our needs
- AI / ML Code Generation Use / Reporting
  - No explicit policy yet published in our repos
  - Informal use of “Assisted-By”
- Goals
  - Establish a stable foundation
    - Clean up existing ACES codebase and practices, predictable intentional releases
  - Empower interoperability & implementation consistency
    - Provide vendors with clearer specs and tools to ensure identical results across applications
  - Expand documentation
  - Build sustainable governance and contributor onboarding
  - Explore ecosystem expansion
- Current & Future Focus
  - Automations
    - Working to add GitHub ACtions to help manage the complex repo structure, including submodule synchronization and automated release prep
  - Publishing to PyPI
    - Will be merging the project’s first Python packages to help with AMF validation, URN management, and more (under ASWF account)
  - Updating implementer contribution guidance and systems
  - Big goal for next year is to being adding tests for ACES CTL components and fof implementers to better verify implementations
- Key Achievements in the past year
  - ACES 2.0 (April 2025)
    - Not technically in “past year” but important foundation for a planned August release
  - Almost ready
    - Python packages: aces-amf-utils, aces-amf-lib, aces-transforms, aces-common
    - CTL enhancements: 16x speed CPU, Metal backend, unit testing framework, VS Code debugger plugin, Matlab & Python bindings
- Areas the project could use help on
  - Re-engage previous participants, bring in new ones
    - Help brainstorm areas for improvement
    - Help reviewing PRs
    - Contribute new work
    - Create issues - bugs, features, anything!
- Feedback on working with ASWF
  - Some of the transition has been frustrating, but…
  - In the long term this is good for the project
  - How to handle CTL vs ACES stuff?
  - Lots of untapped resources here
    - People
    - Tools and support
- Q&A
  - Carol: CTL has unit tests, but the implementation of the ACES core transforms written in CTL. OpenSSF badge scans for what it counts as “code”, but it doesn’t consider the CTL as “code”. Scott: wasn’t initially involved in setting up that infrastructure, but a lot of the links are just for CTL, doesn’t cover the rest of ACES. CTL is not ACES, it’s a language used by the ACES transforms. Carol: is it a goal to have unit tests for reference implementation? Scott: yes, absolutely. Previously we didn’t have a framework for that in CTL. Alex has done work on CTL to allow for native unit tests, have not explored that, especially for aces-core, which is the heart of ACES.
  - Carol: do you have permissions to open OpenSSF forms? Scott: yes I do. Carol: don’t think you need to separate into two? Also valid to exclude some stuff.
  - Larry: for badging, you can mark an item as “not yet met”, but still fill the box as to what’s left to do.
  - JF: seems it would be helpful to better segment the LFX metrics. Scott: yes, we see that as well. Carol: that’s good feedback. JF: multiple repo seems to be WIP.
  - Carol: sometimes the first year can be rough, ACES is a complex project, and I think you are doing a good job. It may feel like a slog. You’ve made good progress, and there are some really cool initatives. Scott: also trying to get other people to do things, if only for the health of the project.
  - Christopher Moore: Skydance is eager to help.
  - Carol: maybe we can do something at IBC.
Annual Review: OpenEXR #483
- OpenEXR - Cary
  - Presentation Slides
  - Developed at ILM in early 90s, still maintaining project. I am officially retiring from ILM at end of the month. Intend to keep working with the foundation and maintain the project. Maybe I have more time!
- TSC
  - Cary Philips / ILM
  - Christina Tempelaar-Lietz / ILM
  - Joseph Goldston
  - Kimball Thurston - Weta
  - Larry Gritz - SPI
  - Nick Porcino - Pixar
  - Peter Hillman - Weta
  - Rod Bogart - Epic Games
  - Kimball does most of the heavy lifting
- Contributing Organizations
  - Weta
  - ILM
  - Sustained constributions from Pierre-Anthony Lemieux / Sandflow Consulting, working with Disney to promote HTJ2K, a great contributor
- Commit Volume
  - Carry top committer
  - dependabot
    - Love/heat relationship
- Dev Days 2026
  - 5 PRs
  - 3 new contributors, including Moira Shooter, ILM London (3 fixes / new features)
- Vulnerapocalypse
  - 78 security advisories since Jan 2026
    - 8 in triage
    - 22 in Draft
    - 24 Published
    - 24 Closed
    - 19 releases (v3.4, v3.3, v3.2)
  - Maintaining is a huge burden at scale. Keep a spreadsheet to keep track. A weak point in GitHub infrastructure, the volume becomes overwhelming.
  - Updates to Security Policy: don’t think it will prevent vulnerabilities getting filed, but can point to policy when closing or not requesting CVE
- Other news
  - Lossy HTJ2K compression (Pierre-Anthony Lemieux) (previously lossless)
  - ZSTD compression (Vlad Lazar, ILM), promising for deep data
- Things we can use help on
  - Clone Kimball
  - Claude for Retirees? About to lose access to Claude.
    - Larry (chat): File an LF ticket, Cary, they have Copilot accounts for maintainers. Josh (chat): Claude for OSS maintainers
- Feedback on working with ASWF
  - Had a hard time coming up with this / voice specific things we could need
  - more maintainers / committers
- Q&A
  - Carol: you give feedback year round, so doesn’t have to be in this annual review. All the work around security has been based on your feedback.
  - Larry: we would like to have a long session about vulnerability reports at a future meeting. Different projects will have a different experience. Good to have a strategy
  - Cary: most of those issues aren’t that complicated, but the issue is when you have dozens. I fixed the same bug twice since I lost track. Larry: maintainer overhead of dealing with vuln report is 10x a normal bug report. Secret reporting, wait for CVE… It’s quite a burden. What should we really consider a vulnerability needs thought.
  - Eric: still ambitions on efficient EXR decode on GPU, some work has been done but doesn’t really deliver benefits yet. The developer retired recently.
  - Larry: EXR is a project everybody depends on, and relies on someone retiring and the CTO of a company who shouldn’t be doing this!
  - Carol: you should try to encourage engineers to look at OpenEXR, even if they are not “imagine developers”

Next Meeting Agenda

General Updates
- 2026 Security Reviews #1137
- TAC Industry Representative Election #1291
Annual Review: OpenQMC #434
Annual Review: USD Working Group #518
Revamp Annual Review Structure/Template #1336
AGENDA TOPIC ASWF Project Health & Resource Framework #1377
2026 TAC Priorities #1208