FFT3DFilter 2.6

[pinterf]

Big thanks to martin53 who woke up first an made and update to this plugin recently.

EDIT:
Get latest version from https://github.com/pinterf/fft3dfilter/releases

Then I checked what the source looked like from inside, put it on git, modified one or two things and now it's ready for experimenting.

Experimental.
x86/x64 versions and XP support (I hope)

apply current avs+ headers
10-16 bits and 32 bit float colorspace support in AVS+
Planar RGB support
look for libfftw3f-3.dll first, then fftw3.dll
inline asm ignored on x64 builds
pre-check: if plane to process for greyscale is U and/or V then returns original clip
auto registers MT mode for avs+: MT_SERIALIZED
autoscale sigma and smin/smax parameter from 8 bit scale if colorspace is different


I need help what parameters are affected when bit depth changes. Now I autoscale all the sigma parameters, smin and smax.

Compiled with VS2015

[Groucho2004]

I checked XP support, works fine (x86/x64). By the way, remove the 3DNow code, I'm pretty sure nobody uses this plugin who doesn't have a CPU that supports at least SSE (not even Manolito :D).

[real.finder]

we all love you pinterf, you are our hero :)

[pinterf]

I checked XP support, works fine (x86/x64). By the way, remove the 3DNow code, I'm pretty sure nobody uses this plugin who doesn't have a CPU that supports at least SSE (not even Manolito :D).
I left there four of them. Two had no sse replacement, only c. They'll be kept only until I check them what they are doing and move them to simd intrinsics.

[FranceBB]

Really really appreciated! Big thanks! :D

[tuanden0]

Can't wait to test, thank you pinterf.

[pinterf]

I left there four of them. Two had no sse replacement, only c. They'll be kept only until I check them what they are doing and move them to simd intrinsics.
Converted one of the inline asm function to simd, and yes, worth doing it.
For a simple FFT3DFilter(sigma=3,plane=4)
v2.3 (x86): 10.4 fps (VS2015, inline asm, speed is same as simd) - for comparison
v2.2 (x64): 9.27 fps (ICL build, C)
v2.3 (x64): 9.15 fps (VS2015, C)
test (x64): 11.94 fps (VS2015, simd intrinsics)

[vcmohan]

In short will it be possible to indicate what this filter does? Excepting that it does a 3D FFT I could not infer anything else.

[Groucho2004]

In short will it be possible to indicate what this filter does? Excepting that it does a 3D FFT I could not infer anything else.
Documentation is here (http://avisynth.org.ru/fft3dfilter/fft3dfilter.html).

[pinterf]

New build

Download FFT3DFilter 2.4 (https://github.com/pinterf/fft3dfilter/releases/tag/v2.4)

Some efforts on x64 and Avs+ MT auto-registration changes


FFT3DFilter v2.4 (20170608)
- some inline asm (not all) ported to simd intrisics, helps speedup x64 mode, but some of them faster also on x86.
- intrinsics bt=0
- intrinsics bt=2, degrid=0, pfactor=0
- intrinsics bt=3 sharpen=0/1 dehalo=0/1
- intrinsics bt=3
- Adaptive MT settings for Avisynth+: MT_SERIALIZED for bt==0 (temporal), MT_MULTI_INSTANCE for others
- Copy Alpha plane if exists
- reentrancy checks against bad multithreading usage
Note: for properly operating in MT_SERIALIZED mode in Avisynth+ MT, please use Avs+ r2504 or better.

FFT3DFilter v2.3 (20170221)
- apply current avs+ headers
- 10-16 bits and 32 bit float colorspace support in AVS+
- Planar RGB support
- look for libfftw3f-3.dll first, then fftw3.dll
- inline asm ignored on x64 builds
- pre-check: if plane to process for greyscale is U and/or V return original clip

[stax76]

Could FFT3DFilter filter load the required DLLs if they are not yet loaded and are located in the same folder then FFT3DFilter?

I have the DLLs in the same folder then FFT3DFilter and manually load FFT3DFilter with LoadPlugin, I get the following error:

FFT3DFilter: libfftw3f-3.dll or fftw3.dll not found. Please put in PATH or use LoadDll() plugin

For some tools I just detect issues and show a warning with instruction what to do, if possible I prefer to integrate things in a way that just works without the user having to do something.

[stax76]

I found a plugin called 'LoadDll' which I could use but is there a x64 version?

[raffriff42]

Could FFT3DFilter filter load the required DLLs if they are not yet loaded and are located in the same folder then FFT3DFilter?The DLLs would have to be in the current working directory (which can be set with SetWorkingDir (http://avisynth.nl/index.php/Internal_functions#SetWorkingDir)), on the Path, or in an explicit, specified folder.

(don't know about LoadDll, but I suppose it has the same requirement)

[stax76]

The DLLs would have to be in the current working directory (which can be set with SetWorkingDir (http://avisynth.nl/index.php/Internal_functions#SetWorkingDir)), on the Path, or in an explicit, specified folder.

(don't know about LoadDll, but I suppose it has the same requirement)

This could only work when staxrip loads the script but not x264, I try to make a installer with inno or just run xcopy.

[raffriff42]

Inno (http://www.jrsoftware.org/isdl.php#qsp) supports copying your DLLS to the System directory, which of course is on the Path. Job done.

[stax76]

Inno supports copying your DLLS to the System directory, which of course is on the Path. Job done.

Problem is I'm clueless about inno (just gave up) and I'm apparently not the only one here. :D

Using xcopy now!

[raffriff42]

Try the starter pack (http://www.jrsoftware.org/isdl.php#qsp) and take the optional Inno Studio.

EDIT here's a screenshot - a file to be copied to the 32-bit System directory (click to enlarge)

https://www.dropbox.com/s/j9cml1xnh55h71r/InnoSetup-files-3s.jpg?raw=1 (https://www.dropbox.com/s/sxbgv8zh4ixtw88/InnoSetup-files-3.png?raw=1)

[stax76]

Does that use 'Inno Setup Compiler', I have v5.5.6 installed to use for my custom avs setup, doesn't support High DPI. :(

[stax76]

I have it working, thanks for the screenshot, that has helped. One thing I don't like is the installer is 0.5 MB larger compared to packed with 7zip, this would probably increase my package with 0.5 MB, it's already about 100 MB and I'm very concerned about file size because of the the hoster and users with low bandwidth.

[Groucho2004]

I found a plugin called 'LoadDll' which I could use but is there a x64 version?
I just made a 64 bit version but I can't test it right now. See if it works:
LoadDLL64 (https://www.dropbox.com/s/8wj7ph7mq78c392/LoadDLL64.7z?dl=0)

[stax76]

Thanks, I need automatic loading though for my use case, anything else is suboptimal, now it does xcopy the files to the sys dir which in my opinion is bad practice. I can make a request at pinterf's FFT3DFilter github tracker asking if FFT3DFilter could load the DLLs if they are located in the same dir then FFT3DFilter.

[Groucho2004]

I can make a request at pinterf's FFT3DFilter github tracker asking if FFT3DFilter could load the DLLs if they are located in the same dir then FFT3DFilter.
Not a bad idea. This is pretty easy - Get the full path to fft3dfilter with GetCurrentDirectory() and use a loadlibrary() call with the full path in addition to just "LoadLibrary("libfftw3f-3.dll")".

[Myrsloik]

Not a bad idea. This is pretty easy - Get the full path to fft3dfilter with GetCurrentDirectory() and use a loadlibrary() call with the full path in addition to just "LoadLibrary("libfftw3f-3.dll")".

The proper solution is to use LoadLibraryEx() and altered search paths.

[Groucho2004]

The proper solution is to use LoadLibraryEx() and altered search paths.Sure. I just have some vague memory about a problem with the LOAD_WITH_ALTERED_SEARCH_PATH flag and WinXP but this goes way back and possibly applied to WinXP pre-SP3.

[TheFluff]

Thanks, I need automatic loading though for my use case, anything else is suboptimal, now it does xcopy the files to the sys dir which in my opinion is bad practice. I can make a request at pinterf's FFT3DFilter github tracker asking if FFT3DFilter could load the DLLs if they are located in the same dir then FFT3DFilter.

Fix the underlying problem instead. Avs+ actually already does a half-hearted attempt at fixing the issue (plugins depending on other DLL's not finding their dependencies) by temporarily setting the process-wide DLL search directory (https://msdn.microsoft.com/en-us/library/windows/desktop/ms686203(v=vs.85).aspx) to the folder it is loading the plugin from, when it does the actual loading. That doesn't help in this case though because FFT3DFilter doesn't actually load its dependency when the DLL itself is loaded, it loads it every time the filter is instantiated (which is really weird and I don't understand why). That's the core issue.

Replacing the Avs+ LoadLibrary call (https://github.com/pinterf/AviSynthPlus/blob/2d3cb6c011f520fc9433d6bff61a6d697cb09ecb/avs_core/core/PluginManager.cpp#L514) with LoadLibraryEx using LOAD_WITH_ALTERED_SEARCH_PATH might fix the problem without the silly process-wide loading directory juggling if the search order stuff persists for the loaded DLL after LoadLibrary returns, but I have no idea if that is the case. I think I would expect that it doesn't, but I haven't found a satisfactory answer. For whatever reason, VS went with LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR instead.

Not a bad idea. This is pretty easy - Get the full path to fft3dfilter with GetCurrentDirectory() and use a loadlibrary() call with the full path in addition to just "LoadLibrary("libfftw3f-3.dll")".
There's nothing that says the current directory is the plugins folder. You can actually get a DLL's own path though using some other mildly exotic win32 API gymnastics (I resorted to it in assrender once upon a time) but it's silly. Don't do that, fix the loading side instead.

[Groucho2004]

There's nothing that says the current directory is the plugins folder.You're right, brain fart.

This would work to get the fully qualified path to the plugin when called from the plugin (I assume that's what you meant by "You can actually get a DLL's own path though using some other mildly exotic win32 API gymnastics"):

HMODULE GetCurrentModule()
{
HMODULE hModule = NULL;
GetModuleHandleEx(
GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS | GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT,
(LPCTSTR)GetCurrentModule,
&hModule);

return hModule;
}

HMODULE hm = GetCurrentModule();
char szPath[MAX_PATH + 1];
GetModuleFileName(hm, szPath, MAX_PATH);
Note: No error handling whatsoever in this code ;-)

[stax76]

@TheFluff

Not only staxrip loads avs but also the encoders, it might be possible to configure the encoder process, setting working dir or path variable but this would be a great ugly mess I believe, doesn't feel right, I would even consider to examine it.

[TheFluff]

You're right, brain fart.

This would work to get the fully qualified path to the plugin when called from the plugin (I assume that's what you meant by "You can actually get a DLL's own path though using some other mildly exotic win32 API gymnastics"):

Yes that is what I meant and that looks like it could work. When I did it I added a DllMain entry point (Avisynth plugins don't normally have one because it's not needed, but if it exists it'll get called) for the sole purpose of getting the system to pass me a HINSTANCE (= HMODULE) referring to the DLL itself as its first parameter, which I then passed directly to GetModuleFileName. Whatever works. There are probably more clever ways to do it.

@TheFluff

Not only staxrip loads avs but also the encoders, it might be possible to configure the encoder process, setting working dir or path variable but this would be a great ugly mess I believe, doesn't feel right, I would even consider to examine it.

Yes that's what I'm saying, it should be fixed in Avisynth itself. No point in trying to work around it on the client side.

[Groucho2004]

Yes that is what I meant and that looks like it could work.It does work, I tested it.

it should be fixed in Avisynth itself. No point in trying to work around it on the client side.Yes, that makes sense.

[pinterf]

New build
Download FFT3DFilter 2.5 (https://github.com/pinterf/fft3dfilter/releases/tag/v2.5)

Change log
FFT3DFilter v2.5 (20180702)
- 32bit Float YUV: Chroma center to 0.0 instead of 0.5, to match new Avisynth+ r2728-

FFT3DFilter v2.4 (20170608)
- some inline asm (not all) ported to simd intrisics, helps speedup x64 mode, but some of them faster also on x86.
- intrinsics bt=0
- intrinsics bt=2, degrid=0, pfactor=0
- intrinsics bt=3 sharpen=0/1 dehalo=0/1
- intrinsics bt=3
- Adaptive MT settings for Avisynth+: MT_SERIALIZED for bt==0 (temporal), MT_MULTI_INSTANCE for others
- Copy Alpha plane if exists
- reentrancy checks against bad multithreading usage
Note: for properly operating in MT_SERIALIZED mode in Avisynth MT, please use Avs+ r2504 or better.

FFT3DFilter v2.3 (20170221)
- apply current avs+ headers
- 10-16 bits and 32 bit float colorspace support in AVS+
- Planar RGB support
- look for libfftw3f-3.dll first, then fftw3.dll
- inline asm ignored on x64 builds
- pre-check: if plane to process for greyscale is U and/or V return original clip
- auto register MT mode for avs+: MT_SERIALIZED

Previous versions by Fizick and martin53

[FranceBB]

Thank you for this update as well. ^_^

[Zetti]

sharpen - sharpening strength (default=0 - not sharpen)
good values about 0.3 to 1.0 (negative values results in reverse effect)
Is value 1.0 the highest or can it be set higher??

[StainlessS]

Is value 1.0 the highest or can it be set higher??

Perhaps you could try that yourself, and tell us all the result {In ordinary Sharpen(), 1.0 is [I think] the max}.

EDIT: You dont need to bother Pinterf with questions that you could easily verify yourself,
P's time is way more valuable than yours :)

[Wilbert]

Perhaps you could try that yourself, and tell us all the result {In ordinary Sharpen(), 1.0 is [I think] the max}.

EDIT: You dont need to bother Pinterf with questions that you could easily verify yourself,
P's time is way more valuable than yours :)
Please don't tell people what they are allowed to ask or not.

[Kurogane]

In the end how to load libfftw3f-3.dll?

How to install LoadDll?

[Zetti]

A posible problem with fft3dfilter and fftw lib:

https://forum.doom9.org/showthread.php?p=1856944#post1856944

[pinterf]

Perhaps alignment problems. Plus I would check if vzeroupper is properly issued before returning, it won't crash but is performance penalty when returning to an sse2 world. I'll check it.

[Groucho2004]

A posible problem with fft3dfilter and fftw lib:

https://forum.doom9.org/showthread.php?p=1856944#post1856944

I built FFTW with GCC 8.2 and it works fine with fft3dfilter. There are a number of guidelines here (http://www.fftw.org/install/windows.html) about building fftw with MingW (gcc).

For example:
--with-incoming-stack-boundary=2: compile FFTW assuming a 4-byte alignment. On win32, some versions of gcc assume that the stack is 16-byte aligned, but code compiled with other compilers may only guarantee a 4-byte alignment, resulting in mysterious segfaults.

[pinterf]

Checked, no problem on fft3dfilter side, allocations use fftw's own malloc, so this is o.k. Fftw is also checking the alignment and won't use simd code if the alignment is not sufficient.

[tormento]

@pinterf would you try to resurrect a new version of FFT3DGPU?

[pinterf]

@pinterf would you try to resurrect a new version of FFT3DGPU?
The source is not complete.
filtersps.h, filtersps.cpp, dxinput.h, dxinput.cpp is missing.

This is what I found:
Forum: https://forum.doom9.org/showthread.php?t=89941

Known sources of the plugin:

x86:
http://www.avisynth.nl/index.php/External_filters#Spatio-Temporal_Denoisers
http://www.avisynth.nl/users/tsp/fft3dgpu0.8.2.exe
http://avisynth.nl/users/tsp/fft3dgpu0.8.2.7z

And the latest one:
This one is non-existant (it is said to have the missing 4 files: filtersps.h, filtersps.cpp, dxinput.h, dxinput.cpp), tsp provided them (https://forum.doom9.org/showthread.php?p=1102862#post1102862) in an updated version:
http://www.avisynth.org/tsp/fft3dgpu0.8.2a.exe
but it disappeared from the site since then.

x64: (binary only, dll and hlsl)
http://avisynth.nl/index.php/AviSynth%2B_x64_plugins
https://www.mediafire.com/download/2chnt1jkwwm/FFT3DGPU_3-15-2010.rar
Comment:
The HLSL (shader program) file is edited from the original to adhere to pixel shader 3.0 syntax rules.
Please make sure to place the correct file in the same directory as the 64bit plugin. Compiled by Joshy D.

[tormento]

The source is not complete.
filtersps.h, filtersps.cpp, dxinput.h, dxinput.cpp is missing.
:(

In the mean time I have found the x64 you were quoting.

Lot of limitations with Prefetch, works with mode 3 only. Computer interface barely usable when running. Video memory, full all the time.

Anyway, that's it.

[tormento]

The source is not complete.
filtersps.h, filtersps.cpp, dxinput.h, dxinput.cpp is missing.
https://forum.doom9.org/showthread.php?p=1102757#post1102757

[pinterf]

https://forum.doom9.org/showthread.php?p=1102757#post1102757
:) As I wrote the file is not found on the server.

[Reel.Deel]

:) As I wrote the file is not found on the server.

fft3dgpu0.8.2a.exe:
https://www.dropbox.com/s/b25nik2r4qkujf9/fft3dgpu0.8.2a.exe?dl=1

:)


Edit:
Hi there pinterf. Yes, I've not been on on here as I use to but I still lurk :).

[pinterf]

Somehow I knew that you - like a good museum officer - will dig it out and appear soon :), thanks.

[Taurus]

Somehow I knew that you - like a good museum officer - will dig it out and appear soon :), thanks.
Sorry, can not resist.
This gave me a good laugh,
it almost saved my day.
:thanks: Reel.Deel for sharing
and :thanks: pinterf for your humoristic thanksgiving to the digger.

[pinterf]

Download FFT3dGPU 0.8.3 - pfmod (https://github.com/pinterf/FFT3dGPU/releases/tag/0.8.3)
Semi-experimental release - nothing important has been changed in the source. This build is giving me identical results to the old v0.8.2 (x86) but who knows.

At least we have a compilable codebase again, an x64 build which is surely compatible with AVS+ x64 structures, and finally the interface version of the plugin is V6 (for Avisynth 2.6.0.5- and Avisynth+).

You can find _no_ additional colorspaces yet.

An attempt to compile FFT3dGPU under Visual Studio 2017 with current Avisynth+ headers for x86/x64.

Changelog (pinterf)

**v0.8.3 (20181118)**
- project hosted on https://github.com/pinterf/FFT3dGPU
- source and project files updated to build under Visual Studio 2017 (15.9) using DX SDK June 2010
- Moved to Avisynth Interface 6 (v2.6) - using headers from the Avisynth+ project
- added x64 platform

**v0.8.2 (x86: 2006, x64: 2010)**
- Initial source: 0.8.2

[tormento]

Lol. I got in touch just today with TSP.

@pinterf do you still need sources or you found another way?

[pinterf]

Lol. I got in touch just today with TSP.

@pinterf do you still need sources or you found another way?
I've got all I wanted, thanks.