exist any filter specially done for (deinterlace) flicker

[Didée]

Terka - sure, there are all sorts of complaints. But from what I hear, quality/artifacts is more seldom the point. People would probably like to use TGMC if, oh if only it was 10 times faster. That's only loosely related to quality. People want to finish their encodes in a few hours, not in a few days. For many, Yadif is the only usable deinterlacer, because it runs so fast ... innumerous people that care only for Yadif's speed, and don't even notice that its quality often is questionable.

Oh, and I forgot to mention another point about adaptive blocksize by MRecalculate: though it's good to have it, the actual method is a bit unsatisfying. And one more time, it's the darn fixed-threshold principle: " SAD(block) < [thresh] ? good : bad" This mostly works out for hard edges, but it has a tendency to fail when there are no hard edges, like e.g. on motion-blurred moving objects.
I have experimented with an adaptive method, and it seemed to me that it works better. Method: do a full search + compensation at blocksize [big], and a full search + compensation at blocksize [small]. Get SAD mask from both. If SAD of [small block] is better by 50%, use it. Else, keep the result of [big block]. (The 50% is an example, actually this is a parameter. Also, I didn't really use a fixed threshold, but instead a sliding threshold zone like 30% to 60%.) The point is that this won't use the small block just because it's a tiny bit better (and thereby lose the big block's stability without necessity), and it won't fail to use the small block because SAD is generally low in a given area. Instead, it (mostly) succeeds to use small blocks in those areas where the small block achieves a *worthwile* improvement over the big blocksize.
But then, of course the implementation is quite slow and cumbersome. Doing full compensations, producing masks, compairing the masks, then doing maskedmerge. And after this, you still can't use MDegrain with it, but you have to simulate MDegrain with the interleave/ttempsmooth/select procedure. Hence, it is a purely proof-of-concept method, but not really practical due to the speed. And just to be clear - this method also can not "just quickly" be implemented into MVTools. The current method of MRecalculate is ~relatively~ easy and straightforward. The method I described is more like a complex processing chain.
Still, when you know that things could be done better, then it's much less fun to use the available "if it's green, it must be a vegetable" methods.


@ Boulder - no, it's still Didée.;) Gaff's objects are nice eyecatchers, but in fact they are lame. E.g: The unicorn is made of three different pieces which are sticked together. And the stickman is either multipiece, or cheated by cutting/tearing. Such is not the pure art. The pure art is One Square, and no cutting/gluing. The idea is that you can take the finished result, and revert it back to the original square, unspoiled.

[WorBry]

The pure art is One Square, and no cutting/gluing. The idea is that you can take the finished result, and revert it back to the original square, unspoiled.

Hence the little known and subtle relationship between One Square and a pure bob deinterlacer.......sorry, I couldn't resist :D

[aegisofrime]

It's funny because I personally use TGMC alot on progressive sources. I do not claim to be an expert: As the author of this script you Didee obviously knows far more than anyone of us as to how TGMC work. I'm also not saying that TGMC is made for bobbing progressive sources, however from my own experience, TGMC is very often better with MVTools. One huge reason why I prefer TGMC over MVTools is that if I use the double frame-rate script:

super = MSuper(pel=2)
backward_vec = MAnalyse(super, overlap=4, isb = true, search=3)
# Use block overlap, halfpixel accuracy and Exhaustive search
forward_vec = MAnalyse(super, overlap=4, isb = false, search=3)
MFlowFps(super, backward_vec, forward_vec, num=2*FramerateNumerator(last), \
den=FramerateDenominator(last))


I get an obscene amount of ghosting during fast motion scenes. TGMC has a much better output here.

[shoopdabloop]

Hence the little known and subtle relationship between One Square and a pure bob deinterlacer.......sorry, I couldn't resist :D

that reminds me, why do line-interpolaters like NNEDI2 not leave the original lines unfiltered?

[thetoof]

aegisofrime, TGMC on a progressive clip will duplicate every frame , while the mflowfps script you posted tries to interpolate (i.e. create a new frame that would be an intermediate between the two original ones)

TGMC = A A B B C C
mflowfps = A AB B BC C CD

Other example - imagine a wonderful dance move where you'd have to move your arm for pointing upwards to in front of you.
TGMC 1-2 = up, 3-4 = front
mflowfps 1 = up, 2 = 45 degrees (between up and front), 3 = front....

See, 2 different goals. If you want to double the frames, a changefps(framerate*2) will do just about the same, only much (MUCH) faster.
If you want to simulate smoother motion, try mflowfps for mo-comp or convertfps for blends......

[Didée]

thetoof - that's spot-on what theory tells. However, practice often is a bit different from theory. ;)

TGMC on progressive input - yes, it should give an AA BB CC... pattern. But there's more to it. Due to the bob-frame ordering, the number of different motion states is not equal in forward and backward direction. Since the search-clip is preprocessed with some TemporalSoften, this can lead to the effect that MVTools finds slighty different vectors for two Bobframes that belong to the same progressive sourceframe. So the produced pattern in fact can be more like 'A A' 'B B' 'C C'... , i.e. with some mini-motion between the same-lettered frames, as indicated by the ' signs.
The strengh of this effect is not exactly predictable, and it also depends strongly on the repX-settings: the more strict repX is set, the lesser the effect will be.


mflowfps 1 = up, 2 = 45 degrees (between up and front), 3 = front
That's exactly what we expect MFlow(FPS) to produce. Alas, exactly this is what we hardly ever get from it. If an arm points forward in one frame, and upward in the next frame, then the interpolated middle frame will not show the arm pointing at 45°. Instead, it most likely will produce funky artifacts of varying degree. The motion engine will not be able to connect these two motion states, since their representation is so different that MAnalyse can not reckognize the belonging-together parts as belonging together.

[aegisofrime]

thetoof - that's spot-on what theory tells. However, practice often is a bit different from theory. ;)

TGMC on progressive input - yes, it should give an AA BB CC... pattern. But there's more to it. Due to the bob-frame ordering, the number of different motion states is not equal in forward and backward direction. Since the search-clip is preprocessed with some TemporalSoften, this can lead to the effect that MVTools finds slighty different vectors for two Bobframes that belong to the same progressive sourceframe. So the produced pattern in fact can be more like 'A A' 'B B' 'C C'... , i.e. with some mini-motion between the same-lettered frames, as indicated by the ' signs.
The strengh of this effect is not exactly predictable, and it also depends strongly on the repX-settings: the more strict repX is set, the lesser the effect will be.



That's exactly what we expect MFlow(FPS) to produce. Alas, exactly this is what we hardly ever get from it. If an arm points forward in one frame, and upward in the next frame, then the interpolated middle frame will not show the arm pointing at 45°. Instead, it most likely will produce funky artifacts of varying degree. The motion engine will not be able to connect these two motion states, since their representation is so different that MAnalyse can not reckognize the belonging-together parts as belonging together.

Thank you for the explanations thetoof and Didee. While I understand that TGMC is not made for bobbing progressive sources, and MFlowFPS is, unfortunately alot of times in practice I find that TGMC works better. In fact, moving arms are one of the main problems with MFlowFPS, and the problem is exactly what you described Didee. I get a watery ghostly kind of image. Maybe I'm knocking a square peg into a round hole, but the ends justify the means, and so for some sources at least, I prefer using TGMC.

[Leak]

that reminds me, why do line-interpolaters like NNEDI2 not leave the original lines unfiltered?
:confused:

They do...

[shoopdabloop]

Really? Hm, for some reason I was under the impression that they didn't.

[IanB]

Which is why you get this flicker.

T is top field data, B is bottom field and x are the interpolated values.

T x T x
x B x B
T x T x
x B x B
T x T x
x B x B

In order for x values to be non flickering with respect to both it's spatial buddies and it's temporal buddies you need to tweak all the buddies.

[2Bdecided]

beautiful paper folding and deinterlacing progressive sources. this thread is just surreal.

Oh, and I still use TGMC on HD when I really need to - e.g. when I need to zoom+crop.


FWIW I noticed TGMC did very little damage to the progressive parts on hybrid sources (25p + 50i). I like it for this (on its own - no adaptive i/p detection - because that can create its own problems), but it's too slow. ;)

Cheers,
David.

[Terka]

Hi Didee,
1. bigger coherence gives me better results for TGMC in static. what a surprice :eek:
2. what about use the "TGMC denoising" as edeint.
so the tdeint result will be quite calm (in compare to clp.nnedi2(field=-2).
And use mild denoising to finish the result.
So something like:
its quick-not much tested. "TGMC denoising"=degrainX is stolen from TGMC. same as VCRep.
yes 2 times motion search, maybee can be done 1 times. What do you think?



clp.TdeintTMMnnedi2up().degrainx(SAD1=100,x=3)

function TdeintTMMnnedi2up(clip c, int "qual")
{
GetParity(c) ? AssumeTFF(c) : AssumeBFF(c)
edeint=nnedi2(c,field=-2,qual=qual).degrainx(x=3)
Tdeint(c,mode=1,emask=TMM(mode=1),edeint=edeint)
}
function DegrainX (clip o, int "calm", int "rep0", int "X", int "SAD1", int "bs", int "limit", bool "external_denoiser")
{
# makes MDegrain1-3 for deinterlace
# Calm function is needed

X = default( X, 3 ) # MVDegrain 1, 2 or 3
calm = default( calm, 1) # use calm() for predenoising as default
bs = default( bs, 16 ) # blocksize
SAD1 = default( SAD1, 400 ) # Threshold for degraining. Decrease if you see ghosting
limit = default( limit, 255 ) # Limits maximum change of a pixel. Default means no limit
ov = bs/2 #overlap
rep0 = default (rep0, 4)


calm=(calm==1) ? o.Calm(rep0): o

o_super = o.MSuper(pel=2, hpad=16, vpad=16, levels=1) # create the source superclip
srch_super = calm.MSuper(pel=2, hpad=16, vpad=16) # create the calm superclip

bv3 = (X==3) ? srch_super.MAnalyse(isb=true , delta=3, blksize=bs, overlap=ov) : BlankClip
bv2 = (X>=2) ? srch_super.MAnalyse(isb=true , delta=2, blksize=bs, overlap=ov) : BlankClip
bv1 = srch_super.MAnalyse(isb=true , delta=1, blksize=bs, overlap=ov)

fv1 = srch_super.MAnalyse(isb=false, delta=1, blksize=bs, overlap=ov)
fv2 = (X>=2) ? srch_super.MAnalyse(isb=false, delta=2, blksize=bs, overlap=ov) : BlankClip
fv3 = (X==3) ? srch_super.MAnalyse(isb=false, delta=3, blksize=bs, overlap=ov) : BlankClip


NR = (X==3) ? o.MDegrain3(o_super, bv1, fv1, bv2, fv2, bv3, fv3, thSAD=SAD1, limit=limit) :
\ (X==2) ? o.MDegrain2(o_super, bv1, fv1, bv2, fv2, thSAD=SAD1, limit=limit) :
\ o.MDegrain1(o_super, bv1, fv1, thSAD=SAD1, limit=limit)



#NR.mt_lutxy(NR.removegrain(11),"x x y - "+string(0.45)+" * +",U=3,V=3)
NR.sharpen(0,0.4)
return (last)
#return (NR)
}



function Calm (clip clp, int "rep0")
{
##################################
# PREPARES CLIP FOR MOTION SEARCH
#################################
#needs VCRep

rep0 = default (rep0, 4) # repair temporalsoften-defects for searchclip
ed0 = rep0<10 ? rep0 : rep0/10
od0 = rep0<10 ? 0 : rep0-ed0*10
ox = clp.width()
oy = clp.height()

# create linearily weighted temporal averaging
ts1 = clp.temporalsoften(1,255,255,28,2)
ts2 = clp.temporalsoften(2,255,255,28,2)

# construct temporal gaussian average from linear averages
t = ts1.merge(ts2,0.357).merge(clp,0.125)

# IF rep0=true: Allow only bob-typical vertical differences
t2 = (rep0!=0) ? t.VCRep(clp,ed=ed0,od=od0) : t

# Create clip for motion search.
t3=mt_lutxy(t2,clp,"x 3 + y < x 3 + x 3 - y > x 3 - y ? ?",U=3,V=3) # small cheat for better motion search
searchclip = t2.removegrain(11).gaussresize(ox,oy,0,0,ox+.0001,oy+.0001,p=2)
\ .merge(t2,0.1).mt_lutxy(t3,"x 7 + y < x 2 + x 7 - y > x 2 - x 51 * y 49 * + 100 / ? ?",U=3,V=3)
return (searchclip)
}

[7ekno]

source.TGMC_beta1u(1,1,0,EdiMode="In.a.hurry",Smode=1,SVthin=0.0,Sbb=0,SLmode=1|2)
=> 9.0 | 8.5 fps


Might be a stupid question, but where does one find "TGMC_beta1u"?!?

Can find beta1 and beta1mod on the Wiki entry, can find various MT and MVTools2 versions in this thread, just can't seem to find the elusive "beta1u" version (or is it outdated?!?) ...

7ek

[Didée]

Yeah ... too much modd's, moddy-mod's, and mod-of-the-mod-of-the-modded-mod ...

To clarify things a bit, here's a link that leads to a link that leads to a link (http://forum.doom9.org/showthread.php?p=1347200#post1347200). :D

[7ekno]

LOL, thanks, I did find that one, just didn't look at the function name!

Cheers,
7ek

[nikosvault]

I updated thetoof's tempgaussmc_beta1mod to support EEDI3 and NNEDI2. EEDI3 is very slow right now and IMO should only be used for testing until Tritical releases an optimized version. EEDI3 is enabled by default. Use EDImode="NNEDI2" to use NNEDI2.

http://www.sendspace.com/file/jyviyv

How did you combine EEDI3 and NEDI2 like you did in that NHL clip (the TGMC + EEDI3 + NEDI2 example):rolleyes:

[Revgen]

How did you combine EEDI3 and NEDI2 like you did in that NHL clip (the TGMC + EEDI3 + NEDI2 example):rolleyes:

It's the default EDIMode of the script I posted. It's the bold part of this section of the script.


# Create spatially interpolated bob-clips
dbob = clp.bob(0,0.5)
edi = (EdiMode=="EEDI3") ? clp.eedi3(field=-2,sclip=clp.nnedi2(field=-2))
\ : (EdiMode=="EEDI2") ? clp.SeparateFields().EEDI2(field=-2, maxd=EEDI2maxd)
\ : (EdiMode=="NNEDI2") ? clp.nnedi2(field=-2)
\ : (EdiMode=="Yadif") ? clp.Yadif(mode=1)
\ : dbob

[aegisofrime]

I had a glimpse at it back in the past ... frankly, I found the scripting style / script flow a bit unintuitive for me, so I let it be. ;)
My thoughts currently circle rather around TGMC (20-40% faster, perhaps make it 'lossless', ... )
And every day, the paper is crying for me, too ... (see sig.)

This was posted in another thread, but I thought it will be better to ask this question here.

I'm curious as to what you have in store for TGMC. It's a script that I use on a daily basis, so any speedup will be awesome! Also, JoshyD is porting quite a fair number of filters to 64-bit. Will 64-bit versions of TGMC's dependencies speed it up?

[Didée]

Can't tell you nothing about how things might be in 64bit land, so my answer to that is "perhaps". ;)

The mentioned speedup is simply achieved by replacing some of the generic MaskTools filters with faster counterparts. E.g. mt_luts(median) is a nice general tool, but rather slow. In the context of TGMC, it can be replaced with the much faster VerticalCleaner() by Kassandro. Another one (albeit smaller) is mt_inflate/deflate, the effect of which can be achieved faster by removegrain+mt_logic.

The improvement varies depending on which settings are used, of course. (I.e. when the inherently-slow NNEDI2 or EEDI2 is used, the improvement is much smaller, compared to using the pretty fast Yadif or plain-bicubic interpolators.)

Some rough speed numbers I got on the Core-2 machine were these:

TGMC(2,2,1,EdiMode="NNEDI2") : approx. +16%
TGMC(1,1,1,EdiMode="NNEDI2") : approx. +21%
TGMC(1,1,0,EdiMode="bicubic") : approx. +40%


I'll post the adapted script later today. Stockholm convinced me that the defaults also should be notched a little ... I'm not a too big fan of truemotion defaults, but the truemotion=false defaults are a bit too loose, either. lambda=400,pnew=25 seems more stable.

[aegisofrime]

Thanks for the reply! I'm sure many others using TGMC will be appreciative of the upcoming speedup :D

BTW, your ultrafast setting:


tempgaussmc_beta1u(1,1,0,0,0,0,edimode="--",SVthin=0.0,pelsearch=1)

Gives me 40fps on DVD resolution content without too much of a quality hit (In fact, it was nearly imperceptible, at least to my eyes.) I'm eager to see if I can get realtime with the upcoming speedup!

[Didée]

Alas, but no. Those settings are completely deactivating everything that is suspected to be sped up. In/Deflate is used in the safety-repair section, which here is completely switched of (the 2nd triple: "0,0,0"). And SVthin=0.0 also does deactivate that feature - and if it's not used, then it can't benefit from a faster median. ;)

[aegisofrime]

Oh I see. Well, hopefully with the speedup, a higher quality setting will give me the same speed as the ultrafast setting. :D

I have always been using TGMC(2,1,1,EdiMode="NNEDI2"), and that gives me about 10 fps. A bit ridiculous especially for 2 hours long DVD footage, but that's the price I have to pay for quality I guess!

One disadvantage of the ultrafast setting was that the encoded file is bigger than the "TGMC(2,2,1,EdiMode="NNEDI2")" one, but that's normal behavior right?

[Didée]

Sorry for I didn't post the mentioned update yet. I started with fiddling a "lossless" mode into TGMC (i.e. a mode that leaves the original fields untouched), and don't want to post a flood of new revisions every few days.
The inherent problem is the same old one ... you can easily get some residual combing, and measures to completely avoid this issue are very likely to also harm good detail, and/or to lose some of the temporal stability. Compromises of some sort have to be made.

The current implementation was made-up rather quickly. Visually, there is only little difference to TGMC-beta1. When things start to look very similar, numbers become more interesting, and so I made a quick test with MSU's measuring tool, compairing the bob-deinterlaced 576i Streams with the 576p50 reference.

Using the Stockholm sequence:
YadifMod(NNEDI2) : avg.PSNR = 34.779

TGMC(1,1,1,bicubic) : avg.PSNR = 36.135 (beta1u)

TGMC(1,1,1,bicubic) : avg.PSNR = 41.489 (beta2: "lossless")

It's only a "snapshot test", but it seems there is potential. ;)

[Revgen]

^Sounds like this "lossless" version can be used appropriately with functions like Srestore since it leaves the original fields unchanged.

Even if it misses some fields, I'm sure a quick vinverse() afterwards won't hurt much.

I'll be waiting to see it released.

[Didée]

Can't tell yet how it'll work with fieldblended footage, that's quite another game to play. For the moment I evaluate only with normal video-interlacing footage.
The code is knotty, but it's fun to finally see in "scientific" numbers what the eye has seen for a long time already. The current TGMC, even tough it gets "respectable" numbers in PSNR/SSIM tests, gets pretty much underrated by those. No wonder, because in the trade for stability it changes 100% of the frame. Other deint's may flicker and whatnot, but they have 50% of the frame correct to start with. And PSNR/SSIM don't care at all about temporal relations, while in the case of bobbing this is one of the most important factors! (Have told this already like ~10 years before when I came to digital video as a newbie ... everybody was so keen on PSNR back then, I told about the missing but important temporal relation, and of course nobody listened ...)

In any case, it's fun to see bobbers X-Y-Z doing ellbow-fighting in [the midrange of] 30db land, while TGMC happily roams in [the lower half of] 40db land, mostly.

I've one or two more things to try, and then the big knot in the script must be cleaned.

[Terka]

Hi Didee,
1. looking forward what the mastercook will serve us.
2. tried the 'noise bypass' technique using 2 mdegrains (both on bobbed=progressive clip)
where "limit" was different. so the most filickering parts
got away. (mostly horizontal lines). after that classical tgmc can be used. know that this is slow (2mdegrain), think that mvtools could be quite simply changed limit-> limitMIN, limitMAX so 1mdegrain will be needed

[tritical]

The results of TGMC are impressive, but it has to be stated (probably has been) that if there was ever a clip born to show the advantage of mc'd deinterlace it is that stockholm sequence :). Very high level of sharp detail, very slow stable pan (pure translation, just fast enough that motion-adaptation is useless) with no complicated motion to confuse mc.

[Didée]

Quite true, the Stockholm sequence is a dream of a perfect showcase example. However, the most important feature is that the dis/advantages are perfectly visible on this sequence. But the basic characteristics are pretty much the same on most other sequences, too. There's so many different things that can be tested. E.g. even when you have a source that has been very strongly lowpassed before interlacing (flicker reduction), so that the bobflicker is so much reduced that it's hardly visible anymore - if two bobbers look "almost the same" on such a source, but one bobber requires 25%~50% more bitrate on mpeg-compression compared to the other, what does that mean? :)
Also, at the very end of the Stockholm sequence the camera is still. Just a very few small objects are moving very slowly. Not much to do for MC there ... yet the new TGMC is still 1.5~2.0 db PSNR ahead over YadifMod(NNEDI2).
Another funny test is to simply knock out all original fields in a final comparison (since they're the same unchanged fields anyway), and compare only the interpolated fields to the respective reference. Guarantees for some funny numbers. (Or in the same spirit: bob-deinterlace, make a fresh interlaced source from only the interpolated fields, then bob-deinterlace *that*. Seriously, try that with a plain Yadif! Horror result!)

[Didée]

OK, another little test. A relaxed scenario, to not get accused of using "extreme" or "cherry-picked" sources that no filter except TGMC could ever handle. :rolleyes:

Contestants: TGMC-b2 lossless, tdeint(nnedi2), Yadif, YadifMod(nnedi2)

Source is ParkRun2 720p50, downsized to 576p for faster comparison.

The progressive source has been lowpassed before interlacing, to make things easier for the contestants. (So don't say the ultra-sharpness from not-lowpass'ing is the cause for the results.)

The snip is from the end of the sequence, frames 400-450. There is almost no motion in that snip, the camera is almost still. The overall scene shows minor subpixel-movement in the first half, the 2nd half is perfectly still. There is some slow motion in the water waves, though.
(So don't say it's the perfect horizontal translation which causes the results.)

Used Avisynth script:
RawSource("720p50_parkrun_ter.yuv",1280,720,"I420").assumetff()

spline16resize(720,576) # make 576p

blur(0,1).sharpen(0,0.75) # lowpass before interlacing

crop(40,0,-40,-0,true) # better preview on 1280-wide displays...

p = last # safe progressive reference

i = separatefields().selectevery(4,0,3).weave() # interlace

#-------------------------------------------------------------------

nnedi = i.NNEDI2(field=-2)

td = i.tdeint(mode=1,edeint=nnedi) # try a bobber
yad = i.Yadif(mode=1) # try another bobber
ydm = i.YadifMod(mode=1,edeint=nnedi) # and yet another bobber
tgmc = i.tempgaussmc_beta2(lossless=3) # and this one, too


comp1 = compare(yad, p)
comp2 = compare(ydm, p)
comp3 = compare(td, p)
comp4 = compare(tgmc,p)

stackhorizontal(comp1,comp2)
# stackhorizontal(comp3,comp4)
# comp1
# comp2
# comp3
# comp4

trim(400,450)


PSNR Results:


Yadif: starts with ~38.5db, ends with ~40.0db. oPSNR = 38.94

YadifMod: starts with ~39.5db, ends with ~41.0db. oPSNR = 39.68

tdeint: starts with ~36.0db, ends with ~41.8db. oPSNR = 37.44

TGMC-b2: starts with ~44.8db, ends with ~44.9db. oPSNR = 44.86


Video Sequences with PSNR measurements: LINK (http://www.mediafire.com/file/vuzojejhi2l/PSNR.rar) (Mediafire, ~16MB)


Let me repeat this isn't a cherry-picked example. That PSNR difference really is typical. I found only few cases where the difference is less, and quite a few where the difference is even bigger.



Temporal stability results:

(Encode to Xvid, q2, no Bframes, "flat-8" matrix. A practical way to watch out for switch-swatch bob shimmer.)

size % of TGMC % of ref

576p reference: 8760 kb (124%) 100%

TGMC-b2: 7023 kb 100% 80%

Yadif: 11148 kb 159% 127%

YadifMod: 10530 kb 150% 120%

tdeint: 10123 kb 144% 116%


Conclusion:
Compared to TGMC, all contestants have a noticably lower quality. (PSNR surely isn't the holy grail - but hey, a difference of 4~8 db is a darn lot, isn't it?)
Compared to TGMC, all contestants are remarkably less compressible. So in a realworld scenario, you start with a lower-quality source to begin with, and then would even need to compress it more strongly to achieve any given filesize, thereby reducing the quality even more.

Makes me wonder ... people happily use slow, slower and evenslower x264 settings to improve 2 percent here, another percent there. But when it's about vastly improved frame quality at vastly reduced birate, then no, thanks, it is too slow. Let's rather use the poor Yadif to quickly turn the source into a psychedelic something, then compress with insane x264 settings to no avail. Strange world.

[tritical]

The interesting thing to me is that in your second test the psnr difference between tdeint+nnedi2 is 37.4 vs 44.8 (7.4) and yet I can hardly tell the difference just watching the sample with the two side by side (maybe I have bad eyes and a crappy monitor). Whereas with the stockholm sequence the psnr difference is 34.7 vs 41.4 (6.7) and the difference is night and day. Actually, it doesn't surprise me since I have seen the same thing developing nnedi2 using squared error to train. Sometimes large psnr gains translate to almost zero visible improvement, whereas sometimes small gains translate to very visible differences (i'm talking gains over cilps containing frames from 50-60 sources). The hvs is very sensitive to differences in certain areas (clear defined structure) more than others ("busy" but somewhat random areas, like the trees and grass in that second sequence). Actually, if you have the time I'd be interested in the psnr numbers for nnedi2() alone and nnedi2 with qual=3 if it isn't too slow. :thanks: (maybe tdeint(mthreshL=-1,mthreshC=-1) also for just cubic interpolation with original fields preserved for kicks). Plus I am in no way trying to say that yadif is going to beat tgmc except for a rare clip or two, in fact I know its and tdeint's horrible scores on psnr tests well.

[Dogway]

Im having a problem setting qual=3 in tempgauss:

tempgaussmc_beta1u(2,2,3,EdiMode="NNEDI2",qual=3)

The encoding crashes at second pass. Its strange because qual=2 works nice, and qual=3 works nice on yadifmod. Do I have to call it as a variable? Do I have a wrong version? How do I know the version I have?

EDIT: Also when you say TGMC, is it the another version, or you just changed the function name?

[aegisofrime]

Great comparison videos there Didee. As far as I'm concerned TGMC has no competitors. Back when I was starting out in video editing, I tried a few trial versions of some commercial deinterlacing plugins for After Effects. None of them worked as well as TGMC.

Also, JoshyD seemed to have gotten TGMC running in 64-bit mode and is reporting significant speed differences. Should be interesting :cool:

Alright, I think I've got that temporal soften bug squashed, test it and let me know if there are any issues

I have TempGaussMC running . . . I'm showing some significant speed differences, anyone care to try there hand at it? I've got a four core machine, and telling AviSynth to use ~8 threads seems to be the sweet spot for processor utilization for me.

[Boulder]

Is the recommended way to deinterlace with TGMC (keeping the original frame rate) to simply use SelectEven or SelectOdd afterwards? Has anyone tested how it fares against other deinterlacers or is it expected that the results are very similar to Didée's tests?

[Didée]

tritical - will do those nnedi2 PSNR's, too. In fact, I definetly would be apt to do a more extensive comparison test, like you did (http://bengal.missouri.edu/~kes25c/deinterlace_comparison.txt) in the past. But you know it's quite an effort to do ... and the fact that my PC is from the beginning of this century doesn't exactly help. Would take me like half a year, and so I probably won't.

The results of PSNR often don't correlate well with HVS, that's oh so true. But that's known for long, and I don't feel like explaining the what-it-means, what-it-means-not, what-it-can-mean, and what-is-it-all-about every time such (mini-)tests are posted. People should know by now that PSNR does tell something, but is to be taken with a BIG grain of salt, and has to be interpreted in context. If they still don't know, so be it.


Dogway - no idea about the qual=3 issue with NNEDI2. Perhaps tritical has. "TGMC" of course is just a shorthand for quicker typing, and for using less space by subtitling. The new version still noone has, except me. ;)


aegisofrime - I'm far from being concerned with 64bit world (well, perhaps later this year, who knows...), but in any case, it seems JoshyD is doing a monster job there! Someone order him free beer for the rest of the year!


Boulder - yes, selecteven/odd is the only way to get samerate. It doesn't even create additional overhead. If "samerate" would be integrated as a feature into TGMC, it would be done in the very same way. The motion engine has to work with all fields anyway, so there's not really much chance to take any sort of "shortcuts" to achieve same-rate deinterlacing. SelectEven/Odd is fine.

Regarding the to-be-expected testing scores of same-rate deinterlacing: The PSNR scores will stay pretty much the same. PSNR/SSIM metrics work only spatially, so it doesn't matter all too much whether all frames are evaluated, or only every other frame. The actual numbers will change only little, the overall figures stay the same.

The "temporal stability", related to "compressibility", is another story. When bobbing, the major part of additional bitrate (compared to TGMC) comes from the flip-flop effect, which causes relatively big changes from one frame to the next. When doing same-rate, the effect is much smaller: the result no more goes flip-flop-flip-flop-.., but either flip-flip-flip,.. , or flop-flop-flop-... i.e. the switching-effect between frames is (mostly) not present anymore. That's much easier to encode.


In numbers:
With the settings given above, Yadif needed 50% more bitrate than TGMC. When doing same-rate, it needed 15% more bitrate. That's much less of a difference, but it's still not trivial. Also, see it in combination with visual quality, as follows.

In moving pictures:
"Shields" sequence, lowpass was done before interlacing, then doing same-rate deinterlacing.
(The shields sequence is nice because it features horizontal translation, static parts, and zoom-motion at the end. Zoom is a tricky situation.)

Sample: Yadif vs. TGMC.selecteven (http://www.mediafire.com/file/enw3mzzngwm/shields_samerate_Yadif-TGMC.avi) (~36MB, sorry it got a little big)

Look close, then tell me why Yadif is so "widely recommended" ... to me, it is visually much worse than any PSNR or compress numbers would ever suggest.

[Dogway]

XD I was about to ask what version was that too.

Actually something had to be on cache on tests because now not even qual=2 works after rebooting, ah, and it crashes just starting first pass. Strangely Avsp shows preview perfectly, can even framforward.
I narrowed my script so the error must be somewhere in there, I post it for if someone can lend a hand.

global MeGUI_darx = 257
global MeGUI_dary = 200

setmemorymax(768)
SetMTmode(5)
Loadplugin("C:\Windows\system32\MT.dll")

SetMTmode(2)
DGDecode_MPEG2Source("D:\MyLovely.d2v")
ColorMatrix(dest=2,hints=false,interlaced=true)

tempgaussmc_beta1u(2,2,3,EdiMode="NNEDI2",qual=3)
SRestore(FRate=23.976)
Dup(threshold=9,blend=false,copy=true,chroma=false,blksize=8,show=false)

trim(12281,22105)

[Boulder]

First of all, move the SetMTMode(2) line after the MPEG2Source. I'm also unsure whether SRestore works properly when multithreaded, weren't global variables a no-no?

[Didée]

tritical, here the PSNR results for NNEDI2 with qual=1|3, for non-adaptive tdeint with kernel interpolation, and for good old BOB(). Testbed setup was the same.

Filter settings:
- NNEDI2(field=-2,qual=1)
- NNEDI2(field=-2,qual=3)
- tdeint(mode=1,mthreshL=-1,mthreshC=-1)
- bob(0,0.5)


Quick numbers: (overall PSNR)

Parkrun2:
--------
NNEDI2(1) 33.10
NNEDI2(3) 33.29
tdeint 33.81
bob 33.45

Shields:
-------
NNEDI2(1) 38.47
NNEDI2(3) 38.62
tdeint 38.10
bob 37.96

Stockholm:
---------
NNEDI2(1) 39.15
NNEDI2(3) 39.26
tdeint 40.19
bob 38.63


Result screens: CLICKME (http://www.mediafire.com/file/mwndxmqzez2/PSNR%20results.rar)


Lesson learned: on my rusty 1core, running 2 times NNEDI2 in parallel is about the same speed as running TGMC. :D

[Didée]

I'm getting tired of it, so throw it out in the wild ...


TempGaussMC, version beta-2 (http://www.mediafire.com/file/ykyg5ymmzyw/TempGaussMC_beta2.rar).


Hope I've ruled out all mistakes, but you never know. If you find something, do speak.


What's changed:

- additionally requires VerticalCleaner.dll (http://home.arcor.de/kassandro/prerelease/VerticalCleaner.rar) by kassandro!! (->Info (http://videoprocessing.11.forumer.com/viewtopic.php?p=651))

- speedup by replacing slow-ish generic filters with faster alternatives. Depending on settings, 15% ~ 40% faster. Affected are several repair modes (tr0,tr1,tr2 parameters), and SVthin operation. When those are deactivated, there is no speedup either.

- introduced new "lossless" parameter:
-- lossless=-1 deactivates (default, same behaviour as has been)
-- lossless=0 is a dumb weave of original/TGMC fields. (Not for using! Just for demonstrating why it can't be done that easily.)
-- lossless=1 is a dumb weave with simple spatial correction.
-- lossless=2|3 use temporal compensation, followed by spatial correction. 2 is faster, 3 is calmer.

- optional "edeint" (clip) parameter. Works as known from tdeint and YadifMod. Useful e.g. when comparing several bob filters that all want to use NNEDI2 interpolation. May also safe from unnecessary script hacking when tritical comes up with NNEDI53 and EEDI427.

- adjusted some MAnalyse defaults:
-- "search" default is now "4" (was "2")
-- shifted the not-truemotion defaults for params "lambda"+"pnew" a little towards truemotion values.


Another side-effect of the "lossless" modes is that it makes the inherent noise-reduction of TGMC much weaker. That's no surprise: if the original fields stay really original, then they keep their noise, too.

[poisondeathray]

Thanks Didee!

I'm getting an error: Invalid arguments to "pointresize" , line 147

which corresponds to this in the .avsi downloaded from the link above


edi = default(edeint.pointresize(ox,oy, 0,-4,-0,oy+.001 ), edi)

[Stephen R. Savage]

@poisondeathray: You can just comment it out. It occurs because edeint was not set, resulting in it having the "void" type when PointResize expects the "clip" type for its first argument. Perhaps this is a 2.5.6 vs 2.5.8 thing.

Alternatively, I think the following works (why -4?):


edi = defined(edeint) ? edeint.pointresize(ox,oy, 0,-4,-0,oy+.001 ) : edi


I find that the new version is mostly similar to the original, but some of the characteristic ghosting artifacts of TGMC on cartoons are greater in this version.

[Didée]

Yes. I'm an idiot. Lately I checked only if edeint can be used - but forgot to check if it can be not used. That, and a misunderstanding-in-detail of the script parser.

Link updated, please get the new one.

[poisondeathray]

Thanks, it works fine now

[Didée]

(why -4?)
Because the script blindly assumes that the optional "border" parameter is set to default, and never set to false by the user. If done so nonetheless, I imagine funny results.

Stupidness corrected. This gave me also time to switch chroma-repair on again, which was completely switched off.

The link is updated again, I am an idiot, you download once more.

[Dogway]

Nice for sharing, it helped me spot the error on my little test script. Now it even doesnt preview on avsp, the conflict was with the dup filter. I can either yadif+dup, or tgmc+nodup. Anyways it looks like a buggy filter... any alternative?

[poisondeathray]

Nice for sharing, it helped me spot the error on my little test script. Now it even doesnt preview on avsp, the conflict was with the dup filter. I can either yadif+dup, or tgmc+nodup. Anyways it looks like a buggy filter... any alternative?

Something similiar happened to me on 1 computer but not the other.... I finally found out the PC that didn't work does not have SSE3 instruction set, so I removed VerticalCleanerSSE3.dll and it worked fine after that; I don't know if this will help you

[WorBry]

Thanks for the 'official' beta2 update Didee :)

Played around about a bit with the lossless modes. Cant see myself using them, at least with my home DV sources - prefer "no residual combing", even if that is at the expense of a little more blur.

One thought though. For denoising interlaced material, I normally bob (with YadifMod-NNEDI2), denoise with MDegrain and reinterlace, based on the understanding that denoising on bob-deinterlaced frames is preferable to denoising on separated fields. Since TGMC_beta2, in lossless modes, now preserves (i.e does not distort) the original fields, do you see it offering any particular benefit purely for denoising interlaced material, or would I be better sticking to my existing method, maybe adding some repair and contra-sharpening to the denoised output before reinterlacing (like TemporalDegrain)?

[Terka]

Didee
Thank you for next version!

WorBry
Please post some samples where you get combing. (DV source)

[Dogway]

(...)didn't work does not have SSE3 instruction set, so I removed VerticalCleanerSSE3.dll and it worked fine after that(...)

Yes it worked! Thanks for that, although my cpu has SSE3, its a core 2 duo...

Anyway I think that only fixes my last problem, Im gonna run some more tests.

EDIT2: OK the error was here:

tempgaussmc_beta2(2,2,3,EdiMode="NNEDI2")
SRestore(FRate=23.976)

It seems I cant decimate from 59.94fps

[Didée]

WorBry -
the denoising question is a bit too complex to elaborate in detail now. Generally/technically, I assume that TGMC in lossless mode should fair better. Since it's more stable on temporal axis, the motionsearch of the actual denoising should find better matches, resp. matches with a lower SAD. In result, there simply should be more denoising taking place. If that's a visual benefit in the end, or if it's not, that can't be said beforehand. Case specific, Settings specific, personal-taste-specific. ;)


Terka & WorBry -
When using the lossles mode, the result is really prone to contain some residual combing. The temporal correction corrects mostly the temporal stability (try lossless=0 to see how much that shimmers again), but helps only little against combing artifacts. And the spatial correction catches some, but not all combing. In short, the spatial anticomb just looks for any interlaced clusters being at least 3 pixels in height (via the Frame-VerticalMedian>Field-VerticalMedian/Repair combo). It's the "easiest" method I found to catch as much as possible, in little time, with as little harm to good detail as possible. But the method necessarily will miss combing that doesn't meet the 3-pixel-height criteria. Such may be found e.g. on thin moving objects, or around diagonally (or near-horizontal) oriented edges.
I don't expect the lossless mode to be "perfect" in any way. It was just done to (optionally) make TGMC a "clinic" bobber. Users might insist on that lossless-ness - either because they really need it, or because they *think* they *would* need it (where in fact they don't;) ). It was just when i had the idea of temporal re-correction, of course I had to try it. And since it turned out quite usable, here it is now.

And lastly, it is a way to make TGMC shine not only visually, but also in those overrated metric tests. The lossy TGMC doesn't fair too badly in those tests (always competitive, oftentimes winner), but it definetly gets underrated for the reasons mentioned earlier. Its PSNR results simply do not justify its potential visual quality. Now, with the lossless mode, the scores are much better, even if the naked eye can not see much of a difference.

Example result for Stockholm - old beta1 on the left, new beta2 to the right:
http://thumbnails24.imagebam.com/7012/f6ed3770112247.gif (http://www.imagebam.com/image/f6ed3770112247)

No matter the result looks almost the same visually - An increase of yet another +4.8 db PSNR makes a good figure when put into some random comparative table. ;)

[Terka]

Didee,
the beta2 looks promising. (Speaking about visual, the PSNR is not important for me.)
the artifacts are present, but ist mostly ok.
plase have a look at some questions below:
have one clip where it is a bit unpleasent - skiing video,
poles of a skier - some ghosting and/or stairsteping
http://rapidshare.com/files/357446100/ski.avi
how could the default setting be tuned?
im still testing.
(on dogs clip the lossless is nice.)