Re: [Algorithms] Gaussian blur kernels

[Jon W. <jw...@gm...>]

Simon Fenney wrote:
> Jon Watte wrote:
>
>   
>> Actually, they are both low-pass filters, so
>> downsampling-plus-upsampling is a form of blur. However, box
>> filtering (the traditional downsampling function) isn't actually all
>> that great at low-pass filtering, so it can generate aliasing, which
>> a Gaussian filter does not.
>>     
>
> AFAICS a box filter won't "generate" aliasing, it's just that it's not
> very good at eliminating the high frequencies which cause aliasing. A
> Gaussian, OTOH, has better behaviour in this respect...
>
>   

Yes, what I meant by that was that the process of box filtering plus 
downsampling can generate aliasing. As can Gaussian plus downsampling if 
your kernel isn't wide enough :-) With filters, it's all about the 
response curve -- you'll need a significantly wide Gaussian to get below 
the -61 dB quantization noise floor of an 8 bpp RGB image for any 
possible aliasing.

>
> ...again, (and my recollection, too, is a bit hazy), the shape of a
> Gaussian filter in the frequency domain is, again, a Gaussian, so it's
> still going to let through some amount of illegally high frequencies. In
>   

All filters do that, because there are no perfect brick wall filters. 
You have design a filter that rejects enough of the aliasing that you 
care about, while retaining as much as possible of the signal that you 
want. I think we can agree that a box filter is pretty far from the 
optimal choice for the more demanding cases :-)

> A sinc filter, when mapped into the frequency domain, is a box and so
> has a hard cut-off of higher frequencies, which should be ideal.
>
>   
That would be an infinitely wide sinc. In most cases, though, you end up 
with only one or two lobes of the sinc, which makes it significantly 
less than ideal box shape :-( Not to mention that all this is defined 
for static processes, but texture images are, at best, only locally 
static. The classic transient-response-vs-aliasing problem, where the 
answer is that you probably want to oversample by more than Nyquist 
suggests you should need to (or why a 48 kHz converter is surprisingly 
better than a 44.1 kHz converter for the 20-20k audible range -- but I 
think we're getting topic skew here :-)

Fabian also mentioned Multirate Filter Banks -- in the audio case, the 
equivalent is the polyphase filter AFAICR, and that's used quite heavily 
in real time, because it actually saves cycles compared to first 
filtering and then decimating. I think a properly implemented multirate 
filter in a pixel shader might actually give you very good bang for the 
cycle buck!

Sincerely,

jw



-- 

  Revenge is the most pointless and damaging of human desires.