QTGMC Deinterlacing Script (v3.32)

[henryho_hk]

I think the simple merge() is out of consideration as we can use a simple and speedy blend-deinterlacer at the first place, no need for the sophisticated QTGMC() script.

MFlowBlur() from 60p to 30p is a better option. If we are to simulate (say, NTSC) 29.97 fps shutter speed from 59.94-bobbed footage, what should be the value of the "blur=" parameter?

And I am thinking whether the existing motion vectors in QTGMC() can be re-used for motion blur in case of single-rate deinterlacing (new QTGMC feature? )

[kypec]

Originally Posted by henryho_hk

MFlowBlur() from 60p to 30p is a better option. If we are to simulate (say, NTSC) 29.97 fps shutter speed from 59.94-bobbed footage, what should be the value of the "blur=" parameter?

And I am thinking whether the existing motion vectors in QTGMC() can be re-used for motion blur in case of single-rate deinterlacing (new QTGMC feature? )

I'd love to see this feature added into QTGMC, just for the sake of seeing the effect when compared to simple SelectEven() approach.
I'm mostly dealing with 50i PAL comedy TV series so there is not much fast motion scenes anyway but still...

[sadie]

Hello, Semi-newb here with a few comments & Qs. On a test clip with a BFF source including an up-pan reversed sequence followed by a standard speed down-pan through jungle foliage coming to rest on a background waterfall, QTGMC is the only deinterlacer (Yadif and TDeint were the other contenders) that could not only knock out that shimmer, but also retain the detail in the moving areas. Brilliant. On the other hand, I've found in more static areas, it resolves less detail than the others. Truth or illusion on my part? And the degradation is slightly worse using any number of combinations of the noise bypass feature. Other than upping the ante with extra sharpening is there any other single feature in the program that might counter this effect?

Is the improvement in resolved (moving) detail due all or in part to the Nnedi3 interpolation component in the plugin. If so, I wonder if configuring Tdeint with Nnedi3 (rather than using the out-of-the box settings in Avidemux) would come close to getting nearly as good results, yet with a dramatic savings in time. Overall, I prefer Tdeint over Yadif, as it can much better handle vertical movement and seems to hold more detail. On the other hand Yadif is tops to completely removing edge jaggies, especially in capture stills. Neither is perfect. Would Tdeint + Nnedi3 be significantly inferior to QGTMC?

Is deinterlacing now at the state of the art where QGTMC might be the preferred method of getting an SD NLE project to a HD flat progressive living room screen? Previously, the classic interlaced DVD was a no-brainer for a simple player on a CRT. But nowadays, it seems you've only had two options: 1 - invest in a top of the line DVD upscaler / Bluray player (which I can't afford) or watch the movie from the hallway outside of your apt (which is uncomfortable). So the question is: Would a SD DV to progressive produced DVD using 'Doom9 technology' produce a quality comparable to what a hardware Oppo or Faroudja would be capable of with a classic interlaced mpeg2 disc?

I wonder if Didee's Stockholm test clip isn't a bit misleading in that the apparently disastrous look of the Yadif sample is only so because the source material is in slow motion. I've never seen anything nearly so bad on a standard speed pan with Yadif. That said, slow motion has always been a royal pain in any of the NLE's i've used. Which leads me to ask the following perhaps dumb Q. Would using QGTMC at the earliest step of the NLE process (even at the pure DV smart render stage) significantly improve on the output of such filters as slow/fast motion, reverse, spot and dust removal, stabilization, etc? In that light, I might ask Didee if his clip was deinterlaced before he applied the slow motion or afterwards?

Anyway, I finish my first full blown encode in a couple of hours, so either I may have answered most of my Qs, or simply be led to come back with more. Thanks for any answers and kudos on a brilliant initiative.

[henryho_hk]

QTGMC/TGMC's output is much more stable than TDeint+NNEDI3+MDegrain3.

[henryho_hk]

Originally Posted by -Vit-

I just added new features to pull out the finest detail... now let's blur it!

Coz "movie" and "motion" share the same prefix "mo".

[matfra]

You said that Tr2=3 is base on MDegrain 1,2,3. Is there a way to Change the thSAD of this Mdegrain with a parameter to get a stronger denoising. What can I do i Tr2=3 is not strong enough.

[Didée]

@matfra: did you already try "rep2=0"? (But don't whine when you discover artifacts afterwards ... it's for a reason that it's activated by default. "Denoising" is not what TGMC was made for.)

Though, your problem could be buried one lever deeper, at the stage of motion estimation. You know.


@ sadie:

Originally Posted by sadie

On the other hand, I've found in more static areas, it resolves less detail than the others. Truth or illusion on my part? And the degradation is slightly worse using any number of combinations of the noise bypass feature. Other than upping the ante with extra sharpening is there any other single feature in the program that might counter this effect?

It is true that TGMC doesn't resolve "100% perfectly" in fully-static areas. You might give a go on the "lossless" option - with this addition, detail recovery in static areas will (should) become better; however results in moving areas probably will become slightly worse.

Key point is that Q/TGMC doesn't care or watch out for "static areas". This property doesn't exist in the world of TGMC. This has upsides and downsides ... the downside you have just discovered. The upside is: when you don't try to guess static static areas, then it's 100% guaranteed that you won't guess wrong.

Is the improvement in resolved (moving) detail due all or in part to the Nnedi3 interpolation component in the plugin. If so, I wonder if configuring Tdeint with Nnedi3 (rather than using the out-of-the box settings in Avidemux) would come close to getting nearly as good results, yet with a dramatic savings in time. Overall, I prefer Tdeint over Yadif, as it can much better handle vertical movement and seems to hold more detail. On the other hand Yadif is tops to completely removing edge jaggies, especially in capture stills. Neither is perfect. Would Tdeint + Nnedi3 be significantly inferior to QGTMC?

Simply try it!

interlaced_clip
tdeint(mode=1,edeint=NNEDI3(field=-2))

You tell if it's "nearly as good".

BTW, i once did Stockholm also with TDeint+NNEDI. (Old version of TGMC, and only NNEDI instead of NNEDI3 back then - but that doesn't impact the technical principles.)

I wonder if Didee's Stockholm test clip isn't a bit misleading in that the apparently disastrous look of the Yadif sample is only so because the source material is in slow motion. I've never seen anything nearly so bad on a standard speed pan with Yadif. That said, slow motion has always been a royal pain in any of the NLE's i've used. Which leads me to ask the following perhaps dumb Q. Would using QGTMC at the earliest step of the NLE process (even at the pure DV smart render stage) significantly improve on the output of such filters as slow/fast motion, reverse, spot and dust removal, stabilization, etc? In that light, I might ask Didee if his clip was deinterlaced before he applied the slow motion or afterwards?

"Misleading" ... maybe a little. It's a "worst case example". With realworld sources, usually you won't see other deinterlacers fail so blataneously obvious. But: technically, the sample is perfectly valid. The shortcomings shown there are exactly the same shortcomings you'll get with any other clip. The problems might be less obvious, but in essence the're the same.

The slow motion has nothing to do with this at all. The clip was bob-deinterlaced from 25i to 50p. At the end I did "AssumeFPS(12.5)" to force slower playback speed. In technical regards to deinterlacing, this is completely irrelevant.

[matfra]

Thks Didée for you reply.
I admit before I was using Rep2=0 in past. What other parameter I can use to get a stronger denoising.
Im using this now.

QTGMC(SourceMatch=3,EdiMode="nnedi3",tr0=2,tr1=0,tr2=3,rep4=0,rep1=0,rep2=4,Sharpness=1.00,MatchEnhance=1.0,NoiseBypass=0, NoiseRemove=1.0, DetailRestore=0.0, NoiseRestore=0.0, Sigma=3, NoiseDeint="generate")

[matfra]

What you think about this idea. Is it better to apply a denoising before the deinterlaced ? Explample run Mdegrain3, then QTGMC. Or may run QTGMC with sone denoising parameter then clean up the rest with a Mdegrain2.

[Didée]

Many ways lead to Rome.

However, I can't tell which road is most suited for your footwear.

[henryho_hk]

Sometimes heavy grain kinda confuses (Q)TGMC.... and I find degrainmedian(mode=2, interlaced=true) helps. I also prefer "tr2=3"

[-Vit-]

Single-rate motion-blur: would slot-in nicely at the end of the script, and would be able to reuse the motion vectors (they might need a reanalyze). I'll try it at some point, but I'm looking at other things at the moment. Not so hard to try yourself - do it in the "Post-Processing" section on the clip "addNoise2" - can see all the mo-co settings a few lines further up where there are some MDegrains.

Static areas: It's not right to say that QTGMC doesn't care for static areas. QTGMC with source match is damn good on static areas. It's much better than the standard TGMC algorithm.
QTGMC( SourceMatch=3, Lossless=2, Sharpness=0.05 ) is near perfect in most cases. QTGMC( SourceMatch=1, Lossless=2, Sharpness=0.05 ) is almost identical, but faster. You can drop the Lossless=2 part for a bit more speed, a bit less accuracy and to avoid worries about artefacts with lossless processing. Tweak the sharpness in each case, may need more if you switch Lossless off - the default for source-match is 0.2

@matfra: I tend to use QTGMC + noise bypass to remove the worst of the noise, but not all of it as that can reduce the quality of the QTMGC processing (the mo-co needs a bit of fine detail to "grip" on to, if your "denoising" starts to become "blurring" then that's a problem). I follow up the QTGMC with a finer denoise step (mdegrain, another FFT3DFilter with a lower Sigma, whatever). Edit: And yes, I may well expose the thSAD settings again.

I hadn't anticipated so much interest in the denoising aspect of QTGMC. It was never intended to be a denoiser, I originally wanted to retain grain in some vids. Recently my interest was caught when I realized you could nicely "deinterlace" noise with motion compensation. However, that's about retaining noise too (or more precisely, detail that has "noise-like" properties). This part of the script is going to undergo some change: (a) to finalize my mo-co noise-bypass technique and deal with chroma noise, (b) simplify the settings, so it's more obvious what the settings actually do, and (c) reluctantly, I'll put some more control over the straight denoising aspects as obviously some people want a one-stop solution for their sources [but QTGMC is never going to be a replacement for a fully featured denoiser].

[Didée]

Perhaps my wording was not good.

What I meant is: neither Q nor TGMC do a "detection" of static areas. Deinterlacers like e.g. tdeint try to detect static areas, then perform "static->weave, motion->interpolate". Which is okay when the detection is okay, but problematic when the detection is wrong. See tdeint's plentitude of parameters that are dealing with / related to artifact protection.

And yeah, QTGMC's source match delivers good results. Though, I think something should be done about "lossless=2". It's not really convenient to first have a "lossy" deinterlacer, then offer a "lossless" option, but still produce a "lossy" result in the end. Lossy is lossy, lossless is lossless.

Nothing against the operations as such, they are fine. It's just that they should be structured differently, somehow.
(I like to drink milk as well as beer. Both are fine. But when I order "beer", then I want to get beer, not milk.)

[-Vit-]

I don't like the name of the Lossless=2 setting either, and considered alternatives. From a scripting point of view, it really is exactly the same process as Lossless=1 (real lossless), just done earlier. But from a user point of view it looks like a source-match extension - yet it's completely independent of source-match. The "logical" alternative is to make Lossless a boolean (true, false) and add a new setting, say "SourceMatchBoost" or something, also a boolean. Before I was sensitive to adding even more settings because I thought that you couldn't have more than 60 of them, but now I think that's a limitation from an earlier version. So maybe I will make a change like that...

[Robert Martens]

Originally Posted by henryho_hk

I think the simple merge() is out of consideration as we can use a simple and speedy blend-deinterlacer at the first place, no need for the sophisticated QTGMC() script.

I agree that it's probably the way to go for those who want things done as fast as possible, but I'd still recommend people at least give Merge() a shot; it's been a while since I've done any real investigation, but I've never seen a blend deinterlacer (or any deinterlacer, for that matter, save MCBob) that comes close to (Q)TGMC as far as producing clean curves and diagonal lines. Using Merge() gives blend-style results while retaining the neat, smooth edges TempGauss and its variants manage to create.

I don't mean to suggest that there's a perfect solution, but if you're as easily irritated by aliased diagonals as I am, you may find Merge helpful for same-rate output.

[sadie]

Well after a full 24 hours of encoding I've obtained 3 full 1-hour encodes using the triad of Yadif, Tdeint and QTGMC. To be frank, much of what I'd commented on earlier this morning turn out to be unfounded. A 1-minute source using single pass settings with non-geometrical subject matter cannot be the litmus test for deinterlacing which excels at straight lines and curves. In fact it was a pure pleasure to go through scene after scene, the first such joy I've felt in some time now in this domain. Finally, a real wheel that works.

To be short, Yadif can match QTGMC in some areas but fails in others. Tdeint can match QTGMC in other areas but fails in turn elsewhere. But none of them can match OTGMC all the time in all areas, much less surpass it. And surpass QTGMC does most of the time. As for detail in static areas, I again spoke to soon. What I mistook for 'sharp details' in Tdeint were in fact artefacts, that because they were in a natural milieu (a stone here, a water droplet there) were not readily apparent as 'errors'. In fact, even with my still captures edges with your program were as good if not not a tad better than even Yadif.

The noise present in my source (for better or worse) was reproduced perfectly. Like Vit, I'm no enemy to noise as such except for certain classic areas such as fade to blacks over bright blue skies or darkish monochromatic walls. It's been my bane for years and perhaps I'll take a stab at some of your suggestions above, or again just throw a whole lot of 'bitwidth' at it (or is that bandwidth). I think Henry Ho will remember a few years back we had huge go around on this board to try and fix an earlier problematic clip.

It took me nearly 6 hours per pass using the 'fast' preset (no MT). I take it if I dared to take the source match route we'd be talking at least double time, no? Which brings me back to Didee and his partial answer to my question. The 'fast' preset did not eradicate all errors. In fact, in those rendered slow motion sequences where the rate was .5x or less QTGMC cleaned it up. But on two static but unstabilized examples where the slow down went as low as .2x it had no effect. So if I'd delaced before using the filter, I'd probably not have suffered the consequences. Or not? Which brings me also to ask whether there is a version in the works of this avisynth script to be of use in a major commercial NLE. Is there a practical workaround (other, that is, than that of delacing the entire body of source material from the outset)?

I may have noticed a slight anomaly. The QTGMC encode (via virtualdub x264 fast recompress) appears slightly darker/contrastier/more saturated than any either the Yadif or Tdeint encodes (using Avidemux x264) or the straight to DVD route with Procoder v3. The latter three are identical luma & chroma-wise? On my screen the effect is actually an improvement under mplayerhc using either VMR 7 windowed or Haali renderers. Any explanation? And I'd still be interested if anyone could compare their experience with Oppo/Faroudja.

For the anecdote, I was so ticked off last week about the whole interlace to progressive problematic that I decided to kiss it all good-bye and gave my daughter my Panasonic GS400. Trouble is she's a tough cookie and I fear there is now no getting it back. Well, maybe I'll just go and write a detective novel.

[STC-Fan]

Originally Posted by matfra

STC-Fan ,
Can you explain me the difference between MDegrain2 and you Mdegrain2i2 ? Its it for interlaced source ?

MDegrain2i2 is for interlaced content only. The code is straight from fizick's MVTools2 page but with values from Cnr2 passed to it, which was added by someone on the VideoHelp forums.

Originally Posted by -Vit-

This video isn't interlaced, there aren't two different fields in each frame. It's more like there's an offset between the odd and even lines in places giving combing-like effects.

Yes, I am seeing them now - and as henryho_uk pointed out just doing a SeparateFields() operation shows it up as well. I'll certainly make use of this a bit more in future as I suspect a lot of the other files I have have come out in this way, and are not really interlaced at all. I haven't really given it much thought before, aside from noticing the smaller and less frequent nature of combing artifacts, but I think only the content I have from the 1990s / 1980s is truly interlaced, so I probably need to treat more of the post-2000 content in the same way as for this Castrol video.

If you do use QTGMC, then flag it as progressive input, e.g:

QTGMC( Preset="xxx", InputType=1, TR2=3 ) # TR2=1,2,3 for some temporal denoising (mdegrain-based)
VInverse() # This helps too

EDIT: I've dropped in those settings (including Vinverse) as above, commented out the separate MDegrain2i2 and the results are very good - I hadn't realised MDegrain was actually used in QTGMC but looking at the preview in MeGUI and the final output encoded to x264, using QTGMC with TR2=3 removes all the noise that MDegrain2i2 was removing before, but is leaving a sharper finish. And the encoding speed hit nearly 10 FPS so that's a big improvement on the previous settings

[-Vit-]

Originally Posted by sadie

I take it if I dared to take the source match route we'd be talking at least double time, no?

Not so much as that: I just did a quick single-threaded test and it's around 15% slower with SourceMatch=1, Lossless=2 when using Preset="Fast". Nice detail improvement too. A slower system might suffer more though...

Originally Posted by sadie

The QTGMC encode [...] appears slightly darker/contrastier/more saturated [...]. Any explanation?

Try "Precise=true". To get a tiny bit more speed, QTGMC removes a couple of minor adjustments by default. I haven't looked at that setting for a while, it may or may not be relevant. I'll be looking carefully at the chroma side of the deinterlace for the next significant release - I'll take the time to do some similar comparisons.

[Didée]

Originally Posted by sadie

The QTGMC encode [...] appears slightly darker/contrastier/more saturated [...]. Any explanation?

I reckon it's a playback issue, and/or the video got flagged differently by the different applications, or sth like that. When I compare bob/yadif/tdeint/qtgmc with levels(), the histograms are virtually identical. No darkening / lightening / contrast spreading is taking place. Everything's like it should be.

[sadie]

Thanks Vit, for your encouragement on the source match info. Doesn't sound as bad as all that. I'll give it a try next.

As for the eventual luma/chroma shift, yes, Didee that's what I originally thought as well. I've experienced it often in the past where it seems to be related to one of two issues, perhaps related. One is somehow connected with overlay. If I open any mplayerhc file under Xpsp2 system default (VMR7 windowed) I'll be presented with an image that is to my eyes flat, over-ex, washed out. If I open a second instance (or more) of that same file the video will then manifest the richer deeper color associated with my edit. Windows is apparently using a different color space the 2nd time around. Yet in the past the simple action of switching to Haali renderer corrected this anomaly. Haali would open all instances of the video with same color space/balance (whatever you want to call it). Except in this case. Here, Haali too reproduces the same aberrant behavior as VMR7. Which is why it lit up a bulb in me. Also, some time back I'd had a similar issue when dealing with Coreavc decoder and the luma variance turned out to be associated with TV vs Computer levels. Now, I haven't a clue what I might have done in virtualdub to possibly force/expand 601? levels artificially. It remains a mystery.