nnedi2/nnedi3/eedi3

[Groucho2004]

Originally Posted by wOxxOm

on default settings nnedi3_rpow2 is about 20% faster (39 -> 47 fps @ 480p -> 960p) when recompiled against FTurn 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]

Originally Posted by Selur

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]

Originally Posted by 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.

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]

Originally Posted by wOxxOm

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]

Originally Posted by wOxxOm

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

Got it!

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

Originally Posted by 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?

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:

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

Originally Posted by mandarinka

Regarding eedi3... today I found that eedi3rpow2 displays the same chroma shift issue that nnedi3rpow2 has - see this post 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]

Originally Posted by Selur

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.