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
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).
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).
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.
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.
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 ^^ - #14 by artao5
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.
Windows:
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.
Linux:
We build on CentOS 6, I see no reason to upgrade until something donât work on it anymore.
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. 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.
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.