[Neo] FFT3D / DFTTest

[MeteorRain]

I believe the change of bit depth should not change a parameter, at least in most cases.
Both vapoursynth-dfttest and dfttest scale parameters to the bit depth so it wasn't a problem.

I haven't decided what to do next, but I may start with a few. mvtools-sf is also a good candidate. Depending on my time availability.

[real.finder]

Originally Posted by MeteorRain

I believe the change of bit depth should not change a parameter, at least in most cases.
Both vapoursynth-dfttest and dfttest scale parameters to the bit depth so it wasn't a problem.

so, parameter for those now float right? (if they not already), since float more flexible, For example if the parameter 0-255 with float we can set it like 112.5 and so, but with int we have only 256 options and that not suitable for more than 8bit

I haven't decided what to do next, but I may start with a few. mvtools-sf is also a good candidate. Depending on my time availability.

since mvtools already has HBD (still there are no float motion analyzing) and it's complex maybe it's good to start with basic things that has no HBD yet in avs+ like VagueDenoiser, EEDI3 and Dither_resize16/fmtconv and then back to mvtools in the end

[MeteorRain]

Which parameters are you talking about? DFTTest has all parameters in float I believe (except for those modes, sizes and frame numbers).

And I've uploaded the release (r7).

[real.finder]

Originally Posted by MeteorRain

Which parameters are you talking about? DFTTest has all parameters in float I believe (except for those modes, sizes and frame numbers).

if they are, then no need to do anything I am just saying if any (Whether here or not)

[tormento]

Originally Posted by MeteorRain

And I've uploaded the release (r7).

I saw your readme.md is pointing to official FFTW download page.

Unfortunately they built only 3.3.5 version of dll, while there are many updated ones such as 3.3.7 or 3.3.8. The latest I can find is here and a fresh compile from you or pinterf with VS and clang (and perhaps Intel) to test would be nice.

[real.finder]

is [Neo] FFT3D / DFTTest stable yet? cuz I want to make scripts use them instead of non-neo one

also as I said in #22 more ports from VS will be nice since avs+ still need those updates for HBD, so I will make another wave of scripts updates

[MeteorRain]

Whether it is stable depends on your bug report. If you're happy about it then I think it's stable enough.

What are the things that you are looking to replace in your script from VS counterparts? Those 3 you mentioned?

[real.finder]

Originally Posted by MeteorRain

Whether it is stable depends on your bug report. If you're happy about it then I think it's stable enough.

What are the things that you are looking to replace in your script from VS counterparts? Those 3 you mentioned?

yes and along with SangNomMod those the most important for now, but there are others with kinda less important like TTempSmooth, EEDI2, TCanny (there are TCannymod by chikuzen but I think with no HBD), Yadifmod (there are Yadifmod2 by chikuzen with not completed HBD), IT, DeblockPP7

and after that maybe these VS only like Bwdif, W3FDIF, VMAF, BM3D

[StvG]

ffvideosource()
neo_ff3d() #r3 crash with no message, r1v4 is ok (x64)

[Myrsloik]

Originally Posted by MeteorRain

I believe the change of bit depth should not change a parameter, at least in most cases.
Both vapoursynth-dfttest and dfttest scale parameters to the bit depth so it wasn't a problem.

I haven't decided what to do next, but I may start with a few. mvtools-sf is also a good candidate. Depending on my time availability.

This is one of the cases where you can argue that it should change. We're dealing with transforms so there's a direct connection between input range and transformed range. Just my thoughts. I suppose scaling is easier but then a 0-255 range makes no sense. Either have a proper 0-1 float or make the int range a percentage or whatever.

Don't propagate 0-255 scaled ranges, they make me very unhappy since they make no sense AND lack fine enough steps to for higher bitdepths.

[MeteorRain]

Originally Posted by StvG

ffvideosource()
neo_ff3d() #r3 crash with no message, r1v4 is ok (x64)

Can't reproduce here.

Source file resolution? (Tested 1280x720)
Source bit depth? (Tested 8-bit)
FFMS version? (Mine stamped at 2019-8-11)
Anything that I might have missed?

[StvG]

Originally Posted by MeteorRain

Can't reproduce here.

Source file resolution? (Tested 1280x720)
Source bit depth? (Tested 8-bit)
FFMS version? (Mine stamped at 2019-8-11)
Anything that I might have missed?

Tested with 1280x720 / 1920x1080 8-bit video, blankclip(pixel_type="yv12").
Added ConvertBits(16) before neo_fft3d() doesn't change the situation.
Tested with this FFMS2, latest LSMASH.
AVSMeter - https://images2.imgbox.com/e6/ba/oz2BaBV8_o.png
AVX-512 CPU.

[MeteorRain]

Oh avx 512. Yea I don't have any testing environment. Can you try debugging it for me?

(Or I can try to use a CPU emulator or rent a server to debug it. Or I can simply remove it since it's not such a big deal to support it now.)

[MeteorRain]

Should have fixed it. The issue is more stupid than I thought.

Please try v4.

Also opt parameter is introduced so you can disable AVX512 manually.

[StvG]

Thanks. It works now.
The output of opt=1 and opt=2 is identical.
The output of opt=3 and opt=4 is identical.
The output of opt=1/2 is a bit different than opt=3/4.

[MeteorRain]

Do you have a combination of resolution-depth-parameters that I can test?

By the way I did find some issues when running 2 instances together. I'll check that part later.

[StvG]

ColorBars(pixel_type="yv12") #whatever pixel_type
a=neo_fft3d(opt=3)
neo_fft3d(opt=2)
Compare(a,"yuv")

Live action video would have bigger difference.

[MeteorRain]

Please try r5 as I fixed the race condition when multiple instances are running together.

[StvG]

The difference is still there.

[kedautinh12]

Originally Posted by StvG

The difference is still there.

can you comment more detail?