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 (?).