RemoveGrain

[vigi_lante]

Not really. I was using, of course, PixieDust with that exactly script, including IVTC.

I tried to use it without IVTC, and speed is just a little faster. That IVTC script also have "post" disabled too, so it's not pushing too much.

Anyway, this filter is great! I just wish I could get that speed too.

[kassandro]

I just ran a further small test. Source was fairly poor. The film was mastered about 30 years ago on a tape and the quality of the tape detioroated over the years (4420 frames).

unfiltered 27.183.680 Bytes
RemoveDust 15.103.098 Bytes
MCRemoveDust 15.969.790 Bytes
LRemoveDust 17.426.043 Bytes

LRemoveDust clearly profited from not limiting the cleaning of the chroma, because the chroma was even worse than the luma.

[vigi_lante]

What about using filters like Undot or Cnr2 with LRemoveDust ? Could it give better results ? (with analog TV source)

[kassandro]

Originally posted by vigi_lante
What about using filters like Undot or Cnr2 with LRemoveDust ? Could it give better results ? (with analog TV source)
Read the beginning of the documentation of RemoveGrain for its relation with Undot. Also this thread contains lots of information about the RemoveGrain/Undot relation.
CNR2 is a filter, which only effects the chroma. It is essentially a temporal filter. The basic idea is to average the chroma of the current frame with that of previuos frame, where the weight of the averages depend on the luma and the chroma differences. This is certainly a good idea and it can also be implemented in a spatial context, though such a filter would be much slower. Having said that I cannot understand the logic behind the computed weights. Actually these weights do not make much sense to me. If somebody is interested I can easily provide a variant of this filter with simpler and more reasonable weights, which would be closer to the basic idea of this filter.


EDIT: A spatial version would have the advantage of avoiding ghosts!

[Boulder]

If you can make a tweaked CNR2, I'm all for it:) The problem with the filter is that it causes chroma ghosting very easily, even at the default values. Then again, it removes noise very effectively when dealing with analogue material.

Out of interest, what causes the spatial version to be much slower?

[kassandro]

Originally posted by Boulder
If you can make a tweaked CNR2, I'm all for it:) The problem with the filter is that it causes chroma ghosting very easily, even at the default values. Then again, it removes noise very effectively when dealing with analogue material.

I probably can't remove the ghosting significantly. However, MarcFD uses only the previous frame for temporal cleaning and ignores the subsequent frame, which would be equally good. Because temporal cleaning ord enoising is quite risky, it is a golden rule to use both the previous and the subsequent frame. I would simply choose for each pixel the best one. As a byproduct I wouldn't have to worry about scene switches as MarcFD. On the other hand, the memory access costs are 50% higher. But the very simple algorithm is very cache friendly, so it shouldn't be a big penalty.


Out of interest, what causes the spatial version to be much slower?
MarcFD relates a pixel of a frame only to the same pixel on the previous frame. My modification would also consider the same pixel on the subsequent frame. If I would do it spatially, then I would have to consider all the eight spatial neighbours of the pixel, which is quite a drag, if one can't use SSE/MMX.

It is fairly easy to do the temporal version outlined above. Probably I will do it next weekend.

[vigi_lante]

CNR2 is very fast too.

But it's recommended to use CNR2 after or before LRemoveDust ?

[kassandro]

Originally posted by vigi_lante
CNR2 is very fast too.

I would call it moderately fast. It cannot compete with SSE/MMX optimised filters like Undot or RemoveGrain (YV12 version only).


But it's recommended to use CNR2 after or before LRemoveDust ?

I have only done one analog capture and that was a b&w VHS movie. Usually I just record DVB streams. Thus I am not a user of CNR2 and really can't answer this question. However, applying CNR2 after LRemoveDust should denoise more than in reverse order.

[vigi_lante]

Read the beginning of the documentation of RemoveGrain for its relation with Undot. Also this thread contains lots of information about the RemoveGrain/Undot relation.


Sorry my ignorance, but it's very hard for me to understand all those tech talk...so, just to keep everything easy: Undot with LRemoveDust is good or bad ? :) Because the compressibility gain with Undot is very nice.

One more thing...is there any other option for LRemoveDust to work with very noise sources ?

[vigi_lante]

I just record DVB streams

Here, the same cable that delivers analog TV also delivers DVB stream. Right now I'm wondering if would be better to capture analog or digital, because DVB uses MPEG-2 compression for video...so you can't avoid artifacts. Analog is more noiser, but without artifacts.

[kassandro]

Originally posted by vigi_lante

Undot with LRemoveDust is good or bad ?

It doesn't really harm to combine it, but it really doesn't make sense either.



Because the compressibility gain with Undot is very nice.

The compression gain with Undot (or equivalently RemoveGrain(mode=1)) is neglible (at least with my digital sources) compared with that RemoveDust. If your extremely conservative, you may use RemoveGrain(mode=2) instead of Undot. The compression gain is about twice as much and the artifact risk is nearly as low as with Undot.


Here, the same cable that delivers analog TV also delivers DVB stream. Right now I'm wondering if would be better to capture analog or digital, because DVB uses MPEG-2 compression for video...so you can't avoid artifacts. Analog is more noiser, but without artifacts.
In static areas DVB is vastly superior over analog and in motion areas DVB may sometimes be inferior to analog, but altogether it would be nightmare for me to go back to analog.
Also recording DVB streams is so easy. You do not have to worry about frame drops and a/v sync and disk space. While recording streams you can easily encode a video with Vdub. This is unthinkable during analog capturing. With massive analog capturing you also reduce the life time of your hard disks substantially. Also you can convert the DVB stream into DVD without reencoding.

[vigi_lante]

In static areas DVB is vastly superior over analog and in motion areas DVB may sometimes be inferior to analog, but altogether it would be nightmare for me to go back to analog.
Also recording DVB streams is so easy. You do not have to worry about frame drops and a/v sync and disk space. While recording streams you can easily encode a video with Vdub. This is unthinkable during analog capturing. With massive analog capturing you also reduce the life time of your hard disks substantially. Also you can convert the DVB stream into DVD without reencoding.

WHAT !? I didn't know this was possible.

But what I need to directly record those streams ? Any special capture card ?

I was thinking it was just like capturing analog signal.

Here I have an settop-box to receive DVB broadcasts. This settop-box convert the digital signal to analogue, in order to work with a normal TV. So, I didn't know there were other ways to capture, besides capture the analogue output from the settop box.

[Boulder]

You need a DVB capture card to do that. Then you can get the same stream that comes to the set-top box.

[vigi_lante]

But what about if the signal is encrypted and needs the settop box to decode it ? It's possible to happen ?

[Boulder]

The streams that you have to pay for are encrypted.

This is getting OT, so you'd better see the appropriate forum section for more and detailed info.

[vigi_lante]

Originally posted by Boulder
The streams that you have to pay for are encrypted.

This is getting OT, so you'd better see the appropriate forum section for more and detailed info.

The problem is that I pay for everything... :scared:

Sorry for the OT.

[vigi_lante]

you may use RemoveGrain(mode=2) instead of Undot. The compression gain is about twice as much and the artifact risk is nearly as low as with Undot.


In this case, I need to use RemoveGrain(mode=2) + LRemoveDust ?

[Boulder]

I wouldn't use RemoveGrain with LRemoveDust, MCRemoveDust or RemoveDust. All of those functions actually include RemoveGrain(mode=4) by default.

[vigi_lante]

Originally posted by Boulder
I wouldn't use RemoveGrain with LRemoveDust, MCRemoveDust or RemoveDust. All of those functions actually include RemoveGrain(mode=4) by default.

What about LRemoveDust with Undot ?

[Didée]

Originally posted by vigi_lante
What about LRemoveDust with Undot ?
/*getting nervous*/

f-o-r-g-e-t i-t! Please!

There is *no need* to assist LRemoveDust with *anything* like undot or removegrain.

[vigi_lante]

Originally posted by Didée
/*getting nervous*/

f-o-r-g-e-t i-t! Please!

There is *no need* to assist LRemoveDust with *anything* like undot or removegrain.

What I'm just asking if there is any side effect using Undot. Because if not, I see no reason to not use it, since it is very fast and gives a very good compression gain.

[Boulder]

LRemoveDust already does the same work - and more - it will remove the stray pixels UnDot would. UnDot is almost exactly the same as RemoveGrain(mode=1) as kassandro already told you. Thus, no need to use it.

[Didée]

Well, after having a second thought about it, there could be cases where it IS useful to to let LRemoveDust follow a RemoveGrain(1).

E.g. LRemoveDust(4,2) will change no pixel by more than +/- 2. Now, if the source contains stray pixels that are standing out very much in value, those would be filtered too weakly, and a final Removegrain(1) would make sense.

Haven't encountered something like that so far, at lest not visually. But it would be possible. My apologizes to vigi_lante.

[scharfis_brain]

mcremovegrain gave me weird blocking artifacts on non predictable movements like flames.
also, it blurs the entire frame like hell.

anything I can do against it?

[Didée]

Originally posted by scharfis_brain
mcremovegrain gave me weird blocking artifacts on non predictable movements like flames.
also, it blurs the entire frame like hell.

anything I can do against it?
Yes. Yesterday I tried something like

function LRemoveDustMC(clip input, int _smooth, bool _grey, int "limit")
{
limit = default( limit, 3 )
repmode = 2
clmode = 4
quad = Quadruple(input) # each pixel is quadrupled, SSETools are needed
qpel = RemoveGrain(quad, mode=12, modeU=-1) # blur the luma for searching motion vectors
bvectors = MVAnalyse(qpel, blksize=16, lambda=200, isb=true)
fvectors = MVAnalyse(qpel, blksize=16, lambda=200, isb=false)
backward = MVCompensate(quad, bvectors)
forward = MVCompensate(quad, fvectors)
# clensed = mcclense(quad, backward, forward, grey=_grey).shrinkby2(grey=_grey) #SSETools are needed for shrinking
# rep=Repair(clensed, input, mode=repmode, modeU=_grey ? -1 : repmode)
# rg = RemoveGrain(rep, mode=clmode, modeU=_grey ? -1 : clmode)
interleave(backward,input.Quadruple(),forward)
LRemoveDust(4,limit)
SelectEvery(3,1)
shrinkby2(grey=_grey)
# return TemporalRepair(rg, rep, grey=_grey, smooth=_smooth)
return last
}
Actually, I forgot to take the function made yesterday with me. The above is just re-typed, from memory. Hope it works. (If not, you get at least the idea).

[scharfis_brain]

Thanks
it works, BUT
all those functions I saw here de only filter over a window of 3 frames. (radius = 1)
For a temporal filter this is definitly not enough!
only when I call them twice:
lremovedustmc().lremovedustmc()
i get a nice denoised result.
but this probably has not been in the intention of the inventor.

for temporal filtering a radius of two or three would be very nice

[scharfis_brain]

It would be great, if one of those denoisers here could fight with noise amounts like manaos filter:
http://forum.doom9.org/showthread.php?s=&threadid=89555

unfortunately it never processes moving edges :(

[Piper]

@Kassandro: I've just tried numerous attempts at www.RemoveGrain.de.tf to find a download location for RemoveGrain and each time I get a Gateway Timeout error. I've googled/searched the forum for an alternative download site but so far have come up with nothing. Is there an alternative URL where I can find a current version of RemoveGrain.dll? Thanks

[kassandro]

Originally posted by Piper
@Kassandro: I've just tried numerous attempts at www.RemoveGrain.de.tf to find a download location for RemoveGrain and each time I get a Gateway Timeout error. I've googled/searched the forum for an alternative download site but so far have come up with nothing. Is there an alternative URL where I can find a current version of RemoveGrain.dll? Thanks
The server in Austria, where my files are located, seems to be down. If that continues until tomorrow night, I will upload the files to my Geocities account and map the domain to this server.

[kassandro]

Originally posted by scharfis_brain
mcremovegrain gave me weird blocking artifacts on non predictable movements like flames.
also, it blurs the entire frame like hell.

anything I can do against it?
It is true, that if the motion compensation fails from both sides, i.e. low quality motion vectors, then motion gets blurred by MCRemoveDust in the same way as with the original RemoveDust. If it fails only from one side, then denoising may be poor, but there shouldn't be any significant damage. If the moving objects are homogeneous, i.e. have no fine details, then the edges should be still sharp, when filtered with RemoveDust or when MCRemoveDust cannot get good motion vectors. With RemoveDust moving thin lines or structures may flicker, when they are in motion. With MCRemoveDust that flicker is quite rare, because in these cases the motion compensation usually works quite well. On the other hand big artifacts should be equally impossible as cleaning of big spots. This is simply assured by the Repair plugin.
Scharfi, could you please post an example, i.e. the unfiltered and the filtered frame with the weird artifacts.

[Piper]

Originally posted by kassandro
The server in Austria, where my files are located, seems to be down. If that continues until tomorrow night, I will upload the files to my Geocities account and map the domain to this server.

Thanks, sorry to be the one to point out server difficulties. Hope you're able to get it sorted without too much hassle.

[kassandro]

Originally posted by scharfis_brain
It would be great, if one of those denoisers here could fight with noise amounts like manaos filter:
http://forum.doom9.org/showthread.php?s=&threadid=89555

unfortunately it never processes moving edges :(
I couldn't download badnoise.zip. But from the picture shown in this thread, it is obvious that this is interlaced material. Virtually all the filters in RemoveGrain are for progressive material only and RemoveDust is very destructive for interlaced material. In fact, if moving information mastered afterwards on a film (it is nearly always interlaced), as it is often done by tv broadcasters, this interlaced information is treated quite poorly by RemoveDust. I simply apply RemoveDust(mode=14) before RemoveDust on those parts and only on those parts usually at the end or the beginning of a movie. mode=13,14 are true bob modes (a true bob is allowed to use only one field, must preserve this field and interpolate the other) very similar to Tomsmocomp(1,0,0), but substantially faster. Actually the RemoveGrain in inofficial.zip (see the link in an earlier posting) has also the bob modes 15,16 which are slightly slower than modes 13,14 but are of higher quality (better compression and in my objective quality test for true bob filters they should be very difficult to beat).

If the entire video is interlaced, then one may denoise the fields seperately, but this is definetly not recommendable. Instead one should denoise both RemoveGrain(input, mode=13) (bottom field preserved, top field interpolated) and RemoveGrain(input, mode=14) (top field preserved, bottom field interpolated) or better use modes 15,16 instead and then merge the two denoised clips together (the bottom field from the first and the top field from the second clip). This is very similar to a standard technique of scharfis_brain, which he uses also for resizing and other spatial filtering of interlaced content.

[scharfis_brain]

I am not referring to interlacing!
look at the scripts and you will notice, that the filter only works with progressive frames (deinterlacer before it).

(I always bob-deinterlace interlaced video, to be able to treat it like progressive video!)

[kassandro]

Originally posted by scharfis_brain
I am not referring to interlacing!
look at the scripts and you will notice, that the filter only works with progressive frames (deinterlacer before it).

(I always bob-deinterlace interlaced video, to be able to treat it like progressive video!)
Of course, I have seen that, but for a real test the video should always be genuinely progressive. No matter how you do it, the interpolated field will always contain less information than the preserved field. Thus the two fields asymmetric and this is simply not natural. This is also the key reason, why deinterlacers, which always preserve one field, perform so poorly as far as compression is concerned.

[scharfis_brain]

man.
I never told, that I want to denoise interlaced contents!

It is just a very grainy and rainbowy PAL progressive video.

[kassandro]

I meant the video in the thread http://forum.doom9.org/showthread.php?s=&threadid=89555. Though it can no more be downloaded, it is obviously interlaced as shown by the picture there.

[scharfis_brain]

I know. But again,
I asked this:

all those functions I saw here de only filter over a window of 3 frames. (radius = 1)
For a temporal filter this is definitly not enough!
only when I call them twice:
lremovedustmc().lremovedustmc()
i get a nice denoised result.
but this probably has not been in the intention of the inventor.

for temporal filtering a radius of two or three would be very nice

and

It would be great, if one of those denoisers here could fight with noise amounts like manaos filter:
http://forum.doom9.org/showthread.php?s=&threadid=89555

unfortunately it never processes moving edges

So is there any chance to get an answer related to this?

[Didée]

The answer most probably is "no". All work done by combinations of RemoveGrain/Repair and their derivatives is based and restricted to working on the values of a 3^3 cube.

For bigger radii, the simplest way is to interleave more compensated frames, and do temporal averaging over those. Just like MVDenoise does internally.
However, that way one can only do a "straight" linear denoise ... kinda like an arrow shot through the block of compensated frames. I could think of something that does smart temporal averaging over such compensated frames, what effectively would be similar to a second stage of motion compensation.

Imagine a panning frame. In the frame there is a clock with fastly moving hands. "Normal" motin compensation will be able (at best) to match the clock positions from frame to frame. But the position of the clock's hands still has moved from frame to frame, and cannot be compensated by ME (information is too small, spatially). That's the point where the smart temporal denoising would work its way through the stack of compensated frames, including the most probable pixel positions from on frame to the next.

[kassandro]

Originally posted by Didée
The answer most probably is "no". All work done by combinations of RemoveGrain/Repair and their derivatives is based and restricted to working on the values of a 3^3 cube.

you couldn't describe it better. It's all about the 3^3 cube and in most cases it is only the 3x3 square. I am not so pessimistic about using more than 3 frames, though. However, it should be put into the MVCompensate code. I just did an inspection of this code. It is very simple and only one frame + motion vectors is used, unless MVCompensate is applied with mode=2, which doesn't make much sense, however, because are artifacts propagate from one frame to the next and probably accumulate to some extent over time. Actually, inspecting MVCompensate showed me that, MCRemoveDust doesn't do, what I wnated it do, because mode=0, which means that the first clip is ignored, is the default and not mode=1. Thus my old RemoveDust script is indeed equivalent to

function MCRemoveDust(clip input, int _smooth, bool _grey)
{
repmode = 2
clmode = 4
quad = Quadruple(input) # each pixel is quadrupled, SSETools are needed
qpel = RemoveGrain(quad, mode=12, modeU=-1) # blur the luma for searching motion vectors
bvectors = MVAnalyse(qpel, blksize=16, lambda=200, isb=true)
fvectors = MVAnalyse(qpel, blksize=16, lambda=200, isb=false)
backward = MVCompensate(qpel, bvectors)
forward = MVCompensate(qpel, fvectors)
clensed = mcclense(quad, backward, forward, grey=_grey).shrinkby2(grey=_grey) #SSETools are needed for shrinking
rep=Repair(clensed, input, mode=repmode, modeU=_grey ? -1 : repmode)
rg = RemoveGrain(rep, mode=clmode, modeU=_grey ? -1 : clmode)
return TemporalRepair(rg, rep, grey=_grey, smooth=_smooth)
}

which should be somewhat softer than intended. Here is the corrected script:

function MCRemoveDust(clip input, int _smooth, bool _grey)
{
repmode = 2
clmode = 4
quad = Quadruple(input, grey=_grey) # each pixel is quadrupled, SSETools are needed
qpel = RemoveGrain(quad, mode=12, modeU=-1) # blur the luma for searching motion vectors
bvectors = MVAnalyse(qpel, blksize=16, lambda=200, isb=true)
fvectors = MVAnalyse(qpel, blksize=16, lambda=200, isb=false)
backward = MVCompensate(quad, bvectors, mode=1)
forward = MVCompensate(quad, fvectors, mode=1)
clensed = mcclense(quad, backward, forward, grey=_grey).shrinkby2(grey=_grey) #SSETools are needed for shrinking
rep=Repair(clensed, input, mode=repmode, modeU=_grey ? -1 : repmode)
rg = RemoveGrain(rep, mode=clmode, modeU=_grey ? -1 : clmode)
return TemporalRepair(rg, rep, grey=_grey, smooth=_smooth)
}

I made also another change to speed up b&w movies slightly. Thus I have to run benchmarks again. The more general mode=1 should really be default mode. Overall, the script should become slightly slower. Probably the additional softness due to my mistake is partially responsible for the better than expected compression performance. I now have to run some more tests again. Unfortunately the big test below was still been done with the old MCRemoveDust.

[kassandro]

This should have been my last benchmark, if there wouldn't have been the mistake in MCRemoveDust. Nevertheless, it's worthwhile to publish the results here. The source is about ten years old (it's from the series "Ein Bayer auf Rügen"), but it has been remastered about two years ago, because it was sold to another broadcaster. Obviously the film deterioated a lot during these 8 years. There are tons of grain but otherwise there is no bigger dirt. The video has 67367 frames. Here are the results:

unfiltered 464.303.331 Bytes
RemoveDust 275.641.562 Bytes
MCRemoveDust 267.164.004 Bytes
LRemoveDust(4,4) 318.499.154 Bytes

Why does LRemoveDust(4,4) perform so purely? The grain has simply too much contrast. With a limit of 4 the grain could only be removed partially. Here are the pictures.
The unfiltered frame:
http://home.pages.at/kassandro/testun.png

the RemoveDust frame:
http://home.pages.at/kassandro/testrd.png

and finally the LRemoveDust(4,4) frame
http://home.pages.at/kassandro/testlrd.png

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