nnedi2/nnedi3/eedi3

[XhmikosR]

Ok, thanks for your results. I'll wait for someone with Intel cpu to see if there's a difference there.

[jpsdr]

What is the Distributor() command in the script ?

[julius666]

Everything works fine here. I built nnedi3 with MSVC2010 and ICL 11. Can someone compare them to the original build speed-wise?
nnedi3_MSVC2010_SSE2 (http://xhmikosr.1f0.de/avisynth/nnedi3_MSVC2010_SSE2.7z)
nnedi3_VS2008_ICL11 (http://xhmikosr.1f0.de/avisynth/nnedi3_VS2008_ICL11.7z)

Could you build a 64-bit version too?

[ajp_anton]

avisource(".avi").trim(0,-500) #384x480, interlaced, YUY2
nnedi3(field=-1)
#nnedi3(field=-2)

Average of 4 runs:
Core i7 at 3.4GHz:
field= -1 -2
tritical's: 83.21 114.05
MSVC2010: 83.29 114.04
ICL11: 83.24 113.94

Athlon II x4 at 2.8GHz:
field= -1 -2
tritical's: 54.13 67.86
MSVC2010: 54.13 67.86
ICL11: 52.70 66.71
edit: Added AMD results.
nnedi3_rpow2 doesn't work for some reason... not with eedi3 or nnedi2 either (happened to have the .dll's), and they did a while ago, so I guess it's because of my computer (computers...).

[Usedocne]

Thanks for the compiles XhmikosR. Doesn't look like theres much of a difference between them though, going by the speed tests.

Be interesting to see a 32-bit versus 64-bit nnedi3 speed test done now.

[HeadlessCow]

There's no reason to average. Just take the fastest time.

[IanB]

@IanB
I think I still have the v0.9.1 source code around. I can post that, but really it is just the sse2 floating point code in nnedi3 minus any sse2 instructions + the necessary workarounds.
It was more just of academic interest to see how you did "the necessary workarounds".

[IanB]

Why do people still think the compiler will make any difference in speed to software that is cpu bound totally in the hand written SSE2 assembler part of the code.

Sure pure C++ code or idiotic code written using intrinsics might get a small boost, but the point of hand written SSE2 assembler is to squeeze the last erg of performance out of the cpu.

I personally find it insulting when people attempt to assert that a compiler might make any difference in performance to hand written assembler code.

[tritical]

It was more just of academic interest to see how you did "the necessary workarounds".

In the floating point path the only real thing to work around is the lack of parallel int->float and float->int conversions in sse taking 128-bit registers as source/dest. In sse2 you get cvtdq2ps/cvtps2dq. int->float is required in both the first/second stage extract() methods and two of the three exp() methods require float->int. You also have to give up pshufd in the prescreener, which can be used to eliminate horizontal reductions. Everything else is basically using shufps instead of some sse2 shuffling instructions. For the int16 path you'd basically have to replace all the 128-bit code with 64-bit mmx code since all of the integer instructions on 128-bit require sse2. Either way, it was just easier to only support sse2.

[XhmikosR]

I personally find it insulting when people attempt to assert that a compiler might make any difference in performance to hand written assembler code.

No problem, feel insulted then. Even if I gain 1% by changing the compiler is fine for me.

[jpsdr]

Be interesting to see a 32-bit versus 64-bit nnedi3 speed test done now.

Interesting only if all the ASM code is re-writen to take use of what 64 bits adds (more registers for exemple). If it's 'simply' recompiled, you 'only' gain a 64bits version, but no performances.
As there is a lot of ASM inline, porting to 64bits will not be easy. You have first to take out all the asm inline on external files, and re-write them...

[Usedocne]

@jpsdr

Hmm... that doesn't sound like too much fun. Still a 64-bit compile is needed for those using Avisynth64 (hopefully me someday).

[Dark Shikari]

@jpsdr

Hmm... that doesn't sound like too much fun. Still a 64-bit compile is needed for those using Avisynth64 (hopefully me someday).Well, start by fixing Avisynth64; its assembly code is also broken.

[Usedocne]

@Dark Shikari

Lol, wish I could, but I'm no programmer. Just a lowly VE hobbyist. :D

[tritical]

64-bit test build: http://bengal.missouri.edu/~kes25c/nnedi3_64.dll

This was built with avisynth.h from JoshyD's 64-bit 2.5.8 MT version. Any testing or reports are welcome :thanks:.

[Didée]

Quick dash with nnedi3(field=-2) on planet x64. It's breathing, it's running, it's reaching goal: seems to work fine. :)

About same speed as x86, perhaps slightly slower ... 3 seconds more for ~29000 output frames, but it was only one single test run.
Anyway, it's close to 100 fps on 720x576i, using 8 threads/4cores on an i7@3.33. (75 to 120 fps, scene dependent.)

average 95.9 fps with internal multithreading (8 threads)
average 113.8 fps with setmtmode(2,8)

[jpsdr]

@tritical : Do you plan to optimize your ASM code for 64 bit also ?

[tritical]

I already changed the few assembly functions that could benefit from the extra xmm registers. None of the sse2 routines were really limited by lack of registers, and the function call overhead is already small. I would not except any noticeable change in speed for the sse2 path going from 32 bit to 64 bit. The C code path is definitely faster. Of course, that is not intended for actual usage.

Here is a 64bit test version of eedi3_64 (http://bengal.missouri.edu/~kes25c/eedi3_64.dll) (I couldn't find a build by anyone else). It's about 15-20% faster than the 32-bit version on my laptop.

[Bi11]

Here is a 64bit test version of eedi3_64 (http://bengal.missouri.edu/~kes25c/eedi3_64.dll) (I couldn't find a build by anyone else). It's about 15-20% faster than the 32-bit version on my laptop.
:thanks:
Any speed improvement to eedi3 is welcomed!

Is there any chance of being able to do assembly-level optimizations to improve performance similar to the speed improvement seen with nnedi3?
If not, can nnedi3 be trained to connect edges as aggressively as eedi3?

Now the remaining plugins I need to complete my 64-bit workflow are, an updated version of dfttest_x64, and dctfilter_x64 for deblock_qed. :)

[jpsdr]

I already changed the few assembly functions that could benefit from the extra xmm registers.
....
It's about 15-20% faster than the 32-bit version on my laptop.
Very interesting and very good !
Nice, thanks for this.

[akupenguin]

Is there any chance of being able to do assembly-level optimizations to improve performance similar to the speed improvement seen with nnedi3?
My version gains 6% speed from 64bit. This is almost entirely due to better scheduling of dotproducts. I have no code that needs more than 8 registers for a naive scheduling, but out of order execution isn't perfect.

[Blue_MiSfit]

I had a wonderful experience with NNEDI3 tonight for an unusual task: Upscaling a 12 megapixel image from my Canon s90 (RAW -> Lightroom -> 16bpc ProPhoto TIFF -> 8 bit sRGB PNG) to ~48 megapixels for professional printing on 20" x 30" paper.

A 64 bit toolchain was mandatory :)


imagesource("...\felix_source.png")
trim(1,1)

red=showred.converttoyuy2(matrix="pc.709")
green=showgreen.converttoyuy2(matrix="pc.709")
blue=showblue.converttoyuy2(matrix="pc.709")

red=red.nnedi3(field=-1,dh=true).turnright.nnedi3(field=-1,dh=true).turnleft
green=green.nnedi3(field=-1,dh=true).turnright.nnedi3(field=-1,dh=true).turnleft
blue=blue.nnedi3(field=-1,dh=true).turnright.nnedi3(field=-1,dh=true).turnleft

mergeRGB(red,green,blue)

spline64resize(7949,6000)


I used a solid 2.8GB of RAM for this script on a single frame. Processing time was under a minute, using PNG output from VirtualDub x64.

The result was very good! When stacked with an image scaled by Photoshop's bicubic filter, it was noticeably better, especially after I staked an instance of Photoshop's "Smart Sharpen" filter on each image.

MARVELOUS work, akupenguin and tritical et al!

Now, if I had support for 16 bpc through the whole pipeline, I'd be REALLY happy :devil:

[dansrfe]

Trying that out now^

EDIT: AvsP starts throwing errors when I press F5. CPU usage does shoot up to 100% for about 1 min though.

EDIT EDIT: for rfactor = 4, rfactor = 2 works very snappily on my c2d.

[jpsdr]

I'm wondering if there is not some kind of memory leak in nnedi3_rpow ? I've made an avisynth script with only AVISource and nnedi3_rpow, absolutely nothing else, and noticed during VDub process that memory usage was always increasing regularly. I've noticed this with x64 version, not tested yet with x86 version. Doesn't anybody else noticed it ?

[bcn_246]

tritical,
I have been using your plug-ins for some time, thought I should say thanks for all your hard work.

I tried your 64-bit build of NNEDI3 using "NNEDI3_rpow2(rfactor=2,cshift="Spline64Resize")" and found the speed improvement to be vast. Using JoshyD's 2.5.8 MT x64 build, an i7 @ 4.00GHz w/6GB RAM, processing the same video (Gorillaz - Feel Good Inc. @ 720p), I got ~3fps on x86 and ~8fps on x64. Probably the most significant x86->x64 increase I have seen.

I tried your first x64 build of EEDI3 but it threw up a "unable to load plugin..." error. I just re-downloaded the file from your post and see the timestamp is different, updated today (08/12/2010), so I will have a go with that build of EEDI3 x64 once my current processing job is done.

Ben

[bcn_246]

Tried the EEDI3 version you posted today. Still refusing to load with JoshyD's AviSynth v2.5.8 MT x64 build 4/16/2010.

http://img80.imageshack.us/img80/8394/64552070.th.jpg (http://img80.imageshack.us/i/64552070.jpg/)

- Ben

[tritical]

@bcn_246
I haven't posted any new versions since my last post - not sure why the timestamps are different. Probably you need the visual studio 2010 runtime (http://www.microsoft.com/downloads/en/details.aspx?familyid=BD512D9E-43C8-4655-81BF-9350143D5867&displaylang=en) for the openmp dependency.

@jpsdr
nnedi2_rpow is just a wrapper around nnedi3() that automates resizing. It constructs an avisynth filter chain consisting of nnedi3(), turnleft/turnright, final resize filter, etc... It doesn't allocate any memory directly so if memory is leaking it is either Avisynth or nnedi3(). It's difficult to tell for sure just looking at memory usage due to the way Avisynth's cache operates... after you open a script Avisynth doesn't immediately gobble up all the memory it plans to use. It gradually fills the cache as frames are requested until it hits its memory limit. If you let it run for a while does the memory usage stabilize? I will look into this.

@dansrfe
rfactor=3 in nnedi2_rpow2 should throw an error. Only powers of two are supported.

[bcn_246]

My (stupid) mistake with the timestamps. My download manager wasn't set to copy the file's date from the server, so re-downloading modified the creation date.

I installed Microsoft Visual C++ 2010 (x64), and updated .NET to v4.0 while I was at it, EEDI3 x64 is still refusing to load.

I am using Windows 7 Ultimate x64, up-to-date with MS. Here is a list of other plug-ins I have in my 'plugins64' folder. I am guessing that there is something that should be here (or in SysWOW64/System...) that EEDI3 depends on.


\Documentation
\Scripts
fieldhint.cpp
Utilities.cpp
AddGrainC.dll
autocrop.dll
aWarpSharp.dll
colormatrix.dll
defreq.dll
DeGrainMedian.dll
dfttest.dll
DirectshowSource.dll
EEDI2.dll
eedi3_64.dll
ffms2.dll
FFT3DFilter.dll
FFT3dGPU.dll
fftw3.dll
FieldHint.dll
FluxSmooth.dll
gradfun2db.dll
hqdn3d.dll
LeakKernelDeint.dll
libfftw3f-3.dll
MipSmooth.dll
motion.dll
MT.dll
mt_masktools-25-x64.dll
mvtools2.dll
nnedi3_64.dll
RemoveGrain.dll
Repair.dll
TDeinterlace.dll
TelecideHints.dll
TIVTC.dll
TNLMeans.dll
TTempSmooth.dll
UnDot.dll
VerticalCleaner.dll
yadifmod.dll
ffmsindex.exe
avisynth.h
info.h
internal.h
Utilities.h
fft3dgpu.hlsl
FieldHint.icproj
FieldHint.sln
FieldHint.vcproj

- Ben

[jpsdr]

@jpsdr
If you let it run for a while does the memory usage stabilize? I will look into this.

Yes, it's stabilize at around 500MB after a long time. This seems a little high considering the fact :
- It begins at around 150MB and constantly increase.
- I'm working in input with 720x480 pictures, asking for an increase size of 2 (so output at 1440x960) + Spline36Resize.
I've not waiting all the time, i've just noticed the continuous increase on the begining, and noticed that several hours laters, and so dozen of file processed laters, memory usage seems stabilized at around 500MB.

Edit : Video is YV12.

Note : You've provided the source code of last version, thanks, nice. You've also made an experimental 64bits version, but without the source code. Is it possible you made this one avaible ?

[IanB]

For a system with 2+GB of ram this is more or less what I would expect. The default SetMemoryMax is 25% physical memory capped to 512Mb. You can of course change this with a SetMemoryMax() statement at the start of your script.

[jpsdr]

I don't understand the slow growing use of memory. Once a filter has done all the memory allocations it needs, if there is no memory leak, i don't understand why memory should slowly go bigger and bigger and bigger.... I use some others avisynth scripts (always simple basic things), and memory used is always stabilised in the few seconds, it doesn't still growing half an hour after starting the process.
This is not the case, but i think if on a script like (YV12 video) :

AVISource("File.avi")
Spline36Resize(1280,720)

I would see a memory use of 500MB !!! I thought it could be a problem................
Wait... I remember now IanB.... I've got similar issue with something totaly different, and problem was linked to the fact that source is YV12 in 720x480, and so some resolution not mod16, and so created some cache default or i don't remember what, resulting in avisynth cache always increasing...
At the time i thought there was a problem with avisynht or Lagarith...
I must look out for the solution you provided me, and test it and check if there is still the memory increase.

[jpsdr]

It's not what i thought...
I've replaced

AVISource("File.avi")
nnedi3_rpow2(rfactor=2,cshift="Spline36Resize",fwidth=960,fheight=720,nsize=0,nns=3,qual=2)

by

AVISource("File.avi",False,"YV12")
SetPlanarLegacyAlignment(True)
nnedi3_rpow2(rfactor=2,cshift="Spline36Resize",fwidth=960,fheight=720,nsize=0,nns=3,qual=2)

but nothing changed, memory is still begining at around 150MB, and is slowly growing until reaching around 500MB.
So, it behaves like there is some kind of memory leak somewhere...

[Didée]

Did you read IanB's post? Start your script with the line "SetMemoryMax(16)", and see Avisynth using only very little memory.

Avisynth has an internal frame buffer. If not used elsehow by internal (temporal) filters, Avisynth will fill that frame cache with "past output frames". (For example, that means that if you're running a very slow/complex "1fps" script, you can very quickly step backwards lots of frames that already have been rendered.)

[jpsdr]

After some test with only Spline36Resize, it seems it's my mistake, behavior is the same.

[IanB]

There are some heuristics involved with the cache memory usage that tries to fight growth. This involves cache instances trying to recognise non-usage cases and marking VFB's involved as returned for early reuse. If the memory manager has a VFB of the right size marked as returned it will issue that one (limit mode) instead of checking the SetMemoryMax values and issuing a new one if current usage is less (growth mode) or issuing one from the LRU chain (plateau mode). The heuristic code errs on the side of safety and won't return VFB's unless it is pretty sure they will never be needed again.

If the growth is a problem use SetMemoryMax() to constrain it. Also the OS had to have memory free at script compile time to set the initial SetMemoryMax value, so that memory was not being used for anything else anyway.

[Gavino]

Interesting stuff, thanks for the details, Ian.
The heuristic code errs on the side of safety and won't return VFB's unless it is 100% sure they will never be needed again.
Can it ever be 100% sure, given that a plugin could request frames in some totally arbitrary order?

[IanB]

Well no it can never be 100% sure.

[Amateur]

new user here. i am wanting to give this eedi3 filter a try but it won't load in megui. i keep getting an error saying "there is no function named eedi3". i put the dll into the plugin folder of avisynth so i don't know what i'm missing.

a secondary question:
i'm wanting to use this filter for some anti-aliasing. am i choosing the proper filter for this purpose? here (http://img225.imageshack.us/img225/634/21384130.jpg) a the scene that i see it the most. i tried to use aaa() but that didn't seem to do much. here is the script that i am using that has given me the best results so far

LoadPlugin("C:\Program Files (x86)\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("E:\xv1e1\VTS_01_1.d2v", info=3)
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, threads=0)

undot()

AnimeIVTC(mode=1, aa=1, precision=3, edimode="nnedi3")

Deen("a2d",7,11,13,min=0.5)

crop( 8, 0, -6, -4)

LanczosResize(640,480)

trim(4000,6000)
**notes on the parameters - i found that line for animeivtc in another thread so i just used it for mine. reading the documentation for that was like looking at chinese for me. i took that deen line from scintilla...maybe that can be tweaked to make my picture look better. and i read that undot is risk free compressibility so i just add that to all of my scripts...not really sure what it does.

here is what the scene looks like at 600kbps (http://img530.imageshack.us/img530/8035/32416345.jpg) bitrate (might bump that up more if i can't get filters to help clean up the image)

i've been trying to read up on filters for the last week or more but a lot of comments are beyond me so i very well might be implementing these filters in the wrong way. would love any help possible. kind of blindly using scintilla's filter guide as a baseline for quite a while but that is somewhat limited now that i've been snooping around on doom9

here is a vob clip (http://www.megaupload.com/?d=CKKDAZ8M) of the opening scene if anyone cares to fool around with it. source is a North American DVD (ntsc?)

just in case the opening scene is different from the actual episode, here (http://www.megaupload.com/?d=F7672659) is a one minute vob clip following the opening scene.

[yup]

Amateur!
try:
http://forum.doom9.org/showthread.php?p=1423090#post1423090
If You want antialiasing use function inside AnimeIVTC (ediaa, daa, maa). I prefer daa with nnedi3, and try setting for nnedi3 for improving accuracy.
yup.

[Amateur]

alright i clicked on the link from the response to your link that is supposed to be the fix and was given a page that had three download options
vcredist_IA64.exe
vcredist_x64.exe
vcredist_x86.exe
i am running a 64 bit operating system so i chose the first two. i went to install the first one and am told my processor isn't compatible (phenom ii x4) so i installed the second one only. but i still get the error there is no function named eedi3. i even restarted my computer after running that vcredist_x64.exe and no change in error

and how do i anti-alias from within animeivtc? i tried finding it in the info of animeivtc but again, it's kind of like reading another language with that much info that i'm not familiar with. i changed aa=2 because the filter had
aaed = aa==0 ? dec :
\ aa==1 ? dec.ediaa() :
\ aa==2 ? dec.daa() :
\ aa==3 ? dec.maa() :


i'm so lost...

also, could deen be tweaked in any way for some improvement?

[yup]

Amateur!
I try only Avisynt 2.58 and SEt 2.6 both 32 bit. I know that for 64 bit tritical write separate version.
Try start from 32 bit.
For realize 64 bit need know a lot of tip trick.
yup.

[bcn_246]

alright i clicked on the link from the response to your link that is supposed to be the fix and was given a page that had three download options

i am running a 64 bit operating system so i chose the first two. i went to install the first one and am told my processor isn't compatible (phenom ii x4) so i installed the second one only. but i still get the error there is no function named eedi3. i even restarted my computer after running that vcredist_x64.exe and no change in error

and how do i anti-alias from within animeivtc? i tried finding it in the info of animeivtc but again, it's kind of like reading another language with that much info that i'm not familiar with. i changed aa=2 because the filter had



i'm so lost...

also, could deen be tweaked in any way for some improvement?

I mentioned this issue also. I am running Visual Studio 2010, and have all the packs that came with that installed, as well as up-to-date Windows 7 Ultimate.

I am going to try running it on a VM'd Windows XP x64 later and see if I have any luck.

I will also have a look for a x64 dependency scanner and see if it can pick up any (missing) required binary(s). The one I have is 32-bit only.

Ben

[Amateur]

so how do i set anti-alias using nnedi3 within animeivtc?

[yup]

Amateur
daa(Your clip)
#Anti-aliasing with contra-sharpening by Didйe
function daa(clip c) {
nn = c.nnedi3(field=-2)
dbl = mt_average(selecteven(nn),selectodd(nn),U=3,V=3)
dblD = mt_makediff(c,dbl,U=3,V=3)
shrpD = mt_makediff(dbl,dbl.removegrain((width(c)>1100) ? 20 : 11),U=3,V=3)
DD = shrpD.repair(dblD,13)
return dbl.mt_adddiff(DD,U=3,V=3) }

I am only replace nnedi2 to nnedi3.
yup.

[Mystery Keeper]

so how do i set anti-alias using nnedi3 within animeivtc?

Do not. Do NOT antialias with nnedi3.

[ajp_anton]

alright i clicked on the link from the response to your link that is supposed to be the fix and was given a page that had three download options
vcredist_IA64.exe
vcredist_x64.exe
vcredist_x86.exe
i am running a 64 bit operating system so i chose the first two. i went to install the first one and am told my processor isn't compatible (phenom ii x4) so i installed the second one only.
Not going to help your problem, but IA64 is Intel's Itanium architecture. You will probably never encounter these, ever.
x64 and x86 are what you think they are.

[Didée]

Do not. Do NOT antialias with nnedi3.
For what reason? Has nnedi3 become bad, all of a sudden?

[Amateur]

so in order to do this i would change my script to

LoadPlugin("C:\Program Files (x86)\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("E:\xv1e1\VTS_01_1.d2v", info=3)
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, threads=0)

undot()

AnimeIVTC(mode=1, aa=1, precision=3, edimode="nnedi3")

daa(VTS_01_1.d2v)

Deen("a2d",7,11,13,min=0.5)

crop( 8, 0, -6, -4)

LanczosResize(640,480)

trim(4000,6000)

and that will do it? not on the computer to test it out currently.

Not going to help your problem, but IA64 is Intel's Itanium architecture. You will probably never encounter these, ever.
x64 and x86 are what you think they are.

this explains why it wasn't working for me since i use an AMD so thank you for that info. but why isn't that filter working still? eedi3 still gives me the "no function named eedi3" error even though it's in the avisynth plugin folder with the rest of my filters.

[Mystery Keeper]

For what reason? Has nnedi3 become bad, all of a sudden?

For anitaliasing? It was always bad for antialiasing. It is deinterlacing plugin. Quite sharp! EEDI2 is the only EDI deinterlacer that is good for antialising, because it blurs the edges while connecting them. NNEDI1/2/3 are completely different. And Amateur was asking about anitalizing anime too. Why did I remove EEDI2 from SharpAAMC? Because SangNom worked twice as fast with same result and didn't have the shift problem. EDIs are not intended for antialiasing. The sharper the EDI - the worse it is for antialiasing.

[Didée]

Might be all well and true. (Though still arguable.)

However, you must consider the basic working principle of the various AA functions. In SharpAAMC (and predecessors a/o cognates), the EDI interpolator basically interpolates between adjacent original pixels. (And btw, SangNom IS an EDI interpolator, too.) But, the daa() script works different! It averages two independent interpolations, where each interpolation set works between odd-distanced pixels. This on its own provides sufficient amount of blurring. Enough blurring that the script uses a contra-sharpening step to counteract the blurring.

Hence, you shouldn't say that EEDI/NNEDI are generally bad for antialiasing. Perhaps they're not suited for *your* preferred AA method. But they are well suited for AA methods other than that.