Why is QTGMC so destructive and why do so many people still recommend it?

[Selur]

Test on BetacamSP (into DV25) capture: https://imgsli.com/MjYxMTMx https://imgsli.com/MjYxMTQx

Hmm,.. old QTGMC with some light contrast sharpening?

64x times slower.

Leaving the Q in QTGMC,.. going back to TGMC?

[Alwyn]

Quadratic, not Quick!

[Selur]

Are you sure? (got a reference for that)
iirc QTGMC started out as basically TempGaussMC with presets to make it usable,...
"(Quick) Temp Gauss Motion Compensated" and thus the Q was quick ('quick' also was then also kind of funny, since it was still horribly slow)
+ I don't see where the quadratic would come from.

seems I'm not the only one who thinks this is correct:
https://forum.doom9.org/showthread.php?p=1987389#post1987389

[Alwyn]

Don't believe everything you see on the Internet. I don't know what to believe!

https://www.quora.com/unanswered/What-is-QTGMC-and-how-can-I-use-it-to-deinterlace-my-...ideo%20footage.

If it does stand for "Quick", that's an odd interpretation of "quick", even without this 64x slowdown.

[Selur]

Like I wrote, the quick more came from its quicker than TMGMC and yes, it was kind of a funny thing back then.
=> Quora is wrong.

[Alwyn]

[DTL2023]

How would someone use this instead of the old one? Just install it and it would remove the old QTGMC?

Unpack archive to some folder and add your processing script (I typically call it src.avs) and Import("M_QTGMC.avsi"):

Example:
LoadPlugin("ffms2.dll")
Import("QTGMC.avsi")
Import("M_QTGMC.avsi")

FFmpegSource2("aos_xtr.avi")

ConvertToYV12(interlaced=true)
AssumeBFF()

old_slow=QTGMC(preset="slow").Subtitle("old slow")
new=M_QTGMC().Subtitle("M_QTGMC")

Interleave(old_slow, new)

Prefetch(2)

"Any video samples comparing the two?"

It was over-night quick release. At my home E7500 CPU it runs at 0.17 fps with SD so I will make some movie demos at next day at work (at least i5-9600K expected to run about 10x faster).

[DTL2023]

64x times slower.

Leaving the Q in QTGMC,.. going back to TGMC?

Oh - if Q was Quick - so it is M_USTGMC of Monster-UltraSlowTGMC. (Where Monster is a new mascot for mvtools 2.8.x series design pre-released in 2024 as golden-furred Dimar Dragon https://www.furaffinity.net/view/56366839/ with lots of small details painted but also in same pre-release alpha state with temporal mane). I will replace my mascot image on github soon for a new Monster headshot

Really M_ may be as Many-*TGMC as M_QTGMC is only wrapper for several calls to QTGMC with different params sets and gathering details from each result. It can be also used with 'classic' QTGMC based on classic 2.7.x mvtools (pinterf release update to 2.7.46 in May 2024 https://github.com/pinterf/mvtools/releases/tag/2.7.46 ). Simply remove all new params in QTGMC calls (named mvt_*).

"since it was still horribly slow"

I understand 64x times slower it is big enough performance penalty. But it is expected for usage as 'industrial grade deinterlacer' (we use it for State broadcasting) so can run on CPUs like FranceBB's Xeons 56c/112th not very slow. For denoise our department currently like Topaz VEAI but it only accepts progressive and we have large interlaced BetacamSP and later archive.

Also not about MT and quality: Internal intra-frame MT (via AVSTP.dll) can make H-striping artifacts because each H-stripe processed in MAnalyse as complete frame so edge of frame border predictors are limited in quality. Also I not sure but overlapped blocks may not cover seams between H-stiped too. So for max quality only frame-based MT via AVS+ is recommended. I not use avstp.dll so it is batter to add mt=false to mvtools in QTGMC to be sure.
As I see mt for mvtools is controlled via
bomt = sh_GetUserGlobalIMTbool() somehow.

Also this 64x slower is not the only new possible mode - it is only sort of 'medium' performance/quality balance. The AreaMode of 1 with AMflags=1 is only +4 new search positions for each block while 16 and more positions possible even for small 8x8 block size. Offsets expected to be effective to blksize/2=4 for 8x8 and currently only offset of 2 used of 1,2,3,4 possible with 4 or 8 search positions with each offset, so max AreaMode load is +32 search positions for 8x8 and much more for 16x16 block size. It is about 32/4=8x slower. Though 16x16 block size is more stable and require less refining.

I think to make also some 'lighter' modes like pel=2 and no AreaMode for 16x16 blocks - it expected about 10x faster but quality may be visibly lower.

Update: With i5-9600K CPU it is not so slow - only about 6x times slower in comparison with QTGMC(preset="slow") with x264 running with preset=slow for h.264 transcoding. 7.5 fps with M_QTGMC and 45 fps with QTGMC.

[DTL2023]

Any video samples comparing the two?

Here is DV25 captured BetacamSP old recording https://drive.google.com/file/d/1Pc7vzWNc6KH_uX2zVTyaa0gxQSEJxK5l/view?usp=sharing . It has some weird chroma plane H-jumping (at some objects only ? and at one field) and I am not sure where it comes from. Maybe some defect of capturing.

Here is 2x upsized with SincLin2Resize (to show small details better on computer screens not supporting such long sinc kernels resize) processed with M_QTGMC - https://drive.google.com/file/d/1WBXDyDSrUHF2EVGvrghgGZ8qIAfXebvz/view?usp=sharing .

Most difference with QTGMC(preset="slow") is at fine details at fast moving objects.

All other versions with old/classic QTGMC or other deinterlacers anyone can create from source locally.

[dellsam34]

Thanks for the samples, I'm finding hard to see the difference without side by side comparison, but I think the slow speed of it is a deal breaker for me.

[DTL2023]

"without side by side comparison,"

You can run your typical workflow with QTGMC and use StackHorizontal() in AVS. I think of creating left-right old-new versions encode but I think users like to see full-screen run of a moving pictures sample and to estimate overal quality. The same is for industry experts quality evaluation - no side by side or frame interleaved comparisons (?). I tried to compare also with realtime hardware deinterlacing via NVIDIA Pascal-series card (via MPC_HC) - it looks much less detailed. But I think still some sharpnener is active in QTGMC with slow preset by default (?).

[i4004]

[Attachment 85092 - Click to enlarge]

Another "negative" of nnedi3 alone - it's not motion adaptive. It "blindly" processes everything. So in no motion scenes - where the image is actually progressive content - nnedi3 will degrade it (because it's a single field, not weaved 2 fields for full quality) . yadifmod2+nnedi3 will only slightly degrade it (yadifmod/yadifmod2 omit top and bottom rows, such as QTGMC border=false). QTGMC will be better (depending on the settings used), but bwdif should be almost perfect if it registers no motion

That was the reason for that "pause" at the beginning in the gif demo. Those first few frames have no motion. A perfect deinterlacer will weave() the 2 field to produce full quality image. QTGMC comes close, but very slightly degrades because of the additional processing . yadifmod+nnedi3 misses the top and bottom row (so does QTGMC default without border=true). Bwdif+nnedi3 is essentially perfect for the static sections, if it detects no motion correctly

But in motion, all of them will generally have more flickering artifacts more than QTGMC

bwdif + nnedi3 as edeint is generally better than yadifmod/yadifmod2 + nnedi3 as edeint . Bwdif alone is actually faster than yadif alone on most semi recent computers (with SSE2 and AVX) and produces higher quality - yadif and yadifmod are basically obsolete IMO, they can be safely replaced with bwdif for faster and higher qualtiy filtering

Of course, YMMV - different types of sources, scenes, content might react better to different deinterlacing algorithms.

(my bold)

case in point: i think no matter what you do you can't make those subtitles' edges look sharp in QTGMC.
via

clip = havsfunc.QTGMC(Input=clip, TR0=2, TR1=2, TR2=1, Rep0=1, Rep1=0, Rep2=4, DCT=5, ThSCD1=300, ThSCD2=110, SourceMatch=3, Lossless=2, Sharpness=0.1, Sbb=0, MatchPreset="slow", NoiseProcess=2, GrainRestore=0.0, NoiseRestore=0.4, NoisePreset="slow",StabilizeNoise=false, NoiseTR=0, NoiseDeint="bob")

(stolen from hybrid script and this post
https://forum.selur.net/thread-3429-post-19638.html#pid19638 seems a bit better than "placebo")
while bwdiff nails it, without nnedi3 for edeint, also in hybrid (vapoursynth).

mpeg2 source
https://www.mediafire.com/file/uo7qd5jftr8rryx/vhs_ba3_vhsi_NEW_LSF_trimmed.mpg/file

in image, i'm pointing to jaggy 'K' (in bwdiff image) as something good, because QTGMC "anti-aliased" it, ie it applied EDI for no good reason, it didn't preserve the original. also qtgmc with these settings is still doing some denoising.

previously in the thread, you discussed quality of tv deinterlacers. it depends on the brand of tv, but i believe sony (was?) best (i guess that's why i have 2 sony tvs), but prior to 2014 bravia3 and "x-reality" processor, sony was also utter garbage for deinterlacing, like other mfrs.
deint. is one part of the job, upscaling is another, i dunno how well sony does by the time SD image is blown to 4K, but i do know that QTGMC is easilly better than my sony tvs for this:
https://www.mediafire.com/file/b913kwcu79d5ucr/lacing_credits_0001.mpg/file
https://www.mediafire.com/file/wi9xifdgnw7mg4h/SAT1.FFS.2011.03.21.mpg/file (didee ripped this from broadcast)

feel free to test it, play back on tv those files, and anything you may conjure via preffered deinterlacing method of your own.
you probably won't find a tv that does justice to all 3 files i linked in this post, if you pay attention to both static subtitles in first clip, and motion (artefacts) in latter two.

i'm pretty sure sony doesn't do EDI, but it has some level of motion adaptivity as there's no "interline twitter" ie 25/30hz flicker (bobbing) at vertical edges that appear on just one field of video, like the subtitles in first clip i linked.
wouldn't it be interesting if sony just took some (older) avisynth deinterlacer and put it into silicon? hehe....

i'm investigating all of this to have an option to watch laced video deinterlaced on PC, in real-time, because i didn't bother with it upon archiving video, because that would just be wasting time.
but also because software playback beats hardware players on all fields, both quality and usability.
offcourse, PC connected to TV, that way you pick deinterlacer and scaler.....in that case TV is just a big monitor....

[Selur]

"while bwdiff nails it," have you tried using bwdif in qtgmc?

[i4004]

i just see bwdif in the context of 'edimode' here
http://avisynth.nl/index.php/QTGMC
in one sentence ("For EdiMode modes "BWDIF+NNEDI3" and "BWDIF+EEDI3"."), and not in following edimode syntax:

EdiMode (string) Interpolation method, from "NNEDI3", "NNEDI2", "NNEDI", "EEDI3+NNEDI3" (EEDI3 with sclip from NNEDI3), "EEDI3", "EEDI2", "Yadif", "TDeint" or "RepYadif" ("repaired" Yadif), anything else uses "Bob"

it seems it's havsfunc addition:

QTGMC 3.33
.......
EdiMode: Interpolation method, from "NNEDI3", "EEDI3+NNEDI3" (EEDI3 with sclip from NNEDI3), "EEDI3" or "Bwdif", anything else uses "Bob".

https://github.com/HomeOfVapourSynthEvolution/havsfunc/blob/master/havsfunc/havsfunc.py

best idea would be bwdif for static portions, and "usual" qtgmc (presets) for motion.
probably.
i didn't check bwdif vs. sat1 and lacing_credits clips....

will check, thanks for suggestion.

[Selur]

Also note that if you are using Hybrid, https://github.com/HomeOfVapourSynthEvolution/havsfunc/blob/master/havsfunc/havsfunc.py isn't the havsfunc version Hybrid used, but https://github.com/Selur/VapoursynthScriptsInHybrid/blob/master/havsfunc.py (those are not identical)

Cu Selur

[poisondeathray]

best idea would be bwdif for static portions, and "usual" qtgmc (presets) for motion.

Yes, and people have tried - various approaches use a motion mask with overlay. eg. QTGMC (some settings) for "base" layer, and a weaver like BWDIF / TDeint (tryweave=true) for the static overlay sections

The problem is creating a "perfect" motion detection mask. Things like small motions, compression artifacts, noise etc... can contaminate detection.

Newer high end TV's have this issue too ( including newer sets that use "AI" chips). There is often a few fields "glitched" before it "kicks" in


Another common problem, far worse for QTGMC is lower thirds/ HUD's with lots of motion underneath (e.g. video games, sports content with overlays). QTGMC will often warp and distort a large section around the motion underneath in that scenario. Using a "simple" deinterlacer if often better in that case, because the large distortions are very noticable

None of the deinterlacers are "perfect" (except for a weaver with 100% full frame, 100% static content), and there are pros/cons to each method

[Selur]

will check, thanks for suggestion.

btw. while testing: one can also use EdiExt with https://github.com/pifroggi/vs_deepdeinterlace, https://github.com/HolyWu/vs-mfdin or any other deinterlacer,..

Cu Selur

[i4004]

AI talk just reminds me of sony advertising blurb where they claimed video is checked against (huge) database and adjusted accordingly.
of course, those tvs look best when you turn off any processing setting you can, and the main difference between sony of that era and others sets was sony actually let you turn those things off completely (noise reductions etc.), while with other mfrs you always saw they're still doing it, even if you turn off those functions....

ai is next best thing (same as nanotubes or fuzzy logic some time ago) that will soon become history. it's a good yt clickbait, "AI upscaled".

as for testing, yes

clip = havsfunc.QTGMC(Input=clip, TR0=2, TR1=2, TR2=1, Rep0=1, Rep1=0, Rep2=4, DCT=5, ThSCD1=300, ThSCD2=110, SourceMatch=3, Lossless=2, Sharpness=0.1, Sbb=0, MatchPreset="slow", NoiseProcess=2, GrainRestore=0.0, NoiseRestore=0.4, NoisePreset="slow",StabilizeNoise=False, NoiseTR=0, NoiseDeint="bob", EdiMode="Bwdif")

produces result even a bit sharper than mere bwdif.

pot-player's 2 frame adaptive deint. mode also doesn't seem to be graphic-destructive as qtgmc with nnedi.

let me just quickly check what these sony x-reality pro(!!!) tvs are doing with "vhs_ba3_vhsi_NEW_LSF_trimmed.mpg/file":

interestingly, the older model shimmers few frames around scene-change (easilly visible on tv station's logo HRT2), but the new one doesn't. both advertised as x-reality pro.
both are preserving static graphics very well.

i'll probably compare the artefacts of pot player 2 frame, bwdif and sony tv deinterlacers next.

[taigi]

What could be your comments on GPT4.5 comment on this script?:
If processing time is not a concern and your goal is maximum achievable quality, detail preservation, and effective noise handling, here's my carefully-tuned recommendation:

Advanced QTGMC Configuration (Highest Quality, Slow Processing)
avisynth

QTGMC(TR0=2, TR1=2, TR2=3, Rep0=1, Rep1=1, Rep2=4,
\ DCT=5, ThSCD1=240, ThSCD2=100,
\ SourceMatch=3, Lossless=2, Sharpness=0.2, Sbb=1, MatchPreset="very slow",
\ NoiseProcess=2, GrainRestore=0.2, NoiseRestore=0.4, NoisePreset="slow",
\ StabilizeNoise=true, NoiseTR=2, NoiseDeint="bob")
Rationale for These Maximum-Quality Settings:
Temporal Radius (TR): Increased (TR2=3) for maximum accuracy and detail consistency across frames.
Repair (Rep) Modes: High-level repair (Rep2=4) ensures aggressive artifact correction at the cost of processing speed.
Source Matching (SourceMatch=3) and Lossless (Lossless=2): Highest setting for maximum detail retention.
DCT (DCT=5): Maximum frequency-domain accuracy for precise processing.
Scene Detection Thresholds: Slightly reduced (ThSCD1=240, ThSCD2=100) for improved scene-change detection accuracy.
Noise and Grain Restoration: GrainRestore=0.2, NoiseRestore=0.4, and temporal noise radius (NoiseTR=2) maintain natural textures while controlling noise effectively.
Sharpness Increased (0.2): Subtle, noticeable sharpening enhancement.
StabilizeNoise and Borders (Sbb=1) Enabled: Ensures stable noise patterns and clean frame edges.
This script is optimized solely for achieving the highest possible visual quality and accuracy, disregarding processing time entirely.

[i4004]

my comment is that chatgpt just found some discussions on selur's or doom9 or this forum...heh....
my suggestion is bwdif for stuff with lots of static shots and/or graphics, and qtgmc for the rest: for example camcorder laced footage has no graphics and it's usually rather non-station, not to say "pretty shaky"
as for noise, nothing, preserve it or do some mild denoising, mdegrain2 or 3 from mvtools....

to reply to myself:

i'll probably compare the artefacts of pot player 2 frame, bwdif and sony tv deinterlacers next.

not much difference here, sony obviously used some variation of bwdif or something simillar. but new sony tv looks a bit better than old one. less flicker, less jaggy etc.

interesting part is handling of inputs: scart input on older sony tv is crap.
hdmi inputs on both are visibly worse than playback from flash usb stick.
it doesn't matter what you're inputting to tv, 576i or 1080i, it looks bad.
so that's interesting: it's either that the device i'm playing it back from is crappy (cheap dvb-t2 tuner) or tv has two separate paths for processing, one for inputs (scart, hdmi), another for local media playback and its internal tv-tuner. ie not the same scaler and deinterlacer is used in both cases.
or, in other words, they can't do good processing on uncompressed video. because both scart input and hdmi will be uncompressed.

[Joscraft_05]

I myself do not like QTGMC much – at default settings.

I spent... I don't know... years tweaking and refining it to find settings that make it close to transparent for my sources. And I pretty much suceeded.

You said if you make QTGMC keep the grain, the grain looks too fine and artificial. I had this problem as well. The key setting here is NoiseDeint="bob". And there are more which may not even seem like they are (as a side effect) related to noise (especially the TR and Rep settings).

The reason QTGMC is so "destructive" is due to the way the core works. It basically works like this: first it does a dumb bob-deinterlace (with or without more intelligent spatial interpolation such as NNEDI), then temporally blurs the differences in bob-shimmer away and uses motion compensation to detect where to do that and where not to avoid a motion blur effect. That was the original concept written by Didée and named TempGaussMC. It's a bob-shimmer remover. As you can imagine, the side effect of this approach is rather strong denoising. But luckily the script evolved dramatically over the years and allows for the side effects to be compensated – although not too many peoply seem to be offended by those.


Here is my honest recommendation of settings for keeping grain and making the deinterlacing quite transparent to my eyes.
Even if you are happy with NNEDI3 alone now, I would like to hear your thoughts on these settings.

QTGMC(TR0=2, TR1=2, TR2=1, Rep0=1, Rep1=0, Rep2=4,
\ DCT=5, ThSCD1=300, ThSCD2=110,
\ SourceMatch=3, Lossless=2, Sharpness=0.1, Sbb=0, MatchPreset="slow",
\ NoiseProcess=2, GrainRestore=0.0, NoiseRestore=0.4, NoisePreset="slow",
\ StabilizeNoise=false, NoiseTR=0, NoiseDeint="bob")

Here my results with my Hi8 XR video wich i captured with a Digital 8 camera to my PC and using Staxrip program, i compare the videos, the left is your code and the right is with the default settings that Staxrip applies:


[Attachment 87069 - Click to enlarge]


[Attachment 87070 - Click to enlarge]

[lordsmurf]

Thanks for the samples, I'm finding hard to see the difference without side by side comparison, but I think the slow speed of it is a deal breaker for me.

This is one of those weird rabbit holes.

A stupid assertion was made (from an OP that hit-and-run posted this years ago), and few/none have ever defended it (and rightly so). It reads like an amateur ad: "Why are people still drinking Coca-Cola? (Drink Pepsi instead!)"

However, some are giving it "devil's advocate" treatment. And yet, they don't see the forest through the trees.

- On one hand, most people are (sadly) butchering video with junk hardware, junk software, and Youtube.
- On the other hand, you have some people seeking better quality deinterlacing, and that should land at QTGMC. This thread isn't helping those folks.
- On the 3rd weird inhuman hand, you get this thread.

I think most of us have our favorite custom settings for QTGMC, and I have settings for scenarios. But I still largely default to the presets of Faster, Medium, and Slower.

[Sharc]

I think most of us have our favorite custom settings for QTGMC, ....

Agree. And there is still the option NOT to deinterlace unless there is a good (technical) reason to do so, like vertical resizing. The TV/player deinterlacers may do a nearly equivalent or visually more pleasing job than some borked QTGMC tweaks with its nearly 100 parameters