RemoveDirt

[kassandro]

RemoveDirt is a temporal cleaner with strong protection against artifacts, highly configurable and SSE optimized.
For more details goto www.RemoveDirt.de.tf
Please post all questions to this thread.
2004|02|15 version 0.4 (first public release) released
2004|02|28 version 0.5 released (for a change log see posting below)
2004|04|01 version 0.6 released (for a change log see posting below)
2004|04|21 version 0.6.1 released (for a change log see posting below)
2005|05|07 version 0.9 released (for a change log see posting below)

[Mug Funky]

starting testing now... it seems to be very gentle, and kills flickering blocks nicely (like those annoying blocky dark scenes we've all seen)

just sussing out the settings.

these lines are a good way to see what's being done...

subtract(last,last.removedirt())
coloryuv(autogain=true)

i seldom see a recognisable picture with the above, except in high motion. very good work.

[edit]

this works beautifully! it's subtle as hell, but improves compressibilty quite a lot! it's almost a free lunch

[edit edit]

okay... my fan blades are disappearing. i guess i'll have to read all that document to know which parameter to tweak

[edit edit edit]

okay... after some tweakage i seem to have preserved the fan blades while pushing back the spots. excellent. combined with temporalsoften i can see me getting undersized encodes for the first time ever :O

[Kintaro]

tested with old anime and my first impression this morning was: whow!

then came back down to reality when I started missing some fine grey lines
after lowering the motion detection thresholds to
RemoveDirt(athreshold=40, mthreshold=90)
no lines were touched anymore, but still most of dots and scratches got completely removed.
only problem left was horrible blocking on high-motion with my settings, but conditional filtering helped out there so Im quite impressed about quality for now *still testing*

vdubmod crashes on closing due to a read error when RemoveDirt was used


edit: sounds somewhat pretty similar to mug funky's post

[kassandro]

Originally posted by Kintaro
vdubmod crashes on closing due to a read error when RemoveDirt was used

Does this crash happen always, or does it only happen with a specific setting of variables? Is it script or clip dependent? Which version of Avisynth do you use (I didn't experience any crashes with version 2.54)? Did you use range files (only surficially tested)? Does this happen for YV12 and YUY2 or only for one color space? Is it luma or chroma related (check it by alternating between grey=true and false)?
If it is specific, could you please post the details (with the exception of the clip of course). If it is the clip please post width, height, number of frames and color space.

[Mug Funky]

wow... i mean wow.

did a quick test with a 500 frame chunk from Blade Runner (r4), possibly the worst quality DVD i own (well, except for ghost in the shell and futurama), and i got a massive compressibility gain.

clips encoded Xvid VHQ1, fixed quant 2, bframes 2 (at q4)...

without removedirt: 833kbps (not bad)
with removedirt: 627kbps (WOW)

settings for removedirt were:

removedirt(mthreshold=4*255,athreshold=18,soscillation=10,doscillation=255,dist=2,tolerance=12,show=0)

aside from obvious bad-motion bits that i didn't bother with as they were lost causes (a brown ceiling fan from above with brown background, barely visible without removedirt), there was no visible degradation in quality, in fact the bitrate pumping present in the source was completely gone, as were a few random black spots.

i'm going to use this baby more often. combine this with a temporal smoother and you've got low-bitrate heaven.

i can't recommend this enough...

[Bogalvator]

Just tested this on my Double Indemnity DVD, which is a poor quality transfer of a 1944 film and as such has boat loads of spots, splurges and scratches - the perfect stuff for RemoveDust to tackle

Used the following command line:

removedirt(grey=true,mthreshold=175,athreshold=75,soscillation=75,doscillation=100)

so it was some quite heavy filtering (it needed it though!). It pretty much removed all of the "dirt" I mentioned above, just as promised! Compressibility was, as Mug Funky said, improved tremendously:

Xvid - Quant 2, Q-Pel, Trellis, B-VOPS 3/1.5/1, 640x480 -
Without RD = 2353MB, with RD = 1618MB !!!

Like I say, it did a great job on the dark spots and scratches, though it wasn't as effective on the white spots, yet.......

So basically, give this filter a whirl, you won't regret it! I have a couple of questions though:

1) "Never crop after RemoveDust" - not even if you resize afterwards to a mod 16 resolution? Does it really effect the codec compression performance?

2) With that in mind - what about colour space conversions? I would like to use Pixiedust after you filter, should I ConvertToYUY2() before using your filter, or will it be safe to use it in YV12 first then convert afterwards?

Also, when I added removedust.dll to my plugins directory, both VirtualDub and TMPGEnc requested a file, msvcr70.dll, on startup (before loading AVS script). Naturally this message went away when I copied a version of it into both the VirtualDub and TMPGEnc directories, but do you know why this message came up. Anybody else have this problem?

P.S. I don't have the problem Kintaro mentioned so I'm not sure if they could be related or not.

[Kintaro]

ok finally found some time for further testing:
first tested again with my avisource/divx5.1/640x480/34534frames, no ranges. tried also converttoyuy2() and grey=true and finally switched back to avisynth 2.54 (using 2.55alpha atm).
error message occured in all cases

after that I tried on mpeg2source/720x480/48466frames and there was no problem with closing vdubmod in this case.
so I took that mpegsource and made a short clip out of it: xvid/720x480/2000frames. behaved again like my first avisource.

next mpegsource: 720x576/34876frames caused no problems when closing vdubmod. that file encoded to xvid also crashed vdubmod

I think its somehow related to avisource, tried opening all avifiles with directshowsource to confirm that -> and not a sinlgle crash occured.

since I cant think about anything worth trying out atm Ill go to sleep now and probably die in 3h when I have to get up =_=

[kassandro]

Originally posted by Bogalvator
1) "Never crop after RemoveDust" - not even if you resize afterwards to a mod 16 resolution? Does it really effect the codec compression performance?
[/B]

That was only reasonable guess of mine. A codec expert has really to answer this question. Or one has to run a lot of tests. On the other hand, I know that all high quality codecs divide the frame into a grid of small blocks and on these blocks the dct = discret cosine transform, a variant of the classical Fourier transform, is applied, to separate the important from the neglible things. That is the reason why too much compression makes a video visibly blocky. As far as I know the dct already appears in jpeg compression. Now RemoveDirt uses also such a grid of blocks and the output gets also blocky, though the blockiness is hardly visable, if pthreshold is not too high. On the other hand, the dct is more sensitve than the human eye, and it should react badly if the edge of a RemoveDirt block is right in the middle of a dct block. To avoid this, any edge of a RemoveDirt block should be the edge of a dct block. That is at least my guess. Now, if you crop on each side by a multiple of 8 that should be ok. But if you crop on the right hand side by 4 and on the left hand side by 12, then both grids are out of sync. The RemoveDirt edges are exactly in the middle of the dct blocks.
A further Remark about blockiness is in order. Because RemoveDirt bases the decision, whether to clean or not to clean, solely on the luma, there should not be any really visible blockiness as far as the luma is concerned. However, theoretically the chroma alone can cause blockiness, though this should be quite unlikely in a normal video. But obviously, as reported by Kintaro, more likely for anime videos. If chroma blockiness becomes a severe problem I can solve it at the expense of execution speed. Also the filter gets a lot more complicated to use, because then the chroma needs its own set of variables.

Originally posted by Bogalvator
2) With that in mind - what about colour space conversions? I would like to use Pixiedust after you filter, should I ConvertToYUY2() before using your filter, or will it be safe to use it in YV12 first then convert afterwards?
[/B]

As far as quality is concerned, it should not matter much, but RemoveDirt is certainly faster in YV12 than YUY2, at least if you use the default mode=2.

Originally posted by Bogalvator
Also, when I added removedust.dll to my plugins directory, both VirtualDub and TMPGEnc requested a file, msvcr70.dll, on startup (before loading AVS script). Naturally this message went away when I copied a version of it into both the VirtualDub and TMPGEnc directories, but do you know why this message came up. Anybody else have this problem?
[/B]

That is a problem with all my filters! To get a rather small dll, I use dynamic linking. In other words, various windows support function are not getting put into the dll. They are in msvcr70.dll and that is the reason why this dynamic link library is needed. Dynamic linking also saves memory during execution, because many other parts of the program can share msvcr70.dll, if they too use dynamic linking. But, if you know how windows wastes memory that shouldn't really matter. Dynamic linking may also be a tiny bit faster. There is one further problem: if your version of msvcr70.dll is not compatible (I really don't understand why this happens), you get execution problems. Perhaps, this is the reason for the crashes reported by Kintaro. With a staticly linked dll, you would not have these problems, because all the support routines are put into the dll. But if you use many staticly linked filters the same support routines may be linked many times into the executable. Nevertheless, I should perhaps release also a staticly linked version.

[kassandro]

Originally posted by Kintaro

I think its somehow related to avisource, tried opening all avifiles with directshowsource to confirm that -> and not a sinlgle crash occured.

You got it! Excellent debugging! I have reproduced exactly, what you said. RemoveDirt and avisource do not like each other. I can now investigate this myself. But first I have to sleep a little.

[kassandro]

I couldn't resist to track down the bug detected by Kintaro. I have now a do nothing filter (it simply passes through all the frames) with only a few lines of source code which exhibits the same hostility to avisource. I will post it later to the AVS developer forum. It remains to be seen whether I am doing something forbidden during dll initialisation or whether this a Avisynth bug. Fortunately, this bug has nothing to do with the filter itself.

[Mug Funky]

to go back to the question about not cropping after removedirt... it will affect compressibility for the DCT components (block edges are shifted and mistaken for high frequencies. high frequencies compress badly because of the VLC coding of blocks after quantization). this probably wont affect motion vectors, so there will still be a gain on your original source.

of course, you could run a deblocker like "blindPP(quant=2,cpu=4)" after removedirt and you might be able to crop after that, so long as the deblocking does it's thing.

[edit]

it'd be really nifty to have hard-coded presets for this (if it's not too much to ask). i ask because although yesterday i knew what the settings do, i've forgotten now... presets would be very cool and could handle 90% of situations flawlessly i think.

[kassandro]

Originally posted by Mug Funky
to go back to the question about not cropping after removedirt... it will affect compressibility for the DCT components (block edges are shifted and mistaken for high frequencies. high frequencies compress badly because of the VLC coding of blocks after quantization). this probably wont affect motion vectors, so there will still be a gain on your original source.

Thank you for this confirming comment. You obviously know more about the subject.

Originally posted by Mug Funky
it'd be really nifty to have hard-coded presets for this (if it's not too much to ask). i ask because although yesterday i knew what the settings do, i've forgotten now... presets would be very cool and could handle 90% of situations flawlessly i think. [/B]

Currently the plugin is not yet mature enough. But if some agreed presets emerge, then I certainly would implement this presets for quick usage.

[Bogalvator]

Thank you Kas and Mug for the answers regarding the cropping issue, they were helpful. I think I see why directly cropping the video would have a negative effect on codec performance now.

Look forward to future versions of the filter.

[leadman584]

Very nice little filter ya got here. Definitely useful for compressibility gain with minimal speed loss. Getting very good results. Keep up the good work.

[acrespo]

I am a user of MipSmooth in analog anime content. After did some tests with this new filter I am impressed with results. I will do more tests to compare with mipsmooth but I think my new filter is RemoveDirt

Keep good work

[scharfis_brain]

Always getting

AVISynth open failure:
Loadplugin: unable to load "removedirt.dll"


any ideas?

[Dreassica]

no problems here, using it in autoload environment.

[kassandro]

Originally posted by scharfis_brain
Always getting

AVISynth open failure:
Loadplugin: unable to load "removedirt.dll"


any ideas?

This is probably due to a missing msvcr70.dll library, which should be put into C:\windows\system32, such that every piece of code, which is dynamicaly linked like RemoveDirt.dll, can find it there. If all applications would be dynamicaly linked, we wouldn't have this problem and little bit more free disk space. I may also provide a staticly linked version, though, to avoid these problems. Please don't put several copies of msvcr70.dll in different application dirs, because then dynamic linking would cost even more disk space and memory than staticly linked binaries. C:\windows\system32 should be the only place.

[scharfis_brain]

Thanks a lot!

It is working now!

EDIT: please remark this issue to your documentation!

[krieger2005]

Is there maybe a version without SSE-optimazion. Not all people has CPUs with SSE (like me).