nnedi2/nnedi3/eedi3

[CorruptNova]

Intel Pentium M (Centrino) with 1.5 GHz. With the new update, now it works fine on my "old" Intel Pentium 4 (2 GHz). In both cases i have installed the latest official release of AviSynth (version 2.58).


I am also getting the same problem and I have basically the same system as Archimedes, a Intel P4 3.0ghz, AviSynth 2.5.8

DebugView gives the same output as Archimedes as well

[powerPC]

a) interp = nnedi(field=-2)
tdeint(mode=2,edeint=interp)

b) interp = nnedi2(field=-2)
tdeint(mode=2,edeint=interp)

a=b:confused:

[tritical]

I put up v1.3. It should fix the remaining opt=0 problems. Changes:
+ added nsize parameter
+ updated neural network weights
- fixed problem with opt=0 and SSSE3 detection

nsize switches between the old predictor neural network architecture, nsize=1 (what was used in v1.0-1.2), and a smaller architecture, nsize=0, which is faster. The only real difference is that the number of neurons in each layer is cut in half. On my Q6600 nsize=0 gives ~50% speed increase w/ qual=1. Speed difference is larger as qual is increased. There isn't that much difference between nsize=0/nsize=1, but nsize=1 should be better quality.

Should have new example images up soon. Will probably make them lossless avis instead of single images.

@powerPC
Those two should do the same thing.

[Archimedes]

Perfect! Now it works! Thank you very much for the update.

[Lorax2161]

Hi tritical,

Thanks for nnedi2 and your other contributions.

Having a problem with version v1.3 relating to:

nnedi2_rpow2(rfactor=4)
or
nnedi2_rpow2(rfactor=2,cshift="spline36resize")

Did the required syntax change for this? Previous versions have worked fine. I rolled back to v1.2 after trying v1.3, and v1.2 still works fine.

Processor: Athlon 64 X2 Dual Core 4200+ 2.19GHz 2GB of RAM

Avisynth: v2.58

DebugView: "nnedi2: auto-detected opt setting = 5"

VirtualDub: "An instruction not supported by the CPU was executed in module 'nnedi2'

Please let me know if you require any more information.

Thanks.

[kemuri-_9]

Processor: Athlon 64 X2 Dual Core 4200+ 2.19GHz 2GB of RAM
Avisynth: v2.58
DebugView: "nnedi2: auto-detected opt setting = 5"
VirtualDub: "An instruction not supported by the CPU was executed in module 'nnedi2'

I'm getting the same issue on my Phenom II x4 940.
getting crashes on the palignr (SSSE3 instruction set) calls
use opt=4 until tritical can fix the instruction set detection.

[tritical]

I goofed on that one. Make sure this - [removed] - works before I post a new version again. :thanks:

[kemuri-_9]

I goofed on that one. Make sure this - nnedi2.dll (http://bengal.missouri.edu/~kes25c/nnedi2.dll) - works before I post a new version again. :thanks:

yes, it's correctly detecting as SSE3 (opt=4) here now.

[Lorax2161]

I goofed on that one. Make sure this - nnedi2.dll (http://bengal.missouri.edu/~kes25c/nnedi2.dll) - works before I post a new version again. :thanks:

Confirmed here as well, thanks.

DebugView: "nnedi2: auto-detected opt setting = 4 (127)"

[MadRat]

I'm afraid vdub is crashing and saying:
An SSE2 (Pentium 4/Athlon 64) instruction not supported by the CPU was executed in module 'nnedi2'.
I have an AMD Anthlon 64 3200+ and opt=3 works so yeah there's still an auto detect problem. Sorry to have to report bad news.

[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]

I goofed on that one. Make sure this - nnedi2.dll (http://bengal.missouri.edu/~kes25c/nnedi2.dll) - works before I post a new version again. :thanks:

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:

http://img514.imageshack.us/img514/5647/eedi2.png
http://img190.imageshack.us/img190/9713/nnedi2.png

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]

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

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 (http://www.sendspace.com/file/jgi6by)

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

Here (http://www.mediafire.com/?sharekey=e1b5f41eed4d25e0c2b435915e8821d723312b95698279d75be6ba49b5870170)'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. :thanks:

[Dark Shikari]

01eac208: 0fd4c1 paddq mm0, mm1 <-- FAULTWhat?!

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]

See if this: nnedi2.dll (http://bengal.missouri.edu/~kes25c/nnedi2.dll) works on that processor. :thanks:
Yes. It fixes the crash.
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]

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

[g-force]

as for the nnedi2/eedi2 debate, why not something like this?

Function EDImod(clip input)
{# function by g-force v.1.00
#connects more lines than NNEDI2, without the blur bubbles and loss of detail of EEDI2

nn=input.NNEDI2(dh=true,field=1)
ee=input.EEDI2()

Interleave(ee,ee.RemoveGrain(12,-1),ee.RemoveGrain(4,-1))
Clense(reduceflicker=false,grey=true)
SelectEvery(3,1)

MT_MakeDiff(last,last.RemoveGrain(12,-1))
last.Repair(MT_MakeDiff(nn,ee),1,-1).MT_LUTxy(last,"x 128 - abs y 128 - abs < x y ?")

ee.MT_AddDiff(last,chroma="copy first")

last.Repair(nn,9)

Return(last)
}

-G

[Didée]

@g-force: Quick question.

The final repair(9) is the most stringuent of the "line-repairing" modes of removegrain. Assuming the scenario that

1) EEDI2 does connect a given diagonal
2) NNEDI2 does not connect the same diagonal

then, how can it be that the result should connect the diagonal, when NNEDI2 is the reference? If NNEDI2 didn't connect, shouldn't the "line-repair" mode remove the connection that EEDI2 did?

[g-force]

@g-force: Quick question.

The final repair(9) is the most stringuent of the "line-repairing" modes of removegrain. Assuming the scenario that

1) EEDI2 does connect a given diagonal
2) NNEDI2 does not connect the same diagonal

then, how can it be that the result should connect the diagonal, when NNEDI2 is the reference? If NNEDI2 didn't connect, shouldn't the "line-repair" mode remove the connection that EEDI2 did?

Agreed, but Repair(9) doesn't repair ALL lines, so, yeah, it basically undoes most of what EEDI2 did, just not all of it.

One could play around with different repair modes I suppose, and use more or less of the EEDI2 result, but then I suspect those darn blur bubbles would start showing up again.

-G

[Revgen]

EEDI2 is okay for alot of sources that aren't sports related.

However, most of what I deinterlace is sports material. IMO, EEDI2 simply doesn't cut it like NNEDI or NNEDI2 does when it comes to sports, especially the diagonal lines of the courts/fields and preserving the detail of the athletes. The cameras usually have far away views showing all of the players on the court/field so preserving details is important, otherwise the athletes look like blurry figments.

[Chainmax]

as for the nnedi2/eedi2 debate, why not something like this?

Function EDImod(clip input)
{# function by g-force v.1.00
#connects more lines than NNEDI2, without the blur bubbles and loss of detail of EEDI2

nn=input.NNEDI2(dh=true,field=1)
ee=input.EEDI2()

Interleave(ee,ee.RemoveGrain(12,-1),ee.RemoveGrain(4,-1))
Clense(reduceflicker=false,grey=true)
SelectEvery(3,1)

MT_MakeDiff(last,last.RemoveGrain(12,-1))
last.Repair(MT_MakeDiff(nn,ee),1,-1).MT_LUTxy(last,"x 128 - abs y 128 - abs < x y ?")

ee.MT_AddDiff(last,chroma="copy first")

last.Repair(nn,9)

Return(last)
}

-G

Thanks for thinking this up, and I apologize for the very late reply. Pending some reading on the Masktools docs (I am very rusty now in this regard), can someone explain in a few words what is this doing? Seems like it is mixing the EEDI2 and NNEDI2 results, then toying around with the differences, but I can't gander much beyond that. Also, I take it this approach would not benefit from using edge masks (i.é: using EEDI2 only on edges and NNEDI2 everywhere else)?

[Didée]

Briefly: Sharpen up EEDI, then limit the result by NNEDI2 via the line-repair mode 9.


Slighty more elaborative:

interleave(orig,rg12,rg4) - clense - selectevery
That combo does a sort of "blurry-clipping", i.e. damping-down of signal peaks. (The result is highly similar to what my "MinBlur" routine does. Same idea, different approch. This one probably is slightly faster.)

diff(last,last.rg12) - repair( diff(ee,nn) ).mt_lutxy(..)
This figures the sharpening kernel. From the two differences: diff{damped-EEDI,gauss1(damped-EEDI)} - and - diff{EEDI,NNEDI}, choose that difference that is smaller (i.e. makes less change).

ee.adddiff(..)
Apply the sharpening kernel.

repair(nn,9)
Limit the sharpened-up EEDI to not exceed the clamp spanned by those two neighbor pixels in the NNEDI clip that are most agreeing on their value. (repair, mode9)


Frankly, I'm not sure if the elaborotive version is understandable.:D - Tried about my best, but it's not easy to squeeze in just a few words.

[Chainmax]

Thanks for the explanation :). Sounds pretty cool, and I guess it would be more effective than my suggestion. I'll toy around with it and post a couple of screenshots here.

[Didée]

While you're at toying, compare also with

nn = theclip.NNEDI2(dh=true,field=1)
nn.sharpen(.6789012345).repair(nn,9)

and see if it's much of a difference. (Vary sharpen strength, can't predict what's a good value here.)

[Didée]

Maybe EDImod helps on the occasional pixel, if you search and look out hard. But, on the occasional noticeable errors of NNEDI2, it won't help anything worth ...

Case example, together with two other simple things one can try:

http://thumbnails22.imagebam.com/5450/9951e054498949.gif (http://www.imagebam.com/image/9951e054498949)

Neither method can rule out errors, because it's not possible to reckognize errors as such. (Not by such simple means, at least.)

[g-force]

The result is highly similar to what my "MinBlur" routine does. Same idea, different approch.

More accurately: "The idea was completely stolen from Didée and tweaked beyond recognition"

As a matter of fact, that's not the only thing that was stolen. Basically, the whole function applies a very dumbed-down version of Didée's Contrasharpening to EEDI (contrasharpen EEDI with NNEDI) then apply some bandages in the form of the repair function to help with the artifacts EEDI produces. Not the greatest function in the world, but it is what it is.

I wrote this function for a source that has some pretty bad aliasing due to a point-resize down applied at some point. I've since switched to the method that I think is the same as what scharfis_brain suggests here:

http://forum.doom9.org/showthread.php?t=150346

I think this is the same as:

NNEDI2(dh=true,field=1)
NNEDI2(dh=false,field=0)

-G

[scharfis_brain]

I think this is the same as:

NNEDI2(dh=true,field=1)
NNEDI2(dh=false,field=0)

-G

I am becoming old... I completely miss the easy stuff sometimes ;)

[g-force]

I am becoming old... I completely miss the easy stuff sometimes ;)

Yours makes logical sense, gets the job done, and probably doesn't take much more time.

I noticed in the post that I linked to, you call it a "very disgusting way...". This is no more disgusting that the crazy stuff that someone else has done to the video to get it to the point that you need to do something so drastic. I originally thought the same way, but thinking about it more i realize that when doing a "good" resize, you have all interpolated pixels anyway. Now if someone does a point resize that causes lots of aliasing, they could equally say, "well, at least I have some of the original pixels". Sounds good until you see what a hatchet job of the input they made. So, why not interpolate ALL of the pixels, just like the good resizer would have done anyway?

-G

[scharfis_brain]

I think the video in the thread you mentioned hasn't been butchered at all.

It is high speed footage taken with a high speed camera.

These cameras usually will drop lots of sensor pixels in order to achieve fast readout rates.

[g-force]

I think the video in the thread you mentioned hasn't been butchered at all.

It is high speed footage taken with a high speed camera.

These cameras usually will drop lots of sensor pixels in order to achieve fast readout rates.

Oh, I see. Well, whether it was done by a person or the camera, the video is still decimated instead of being interpolated/resampled. So my point is, why not do after the fact what should have been done to begin with.

-G

[Didée]

Regarding the source in "that other thread" - though not fully sure, I think the reason that a simple nnedi interpolation looks still jaggy is due to the camera's sampling. NNEDI assumes that there is *one* sample (scanline) missing between the present samples. But there, probably the camera dropped much more, and there are actually two or three, or evenmore samples missing between the actual samples. Which is a scenario that NNEDI is not really made for ... there is much more data missing than NNEDI assumes that it would!

[tritical]

I have a new filter almost ready that is much more an extension of eedi2 than nnedi2, but does use some ideas from nnedi2. It is much better at line/edge connection. In terms of subjective visual appearance I definitely prefer it for deinterlacing. Image enlargement is another story. Hopefully this weekend a rough first cut will be done. Just a warning, it will be quite slow since it takes into account how every pixel in the same line is being interpolated.

[scharfis_brain]

Oh, I see. Well, whether it was done by a person or the camera, the video is still decimated instead of being interpolated/resampled. So my point is, why not do after the fact what should have been done to begin with.
-G
With high-speed cameras it often is impossible to interpolate, cause the camera hadn't the time available to read out all necessary pixels.
The only solution would have been an exchangable optical low pass filter in front of the sensor. (Like the fixed ones in front of bayer based colour sensors to avoid colour moire).

[g-force]

I have a new filter almost ready that is much more an extension of eedi2 than nnedi2, but does use some ideas from nnedi2. It is much better at line/edge connection. In terms of subjective visual appearance I definitely prefer it for deinterlacing. Image enlargement is another story. Hopefully this weekend a rough first cut will be done. Just a warning, it will be quite slow since it takes into account how every pixel in the same line is being interpolated.

I look forward to checking it out!

-G

[tritical]

A little late, but here is an early version: eedi3 (http://bengal.missouri.edu/~kes25c/eedi3/eedi3.dll). Like I said, it is SLOW. Atm it isn't optimized at all... no asm, no threading, not even on the algorithmic level. It's just proof of concept stage.

Suggested usage is eedi3(sclip=nnedi2()) for same rate deinterlacing, and eedi3(field=-2,sclip=nnedi2(field=-2)) for double rate.

Some example images:
http://bengal.missouri.edu/~kes25c/eedi3/soccer_original.png
http://bengal.missouri.edu/~kes25c/eedi3/soccer_eedi2.png
http://bengal.missouri.edu/~kes25c/eedi3/soccer_nnedi2.png
http://bengal.missouri.edu/~kes25c/eedi3/soccer_eedi3+nnedi2.png

http://bengal.missouri.edu/~kes25c/eedi3/bbcourt_original.png
http://bengal.missouri.edu/~kes25c/eedi3/bbcourt_eedi2.png
http://bengal.missouri.edu/~kes25c/eedi3/bbcourt_nnedi2.png
http://bengal.missouri.edu/~kes25c/eedi3/bbcourt_eedi3+nnedi2.png

Haven't created a readme yet, but the parameter strings from the code are:

"eedi3", "c[field]i[dh]b[Y]b[U]b[V]b[alpha]f[beta]f[gamma]f[nrad]i[mdis]i[hp]b[ucubic]b[cost3]b[vcheck]i[vthresh]f[sclip]c"

"eedi3_rpow2", "c[rfactor]i[alpha]f[beta]f[gamma]f[nrad]i[mdis]i[hp]b[ucubic]b[cost3]b[vcheck]i[vthresh]f[cshift]s[fwidth]i[fheight]i[ep0]f[ep1]f"

Similar to nnedi2 calls, field/dh/y/u/v are the same as nnedi2. rfactor/cshift/fwidth/fheight/ep0/ep1 are the same as nnedi2_rpow2. The other parameters:

alpha/beta/gamma (defaults: 0.15,0.2,20.0):
These trade off line/edge connection vs artifacts created. alpha and beta must be in the range [0,1], and the sum alpha+beta must be in the range [0,1]. alpha is the weight given to connecting similar neighborhoods.. the larger it is the more lines/edges should be connected. beta is the weight given to vertical difference created by the interpolation... the larger beta is the less edges/lines will be connected (at 1.0 you get no edge directedness at all). The remaining weight (1.0-alpha-beta) is given to interpolation direction (large directions (away from vertical) cost more)... so the more weight you have here the more shorter connections will be favored. Finally, gamma penalizes changes in interpolation direction, the larger gamma is the smoother the interpolation field between two lines (range is [0,inf].

My findings have been that alpha in [0.08-0.2] and beta in [0.1-0.3] work well. If lines aren't getting connected than increase alpha and maybe decrease beta/gamma. Go the other way if you are getting unwanted artifacts.

hp/ucubic/cost3 (defaults: false, true, true):
These are speed vs quality options. hp=true, use half pel steps, hp=false, use full pel steps. ucubic=true, use cubic 4 point interpolation, ucubic=false, use 2 point linear interpolation. cost3=true, use 3 neighborhood cost function to define similarity, cost3=false, use 1 neighborhood cost function.

vcheck/vthresh/sclip (defaults: 2 range is [0-3], 32 range is (0,inf], NULL):
A inverse reliability measure in the range [0,255] is created at each interpolated location. The generated pixel value is averaged with the pixel value at the same location in sclip using:

a = min(rmeasure/vthresh,1.0)
(1.0-a)*generated_val+a*sclip_val

How rmeasure is generated is controlled by vcheck. vcheck=0, always gives rmeasure=0 (so no averaging with sclip). As you increase from 1 to 2 to 3 it gets stricter so rmeasure will always be greater for vcheck=2 than 1, etc...

If sclip is not given than cubic interpolation is used instead for those values.

Any testing would be appreciated, and any images that fail miserably. eedi3 isn't that great at enlargement, it's mainly for deinterlacing.

[elguaxo]

great! :thanks: