nnedi2/nnedi3/eedi3

[10L23r]

pscrn -

Controls whether or not the prescreener neural network is used to decide which pixels
should be processed by the predictor neural network and which can be handled by simple
cubic interpolation.

why not spline or lanczos instead of cubic?

[Chainmax]

Originally Posted by tritical

I goofed on that one. Make sure this - nnedi2.dll - works before I post a new version again.

I was experiencing VDubMod crashes with v1.3 too, although it would just crash down without giving me time to see the error message (I think it was the "oops" one, not sure though). This DLL works perfectly. Thanks .


By the way, I have one example where it seems like EEDI2 gives better results than NNEDI2. The first screenshot is with the former, the second with the latter:




Yep, it's that clip again . I assume that due to the unique nature of both the source and the script, it's not just the switch from EEDI2 to NNEDI2 that causes the differences. In fact, the script might only work with EEDI2. In any case, I can provide you with a clip (or the whole video, it's ~160MB) and the script if you want.

[JohannesL]

EEDI2 smoothes edges (and the whole image) more. NNEDI2 is sharper and thus enhances detail (and noise) more.

[Chainmax]

That's not the only difference. Look closely at the microphone: the lines on the EEDI2 version are completely straight (and the edges themselves are sharper), whereas the ones in the NNEDI2 version aren't.

[10L23r]

what's the source?

imo, the mic in nnedi2 looks better...
nnedi2 also keeps more details; eedi2 feels more artificial.
the only place where i find eedi2 better is the outline of the face.

[Keiyakusha]

I like EEDI2 result. On NNEDI2 screenshot these additional details are less noticeable than microphone (where eedi2 shows better result). In motion these details probably can't be noticed at all, while jagged lines - easily. I wonder how NNEDI2 looks on Anime compared to eedi2...

[shoopdabloop]

EEDI2 is the smoother deinterlacer, so if you can deal with the slight loss of detail it is definitely the way to go.

NNEDI2, on the other hand, is the far superior upsizer, hands down.

[10L23r]

wait... what is the mic supposed to look like? cus the mic in eedi2 looks rly rly fake

[shoopdabloop]

Chainmax, could you upload a clip of the unfiltered source? A small one.

Unless there are other filters that are somehow causing the poor deinterlacing in both cases, perhaps it would be best to go with MCBob or TempGaussMC.
I would like to try out various deinterlacers on the source myself.

[scharfis_brain]

@chainmax: provide your unprocessed sample as well as both scripts (for eedi2 and nnedi2)

[Didée]

Originally Posted by Chainmax

That's not the only difference. Look closely at the microphone: the lines on the EEDI2 version are completely straight (and the edges themselves are sharper), whereas the ones in the NNEDI2 version aren't.

It's give and take. The diagonal rods are more straight with EEDI2, yes. But then, the lattice on the microphone's corpus are correctly (non-)interpolated only by NNEDI ... there, EEDI2 creates an artificial geometric pattern that should not be there. (And it probably will warp-around when there is slight motion.)

It's okay if you like EEDI2 better in some parts, but one should note that at the same time EEDI2 *fails* in other parts.

[*.mp4 guy]

A good interpolator will only blur/antialias/lowpass to the extent that must in order to remove aliasing. EEDI2 is far too aggressive for even the most aliased source achievable using a competent processing chain. nnedi(1/2) are extremely good at processing sources containing medium to high aliasing that is still more or less recoverable, but are not very good on sources with low/no aliasing (too slow for, if anything, likely reduced quality).

I should note at this point that most good sources will have some aliasing. Killing all aliasing in a signal will take too much of said signal to the grave with it, wheather through blurring or ringing, the damage is more or less the same.

If your source is butchered : eedi2
If your source is on the sharp side of good quality : nnedi
If your source is blurry : high quality linear resampling

Obviously there are gaps between the categories, they fall to personal taste.

[tritical]

I put up version 1.4. Same as the standalone nnedi2.dll that I posted before, except that it adds another nsize value (nsize 0,1 in v1.3 are now 1,2).

Originally Posted by 10L23r

why not spline or lanczos instead of cubic?

It's faster. Also, it doesn't make any noticeable difference. In the areas where it gets used (non-edges) they all give the same result.

@Chainmax
If you can provide a sample that would be great. As mentioned already, there is always a tradeoff between eedi2/nnedi2.

[Chainmax]

[EDIT]Link to the full video

shoopdabloop: the source is progressive, the EDI interpolators are used as a resizing method and to diminish aliasing actually.

Here's a clip of the source, which most of you guys will recognize . It contains the intro and the scene where the screenshots were taken from. Bear in mind it's encoded on Microsoft Video 1, in order to be able to work with it you'll have to load the file in VDub and make a lossless encode out of it, as AFAIK Avisynth cannot load it.

The script used is, again, familiar to most of you guys:

f=4

AVISource("X:\wherever\MakingGK-LssLss.avi",audio=false)

a=last

a.converttoyv12()

nnedi2_rpow2(qual=3,rfactor=2,cshift="spline36resize")

pointresize(a.width*f,a.height*f)

vf=last.mvanalyse(isb=false,blksize=16, truemotion=true)
vb=last.mvanalyse(isb=true,blksize=16, truemotion=true)
vf1=last.mvanalyse(isb=false,delta=2,blksize=16, truemotion=true)
vb1=last.mvanalyse(isb=true,delta=2,blksize=16, truemotion=true)

xf1=last.mvflow(vf1,thSCD1=9999)
xf=last.mvflow(vf,thSCD1=9999)
xb=last.mvflow(vb,thSCD1=9999)
xb1=last.mvflow(vb1,thSCD1=9999)

interleave(xf1,xf,last,xb,xb1)
temporalsoften(2,40,50,mode=2)
x=selectevery(5,2)

x.converttorgb()
xa=pointresize(a.width*2,a.height*2).converttoyv12().nnedi2_rpow2(qual=3,rfactor=2,cshift="spline36resize")
xb=crop(1,1,0,0).addborders(0,0,1,1).converttoyv12().pointresize(a.width*2,a.height*2).nnedi2_rpow2(qual=3,rfactor=2,cshift="spline36resize")
x=merge(xa,xb)

xvf=x.mvanalyse(isb=false,blksize=16, truemotion=true)
xvb=x.mvanalyse(isb=true,blksize=16, truemotion=true)
xvf1=x.mvanalyse(isb=false,delta=2,blksize=16, truemotion=true)
xvb1=x.mvanalyse(isb=true,delta=2,blksize=16, truemotion=true)

xxf1=x.mvflow(xvf1,thSCD1=9999)
xxf=x.mvflow(xvf,thSCD1=9999)
xxb=X.mvflow(xvb,thSCD1=9999)
xxb1=x.mvflow(xvb1,thSCD1=9999)

interleave(xxf1,xxf,x,xxb,xxb1)
temporalsoften(2,255,255,mode=2)
selectevery(5,2)

Spline36Resize(512,384)

Levels(0,1,245,16,235)

FFT3DFilter(sigma=6,plane=3,bw=32,bh=32,bt=3,ow=16,oh=16)

Tweak(sat=1.3)

dull=last
sharp=dull.LimitedSharpenFaster(Smode=4,Strength=200)
Soothe(sharp,dull,25)

c=last
GrainU=c.UtoY().AddGrain(4,0,0)
GrainV=c.VtoY().AddGrain(4,0,0)
Return ytouv(GrainU,GrainV).MergeLuma(c).gradfun2db(thr=2.4).gradfun2db().AddGrain(10,0,0)

The EEDI2 version is the same, only substituting nnedi2_rpow2(qual=3,rfactor=2,cshift="spline36resize") for eedi2().turnleft().eedi2().turnright()

[tritical]

See if this: [removed] works on that processor.

[Dark Shikari]

Originally Posted by HolyWu

01eac208: 0fd4c1 paddq mm0, mm1 <-- FAULT

What?!

PADDQ mm1,mm2/m64 ; 0F D4 /r [PENT,MMX]

paddq is part of MMX1, which should be on every chip since the Pentium 2 (and a few before).

[MasterNobody]

Originally Posted by tritical

See if this: nnedi2.dll works on that processor.

Yes. It fixes the crash.

Originally Posted by Dark Shikari

paddq is part of MMX1, which should be on every chip since the Pentium 2 (and a few before).

Probably, you are wrong and PADDQ is SSE2 instruction.

[Dark Shikari]

Originally Posted by MasterNobody

Yes. It fixes the crash.

Probably, you are wrong and PADDQ is SSE2 instruction.

NASM documentation says it's MMX, but it could be wrong.

[MasterNobody]

http://www.intel.com/Assets/PDF/manual/253667.pdf says it's SSE2. So I would trust Intel documentation more than NASM.

[IanB]

And from the Fastwire defs (very reliable) :-

{"PADDQ", "mmreg,r/m64", "0F D4 /r", Instruction::CPU_WILLAMETTE|Instruction::CPU_SSE2},

So you need CPUF_SSE2 = 0x20