Academy Software Foundation Technical Advisory Council (TAC) Meeting - March 18, 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 - D&I 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

JT Nelson
Jim Geduldick
Cory Omand - Pixar
Alyssa Alexis - SIGGRAPH
Cuneyt Ozdas - Autodesk / OCIO
Doug Walker - Autodesk / OCIO
James Helman - MovieLabs
James Spadafore - ILM / Dailies Notes Assistant project
Lee Kerley - Apple
Olga Avramenko - Sony Imageworks / Dailies Notes Assistant project
Rob Wilson - DreamWorks Animatino
Robin Rowe
Sam Richards - ORI
Tony Micilotta - Autodesk

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 #1288
- AGENDA TOPIC: AI code assistant policy #1195
- AGENDA TOPIC SLP 2026 #1306
Annual Review: OpenColorIO #474

Notes

General Updates
- Dev Days 2026 #1288
  - Olga: 8 weeks away, getting ready. If you are company rep, someone from Dev Days outreach team will reach out to you. Please be on the lookup, will provide info if you want to organize. We are looking to increase participation in India, will ask for contact in your India branch if you have one.
  - Carol: coming up soon, please respond to emails from the team!
- AGENDA TOPIC: AI code assistant policy #1195
  - Carol: request to record that part of the discussion, for individual distribution. Any objections? Eric: I’m fine, as long as it’s not normal procedure. Carol: a number of people can’t make it today. I’ll go ahead and hit the record button.
  - Larry: projects are getting AI assisted contributions, asked TSC to discuss this. Have been on some of the meetings. This is a chance of projects discussing where they are. Promote the exchange of info, are there enough commonalities between views of projects so the TAC can adopt some “best practices” guidance. Would also like to hear from TAC / company representatives. Especially anything that affects your ability to contribute or use the project. MaterialX did this, Jonathan?
  - Jonathan: Larry attended our MaterialX meeting, we had a good discussion, focussed on 3 highlights from existing policies, LLVM a great example:
    - Contributor of a PR is considered as PR, must be confident of the quality of the work
    - Good First Issues are learning opportunities, not a good place for AI
    - Contributions must be labeled correctly, what is the level of detail. LLVM policy has “Assisted-By: “ model. I’ve seen that added to MaterialX PRs. It doesn’t require too much of a burden of telling the whole story of how a developer worked with AI assist.
  - Carol: OCIO discussed this. We align with “the author is the contributor, you are responsible for the PR you submit, regardless of how it was created”. For the “Good First Issues”, we understand wanting to learn, but OCIO has less of an issue with AI assistance on those. But don’t just “slam through Good First Issues” with an LLM. Personally don’t care so much if an LLM is used there, still so much to be learned / followed. Contribution guidelines, build the project, PR process. So these are all learning opportunities. I don’t want to make a process that is too hard to enforce / too restrictive and we don’t get a PR we would otherwise get.
  - Gordon: I like that direction. AI assisted coding is just going to be coding. Not using it will mean you are not competitive. AI will fundamentally raise the bar of what a Good First Issue looks like. “Contributor owns the contribution”, we want to guard against bots. As long as actual people are involve, we need to embrace AI, that will raise the bar of what a “Good First Issue” is.
  - Larry: from OSL / OIIO perspective, we are in alignment with MaterialX, wavering about “Good First Issues”. Also a 4th principle, “you may use the tools to help you write and understand the code, but interact with the project as a user, no bots, no automatic process”. I want people to write their own PR descriptions to the greatest extent possible. If you can’t summarize what was done, do you really understand it? 80% agree with Gordon, but we’re all looking at it from perspective of senior devs, and I worry using these tools by juniors to avoid understanding it. Not sure how it is going to shake out. Not worried about telling people to “go light”, you can fool yourself into thinking you know more about programming than you really do?
  - Gordon: what First Issues are we stopping getting fixed? If there’s an easy bug to fix and we’re not letting it get addressed…
  - Olga: Good First Issues are there to allow junior people to interact with the project. If we allow AI and agents to take those on, aren’t projects specifically created these First Good Issues for learning opportunity? If you make those harder, you may need to use AI, but then you may lose the point of getting people involved in the project. Seems like a poor idea, and how do you know that people aren’t “secretly” using those tools? Carol: people will do it anyway. There are lots of learning opportunities, unless you use a bot, and that we’re saying you shouldn’t do. AI won’t solve everything up front, like building the project. It’s not about the code fix, it’s about getting involved. Olga: by the time Dev Days is here, we should come up with rules in time for that. Carol: gives us a deadline!
  - Jonathan: may be a fool’s errand to prevent AI usage in Good First Issues. But I will refer to great language in the LLVM policy, they use the phrasing “learning opportunities”. “These issues are generally not urgent…” (see LLVM policy). We don’t have to inherit this idea, but it resonates with me. We want to people to “struggle” with the process so it sticks in their mind.
  - Eric: there’s “learning about the code” and “learning about the project”. Colleagues are no longer afraid to dive into something new with AI tools. If someone can’t figure out how to build, they will ask the AI to figure out it, then cut-n-paste the commands.
  - Chris Kulla: in practice people won’t read our AI policy until they reach the PR stage, and then won’t submit. I’d like to avoid that. We require people to sign off on what they used for the PR, a check box that “I understand this”. Up to project to decide if the contribution is to be accepted. Carol: we should write good recommendations, here’s our policy, and here’s our “philosophy” behind this. Chris: do we even have enough experience to say this is detrimental. These tools are so new, who knows.
  - Alyssa: AI has helped be debug gfx projects for shader files, as well as Docker files, but if I don’t understand Docker, the AI will suggest fixes I don’t understand anyway.
  - JF: we also need to guard against malicious contributions, whether automated or not.
  - Gordon: what do we want to stop happening? Bot contributions? But we also want to make sure things do happen, like learning about the project and becoming long term contributors. Will need to be more nimble. This is all moving very quickly. On a first contribution, we could ask a “skill testing question” for instance? Do we care that they learned through AI? There is a future where there are bots which are really good engineers, lifting the quality of the software? We don’t want to hold ourselves back.
  - Stephen: what seems to already happen is that projects are being rewritten wholesale to rewrite with a different license. This is a bit more “existential”, if we refuse contributions, people could end up “routing against us”. We need to figure out how to interact with such contributors. We also need to level up our docs, so that LLMs want to consume our projects, and can better interact with our projects. We should keep our eyes on the tooling that can be used to make our docs easier to consume by LLMs, it will raise the quality of LLM assisted contributions. Jonathan: excellent points! The 3djs project have an LLM.txt file to guide the models towards the documentation, they have a good approach we may want to borrow.
  - Jonathan: maybe our best approach is to state our philosophy towards learning, may stand the test of time better.
  - Carol: everybody learns differently, everyone approaches their work differently. We need to embrace that, it’s not new, whether AI or not. We want to make sure we are thinking about this, and don’t think a lot of our policies need to change, but we need to address this head on.
  - Larry: very few of what we are talking about are truly AI specific. AI allows a scale that is making problems we need to deal with, for instance on Good First Issues, we never hard to say “if you are a senior dev, don’t do every GFI on a project”, we thought it, but we didn’t have to say it. Also on the “you’re responsible for your PR”, before they could have cut-n-pasted from StackOverflow without understanding it, but we didn’t feel we had to say it. We’re re-stating assumptions we’ve always had. So putting on “paper” assumptions we’ve had all along.
  - Mark Wiebe: on topic of writing docs for LLMs, I find it useful to write for people then add exact goal that it’s also for LLMs. Never ran into a problem that I needed to make a completely different document. Can always keep it for people first. Also using LLMs to create drafts, then extensive iterations to fix, is quicker to get to message and overall structure. AGENTS.md can be pointers to find documents, but same thing you do when navigating a directory structure. It’s not just good for the agent, it’s also good for users.
  - Carol: we will continue this discussion. We will also need to keep an eye on resources it’s taking from maintainers, the policies we put in place need to help maintainers as well. I don’t want to refuse a PR on OCIO, but who knows what that will look like in the future. We can have more discussions on this, but if everyone feels comfortable on this, we can work on a draft? Larry: this is super helpful, sounds like we’re 90% in alignment, most importantly, I’ve not heard anyone say it would inhibit contribution or use, so that’s reassuring. We can figure the rest out. Sounds like several projects are on the way to have a first stab at a document, can we synthetize these into TAC-level guidelines / best practices, so that other groups who haven’t gotten there yet, they don’t have to start from scratch. As an organization, we seem to be mostly pointed in same direction. Carol: having something for Dev Days would be the deadline, as said by Olga. Larry: we’ll see where we are in 6-12 months and revise as necessary.
- AGENDA TOPIC SLP 2026 #1306
  - Carol: launched yesterday, will be 6th year.
  - Volunteer info
  - Volunteer application form
  - Please Volunteer! And propagate in your company. We revamped the volunteer form, should only take 45 seconds. Can be anywhere from just reviewing applications (2H total) to mentoring (1H per week). Eric: target audience for mentees? Carol: yes, we are doing under-represented race / ethnicity in VFX and animatino. Eric: the form may need to be updated. Carol: thanks, will update. “Under-represented” is a wide category, we allow applicants to self identify.
Annual Review: OpenColorIO #474
- Presentation Slides
- ASWF Tac Update - March 2026 - Carol, project chair, here with Doug Walker
- Project Health
  - TSC
    - Chair: Carol Payne
    - Chief Architect: Doug Walker, tech lead for color science at Autodesk
    - TSC Members: 11
    - TSC Emeritus: 2
      - Patrick Hodoul (Autodesk)
      - Carl Rand (Weta Digital)
    - TSC hasn’t changed since last year
  - LFX Insights - some improvements
    - Top Contributors
      - Doug Walker: 30%
      - Thomas Mansecal: 8%
      - Cuneyt Ozdas: 8%
      - …
    - 563 Commit Activities
      - Large spikes when we do releases
    - LFX getting better / more accurate, lines up better with expectations of contributors / commits.
    - LFX Insights - some things still don’t make sense
      - Autodesk called “Delcam”, not sure about “Yalansavar” which is supposed to be second top orga
      - Unclear on what “Active Organizations” means, or whether it is useful.
      - Would like to look at what kind of data is useful:
        
        for project
        
        for TAC
        
        for Board
  - Other project health factors
    - We depend a lot on folks at Autodesk, but also Remi Achard at DNEG, Kevin Wheatley at Framestore, who could take over running project, maintaining CI
    - “Could be better, could be worse”
  - Release Cadence
    - Solid release cadence
    - On 2.5.1, bugfix on 2.5.0 for VFX Platform 2026
    - Planning 2.6.0 for September for VFX Platform 2027, with updated configs
    - OCIO Roadmap
  - Development Highlights
    - OCIO 2.5
      - Built-in ACES 2 configs
      - Interop color spaces metadata
        
        Better interop between OCIO and other apps
      - Config merging
      - Hue curve xforms
      - Vulkan Support
      - Biggest release since 2.0
    - In progress for a future release
      - SMPTE CLF v4 updates
      - Test harness for Vulkan and HLSL
      - Better os-level HDR display integration
      - Nanocolor
      - …
- OCIO library roadmap
  - keep larger community up to date as to what we are working on / what we have planned
  - can discuss requirements with maintainers
- ocio support in FFmpeg 8.1
  - Convert scene-referred OpenEXR frames for use in movie files
  - Supports:
    - OCIO ColorSpaceTransform
    - OCIO DisplayViewTransform
    - OCIO FileTransform
  - currently in FFmpeg master branch for easier developer
  - Sam: 8.1 released yesterday
- OCIOView
  - GUI-based app to support editing and testing of OCIO configs
  - Still in beta, hoping for 1.0 release with OCIO 2.6
  - Moved to standalone repository for easier development
- OCIOView - Dev Days
  - Hoping to focus on OCIOView for April Dev Days
    - A Python based app
    - Standalone repo should be easier lift for new contributors
    - GUI app framework should be more approachable / testable
    - Lots of low-hanging fruit to help us get to that 1.0 release
    - Carol: hoping this is more approachable, help with steep learning curve projects, make it fun
- ASWF Color Interop Forum
  - Goal: encourage color space interop across industry projects
  - Who: everyone who deals with color interop, even if not using OCIO
    - ACES, camera vendors, experts from VFX< animation, games, post
  - Why: color is hard enough…
- Color Space Encodings for Displays
  - Completed in 2026
  - Baseline set of standard display color spaces
    - Display only - does not include view (i.e. tone mapping)
    - In the ColorInterop GitHub repo
- Interop ID & its use in OpenEXR
  - An ID for Color Interop
    - Identifying the COlor Space of OpenEXR files
    - Currently Google Docs (see slides)
    - OCIO COnfigs allowed people to use whatever name they want to refer to color space, great for studio conventions, but not great for interop. This gives a way for the config to have a unique ID that will make interop a lot easier. Also ICC profile paths, ACES xform IDs are now part of configs.
    - Color Interop ID implemented in OpenEXR, usable today. Documents are in final stages, open to comments on how they can be used in apps, workflows, there are flowcharts of what should happen when writing / reading an EXR file. Best practices that DCCs can follow, how to handle the metadata.
    - Color Interop forum meeting next week will discuss these.
- ASWF Color Interop Forum
  - This is new ground for ASWF
    - Publishing recommendations instead of code
    - ASWF is not a formal standards group (eg SMPTE, ISO, IEC, ITU)
    - We may talk with the TAC as to what the future should be.
  - Current Citations
    - AOUSD core spec (see notes for URL)
    - khronos Group - glTF Guassian Splat Specification (see notes for URL)
    - Wxciting to see our work cited in other specs! Validates that what we are doing is useful and working.
- OpenUSD / MaterialX collaboration
  - Bi-monthly Nanocolor meetings
  - Current focus is on documentation and test assets for OpenUSD and MaterialX
    - testing that color space info is preserved
    - communicated through Hydra
    - Handled correctly by renderers
- ACES collaboration
  - Developing a look transfor for DCC / game usage
    - Provides a more finished level of contrast in ACES 2
  - Serves as a test-case to explore look transform handling in OCIO
    - Provides guidance on customizing ACES output transforms
- Summary: project collaborations
  - Completed
    - OpenFX - introduced OCIO support in OFX 1.5
    - ACES - output transform 2.0 working group and configs
  - In progress
    - OTIO
    - …

Next Meeting Agenda

General Updates
- 2026 Security Reviews #1137
- ORI follow up on Incubation #1167
- TAC Industry Representative Election #1291
2026 TAC Priorities #1208