For those who don’t know the thing: OpenPGL plugs into path tracing renderers to guide sampling. It already shows up in Blender via Cycles, and now lives under Academy Software Foundation governance for broader adoption.

A new home for guided rays

OpenPGL just became a hosted project under the Academy Software Foundation. It enters at the sandbox stage, which is the earliest entry point for young projects and comes with a stated goal of graduating to incubation within one year.

The project targets a specific kind of pain that every lighting TD knows by feel: path traced frames that need more samples because the sampler keeps spending effort in the wrong places. OpenPGL focuses on path guiding, an importance sampling strategy that uses additional information about a scene’s light distribution to make better sampling decisions. The result is higher rendering efficiency because the renderer spends more samples where they matter.

Path guiding has a deep academic history, but production teams rarely get value from a PDF alone. Integrating path guiding research into a production renderer can be tedious, and the implementation details often become a long-term maintenance tax. OpenPGL positions itself as a production-ready open source library aimed at lowering that cost by offering well-tested, robust implementations of state-of-the-art path guiding methods.

What OpenPGL actually does in a renderer

OpenPGL learns a representation of a guiding field during rendering and updates it on a per-frame basis using radiance and importance samples generated during rendering. During path generation, the renderer can query the guiding field at vertices along a path to get a local distribution that can guide sampling decisions, including which directions to pick next.

The practical promise is simple: better sampling quality, less noise, and more efficient renders for the same sample budget. The project also carries an explicit caution flag: its current versions are still pre v1.0, the API is still in flux, and it should be used with caution in production related environments. That is a polite way of saying the interface may change under you, so build your integration like you expect to revisit it. A lot. any times. Remember what you did for USD.

There is also a performance angle baked into the design. The implementation is optimized for recent Intel processors with SIMD instruction support listed as SSE, AVX, AVX2, and AVX-512. OpenPGL also states support for Linux, Windows, and macOS.

If you are the sort of person who reads build flags for fun, OpenPGL includes a CMake superbuild option that pulls dependencies and builds a full install directory. It can also build extra tools named openpgl_bench and openpgl_debug when enabled.

Who is already using it

OpenPGL is not arriving as an untested science project or white paper. It is already integrated into several big-name production renderers, including Blender’s Cycles, Chaos V-Ray, SideFX Karma, and Disney Animation Hyperion.

Disney Animation describes OpenPGL as an important building block in the second generation path guiding system of its Hyperion renderer, calling out a simple API and faster iteration on production challenges. The statement also says the studio used a new path guiding system using OpenPGL in the production of Zootopia 2, including shots with difficult lighting setups and complex volumetrics.

Illumination Studio Paris is using OpenPGL to bring advanced path guiding techniques into its production renderer in a robust and practical way, citing more efficient handling of complex lighting, reduced need for labor-intensive hacks, and more freedom for natural lighting setups. The statement also says OpenPGL proved especially valuable on its latest production, The Super Mario Galaxy Movie, for tackling challenging lighting scenarios.

Chaos describes performance gains in production scenes with complex lighting and calls the integration into V-Ray relatively straightforward. But V-Ray always has all the tools in it.

Governance, now with more grown-up shoes

As a sandbox project, OpenPGL is set up for open community participation under the foundation’s hosted-project framework. Separately, the Technical Advisory Council meeting notes for the project proposal capture additional context around the move, including that the proposal presentation was delivered by Sebastian Herholz, listed there as ex-Intel and soon Blender, and that the sponsor is Kimball Thurston at Weta.

The same meeting notes also include examples discussed in the proposal materials, such as comparisons showing less noisy results with path guiding enabled at the same samples per pixel, and an example that describes a V-Ray timing comparison of 50 minutes with path guiding off versus 34 minutes with path guiding on. Those examples are presented as part of the proposal materials, not as independently reproduced benchmarks here, so treat them as directional evidence rather than a guarantee.

Licensing, access, and the practical reality check

OpenPGL is released under the permissive Apache Software Foundation Apache 2.0 license. The code is available on GitHub, and the repository labels the current release as v0.7.1. The project is distributed as open source software under its stated license.

If you are considering bringing it into a pipeline, the most important detail is not the headline. It is the warning label: pre v1.0 and API changes are on the table. Plan for integration work, version pinning, and regression testing across scenes that stress your sampler. So, don’t put it into a production pipeline, and if you are writing your own render engine, please, be careful.

https://www.awn.com/news/academy-software-foundation-adds-openpgl-new-hosted-project

https://github.com/openpathguidinglibrary/openpgl

https://www.intel.com/content/www/us/en/developer/articles/technical/open-path-guided-rendering-made-easier.html



https://www.intel.com/content/www/us/en/developer/videos/path-guiding-with-blender-and-intel-open-pgl.html

The post OpenPGL joins ASWF first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

The Academy Color Encoding System (ACES), long the industry’s preferred standard for end-to-end color management, is officially moving its governance to the Academy Software Foundation (ASWF). Announced on August 6, 2025, this transfer marks the end of a decade-plus era where ACES was steered solely by the Academy of Motion Picture Arts and Sciences. Instead, ACES will now leverage the ASWF’s open governance, legal framework, and technical community.

Ten Years of Color, Now Open Source

ACES began life more than a decade ago inside the Academy as a response to the growing complexity of digital color workflows in modern filmmaking. Its goal: create a universal system for color management and image interchange that holds up from on-set through visual effects, grading, mastering, and archiving.

Putting the „Ace” in ACES

The recent 2.0 release this past spring brought enhanced color rendering, more consistent displays across different dynamic ranges, improved invertibility for transforms, and broader device support. Still, for all its impact, ACES’ future was tied to the Academy’s stewardship, until now.

ACES 2.0 – available in Mistika!

Why the Switch?

In practical terms, moving to ASWF means ACES will benefit from the same open governance and infrastructure that support other industry-defining open source projects. Expect easier collaboration between ACES and technical mainstays like OpenColorIO, OpenEXR, and MaterialX. This is less about rewriting ACES than about improving how it interacts with the rest of your pipeline.

How to Persuade Competing VFX Studios to Cooperate

ASWF: A Short History and a Growing Roster

The ASWF itself was established in 2018 by the Academy and the Linux Foundation as a home for open source software crucial to visual effects, animation, and postproduction. The list of member organizations reads like a credit roll from a superhero franchise: DreamWorks, Laika, Netflix, Sony Pictures Imageworks, Walt Disney Studios, Weta FX, and Warner Bros., among others. The ASWF has already shepherded open tools from Open Shading Language to OpenVDB, serving both creative and technical teams.

Governance and Next Steps

As with other ASWF projects, ACES will now be overseen by a Technical Steering Committee, composed of long-standing ACES leadership and developers. This committee will steer development, while the Academy remains an active participant. The aim: keep ACES stable, open, and evolving, but without sudden breaks from its established direction.

David Morin, Executive Director of the ASWF, points to the growth in developer participation and cross-industry adoption of ASWF projects as proof that the foundation can provide the community and infrastructure ACES needs for long-term health.

The open libraries of Hollywood

What’s Next for ACES?

Further details on the transition will be given during Open Source Days (August 10-11) at the Marriott Pinnacle in Vancouver, as well as virtually. The schedule includes keynotes, presentations on ACES’ open source innovation, and technical project updates for those who want the inside scoop (and are willing to navigate SIGGRAPH registration).

ACES Remains Industry Standard—But Test First

ACES may be the industry’s open source color management system of record, but—as always—test innovations before deploying them in production. New open source governance should lead to smoother updates, more robust collaboration, and a steadier development pace, but the fundamental rule remains: verify, then trust.

The post ACES Gets a New Home: Academy Hands Off Colour Science to the Academy Software Foundation first appeared on DIGITAL PRODUCTION and was written by Jürgen Firsching.

The Academy Software Foundation (ASWF) has added OpenAPV to its project lineup, a move bringing Samsung Electronics’ codec technology into an open-source environment for professional video production. OpenAPV promises “perceptually lossless” quality and supports resolutions from 2K to 8K with 10- to 16-bit color depth. Notable for its efficiency, OpenAPV uses around 20% less storage than proprietary codecs, offering an alternative to formats like Apple ProRes and Avid DNxHR. Samsung joins ASWF as a Premier member, reflecting its commitment to accessible media solutions.

While OpenAPV’s technology might appear enticing for real-time graphics and high-res media workflows, production professionals should assess its integration potential carefully. This codec supports high bit-rates, royalty-free usage, and varied chroma sampling, yet its newness in the ASWF “sandbox” means practical adoption will depend on further field testing.

For more, read the ASWF announcement here.

And while we absolute think the ASWF is an amazing organization, that is doing and will be doing great and useful things, we cannot help but be reminded of this XKCD-cartoon.

The post Academy Software Foundation Welcomes OpenAPV as a New Codec Standard first appeared on DIGITAL PRODUCTION and was written by Bela Beier.

In the case of Linux, this is done by the Linux Foundation. Some VFX-relevant open-source projects, such as OpenEXR or OpenVDB, are now under the umbrella of the Academy Software Foundation (ASWF), which in turn is under the umbrella of the Linux Foundation.

Anyone working with VFX will inevitably also directly or indirectly use open-source technologies, such as OpenEXR for exchanging images with high bit depth in the scene-referenced colour space, OpenColorIO for colour management, or OpenImageIO for reading and writing numerous image formats. These components are usually invisible to the user as parts of larger software, such as The Foundry Nuke, Autodesk Maya, or Blender. Although these open-source projects are used by many companies, the development of the projects was mostly in the hands of individual companies. For example, OpenEXR was under the control of Industrial Light & Magic (ILM), Open Shading Language (OSL) was managed by Sony Pictures Imageworks, and OpenVDB was overseen by DreamWorks.

A Question of Trust

This situation was unsatisfactory for other market participants, as they did not trust each other. This is also one of the reasons why all these projects are open-source and subject to extremely permissive licenses. Disney, for instance, would never use proprietary software from DreamWorks, but it would use OpenVDB as open-source software under the Mozilla Public License. However, trust would be further strengthened if the projects were managed by a neutral third party. This would also address the issue of projects becoming orphaned when a central developer changes jobs.

Enter the ASWF

The Academy Software Foundation (ASWF) has taken on this role, and under the auspices of the experienced Linux Foundation, it has successfully persuaded competitors such as NVIDIA and AMD, DreamWorks and Weta Digital, as well as The Foundry and Adobe, to work together. Jean-Francois Panisset explains how this was achieved in an interview.

DP: I‘m here at FMX with Jean-Francois Panisset (is.gd/jean_francois_panisset) from the Academy Software Foundation (ASWF). It‘s basically an umbrella foundation for a lot of open source projects that are currently used in visual effects. But why do you need an umbrella foundation for those projects at all?
Jean-Francois Panisset: Many foundational projects, like OpenEXR, OpenColorIO, and OpenVDB, were originally developed by major visual effects studios and later open-sourced. OpenEXR, for example, was open-sourced around 2003, and for a while, everything worked well — other studios could download the software, and vendors could integrate it into their products.
However, as time went on, the original creators moved on to new roles, left their companies, or even left the industry entirely. This led to a lack of active maintenance, and these projects began to stagnate. Bug reports went unaddressed, pull requests weren’t reviewed or merged, and in some cases, the projects couldn’t even be built anymore due to a lack of automated CI builds. It became an industry-wide problem. Recognizing this issue, discussions began on how to maintain these projects long-term and create a sustainable ecosystem. CTOs from major studios and software companies held meetings, conducted surveys, and explored solutions with organizations experienced in setting up foundations.
The Linux Foundation emerged as the best fit, having successfully created similar initiatives, like the Automotive Linux Foundation, which brought together competing car manufacturers to collaborate. This led to the decision to establish the Academy Software Foundation (ASWF) as a sub-foundation of the Linux Foundation, providing a structured environment for professional open-source development, ensuring projects wouldn’t collapse when individual contributors moved on.
Since its formation, the ASWF has expanded from the original three projects to 14, all of which are now active and well-maintained. One key advantage of the foundation is its legal framework, which allows competing companies to collaborate on these projects without concerns about antitrust issues. This neutral, legally protected space enables a higher level of cooperation than a three friends developing together – competing companies need to have a neutral space to collaborate.

DP: How do you support developers looking to contribute?
Jean-Francois Panisset: The ASWF offers a range of resources to support project development. We provide collaboration tools like a paid Slack instance, Zoom, and scheduling platforms to keep teams connected. Our GitHub organization is at the enterprise level, giving projects higher build-time limits, and we also have technical support through the Linux Foundation’s release engineering team for any GitHub issues.
We cover paid infrastructure like Docker Hub to avoid throttling on container pulls and offer more powerful build systems for projects that need extra memory or CPU, like OpenVDB. Projects with GPU-enabled test suites can also access paid GPU runners, which aren‘t available for free on GitHub. While development still follows the open-source model, working publicly on GitHub, these resources help avoid roadblocks and make the process smoother. The way you develop software within ASWF is really still the open source way – you get access to all these extra features that just facilitate the development process and mean you don‘t get blocked because “oh we don‘t have access to this”.

DP: Let‘s say I found a bug in one of your projects and I want to file a report or maybe I even have a fix. Usually it can be quite daunting to approach a project. I think you have some on-boarding process?
Jean-Francois Panisset: It varies by project, but most follow a standard process since they’re all GitHub-based. If you find a bug, the first step is to create a GitHub issue. All projects monitor these, and their technical steering committees review and prioritize new issues. If you also know how to fix it, submitting a pull request (PR) is encouraged. Some projects require signing a Contributor License Agreement (CLA), which assigns ownership of the code to the project, preventing IP disputes. The Linux Foundation provides an easy process for this. Individual developers sign an ICLA, while companies can sign a corporate CLA, allowing their employees to contribute without additional approvals. Though it may seem like legal paperwork, it can simplify contributions, especially from large organizations.
Other projects have a simpler process, requiring a Developer Certificate of Origin (DCO), where you certify that you wrote the code. Before submitting a PR, it‘s always good to engage with the project to confirm how they‘d like it implemented. Even if a PR needs adjustments, the steering committees ensure that issues and contributions are addressed.

DP: What if we’ve made a larger change, like customizing a library, and want to start small before submitting the bigger contribution?
Jean-Francois Panisset: The concept of a “good first issue” is key to project maturity. Projects are encouraged to flag these issues to attract new developers. While some projects require domain-specific knowledge—like contributing to OpenColorIO’s colour transform engine, which is suited for colour scientists—there are still many contributions that don‘t require specialized expertise. By tagging beginner-friendly tasks, newcomers can browse the backlog, find something they can tackle, and submit a pull request.
Last year, we introduced “Dev Days,” a 48-hour event, similar to a hackathon, where developers can get real-time help with setting up their environment or validating their approach. It’s a great way to onboard new contributors. Facilities are also participating by encouraging their engineers to work on open-source projects. This helps studios prevent knowledge loss — especially when only one developer knows certain systems like OpenEXR — by getting more developers familiar with key projects.
There‘s a tool called Clotributor, developed by the Cloud Native Computing Foundation (CNCF), that aggregates “good first issues” across multiple projects. You can search for projects you‘re interested in, and it will suggest issues flagged for beginners. It‘s not limited to ASWF; several foundations use it. Some projects have received PRs from developers outside their field who found the issues interesting. It‘s in every project‘s best interest to attract new contributors, even if it‘s just for a one-off fix — you‘re still better off than before.

DP: The list of projects on your umbrella is pretty impressive and every artist in the industry is using them actively. What‘s the rationale for the organizations behind the projects to open source their technology in the first place?
Jean-Francois Panisset: So, obviously, I don‘t speak for any of those organizations, but there‘s multiple motivations. The first one is: don‘t underestimate people wanting to do the right thing, and realizing that in our industry being able to collaborate is important. Maybe there‘s that, but also almost a business reason, because today there‘s very few projects that are done at only one facility. So, if I as a facility have this great proprietary data format that no one else know, that‘s not really helpful. How am I going to exchange data with other facilities? So open sourcing my component and “hoping” it becomes the de facto industry standard is great because I don‘t have to rewrite all my internal software.
Also, I don‘t have to carry a hundred percent of the burden of maintaining that software, because other facilities have an incentive to help develop and maintain that software. That‘s partly why the list of projects in ASWF are interchange formats – which are handling how you move data around between projects and departments and facilities and vendors. There‘s also the idea that I would love software vendors to support that format – and the way to do that is to make sure that my format becomes a de facto standard and the implementation becomes the de facto implementation.

Also if they can easily adopt the implementation into their software, it becomes more likely – who wants extra work, right? And in turn this would attract and retain software development talent – which is always a challenge and providing the opportunity for your engineers to not just “work internally” but also to contribute to a greater community will demonstrate their value to the community. And that‘s good for the company in the long term, because you‘ll have happier engineers who will be more productive.

Because, as an engineer, if you‘re exposed to not just the way things are done in your company but the way things are done elsewhere,you learn more and you become better at what you do. Open Sourcing as a way to make your engineers more productive and attract talent. I wouldn’t want to work where all the work is just internal – and with an Open Source Development, you will show the fact that you‘re not just a great studio that makes great visual effects, but you also have a great technical culture. There‘s no better way to advertise to professionals that than through open sourcing some of your internal technologies.

The post How to Persuade Competing VFX Studios to Cooperate first appeared on DIGITAL PRODUCTION and was written by Gottfried Hofmann.

The Academy Software Foundation (ASWF) has announced version 1.5 of the OpenFX standard. OpenFX, a popular open source plug-in standard, enables interoperability between image processing tools in the VFX industry. This release brings a number of new features and improvements aimed at optimising workflows and enhancing artists’ creativity. One of the key features in OpenFX v1.5 is enhanced colour management. New APIs ensure accurate and consistent colour representation across different media sources, devices and platforms. This is particularly important to ensure that colours are reproduced uniformly and correctly in different environments.

Another highlight is the introduction of DrawSuite, which provides on-screen drawing capabilities. This feature allows hosts and plugins to work together without the need for OpenGL. This facilitates the integration and use of drawing tools. The new version also offers extensive GPU support, including OpenCL, CUDA and Metal. This support accelerates performance and ensures smoother rendering and processing of graphics. This allows artists to work more efficiently and complete their projects faster.

Another important improvement concerns parameter management. With the introduction of Choice Params, user interfaces can be made more intuitive and organised. These new parameter options allow for easier and more efficient handling of settings and adjustments.

OpenFX v1.5 now also supports binary data processing, making it easier to handle plugin-specific data types and improving processing efficiency. This is particularly useful for complex projects that require specific data types. In addition, the new version brings support for Windows ARM64, extending compatibility with a wider range of devices and platforms. This allows artists to use OpenFX on a greater number of systems. Of particular note is the integration of OpenFX into the upcoming version 20.5 of SideFX Houdini. Houdini’s new Copernicus image processing node will support OpenFX, significantly expanding the possibilities for artists to integrate Houdini into their workflows.

Links:

OpenFX v1.5 Release Notes

Academy Software Foundation

The post OpenFX v1.5 first appeared on DIGITAL PRODUCTION and was written by Bela Beier.