exist any filter specially done for (deinterlace) flicker

[Terka]

mcbob 1.1fps
TempGaussMC(): 0.3 fps
some of my plugins is old :(
it was masktools, now got
TempGaussMC(): 1.6 fps

[WorBry]

Like this: LAA(last, 96, 10, true, 2.0) :)

Thanks. Not bad, but pretty much the same result as 'Anti-aliasing' script:

http://avisynth.org/mediawiki/AntiAliasing

Note the residual 'hatching' on the white base-board and red pole in the last scene of the DV sample I put up.

Didnt really want to turn this into an 'anti-aliasing' thread per se. Was more interested in the potential application of TempGaussMC in this area.

Edit: PS - I note that this also works quite well on the aliasing:

SeparateFields()
merge(SelectEven().EEDI2(),SelectOdd().EEDI2(),0.5)

But then you start to see more disruption and shimmering of high contrast line patterns (e.g. the striped red shirt in the last scene), and even more so with NNEDI:

SeparateFields()
merge(SelectEven().nnEDI(dh=true,field=1),SelectOdd().nnEDI(dh=true,field=0),0.5)

Hence the notion that this might be resolved by applying similar temporal treatments to those employed by TempGaussMC.

[Terka]

did some tests on TempGaussMC and its really good! :thanks:
Have some questions:
1.

is the (tr0==0) correct? (default is 2, so default will end with t1.merge(t2,0.357).merge(dbob,0.125))

t = (tr0==0) ? dbob
\ : (tr0==0) ? t1.merge(dbob,0.25)
\ : t1.merge(t2,0.357).merge(dbob,0.125)


2. if i understand the behaviour correctly, TempGaussMC is mostly denoiser which is suited for deinterlace. Didee feed it with yadif or "nnedi deinterlacer"... . If feeded with mv/mcbob will be the fesults even better?

3. Scharfi sugested to put some stabilization into. If this to do, where in the chain to put into?
bob-stabilize-TempGaussMC
or
bob-TempGaussMC-stabilize?
thank you!

[Didée]

It's amazing how much small bugs sneak into my posted scripts ...

1. No, of course that's not correct. The 2nd condition has to be "tr0==1".
Moreover there was a bug that causes an error for TGMC(tr2=3) ... a stupid syntax thingy.

Both bugs have been corrected, the function in post#13 is bugfree now. (Hopefully.)

I've another update pending. It'll cover an adapted sharpen mode (stronger in vertical direction, since that direction gets blurred more), and an option for rep1 acting a bit better.


2. Some improvements may be possible that way, but most probably it'll be minor improvements with major effort. TempGaussMC will average away much of the benefits that any motion-compensate bob will feed it with.
The other way round would be much better: Make a motion-compensated bob that uses TempGaussMC as basis for vector search, comparisons, etc. (Subsequently, this poses a pile of questions again, can't dive into that right now...)


3. Can't say much to that, for some reason DepanStabilize doesn't even work correctly for me. Besides, scharfis_brain didn't suggest stabilization. It was in the script posted by map1742, scharfis_brain just talked about the order of steps in that script.

[Terka]

Didee,
thank you for explanation.

[WorBry]

Any thoughts on my query about applying the temp gauss to progressive material? :(

Although applying Merge(SelectEven(), SelectOdd(), 0.5) to the output gives quite good results, I realize that the gauss itself has been applied over (near identical) dupe frames which will have disrupted the motion flow.

Tried tinkering myself, using merged dupes from the dbob and edi, or replacing dbob with the source clp itself, but I suspect this is screws up the temp gauss and mask tuning etc. I’m wondering if applying the gauss to the masked difference between the dupe frames and then adding this back to the merged dupes, might be a better approach, but am unsure how to set this up and what would be the better source for the dupes, a dbob or edi?

Do you think this would be a valid approach or am I completely off whack?

Cheers.

[Didée]

Well, I'm not sure what to say about that. Applying it to progressive material, the effect can be denominated as ...

a) (pragmatic version) ... a mix of spatial softening and temporal smoothing. :rolleyes:

b) (PR department version) ... spatio-temporal super-resolution filter. :cool:


Mixing in the way of

AnyBobFilter()
Merge( SelectEven(), SelectOdd() )

is the (mostly) spatial part. The motion-compensated parts of the script will partly consolidate the spatial part (one temporal neighbor is in fact the other spatial field), the rest will manipulate the spatial resolution by temporal processing after motion compensation.

So what to say? It does something, not necessarily something bad, but neither tuned to do something particularily good.

The funny thing about your progressive sample is that there's aliasing in some places, but not everywhere. The aliasing seems to happen mostly in high-contrast areas, but then again, not in all high-contrast areas. For that reason it's hard to find something that acts on only the aliased parts ... the problem is how to identify them.

Somewhen, somewhere, there was a thread by Chainmax about removing aliasing, where I had extracted the averaged-EEDI2-with-contrasharpening-method out of MCBob into a standalone script. Might be worth a try, too.

[thetoof]

If this (http://forum.doom9.org/showthread.php?t=118784) is the thread you're talking about, the AA script would be this, right?
c=last
dbl = mt_average(c.nnedi(field=1),c.nnedi(field=0),U=3,V=3)
dblD = mt_makediff(c,dbl,U=3,V=3)
shrpD = mt_makediff(dbl,dbl.removegrain(11),U=3,V=3)
DD = shrpD.repair(dblD,13)
dbl.mt_adddiff(DD,U=3,V=3)

[WorBry]

Yes, I assume thats the one also, or for EEDI2 and BFF clip:

o=last
AssumeBFF().SeparateFields()
dbl = mt_Average( SelectEven().EEDI2(field=0, maxd=4),
\ SelectOdd() .EEDI2(field=1, maxd=4), U=3,V=3 )
dblD = mt_MakeDiff(o,dbl,U=3,V=3)
shrpD = mt_MakeDiff(dbl,dbl.RemoveGrain(11),U=3,V=3)
DD = shrpD.Repair(dblD,13)
dbl.mt_AddDiff(DD,U=3,V=3)

Problem there is that even with the EEDI2 maxd set down to 4, there is still some disruption of high contrast line patterns (like on the striped shirt in scene 3 of the clip). Dropping to maxd=2 helps to avoid this but then the anti-aliasing is less effective. Maxd=3 seems to offer a reasonable compromise.

The NNEDI version looks better in some areas (e.g. a bit less shimmering of figures on wall posters in scene 2, although more than in the original clip), but there appears to be more degradation of fine line patterns (e.g. striped shirt).

[WorBry]

@Didee,

Tinkered a bit with the AA script above; found that applying the RemoveGrain (11) kernel blur diff to the unmerged EEDI2 bob and using a DumbBob (rather than the source clip itself) as the reference for the repair, before finally merging the even and odd output frames, helped to reduce the flickering/shimmering of objects (like the figures on the wall posters in scene 2) that were quite stable in the original clip. Seemed a valid approach since the treatment is primarily spatial i.e. no temporal component to be confused by dupes.

AVISource("E:\... \Test Mix Frame Mode 16.9 DV Type 2.avi")
o=last.AssumeBFF()
dbob=o.Bob()
edibob=o.SeparateFields().EEDI2(field=-2, maxd=3)
ediD = mt_MakeDiff(dbob,edibob,U=3,V=3)
shrpD = mt_MakeDiff(edibob,edibob.RemoveGrain(11),U=3,V=3)
DD = shrpD.Repair(ediD,13)
AddDD = edibob.mt_AddDiff(DD,U=3,V=3)
Mrgeo = merge(AddDD.SelectEven(),AddDD.SelectOdd(),0.5)
return( Mrgeo )

It also helped to smooth out the more stubborn aliasing (like the ‘quilting’ on the white base boards in scene 3). Predictably however, the mod resulted in slight increase in blurring.

Having seen what TempGaussMC can do, can’t get away from this (maybe misplaced) notion that a modified version (or the guts of it) that uses the merged (averaged) even and odd frames from the dumbbob (as source for the 'pre-mc' temp gauss) and likewise for the edi-bob (for the mo-comp/interp etc part), would provide anything other than an improved result (i.e. effective anti-aliasing whilst avoiding by-product flickering of 'stable' objects) for progressive DV sources such as this, even if inconsistencies in the appearance of aliasing and 'line-twitter' (love that phrase) make it more difficult to tune precisely.

Any chance you could put the usual (greyed-out) brief explanation of what each segment of the script does in the next TempGaussMC update; maybe I could get my head around it enough to have a stab (in the dark) at it? :rolleyes:

Unless of course you do have a ‘spatio-temporal super-resolution filter’ up your magician's sleeve? ;)

BTW - I'm continuing to get consistently excellent results with TempGaussMC as I test more interlaced material. Really is a superb processor.

Edit: In the routine for preparing the searchclp for the mo-comp, what added effect does RemoveGrain(11).RemoveGrain(11) as compared to single RemoveGrain(11)? I'm assuming more sharpening, which in the context of the mt_diff will mean more blurring and so smoothing of the mv's...correct?

[Terka]

Some idea, maybee worth maybee not.
o=original lines
b=bobbed (computed) lines
t=original tempgaussed
T=bobbed tempgaussed
-=no lines

orig:
o-o
-o-

bobbed:
obo
bob

bobbed tempgaused:
tTt
TtT

to do (is easy):
oTo
ToT

n=new way of using TG
to do:
ono
non

Lets use the TempGausMC usual way for deinterlace:
Use the original lines & the deinterlaced-TempGaussed.
So because TGMC changes original lines too, after
joining o with bt will improve sharpness, but increase flicker.
So let the TG more change the b, not the o.
Ive seen somewhere that for mcdenoisig is used some duplication of frames,
to increase their weight.It was something like:
ooobOOO , o=(1.frame ),O=(2.frame)
so the b=bobbed one will be changed more than the o=O=original.

[WorBry]

@Terka, Cant say I fully understand what you are suggesting…..assuming it was directed to me.

Basically, this is what I was thinking of as a working basis for progressive sources (noting disclaimer at end of post):

Either this
function TempGaussMC_mod(clip clp, int "tr0", int "tr1", int "tr2", float "sharpness", bool "rep0", bool "rep1", int "border", int "blocksize", int "overlap", string "EdiMode", int "draft")
{
tr0 = default( tr0, 2 ) # temporal radius for temporal Gauss before motion compensation (1 or 2)
tr1 = default( tr1, 2 ) # temporal radius for temporal Gauss with motion compensation (1 or 2)
tr2 = default( tr2, 1 ) # temporal radius for final MVDegrain (1, 2 or 3)
rep0 = default( rep0, true ) # repair temporalsoften-defects for searchclip
rep1 = default( rep1, true ) # repair MVDegrain-defects for output
border = default( border, 1 ) # 1 = padd borders internally to catch "half scanlines" at top + bottom (broadcast material)
bs = default( blocksize,8) # Blocksize for motion search
ovlp = default( overlap,bs/2) # Overlap size for ME blocks
sharpness = default( sharpness, 0.25+(tr1+tr2)/8.) # "inloop" sharpening to counteract softening, 0.0 to 1.0, or more if you like
EdiMode = default( EdiMode, "NNEDI") # interpolator to use: "NNEDI", "EEDI2"
draft = default( draft, 0 ) # '1' outputs a quick draft, and '2' is even more draft'ier :p

trmax = (tr1 > tr2) ? tr1 : tr2
nullclip = blankclip(clp,width=16,height=16)

clpo = (border==0) ? clp
\ : clp.pointresize(clp.width(),clp.height()+8, 0,-4,-0,clp.height()+8.001 )

clps = clpo.AssumeBFF().SeparateFields()

eeddbl = mt_Average(clps.SelectEven().EEDI2(field=0, maxd=4),
\ clps.SelectOdd().EEDI2(field=1, maxd=4), U=3,V=3 )

nnedbl = mt_average(clpo.nnedi(field=0),clpo.nnedi(field=1),U=3,V=3)

edidbl = (EdiMode=="NNEDI") ? nnedbl
\ : eeddbl

dbdbl = mt_average(clpo.Bob().SelectEven(),clpo.Bob().SelectOdd(),U=3,V=3)

t1 = dbdbl.temporalsoften(1,255,255,32,2)
t2 = dbdbl.temporalsoften(2,255,255,32,2)

t = (tr0==0) ? dbdbl
\ : (tr0==1) ? t1.merge(dbdbl,0.25)
\ : t1.merge(t2,0.357).merge(dbdbl,0.125)

tD = mt_makediff(dbdbl,t,U=3,V=3)
tD1 = tD.mt_inpand(mode="vertical",U=3,V=3).mt_deflate(U=3,V=3) .mt_expand(U=3,V=3)
tD2 = tD.mt_expand(mode="vertical",U=3,V=3).mt_inflate(U=3,V=3) .mt_inpand(U=3,V=3)
tDD = tD.mt_lutxy(tD1,"x 129 < x y 128 < 128 y ? ?",U=3,V=3).mt_lutxy(tD2,"x 127 > x y 128 > 128 y ? ?",U=3,V=3)
t2 = (rep0==true) ? t.mt_adddiff(tDD,U=3,V=3)
\ : t

searchclip = t2.removegrain(11).removegrain(11)
searchclip = (rep0==true) ? searchclip
\ : searchclip.mt_lutxy(edidbl,"x 2 + y < x 2 + x 2 - y > x 2 - y ? ?",U=3,V=3)

#bs = 16
#ovlp = 4
tm = false
pel = 2
shrp = 2

bvec3 = (trmax>=3) ? searchclip.MVAnalyse(isb=true, delta=3,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=6) : nullclip
bvec2 = (trmax>=2) ? searchclip.MVAnalyse(isb=true, delta=2,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=6) : nullclip
bvec1 = searchclip.MVAnalyse(isb=true, delta=1,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=6)
fvec1 = searchclip.MVAnalyse(isb=false,delta=1,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=6)
fvec2 = (trmax>=2) ? searchclip.MVAnalyse(isb=false,delta=2,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=6) : nullclip
fvec3 = (trmax>=3) ? searchclip.MVAnalyse(isb=false,delta=3,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=6) : nullclip

mvdg1 = edidbl.MVDegrain1(bvec1,fvec1, thSAD=800,idx=7)
mvdg2 = (tr1>1) ? edidbl.MVDegrain1( bvec2,fvec2,thSAD=800,idx=7) : nullclip

stage1 = (tr1==0) ? edidbl
\ : (tr1==1) ? mvdg1.merge(edidbl,0.25)
\ : mvdg1.merge(mvdg2,0.2).merge(edidbl,0.0625)

stage1a = stage1.mt_lutxy(stage1.removegrain(11),"x x y - "+string(sharpness)+" * +",U=3,V=3)
stage1b = (sharpness==0.0) ? stage1 : stage1a.repair(stage1a.repair(edidbl,12),1)

stage2 = (tr2==0) ? stage1b
\ : (tr2==1) ? stage1b.MVDegrain1(bvec1,fvec1, thSAD=400,idx=8)
\ : (tr2==2) ? stage1b.MVDegrain2(bvec1,fvec1,bvec2,fvec2, thSAD=400,idx=8)
\ : stage1b.MVDegrain3(bvec1,fvec1,bvec2,fvec2,bvec3,fvec3,thSAD=400,idx=8)

tD_2 = mt_makediff(dbdbl,stage2,U=3,V=3)
tD1_2 = tD_2.mt_inpand(mode="vertical",U=3,V=3).mt_deflate(U=3,V=3) .mt_expand(U=3,V=3)
tD2_2 = tD_2.mt_expand(mode="vertical",U=3,V=3).mt_inflate(U=3,V=3) .mt_inpand(U=3,V=3)
tDD_2 = tD_2.mt_lutxy(tD1_2,"x 129 < x y 128 < 128 y ? ?",U=3,V=3).mt_lutxy(tD2_2,"x 127 > x y 128 > 128 y ? ?",U=3,V=3)

stage3 = (draft==2) ? t .subtitle("Draft 2")
\ : (draft==1) ? t2 .subtitle("Draft 1")
\ : (rep1==true) ? stage2.mt_adddiff(tDD_2,U=3,V=3)
\ : stage2

(border==0) ? stage3
\ : stage3.crop(0,4,-0,-4)

return( last )
}

Or maybe this:

function TempGaussMC_mod2(clip clp, int "tr0", int "tr1", int "tr2", float "sharpness", bool "rep0", bool "rep1", int "border", int "blocksize", int "overlap", string "EdiMode", int "draft")
{
tr0 = default( tr0, 2 ) # temporal radius for temporal Gauss before motion compensation (1 or 2)
tr1 = default( tr1, 2 ) # temporal radius for temporal Gauss with motion compensation (1 or 2)
tr2 = default( tr2, 1 ) # temporal radius for final MVDegrain (1, 2 or 3)
rep0 = default( rep0, true ) # repair temporalsoften-defects for searchclip
rep1 = default( rep1, true ) # repair MVDegrain-defects for output
border = default( border, 1 ) # 1 = padd borders internally to catch "half scanlines" at top + bottom (broadcast material)
bs = default( blocksize,8) # Blocksize for motion search
ovlp = default( overlap,bs/2) # Overlap size for ME blocks
sharpness = default( sharpness, 0.25+(tr1+tr2)/8.) # "inloop" sharpening to counteract softening, 0.0 to 1.0, or more if you like
EdiMode = default( EdiMode, "NNEDI") # interpolator to use: "NNEDI", "EEDI2"
draft = default( draft, 0 ) # '1' outputs a quick draft, and '2' is even more draft'ier :p

trmax = (tr1 > tr2) ? tr1 : tr2
nullclip = blankclip(clp,width=16,height=16)

clpo = (border==0) ? clp
\ : clp.pointresize(clp.width(),clp.height()+8, 0,-4,-0,clp.height()+8.001 )

clps = clpo.AssumeBFF().SeparateFields()

eeddbl = mt_Average(clps.SelectEven().EEDI2(field=0, maxd=4),
\ clps.SelectOdd().EEDI2(field=1, maxd=4), U=3,V=3 )

nnedbl = mt_average(clpo.nnedi(field=0),clpo.nnedi(field=1),U=3,V=3)

edidbl = (EdiMode=="NNEDI") ? nnedbl
\ : eeddbl

t1 = clpo.temporalsoften(1,255,255,32,2)
t2 = clpo.temporalsoften(2,255,255,32,2)

t = (tr0==0) ? clpo
\ : (tr0==1) ? t1.merge(clpo,0.25)
\ : t1.merge(t2,0.357).merge(clpo,0.125)

tD = mt_makediff(clpo,t,U=3,V=3)
tD1 = tD.mt_inpand(mode="vertical",U=3,V=3).mt_deflate(U=3,V=3) .mt_expand(U=3,V=3)
tD2 = tD.mt_expand(mode="vertical",U=3,V=3).mt_inflate(U=3,V=3) .mt_inpand(U=3,V=3)
tDD = tD.mt_lutxy(tD1,"x 129 < x y 128 < 128 y ? ?",U=3,V=3).mt_lutxy(tD2,"x 127 > x y 128 > 128 y ? ?",U=3,V=3)
t2 = (rep0==true) ? t.mt_adddiff(tDD,U=3,V=3)
\ : t

searchclip = t2.removegrain(11).removegrain(11)
searchclip = (rep0==true) ? searchclip
\ : searchclip.mt_lutxy(edidbl,"x 2 + y < x 2 + x 2 - y > x 2 - y ? ?",U=3,V=3)

#bs = 16
#ovlp = 4
tm = false
pel = 2
shrp = 2

bvec3 = (trmax>=3) ? searchclip.MVAnalyse(isb=true, delta=3,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=6) : nullclip
bvec2 = (trmax>=2) ? searchclip.MVAnalyse(isb=true, delta=2,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=6) : nullclip
bvec1 = searchclip.MVAnalyse(isb=true, delta=1,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=6)
fvec1 = searchclip.MVAnalyse(isb=false,delta=1,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=6)
fvec2 = (trmax>=2) ? searchclip.MVAnalyse(isb=false,delta=2,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=6) : nullclip
fvec3 = (trmax>=3) ? searchclip.MVAnalyse(isb=false,delta=3,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=6) : nullclip

mvdg1 = edidbl.MVDegrain1(bvec1,fvec1, thSAD=800,idx=7)
mvdg2 = (tr1>1) ? edidbl.MVDegrain1( bvec2,fvec2,thSAD=800,idx=7) : nullclip

stage1 = (tr1==0) ? edidbl
\ : (tr1==1) ? mvdg1.merge(edidbl,0.25)
\ : mvdg1.merge(mvdg2,0.2).merge(edidbl,0.0625)

stage1a = stage1.mt_lutxy(stage1.removegrain(11),"x x y - "+string(sharpness)+" * +",U=3,V=3)
stage1b = (sharpness==0.0) ? stage1 : stage1a.repair(stage1a.repair(edidbl,12),1)

stage2 = (tr2==0) ? stage1b
\ : (tr2==1) ? stage1b.MVDegrain1(bvec1,fvec1, thSAD=400,idx=8)
\ : (tr2==2) ? stage1b.MVDegrain2(bvec1,fvec1,bvec2,fvec2, thSAD=400,idx=8)
\ : stage1b.MVDegrain3(bvec1,fvec1,bvec2,fvec2,bvec3,fvec3,thSAD=400,idx=8)

tD_2 = mt_makediff(clpo,stage2,U=3,V=3)
tD1_2 = tD_2.mt_inpand(mode="vertical",U=3,V=3).mt_deflate(U=3,V=3) .mt_expand(U=3,V=3)
tD2_2 = tD_2.mt_expand(mode="vertical",U=3,V=3).mt_inflate(U=3,V=3) .mt_inpand(U=3,V=3)
tDD_2 = tD_2.mt_lutxy(tD1_2,"x 129 < x y 128 < 128 y ? ?",U=3,V=3).mt_lutxy(tD2_2,"x 127 > x y 128 > 128 y ? ?",U=3,V=3)

stage3 = (draft==2) ? t .subtitle("Draft 2")
\ : (draft==1) ? t2 .subtitle("Draft 1")
\ : (rep1==true) ? stage2.mt_adddiff(tDD_2,U=3,V=3)
\ : stage2

(border==0) ? stage3
\ : stage3.crop(0,4,-0,-4)

return( last )
}

In both cases, I knocked off the Yadif option as I would never use it in this context. As they stand (with Tr0=2, Tr1=2, Tr2=2), both give quite decent results. The only problem area appears to in preserving uniform definition and integrity of high contrast line patterns (like the striped shirt in scene 3 of the clip I posted), notably when objects move over them. Again, dropping the EEDI2 maxd (from 8 to 4) seems to help a little.

Can’t see what parameters other than maybe the temp gauss weightings might be open for further tweaking, and I didn’t touch them. Any thoughts Didee? (hopefully other than ‘why are you still blindly screwing around with a script that wasn’t created for this purpose’ )

Writes hasty disclaimer: the above scripts are in no way intended to be taken as accepted modifications of the TempGaussMC function created by Didee for interlaced sources. They merely serve to illustrate possible approaches for applying a similar treatment to progressive/frame-based material that exhibits various forms of aliasing artifact.

[WorBry]

Didee,

After playing around with the first of the two scripts I posted above (“TempGaussMC_Mod") I discovered that setting Tr0=0 (i.e. disabling the pre-mocomp temp gauss) appeared to better preserve the definition and integrity of high contrast line patterns (like the striped shirt in 25p clip I provided), whilst still retaining good anti-aliasing effect and minimal flickering/shimmering of objects that, in the original clip, were fairlystable - more or less the outcome I have been aiming for.

I hadn’t realized that Tr0=0 was possible until I followed the script process path. So, in this case the searchclip that derives the motion vectors for the mocomp gauss becomes entirely modulated by the kernel blur (the contrasharpen bit), which I assume is entirely spatial.; possibly the reason why the edges of the stripes still appeared a bit rough.

So, starting with Tr0=1, I tried decreasing the strength of the pre-mocomp gauss, by incrementally increasing the weighting of the ‘un-softened’ dbdbl from default 0.25 through to 0.95. To my eyes, the optimum seems to be around 0.55 – 0.60.

Changing the EEDI2 maxd value from 4 to 6 (originally 8) also seemed optimal.

Question is:

a) How does one derive the weightings for the tr0=2 gauss? Simple extrapolation would give:

t1 = dbdbl.temporalsoften(1,255,255,32,2)
t2 = dbdbl.temporalsoften(2,255,255,32,2)

t = (tr0==0) ? dbdbl
\ : (tr0==1) ? t1.merge(dbdbl,0.6)
\ : t1.merge(t2,0.8568).merge(dbdbl,0.3)

Would this be correct or is the calc more involved?

b) Is it valid to make such changes without impacting the post-mo-comp gauss weightings, which seem OK as they are?


Thanks a lot.

BTW- how’s the new update coming on? I’m keen to start using TempGaussMC on my interlaced DV stuff, but will hold off if there are going to be further improvements.

[Didée]

@ Terka:

Well, where to start ... [deep breath] ...

What you bring up there is by all means valid. But do you realize that, in last instance, the result is something totally different ... ?
You can't just hop in and "change the o's less, and give more weight to the o's when doing the averaging for the b's". Consequentially, one would have to leave the o's perfectly untouched, and give ALL weights to the o's when doing the averaging for the b's. But then, this is nothing else but putting the compensations of the neighbor frames into the "b" lines of the current frame. And that's basically just what MVBob or MCBob are already doing.

The "strength" of TempGaussMC comes from the fact that changing the original data is allowed. This also allows to handle the problem of "the data missing in this frame is also missing in the neighbor frames" (vertical motion by an odd numer of pixels). For a lossless MV-Bobber this case is problematic, whereas TempGaussMC inherently uses a "prophet-and-mountain" - way to handle this case: if the prohet won't come to the mountain, then the mountain has to come to the prophet.

Also, when using the strict way of giving 100% weight to the compensations, then new problems arise from the side of motion-compensation: you then need to be *very* careful in checking whether the compensation is valid or erroneous; and ideally should also check whether the compensation for the current "b" line actually is delivering an "o" from the neighbor, or just the neighbor's "b" in turn.

In contrast, the way TempGaussMC is working is much more fuzzy, that's why it can get away with much less checking of all those things. And that's the bottom line: TempGaussMC works surprisingly good with a rather simplistic approach, and it should be left that way. Trying to make any improvements to the basic methodology will only result in something that we already have, in shape of MV/MC-Bob.



@ WorBry:

Regarding the weightings, I'm not quite sure ... perhaps the easiest way is to just use the "repeating" way (which is a valid way to get gaussian weightings for arbitrary radii), just with your preferred weighting instead:


t1 = dbdbl.temporalsoften(1,255,255,32,2).merge(dbdbl,0.6) # for gauss, this weight is 0.25
t2 = t1 .temporalsoften(1,255,255,32,2),merge(t1, 0.6) # for gauss, this weight ALSO is 0.25

t = (tr0==0) ? dbdbl
\ : (tr0==1) ? t1
\ : t2
(BTW, note that those merge-weightings in TempGaussMC are not directly related to gaussian weightings, regarding the numbers as such. They just deal to get the gaussian [1-2-1] or [1-4-6-4-1] out of the linear [..-1-1-1-..] of TemporalSoften.)

Still, for your case of AA'ing progressive input this is a try'n'error thing without obvious justification. For the case of bobbing, the temp-gauss'ing deals a very specific and necessary purpose: to average-away the bob jumping. For your case, the effect (if any) is more or less ~random~. What has to be avoided in your case is that the motion search between frames snaps in to the aliasing. And in the case of zero motion, the effect of the initial temporal averaging is exactly zero. When there is motion, then it may or may not help, IMHO that's unpredictable. My guess is that with exhaustive investigation, you might find that a weight of X is ideal for this spot, weight Y is ideal for that spot, weight Z is ideal for other spots ...

Lately I started looking at something else: Let EDI do a self-validation by using a "back-interpolation" instance, in order to judge whether a given EDI interpolation at a given place seems reasonable or not. Method: construct a frame consisting ONLY of EDI-interpolation. From this constructed frame, again construct a frame consisting ONLY of EDI-interpolation. In places where EDI does "good" interpolation, the 2nd interpolation should be reasonably close to the original frame. In places where EDI does "bad" interpolation, the 2nd interpolation can be expected to be fairly different to the original frame.
Quickly knocking together the first part (full interpolation & back-interpolation) and looking at the resulting differences, it seems pretty reasonable, but I've yet to see if one can get a tight enough grip on the problematic areas.

[WorBry]

My guess is that with exhaustive investigation, you might find that a weight of X is ideal for this spot, weight Y is ideal for that spot, weight Z is ideal for other spots ...

Yes, that's pretty much been my experience. Think I've got it down for one test clip and then apply it to another...not quite as good...more tweaking. In addition, whilst I am acheiving (on balance) better 'subjective' results than any other anti-aliasing method I've tried, as I test more material I'm coming across some instances of aliasing ('quilting' in particular') that I just cannot budge....or fudge.

This inconsistent and seemingly erratic pattern of aliasing in frame-mode DV material has been noted by others and some have suggested that it stems from the offset timing of the green CCD in the pixel shift, resulting in some color/hue edges being more affected than others, although how they know this for certain when the process involved in constructing the 'pseudo-progressive' frame has never been fully disclosed (at least for the GS400). A similar explanation has also been offered for a slight loss in chroma resolution observed in frame-mode, compared to normal interlaced.

I was thinking of playing around with chroma thresholds to see if I could get a better result, but, even if this 'green CCD timing' is the source, given the complexities involved in transforming an analogue RGB footprint into a digital YUV image, not to mention all of the other electronic jiggery-pokery going on inside the cam (internal sharpening for one), it seems a bit pointless.

So, thanks for the advice on the gauss weightings; I'll persist a bit more with my tests, more to satisfy my curiosity, but agree that the best outcome will probably be one of a subjective compromise. Probably also what the Panasonic engineers had in mind when they developed the technology, maximum vertical luma resolution and filmic-like motion cadence being the highest priority.

This Edi self-validation concept sounds interesting. Does this mean that you'll likely be holding off on the pending TempGaussMC update that you indicated earlier?

Just going back to the ‘super-resolution’ temporal filter that you eluded to (not sure if the :cool: smiley meant 'cool' or 'yeah, right' :D) ; I see Scharfis_Brain experimented with ‘super-resolution’ for image enhancement some time back and am curious as to whether he or anyone has developed this further. As I recall there is a commercial soft out there (Video Enhancer) that claims to use super-resolution. Looked at it briefly for up-scaling but was not particularly impressed.

[Terka]

Didee,
i think i understand. Thank you for your patience with my "ideas" :)

[Didée]

... (Video Enhancer) that claims to use super-resolution. Looked at it briefly for up-scaling but was not particularly impressed.

Pssst, don't tell anyone, but ... being "not impressed" is exactly what you can expect from it. ;)

Temporal Super-Resolution is a over-hyped concept. Basically it works, but "good" it works only on footage with a very certain characteristic, namely "decimated" resolution. On "blurred" resolution, it works not. The latter case is the usual one, the former is what is hard to find at all, except for one special case: interlacing. And truly, filters like MVBob, MCBob and, in a fuzzy way, TempGaussMC in fact are REAL temporal super-resolution filters.
Put shortly, in "decimated" resolution there is information missing in a frame, like the missing scanlines in interlaced footage, or due to point.sampling in the initial frame scanning process. In this case, it is ~relatively~ easy to pull the missing information from the neighbor frames, and put it into the current frame.
In the case of "blurred" resolution, like e.g. a DVD source or such, there is no information "missing". The original master has had bigger resolution, and by downscaling to the final production resolution you get "blurring", because several pixels of the bigger master are sampled-together to get one pixel of the smaller output.
In this case, it's basically so that the same blurred information is present in consecutive frames, and because of that, there is no "new" or "additional" information in the neighbours that you could put into the current. NB, the presence of compression artefacts (even very small ones) doesn't exactly help on the matter.

And that's why I had put the cool-smiley in that place: just because of "what's in a name". Something might be a TSR operation basically, but that doesn't mean that it's worthwile to name it so. But for reasons of PR and possibly making money, it's clever to have an impressing name for the child .... If you'd try to sell a primitive sharpen filter in the name of "a 3x3 pixel matrix filter", then people are bored. But, if you sell it as "Deconvolution filter, man!", then it goes "Aah!" and "Ooh!" ... ;)

[WorBry]

I've another update pending. It'll cover an adapted sharpen mode (stronger in vertical direction, since that direction gets blurred more), and an option for rep1 acting a bit better.



Any news on the pending update ? :o

[Didée]

I'm fiddling. The new stuff grew more than I had thought, and now there's need to check lots of things.

A small appetizer (http://www.mediafire.com/?wm9mxjlpn2d) of what things will look like. :)
(Interlaced source not included, construct with "source50p.SeparateFields().SelectEvery(4,0,3).Weave()" )

[WorBry]

Nice :)

[Malcolm]

Your 'appetizer' looks great!! :)

[Terka]

In comparsion to before used methods - Hut runter!
For people who want to buy an camcorder, there will be new question 1080@50i or 720@50p when final res. is 1080@50p.

[Didée]

Almost there, it's almost there. It's a pleasure to see what it pulls out of some difficult content. Especially with really sharp & detailed sources, the differences are astounding.

Wanna see some filters trying their luck at Stockholm (http://www.mediafire.com/?mzdzmbyjnmg)? Amazing!
(Sorry, forgot to reset the framerate from RawSource's default of 25fps to the real 59.94fps ... but hey, the slo-mo is good to make the bobbing issues even more obvious);)

Just a bit more twiddling with a few smaller things, and TempGauss should go beta.

[WorBry]

Lookin’ good; hey whilst you’re still fiddling with the new version, why not also give it a shot with the ‘CrowdRun’ HD sequence from:

ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_MultiFormat/

Plenty of moving detail there plus some conspicuous bob-shimmer (e.g. the tree tops)

I’ve put up matched (1 second) 1080/50i, 1080/50p and 720/50p HuffYuv-YV12 samples:

http://rapidshare.com/files/123222835/ParkRun_1080_50i_YV12.avi.html Note: Top Field First

http://rapidshare.com/files/123226654/ParkRun_720_50p_YV12.avi.html

http://rapidshare.com/files/123230935/ParkRun_1080_50p_YV12.avi.htm

Intrigued by the 'new question' posed in Terka’s last post, I was in the middle of doing a little comparison (purely subjective) of bob-deinterlacing 1080/50i (TempGauss_alpha3, MCBob, YadifMod-NNEDI) versus upsizing 720/50p (NNEDIResize_YV12/LimitedSharpen) to 1080/50p, but if you’re nearly there with alpha4 or a beta, it seems it bit redundant now. Suffice it say that encoding time for TempGaussMC_alpha3 at default (Tr0=2, Tr1=2, Tr2=1, edimode="NNEDI") tipped one hour (for 50 output frames) on my AMD XP2800+, 1GB DDR RAM; that would be more 60 hours for processing 1 minute of 1080/50i footage. Imagine if the source was AVCHD. For HD sources at least, the faster Yadif edi mode (with say Tr0=1, Tr1=1, Tr2=1) would seem a more practical proposition (encoding time 9 min 51 sec). MCBob 0.3u ran at 28 min 47sec and YadifMod-NNEDI 3 min 2 sec (....plus the bob-shimmer). On the upscaling side, NNEDIResize_YV12 plus a simple LanczosResize took 7 min 42 sec; not bad quality but more blurred than the bob-deinterlaced outputs. Hadnt got around to LimitedSharpen (Edit: NNEDIResize_YV12 plus LimitedSharpen (dest_x=1920, dest_y=1080, Smode=1, strength=40) took 8 min 43 sec)

Edit: Ooops, noticed that I'd labelled the uploaded samples ParkRun instead of CrowdRun. Ah well, what's in a name.

Edit2:If anyone’s interested :rolleyes:, here are sample outputs (first 5 frames) from the comparative tests:

http://rapidshare.com/files/123691501/CrowdRun_1080_50i_bob-deinterlace_tests.zip.html

http://rapidshare.com/files/123628340/CrowdRun_720_50p_upscale_tests.zip.html

Since TempGaussMC incorporates MVDegrain (limited to Tr2=1 in these tests), I also tested the other methods with and without MVDegrain1. Maybe folks more experienced with Limited Sharpen, or maybe See-Saw, could improve on the up-scaled outputs.

Edit3: Here also is a small (file size) direct (cropped) comparison of:

Reference 1080 50p
TempGaussMC_alpha3 (221 NNEDI)
MCBob 0.3u
NNEDIResize_YV12 + LimitedSharpen

http://rapidshare.com/files/123702365/CrowdRun_Ref_TGMC_MCBob_NNEDIResizeLS.avi.html

Perhaps not the best example to demonstrate shimmer/flicker supression but it highlights relative preservation of definition.

[2Bdecided]

Wanna see some filters trying their luck at Stockholm (http://www.mediafire.com/?mzdzmbyjnmg)? Amazing!
(Sorry, forgot to reset the framerate from RawSource's default of 25fps to the real 59.94fps ... but hey, the slo-mo is good to make the bobbing issues even more obvious);)I love the steps near the end of that footage - even watching the footage native on an interlaced display they look very "wrong" yet TGmc(full) does a brilliant job of making them look as they should.

Just a bit more twiddling with a few smaller things, and TempGauss should go beta.Looking forward to it! (wish I had a faster machine though! :( ).

Cheers,
David.

[Malcolm]

@Didée,
your sample is absolutely stunning! Really looking forward getting my hands on the beta! :) :)
However, besides removing nearly all the flicker and showing much more detail than the other contenders, there are some minor areas with errors.
Here are 2 frames for illustration:
http://img176.imageshack.us/img176/8955/tempgaussmc1qd0.th.jpg (http://img176.imageshack.us/my.php?image=tempgaussmc1qd0.jpg) http://img253.imageshack.us/img253/4813/tempgaussmc2hs9.th.jpg (http://img253.imageshack.us/my.php?image=tempgaussmc2hs9.jpg)
I hope this will help you to eliminate them.

Greetings,
Malcolm

[LaTo]

@Didée
TempGaussMC is amazing! Thanks a lot for this stuff :thanks:

But I have noticed one problem, TTMC produce some strange lines... It look like residual combing, but it isn't because it's horizontal and... vertical.

Screenshots of my problem:
http://latoninf.free.fr/lines/

Maybe you could fix this, I hope... :cool:

[2Bdecided]

Ouch.

There's no source clip to be sure, but I think this is the inherrant problem with deinterlacing.

Very fine vertial detail can be very fine vertical detail, or fast movement (including a flash of light!). The two cannot be disambiguated.

mcbob errs on one side, ttmc on the other. mcbob messes up very fine detail, ttmc messes up very fast changes.

Still, magician Didée to the rescue! Maybe there's a threshold to tweak or a blur weighting to adjust somewhere...

(A source clip might help)

Cheers,
David.

[Didée]

Those effects are known, and mostly resolved.

Malcom: The detail loss is because too much structure may get lost during the 1st (not MC'ed) gaussian stage. (BTW, it wasn't only the pole ... also much of those little waves on the water were smeared away.)
=> Solved, by giving a bit more bias towards the original.

LaTo/2BDecided: What you're seeing there is MVTools when it actually misses scenechanges. (Light flashes can be considered as such, in this context).
=> Probably solved, by lowering SAD thresholds in some MVTools-filters.

(I hope it'll work out reliably enough ... generally, SAD is only a rough (and relatively poor) measurement: in high detail/high contrast areas, even related blocks can have a rather big SAD, whereas in low detail/low contrast areas, even unrelated blocks may have a rather low SAD. Well, what to do. SAD really is not a versatile measure, still in MVTools it is *THE* decisive element. TempGaussMC actually has to play one or two severe tricks to sail around the darn SAD cliffs...)

[LaTo]

What you're experiencing is MVTools when it actually misses scenechanges. (Light flashes can be considered as such, in this context).
=> Probably solved, by lowering SAD thresholds in some MVTools-filters.

I have made a quick-fix with SAD & SCD settings (attachments).

With TempGaussMC_alpha3M(scd1=100) the lines go out :thanks:

[Didée]

You're turning the wrong knob. Lowering thSAD in MVDegrain is not the preferred solution ... you could lower it to,say, '100' - hooray, no more artefacts!! -- but oh dear, why there's all this bob flickering again? ;)

The culprit is "thSCD1", which defaults to 400, which is way to high for the prepared searchclip ... that one is "flattened" on purpose, and reasonable scenechange values for such a clip are e.g. "thSCD1=175,thSCD2=100". <--Put these into all MVDegrain calls if you can't wait for me posting the beta.

[LaTo]

You're turning the wrong knob. Lowering thSAD in MVDegrain is not the preferred solution ... you could lower it to,say, '100' - hooray, no more artefacts!! -- but oh dear, why there's all this bob flickering again? ;)

The culprit is "thSCD1", which defaults to 400, which is way to high for the prepared searchclip ... that one is "flattened" on purpose, and reasonable scenechange values for such a clip are e.g. "thSCD1=175,thSCD2=100". <--Put these into all MVDegrain calls if you can't wait for me posting the beta.

Previous post updated!

The problem go away with SCD1=100... If >100 the lines is present.

:thanks:

[Didée]

The problem go away with SCD1=100... If >100 the lines is present.

That's bad news. Just figured that on detailed material (CrowdRun), thSCD1=180 (for blocksize=8) resp. thSCD1=240 (for blocksize=16) are good values. If you need a value of 100 for your footage, that means that there's probably no smart handling of that issue in sight. (With '100' there is big danger that some frames won't get filtered at all ... try on 'ParkRun', you'll see....)

Darn SAD. Darn fixed-dumb-thresholded-solutions. The good solutions are those that work without any thresholds. Solutions that essentially rely on thresholds are not solutions, just case-dependent fiddlework ... like almost any filter available for Avisynth. :rolleyes:

[WorBry]

Cmon guys, we've had the appeteasers, now let Chef Didee serve up the main course and then you can pick at the food if you like - my stomach's rumbling :D

[yup]

LaTo & Didée!

May be need try search=3 in MVTools. I am last time try write script for remove pulse noise and found that search=3 give more better result than search=2. Also I try decrease thSAD with search=2 but without result. I agree search=3 decrease speed, but give better quality MV.

yup.

[Didée]

Yeah, exhaustive search, sure. Exhaustive is always the last ressort when everything else fails. Next step beyond exhaustive is: kick all filters to dustbin, and arrange the fields' scanlines manually with PhotoShop. Blargh.
With "light" settings, TempGaussMC can run in range of "half realtime", perhaps full on beefy machines. Exhaustive search doesn't quite fit into the picture.

But BTW ... in MVTools, the "2nd best" motion search (short of "exhaustive") is search=2, "diamond search". OTOH, compare with x264: in x264 there is also "diamond search" available ... but there, it's about the cheapest and lowest-quality ME method you can only choose. Hmh.

Dunno if I'm missing something here, but my feeling is that MVTools is in severe need of some better motion analysis.

[LaTo]

With "light" settings, TempGaussMC can run in range of "half realtime", perhaps full on beefy machines.

ARGH, I bought a E8400 last week... and TempGaussMC run +- 2fps on SD footage :eek:
(with defaults settings)

[WorBry]

So try a "lighter" setting, maybe (tr0=1, tr1=1, tr2=1, EdiMode="EEDI2"). Should at least double the speed, and with EdiMode=Yadif, maybe five-fold.

[Didée]

With defaults, of course. Default is "NNEDI", and NNEDI on its own already is pretty slow. Fast is Yadif, or just plain bicubic interpolation instead of any EDI.
Perhaps the estimate was a bit too optimistic, but ... with my archaic hardware, the usual quick guess is that a higher-end machine is 10 or 20 times faster than mine ... (lately, some suggested x264 settings, running 6-7fps on a Q9450, did run at 0.2-0.25fps for me) ... out of the game, I am.

[Malcolm]

Malcom: ... (BTW, it wasn't only the pole ... also much of those little waves on the water were smeared away.)Oh, i've noticed that as well. But that was _so_ obvious, pointing that out would have been a bit insulting to you, wouldn't it?! ;) :D

[kandrey89]

OK, I'm confused. TempGaussMC is a deinterlacer right? So what stage of development is it in, where can it be obtained?
If it's so good why doesn't it have it's own dev page?

[sidewinder711]

If you are reading this thread carefully from the beginning, you will find out that it is not only a deinterlacer. It's in its "alpha" stage or a bit further... and you can download/copy it from article #13 of this thread.:rolleyes:

[kandrey89]

Saw the code, but I don't know avisynth, and don't know any necessary skills to utilize that code :/
Will have to wait for a plugin for VirtualDub, if that's possible :/

[WorBry]

Saw the code, but I don't know avisynth, and don't know any necessary skills to utilize that code :/

Do yourself a favour. It's not that difficult:

http://avisynth.org/mediawiki/Main_Page

Will have to wait for a plugin for VirtualDub, if that's possible :/

TempGaussMC is a scripted function that utilizes a number of AVISynth plugins (filters) that have no VirtualDub equivalent. I think I can safely say that the possibility of a VirtualDub plugin, or series of plugins, that perform(s) the same function is more than remote.

[Terka]

Dunno if I'm missing something here, but my feeling is that MVTools is in severe need of some better motion analysis.

There are some papers on the net...

[Terranigma]

Would it be possible to use/construct TempGaussMC for deinterlacing only without denoising?

[Terka]

you can join original and computed lines together

[WorBry]

Would it be possible to use/construct TempGaussMC for deinterlacing only without denoising?

Well you could disable the 'post gauss' MVDegrain denoising (Stage 2) by setting Tr2=0, but the mo-comped temporal gauss itself is basically a MVDegrain temporal denoise that has been warped into a gaussian distribution (Stage 1).

As Didee stated earlier:


And a *denoiser* is all that this script is, indeed. A denoiser that also "denoises" bob flickering. ;)

[Didée]

Hi ... there's some technical problem with my ISP, currently I'm without internet connection at home. :|

The noise reduction of TempGaussMC is an inherent property of the used method. Trying to avoid this "feature", you'll open several cans of worms that TempGaussMC so explicitly tries to keep closed ... and in the end you would have it stumbling in the very same pitfalls which the other methods regularly fall in. Better let it levitate over those pitfalls, at the expense of reducing noise.

If you actually enjoy the comfy ambience of those pitfalls, then use something else, but not TempGaussMC. :)


You might try something among the lines of first reducing noise in the interlaced footage, deinterlacing the denoised material, then re-adding the removed noise ... like

interlaced_clip

NR = FFT3DFilter(sigma=plenty,interlaced=true)

TGMC = NR.TempGaussMC()

NRD = mt_makediff(interlaced_clip,NR)

TGMC.mt_adddiff( NRD.doubleweave(), U=2,V=2 ) # or NRD.bob()

, with FFT3DFilter as an example for an interlace-aware denoiser. The results will depend on how properly the denoiser does its job.

[WorBry]

The noise reduction of TempGaussMC is an inherent property of the used method. Trying to avoid this "feature", you'll open several cans of worms that TempGaussMC so explicitly tries to keep closed ... and in the end you would have it stumbling in the very same pitfalls which the other methods regularly fall in. Better let it levitate over those pitfalls, at the expense of reducing noise.


I guess this would be an example of one variety of ‘worm’ that emerges from ‘opening the TGMC can’. Did a little comparison of:

TGMCa3 (Tr0=2, Tr1=2, Tr2=2) # i.e. with ‘internal’ MVdegain2

TGMCa3 (Tr0=2, Tr1=2, Tr0=0) + MVDegrain2 # same MVAnalyze/Degrain parameter settings as ‘internal’

TGMCa3 (Tr0=2, Tr1=2, Tr0=0) + hqdn3d(2) # my hitherto preferred (temp-spatial) denoiser for MV/MC-Bobbed DV sources

TGMCa3 (Tr0=2, Tr1=2, Tr2=2) + RemoveGrain(mode=2) # mild ‘post’ spatial degrain

Here’s the results:

http://rapidshare.com/files/125536164/TGMC_222__vs_TGMC_220_vs_TGMC_220___MVDG2_vs_TGMC_220___hqdn3d2_vs_TGMC_222_RG2.avi.html

Note the relative stabilities of the B&W spotted pattern on the cushion with the red square. With TGMC 222 (i.e. ‘internal’ MVdegrain2) the pattern is well calmed. However, apply the MVDegrain2 after TGMC and some shimmer/vibration starts to appear again. Likewise with hqdn3d, and slightly more so. Apply a light spatial degrain (RemoveGrain mode=2) after TGMC (with internal MVDegrain2) and the ‘worms’ really get wiggling.

So, if I understand the levitation trick correctly, the ‘internal’ MVDegrain avoids regenerating shimmer (one such pitfall) by utilizing the same motion analysis as the denoised feed for mo-comped gauss, but applying a lower thSAD value, so avoiding interference with the directed (high contrast) denoising that has been applied by the gauss. Added to which is an internal repair mechanism that corrects the MVDegrain defects. Correct?

Hope you rectify your connection problem.

Edit: Doh, just noted that merely disabling the internal MVDegrain (Tr2=0) itself results in return of the shimmer. So the internal MVDegrain is actually an integral component of the flicker supression. I guess I should have realized from Didee's comment above :rolleyes:. I've edited the uploaded comparison clip accordingly.