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. |
15th December 2011, 01:55 | #1021 | Link |
Registered User
Join Date: Jul 2010
Posts: 448
|
Yes, QTGMC does "take both fields into account" (and more) even if you keep single rate. Every output frame is constructed from a range of neighbor fields as Didée has noted. By default the current field is interpolated into a full frame, then the two fields before and after (interpolated + motion compensated) are combined into the frame in such a way as to remove bob-shimmer. This temporal processing also enhances detail to some degree and has some noise reducing effect.
So all source data will have been used in your output even after a SelectEven(). The result will be primarily based on the even fields of course, but the neighboring ("thrown away") fields will have had an influence too. Last edited by -Vit-; 15th December 2011 at 02:05. |
15th December 2011, 10:27 | #1022 | Link |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
Most deinterlacers will take neighbouring fields into account in some way, rather than simply interpolating a single field. Exceptions to this are Bob (at one end of the sophistication spectrum) and the nnedi family (at the other).
|
21st December 2011, 01:29 | #1023 | Link |
Registered User
Join Date: Aug 2006
Location: Stockholm/Helsinki
Posts: 805
|
When EdiMode doesn't match anything (so it uses Bob) (of course together with SourceMatch), the result looks horrible.
Adding a ComplementParity to bobbed fixes this. Line 353-355: Code:
bobbed = (InputType == 0) ? planarClip.Bob( 0,0.5 ).ComplementParity() : \ (InputType == 1) ? planarClip : \ planarClip.Blur( 0,1 ) Last edited by ajp_anton; 21st December 2011 at 02:41. |
21st December 2011, 10:52 | #1024 | Link | |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
Quote:
Therefore, the parity should probably only be reversed if the input clip is TFF. |
|
21st December 2011, 22:07 | #1025 | Link | |
Registered User
Join Date: Aug 2006
Location: Stockholm/Helsinki
Posts: 805
|
Quote:
|
|
21st December 2011, 23:38 | #1026 | Link |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
That suggests your captured clips are TFF.
If my assumptions about the problem are correct, your suggested fix to QTGMC will work for your source, but will make BFF sources go wrong instead. It needs to check the parity of the original input and reset the Bob() output to match it, rather than calling ComplementParity() unconditionally. |
22nd December 2011, 06:18 | #1027 | Link |
Registered User
Join Date: Jul 2010
Posts: 448
|
Thanks ajp_anton/Gavino, noted. I finally have the time for occasional QTGMC work again. I may put out a service release with a few minor bug-fixes/improvements in the next week or so, as the next major release will still take some time.
|
24th December 2011, 01:55 | #1028 | Link |
Registered User
Join Date: Dec 2011
Location: Australia
Posts: 13
|
Im sorry if this a stupid question but I'm really trying my best to get to grips with all this. Is it possible to use QTGMC within Ripbot?, if so, is there anyone who would be willing to lend me a hand in setting it up?
|
28th December 2011, 17:24 | #1030 | Link |
Registered User
Join Date: Mar 2003
Location: SVK
Posts: 15
|
Hi everyone
is there a filter/solution for this record ? http://www.mediafire.com/?rwugl4d4269x5v6 thanks |
28th December 2011, 20:59 | #1031 | Link |
brontosaurusrex
Join Date: Oct 2001
Posts: 2,392
|
dbart: looks like a dirty (composite connection?) analog path was there to make this happen, possibly with some less than perfect digital compressor (might be also something to do with the way some of the digital tapes work, when their head is getting aged...), deinterlacing works thought (i just tryed quick yadif=0).
__________________
certain other member |
29th December 2011, 02:04 | #1032 | Link |
Registered User
Join Date: Aug 2006
Location: Stockholm/Helsinki
Posts: 805
|
I'm starting to look through / rewrite the code for this to better understand how it works.
I noticed that instead of Code:
ts = bobbed.temporalsoften(1,255,255,28,2) binomial = ts.merge(bobbed, .25) Code:
bef = bobbed.trim(0,-1)+bobbed aft = bobbed.trim(1,0) binomial = merge(bef,aft).merge(bobbed) Comparing them to a mt_lutxyz, which I guess is the most accurate (in 8-bit), on my test clips it seems temporalsoften has on average ~22% errors and "my" trick has ~25.0% (how many pixels are off by 1). Not that it makes much speed difference either, but it's something... edit: mt_lutxyz actually runs between these two in terms of speed (but obviously needs much more RAM and has slower startup time). Last edited by ajp_anton; 29th December 2011 at 02:26. |
29th December 2011, 03:53 | #1033 | Link |
Registered User
Join Date: Jul 2010
Posts: 448
|
I doubt your few extra out-by-1 pixels will cause much problem since the result is only used for motion analysis where the pixels are aggregated into blocks. The lack of motion compensation at that point is likely a much more significant source of motion analysis error.
However, TemporalSoften has (simplistic) scene change detection, whereas your script will blend across scene change boundaries, which may cause analysis errors or conceivably make scene change boundaries be missed when motion analyzed... Last edited by -Vit-; 29th December 2011 at 04:41. Reason: ... |
29th December 2011, 04:44 | #1034 | Link |
Registered User
Join Date: Aug 2006
Location: Stockholm/Helsinki
Posts: 805
|
Ah, didn't think about that. That could be why it's slower =). The content I'm fine-tuning this for doesn't have any scene changes so I'm fine without it.
rep0 seems to take care of most of the scene change artifacts though. Especially rep0=0, which leads me to: Is there any downside to using QTGMC_KeepOnlyBobShimmerFixes with rep0=0? It's "blocked" in your script (and the original TGMC), but I think it does a pretty good job. (And rep1/rep2? Haven't gotten that far yet =).) edit: Another thing I've been thinking about... that epsilon in GaussResize. I realize how meaningless this is, as it's probably well within the precision of 8 bits, but it disturbs me a little that the epsilon "downsizes" the clip. Using it to "shift" instead helps me sleep a little better at night =). (GaussResize(w,h,ep,ep,w,h,p=2)) Last edited by ajp_anton; 29th December 2011 at 08:19. |
29th December 2011, 15:26 | #1035 | Link |
Registered User
Join Date: Jul 2010
Posts: 448
|
Temporal smoothing is used to remove bob-shimmer, but we don't want large areas of motion blur so the Rep0/1/2 settings limit the amount of change that the temporal smoothing is allowed to make. Higher values for Rep0/1/2 allow larger areas of change from the smoothing, but (counter intuitively) 0 switches of the limiting completely and so allows all changes through. You're right that there is a code path for Rep0/1/2 = 0 that is not used. However, that code path would only allow 2-pixel high areas of change, much bob-shimmer covers a larger area than that. It would be getting close to doing no temporal smoothing at all, similar to TR0/1/2=0 and would be especially bad on stationary detail. Having said that, it does seem to be a little odd not to allow that code path even if it is not the most useful.
Why is 2 pixels not enough? Consider a stationary single pixel high horizontal line, positioned such that it appears only in the even fields. The bob will expand that to a 3 pixel high line, and clearly it will be a cause of major bob-shimmer, flickering on and off. When temporally smoothed, the now 3 pixel high line is softened in the even frames and appears in the odd frames. Bob shimmer removed - by a 3-pixel high area of change, which would be removed if you followed the Rep0=0 code path... I could make that more clear with a diagram, but I hope you get the idea... [I note that my comments on that function need an update for precision: the two vertical in/expands allow through areas of change up to 4 pixels high, the in/deflate and RemoveGrain are not limited vertically so they also perform some measure of mask clean up] As I'm sure you're aware, the epsilon is only there to trigger the GaussResize to do its blur even though we're not actually resizing, I'm sure it doesn't matter much where it is placed given the tiny value and the fact it is being used on a huge blur anyway. I do wonder if there's a more efficient way to do a Gaussian nowadays, or something similar. Last edited by -Vit-; 29th December 2011 at 15:30. |
29th December 2011, 17:44 | #1036 | Link |
Registered User
Join Date: Aug 2006
Location: Stockholm/Helsinki
Posts: 805
|
Yes it seems that higher reps are needed for really worst case scenarios (made some in mspaint =)).
rep=0 flickers slightly on most 1-pixel lines but works on everything (?) else, rep=3 captures 1-pixel lines, but rep=5 is needed for when two lines are spaced 2 pixels from each other. Here rep=0 fails hard. What I don't like about rep>0 is that they allow too much blur in motion, and my videos are slightly blurred before being interlaced, so rep=0 works well there. (I know why the epsilon is used, I just don't like where it's used, even though it makes exactly zero difference =).) |
29th December 2011, 18:47 | #1037 | Link |
Registered User
Join Date: Jul 2010
Posts: 448
|
Those "worst case" examples occur in reality - almost any static text/captions/graphics, and also detailed stationary shots. I can easily find examples where the rep=0 code path looks very bad. However, as I have a small update to make shortly I will probably enable that code path with Rep=1 and shift the other Rep values up by 1. I'm sure the 2 people who actually use those settings manually can cope with the change
|
2nd January 2012, 05:50 | #1038 | Link | |
Registered User
Join Date: Dec 2002
Location: Region 0
Posts: 1,436
|
Quote:
Here is my post on it. |
|
3rd January 2012, 08:39 | #1039 | Link |
Oz of the zOo
Join Date: May 2005
Posts: 208
|
if you have a 64-bit Windows and a lot of RAM (4+ GB) then patching 32bit host exe (avs2yuv etc) with 4GB limit patch helps qtgmc a lot - then you can set SetMemoryMax(3072) or probably even more and enjoy your qtgmc.
Last edited by wOxxOm; 4th January 2012 at 09:06. |
Thread Tools | Search this Thread |
Display Modes | |
|
|