Archive: Blur convolution equivalents


28th April 2003 17:10 UTC

Blur convolution equivalents
Here are the convolution matrices that correspond to the standard blur modes. The standard blur is actually pretty bad, with tons of roundoff errors causing a soft fadeout (which convo doesn't have afaik).

Each kernel is followed by a simplified, non-fading, faster version. The simplified version is done by rounding each value up to the nearest power of two and dividing until no common divisors exist.

You can find these by putting a single white dotscope followed by a blur (with 'clear every frame' on of course) and taking a screenshot. AVS itself probably uses a combination of bitshifts and additions (so it does use powers of two), but because it bitshifts before adding, precision is lost and the image fades.

The 3x3 matrix is of course centered in convo-ape's 7x7, with zeroes in the other positions.

Light:


0 15 0 0 1 0
15 187 15 -> 1 12 1
0 15 0 0 1 0
div: 255 div: 16
bias: 0 bias: 0


Medium:

0 31 0 0 1 0
31 125 31 -> 1 4 1
0 31 0 0 1 0
div: 255 div: 8
bias: 0 bias: 0


Heavy:

0 62 0 0 1 0
62 0 62 -> 1 0 1
0 62 0 0 1 0
div: 255 div: 4
bias: 0 bias: 0


Example of roundoff error:

Blend 50/50 rgb(255,255,255) with itself should logically result in rgb(255,255,255).

Bad: Bitshift/divide, then add:
255 / 2 = 127 (integer math only!)
127 + 127 = 254 (faded out!)

Good: Add, then bitshift/divide:

255 + 255 = 510
510 / 2 = 255


The reason AVS does this is probably because the blur doesn't use MMX, and so it works with the entire RGB color rather than unpacking and handling each channel separately (which is unbearably slow without MMX). When you work with the entire channel, you cannot use the good-method, because then the channels' bits would overlap.

APE authors: the 'lovely helper functions' inside the APE SDK header also contains bad, non-MMX versions of the blending functions. In this case, using convolution might in fact always be faster.

28th April 2003 17:18 UTC

unconed strikes again ;)
/me plans on testing this this afternoon...


28th April 2003 18:50 UTC

Thanks UnConeD...


28th April 2003 19:03 UTC

31? 125? 255? 62??? Does nullsoft understand the concept of 'power of 2' and how much faster it makes multiplication (i.e. bit shifting).

It is possible that in my blind envy of nullsoft's mad coding skillz that I might be ignoring the fact that the blurs probably don't use the actual convolution method....


28th April 2003 19:55 UTC

i think unconed meant 127 and 63, which are 2^n-1 (because it starts from 0), which works for bitshifting, no?


28th April 2003 22:15 UTC

I dunno for sure Atero, but those numbers do seem really weird.


28th April 2003 22:51 UTC

Um, did you guys READ the text? These are the resultant values, after round-off. To get the exact same behaviour in convolution, you need to use these values, because convolution does not have roundoff errors.

AVS does use the optimized version on the righthand (ie powers of two) internally, but it comes out as the values on the left.


29th April 2003 10:48 UTC

after long discussions about MMX with UnConeD, i still dont know how to work with it :(, anyway, can you post this in the tips and tricks folder too?