exist any filter specially done for (deinterlace) flicker

[Didée]

Ah, splendid! Nice work, really, thank you very much!

Did you count how often it is converted back-and-forth between planar and interleaved? Twenty, thirty, perhaps forty times ... ?

(It's kind of ridiculous if something has to be done like that, isn't it ... but alas it's the only way to keep all those precious chroma samples ... a pity that they will be lost anyway, if in the end a compression with Mpeg2/x264/Xvid/whatever is done ... <giggles>)

[2Bdecided]

Just to confirm that the table in this post (http://forum.doom9.org/showthread.php?p=1155566#post1155566) pretty much restores the alpha3 performance to beta1, but for my HDV footage alpha3 still has the very slight edge IMO.

For my HDV footage, the default beta1 settings are a disappointment (except in terms of speed!). I think NNEDI>EEDI2 is the biggest factor, but everything seems to play its part.

I accept that for more detailed footage beta1 might be far better, but (again, IMO) the stuff that looks a bit like combing shouldn't be coming through by default.

Just my 2 pence. It's all a bit theoretical for me - it's not really practical to use something this good (slow) on HD anyway, except for grabbing stills.

Cheers,
David.

[Terka]

to 2Bdecided:
if i can understand correctly, the defaults:
for beta are fast, but bad quality?

[Yoshiyuki Blade]

Just my 2 pence. It's all a bit theoretical for me - it's not really practical to use something this good (slow) on HD anyway, except for grabbing stills.


Yes, it may seem way to slow to be used in practice, but I've been encoding many 1080 resolution clips using TGMC, and its well worth it :D. Although (currently) none of my clips ever exceed just a couple minutes, every second of footage looks fantastic.

But even on the great hardware I have, it will take quite a long time to process everything, and will also require great hardware to playback at full speed. It really depends on what you have, I guess.

[Didée]

to 2Bdecided:
if i can understand correctly, the defaults:
for beta are fast, but bad quality?
They're not bad quality. They are just faster.

What looks good-or-bad depends pretty much on the actual source and its characteristics.

Please read this post (http://forum.doom9.org/showthread.php?p=1154607#post1154607) again.

[2Bdecided]

I wasn't arguing against your post Didée, which is why I wrote what I wrote, rather than what Terka thought I meant. The results I post are for my footage; certainly not universally proven.

I do have a slight concern that WorBry seems to be seeing similar problems though, on quite different footage. Maybe a slightly different default setting might make more sense. I don't know. I'm not using other people's content.

It's strange, because in other uses (e.g. mcbob, upsizing), if I can see a difference, I usually subjectively prefer the eedi2 version over nnedi. Whereas with this script, nnedi is clearly better for my content.

Cheers,
David.

[Terka]

2 Didee:my question was posted because i didnot understand what 2Bdecided wants to say. When i reread 2Bdecided's post - its still not clear to me.
So beta has faster default settings, in different situation they produce worse or better results than default setings used in alpha.
Sorry for using simple English.

[2Bdecided]

So beta has faster default settings, in different situation they produce worse or better results than default settings used in alpha.Yes, that's it.

Cheers,
David.

[Terka]

Hi Didee,
welcome back from holidays.

tgmc sometimes causes following artefacts:
on _static_ parts with detailed structure (like grass on psi.avi)
Grass should be static, but some bigger (40*20pixels) parts of it are moving in different directions by +-1pixel. Could this be somehow eliminated (what about separate picture onto smaller areas and use dup?)


Some questions regarding the tmcg. As usually from me, if something could be useful, take it, if not, ignore it. Please dont spend much time regarding the following.
if the TG result depends on interpolation method (nnedi, edi ...), than we can:
1. feed it with something better
2. use "weaker settings" (you told that:TempGaussMC will average away much of the benefits that any motion-compensate bob will feed it with.)

ad 1)

a) overlay "interlaced original over tgmc"
b)

o'riginal
g'aus
n'nedi

o
g
o
g

(double the height)
o
n1
g
n2
o
n3
g

(remove lines with g)

o
N -> overlay of n1,n2 or another nedi to get the line between n1,n2
o
N

ad 2) dont know if i understand the script, is the core the >>temporalsoften<< ?
if yes, what about double the framerate to weaker the temporalsoften behaviour?

[WorBry]

@Didee,

Just wondering, does this have implications for TempGaussMC?

http://forum.doom9.org/showthread.php?p=1172038#post1172038

[Nikos]

The same typo error in beta-1 :D

# construct temporal gaussian average from linear averages
t = (tr0==0) ? dbob
\ : (tr0==0) ? t1.merge(dbob,0.25)
\ : t1.merge(t2,0.357).merge(dbob,0.125)

[Mystery Keeper]

I can't find tempgaussmc_beta2 anywhere. Am I dumb? ^_^'

[WorBry]

I can't find tempgaussmc_beta2 anywhere. Am I dumb? ^_^'

AFAIK, there is no beta2 (as yet). Beta1 is here:

http://forum.doom9.org/showthread.php?p=1158000#post1158000

The same typo error in beta-1 :D

# construct temporal gaussian average from linear averages
t = (tr0==0) ? dbob
\ : (tr0==0) ? t1.merge(dbob,0.25)
\ : t1.merge(t2,0.357).merge(dbob,0.125)


By George, he's right you know. Obviously, easily remedied:


# construct temporal gaussian average from linear averages
t = (tr0==0) ? dbob
\ : (tr0==1) ? t1.merge(dbob,0.25)
\ : t1.merge(t2,0.357).merge(dbob,0.125)


...but probably Didee should be the one who puts up a corrected version.

[Nikos]

Foremost, thanks Didie for this excellent function.

After observation the whole function i have one note:


beta-1
Smode = default( Smode, 2 ) # Which method to use for re-sharpening the MC'ed temporal gauss:
# 0 = not at all
# 1 = 3x3 kernel
# 2 = vertical min/max plus 3x3 kernel

SLmode = default( SLmode, 2 ) # How to limit the sharpening:
# 0 = not at all
# 1 = spatial, before 2nd MV stage (fast)
# 2 = MC-temporal, before 2nd MV stage (slow)
# 3 = spatial, after 2nd MV stage (fast)
# 4 = MC-temporal, after 2nd MV stage (slow)


Sbb = default( Sbb, 1 ) # Back-blending of gauss-blurred sharpen's difference (slightly increases visual fidelity)
# 0 = no back-blending
# 1 = before sharp-limiting
# 2 = after sharp-limiting
# 3 = before AND after sharp-limiting


but here with Smode !=0, SLmode = 4 or 3 and Ssb = 3

# re-sharpen the temporal gaussian blur
stage1a = (Smode==0) ? stage1
\ : (Smode==1) ? stage1.mt_lutxy(stage1.removegrain(11),"x x y - "+string(sharpness)+" * +",U=3,V=3)
\ : stage1.mt_lutxy(st1mmavg.removegrain(11),"x x y - "+string(sharpness)+" * +",U=3,V=3)

# apply vertical thinning?
stage1a = (SVthin==0.0) ? stage1a : stage1a.mt_adddiff(vmedDD,U=2,V=2)

# apply 1st sharpening back-blending?
stage1a = ((Sbb==1 || Sbb==3) && Smode!=0 && sharpness!=0.0)
\ ? stage1a.mt_makediff(mt_makediff(stage1a,stage1,U=1,V=1).removegrain(11,-1).gaussresize(ox,oy,0,0,ox+.0001,oy+.0001,p=5),U=2,V=2)
\ : stage1a

# apply sharpening limiting? (SLmode 1|2)
stage1b = (sharpness==0.0) ? stage1
\ : (SLmode==1) ? ( (SLrad<2) ? stage1a.repair(edi,1) : stage1a.repair(stage1a.repair(edi,12),1) )
\ : (SLmode==2) ? stage1a.mt_clamp(pmax,pmin,Sovs,Sovs,U=3,V=3)
\ : stage1a

# apply 2nd sharpening back-blending?
stage1b = ((Sbb==2 || Sbb==3) && Smode!=0 && sharpness!=0.0)
\ ? stage1b.mt_makediff(mt_makediff(stage1b,stage1,U=1,V=1).gaussresize(ox,oy,0,0,ox+.0001,oy+.0001,p=5),U=2,V=2)
\ : stage1b

we have two back-blending before sharp-limiting.

[thetoof]

beta2 is an unofficial version modded for the multithreaded version of MVTools
http://forum.doom9.org/showthread.php?p=1171286#post1171286

[WorBry]

Since its not an official update from the author, wouldnt it be better to call it something different like TempGaussMC_Beta1_MT or similar?

Didee, wherefore art thou???

[Didée]

I'm busy making preparations for my funeral. When I saw that "tr0==0" typo, I got a heart attack, and deceased. :D

Just wondering, does this have implications for TempGaussMC?
http://forum.doom9.org/showthread.php?p=1172038#post1172038
For the moment, no. I consider that not important enough. When using Yadif/EEDI2/NNEDI as interpolator, there should be no practical impact on the result at all. Chroma is only a "small helper" in MVAnalyse. And even when using EdiMode="MickeyMouse" (no EDI, use simple bicubic interpolation), the error is so small that it hardly matters. (it does when you're chaining several instances of bob->separatefields->weave ... that's a good way to demonstrate the problem, but it's nothing you do in a typical workflow.)
Let's wait for Avisynth to sort this issue internally.


@ Nikos: Well spotted that "tr==0" error. How could I overlook that!?

You're also correct on the back-blending issue in case of SLmode=3|4. However, that one is on purpose. Re-sharpening is done before the 2nd MVDegrain stage, and after the 2nd MVDegrain stage it's no more possible to differentiate between difference-of-sharpening and difference-of-MVDegraining. Theoretical options were to sharpen after the 2nd MVDegrain stage, or to take the sharp-diff from before and back-blend it after the 2nd MVDegrain ... but both ways would be prone to re-introduce some noise or bob-shimmer.
The fully correct way would be to first separate the sharp-difference, and apply yet-another instance of MVDegrain to this difference. And that's way too much computational effort for a rather small effect.

The way it is now, the backblending procedure works not exactly as described (in case of SLmode=3|4 and Sbb=2|3), but it works reasonably. I'll leave it like it is.


I've updated the script with the major edit of [tr0==0] => [tr0==1]. :rolleyes:


@ Terka: I'm not convinced that your last proposal of weaving + NNEDI-interpolation will work out, methinks it should lead to shimmer again. However I'm not fully sure in this case, so I'll have to actually try it out.

[Nikos]

Thanks Didie for the analytical explanation. Another solution is to aplly "Back-blending after sharp-limiting" only for SLmode=1|2.

Sbb = default( Sbb, 1 ) # Back-blending of gauss-blurred sharpen's difference (slightly increases visual fidelity)
# 0 = no back-blending
# 1 = before sharp-limiting, for Slmode = 1|2|3|4
# 2 = after sharp-limiting, for Slmode = 1|2
# 3 = before AND after sharp-limiting, for Slmode = 1|2

[WorBry]

@Didee,

I see Fizick has now fixed the MVDegrain 'chroma shift' issue in the latest MVTools v1.10.2.1

http://forum.doom9.org/showthread.php?p=1176507#post1176507 :rolleyes: :rolleyes:

Does this mean that the compensating segment in TGMC_beta1 (lines 245 - 247) can and should now be deleted?

## MVDegrain causes a chroma shift (yes it does, with pel>1 !) We compensate by shifting chroma towards plain EDI by a small notch
## [ 1+(x-1)/(1+(x/5)^4) ] on 128-centered diff-clip (x-y) ==> [ x y - abs 2 < y x x y - abs 1 - 1 x y - abs 5 / 4 ^ + / 1 + x y - x y - abs 0.0001 + / * + ? ]
stage2 = stage2.mt_lutxy(edi,"x y - abs 2 < y x x y - abs 1 - 1 x y - abs 5 / 4 ^ + / 1 + x y - x y - abs 0.0001 + / * - ?",Y=2,U=3,V=3)

Edit: Ah, I note Nikos has queried this also in the MVTools thread:

http://forum.doom9.org/showthread.php?p=1176566#post1176566

[boondoggle]

I get "no function named MVAnalyseMulti" (line158) when using MVtoolsv1.10.2.1 and TGMC beta2 .. but with MVTool 1.9.6.7 it works. Any ideas whats wrong?

[talen9]

Yes :)

There are two (at this time) separate branches of MVTools; 1.10.x.x is Fizick's branch, it contains only the standard "MVAnalyse" functions.
1.9.6.x is josey_wells' branch, it does contain the MVMulti* functions.

So, the behaviour you're reporting is consistent.

Let's only hope that those two branches can be merged soon ... at least, to avoid further confusion :)

[boondoggle]

ah, could you/anyone describe differences between the two?

[talen9]

Well, there's the MVTools thread (http://forum.doom9.org/showthread.php?p=1171286), where all the info you're requesting (and more) can be found :)

Have a look at the last 3-4 pages, I think it should be enough :)

[thetoof]

Hi,
I've got a sample that's flickering like crazy after deinterlacing... does someone know anything that'd help remove that? I tried a few settings with tgmc and even if I can't have anything better with the other smart-bobbers, it is still unpleasing to the eye.

Get it here (http://www.mediafire.com/?jxdjdg9rtdi) if you want to give it a try.

Maybe it could be a good test clip for the dev of tgmc since it's very tricky...?

[Didée]

You just got aware of the "black hole problem" of de/interlacing.

To start, I came up with settings like this:
tempgaussmc_beta1(2,2,3,0,0,0,"EEDI2",eedi2maxd=16,truemotion=true,sharpness=1.75,Sbb=2,SLrad=2,SVthin=0.75,Sovs=2)

In now way perfect, yes, but it won't get much better than that, see below. If you think it's bad, then do a stackhorizontal with TDeint or Yadif/Mod or with whatever else -- instantly, the result of TGMC will look much better then! ;)


There's lots of motion in vertical direction, and there lies the problem. MC'ed bobbers/deinterlacers basically are temporal superresolution filters, i.e. the information not present in the current frame (field) they try to pull out of the neighbor frames (fields). This is fine if the vertical component of motion amounts to 0 / 2 / 4 /... pixels. On contrary, if the vertical component of motion amounts to 1 / 3 / 5 /... pixels, then the current frame/field and its neighbors contain exactly the "same" information, and exactly the "same" information is missing. In this case there is *nothing* that can be pulled from the neighbors. This results in "static aliasing" in the moving parts. Now, if mod2 of the vertical component is not exactly 1.0 but only close, then the result will be some kind of "travelling" aliasing in the moving parts. In parts where the temporal approach (necessarily) has to fail, the only hope is that the spatial deinterlacing part constructs something useful. This will succed in many places, but will fail in others, and usually will be plagued by flickering, especially if speed of motion is rather slow.

Since in this sample there is stuff moving at all kinds of different speeds, the result contains the full bandwith from "perfect" deinterlacing, over the travelling aliasing nastiness, up to the black hole.

TGMC still does better than most other deinterlacers - the other ones will fail if the missing information is not present in the +/-1 neighbors, while TGMC can pull a good amount from the +/-2 ones, too, and even a bit from the +/-3 neighbors (not very much from the latter, though.)
In theory one could reflect about evaluating an increasing temporal window in order to pull information from even further away neighbor fields; but that's difficult, and the computational effort explodes.

So, sorry if it's not perfect, but that's the way it just is. In case you find something that works better than TGMC for this stuff, keep us informed!

(I really would like to see what some expensive hardware like Snow & Wilcox would produce in this case .... not because I expect a [much] better result, but rather for the chance to see such $$$$$-hardware failing in the very same way.) ;)

[2Bdecided]

I think the fault lies with the originator of the content. Image detail of the order of 1 pixel high combined with movement of the order of 1 pixel per field cannot be accurately represented in an interlaced system. With live events, you never know what might happen momentarily - you can sometimes see the same problem with details in football matches and motor sport. However, with animation, you create the stuff frame by frame - or in this case field by field. Watch it on an interlaced display, and you'll get plenty of weirdness! The originators of the content should have spotted this, and either filtered the fine detail, or modified the scroll rate.

I doubt that Snell and Wilcox can solve it, but they have some great white papers explaining this specific problem, among others...

http://www.snellwilcox.com/community/knowledge_center/engineering_guides/

I think it's the standards conversions and composite decoder documents - IIRC it crops up in both, but I could be wrong.

Cheers,
David.

[thetoof]

Thanks a lot for the detailed explanation!

I never questionned the fact that tgmc outputs amazing results compared to the other bobbers around (that's why I said:
I can't have anything better with the other smart-bobbers
Anyways, thanks again for your help/explanation/awesome script!

[WorBry]

I know Snell & Wilcox is considered to be the holy grail of converters, but has anyone out there in Doom9 land used it? I've never see an example on the forums. AFAIK there is a standalone, software version (Helios) that someome, somewhere posted retails at $3000+. Strange that they dont seem to have a demo version available. It sure would be interesting to compare with TGMC (for deinterlacing) and MVFlowFPS (for frame-rate conversion).

[Dr.D]

Can I use TempGaussMC for removing flickering from a progressive (deinterlaced) clip?

[Adub]

You really shouldn't. Use a flicker reducer, such as ReduceFlicker or Deflicker. You never want to deinterlace a progressive source.

[thetoof]

What was discussed here (http://forum.doom9.org/showthread.php?t=141292) might interest you ^_^

[Dr.D]

You really shouldn't. Use a flicker reducer, such as ReduceFlicker or Deflicker. You never want to deinterlace a progressive source.
Sure I don't want to deinterlace. I want to femove flicker.
I have some clips without sources, deinterlaced by wrong deinterlcer (I would say, any deinterlacer is wrong for my camera except TempGaussMC :), because produces this annoying flicker).

So, question to Didee - is it possible to populate this magic deflickering logic from the TempGaussMC to work with progressive source? Or it's impossible to make a meat from a grinded one?

[WorBry]

Or it's impossible to make a meat from a grinded one?

Try TempGaussMincedChicken :D

[Didée]

is it possible to populate this magic deflickering logic from the TempGaussMC to work with progressive source? Or it's impossible to make a meat from a grinded one?
A bit of both. It's certainly possible to remove much of such flicker, but it will always boil down to some sort of "brute force" filtering.

Taken very strictly, you won't get TempGaussMC's "magic" when running it on already-deinterlaced sources with deinterlace-flicker. The point of TGMC is that the, hmh, the deviations of even fields and those of the odd fields should cancel out each other. But on already deinterlaced sources, you're basically missing one of those fields completely, and so the cancelling-out obviously can't work correctly anymore.

Nonetheless an improvement by TGMC surely is possible. And the proposals that thetoof above has pointed to will also improve notably.

Point is, there is no really "correct" way of dealing with the problem. Possibilities are plenty, each with their pros and cons ... and in the end, it's once more a matter of personal preference which method might be *your* personal favorite.

Important points:

a) temporal filtering is a must

b) without motion compensation you won't get very far

c) when using motion compensation, then the flicker that you want to remove is very likely to disturb the motion search


Both TGMC and the script suggested by thetoof (the 1st of the three, actually) address all three points. TGMC probably will be somewhat more strong on the pre-filtering side (I suspect the tempgauss to straighten out more flicker than FFT3D), but it's not clear if the mocomp-tempgauss stage deals well or better should be modified for such a task. In any case, thetoof's script uses edge masking, which is likely to keep more detail in the result (mostly in flat areas, think of skin and faces).

A random suggestion to try:

TempGaussMC_beta1(2,2,2,4,2,2,"NNEDI",sharpness=4.0,Sbb=3,SVthin=2.0,SLrad=2,sovs=1)
Merge( SelectEven(),SelectOdd() )
... which of course could be additionally combined with edge masking, too.

Again, there's thousands of possibilities ... at best, you try them all. ;)

-----

BTW, did anyone notice?
... expensive hardware like Snow & Wilcox ...

ROFL! :eek::p:D

(That day, it was VERY cold over here ...)

[Dr.D]

Didée, thetoof thanks a lot, I'll try both.

Another question. The source is noisy as well. What is the best option for denoise before de-flickering:
1. No any denoise before.
2. Some denoise (what kind?).
3. All supposed denoise.

[Dr.D]

try tempgaussmincedchicken :d
:) :)

[Terka]

@ Didee:
"I'm not convinced that your last proposal of weaving + NNEDI-interpolation will work out, methinks it should lead to shimmer again. However I'm not fully sure in this case, so I'll have to actually try it out."
could you have a practical look at #159 thank you, Terka

[Didée]

Well ...

ad 1)

a) overlay "interlaced original over tgmc"


That's already an impossibility: "tgmc" has double as much frames as the "interlaced original". So, when taking that proposal *literally*, it does not make sense.

It could be interpreted like:

a) overlay InterlacedOriginal.DoubleWeave() over TGMC

=> NNEDI interpolation will construct a result that's inbetween the results of TGMC and orig.DoubleWeave(). This seems not promising.


b) overlay InterlacedOriginal.Bob() over TGMC

=> NNEDI interpolation will construct a result that's inbetween the results of TGMC and orig.Bob(). This seems not promising either.


The trick is that the differences between even and odd phases are *not symmetric*. That's why interpolation based on the original fields won't work out in the way one is dreaming of.
Even MCBob stumbles in this pitfall of a false assumption: its STT routine is a misconception, it re-introduces bob shimmer. :)

[Didée]

Frankly, that description above wasn't very good. Let's try a simple example instead.


Original progressive sample:

... 80 80 80 ...
... 20 20 20 ...
... 60 60 60 ...


Examine a (field)/(bob frame) where the dark line (20 20 20) is missing and has to be re-interpolated.

Interlaced:

... ?? ?? ?? ...
... 80 80 80 ...
... ?? ?? ?? ...
... 60 60 60 ...
... ?? ?? ?? ...


TGMC result: (example)

... 82 80 78 ...
... 19 20 21 ...
... 58 60 62 ...


Now we do what you proposed.

Interleave orig with TGMC:

... 80 80 80 ...
... 19 20 21 ...
... 60 60 60 ...


Let NNEDI create interpolations:

... 80 80 80 ...
... 50 50 50 ...
... 19 20 21 ...
... 40 40 40 ...
... 60 60 60 ...

Throw out TGMC's interpolation, replace with average of NNEDI interpolation orig<>TGMC:

... 80 80 80 ...
... 45 45 45 ...
... 60 60 60 ...

Hey! The "20" line has turned into a "45" line! A dumb bob would've produced a "70" line.

It's a very simplistic example, but it shows that this method will turn a 100% correct result into a result that lies halfway between "100% correct" and "dumb bob". This means that you'll get 50% of the flicker/shimmer that a dumb bob would produce. Not good. First use a rather slow bob filter, then throw away 50% of the improvement you got from the slow method? No. That's a too heigh prize to pay only to "safely" use the original lines of the original field.

(That example didn't really use NNEDI, just ordinary linear interpolation - but that's irrelevant. It doesn't matter which spatial interpolator you use here. It's the basic principle in itself that is faulty, the kind of interpolator has nothing to do with that.)

[Terka]

of course we want to double the resolution, look for information which is not there, maybee in previous/next frame.

hm... simple clear model. yes nnedi method fails. but interleave looks quite good. in horizontal direction.
but what about in above posts described "errors" seen in narrow vertical lines which are discarded by pure tgmc?

and could the 2) be useful

or could we put the temporal axis to nnedi (put eg 3 frames over each other and after that fill the missing information)
like for example
1.some bobber (needed for more sucessful motion comp.)
2.motion comp - overlay
3. erase the filled areas="gaps" come into existence
4. fill the "gaps"

[Terka]

is the above useful?

[Didée]

Can't tell. I don't "see" what exactly should be done, your description is not precise enough, sorry.

My probably-closest interpretation of your 1.-4. steps would mean that step 3) is exactly un-doing step 2), which wouldn't make much sense.


What else could it be? Mo-comp c-1 and c+1 onto c, then NNEDI-average between them? Not spectacular, in this case NNEDI would perform some kind of fine-compensation in addition to the initial mo-comp. I don't see an actual problem being solved by this.

First weave scanlines of c-1, c, c+1, then doing mo-comp on this weave? Probably not. That plainly can not work, mocomp on such spatially-not-continuous frames can't be successful.


Hint: always think about which basic problem a method should solve, and WHY the method solves that problem. To me, it frequently sounds like "take some A, take some B, throw'em at NNEDI, see if some magic arises."

Such poking is not the way. (Alchemy *never* has been able to produce gold. Nuclear physics can, but the result is more expensive than natural gold. )

So please, try to explain better.
- If needed, make diagrams.
- - In case of doubt, implement yourself, then show us that it works. ;)


edit: oops, forgot your "ad 2)" :
[ 2. use "weaker settings" (you told that:TempGaussMC will average away much of the benefits that any motion-compensate bob will feed it with.) ] ...

ad 2) dont know if i understand the script, is the core the >>temporalsoften<< ?
if yes, what about double the framerate to weaker the temporalsoften behaviour?
No, not good either. Temporal-gauss-filtering calms the up-down-up-down flicker into a "flat" sequence (at least that's the basic idea), so that motion compensation doesn't "follow" that flicker. There is no benefit by first increasing framerate.
What could be a possibility is: to do a rough pre-pass motion compensation, to make the initial tempgauss not ghost as much as it currently does without MC. But that would require bigger blocksizes than 16x16, more like 32x32, perhaps up to 48x48. If I'm not mistaken, MVTools does not offer that.

Phase correlation is something too ... but a) we don't have it, and b) IMO it's an over-hyped concept. Phase correlation can show you "yes there IS an solution", but it doesn't GIVE you one. To GET that solution that phase correlation showed to exist, you need to use ... good old ME+MC, and in an instant, you're facing exactly the same problems as without phase correlation.

[Terka]

input:
11111111
________
55555555

we need fill the blank line (_____)
the nnedi or another method could fill like
11111111
33333333
55555555

what i want to say - lets use for the filling also the f-1, f+1 frames
because the original could be eg.
11111111
55555555
55555555

how?
A) do the motion comp. (or phase correlation or ...)
put the pictures over each other:
(lets assume pointresize to doubleheight)
eg. lets the object moving right-down by 1/2pix per frame
111111
11111111
_1111111
______
555555
55555555
_5555555

so from the next (red) frame we could get the half of missing line.
for the successful overlay we need good step A
but simple mo-co is comparing two different pictures (upper-lower), thats why i tried to explain how to get more correct vectors (first fill the missing lines, mo-co to get vectors, unfill the filled=back to original, use the vectors to overlay and fill the gaps)

add 2)
No, not good either. Temporal-gauss-filtering calms the up-down-up-down flicker into a "flat" sequence (at least that's the basic idea), so that motion compensation doesn't "follow" that flicker. There is no benefit by first increasing framerate.

is the core of temp-gauss the usage of temporalsoften?

[Didée]

Small allegory before falling asleep: (2.00 AM here)


We have a bucket that has its bottom broken away. We also have some synthetic granules to repair the bucket with. To work the granules, we need to mix it with water. Water is available from a far-away river.

The problem is, obviously, how to transport the water from there to here.

You are suggesting to transport the water in the bucket with the missing base.


zzzzz..... <sleeps>

[Didée]

OK, lets expand a bit on that allegory. BTW, just found there's a Wikipedia article (http://en.wikipedia.org/wiki/There%27s_a_Hole_in_My_Bucket) about that song.

(It's only some free minutes during lunchbreak, not sure if I can finish in this run.)


There is information missing. And no matter how you turn the coin: in order to have any method "perfectly" reconstruct the lack, the method would need to have a-priori access to the information that is yet missing.

Throwing out some simple thoughts:

Your example with |1|?|5| . Assuming the case that "?" should actually be "5", yould "showed" that this info could be gotten from a neighbor frame (using mocomp).

What you forgot: assume that mocomp of f+1 gives you a "5", BUT f-1 gives you a "1". Now what to do? You can't decide if the "1" is correct, or if the "5" is correct. Or if the truth infact lies in the middle, and there really should be a "3". You just can't decide.


Looking at it from a generalized point of view, it boils down to this:

The "simple" approch uses mocomp to fill in the missing data from the neighbors. This generally works, but we found the result is often insufficient, because certain configurations of the "decimated" original data can lead to unwanted results of the motion engine.
Spatial interpolation is not sufficient, because it basically does not change the characteristics that fool the motion engine.
So you propose to instead use a pre-pass motion compensation for "better" interpolation of the missing data. And that's the point where the dog bites its own tail:
If the whole mocomp thingy gets fooled in the "simple" approach, then the mocomp thingy is *not suited* to provide a better pre-interpolation for the "real" mocomp thingy in a 2nd pass. All that happens is that the 1st mocomp stage would consolidate those characteristics that are fooling the motion engine.

Or like this: a one-stage mocomp suffers from producing the error "E". We want to eleminate producing this error. Now, in order to prepare the initial data in a better way, you propose to use the very method that is producing error "E". Hence, the 2nd-stage mocomp will be working on a dataset that has the error "E" already burnt-in.

It just does not work out. There's a whole in my bucket oh Henry oh Henry, ...


OTOH ...

as long as rather "small" motion is present, current TempGaussMC does work out pretty good already. There is not so much that could be improved at all.


Further on ...

Elaborating about "simple examples" is good and all, but it's not sufficient. One can get to "solutions" that *seem* to work on the simple examples. But the bad surprise usually comes when you practice those "solutions", and you discover that are so darn many small pitfalls and special cases that also have to be considered; and it's all these little things that turn the beautiful "solutions" upside-down and inside-out, and *POOF*, there the bubble blows.

Think about the "black hole" problem (vertical motion of 1 pixel, the data missing "here" is also not available from "there"). A big problem, and I don't see your proposal to offer any solution.

Or what about not-antialiased original (progressive) detail of high frequency. Your current dataset is |5|?|5|, and from the mocomp you get a surprising "60" as solution for "?". Now, decide if that "60" is correct (it is really detail), or if it's false compensation. If you just play safe ("such a big difference must be considered an error"), then you#re fine if it really was an error; BUT of course you get nasty flickering if it indeed is detail. (This is the route that's usually taken: better play safe.)
The other way round, if you just blindly trust mocomp's result, then you are fine if it really was detail, but you get artifacts if it in fact was an error.


And so further and so on ...


Lots of problems that can arise. The current way surely is not at all perfect, but I'd say it's rather good. Over time, I've wrapped my mind quite thoroughly around what can be done with our current tools; and I don't see easy ways to get a worthwile improvement with reasonable effort.

I'm all open for NEW ideas to be introduced.

However, old wine in new skins won't get us very far.


Finished *almost* in time. ;-)

[Didée]

To not get accused of just babbling and making everything bad, I (tried to) make a script that follows Terka's last proposal.
Perhaps it is what he meant, perhaps it's just sort of an interpretation ... it's still not fully clear.

# Trying an idea of Terka
# Target: a pre-bobbed clip with "better interpolation"
# Method: Do vector search on (dumb) bobbed clip. Create forward compensation and backward compensation.
# Let NNEDI interpolate between them two. From that interpolation, use the according complementary fields to weave with the original fields.


bs = 16 # blocksize
ov = bs/2
tm = true # truemotion?
iidx = 15 # idx value to use

i = last # this is the original interlaced input

fflag = i.GetParity()

bob1 = i.bob(0,0.5)
bob1 = fflag ? bob1.AssumeTFF() : bob1.AssumeBFF()

# motion vectors
bv = bob1.MVAnalyse(isb=true, truemotion=true,blksize=16/1,overlap=8/1,idx=iidx)
fv = bob1.MVAnalyse(isb=false,truemotion=true,blksize=16/1,overlap=8/1,idx=iidx)

# bw & fw compensation
bc = bob1.MVCompensate(bv,idx=iidx,thSCD1=800,thSCD2=255)
fc = bob1.MVCompensate(fv,idx=iidx,thSCD1=800,thSCD2=255)

# from the MC'ed bob frames, select the "new" fields
compfields_b = bc.SeparateFields().SelectEvery(8,1,2,5,6)
compfields_f = fc.SeparateFields().SelectEvery(8,1,2,5,6)


# Now, make a "NNEDI average" of (forward compensation) and (backward compensation)

# breeeaaaaaathe in deeply .........
interleave(compfields_b,compfields_f).AssumeTff().Weave().NNEDI(field=1,dh=true).AssumeTFF().SeparateFields().SelectOdd().AssumeFrameBased().AssumeTFF().SeparateFields().SelectEvery(4,0,2)
# breeeaaaaaathe out again!

# weave the original fields with the NNEDI-averaged compensated fields
interleave( i.separatefields() , last ) .SelectEvery(4,0,1,3,2)
fflag ? AssumeTFF().Weave() : AssumeBFF().Weave()

# for comparison: radius-1 dumb temporal gaussian blur
t = bob1.temporalsoften(1,255,255,32,2).merge(bob1,0.25)

left = last.Subtitle("Search clip, proposed method")
rite = t.Subtitle("dumb temporal gaussian blur, temp.radius=1")

stackhorizontal(left,rite)

return(last)


See if you find something useful in it ... note that it's not for producing a "nice" output, but only for preparing a clip to search motion vectors on.
Hence, "sharpness" is not (much of) an argument. Absence of bob flicker/shimmer is.

[thetoof]

TGMC seems to have some trouble with the motion blur... maybe it's just me or the source being tricky, but here's the sample: http://www.mediafire.com/download.php?djchzhwjzii

[Didée]

What is this? The source to be processed by TGMC, or the result after bobbing + re-weaving?

If the former - great, the source is already full of artifacts. Expect a bobber to repair motion defects that are in the source?
If the latter - great, what to say? Yes, it's full of artifacts. Having the original sample could help.

(If it's the result indeed, then more exhaustive search settings will be benefitial - blocksize=8 / searchparam=8 / pelsearch=8 / small lambda & pnew etc.pp., if you have time...)
(edit - and if it's really the source, then we have interlaced content coded as progressive?! O_o)

[thetoof]

The following was asked a little while ago, but I think it ended up being unanswered:

Now that
1.10.2.1 (28.08.2008 by Fizick)

* MVDegrain1-3: fixed old rounding error resulted in some chroma tint (some thanks to Didee for bugreport, but it could be more persevering in official MVTools forum thread :)
Should we remove this from tgmc?
## MVDegrain causes a chroma shift (yes it does, with pel>1 !) We compensate by shifting chroma towards plain EDI by a small notch
## [ 1+(x-1)/(1+(x/5)^4) ] on 128-centered diff-clip (x-y) ==> [ x y - abs 2 < y x x y - abs 1 - 1 x y - abs 5 / 4 ^ + / 1 + x y - x y - abs 0.0001 + / * + ? ]
stage2 = stage2.mt_lutxy(edi,"x y - abs 2 < y x x y - abs 1 - 1 x y - abs 5 / 4 ^ + / 1 + x y - x y - abs 0.0001 + / * - ?",Y=2,U=3,V=3)

[News Bot]

I've been trying to get TempGaussMC to work for a few hours now, but it out-right refuses. Everything is perfect, there are no errors. However anytime I try to encode the actual .avs script with it in it, it crashes whatever program I'm using (MeGUI, x264 builds, Media Players etc).

I'm using Vista 64, would this have an effect?