exist any filter specially done for (deinterlace) flicker

[Didée]

You're turning the wrong knob. Lowering thSAD in MVDegrain is not the preferred solution ... you could lower it to,say, '100' - hooray, no more artefacts!! -- but oh dear, why there's all this bob flickering again?

The culprit is "thSCD1", which defaults to 400, which is way to high for the prepared searchclip ... that one is "flattened" on purpose, and reasonable scenechange values for such a clip are e.g. "thSCD1=175,thSCD2=100". <--Put these into all MVDegrain calls if you can't wait for me posting the beta.

[LaTo]

Originally Posted by Didée

You're turning the wrong knob. Lowering thSAD in MVDegrain is not the preferred solution ... you could lower it to,say, '100' - hooray, no more artefacts!! -- but oh dear, why there's all this bob flickering again?

The culprit is "thSCD1", which defaults to 400, which is way to high for the prepared searchclip ... that one is "flattened" on purpose, and reasonable scenechange values for such a clip are e.g. "thSCD1=175,thSCD2=100". <--Put these into all MVDegrain calls if you can't wait for me posting the beta.

Previous post updated!

The problem go away with SCD1=100... If >100 the lines is present.

[Didée]

Originally Posted by LaTo

The problem go away with SCD1=100... If >100 the lines is present.

That's bad news. Just figured that on detailed material (CrowdRun), thSCD1=180 (for blocksize=8) resp. thSCD1=240 (for blocksize=16) are good values. If you need a value of 100 for your footage, that means that there's probably no smart handling of that issue in sight. (With '100' there is big danger that some frames won't get filtered at all ... try on 'ParkRun', you'll see....)

Darn SAD. Darn fixed-dumb-thresholded-solutions. The good solutions are those that work without any thresholds. Solutions that essentially rely on thresholds are not solutions, just case-dependent fiddlework ... like almost any filter available for Avisynth.

[WorBry]

Cmon guys, we've had the appeteasers, now let Chef Didee serve up the main course and then you can pick at the food if you like - my stomach's rumbling

[yup]

LaTo & Didée!

May be need try search=3 in MVTools. I am last time try write script for remove pulse noise and found that search=3 give more better result than search=2. Also I try decrease thSAD with search=2 but without result. I agree search=3 decrease speed, but give better quality MV.

yup.

[Didée]

Yeah, exhaustive search, sure. Exhaustive is always the last ressort when everything else fails. Next step beyond exhaustive is: kick all filters to dustbin, and arrange the fields' scanlines manually with PhotoShop. Blargh.
With "light" settings, TempGaussMC can run in range of "half realtime", perhaps full on beefy machines. Exhaustive search doesn't quite fit into the picture.

But BTW ... in MVTools, the "2nd best" motion search (short of "exhaustive") is search=2, "diamond search". OTOH, compare with x264: in x264 there is also "diamond search" available ... but there, it's about the cheapest and lowest-quality ME method you can only choose. Hmh.

Dunno if I'm missing something here, but my feeling is that MVTools is in severe need of some better motion analysis.

[LaTo]

Originally Posted by Didée

With "light" settings, TempGaussMC can run in range of "half realtime", perhaps full on beefy machines.

ARGH, I bought a E8400 last week... and TempGaussMC run +- 2fps on SD footage
(with defaults settings)

[WorBry]

So try a "lighter" setting, maybe (tr0=1, tr1=1, tr2=1, EdiMode="EEDI2"). Should at least double the speed, and with EdiMode=Yadif, maybe five-fold.

[Didée]

With defaults, of course. Default is "NNEDI", and NNEDI on its own already is pretty slow. Fast is Yadif, or just plain bicubic interpolation instead of any EDI.
Perhaps the estimate was a bit too optimistic, but ... with my archaic hardware, the usual quick guess is that a higher-end machine is 10 or 20 times faster than mine ... (lately, some suggested x264 settings, running 6-7fps on a Q9450, did run at 0.2-0.25fps for me) ... out of the game, I am.

[Malcolm]

Originally Posted by Didée

Malcom: ... (BTW, it wasn't only the pole ... also much of those little waves on the water were smeared away.)

Oh, i've noticed that as well. But that was _so_ obvious, pointing that out would have been a bit insulting to you, wouldn't it?!

[kandrey89]

OK, I'm confused. TempGaussMC is a deinterlacer right? So what stage of development is it in, where can it be obtained?
If it's so good why doesn't it have it's own dev page?

[sidewinder711]

If you are reading this thread carefully from the beginning, you will find out that it is not only a deinterlacer. It's in its "alpha" stage or a bit further... and you can download/copy it from article #13 of this thread.

[kandrey89]

Saw the code, but I don't know avisynth, and don't know any necessary skills to utilize that code :/
Will have to wait for a plugin for VirtualDub, if that's possible :/

[WorBry]

Saw the code, but I don't know avisynth, and don't know any necessary skills to utilize that code :/

Do yourself a favour. It's not that difficult:

http://avisynth.org/mediawiki/Main_Page

Will have to wait for a plugin for VirtualDub, if that's possible :/

TempGaussMC is a scripted function that utilizes a number of AVISynth plugins (filters) that have no VirtualDub equivalent. I think I can safely say that the possibility of a VirtualDub plugin, or series of plugins, that perform(s) the same function is more than remote.

[Terka]

Dunno if I'm missing something here, but my feeling is that MVTools is in severe need of some better motion analysis.

There are some papers on the net...

[Terranigma]

Would it be possible to use/construct TempGaussMC for deinterlacing only without denoising?

[Terka]

you can join original and computed lines together

[WorBry]

Originally Posted by Terranigma

Would it be possible to use/construct TempGaussMC for deinterlacing only without denoising?

Well you could disable the 'post gauss' MVDegrain denoising (Stage 2) by setting Tr2=0, but the mo-comped temporal gauss itself is basically a MVDegrain temporal denoise that has been warped into a gaussian distribution (Stage 1).

As Didee stated earlier:

Originally Posted by Didée

And a *denoiser* is all that this script is, indeed. A denoiser that also "denoises" bob flickering.

[Didée]

Hi ... there's some technical problem with my ISP, currently I'm without internet connection at home. :|

The noise reduction of TempGaussMC is an inherent property of the used method. Trying to avoid this "feature", you'll open several cans of worms that TempGaussMC so explicitly tries to keep closed ... and in the end you would have it stumbling in the very same pitfalls which the other methods regularly fall in. Better let it levitate over those pitfalls, at the expense of reducing noise.

If you actually enjoy the comfy ambience of those pitfalls, then use something else, but not TempGaussMC.


You might try something among the lines of first reducing noise in the interlaced footage, deinterlacing the denoised material, then re-adding the removed noise ... like

interlaced_clip

NR   = FFT3DFilter(sigma=plenty,interlaced=true)

TGMC = NR.TempGaussMC()

NRD  = mt_makediff(interlaced_clip,NR)

TGMC.mt_adddiff( NRD.doubleweave(), U=2,V=2 )  #  or NRD.bob()

, with FFT3DFilter as an example for an interlace-aware denoiser. The results will depend on how properly the denoiser does its job.

[WorBry]

Originally Posted by Didée

The noise reduction of TempGaussMC is an inherent property of the used method. Trying to avoid this "feature", you'll open several cans of worms that TempGaussMC so explicitly tries to keep closed ... and in the end you would have it stumbling in the very same pitfalls which the other methods regularly fall in. Better let it levitate over those pitfalls, at the expense of reducing noise.

I guess this would be an example of one variety of ‘worm’ that emerges from ‘opening the TGMC can’. Did a little comparison of:

TGMCa3 (Tr0=2, Tr1=2, Tr2=2) # i.e. with ‘internal’ MVdegain2

TGMCa3 (Tr0=2, Tr1=2, Tr0=0) + MVDegrain2 # same MVAnalyze/Degrain parameter settings as ‘internal’

TGMCa3 (Tr0=2, Tr1=2, Tr0=0) + hqdn3d(2) # my hitherto preferred (temp-spatial) denoiser for MV/MC-Bobbed DV sources

TGMCa3 (Tr0=2, Tr1=2, Tr2=2) + RemoveGrain(mode=2) # mild ‘post’ spatial degrain

Here’s the results:

http://rapidshare.com/files/12553616...2_RG2.avi.html

Note the relative stabilities of the B&W spotted pattern on the cushion with the red square. With TGMC 222 (i.e. ‘internal’ MVdegrain2) the pattern is well calmed. However, apply the MVDegrain2 after TGMC and some shimmer/vibration starts to appear again. Likewise with hqdn3d, and slightly more so. Apply a light spatial degrain (RemoveGrain mode=2) after TGMC (with internal MVDegrain2) and the ‘worms’ really get wiggling.

So, if I understand the levitation trick correctly, the ‘internal’ MVDegrain avoids regenerating shimmer (one such pitfall) by utilizing the same motion analysis as the denoised feed for mo-comped gauss, but applying a lower thSAD value, so avoiding interference with the directed (high contrast) denoising that has been applied by the gauss. Added to which is an internal repair mechanism that corrects the MVDegrain defects. Correct?

Hope you rectify your connection problem.

Edit: Doh, just noted that merely disabling the internal MVDegrain (Tr2=0) itself results in return of the shimmer. So the internal MVDegrain is actually an integral component of the flicker supression. I guess I should have realized from Didee's comment above . I've edited the uploaded comparison clip accordingly.