Dust - a noise remover

[Steady]

Hi all, I have returned from never-never land. I brought some magic dust back with me. Please give it a try.

edit - will keep latest version at the top of the thread.

[Guest]

Steady!!!!!!!!!!!!!

Welcome back. :eek: :D

It is GREAT to see you here again.

[digitize]

hmmm, i'll give it a try (on a noisey anime source).

[Kaiousama]

i can go in my noisy anime crypt to bring up a good beast for your filter.

It's testing time, yuppie !!

Welcome back and many many thanks for the new filter :sly:

[dividee]

Welcome back, Steady !
It's good to see you. I don't know if you read the forum lately, else you have a lot to catch up! ;)

[Steady]

Thanks for the warm welcome all:D Yes Dividee - I have been lurking for a few days and I feel liking I am starting over from scratch! Avisynth 2.5 with YV12 looks like a good idea that is long overdue. Convolution3d has taken a lot of the wind out of my sails since I had been comparing Dust to TemporalSmoother :eek:

Still dust is quite a bit different. It uses motion compensation for the temporal averaging, that is why it is so slow.(82% of the time is spent on motion search). It is going to get slower before it gets faster. I am looking at alternates to simple bilinear(mmx pavgbw) half pel interpolation. I read an interesting paper on using the phase shift information from an FFT for global motion compensation, a radiacal departure from the usual block matching.

It is fun to have a project to sink my teeth into:D

[FuPP]

Probably a stupid question, but is it an avisynth 2.5 filter, because I only get an exception error trying to use my new toy ?

Regards,
FuPP.

[Steady]

No, I am using 2.07 (not up to speed on 2.5 yet). What CPU do you have ? I have only tested it on my AthlonXP. It is possible some CPU specific code crept in. What error are you getting, illegal instruction ?

[FuPP]

I'm using avisynth 2.5... :D

Regards,
FuPP

[Steady]

Oops. PMULHRW is 3dnow! only isn't it? I hate to lose that proper rounding.

[Steady]

Okay, hopefully this version will run on Intel CPU's.

edit - old version 2 removed - newest version at the top of the thread.

[Steady]

Version 3 fixes the conflict with resize, random seeking issue and should fix all the major bugs.

Has anyone actually tried this? It really is quite good. Compressibilty gains of 10-50%

[SansGrip]

Originally posted by Steady
Has anyone actually tried this? It really is quite good. Compressibilty gains of 10-50% No, but I'm about to :D.

[SansGrip]

In a word: fantastic! Here's another one: stunning!

I just tried FaeryDust on a fairly noisy DVD source (Death To Smoochy) and the difference was like night and day. I've honestly never seen that dramatic a result from a denoiser before. I can't wait to try PixieDust on my next capture...

I did notice the scene-change weirdness (occasionally), but didn't spot any motion problems. No ghosting either, of course. Is scene-change detection that hard to add? Can we expect it from v4? Demanding? Me? ;)

It's slow, too, but that's not surprising if you're doing ME. Is it all in iSSE, i.e. is the only possible speed-up an algorithmic change?

Any chance you'll release the source? I'd love to see how this magic happens :).

[SansGrip]

Forgot to mention, I did see a tiny bit of detail-loss on very subtle surfaces (a woman's red sweater lost some very gentle shadows, for example). Is a strength parameter out of the question?

[Shamballa]

WHAT THE HELL OF THIS FILTER4S O_o i never see that maybe i have alucination i simply perfect he beat all denoiser of all time and the compresability is fabulous >_< please please don't stop the development of goldust ! thx a lot for have see that one time in my life ;_;

[MaTTeR]

Initial testing here seems to look very good indeed. Very evil things happen when trying it with AVS 2.5 of course.

Can't wait to see a YV12 version of it though (I'm sure I can speak for iago on this as well :-)). Keep up the great work!

Edit- Oh, I was getting 5-7FPS with Dual Athlon 1600s and 512MB DDR RAM.

[iago]

@Matt,

Hehe, I'm back man, though fairly declined and terribly limited after the latest motherboard disaster I had! :D

Dust! Nice name!
Gonna be tested on U-Turn soon! ;)

regards,
iago

edit - guess it will finish in a fortnight's time on my new system! :D

[SansGrip]

Originally posted by MaTTeR
Edit- Oh, I was getting 5-7FPS with Dual Athlon 1600s and 512MB DDR RAM. Ouch ;).

[Dali Lama]

Sorry, but may I ask how everyone knows Steady? I see he/she has a low post number and has been away for a long time, but is a moderator? I've been here for a while but have never seen this person.

Well anyways, I will test your filter out once its in YV12 (I hope) ...or until I finish my current encoding (I always love trying new denoisers out) ;)

Anxious,

Dali

[SansGrip]

@Steady

On closer inspection I see the weird artifacts you mention with fast motion -- looks almost like the chroma isn't "keeping up" with the luma. It's a shame, because I can't wait to start using this filter in my encodes :).

[FuPP]

OK, found some time to make a few tests : this one seems very promising (even better than Peach it semt to me, sorry HSD ;) )

I've seen 'artifacts' on scene changes, and sometimes on motion.

do you plan to add parameters (strength, thresholds and so on) ?

Nice work! (yv12 ?:D )

Bye,
FuPP.

[UGAthecat]

Originally posted by Dali Lama
Sorry, but may I ask how everyone knows Steady? I see he/she has a low post number and has been away for a long time, but is a moderator? I've been here for a while but have never seen this person.
I was a lurker for well over a year before I signed up, and while I don't recall the last post I've seen from Steady, he has definitely been around for a while, I'll leave you to the search function if you are really curious about him :)

anyway, @steady...
speaking of my first post, the reason I signed up originally was to request a filter that does exactly what dust does :)
haven't tested it yet, but from what everyone is saying, looks like you've come up with something incredible!

[Steady]

Posted version 4. This adds scene change detection. This will probably be the last version for a while (barring bug fixes). Most of the changes I have in mind now will require fairly major rewrites.
SansGrip:
I did notice the scene-change weirdness (occasionally), but didn't spot any motion problems. No ghosting either, of course. Is scene-change detection that hard to add? Can we expect it from v4? Demanding? Me?

It's slow, too, but that's not surprising if you're doing ME. Is it all in iSSE, i.e. is the only possible speed-up an algorithmic change?

Scene change detector is done but I am sure it will need some tuning.
It is mostly written in mmx/assembler. The main speed limition is in memory access, and I am using 8x8 blocks; so going to xmm (SSE) would not help much.
On closer inspection I see the weird artifacts you mention with fast motion -- looks almost like the chroma isn't "keeping up" with the luma. It's a shame, because I can't wait to start using this filter in my encodes .
The search range is currently very limited (+-24 H, +-15 V) This is hard wired into the wide search. I may add a quick and dirty temporary hack to abort gracefully if it can't find a good match, but a complete rewrite of the wide search is next on my list. Eventually it will use more sophisticated prediction techniques and this is where it will start to speed up. Right now, when there is significant motion, it has to basically search each frame 187 times over which is going to be slow no matter how optimized the code is.
Can't wait to see a YV12 version of it though (I'm sure I can speak for iago on this as well :-)). Keep up the great work!
Internally it keeps its own YUV 4:4:4 buffers, with routines to copy to/from YUY2/RGB24/RGB32. It shouldn't be to hard to add YV12 support once I get time to look at the specs. I'll also add an 'output="YUY2/RGB..."' parameter so you can output a different format from the input.

[SansGrip]

Originally posted by Steady
Posted version 4. This adds scene change detection. This will probably be the last version for a while (barring bug fixes). Does this version fix the artifacts during fast motion?

Most of the changes I have in mind now will require fairly major rewrites. It's definitely worth it. This promises to be a great filter :).

Right now, when there is significant motion, it has to basically search each frame 187 times over Yikes. Yes, I think that answered my question: the speed is an algorithmic problem ;).

It shouldn't be to hard to add YV12 support If you're keeping your own 4:4:4 buffers then that'll make things easier. The biggest challenge for me in porting from YUY2 to YV12 is the packed/planar difference. Of course it depends on the algorithm.

Keep up the good work -- I'm looking forward to using this one on a regular basis :).

BTW, maybe releasing the source would help? I believe Vlad got a significant number of suggestions for algorithmic improvement from those who'd seen the source code. It can only make things better.

[Shamballa]

thanks a lot for you filter i will tested the last version i have bug in travelling in vp3 version i hope his gone ^^

[Guest]

Originally posted by Dali Lama
Sorry, but may I ask how everyone knows Steady? I see he/she has a low post number and has been away for a long time, but is a moderator? I've been here for a while but have never seen this person. Well, for me it was three lives ago, during the Civil War. He wasn't as good a shot as I was with the musket but his tactical sense was extraordinary.

[SansGrip]

Originally posted by neuron2
He wasn't as good a shot as I was with the musket but his tactical sense was extraordinary. I'm glad you both traded in your muskets for compilers ;).

[High Speed Dubb]

FuPP wrote
even better than Peach it semt to me, sorry HSD ;)

So sad. ;) The Peach has some pretty heavy design limitations &mdash; It&rsquo;s a single pass algorithm, there&rsquo;s no inference of the direction of motion, and each pixel looks at just one other pixel at the same location for averaging. (It&rsquo;s primarily a DScaler filter, and it needs to run in real time.) So it should be possible to improve on it.

[onesoul]

Just a little joke @Steady: I guess your nick doesn't do justice to you :)

[vlad59]

Originally posted by neuron2
Well, for me it was three lives ago, during the Civil War. He wasn't as good a shot as I was with the musket but his tactical sense was extraordinary.

ROTFL :D

@Steady

Wahoooo excellent work, that a really good denoiser. BRAVO !!!!

[vidiot]

...is it faster than DusTPanC ???
And is it also good for interlaced to interlaced conversions?
(DV to DVD or SVCD)
(I know I could easily try, but I´m a lazy lamer):D

Surely great work (I liked DustpanC, but it was to slow for my old Duron...)

Harald

[Guest]

Originally posted by vidiot
And is it also good for interlaced to interlaced conversions?
Do it this way:

SeparateFields()
filter of choice here
Weave()

That's how I use MSharpen() on interlaced source. Then I deinterlace afterwards. If you apply MSharpen() after deinterlacing, you amplify residual combing that normally can't be seen.

[onesoul]

By what has been suggested by others if the filter applied works in a temporal manner you should apply the filter separately to each field, something like this:
separatefields()
e=selecteven().filter()
o=selectodd().filter()
interleave(e,o)
weave()

[High Speed Dubb]

It&rsquo;s probably a good idea for any temporal smoother to include code like

if( vi.field_based == TRUE )
lastFrameNum = -2
else
lastFrameNum = -1
That way the filter will handle interlaced material correctly without needing any extra manipulation &mdash; at least if vi.field_based is accurate.

[Dali Lama]

Originally posted by neuron2
If you apply MSharpen() after deinterlacing, you amplify residual combing that normally can't be seen.

That's a really smart idea. I never thought about that.

Oh, I think I found out that Steady worked on AVISynth 1.x, correct?

Bye,

Dali

Edit: Why doesn't the latest version of Dust contain a heavy noise level. I forgot what it was called in previous versions...probably Espestos Dust :scared: :D

[Steady]

Because of the way it works internally, it should work reasonably well on interlaced source. A better method is the one suggested by onesoul and neuron2 if you want to keep the intelace.
Originally posted by onesoul
By what has been suggested by others if the filter applied works in a temporal manner you should apply the filter separately to each field, something like this:
separatefields()
e=selecteven().filter()
o=selectodd().filter()
interleave(e,o)
weave()
I think bob deint is to often neglected and is the best method for high-motion material.
#ComplementParity ##I need this
bob
noisefilter()
SelectEven #delete for 60/50 fps output
If you leave out the SelectEven you can take advantage of the higher temporal resolution of true interlaced material. You might also want to use VerticalReduceBy2 to keep the pixel rate the same as the original. I mainly use Sasami2k for a player and it can correct the aspect ratio on the fly.

[vidiot]

Thanx to all for enligthen me...

I´ve so many troubles with DV Files (Codecs that causes Field Shifts ect.) in the past and even today I couldn´t take just "one way" for the whole process.
But it´s getting better and better...

Kind regards
Harald
(This thread is about Dust - sorry for this OT things)

[onesoul]

To achieve the best possible quality (slower too) you should do like Bach mentioned but the other method is quite good also.
Another way of creating a interlaced video after 50fps is, quoting sh0dan:
assumeframebased()
doubleweave()
assumefps(25)

Quite nice :)

[SansGrip]

@Steady

Just thought I'd let you know I'm getting outstanding MPEG-1 encodes using FaeryDust (to denoise) and C3D preset="movieHQ" (to smooth). Compression ratios have drastically improved. LOTR on two CDs can't be bad :D.

Anxiously awaiting a version without the high-motion blockiness. Speed will come eventually ;).

[Valky]

Just tested with tv-capture, with lot of noise and resolution was 448x256. This is the best de-noise ever! I have tried every one of them, but this was amazing! Of course it blurs picture, but still it also removed almost every noise there was visible for me and now the file is perfect when watching through tv-out.

I wish I would had this filter before when I backupped some of my old vhs-tapes.

I used now the medium filter, cause the heaviest was disabled? Still it did all I could ever expect so I dont really need taht heavy choice. I got 18 fps in virtua-dub for the first couple of minutes, but after that the speed decreased to 12 fps and stayed there..any reason for this?

My system is Athlon 1700+ XP, WIN XP, 1Gb ram and now other filters were included during the de-noise and codec was Huffy.

[Bulletproof]

Hey it sounds pretty cool, I'm eagerly awaiting a YV12 version :p, I think I did try dustpan a while ago and it did work pretty decent, however I think I remember it being really slow.

[Steady]

Originally posted by Valky
I used now the medium filter, cause the heaviest was disabled? Still it did all I could ever expect so I dont really need taht heavy choice. I got 18 fps in virtua-dub for the first couple of minutes, but after that the speed decreased to 12 fps and stayed there..any reason for this?
Golddust is on hold for a bit. For heavier filter I need more frames and it is slow enough already. Also with stronger settings, weakness in the motion search accuracy starts to look bad.

The speed depends on how often it has to use the wide search. The local search is relatively fast. On my AthlonXP1900+ I get about 15fps in fairly still scenes and 5fps with lots of motion.
Originally posted by Bulletproof
I think I did try dustpan a while ago and it did work pretty decent, however I think I remember it being really slow.

This filter really has no relationship to DustPanC except in the sense of lessons learned and all that.

Bear in mind that I consider this to be an Alpha release. I have many ideas to explore. The blurring mostly comes from simple bilinear half-pel interpolation. I am working on 4-tap bicubic (Catmull-Rom) subpixel interpolation. That should do clear up a great deal of the detail loss.

Right now the only difference between Faerydust and Pixiedust is the strength setting. It will not remain that way. Faerydust assumes a clean source and is intended to preserve maximum detail. It has a minimum of spatial filtering. Pixiedust assumes clear video but with noticable noise (The Hunt for Red October is a major source of Pixie test clips - sharp but noisy video). The setting is stronger and it is more aggressive in applying spatial smoothing. Golddust will assume your cable company is as bad as mine. It will start with complete spatial smoothing and restore sharpness in high-detail areas.

You would probably be surprised to learn just how light the filtering is. Faerydust adjusts a source pixel by a maximum of 2 (<1%), Pixie a maximum of 4.

[Milkman Dan]

Originally posted by Steady
Pixiedust assumes clear video but with noticable noise (The Hunt for Red October is a major source of Pixie test clips - sharp but noisy video).


Hell YES. Christ, that has the be the nastiest transfer I've ever seen to a DVD. I practically had a coronary when I saw the video like that on one of my favorite movies.

[/rant]

[iago]

I must say that, after a couple of short test encodes with Matrix, I'm really impressed by the compressibility gain it offers and the level of details preserved together with such considerable increase in compressibility.

regards,
iago

[wotef]

blimey, this is a good filter!

[SansGrip]

Originally posted by wotef
blimey, this is a good filter! No kidding ;). I think this one deserves a C3D-like joint effort to squeeze some more performance out of it -- when Steady's done his rewrite, of course...

[MaTTeR]

Originally posted by SansGrip
like joint effort to squeeze some more performance out of it Yeh, like multi-threading:D

[SansGrip]

Originally posted by MaTTeR
Yeh, like multi-threading:D Would that be useful for those with uniprocessor machines? I've never been quite clear on that ;).

[MaTTeR]

Originally posted by SansGrip
Would that be useful for those with uniprocessor machines? Doubt it would effect uniprocessor machines either way. You may have noticed more and more users on here with dualies though, they are way too cheap these days;) Year ago, maybe 3-4 ppl on Doom9 had them; that quickly changed.

I mentioned it specifically for this filter since it's obviously _very_ CPU intensive. I average between 57-59% CPU usage using the filter, without the filter I easily see 93-96%.

[SansGrip]

Originally posted by MaTTeR
You may have noticed more and more users on here with dualies though, they are way too cheap these days;) I nearly got a dual system last time I upgraded (a few months ago) but couldn't quite afford it. Next time :D.

If the filter's already written in MMX, though, there's not that much scope for optimization other than algorithmic. This might be a good candidate to include in an encoder, since it's doing ME anyway...

[soulfx]

I must say, nice work on this filter.

I ran a couple tests and found it does a great job at de-noising without sacraficing detail. I did notice the blocking during motion, but it's not really too bad and with C3D it's even less noticable.

I've been workin with Peach for a while, but really like where Dust is heading. Peach does a great job for the speed it goes at, but for really taking out the noise, this filter's great. Dust drops my fps down to 1-4, but hey, my computer doesn't mind the work.

By itself Dust doesn't handle interlaced content very well. I had to seperate the fields, filter, and weave, in order to get the results I was looking for. Maybe something could be worked in to future versions were it can handle this content better by itself?

*Sigh* I too dream of a day in which I have a MP machine.

Keep up the great work, Steady.

[Acaila]

I am seeing something I can only describe as "checkerboard-patterns" appearing in the frames directly before and directly after scene changes. It is more pronounced with Pixiedust than with Faerydust.

I'm using a bare-bones avisynth script with only BicubicResizing (before resizing) and am using it with Avisynth 2.07.

If you're interested I can attach a picture later.

Btw, are there special requirements regarding width and height MOD for these filters? I get the above with cropping to width MOD 4 and height MOD 8.

EDIT: Also, both filters create a black line of about 2-3 pixels wide at the right side of each frame.

[bb]

@Steady:
I wonder whether it would be possible for your filter to use XviD's or DivX5's mv hint files to work faster. I'm asking myself if it's really necessary to do the motion search twice (encoder and denoiser).

bb

[FuPP]

aren't you assuming that all people encode with divx or xvid ? What about mpeg1 or mpeg2 encodes ? Or may be I didn't get you...

[MfA]

XviD cant efficiently use hintfiles at the moment, when it can it might be usefull for dust to write hint-files (that would be better than reading them, for one it would work with 1-pass coding too and also XviD's motion search tries to minimize rate instead of finding "true" motion). It is not an issue at the moment though.

FuPP, which MPEG1/2 encoders can use motion hint files?

[onesoul]

Originally posted by SansGrip
Would that be useful for those with uniprocessor machines? Hi. The new processor of intel the Pentium IV with hyper threading can work on two separate threads of an aplication, running as a dual processor does. Only the processor of 3.06 ghz or higher support HT and requires a specific chipset and also an OS (Windows Xp supports it). The bad thing is that is expensive, here at Portugal the PIV costs 846€. The board has a "normal" price.

[Steady]

First let me stress that this is a very early release. It will be continue to develop not in a matter of days or even weeks but months. I had not really intended to release it for a couple of months but was so surprised at how effective this "first generation" version is that I decided to put it out. It is all to easy to get 'tunnel vision' when writing, and the feedback helps me keep the priorities straight.
bb asks
I wonder whether it would be possible for your filter to use XviD's or DivX5's mv hint files to work faster. I'm asking myself if it's really necessary to do the motion search twice (encoder and denoiser).
The short answer is no. On the surface, motion search for an encoder and for noise removal would seem the same. As you get into the details they become more different. It starts with different goals: An encoder wants to find the closest match to minimize the differences it needs to encode. My filter needs to find the same area in the screen; which may or may not be the the closest match. In low-detail areas with heavy noise it will almost certainly not be the closest match (lowest SAD). The presence of noise greatly complicates a motion search (and without noise there is no point). There are many more differences. My subpixel precision needs to be much better than an encoder, which it isn't yet. Also an encoder uses 16x16 blocks. I use 8x8 blocks. Down the road I may start with 16x16 blocks for the wide search, 8x8 for local search, and 4x4 for subpixel interpolation.
Acaila mentioned
I am seeing something I can only describe as "checkerboard-patterns" appearing in the frames directly before and directly after scene changes. It is more pronounced with Pixiedust than with Faerydust.

Btw, are there special requirements regarding width and height MOD for these filters? I get the above with cropping to width MOD 4 and height MOD 8.

I am guessing that is with fairly dark scenes?
The scene change detector will need tuning. I need to adjust the threshold to the overall screen brightness.

I should have mentioned the size needs to be a multiple of 8. Any remainder after dividing by 8 will not be filtered on the right and bottom edges (though it will be used for the motion search).


I am currently working on the "blockiness with motion" issue. It is turning out to be be a deeper and trickier issue than I had originally thought. It will probably require another level of pre-filtering which will slow things down further (sigh). If it works, a pleasant side effect will be a much improved ability to deal with changes in brightness.

[bb]

Steady,

thanks for clarifying. I somehow had the feeling it wouldn't be that easy...

bb

[MfA]

Originally posted by Steady
The short answer is no. On the surface, motion search for an encoder and for noise removal would seem the same. As you get into the details they become more different. It starts with different goals: An encoder wants to find the closest match to minimize the differences it needs to encode.

Not entirely true, it tries to find the match which takes the least bits to encode ... with modern ME this takes into account the amount of bits needed for the motion vector. The end effect is not too much unlike the smoothness constraint you would find in "true" ME, although especially at higher levels of quantization it tends to smooth out the motion field more and ignore small changes (since sometimes its easier to just encode the differences than to encode the "correct" motion vector).

My filter needs to find the same area in the screen; which may or may not be the the closest match. In low-detail areas with heavy noise it will almost certainly not be the closest match (lowest SAD). The presence of noise greatly complicates a motion search (and without noise there is no point). There are many more differences.

Still the found motion vectors would provide great candidates for a new motion search, even if that one is rate optimal. Especially at motion-discontinuities/edges having a MV candidate which allowed you to skip most of the gradient search for the new surface inside the encoder might provide a decent speedup.

XviD cant use hints in this way at the moment, it just reuses them as is, but it might in the future.

My subpixel precision needs to be much better than an encoder, which it isn't yet.

Have you read Thomas Wedi's stuff on wiener interpolation filters (http://www.tnt.uni-hannover.de/~wedi/papers-html/EI01-TW.html)?

Additionally you might be interested in better matching criteria, changes in illumination arent the only problem ... motion discontinuities cause large motion vector errors. Dirk Farin has some nice pictures in one of his papers (http://www.informatik.uni-mannheim.de/informatik/pi4/publications/library/Farin2001c.pdf) showing the effect when using the MSE criteria, I doubt SAD does any better. His solution to the problem is rather compute intensive though. I have seen ME which performed matching in horizontiallly and vertically sobel filtered images, simply summing SADs for both, which seems more practical (this is also mostly insensitive to illumination changes since it ignores the DC component).

Also an encoder uses 16x16 blocks. I use 8x8 blocks. Down the road I may start with 16x16 blocks for the wide search, 8x8 for local search, and 4x4 for subpixel interpolation.

Are you sure that is wise? In XviD a coarse to fine search makes sense, for 4MV, since most for most MBs the fine search is never done. If all MVs have to be eventually found at the finest level Im not sure if it still makes sense though, I doubt the coarse MV is a better predictor than the median predictor at the finest level ... you might even end up having to do more work.

Marco

[DVD__GR]

I tried it in interlaced source and use smartdeinterlace with blend denoise and feild only difference,i can tell it cleaned some shitty areas and improved a bit the compressibility (i encoded to svcd via cce) but ITS TERRIBLY SLOW.!!
nevertheless its pretty good..
Congratulation for your work
(could we expect more speed in future??)

[digitize]

Im sure Steady is trying his hardest to optimize this filter, but would you rather speed and mediocre (sp?) results, or great results and not too good speed, personally I'd go for the latter. But like I said Im sure Steady is working his hardest, good work Steady ;)

[Boulder]

Seems like a very powerful denoiser, but unfortunately too slow for me as I can't keep my computer running at nighttime. I'll have to wait for the speed version (AngelDust?) then;) The quality is really excellent!

[Steady]

Originally posted by MfA
Have you read Thomas Wedi's stuff on wiener interpolation filters (http://www.tnt.uni-hannover.de/~wedi/papers-html/EI01-TW.html)?
1)
Additionally you might be interested in better matching criteria, changes in illumination arent the only problem ... motion discontinuities cause large motion vector errors. Dirk Farin has some nice pictures in one of his papers (http://www.informatik.uni-mannheim.de/informatik/pi4/publications/library/Farin2001c.pdf) showing the effect when using the MSE criteria, I doubt SAD does any better. His solution to the problem is rather compute intensive though. I have seen ME which performed matching in horizontiallly and vertically sobel filtered images, simply summing SADs for both, which seems more practical (this is also mostly insensitive to illumination changes since it ignores the DC component).

Those are some interesting papers thank-you. (Don't you just hate those postscript to .pdf files?) Do you know offhand where I can find a paper on wiener filters - preferably less calculus intensive (I could care less about proofs and such). I am going to start out with a 4-tap catmull-rom filter. The weights for tau=0.5 are -1/16, 9/16,9/16,-1/16. I may be able to do this using just shifts and adds without even unpacking to word. Later I will look at filters with greater extent. I also see I how will implement the subpixel search. I will use a 'logarithmic diamond search' that starts with the 4 half-pels left,right,top,bottom; then does 1/4-pel search around the best; down to 1/8 pel. This should be a good comprimise between speed and accuracy (though not all possible positions can be reached - particularly on the diagonals).

edit: Yesterday I looked at adding highpass filtering to remove the DC component (just a quick and dirty IIR filter that simulates a 1-capacitor, 1-resistor filter). It didn't seem to help any. I thought about adding 7x7 or so general convolution FIR filter. But that would be quite slow for a minor improvement. (I already use a 3x3 1 2 1 filter to remove the worst of the noise and improve neighbor-pixel similarity)

edit edit: Stupid me, I forgot you can't shift bytes in mmx.

[trbarry]

I don't know the filter math but can't you remove the DC component just by subtracting the average?

- Tom

[Steady]

Yeah, but how do you get the average? That is where the 7x7 would come in - average 48 pixels together and remove that from the current pixel.

[MfA]

Originally posted by Steady
Those are some interesting papers thank-you. (Don't you just hate those postscript to .pdf files?)

As long as I can do text search and its mostly readable I dont care much, it should look ok when printed.

Do you know offhand where I can find a paper on wiener filters - preferably less calculus intensive (I could care less about proofs and such).

No ... but the filter taps are in the paper, calculus wise that is about as low intensity as it is going to get :)

I am going to start out with a 4-tap catmull-rom filter. The weights for tau=0.5 are -1/16, 9/16,9/16,-1/16. I may be able to do this using just shifts and adds without even unpacking to word.

I doubt it will be faster than simply using multiplies with MMX.

Yesterday I looked at adding highpass filtering to remove the DC component (just a quick and dirty IIR filter that simulates a 1-capacitor, 1-resistor filter). It didn't seem to help any.

The more usual approach is to simply take the average of the block and subtract it (you can use a summed area table to quickly find the average for an arbitrary block during ME). One problem is that the DC component plays a big role when you are doing a gradient search though.

Just removing the influence of illumination on ME is only half the problem though, what are you going to do after you find the correct motion? Is simply calculating a scale factor for luma before applying the temporal filtering enough?

Marco

PS. on second thought, for 8x8 blocks it is probably better to just calculate the average on the fly.

[Shamballa]

what's going on on Version 4 ??? see that the first is v3 version et the second v4 version ^^


http://www.lance-dragon.com/images/dustv3.jpg




http://www.lance-dragon.com/images/dustv4.jpg


i precise a have this litle white point in a lot of darknes scene is exactly the same problem i had with the refdivx lumimasking when is buging (is fixed now) i hope i can help you in this beautiful filter's

[SansGrip]

Originally posted by Shamballa
i precise a have this litle white point in a lot of darknes scene Looks like overflow to me. I've never seen this with v4.

[Shamballa]

the ref lumi masquing is based on wavelet code is my memory is good if that can help i have tested it on another anime and i have it too. you can see the image is more crapi too with the v4 i precise i use the parametre fairies() (is have tried pixies too is the bug)

[Steady]

Originally posted by Shamballa
I have these little white points in a lot of dark scenes.
Can you post a link to a very small clip that shows this problem? (10 frames or so). I am on dial-up so I cannot download large files.

I am close to releasing version 5 which will reduce blockiness. The fix will probably be in that version.

[Shamballa]

mm i was removed all other filter i forget only one filter i can imagine have effect on the denoiser is a filter of color (coloryuy2) if i load the video with only coloryuy2 no problem when i load with only dustv4 no problem but when i put this 2 filter i have this white atrifact but when i put dustv3 and coloryuy i have no problem so it's only a problem of cohabitation in the dustv4 ^^ sorry for not have found sooner .....:(

if you want tested :

http://www.lance-dragon.com/images/sample.avi

[trbarry]

edit: Yesterday I looked at adding highpass filtering to remove the DC component (just a quick and dirty IIR filter that simulates a 1-capacitor, 1-resistor filter). It didn't seem to help any. I thought about adding 7x7 or so general convolution FIR filter. But that would be quite slow for a minor improvement. (I already use a 3x3 1 2 1 filter to remove the worst of the noise and improve neighbor-pixel similarity)

FWIW, the psadbw instruction calcs the sum of abs byte differences. So when compared to zeros it calcs the sum of 8 unsigned bytes. Thus it's fast for calculating area avgs (8 wide). But for MMXSSE only.

- Tom

[SansGrip]

Originally posted by trbarry
But for MMXSSE only. Isn't it iSSE?

[trbarry]

SansGrip -

Dunno. Is this just terminology or do I have the wrong collection of machines. I always just called it SSE suport until I realized that I only use integer SSE, which is okay with Athlons. And code like Xvid calls it SSEMMX or MMXSSE so I started to also.

But maybe I have the completely wrong generation of support here. ??

- Tom

[MfA]

Oops I just realized that the link to the Dirk Farin paper I gave was a different file than I had on my own HD ... I converted the PS version also available on the web myself, in which case you do get a text searchable version.

[Steady]

Originally posted by trbarry
FWIW, the psadbw instruction calcs the sum of abs byte differences. So when compared to zeros it calcs the sum of 8 unsigned bytes. Thus it's fast for calculating area avgs (8 wide). But for MMXSSE only.

- Tom
I use psadbw heavily in the search algorithm. With everyone complaining about how slow it is, I was hoping to avoid another pre-filtering/analysis pass, but it looks like I am going to need the average luma for several different things.

I think of psadbw as MMX+ or extended MMX. I think the confusion comes from Intel and AMD putting the same instructions in different class names. AMD is the main culprit here, and their documentation is almost non-existant (at least on their public website). I have to use Intel docs for instruction set reference. I can find no complete reference anywhere on AMD's site.

I know people want more speed from this filter, but it is going to be a long time coming. It is under heavy development/experimentation. I don't want to waste a lot of time optimizing routines for speed when I will just have to throw them out later when that routine gets superceeded.

[Steady]

Shamballa: I cannot recreate the problem. Can you post your exact script? Also is you CPU Intel or AMD?

[sh0dan]

Look for "MMX Extensions" on AMD's site - or go to my CVS-bin site (see sig.) I put up a lot of assembler documentation there. Download the "3D Now MMX extensions.pdf".

[SansGrip]

Originally posted by trbarry
I always just called it SSE suport until I realized that I only use integer SSE, which is okay with Athlons. To me MMX means either simply "multimedia extensions" or refers to the first version of MMX that was introduced with the Pentium Pro (I think). SSE is the next step up (Pentium IIs?) and iSSE next from there (Pentium IIIs), and finally we have SSE2 (Pentium IVs).

The only reason I ask is because if that instruction is from iSSE it'll only work on Pentium IIIs and above. Probably not a big concern, but there you go ;).

[vlad59]

@SansGrip

MMX -> Pentium MMX, Pentium II, K6, K6II, K6III and later
iSSE -> Pentium III, all Duron (called 3DNow extension), all Athlon (called 3DNow extension)
SSE -> Pentium III, Duron (core Morgan), Athlon XP and later
SSE2 -> PIV

I hope I'm right ;)

[Shamballa]

i have put the detail in pm for personale reason ^^ for shodan are you still interested to know what is the interpolation in coloryuy site ? i can try translate it if you want ;)

[d4Rk Ch1Ld]

i wonder will there be any version of Dust for avisynth 2.5a ?
it would be interesting if someone converts it...

[Koke]

Originally posted by d4Rk Ch1Ld
i wonder will there be any version of Dust for avisynth 2.5a ?
it would be interesting if someone converts it...

So it doesn`t work on 2.5a?

Hi Junior!

[d4Rk Ch1Ld]

Originally posted by Koke
So it doesn`t work on 2.5a?

Hi Junior!

just because i mostly observe and read post and dont take a part of discussion in them doesnt mean i am junior ;)

and yap it crashes 2.5a :( tried with 2.07... it does some great job on noisy material but its damn slow i'll rather use in that case c3d or smoothflux and undot with 2.5a and optimized mpeg2dec3, get same results with faster processing...

but its up to the author if he is going to put version of 2.5a version of plugin... catch ja on h.r.d ;)

[Koke]

Originally posted by d4Rk Ch1Ld
just because i mostly observe and read post and dont take a part of discussion in them doesnt mean i am junior ;)

Ups!
I forgot to draw a :p !
I was kiddin, of course...

I`m encoding Gattaca right now.
17 hrs first pass done soon :eek:.
It flies at 2-3 fps on celeron@900.
It flies like hell :).
So I set priority on lowest and
my PC is still usable.

Adio!

[d4Rk Ch1Ld]

Originally posted by Koke
Ups!
I forgot to draw a :p !
I was kiddin, of course...

I`m encoding Gattaca right now.
17 hrs first pass done soon :eek:.
It flies at 2-3 fps on celeron@900.
It flies like hell :).
So I set priority on lowest and
my PC is still usable.

Adio!

i tried it... got 20 fps on black screens (Credits and intro ;))
and then fps dropped around 8-12 fps

got p4 1.8 GHz(northwood) @ 2.4 GHz(533fsb)

[Steady]

Version 5 posted

This version should greatly reduce the blockiness with motion issue. It has many internal changes.

Two new filters introduced.
GoldDust Heavy filtering for more serious problems. This one will definately blur the image, so it recommended you use it before resizing smaller.

SpaceDust This fast filter is spatial only. For those complaining about how slow Dust it:)

[Koke]

Man, you are fast!
2 hrs more to finish my Gattaca 2nd pass vith dust4,
and I have a new dust to try.
Me happy.:)
Thanks

[Candock]

:( just used 8 hours to finish the filtering of a incredible noisy 42min-movie with dust4.

[mikeson]

@Steady:

Many thanks for new version of this great filter!

May I ask what about AviSynth 2.5 support?

[lancer]

nice filter.

came across this yesterday on the forum. in combination with msharpen and convolution if gets rid of some nasty grain.

god, disc 1 side 1 and 2 on star wars are bloody awful. dead soft, lot of grain. side 2 disc 1 on empire is not great either.

convolution was a lot better on color areas than 2dcleaner but I still had spotty grain. if I lofted it's variables too high the detail disappeared. but faerydust is all over them.

neat

[onesoul]

I have to share my thoughts cause I am just a noob :)
I am ashamed but I admit that first when Steady appeared with this dust filter I was in doubt of it (there are so many filters and not always do what we would like), and not even have ever heard of Steady it doubled my doubts. I was wrong.
I see now dust as a pearl and I belive it will become the ultimate denoise filter.
I have not done any really encodings, just tests, and here is what I have done: I grabbed a divx(movie on 700mb) and put as the source on avscompare (the ones who didn't try it yet, please do, it's great) and I compared fluxsmooth(15,10), convolution3d(preset="movieLQ"), nomosmooth(), dnr2(), pixiedust() and no filter at 1 one frame. With no doubt pixiedust was the winner, and when I zoomed the picture I was amazed by the quality achieved (not blocky, fine detail), none of the other filters or no filter at all would match pixiedust.

I will use dust from now on. Great work Steady. :)

[^^-+I4004+-^^]

and now add some peaches and grapes....,and test again...

[digitize]

@Steady
Perhaps this has been asked before, but I haven't seen it so I'll go ahead and ask. What is the spacial matrix for the spacial cleaning part of this filter? Im guessing it is 3x3 like C3D, but I could be wrong. And keep up the good work ;)

[Steady]

Originally posted by digitize
@Steady
Perhaps this has been asked before, but I haven't seen it so I'll go ahead and ask. What is the spacial matrix for the spacial cleaning part of this filter? Im guessing it is 3x3 like C3D, but I could be wrong. And keep up the good work ;)
It starts with a notch filter at the Nyquist frequency (a 3x3 1 2 1 filter). Then it blends this with the raw image on a pixel by pixel basis depending on local detail. The 1 2 1 filter is also good at reducing residual interlace artifacts.

[digitize]

Ah I see, thank you for the response.

[onesoul]

A litte update to my tests (I hope someone finds it useful):
With noisy sources pixelized: pixiedust() is the one to try.
With clean sources: try fluxsmooth(15,10).
Suggestions?

[iago]

With clean sources: try fluxsmooth(15,10)

With clean sources: first, try no filtering at all ;).

[rubic42]

I'm not certain what is going on, but this is what I'm seeing:

The following code produces video with one field interlaced with a completely black field in each frame:


SeparateFields()
e = SelectEven().GoldDust()
o = SelectOdd().GoldDust()
Interleave(e,o)
Weave()


The following code does not have the black field in each frame, looks normal:


SeparateFields()
e = SelectEven().GoldDust()
o = SelectOdd()
Interleave(e,o)
Weave()


What's going on? Is this the proper technique for applying GoldDust() to separate fields in an interlaced video?

Thanks.

[onesoul]

Originally posted by iago
With clean sources: first, try no filtering at all ;). [/B]I sure had it coming :). But are there any real "clean" sources? I do a little magnifying at avscompare and I see noise and honestly the fluxsmooth gave me the better result with "clean" sources (mostly DVD's).

@rubic42

Have you tried pixiedust()? Goldust is stated by Steady to be experimental. Maybe it is the reason.

[Steady]

Originally posted by rubic42
What's going on? Is this the proper technique for applying GoldDust() to separate fields in an interlaced video?

Well it should be but ... This is related to the 'only one instance per filter' issue. I am not sure why (something about how it interacts with avisynth). But for now if you have more than one (dust) filter in a script you get odd behavior.

For those asking about avisynth 2.5 version ... Of course there will be a avs2.5 version eventually. But Dust is constantly changing, and avisynth2.5 is constantly changing. And I just don't need another source of weird bugs to track down. In a month or 2 when things have stabilized a bit.

Please remember that this is an Alpha version not a Beta. I consider an alpha as something that you are not even sure what it does yet. Beta is more where you make it work stable and fast. If you you this, you may get odd results, crash your computer, or martians may come cut off your head and put it on backwards. Almost certainly you will regret using it on something permanent when the much improved Dust17 comes out down the road.

One other thing I keep forgetting to mention. The height and width should be a multiple of 8 or you may get strange artifacts.

[rubic42]

Well it should be but ... This is related to the 'only one instance per filter' issue. I am not sure why (something about how it interacts with avisynth). But for now if you have more than one (dust) filter in a script you get odd behavior.

I remember reading that caveat, but somehow it didn't connect for me that that would be causing my problems. Thanks for the info.

Otherwise, the filter looks great! Even when it's not operating on interlaced video the right way, it looks awesome. Keep it up.

[onesoul]

Originally posted by Steady
One other thing I keep forgetting to mention. The height and width should be a multiple of 8 or you may get strange artifacts. Thanks for the warning, maybe you could put that at the readme file :)
I got a question, maybe a dumb one: Applying this filter or other filters to a picture with and without black borders (supposing both height and width are multiple of 8) will make any difference to the final quality of the picture?

[Rhaegar Targaryen]

Originally posted by onesoul
A litte update to my tests (I hope someone finds it useful):
With noisy sources pixelized: pixiedust() is the one to try.
With clean sources: try fluxsmooth(15,10).
Suggestions?

Have a look through the original FluxSmooth thread started by the program author. Many people seem to think that even the default values of FluxSmooth (7,7) are too strong for clean DVD's - me included. A more conservative setting such as (5,5) is what we find more appropriate.

[Assault]

@ onesoul

Fluxsmooth is a great filter but I agree with Rhaegar Targaryen and many other forum members here. Fluxsmooth (15,10) is definately too high for a clean dvd source. Try convolution3d moviehq and compare the result to fluxsmooth (15,10). You'll see there's much more detail kept by convolution3d. Perhaps this convinces you... ;)

Regards
Assault

[onesoul]

Originally posted by Assault
Fluxsmooth is a great filter but I agree with Rhaegar Targaryen and many other forum members here. Fluxsmooth (15,10) is definitly too high for a clean dvd source. Try convolution3d moviehq and compare the result to fluxsmooth (15,10). You'll see there's much more detail kept by convolution3d. Perhaps this convinces you... ;) I respect your opinions, but as I said before I tried convolution3d(preset=movieHQ") but I found it ruins too much the picture for me. Some thoughts on which filters applie can be found here (http://forum.doom9.org/showthread.php?s=&threadid=44264). Personally I didn't find much differences of fluxsmooth(7,7) with fluxsmooth(15,15) when applied after pixiedust. Keep in mind that I don't want to sell anything, I respect all authors who put their time on creating their filters and I thank them, I am only trying to find how to take the best out of them.

Cheers

[molerus]

Hi!

For a some time I'm fiddling with Pixie and Gold Dust. I encouraged my brother to using it, but he doesn't have so much time as I. So I wrote the ultimate script to use this filters with all kind of video. But since Dust requires both width and height of video to be divisible by 16 I'm adding a frame prior to filtering and after that I crop back. Since I use filtering in interlaced video I downloaded and modified the filter ViewFields. This filter separates the fields and puts them one under the another, and after Pixie or Gold Dust it interleaves them back.
But when I crop the image horizontally (vertically everything's ok) the filter fails. Although the width of the picture in VDub is ok, my filter recognizes it wrongfully and interleaving fails. I doscovered, that when I add borders with 0 width everything backs to normal.
Has anyone had the same problem?

If you want me I can enclose my de- and interleaving filter.

[Koke]

We want filter...
We want filter...
:)
Please...

[molerus]

Hi!

I enclose my filter (in fact there are two filters in it - ViewFields to de-interlace and MergeFields to interlace back), along with the script and source code. I added some not-so-wise comments, pointing the two errors in AviSynth.
Firstly, as you will probably notice, there is a line "AddBorders (0, 0, 0, 0)". Althouth it looks silly it's the only way that MergeFields could work correclty. Otherwise it scrambles the picture.

The second thing is using AviSource with "RGB24" option and then ConvertToYUY2. I use capture card to record from TV and this card uses the MJPEG codec. When AviSource is used without "RGB24" option it "wraps" the picture, putting the last line first, but only with MJPEG (I use Morgan codec) :p .

Uff!! So many errors - so little time ;)

However: here is the filter
Have fun

[Jellygoose]

Hi Steady!

Me and many others at KVCD.net are anxiously waiting for the next relase of your excellent filter. I just post here to show that I really appreciate the work you're doing! Keep it up!

Regards
Jellygoose

[Si]

@a moderator

I can't down load the attachment. (can now - thanks)

I'd like to look at it since I can't make any sense of the posts and see if there is a problem with my filters or molerus's "filter" (script? :confused: )

Could one of you look into it please.
regards
Simon

[Si]

@molerus
WT* :angry:

If you are going to modify a filter - I'd suggest you change the name to reflect the changes you've made otherwise people (not least the author :angry: ) are going to get confused :(

Another thing that comes to mind is that this is a thread about Steady's Dust filter and to publish another filter in it is a bit rude :(

Normal etiquette would be to email (or PM) the author if they are currently active (which I am :( ) and suggest changes to their filter so everyone can benefit and saves unneccesary proliferation.

And on a personal note what does MergeFields do that UnViewFields doesn't? (but don't actually bother replying to this question as that would contravene point 2 :( )

yours sincerely
S Walters :mad:
PS sorry Steady </rant>

[molerus]

Ok!

So here is the thing. I encoded "The Terminator" with the combination of PixieDust and Convolution3D. The whole film looks just astonishing (2CD + AC3 sound), but some parts became totally incompressible. Scenes where there is a lot of smearing smoke got horrible blocky. At first I thought it's the fault of lack of the luma noise correction. So I had ported NanDub's luma noise estimation routines into a VirtualDub filter, and then computed the noise. Next I muxed the computed values into XviD stat's file and compressed bitrate curve with GKnot, using luma correction. But it appeared that it didn't help, blocks were still there.
I encoded the problematic scene with constant quant 2 and the same happen - blocks and blocks. Only when I used quant 1 (ridiculous I know :p) the block have gone. Is there way to force XviD to use quant 1 for such a problematic scenes?? If it will be 1% of the film I can live with that. If not what are the other solutions??
Maybe adding dust with the use of information about luma noise would be useful?? Maybe someone has made such a filter??

P.S. If someone got angry by my recent post then please accept my sincere apology.

[MfA]

Id start a new thread for that question molerus, instead of tacking it on a 6 page existing thread specifically concerning an avisynth filter which has nothing to do with your question anymore. I suggest the xvid forum.

[Didée]

molerus,

you should read again my answer to your question in your "XviD new luma correction" thread.

:rolleyes:

[crOOk]

originally posted by Steady
82% of the time is spent on motion search
First of all: This filter really blows my mind. Even in this early stage of developement it already does a perfect job (besides the scene changes). Another thing that blew my mind was it's speed... :o
Not that I want to sound demanding, but for me (and I think I'm not the only one there) who does LOTS of encodes (several ones each day) it is just too slow to be used on a regular rip, but I guess you already knew that. ;)
Since the motion search takes such a lot of encoding power and 'most' people do two passes in their encodes, wouldn't it be possible to only do the ME once? You could write the results of the whole process into a file (like XviD does) and reuse this information in the second pass, couldn't you? This could save hours of encoding time. Most likely you have already thought about this, so let me just ask you if there are plans to implement such a feature in a future version. Keep up the brilliant work!

[MasterYoshidino]

would not make any sense to diasable a filter for comp test since the enviroment is different.

your bitrate distribution will be incorrect, as it will be like using TemporalSmoother() for the first pass and FaeryDust() for the second. You have to do both passes with exact same script and settings for a proper 2 pass encode.

you can't expect better compressability and speed :\

[crOOk]

I'm not talking about applying the filter in one of the passes only. I'm just saying that the motion estimation process is done twice. How does the ME affect the quality of the uncompressed video??? The result for both passes would still be the same. Even the script could stay the same. The filter would just need to check if there already is a file that includes the results of the first motion search (similar to the mvh files that XviD can create), so they can be reused in the second pass (If there is no file the filter would create one). This way the motion search does not have to be done twice...
@MasterYoshidino
Either you have not read my post carefully enough or I am terribly wrong about this whole thing. I just don't understand what you're saying. Have I missed the whole point of Motion Estimation?
@Steady
In case I have not missed the whole point of the ME, how much time could be saved by reading the ME results from a file instead of recalculating them all over again? You mentioned that the ME takes about 82% of the processing power needed by your filter.

[wingphil]

yep, he didn't read your post properly ;)

if steady is even still developing this filter he's more likely to be working on a yv12 version i would hope (hint hint :D)

[crOOk]

Thx for being so kind and clearing this up (MasterYoshidino doesn't seem to visit this forum regularly). Actually I've got to admit: I'd love a YV12 version, too. Especially because there'd sure be some speed increase in it as well.
Whatever, I'm using the filter on most encodes right now and am getting around 8 fps (XP2700+). The 'trick' is that I'm applying Dust after resizing and it is still doing a very good job with removing the noise and increasing the compressability without blurring too much.
I love it! Steady, please don't give up your project!

[wingphil]

it's a brilliant filter, and i used to use it every time i did a 1cd encode, but now i've changed to yv12 it's just not worth the slowdown any more.

come on steady :D

[Holomatrix]

Just wondering if we are any closer to a YV12 version? I'm running some tests on clean DVD material and want to be able to test PixieDust YV12. I'm taking Fluxsmooth over Convolution3D and would like to test Flux against Dust in YV12. Thanks

[MasterYoshidino]

hah !
lol :( a yv12 would be nice though as this is the only temporal filter that seems to do the job no noisy anime (yv12 has little need for spatial filtering but I notice I need some temporal filtering still :D )
doh why do I have to stick wtih 2.07 :p ( conversion from YUV2 to YV12 for direct stream encoding causes color errors in encoding MPEG4's)

[sh0dan]

Unless you are using captured material in huffYUV YUY2, you are still having the same number of colorspace conversions - they are just at different placed.

2.0:
MPEG2DEC (YV12) -> MPEG2DEC (YUY2) -> AviSynth (YUY2) -> MPEG4 (YUY2) -> MPEG4 (YV12).

Conversion are YV12 -> YUY2 -> YV12

2.5:
MPEG2DEC (YV12) -> AviSynth (YV12) -> AviSynth (YUY2) -> AviSynth (YV12) -> MPEG4 (YV12).

Conversions are YV12 -> YUY2 -> YV12. Now it's just done within AviSynth instead.

[Richard Berg]

I emailed Steady a couple weeks ago offering to compile Dust for v2.5. Has anyone heard from him recently?

Oh, and forgot to mention, a friend of mine and I have found a pretty serious Crop bug.

[troy]

Can someone tell me how I can use this filter with an avi interlaced source. I read that molerus had some script to use but I could not find it to download. Has anyone made script yet to use for an interlaced avi source.

[Richard Berg]

Look at the bottom of page 1.

[troy]

Sorry I looked on this page. I can not see anything to answer my question?????

[scharfis_brain]

that's easy:



separatefields()
yourfavouritedenoiser(Parameters)
weave()

[ulfschack]

Nope that wont cut it entirely.

You have to separate the the evens from the odds by inserting:
separatefields()
even=selecteven().yourfavouritedenoiser(Parameters)
odd=selectodd().yourfavouritedenoiser(Parameters)
interleave(even,odd) #... possibly the other way around (odd, even)
weave()

Because if you have a 50 fps stream of 288 lines every other picture will be relatively moved half a scanline thus not providing the right information for a temporal denoise filter.

cheers

[Boulder]

@ulfschack: You can't use the filter in more than one instance in your script for some reason. I doubt that the script would work, I'm not 100% sure though;)

[ulfschack]

@boulder

You're absolutely right. In fact I even found this out by myself a few weeks back, but managed to forget :)

Even so, by not separating the evens and the odds be prepared for a much more blurred picture, as the filter with confuse pixels from different locations as being from the same.

If I remember correctly I abandoned Dust in favour of Peach for this reason alone.

cheers

[scharfis_brain]

separatefields()
yourfavouritedenoiser(Parameters)
weave()

but while using this script, you'll have a better temporal noise removal.

But the denoiser may have some trouble with the sharp flickering edges (or is this flickering positive for the denoiser???)

[Loul]

Originally posted by Richard Berg
I emailed Steady a couple weeks ago offering to compile Dust for v2.5.

I'm eagerly waiting for a 2.5x Dust version.

Dust is among the best (and maybe the best) denoisers and it would be so disappointing it would die from not being updated :'(

[trance]

I would to try Dust as well but have been unable because of AVS 2.5 (which I would imagine most people have installed).

[DoW]

Sigh... use loadpluginex.dll from the warpsharp package to load Avisynth 2.0x plugins (like dust). Just remember to put it before the loading of dustv5.dll and make sure you pass YUY2 to dust, and your set.
See: Plugin Chaos (http://forum.doom9.org/showthread.php?s=&threadid=48160&highlight=loadpluginex)

[FredThompson]

Any progress on a 2.5 compile? dustv5 and loadpluginex aren't playing friendly with the latext CVS Avs 2.5.2

[toshi]

Originally posted by trance
I would to try Dust as well but have been unable because of AVS 2.5 (which I would imagine most people have installed).

You had better use LoadPluginEx.dll. You can use Avisynth 2.0 plugin on Avisynth 2.5 by using this plugin.

[FredThompson]

As mentioned in another thread, it's not so simple. The 2.5.2 CVS build doesn't seem to play well and the question is where to find a version of loadpluginex.dll which does.

[Loul]

What's up with Dust ?

Has developpment stopped ? :(

It's my favorite denoiser but I'd like a 2.5x Avisynth version of it and we don't have any feedback :(

If someone has some news let us know please !

[digitalman]

So many people keep asking about it, I don't think there will ever be a 2.5 version. Kind of like certain great games on Playstation or Nintendo 64 were not brought over to PS2 or the Gamecube. Or certain movies that were on VHS, took years before they were on DVD.

[Loul]

That would be terrible.

What has happened to Steady ?

Can't find a post of him that would be of less than 5 months, though he's still in the moderator list of this forum...

[WarpEnterprises]

http://forum.doom9.org/showthread.php?s=&threadid=60703

[FredThompson]

I've been trying to gen up some development of scratch/dropout/dust filters for 2.5.x. There are some good technical articles in Donald Graft's library section of this website. Also, the SpotRemover site has some good theory explained. (Wish Konstantin would release an AviSynth version...) A few experimental filters exist but nothing that's really complete yet.

steady does seem to have gone on an extended sabbatical...

[kempfand]

Dust is basically the only AVS filter which helps with some of my problematic DV-avi conversions. In my experience and situation, I mostly use SpaceDust(). PixieDust(limit=5) is a bit better but too slow :eek: .

Only other filters that help is MipSmooth(preset = "MovieLQ"), or brute-force blur(0,1) / CCE LowPass 4-6.

I really would hope that someone can port Dost to AviSynth 2.5+ and add YV12 ;)

Kind regards,

Andreas

[WarpEnterprises]

someone can port
it is closed source :(

[crOOk]

it is closed source
That's what I don't get. No offense, but if Steady is too busy to develope it, why doesn't he make it open source?

[FredThompson]

steady has, apparently, disappeared. At one time, he was hoping to make dust a commercial product and nothing seems to have happened.

[FredThompson]

Originally posted by kempfand
Dust is basically the only AVS filter which helps with some of my problematic DV-avi conversions. In my experience and situation, I mostly use SpaceDust(). PixieDust(limit=5) is a bit better but too slow :eek: .

Only other filters that help is MipSmooth(preset = "MovieLQ"), or brute-force blur(0,1) / CCE LowPass 4-6.
PAL or NTSC? What, exactly, are the quality issues you are trying to filter?

[kempfand]

Fred: My issue is kind of a 'long and winding road'. Difficult to explain (my native language is not English), but I'll give it a try.

It's PAL DV-avi (16:9 anamorph recorded source) from my vacation videos. I usually go South and have lot's of bushes, grasses, palmtrees in the picture. As there aleays is some mild wind, the palm-leaves are a bit moving, and, in addition, I mostly use no tripoid, so there is some slight movement also from me holding the cam (or slowly moving to change scene). What I want to say: complicated stuff to encode (i.e. more difficult than DVD-backups from Hollywood movies, which in addition are progressive).

The problem I have now, is as follows: In the picture, where there are moving leaves, the resulting MPG (when viewed on TV) is kindof flickering, pulsing, not moving smoothly. This only applies to areas with these leaves and tree or grass -structures (i.e. if there is a stone or sand in the very same picture and scene, the part of the image where the sand is is very good).

For testing, I use CCE, CBR 7000, DC 9, Standard Matrix, Alternate Scan, no filters within CCE. I'm feeding an AVS to CCE. The resulting fieldorder from the AVS is correct (i.e. I always check the AVS with assumetff() & bob() through feeding it into VirtualDub).

When I 1st faced the problem 2 months back, I started to test as follows:
- Deinterlace (various ones, best was TomsMoComp and KernelDeInt). This solved the problem, but the image was not 'fluid' anymore when the cam moves, so this is a no-go
- Tried various SpatioTemp filters (Convolution3D (1, 6, 10, 6, 8, 2.8, 0) and lately MipSmooth(preset = "MovieLQ"), plus some of the others around). And yes: I did not use SeparateFields() but used some of the more advanced scripts such as the ones from UnPlugged ( Bob(0,0.5) ... SeparateFields().SelectEvery(4,1,2).Weave() ) or StickyBoy (Fold/UnfoldFieldsVertical(true) ).

Long story result: SegmentedAVISource("V:\sclive\Z\Z-01.avi")
Bob(0,0.5)
SpaceDust()
SeparateFields().SelectEvery(4,1,2).Weave()
gives excellent results (i.e. the flickering/pumping within the image-area where I have the palm-trees are gone). With PixieDust(limit=5), results are even better, but it takes forever.

I also found that Blur improves the situation, either the LowPass filter in CCE, or Blur(1,0) (better than Blur(0,1) or Blur(1,1). But things get clearly 'unsharp', and it's not easy to view (the eye constantly tries to 'focus' and get things more sharp).

Another good approach came from mb1 (he knows all the 'old' tricks). He suggested using a BilinearResize (taking into account 2 blocks for TV-overscan). This, in combination with MipSmooth (latest version) also gets rid of the problem, and this is what I currently use:
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\MipSmooth.dll")
SegmentedAVISource("V:\sclive\Z\Z-02.avi")
ConvertToYV12(interlaced=true)
Bob(0,0.5)
MipSmooth(preset = "MovieLQ", weigh = false)
BilinearResize(688,544,0,3,720,570)
SeparateFields().SelectEvery(4,1,2).Weave()
AddBorders(16,16,16,16)
ConvertToYUY2(interlaced=true)
I also found out, that some (not all) of the flickering with the palm-leaves comes from the DVD-player itself, and how it is connected. For example, my old player was connected via RGB to the TV. When I switched to SVHS-cable, the flickering was less.

But more: I upgraded to a new player 5 days back. Guess what: The flickering is much less (even through RGB). I was also told that some players (i.e. Grundig) even have different firmwares (which can be flashed) which produce different sharpness and more/less flickering. My learning is that the player (and how it transmits to the TV) are an important element in the chain.

That's basically the story. If you or other readers have additional suggestions for concrete scripts/filter -combinations, I'm keen to test them (I already tried some of the more elaborated ones such as the ones for KVCD/KDVD or the one 'Quantified Motion Filter' by HomiE described somewhere in this forum.

Kind regards,

Andreas

[FredThompson]

The term "bob" also means to bounce slightly. That's what happens when you try to use it to change field order. A "bobber" is the float on a fishing line. When it "bobs" in the water, you know a fish is at the bait.

Get rid of that statement and encode as BFF. IF you don't like that, add Peachsmoother.

[kempfand]

Can't encode BFF, as most of the players with friends/colleagues will not play BFF correctly. It results a 'stottering' during playback. When I chnge the fieldorder (Darim's EasyChanger, or by adding DoubleWeave().SelectOdd() at the end of the AVS), the DVD-players correctly play.

I've read in other threat here that it works for you, but not on the players I have at hand :(

I tried PeachSmoother ... did help a bit, but the picture (when viewed on TV ober > 5 minutes) was a bit too 'nervous' (don't know how to better say this in English).

I will give another try to stickboy's functions (which avoids Bob if I'm reading this correctly): import("C:\Program Files\AviSynth 2.5\plugins\StickBoy.avs")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\MipSmooth.dll")

SegmentedAVISource("V:\sclive\Z\Z-01.avi")

ConvertToYV12(interlaced=true)

UnfoldFieldsVertical(true)
MipSmooth(preset = "MovieLQ")
FoldFieldsVertical(true)

DoubleWeave().SelectOdd()

ConvertToYUY2(interlaced=true)

Regards,

Andreas

P.S. I also found that DGBob(mode=1) works well.

Maybe this is better to use than the "normal" Bob (from the readme: "Set mode=1 to output a clip with a number of frames equal to twice that of the input clip (frames from fields) and a frame rate twice the input frame rate. This allows you to use the filter for smart bobbing")

[High Speed Dubb]

kempfand,

Kannst Du das nervous PeachSmoother Bild genauer auf Deutsch beschreiben?

If I’m interpreting “nervousness” correctly, you would probably see an improvement with PeachSmoother using a lower Stability setting.

[FredThompson]

DoubleWeave().SelectOdd() will create some goofiness. See this thread: http://forum.doom9.org/showthread.php?s=&threadid=46765

[kempfand]

@ Lindsey :

I tested 2 settings (being fully aware that I should run different values to hopefully find optimal settings):
-> PeachSmoother(NoiseReduction=35, Stability =20, Spatial=100, ShowMotion=false) and
-> PeachSmoother(NoiseReduction=50, Stability=30, Spatial=200, NoiseLevel=3.5, BaseLine=2.5)

Regarding the "nervous" (trying to explain this in German): Das Bild war irgendwie unruhig, nicht fliessend, sondern eckig & kantig (stotternd wäre übertrieben, aber es geht in diese Richtung).


@ Fred :

Completely agree. I think it should be pointed out more, as I often see "wrong" scripts using DoubleWeave().SelectOdd() before feeding into spatio-temporal filters. I stopped using it and was only mentioning above to make the point about TFF for DVD-MPEG playback.

If I have to change the field order, I use Simon Waters' Reverse Field Dominance (http://www.geocities.com/siwalters_uk/fnews.html).

To make the spatio-temporal filters work correctly, I either use
- Stickboy's Fold / UnfoldFieldsVertical (http://forum.doom9.org/showthread.php?threadid=59029&highlight=UnfoldFieldsVertical) , which I understand is similar to Simon Walter's View / UnViewFields in the link you gave above or
- Bob(0,0.5)
...<filters>...
SeparateFields().SelectEvery(4,1,2).Weave()
Offtopic: I saw your Q in the other forum about changing field-dominance in MPEG2 (without de- & re-mux to m2v, which is needed for ReStream). Tried to register there but didn't get activatio yet. In short: If I remember correctly, Darim's EasyChanger will do (don't have a link handy, but PM in case you need help).

Regards,

Andreas

[FredThompson]

@Lindsey,

If you're still watching this thread, would you please comment on what you think the strengths/weaknesses are of peachsmoother vs. dust?

Also, am I correct that PeachSmoother and GuavaComb are both interlace-aware?

@kempfand,

You could also split your interlaced source into 2 streams which might be safer. If I understand the code snip from stickboy, spatial-temporal filters which do not support interlaced source will still corrupt the frames. You will have the top of one field right next to the bottom of the other. How would the filter know these are not related and filter across the "border"?

Try something like this:

even=SelectEven(SeparateFields()).Your_Function_Here()
odd=SelectOdd(SeparateFields()).Your_Function_Here()
Interleave(even,odd).Weave()

[Boulder]

Originally posted by FredThompson
You could also split your interlaced source into 2 streams which might be safer. If I understand the code snip from stickboy, spatial-temporal filters which do not support interlaced source will still corrupt the frames. You will have the top of one field right next to the bottom of the other. How would the filter know these are not related and filter across the "border"?


See this : http://forum.doom9.org/showthread.php?s=&threadid=64253&perpage=20&pagenumber=2 . I asked the very same question there. Basically ViewFields-Spatio-TemporalFiltering-UnViewFields works fine and you won't notice any oddities.

The SelectEven/SelectOdd/Interleave works fine on most cases but some filters don't like to be called more than once in the script. IIRC PeachSmoother may be one of those, and the Dust filters won't even work if they are called more than once per script.