exist any filter specially done for (deinterlace) flicker

[Mystery Keeper]

Oh my. It connects lines so neatly! I'm not very good at avisynth, so I don't really understand what's happening in the script. For me you guys are wizards ^_^

[WorBry]

My friend, you dont really need to understand whats happening in the script, its a complete function to be used as such and Magician Didee is the sole author.

[Mystery Keeper]

I know. I'm already successfully using it ^_^
By the way, I usually process MPEG2 musical videos and I'm used to low speed. right now I'm encoding one at 0,5 fps ^_^' So don't you guys complain. Quality certainly worth it.

As for anti-aliasing, my choice is still EEDI2().TurnRight().EEDI2().TurnLeft() after cropping and before resizing. As it almost destroys no details, the result is much smoother than the same method with nnedi.

[Mystery Keeper]

Had it screw up large detailed and static frame in anime, over which a strongly interlaced spot was applied. MCBob handled that frame gracefully. Can not give snapshots now, but shall later.

[WorBry]

Originally Posted by Mystery Keeper

As for anti-aliasing, my choice is still EEDI2().TurnRight().EEDI2().TurnLeft() after cropping and before resizing. As it almost destroys no details, the result is much smoother than the same method with nnedi.

Tried that, and the NNEDI version, but it doesnt deal very effectively with the type of aliasing (notably 'quilting' or 'moire effect') that I encounter with my pseudo-progressive material.

[Didée]

Beta 1.

(Fixing update: BinomialBlur() leaks memory, replaced it with some equivalent filtering.)

[WorBry]

Wow, and just when I thought I'd got my head around the scripting of TempGaussMC_alpha3.

Ran a few tests and needless to say the results are incredible.

Glad you put in EEDI2maxd as an adjustable parameter, as I find the occasional hole in my 'stripey shirt' tests at default maxd=8; adjusting to maxd=6 seems to resolve that.

I see the default sharpness been increased a little i.e from 0.25+(tr1+tr2)/8. to 0.25+(tr1+tr2)/6. which (at default Tr1=2, Tr2=1) represents an increase from 0.625 to 0.75. I know the sharpness can be adjusted to personal taste, but just wondered if there is an empirical reason for the change i.e. more blur that needs to be countered?

[2Bdecided]

It's sharper and faster, but I'm getting slight combing-like artefacts. There are parts that were blurred in the original (either out of focus, or moving) which alpha3 kept blurred. The Beta versions adds little lines or steps within the blur.

Would it help to upload something to show this?

Cheers,
David.

[Didée]

@2Bdecided:
Yes, please. It's probably the "SVthin" thingy (try to set that to 0.0), but checking is better than guessing.
The faster performance is because the blocksize/overlap defaults now are 16/8, before they were 8/4.


@ WorBry:
The default is sharpness=0.75 for the spatial SLmode=1|3, or sharpness=1.5 for the temporal SLmode=2|4.

In theory (i.e. on a "perfect" syntetic showcase), it would need sharpness=4.0 (for Smode=1) or sharpness=2.0 (for Smode=2), in order to completely restore the blur-down of the temporal gauss. So the sharpness defaults are still on the conservative side of things.

[2Bdecided]

SVthin=0.0 dramatically improves it. It's still a little worse than before, but subtle.

See the finger nails on the boy's left hand (i.e. the hand on the red bar)...
http://rapidshare.com/files/12630064...tgmcb.m2v.html

Cheers,
David.

[Didée]

Seems like it's one of the dangerous downsides of using the mc-compensated neighbors for limiting. The "flattening" of the search-clip makes the reckognition of bad compensations less reliable ... however the flattening is ultimately needed. Without it, MVDegrain would do almost nothing-at-all to the bobbing parts ...

I'll have a look at it. For the moment, here's some justification for why things are like they are in beta-1 :

( top: progressive reference | YadifMod(NNEDI) - bottom: TGMC alpha-3 | TGMC beta-1 )

Beta-1 is not only "sharper" ... it really recovers more true detail (detail that is 'not present' in a given field but only in its neighbors can not be recovered by the alpha versions, due to the spatial limiting), and it even is more stable than the previous alphas.


Edit:
With your sample, I can not (or hardly) confirm a problem with the new beta version as such. The artefacts e.g. on the fingernails are just a coincidence: they're worse with EEDI2 (beta's default, faster), and less prominent with NNEDI (alpha's default, slower). Also they're a bit worse with 16/8 (beta's default, faster), and less so with 8/4 (alpha's default, slower).
It seems in this case it's mostly a matter of the changed default settings.

Hmmh ... perhaps I should make make ALL parameters MANDATORY with NO DEFAULT settings, so everyone HAS TO choose his own poison ...

[2Bdecided]

That's a great comparison. It's very useful having the progressive source for testing - not something I have the luxury of with HDV (otherwise I wouldn't need TGMC!).

Thanks for taking a look at it Didée. I do like the extra sharpness of beta-1, though my HDV footage rarely has anything pixel sharp in it to start with (other than noise and encoding artefacts!).

Cheers,
David.

[Terranigma]

Originally Posted by Didée

perhaps I should make make ALL parameters MANDATORY with NO DEFAULT settings, so everyone HAS TO choose his own poison ...

Or change the defaults to the most optimal settings and let users be able to alter them for speed over quality.

[Didée]

There is no such thing as "most optimal settings".

Par ex.: "EdiMode".
Yadif is blazingly fast, sometimes it looks okay, sometimes it looks terrible. NNEDI is very slow, often looks good, but I could show you cases where even NNEDI's neural network *fails*, yet the cheapo-quicko Yadif looks brilliant(!) in comparison. EEDI2 is king & pope when it comes to connecting diagonals and thin lines, but it also mis-guesses quite often, and is prone to give the dreadful "oilpaint look" (same as Yadif, but even more so). Ditching e.d.i. completely and just using plain bicubic interpolation will - in many places - look as good as any other setting, but in some places it'll cause aliasing (depending on vertical motion, when neighbor fields happen to not contain the necessary information.)

And now you tell me, which is the "most optimal" setting for EdiMode?

Yeah, exactly. Same goes for all other parameters.

Current defaults should be in reasonable mid-range. And altering the settings for trading speed vs. quality is exactly what the user is supposed to do, anyway.

[murrsturr]

Thanks for this great filter Didee. I am presently using it, and it only, on sd digital TV captures with great results.

With all settings default, save for edimode, on a Q9300 with 4 gigs of ram with multi-threading enabled (I am using SetMTMode(2) prior to calling your function) I am getting the following FPS averages:

EED12=4.7+
NNEDI=5.8+
Yadif=8.7+

With the lighter settings WorBry suggested (thanks WorBry) a few posts back I am getting 12.5+ fps with Yadif. So on my setup "mid-range" default EED12 is actually slowest but I am more than happy with the results that Yadif is giving me thus far. I am looking forward messing around with this much more.

Thanks again!

[WorBry]

With my home DV sources, I’m also noticing some ‘edge serration’ and, I’d dare say, a little distortion/erosion in places where objects are moving over objects/ high contrast edges.

Here are two examples from the test clip that put-up in Post #30

http://rapidshare.com/files/12655174...lpha3.avi.html

Compared were (left to right):

TGMC-beta (Tr0=2, Tr1=2, Tr2=2, edimode=NNEDI)
TGMC-beta (Tr0=2, Tr1=2, Tr2=2, edimode=NNEDI, blocksize=8)
TGMC-beta (Tr0=2, Tr1=2, Tr2=2, edimode=NNEDI, SVThin=0)
TGMC-beta (Tr0=2, Tr1=2, Tr2=2, edimode=NNEDI, blocksize=8, SVThin=0)
TGMC-a3 (Tr0=2, Tr1=2, Tr2=2, edimode=NNEDI)

Note the finger as it passes over the railings (frames 8 – 24) and thumb and forefinger in frames 42 – 49.

With TGMC-beta, reducing the block-size from default 16 to 8 definitely helps a little. Not too sure if setting SVThin=0 makes much of a difference, if any, in this case. But of course, without a progressive reference source it is difficult to gauge what represents true detail (or lack of it) from the ‘original’ and so there’s no telling what the slightly more blurred result with TGMC-alpha3 actually masks.

So, I guess it boils down to what one considers the more subjectively appealing….at normal playback speed that is. Generally, from my tests so far I do prefer the overall crisper look of the beta.

[Mystery Keeper]

I suggest this thread renamed "TempGaussMC deinterlacer".

[Didée]

I rather suggest spanking Didée, until he gets off his duff and makes a dedicated thread for it ...

(Which is what I'll probably make ... when I've a little more free air again.)

[WorBry]

Originally Posted by WorBry

With my home DV sources, I’m also noticing some ‘edge serration’ and, I’d dare say, a little distortion/erosion in places where objects are moving over objects/ high contrast edges.

Here’s another example (from the test clip I put-up in Post #30).

This time I ran a parallel series with edimode=EEDI2.

http://rapidshare.com/files/12693557...test2.avi.html

The series shows quite marked ‘combing’ on the boy’s hand with TGMC_beta and to a much lesser degree with TGMC-alpha3. Reducing Blocksize= 8 and SVThin=0 together brought a little improvement but not complete resolution. Although not shown in this series, reducing the EEDI2maxd value had no effect.

With edimode=NNEDI, the effect was rather more subtle, but distinct combing is still visible in parts (see Frame 5)

http://rapidshare.com/files/12693602...test2.avi.html

I think anyone looking at the ‘EEDI2’ series in particular would, at face value, assume this to represent residual interlace combing and if it is definitely not, then what is it – interpolation error that slips through the net, aliasing?

More to the point, what other tweaks available in the beta might be applied to avoid it ?

Thanks.

Edit: Seems to be arising somewhere in Stage 1a, as the Stage 1 output looks OK.

[Didée]

The basic problem is that motion compensation can't be successful in such spots. Those twiddling finglers of the little man are too different from one frame to the next, so MC can't do much useful there. At best, MC should do *nothing* in such areas ... but that's one example of where it is highly difficult to separate "the good" from "the bad" ...

1st, lowering blocksize/overlap does help, like you already found. Smaller blocksize can adapt better to such chaotic motion.

2nd, the "rep" reparations play a big role. Those deal for accepting only bob-typical vertical differences from the temporal filters (a bob-typical difference is "thin" in vertical direction). However in the areas you showed, the artefacts from motion compensation do form differences with quite similar characteristics as bob-typical differences do have, that's a problem.
You can try using lower repX values to reduce those artefacts. repX=1 is most aggressive in avoiding artefacts, repX=5 is most relaxed. But OTOH, too aggressive repX values may introduce bob flicker in the output again. It's a trade-off that's also content related. Some average footage may get away with more aggressive repX values; extremely detailed footage like the "Stockholm" panning scene is a nightmare that requires very relaxed reparation.

3rd, SLmode is also related. The old mode (SLmode=1 or 3, spatial) is more safe to avoid motion-related artefacts, but in some places it can inhibit full detail recovery, or even can result in slight flicker re-introduced into the output.
The new mode (SLmode=2 or4, temporal) theoretically are the true thing, since they allow for full detail recovery and maximum stableness in static or low-motion areas. But, in areas where motion compensation wasn't successful, the temporal mode allows that the sharpening expands into wrong pixel values. It's a trade-off.


In the end, there's no holy grail in sight, and trade-offs have to be made. For general denoising and/or motion compensating, the consens is to accept only differences that are "small enough", since using big differences usually introduces artefacts.
However, in the case of "denoising" bob flicker, it is a MUST to accept big local differences, and it's this very fact why TempGaussMC looks as good as it (mostly) does.
In light of the fact that TempGaussMC does exactly that what most other filters are too anxious to do, I'd say that the potential artefacts are rather little.

Besides, I'm not sure if I would note the artefacts of your example when viewing in realtime. Flicker in almost-static areas is so much more obvious than a few stray pixels that are located in funky-motion areas.


For orientation, here's a table with Beta1 defaults, alpha3 defaults, and the corresponding values to make beta1 behave (mostly) like alpha3:

          |Default |beta1=> |Default |
Parameter |beta-1  | alpha3 |alpha3  |
----------+--------+--------+--------|
tr0       |   2    |   2    |   2    |
tr1       |   2    |   2    |   2    |
tr2       |   1    |   1    |   1    |
EdiMode   | EEDI2  | NNEDI  | NNEDI  |
rep0      |   4    |   1    | true   |
rep1      |   0    |   0    | [true] | <-  alpha's "rep1"
rep2      |   4    |   1    | [---]  | <-  is beta's "rep2"
blocksize |  16    |   8    |   8    |
overlap   |   8    |   4    |   4    |
Smode     |   2    |   1    |  (1)   |
SLmode    |   2    |   1    |  (1)   |
SLrad     |   1    |   2    |  (2)   |
SVthin    |  1.0   |  0.0   |  ---   |
Sbb       |   1    |   0    |  ---   |
thSAD1    |  600   |  800   | (800)  | 
thSAD2    |  300   |  400   | (400)  | (MVTools' standard default)
SCth1     |  180   |  400   | (400)  | (dto.)
SCth2     |   98   |  130   | (130)  | (dto.)