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