QTGMC Deinterlacing Script (v3.32)

[William.Lemos.BR]

Please, be pacient with my english, I'm from Brazil...

First of all, I'd like to say your filter is simply wonderful!! I've been testing other deinterlace methods (for years) and what you achieved here is very close to perfet!
Actually I'm not used to AVISynth but the reason I started to try it was exactly how impressed I was by the QTGMC's results. So, after some strugle to learn I managed to run it under VirtualDUb.

I became excited when I saw the new version here (specially for the speed tunnings). So I downloaded it and tried to test, but got the messege:
"Avisynth open failure:
The script's return value was not a video clip"

The strange is that I'm using the new QTGMC exactly the same way, and the previous version works fine! I double-checked if I have all the needed dlls (and last versions) but everything looks ok. I'm lost here.

Could you help me somehow?

Since now I thank you for the attention and, specially, for the EXCELENT work you've done!!

[-Vit-]

Originally Posted by William.Lemos.BR

So I downloaded it and tried to test, but got the messege:
"Avisynth open failure:
The script's return value was not a video clip"

Please could you post the exact script you used to get this error message.

[William.Lemos.BR]

Originally Posted by -Vit-

Please could you post the exact script you used to get this error message.

Thanks, -Vit-, for the reply!

As a matter of fact, my script is quite simple. I've just replaced the previous code by the new one. By the way, my OS is Windows 7 64 bits (but I'm using the 32 bits dlls and VirtualDUb). I'm quite sure the problem has nothing to do with this, 'cause everything runs fine, but I'm not an expert so... just in case.

PS: Yeah, I'm a noobie, but I'm not trying to open a .txt in VirtualDub. I added the .txt extention so I could upload the file,

There it is...

[poisondeathray]

Instead of waiting for a mod to approve your attachment, you can copy & paste the avs script here in text

Also, if you had screenshots or files you can use a free image host e.g. mediafire.com, sendspace.com

[Didée]

Are you using the latest version, v2.51? The previous versions "2.4r" and "2.47r" seemed to have a mistake in the showsettings section - according to the syntax highlighting of my editor, there was a " (quotation mark) too much (or one missing), which might cause the script to blow. (Though I didn't try).
The most recent version v2.51 seems to be correct. (Again, only judging by the syntax highlighting).

[William.Lemos.BR]

Originally Posted by poisondeathray

Instead of waiting for a mod to approve your attachment, you can copy & paste the avs script here in text

Also, if you had screenshots or files you can use a free image host e.g. mediafire.com, sendspace.com

Thanks for the suggestion, Poisondeathray! There it is the link with the .avs (I didn't paste the hole script because it is too big):

http://www.mediafire.com/?31dllf6310x3ds3

Originally Posted by Didée

Are you using the latest version, v2.51?

Hi, Didée!

Yeah, I'm using the v2.51 that was downloaded in this very thread.

[-Vit-]

You've pasted the entire QTGMC script at the end of your script. This is unnecessary and causes a problem because of the global variable in QTGMC. Do this instead:
- Save QTGMC in a file on its own called "QTGMC2.51.avsi".
- Put that file in your Avisynth/plugins folder. Delete any other QTGMC files in there.
- Then QTGMC will "autoload" and your script is just this:

AviSource ("d:\VIDEO_720x480_1MIN_uncompressed.avi")

ConvertToYV12(interlaced=true)

QTGMC( Preset="Slower", EdiMode="NNEDI3" )

Or you can use the Import statement if you don't want to use autoload for some reason.

____

[The syntax was off in the earlier versions around the ShowSettings part but the Avisynth parser seemed to cope anyway.]

[William.Lemos.BR]

My God!!! How stupid I was!!!! hehehehehe

I'm going to fix it right now. Thank you VERY MUCH, for your help and pacience!

I'm still at the beggining of my learning but who knows someday I can retribute your help...

EDITED:

I've just tested it and WORKS LIKE A CHARM!! Thank you, again!
Now I'm going to have fun all night long...

[Gavino]

Originally Posted by -Vit-

You've pasted the entire QTGMC script at the end of your script. This is unnecessary and causes a problem because of the global variable in QTGMC.

Is there a good reason for the variable (Yadifpath) being global? It could just as easily be declared inside the QTGMC function (eg on the first line). Then such problems would not occur.

[-Vit-]

Originally Posted by Gavino

Is there a good reason for the variable (Yadifpath) being global?

Maybe there was a reason once, but I don't see it now... like much in life.
I'll shift it in the next release.

[SilaSurfer]

Hello -Vit-. First of all great work. I was wondering something is your script meant for pure progressive sources like Dvd's, if so probably for "denoising and sharpening/keeping detail" purposes wright?

[-Vit-]

Originally Posted by SilaSurfer

Hello -Vit-. First of all great work. I was wondering something is your script meant for pure progressive sources like Dvd's, if so probably for "denoising and sharpening/keeping detail" purposes wright?

QTGMC is a deinterlacer: it's for converting interlaced content into progressive content.
DVDs are usually interlaced, not progressive, so QTGMC is an appropriate tool.

QTGMC can accept pure progressive content with the InputType setting:

QTGMC( Preset="Slow", InputType=1 )

It also has settings for retouching badly-deinterlaced material (progressive, but with strong bob-shimmer / interlacing artefacts remaining):

QTGMC( Preset="Slow", InputType=2 ) # or 3

Regardless of input type, QTGMC strongly denoises and sharpens by default. Although you can adjust how much as necessary.
However, if you only want to denoise or sharpen some progressive content, you're better using scripts/plugins designed for that. QTGMC is really only helpful if you have interlaced content or progressive content with some shimmer you want to remove as well.

[Didée]

Originally Posted by -Vit-

DVDs are usually interlaced, not progressive, so QTGMC is an appropriate tool.

Depends on content, and where on the blue ball you're located. From the plentyness of my (PAL) DVDs, the vast majority has progressive content. Only very few have interleced content.

QTGMC can accept pure progressive content with the InputType setting

BTW, did you adjust the temporal averaging for this? For progressiv input, the whole "gaussian" thingy does not make all that much sense anymore.
(And BTW, the commented explanations about "gaussian" averaging are not good, they're almost wrong. At least, they are misleading and don't clarify the technical reason for using gaussian weights.) *)

The bigger deal would be to come up with a temporal straightening that works correctly for both interlaced and progressive sequences, i.e. for sources that contain both types of sequences.

Somehow, the real improvements hardly ever happen in modded spinoffs ...

- - - - - - -

*) Why gaussian averaging?

TGMC doesn't care for static sections. It assumes everything is moving. (Or: everything is static, due to MVTools.)

Imagine a perfectly-static thin line that is dumb-bobbed:

input pixel sequence (temporal): .... - 30 - 120 - 30 - 120 - 30 - 120 - 30 - .....


Now do a normal temporal average with 1-1-1 weighting:

resulting sequence: .... - 90 - 60 - 90 - 60 - 90 - 60 - 90 - ...

Result: not only the sequence is still flickering after the averaging. Worse, the flicker has been inversed! Up-down-up has become down-up-down!


Now, do a gaussian temporal average with 1-2-1 weighting:

resulting sequence: .... - 75 - 75 - 75 - 75 - 75 - 75 - 75 - ....

Result: stable. period.


The reason for using temporal gaussian is simply this:

Traditional 1-1-1 averaging will push the strobing pattern into inversion.
Gaussian 1-2-1 averaging is the [only] mathematically correct weighting to cancel-out the bob strobing.

Not more, not less, end of story. A simple, but well grounded mathematical reasoning.


- - - - - - -

This one is simply wrong:

# Spatially gaussian blur (and tweak) motion search clip for more stable motion vectors - removing noise makes features easier to track

This part is not about noise, and not about stable motion vectors. These issues already have been addressed previously, by the temporal filter.

What this section does is: reduction of the amplitude of the "signal peaks" of all prominent detail.

MVTools uses safe-guarding by SAD (or SSD). Big SAD -> do nothing. In traditional denoising, this avoids obvious artifacts where the motionsearch failed.

In particular, SAD is generally big around prominent detail. For general denoising this means that the very edges usually get almost no filtering. (!)
But in TGMC, the very edges are the main target of all filtering. For TGMC it is not acceptable that MDegrain "goes NOP" on edges. But, simply using insanely-high thSAD is not good either: this would lose the ability to reckognize bad motion estimation.
Therefore, TGMC does it the other way round. Instead of practically disabling the SAD concept, it "smallifies" the edges so that they don't produce such big SAD values anymore. This way, the error-reckognition-by-SAD stays at least partly intact.

And that's a completely different story, compared to "removing noise makes features easier to track" ...


A (good) explanation surely is better than not explaining.

But - not explaining surely is better than giving a wrong explanation.

[-Vit-]

Ah! Finally some comment, Didee! Appreciated.

As I noted from the start, I commented for myself not for the wider world. I wanted to mod the script but it offered very limited explanations so it was a reverse engineering task and commentary helped me wade through it. The explanations evolved from deduction and experimentation. Inevitable that would lead to some misleading descriptions. I didn't originally intend to release this script so I wasn't concerned.

I toyed with the idea of deleting the comments before release but I disagree with your premise: I believe misleading comments are much better than none when the author is around to correct them. How else to get commented TGMC?

Your explanation regarding the two Gaussian averages makes perfect sense and is very welcome, thanks. I will update the commentary on those sections for the next release. If you notice anything else, please advise.

I didn't adjust the temporal work for progressive - I'll update the first temporal average code as appropriate. I'm not really interested in dealing with mixed sources.

[cretindesalpes]

The word "gaussian" is probably misleading too. If I understood correctly the concept, the real strategy for the coefficient choice is :

• kill the component at the Nyquist frequency (bob flickering),
• Preserve as much content as possible, especially the constant component,
• and give more weight to the center frames, given their higher probability of validity after MC in the general case (oh statistics... now this may be a reason to wave the "gaussian" word !)

[-Vit-]

Originally Posted by cretindesalpes

The word "gaussian" is probably misleading too. If I understood correctly the concept, the real strategy for the coefficient choice is :

• kill the component at the Nyquist frequency (bob flickering),
• Preserve as much content as possible, especially the constant component,
• and give more weight to the center frames, given their higher probability of validity after MC in the general case (oh statistics... now this may be a reason to wave the "gaussian" word !)

I only identified the last point in the original commentary. I had queried Didee to see if that was at least part of the rationale - thanks for the confirmation that I didn't completely miss the point there

What I did miss was the fact that the temporal coefficients sum to give equal weight overall to even and odd frames (removing the Nyquist frequency). Leaving just one possible kernel for temporal radius 1 (1:2:1), and a constrained set of possibilities for radius 2 (e.g. 2:3:2:3:2, 1:3:4:3:1 or 1:4:6:4:1) from which a kernel is chosen that favors the central frame.

[aegisofrime]

Ok, so for the less technically inclined among us (myself especially):

Is it merely the comments that are wrong, or is the progressive input algorithm wrong as well? Because I have been finding that progressive input seems to have little effect on the results :/

[SilaSurfer]

Thanks -Vit- for the info. I will use QTGMC if I encounter any interlaced DVDs or videos in the future.

Didée
Just wanted to say Thank You for the past (IIP, LimitedSharpen, SeeSaw, 6of9 CQM...) and future if you have some plans. You're like Albert Einstein in video encoding world.

[Didée]

aegisofrime: Yepp, I was only nagging about some comments giving rather poor explanation. (And I have one more, below.) *)
No technical bugs involved.

Regarding the "progressive mode(s)" ... there's nothing wrong about them. Just that they are supposed to help only very little.
(If 50% of the original input data is already missing, you can't use them to improve the remaining 50% that you have ... or to even *judge* the remaining half. Hence, consequentially, there's not that awfully much improvement to expect.)

Regarding different kernels ... well, the 1:3:4:3:1 one I had tried already, but there was hardly any difference.
Arguments:
a) if the input data fits the theoretical model, none of those kernels is better than the gaussian kernel.
b) if the input data does not fit the theoretical model (e.g.: bad motion matches), then the gaussian kernel does the least harm. The other kernels would include more potentially-bad data.
_______

*) Nagging ... ... about mt_inflate -vs- TGMC_inflate

First off, TGMC_in/deflate shouldn't be necessary anymore. This workaround was much faster than the C-routines of previous masktools. Now that Manao has asm'ed the XXflate filter, it's slightly slower. (thumb's values: old: 79 fps / TGMC_xxflate: 510 (750) fps / new masktools: 950 fps)
Now, one could put the original filters back in, since they are even faster. However ... the difference of the original workaround was noticeable. But if the even-faster original are put back in, you might sleep better, but you won't notice any difference.

In any case ... -Vit- had written that TGMC_xxflate would not do the same operation as the original masktools filters. That's mostly incorrect, it is the same operation. (Except a tiny difference.)

The first thing being wrong is ... the description in MaskTools' documentation. We read:

mt_xxflate : It computes a local average by taking into account only the neighbourgh whose value is higher/lower than the pixel.

Short, grippy, and wrong. If this was the case, then xxflate would be almost the same as xxpand, in many cases.

To my knowledge, xxflate does this: compute the average of all eight neighbor pixels, then use that value only if it is darker than the original pixel (deflate), resp. if it is brighter than the original pixel (inflate).

And that's exactly what TGMC_xxflate is doing. Only difference: it uses RemoveGrain(20), i.e. computes the average of all nine pixels. To exactly mimick the masktools filter, it should use RemoveGrain(19). (which is also faster again, see thumb's values above).

Put in Removegrain(19), build a 10-fold inflate by both mt_inflate and TGMC_inflate, then look at the difference between them: There will be almost none ...
(If any, it is because RemoveGrain and masktools use different code implementations for averaging. I.e., it's only rounding differences.)

[-Vit-]

Originally Posted by Didée

-Vit- had written that TGMC_xxflate would not do the same operation as the original masktools filters. That's mostly incorrect, it is the same operation. (Except a tiny difference.)

That nag is a little unfair . My comment merely asserts that TGMC_xxflate is not "equivalent" to mt_xxflate, which is correct: TGMC_xxflate has a less strong effect. However, it is interesting to learn that the underlying operation is so similar.

@aegisofrime: Progressive input works, but has limited use - it is not a panacea. Maybe there are tweaks to be made, but any improvements will be tiny.

And on that point, I'm not seeing why the existing binomial smoothing kernels (QTBMC...?) are inappropriate for a progressive pre-filter. I was under the impression that a gaussian was at least a fair pre-filter. It seems convenient mathematical fate that a binomial kernel is both a good gauss approximation and also reduces Nyquist to 0 with its odd/even properties. But perhaps it's more complex than that...