exist any filter specially done for (deinterlace) flicker

[WorBry]

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

Do I really need to? Seems little point in illustrating what Didee acknowledges is inevitable.

My interest was rather in the potential benefits of TGMC_beta2's lossless modes for denoising interlaced material......

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


Thanks for the reply. I'll do some more tests to satisfy my curiosity on that.

[Terka]

its up to you if you post something. im dealing with dv also and wanted to know which artefacts are you getting.
btw. you store some recordings interlaced? which codec? DVD/mpg2?

[WorBry]

Well, yes I keep all of my edited native DV footage on tape and HDD. I dont generally archive interlaced material after post-processing and transcoding, save keeping a copy of the "heavily-edited" DVD that I produce for other family members. For personal viewing (on PC) I still prefer to bob-deinterlace (TGMC or MCBob) and transcode to x264. In that case I do also archive a copy of the 50p lossless intermediate (usually FFDShow-HuffYuV YV12). However, every now and then I revisit and play around with interlaced (MBAFF) x264 encoding; since I dont yet possess a standalone Blu-ray/AVCHD player, it's just that for now.

[2Bdecided]

I'm a big fan of TGMC, so I'm a bit disappointed that the newest version doesn't offer me anything useful for my HDV footage.*

My favourite version is still alpha3.
beta1 is genuinely sharper but with more artefacts (subtle "almost-combing", and letting more actual MPEG-2 artefacts through).
beta2 is maybe slightly worse by default, and worse still in lossless modes. I realise it gets nice PSNR numbers, but would the lossless modes really help where people think they would?

I'll try and post a test clip to show why I still like alpha3.

Cheers,
David.

*EDIT - I'm not complaining!!!! - I sounded really ungrateful, but I'm not! I'm just suggesting that maybe other test clips might be helpful during development.

[Didée]

Terka - cant say much to the skier clip at the moment, but I'll have a look into it. Worth trying: blocksize 8, different rep0/1/2 settings, MVTools params further toward "truemotion", or perhaps further away from "truemotion" ... last ressort, exhaustive search with all SAD penalties turned down :eek:. (Just dont know which is the main culprit in this case, sorry.)

2Bdecided - a sample showing the issue / regression would be nice.


The next step for a possible improvement most probably reads "MRecalculate", but then things will get slower, necessarily. Though, I'm a bit discouraged ... some time ago I had made a quick trial in that direction, and the result was different from what I had expected. Don't know if my thoughts were wrong, or if I didn't use MRecalculate corectly, or if MRecalculate doesn't do what I suppose it to do ...

[Revgen]

This appears to be my favorite (albeit very slow) replacement for yadif when used with srestore. As you said before, lossless lets in more interlacing than non-lossless (mostly on thin angled objects like stair rails) even at lossless=3, but most of what it allows in can be cleaned up for the most part using vinverse() afterwards without destroying much detail.

[nicmar]

I've got exactly the same problem on the lossless with the diagonals of my skiing video (with lossless=0,1,2) .
But it's ok with lossless=-1.

It's good with this script :
_______________________________________________________
LoadPlugin("c:\divx\avisynth\RepairSSE3.dll")
LoadPlugin("c:\divx\avisynth\RemoveGrainSSE3.dll")
LoadPlugin("c:\divx\avisynth\VerticalCleanerSSE3.dll")
LoadPlugin("c:\divx\avisynth\nnedi2.dll")
LoadPlugin("c:\divx\avisynth\mt_masktools-26.dll")
LoadPlugin("c:\divx\avisynth\masktools.dll")
LoadPlugin("c:\divx\avisynth\mvtools2.dll")

import("c:\divx\avs\TempGaussMC_beta2.avsi")
import("c:\divx\avs\LimitedSharpenFaster.avsi")
avisource("ski.avi")
assumetff()
crop(14,4,-12,-12)
# More details ???
TempGaussMC_beta2(1,1,1,1,1,1,"NNEDI2",qual=3)
# Less details ???
#TempGaussMC_beta2(2,2,1,1,1,1,"NNEDI2",qual=3)
selecteven()
BlackmanResize(720,576)
_______________________________________________________

Didée : Thanks for the work and this nice reflexion !

[Terka]

if i correctly understand the behaviour of mvdegrain
lets have clp,searchclip (done by temporalsoften).
where mvtools search fails, ghosting is visible.
so the visible ghosting are the searchclip pixels?

from Temporal Degrain comments:
# Currently, Temporal Degrain works by creating a "clean" clip that has no noise.
# This clean clip is used for MV search, and will generally give more accurate vectors
# than an unfiltered clip would. However, our current implementation uses heavy filtering
# from FFT3DFilter. The prefiltered clip looks like mush, and our first stage of denoising
# cannot exhibit denoising greater than this. Because of this, the limit on denoising
# is essentially nothing! In some cases, the denoising is much more severe because our
# "clean" sometimes replaces the results from vanilla MDegrain, giving a very flat and
# undetailed look the image. We can alleviate this by creating a secondary "limit" clip
# that isn't as severely filtered as our search clip is. But, this would cost even more time.

if yes, how the limit clip could be done?
if yes, could it be possible to replace the failed places with clp instead searchclip using mvtools parameter (implement new param. to mvtools?)

[Terka]

Didee, once you mention the (not available) inverse vectors.
eg. v=(2,3) ->v_inverse =(-2,-3)
have you tried to get them by reordering the stream with selectevery? eg. selectevery(2,0,1,0)

[Didée]

Swapping frames is not the same as reversing a vector.

_____


Don't give too much on that TDegrain explanation. Wordsmiths might debate whether the description is wrong, or just "a bit misleading". The prefiltering stage is independent from the actual filtering stage. It is not so that the result of the prefiltering would be used anywhere for the output. If the prefiltering did a small change in one place, and the actual filtering did a big change in the same place, then the actual filtering will be limited. But not the other way round: If the prefiltering did a big change in one place (too big, producing "mush"), and the actual filtering did only a small change, then the smaller change is used. No mush is used for the output. It is used whichever filter did cause the lesser change, i.e. that one that did less harm. Of course, there might be cases where the strong prefiltering caused MAnalyse to find a bad vector, which subsequently will harm the actual filtering. But then, a "wrong vector" is a pretty much different thing than "mushy prefilter is replacing the result of vanilla MDegrain." ;)

Also, all this is only for TemporalDegrain. In TGMC, limiting the actual filter by the prefilter's result is *not* done. But in TGMC, too, the various prefiltering may cause a worsened result of motionsearch in some spots. However, I suspect it's not so much the temporal prefiltering (which usually is safeguarded by the "rep" options, anyway). Probably more critical is the flattening of signal amplitude, which is done in a separate step. It has been noted before: this flattening is pretty much necessary to get the whole thing working at all. Without it, MDegrain would not work in those places where it's needed at most....

And that's the point where MRecalculate should come into play: do the motionsearch after the temporal prefilter (which is needed), but without the signal flattening. Only after the vectors have been searched, use MRecalculate to update all block-SADs in respect to the flattened signal.

That is the idea, and I consider it reasonable. But as said, a quick tryout didn't work as expected. Wrong thinking? Wrong scripting? Buggy MRecalculate? I don't know yet.

[2Bdecided]

2Bdecided - a sample showing the issue / regression would be nice.Two demuxed m2v samples here:

http://www.mediafire.com/?sharekey=605ee2b5f85656f5e62ea590dc5e5dbb31f572f6d5454f27a9a26c4ed87536eb

The images in there are field (bobbed frame) number 146 of test clip 2. I've found that's quite representative of my outdoor footage.

(clip 1 has some silly fine detail in the background (little holes on the large pipe) - no expectation this will come good, but it's a nice test case.)

What I see in clip two compared with alpha3 are little bits of false fine detail getting through (alongside some real extra fine detail).

Last time I mentioned this, you suggested settings for beta1 which made it similar to alpha3 - which 80% worked.

FWIW I rarely use TGMC for hours of HD(!) - occasionally I leave a PC running for a week to process a few minutes footage with TGMC that I need to zoom+crop. More often I use TGMC to grab a single frame for a photo.

Cheers,
David.

[Didée]

Thanks for sharing, I'll have a look. (Somehow ... HD is really nothing you would process with my PC)

By now, I remember that I also did a slight modification in the searchclip preparation from alpha3 to beta1. It's a tricky field, in the same way as the general setting or tweaking of MVTools' parameters. There never is a "better" or a "worse". It's only ever "you win here, you lose here". When saving waving hands, I lose Stockholm. When saving Stockholm, I lose waving hands. (SAD concept is fixed-absolute, not relative to amount of local energy.)

[Didée]

@ 2Bdecided: Didn't do very much testing, it's just no fun with my hardware.

Though, it seems the few non-adjustable changes from alpha3->betaX are not the point. It's really only the different defaults. There is virtually nothing that alpha3 could do that beta1/2 could not. The progress was evolutive, not eliminative.


EEDI2 <-> NNEDI/NNEDI2
alpha3 used the old NNEDI. beta1 used EEDI2 because faster than old NNEDI. Nowadays we have MT'ed NNEDI2. Use that.

blocksize=8 <-> blocksize=16
Of course, "8" can catch tricky motion better than "16". It's a speed compromise. You can set it back to "8".

repair: "hardcoded" alpha3 vs. default 4,0,4 in beta1/2
The hardcoded repair of alpha3 was more strict than beta's defaults. Use "1,0,1" in beta2 to get old behaviour (mostly).

Sharp-limiting:
alpha3 had hardcoded spatial limiting. beta has temporal limiting per default.
Set "SLmode=1, SLrad=2" to get old behaviour back.

(This is a "matter-of-principle". Spatial limiting is of course much more failsafe: MVTools has not a "sliding" thSAD limit for MCompensate, as it has for MDegrain. MCompensate is only "hard limited". Therefore MCompensate can produce rather bad blocks in difficult areas, and that's indeed dangerous for the limiting process. (Manually caring for this problem is possible, but unpleasingly slow.)
OTOH, spatial limiting is basically a poor strategy - it works out only when the source is sufficiently soft. In the theoretical hardcore case of a very sharp progressive original that has been interlaced without any lowpass, the temporal mode basically works correctly, but the spatial mode fails blataneously.)


Yet again, there is no "right" or "wrong". There's only different sources, and different preferences.


Okay then, what happens with those settings adjusted?


(2,2,1,1,0,1,edimode="NNEDI2",SLmode=1,SLrad=2,blocksize=8)
(mostly like alpha3 did)
http://thumbnails10.imagebam.com/7042/e68a8070410786.gif (http://www.imagebam.com/image/e68a8070410786)

(2,2,1,1,0,1,edimode="NNEDI2",SLmode=1,SLrad=2,blocksize=8,lossless=1)
(same, plus the simple lossless=1 mode)
http://thumbnails28.imagebam.com/7042/e01eac70410789.gif (http://www.imagebam.com/image/e01eac70410789)


Can't judge if that is exactly an "80%" approximation of alpha3's result. ;)

But if so, then it can be argued if the other 20% are to alpha3's advantage -- or perhaps to alpha3's disadvantage? I'd say the adjusted settings avoid almost all of the artifacts, and beta2 still shows more detail.

[aegisofrime]

I wonder what are we supposed to see in those comparison images? Or maybe that was the point, we are not supposed to see anything different? :D

In any case, I think in the context of video (moving images), you will have to be looking very hard to see differences. In my opinion, the important factor is speed then.

[Didée]

You've (also) to compare with the screens posted by 2Bdecided. Between the different filters and versions, the main differences are e.g. the boy's hand (with or without artifacts), the diagonal pole of the baby buggy (with or without artifacts), the texture of the girl's clothing (more or less detail, with or without distortions), ...

[2Bdecided]

Very much appreciated Didée - those settings are spot on!

Compared with alpha3 default, there's a little more genuine detail coming through, and a little more artefacts from the original encoding coming through - and (AFAICT) no increase in deinterlacing artefacts (if anything, there might be a slight decrease in deinterlacing artefacts - though there weren't many to start with). For this footage, to my eyes, this gives a nicer result than the default settings.

(The artefacts from the original encoding look worse with a simple dumb bob, so no real harm done there by tgmc. It's not a great worry anyway as it'll probably get even worse when subsequently encoded for anything).

Cheers,
David.

[WorBry]

FWIW - With my DV sources at least, I find that reducing the sbb value (default = 1.0), and sometimes inactivating it (sbb=0), can help to minimize those "subtle almost combing-like artifacts", that you referred to.

[danielkun]

I've only recently started using TGMC, and I like it a lot! On interlaced video is my first choice, and the denoiser saves me doing MCTD (which I find complex and can't get the most out of it, requires too much knowledge of the filters it uses)

Also, I like TGMC's denoising much better than MCTD's, I tried the latter's low, medium settings with some lower sigma values (it's too blurry otherwise) but it somehow fails a bit on edges (or is it that H264 accentuates some error in those edges)

The way TGMC denoises is just what I want since not only raises PSNR more, but it looks better as well, the image looks cleaner and with less "grain" around edges. Great work Didée :)

Anyway, as said, TGMC is my preferred choice for interlaced content, but it leaves to problem with telecined one. I've no experience with motion compensation or any other advanced filtering, so I'd like some help in this matter. I'd like something like:

1) Use TGMC along TMM or something, but it wasn't designed to denoise progressive content, so is this adviceable?

or

2) Tweak MCTD in order to closely ressemble TGMC's denoising.

I hope someone can enlighten me in this matter :thanks:

[Boulder]

For telecined sources, you have to do inverse telecine, not deinterlacing. Tritical's TIVTC plugin contains all you need (functions TFM and TIVTC).

[Didée]

There's a problematic clip pending - and the news are not good ...

have one clip where it is a bit unpleasent - skiing video,
poles of a skier - some ghosting and/or stairsteping
http://rapidshare.com/files/357446100/ski.avi
how could the default setting be tuned?

To make a long story short: if you want an example where TGMC works not good, here you have it !!

In this clip, it is simply so that the combination of following factors:

a) "thin" image features (little image area that MVtools can snatch onto),

b) those thin features being on almost texture-less background (vector predictors in MAnalyse don't give useful predictions),

c) the shaky hand camera

These three factors cause "situations" in which the initial gauss-denoising produces something that does more harm than it helps. And even the safety-repair (tr0) can't fully prevent the misery.


The closest approach (while keeping the general tempgauss-principle) is to just use more stringuent repair-options, together with only small temporal radii, like
TGMC(1,1,1,1,1,1, ...)

That's a little better, but "good" is something else. In this case here, it seems really necessary to completely de-activate the initial tempgauss:
TGMC(0,1,1,0,1,1, ...)

Now, deactivating the initial tempgauss kind of defeats the whole principle that TGMC stands for. But in this case, it seems it's the only way to prevent TGMC falling apart into pieces. :mad:

[danielkun]

For telecined sources, you have to do inverse telecine, not deinterlacing. Tritical's TIVTC plugin contains all you need (functions TFM and TIVTC).

Indeed, I use TIVTC with MCTD for telecined content but I'm not satisfied with the results, sorry I wasn't clear about it.

I just want to know if there's a way to use TGMC's denoising with decimate or tweak MCTD to match TGMC's denoising (since I like it so much)

[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 (http://forum.gleitz.info/showthread.php?p=404392#post404392) for the necessary changes, it's really not difficult. (If you don't speak German - the changes are in red.) :D

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.

[Terka]

Didee, ok. extrem case.
are you still working on the mrecalculate idea or is it no-go?

[Didée]

Neither-nor. It's not a no-go, (and/but) I'm currently not working on it. :)

[2Bdecided]

To make a long story short: if you want an example where TGMC works not good, here you have it !!This one is pretty atrocious too... ;)

http://www.mediafire.com/?ghxzmw4yrny

(not my clip - probably downloaded from doom9 somewhere - apparently on 2009-10-06).

That background is too sharp IMO and would flicker horribly on an interlaced display. Never-the-less, it confuses the heck out of TGMC.

Using TGMC as the edeint in Yadifmod helps (not enough IMO!), but as a general approach I think that would cause more problems than it solves.

Cheers,
David.

[Didée]

Oh, *that* clip. Yes I remember, I once had downloaded it, too.

Using TGMC as the edeint in Yadifmod helps (not enough IMO!), but as a general approach I think that would cause more problems than it solves. Well, to me, using TGMC as an edeint for YadifMod is not an option, as a matter of principle. ;)

The clip is difficult, but not impossible. The very fine hi-contrast detail is irritating most sorts of spatial filtering. As you'll see in the sample below, every deinterlacer is fighting with that issue. In TGMC it's (again) the repair-part. Set all repair's to zero, and the result changes noticeably. (Didn't I mention something similar, back when that clip was under discussion?)

Test script:
(Sorry for the funny cropping/bordering, wanted to fit 6 screens into a 1280x960 display)

AviSource("F:\Downloads\sample_interlaced_LAGS.avi") .assumetff()
converttoyv12(interlaced=true)
crop(32,0,-264,-0,true)
o=last

bobb = o.bob(0,0.5)
yad1 = o.yadif(mode=1)
yad2 = o.yadifmod(mode=1,edeint=o.nnedi2(field=-2))
td1 = o.tdeint(mode=1)
td2 = o.tdeint(mode=1,edeint=o.nnedi2(field=-2))
tgmc = o.tempgaussmc_beta2(1,1,1,0,0,0,"NNEDI2",blocksize=8,sharpness=4.0,SVthin=2.0)


vv=blankclip(bobb,width=4,height=bobb.height,color=$808080)

stackvertical(
\ stackhorizontal( bobb.subtitle("bob(0,0.5)"), vv,
\ yad1.subtitle("Yadif"), vv,
\ td1 .subtitle("tdeint")
\ ).crop(0,2,0,0).addborders(0,0,0,4,color=$808080),
\ stackhorizontal( tgmc.subtitle("TGMC"), vv,
\ yad2.subtitle("YadifMod*NNEDI2"),vv,
\ td2 .subtitle("tdeint+NNEDI2")
\ ).crop(0,2,0,0)
\ )

return(last)

Result: >Linky (http://www.mediafire.com/file/tte0jrhdizm/ChooseYourPoison-Deint.avi)< (Mediafire, ~67MB)

I don't claim there is a "winner". *) -- But there's one out of the six that appears "the least annoying" to me. ;)

*) In particular since TGMC was tweaked, but tdeint was just at its defaults ... though, I doubt you could tweak tdeint to a similar obvious improvement. ;-)

[osgZach]

Just wanted to say, thanks for all the work on TempGauss. It is giving really great results so far, that I can tell.. I'm much more content to wait a couple hours versus spending those hours messing with various IVTC combing problems (either getting through, or ending up with too much deinterlacing on good frames) and so forth.

In particular it is really good for title sequences, and brings the credits text through as pretty as I have ever seen.

Kind of a random question. Currently I'm using TempGaussMC_beta2().SelectEven() to keep the footage at 29.97fps - Although I was wondering (here comes the n00biness) can you use SelectEven() (or an equivalent to end up with a half-frame rate clip) and then use TempGaussMC, or does it really require both fields present, to form the output from? If you could do that, would it increase speed without sacrificing quality?

[osgZach]

No, that makes plenty of sense Stephen, it was just a curiousity on my part. I couldn't really tested it as I am bogged down waiting on an encode to finish at the moment, so figured I'd take a stab in the dark and ask.

[2Bdecided]

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

Cheers,
David.

[WorBry]

@Didee,

You might recall earlier in this thread that we had some dialogue about the potential application of TGMC for anti-aliasing progressive material, and, as a case in point, pseudo-progressive (frame mode) DV footage from my Panasonic GS400 camcorder, which is highly prone to irregular aliasing:

http://forum.doom9.org/showthread.php?p=1144403#post1144403

(I cringe to look at it now )

Well, after much tinkering with altered temporal gauss blur strengths and the like, I eventually came to the startling realization that the bulk of the anti-aliasing effect could be attributed to substitution of the bobbed EDI stream for one in which the complementary (duplicate) interpolated frames are merged ('Double Edi'), viz:

edidbl=mt_average(nnedi(field=0),nnedi(field=1),U=3,V=3)

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

Even so, in terms of 'straight' denoising of the ‘Double-Edi’ with MDegrain, there does appear to be some benefit (stability-wise) in creating a search clip (for motion vectors) using the ‘trick’ (weighed-in mini spatial gauss blur) that you employ in TGMC_beta1/2 to reduce local contrast.

So, what I’ve arrived at is this, using NNEDI2 for the `Double-Edì, and a simple contrasharpen-repair routine (cringes again):

AVISource("C:\........Pseudoprogressive DV.avi")
Tweak(coring=true)
clp=last
#Create Double-Edi clip:
edidbl=mt_average(clp.nnedi2(field=0, qual=1),clp.nnedi2(field=1, qual=1),U=3,V=3)
#Prepare search clip for motion vectors - apply spatial (mini) gaussian blur to reduce local contrast (from TGMC_beta1/2):
spre=mt_lutxy(clp,clp,"x 3 + y < x 3 + x 3 - y > x 3 - y ? ?",U=3,V=3) # ?? REDUNDANT NO-OP
ox=clp.width()
oy=clp.height()
sclp=clp.removegrain(11).gaussresize(ox,oy,0,0,ox+.0001,oy+.0001,p=2).merge(clp,0.1).mt_lutxy(spre,"x 7 + y < x 2 + x 7 - y > x 2 - x 51 * y 49 * + 100 / ? ?",U=3,V=3)
# Get motion vectors from search clp:
sclp_super=sclp.MSuper(pel=2, sharp=2, levels=1)
edidbl_super=edidbl.MSuper(pel=2, sharp=2, levels=1)
backward_vec2 = MAnalyse(sclp_super, isb = true, delta = 2, truemotion=false, blksize=8, overlap=4, search=2, global=true)
backward_vec1 = MAnalyse(sclp_super, isb = true, delta = 1, truemotion=false, blksize=8, overlap=4, search=2, global=true)
forward_vec1 = MAnalyse(sclp_super, isb = false, delta = 1, truemotion=false, blksize=8, overlap=4, search=2, global=true)
forward_vec2 = MAnalyse(sclp_super, isb = false, delta = 2, truemotion=false, blksize=8, overlap=4, search=2, global=true)
# MDegrain denoise:
mdg=edidbl.MDegrain2(edidbl_super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=256, thSCD1=180, thSCD2=98)
#mdg=edidbl.MDegrain1(edidbl_super, backward_vec1,forward_vec1, thSAD=256, thSCD1=180, thSCD2=98)
#Repair-contrasharpening:
allD = mt_makediff(edidbl,mdg) #The difference achieved by the denoising.
ssD = mt_makediff(mdg,mdg.removegrain(11,-1)) #The difference of a simple kernel blur.
ssDD = ssD.repair(allD,1) # Limit the difference to the max of what the denoising removed locally.
ssDD = ssDD.mt_lutxy(ssD,"x 128 - abs y 128 - abs < x y ?") # abs(diff) after limiting may not be bigger than before.
mgdADD = mdg.mt_adddiff(ssDD,U=2,V=2) # Apply the limited difference - contrasharpen
Return(mgdADD)

Any chance you could look over it - specifically the search clip segment (red highlight), which I adapted from TGMC_beta1/2. I realize that the ‘spre’ line (as applied, without the first stage temp gauss treatment) becomes an effective no-op, but I am not sure how to modify the ‘sclp’ line without it .....should I just delete the

mt_lutxy(spre,"x 7 + y < x 2 + x 7 - y > x 2 - x 51 * y 49 * + 100 / ? ?",U=3,V=3)

I`ll put up a sample clip shortly, the old links are long dead.

Edit: Here's a short clip which exhibits some of the worst forms of aliasing I am dealing with. It's in FFDShow HuffYuv-YV12 format (Pal 720x576 anamorphic); unfortunately, I cant readily locate the original DV source footage:

http://www.mediafire.com/file/ewiwmznyzyz/Frame%20Mode%20Progressive%20Sample%20HuffYuv-YV12.avi

Note, in this sample, the above script does leave a little aliasing (some residual hatching on the white wall baseboard) but that's about as good as I've been able to acheive without blurring the heck out of everything.

Edit2: Changed the NNEDI2 qual value from 3 to 1 (highest quality)

[danielkun]

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 (http://forum.gleitz.info/showthread.php?p=404392#post404392) for the necessary changes, it's really not difficult. (If you don't speak German - the changes are in red.) :D

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]

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]

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 ?:o

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]

... 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".)