Natron 2.3.15 released!

Get it from GitHub or!

Known Issues

See #504


Version 2.3.15

  • Inputs of the selected nodes are now always visible.
  • Avoid crash and issues when NatronEngine.Effect.destroy() is called. #368
  • macOS: fix version numbers in Finder information. #372
  • Fix callbacks in PyPanel and PyModalDialog. #379
  • Fix recursive Python calls and handle the Python GIL properly.
  • Fix loading of Python Toolsets, and document how Toolsets are detected.
  • Fix using Rotopaint with multiple layers. #420 #205
  • Fix loading project settings. #439
  • Fix property panels of PyPlug nodes. #449
  • Fix missing python API entry points. #485
  • Make “Use Host Interact” setting available from user parameters. #490
  • Fix deadlock when creating a dialog from #487


  • Fix bugs in DenoiseSharpen that caused crashes. #300
  • Add support for chromatic aberration correction when reading RAW files. #309
  • Update CImg and G’MIC to 2.8.4 and fix several issues in GMIC plugins (which are still beta).
  • Many new GMIC plugins, including GMIC Custom Code.
  • FrameRange: New options “Loop” and “Bounce”. #411
  • Update OpenImageIO to #350
  • Fix reading multi-view EXRs. #429
  • Support for reading and writing HEIF/HEIC images. HEIC is the still-image sibling of HEVC (a.k.a. H.265), and compresses to about half the size of JPEG but with higher visual quality.
  • Text: Added SRT subtitle format support.
  • AudioCurve (audio curve generator): new plugin.
  • Fix plugin bugs (IO and CImg) with images that take more than 2GiB of memory (e.g. 12000x12000 RGBA float). #456
  • Fix “Fill” PyPlug: was not filling everything if the Source was larger than the project. #475
  • Shadertoy: use the preset name as a sublabel.
  • LensDistortion/IDistort/STMap: add “Use src RoD” option to override format.
  • Blur: fix handling of render scale when computing derivatives. #496
  • Text: fix animating font family and retiming the text output. #482 #476

Binary Builds

  • Natron-2.3.15-Windows-64: Windows 8.0+, 64 bits
  • Natron-2.3.15-Linux-64: GNU/Linux 2.6.18+ (Glibc 2.12+, libgcc 4.4+)
  • Natron-2.3.15-OSX-64: OS X/macOS 10.9+, 64 bits
  • Natron-2.3.15-OSX-Universal: OS X/macOS 10.6+, 32/64 bits

Special thanks for this release go to:


Big thank you to all that made this happen! It’s going to go a long way towards letting people know the project is doing well!

1 Like

Major thanks and Congrats to all.


Thanks to everyone who helped that this could happen!
You guys rock!

Just wanted to say that on some Windows installations you may get a “Microsoft Defender SmartScreen” warning. Just ignore the warning and run it anyway (or similar option).

You can read more about it here:

So, the more people that downloads and run the Windows version the better “ranking” it will get and the warning will eventually disappear (until the next build).


Great work, congratulations!


Great to see Natron being developed again!
Thank you!

Actually we’ve been steadily fixing issues since 2.3.14, but what was really needed was an overhauled windows build system, and @rodlie did it!

1 Like

Some awsesome new stuff in there. I’m particularly excited about the audio node.
However, being on Win 7 64 bit Pro … well … I cannot read or write any files. Which makes Natron 2.3.15 totally useless to me.
I BEG of you, PLEASE do a Win 7 compatible build. Pretty please with sugar on top.
I tried the ‘quick fix’ in a dev thread that was pointed out to me in the Facebook group, where there was a new libOpenImageIO.dll file to replace in the 2.3.15 install. However, that didn’t work. That discussion was from when 2.3.15 was still in RC stage.
Is there no similar quick fix now?
I don’t understand … Why
Someone in the Facebook group said underlying libraries have dropped Win 7 support. :frowning:
Would that be OpenImageIO? It can’t be ffmpeg, cuz I just updated that and it still works just fine.
The dropping of Win 7 support makes me very very sad.

1 Like

Because windows 7 is old and isn’t supported by the vendor anymore.

It’s apparently an issue with OIIO using a function/command that isn’t in Win 7. Apparently compiling with mingw fixes that, as mingw includes that function/command. However, doing so ALSO breaks it for other builds.
At any rate, the dev said he’ll upload sometime this week a new libOpenImageIO.dll that should be compatible with Win 7. Crossing my fingers that that works.
Relevant Thread: To bug or not to bug ^^

To speed up the development, support only

  • Windows 10,
  • RHEL/CentOS >=7
  • Macos >= 10.9

Drop the support for outdated and non standard OS.

As long as our build system works I see no reason to do any changes, maintaining the build system must be done regardless of the OS versions we target anyway.


We build with MSYS2, the default target is Vista. Even if we only target Windows 10, the binaries would still be Vista compatible. OIIO is the only component that requires Windows 8+, and the reason why we had to drop Windows 7 on this and future releases. The Windows binaries are built on Windows 8.1 Pro, this is my choice since I want a stable and predictable build environment.


We build on CentOS 6, I see no reason to upgrade until something don’t work on it anymore.


The main binary is for OSX 10.9+. We also have a binary for 10.6+, this is Frédéric’s choice and I don’t think he would maintain it if I was too much work.

IMHO dropping 32-bit on Windows/Linux was worth it, it saved a lot of time.

Hi, all.

I joined the forum to tell that 2.3.15 release improved Natron big time!

I’ve tested older version for about a year irregularly for compositing 3D rendered still images (multilayer EXRs, up to 5000x5000px). Quite big issue has been constant freezing while compositing and often got pop up window notice if I want to cancel the viewer render or wait. Many times by waiting software got back alive, but sometimes ended up total freeze and I had to force close the software. Because of this I haven’t been fully convinced by Natron (Windows build).

Yesterday I downloaded this new version and old comp files worked way better and even though bigger setups might end up being a bit slow there was no freezing like before and working is much more pleasant. I attached 2 screenshots of my Node Graphs for an idea that 2 totally different type comps both had same problems and improvement despite of being different scale.

I didn’t make any tests what has caused improvement and this is just a first feel, but big applause for everyone who are continuing development and I will definitely get back to test/use Natron again.

Noticed another thread about UI redesign, which was shot down quite direct way with reasoning that current UI is good and development resources should be used for bug fixes and other improvents. :slight_smile: I agree on usability of Nuke style node graph, numeric value controls and UI layout in general, but would be interesting to see iterated UI design that keeps good features of Nuke but would have own distinctive look for Natron. Maybe it wouldn’t need to take developer resources for quite a long time if there are UI designers who can publish design samples regardless of standard development. I’m thinking it being good to get away from being a total Nuke ripoff, even though for my personal use I don’t mind Natron being 100% Nuke copy if it works as well as Nuke.


I have been thinking about that and I will be doing some research and propose a UI redesign some time in the future. For the time being, as you said the current UI is good enough.
I think Natron would get some trouble from Foundry as it gets better and more popular so having a distinct UI would be better to keep it unique and free from such trouble.

I doubt that this will be a problem, The Foundry could have done something back in ~2015 when Natron had a large momentum (and owners with capital). Now they can’t do much, it’s an open source project with no one to sue, and they don’t have any “copyright” on the layout.

Just a heads up, going from a mockup to something usable in Natron will require more than just styling, it will require code changes.

1 Like

That is true.

I’m aware of that. I will be cooperating with developers to see what works and I’ll most probably start working on it when we have more developers. Till then I’ll spend whatever time I have on research.