Log in

View Full Version : TempGaussMC vs McBob?


Forteen88
12th September 2009, 14:57
Hey,
I have a deinterlacing-question,
I think TempGaussMC plugin denoises and sharpens a bit too much, and the McBob plugin creates too much ghosting :p
Are there other high-quality deinterlacing alternatives, or can someone tell (for good deinterlacing) how I can modify TempGaussMC not to denoise and/or sharpen as much?

Terka
12th September 2009, 15:02
there are options about sharpening and denoising in TGMC; if your output is 25 or 30 fps (selectodd after TGMC), try nnedi2 only.

Forteen88
12th September 2009, 15:16
Thank Terka.
In TempGaussMC, I see that I can set
TempGaussMC_beta1mod(sharpness=0, sharp=0)
which I assume disable sharpening, but I still don't know what parameter is used for disabling denoising :P

LaTo
12th September 2009, 15:27
You can't *disable denoising*...

Forteen88
12th September 2009, 15:32
You can't *disable denoising*...Thanks, but can I set it lower?

EDIT: Thanks Didée, I'll try that.

Terka
12th September 2009, 16:34
tr2=0

Didée
12th September 2009, 16:44
You can't stop TGMC from removing noise. TGMC is a denoising filter, just that it has been tailored to remove bob flicker in the first place. It's not very promising to ask that a denoising filter shall not remove noise.

You can reduce the inherent denoising by reducing the temporal radii, like e.g. TGMC(1,1,0,...). (Default is 2,2,1, maximum is 2,2,3. The first number must not be 0.) On the downside, reducing the inherent denoising this way, you also reduce the stability of the bobbed result. Though, it might be not all too noticeable when you're aiming for same-rate deinterlacing anyway.


My preferred way is this: first remove the noise, then bob/deinterlace with TGMC, then add back the removed noise.


source = last
denoised = source.fft3dfilter(sigma=3,bt=3,interlaced=true) # just an example. Choose settings to your needs
denoised_D = mt_makediff(source,denoised,U=3,V=3)

denoised.TempGausMC(...) .mt_adddiff(denoised_D.douleweave(),U=3,V=3) # or bob() instead of doubleweave()

(This suggestion I had already given in the past, but I'm too lazy to search for it now ... with a bit of searching, you should find it.)
(Edit: here (http://forum.doom9.org/showthread.php?p=1152932#post1152932) it was.)

Forteen88
12th September 2009, 21:05
if your output is 25 or 30 fps (selectodd after TGMC)So for all PAL (25 fps) DVD-sources, TempGaussMC_beta1mod(EdiMode="NNEDI2").SelectOdd()
should be used?
EDIT: Doesn't seem to, as when I used SelectOdd() instead of SelectEven() on a PAL-source, it had some ugly jagged edges with McBob..

Terka
14th September 2009, 08:21
it doesnot matter if selectodd or selecteven. WHATEVERbob gives you 50fps, so you discard every second frame using selectODD/EVEN.
when the output should be 25fps, try
clip=avisource("film.avi")
clip.nnedi2(field=-2)
its faster than tgmc

Didée
14th September 2009, 09:56
...when I used SelectOdd() instead of SelectEven() on a PAL-source, it had some ugly jagged edges with McBob..
Phrased more precisely: "it had some ugly jagged edges in some places with McBob.."
And I'm pretty sure that when using selecteven, you'll find some ugly jagged edges in some other places ...

Or, perhaps you're dealing with a funky source where something is fishy with one parity of fields.
Or: your source is not of the "true" interlaced kind (aka "video interlace", with unique motion states in all fields).

Since we know nothing about your source, both could be possible.
(We've had it more often than not, that people were applying motion-compensated bobbers to sources that didn't quite fit the necessary criteria for those filters...)

***

MCBob is mostly indicated when you're after hunting maximum metrics (PSNR et al.) against a present doublerate progressive reference. For practical purposes, it's not nearly as hot.

Really, MCBob was created as a try to do things differently than the back-then available solutions. It does contain some interesting concepts as well. That's about the theory.

However, from a practical point of view: regarding the technical issues of the employed motion interpolation(!) technique, and regarding the speed/benefit tradeoff, I would mostly recommend to *not* use MCBob at all .... Label it "for studying purposes", and let it be.

Forteen88
14th September 2009, 10:11
True Didée, you're right, "Phrased more precisely: "it had some ugly jagged edges in some places with McBob.."". I just used McBob to try SelectOdd out.

...
However, from a practical point of view: regarding the technical issues of the employed motion interpolation(!) technique, and regarding the speed/benefit tradeoff, I would mostly recommend to *not* use MCBob at all .... Label it "for studying purposes", and let it be.But TempGaussMC is also very slow. Do you consider TempGaussMC also mostly "for studying purposes"? Does McBob keep more grain than TempGaussMC, or does McBob only keep added "dirt"-grain which was generated by deinterlacing?
I think Yadif (that is much faster) got ugly artifacts when deinterlacing scrolltexts :P
Thanks you both.
EDIT: TempGaussMC_beta1mod(EdiMode="NNEDI2") is almost double as fast as McBob (who uses NNEDI2).

Didée
14th September 2009, 12:16
Quick typing now.

TGMC is not *that* slow. With "light" simple settings, on this old Core-Duo here I get ~9fps on a full PAL source. Compare: tdeint(mode=1) ~24fps, pure NNEDI-bob is ~2fps, pure NNEDI2-bob is ~3.5 fps.
Note that TGMC's defaults are like medium effort. You can have it much faster, and you can have it much slower even. Using MVTools always comes at a price. When using only little of the general MVTools-effort, it comes at a moderate price. When trying to get the maximum out of the general effort, it comes at a noticeable price. That's how things are. Lamborghinis usually are not cheap, you know.

With direct usage, MCBob surely keeps more grain/noise than TGMC, for sure. As said, that's inherent to the methodology. However, the proposed noise-bypass technique is pretty effective - see below. (Did you even try it...?)

Summed up, I wouldn't consider TGMC as being purely academic. It's definetly on the slow side of things, yes. But when a high-quality bobber is wanted, then it spends its time quite well. I'd say that TGMC breaths air that is much thinner than any other bob filter...

You also have to keep in mind that same-rate deinterlacing is a different story than double-rate deinterlacing (bobbing). A lot of the ugly issues that are distracting in a bobbed result are more or less a non-issue when you're aiming for same-rate deinterlacing! There's still worthwile benefit that could be shown off, but it's definetly less as in the bobbed result.
So, the question of "shooting a butterfly on a wheel" is what everyone has to answer for his own purpose. ;)

Oh, and yes ... plain Yadif looks pretty ugly, at least to my eyes. Plastic look galore. Many don't seem to care. Everyone to it's own.

Okay ... small comparison of source vs. bob vs. TGMC vs. noise-bypassed TGMC:

Sample (http://www.mediafire.com/download.php?ylmkji2jmmz) (~6MB, MediaFire)

If you do want the noise: there it is. Isn't it?

Forteen88
14th September 2009, 13:26
.. TGMC is not *that* slow. With "light" simple settings, on this old Core-Duo here I get ~9fps on a full PAL source. Compare: tdeint(mode=1) ~24fps, pure NNEDI-bob is ~2fps, pure NNEDI2-bob is ~3.5 fps.
Note that TGMC's defaults are like medium effort. You can have it much faster, and you can have it much slower even. Using MVTools always comes at a price. When using only little of the general MVTools-effort, it comes at a moderate price. When trying to get the maximum out of the general effort, it comes at a noticeable price. That's how things are. Lamborghinis usually are not cheap, you know.

With direct usage, MCBob surely keeps more grain/noise than TGMC, for sure. As said, that's inherent to the methodology. However, the proposed noise-bypass technique is pretty effective - see below. (Did you even try it...?)Thanks a lot Didée. The noise-bypass technique looked a bit better. I haven't tried the proposed noise-bypass technique yet, but I will as soon as I got an important source to deinterlace. I'm a bit discouraged to use it on all interlaced source though, because of the slow fft3dfilter :-P I don't quite understand what you mean by "noise-bypass technique", do you mean that you add digital noise ("first remove the noise, then bob/deinterlace with TGMC, then add back the removed noise", sounded like adding back the removed noise from the source)?

I usually use extremely slow x264-settings, so that's why I said TGMC is slow (although as said, there aren't real alternatives for high-quality deinterlacing). The McBob I tried was a modified McBob v0.3u3 that uses NNEDI2, so I guess it's a bit faster than older versions.

EDIT: BTW, I thought "noise-bypass technique looked a bit better" because I thought the grain was detail, not just some added random noise.

Didée
14th September 2009, 13:42
because of the slow fft3dfilter
With adequate hardware (graphic card), you can use FFT3DGPU to speed that part up. (Me, I don't have such a one, so I have to use the original.)

I don't quite understand what you mean by "noise-bypass technique", do you mean that you add digital noise ("first remove the noise, then bob/deinterlace with TGMC, then add back the removed noise", sounded like adding back the removed noise from the source)?
Sorry but Im not sure how to explain more clearly. You complain TGMC removes too much noise. In reverse, this means you want to keep the noise. Hence, the trick is to first make the clip noise-free. Then TGMC does its job on the noise-free clip. (now that there is no noise anymore, TGMC won't acidentially remove it.) Afterwards, the noise that was removed is added back (since the goal is to keep it).

If that's not clear enough, I'm out of means of explaining.

Forteen88
14th September 2009, 14:51
With adequate hardware (graphic card), you can use FFT3DGPU to speed that part up. (Me, I don't have such a one, so I have to use the original.)Thanks, but I read somewhere one who had artifacts with FFT3DGPU (don't know if it's fixed yet, or if that graphicscard was broken) and it was no such problem with fft3dfilter. Also, I don't have a new graphicscard either, yet :P

Sorry but Im not sure how to explain more clearly. You complain TGMC removes too much noise. In reverse, this means you want to keep the noise. Hence, the trick is to first make the clip noise-free. Then TGMC does its job on the noise-free clip. (now that there is no noise anymore, TGMC won't accidentally remove it.) Afterwards, the noise that was removed is added back (since the goal is to keep it).

If that's not clear enough, I'm out of means of explaining.Ok, thanks, I think I got it. It seems you mean that it adds back the grain, not that it adds just some random noise.
I don't really care much about "noise", it's the small detail (grain) from the source I want to keep.

EDIT: Ok Didée, now I really get what you meant.

Didée
14th September 2009, 15:27
From a signal processing point of view, grain and noise are the same thing, or at least very very similar. Grain is a random, non-predictable variation on the original clean signal. (The "real world" got pictured by some sort of camera ... but when looking at the real world with your eyes, it is free of grain...).
"General" noise, too, is a random and (mostly) non-predictable variation on the original clean input.

It's a bit amusing when people state they want to "kill the noise, but keep the grain" ...
With a bit of broadsword generalisation: For all filters not driven by a neural network of very high complexity, noise and grain look the same. At least, all those highly sophisticated {difference < threshold ? noise : not-noise} black/white filters don't stand a chance on that matter.

henryho_hk
15th September 2009, 12:03
I believe that "kill the noise, but keep the grain" mean "improve the compressibility while maintaining the same level of grainy look". Perhaps something like your GrainFactory3()?

BTW, is TGMC(1,1,0,...) + Bob EDI mode the "light simple" setting you mentioned?

Didée
15th September 2009, 12:44
Yes. That, and some more. a) Reduce the sharpening to Smode=1, or deactivate with =0. b) The default temporal limiting is good for maximum & stable detail, but it's also rather slow (because of additional MCompensate). Its faster to use Use the spatial SLmode=1, or =0 to completely disable the limiting. c) Disabling the sharpness modificator via Sbb=0 gives another little boost. d) Lastly, the SVthin feature isn't exactly a runner because of mt_luts, so setting SVthin=0.0 makes things faster.

About the fastest possible settings for TGMC_beta1 are

(1,1,0, 0,0,0, "blah", sharpness=0,Smode=0, SLmode=0,Sbb=0,SVthin=0.0)

That's the minimal temporal/MVTools effort, and all funky stuff for re-sharpening and artifact-safety is disabled. Hence, it will not be top-notch quality, of course. But it is fast.

In other words, that's more or less the "barebone principle" of TGMC's bobbing methodology. All the now switched-off stuff deals for bringing the result of the barebone principle closer to the ideal result. The speed fanatics might start from here, and examine what of the extra-stuff they need, and what not.

Undead Sega
22nd November 2009, 03:13
How did u do the noise bypass for TGMC? Even when bypassed, would the quality of deinterlacing or bobbing of TGMC be affected?

Revgen
22nd November 2009, 03:47
^Read the whole thread. Specifically Didee's first post.

cretindesalpes
25th November 2009, 21:21
Shouldn't the noise be motion-compensated before adding it back ?

R3Z
27th November 2009, 05:59
Shouldn't the noise be motion-compensated before adding it back ?

What are you reffering to ? Noise removed and re-added as a final step doesnt need motion compensation as its already been motion compensated to start with.