Academy Software Foundation Technical Advisory Council (TAC) Meeting - September 2, 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

Doug Walker - Autodesk / OCIO
Jonathan Swartz - NVIDIA
Jim Helman - MovieLabs
JT Nelson - Pasadena Open Source consortium / SoCal Blender group
Guillaume Brossard - Autodesk
Bill Ballew - Dreamworks
Andrew Pearce - Alienrobot
Jim Geduldick - Spaceboy Studios / VES Tech Committee

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
- Dev Days 2026 - Sept 17th #1446
- Add CRA Guidance for hosted projects #1455
Add Guide #1105
New Project/Working Group Proposal: New Project Proposal - libsmpte2094-50 #1460
Annual Review: rawtoaces #475

Notes

General Updates
- Dev Days 2026 - Sept 17th #1446
  - Coming up real soon
  - Starting to communicate, for instance on LinkedIn, please reshare, speak internally at your companies, encourage people to participate
- Add CRA Guidance for hosted projects #1455
  - John: slide presentation
  - What is the CRA?
    - The EU Cyber Resilience ACT (CRA) establishes mandatory cybersecurity for products with digital elements placed on the EU market. Orgs that develop, maintain or distribute software with digital elements must ensure their products meet essential cybersecurity requirements throughout product lifecycle
      - For more info on the CRA, LF Education has the following free course you can take for more information
  - What does the CRA mean for my project
    - On 11 sept 2026, EU CRA being requiring open source software stewards to report actively exploited vulnerabilities and severe incidents to EU authorities on tight deadlines (24h, 72h, final report)
    - Handled by LF
  - What does my project need to do?
    - Document whether your software is ultimately intended for commercial activities (most widely-used LF open source projects are). If your project does not publish software, the CRA is not relevant
    - Add a short CRA stewardship statement to your SECURITY.md identifying the LF CRA Steward (template on next slide)
    - Know the escalation rule: if you learn of an actively exploited vulnerability or severe incident, notify your LF CRA Steward immediately, while you fix the problem, never instead of fixing it
  - Stewardship Statement
    - Add to your SECURITY.md or similar public facing security documents (will be merged to TAC repo)
      - CRA stewardship: This project is supported under the Linux Foundation CRA stewardship framework. Our project CRA steward is [LF CRA Steward] and its policy is available at Linux Foundation Security Reports Security vulnerabilities should be reported through [project security mechanism] which we will coordinate with our CRA steward. For actively exploited vulnerabilities or other security matters that may require CRA escalation, please use the project’s security [emergency reporting mechanism] as appropriate.
  - Events where your project MUST notify the steward
    - Actively exploited vulnerability (AEV): a vulnerability for which there is reliable evidence that a malicious actor has exploited it…
    - Severe incident: an incident that harms (or could harm) the confidentiality, integrity, availability, or authenticity of important data or functions, or that has led (or could lead) to malicious code in the product or in users’ systems. Compromise of your release process resulting in malicious code in a release is the canonical example and must always be escalated.
    - If your project becomes aware of either, notify all of the following simultaneously and promptly: LF CRA Steward and your project’s own security channel.
    - When escalating, provide what you have: a description of the issue, reproduction steps, affected versions, any evidence of exploitation, and known mitigations. Don’t wait for complete information - the clock the steward faces starts at awareness.
- Ken: what are the penalties if we miss the windows? John: it’s more of a reputational issue.
- John: doesn’t just apply to open source software, any digital products or goods. Penalties for manufacturers are much more severe.
- Larry: some of the projects have had a lot of vulnerability reports, but none of them have had actively exploited vulnerability / major incident before, so hopefully this would be very rare. Major burden will be on vendors adopting open source projects, could have a cooling effect on adoption. Can we do anything to help? John: message can be the stewardship of a foundation. Also good hygiene to take a look at security processes, that’s where your focus should be. For all our projects, on a regular basis we build an SBOM.
- Eric: what about something like DPEL? John: the DPEL license strictly says not for commercial use, we can discuss offline. Majority of projects here are used in a commercial setting, embedded in a product, used as a studio. Spec development is excluded, also purely educational materials.
- Michael: any possibility that LF could hire white hat consultants for our “CRA resilience”? John: TAC should come up with requirements we would look for out of that. What would be value to businesses. OpenSSF spinning up services around this. This group should decide what makes the most sense.
- Larry: projects would love some guidance from vendor experts. Michael: I’m thinking as hiring resources to do some of the validation / hardening tests. Getting vendors resources for security is always a challenge. Carol: falls into grey area of “paying for development services”.
- Larry (chat): Mostly, I am not looking for a contractor to come work for the project for 6 months. But what the project could use is a legit security expert to spend maybe a day or two learning about the project and then tell us clearly what the threat model should be for a project of this nature, a couple pages of guidelines for what we should do in the future, and maybe a handful of agent skills that can be used to scan for most of the obvious mistakes we’re likely to make.
Add Guide #1105
- John working on adding, need each subject matter expert to look at the language, please take a look
New Project/Working Group Proposal: New Project Proposal - libsmpte2094-50 #1460
- Not enough heads up to have submitter ready
Annual Review: rawtoaces #475
- Presentation Slides
- Annual Review for rawtoaces - Anton Dukhovnikov
  - rawtoaces seeks to provide a reliable and extensible framework for the conversion of digital camera raw files to a high dynamic range scene referred format, along with establishing a database of camera and related data to enable this framework
  - Project was dormant for a while
  - TSC: no active members, it’s just me
  - Project contributed by AMPAS, most of the work done by Anton at Weta
- rawtoaces components
  - rawtoaces CLI tool
  - python bindings
  - rawtoaces_util C++ library (read->transform->write)
  - rawtoaces_core C++ library (solvers)
  - camera spectral sensitivity database
- roadmap
  - goals from last year
    - transform cache (done)
    - lens correction (done)
    - rawtoaces-specific CI containers (done)
    - user and developer documentation (done)
    - better test suite (wip)
      - A big target: we deal with raw camera files which are huge, and we need to support tons of cameras. Can’t have hundreds of camera files in the repo. Working on a generator for raw camera files for testing on the go
    - Python bindings (wip)
      - in a usable state
      - have not exposed all the C++ APIs yet since waiting for OIIO 3.2 release, which should be soon, we base our Python bindings on nanobind, OIIO is switching from pybind11 to nanobind in 3.2. Will be able to expose APIs which require OIIO objects
  - goals for next year
    - GUI application
      - attract more users
    - exposure stacking
- Adopted project review criteria
  - We don’t meet most criteria, except “demonstratable roadmap progress”
  - We don’t have many contributors or users. Lack of users is probably bigger issue.
  - Although still in incubation stage, we haven’t met all those requirements (missing GOVERNANCE document, since there’s no TSC at the moment)
- Contributions
  - 85% coming from 2 contributors, which isn’t great (Anton and Aleksandr Motsjonov, a hobby project)
  - We get some PRs from other people, but not many recurrent
- Organizations contributing or using
  - Weta
  - AMPAS
  - DNEG (some bug reports and fixes)
  - Not aware of any studios using rawtoaces, if you are using it, please let us know
- VF Industry Build Matrix Updates
  - Python bindings: none -> nanobind
  - Python: none -> 3.10+
  - Active VFX platform years; 2022-2024 -> 2023+
  - OpenImageIO: none -> 2.4+
- Project Engineering Contributions Updates
  - Contributing organizations: Academy, Weta -> Wera
  - Tactical needs/goals being met: 5% -> 70%
  - Strategic needs/goals…
- CI Security / Marketing Updates
  - CI build for VFX Platform 2023-2027, Linux, Windows, macOS
  - Dynamic analysis / fuzzing needs some work, played with local fuzzing, but not in CI yet
  - No vulnerability reports so far
    - Not many users!
  - Automatic documentation builds on readthedocs and github-pages
- AI / ML Code Generation Use / Reporting
  - Adopted the OIIO AI policy
  - using agents (Cursor, Codex) for both code generation and code review
  - almost all contributions from non-core developers seem to be AI-generated, many are “drive by” contributions, no follow up. Marking issues as “Help Wanted” would get an auto generated PR 20 minutes later
  - Larry (chat): It’s wild that a project this obscure can put a “help wanted” tag on an issue and immediately get a bot sending code.
- Key Achievements in last year
  - 3 releases: 2.0 / 2.1 / 2.2
  - expanded spectral measurements database from 11 to 52 camera models
  - created project documentation
  - test coverage 24% to 92%
  - homebrew formula
  - passing OpenSSF badge
- Areas the projects could use help on
  - We are looking for (in order of priority)
    - users / adopters
    - TSC members
    - contributors
      - a small project, would be good for project resilience, but we are coping
- Feedback on working with ASWF
  - The help from the CI WG is invaluable!
  - Collaboration with other projects is great (mostly OpenImageIO)
- TAC Open Discussion
  - TSC meetings happen right after TAC meeting, please come say hi after this meeting!
  - Carol: appreciate the optimistic yet realistic feedback!
  - JF: rawtoaces interacted well with CI to define what they needed
  - Adoption? Anton: we are mostly focussed on still cameras, need spectral sensitivity from the camera, don’t know if anything publicly available , or willing to contribute. Carol: also for cine cameras you need proprietary SDK. Anton: we have access to SDKs, could add the ability. If that’s something required, it could be done. Currently relies on libraw plugin in OIIO, which is still cameras only. Also could give a raw image buffer to rawtoaces if you have access to camera spectral sensitivity curves. Most of the curves in the database come from WETA, we share the stills cameras we measure, but can’t share the cine cameras.
  - Larry: I wonder if one of the big use cases for rawtoaces might be not just the CLI, but the library, which has algorithms which are generally useful to combine spectral info with debayering. Could be a useful part of functionality for other projects to consume. Not sure many know what the project fully does, need an evangelism component. Anton: rawtoaces can be used just to compute the transforms, doesn’t require OIIO or images, operates purely on metadata. Larry: don’t be shy about build-time enabled support for cameras, only present if the camera SDK is present. OIIO operates that way for at least one. Anton: that would be on the OIIO side, since we use OIIO for reading.
  - JF: would be good to try to talk to manufacturers to make it easier to automate builds against their SDKs.
  - Anton: neither Red nor ARRI SDKs give all the information that rawtoaces needs, which isn’t just the pixels.
  - Larry: a short white paper could be useful, “what are you not getting by just using libraw”, people have an ingest pipeline, they might not know there is something better
  - Andrew (chat): the lack of use is odd - is it due to low adoption of ACES? Is it because studios are using a different ingest into some other format? It seems like it would be highly valuable for any studio with footage from production and using ACES…
  - Carol (chat): It’s not really due to low ACES adoption
  - Larry (chat): I wonder if they just don’t know enough about its existence and features, or why their current ingest pipeline would benefit from it?
  - Carol (chat): Also raw2aces doesn’t handle video cinema camera formats (.mxf etc) so those go through other solutions (resolve etc). So we need to distinguish use cases here. Anton might talk about this but also it does not have any product integrations - CLI/API only

Next Meeting Agenda

General Updates
- AGENDA TOPIC: GitHub Security Manager role #1434
- Vulnerapocalypse #1403
- 2026 Security Reviews #1137
Annual Review: Dailies Notes Assistant (DNA) #1040
Revamp Annual Review Structure/Template #1336
AGENDA TOPIC ASWF Project Health & Resource Framework #1377
2026 TAC Priorities #1208
CRA Compliance #1442