dfttest - 2D/3D frequency domain denoiser.

[Terranigma]

dfttest by tritical

Info:
2D/3D frequency domain denoiser.

Requires libfftw3f-3.dll to be in the search path.
http://www.fftw.org/install/windows.html

Download (http://web.missouri.edu/~kes25c/)

[DeathAngelBR]

Straight to the point. Here's some screens. Yep, anime! No conclusion from me except anime is always a bitch to denoise.
It seems a sigma value of 0.25 to 0.5 is enough for grainy anime like this one.

Original noisy frame:
http://img503.imageshack.us/img503/9152/27730000originaltx9.th.png (http://img503.imageshack.us/img503/9152/27730000originaltx9.png)

Denoised with a not-so-much-detail-killer.

fluxsmoothst(9,9)
ttempsmooth()
fastlinedarkenmod(thinning=0, strength=25)
limitedsharpenfaster(smode=4, strength=50)
tweak(sat=1.10)

http://img525.imageshack.us/img525/310/27730001denoisedmw9.th.png (http://img525.imageshack.us/img525/310/27730001denoisedmw9.png)

Next is mc_spuds()

mc_spuds(frames=2, strength=1, anime=true, starfield=true, lsfstr=50, blocksize=8, overlap=8/2)
ttempsmooth()
fastlinedarkenmod(thinning=0, strength=25)
tweak(sat=1.10)

http://img267.imageshack.us/img267/1323/27730006mcspudswp5.th.png (http://img267.imageshack.us/img267/1323/27730006mcspudswp5.png)

Using dfttest() default.

dfttest()
fastlinedarkenmod(thinning=0, strength=25)
limitedsharpenfaster(smode=4, strength=50)
tweak(sat=1.10)

http://img523.imageshack.us/img523/764/27730002dfttestdefaulteo8.th.png (http://img523.imageshack.us/img523/764/27730002dfttestdefaulteo8.png)
Ooops! Too washed out.

dfttest(sigma=1.0), everything else the same.
http://img523.imageshack.us/img523/8152/27730003dfttestsigma1qm4.th.png (http://img523.imageshack.us/img523/8152/27730003dfttestsigma1qm4.png)

dfttest(sigma=0.5)
http://img509.imageshack.us/img509/3465/27730004dfttestsigma05md9.th.png (http://img509.imageshack.us/img509/3465/27730004dfttestsigma05md9.png)

dfttest(sigma=0.25)
http://img509.imageshack.us/img509/2218/27730005dfttestsigma025lx0.th.png (http://img509.imageshack.us/img509/2218/27730005dfttestsigma025lx0.png)

[Adub]

What kind of speed are we getting?

[cestfait]

WOW! :eek:

That is one powerful filter-- I've never seen such a good stand-alone temporal denoiser without artifacts (fluxsmooth and degrainmedian's blurring or temporalsoften and fft3d's ghosting, for example). It also temporally denoises much better than the former examples in general, imho (even when these others are mv-compensated).

It looks like you can set tbsize really high w/o side effects beyond slower processing. (ok, with high temporal radii it can get pretty slow, actually. . .)

Unfortunately, being quite mathematically illiterate, I still have some total blanks here and there in the docs. I wonder if tritical has any explanations for us about the differences between the analysis/synthesis windows. . .

It's really fun to play with, though. Now for some play with the spatial thresholds!

Fabulous! ^_^

:thanks:


P.S. I'm not big on spending my time clocking these filters, but I can say that with low sigma and temporal radii, this filter is acceptably fast. In fact, considering its power, it is pleasingly quick, indeed!

[foxyshadis]

btw, if you feel like really slowing it down, dfttest improves much with motion compensation, was originally made for that (http://forum.doom9.org/showthread.php?p=866255#post866255) in fact.

You could use it as a drop-in replacement for mvdegrain in mc_spuds, too, just in case it's still too fast for you. :p

[2Bdecided]

The parameters for dfttest have changed since that thread was written. What would be the equivalents of...

dfttest(sigma=3.6,bsize=8,osize=6,ssr=0,tsr=2,max2dblocks=5)

...in that post? I did try to figure the changes out from the help file, but some parameters have vanished!

Cheers,
David.

[tritical]

closest thing to:

dfttest(sigma=3.6,bsize=8,osize=6,ssr=0,tsr=2,max2dblocks=5)

would be:

dfttest(sigma=3.6,sbsize=8,sosize=6,tbsize=5)

The max2dblocks parameter is gone now along with ssr/tsr. ssr/tsr (spatial search radius, temporal search radius) were part of its internal mc, which I decided to remove since external mc with mvtools is faster and better. Previously, it would search within the area defined by ssr/tsr for the best matching blocks (most similar to the block on the current frame), and then choose the best 'max2dblocks' worth to include in the 3d transform. With ssr=0/tsr=2 and max2dblocks=5 it is essentially the same as using tbsize=5 and tmode=0 in the new filter.

Atm, the temporal operation of this filter (tbsize>1) is quite a bit slower than it needs to be since I don't cache the 2d transforms on each frame. The upside of the current method is that it uses a lot less memory (especially for small windows with large overlaps). If I get the time I will add optional caching. Also, there are 2 more filter types I would like to add.

Unfortunately, being quite mathematically illiterate, I still have some total blanks here and there in the docs. I wonder if tritical has any explanations for us about the differences between the analysis/synthesis windows. . .
I'm not an expert on windowing function characteristics either. Basically, I just included a bunch of different ones to play with. This page gives a nice overview, and has most of the ones I implemented listed:

http://en.wikipedia.org/wiki/Window_function

[*.mp4 guy]

Did you implement a "square" (sometimes called rectangular, Dirichlet, or sinc) windowing function (a square windowing function is just a plain cut-off, its the simplest one). With high overlap square often looks the best, square also always retains the most detail.

[Terranigma]

Did you implement a "square" (sometimes called rectangular, Dirichlet, or sinc) windowing function (a square windowing function is just a plain cut-off, its the simplest one). With high overlap square often looks the best, square also always retains the most detail.


swin,twin -

Sets the type of analysis/synthesis window to be used for spatial (swin) and
temporal (twin) processing. Possible settings:

0: hanning
1: hamming
2: blackman
3: 4 term blackman-harris
4: kaiser-bessel
5: 7 term blackman-harris
6: flat top
7: rectangular
8: Bartlett
9: Bartlett-Hann
10: Nuttall
11: Blackman-Nuttall

default: 0,0

So you think tritical should change the default to 7?

Also, you think you could explain how each method works (if you don't mind ?)

[*.mp4 guy]

Well, I don't know how the windowing functions will effect denoising specifically, but generally speaking a rectangular windowing function retains the most detail and has the most artifacts (ringing). All of the other windowing functions give less "wieght" to pixels close to the edges of the window when performing the dft transform, to try to lower the amount of ringing while retaining a certain type of information as well as possible (what is targeted varies amoung windowing functions) I would Guess that 7 would work the best, but obviously, to be sure testing would have to be done.

The wikipedia page should give you a good idea about how each different method works, the blue shape in the picture associated with each function gives a visual representation of how the weight of outlying pixels is reduced compared to the center pixel (in actuality they don't represent this, but for this usage of windowing functions its safe to think of them in this way).

[tritical]

I guess I'll try to give an explanation of some of the differences between the windows. There are basically three main characteristics to look at... the main lobe width, the peak side lobe level, and the side lobe roll off.

A small main lobe width gives better resolution. That is, given two equal magnitude peaks in the frequency spectrum, the smaller the main lobe width, the closer together the two peaks can be and we will still be able to resolve them. The rectangular window has the smallest main lobe width.

A small peak side lobe level makes it possible to resolve a weak (small) peak that is next to a, relatively speaking, strong (large) peak. The peak side lobe level determines the maximum response outside the main lobe. In other words, if the peak side lobe level is too high, then the energy from a strong peak can leak into nearby frequency bins and cover up a smaller peak if one is present. Of the windows implemented in dfttest, flat top or 7-term blackman-harris has the smallest peak side lobe level. The rectangular window has the largest peak side lobe level.

The third characteristic is the side lobe roll off, which gives the rate of decrease in the peak of each side lobe as you move away from the main lobe. Sometimes trading a faster roll off for a larger peak side lobe level (the peak side lobe level generally occurs in the side lobes closest to the main lobe) is good if there are no nearby peaks, but there are some farther away.

Thus, the best window would have a small main lobe width, a small side peak, and a fast roll off. The problem is that you can't have all of that at the same time. Generally, the smaller the main lobe width, the higher the side peak and vice versa. Of the windows in dfttest, the order from smallest to largest in terms of main lobe width is:

rectangular
bartlett
hamming
hanning
bartlett-hann
blackman
blackman-harris (4-term)
blackman-nutall
nutall
blackman-harris (7-term)
flat top

I left out kaiser-bessel because it is adjustable and could end up anywhere in there.

Exactly which window is best for denoising is hard to say, and would also depend on overlap amount, window size, etc... I can say from my tests in the objective denoiser thread that hanning/hamming with large overlap >= 75% and window size around 8-16 seemed to work best for removal of gaussian white noise (in terms of resulting psnr and ssim).

http://en.wikipedia.org/wiki/Image:Window_function_%28comparsion%29.png

This graph from wikipedia has pretty much all of the windows listed above, and shows the main lobe, along with the frequency envelope (you can see the peak side lobe level and how fast the roll off is).

[*.mp4 guy]

Exactly which window is best for denoising is hard to say, and would also depend on overlap amount, window size, etc... I can say from my tests in the objective denoiser thread that hanning/hamming with large overlap >= 75% and window size around 8-16 seemed to work best for removal of gaussian white noise (in terms of resulting psnr and ssim).


Nitpick: its important to note that addgrain produces noise that may differ from other guassian-like noise commonly seen in actual video.

Anyway, sorry for veering a bit off topic, I just wanted to know if the option was available (its left out surprisingly often when multiple windowing functions are available) I'm sure the default settings dfttest uses are as close to optinal for any given source as you can expect defaults to be.

[Chainmax]

...
Requires libfftw3f-3.dll to be in the search path.
http://www.fftw.org/install/windows.html
...


What exactly does that mean? All I see on that link are compilation instructions.

[Dark Shikari]

What exactly does that mean? All I see on that link are compilation instructions.The top section on the page is titled "precompiled..." ;)

[Chainmax]

dfttest already has a pre-compiled DLL included. What I don't understand is what does "Requires libfftw3f-3.dll to be in the search path" mean, which doesn't seem to be clarified in the URL.

[Terranigma]

The post was taken vertabimly from dfttest's .txt document. What that means is, is that it needs to be in WINDOWS's directory like fftw3.dll

[Chainmax]

Here's a comparison between DeGrainMedian(limitY=5,limitUV=7,mode=0) and dfttest(sigma=1.25) on an extremely crappy source:


Source (resized by two on VDub's preview window):
http://img84.imageshack.us/img84/4918/sourceos5.png (http://imageshack.us)

DeGrainMedian(limitY=5,limitUV=7,mode=0):
http://img81.imageshack.us/img81/1800/degrainmedianlimity5limox4.png (http://imageshack.us)

dfttest(sigma=1.25):
http://img209.imageshack.us/img209/8708/dfttestsigma125bi2.png (http://imageshack.us)


If you want more pics, let me know.

[BlueCup]

I think I can count the blocks in that first picture, whoa. Is that even watchable?

[Chainmax]

From a distance :p :(.

It's so sad because it's one of my favorite clips and as far as I know it's only available in this crappy YouTube form. :( x20

[Chainmax]

It seems dfttest can cause some problem with the order of the frames being displayed. I was trying to re-encode Pirate Baby's Cabana Battle Street Fight 2006 (freeware video, available here (http://www.selectparks.net/modules.php?file=article&name=News&sid=442)), and after encoding the video would sometimes jerk around as if a wrong field order was assumed. Here's the filterchain:

SetMemoryMax(512)

LoadPlugin("X:\wherever\MT.dll")

LoadPlugin("X:\wherever\MT_MaskTools.dll")
LoadPlugin("X:\wherever\DGDecode.dll")
LoadPlugin("X:\wherever\DCTFilter.dll")
Import("X:\wherever\DeBlock_QED_MT2.avs")

LoadPlugin("X:\wherever\RemoveGrainSSE3.dll")

LoadPlugin("X:\wherever\dfttest.dll")

Import("X:\wherever\LimitedSharpenFaster.avs")
Import("X:\wherever\Soothe_MT2.avs")





SetMTMode(5)
DirectShowSource("X:\wherever\PaulRobertson_PirateBabysCabanaBattleStreetFight2006.mpg",fps=25,audio=false)

ConvertToYV12()

SetMTMode(2)
DeBlock_QED_MT2(quant1=35,aOff1=16,quant2=45,aOff2=6)

RemoveGrain(mode=5)

Crop(12,52,328,184,align=true)

dfttest(sigma=1.5)

Spline36Resize(320,176)

RemoveGrain(mode=5)

LimitedSharpenFaster(SMode=4,Strength=200)

Commenting out the dfttest line would solve the issue.


[edit]mmm...commenting out the SetMTMode calls instead also solves the issue. Should I post this in the MT thread as well?

[tritical]

With the settings you used dfttest isn't even a temporal filter... on every getframe call it simply requests the current frame, filters it, and then returns it. I'm really not sure how it could have any effect on the order of frames.

dfttest might have an issue with SetMTMode(2). Unfortunately, I'm not up to date on how all the setmtmode and built-in avisynth multithreading works. I do remember that Colormatrix initially had some problems working with mt-avisynth, and dfttest uses the same kind of threading model. The main thread creates a set of worker threads which it maintains in a threadpool, and on every getframe call the main thread distributes work to the worker threads. The main thread then sits and waits for the worker threads to finish, and then returns the final frame. tsp would be probably know whether this can work with SetMTMode(2) or not.

On another note, in the currently available version of dfttest I accidently left 3 function pointers as global variables. This will cause an issue if multiple instances of dfttest are used in the same script and they have different values for ftype or zmean. Also, if in one instance sbsize%4==0 and in another it doesn't then there will be a problem. I've fixed this issue in the version on my computer. Hopefully I'll be able to it this weekend.

[Kumo]

i'm finding this filter very usefull for a video i'm trying to convert.at the moment i'm using dfttest like this:
source = last
backward_vec3 = source.MVAnalyse(isb = true, delta = 3, pel = 2, overlap=4, sharp=1, idx = 1)
backward_vec2 = source.MVAnalyse(isb = true, delta = 2, pel = 2, overlap=4, sharp=1, idx = 1)
backward_vec1 = source.MVAnalyse(isb = true, delta = 1, pel = 2, overlap=4, sharp=1, idx = 1)
forward_vec1 = source.MVAnalyse(isb = false, delta = 1, pel = 2, overlap=4, sharp=1, idx = 1)
forward_vec2 = source.MVAnalyse(isb = false, delta = 2, pel = 2, overlap=4, sharp=1, idx = 1)
forward_vec3 = source.MVAnalyse(isb = false, delta = 3, pel = 2, overlap=4, sharp=1, idx = 1)
source.MVDegrain3(backward_vec1,forward_vec1,backward_vec2,forward_vec2,backward_vec3,forward_vec3,thSAD=400,idx=1)
dfttest(sigma=1)
with mvdegrain before it.there's a way to mvcompensate dfttest with mvtools instead of using mvdegrain3 as a previus filter?can anyone post a sample usage sript?thanks

[Terranigma]

(tritical's example, modded)

source=last
vf1=source.mvanalyse(pel=2,blksize=8,isb=false,idx=1,overlap=4,sharp=2,truemotion=true)
vf2=source.mvanalyse(pel=2,blksize=8,isb=false,idx=1,delta=2,overlap=4,sharp=2,truemotion=true)
vb1=source.mvanalyse(pel=2,blksize=8,isb=true,idx=1,overlap=4,sharp=2,truemotion=true)
vb2=source.mvanalyse(pel=2,blksize=8,isb=true,idx=1,delta=2,overlap=4,sharp=2,truemotion=true)
interleave(\
mvcompensate(source,vf2,idx=1,thSCD1=800)\
, mvcompensate(source,vf1,idx=1,thSCD1=800)\
, source\
, mvcompensate(source,vb1,idx=1,thSCD1=800)\
, mvcompensate(source,vb2,idx=1,thSCD1=800))
dfttest(sigma=1)
selectevery(5,2)

[elguaxo]

Isn't it necessary to have tbsize=3 in dfttest?

Note that with default settings, dfttest works purely spatial (tbsize=1), so it won't benefit at all from the compensation.
You should instead use dfttest(sigma=[something], tbsize=3) in that script, to actually make use of the motion compensation.

[Didée]

With tbsize=3, dfttest uses 3 frames: current, current-1, current+1.
To use 2 backward and 2 forward compensations in the code Terranigma posted, set tbsize=5.

[Adub]

I find it interesting how people just copy and paste the script information from that DV cleaning thread, even after Didee already explained this.

[Terranigma]

I find it interesting how people just copy and paste the script information from that DV cleaning thread, even after Didee already explained this.

...and what I find interesting, is that I missed it, since I don't go searching and waiting for all posts by Didée. :D

[elguaxo]

With tbsize=3, dfttest uses 3 frames: current, current-1, current+1.
To use 2 backward and 2 forward compensations in the code Terranigma posted, set tbsize=5.

:thanks:

[Chainmax]

With the settings you used dfttest isn't even a temporal filter... on every getframe call it simply requests the current frame, filters it, and then returns it. I'm really not sure how it could have any effect on the order of frames.
...
On another note, in the currently available version of dfttest I accidently left 3 function pointers as global variables. This will cause an issue if multiple instances of dfttest are used in the same script and they have different values for ftype or zmean. Also, if in one instance sbsize%4==0 and in another it doesn't then there will be a problem. I've fixed this issue in the version on my computer. Hopefully I'll be able to it this weekend.
If you can, please set default values that make it act as a 3D filter so that lazy filterers like I only have to change the sigma value :p.

[tritical]

I'll change it in the next version.

[murrsturr]

Thanks Tritical. Very much appreciated.

[kwak]

Hi Guys :) this is my first post:D

I've a problem to locate the directory for the libfftw3f-3.dll file in windows Vista 64bit, I've just used this filter in XP without problem, and I've just tried a solution on the FFTW site without success.

Please help me :)

:thanks: forward to all

[lol_123]

I am confused about the term "denoise" , when you guys say it, what does it exactly mean, de-mosquito noise of MPEG ?

[R3Z]

I am confused about the term "denoise" , when you guys say it, what does it exactly mean, de-mosquito noise of MPEG ?

Predominantly random dots and particles that are not part of the detail make up of the movie. Denoise also covers film grain and other small imperfections.

[foxyshadis]

kwak, if you can't get it into the windows system32 folder (or syswow64 in x64) then you have to put it into the same folder as the program you're running, or another folder that's on the "path".

[kwak]

thanks foxyshadis, now dfttest runs great also in vista :)

[Chainmax]

So, for using its temporal component, all one has to set is tbsize to something higher than 1, right?

[Adub]

Yes. I usually find 3-5 a good range.

[weisskreuz]

Thanks, that gives amazing effect.
But I’ve got a problem, that when I use dfttest on win2003, it gives me a result with random black/green bar (random frame & random location)
I tried avs 2.5.6~2.5.8, also tried just put dfttest and avs default filters in plugins directory, update fft, update drivers, but can't solve this problem.

If you can see this clip, you will know what I said
http://www.mediafire.com/download.php?jgtn2el3xjn


I'm using:
Microsoft Windows Server 2003, Enterprise Edition SP2
QuadCore Intel Xeon E5335, 2000 MHz (6 x 333)
Intel Sapello S5000VSA (1 PCI, 2 PCI-E x8, 2 PCI-X, 4/8 FB-DIMM, Video, Dual Gigabit LAN)
4089 MB (DDR2-667 Fully Buffered ECC DDR2 SDRAM)
ATI ES1000 (16 MB)

[masterkivat]

I already had that issue, but I've formated my pc here (now running Vista x64 with updated drivers), and until now I didn't get it. Hope tritical could awser us what we must to do avoid that :D

[mikeytown2]

Try it with mod16 width and height. That usually takes care of problems related to random green.

[tritical]

Please post the scripts causing problems.

[tritical]

I finished/cleaned up the code for the next version that I had from November 08. Try it, and see if it fixes the problems... dfttest v1.2 (http://bengal.missouri.edu/~kes25c/dfttestv12.zip). Changes:

+ added filter types 3/4 and corresponding parameters (sigma2,pmin,pmax,sfile2,pminfile,pmaxfile)
+ more asm optimizations
- fixed problem with global function pointers add multiple instances in the same script
- changed name of 'cfile' parameter to 'sfile'
- the value given for sigma is no longer squared on initialization
- sigma now defaults to 2.0
- tbsize now defaults to 5

Note that tbsize now defaults to 5... so it will be slow as hell :p.

[Dark Shikari]

Oh come on, you must be able to make this one faster:

void addMean_SSE(float *dftc, const int ccnt, const float *dftc2)
{
__asm
{
mov edx,dftc
mov edi,dftc2
mov ecx,ccnt
xor eax,eax
four_loop:
movaps xmm0,[edx+eax*4]
addps xmm0,[edi+eax*4]
movaps [edx+eax*4],xmm0
add eax,4
cmp eax,ecx
jl four_loop
}
}

---> (not tested but you get the idea)

void addMean_SSE(float *dftc, const int ccnt, const float *dftc2)
{
__asm
{
mov edx,dftc
mov ecx,dftc2
mov eax,ccnt
four_loop:
movaps xmm0,[edx+eax*4-16]
movaps xmm1,[edx+eax*4-32]
movaps xmm2,[edx+eax*4-48]
movaps xmm3,[edx+eax*4-64]
addps xmm0,[ecx+eax*4-16]
addps xmm1,[ecx+eax*4-32]
addps xmm2,[ecx+eax*4-48]
addps xmm3,[ecx+eax*4-64]
movaps [edx+eax*4-16],xmm0
movaps [edx+eax*4-32],xmm1
movaps [edx+eax*4-48],xmm2
movaps [edx+eax*4-64],xmm3
sub eax, 4
jl four_loop
}
}

(Even if it isn't guaranteed to be mod64, it probably costs less to modify the code to allow it than to have such a short loop...)

Also, sqrtps is really slow. Apparently rsqrtps is 3 cycles, while sqrtps is up to 58. And rcpps is just 3, so it's far faster to do rsqrtps + rcpps than to do sqrtps. At least on the Core 2.

By the way, any commentary about the merits of the various ftypes?

[tritical]

Unrolling there does make addmean faster, but it isn't one of the more time consuming functions. However, it did make more of a difference in overall speed than I thought it would based on previous profiling results:

libfftw3f-3.dll 67.75 smode=1,sbsize=12,sosize=9,tmode=0,tbsize=5
dfttest.dll 19.03
filter_0_SSE 38.16
proc0_SSE2_4 25.03
removeMean_SSE 14.89
proc1_SSE 10.22
addMean_SSE 7.31
func_1 2.38

libfftw3f-3.dll 48.79 smode=1,sbsize=12,sosize=9,tbsize=1
dfttest.dll 28.34
proc1_SSE 31.01
filter_0_SSE 28.62
proc0_SSE2_4 14.42
removeMean_SSE 9.96
addMean_SSE 6.34
func_0 3.15

So I changed that, made a few other small tweaks, and fixed tmode=1 operation so that during linear access it doesn't have to recalculate all involved temporal blocks on every frame. Will put it next version later tonight.

ftype=0/1 are probably the only useful ones for typical video denoising. The others allow for lots of frequency domain effects, but to really be useful you'd probably have to spend the time to specify different sigma/sigma2/pmin/pmax values for each dft coefficient. Plus, as there is currently no option to show the dft coefficients/psd values it would be rather difficult to set all of those. I have plans to add a 'show' option of some kind.

[Dark Shikari]

Since I'm rather interested in this going faster, is there any general reason why you can't do the transforms in integer math?

I imagine that special-casing transforms could make things a whole lot faster, though switching the whole program over to DCT/iDCT instead of FFT might be quite complicated.

[weisskreuz]

Try it with mod16 width and height. That usually takes care of problems related to random green.

:rolleyes:512x288 is already mod 16&32



Please post the scripts causing problems.

directshowsource("cb_nico_04.mp4")
dfttest(sigma=0.8)
crop(0,48,0,-48)# video height is 384px with borders
trim(0,3000)

It seems not caused by script or video, because I also tested it on XP, no problems have been found.



I finished/cleaned up the code for the next version that I had from November 08. Try it, and see if it fixes the problems... dfttest v1.2 (http://bengal.missouri.edu/~kes25c/dfttestv12.zip).


:D Thx tritical

Problem still exist, here is a 301 frames test between 1.1 and 1.2 with another video.
http://www.mediafire.com/download.php?dnyj4z4nnzy

also used with default setting, script:

dss2("Druaga2_tvs_03.mp4")
dfttest(sigma=1)
trim(0,300)

[Sagekilla]

I assume that was a typo and you mean 512x256 yes? ;)

[weisskreuz]

sorry, that's 512x288(16:9)

post update

[Caroliano]

Regarding the filter going faster, as dfftest seems to be similar to ff3dfilter, how dificult would be to do an "dfttGPU"? Or I'm comparing apples to oranges here?

I would love to see that, because most of my encoding time is dfttest, and I can't drop it, because it is so good in anime.