UnConeD
28th April 2003, 16:10
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.
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.