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

[lollo]

The underlying problem is interlace in the first place

so true,...

Interlacing was a very clever way to reduce bandwidth in the old days, and it worked very well on CRT, because the persistance of the image on the screen. In modern days is a source of problems.

Because poisondeathray is on board, I should have mentioned his contribution also to the question of using SeparateFields + Select even/odd on temporal filtering. Sorry pdr, I lost your comments in my cut & paste:

https://forum.doom9.org/showthread.php?p=1691595#post1691595

Even if you group even/odd separate fields, and filter that way, then interleave and weave - then use of temporal filters is technically "wrong" and less effective, because in bobbed sequence, you will be filtering 0,2,4,6... separately from 1,3,5,7.... ie. there will be no temporal filtering between even and odd, only within

[sebastiaaan]

NNEDI3 is a single field deinterlacer only . When used alone for double rate deinterlacing, NNEDI3 does not compensate for the odd/even field ofset . You can end up with up/down/up/down motion (it might not be as noticable with a shaky camera, or lower quality/soft video). On adjacent frames, lines don't match up between objects - this one of the causes for NNEDI3 temporal aliasing and flickering artifacts. Similarly, NNEDI3 doesn't address the top/bottom frame border edges either - there is missing data on either the top or bottom frame edges on adjacent frames (because of even/odd scan lines) - QTGMC with border=true switch (not the default setting) compensates for that.


[Attachment 62572 - Click to enlarge]

Interesting! And you are right, I just checked and there is in fact some of this up/down/up/down motion, you can see it e.g. when the opening credits play and on some objects. However it's very minor and doesn't really bother me too much, in fact I haven't noticed it before you told me about it. What's more annoying to me is QTGMC's motion compensation (I think is the right term for it?) like when the camera and objects/persons are moving and the grain/noise is behaving very weird in that area, it kind of stays at the same place when it should in fact move (like I described in my original post it acts like a magnet). I'm trying Skiller's (how can I tag a user?) settings right now, I just need to do a full encode first to actually determine whether it's an improvement or not (11.45fps on my 9900K). But from my sample clip (15 seconds) it looks cleaner overall than NNEDI3, less blocky and a bit softer but sometimes details get a little bit lost.

Since NNEDI3 is an intra-field only deinterlacer, is there any alternative besides using QTGMC that is not intra-field only (e.g. EEDI2, etc. sometimes there's no word on it)? Does yadifmod2+NNEDI3 provide better results than just NNEDI3? I mean technically I could just do single rate deinterlacing to avoid this up/down motion, right? I prefer bobbing though, as it preserves the original framerate and looks better for PAL content.

And this might be a dumb question but it is okay that my output file size will be higher than the original one (about 950 MB interlaced source resulting in a 1.1GB 50fps progressive output file with near-lossless encoding settings), since I'm basically adding 2 times the information, right? I don't care about HDD space anyways..

[poisondeathray]

I mean technically I could just do single rate deinterlacing to avoid this up/down motion, right? I prefer bobbing though, as it preserves the original framerate and looks better for PAL content.

Yes, for single rate - 1/2 the information is discarded motion is less smooth. Either all even fields, or all odd fields, not both (ie. all "up", or all "down") . "Bobbing" doubles the original framerate (it does not preserve it), it retains the number of original motion samples. 25 frames per second interlaced has 50 fields per second. 50 moments in time represented. All motion samples from individual fields are retained

Does yadifmod2+NNEDI3 provide better results than just NNEDI3?

In terms of what? the up/down ? Partially. The difference is the whole image isn't filtered with NNEDI3 when used with yadifmod as edeint - Only certain areas are.

yadifmod/yadifmod2 + nnedi3 will still have some partial up/down motion and flicker during motion (less bad than nnedi3 alone), but will be better during static sections (but it doesn't process some pixels, such as the top and bottom rows), and have less edge enhancement (nnedi3 causes edge enhancement artifacts, a haloing effect).

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.

What's more annoying to me is QTGMC's motion compensation (I think is the right term for it?) like when the camera and objects/persons are moving and the grain/noise is behaving very weird in that area, it kind of stays at the same place when it should in fact move (like I described in my original post it acts like a magnet).

Yes, stuck grain, blocks moving in wrong direction, temporal artifacts

But those types of can also be partially compounded from your encoding settings. More common with certain codecs like HEVC with certain settings. You can rule that out by using lossless encoding

is there any alternative besides using QTGMC that is not intra-field only

Any temporal deinterlacer is not considered "intrafield". eg. mcbob, mvbob, a few others. Temporal deinterlacers are predisposed to similar negatives as any temporal filtering - ghosting, smoothing/blurring etc...the "haloing" around objects, the mvtools2 "warping" of areas, etc.... That smoothing over of bob shimmer comes at a price

Pros/cons to any choice you make. If you dislike the QTGMC side effects , and cannot find QTGMC settings that get the results you want, I would also try bwdif with nnedi3 as edeint

And this might be a dumb question but it is okay that my output file size will be higher than the original one (about 950 MB interlaced source resulting in a 1.1GB 50fps progressive output file with near-lossless encoding settings), since I'm basically adding 2 times the information, right? I don't care about HDD space anyways..

Not really comparable ; you're comparing different generations. So how "near lossless"? At some point it should be several times larger than the original. It would be slightly more relevant if you encoded interlaced then compared that. But it's a bit tricky too - because if you're using CRF rate control, that algorithm autoscales the rate factor with the frame rate. 25fps interlaced is technically lower than 50fps progressive

Many factors to consider - It also depends on the encoding settings and the content. If you use longer GOP, more b-frames, etc.. that can help with compression

[killerteengohan]

You can alter some settings to make it much less destructive. The default settings really suck, and are indeed very destructive.

QTGMC(preset="slow", matchpreset="slow", matchpreset2="slow", sourcematch=3, tr1=2, tr2=1, NoiseTR=2, sharpness=0.1)

I only really use QTGMC on PAL sources, or the very few NTSC sources that TIVTC cannot get correctly. There's a better way to do most NTSC sources.

tfm(order=-1, slow=2, cthresh=8, clip2=QTGMC(preset="slow", matchpreset="slow", matchpreset2="slow", FPSDivisor=2, sourcematch=3, tr1=2, tr2=1, NoiseTR=2, sharpness=0.1))

[defbiz]

What is more, unless you are resizing, you don't need to do it, and your TV set will do a very good job.

Most TV sets either standard bob, interpolate or decomb. There's no real-time smart deinterlacing, as it takes too much processing power. What it can do though is adjust color balance and make it seem like it's higher quality/less blocky.

[rrats]

What is more, unless you are resizing, you don't need to do it, and your TV set will do a very good job.

Most TV sets either standard bob, interpolate or decomb. There's no real-time smart deinterlacing, as it takes too much processing power. What it can do though is adjust color balance and make it seem like it's higher quality/less blocky.

First, the hell is a decomb?

Second of all, you are wrong about TV's not having smart deinterlace. If computers from years ago were able to do the SmoothDeinterlace in real time then I don't see why modern TV's wouldn't

[cjdavis83]

You can alter some settings to make it much less destructive. The default settings really suck, and are indeed very destructive.

QTGMC(preset="slow", matchpreset="slow", matchpreset2="slow", sourcematch=3, tr1=2, tr2=1, NoiseTR=2, sharpness=0.1)

I only really use QTGMC on PAL sources, or the very few NTSC sources that TIVTC cannot get correctly. There's a better way to do most NTSC sources.

tfm(order=-1, slow=2, cthresh=8, clip2=QTGMC(preset="slow", matchpreset="slow", matchpreset2="slow", FPSDivisor=2, sourcematch=3, tr1=2, tr2=1, NoiseTR=2, sharpness=0.1))

Are these optimal settings for NTSC video/tape source (Not telecined)?

[Master Tape]

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")

I tried your script and like the image quality, but unfortunately it has introduced some very strange artifacts.

[davexnet]

I tried your script and like the image quality, but unfortunately it has introduced some very strange artifacts.

Perhaps you should post your complete script

[Master Tape]

I tried your script and like the image quality, but unfortunately it has introduced some very strange artifacts.

Perhaps you should post your complete script

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("QTGMC", 2)
AVISource("F:\Video Files\Video.avi")
AssumeTFF()
AssumeFPS(25)
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")
Crop(0,0,-0,-6)
Prefetch(5)

[Sharc]

I tried your script and like the image quality, but unfortunately it has introduced some very strange artifacts.

Perhaps you should post your complete script

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("QTGMC", 2)
AVISource("F:\Video Files\Video.avi")
AssumeTFF()
AssumeFPS(25)
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")
Crop(0,0,-0,-6)
Prefetch(5)

I don't get these artifacts with the script

AVISource("Original Source.avi")
AssumeTFF()
AssumeFPS(25)
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")
Crop(0,0,-0,-6)

Which Avisynth/QTGMC/x264 versions are you using?

[Master Tape]

I tried your script and like the image quality, but unfortunately it has introduced some very strange artifacts.

Perhaps you should post your complete script

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("QTGMC", 2)
AVISource("F:\Video Files\Video.avi")
AssumeTFF()
AssumeFPS(25)
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")
Crop(0,0,-0,-6)
Prefetch(5)

I don't get these artifacts with the script

AVISource("Original Source.avi")
AssumeTFF()
AssumeFPS(25)
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")
Crop(0,0,-0,-6)

Which Avisynth/QTGMC/x264 versions are you using?

AviSynth+ v3.7.2
QTGMC 3.383s
libx264 via FFMPEG

All 64-bit.

[defbiz]

QTGMC at its default settings makes all of my videos with heavy grain look like crumpled cardboard.

[Selur]

Out of curiosity, can someone post before after images of such an occurrence? (I normally deal with content that doesn't have much noise and use QTGMC in mode 'Fast',...)

Cu Selur

[wright96d]

If you want to disable the noise reduction and sharpening, then disable the noise reduction and sharpening. This is what I use and it produces a near flawless output.

SetFilterMTMode("AVISource", 3)
SetFilterMTMode("QTGMC", MT_MULTI_INSTANCE)
AVISource("$inputFile")
AssumeTFF
QTGMC(Preset="Slower", EdiThreads=4, NoiseProcess=0, Sharpness=0, SourceMatch=3, Lossless=2)
ConverttoYV12
Prefetch(16)

[DTL2023]

For SD sources (sharp enough like BetacamSP or DVD) it may be better to keep blocksize of 8x8. At least using RefineMotion from Dogway version of QTGMC or setup its manually with some not very poor search params:

preset="slow", thSAD2=150, BlockSize=8, SubPel=2, Search=3, SearchParam=2, Overlap=4, ChromaMotion=true, GlobalMotion=true, TrueMotion=true, TR2=1

Also I see the thSAD2 for final denoise looks like not good autoscaled between blocksize of 16 and blocksize of 8 so it may be required to set it to lower value (of default 256) to keep about the same noisereduction/blurring.

Blocksize of 8x8 can better track small details at complex moving areas but may fail to keep details in some big areas and it run significantly slower. Also subpel=4 may be tested by more die-hard perfectionists.

Also with the next -a.30 release of post-2.7.45 mvtools there will be avaialble even more slower modes of MVs refining like "Super Slow" and "Ultra Slow" (1,2,3...) with AreaMode MVs averaging from several full-searches of block in some surrounding area. With performance penalty from several times to 10x and more. While still keeping >1 fps rate at CPUs like i5-9600K (6 real cores no HT) at PAL SD source.

[Skiller]

If you want to disable the noise reduction and sharpening, then disable the noise reduction and sharpening.

Like I explained in post #6, the noise reduction in an inherent side effect of how the core of QTGMC works. There is no simple switch to turn it off. SourceMatch and Lossless settings help, but there is much more to it.

[wright96d]

If you want to disable the noise reduction and sharpening, then disable the noise reduction and sharpening.

Like I explained in post #6, the noise reduction in an inherent side effect of how the core of QTGMC works. There is no simple switch to turn it off. SourceMatch and Lossless settings help, but there is much more to it.

You're wrong. NoiseProcess=0 turns it off completely. It's called bypass mode for a reason. If there is some amount of noise reduction remaining, it's completely imperceptible.

[Selur]

Isn't some noise reduction unavoidable (!and wanted!) when bobbing due to the nature of interpolating/upscaling (call it what you like) from fields to frames?

[wright96d]

Isn't some noise reduction unavoidable (!and wanted!) when bobbing due to the nature of interpolating/upscaling (call it what you like) from fields to frames?

Interpolated noise is still noise.

[Selur]

Interpolated noise is still noise.

Different noise. And if you have once pixel noise/grain you either lose some or gain some depending on how your interpolation method works.
I like some control over that and still think that noise reduction unavoidable (!and wanted!), but it's probably something like personal taste.

If you want simple bobbing, use Bob().

[lollo]

If you want to disable the noise reduction and sharpening, then disable the noise reduction and sharpening.

Like I explained in post #6, the noise reduction in an inherent side effect of how the core of QTGMC works. There is no simple switch to turn it off. SourceMatch and Lossless settings help, but there is much more to it.

You're wrong. NoiseProcess=0 turns it off completely. It's called bypass mode for a reason. If there is some amount of noise reduction remaining, it's completely imperceptible.

Sure.

lossless bob versus QTGMC: https://imgsli.com/MjYxMDcx
lossless bob versus QTGMC(NoiseProcess=0): https://imgsli.com/MjYxMDcy
and finally QTGMC versus QTGMC(NoiseProcess=0): https://imgsli.com/MjYxMDcz

compare with metrics image:


compare with metrics movie:
compare.avi

[wright96d]

If you want to disable the noise reduction and sharpening, then disable the noise reduction and sharpening.

Like I explained in post #6, the noise reduction in an inherent side effect of how the core of QTGMC works. There is no simple switch to turn it off. SourceMatch and Lossless settings help, but there is much more to it.

You're wrong. NoiseProcess=0 turns it off completely. It's called bypass mode for a reason. If there is some amount of noise reduction remaining, it's completely imperceptible.

Sure.

lossless bob versus QTGMC: https://imgsli.com/MjYxMDcx
lossless bob versus QTGMC(NoiseProcess=0): https://imgsli.com/MjYxMDcy
and finally QTGMC versus QTGMC(NoiseProcess=0): https://imgsli.com/MjYxMDcz

compare with metrics image:

[Attachment 78808 - Click to enlarge]

compare with metrics movie:

[Attachment 78809 - Click to enlarge]

1. Then what's the point of the bypass mode? It's not my fault that the guide is wrong.

2. I suppose that means SourceMatch and Lossless are the more important settings. I did a test and excluding them produces a horrible quality output.

3. That junk in your example is more field to field flicker than noise.

4. Can you share the source file?

[lollo]

1. Then what's the point of the bypass mode? It's not my fault that the guide is wrong.

RTFM again, check the source code (QTGMC.avsi) and think twice before saying to knowledgeable users like Skillers that they are wrong

2. I suppose that means SourceMatch and Lossless are the more important settings. I did a test and excluding them produces a horrible quality output.

Redo your test

3. That junk in your example is more field to field flicker than noise.

It was chosen in purpose to highlight the outcomes; in addition, the noise intra-frame and inter-frame is well there.

4. Can you share the source file?

here: https://drive.google.com/file/d/1_Ckp3NJzJ1U39RO0m_V_YLiIoUkwaymZ/view?usp=sharing

let us know your findings

[wright96d]

Redo your test

What do you mean? Should I expect a better output without source match and lossless?

[Selur]

There are no setting that will always produce nice results when deinterlacing. Depending on the source, you should adjust your settings,.. this is true for basically any filter and script.

[Sharc]

There are no setting that will always produce nice results when deinterlacing. Depending on the source, you should adjust your settings,.. this is true for basically any filter and script.

There's a reason why QTGMC has nearly 100 parameters

[lollo]

Selur and Sharc said all!

[DTL2023]

First release of M_QTGMC() . https://github.com/DTL2020/QTGMC/releases/tag/m_0.1 (M is sort of Monster-QTGMC)

Zero params .

It opens Super and Ultra Slow processing. Release includes required new .dlls - release for test of mvtools2 2.8.0-a.00 and new created plugin MostDiffVal (used in M_QTGMC). Also some version of QTGMC2() based on Dogway version v3.384s .

With current settings (internal) it attempt to create sharpest possible - so most of noise also keeping in.

M_QTGMC is aggregator of 4 calls to QTGMC2 with blocksizes of 8x8 and 16x16 and PP on (for preset="slow") and off. Also each calls of QTGMC2() uses new AreaMode (with not very high AM params - only +4 additional points of search) of MVs internal refining in MAnalyse and new predictor modes for TrueMotion and for median predictor.

Total performance is expected about 0.1 of classic QTGMC(preset='slow') or maybe a bit higher. (Update: at Core2Duo E7500: 11 vs 0.17 fps = 64x times slower.)

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

Most of details saving expected at fast moving subjects. Also may add something good to old noised BetacamSP sources.

[dellsam34]

How would someone use this instead of the old one? Just install it and it would remove the old QTGMC? Any video samples comparing the two?