# Natron: an open source node-based compositor for VFX work

> Natron is a GPLv2 video compositor built around a node graph, cross-platform and scriptable in Python. It is aimed at artists who need After Effects or Nuke style compositing without a commercial licence, and the project itself is openly asking for maintainers.

**NatronGitHub/Natron** — Open-source video compositing software. Node-graph based. Similar in functionalities to Adobe After Effects and Nuke by The Foundry.

- Repository: https://github.com/NatronGitHub/Natron
- Website: http://NatronGitHub.github.io
- Stars: 5,562 · Forks: 409
- Language: C++
- License: GPL-2.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/natrongithub-natron

## What Natron solves, and who it is actually for

Commercial compositing tools sit at a price point that rules out a lot of work: student projects, small studios, archival restoration, scientific visualisation, and anyone compositing on a machine that is not attached to a licence server. Natron fills that gap with a node-graph compositor released under GPLv2. The README describes it as "similar in functionality to Adobe After Effects, Foundry's Nuke, or Blackmagic Fusion", which is a positioning statement rather than a feature list, but the feature list behind it is concrete: a 32-bit floating-point linear colour pipeline, colour management through OpenColorIO, and image and video I/O through OpenImageIO and FFmpeg covering H264, DNxHR, EXR, DPX, TIFF, JPG and PNG.

The intended user is a compositor who thinks in node graphs rather than layers. If your mental model is a timeline with stacked layers and blend modes, Natron will feel like work. If your mental model is a dependency graph where a Read node feeds a Grade node feeds a Merge node, the interface will be familiar. The README explicitly says the interface "aims not to break habits", and the layout files are saved as .nl files that can be reused and shared, which matters for facilities standardising a workspace across several artists.

There is a second audience the README names directly: contributors. Natron is "looking for developers and maintainers" and lists the skills it needs, including Git and GitHub, C++ (the source is still C++98), design patterns, Qt (Qt4 or Qt5, with no Qt6 support yet), basic OpenGL, and basic Python. That is an unusually blunt statement of project health, and it should inform how you read everything else on this page.

## The node graph, the render pipeline and what runs where

Natron's architecture separates the engine from the interface, and the repository layout shows it: Engine/, Gui/, Renderer/, App/, Global/, HostSupport/ and BreakpadClient/ are separate top-level directories, with a PythonBin/ directory and Shiboken/ for the Python bindings. The practical consequence is that the same graph can be evaluated by the GUI process or by a headless renderer. The README states that Natron "can also be used as a background process in headless mode" and that it is "capable of running without a GUI for batch rendering with scripts or on a render farm".

Rendering is also isolated per process. According to the README, Natron "is able to render frames in a separate process, meaning that any crash in the main application would not crash the ongoing render (and the other way around)". That is a real design decision with a real cost: process separation means frames have to cross a boundary, and it is why the crash reporter directories (CrashReporter/, CrashReporterCLI/, BreakpadClient/) exist in the tree. For a long overnight render on a farm, the isolation is worth more than the overhead.

The caching model is described in the README as a RAM and disk cache that makes playback real-time once a frame has been rendered. Proxy rendering computes at lower resolution to speed up interaction. Neither is unusual, but the combination is what makes the viewer usable on large plates. The README claims the viewer has been "tested on 27k x 30k images", which is a scale figure, not a benchmark, and the documentation does not publish frame rates for it.

OpenFX is the extension mechanism. The README states that almost all features of OpenFX v1.4 are supported, and that OpenFX-IO, OpenFX-Misc, OpenFX-G'MIC and OpenFX-Arena are included in the binary releases. Commercial OFX plugins from RevisionFX, Boris FX (including Sapphire) and The Foundry's Furnace are listed as usable, but the README only says to "tell us if you successfully tested other commercial plugins", which is an admission that coverage is not guaranteed.

## Installing Natron and rendering a first comp from the command line

The repository does not put install steps in the README. It points at the website, https://natrongithub.github.io, for downloads, and keeps per-platform build instructions in INSTALL_LINUX.md, INSTALL_MACOS.md, INSTALL_WINDOWS.md and INSTALL_FREEBSD.md at the repository root. There is also a Natron.spec file and a build-configs/ directory, plus config-homebrew.pri and config-macports.pri for macOS package managers. If you are building rather than downloading, start with the INSTALL file for your platform, because the README does not reproduce those steps.

On Linux, the README documents one environment variable for machines without a supported GPU. Setting it forces software rendering, which the README presents as a fallback rather than a recommendation:

```bash
export LIBGL_ALWAYS_SOFTWARE=1
```

After that, running Natron from the same shell starts it without hardware acceleration. Expect the viewer to be far slower; the README lists the Intel, Nvidia and ATI/AMD chipsets that get hardware rendering, and an OpenGL 2.0 compatible card is the stated requirement for Natron 2.1 and later.

The reason to care about headless mode is batch rendering. The README says Natron can run without a GUI for rendering with scripts or on a render farm, and the Renderer/ directory in the tree is the part that does it. The documentation for the exact invocation lives in the user documentation at https://natron.readthedocs.io/ rather than in the README, so check there for the flag set your build accepts. What the README does confirm is the shape of the workflow: a project file saved as XML, which the README notes is "easily editable by humans", handed to a renderer process that does not need a display.

For scripting, the README lists the Python integration points: parameter expressions, user-defined parameters, node groups as Python scripts, a script editor for controlling the application, user-defined Python callbacks that fire at checkpoints such as a parameter change or before rendering a frame, and PySide embedded in the GUI so the interface can be extended with new menus and windows. Those callbacks are the hook to look at first if you want to automate a pipeline step rather than write a plugin.

## Where Natron is the wrong tool, and the maintenance question

The README does not document rollback, and it does not document a supported upgrade path between major versions. That silence matters more than usual here, because the release history is thin. The most recent release listed is v2.5.1-pre2 from 2024-09-13, preceded by v2.5.1-pre1 in 2023 and a MinGW package repository release in 2023. A pre-release is not the same as a stable release, and anyone planning a production pipeline around 2.5.1 is planning around a pre-release. The default branch is RB-2.6, so development is not stopped, but the last push was on 2026-07-24 and the project is openly recruiting maintainers. Treat that as a project with a small team, not a project with a release cadence you can schedule against.

There are hard technical limits too. Qt6 is not supported; the README says Natron "builds with Qt4 or Qt5, but does not yet support Qt6". On a modern distribution that ships Qt6 by default, that is a build configuration problem you will hit before you hit any compositing problem. The source is still C++98, which the README acknowledges, noting that moving to C++11 or C++14 "should be straightforward if needed". "Should be" is not "is".

Commercial plugin support is a compatibility claim, not a guarantee. The README lists RevisionFX, Boris FX and Furnace as plugins people have used, then asks users to report what else works. If your comp depends on a specific Sapphire effect, verify it in your own build before you commit a project to it. The same caution applies to any workflow that assumes a particular OpenFX feature outside v1.4.

Finally, consider what Natron is not. It is not a video editor. The README describes a compositor, and the node graph is the interface; there is no timeline-based editing model documented. If your task is cutting a sequence, Natron is the wrong layer of the stack.

## Natron compared with Nuke and After Effects

The README names Nuke and After Effects as functional peers, so the honest comparison is about approach rather than capability lists. After Effects is layer-based with a timeline, and its compositing model is built around stacking and blending; Natron is node-based, so a merge is an explicit node with two inputs and a defined operation order. That difference shows up in debugging. In a node graph you inspect the intermediate output at any point by viewing that node; in a layer stack you toggle visibility and reorder. Neither is strictly better, but the mental overhead of switching is real, and the README's claim that Natron does not want to break habits is about interface conventions, not about the compositing model.

Nuke is the closer analogue: node-based, scriptable, built for deep compositing and multi-channel EXR work. Natron matches several of those axes. It handles multi-layered EXR through OpenImageIO, and the README states that users "can choose to work with any layer or channel on any node" and create custom layers. It supports multi-view workflows by keeping all views in the same stream, with a OneView node to separate them. Where Nuke differs is in the surrounding commercial apparatus: vendor support, a plugin ecosystem with certification, and a release schedule. Natron's answer to that is GPLv2 licensing and no cost, plus a plugin system that accepts the same OFX plugins where they work.

A more useful alternative for some readers is not another compositor at all. If your pipeline is already FFmpeg-based and your effects are simple, a filter graph will do the job with far less machinery. Natron earns its place when you need interactive inspection, roto and tracking, and a graph you can re-render headlessly from an XML project file. The README lists rotoscoping, rotopainting and tracking support, which is the set of tasks that are painful to express as a command-line filter chain.

## Licence, upgrade cost and what to check before you commit

Natron is GPLv2. The README states the licence at the top and links to LICENSE.txt and LICENSE_SHORT.txt at the repository root. The practical implication for a studio is the usual copyleft question: if you distribute a modified Natron, or a work derived from it, the GPL's terms apply to that distribution. Running Natron to produce rendered images is a different activity from distributing the software, and the repository does not attempt to answer that question for you. Get your own advice if your business model depends on shipping a modified compositor.

The OpenFX plugin situation is separate from Natron's own licence. OpenFX-IO, OpenFX-Misc, OpenFX-G'MIC and OpenFX-Arena are bundled in the binary releases and are separate projects under their own terms. Commercial plugins from RevisionFX, Boris FX and The Foundry carry their own licences, and the README does not describe how those interact with Natron's GPLv2. If your pipeline mixes them, that is a question for the plugin vendors.

Upgrade cost is the part the material is weakest on. There is no documented migration guide between 2.5.x and 2.6 in the README, and the CHANGELOG.md at the repository root is where that information would live. Project files are XML, which makes them diffable and, in principle, editable by hand if a node parameter changes name, but the README does not promise backward compatibility for project files across versions. The safest posture is to keep the Natron version pinned per project and read CHANGELOG.md before moving a live comp forward. That is a specific file to check, not a general process to adopt.

## Conclusion

Adopt Natron if you need a node-graph compositor with OpenFX plugin support, Python scripting and headless batch rendering, and you are willing to build it from source or run a pre-release binary, because the newest published release is v2.5.1-pre2 from 2024-09-13. Do not adopt it if you need a vendor support contract, a Qt6 build, or a guarantee that a specific commercial OpenFX plugin works. Before committing, verify that your GPU supports OpenGL 2.0 for hardware rendering, check whether the OFX plugin you depend on is listed as tested in the README, and read INSTALL_LINUX.md, INSTALL_MACOS.md or INSTALL_WINDOWS.md for your platform instead of assuming the pre-built package matches your Qt and OpenColorIO setup.

## FAQ

### What is Natron software?

Natron is a free, open-source video compositor released under GPLv2, described in its README as similar in functionality to Adobe After Effects, Foundry's Nuke or Blackmagic Fusion. It is node-graph based, cross-platform across GNU/Linux, macOS and Microsoft Windows, and supports OpenFX plugins and Python scripting.

### How to install Natron?

The README does not contain install steps; it points to the project website at https://natrongithub.github.io for downloads, and the repository root carries INSTALL_LINUX.md, INSTALL_MACOS.md, INSTALL_WINDOWS.md and INSTALL_FREEBSD.md for building from source. The most recent release listed is v2.5.1-pre2 from 2024-09-13.

### How to use Natron software?

You build a node graph in the GUI, where each node performs an operation and feeds the next, and the README states that anything you do produces real-time feedback in the viewer through the multi-threaded render pipeline and proxy rendering. The same graph can then be rendered without a GUI for batch work or on a render farm, and the project file is saved as XML.

### How to use Natron?

The README lists the main entry points: parameter expressions, user-defined parameters, node groups as Python scripts, a script editor to control the application, and Python callbacks that fire at checkpoints such as a parameter change or before rendering a frame. The user documentation at https://natron.readthedocs.io/ covers the interface itself.

### What is Natron used for?

The README describes Natron as a video compositor, so its use is combining and processing image sequences: multi-channel EXR compositing, rotoscoping, rotopainting and tracking, with colour management handled by OpenColorIO. It can also run without a GUI for batch rendering on a render farm.

### What is Natron in English?

In this context Natron is the name of a free, open-source, node-graph based video compositor released under GPLv2, cross-platform across GNU/Linux, macOS and Microsoft Windows. The README positions it as similar in functionality to Adobe After Effects, Foundry's Nuke and Blackmagic Fusion.

## Sources

- [License: GPL-2.0](https://github.com/NatronGitHub/Natron/blob/RB-2.6/LICENSE)
- [NatronGitHub/Natron on GitHub](https://github.com/NatronGitHub/Natron)
- [Project website](http://NatronGitHub.github.io)
- [README](https://github.com/NatronGitHub/Natron/blob/RB-2.6/README.md)
- [Releases](https://github.com/NatronGitHub/Natron/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/natrongithub-natron