TempLinearApproximate plugin

[Mystery Keeper]

Here's what seems to be stable release of TempLinearApproximate plugin rewrite for VapourSynth.
This plugin is meant for motion-compensated temporal denoising.

TempLinearApproximate r3 - Windows binaries.
Sources.

Usage:

tla.TempLinearApproximate(
	clip:clip
	radius:int:opt
	planes:int[]:opt:empty
	gamma:int:opt
	)

radius: (default 5) The size of neighborhood of the current frame. Approximation is made by (radius * 2 + 1) points, unless close to beginning or end - it is trimmed in these cases.

planes: The array of planes you want to process. If not specified - all planes are processed. Empty array is allowed for testing purposes.

gamma: Boolean. True by default. Indicates if luma values are converted from gamma corrected to linear light before processing and back after. Never applied to chroma planes. Setting this argument to False gives a speed up.

Motion compensated denoising script.
Usage example:

import sys
sys.path.append('E:\\vapoursynth-plugins\\py\\')
import MCDenoise as mcd

tlamcArguments = {
	'radius': 5,
	'search': 5,
	'pelsearch': 2,
	'subpelinterp': 2,
	'searchparam': 5,
	'truemotion': True,
	'chromamotion': True,
	'thsad': 600,
	'thscd1': 200,
	'thscd2': 150,
	'refine': True,
	'_lambda': 2000,
}

denoised = mcd.TempLinearApproximateMC(input=source, **tlamcArguments)

Note the "refine" argument. It makes the function ignore the "blocksize" and "overlap" parameters, start motion estimation with blocksize=32 and overlap=16 and gradually refine down to blocksize=4 and overlap=2. Very accurate, but very slow.

CHANGELOG:

r3: Support for single precision float input.
Processing in linear light. On by default.
Motion compensated script modified into standalone function. "gamma" argument added.

r2:
Fallback to averaging when current frame is the middle in the range (it is not the middle only when close to the beginning or the end). Speedup.
License change to MIT.
Fallback to C90. Compilable with MSVC.

Originally Posted by Mystery Keeper

As there are no motion compensation means in VapourSynth at the moment, it uses AviSynth MVTools2 plugin and thus is only usable in x32 VapourSynth.

You are just using MAnalyse, MSuper and MCompensate right now, correct? I noticed that making an MVTools replacement was on the list of Vapoursynth issues. If no one else has started I can try to whip up a quick port of those functions. Now, I haven't yet looked at the code so it could be far less "quick", though, as it's likely my eyes will begin bleeding reading the source...

[Mystery Keeper]

Originally Posted by handaimaoh

You are just using MVAnalyse, MVSuper and MVCompensate right now, correct? I noticed that making an MVTools replacement was on the list of Vapoursynth issues. If no one else has started I can try to whip up a quick port of those functions. Now, I haven't yet looked at the code so it could be far less "quick", though, as it's likely my eyes will begin bleeding reading the source...

Community will worship you if you do. Though I think it would be better if Myrsloik ported it personally. MVTools relies on AviSynth specifics, and VapourSynth port could make use of VapourSynth capabilities. Like frame properties. I hope he'll at least supervise it if you undertake the port.

Originally Posted by Mystery Keeper

Community will worship you if you do. Though I think it would be better if Myrsloik ported it personally. MVTools relies on AviSynth specifics, and VapourSynth port could make use of VapourSynth capabilities. Like frame properties. I hope he'll at least supervise it if you undertake the port.

I'll see what I can do. Having just started looking at the code I can see this will be interesting...

Also looking at the code, what "Avisynth specifics" are you referring to? I'm not seeing what you are talking about. It's mostly using a bunch of its own internal functions. The most I'm seeing it use of the Avisynth API is the getReadPtr/getWritePtr, getPitch, etc. functions.

[Mystery Keeper]

Originally Posted by handaimaoh

Also looking at the code, what "Avisynth specifics" are you referring to? I'm not seeing what you are talking about. It's mostly using a bunch of its own internal functions. The most I'm seeing it use of the Avisynth API is the getReadPtr/getWritePtr, getPitch, etc. functions.

Some data is stored in audio stream or something like that. I'm not sure.

Originally Posted by Mystery Keeper

Some data is stored in audio stream or something like that. I'm not sure.

Ok, I see that in the documentation. It uses the "num_audio_samples" as a field to push data through. Just requires using the propSet* functions to do the same thing. So we would just need to decide on what to call the frame properties that are needed to be pushed out. It's quite simple.

[Myrsloik]

Originally Posted by Mystery Keeper

Some data is stored in audio stream or something like that. I'm not sure.

A few words on "porting" MVTools and motion estimation in general.

I won't.

When I get to it (sometime early next year I guess), I will start writing something new. It will be inspired by mvtools and the goal is to have equivalent useful functions.

The only vapoursynth features mvtools would benefit from is the possibility to attach data to frames, that would remove the insanity of passing a data pointer in an int for the audio properties. That and the general parallelism.

Don't expect wonders from running it in parallel though, it already breaks things down into many small and fairly balanced steps as separate functions so even the avisynth version scales in an acceptable way.

Feel free to shitport the existing lump of mvtools code but I won't waste my time doing that.

Now I let you go on with the thread's actual topic....

Originally Posted by Myrsloik

Feel free to shitport the existing lump of mvtools code but I won't waste my time doing that.

Well if you're going to make something different to replace it I won't bother. My eyes have had enough bleeding for one day reading its code even for 10 minutes or so. I'll just continue working on other stuff instead.

I'll bow out for now too.

[Mystery Keeper]

Originally Posted by Myrsloik

When I get to it (sometime early next year I guess), I will start writing something new. It will be inspired by mvtools and the goal is to have equivalent useful functions.

That's exactly why I said it is better be done by you =)

[mastrboy]

Originally Posted by Myrsloik

Feel free to shitport the existing lump of mvtools code but I won't waste my time doing that.

Even if the code is a lump of unreadable/messy code from a programming perspective, for video encoding isn't it the result that matter? and not how that result is achieved?

I've yet to find a better temporal denoiser/degrainer which can produce the exact result I'm looking for combined with masktools2 for any source yet. (Of course not at default settings...)

Originally Posted by mastrboy

Even if the code is a lump of unreadable/messy code from a programming perspective, for video encoding isn't it the result that matter? and not how that result is achieved?

I've yet to find a better temporal denoiser/degrainer which can produce the exact result I'm looking for combined with masktools2 for any source yet. (Of course not at default settings...)

Sure, if you don't care about the fact that no one else can pick up development on it if the original author stops.

[Mystery Keeper]

Originally Posted by mastrboy

Even if the code is a lump of unreadable/messy code from a programming perspective, for video encoding isn't it the result that matter? and not how that result is achieved?

I've yet to find a better temporal denoiser/degrainer which can produce the exact result I'm looking for combined with masktools2 for any source yet. (Of course not at default settings...)

AviSynth is in such a poor state because its authors have sacrificed maintainability to speed. There were no options at the time. No intrinsics and multicore CPUs. Now we don't need to do such thing and can keep the code neat and maintainable.

Also, motion compensated denoising is great, but no way universal. When two moving scenes get blended (and that happens a lot in movies and even more in music video) - you can expect motion compensation to create all kinds of distortion.

Originally Posted by Mystery Keeper

AviSynth is in such a poor state because its authors have sacrificed maintainability to speed. There were no options at the time. No intrinsics and multicore CPUs. Now we don't need to do such thing and can keep the code neat and maintainable.

Compiler intrinsics for MSVC have been around since at least Visual Studio 2003. Now there have been numerous code generation bugs over the years, but Avisynth's lack of their usage is not because they are something recent. Lack of their usage is likely because the core devs never moved passed Visual Studio 6 and what you said about both the core devs and plugin writers sacrificing any maintainability for writing the most "optimized" code. Even x264's ASM is far easier to follow than the inline asm macro mess that makes up the vast majority of asm in Avisynth plugins.

[Mystery Keeper]

Question!
Since my filter calculates linear approximation, should I use gamma correction? Should I make it default? Should I only apply it to Y-plane? Or make an option to specify the planes?

[Mystery Keeper]

r2 is out with speedup, license change and source compilable with MSVC.

[mawen1250]

It seems the 64bit binary is an old one?

[Mystery Keeper]

Originally Posted by mawen1250

It seems the 64bit binary is an old one?

Oops. You're right. Fixed.

[Mystery Keeper]

r3 is out with processing in linear light, single precision float input support and MC script changed into standalone function.

[TurboPascal7]

http://pastebin.com/1KqGiCQR
I didn't actually run this but it should probably work. Just made your python less bad.