General convolution filter

[Richard Berg]

I know you've all been waiting on the edge of your seats (;)), but it's finally here.


Demo
avisource("l:\bebop.avi")
# 5x5 gaussian
generalconvolution(0, "0 1 2 4 0
1 4 8 4 1
2 8 16 8 2
1 4 8 4 1
0 4 2 1 0")
# 3x3 sharpen
generalconvolution(0, "-1 -1 -1
-1 9 -1
-1 -1 -1")


The first argument is an additive bias. It'll be optional (defaulting to 0) as soon as I can get Avisynth to not crash when I do so...

It's no speed demon, but not terribly shabby either. 512x384 HuffYUV video -> XviD via a 5x5 kernel goes at about 11fps on a 1.4Ghz Pally. (L:\ is a network share to the HTPC capture drive, but I don't think bandwidth was the limiting factor since it was compressed on the return route.) That's without any optimizations at all, though I'm not too confident there's much to be gained from MMX/SSE etc. since the algorithm really thrashes the L1 cache. Source code is in the ZIP, though, so Trbarry et al. are welcome to prove me wrong :)

Speaking of the code -- if you haven't noticed, it's in a .h/.cpp file of its own. In general all you have to do is add GeneralConvolution_filters in 2 places at the very beginning of avisynth.cpp, but this filter also required some hacking of script.cpp to allow newlines within single commands. Not to worry; the binary is posted, and I hope to get at least the major code-revision issues banged out ASAP...keep up with the "leadership" thread for the latest, I suppose...

[trbarry]

That's without any optimizations at all, though I'm not too confident there's much to be gained from MMX/SSE etc. since the algorithm really thrashes the L1 cache. Source code is in the ZIP, though, so Trbarry et al. are welcome to prove me wrong

Richard -

Haven't looked at your source but generally EVERYTHING is faster in assembler, it just depends on whether it's worth complicating the program for it. ;) But the following is part of a comment I left when doing the SSEMMX optimization for Nic's deringing filter:


Note - As near as I can see, (a + 2*b + c)/4 = avg( avg(a,c), b) and likewise vertical. So since there is a nice pavgb MMX instruction that gives a rounded vector average we may as well use it.

In that case the array was:

1 2 1
2 4 2
1 2 1

but if similar principles could apply to your case then it could be applied to 8 (16 for SSE2) bytes with only a few assembler instructions. My own theory on assembler programming is to usually not try to write the general case but just cherry pick the cases where I get bang for the buck.

You're right about the cache issues placing a floor under the speed but repeated hits to the same (very) few strings of memory don't seem to cause too much of a problem.

But again, I am an obvious and self-confessed assembler bigot. ;)

- Tom

[Dali Lama]

Hi

Maybe it says in the readme but what is a General Convolution Filter anyways? What does it do and how does it work. Thanks. Oh and please try to explain it in semi-lamens terms.

Dali

[Richard Berg]

It basically lets you apply an arbitrary linear function to a pixel, using surrounding pixels as variables. I'm sure Google has more info than I do.

Tom: obviously for any given kernel there's a way to optimize it better than the general case. That defeats the purpose of this filter, but if by using it we discover a cool config or two then we could make them into separate (optimized) filters.

[Acaila]

@Dali Lama:
Someone gave a very good explanation of that a while ago. Read this (http://forum.doom9.org/showthread.php?s=&threadid=25908&highlight=general+convolution).

@Richard Berg:
There are already a few general convolution filters already out there for VDub. Is your version just a port from one of those from VDub to Avisynth, or is it completely different?

[Richard Berg]

The math is the same as in Gunnar Thalin's plugin (see comments in the source), but support for the temporal axis was stripped since you can do that with the new Layer filters.

[Richard Berg]

Fixed a few bugs last night:
-the binary I built used the debug config. oops...though I guess that means it'll be faster than my previous measurements would indicate
-logic to detect input type was incorrect, would overstep its buffer if not fed RGBA
-alpha channel was set to null; it's now preserved from the original clip. let me know if you want additional options for handling this (eg setting to 255 or heck actually convolving it too)
-minor code cleanup

The latest version was included in the tree I posted to the "core" thread. Yes, I'll build a binary soon, but I'd still like feedback from folks with compilers so I can figure out why it won't build on some people's machines.

Edit: binary can be found in the "layer" thread