RemoveGrain

[Didée]

Jeeze, that is grain! On such a source, LRemoveDust is clearly out of the race - it's mostly good as long as all noise or grain can be pressed down with a reasonable limit. This is clearly not the case here ...
(However looking at the filesizes, LRemoveDust wasn't all that bad, either. Try to filter that source with e.g. Convolution3D ... )

Another thought - I'm not sure how sensitive MVTools' motion engine actually reacts on noise. But perhaps it would be good to replace the clip's cleaning that MCRemoveDust is doing by RemoveGrain(mode=12) (before creating the motion vectors) by an instance of RemoveDust itself? I could imagine that MVTools like this better, if the source contains *so* much grain.

[kassandro]

Originally posted by Didée

Another thought - I'm not sure how sensitive MVTools' motion engine actually reacts on noise.

mvtools uses SAD, i.e. it sums up the absolute differences of the pixels of the blocks. I used the same routine in RemoveDirt and it is quite noise sensitve. However, mvtools is already designed such that SAD can easily ber replaced by other block difference functions and in the upcoming new RemoveDirt I have a modified SAD which ignores a certain noise level, i.e. instead of summing up |x_i - y_i| I sum up max(0, |x_i - y_i| - noise), where noise is usually a small number below 10. This is in a way opposite to what you have done with RemoveDust. The modified SAD just ignores that noise, which is cleaned by LRemoveDust. Clearly the modified SAD is slower than the original one, but with SSE2 the modified SAD should be about as fast as the simple SAD with ordinary SSEMMX. Because RemoveDirt spends most of its time measuring block differences I will therefore provide an SSE2 version. Similarily MVAnalyse spends well over 90% of its time measuring block differences.

But perhaps it would be good to replace the clip's cleaning that MCRemoveDust is doing by RemoveGrain(mode=12) (before creating the motion vectors) by an instance of RemoveDust itself? I could imagine that MVTools like this better, if the source contains *so* much grain.

That is a good idea. When I designed this script, I wanted to make it as fast as possible and I have now even a faster version of RemoveGrain(mode=12), but it really doesn't matter, because the time spent within these filters is neglible compared with the two MVAnalyse calls. It may be even be faster, because the motion vector search terminates as soon as it has found a resonably good vector. That is the reason, why XviD with RemoveDust is much faster than without. In fact, in the last benchmark the unfiltered encoding took almost 50% longer than with RemoveDust (the unfiltered encoding took only 30% less than with MCRemoveDust). In my encodings I always use XviD qpel motion vector search with Turbo mode. Without Turbo mode the speed would probably be even larger, but without qpel probably a lot smaller.

[morsa]

You see..that is my problem.
Super8 black an white film has way more grain than that and far more contrasty...
So none of the filters here can remove its noise, at least with more or less normal settings...
(just a comment)

[redfordxx]

Hi,
I have tried your scripts and wanna share experience (I have low noise source LOTR TTT).
RemoveDustMC: Probably same experience as Scharfis brain --- Blurred blocks, and for me label unusable I didn't try Didée's LRDMC, since I read it just now. Probably helps... (after trimming first frame before SelectEvery, if I understand the idea correctly?)
LRemoveDust: much better experience --- removed the noise I wanted to... large surfaces (sky, snow..). But little problems with motion: When an object is moving relatively fast, it gets smaller (wow, hope Einstein doesnot hear me). The reason is, I think, that Repair not able to fully compensate the brutality with which Clense attacks moving objects. So, as I am beginner in the area, what do you think of following line as an aid (between Clense and Repair)

clensed=YV12LUTxy(clensed,input,"x y - abs 6 > y x ?","x y - abs 6 > y x ?","x y - abs 6 > y x ?",Y=3,U=3,V=3)

where 6 is threshold to be tuned. (I suppose limitchange does something like this, but inserting it here shoud provide better results, i think)
Other idea can be
input.MotionMask(.Inpand.Expand???)
MaskedMerge(...where is motion, use input, otherwise clensed)

[redfordxx]

Is somewhere described ShrinkBy2, LimitChange...?

[redfordxx]

As you are presenting some comparisons, I add one as well if u don't mind (low noise source, H.263, 1passQ2):

unfiltered:                 0.400 bit/(pixel*frame)
LRemoveDust(3 (or 4?),1):   0.357 bit/(pixel*frame)

(IMHO bpp gives more info than filesize)

[kassandro]

Originally posted by redfordxx
As you are presenting some comparisons, I add one as well if u don't mind (low noise source, H.263, 1passQ2):

unfiltered:                 0.400 bit/(pixel*frame)
LRemoveDust(3 (or 4?),1):   0.357 bit/(pixel*frame)

(IMHO bpp gives more info than filesize)

The terrrible compression results are easily explained. With LRemoveDust(3 (or 4?),1) you allow LRemoveDust to change the Luma value of each pixel only by 1. With LRemoveDust(3 (or 4?),0) the Luma wouldn't be changed at all. Please use more reasonable values like 4 for the second parameter.

[redfordxx]

Originally posted by kassandro
The terrrible compression results are easily explained. With LRemoveDust(3 (or 4?),1) you allow LRemoveDust to change the Luma value of each pixel only by 1. With LRemoveDust(3 (or 4?),0) the Luma wouldn't be changed at all. Please use more reasonable values like 4 for the second parameter.

In fact, this was the last of my three post I expected being answered...
By "terrrible compression results" you understand small compression gain, right? Well as I said, I have low noise source and don't need heavy denoising. I want to preserve some detail. Moreover, I dont know exactly what LimitChange does... (my second post)
I also suppose, that the sources you used would have higher bpp than 0.400, so the potential is higher. (that's why I wrote it gives more info, than filesize)
Well, maybe I'll experiment with the limit parameter.

BTW: I limit chroma as well I hope (no limitU=255 parameter)
BTW2: Some experiment results: MotionMask does not preserve the moving object as well as YV12LUTxy...(maybe it is about threshold setting)

[Bexley]

I'm trying to play around with MCRemoveDust, but I can't get SSETools to work. VDubMod throws an error like "AVISynth open failure: AVISynth: script open failed!" If I delete it from my plugins directory, the script loads, but of course the MCRemoveDust function doesn't work.

Am I doing something dumb again, or does SSETools not work on an Athlon T-Bird?

[kassandro]

Originally posted by redfordxx
In fact, this was the last of my three post I expected being answered...
By "terrrible compression results" you understand small compression gain, right? Well as I said, I have low noise source and don't need heavy denoising. I want to preserve some detail. Moreover, I dont know exactly what LimitChange does... (my second post)

LimitChange does the same as YV12LUTxy with special yexpr, uexpr, vexpr (see Didee's original LRemoveDust). It simply limits the amount of change. For instance if the filtered pixel has the y value 200 and the unfiltered pixel has the y value 100, then the y value is replaced by 104 if LimitChange(filtered, unfiltered, 4) is used. If you use LimitChange(filtered, unfiltered, 1) then the y value is replaced by 101.

I also suppose, that the sources you used would have higher bpp than 0.400, so the potential is higher. (that's why I wrote it gives more info, than filesize)
Well, maybe I'll experiment with the limit parameter.

You can safely take 4 instead of 1. The difference is hardly visable. Moreover, codecs certainly make substantially more significant changes through quantising.

BTW: I limit chroma as well I hope (no limitU=255 parameter)
BTW2: Some experiment results: MotionMask does not preserve the moving object as well as YV12LUTxy...(maybe it is about threshold setting)

That's correct. If you drop limitU=255, then LimitU inherits the value 4. You may safely take limitU=10, because the human eye is much less sensitve to chroma changes than to luma changes. Filters like CNR2 change the chroma much more aggressively.

Originally posted by Bexley
I'm trying to play around with MCRemoveDust, but I can't get SSETools to work. VDubMod throws an error like "AVISynth open failure: AVISynth: script open failed!" If I delete it from my plugins directory, the script loads, but of course the MCRemoveDust function doesn't work.

Am I doing something dumb again, or does SSETools not work on an Athlon T-Bird?

SSETools has some filters, which use floating point SSE (however, this filters are not used with MCRemoveDust). Probably, the Athlon Thunderbird only supports integer SSE. I may provide a version without checking for full SSE next weekend. It will of course crash if some of the floating point SSE filters is used, but they aren't yet documented either.

[Heini011]

hi kassandro,

i have an athlon xp and have the same problem. ssetools and the current RemoveGrain.dll doesn't work. RemoveGrainS.dll is ok.

system: win 2k, avisynth 2.55

VirtualDub Error

Avisynth open failure:
LoadPlugin: unable to load "C:\Programme\Avisynth 2.5\plugins\SSETools.dll"

greetings.

[kassandro]

Originally posted by Heini011
hi kassandro,

i have an athlon xp and have the same problem. ssetools and the current RemoveGrain.dll doesn't work. RemoveGrainS.dll is ok.

system: win 2k, avisynth 2.55

VirtualDub Error

Avisynth open failure:
LoadPlugin: unable to load "C:\Programme\Avisynth 2.5\plugins\SSETools.dll"

greetings.

The Athlon XP certainly has floating point SSE. Thus the problem is a missing DLL. I think you need msvcp71.dll (but I am not sure about it). Until the end of 1004 I had Visual Studio 2002 and it required msvcp70.dll. As I have now moved to Visual Studio 2003 also the DLL has changed. Each version of the C++ compiler has its own DLL.

Probably the them is true for Bexley's Athlon Thunderbird.

[Leak]

Originally posted by kassandro
The Athlon XP certainly has floating point SSE. Thus the problem is a missing DLL. I think you need msvcp71.dll (but I am not sure about it). Until the end of 1004 I had Visual Studio 2002 and it required msvcp70.dll. As I have now moved to Visual Studio 2003 also the DLL has changed. Each version of the C++ compiler has its own DLL.

Probably the them is true for Bexley's Athlon Thunderbird.

For those missing a DLL:

http://www.dependencywalker.com/ is a good tool to check for missing DLLs - it's free and it's not hard to use...

np: Funkstörung - Captured In Tones (ft. Sarah Jay) (Disconnected)

[Bexley]

I may provide a version without checking for full SSE next weekend. It will of course crash if some of the floating point SSE filters is used, but they aren't yet documented either.

Thanks, kassandro. I checked and the DLL isn't my problem, so that would be awesome.

[kassandro]

I have uploaded a new inofficial.zip. It contains a staticly linked SSEToolsS.dll.

@Bexley:
Did you copy several versions of SSETools in the plugin directory. Only one version of SSETools (in the future the SSE2 version will be called SSE2Tools and the SSE3 version will be called SSE3 Tools) and RemoveGrain should be in the plugin directory. Otherwise it is not predictable, which plugin is chosen be Avisynth. If the SSE2 or SSE3 is chosen, then Athlon32 owner will have troubles. Actually, the old SSETools did only check for integer SSE and not full SSE.

[Bexley]

Ugh... I have a big problem, then.

I only have one version of SSETools.dll and RemoveGrain.dll in my plugins directory. I wonder if some other plugin might be causing a conflict... I'll try removing all unnecessary plugins when I get home and see if that helps.

[kassandro]

Originally posted by Bexley

I only have one version of SSETools.dll and RemoveGrain.dll in my plugins directory. I wonder if some other plugin might be causing a conflict... I'll try removing all unnecessary plugins when I get home and see if that helps.

You also need Repair.dll from the official RemoveGrain.zip on www.RemoveGrain.de.tf. I am sorry for that mess, but it will take a while until I can return to RemoveGrain.

[Bexley]

No joy.

I removed all unnecessary plugins and made sure I have the most current versions of everything, and VDub still throws an error. The only way to load a script is to remove SSETools from the plugin directory. Oh well.... I'm still having fun with LRemoveDust, so I'll keep playing with that for a while.

[kassandro]

Originally posted by Bexley
No joy.

I removed all unnecessary plugins and made sure I have the most current versions of everything, and VDub still throws an error. The only way to load a script is to remove SSETools from the plugin directory. Oh well.... I'm still having fun with LRemoveDust, so I'll keep playing with that for a while.

You may also use Didde's original version. It doesn't require LimitChange. YV12LUTxy is used instead. On the other hand it would be nice to know the reason for failure. Avisynth's error message are unfortunately not very informative.

[kassandro]

I just have uploaded a new version of my RemoveGrain plugin. It became necessary because in the thread http://forum.doom9.org/showthread.php?s=&threadid=91823
a bug in the YUY2 version of TemporalRepair was discovered. Rather than fixing the YUY2 code, I dropped the interleaved YUY2 support altogether and replaced it by planar YUY2 (this is the reason why I have included inofficial versions of SSETools, which contain the filters Interleaved2Planar and Planar2Interleaved). The above thread contains also a claim by scharfis_brain, that the deinterlacer RGDeinterlace contructed with RemoveGrain is a "superblurrer", which blurs static areas. This is false as the test scripts in the above thread show, but scharfis_brain is not willing to withdraw his claim.
I have added also new bob modes 15,16 which are slightly better than modes 13,14 but also slightly slower.
However, the most import change is the new mode 17. It is a denosing mode for truely progressive film only, just like modes 1-10. I really love it. When the very aggressive mode 4 doesn't destroy thin lines, mode 17 uses this mode for denoising. If mode 4 is destructive, then mode 17 denoises more conservatively such that thin lines are preserved. The first test results with a b&w video clip (3962 frames) are impressive:

no cleaning           32.463.010 Bytes
RemoveGrain(mode=8)   29.964.964 Bytes
RemoveGrain(mode=9)   29.994.246 Bytes
RemoveGrain(mode=17)  28.221.649 Bytes
RemoveGrain(mode=4)   28.043.482 Bytes

Thus mode 17 clearly beats my old favorite mode 8 and comes quite close to the very aggressive mode 4. Of course, these results have to be confirmed by more extensive tests. Mode 17 seems to be ideal for any kind of postprocessing as, for instance, in RemoveDust. Previously mode 4 was used for this purpose and to avoid excessive softness it had to be corrected by TemporalRepair. This correction is no more necessary with mode 17. Compression should improve slightly while softness is reduced.

There are also substantial changes for the Repair filter. Modes 5-9 have now become useful by including the center pixel. Mode 9 repairs all thin lines, mode 5 now behaves similaroutput files to mode 2 and modes 6-8 are between mode 5 and 9. Of course, if mode 9 is used in RemoveDust, it has negative impact on compression (are 5-20% larger). However, mode 9 is ideal for the new RemoveDirt. It is used for cleaning the non-static areas, which are identified by the filter RestoreMotionBlocks of the new RemoveDirt plugin, and keeps these areas quite sharp, while for the static areas Repair isn't applied at all. My first tests with this new RemoveDirt script function show slightly better compression than with RemoveDust (with Repair(mode=2)) with significantly sharper non-static areas.