exist any filter specially done for (deinterlace) flicker

[danielkun]

Originally Posted by Didée

Of course it is possible to use the general processing chain of TGMC also for progressive content. Basically, all that's needed is to deactivate the internal bobbing. Just lately someone has asked for a progressive-TGMC (though in a different context, for postprocessing after MFlowFPS) ... short of putting one more switch into the function, see here for the necessary changes, it's really not difficult. (If you don't speak German - the changes are in red.)

It's not 100% optimal this way, since a few things in TGMC assume that the vertical resolution is blurred much more than the horizontal resolution. Perhaps Smode=1 is better than the default Smode=2 in ths case, and probably you'd want to reduce SVthin, or even set it to 0.0. Also, it might be good to put Vinverse between IVTC and TGMC ... like

TFM().TDecimate()
Vinverse()
TGMC_b2(Smode=1,SVthin=0.49) # script modified as shown!!

It's all theory, I didn't try this myself yet.

Danke Didée
I'll look into this and try your different suggestions.

[osgZach]

Originally Posted by 2Bdecided

wow - can people delete posts without leaving a trace? That can make for some strange looking conversations (see above!).

Cheers,
David.

Yes.. Although some forums can be set up to not allow the user to delete their posts after a certain amount of time has passed.. I'm pretty sure I have posted on boards like that before.. If so, I would think a hack / mod of some sort would be available for VBulletin.

[2Bdecided]

Whether people should be allowed to delete posts is one thing - but on most forums it says "deleted by user" in place of the missing post.

Cheers,
David.

[henryho_hk]

I suggest case-insensitive comparison on the EDIMODE parameter. It is now rather tricky ("NNEDI" vs "nnedi2").

[Didée]

Originally Posted by henryho_hk

I suggest case-insensitive comparison on the EDIMODE parameter. It is now rather tricky ("NNEDI" vs "nnedi2").

I fully agree that this is bad style. The excuse is that Avisynth's parser accepts it.
(And the 2nd excuse is that the lowercase string was not added by me - that was done by third-party scripter/s.)

It's definetly not clean, but ... laziness has learned that the parser does not care for upper/lowercase when checking identity: it evaluates "big"=="BIG" = TRUE. Has been like that for over a decade.

Is someone about to change the parser's behaviour?

Also, there's lots of bad style that frequently is used in Avisynth ... A similar case:

a = [some float]
b = [some int]

result = a * b

In a clean programming style, such mixing of var types should not be done. Strict parsers/compilers would complain. Wanna urge some billion instances in some thousands of Avisynth scripts that do an INT*FLOAT multiply?

[WorBry]

@Didee,

Any thoughts about my last post above ?

Hope it wasn't too dumb; if complete nonsense, just let me know.

Cheers.

[henryho_hk]

No.

While the parameter name is case insensitive, the parameter value (avisynth's string compare) is case sensitive. "NNEDI2" has the same result as "Blah".

[Gavino]

Originally Posted by henryho_hk

... the parameter value (avisynth's string compare) is case sensitive.

No, it isn't. Case is ignored in all string comparisons.

[Didée]

@ henryho_hk - what do you get with this little script?

check = ("BIG"=="big") ? "size doesnt matter!" : "size DOES matter!"

version().subtitle(check,align=2)

@ WorBry - only one small issue: don't put "levels=1" in the sclip_super line. Don't you get "MAnalyse: it is not enough levels in super clip (1), while MAnalyse asks [n]" ... ? - The searchclip should have all levels available.

The rest of the script seems OK to me. Same as your conclusion about AA strategy - in this case, there is not much AA to get from temporal processing. Spatial interpolation is the most-promising approach, and averaging two EDI's (top/bottom) is a good way.

Also,

Also I found that the temporal gauss treatment itself tended to introduce conspicuous warping/undulation of lines/edges.

is not surprising. When applying TGMC to progressive input, there's a problem because the number of different motion states in forward- and backward-direction are different. This un-balance can mislead the motion engine.

[WorBry]

OK, thanks for the advice

My only frustration with the 'double-Edi' approach is the line thickening, but I guess that's a better trade-off than other detail-destroying blur AA techniques, and thankfully NNEDI2 is a great improvement over its predecessors in this respect.

[Revgen]

Small question.

Does the "edeint=" parameter override the "EDIMode=" parameter?

[Didée]

Small answer: Yes. "Edeint" has priority over "EdiMode". (Assumption: if the user takes the effort of producing a bobbed clip and feeding it into TGMC, then it's probably not by accident.)

[Revgen]

^Thanks. That's the way it works in TDeint, so I just wanted to be sure.

[Terka]

Didee,
regarding the clips where the VCrep function cant catch the mvtools errors:
1.what about build the repair function based on mmask?
2.comparsion of vectors from 2 vectors search is not possible in mvtools for now.
(mean use your recalculate idea and apply it where the 1st search vec. differ from 2nd vectors search by more than threshold.
this means where 2nd search is 'more' different from 1st one, use 2nd. because usually they should be +-pixel the same.)

[Didée]

1.what about build the repair function based on mmask?

That's the Chicken-vs-Egg problem, once again. The issue takes place in stage1. No motion data is available at that point. After the motion data has been computed in stage2 (based on the possibly-erroneous result of stage1), it is not reliable to catch errors of stage1.

where 2nd search is 'more' different from 1st one, use 2nd. because usually they should be +-pixel the same.)

I.e., making some sort of self-validation. That's not a bad idea in general. Basically, it even is a rather nice idea. Be surprised or not, pretty much that is what I have tried already. Precisely, years back when I was fiddling with MCBob ... and as much as I like the principle, I didn't get the method to work out.

[Terka]

1. mean like this:
# IF rep2=true: Allow only bob-typical vertical differences
stage2 = (rep2!=0) ? stage2.VCRep(edi,ed=ed2,od=od2) : stage2

but do this on seachclip. so the 'final' searchclip will be done from
2 searchclips, classical tg and not preprocessed.


2.
why you didnt?

[translucent]

First off, thanks to Didée for such a useful script. Just had to point out this (seemly longstanding) bug:

# cheap halo-reduction for sharp pel modes (for Lmode=2|4)
cx1=comp_fw1.width()
cx3=comp_fw3.width()
cy1=comp_fw1.height()
cy3=comp_fw3.width() #!?!?

[henryho_hk]

Is it a bug or a feature? lol

[Terka]

Didee,
remember the grass problem with the dogs clip?
(For the ones who dont know the clip:
realatively static clip, handheld camera. People on grass filmed from 10m. On the static grass after tempgauss appeared large up/down moving areas.)
this helped:
searchclip=searchclip.HQdn3D(4,3,6,3)
its line before
# Get motion vectors

(the idea was stolen from TemporalDegrain)
tested on tr2=1 where most visible.

Could please other tgmc users test this tweak? Thank you, Terka.

[Didée]

That's also a "you win here, you loose there" game. It'll work out in quasi-static areas. But if you have, for example, a panning shot where the top half of the frame shows a cloudy sky, then it is very likely to harm.

(In TemporalDegrain, the according "HQ" option better should be labelled "BF" ... because this trick is not "high quality", but rather "brute force".)