QTGMC Deinterlacing Script (v3.32)

[dansrfe]

That's true^. btw what purpose does the "lossless" variable have? Since I'm encoding to a lossless format, be it megui pre-render, lagarith, or even huffyuv what does QTGMC's lossless do?

[-Vit-]

That's true^. btw what purpose does the "lossless" variable have? Since I'm encoding to a lossless format, be it megui pre-render, lagarith, or even huffyuv what does QTGMC's lossless do?
Yeah, I suppose I didn't explain it clearly anywhere. I'll add this info to the OP:

(Q)TGMC separates the interlaced source fields, then "fills in" the missing lines (with the help of an interpolator) to create a shimmer-free progressive output. However, by default, the original field lines do not remain unchanged in the output. Put simply, the input pixels are not in the output. This is not ideal - we are not rescaling, just filling in the "missing" lines so it would seem best to keep the original fields unchanged. But that is hard to do whilst removing the shimmer from the interlacing.

QTGMC's lossless mode will do additional processing to keep the original fields exactly as they were whilst still retaining as shimmer-free an output as possible. This mode gives output that is truer to the source, but it can contain some minor combing or bob-shimmer. It also retains any noise from the source (QTGMC denoises somewhat by default)

This mode has nothing to do with lossless encoding.

BTW. Megui pre-renders are encoded to huffyuv

[dansrfe]

Ok :D That makes things clearer. Thanks!

[yup]

dansrfe!
Try other lossless codec for example Ut. On my Core2 QUAD work faster. Lagarith use only 2 threads. I use Lagarith only for archive purpose, for intermediate using Ut.
yup.

[jpsdr]

@dansrfe
I also strongly suggest you tu use UT Video codec. I've made some tests, and confirmed they work faster. Problem of huffyuv is that you've not YV12 support, thing you have with UT Video. File with UT Video (YV12 codec) are a little bigger than lagarith, even in best compression, but it's realy a little, less than 10%.

[dansrfe]

Can you guys direct me to the link for UT Video?

[jpsdr]

Google : UT Video

[Revgen]

huffyuv does have yv12 support if you use the ffdshow version. I use it all the time to capture HDTV.

[moozooh]

Much thanks for taking over for Didee and his awesome script!

I have a question. I'm processing a considerably clean (very little noise, mostly MPEG2 artifacts if any) 60i game video for further encoding to x264 at around the crf of 22..27. Will it make sense for me to retain/generate the noise when using the slowest QTGMC presets? It seems like it would only complicate encoding since at that crf x264 will smear the noise invariably whilst spending more bits than otherwise in an attempt to preserve it.

Thanks in advance.

(Vit, out of curiosity… are you Russian?)

[-Vit-]

I have a question. I'm processing a considerably clean (very little noise, mostly MPEG2 artifacts if any) 60i game video for further encoding to x264 at around the crf of 22..27. Will it make sense for me to retain/generate the noise when using the slowest QTGMC presets? It seems like it would only complicate encoding since at that crf x264 will smear the noise invariably whilst spending more bits than otherwise in an attempt to preserve it.
The two slowest presets, "Very Slow" and "Placebo" use the wider temporal radii in the TGMC algorithm. This denoises strongly creating a very clean, but rather artificial look, also losing some detail. To counteract this, those presets also use some noise bypass to retain some of the detail/grain that would otherwise be lost. Obviously you can do this manually in the other settings if there's some grain you particularly want to keep.

Depending on the game content, there may well be grain in the textures/backgrounds (rather than over the entire image) that might be lost at the highest settings. And, assuming that this is a 720p+ capture, then a CRF of 22 might be enough to have caught some of it. But it will be a lesser effect than on the naturalistic sources for which the presets were designed. So, yes it may well be OK to reduce this processing to save on time & filesize (and memory used during the encode - important if you intend to multithread).

However, this is just speculation - I have only worked with a little game footage on the default "Slower" setting - and I didn't try noise bypass. Others will have more experience than I do for that kind of source. Why not just try encoding a few thousand frames each way and compare?

(Vit, out of curiosity… are you Russian?)
;)

[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-]

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]

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, :sly:

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]

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

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]

:stupid:

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... :thanks:

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]

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-]

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-]

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]

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? :p

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-]

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 :o

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 ... :D ... 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-]

-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...

[der_groschi]

Hey Vit, thanks for your great work on this awesome script.
@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.
Well, recently "inputtype=2" did a great job for me on two problematic sources. The first one was a hard telecined DVD source which obviously came from an analog video source. It definitely wasn't fieldblended, but still something strange was going on with the original fields so the result of "TFM().TDecimate()" still had some combing and aliasing in it. QTGMC fixed it perfectly.
The second one was a heavily aliassed 30 FPS progressive DVD Source, which seemed to be the result of exactly the bad deinterlacing you say "inputtype=2" is designed for.
I haven't tested it yet, but i'd expect it to work just as good as a postprocessor for TDeint+NNEDI'ed and then srestore'd material.

Now, what do you suggest about that? Recently i've always feeded fieldblended material through good ol' TempGaussMC and then deblended it with srestore. The results were pretty satisfying, but it always seemed a bit unreasonable to me, first from a speed standpoint, beacuse TGMC had to process many frames (more then half) that get thrown away later anyway, and also because TGMC cannot develop all its power on such sources anyway because (if i understand this correctly) its motion compensated parts are pretty useless on non-pure interlaced sources.
What do you think about that? Is using QTGMC afterwards in progressive mode more reasonable or ar there still any benefits from the "oldschool"-aproach?

[-Vit-]

I don't work with fieldblended material or problem sources generally so others may be able to make better comment from experience. Your idea is to deinterlace in such a way to retain more detail (but also with more shimmering/aliasing), then remove the fieldblending, then QTGMC away the shimmer. The idea being that this will involve less processing as well as avoid using motion-compensation when the field blending is still there.

Progressive QTGMC is certainly effective to remove deinterlacing residue (http://forum.doom9.org/showthread.php?p=1455667) from earlier processing so your workflow seems to be within spec for QTGMC. Whether it's the best approach for this kind of material I cannot say having not tried it. I play down progressive QTGMC effectiveness in the general case because it's only tailored for sources with thin horizontal shimmer.

[pokazene_maslo]

Hello. How to set up QTGMC for stronger denoising? I have an interlaced DVD with lots of noise. So far I'm using this command: "QTGMC( Preset="Very Slow", Edimode="EEDI2", Sigma=2.2 , NoiseBypass=0)". AFAIK sigma parameter is useless if NoiseBypass=0. Thanks.

[henryho_hk]

Try putting degrainmedian(mode=2, interlaced=true) or even degrainmedian(mode=1, interlaced=true) before QTGMC().

[-Vit-]

The NoiseBypass setting is designed to retain noise that TGMC would normally lose, but it can be used to reduce noise too. However, you're switching off all noise processing by setting NoiseBypass to 0 and you're just seeing the denoising that inevitably comes with any TGMC processing.

There are three related parameters, NoiseBypass, NoiseRemove and NoiseRestore.
You should use NoiseBypass=1: this will remove noise before processing with the intent of restoring it afterwards. However, in your case you're not going to restore any.
NoiseRemove is a value 0.0 to 1.0, to indicate how much noise (at the selected Sigma level) you wish to remove before TGMC processing. Clearly you want 1.0 or close to it.
NoiseRestore is a value 0.0 to 1.0 (or more) to indicate how much noise to restore after processing. You should use 0.0 or a small value.
You should ensure you specify all these settings, because otherwise you'll get the defaults for "Very Slow", which include some noise retention.

So a initial attempt might be:
QTGMC(Preset="Very Slow", EdiMode="EEDI2", NoiseBypass=1, NoiseRemove=1.0, NoiseRestore=0.0, Sigma=2.2 )
Obviously, tweak for preference. You could try setting tr2=3 to get more denoising out of TGMC too.

As henryho_hk has indicated, for your purposes you could just denoise separately instead.

[henryho_hk]

When there is a large amount of grain, degrainmedian() helps mdegrain3() greatly, being more cost-effective than mdegrain4/5/6 mods in many cases.

[pokazene_maslo]

Thanks for very explanatory answer -Vit-. Finally a filter that provides results I wanted! Also thanks to henryho_hk, but I don't like the idea to run two separate denoisers when one properly set up can do the job.

[henryho_hk]

By adding NoiseRemove=1.0, we are activating FFT3DFilter(), which is quite strong. If we don't apply NoiseRestore in combination, the output may look too smooth to be realistic.

[-Vit-]

henryho_hk makes a good point. Should consider the effect of using NoiseBypass on details:

QTGMC-NoiseBypass uses FFT3DFilter, which is a spatio-temporal denoiser. However, at the core of QTGMC is MDegrain, which is a motion-compensated temporal denoiser (used regardless of NoiseBypass). MDegrain has a better chance of removing noise without losing detail on moving images since it is motion compensated. So there's good reason to consider lowering NoiseRemove from 1.0 - allowing the MDegrain to do some denoising, and hopefully retaining some more detail. Similarly, you may also wish to increase NoiseRestore from 0, to get back the impression of any lost detail, without making the restored noise too prominent. Depends on how terminally noisy your source is though...

A related point - QTGMC resharpens quite strongly, which will enhance any remaining noise. You may wish to consider reducing sharpness. I actually think Sharpness=0.3 or so is closer to the source.

Although not relevant for noise removal, for completeness I should note the purpose of NoiseBypass=2. This mode measures the noise at the start and restores at the end using the same settings as mode 1. But it only measures the noise at the start - it doesn't actually remove any. This mode expects the TGMC process to do all the denoising, then adds some noise back at the end. As such it tends to give stronger grain retention, and even a sharpening effect unless applied lightly. Suggested NoiseRestore value is around 0.4 for this mode.

[Boulotaur2024]

I actually think Sharpness=0.3 or so is closer to the source.... How about making it the default value then :] ?

[-Vit-]

... How about making it the default value then :] ?
I wanted QTGMC to be a drop-in replacement for TempGaussMC_beta2. I wanted to encourage uptake. So I kept all the important defaults the same when I first released it.
Many people used the defaults for TGMC_b2 and are continuing to do so on QTGMC. They're used to the additional sharpness. Didn't want them to think that QTGMC was "blurry"!

However, QTGMC is well used now so I'll probably tweak the default in the next version (with a big warning notice!).

[pokazene_maslo]

QTGMC-NoiseBypass uses FFT3DFilter, which is a spatio-temporal denoiser. However, at the core of QTGMC is MDegrain, which is a motion-compensated temporal denoiser (used regardless of NoiseBypass).
Hmm. What about adding motion compensation to FFT3DFilter?

[Didée]

You're not forced to like the default values. But they have been chosen for a technical reason.

The decision factor for TGMC's sharpness defaults was: the case of perfectly-static sections. (Keep in mind that TGMC does not use the "no motion -> weave fields" method). In perfectly motionless areas, the temporal processing is reducing the signal amplitude significantly (in borderline cases: 50% reduction). The default sharpness values of TGMC have been chosen to restore most of this loss. You can use lower sharpness settings, but then static sections (subtitles, logos, static backgrounds) will come out more blurry.

Example (http://www.mediafire.com/?mo4bljcmz24b3ez) (650 kB)

I agree the sharpening is a bit of a weak point - another aspect is areas of bad motion matching. there's danger that artifacts from bad matching may get additionally enhanced.

=> Full sharpening for static areas, somewhat less sharpening for motion areas, and no or only little sharpening for badly matched motion areas. (Sounds good? Sounds ... slow!)

Looking closer, there's quite a few more aspects that influence the required sharpening strength: the "Lmode" (spatial or temporal), which kind of interpolator is used, which kind of sharpening mode, thinning, a.s.o.

_____

Unrelated to sharpening:
A few days ago, on the German board we found a case (http://forum.gleitz.info/showthread.php?42935-DeRainbow-Skriptalternative-zu-DeRainbow-sh0dan) where TGMC turned out to be pretty effective in removing rainbowing ... but only when the chroma repair section was disabled. The bands of chroma fringes often are too broad to get through the repair section. OTOH, completely switching off the repair often is not such a good idea.
Suggestion: separate switch whether the repair values (NonBobDiff) shall work on luma+chroma, or only on luma.

[William.Lemos.BR]

Hi, everyone!

Since my last post I've been doing some tests and experiences with QTGMC. I say with gladness that I've achieved some REALLY IMPRESSIVE results. Thanks, Dideé, for your astonishing script and congratulations, Vit, for the improvements in QTGMC.

My goal is to use QTGMC for converting old VHS tapes into Blu-ray. Playing with the QTGMC's parameters and using MT I've managed to get a good balance between process speed / quality (in my old PentiumD 3.20GHz, running Win7 64). Now I can do 1 hour convertion in 24 hours with this code:

MT(""" QTGMC( Preset="Placebo", EdiMode="NNEDI3", EdiQual=1, NoiseBypass=2, Lossless=1, LosslessTR=3, LosslessPreset="Placebo", SubPel=4)""", 4,4)

I've choosed SubPel=4 'cause noticed some improovement in edge details (specially after I upscale to 720p using VideoEnhancer). Then I use NeatVideo to do some filtering in HD (my tests shows that this sequence gives the best results).

Just one thing that may be helpfull: when I set "EdiQual=3" VirtualDub crashes. Actually I'm satisfied with current settings and probably won't change them (just tried it 'cause QTGMC's help text gives this possible parameter), but NNEDI seems to alow EdiQual to be 1 or 2 (the error message said so).

Anyway, I'm going to use QTGMC extensively from now on and expect to help you somehow in retribution. Thanks a LOT!

[Didée]

VideoEnhancer
NeatVideo
Herewith I declare that you are forbidden to use TGMC or QTGMC. :D

/endofjoke

Could you show examples where pel=4 gives a visible advantage over pel=2? From my past experiences it's like 98% wastoftime + 2% improvement ...

Also, probably I'd rather go for upscaling with NNEDI, instead of VideoEnhancer. (It has been discussed before - my opinion is that VideoEnhancer can not hold its claims when it receives smoothely sampled input: it is impossible for simple technical reasons.)
Ideally would by upsampling internally in TGMC (i.e. combining the temporal processing with the upscaling), rather than using it in a post-upsampling style. But that's not trivial - it won't integrate easily, because of the "repair" section of Q/TGMC. (The spatial radii won't fit anymore when the upscale is made inbetween. )

[Boulotaur2024]

The decision factor for TGMC's sharpness defaults was: the case of perfectly-static sections. Ah sorry I thought QTGMC defaults were higher than the original TGMC (pretty sure I had read that somewhere... oh well)... Thanks for the explanation anyway, they're always valuable coming from you :]

Then I use NeatVideo to do some filtering in HD (my tests shows that this sequence gives the best results).Sorry for not being ontopic, but "best results" compared to what ? (just out of curiosity)

[-Vit-]

When I set "EdiQual=3" VirtualDub crashes. Actually I'm satisfied with current settings and probably won't change them (just tried it 'cause QTGMC's help text gives this possible parameter), but NNEDI seems to alow EdiQual to be 1 or 2 (the error message said so).

You're correct, thanks. NNEDI3 only allows quality setting = 1 or 2, whereas NNEDI2 allows 1,2 or 3. I'll correct the code/comment in the next version.

[wohoo]

Can some one kindly upload the AddGrainC 1.5, as the link for it on the first page doesn't work.

[-Vit-]

I've updated the links for AddGrain in the OP. There was a slightly newer version (http://ldesoras.free.fr/src/AddGrainC-1.5.1.7z) that I had missed.

[William.Lemos.BR]

Herewith I declare that you are forbidden to use TGMC or QTGMC. :D


My god! I'm feeling as if I had fallen (with a parachute) into the middle of a gunfight, not knowing who is the bad or the good guys. But now, after 24 hours of researching and testing I can say with ABSOLUT certainty: VIDEO ENHANCER IS A LIEWARE!

It doesn't use super resolution, as it claims. The comparison shows the same results of using nnedi3, with a tiny sharpening. I think the only time I was as shoked as now was when I discovered that Santa Claus doesn't exists! Thanks, Dideé, for helping me to see that this world is cruel, and that I've spent 46 bucks for a GARBAGE like this. :stupid:

Anyway, I'm a noobie, but I learn fast. This only confirmed to me that we may get better results with personal effort and research, instead of buying a comercial program from a software swindler.

Could you show examples where pel=4 gives a visible advantage over pel=2? From my past experiences it's like 98% wastoftime + 2% improvement

I think you're right. What I noticed was a little improvement in the "pixelation" of the image, but now I'm feeling like that philosopher who said "I know that I know nothing", thanks to you that ruined all my illusions... :(

But I'm going to make some more tests after recovering from the shock...

Ideally would by upsampling internally in TGMC


Totally agree with you, just don't have any idea of how to do it! The same about NeatVideo (probably I'm going to find a better tool within Avisynth). Need to study a lot... who knows in 20 years I become a Didée v.0.1? :D

But the idea behind super resolution is really interesting, do you agree? Going to give a try. In the end at least I'm going to learn usefull stuff.

Thanks Didée, for the enlightenment and pacience! :thanks: