dfttest - 2D/3D frequency domain denoiser.

[cretindesalpes]

Thanks for the dithering ! Could you please also implement a 16 bit output (like the way I modified the 1.6 version here (http://forum.doom9.org/showthread.php?p=1386559#post1386559)) so the dithering can be performed later in the processing chain with other tools or algorithms ?

[tritical]

AddGrain pre-generates a field of grain and quickly applies it to the image each frame, starting from a random offset, rather than coming up with a new random number each pixel. Since dither isn't nearly as visible, you could probably get away with pre-generating as few as 128-256 values to repeatedly add prior to floyd-steinberg.
I might use a faster method like you suggest in the future. I didn't actually benchmark it at all, but it probably doesn't take up much time compared to all of the other processing dfttest does... so may not be worth it to change it. Will do some testing before the next version.

Question: might it be in your future plans to include a "show" parameter which would display either the noise identified for denoising without the video--or which would paint the pixels that have been identified as noise to be removed a different color?
Hm, is this for nstring/nfile use (paint the windows being used to estimate the noise spectrum) or just in general? If in general then Stephen R. Savage's suggestion will show you what dfttest thinks is noise. For the nstring/nfile case I don't plan on making a mode that paints the windows since you can easily locate the windows on your own. The estimated spectrum is already output to a file. The one thing that might be cool is to take the inverse transform of the estimated noise spectrum and show that against a flat image. If multiple windows are being used in the nfile/nstring, dfttest could take into the variance of the estimation when doing this (otherwise it would really only need to show one block).

Tritical: do you plan to update the x64 version too?
No. The reason I don't make x64 builds of any of my filters is that I don't run a 64-bit windows OS on any computers. When that changes I will probably start making them. Of course, another hold up is all of the inline assembly which has to be moved out (never mind rewriting to take advantage of the extra registers) to yasm or similar. dfttest has a lot of that :(

Thanks for the dithering ! Could you please also implement a 16 bit output (like the way I modified the 1.6 version here) so the dithering can be performed later in the processing chain with other tools or algorithms ?
Yep.

[Lorax2161]

Stephen R. Savage

Lorax, that feature would not need to be implemented in dfttest. You can already create the difference map between two clips with the internal Subtract() filter or the mt_makediff() function from the MaskTools plugin.

Thanks for pointing me in the right direction; I will look into those suggestions.

tritical

Hm, is this for nstring/nfile use (paint the windows being used to estimate the noise spectrum) or just in general? If in general then Stephen R. Savage's suggestion will show you what dfttest thinks is noise. For the nstring/nfile case I don't plan on making a mode that paints the windows since you can easily locate the windows on your own. The estimated spectrum is already output to a file.

I meant just in general. At the moment, I use a script someone wrote here which will split your screen into a "before" and "after" filtering, and it's useful for fairly obvious changes but not so much finer differences unless they are more isolated.

This came about as I tweaked dfttest to improve speed on my dual core, and I wanted to see what I was giving up in noise reduction. But Stephen's suggestion should do the trick. I have some reading up to do on that, though. Thanks for the reply.

[tritical]

Personally, I like to use interleave() to see the visual differences between clips since the output from subtract() can be hard to interpret (in relation to how different the two frames actually look to your eyes). So something like:

source()
a = dfttest(settings_old)
b = dfttest(settings_new)
interleave(a,b)

then open in virtualdub and flip back and forth between the same frame in both clips. Everyone has their own preference for this though.

[Keiyakusha]

doesn't take up much time compared to all of the other processing dfttest does...

Well... I guess "not much time" is somewhat subjective. When with this: dfttest(sstring="0.0:1.0 1.0:16.0",dither=0,tbsize=1) I have average speed 9.2531 fps, with dither=1 I have 8.1968.
It will be nice if it can be faster. However results are perfect, thanks!
EDIT: or what foxyshadis proposed is valid only for dither>1?
By the way what tbsize=1 actually means? To process 1 frame in temporal dimension or it turns filter into pure spatial? Because with more than 1 I see some temporal artifacts...

[VincAlastor]

tritical, thank you very much. to slow for "daily" using, but dfttest is a outstanding filter for extraordinary sources :)

[tritical]

@VincAlastor
It's only slow if you use slow settings :). For example, processing 720x480 material on the Q9650 here in the lab with the following script:

mpeg2source()
dfttest()

I get 5.75 fps with (dither=2) - everything else defaults, and I get 6.3 fps with dither=0. If I use (tbsize=3,sbsize=48,sosize=16,U=false,V=false), which is equivalent to fft3dfilter's defaults, I get 54fps. If I use (tbsize=1,sbsize=48,sosize=16,U=false,V=false) I get 112 fps. Finally, if I use (tbsize=1,sbsize=16,sosize=0,U=false,V=false) I get 190 fps. Of course, the trade off for speed is quality (usually). Like most of the rest of my filters (nnedi3 for example) the defaults are tuned heavily in favor of quality. Though I should really change the tbsize default to 3 instead of 5, since 5 usually causes visible artifacts in motion areas unless motion-comp is used.

@Keiyakusha
The slow down is more than I thought it would be, but it's also relative to the settings being used. If you use fast settings then the float to unsigned char conversion process at the end takes up more time relative to the filtering. Also, dither=0 has SSE/SSE2 code paths while dither>0 (dithering or dithering+random_noise) is just C code for now. The difference between dither=1 and dither>1 isn't enough to make me use a faster method for generating the noise. If I have time I'll try to write SSE versions of dither>0 which should narrow the gap a lot.

[Bi11]

Could someone explain to me in plain english, what makes dfttest better than other 2D/3D frequency domain denoisers like fft3dfilter? The documentation doesn't easily say what differentiates it from other denoisers, only how the use the parameters.

How does dfttest compare to tnlmeans? I know they operate very differently but are there sources under certain conditions that are more favorable to tnlmeans than dfttest?

Though I should really change the tbsize default to 3 instead of 5, since 5 usually causes visible artifacts in motion areas unless motion-comp is used.
What would the ultimate MC script with dfttest look like? :devil:

Off topic, tritical, if you have time, could you release an optimized version of EEDI3 please? It is very very useful with TGMC, but very very sloooow. :(

[pandy]

big THX Tritical! Is there any chance to add: fixed - time constant dither (like ordered for example) THX once more!

[Caroliano]

Thanks for the dither function! It seems much less destructive than the gradfunkmirror's one. I hope it is as effective. I aways wanted an lower strenght for dither, and now I have. But I assume that for sources with much banding, I'm better off using an external dither utility, right? I don't like to add grain.

Though I should really change the tbsize default to 3 instead of 5, since 5 usually causes visible artifacts in motion areas unless motion-comp is used.
I very much agree with that. I never use tbsize=5 anymore because of that. Can't you make an mode that turns the temporal filter of dfttest as safe as ttempsmooth? Or it won't work/won't work well with dfttest? And it is also a good idea to make the filter a little faster by default, as this is the main complaint that I hear about dfttest() elsewhere, from people that don't dare to mess with the settings.


I for myself don't mess much with the sbsize and sosize settings. The readme could be a bit more "user-friendly". Like, in the sbsize description saying that it is an speed/quality trade-off, and that an higher setting. the filter will be faster. Or in the ftype say something like "this is much slower, but likely to be more precise" or "works better for heavy denoising" or "blurs more", etc. For me "mult = sigma*sqrt((psd*pmax)/((psd+pmin)*(psd+pmax)))" don't means anything.

Dfttest() is really a great filter.

What would the ultimate MC script with dfttest look like? :devil:
I think it look like this: http://forum.doom9.org/showthread.php?p=1308269#post1308269

[foxyshadis]

Rather than faster by default, a preset argument for fastest/fast/normal/quality would make sense to control default size/overlap. It's still a bit of an experimental filter, though.

ftype (and swin/twin/sbeta/tbeta/f0beta/zmean) isn't something that really even goes in the front of the docs. There are a few places where you would try another ftype or tweak the arguments, but they're way out in an experimental left field if you just can't get the results you want or want a very different effect. The defaults are definitely sufficient for everyday use.

[nibus]

I've been using this for the past few days and I have to say I am getting some amazing results, especially on HD content with the dither function.

It is slow, but it does do a very good job of utilizing the whole CPU.

[Keiyakusha]

yeah, but there is one problem. this dither is so small, its hard to keep it with sane bitrates. even simple removegrain(mode=1) which I always use shaves it off :Р

[Dogway]

When it comes to speed I like using dfttest, I have found it works nice along mdegrain, so I make a mdegrain prefilter and then run dfttestmc. The only drawbacks are the ghosting and the heavy blur on dark areas. I wanted to ask about this one, is there a way in the filter to protect these dark areas? as for now Im raising levels->dfttest->lowerin levels which preserves most details on penumbra but might harm the overall image/dynamic range.

[thewebchat]

When it comes to speed I like using dfttest, I have found it works nice along mdegrain, so I make a mdegrain prefilter and then run dfttestmc. The only drawbacks are the ghosting and the heavy blur on dark areas. I wanted to ask about this one, is there a way in the filter to protect these dark areas? as for now Im raising levels->dfttest->lowerin levels which preserves most details on penumbra but might harm the overall image/dynamic range.

You generally shouldn't be using MDeGrain to preprocess for MAnalyse. This doesn't make sense, because if MDeGrain could remove the grain, that means MAnalyse found the vectors and doesn't need any preprocessing. You should use a spatial denoiser like dfttest or FFT3DFilter instead.

Aside from that, you should check to see if you get the same artifacts running just dfttest, since they could be related to the MC function. I would try lowering sigma (obviously) and the temporal radius to see if that prevents the artifacts. If you find the artifacts are specific to dfttestMC, try reducing the spatial component (sbsize/sosize) and the number of compensated frames (mc). Also, don't set the mdg parameter to true, it's typically counter-productive.

[Dogway]

I just found someone uses a similar principle (http://forum.doom9.org/showpost.php?p=1444252&postcount=31). The goal was to denoise with mdegrain (not the mdg flag), and only then denoise with dfttest with a low sigma, using the mc version to avoid ghosting, this way you get a good denoised result while preserving details.

From here you can enhace the mechanism which probably you pointed out. Preprocess with spatial denoiser for vector evaluation, pass mdegrain, pass dfttest using previous vectors, and probably use the lumamask function I posted a few days ago to mix mdegrain+dfttest on bright with only mdegrain for dark.

[maki]

Question, is it okay if I try to keep the settings close to the original video (in this case), or is it okay to leave this relatively amount of noise.
(I'm trying to keep the video close to the source, but I don't know whether to keep this amount of noise, or try to remove it completely.
For those that are used to encoding anime what should I do?).

Original: No filtering whatsoever
http://img825.imageshack.us/img825/769/haruhiwithoutfilter.th.png (http://img825.imageshack.us/i/haruhiwithoutfilter.png/)


http://img101.imageshack.us/img101/71/haruhiwithfilter.th.png (http://img101.imageshack.us/i/haruhiwithfilter.png/)

With filters
toonlite(0.05)
dfttest(sigma=0.05, tbsize=3)
WarpSharp(96, 10, 128, -0.6)
LimitedSharpenFaster(strength=200).LimitedSharpenFaster()
Dehalo_alpha()

http://img192.imageshack.us/img192/7672/haruhi2006version.th.jpg (http://img192.imageshack.us/i/haruhi2006version.jpg/)

I know it sort of bothers me, but how can I thin the lines enough to make it look close to the thin lines of the 2006 version. Any help with the warpshap settings would be appreciated.

As for the the noise, dfttest seems to affect the background as the preview shows, but the moving object likes haruhi and kyon seem blocky,
nothing like the preview. How can I fix the chroma of moving objects without affecting the overall of the background too much.
Deen's defaults doesn't seem to do much, and I don't really get DeBlock_QED, I could also use some noise remover, but I am lost any help would be appreciated.

[naoan]

Uh... shouldn't that be up to what you want?

Imo, that warpsharp destroy it too much though.

[GMJCZP]

First of all the order of the filters would be:

dfttest (sigma = 0.05, tbsize = 3)
toonlite (0.05)
LimitedSharpenFaster (strength = 200). LimitedSharpenFaster ()
WarpSharp (96, 10, 128, -0.6)
Dehalo_alpha ()

I suggest using AwarpSharp2 instead of WarpSharp for anime. ;)

[VincAlastor]

The faster-than-fast Fourier transform

For a large range of practically useful cases, MIT researchers find a way to increase the speed of one of the most important algorithms in the information sciences.

http://web.mit.edu/newsoffice/2012/faster-fourier-transforms-0118.html
http://groups.csail.mit.edu/netmit/sFFT/

[redfordxx]

"Under some circumstances, the improvement can be dramatic — a tenfold increase in speed." Wow, hopefully dfttest gets lucky;-)

[mandarinka]

Doesn't dfttest stand for >discrete< Fourier transform, as opposed to fast Fourier transform?

But if dfttest uses FFT for lower complexity (no idea), it might benefit if that method got integrated into the FFTW library it uses? I assume it uses that code to do the transform.

[gyth]

FFT is the class of algorithms used the compute DFT.
http://en.wikipedia.org/wiki/Fast_Fourier_transform

Naive implementation of DFT would invert a square matrix taking a number of steps equal to the size of the matrix, O(n^2). FFT does the same thing in O(n log n). For sparce matrices (when many of the values are zero) things can possibly be even faster.

Many of the values are zero for heavily compressed files. Denoising won't zero out as many values unless you are using aggressive settings.

[Chyrka]

Hi, guys!
Can anybody explain this miracle
http://forum.doom9.org/showthread.php?p=1070418#post1070418
with old dfttest that give aa-effect at sigma=1.0 ?
:eek:

[cretindesalpes]

I’m pretty sure the aliasing wasn’t in the original picture and was added by Imageshack.us when they resized everything above some limit to 800x600 using a terrible resizer, probably to save space on their servers. All pictures hosted on imageshack.us should be considered as "unreliable" for comparison purpose.

[Chyrka]

cretindesalpes, thx for answer. But your idea doesn't correlate with point of that post. There are dependence between screenshots and posted there scripts. :confused:
But preview include the text (640*480) when screens are 800*600. What the ridiculous situation. o_O

[kedautinh12]

I seen 299792458m update dfttest 1.9.6 of pinterf with new commits, can anyone compile it?? thanks
https://github.com/299792458m/dfttest_mod/commits/196

[pinterf]

I seen 299792458m update dfttest 1.9.6 of pinterf with new commits, can anyone compile it?? thanks
https://github.com/299792458m/dfttest_mod/commits/196
You probably really badly need those features, I suppose because your daily-used scripts would immediately exploit the new possibilities?
So kedautinh12 you are the one who directly emailed me to integrate "some speed tune when stacked or dither" commits from that repo?

And the one, who - though not owning either repositories - cross pull-request our repos
https://github.com/gabest11/TIVTC/pull/1
and
https://github.com/pinterf/TIVTC/pull/28
Hilarious! You make us work twice to achieve the same result: in order to have you a latest zero-day plugin collection.

And request AVX2 and AVX512 additions to AddGrainC you've seen in the - now completely different - VapourSynth repo. Why did you need that so much, I asked you to make benchmarks in order to see whether it is worth, got zero answer? Asking is free, I hope you have an AVX512 processor.

What next? Daily snapshot for all plugins for you? Last time you have requested a plugin compile when you realized that there is a new commit there (We are talking about a maximum 10 hours old commit at that time!)

I suppose you are only a zero-day-plugin collector, it costs you nothing to report/thank/request newer and newer developments.

Look, these are free-time projects. In no way will I serve you to ease your hunger for a complete plugin collection which is at most one week old.

[real.finder]

maybe kedautinh12 just liking see more Development :D

[kedautinh12]

Oh, sr, I am a hunter's development thing so i jusk liking see more Development like real.finder say. If you were felt disturb so i am sorry about that. I don't know that make you angry, i only think i want see more development when i can. I didn't recognized this is ambition. Very sorry

And i have AVX2 processor, i ask for this and i don't know about c++, c, python knowledge so i don't know it's completely different now. Sorry

[kedautinh12]

And i only ask you for this feature development, you can refuse me immediately if you think it's don't important and need do it now like your email you send me. After, i don't ask you more with same features you were refused. Very sorry

[kedautinh12]

I am a people. Who have noob English skill and only use simple English vocabulary and grammar. So i normally misinterpret my words about ask someone do something and they things it's rude. Very sorry, i was closed two pull requestes in your links. I only want see more development in the future and don't want it's must do immediately. You can do it in several years and i just share what i find out. That's about my thinking and not anymore

[DJATOM]

xD...

[kedautinh12]

xD...

Sorry DJTOM, this is mistake when i first use pull request in github. I just want share commits of 299792458m to pinterf but i was pull request to your dfttest (first time use pull request)

[DJATOM]

Nah, no need to sorry. It just hilarious for me to see that I was so eager for updates in the past, but now when I gained some knowledge and making own stuff, I'm no so eager anymore. Basically that "xD" refers to myself.