New filter - DeGrainMedian for grain removal

[Boulder]

The filter could use AssumeFieldBased or similar internally. Avisynth defaults to BFF so that might be the cause.

[JuanC]

Thanks for your comment Boulder, more info: Avisynth correctly identifies the original video clip as Not FieldBased (Not Separated), TFF. After the filter is applied, Avisynth still believes the video clip is TFF, when in fact it's now BFF. Meanwhile, I am using this filter like this: limpiar=AssumeTFF().SeparateFields()
E=selectEven(limpiar).DeGrainMedian(interlaced=false,mode=2)
O= selectOdd(limpiar).DeGrainMedian(interlaced=false,mode=2)
Interleave(E,O) .Weave() Now I still get the video clip TFF after applying the filter.

[Turyst04]

JuanC
Meanwhile, I am using this filter like this: limpiar=AssumeTFF().SeparateFields()
E=selectEven(limpiar).DeGrainMedian(interlaced=false,mode=2)
O= selectOdd(limpiar).DeGrainMedian(interlaced=false,mode=2)
Interleave(E,O) .Weave() Now I still get the video clip TFF after applying the filter.
I now try use doom9 forum only (and my english is bad - sorry).
Anyway: JuanC, your avs is correct.
May be next script is suitable (if use more then 1 filters):

function ApplyInterlacedFilter(clip v1, string filter) {
v2 = separatefields(v1)
selecteven(v2)
even = Eval(filter)
selectodd(v2)
odd = Eval(filter)
interleave(even,odd)
return weave()
}

i=last
mdata=Depanestimate(i)
depaninterleave(i,data=mdata, prev=1, next=1, matchfields=true)
applyinterlacedfilter(last, "DeGrainMedian(interlaced=false,mode=2)")
applyinterlacedfilter(last, "fft3dfilter(sigma=3,bt=3)")
selectevery(3,1)

(depaninterleave using is recommended by Fizick and result is better)

[Fizick]

JuanC,
after SeparateFields interlaced clip become progressive.
So, you must use (interlaced=false).

But why do you not use the simplest script ?:

DGdecode_mpeg2source("Paulita-mpeg2-corta.d2v")
AssumeTFF()
DeGrainMedian(interlaced=true,mode=2)

Does this script reverse the fields dominance ? :confused:

[JuanC]

Originally posted by Fizick
Does this script reverse the fields dominance ? :confused: Yes it does.

[Fizick]

JuanC,
I found a bug for mode=2 YV12 interlaced,
and release new version 0.7 today.

Personally I prefer mode=0,1. and never used mode=2.

I can not reproduce the reverse of fields dominance.
What about other modes and colorspace YUY2?
How you detect it?

[JuanC]

Originally posted by Fizick
I found a bug for mode=2 YV12 interlaced,
and release new version 0.7 today. Thanks!, I'll try this.Originally posted by Fizick
I can not reproduce the reverse of fields dominance.
How you detect it? To detect it I use the technique described by D.Graft and included in the Decomb_Tutorial.html file in the Step 1 of Telecide Section: "Determine and Set the Field Order": Use this in your script: Return AssumeTFF().SeparateFields() And by playing it (Vdub) review if the movement is always fluid, then it is TFF, if the movement is back&forth... Then it is not TFF, you could then use AssumeBFF and verify the same way. Also, if you don't IVTC neither Deinterlace, you encode your video interlaced, you'll see using any player very strange artifacts (back&forth!!!)Originally posted by Fizick
What about other modes and colorspace YUY2? I haven't tried that yet. But I would next weekend.

[LordIntruder]

Hi,


Can someone enlighten me about the 'mode' option? I mean is mode=0 will clean less grain or not than mode=4 ? In the doc it is said:

"mode (0 to 4, default=1) - operation mode (the more, the weaker)"

The more (4 per exemple) the weaker. The weaker what? The image quality is cleaned more but also looks worse?

And a important thing: I have an interlaced PAL source. In my AVS I deinterlaced it with decomb. Must I integrate the option 'interlaced'?

FieldDeinterlace()
DeGrainMedian(interlaced=true, mode=0)

??

I think not because before I deinterlace my source so I guess this option is not needed but an advice won't be too much. ;)

Thanks. :)

[Fizick]

LordIntruder,
1. The more mode number, the weaker the degree of denoising.
If someboby can say this in good English, please post.

2. Yes, use:
interlaced=false

3. Use your own eyes to test :rolleyes:

[LordIntruder]

Fizick: thanks.

I'll try mode=0 and mode=4 to see the differences. I asked because I've just tried your filter last night for the first time and was a bit lost with technical explanations. Now I have to modify parameters and see what changes in the video.

And thanks to confirm for 'interlaced' option. :)

[LordIntruder]

Ok so to confirm after some tests

mode=0 --> removes a lot of grain

mode=4 --> removes only a little grain

Even in mode=0, the more aggressive, details are still well preserved.

Thanks for your work on all those filters. :)

[Poutnik]

DegrainMedian and STMedianFilter relation - I am little confused:

AFA I understand, the main result difference is limiting - not disabling - change, if pixel is to be changed too much.

Both ones have limits/thresholds for Y and UV change - treated differently.
But STMF has spatial edge threshold and temporal scene change one.

Should I consider DGM as "more clever", having those detections
build in ?

Or maybe these are controlled indirectly by other approach
- by choosing mode number ( I understand mode differences ) ?

[Beave]

I just stumbled across this filter. I must say I'm really impressed by the results. I used mode=0 on very noisy HDTV source and it was almost as good in removing the grain as Pixiedust, but much faster.

Compressebility:
Original: 34% / 8:23
DeGrainMedian(mode=0):50% / 9:44
Pixiedust(): 53% / 16:44
Pixiedust(8): 56% / 16:58

Visually both the filters are very close I must say. DeGrainMedian leaves the pictiure very sharp and removes a good portion of the grain. Pixiedust produces wierd black or white lines in some parts of the image. I will definatly rather use DeGrainMedian in the future.

I still can't decide how to pair this filter. RemoveGrain(mode=2) is not bad, but removes more fine details. On the website it is mentioned that one should try to put a motion compensation filter after this one. Which filter of MVTools should I try here? Does DePan work better in combination?

[Chainmax]

First, try mode=5 instead of mode=2. According to Boulder, mode=5 removes almost as much noise as mode=2 whithout softening the picture that much.

I remember that some time ago, scharfis_brain recommended to use depaninterleave (from the DePan package) for improved results on heavy denoising. I bet you have to use the DepanInterleave commands before the denoising steps.

I would recommend you to try LRemoveDust_YV12(17,x) with x being the denoising strength (I suggest you start by "2"), then follow that with BlindPP(quant=0,cpu=0,cpu2="ooooxx") (from DGDecode) or a very slight denoiser.

[Beave]

I forgot to tell that the above tests had Removegrain(mode=2) in the end of the script.
Compressebility with Removegrain(mode=2):
Original: 34% / 8:23
DeGrainMedian(mode=0):50% / 9:44
Pixiedust(): 53% / 16:44
Pixiedust(8): 56% / 16:58

Compressebility without Removegrain(mode=2):
Original: 26% / 8:23
DeGrainMedian(mode=0):40% / 9:42
DeGrainMedian(mode=0) + RemoveGrain(mode=5):45% / 10:32

All the tests have cpu=4 in mpeg2source and I'm really ok with it, cause it seems only to remove blocks, but not softening the rest of the picture. Is there a reason why you would rather use BlindPP?
RemoveGrain(mode=5) is definatly much better then mode=2. There is almost no visual difference, but I gain 5% (well actually 11%). mode=2 improves the %age even more, but takes away those little light spots in the eyes, which makes the picture less appealing to me.
LRemoveDust(17,2) is even worse IMHO. The picture is even smoother and has less details left.
Doesn't mode=5 have a thin line problem? Or maybe I'm confusing it with some other mode.
I can't get DepanInterleave to work properly. I have not studied the entire docs, but the framerate seems to be different. I used:
mdata = DePanEstimate(r)
r=DePanInterleave(r, data=mdata)

[Beave]

I just made another testrun with an additional FFT3DFilter. This seems to be a very good combination. The picture still appeares to be sharp and the compressibililty enhances to 56%. It is a much better choice in my case then RemoveGrain(mode=2). It is sharper and still improves from 50% to 56%. Another RemoveGrain(mode=5) after this one and I even get 59% without seeing any difference. Not bad at all compared to the original 26%.

Is there an avisynth function where I can put one frame from movie1 and then the same frame from movie two after another? Like 11223344 ...
It might be easier to spot the differences when the same frame can be switched instead of putting them beside each other to compare. Or is there an even better method to compare different filter settings?

[krieger2005]

interleave

[Fizick]

When i have not a time, i often use for analog TV capture two degrainmedian (fast) script similar to:

AVISource("H:\capture\n-c6.avi")
degrainmedian(limity=2,limituv=4,interlaced=true)
degrainmedian(limity=2,limituv=4,interlaced=true)

[leonid_makarovsky]

I am now playing with DeGrainMedian to remove grain from LaserDisc. It does an amazing job. However, LDs are not only grainy, they are a bit noisy like VHS but to a less degree. I remove grain, but the noise is still left. I was thinking applying PixieDust to remove the analog noise. The question is, should I use PixieDust before DeGrainMedian or after? Thanks.

--Leonid

[leonid_makarovsky]

I chose the optimal parameters for LaserDisc grain removal:

DeGrainMedian(limitY = 5, limitUV = 10, mode = 0, interlaced = true)

However, I am using this in combination with other filters that work only in progressive mode. So I'd like to change it to:

SeparateFields()
DeGrainMedian(limitY = ???, limitUV = ??, mode = ???, interlaced = false)
Weave()

I have a hard time choosing equivalent arguments that give the same effect as interlaced version. Nothing seem to work. Can anyone give me a clue which arguments would give the same effect for the SeparateFields/Weave as this one:
DeGrainMedian(limitY = 5, limitUV = 10, mode = 0, interlaced = true)

Thanks.

--Leonid

[Fizick]

http://www.avisynth.org/InterlacedSmoothing

[foxyshadis]

I just made another testrun with an additional FFT3DFilter. This seems to be a very good combination. The picture still appeares to be sharp and the compressibililty enhances to 56%. It is a much better choice in my case then RemoveGrain(mode=2). It is sharper and still improves from 50% to 56%. Another RemoveGrain(mode=5) after this one and I even get 59% without seeing any difference. Not bad at all compared to the original 26%.
Although removegrain mode 5 is much safer, if you're going to compare to temporal smoothers you really should be comparing to removetemporalgrain. (It's in the docs, for reference it's this: )

function RemoveTemporalGrain(clip input, int _mode) {
rg = RemoveGrain(input, mode=_mode)
return TemporalRepair(rg, input)
}

I've found it to be much safer at higher smoothing levels than removegrain, while still being effective. I generally use mode 2 or 3 with it, as 4/17 tends to cause the minor dulling you noticed earlier. It's also nearly as fast as removegrain alone.

That said, I'm going to run my own tests with degrainmedian, fft3d, and a few others when I start my next round of work next week sometime.

[Fizick]

Version 0.8 October 9, 2005 - changed frame cache range to 3;
- added option norow to disable using same row (horizontal) spatial pair;
- fixed documentation error about mode=1;
- renamed old mode 4 to 5, 3 to 4, 2 to 3, added new mode 2.

[KillNoise]

Is DeGrainMedian() operating in recursive manner ?
i.e. with

c = current input frame
p = previous input frame
f = forthcoming input frame
o = current output frame
l = last (previous) output frame (for sequential access; otherwise l = o)

is it
o = function(p,c,f) # non-recursive
or
o = function(l,c,f) # recursive (sequential access provided; otherwise use non-recursive p)
?
(Using l gives some better estimation than p, because l has been already cleaned before.)

PS: Any recommendations when to use new DeGrainMedian() parameter "norow" ?

[Fizick]

1. non-recursive, as almost all Avisynth filters
2. use norow, when you have thin horizontal noise lines and you have not horizontal wires :)

[KillNoise]

non-recursive, as almost all Avisynth filters

I have been discussing this recently with Kassandro concerning his Clense(): He has changed it to recursive operation on sequential access for better
temporal smoothing (introducing a bool option parameter to switch back to former non-recursive method). We also discussed making the chain "Clense(source).Repair(source, mode=16)" into a monolytic compound function to use the last repaired frame as recursive input for the clense-operation. (This lead to a general recursion scheme implemented in Kassandros new AssignRecursionClip() & Recusrsion.dll)

I think recursive operation will be benefit for DeGrainMedian() as well. Do you think it will be much effort to give it a try ? (Might perhaps use negative mode numbers to activate recursion.)

[Fizick]

Sorry for silence,
but i am still not sure, that recursion will be better for this median algo.

[Poutnik]

Two questionable ideas:

Would it make sense to give ( in general ) different weights to temporal and spatial pairs ?

One can see 3x3x3 cube as a cube in real 3D space. More precisly 2D x time.
Object presence in 2D frame is like 2D slice/cut of mystery 3D object.

The question is, if these dimensions are comparable in scale.

Almost everyone would consider spatial neighbors as similar/related with high probability. But in time scale it is not such case, even without scene change.
Looks for me like a temporal unit is significantly larger than spatial one so 3x3x3 is more a block than a cube.
Spatial scale units (pixel size) are quite fine small, but temporal space units
are quite large, so at one time the object is there, in next time unit it is not there. Ghosting of temporal smoothers can be related to that.
If there is 1000 fps temporal smoothers would have life much easier.

From that was born an idea to give pure spatial pairs other weights then to temporal-spatial pairs.

another question what about adaptive weights.... But it could slow down this
pretty, simple and fast filter.

-------------------

Would it make sense to implement in 3D any other methods from RemoveGrain ?

[livetoride2112]

Hey,
Thanks to everyone for your input on my thread.

[KillNoise]

I don't know how to prove recursive operation advantages without practical testing an implementation, but there is some evidence: Median operation is not good in damping of flickering oszillations. Easy to see for Clense() operation, which performs temporal min-max-clipping pixel values of input[t,x,y] within interval
min(input[t-1,x,y], input[t+1,x,y]) to max(input[t-1,x,y], input[t+1,x,y])
Recursive operation would use interval
min(output[t-1,x,y], input[t+1,x,y]) to max(output[t-1,x,y], input[t+1,x,y])
Example for temporal sequence at some single pixel:

Input(t): 5,4,6,5,6,4,6,5,4,6,4,6,4,5,... # oscillating noise over constant value 5
Clensed(t) non-recursive: 5,5,5,6,5,6,5,5,5,4,6,4,5,x,... # non-recursive pass through some oscillations
Clensed(t) recursive: 5,5,5,5,5,5,5,5,5,5,5,5,5,x,... # better smoothing with recursive Clense

Other examples may be constructed, but i'm sure you will not find any for which recursive operation will perform inferior. Note that this applies not only for small noise amplitudes: Even very high oscillation amplitudes may pass through. Effect is worst for "resonant" flickering frequency of half frame rate - likely after deinterlace.
I think recursive operation is superior because it makes use of the available signal/noise enhancement performed on previous frame. Further, using the previous output as reference helps to reduce temporal flutuations, thus improving compression.

Considering DeGrainMedian() is little more complicated, but i think recursion can help in both of two stages:

In first stage DeGrainMedian() tries to find the spatial/temporal texture-direction by selecting the axis of minimal change among the 13 line-pairs. Replacing the previous input frame by the previously degrained output provides the best estimate of previous image available at this point, making the direction decision more reliable.


Second stage applies the median filter along the determined texture-direction axis. If this is one of the 9 temporal directions (most likely for all static areas), then recursion will enhance denoising as shown for Clense().


Besides, i like the slight motion compensation capability of DeGrainMedian() which might reduce small image jitter, sometimes caused by bad film transport mechanics, as well as possibly from fidgety motion compensation disturbed by noise. This jitter stabilizing feature will surely improve with using previous output frame as reference.

I expect DeGrainMedian() recursive operation will be nearly as effective as double-cascading DeGrainMedian(), but faster and with lower artefacts risk (e.g. not degrading spot-details by limit-value twice).

What do you think ? Isn't it worth trying an option for DeGrainMedian() recursive operation ?
Then you can experimentally evaluate performance comparison between simple, recursive and double-cascaded DeGrainMedian().

[KillNoise]

Using DeGrainMedian() "norow" option

I think "norow" adresses two important issues with analog video signal transmission:
Primary application is removing line offset error caused by faulty black level clamping, which sometimes occurs with analog video signal, mostly for video tape recordings.


Further, denoising (generally based on stochastic estimation techniques) mostly assumes noise to be uncorrelated for each pixel indepently, which is correct only with one exception: if analog video signal transmission was involved somewhere in signal chain, it introduces some lowpass filtering which correlates noise for horizontal neighbour pixels, so that it is likely mistaken as horizontal line segment detail to be preserved.
For this reason i like using initial filtering with RemoveGrain(2), whose "line end eating" property is able to reduce horizontaly correlated noise considerably (though it works equally in every other direction too). DeGrainMedian(norow=true) might be a more specific alternative.

[KillNoise]

Using DeGrainMedian() for extremely grained movies

When looking carefully at heavily grained movies, i often see extreme fluctuation amplitudes, exceeding image details level by far. I think only the human eyes temporal low pass filtering capeability makes such image appear acceptable. Of course these fluctuations are disastrous for compression efficency.
Effectively suppressing those high fluctuation amplitudes requires DeGrainMedian() to be used with equivalent high change limit values, thus increasinging artefacts risk as well. I think there is a fundamental difference regarding any filters performance depending on whether noise exceeds image details level or is only a small, harmless amplitude (the former renders most threshold based concepts useless !).
I wonder how much recursive operation can improve performance in case of such excessive fluctuations ...

Using DeGrainMedian(limitY=255, limitUV=255, mode=4) - recursive or not - might be another alternative: DeGrainMedian mode 4, similar to RemoveGrain mode 6, should preserve line end points as well as small spots, so i think can be well used without any change limits. Because of including temporal filtering, it should be more effective than RemoveGrain(mode=6). Might it also do more harm then ? Any suggestions ?

Though quite simple in concept, DeGrainMedian() seems to be a most powerfull filter. (Suppose it implements a simple form of signal-adaptive filtering.)
"Fascinating !", as Mr. Spook would say.
I wonder whether this concept can be further enhanced by more sophisticated texture detection in first stage or an improved filter-algo in second stage ? Perhaps by iteratively reusing direction information or filtered results from spatial neighbours (similar idea as with temporal recursion for previous frame). It would be easy at least for the 4 spatial neigbours which have already just been processed (though i don't realy like this kind of anisotropic recursion).

[Fizick]

Poutnik,
IMHO, if we give small weight to temporal pair, the filter will be too weak to grain, like RemoveGrain ;)

But you may try modify the code and experiment what you want.
The code is opensource.
There are many ways to add and subtract even 3 pixels :)
But you must understand, what do you want to do. :)

I think, for true denoising improving, we must use more pixels, and probably compare not single pixels , but small spatial blocks (2x2 ?).
It seems, Tom Barry used similar aporoach in his great TomsMoComp plugin.
But it will be not DGM filter.

The larger block is fine too, but we then re-invent Dust and MVtools. :)

[Poutnik]

Spasibo za otvet, Sasa. (Thank you for the answer).

I may try to modify a filter, but it would not Avisynth filter anymore. :p I am just going to learn VC++. I did not programming for many many years. I know well Z80, much more then SSE :(

Not brave enough to try xxxxDust on my Celeron600(SSE). :p
XXXXTools are still blackbox for me.

I had to ask even I could imagine You asked this question yourself before.
Thank you for all your effort developing those nice filters, in spite of that my CPU some of them does not like ( is lazy ) :p

[KillNoise]

Different handling for temporal and spatial pairs

Would it make sense to give (in general) different weights to temporal and spatial pairs ? ...
The question is, if these dimensions are comparable in scale. Almost everyone would consider spatial neighbors as similar/related with high probability. But in time scale it is not such case, even without scene change. Looks for me like a temporal unit is significantly larger than spatial one so 3x3x3 is more a block than a cube. Spatial scale units (pixel size) are quite fine small, but temporal space units are quite large, so at one time the object is there, in next time unit it is not there. ...
From that was born an idea to give pure spatial pairs other weights then to temporal-spatial pairs.

Very, very true note, Poutnik !

The question is: Does temporal filtering make sense at all for motion areas ?
Generally: No! - There is no useful correlated information in temporal axis, so any temporal filtering can do nothing but harm (except with motion compensation establishing temporal correlation). An exception is for uniform colored moving areas overlapping from frame to frame, but for these we should not recognize motion.
==> For DeGrainMedian: if motion > 1 pixel would be detected, none of the temporal pairs should be regarded at all.

In my oppinion the ideal ST-filtering scheme (without using motion compensation) should be:

1) moderate spatial filter (YUV; nonlinear to remove large grain and noise peaks, e.g. RemoveGrain mode 2)
# can be applied overall, will make motion detection and subsequent filtering more reliable

2) determine binary motion mask by frame-to-frame change analysis
# preferably using a low pass filtered clip version to supress jitter & HF noise disturbance
# change analysis preferably based on small clusters rather than single pixels (e.g. 2x2 or 4x4 blocks)
# the motion mask might be reduced to 2x2 or 4x4 "macropixel"-resolution for processing performance

3a) apply temporal filter for static areas (YUV)
# with breaking temporal filter extent on frames indicating motion (recursive method prefered)

3b) apply stronger spatial filter for motion areas (YUV)
# spending less bits on encoding where the eye is less sensitive for deterioration

4) downsize target resolution with appropriate lowpass for anti-aliasing (e.g. RemoveGrain mode 12)
# making an adequate tradeoff for spatial resolution versus signal/noise dynamic resolution

5) aplly structure adaptive (signal-adaptive) spatial filter (YUV) (e.g. RemoveGrain mode 6)
# "intelligent" spatial filter can use denoised input to further enhance image structures
# (spatio-temporal DeGrainMedian(mode=4) could be used as well)

6) optionally use some change limited sharpening on luma to compensate loss of "crispness"

I'm not sure whether step 5 and 6 should be reversed. However, step 6 might also be done after decoding.
On the other hand, my experience: Encoding with limited sharpness "preemphasis" and stronger quantizer at same bitrate often yields nicer, more detailed result (sufficient denoising provided; only for "naturally" textured image, not for cartoon-anime)

Well, the power of simplicity with DeGrainMedian is its implicit (though far from perfect) ability to automaticly switch from temporal to spatial filtering on motion areas, so that it incorporates steps 2 and 3 in one. This is simmilar to Kasandros approach of using Clense with Repair-Bypass, which could also be implemented as monolithic compound function to operate on 3x3x3 cube like DeGrainMedian (one example of ST-anisotropic handling asked for).

I see most artefact risk for any small objects transient passing constant background during one frame: Temporal 2-frame step difference would be near zero for this case, so DeGrainMedian mode 0 is likley to erase the object (only change limits would help, but these also obstruct grain filter performance as i stated earlier here). At least there is high risk for compression-hampering unsteadiness caused by wavering between temporal and spatial axis, thus switching between object and backgroung colour.
My consequence: If mode 0 is used, spatial directions need some higher priority than temporal ones.
Suggest modification to select only among the 9 temporal axes with using DeGrainMedian mode 0 first, then correct the resulting center pixel by spatial filtering rules like Kassandros Repair mode 9 or 16. This is quite similar to Clense-Repair pattern, except for the Clense-operation based on a divergent bundle of 9 axes rather than only one central. Recursion would then comprise the entire operation rather than clense alone, reusing an even more reliable output for previous of next frame.

Further improvement specially with recursive operation: Instead of using 9 temporal axis with central pixel of current frame as pivot, we could use 9 axes with their pivot on center pixel of last frame, i.e. simply find the one pixel among the 3x3 in forthcomming frame whose value is next to last center pixel (probably even faster). Then use this pair for clipping (again with subsequent spatial Repair within current frame).
Why better ? If we consider the last filtered output frame as most reliable reference available, it is only consequent to make it the pivot for DeGrainMedian "motion compensation" for best jitter suppression on output.

I wonder, whether someone could find a set of rules to make up stochastic optimal ST-filtering decisions based on a 3x3x3 cube (not bothering about effort and speed performance for a first theoretical evaluation) ?

[KillNoise]

DeGrainMedian Based on Motion Detection

Here is another idea: The 3x3 cluster can be used for motion detection by frame-to-frame change analysis, enabling explicit decision whether to use temporal or spatial filtering. Might work as follows:

Calculate 2x2 averages (or simply sums) for each of the four quadrants at the corners within 3x3 block (partially overlapping):

Q0 = (c + n0 + n1 + n2)
Q1 = (c + n2 + n3 + n4)
Q2 = (c + n4 + n5 + n6)
Q3 = (c + n6 + n7 + n0)
for 3x3 array
[n7] [n0] [n1]
[n6] [c] [n2]
[n5] [n4] [n3]

This is convenient for data reduction and supressing noise & jitter by low-pass filter.

Motion detection compares these 4 quadrant averages from current frame with those of last frame, assuming motion if more than one of the four difference values exceeds a threshold parameter.

Depending on this motion decision apply prefered pure temporal or pure spatial filtering (e.g. RemoveGrain mode 22 for moderate or mode 17 for strong filtering might be a good choice)


An even more efficent modification might be using a 4x4 luma pixels block instead, with the four 2x2 cluster averages not overlapping and then use the motion decission commonly for each of the 2x2 core pixels as well as for the U and V chroma pixel in YU12 simultaneously. This performs faster motion detection on half resolution grid only and we could also apply very efficient temporal filtering methods for the 2x2 luma cluster.

Well, this might go beyond scope of DeGrainMedian, but maybe some talented programmer would like to adopt and implement this idea. If there is interest, i could tell some more about efficent temporal filtering on clusters. (Maybe continue this on a new thread)

[Fizick]

KillNoise,
Thank you very much for your suggestions!
I read it , but i am busy with other project now.

The one comment first:
You wrote:
For DeGrainMedian: if motion > 1 pixel would be detected, none of the temporal pairs should be regarded at all.
IMHO, it is not true:
1. Often we have large areas with similar colors.Even if this object moves, we can yse strong temporal filter.
2. There are no good way to reliably detect motion and distinguish it from big grain.
(you wrote it above).
3. Using different filters and its strength on different regions give anoying transient regions (edges).

So, DegrainMedian is still the best now :)
Will waiting some talanted programmer. :)

[Fizick]

Three more comments:
4. Threre are many good denoisers, but threre are no good de-grainers.
DeGrainMedian is best (IMHO :) ) but it is not good.
5. Instead of explicit clustering, we can use multilevel processing.
6. Some time ago i also waited when somebody will wrote filter with advanced algo.
Killnoise, take C complirer, and become the talanted prorgammer !

[KillNoise]

Thank you very much for your suggestions!
I read it , but i am busy with other project now.

Well I know; noone having no time no more seems to be THE affliction of our time ...
Me, i took until now even to watch your replies.

Can you imagine yet to find opportunity to provide an enhanced version at least with recursive option ?
Suppose this might not be very great effort for you, knowing all the code structure and caveats
(realy no chance of doing it myself - i am so far from talented in coding)
I'm sure, not only me would appreceate you very much for doing so, making this best filter even better.


1. Often we have large areas with similar colors. Even if this object moves, we can use strong temporal filter.

Absolutely true. When talking of simple Motion Detection, i assume uniform areas should adequately not be detected as moving (may be different for using Motion Compensation)


2. There are no good way to reliably detect motion and distinguish it from big grain.
...
4. Threre are many good denoisers, but threre are no good de-grainers.

Seems like a logical consequence, maybe a fundamental law: Rather easy to get rid of uncorrelated white noise; however, grain is spatially correlated noise, ranging into the frequency scale of image details to be preserved. So only temporal filtering can help to separate grain from image detail. Using motion compensation would clearly be the way to do it perfectly. (For encoding efficiency, it would be consequent to fight grain within the encoders motion estimation & residual encoding process, rather than aiming exact reproduction of bad input !)
However, even without motion compensation efforts we should already be able to "squeeze" away most part of the bits commonly wasted on noise and grain, leaving some residual noise for the benefit of dithering effects.

Concerning motion detection/compensation beeing fooled by grain & noise, i think its allways a good idea to provide a separate, heavily filtered parallel stream/clip to be used merely for motion analysis. In case of DeGrainMedian() you might use this to determine selection of the axis direction to be used for filtering the pixels from original clip then.


5. Instead of explicit clustering, we can use multilevel processing.

Not sure i got you right: Do you mean multi-scale decomposition ? How would you apply it here ?


DeGrainMedian is best (IMHO) but it is not good.

It IS good, because it is one of the best we have today.
Good reason however to develop it further to make it even better, if you can.
Recursion seems to be a most promising approach. Looking forward to see it playing soon ...

[Fizick]

mulilevel approach I tried implement in degrainpiramid script somewhere here.

other comments later.

[Poutnik]

There is Didée's comment and modification of DegrainPiramid
at Kassandros forum...
He suggested to replace pointresize by bicubicresize.

http://videoprocessing.11.forumer.com/viewtopic.php?t=44&postdays=0&postorder=asc&highlight=degrainpiramid&start=30

[Axed]

I think i have a problem here. I was playing with degrainmedian because everyone said it was quite fast, my problem is that its sooo slow. I get 0.3 - 0.5 speeds in CCE on my P4 2.4 with only dgdecode and degrainmedian in the filter chain. I tried degrainmedian() with a movie that is progressive.

All my other filters (in other avs files) seem to be fast and working properly, but if you need more information please say so.

[Fizick]

:script:
system config? Avisynth version? DegrainMedian version?
It is trivial questions. We are not telepathic.

[Axed]

Sorry, never had to report a problem before.

Avisynth 2.5.6, newest degrainmedian. P4 2.4, 768 meg ram running Windows XP SP2.

loadplugin("c:\stuff\dgindex\dgdecode.dll")
loadplugin("c:\stuff\filters\degrainmedian.dll")

mpeg2source("rush hour.d2v")
degrainmedian()


Nothing special there as you can see, and i know every single other filter is running at full speed?

Just remembered something too, when i ran degrainmedian on a shorter clip (i believe it was 10,000 frames) it ran at above realtime speeds using the same style script.

[Fizick]

Strange.
1.What is "newest" degrainmedian version?
2. you do not use convertto...?

[Axed]

I use 0.8, i knew it was the newest because i only downloaded it a week ago and i keep an eye on your homepage.

The reason i didnt have converttoyuy2() in that script is that i was testing the script in xvid to doublecheck it wasnt a CCE fault.

Im a newbie at programming, but is there any special libraries that degrainmedian uses? Its entirely possible one of them on my computer could be corrupted or something.

Also i ment to say, i have no plugins in my "avisynth 2.5\plugins" directory barring the default avisynth ones.

[Boulder]

Try

loadplugin("c:\stuff\dgindex\dgdecode.dll")
loadplugin("c:\stuff\filters\degrainmedian.dll")

mpeg2source("rush hour.d2v")
Crop(0,0,-0,-0,true)
degrainmedian()

[KillNoise]

other comments later.

Well ... ?
How do you think about you can make a recursive DeGrainMedian ?

BTW:
Thinking thoroughly about it , i can't understand the idea behind using 9 temporal axis rather than simply one straight:
You mentioned "motion compensation", but this can not happen but for veeery slooow < 2 px/frame; but see practically almost every movements much faster than that (i.e. temporally discontinous).
There may be small jittering fluctuatuions (e.g. irregularities from film-scanner transport mechanism or from TV horizontal line sync) which might lead to some blurr (at least on "stupid" temporal filtering). However, these seem mostly fast jittering or oszillating forth an back, so they misfit the 3-frame linear motion model assumed by DeGrainMedian, rendering it useless.
So i ask you, how to justify computational effort for extra 8 temporal diagonal axis (beyond only 1 straight temporal + 4 spatial) ?

[Axed]

Try
<snip>

Didnt help.

[Fizick]

KillNoise,
1. "Later": is still not occures. Sorry. :(
I am still do not want implement recursion (not generally, but in DegrainMedian specifically - it would not be median).
2. By the way, some time ago I considered to add more temporal pairs. :)
(for 2 pixel compensation).
But I am still do not want broke my filter.
It will be better to design a new, for example "KillNoise" :)
Who will wrote it? ;)
But my thougths are about MVDeGrain.