FFT3DFilter - The Portening

[Myrsloik]

Some people asked for fft3dfilter builds so I improved the existing port a bit. Now supports 8-16 bit integer and float formats. Also cleaned up the code quite a bit (something started by VFR-maniac in the initial port). The only difference in arguments is that plane was changed to planes and now works like the plane selection usually does in VS filters.

Fixed/improved stuff (relative to original VS version):
8-16 bit and float support
Piles of memory leaks fixed if there's an error on creation, for example invalid arguments would cause this a lot
Fixed beyond array bounds memory access
Improved internal cache to better handle not completely linear access

Known issues:
In really rare conditions the default for the bw and bh arguments that depend on whether one or many planes are processed can get confused
pshow and pfactor related things are completely untested

Test3 (https://www.dropbox.com/s/qbrx8pasawyx3kp/VapourSynth-FFT3DFilter.7z?dl=1)

[Sparktank]

Mmmmm, float.

[VS_Fan]

I made some visual inspection of results of the filter using vsedit. I tested different bit-depths: 8,10,16 bits and chroma sub-samplings: 444, 422, 420

I got the expected results for different values supplied to the parameters (separately and combined): sigma, sigma2, sigma3, sigma4, dehalo and sharpen

several instances of the filter in the same script - no problem!: I remember avisynth-MT (SEt's avisynth mod) crashing because of this.

Didn't test for speed yet, but tried ncpu=2, without problems. I remember this crashed avisynth-MT (SEt's avisynth mod). Is ncpu still relevant?

Usage Suggestions:

sigma2=sigma/n, sigma3=sigma2/n, sigma4=sigma3/n (n=2 or 4). Higher values for sigma3, sigma4 (lower frequencies) will considerably destroy details and increase halos
bw=bh=18; ow=oh=9 (half the block size). This is attending the recommendation from Fizick: "can be factored into small primes 2, 3, 5, and 7". Also, it will help reduce blocking artifacts.

problems found:

It's always processing all planes, no matter what value you use for the 'plane' parameter
sigma values don't scale with bit-depth: e.g.: sigma=2.0 will eliminate much less noise as you process at a higher bit-depth

[Myrsloik]

I made some visual inspection of results of the filter using vsedit. I tested different bit-depths: 8,10,16 bits and chroma sub-samplings: 444, 422, 420

I got the expected results for different values supplied to the parameters (separately and combined): sigma, sigma2, sigma3, sigma4, dehalo and sharpen

several instances of the filter in the same script - no problem!: I remember avisynth-MT (SEt's avisynth mod) crashing because of this.

Didn't test for speed yet, but tried ncpu=2, without problems. I remember this crashed avisynth-MT (SEt's avisynth mod). Is ncpu still relevant?

Usage Suggestions:

sigma2=sigma/n, sigma3=sigma2/n, sigma4=sigma3/n (n=2 or 4). Higher values for sigma3, sigma4 (lower frequencies) will considerably destroy details and increase halos
bw=bh=18; ow=oh=9 (half the block size). This is attending the recommendation from Fizick: "can be factored into small primes 2, 3, 5, and 7". Also, it will help reduce blocking artifacts.

problems found:

It's always processing all planes, no matter what value you use for the 'plane' parameter
sigma values don't scale with bit-depth: e.g.: sigma=2.0 will eliminate much less noise as you process at a higher bit-depth



I found the planes bug. How does sigma scale? same as the max value?

You can still use ncpu but you probably shouldn't. At least not unless fft3dfilter is the single thing bottlenecking your whole script...

The default argument changes I have no idea about, I'll do them if more people agree.

[VS_Fan]

How does sigma scale? same as the max value? Yes, scaling sigmas in the script, proportionally with max pixel value, gives me very similar results with different bith-depths
The default argument changes I have no idea about, I'll do them if more people agree.I have no problem keeping the old default values. Beides, it will be backward compatible

[Myrsloik]

I actually thought about scaling of arguments but doing so would actually be counter-intuitive for anyone who understands the underlying concepts. So I don't like that idea.

I updated the download link so now the planes argument works like it should.

The part I'm not sure about working now is pshow and pfactor. It just seems odd to me but not sure what the original does. I'll leave it for you to investigate... Note that text printing only looks correct in 8 bit, mangled in 16bit and derp in float. It's a known issue.

I'm also curious about speed comparisons with pinterf's version. Does all that asm really help?

[pinterf]

I'm also curious about speed comparisons with pinterf's version. Does all that asm really help?

When ported, I have made some comparisons, there is gain but I think the real bottleneck is not in these functions.
// bt=0
// x64 C -> simd: 10.24 -> 11.41 fps
// x86 C -> simd: 8.38 -> 9.86 fps
ApplyKalman_SSE2_simd

// bt=2, degrid=0, pfactor=0
// SSE2 x64 C -> simd: 11.37 -> 13.26 fps
ApplyWiener3D2_SSE_simd

[Myrsloik]

Test3 (link in first post)

Now the info printing works properly and did a bit more code cleanup. 4re updated the build system too. I really need some pshow and pfactor testing and then this thing is done. I guess...

[VS_Fan]

Test3 (link in first post) ... I really need some pshow and pfactor testingFindings:

pshow is printing 3 different [floating point] values. I assume the "sigma" is the first one to the left, because it is similar to the one you get in the old avisynth version (v2.1.1, which shows an integer value) and the newer pinterf's v2.4, which shows only one floating point value
The number of values shown for sigma is the same number of planes processed.
EDIT: Are these values the corresponding sigmas for each plane?
Please scratch this: If I assume these values are the corresponding sigmas for each plane, I could not be sure that the pframe parameter is taken into account. the proportion (luma:chroma) between the values, changes considerably as the selected block of the pattern contains different features in different frames. For the frame I selected with pframe, the noise (sigmas detected) are 1:2 approx. (much more chroma noise - luma:chroma) for the rest of frames, it changes dramatically up to to 3:1 (more luma noise), as the pattern block contains different objects and features in different frames. Unfortunately there's no way to check this in any version of the fft3dfilter for avisynth

Other than that, pshow and pfactor seem to work as intended (very similar to the old avisynth version 2.1.1, and newer v2.4)

shown value(s) for sigma(s) is(are) scaled according to bit-depth
px and py [block position of the selected pattern] depend on blocksize and overlap
pfactor < 0.5 will reduce too little noise
pfactor > 0.9 will destroy details and generate multiple artifacts

I haven't tested for speed, yet

[VS_Fan]

I can process every plane individually using different sigmas with a new instance of the filter for every plane.

So I tested both avisynth versions: 2.1.1 and 2.4. This led me to understand a problem present in every version of the fft3dfilter, v2.1.1 and 2.4 for avisynth and your test #3 for vapoursynth: Chroma subsampling affects size and position of the pattern block on chroma planes. Px and py parameters need to be different. The only way you get the same size and position for the pattern block on all the planes is when there’s no chroma subsampling: 4:4:4

So, if your video uses chroma subsampling, to use fft3dfilter with the “noise pattern method” (pshow, pfactor et al) working correctly in any version of the filter, you need to process every plane individually, taking care of the different px and py values. Additionally, by processing the planes individually, you can use different sigma(s) values for each plane!

[Myrsloik]

I can process every plane individually using different sigmas with a new instance of the filter for every plane.

So I tested both avisynth versions: 2.1.1 and 2.4. This led me to understand a problem present in every version of the fft3dfilter, v2.1.1 and 2.4 for avisynth and your test #3 for vapoursynth: Chroma subsampling affects size and position of the pattern block on chroma planes. Px and py parameters need to be different. The only way you get the same size and position for the pattern block on all the planes is when there’s no chroma subsampling: 4:4:4

So, if your video uses chroma subsampling, to use fft3dfilter with the “noise pattern method” (pshow, pfactor et al) working correctly in any version of the filter, you need to process every plane individually, taking care of the different px and py values. Additionally, by processing the planes individually, you can use different sigma(s) values for each plane!

Hmm... will have to ponder how to best solve that. Internally the filter more or less creates one instance per plane and processes things in series so simply one instance/plane doesn't make things worse, just a bit awkward. I'll experiment with subsampling adjustment I guess. Btw, does anyone know why it shits all over the image data instead of just drawing a simple box around the block being used? Just looks ugly...

[VS_Fan]

Questions remaining:

Are these values, printed by pshow=True, the corresponding sigmas for each plane?
Is the pattern analyzed and constructed only for the frame selected with pframe parameter?

[Myrsloik]

Questions remaining:

Are these values, printed by pshow=True, the corresponding sigmas for each plane?
Is the pattern analyzed and constructed only for the frame selected with pframe parameter?


Yes, the sigmas printed should be for each plane that's processed.

Yes, it only uses the block in pframe. I guess pshow shows the current frame block's sigma to make determining the pframe argument faster.

It almost feels lile the sigma and pframe stuff would do better split out as a separate function. Somehow. Not sure.

[Q3CPMA]

Hello, I'm having troubles compiling this one, any idea about the reason? Here's the original issue https://github.com/4re/vapoursynth-portage/issues/71, by the way.

Here's the build log

meson --buildtype plain --libdir lib64 --localstatedir /var/lib --prefix /usr --sysconfdir /etc --wrap-mode nodownload /tmp/portage/media-plugins/vapoursynth-fft3dfilter-0.20180118/work/vapoursynth-fft3dfilter-0.20180118 /tmp/portage/media-plugins/vapoursynth-fft3dfilter-0.20180118/work/vapoursynth-fft3dfilter-0.20180118-build
The Meson build system
Version: 0.43.0
Source dir: /tmp/portage/media-plugins/vapoursynth-fft3dfilter-0.20180118/work/vapoursynth-fft3dfilter-0.20180118
Build dir: /tmp/portage/media-plugins/vapoursynth-fft3dfilter-0.20180118/work/vapoursynth-fft3dfilter-0.20180118-build
Build type: native build
Project name: FFT3DFilter
Native C++ compiler: x86_64-pc-linux-gnu-g++ (gcc 6.4.0)
Appending CXXFLAGS from environment: '-O3 -march=native -pipe'
Appending LDFLAGS from environment: '-Wl,-O1 -Wl,--as-needed'
Build machine cpu family: x86_64
Build machine cpu: x86_64
Found pkg-config: /usr/bin/x86_64-pc-linux-gnu-pkg-config (0.29.2)
Native dependency vapoursynth found: YES 42
Native dependency fftw3f_threads found: YES 3.3.6-pl2
Build targets in project: 1
Found ninja-1.8.2 at /usr/bin/ninja
>>> Source configured.
>>> Compiling source in /tmp/portage/media-plugins/vapoursynth-fft3dfilter-0.20180118/work/vapoursynth-fft3dfilter-0.20180118 ...
ninja -v -j8 -l8 -C /tmp/portage/media-plugins/vapoursynth-fft3dfilter-0.20180118/work/vapoursynth-fft3dfilter-0.20180118-build
ninja: Entering directory `/tmp/portage/media-plugins/vapoursynth-fft3dfilter-0.20180118/work/vapoursynth-fft3dfilter-0.20180118-build'
[1/4] x86_64-pc-linux-gnu-g++ -Ifft3dfilter@sha -I. -I../vapoursynth-fft3dfilter-0.20180118 -I/usr/include/vapoursynth -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c++1z -O3 -march=native -fPIC -MMD -MQ 'fft3dfilter@sha/Plugin.cpp.o' -MF 'fft3dfilter@sha/Plugin.cpp.o.d' -o 'fft3dfilter@sha/Plugin.cpp.o' -c ../vapoursynth-fft3dfilter-0.20180118/Plugin.cpp
[2/4] x86_64-pc-linux-gnu-g++ -Ifft3dfilter@sha -I. -I../vapoursynth-fft3dfilter-0.20180118 -I/usr/include/vapoursynth -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c++1z -O3 -march=native -fPIC -MMD -MQ 'fft3dfilter@sha/FFT3DFilter.cpp.o' -MF 'fft3dfilter@sha/FFT3DFilter.cpp.o.d' -o 'fft3dfilter@sha/FFT3DFilter.cpp.o' -c ../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp
FAILED: fft3dfilter@sha/FFT3DFilter.cpp.o
x86_64-pc-linux-gnu-g++ -Ifft3dfilter@sha -I. -I../vapoursynth-fft3dfilter-0.20180118 -I/usr/include/vapoursynth -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c++1z -O3 -march=native -fPIC -MMD -MQ 'fft3dfilter@sha/FFT3DFilter.cpp.o' -MF 'fft3dfilter@sha/FFT3DFilter.cpp.o.d' -o 'fft3dfilter@sha/FFT3DFilter.cpp.o' -c ../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp: In member function ‘void FFT3DFilter::DecodeOverlapPlane(const float*, float, T*, int, int, int)’:
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:880:20: error: expected ‘(’ before ‘constexpr’
if constexpr (std::is_integral<T>::value)
^~~~~~~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:882:17: error: ‘else’ without a previous ‘if’
else
^~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:891:24: error: expected ‘(’ before ‘constexpr’
if constexpr (std::is_integral<T>::value)
^~~~~~~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:893:21: error: ‘else’ without a previous ‘if’
else
^~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:900:24: error: expected ‘(’ before ‘constexpr’
if constexpr (std::is_integral<T>::value)
^~~~~~~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:902:21: error: ‘else’ without a previous ‘if’
else
^~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:910:20: error: expected ‘(’ before ‘constexpr’
if constexpr (std::is_integral<T>::value)
^~~~~~~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:912:17: error: ‘else’ without a previous ‘if’
else
^~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:933:20: error: expected ‘(’ before ‘constexpr’
if constexpr (std::is_integral<T>::value)
^~~~~~~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:935:17: error: ‘else’ without a previous ‘if’
else
^~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:944:24: error: expected ‘(’ before ‘constexpr’
if constexpr (std::is_integral<T>::value)
^~~~~~~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:947:21: error: ‘else’ without a previous ‘if’
else
^~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:955:24: error: expected ‘(’ before ‘constexpr’
if constexpr (std::is_integral<T>::value)
^~~~~~~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:957:21: error: ‘else’ without a previous ‘if’
else
^~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:965:20: error: expected ‘(’ before ‘constexpr’
if constexpr (std::is_integral<T>::value)
^~~~~~~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:967:17: error: ‘else’ without a previous ‘if’
else
^~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:981:20: error: expected ‘(’ before ‘constexpr’
if constexpr (std::is_integral<T>::value)
^~~~~~~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:983:17: error: ‘else’ without a previous ‘if’
else
^~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:992:24: error: expected ‘(’ before ‘constexpr’
if constexpr (std::is_integral<T>::value)
^~~~~~~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:994:21: error: ‘else’ without a previous ‘if’
else
^~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:1001:24: error: expected ‘(’ before ‘constexpr’
if constexpr (std::is_integral<T>::value)
^~~~~~~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:1003:21: error: ‘else’ without a previous ‘if’
else
^~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:1011:20: error: expected ‘(’ before ‘constexpr’
if constexpr (std::is_integral<T>::value)
^~~~~~~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:1013:17: error: ‘else’ without a previous ‘if’
else
^~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:1030:20: error: expected ‘(’ before ‘constexpr’
if constexpr (std::is_integral<T>::value)
^~~~~~~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:1032:17: error: ‘else’ without a previous ‘if’
else
^~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:1041:24: error: expected ‘(’ before ‘constexpr’
if constexpr (std::is_integral<T>::value)
^~~~~~~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:1043:21: error: ‘else’ without a previous ‘if’
else
^~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:1050:24: error: expected ‘(’ before ‘constexpr’
if constexpr (std::is_integral<T>::value)
^~~~~~~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:1052:21: error: ‘else’ without a previous ‘if’
else
^~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:1060:20: error: expected ‘(’ before ‘constexpr’
if constexpr (std::is_integral<T>::value)
^~~~~~~~~
../vapoursynth-fft3dfilter-0.20180118/FFT3DFilter.cpp:1062:17: error: ‘else’ without a previous ‘if’
else
^~~~
[3/4] x86_64-pc-linux-gnu-g++ -Ifft3dfilter@sha -I. -I../vapoursynth-fft3dfilter-0.20180118 -I/usr/include/vapoursynth -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c++1z -O3 -march=native -fPIC -MMD -MQ 'fft3dfilter@sha/fft3dfilter_c.cpp.o' -MF 'fft3dfilter@sha/fft3dfilter_c.cpp.o.d' -o 'fft3dfilter@sha/fft3dfilter_c.cpp.o' -c ../vapoursynth-fft3dfilter-0.20180118/fft3dfilter_c.cpp
ninja: build stopped: subcommand failed.


This is with GCC 6.4.0, so the lack of C++17 support might be the culprit.

[Myrsloik]

Your compiler only pretends to know c++17. It's too old gcc.

[Q3CPMA]

Well, thanks, the ebuild is bad then.

[Myrsloik]

I've added the only improvements I can think of and what I currently consider to be bugs. Would be nice if someone helped with updating the documentation too. I'll only do the enhancement marked items if there's demand for it.

https://github.com/myrsloik/VapourSynth-FFT3DFilter/issues

[lansing]

I'm trying to apply the filter on an png image, and it turned the image into large pixels.


img = core.imwrif.Read(r'001.png')
img = core.fft3dfilter.FFT3DFilter(img, sigma=1)

[Selur]

@lansing: works fine here when loading an image sequence:
# Imports
import vapoursynth as vs
core = vs.get_core()
import ctypes
# Loading Support Files
Dllref = ctypes.windll.LoadLibrary("G:/Hybrid/64bit/vsfilters/Support/libfftw3f-3.dll")
# Loading Plugins
core.std.LoadPlugin(path="G:/Hybrid/64bit/vsfilters/DenoiseFilter/FFT3DFilter/vsfft3dfilter.dll")
core.std.LoadPlugin(path="G:/Hybrid/64bit/vsfilters/SourceFilter/Imagemagick/libimwri.dll")
# Loading H:\sequence\ED-360-png\%05d.png using vsImageReader
clip = core.imwri.Read("H:/sequence/ED-360-png/%05d.png", firstnum=1)
clip = core.std.Trim(clip=clip, length=15691)
# making sure frame rate is set to 25
clip = core.std.AssumeFPS(clip, fpsnum=25, fpsden=1)
# Making sure input color range is set to PC (full) range.
clip = core.std.SetFrameProp(clip=clip, prop="_ColorRange", intval=0)
# denoising using FFT3DFilter
clip = core.fft3dfilter.FFT3DFilter(clip=clip, sigma=1.00)
# adjusting output color from: RGB24 to YUV420P10 for x265Model (i420)
clip = core.resize.Bicubic(clip=clip, format=vs.YUV420P10, matrix_s="470bg")
# Output
clip.set_output()
and when loading a single image:
# Imports
import vapoursynth as vs
core = vs.get_core()
import ctypes
# Loading Support Files
Dllref = ctypes.windll.LoadLibrary("G:/Hybrid/64bit/vsfilters/Support/libfftw3f-3.dll")
# Loading Plugins
core.std.LoadPlugin(path="G:/Hybrid/64bit/vsfilters/DenoiseFilter/FFT3DFilter/vsfft3dfilter.dll")
core.std.LoadPlugin(path="G:/Hybrid/64bit/vsfilters/SourceFilter/Imagemagick/libimwri.dll")
# Loading H:\sequence\ED-360-png\%05d.png using vsImageReader
clip = core.imwri.Read("H:/sequence/ED-360-png/00001.png", firstnum=1)
# denoising using FFT3DFilter
clip = core.fft3dfilter.FFT3DFilter(clip=clip, sigma=1.00)
# adjusting output color from: RGB24 to YUV420P10 for x265Model (i420)
clip = core.resize.Bicubic(clip=clip, format=vs.YUV420P10, matrix_s="470bg")
# Output
clip.set_output()

Cu Selur

Ps.: I use the portable version which is why I need to load the libraries manually.

[Myrsloik]

You don't need to load it manually. Just put it all in the plugins64 subdir.

[Selur]

You are right, but since I like to keep stuff in separate sub folders that wouldn't work. :) (not complaining, since I usually generate most of the scripts I use, I don't really care much about the explicit loading and even prefer it since for me it seems 'cleaner' :))

[lansing]

My image format are rgbs, it works when I convert them to rgb24.


img = core.imwrif.Read(r'001.png')
img = core.resize.Bicubic(img, format=vs.RGB24)
img = core.fft3dfilter.FFT3DFilter(img, sigma=1)

[Myrsloik]

My image format are rgbs, it works when I convert them to rgb24.


img = core.imwrif.Read(r'001.png')
img = core.resize.Bicubic(img, format=vs.RGB24)
img = core.fft3dfilter.FFT3DFilter(img, sigma=1)

There's no argument scaling (like most vs filters), so probably you need to use a small sigma like 1/256 for similar effects.

[ChaosKing]

Ps.: I use the portable version which is why I need to load the libraries manually.
I never had to load the libraries manually in my portable version. just use the default folder structure vapoursynth64\plugins (vspipe is in the same folder as vapoursynth64)

[tuanden0]

Could you correct me if I wrong?
planes=0: Y
planes=1: U
planes=2: V

[Myrsloik]

Could you correct me if I wrong?
planes=0: Y
planes=1: U
planes=2: V

No correction needed

[KingLir]

May I ask if anyone can help with building on macOS 10.13 ?

I have install successfully, using brew, both vapoursynth and fftw --enable threads, but it fails on fftw3f_threads ....

The Meson build system
Version: 0.48.0
Source dir: /Projects/VapourSynth-FFT3DFilter
Build dir: /Projects/VapourSynth-FFT3DFilter/build
Build type: native build
Project name: FFT3DFilter
Project version: 1
Native C++ compiler: ccache c++ (clang 10.0.0 "Apple LLVM version 10.0.0 (clang-1000.11.45.2)")
Build machine cpu family: x86_64
Build machine cpu: x86_64
Found pkg-config: /usr/local/bin/pkg-config (0.29.2)
Dependency vapoursynth found: YES 44
Dependency fftw3f_threads found: NO (tried pkgconfig and framework)

meson.build:11:0: ERROR: Dependency "fftw3f_threads" not found, tried pkgconfig and framework

If I just remove from meson the fftw3f_threads dependency it runs OK but when I build (ninja), I get:

FFT3DFilter::FFT3DFilter(float, float, int, int, int, int, int, int, float, float, float, float, float, float, bool, bool, int, int, int, int, bool, float, float, float, float, float, float, float, float, float, int, VSVideoInfo, VSNodeRef*) in FFT3DFilter.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.

[Are_]

Dont' mess up with the build script, the problem is in your system. Your fftw compilation is miss-configured, as the build script alerts you, you didn't build fftw3f_threads.
Or can you check if you really have fftw3f_threads .so (or whatever is the extension in mac for a dynamic library) somewhere in your path?

[KingLir]

I have libfftw3f_threads.dylib in my path and still the same error.
I tried changing the file name to fftw3f_threads.dylib - but no luck.

Anyone have an idea what to do on macOS ?

[KingLir]

The build script is updated and the issue should be fixed now.

Thanks!! Works like a charm.

[zorr]

My tests (https://forum.doom9.org/showthread.php?p=1867223#post1867223) indicate that larger overlap results in better quality when denoising. Currently the maximum overlap that can be used is blocksize / 2. Is there a limitation in the algorithm that prevents using larger ones or why is it not allowed? It would be interesting to see if even larger overlap helps with the quality.

Also best results were obtained with the largest allowed bt=5. Adding support for even larger would also be helpful, but I do realize it takes more work.