TempLinearApproximate. Filter for temporal linear approximation between pixels.

[Mystery Keeper]

Takes several frames and for each pixel calculates linear approximation of its values through time, then returns its value in the middle (unless close to beginning or end of clip) of that line. Meant mainly for denoising aid in motion compensated clips. If you use it on plain video - you'll just get heavy ghosting.

Only works on planar formats.

[USAGE]
TempLinearApproximate(clip, int radius=5, int plane=7, bool inLsb=false, bool outLsb=false)

radius: 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.

plane: The sum of three flags of planes to process. 1=Y, 2=U, 4=V.

inLsb: Set to true if input clip is in stacked 16 bit format.

outLsb: Set to true if you want output to be in stacked 16 bit format, whether input clip is stacked 16 bit or not.

Download TempLinearApproximate r6 (http://www.mediafire.com/?au8t2k8mbkzb4c6)
Get the source code from Bitbucket repository. (https://bitbucket.org/mystery_keeper/templinearapproximate)

[CHANGELOG]
r6: Full AviSynth 2.6 support.

r5: Added support for stacked 16 bit format.

r4: Fixed clamping issue changing white to black and black to white.

r3: Optimization.

r2: Fixed handling the frames pitch.

r1: Initial release.

[wOxxOm]

There is a similar filter, TemporalSoften (http://avisynth.org/mediawiki/TemporalSoften), so what are the advantages of TempLinearApproximate and in which cases will it do a better job?

[Mystery Keeper]

There is a similar filter, TemporalSoften (http://avisynth.org/mediawiki/TemporalSoften), so what are the advantages of TempLinearApproximate and in which cases will it do a better job?

Similar, but far from same. I can not say anything about advantages yet. Right now it is just a test thing. The idea behind it is assumption that in noiseless unmoving source colour of pixel either stays the same or changes smoothly. Both cases give you a straight line on the temporal scale. Another idea is that noise oscillates around that line. What this filter does is finding that line in the oscillating noise and aligning pixel colour to the line.

As I said, it will do a good job in well motion compensated clip.

[IanB]

Pitch is a unique property of each PVideoFrame, your code uses the pitch of your output frame for everything and of course it does not work when the input frames do not have the same pitch value.

Use this as a pitch processing torture test for any plugins you develop.....
A=SelectEvery(3, 0).AddBorders(0,0, 16,0).Crop(0,0, -16,0)
B=SelectEvery(3, 1).AddBorders(0,0, 32,0).Crop(0,0, -32,0)
C=SelectEvery(3, 2).AddBorders(0,0, 64,0).Crop(0,0, -64,0)
Interleave(A, B, C)
....

[Mystery Keeper]

IanB, thank you. Am I safe with planes width and height?

[Mystery Keeper]

Fixed it. Works with IanB torture test too. Updated the post.

[IanB]

Am I safe with planes width and height?Width and Height are both properties of the PClip.

Hint:- You have structured your code with lots of work in the inner most loop. With some devious restructuring you might achieve a ten fold speed improvement. E.g. the if null test could be moved out entirely. The GetReadPtr and GetPitch values are constant for a given PVideoFrame, copy them out once to a local array. The index calculation H*pitch+W can be avoided by techniques like bumping the readptr's by their pitch's each time in the outer most loop. When using STL components always check in detail what you inherit under the covers, some are very good and expand to code equivalent to for(int i=0;i<K;i++), others are evil and resolve to a rats maze of deeply nested method calls.

[Mystery Keeper]

Thank you for suggestions, IanB. Done. New somewhat faster version.

[Terka]

im not able to load the dll.

[Mystery Keeper]

im not able to load the dll.
How are you trying to load it, and what result do you get?
I scanned it with Dependency Walker, and it says you may need MSVCR110.dll and MSVCP110.dll - the MS Visual C Runtime.

[Reel.Deel]

I also couldn't load the plugin. When I tried, I got this error:
LoadPlugin: unable to load "TempLinearApproximate.dll", error=0x7e
I compiled it myself with MSVC 2010 (XP SP3), and now it works just fine. Perhaps a similar issue as this (http://forum.doom9.org/showthread.php?p=1603648#post1603648)?

[Mystery Keeper]

I also couldn't load the plugin. When I tried, I got this error:
LoadPlugin: unable to load "TempLinearApproximate.dll", error=0x7e
I compiled it myself with MSVC 2010 (XP SP3), and now it works just fine. Perhaps a similar issue as this (http://forum.doom9.org/showthread.php?p=1603648#post1603648)?

Programs built with VS2012 don't work with XP? Never knew it. I'm on Windows 8, and yes, I built it with VS2012. Could you please upload your build so I could link it in here? mediafire.com preferably.

[Rumbah]

The first VS2012 update adds WinXP support.

[Mystery Keeper]

Tested my filter against TemporalSoften and TTempSmooth on BlankClip().AddGrain() with fixed seed for fair test. TemporalSoften just sucks. And judging by the resulting file size TempLinearApproximate did 8% better than TTempSmooth. For TTempSmooth I used the settings from MCTemporalDenoise function. On other hand, my filter gave some bright dots on the frames close to the beginning and the end. Quite possible with the pure noise oscillating between 0 and 255, but should never happen on real source.

Here goes proof. (http://www.mediafire.com/?mibcz7mffxcqqah)

[LoRd_MuldeR]

The first VS2012 update adds WinXP support.

But you still need a special option: The "Platform Toolset" needs to be set to "v110_xp" explicitly. It's that option that was added with Update-1.

[Robert Martens]

On other hand, my filter gave some bright dots on the frames close to the beginning and the end. Quite possible with the pure noise oscillating between 0 and 255, but should never happen on real source.

I hate to be the bearer of bad news, but I've got a clip here that shows some spotting: http://www.mediafire.com/?8yfw392di0e31mc

I'm loading the file in single threaded Avisynth 2.6 (Alpha 4) with AVISource, through Cedocida 0.2.2 at its default settings, and calling TempLinearApproximate with no arguments. Some small sections of the clip that are black, or close to it, turn white, and vice versa. You can accentuate the effect by first loading the clip as RGB, then doing the planar conversion manually with PC levels before calling TLA:

AVISource("TLAspots.avi", pixel_type="RGB32").ConvertToYV12(matrix="PC.601")

Setting radius to 1 eliminates the problem. I also notice that the last two frames show a dark ghost of the pickup truck, offset to the right, that becomes more pronounced with larger radii. I decided to try TempLinearApproximate out of curiosity, but I don't do much video processing with filters like these, so I don't know if that's a symptom of the problem or if it's a reasonable thing to expect.

If you need something longer to work on, the test clip is the first ten frames of this one (http://gyroshot.com/files/simpleslug/testclip.zip), but that small snippet shows the black<->white issue fairly well.

[Mystery Keeper]

Robert, when I first read your post, I thought: "I bet he just used the filter as is right after loading video." Please read the description in the first post more carefully. You should only use this filter on motion compensated clip. Otherwise, ghosts are to be expected. Still, I tried your video, was surprised, but the black<->white issue does present and looks like glitch. Thank you. I'll look into it. My first guess is me forgetting to clamp linear function to [0, 255].

[Robert Martens]

I did see that you mentioned a "likely undesired motion blur effect", but I thought that was in reference to the obvious blur seen over the entire image when the filter's applied to a clip that hasn't been prepared correctly; when I use the word "ghost" I'm referring in particular to the dark, negative image of the bright white truck seen only in the last few frames. If that's to be expected when this filter's applied incorrectly, my mistake, sorry I jumped the gun there.

[Mystery Keeper]

Was right. Clamping issue. Fixed. New version. Please test if it works with XP now.

[Mystery Keeper]

I did see that you mentioned a "likely undesired motion blur effect", but I thought that was in reference to the obvious blur seen over the entire image when the filter's applied to a clip that hasn't been prepared correctly; when I use the word "ghost" I'm referring in particular to the dark, negative image of the bright white truck seen only in the last few frames. If that's to be expected when this filter's applied incorrectly, my mistake, sorry I jumped the gun there.

You see, the last frames have white track that moves out of these spots. My filter sees that as pixels with fading out white. It constructs a line with negative gain and takes its value near the end. That's what gives you the black ghost.

[Didée]

TemporalSoften just sucks.

TemporalSoften(5,0,0,100,2)

Is this a joke?

[TheProfileth]

If possible linear processing would be a lot more accurate with something like 16bit over 8 bit simply due to better in between values.
Obviously the processing is vastly more however I think that this would help it to outpace many competitors especially temporalsoften.

[Mystery Keeper]

TheProfileth, this filter uses double precision, which is 64bit floating point.

Didée, my bad. Misinterpreted the thresholds. You could also point that out instead of saying something like "Is that a joke". I'm getting strong impression you're bashing on me.

[Mystery Keeper]

Redone the test with much heavier noise and corrected TemporalSoften settings. Apologies, TemporalSoften doesn't suck. Actually, it outdone TTempSmooth. TTempSmooth leaves noticeably more noise. Compression-wise the score is this:
1) TempLinearApproximate
2) TemporalSoften
3) TTempSmooth
With very little file size difference though.

New test (http://www.mediafire.com/?fukbp6u7qkyfqmp)

[Didée]

No, I'm too much in a hurry to have any time for bashing. :)

But seriously, shouldn't you've become suspicious when seeing that temporalsoften does exactly nothing in your test?

I think you should. But no, instead you blindly jump to conclusions: "it sucks".

[Reel.Deel]

Please test if it works with XP now.

R4 still does not load. For the meantime, here's (http://www.mediafire.com/?t2f3aw9hhwzhnh2) r4 built with MSVC 2010.

[Mystery Keeper]

Thank you, Reel.Deel. Pity it is not working even after built with XP toolchain =(

[Terka]

im on XP.
still not able load the plugin.

I have msvcr110.dll, msvcp110.dll in c:\WINDOWS\system32\ directory
LoadPlugin("c:\Program Files\AviSynth\plugins\TempLinearApproximate.dll")
gives
LoadPlugin: unable to load "c:\Program Files\AviSynth\plugins\TempLinearApproximate.dll"

[TheProfileth]

TheProfileth, this filter uses double precision, which is 64bit floating point.
Well I assumed you were at least using higher precision than 8 bit for your calculations, however my point was not of your internal processing but of the output, IE could you have it output in stacked 16 bit preserving more of the accuracy that is acquired my using 64 bit. Stacked 16 bit would be a wonderful contribution to this. Also if I may ask why did you choose to use 64 bit floating point over 32 bit floating point? Was there a significant quality increase over the speed that was lost?

[Mystery Keeper]

Regarding the precision question - filter is dealing with squares and divisions, so double precision might be necessary. It is also surprisingly fast on any sensible radius. I assume its slowest part is not the calculation, but requesting multiple frames. I honestly don't know if that is even safe and wouldn't break your script if cache size is insufficient. But alternative is requesting each needed frame for every pixel. You can guess how fast is that.

As for stacked 16 bit - sure, I can easily extend my plugin to work with it. If someone explains to me in one place how it is structured, how to deal with it both in plugin and in script, and gives me a complete script example working with 16bit clip. The info I've seen so far is scattered. I had no practice with 16 bit yet.

[Mystery Keeper]

Am I getting it right that stacked 16 bit is double height frame with lower byte placed on the lower half? Is maximum intensity 0xFF00 instead of 0xFFFF?

[Mystery Keeper]

Added stacked 16 bit support. Don't really know if it is working right. My understanding of that format is incomplete.
Built with MSVS 2008 Express. Should work with any Windows without any runtimes.

[Reel.Deel]

I'm not really sure on this but r5 is still compiled with an avisynth 2.5 api 2 header.
If you want the extra planar color spaces, maybe try updating your filter to use a 2.6 header or do something like AddGrainC 1.7.0 (http://forum.doom9.org/showthread.php?p=1587215#post1587215) which uses an updated 2.5 header to support the extra color spaces.

Also r5 compiled with MSVC 2010 (http://www.mediafire.com/?l6mjbvkqvmth1ce) on a 1080p video with default settings is about 5fps faster (at least on my computer). Size of dll is also 3 times smaller. :)

One last thing, how about changing inLsb and outLsb to lsb_in and lsb_out similar to Dither. Easier to remember. :p

[Mystery Keeper]

The size is smaller due to additional dependency on the runtimes. Faster? Maybe. I'll put your link into first post too. I've only got VS2008 and VS2012.
I remember switching to the older header because I got compilation errors. I shall look into that again.

[Mystery Keeper]

New version. No functional change, only AviSynth 2.6 support. Works correctly on YV16 and YV24 now.

[Mystery Keeper]

Got VS2010 toolchain and made new build. Shall build with 2010 from now on.

[Mystery Keeper]

Created Bitbucket repository for the source. Can be used as git repository or to download sources in archive.