Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
|
|
Thread Tools | Search this Thread | Display Modes |
24th June 2008, 15:51 | #81 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,391
|
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.
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
24th June 2008, 16:19 | #82 | Link | |
LaTo INV.
Join Date: Jun 2007
Location: France
Posts: 701
|
Quote:
The problem go away with SCD1=100... If >100 the lines is present. Last edited by LaTo; 24th June 2008 at 16:32. |
|
24th June 2008, 16:43 | #83 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,391
|
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.
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
24th June 2008, 16:44 | #84 | Link |
Registered User
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,197
|
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
__________________
Nostalgia's not what it used to be |
24th June 2008, 16:54 | #85 | Link |
Registered User
Join Date: Feb 2003
Location: Russia, Moscow
Posts: 854
|
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. |
24th June 2008, 17:17 | #86 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,391
|
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.
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
24th June 2008, 18:14 | #87 | Link | |
LaTo INV.
Join Date: Jun 2007
Location: France
Posts: 701
|
Quote:
(with defaults settings) |
|
24th June 2008, 18:40 | #88 | Link |
Registered User
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,197
|
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.
__________________
Nostalgia's not what it used to be |
24th June 2008, 18:43 | #89 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,391
|
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.
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
25th June 2008, 00:46 | #92 | Link |
near the waterfront
Join Date: Feb 2008
Posts: 38
|
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.
|
25th June 2008, 04:50 | #94 | Link | ||
Registered User
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,197
|
Quote:
http://avisynth.org/mediawiki/Main_Page Quote:
__________________
Nostalgia's not what it used to be Last edited by WorBry; 25th June 2008 at 04:53. |
||
27th June 2008, 00:39 | #98 | Link | |
Registered User
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,197
|
Quote:
As Didee stated earlier:
__________________
Nostalgia's not what it used to be |
|
27th June 2008, 11:20 | #99 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,391
|
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 Code:
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()
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
28th June 2008, 03:12 | #100 | Link | |
Registered User
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,197
|
Quote:
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.
__________________
Nostalgia's not what it used to be Last edited by WorBry; 28th June 2008 at 05:10. |
|
Tags |
deinterlace, flickering |
|
|