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. |
29th October 2009, 21:43 | #1 | Link |
Banned
Join Date: Jun 2008
Posts: 94
|
TempGaussMC "insane" settings?
Hi all,
According to this post, the Default settings of TempGaussMC are a medium effort. So Iv'e been wondering what are the extreme settings of TempGaussMC, visual quality wise? to be honest, reading to docs and figuring this out for myself is still a bit confusing... Last edited by bizz & buzz; 30th October 2009 at 04:36. |
30th October 2009, 09:49 | #2 | Link | |
Registered User
Join Date: Jan 2005
Location: cz
Posts: 704
|
1. ON which source, what artefact do you want to remove, or what you want to achieve?
2. Have some experience on DV sources. tr0=2 tr1=2 tr2=3 (or more-you can change the script, so it uses mdegrain5 EdiMode="nnedi2" - or you can change the script to use TdeintTMM_Nnedi2: Quote:
DCT=0 <- try yourselves 1 or more, but speed is getting looow (depending also on blocksize) the blocksize change wont help instead of inner sharpen routine use SuperSlowSharpen tryied also mrecalculate using blocksize=32 and blocksize=4 IMHO the red will help more, the orange will help less, other are discutable. Myself spend a lot of time playing with it. But im rookie. You can also try modify MCbob: return (last) -> return (repaired) (and also put in it nnedi2 instead nnedi) IMHO conclusion: insane settings and tweaks are possible, but you got 2% in quality for 5-10x slower time. So until someone will get an idea, how get the 2% for 2x slower time, or mvtools will significantly improve or new filters appear...use the default, or red, or play with the script yourselves |
|
30th October 2009, 20:11 | #3 | Link |
Banned
Join Date: Jun 2008
Posts: 94
|
I'm trying to retain as much details as possible (i.e no denoising higher then defaults) and still get a stable and accurate result as much as possible. Speed is not an issue - I'm willing to leave the machine working for days.
Here is a little report after testing some of your your recommendations: - tr2 - setting it to 3 is probably more precise then the default (1), but it also denoise more, so no go. - EdiMode settings are source dependent (here). on my specific source "nnedi2" was better then EEDI2 and Yadif. - Search=3 yield very small to no improvement. - Changing DCT didn't make much difference. - Blocksize - reducing it to 8 actually created some minor distortion on horizontal straight lines in some frames. Setting it back to the default 16 resolved the issue. Haven't got time to try SuperSlowSharpen and the modified MCbob So to my eyes, apart from EdiMode (and TGMC's Sharpness), changing the other parameters indeed made only a small difference. Thanks for your input Terka, and if there's some more suggestions I'll be happy to try them. |
30th October 2009, 20:53 | #4 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
You might want to give a try on that noise-bypass technique with TGMC.
__________________
- 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!) |
31st October 2009, 10:08 | #5 | Link |
Registered User
Join Date: Jan 2005
Location: cz
Posts: 704
|
want ask:
1. what is your source? 2. what is the output framerate? Try the above 'noise-bypass technique' together with tr2=3 (and maybee Blocksize=32 will calm also a bit more) Last edited by Terka; 31st October 2009 at 10:11. |
31st October 2009, 14:07 | #7 | Link |
Banned
Join Date: Jun 2008
Posts: 94
|
The noise-bypass technique did really really well!
also, using tr2=3 with the above technique restored the details that otherwise would have been lost due to tr2=3 - so now tr2=3 will be used. Changing Sbb didn't change thing significantly, but reducing SVthin did improve the picture a bit, so it will be set to 0.5. BTW, the source is an NTSC DVD of old NBA games, so output frame rate will be 29.97 (I'll use SelectEven). some questions: Is the noise-bypass technique can be useful with other filters that tend to remove details in order to do their job? Am I right to assume that now there is no need to change block size to 32 (and risk loosing accuracy), because the fine details have already been restored? |
31st October 2009, 20:21 | #8 | Link | |
Registered User
Join Date: Jan 2005
Location: cz
Posts: 704
|
the blocksize 32 will make static areas more calm, moving areas will be less precise, but you wont realise this much.
Try yourselves. If the output is 29.97, you can try: Quote:
but if its fast, and NBA is damned fast, imho ill left the double framerate. Last edited by Terka; 31st October 2009 at 20:29. |
|
1st November 2009, 00:12 | #9 | Link |
Banned
Join Date: Jun 2008
Posts: 94
|
I'm getting an error when setting blocksize to 32:
MVAnalyse: block's size must be 4x4 8x4....32x16. ? (Couldn't find anything useful with search or Google). Using NNEDI2 alone was a lot faster then TGMC but as expected, TGMC had better quality. I too think that sport vids can benefit from the doubled frame rate, so I'll do two encodes and see if the visual improvement will be worth the extra bits. |
1st November 2009, 06:22 | #10 | Link | |
*Space Reserved*
Join Date: May 2006
Posts: 953
|
Quote:
syntax to use is practically the same, but with the letter 'u' added at the end. |
|
2nd November 2009, 11:46 | #12 | Link |
Banned
Join Date: Jun 2008
Posts: 94
|
@Terranigma:
There's a small smoothing effect when using TempGaussMC_beta1u and not the regular TempGaussMC_beta1. Since the difference is only by using MVtools2 and not MVtools 1.XX, the cause for the effect is either a change in MVtools' internal functions, or a change in it's defaults. Looking at the defaults, I did find some changes (Search, Rfilter) but I'm not sure they are related. is there any way to eliminate this smoothing effect? |
2nd November 2009, 15:47 | #13 | Link | |
*Space Reserved*
Join Date: May 2006
Posts: 953
|
Quote:
What you could do however is open the script with a text-editor such as notepad or wordpad and hit ctrl+f to bring up the search menu and do a search for msuper (3 total) and add rfilter and set it to mode 0 for all 3 (per the old method in mvtools 1)--see if that helps. |
|
2nd November 2009, 18:48 | #14 | Link | |
Advanced Blogging
Join Date: May 2009
Posts: 480
|
You are introducing a chroma shift with this line:
Code:
## MDegrain causes a chroma shift (yes it does, with pel>1 !) We compensate by shifting chroma towards plain EDI by a small notch ## [ 1+(x-1)/(1+(x/5)^4) ] on 128-centered diff-clip (x-y) ==> [ x y - abs 2 < y x x y - abs 1 - 1 x y - abs 5 / 4 ^ + / 1 + x y - x y - abs 0.0001 + / * + ? ] stage2 = stage2.mt_lutxy(edi,"x y - abs 2 < y x x y - abs 1 - 1 x y - abs 5 / 4 ^ + / 1 + x y - x y - abs 0.0001 + / * - ?",Y=2,U=3,V=3) Quote:
|
|
2nd November 2009, 20:14 | #15 | Link | |
*Space Reserved*
Join Date: May 2006
Posts: 953
|
Thanks for pointing that out, but i'm pretty sure that this chroma shift you're referring to is not the issue bizz & buzz was referring to (since i'm pretty sure he was using the latest version of mvtools 1 which would mean the shifting would have occured), and now that I think about, it's not rfilter either. It's this:
Quote:
Zshare |
|
2nd November 2009, 23:56 | #17 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
Thanks for the pointer, though it's only a reminder. This point already was mentioned earlier.
"Chroma shift" is a slippery formulation here. (Congrat's, if intended.) It's a valid denomination for what is happening, but predominantly it suggests sort of an "incorrectness", like e.g. wrong spatial position of chroma samples, or possibly a shift of hue. Which it is not. It is not incorrect in any way. It is a bit suboptimal, yes. But it is still correct. All it does is to take the end result, and adjust each chroma pixel a notch towards the chroma pixel of the initial EDI interpolation. Since the initial EDI interpolation can be assumed to be technically correct, so is the result of this operation. The only loss is a tiny bit of temporal stability, at worst the result will have some minor additional bob shimmer in the chroma channels. So little, and and in such places, that nobody ever would see a difference. Set up a blind test, it'll come in close to 50%. With the affected older MVTools versions, it was a good thing. And after MVTools's correction, it doesn't matter. TGMC is not pixel-exact / value-exact anyway, and ... wait ... Ooohh, waitwaitwait! Make a PSNR comparison! Didn't try, but I bet that this shift operation increases the PSNR score of the result! Strike! Leave it in, kick it out, whatever. It doesn't matter.
__________________
- 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!) |
16th February 2010, 04:58 | #18 | Link | |
Registered User
Join Date: Nov 2009
Posts: 2,352
|
Quote:
Also whats the difference between your last version, and the EEDI3 one, besides EEDI3? which one should I use (in quality terms)? Does TempGauss work for Hybrid should I say(?) like some 3-progressive+2interlaced frames material? or just plain bobbing? MT=true is outdated? it asks me for MvAnalyseMulti which I think is from an older MVtools? Sorry for the questions, Im new to this filter... Last edited by Dogway; 17th February 2010 at 13:53. |
|
17th February 2010, 14:12 | #19 | Link |
Registered User
Join Date: Oct 2009
Location: crow-land
Posts: 540
|
Well, just above the recent post at this link http://forum.doom9.org/showthread.ph...74#post1374374 Didee seems to use tempgaussmc_beta1u which could possibly be the version from 3Nov just a few posts above here (post #15).
|
Thread Tools | Search this Thread |
Display Modes | |
|
|