FFT3DFilter 2.6

[MeteorRain]

I shot a quick email to the original author and see if I can get something.

I finished organizing all Apply*3D*() family and all their SSE2 counterparts. bt=5 shows a significant speed improvement (85539ms -> 13925ms for a short clip). Might start working on AVX part later.

Hopefully I can get an answer soon.

[pinterf]

Nice. You can check VapourSynth solution, there had been a refactor as well.
https://forum.doom9.org/showthread.php?t=175199

[MeteorRain]

Thanks! That's ... a lot of diversity in this community.

Hopefully I will finish it with most of the fixes in the other repo and make it a dual interface.

[Myrsloik]

Originally Posted by MeteorRain

Thanks! That's ... a lot of diversity in this community.

Hopefully I will finish it with most of the fixes in the other repo and make it a dual interface.

Insanity! The Avisynth developer code dictates that you must create yet another incompatible fork!

[MeteorRain]

Hi,

It seems, that Sharpen_C code is correct, but

pair of brackets are missed in ApplyWiener2D_C code for non-zero both
sharpen and dehalo.

It is a bug.

So as I expected. Will include that fix also.

[MeteorRain]

(pfactor=1.0, bt=0) seems to be broken. Can you confirm if that's broken on your side?

[MeteorRain]

https://github.com/pinterf/fft3dfilt...lter.cpp#L2811

Is coverpitch * pixelsize supposed to be coverpitch?

[pinterf]

Originally Posted by MeteorRain

https://github.com/pinterf/fft3dfilt...lter.cpp#L2811

Is coverpitch * pixelsize supposed to be coverpitch?

Yes, it worked only for 8 bits! Seems I have not tested all parameter and bit depth combinations.

[pinterf]

(In general) When you make filters that work for both VS and AVS, parameter handling is different when applied on different bit depth.
Conventionally VS filters require to scale parameters to the appropriate bit-depth at the scripting side. In my AVS filters the same parameter magnitudes will work similarly for all bit depths. E.g. sigmas, smin, smax.

[MeteorRain]

Yea I saw that when I refactor those part.

Now I can almost ensure it's very bit identical to the before-refactoring, except for some minor difference (such as different order of float additions and subtractions). Moving from ancient C++ to modern C++ really gives a fresh breeze. I have wiped the original caching system and made a LRU template caching, and refactor bt 2..5 into a single block. Should be much easier to maintain now. Duplicate code in Apply family are all eliminated with a more functional programming structure (lambda callback). This is the first time I'm writing C++ code in Ruby style, so will see how it goes.

Next step is to finish the AVS+VS dual interface, then I'll move back to LSMASH-Works Linux porting work, and hopefully I can get it up and running on Debian very soon.

[real.finder]

maybe parameters scale parameter like paramscale in MaskTools2 will be a good idea, with "none" by Default in vs and Default "i8" in avs

[MeteorRain]

I think the rule of thumb is -- the same clip in different depth with the same parameters should behave similarly.

[real.finder]

Originally Posted by MeteorRain

I think the rule of thumb is -- the same clip in different depth with the same parameters should behave similarly.

I think that too, but it's too late for vs (or all vs scripts must update for that)

so paramscale will be balanced solution for both, and it's also useful in debugging

also sigmas, smin, smax etc... should be float parameter instead of int (if it not float already) and if the old filter/plugin parameter was int, then it better to have dual filter signatures

[MeteorRain]

Since this refactor is going to be a big change, I'm going to ignore full compatibility and try to do things right (at least right according to my mind).

That includes removing of plane / multiplane parameter and use the easier [y/u/v]=[3/2/1] convention, removing YUY2 colorspace support, and a few fixes that might not give bit identical result. I also plan to add a set of window parameters according to my personal need, so only pixels inside window is processed.

[pinterf]

Forget dual filter signatures please, it's a hack, separate the filter dlls properly, it is just conservating the disorder we see sometimes posted as heap of dlls from the last century.

[real.finder]

Originally Posted by MeteorRain

Since this refactor is going to be a big change, I'm going to ignore full compatibility and try to do things right (at least right according to my mind).

That includes removing of plane / multiplane parameter and use the easier [y/u/v]=[3/2/1] convention, removing YUY2 colorspace support, and a few fixes that might not give bit identical result. I also plan to add a set of window parameters according to my personal need, so only pixels inside window is processed.

Originally Posted by pinterf

Forget dual filter signatures please, it's a hack, separate the filter dlls properly, it is just conservating the disorder we see sometimes posted as heap of dlls from the last century.

then in these cases, function name should be changed, FFT3DFilter2 or Neo_FFT3DFilter

[pinterf]

Yes, if there would be way too different parameters and behaviour then a name separation would help. Like masktools(2), mvtools(2)

[MeteorRain]

I already changed it to Neo_FFT3D since I forgot to mention that. The original filter was written in 2004/2005 where WinXP and YUY2 were mainstream support. I think now it's a good time to move on. Although there are incompatibilities, it's still pretty easy to move to the new filter with minor changes to scripts.

[FranceBB]

Originally Posted by MeteorRain

I already changed it to Neo_FFT3D since I forgot to mention that. The original filter was written in 2004/2005 where WinXP and YUY2 were mainstream support. I think now it's a good time to move on. Although there are incompatibilities, it's still pretty easy to move to the new filter with minor changes to scripts.

I just popped up out of nowhere to say that although nobody uses 8bit 4:2:2 interleave (YUY2) now (since Avisynth has been having yv16 support for years) and I'm totally in favor of removing it if it's an hassle to support, but the same isn't true for XP as there are still people using XP, so unless it's impossible, I would beg you to keep XP support in the new Neo_FFT3DFilter as well.

[StainlessS]

I would beg you to keep XP support in the new Neo_FFT3DFilter as well.

+1 on that.