dfttest - 2D/3D frequency domain denoiser.

[tritical]

I put up [link removed], changes:

+ some small assembly optimizations
+ tmode=1 caching (don't need to recalculate all involved temporal blocks on every frame)
- replicate temporal dimension at beginning/end, don't mirror


@weisskreuz
Please try v1.3. If the problem with win2003 is still there then I have no idea what is causing it.

@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.
I don't have any experience with integer transforms, but if you can only do transformations of integer inputs then it wouldn't be useable because the windowing function needs to be applied beforehand. I guess you could do scaling/integer approximation. You probably know more than I do about it. Switching from DFT to DCT wouldn't take that much work.

IMO, dfttest isn't that slow in spatial only mode (tbsize=1). The default of 12x12 blocks with 75% overlap is simply a lot of calculations. More reasonable settings, 16x16 w/ 25-50% overlap, are quite fast. Of course, the results aren't usually as good. dfttest is slow with tbsize>1, especially with tmode=0, because it computes full 3D transforms instead of computing 2D transforms on each frame, storing the results, and then applying the temporal window and 1D transform as needed to those. That method uses significantly more memory, especially for large overlaps, but eliminates a lot of redundant calculations. I've started making the changes to do this, but it is going to take a little while to complete.

@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?
Let's just say that I will not be the one to make a dfttGPU :p.

[tritical]

I forgot to upload v1.4 with the fix for weisskreuz's issue from February. It's now up on my website. Turns out the problem was caused by threads>1 creating the possibility for multiple threads to try to update the same memory location (add their value to the current value) simultaneously. Well, I should say I think that is what the problem was, as fixing that problem also fixed his issue. However, for some reason I could never make threads>1 result in significant differences (more than +-1 for a given pixel value) on my quadcore machine running XP. Unfortunately, the fix does slow it down a little bit.

[tritical]

I've been doing some work on dfttest, v1.5 is up on my website.

I've added an exponent to the 0 filter type:

mult = max((psd-sigma)/psd,0)^f0beta

1.0 (the previous default) corresponds to wiener filter with spectral subtraction as the signal power estimate. If you set f0beta=0.5 you get spectral subtraction, which I've been finding to be slightly better in ssim/psnr tests of removing white noise. Other values are also possible (actually I got even better ssim/psnr with f0beta=[0.2,0.3]), but are not typically used. The 1.0 and 0.5 cases have special code paths for speed, other cases use a general routine that needs to compute pow(), so are slower.

I also added the ability for dfttest to estimate the noise spectrum based on pure noise blocks that the user can specify using the 'nfile' parameter. This way dfttest can be more easily used for noise that doesn't have a flat power spectrum, but the noise still needs to be stationary (power spectrum doesn't change).

Finally, sigma/sigma2, for ftype<2, and pmin/pmax are now normalized based on the non-coherent power gain... so sigma corresponds directly to power regardless of the window size/function.

I'm also playing with some SNR adaptive spectral subtraction techniques, one of which should make it into v1.6.

[vampiredom]

I have a question; and please pardon me if it seems silly or obvious: Would it not be a good idea to include an interlaced=true/false option in dfttest (like exists in FFT3DFilter)?

In the absence of such an option, what is the best way to handle interlaced sources? Should we use SeparateFields().dfttest().Weave() ?

Thanks! (the denoiser quality looks great, BTW)

[tritical]

I don't include an interlaced parameter, and probably never will, because IMO you are better off handling it yourself... with separatefields().dfttest().weave() as you suggested, or more involved, but usually better quality, approaches such as bobbing the video (with a bobber that preserves the original fields), filtering, and then re-interlacing. The many possible approaches have been discussed before in various threads. Here is one I found: http://forum.doom9.org/showthread.php?t=112551. I thought there were some more recent ones, but can't seem to find any right now.

[vampiredom]

Thanks for the clarification. I think I understand what you mean: A simple separate -> filter -> weave does not apply the filter to realistic spatial interpretation of the image.

Yes, bobbing beforehand is the "quality" way to go; but it requires (at least) twice the processing time.

Out of curiosity: Does anyone happen to know if the interlaced=true option in FFT3DFilter simply separate and then re-weave the fields, or is there more going on behind-the-scenes? Does it force different handling of the chroma planes (when chroma denoising is selected) for YV12 sources?

[nonsens112]

tritical, thanks for such a great denoiser.

but since it is rather slow, especially with big tbsize values, it would be great to add a clip parameter which can locally modify sigma.
I noticed that when using MC+dfttest, it's good to apply dfttest with bigger sigma on bad SAD areas, and almost disable dfttest (replacing it with mdegrain) on areas with too little local contrast, otherwise it eats some weak detail. so I have to blend 2 or even 3 instances of dfttest when it's needed to just locally control its sigma by external mask.

hope you'll consider such ability in further versions ;)

[nonsens112]

another similar idea which also looks attractive in MC+dfttest(big tbsize) case is external clip that controls local tbsize.

in high-motion or intensively flickering areas big tbsize values don't work as good as low ones because most part of compensated frames in such areas violates SAD limitations, thus making most part of 3D-block belong to current frame. in static areas, the bigger tbsize is, the better detail retainment and the better stability can be obtained. for noisy DVD sources, maximum tbsize should be more than GOP size, which is about 16 frames if I'm not wrong.
thus, blending of multiple instances of dfttest with various tbsize (for example, from 3 to 17) seems to be a good idea qualitywise, but speedwise (and memorywise, if doing in 1 pass) is unreal now.
adding external control of local tbsize could easily solve this problem I think.

[tritical]

Modifying sigma while the filter is running based on an external mask is easy enough. How do you want the mask clip to be interpreted? How should sigma change based on it?

Modifying tbsize while the filter is running would require more substantial code changes. Atm, the 3D window/transform are computed during initialization. I guess the easiest way would be to compute all possible windows/transforms for the varying tbsize range, and then switch between those during runtime. How do you want the external mask to be interpreted? I also had the idea of limiting tbsize based on sad or ssd to the center frame block as you move outwards... if the difference exceeds some threshold then stop (sort of how most temporal denoisers with adaptive radius work).

In other dfttest news, a few weeks back I worked on adding local neighborhood (i.e. neighboring blocks) smoothing of filtered power spectra prior to taking inverse fft and combining results. This is similar to smoothing the short time fourier spectra when using spectral subtraction in audio processing in order to reduce 'musical' noise. I only added it to the 2D (spatial only) denoising case. It works quite well to remove the typical artifacts of fft based denoising, especially when using strong settings. Applying it to the 3D case is more difficult though.

[nonsens112]

Modifying sigma while the filter is running based on an external mask is easy enough. How do you want the mask clip to be interpreted? How should sigma change based on it?
I think the most natural way is: block's sigma = ("sigma" parameter) * (luma of ext clip averaged on spatial block of current frame) / 255

Modifying tbsize while the filter is running would require more substantial code changes. Atm, the 3D window/transform are computed during initialization. I guess the easiest way would be to compute all possible windows/transforms for the varying tbsize range, and then switch between those during runtime. How do you want the external mask to be interpreted? I also had the idea of limiting tbsize based on sad or ssd to the center frame block as you move outwards... if the difference exceeds some threshold then stop (sort of how most temporal denoisers with adaptive radius work).
I think the best way to interpret ext mask is: block's tbsize = 2 * round(("tbsize" parameter/2 -1) * (255 - ext clip luma at center of block) / 255) + 1
limiting tbsize based on sad or ssd to the center frame block as you move outwards is a good idea. the only drawback I see here is double SAD/SSD computation when using MC - in mvanalyse and here. if I'm not wrong, mvmask doesn't compute SAD but just takes it from vectors' clip, so using ext clip based on mvmask could be faster. whether it really matters compared to your DFT magic or not is the other question :)

also, as possible further improvement of this idea, I would consider not tbsize limiting but determine temporal borders independently, thus the current frame could be not in the center of the block. external control would require 2 clips in this case - forward and backward temporal depth. I'd expect much better stability, especially on scene changes. afaik, mdegrain works in such way.

[tritical]

@nonsens112
Your suggestions seem fine to me. Making the temporal radius unequal going backwards/forwards is rather difficult taking into account windowing. For now I'll stick with only the first two items :). No guarantees on when it will get done though.

@all
I discovered a bug in dfttest's window normalization under the following scenerios:

tbsize>1, tmode=0
consequence is a rectangular temporal window regardless of what twin is set to

sbsize>1, smode=0
consequence is a rectangular spatial window regardless of what swin is set to

In the smode=tmode=0 case you got rectangular for both temporal/spatial.

I should have a fix up later tonight.

[nonsens112]

Making the temporal radius unequal going backwards/forwards is rather difficult taking into account windowing.
I wonder what's difficult - current implementation limitations, possible quality issues (3D-ringing or like that) or smth else? or a mixture of?)))
I'll stick with only the first two items . No guarantees on when it will get done though.
that's great anyways :) hope the features will be useful to many people.

[Keiyakusha]

Hi. Please can someone tell me what options of this filter actually do? I mean when I need to adjust them? I have read the documentation but I don't understand it.

Y,U,V - If true, the corresponding plane is processed. Otherwise, it is copied through to the output image as is. default: true,true,true
So I need to add u=false,v=false parameters if I want to process only luma?
ftype - Controls the filter type. default: 0 - generalized wiener filter; mult = max((psd-sigma)/psd,0)^f0beta)
I guess I better leave it at default?
sigma,sigma2 - Value of sigma and sigma2 (used as described in ftype parameter description)
"ftype parameter description"- this is that formula? I don't understand what it means. This option is something like sigma in FFT3Dfilter?
pmin,pmax - Used as described in the ftype parameter description.
Again, have no idea what it means and when I should adjust it.
tmode - Sets the mode for temporal operation
Default is good most of the time?
swin,twin - Sets the type of analysis/synthesis window to be used for spatial (swin) and temporal (twin) processing.
Should I adjust this parameters or defaults is good?

Sorry for dumb questions. Please give me a link if I can read about it somewhere else.

[Nightshiver]

the sigma's are the strength of the filter. The high you set it, the stronger it denoises. For just about every use you will have for this filter, you will not need to alter anything, save the sigma.

[tritical]

So I need to add u=false,v=false parameters if I want to process only luma?
yep.

For general denoising, only ftype=0 and ftype=1 are useful. ftype=0 actually becomes ftype=1 as the value for f0beta approaches 0. pmin/pmax/sigma2 are only used in ftype>1 so you don't need to worry about those. ftype>1 is really only useful if you plan to use the 'sfile' parameter to specify sigma values for specific fft coefficients... in which case you can accomplish all sorts of frequency domain manipulations.

As for tmode, I would always use 0. 1 is faster (its the same idea as smode=0 vs smode=1 in the spatial domain), but in the temporal domain it causes artifacts. swin/twin you could play around with. The defaults are what I've found to work best in most cases. They also worked best in the ssim/psnr tests I've done. See http://en.wikipedia.org/wiki/Window_function for some information on the different windows.

If you are trying to remove noise that isn't white, the nfile parameter (which allows you to specify blocks containing only noise, from which dfttest estimates the noise power spectrum) can be very useful.

[Keiyakusha]

Oh, big thanks for the explanation!:thanks:

[rkalwaitis]

Tritical,

I am trying to use the nfile option and I receive an error that states unable to open nfile. Is there something special I should be doing. Perhaps a little example. Thanks. Also is there a way to make the nfile do each frame, remember the results for use by the denoiser, instead of working on an average?

Thanks

[tritical]

I am trying to use the nfile option and I receive an error that states unable to open nfile. Is there something special I should be doing. Perhaps a little example.
What is your script? What is in your nfile? When I use the nfile option it works fine... so I need a little more information about your problem.

Also is there a way to make the nfile do each frame, remember the results for use by the denoiser, instead of working on an average?
You actually have a clip where the noise power spectrum is changing on every frame, and the same position on the image is always flat with just noise? Or do you intend to manually specify locations for every frame?

[rkalwaitis]

Tritical I have no real script for use of the option. I was trying to make it work via your read file. I thought that the nfile took a sample of a frame and used that to compute denoising. I was just wondering if it could do it frame by frame.

Thanks K

[onesloth]

I thought that the nfile took a sample of a frame and used that to compute denoising. I was just wondering if it could do it frame by frame.
Somebody correct me if I'm wrong but my understanding is that one uses nfile by defining an area of one frame from the clip where there is nothing but noise (e.g. a flat color background). The analysis of that noise area is used to tweak the denoising parameters for the whole clip *not* just the frame in which the area is defined.

I think Tritical's point is that he would be really surprised if the noise in your clip changed significantly from frame to frame (thus requiring a new noise sample) and that it would likely be impossible for you to find a flat noise-only area in *every* frame that would be suitable for defining the noise.

[rkalwaitis]

This makes sense to me. Thanks for an explanation. Thanks Tritical for the great denoiser.

[lansing]

my script was this:

MPEG2Source("sample.d2v", info=3)
colormatrix(hints=true)

dfttest()

And I'm seeing ghosting in some dark area. Noticed the blue coat.

Original:
http://img2.imageshack.us/img2/8519/originalz.png

dfttest:
http://img40.imageshack.us/img40/4609/dfttestghosting.png


I've uploaded a sample here (http://www.mediafire.com/download.php?tdqiwqynztf).

[tritical]

Have you tried reducing tbsize and/or sigma, or running dfttest on a motion compensated version of the video? dfttest is definitely not immune to ghosting when using 3d filtering.

[mgh]

dfttest is excellent at removing compression artefacts such as blocking and also at removing the noise you get when capturing analog tv from mildly weak channels. Have seen its deblocking powers mentioned in other threads here but not in this one:)
Nothing else i have tried is as good as dfttest at presrving details.
thanks for a superb filter.

[lansing]

Have you tried reducing tbsize and/or sigma, or running dfttest on a motion compensated version of the video? dfttest is definitely not immune to ghosting when using 3d filtering.

I get what you mean now. I decreased the tbsize to 1 and the ghosting went away. Thanks for the help.

[yup]

Hi all!
I written simple script for deblocking VCD (my daughter have big collection anime on VCD and I want transfer to DVD replace 6-8 VCD to one DVD DL) result very good.
MPEG2Source("AVSEQ01.d2v",5,6,info=3)
source=ColorMatrix(hints=true)
sigma=110*1.5
sigmamc=110
sourcef=source.dfttest_dfttest(Y=true,U=false,V=false,tbsize=1,ftype=1,sbsize=8,sosize=6,sigma=sigma)
sourcef=sourcef.dfttest_dfttest(Y=false,U=true,V=true,tbsize=1,ftype=1,sbsize=16,sosize=12,sigma=1.5*sigma)
sclip = source.msuper()
sclipf = sourcef.msuper()
vf1=manalyse(sclipf,isb=false,delta=1,overlap=4,badSAD=1000)
vf2=manalyse(sclipf,isb=false,delta=2,overlap=4,badSAD=1000)
vf3=manalyse(sclipf,isb=false,delta=3,overlap=4,badSAD=1000)
vb1=manalyse(sclipf,isb=true,delta=1,overlap=4,badSAD=1000)
vb2=manalyse(sclipf,isb=true,delta=2,overlap=4,badSAD=1000)
vb3=manalyse(sclipf,isb=true,delta=3,overlap=4,badSAD=1000)

mcomp7 = interleave(\
mcompensate(source,sclip,vf3,thSCD1=600)\
, mcompensate(source,sclip,vf2,thSCD1=600)\
, mcompensate(source,sclip,vf1,thSCD1=600)\
, source\
, mcompensate(source,sclip,vb1,thSCD1=600)\
, mcompensate(source,sclip,vb2,thSCD1=600)\
, mcompensate(source,sclip,vb3,thSCD1=600))
chroma=mcomp7.dfttest_dfttest(Y=false,U=true,V=true,tbsize=7,ftype=1,sbsize=16,sosize=12,sigma=1.5*sigmamc).selectevery(7,3)
mcomp7.dfttest_dfttest(Y=true,U=false,V=false,tbsize=7,ftype=1,sbsize=8,sosize=6,sigma=sigmamc).selectevery(7,3)
MergeChroma(chroma)
#StackVertical(source,last)

I use different spatial block for luma and chroma, because it is YV12 and chroma resolution 2 time little than luma (please advice) .
Also I think will be useful find optimal matrix (sfile parameter) based on MPEG quantizer, but why? For analog capture I use only sigma and increase sigma for chroma.
Any suggestions, please welcome!
With kind regards yup.

[VincAlastor]

dfttest is to crazy slow for hd encoding. can i use the gpufftw library or a cuda library instead? (http://gamma.cs.unc.edu/GPUFFTW/)

[markanini]

dfttest is to crazy slow for hd encoding. can i use the gpufftw library or a cuda library instead? (http://gamma.cs.unc.edu/GPUFFTW/)
Wow, that would be sweet! :D

[Vitaliy Gorbatenko]

It seems the project abandoned. Have not updated. I think it should look for the implementation of FFT on Open-CL, as the most promising and unlike CUDA universal.

[Great Dragon]

It's a great filter you've made, tritical. Thanks.
And I have one question: can I disable completely a temporal filtering to use only spatial features?

[nonsens112]

It's a great filter you've made, tritical. Thanks.
And I have one question: can I disable completely a temporal filtering to use only spatial features?
tbsize=1 makes filter spatial.

[Dogway]

Im wondering whether this is the spiritual sucesor of tnlmeans. is it?
I use tnlmeans because its wonderful results on anime, although its deadly slow and blurs a little bit on undifined areas. Its also abandoned and not supported anymore.

Is there a setting on dfttest aimed at animation? or similar to tnlmeans(ax=3,ay=3,az=6,sx=2,sy=2,bx=1,by=1,h=0.6,a=1000.0,sse=false)

EDIT:
http://img64.imageshack.us/img64/9092/compac.th.png (http://img64.imageshack.us/img64/9092/compac.png)

[tritical]

dfttest isn't related to tnlmeans in any way other than being a denoiser. dfttest works in the frequency domain. tnlmeans is basically bilateral filtering with no distance weighting and similarity weighting based on local neighborhood similarity (difference) instead of individual pixel difference. The only way to find equivalent settings (if they even exist) is to test I'm afraid.

[Dogway]

Thanks for the answer. I added the adjective "spiritual" only because its the next denoiser you made after tnlmeans. I still havent fully tested dfttest but sigmas and tbsize, but results doesnt seem much animation oriented at defaults settings as tnlmeans thats why Im trying to speed up this one with MT+ms=true (doesnt seem to work) or find out a good dfttest setting for this kind of sources. But its good to know that unlike tnlmeans sse=false, dfttest doesnt have any specific setting which would undoubtedly work better in animation.

[foxyshadis]

I think the noise power spectrum analysis might be a little off, it smooths the image way out. For instance, I get this on one image:

0.013 18650.967 1413.832 255.401 143.324 45.611 0.009
43671.273 846.859 561.533 310.418 87.381 18.431 7.488
4325.101 438.551 167.673 90.019 45.118 18.157 23.700
134.528 189.763 4.576 86.177 57.927 23.606 24.473
13.794 7.955 4.505 34.447 15.854 4.820 5.515
2.716 2.340 6.929 0.477 0.114 0.087 0.327
11.135 3.224 0.270 0.179 0.501 0.372 0.417
2.716 3.802 0.464 1.590 0.274 0.150 0.327
13.794 26.689 67.291 47.565 6.188 7.503 5.515
134.528 1.487 60.844 123.280 64.566 35.531 24.473
4325.101 3644.524 187.824 80.187 130.267 33.799 23.700
43671.273 40664.180 1224.066 10.090 92.101 19.694 7.488


avg noise power = 2006.033321
The text file is just "0,0,486,368", and attached is the image that I used to create it. The script is:

ImageReader("C:\Temp\grafix\4454627606_fb119cdbfb_o.jpg",end=0).crop(0,0,0,-1).converttoyv12(matrix="pc.709")
dfttest(tbsize=1,nfile="nclip.txt")


On the other hand, when I crop the image to just that 12x12 square and use "0,0,0,0", I get this:
0.001 21.195 74.256 26.044 4.195 1.394 0.660
2.550 17.687 66.975 59.390 7.629 1.961 0.575
33.436 24.428 33.947 27.089 2.309 0.416 0.342
51.260 28.261 10.396 8.658 2.295 0.064 0.096
11.952 6.892 0.965 3.310 1.639 0.018 0.067
7.062 3.432 0.490 3.285 1.215 0.011 0.127
6.039 3.123 0.284 2.904 1.121 0.030 0.101
7.062 3.752 0.355 3.274 1.124 0.198 0.127
11.952 7.017 1.482 6.035 2.040 0.227 0.067
51.260 36.053 4.138 5.044 4.195 0.013 0.096
33.436 15.871 3.712 13.901 8.128 0.281 0.342
2.550 11.079 28.088 11.395 5.175 1.396 0.575


avg noise power = 10.156793
Which seems much more reasonable (it's rather chunky noise).

Edit: Further investigation reveals that the numbers keep increasing as the sbsize goes up.

[tritical]

I think you have x and y switched in nclip.txt. The ordering is:

frame_number,plane,y,x

If I use:

0,0,368,486

instead of

0,0,486,368

I get the same result as you show for the 12x12 cropped image. As far as dependence on sbsize/sosize/tbsize/tosize, the values are normalized based non-coherent power gain, and should be independent of window size (of course that only applies to ideal cases, such as different windows containing only white noise, etc...). Overlapping isn't considered when estimating the noise spectrum, but the estimated values are adjusted accordingly before use. If you continue to see any weirdness please let me know :thanks:.

[foxyshadis]

Thanks. Sorry for the bad call; given that I've been staring at the code in question all day, I have no excuse. Also, I made a patch which may or may not be of any use to you: It allows specifying nframe, nplane, nx, ny as arguments if you only want one set, without having to make a file. Also included is an experimental nclip parameter, where instead of specifying a location, it uses a naive random algorithm to find a suitable location in the blank area of an edge map. It's pretty half-baked right now. My original plan was to use tdtrans to find the farthest locations from any edge, but it wasn't really any better than just choosing a location at random.

For noisy edge maps, one of my work in progress is:

dn=dfttest(tbsize=1,sigma=40,sigma2=40)
ed1=dn.scalededge(1)
ed2=dn.scalededge(2)
ed4=dn.scalededge(4)
ed=average(ed1,.4,ed2,.4,ed4,.2).mt_binarize(64,chroma="process").removegrain(2)

function scalededge(clip c, int "scale") {
c
sm=Spline16Resize(m(2,width/scale),m(2,height/scale))
ved=sm.mt_convolution(horizontal="1 2 1",vertical="1 0 -1",chroma="process")
hed=sm.mt_convolution(vertical="1 2 1",horizontal="1 0 -1",chroma="process")
return mt_lutxy(hed,ved,expr="x y +",chroma="process").Spline16Resize(width,height)
}

dfttest(tbsize=1,nframe=0,nclip=ed)
There are probably more elegant ways of getting a good mask, but I'm a bit sleepy now.

[tritical]

Definitely good ideas. For some reason, trying automatic placement of the window for noise estimation never even crossed my mind. I'll try to get your changes added.

[dansrfe]

Is there any way to speed up dfttest() at default settings. I'm really happy with the results of this filter, but It's just way to slow to use in practice. I MT'd it but I still get about the same speed maybe a bit more.

[tritical]

dfttest is internally multithreaded so I wouldn't expect much if any speed increase from using MT. By default dfttest uses threads = # of processors... in some cases it might be faster with slightly more threads, but I've never tested that. First option to make it faster is decrease tbsize to 3 or 1 (default is 5). Second option is to decrease the amount of spatial overlap and increase the spatial window size. By default it uses a spatial window size of 12 with 9 overlap (75%). For the same window size less overlap will be faster. For the same overlap percentage, larger window size will be faster.

[dansrfe]

Thanks tcritical! Also can you post the documentation for dfttest so I can read up on all the options. I can't find the documentation anywhere.
Also do you have any plans to revise and upgrade dfttest in the future? :)

[Didée]

I can't find the documentation anywhere.
Huh? The documentation is included in dfttestv16.zip from tritical's page (http://web.missouri.edu/~kes25c).

[dansrfe]

*Oop's*, sorry about that. I had the dll downloaded a while ago and must have forgotten to save the documentation. I didn't look at the one place it had to be :eek:

Thanks Didée! :)

[tritical]

Posted v1.7. Changes:

+ added nstring/sstring/ssx/ssy/sst parameters and functionality
+ allow space as delimiter in input files
- fixed missing emms in sse routine for f0beta != (1.0 or 0.5) and ftype=0

Explanations for new parameters (from v1.8 readme):


nstring -

Same functionality as 'nfile', but allows entering window locations directly in
the script instead of creating a separate file. The list of frame/plane/ypos/xpos
quadruples is stored as a string with each quadruple separated by a space.
Example:

If you use an nfile that looks like:

a=4.0
35,0,45,68
28,0,23,87

You can use the following nstring and get the same result:

nstring="a:4.0 35,0,45,68 28,0,23,87"

The one restriction is that the oversubtraction factor (a:x.x) must be the first
entry in the string (as opposed to nfiles where the a=x.x can be placed anywhere).
If it is not supplied, then the same default oversubtraction factor is used as
is used for the nfile option.

default: ""


sstring/ssx/ssy/sst -

Used to specify functions of sigma based on frequency. If you want sigma to vary
based on frequency, then use 'sstring' instead of the 'sigma' parameter. sstring
allows you to enter values of sigma for different normalized [0.0,1.0] frequency
locations. Values for locations between the ones you explicitly specify are computed
via linear interpolation. The frequency range, which is dependent on sbsize/tbsize,
is normalized to [0.0,1.0] with 0.0 being the lowest frequency and 1.0 being the
highest frequency. You MUST specify sigma values for those end point locations
(0.0 and 1.0)! You can specify as many other locations as you wish, and they don't
have to be in any particular order. Each frequency/sigma pair is given as "f.f:s.s".
The list of frequency/sigma pairs is saved as a string, with each pair separated by
a space.

For example, if you want a linear ramp of sigma from 1.0 for the lowest frequency
to 10.0 for the highest frequency use:

sstring = "0.0:1.0 1.0:10.0"

"0.0:1.0" => this means sigma=1.0 at frequency 0.0

"1.0:10.0" => this means sigma=10.0 at frequency 1.0

Sigma values for frequencies between 0.0 and 1.0 will be computed via
linear interpolation.

Or if you want a band-stop filter that passes low and high frequencies (filters
middle frequencies) use something like:

sstring = "0.0:0.0 0.15:10.0 0.85:10.0 1.0:0.0"

To help visualize the process, the resulting filter spectrum is output to
"filter_spectrum-date_string.txt" using the same format as the "noise_spectrum.txt"
file that is output by the nfile/nstring options. The format of this file is compatible
with 'sfile' input.

There are two methods for computing sigma values for a given frequency bin based on
sstring. The first computes the normalized frequency location of each dimension
(horizontal,vertical,temporal), interpolates sigma for each of those dimensions,
and then multiples the individual sigmas to obtain the final sigma value. So that
everything scales correctly, all sigma values entered in sstring are first raised to
the 1/#_dimensions power before perform performing linear interpolation and multiplying.
The second method (based on fft3dfilter's system) works by computing a single location
from the seperate dimension locations (x,y,z) as:

new = sqrt((x*x+y*y+z*z)/3.0)

sigma is then interpolated to this location. By default the first system is used.
To use the second system simply put a '$' sign at the beginning of sstring as shown
below:

sstring = "$ 0.0:1.0 1.0:10.0"


---------------- ssx/ssy/sst explanation -------------------------------

sstring breaks the 1D (sbsize=1), 2D (for tbsize=1), or 3D (for sbsize>1 and tbsize>1)
frequency spectrum into chunks by normalizing each dimension to [0.0,1.0]... i.e. the
frequency range [0.0,0.25] is a cube covering the first 1/4 of each dimension. This works
fine if you want to treat all dimensions the same in terms of how sigma should vary.
However, if you wanted to ramp sigma based only on temporal frequency or horizontal
frequency, this is too limited. This is where ssx/ssy/sst come in!

ssx/ssy/sst allow you to specify sigma as a function of horizontal (ssx), vertical (ssy),
and temporal (sst) frequency only. The syntax is exactly the same as that of sstring. To
get the final sigma value for a frequency location, the three separate values (one for
each dimension) are computed and then multiplied together. As with sstring the sigma values
are first raised to the 1/#_dimensions power before performing linear interpolation and
multiplying. If you don't specify all three strings, then a flat function equal to the
'sigma' parameter is used for the missing dimensions. For dimensions of size one (the
spatial dimenions if sbsize=1 or the temporal dimension for tbsize=1) the corresponding
string is ignored.

For example:

ssx="0.0:1.0 1.0:10.0",ssy="0.0:1.0 1.0:10.0",sst="0.0:1.0 1.0:10.0"

will give the same result as

sstring="0.0:1.0 1.0:10.0"

Or if you want to ramp sigma based on temporal frequency:

sigma=10.0,sst="0.0:1.0 1.0:10.0"

This will use 10.0 for the horizontal/vertical dimensions, and ramp
sigma from 1.0 to 10.0 in the temporal dimension.

If 'sstring' is specified, it takes precedence over ssx/ssy/sst. Again, the
"filter_spectrum-date_string.txt" output file is helpful in visualizing the result.

default: ""


dither -

Controls whether dithering is performed when converting from float to unsigned char
for output. Internally dfttest works on floating point values. For output the
result must be quantized back to unsigned char values. Prior to v1.8 this was always
done by simply rounding. Possible settings:

0 - no dithering (same as v1.7 and prior)
1 - Floyd-Steinberg dithering
2-100 - Floyd-Steinberg dithering with increasing amounts of uniform random
noise added prior to the dithering process

Obviously dither=0 is the fastest, and dither=1 is slightly faster than dither>=2
due to not having to generate a random number for every pixel. However, this part
doesn't take much time compared to the actual filtering operation. dither=1 should
combat any banding introduced by dfttest's quantization, but probably wont help
banding in the source. At least, not anymore than the filtering itself. dither>=2 can
combat banding in the source that is left over after filtering.

default: 0

Needless to say 'nstring' came from foxyshadis' idea for not having to create a separate file. The sstring/ssx/ssy/sst I had been meaning to do for a while since it is a frequently requested feature.

For reference, the sigma4/sigma3/sigma2/sigma system of fft3dfilter converts to - sstring="$ 0.0:sigma4 0.1768:sigma3 0.3536:sigma2 1.0000:sigma". Note the '$', which makes dfttest use the second sstring method for determining sigma values.

[tritical]

Posted v1.8, changes:

+ added dither parameter and functionality
+ attach date string to filter_spectrum.txt and noise_spectrum.txt output
+ changed sstring handling and added option to function like fft3dfilter

See post above for more info on parameters.

[foxyshadis]

Wow, nice. Thanks!

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.

[Terranigma]

Thanks a lot for the update. After fiddling around with it, i've really come to love this new version, even more so than fft3dfilter in every conceivable way. :D

And oh yea, thanks for adding in my request. :)

[Lorax2161]

Thanks for your hard work on this. It just keeps getting better and better.

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?

Of course I presume this would make it slower, but it would only be for testing/analysis... not to be left on during an encode.

In any event, I really do appreciate your contributions.

:thanks:

[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.

[tormento]

Sob. If only it could be a little faster on HD contents.

Tritical: do you plan to update the x64 version too?