nnedi2/nnedi3/eedi3

[Reel.Deel]

Would be nice if eedi3&co could be recompiled with a newer Visual Studio...

A while back 06_taro recompiled EEDI3 with ICL12. Here you go:
[EEDI3_ICL12 (http://nmm.me/oe)], [EEDI3_ICL12_static (http://nmm.me/of)]

For NNEDI3 how about using -Vit-'s version? It's compiled with MSVC10.
-Vit- has a separate 2.5 (http://forum.doom9.org/showpost.php?p=1503034&postcount=691) / 2.6 (http://forum.doom9.org/showpost.php?p=1568142&postcount=1126) plugin package. I've been using the 2.6 one for a while and everything worked nicely.
I recently upgraded to AVS alpha4 and had to switch from his 2.6 to the 2.5. So far, everything seems to be working as good as it did.

[wOxxOm]

on default settings nnedi3_rpow2 is about 20% faster (39 -> 47 fps @ 480p -> 960p) when recompiled (https://dl.dropboxusercontent.com/u/40341141/nnedi3-tp7.7z) against FTurn (http://forum.doom9.org/showthread.php?p=1638416) instead of avisynth's built-in turnleft/turnright.

Edit1: nnedi3_rpow2(), not nnedi3()
Edit2: FTurn plugin should be (auto)loaded so that nnedi3_rpow2 linked in my post could use it, see the discussion below.

[Selur]

Nice, thanks for sharing :)

[TurboPascal7]

on default settings nnedi3 is about 20% faster (39 -> 47 fps @ 480p -> 960p) when recompiled (https://dl.dropboxusercontent.com/u/40341141/nnedi3-tp7.7z) against FTurn (http://forum.doom9.org/showthread.php?p=1638416) instead of avisynth's built-in turnleft/turnright.

Only nnedi3_rpow2, this has no effect on nnedi since it doesn't use turns.

[Groucho2004]

on default settings nnedi3 is about 20% faster (39 -> 47 fps @ 480p -> 960p) when recompiled (https://dl.dropboxusercontent.com/u/40341141/nnedi3-tp7.7z) against FTurn (http://forum.doom9.org/showthread.php?p=1638416) instead of avisynth's built-in turnleft/turnright.
I can't confirm that. I get 5% speedup at most with the "official" Avisynth 2.6 Alpha4 (i5 2500K).
When I rebuild avisynth and the original nnedi3 with ICL10 it's actually a bit faster than the DLL you posted.

[wOxxOm]

Sorry for the confusion, Groucho2004, I've fixed my post above, nnedi3_rpow2, of course.

[Selur]

@Groucho2004: would be nice if you could share the icl10 build of nnedi3.

[Groucho2004]

@Groucho2004: would be nice if you could share the icl10 build of nnedi3.

Here (http://www.mediafire.com/download/ft1ophbu6a7b38u/nnedi3_icl10.zip) you go.

[Groucho2004]

Sorry for the confusion, Groucho2004, I've fixed my post above, nnedi3_rpow2, of course.

That's what I was referring to as well.

[Selur]

Here you go.
Thanks :D

[Groucho2004]

on default settings nnedi3_rpow2 is about 20% faster (39 -> 47 fps @ 480p -> 960p) when recompiled (https://dl.dropboxusercontent.com/u/40341141/nnedi3-tp7.7z) against FTurn (http://forum.doom9.org/showthread.php?p=1638416) instead of avisynth's built-in turnleft/turnright.
OK, did some tests using "official" Avisynth 2.6 Alpha4:

The test clip is a short 720p avc video.

Script:
LoadPlugin("DGDecodeNV.dll")
LoadPlugin("nnedi3.dll")
DGSource("F:\Test\test.dgi")
NNEDI3_rpow2(rfactor = 2)

Results (AVSMeter):
nnedi3_tritical.dll : 26.70 fps (from tritical's website)
nnedi3_fturn.dll : 28.14 fps
nnedi3_icl10.dll : 28.28 fps

[TurboPascal7]

It looks like you didn't load fturn.dll. It would use avisynth's turn functions as usual in this case. "Compiled against" was an incorrect term. "Able to use if available" is.

[Selur]

So nnedi3_fturn.dll will use the fturn.dll if it is loaded in the script?

[wOxxOm]

So nnedi3_fturn.dll will use the fturn.dll if it is loaded in the script?Yes.
Or if fturn was autoloaded from plugins directory.

[TurboPascal7]

Let me just paste the code.
auto turnRightFunction = env->FunctionExists("FTurnRight") ? "FTurnRight" : "TurnRight";
auto turnLeftFunction = env->FunctionExists("FTurnLeft") ? "FTurnLeft" : "TurnLeft";
try
{
double hshift = 0.0, vshift = 0.0;
if (vi.IsRGB24())
{
for (int i=0; i<ct; ++i)
{
v = new nnedi3(v.AsClip(),i==0?1:0,true,true,true,true,nsize,nns,qual,etype,pscrn,threads,opt,fapprox,env);
v = env->Invoke(turnRightFunction,v).AsClip();
v = new nnedi3(v.AsClip(),i==0?1:0,true,true,true,true,nsize,nns,qual,etype,pscrn,threads,opt,fapprox,env);
v = env->Invoke(turnLeftFunction,v).AsClip();
}
hshift = vshift = -0.5;
}

Nothing fancy, one minute's job. If fast alternative is available - use it, otherwise go with default one. Optimizing this function in the core/writing nnedi3_rpow2 as a script would be better, but we get what we get. I'm surprised tritical didn't implement fast turns himself.

[Selur]

Okay, thanks, that clears it up. :)

[Groucho2004]

It looks like you didn't load fturn.dll. It would use avisynth's turn functions as usual in this case. "Compiled against" was an incorrect term. "Able to use if available" is.

Aaaahh, I see. Now that certainly changes things. With FTurn I get actually 57 fps (!) in the same scenario. Nice.

[Myrsloik]

Since we're on the subject of speed and turning...

Currently nnedi3_rpow2() does this internally:
nnedi3()
turnright()
nnedi3()
turnleft()

It should in theory be slightly faster if rearranged to:
turnright()
nnedi3()
turnleft()
nnedi3()

I didn't bother to test it myself but you'll be turning half the number of pixels so maybe it'll be a noticable improvement. Or maybe it'll look a lot different... who knows...

[PetitDragon]

Yes.
Or if fturn was autoloaded from plugins directory.

Hi wOxxOm,

If I do it with ffdshow in realtime, I just put both nnedi3_fturn.dll and fturn.dll in avisynth plugin folder, then nnedi3_rpow2 will use the new fturn automatically. right?

[wOxxOm]

PetitDragon, yeah. Anyway you can check in ffdshow if FTurn is autoloaded by explicit call: FTurnLeft().FTurnRight()

[PetitDragon]

PetitDragon, yeah. Anyway you can check in ffdshow if FTurn is autoloaded by explicit call: FTurnLeft().FTurnRight()

Got it! :thanks:

[aegisofrime]

Hi Groucho2004! While you are at it, do you think you could do a ICL10 compile of the Vapoursynth version of NNEDI3 as well?

[Groucho2004]

Hi Groucho2004! While you are at it, do you think you could do a ICL10 compile of the Vapoursynth version of NNEDI3 as well?
It won't make any difference. All the "speed-relevant" code is already ASM. A C compiler can't perform miracles. :)

[cretindesalpes]

I did some modifications on EEDI3 0.9.2 (https://ldesoras.fr/src/avs/eedi3-0.9.2.zip):
SSE/SSE2 optimizations, giving a nice 4× speedup.
Added an optional mask to process only the specified parts. It’s helpful when EEDI3 is used as an anti-aliasing processor on cartoon-like materials. Additional 1.2×–2× speedup, depending on the source.
I fixed a typo in the original code too, but I don’t know if it has any visible effect.
Be sure to have Visual C++ Redistributable for Visual Studio 2012 (http://www.microsoft.com/download/details.aspx?id=30679) installed (needed for vcomp11.dll).
The SSE2 code is 16-bit ready, although the glue code to pass stack16 clips hasn’t been implemented yet. It will probably come in a next update.

If you compare the C++ and SSE2 results, there are some rare and minor differences here and there, but I don’t know the exact reason at the moment (different rounding? bug?), and it’s difficult to tell which result is better.

[mandarinka]

Regarding eedi3... today I found that eedi3rpow2 displays the same chroma shift issue that nnedi3rpow2 has - see this post (http://forum.doom9.org/showthread.php?p=1499826#post1499826) and following discussion. Just so that people know.

Sadly I totally forgot that the issue is (still) there, only finding out today. Aw, I was using nnedi3rpow2 for antialiasing purposes...
I'm not sure how correct would Sapo84's scripted workaround (described back there) be, since I have no idea how exactly does nnedi3 implement the shifting mechanism in nnedi3rpow2.

Edit: Nice to see this update, cretindesalpes. Thanks!

[mawen1250]

Regarding eedi3... today I found that eedi3rpow2 displays the same chroma shift issue that nnedi3rpow2 has - see this post (http://forum.doom9.org/showthread.php?p=1499826#post1499826) and following discussion. Just so that people know.

Sadly I totally forgot that the issue is (still) there, only finding out today. Aw, I was using nnedi3rpow2 for antialiasing purposes...
I'm not sure how correct would Sapo84's scripted workaround (described back there) be, since I have no idea how exactly does nnedi3 implement the shifting mechanism in nnedi3rpow2.

Edit: Nice to see this update, cretindesalpes. Thanks!
nnedi3_rpow2 internally uses Spline36Resize to fix the vertical chroma shift introduced by nnedi3(dh=True, field=1).nnedi3(dh=True, field=0).nnedi3(dh=True, field=0)...
For horizontal scaling, nnedi3_rpow2 doesn't produce horizontal chroma shift for MPEG-2 chroma placement by nnedi3(dh=True, field=1).nnedi3(dh=True, field=1).nnedi3(dh=True, field=1)...(both of them are left-aligned)

When "cshift" is set, nnedi3_rpow2 uses AviSynth resizers to fix the center shift introduced by nnedi3. As for the chroma shift issues when "fwidth" is set, that's exactly the problem of AviSynth's resizers. For 4:2:x content, AviSynth's resizers always assume they are of MPEG-1 chroma placement and produce horizontal chroma shift.

Recently I wrote a script named Resize8, which fixes the chroma shift issues of AviSynth's resizers: http://www.nmm-hd.org/newbbs/viewtopic.php?f=7&t=1323
I have also written a script named nnedi3_resize16, which combines nnedi3 & Dither_resize16 for scaling & color space transferring, and it also correctly deal with center shift & chroma shift: http://www.nmm-hd.org/newbbs/viewtopic.php?f=7&t=1117

[Selur]

Be sure to have Visual C++ Redistributable for Visual Studio 2012 installed (needed for vcomp11.dll).
how about a statically compiled version?

[TurboPascal7]

how about a statically compiled version?
Out of curiosity: why?

[Selur]

Because having to keep track which avisynth dlls needs what runtime is a pain and atm. no other plugin is using the 2012 runtime, especially if you use Avisynth as a portable package.

[wOxxOm]

y8, yv16, yv24, please.

[zero9999]

I have also written a script named nnedi3_resize16, which combines nnedi3 & Dither_resize16 for scaling & color space transferring, and it also correctly deal with center shift & chroma shift: http://www.nmm-hd.org/newbbs/viewtopic.php?f=7&t=1117
here's (https://github.com/AviSynth/avs-scripts#eedi3_resize) a script for Firesledge's eedi3 mod that is based on mawen1250s nnedi3_resize16.

[feisty2]

here's (https://github.com/AviSynth/avs-scripts#eedi3_resize) a script for Firesledge's eedi3 mod that is based on mawen1250s nnedi3_resize16.

have you considered using eedi3+nnedi3 instead of pure eedi3/nnedi3, because eedi3 seems failed to connect small aliasing like something caused by downscaling with bicubicresize (b=-1,c=0) and nnedi3 failed to connect large aliasing like badly deinterlaced clips, but eedi3 (sclip=nnedi3 ()) can connect both kinds of aliasing

[zero9999]

have you considered using eedi3+nnedi3 instead of pure eedi3/nnedi3, because eedi3 seems failed to connect small aliasing like something caused by downscaling with bicubicresize (b=-1,c=0) and nnedi3 failed to connect large aliasing like badly deinterlaced clips, but eedi3 (sclip=nnedi3 ()) can connect both kinds of aliasing

eedi3_resize isn't supposed to be an antialiasing script, but more like a building block for the actual antialiasing script (http://forum.doom9.org/showthread.php?p=1657610). That said, i totally forgot about this one and will add it to HiAA

[feisty2]

eedi3_resize isn't supposed to be an antialiasing script, but more like a building block for the actual antialiasing script (http://forum.doom9.org/showthread.php?p=1657610). That said, i totally forgot about this one and will add it to HiAA

when upscaling, the possibility of small aliasing that eedi cannot connect contained in source clip is much bigger than large aliasing like badly deinterlaced clip, so it makes more sense to upscale with nnedi3 or eedi3+nnedi3

[zero9999]

when upscaling, the possibility of small aliasing that eedi cannot connect contained in source clip is much bigger than large aliasing like badly deinterlaced clip, so it makes more sense to upscale with nnedi3 or eedi3+nnedi3

do you have a sample at hand that demonstrates this issue?

[feisty2]

do you have a sample at hand that demonstrates this issue?

here
source (videos suffered from aliasing like this are very common, maybe caused by bicubicresize (b=-1,c=0))
http://thumbnails109.imagebam.com/29574/82f832295739191.jpg (http://www.imagebam.com/image/82f832295739191)
eedi3_rpow2 (rfactor=2) (aliasing is still there)
http://thumbnails112.imagebam.com/29574/9f9d1d295739370.jpg (http://www.imagebam.com/image/9f9d1d295739370)
nnedi3_rpow2 (rfactor=2) (aliasing is gone)
http://thumbnails110.imagebam.com/29574/56990e295739428.jpg (http://www.imagebam.com/image/56990e295739428)
eedi3 (dh=true,sclip=nnedi3 (dh=true))
TurnLeft()
eedi3 (dh=true,sclip=nnedi3 (dh=true))
turnright () (best result)
http://thumbnails111.imagebam.com/29574/aa74d6295739507.jpg (http://www.imagebam.com/image/aa74d6295739507)

[Bloax]

They're certainly very sharp edges, but I wouldn't really call that aliasing.

[jpsdr]

I've ported NNEDI3 v0.9.4 to x64. It's working with new API, so, only avisynth 2.6 or avs+. If some are interested to test (of course, it's intented/supposed to work, but maybe there still some issues i may have not encounter in my tests).

You can get binaries here (https://github.com/jpsdr/NNEDI3/releases/download/v0.9.4.1/NNEDI3_v0_9_4_1.7z).
Source files are here (https://github.com/jpsdr/NNEDI3).

[jpsdr]

Updated version (Add Y8, YV16 and YV24) of my ported NNEDI3. More here (http://forum.doom9.org/showthread.php?p=1661944#post1661944).

EDIT :
Another updated version (add fturn support). More here (http://forum.doom9.org/showthread.php?p=1662012#post1662012).

[jpsdr]

I've created specific thread for port of NNEDI3 v0.9.4. More here (http://forum.doom9.org/showthread.php?t=170083).

[hydra3333]

I am getting a crash that VDubMod attributes to an out-of-bounds error that might be originated in nnedi3. How can I modify this to be able to encode?

Hello, did you get a workaround for this ?

[BBA163]

Who can make eedi3 more fast...

[GMJCZP]

I thought it was my imagination, but it is true that eedi3 is super slow. Please could do it faster?

[Reel.Deel]

I thought it was my imagination, but it is true that eedi3 is super slow. Please could do it faster?

Are you aware of this update (http://forum.doom9.org/showpost.php?p=1652667&postcount=476)?

[GMJCZP]

Reel.Deel I can't to access to the link, my web browser reject it.

[Bloax]

Just add an exception, or if you're too scared then just
http://forum.doom9.org/showthread.php?p=1652667#post1652667

or alternatively just read the the previous page of this thread

[GMJCZP]

Thank you all for helping me, but I think it was not necessary so much mystery, only to tell me it was version 0.9.2 (cretindesalpes) have been enough. That is the version I already had.

I did some tests with Santiag and "Sangnom" (using Sangnom2) and the process would take approximately 43 min, in contrast to "eedi3" was almost 11 hours! And that I added to Santiag previously Fturn.

Could it be that is incompatible eedi3 with Fturn, as I read with another version of nnedi3? :thanks: again.

[feisty2]

nnedi3 works rather fast because it adopts the "prescreener" method, aka "only process the edi necessary parts like edges with the edi algorithm, and bicubic for other parts", and yet, prescreener does not (maybe never will) work on eedi3 cuz it requires every vertical line to calculate the edi similarity stuff, so, its just slow like hell, and no way outta it

[colours]

mclip (default: not set)

A mask to use edge-directed interpolation only on specified pixels. The clip should have the same format as the input clip. Pixels where the mask is 0 are generated using cubic linear or bicubic interpolation. The main goal of the mask is to save calculations.
This parameter does not exist in eedi3_rpow2.

This pretty much functions as a prescreener if you use an edge mask.

[GMJCZP]

Thank you for your observation, colours.

I applied the option mclip in Santiag (function santiag_eedi3) as follows (additions in red):

...
c_edge = c.mt_edge()
c.eedi3(dh=dh, field=field, threads=threads, vcheck=vcheck, sclip=sclip, mclip=c_edge)
}
...

I did another test and spent almost 11 hours to just over 6 hours, and the speed increased by approximately 40%. But I'm not satisfied, the turtle was put a rocket on the back, but is still tortoise.

The idea applied it correctly?