Blur convolution equivalents

[UnConeD]

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:

code:


  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:

code:


  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:

code:


  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.

[dirkdeftly]

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

[Jaak]

Thanks UnConeD...

[jheriko]

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

[dirkdeftly]

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

[anubis2003]

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

[UnConeD]

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.

[shreyas_potnis]

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?