delinterlacing - yadifmod.. with eedi2 or nnedi2 ?

[hydra3333]

I've seen in some posts that BFF doubleframerate deinterlacing could be done well with Yadifmod from http://bengal.missouri.edu/~kes25c/ (doubleframerate so it can be re-interlaced later).

However there are a mix of posts which say use EEDI2 like

AssumeBFF()
edi=separatefields().eedi2(field=-2)
YADIFmod(order=-1,mode=1,field=-1,edeint=edi)

and others posts which say use NNEDI2 instead of eedi2.

As a non-technical user, reading tcritical's description of the filters didn't help me a lot - it seemed at face value that eedi2 was able to use alternating fields whereas nnedi2 wasn't.

Any clarifying suggestions or links, please ?

PS: DV camera AVI clips, or VHS captures in AVI with huffyuv, or movie clips from a still-camera

[thetoof]

Usually the type of edi to use depends on the clip itself... so I'd say test both and see what looks best for you!

with nnedi2 it's edi=nnedi2(-2)

[aegisofrime]

Or if speed is not any issue to you, use TGMC?

[hydra3333]

Thanks, was just looking at it here http://avisynth.org/mediawiki/TempGaussMC#Modification and http://forum.doom9.org/showthread.php?t=133826 ... the comments suggest it's quite slow, so a faster alternative for "less critical" clips is still a handy thing to have.

Some guidance on when eedi2 vs nnedi2 is applicable would be valuable. tcritical's description doesn't clarify enough for me, so I was hoping for something from people who have used them. Pending that, the wording for EEDI2 seems to imply it takes more data into account.

[Didée]

Well, the most recomendable advice was given by thetoof already ...

Originally Posted by thetoof

test both and see what looks best for you!

As a rough rule of thumb, the result of NNEDI2 usually looks more "natural", where EEDI2 has a tendency to look more artificial. On the other hand, EEDI2 usually is more successful at connecting "broken" lines (restoring missing pixels due to interlacing), where NNEDI2 seems to play more safe. Sometimes EEDI2 will "connect" image features that should not be connected.

Hence, "EEDI2 for animation, NNEDI2 for natural content" is a slogan that makes sense ... but again, making such generalizations is always dangerous.

[hydra3333]

Thanks !! On the balance of that, living dangerously and generalising , NNEDI2 could be preferable for DV and VHS and hand-held camera captures if one isn't too worried about connecting broken lines and we want to be a little "natural". Hence for BFF material and a double-framerate output,

AssumeBFF()
nnediclip=separatefields().nnedi2(field=-2) #-2=double rate (alternates each frame), uses avisynth's internal parity value to start
YADIFmod(order=-1,mode=1,field=-1,edeint=nnediclip)

and to re-interlace back to BFF (after doing something to the clip, like denoising and de-shaking and HDRAGC)

# re-interlace back to BFF
SeparateFields().SelectEvery(4, 0, 3).Weave().AssumeBFF()

I like to re-interlace material that involves movement since someone once said 25i retains more perceived "motion fluidity" than 25p.

[scharfis_brain]

for VHS (eg. horizontally lowpassed) sources it is pretty safe to use EEDI2, cause dangerous patterns already are smeared away.
But like Didée said before: take what pleases you better.

[hydra3333]

Did I get the nnedi2 field=-2 right for that particular use with the YADIFmod ?

[scharfis_brain]

you are doing it too complicated and too error prone.
You are suggesting a filedorder via assumebff() and then you overrule it via the order parameter!

just write:

Assume?ff() #the ? is placeholder for T or B which depends on your source.
yadifmod(mode=1, edeint=nnedi2(field=-2))

do_somethin'_werrrry_special()

Assume?ff() #choose the SAME field order like before deinterlacing
SeparateFields().SelectEvery(4, 0, 3).Weave() #reinterlace. if you forced TFF beforehand, this line will return TFF video automagically!

[hydra3333]

OK !! Much nicer. NNEDI2 is my final "close enough" script choice then, pending a couple of small visual tests of eedi2 vs nnedi2 for my usual types of clips.

If I find a clip I need to get really finicky with, I'll look at http://avisynth.org/mediawiki/TempGaussMC#Modification and wear the pre-global-warming glacial speed.

[Didée]

Originally Posted by hydra3333

... wear the pre-global-warming glacial speed.

It's not always necessary to run full-rigged TGMC. Depending on the source, it may embarrass other contestants even with vastly reduced settings. Not necessarily, but possibly.

clip_576i.avi

YadifMod(mode=1,edeint=XX)

- with -

XX=separatefields().eedi2(field=-2) : 3.7 fps
XX=nnedi2(field=-2) : 3.8 fps (benefits from Core Duo CPU)
                      2.2 fps (single threaded, for comparison)
---

tempgaussmc_beta1u(1,1,0,edimode="--",SVthin=0.0)  #  2.8 fps
tempgaussmc_beta1u(1,1,0,3,3,0,edimode="--",SVthin=0.0,pelsearch=1)  #  3.15 fps
tempgaussmc_beta1u(1,1,0,0,0,0,edimode="--",SVthin=0.0,pelsearch=1)  #  6.1 fps

Sure TGMC is slow, but it's not out of the world either. Those who say "TGMC is unusable slow! NNEDI rulez!!" are those who cry much but understand little.

... And after all, using motion compensation of course comes at a price, compared to *not* using motion compensation. That's not a surprise.

[Didée]

Just because it's so much fun, here's a visual comparison between the 3.8-fps YadifMod-NNEDI2 and the 6.1-fps TGMC.
(It's Stockholm, and slowed down to 12.5 fps to see everything in its full glory.)

SAMPLE (Mediafire, ~11 MB)

Think about generalizations, and about preconceptions. Maybe there is no spoon.

[hydra3333]

Thanks I must have a look at that. Oh dear, tempgaussmc_beta1u wasn't in the wiki ... now I'm off to search for it


edit: is this tempgaussmc_beta1u here ? http://forum.doom9.org/showthread.ph...12#post1340412 TempGMCMVT2v2.rar 3 Nov 2009

Or should I use TempGaussMC_beta1mod.avsi in the Wiki http://avisynth.org/mediawiki/TempGaussMC#Modification which says it can use MVTools2 with MT=false (default). Hmm, tempgaussmc_beta1u seems to allow nnedi2 whereas the other doesn't. I guess tempgaussmc_beta1u is "it" then, hopefully at the link above.

edit2: My goodness, there's really a great deal of difference as displayed in that sample clip. Even with edimode as a dumb bob. Too much to be dismissed lightly.

[aegisofrime]

Since we are somewhat on the topic of TGMC's speed, I have a question for you Didee.

Is there any reason why this script

SetMTMode(2,4)
DGDecode_mpeg2source("D:\Raws\Test.d2v")
TempGaussMC_Alpha3(2, 1, 1, EdiMode="NNEDI2")

Distributor()

is faster with TGMC Alpha 3 than TGMC Beta1mod?

The difference is quite significant as well. 10+ fps for Alpha 3 vs 9+ for Beta1.

[Didée]

I can't answer that. Still have only ancient 1core-machines at home. (And the (same old) Core-Duo at work is not the place where I can do extensive testing.)
Par.ex., I see people sometimes use Distributor(), sometimes not, and I have no clue what's the deal ...

In any case, multithreading of TGMC (so that it's worthwhile) is pretty difficult, because of the complexity of its processing chain.

MT() should be possible, but will worsen the motion search.
SetMTMode probably is a bad idea, because it requires too much ressources. (Having multiple dredges instead of one doesn't help much when it's still only one truck to take the excavation - you can only load so much onto one truck, no matter how many dredges.)
Best bet probably is to use the multithreaded MVTools of josey_wells (though it's the old v1.9 branch) ... using several cores to spread the computational effort for one frame, that's reasonable. Opposed to SetMTmode, which basically means to run TGMC {cores}-times in parallel, which is likely to fail.


In any case, this is the wrong thread for that topic.

If only a tiny fraction of the manpower & ingenuity that's going into x264 would go into MVTools, and Avisynth's/MVTools's multithreading ... <dreams>

[Gavino]

Originally Posted by Didée

I see people sometimes use Distributor(), sometimes not, and I have no clue what's the deal

When using SetMTMode, Distributor() is the function which co-ordinates the multiple threads and provides a coherent output stream. When using Avisynth via the VfW interface, it is called automatically at the end of the script.

However, for applications that bypass the VfW interface and talk directly to Avisynth (such as hc), it is necessary to call it explicitly instead. Calling it when not required is a bad idea, as is failing to call it when required, so you need to know what method your Avisynth client application uses to communicate with Avisynth.

[2Bdecided]

Originally Posted by Didée

Just because it's so much fun, here's a visual comparison between the 3.8-fps YadifMod-NNEDI2 and the 6.1-fps TGMC.
(It's Stockholm, and slowed down to 12.5 fps to see everything in its full glory.)

SAMPLE (Mediafire, ~11 MB)

Think about generalizations, and about preconceptions. Maybe there is no spoon.

Thank you. That's classic.

Partly because the "faster" TGMC settings hold up so well with that sample (going to try them on some of mine now!) - but even more because it shows that yadif isn't magic at all. I keep hearing people describe it as "pretty good" - it's not - if anything moves, it's just "bob"! Yadifmod means it's just NNEDI2 in this case, but it fails so badly on this sample. IIRC EEDI2 is happier connecting the lines on that one, but still pails in comparison with TGMC.

Cheers,
David.