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 (http://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! :eek:

then came back down to reality when I started missing some fine grey lines :D
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 :D

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

[kassandro]

Originally posted by krieger2005
Is there maybe a version without SSE-optimazion. Not all people has CPUs with SSE (like me).
In theory, I could provide a non-SSE version, because all low routines have not only been written in SSE assembly code, but also in C. Then I have compared whether the C and the SSE version yield the same result. Checking the validity of the SSE version was the only reason for the C version. In real life the C version would be unusable, because it is at least by a factor of 10 slower than the SSE version. SSE allows not only to handle 8 pixels at a time, but also the programming is virtually jump free. Together with instruction pairing this keeps the cpu pipelines full almost all the time. That makes it possible for RemoveDirt to be slightly faster than the well known mpeg2dec3, that means about 80 fps for a 720x576 clip. Now any cpu without SSE is much slower than my 1.3 GHZ Tualatin Celeron. So it really doesn't make sense to me.

[Fizick]

Removedirt is needed in Integer SSE or Full (Integer and Float) SSE?

[yaz]

i've just tested rd on some heavy sources (monty python trilogy, blade runner & so) great stuff. the member of the crew, definitely.
thx for it!
y

[kassandro]

Originally posted by Fizick
Removedirt is needed in Integer SSE or Full (Integer and Float) SSE?
Only integer SSE is used. But is there any cpu with integer SSE and without floating point SSE? If that is the case, I will certainly fix it in the next version, which will be released next sunday.

[Fizick]

SSE: New commands present in P3, P4, newer Celerons, Athlon XP, MP.

Integer SSE: A subset of the SSE command set, mostly used for video processing. These instructions are also present in AMD Athlon (all versions), AMD Duron (all versions).

See:
http://www.avisynth.org/index.php?page=IntegerSSE

[kassandro]

Originally posted by Fizick
SSE: New commands present in P3, P4, newer Celerons, Athlon XP, MP.

Integer SSE: A subset of the SSE command set, mostly used for video processing. These instructions are also present in AMD Athlon (all versions), AMD Duron (all versions).

See:
http://www.avisynth.org/index.php?page=IntegerSSE
Sorry, I didn't know that and will fix it today. I thought the older Athlons and Durons have only 3DNOW. Clearly Integer SSE is much simpler than full SSE, because it does not require the 128 Bit xmm registers. It only implements a few important instructions which were unfortunately missing in the original mmx instruction set.

[kassandro]

I just have put version 0.5 onto the website. The binary package contains now also a staticly linked version. Please put only one dll into the plugin directory. The following changes have been made:
1. Chroma postprocessing has been added for YV12 clips. By default RemoveDirt does not only luma postprocessing but also chroma postprocessing. It is controlled by the new variable cthreshold. By default, cthreshold=pthreshold. To avoid distortion by the chroma, it is now more important to use "grey=true" for black&white video (in version 0.4 this option was only good for a slight speed increase). This option disables chroma postprocessing. Chroma postprocessing is also disabled if cthreshold > 8*255. Then version 0.5 operates the same way as version 0.4 and is somewhat faster. For b&w videos I recommend to lower pthreshold to 30 or even 20 to avoid slight blockiness in areas with very flat contrast. Chroma postprocessing is yet only implemeted for YV12. Unfortunately, in YUY2 the chroma is vertically twice as dense as it is horizontally. An implementation would therefore require a vertical and horizontal cthreshold variable.
2. If RemoveDirt is used jointly with AVIsource, VirtualdubMod did crash upon leaving (many thanks to Kintaro for detecting this problem). In version 0.5 this problem has been fixed. However, if RemoveDirt stops during initialisation, because something has gone wrong, it stills messes up VirtualDubMod, if it is jointly used with AVIsource. This is an Avisynth bug. Many other filters share the same problem, if they stop during initialisation and are used jointly with AVIsource. Hopefully this problem is fixed with the next version of Avisynth.
3. I always thought, that upon loading a new script, Avisynth starts with a fresh heap and therefore never released allocated memory. Because RemoveDirt allocates one byte for each frame to handle range files, that led to a loss of 135000 Bytes for a 90 minute PAL-video each time the script was reloaded. Together with a slight Avisynth design flaw the memory leak was also responsible for the above VirtualDubMod crash. The memory leak has been fixed in version 0.5.
4. Version 0.4 rejected any cpu, which did not have full SSE capability, although RemoveDirt only uses Integer SSE. As I learned recently (thank you Fizzik), old Athlons and Durons have Integer SSE but not full SSE. Version 0.5 now works with these cpus as well.
5. In version 0.4, the "grey" option was not handled properly for the first and the last frame within range files. 0.5 fixes this problem.
6. The dirt oscillation check of RemoveDirt has been disabled by default. Unfortunately this feature prevented a lot of dirt from being removed, while doing little for artifact protection. For instance, damages caused by film projector heat are black in the interior but have a tiny white boundary, whence this frequent kind of "dirt" has a very high oscillation. RemoveDirt is also faster without oscillation dirt check. Putting doscillation=50 restores the old default mode. In subsequent versions the oscillation check may be removed completely.
7. Various updates for the documentation.

Following a suggestion of Mug Funky I am preparing a general preset mechanism for version 0.6. If now RemoveDirt is used with RemoveDirt(input, default="anime", ...) then RemoveDirt looks for a file named RemoveDirt.ini in the script directory and in this configuration file it looks for preset values associated with anime and replaces the builtin defaults by the anime defaults. The syntax of RemoveDirt.ini will be simple and efficient. In fact, the basic class to achieve the preset mechanism is already in the source code (it can be easily used for other filters as well), but is yet untested, has to be connected with RemoveDirt and there is not yet any documentation.

Thanks for the friendly comments!

[krieger2005]

Hi,

now i can use RemoveDirt too (seems that i have an old AMD ;)).

I tried your filter and its works very fine. But I have some questions:

First
I tried now to use the range-Options. Here the Script:

ConvertToYV12().RemoveDirt(range1= "1084 2971",
\ mode=2, dist=3, tolerance=50)


As you can see i took first some frames. When i try to open this Script in VDubMod i get this error-message:
"IO Error with 1084 2971"
I thought that this was the cause of use of "avisource". Tried then open my file with "mpeg2source" (i have of this movie an avi-file and a DVD). But the same error.

Second
I have first many more frames. When i tried to open the script i get always this error: "the named argument "range6" was passed more than once to RemoveDirt"

I have used range6 only one time in the hole script.
Here the code:

ConvertToYV12().RemoveDirt(range1= "1084 2971",
\ range2= "60930 61216 61492 62123 62233 62596 62650 62899 62976 63265 63292 63321 63496 63783 63807 64374 64563 65021 65070 65568 66001 66035 66074 66151 66176 66438 67149 67185 67262 67429 67470 68033 68078 68224 68399 68833 68993 69086 69125 69348 69516 69844 69940 70297 71116 71343 71488 71664 71981 72015 73006 73031 73927 73976 74131 74350 74644 74748 75036 75153 75356 75402 75431 75540 75559 76518 76602 76764 76974 77014 77111 77200 77372 77744 77803 78156 78679 78751 78963 79061 79121 79205 79838 79881 79951 80078 81531 81616 81997 82212 82391 82526 82836 83056 83113 83244 83391 83471 83552 83568 83615 84162 84417 84677 84803 84973 85023 85807 85869 85942 85984 86041 86259 86353 86425 86554 86629 86771 86924 86958 87138 87253 87315 87368 87405 87453 87721 87745 87821 87920 87966 88095 88181 88564 88745 89111 89523 89761 90417 90618 91494 92227 92425 92689 92794 92839 93098 93265 93349 93389 94218 94243 94612 94992 95352 95615 96007 96120",
\ range6= "100248 100484 100540 100773 101062 101116 101646 101918 101996 102051 102303 102545 102934 103108 103189 103315 103335 103746 103824 104009 104220 104599 104632 104815 105143 105222 105943 106094 106329 107809 108084 108297 108981 109212 109616 111192 111704 111795 111923 112117 112389 112591 112685 112909 112923 112947 113383 113617 113707 113881 114103 114137 114170 114246 114432 115131 115154 115274 115377 115464 115506 115621 115669 115720 116017 116080 116126 116185 116372 116658 117990 118224 118696 119028 119247 119450 119494 119546 119660 119721 119816 119899 120040 120340 120469 120710 120829 120923 121163 ",
\ range5= "62597 62651 62900 62977 63266 63293 63322 63497 63784 63808 64375 64564 65022 65071 65569 66002 66036 66075 66152 66177 66439 67150 67186 67263 67430 67471 68034 68079 68225 68400 68834 68994 69087 69126 69349 69517 69845 69941 70298 71117 71344 71489 71665 71982 72016 73007 73032 73928 73977 74132 74351 74645 74749 75037 75154 75357 75403 75432 75541 75560 76519 76603 76765 76975 77015 77112 77201 77373 77745 77804 78157 78680 78752 78964 79062 79122 79206 79839 79882 79952 80079 81532 81617 81998 82213 82392 82527 82837 83057 83114 83245 83392 83472 83553 83616 84163 84418 84678 84804 84974 85024 85808 85870 85943 85985 86042 86260 86354 86426 86555 86630 86772 86925 86959 87139 87254 87316 87369 87406 87454 87722 87746 87822 87921 87967 88096 88182 88565 88746 89112 89524 89762 90418 90619 91495 92228 92426 92690 92795 92840 93099 93266 93350 93390 94219 94244 94613 94993 95353 95616 96008 96121 96416 96837 98620 98676 99029 99111 99158 99569 99647 99837 100116 100168 ",
\ mode=2, dist=3, tolerance=50)


What could this error mean?


Third
The Filter works very bad at scene-changes. Is there something in your mind to solve this problem. This is why i have so many frames above. All these frames were at scenechange and were cleaned bad.



But at all i must say, that this is at the moment one of the best Filter to restorate old Movies...

Thank you

[kassandro]

now i can use RemoveDirt too (seems that i have an old AMD ).
Glad to hear, that the plugin works now for the older AMD's as well.



ConvertToYV12().RemoveDirt(range1= "1084 2971",
\ mode=2, dist=3, tolerance=50)


There is a misunderstanding. range1, range2, etc. expect file names as arguments, not frame sequences. Thus write a text file with "1084 2971" in it, but please without the quotes and let's call it, say, "range1.rd" and in your script replace the above line by

ConvertToYV12().RemoveDirt(range1= "range1.rd",
\ mode=2, dist=3, tolerance=50)

Then the script should work as intended.

IO Error with 1084 2971
That is an error message of RemoveDirt. It indicates an io error with the file named "1084 2971". In this case the filter couldn't simply open the file.

the named argument "range6" was passed more than once to RemoveDirt
This is an error message of Avisynth, not of RemoveDirt. It usually happens if a named argument is used more than once. Clearly you haven't done that. I will investigate this. Perhaps Avisynth has problems with the crazy length of the strings, which you used because of the above misunderstanding. Nevertheless Avisynth should be able to handle even longer strings. Now write for each range1, range2, range5, range6 a range file as above and make the appropriate changes to your script (hopefully the file names are shorter than the frame sequences).

The Filter works very bad at scene-changes. Is there something in your mind to solve this problem.
I wouldn't say bad. RemoveDirt simply can't clean at a sharp scene switch. I would say bad, if it would creat severe artifacts. That is truely the worst. You can force RemoveDirt to clean with tolerance=100. If there is not much motion the damage will be limited but I can't recommend it. It is somewhat better if you use the two pass method, as decribed in the documentation, at scene switches, but I can hardly recommend cleaning at scene switches. Whay can't RemoveDirt clean at scene switches? The basic idea behind any temporal cleaner is to compare frame n-1 and frame n+1. If their difference is much smaller in a certain area than the difference of frame n-1,n and the difference of n, n + 1, then one may suppose dirt in this area of frame n (unfortunately that is only half the truth). Now at a sharp scene switch the difference of frames n-1 and n+1 is unusually large, whence there will only be cleaning in very few random blocks. Nevertheless the basic idea can be modified to work at scene switches. Two cases have to be distinguished: 1. frame n is the last frame of a scene. 2. frame n is the first frame of a scene. In the first case, frame n+1 doesn't fit at all and has to be replaced by frame n-2. In the second case, frame n-1 doesn't fit and has to be replaced by frame n+2. However, one has to be very certain about a scene switch and the above modifications should only be used at scene switches. Obviously this special handling of scene switches has not yet been implemented in RemoveDirt and is of low priority because it concerns only a few frames. It is easier to creat a special filter, which only cleans at scene switches. My main priority is to improve cleaning in the presence of motion, without increasing artifact risk.

[Heini011]

Hi,

thanks very much for this great filter! i came to good results on
a movie with not very much noise:

RemoveDirt(pthreshold=25,cthreshold=40,mthreshold=200,athreshold=80,show=0)

so i think the default values for motion are quite conservative, but
for dirt detection they could become a litte bit more conservative...

the value of soscillation seems to have no influence at all - maybe
a bug ?!


greetings, Heini011.

[kassandro]

Originally posted by Heini011
the value of soscillation seems to have no influence at all - maybe
a bug ?!

greetings, Heini011.
since the last version I have raised the default value of doscillation to 260, which disables oscillation checking. You can reactivate oscillation checking by setting doscillation to a value well below 255. Then also soscillation beomes important again. As I wrote earlier, oscillation checking has turned out to be not very useful. On one hand, it does very little for artifact protection. On the other hand, it prevents a lot of dirt from being cleaned.

[Heini011]

Hi,

one good automatic solution for high-motion scenes:

FrameEvaluate("mot_level = (YDifferenceFromPrevious+YDifferenceToNext)/AverageLuma")

vid_mo=last
vid_st=RemoveDirt(pthreshold=25,cthreshold=40,mthreshold=160,athreshold=50,show=0)

ConditionalFilter(vid_st, vid_mo, "mot_level", "<", "0.07")

[kassandro]

Originally posted by Heini011
Hi,

one good automatic solution for high-motion scenes:

FrameEvaluate("mot_level = (YDifferenceFromPrevious+YDifferenceToNext)/AverageLuma")

vid_mo=last
vid_st=RemoveDirt(pthreshold=25,cthreshold=40,mthreshold=160,athreshold=50,show=0)

ConditionalFilter(vid_st, vid_mo, "mot_level", "<", "0.07")
Nice, my forthcoming filter ImproveSceneSwitch, part of RemoveDirt 0.6 due out next sunday, is based on the same idea. However, it will be a lot faster and it will handle both sides of a sharp scene switch. The last frame of a scene will be replaced by the penultimate frame, while the first frame of the new scene will be replaced by the second frame of the new scene.

[kassandro]

I just put up a new version of RemoveDirt to the web site. Actually RemoveDirt itself is almost unchanged. However two major features were added to the plugin. Firstly I have added a flexible preset facility to RemoveDirt, such that any user can creat his very own presets. Secondly I have added the the filter ImproveSceneSwitch, which is useful for most temporal filters to cope better with sharp scene switches. Thus it can not only be used with RemoveDirt but also with my deinterlacer AlignFields. For more details I refer to the updated documentation.

[Mug Funky]

thanks! i really dig this filter...

[FredThompson]

How does the output of RemoveDirt compare to Peach's output?

[kassandro]

Originally posted by FredThompson
How does the output of RemoveDirt compare to Peach's output?
I cannot find any source code for Peachsmoother. Thus I can only make guesses. As the name indicates Peachsmoother is blurring dirt, if it detects it. RemoveDirt tries to completely remove detected dirt. The advantage of blurring is that artifacts are less severe, if motion is confused with dirt. Thus RemoveDirt requires very sophisticated motion detection and artifact removal.
Peachsmoother is a temporal and a spatial filter. RemoveDirt is 98% temporal. It has a spatial aspect only, because all the processing decisions are based on 8x8 pixel blocks instead of single pixels.
Actually I recommend to use a slight softener after RemoveDirt, to deal with dirt, which could not be handled by RemoveDirt.
RemoveDirt is specifically aimed at dirt and scratches of photographic film, in particular the clips should be progressive. If the clip is telecined, it should be inverse telecined before using RemoveDirt, but best results are obtained with genuinely progressive material. RemoveDirt is not a general purpose noise filter.

[FredThompson]

OK, sounds great.

Any known problems filtering split interlaced source then weaving?

This might go a long way towards helping remove tape dropouts.

[scharfis_brain]

@fred:

If you want to filter VHS-dropouts, try this:

ibob() #do not use the internal bob. use ibob.dll
removedirt(params...)
separatefields()
selectevery(4,0,3) #or (4,1,2) choose the cripser one. depends on Fieldorder
weave()


I didn't tested this. Its just theoretically.
I think that removedirt could get some problems with the heigh-detail interlacing-shimmer, caused due to the bobbing.

I have no drop-out-sequences to test on.

[iradic]

hi...

i have this scene in movie with ship passing by - ship has some black vertical lines which are constantly removed/not-removed with removedirt

what settings should i tweak to avoid this?

thanks

[Mug Funky]

@ scharfi: avisynth's internal bob is lossless so long as the "a" parameter is zero. (a = "blurring", b = "ringing" parameters of the Mit-Net filter)

ie: bob() is not lossless as a=1/3 and b=1/3

but bob(0,.5) is lossless, as is bob(0,1)

you can verify with subtract(last, last.bob(0,.5).selectevery(4,0,3).weave)

you'll get pure grey...

(also, ibob() doesn't work in the latest binaries, unless i wasn't holding my mouth right)

[kassandro]

Originally posted by iradic
hi...

i have this scene in movie with ship passing by - ship has some black vertical lines which are constantly removed/not-removed with removedirt

what settings should i tweak to avoid this?

thanks
By the very nature of the algorithm, RemoveDirt can only clean dirt on single frames. If two subsequent frames have the same dirt at the same position it cannot be cleaned. Hoping that this is not the case,
the problem is the moving ship. With reasonable values of mthreshold etc. RemoveDirt does not clean in the presence of motion to avoid artifacts. However, you can force RemoveDirt to clean everything, by setting mthreshold=5000 and athreshold=5000. However, this should be done only for a selected number of frames and all the selected frames have to be checked for artifacts. The selected frame numbers or frame range should be written to a file, say, "clensing" as described in the documentation. Then
RemoveDirt(range1="clensing", mthreshold1=5000, athreshold1=5000, ...)
should totally clean the frames specified in the file clensing, while the other frames are processed as usual.

[iradic]

sorry i wasnt clear...

you are explaining situation where i want to remove these black lines right?
well i dont want to (my wrong words - "lines" - are part of the ship)...
anyway i will try to work with those tresholds but in opposite values - trying to save these "lines"...

thanks for help

[kassandro]

Originally posted by iradic
sorry i wasnt clear...

you are explaining situation where i want to remove these black lines right?
well i dont want to (my wrong words - "lines" - are part of the ship)...
anyway i will try to work with those tresholds but in opposite values - trying to save these "lines"...

thanks for help
I see, you want to preserve the black lines. If they are only partially erased, then pthreshold and cthreshold are too low. Try pthreshold=20 or 10, cthreshold shouldn't matter much, because it seems to more a luma problem. The default value pthreshold=50 seems to be too aggressive in general. This was already remarked by other users.

[krieger2005]

Can You explain how the extrapolation-method works. I think does not seen the description about.

I tried the function for now. At Scenechange i need a ratio of "3" (at my movie). Interesting is that at ratio=2 the Function found other Scene-changes but not the same as with ratio=3 (with ratio=3 were not all scene-changes found). While the frame-doubling generate "clean" frames the extrapolation generate an "oversharp"-shadow frame. But as you are write at your description, the frame-double-method is bad, when an "fast-scene" is detected as "scene-change". I had seen such situation in my test-movie (with frame-doubling) and does not notice any bad artifacts (while see the movie at TV).

So for now the extrapolation-method is not my preferntial because it generate an oversharp frames and this look in the movie like an artiface (but not realy noticeable)

[kassandro]

Originally posted by krieger2005
Can You explain how the extrapolation-method works. I think does not seen the description about.

To explain (linear) extrapolation, let me first recall (linear) interpolation. If c[x,y,t] denotes the luma value of the pixel with coordinates x,y at time t, then (c[x,y,0] + c[x,y,2])/2 = c[x,y,0] + (c[x,y,2] - c[x,y,0])/2 is the interpolated luma value at time 1. If we have the values at time 0 and 1 and want to extrapolate the value at time 2, then c[x,y,0] + (c[x,y,1] - c[x,y,0])*2 is the natural analogue of interpolation, but because the parameter 2 is now outside the interval [0,1], this kind of procedure is now called extrapolation instead of interpolation. There one problem with extrapolation: while the interpolated value is always between the two values, this is no more the case for extrapoaltion. In fact, if c[x,y,0] and c[x,y,1] are within the "byte" range 0-256, the extrapolated value may be outside the byte range. Fortunately there are the SSE instructions paddusb and psubusb, which keep the extrapolated value within the byte range. Thus extrapolation can be implemented nicely with SSE.


Interesting is that at ratio=2 the Function found other Scene-changes but not the same as with ratio=3 (with ratio=3 were not all scene-changes found).

Any scene switch found with ratio=3 must be also be found with ratio=2. The lower the value of ratio the more the number of scene switches. There is one exception, though: arithmetic overflow. If the frames of a clip are made of 400,000 pixels, the maximal difference in the yv12 color space is 400,000*255. Now if ratio*400000*255 exceedes 1<<32 (approximately = 4000,000,000), then arithmetic overflow is possible and this may already happen with ratio=40. Now if the color space is RGB32, then the maximal difference is 400,000*255*4 and arithmetic overflow becomes possible already at ratio=10. Of course, I could have avoided arithmetic overflow altogether, by using division instead of multiplication. However, it is a good programmer's rule to avoid division as much as possible, because division, unlike multiplication, is a very slow cpu instruction.
Dirt may distort massively the frame differences. Taking this into account, better scene switch detection with higher ratio value can be obtained for RemoveDirt with

dein=RemoveDirt(input)
ImproveSceneSwitch(dein, dein)

instead of

dein=RemoveDirt(input)
ImproveSceneSwitch(dein, input)

as recommended in the documentation. However, for deinterlacing such a changed should not even be considered.


While the frame-doubling generate "clean" frames the extrapolation generate an "oversharp"-shadow frame. But as you are write at your description, the frame-double-method is bad, when an "fast-scene" is detected as "scene-change". I had seen such situation in my test-movie (with frame-doubling) and does not notice any bad artifacts (while see the movie at TV).

If two many frames are doubled, the motion may look jerky, while with extrapolation it should be smoother. I also noted the oversharpness of extrapolated frames.


So for now the extrapolation-method is not my preferntial because it generate an oversharp frames and this look in the movie like an artiface (but not realy noticeable)
I hope for further feedback. Extrapolation can be nicely implemented with SSE, that was the primary reason, why I did it. However, if it doesn't turn out to be useful, I will not hesitate to remove it.

I also observed that after encoding with ImproveSceneSwitch VdubMod is crashing upon exit. This is probably due to a missing emms instruction and will hopefully be corrected soon.

[SILICON]

I test the filter and i have a great result

The compresibility gain are very good in a good quality film (MINORITY_REPORT).

In films with spots, remove it.

Can you add a presets for noise and clean film?
Can you put ImproveSceneSwitch inside of RemoveDirt (as switch)?

Thank for you great pluging.

[kassandro]

Originally posted by SILICON
Can you add a presets for noise and clean film?

Thanks for your kind comments. Starting with version 0.6 there is a preset facility built into the plugin. However, you have to creat a the file RemoveDirt.ini yourself. Then you can simply use RemoveDirt(default="noise") or RemoveDirt(default="clean"), if you have created presets named "noise" and "clean".

Can you put ImproveSceneSwitch inside of RemoveDirt (as switch)?

I think that this would not be a very good idea. Firstly, for easy maintenance, it is better to keep different things separate. Secondly, the scene switch problem is a problem for most temporal filters. It is more severe for advanced deinterlacers than for RemoveDirt.

[kassandro]

I just put up version 0.6.1 to the web site. Besides correcting an emms problem for ImproveSceneSwitch, RemoveDirt has undergone substantial changes. Firstly I have removed the oscillation code. While theoretically nice the underlying idea has turned out to be poor in practice. Consequently, the variables doscillation and soscillation are now obsolete. I also lowered the default value of pthreshold from 50 to 20. If tolerance=0, then there should be no difference between version 0.6 and 0.6.1. If tolerance > 0 only blocks near the margins may be handled differently by the two versions. Of course, the oscillation code has to be disabled (as is the deefault) in version 0.6 for comparison with version 0.6.1. Version 0.6.1 should be slightly faster than version 0.6, however the speed increase should hardly be measurable.
Why these changes? They are in preparation of a major change in version 0.7. At least I hope so. By providing an alternative motion detection, I hope for cleaning in the presence of a certain type of motion. Most of the work is already in the source code, but I have first to check whether my idea really works in practice.

[SILICON]

One temporal filter, check the previous and the next frame (frames -1, 0 and 1).
If no motion for frame -1 to frame 1, you filtes think thae the motion in frame 0 are noise. Isn`t it?
In the scene switch, we don´t have previous frame, because the previous freme are very diferent and the temporal filter don´t work.

But the motion are in several frames, not only in two frames. In scene switch, you can check the two next frames. If one block don´t have motion for the frame 1 to 2, you can estimate that haven't motion for the frame 0 to Frame 1 (The change are noise, and not motion.)

If you are wrong, the artifact are the same that the actual SceneSwitch, but you cannot wrong for every blocks.

In resume, This metod will make lees artifact the the actual SceneSwitch. Can you test it?