Log in

View Full Version : TfNLMeans - an AviSynth 2.6 fork of TNLMeans 1.0.3


martin53
21st February 2015, 16:20
Anybody (besides me) interested in an AviSynth 2.6 update of the TNLMeans plugin?
here (http://www.mediafire.com/download/z3f7w4mkin8mh8y/TfNLMeans_1.05_151114.zip) is v1.05.
It is a fork of TNLMeans 1.0.3, which was the most recent version I found.

Changes
+ Compiled for AviSynth 2.6
+ supports YV16, YV24, YV411, Y8 (plus previous YV12, YUY2)
+ integer param. planes added to allow faster luma-only processing
- internal bitblt() function removed, replaced by AviSynth bitblt() calls (I judge these are best optimized)
+ float TfNLMeans_VersionNumber() function added, so future extensions can increment and scripts can check it
+ simple test suite included
+ ... more, see doc

Caveats
I am a beginner regarding VS project and compiler configurations, linkage and other AviSynth options, SSE optimizations and many, many other topics. Please do not expect it is bug free.

Reel.Deel
21st February 2015, 18:10
Thanks martin53, will test it out and report back if I find anything unusual.

I always liked TNLMeans, the only downside is the speed. Hopefully Groucho2004 can give us an ICL10 build (http://forum.doom9.org/showthread.php?t=168090).

So does the f in TfNLmeans stand for fork? Just curious :).

martin53
21st February 2015, 18:22
So does the f in TfNLmeans stand for fork? Just curious :).
Yep - I just lacked fantasy in that moment.

Groucho2004
21st February 2015, 19:45
Hopefully Groucho2004 can give us an ICL10 build (http://forum.doom9.org/showthread.php?t=168090).
ICL10 build can be found here (https://www.dropbox.com/s/lvdwvfo6at94cpg/TfNLMeans.7z?dl=0).

Quick speed test:

Script:
SetMTMode(2)
colorbars(width = 1280, height = 720, pixel_type = "yv12").killaudio().assumefps(24000, 1001)
trim(0,499)
fadeio(248)
trim(0,499)
tnlmeans() #tfnlmeans()

Tritical's 1.0.3 DLL: 2.464 fps
Tritical's 1.0.3 (ICL10): 4.764 fps
Martin53's tfnlmeans: 3.583 fps
tfnlmeans (ICL10): 4.645 fps

martin53
28th February 2015, 18:59
Please note that, with the update, I removed internal BitBlt code from the plugin, and in order to call AviSynth's BitBlt, AviSynth's environment pointer is stored in a class variable (for the sake of small changes, because the given calls did not forward it as a parameter).
I just learned that this can make MT environments (AviSynth MT, AviSynth+, VaporSynth) crash (http://forum.doom9.org/showthread.php?p=1649886#post1649886), and will provide an update to meet MT requirements.

EDIT: correct IScriptEnvironment pointer forwarding is done, but TNLMeans contained extensive caching and uses forbidden read/write class variables. Pffh...

AVIL
7th November 2015, 12:24
@Groucho2004

I'm interested in testing the ICL 10 version set in post #4 but the dropbox link gives a 404 page. Could you re-upload it?. Thanks in advance.

Groucho2004
7th November 2015, 15:39
@Groucho2004

I'm interested in testing the ICL 10 version set in post #4 but the dropbox link gives a 404 page. Could you re-upload it?. Thanks in advance.
You can find them (TNLMeans_ICL & TfNLMeans_ICL) here (https://www.sendspace.com/folder/10dsem).

AVIL
7th November 2015, 19:33
Many Thanks!!

martin53
10th November 2015, 20:00
Will post an update soon. I have nearly no spare time to work on this, but an update is almost ready for months and i decided to complete the last 5%.
The update will, in contrast to the published version, be fully MT friendly in almost all modes - only Bx|By>1 is not supported. Last bug I need to fix is Y8 format.

Mounir
10th November 2015, 23:25
i can't wait for this mt friendly release

martin53
14th November 2015, 18:04
I added a mask option to the filter, so the pixels to be processed can be restricted for speed improvement.
Please comment if the filter mask should just output the filtered pixel if the mask pixel value is > 0, or if the output should be a merge between the input and filtered value for mask values 1...254?

The merge option needs one more check even if the mask is binary. An additional mt_binarize() or Levels() filter is needed for hard switching behaviour.

Without the internal blend option, an additional merge() is needed if soft borders between filtered and unfiltered pixels are desired.

In my personal opinion soft blending (need for binarized mask if desired) is better.

martin53
15th November 2015, 10:44
i can't wait for this mt friendly release

See 1st post v1.05

AVIL
15th November 2015, 12:03
IMHO is better that the filtered output will be blended with the input proportionally at the corresponding value in the mask.

Zero value in the mask means, copy input to output (and do not process input), 255 value means output filtered value and, in the rest of values, output a proportional blend of input-filtered.

Then, if I want hard switching, I would prepare a mask with only 0 and 255 values.

AVIL
15th November 2015, 12:50
Your new version binaries do not load in my system (I lack of any libraries it said). ICL 10 version of former plugin by Groucho2004 loads fine. I understand they are no linked the same (the size isn't the same either).

martin53
15th November 2015, 17:11
Your new version binaries do not load in my system (I lack of any libraries it said). ICL 10 version of former plugin by Groucho2004 loads fine. I understand they are no linked the same (the size isn't the same either).

This is compiled with Visual Studio 2015, Groucho2004 compiled with the 2007 Intel compiler.

Since you probably have not yet installed another SW built with this Visual Studio version, you may need a Microsoft library:

Usually, Microsoft compiled SW requires that users install a runtime library. Registered SW publishers can include it in their installers, but else MS wants that it is not republished but downloaded directly from their servers (https://www.microsoft.com/en-us/download/details.aspx?id=48145).

StainlessS
15th November 2015, 18:03
M53, you could compile static linked, as /MT (multi-threaded) rather than /MD (multi-threaded dll) and avoid having to have the runtimes.
I have not even seen another plug that uses VS2015 runtimes, yet.

/MT in "Configuration Properties/C/C++/Code Generation/Runtime Library"

Groucho2004
15th November 2015, 19:13
M53, you could compile static linked, as /MT (multi-threaded) rather than /MD (multi-threaded dll) and avoid having to have the runtimes.
I would not recommend that for DLLs built with VS versions > 7.1. See here (http://forum.doom9.org/showthread.php?p=1736111#post1736111).
There is an excellent all-in-one runtime installer (http://www.wincert.net/forum/topic/9790-aio-microsoft-visual-bcfj-redistributable-x86x64/).

StainlessS
15th November 2015, 20:35
Thanx Grouchy, I musta missed that thread somehow.

MysteryX
15th November 2015, 21:05
I would not recommend that for DLLs built with VS versions > 7.1. See here (http://forum.doom9.org/showthread.php?p=1736111#post1736111).
There is an excellent all-in-one runtime installer (http://www.wincert.net/forum/topic/9790-aio-microsoft-visual-bcfj-redistributable-x86x64/).
mmm I didn't know that. With AviSynthShader, I wanted to avoid linking to Visual Studio 2015 runtime, which most people don't have.

It's working... and I'm not clear about the downsides. Are there serious concerns that should make me change it?

AVIL
15th November 2015, 21:46
Hi,

I've installed VS 2015 runtime and the plugin don't load. Same message "Module not found. ¿Install missing library?. Rebooting the PC don't resolve the problem.

Groucho2004
15th November 2015, 22:05
mmm I didn't know that. With AviSynthShader, I wanted to avoid linking to Visual Studio 2015 runtime, which most people don't have.

It's working... and I'm not clear about the downsides. Are there serious concerns that should make me change it?
Certain exceptions may not be caught and all you get is a nasty crash with little chance figuring out the reason by wading through a crash dump. Here's a selection of those exceptions:
STATUS_ACCESS_VIOLATION
STATUS_ARRAY_BOUNDS_EXCEEDED
STATUS_BREAKPOINT
STATUS_DATATYPE_MISALIGNMENT
STATUS_FLOAT_DENORMAL_OPERAND
STATUS_FLOAT_DIVIDE_BY_ZERO
STATUS_FLOAT_INEXACT_RESULT
STATUS_FLOAT_INVALID_OPERATION
STATUS_FLOAT_OVERFLOW
STATUS_FLOAT_STACK_CHECK
STATUS_FLOAT_UNDERFLOW
STATUS_GUARD_PAGE_VIOLATION
STATUS_ILLEGAL_INSTRUCTION
STATUS_INTEGER_DIVIDE_BY_ZERO
STATUS_INTEGER_OVERFLOW
STATUS_INVALID_DISPOSITION
STATUS_INVALID_HANDLE
STATUS_IN_PAGE_ERROR
STATUS_NONCONTINUABLE_EXCEPTION
STATUS_NO_MEMORY
STATUS_PRIVILEGED_INSTRUCTION
STATUS_SINGLE_STEP
STATUS_STACK_OVERFLOW


As always, it's a good idea to read the compiler documentation before using it.

AVIL
15th November 2015, 22:47
Sorry. I've downloaded x64 runtime. With the x86 runtime the plugins works.

martin53
16th November 2015, 16:05
Sorry. I've downloaded x64 runtime. With the x86 runtime the plugins works.

Glad to read that - and it's horribly slow ...? At least that's what it is on my system.

I think I kept most if not all speedup mechanisms in the fork.
But with the settings I suppose as neccessary (Ax=Ay=6, Sy=Sy=5, a=2.5, h=1.5) the filter has to calculate 13² x 11² (20449) multiplications with values from two matrices per pixel and plane, that is 8.5 billion multiplications for a 720x576 luma plane alone. With Az=0 and no mask, this is reduced to 4.25 billion multiplications. But how many of these can a processor with ~3 billion clock cycles/sec calculate per second ...

AVIL
16th November 2015, 22:01
Hi Martin53,

Tanks for your work. I want retouch spatially the dirt left by motion compensated filters. In a rough approximation that can be an area equivalent to 1/100th of the whole frame. Then I expect a speed 100 times superior to the old method. 11 fps, perhaps.

real.finder
5th February 2022, 18:43
the link is down

and how this performed in comparison with https://github.com/pinterf/TNLMeans ? seems pinterf TNLMeans didn't add TfNLMeans optimizations

edit: I think this project has been replaced by https://forum.doom9.org/showthread.php?t=172966