Re: Filtering kernel width

mike3 schrieb:
On May 13, 5:33 am, News Reader <n...@xxxxxxxx> wrote:
mike3 schrieb:



On May 13, 1:34 am, Lorenzo Gatti <ga...@xxxxxxxxx> wrote:
On 13 Mag, 03:54, mike3 <mike4...@xxxxxxxxx> wrote:> Hi.
I was wondering: in order to do antialiasing with a windowing function
(see the thread I posted here earlier), how wide should the window be,
anyway?
As large as you can afford to use. A perfect lowpass filter (with a
bandwidth that depends on the desired resampling ratio) has a sinc
impulse response with infinite "tails"; it can only be implemented
exactly for periodic signals (the coefficients fold together).
Multiplying the ideal impulse response by a suitable windowing
function leaves a realizable filter of finite size: a larger window
gives a closer approximation, while different windowing functions give
different linear distortions.
But I thought the wider you make the "hump", the more "blurred" the
picture
becomes when it is convoluted with the function as more pixels
contribute
to the average with bigger weights.
And how do you apply it to a 2-dimensional picture, when it's
a fundamentally 1-dimensional function?
No, you can perform filtering and convolution in any number of
dimensions. Read other textbooks.
Well I didn't see a problem with performing the convolution, the
question
was the suitable generalization of the windowing function itself. How
does one generalize, for example, Lanczos or Hamming windows to 2-dim?
Perhaps this will help you

http://www-sigproc.eng.cam.ac.uk/~jl/imageproc/4F8imageprocessing08_h...


Hmm. However it doesn't seem to really explain how many pixels you
should stick
under the central "hump". And what happens when you use say a more-
than-one-lobe
Lanczos filter that has negative values? Won't convolution with that
yield pixels
having negative color? What do you do with that?


<cite>"However it doesn't seem to really explain how many pixels you should stick under the central "hump""

Hey be careful here! You do NOT stick pixels under the central hump. What you do is to clamp the function, but you evaluate the function at integral values! E.g. you spread the gaussian function by using a larger sigma and NOT by putting more pixels under a sigma=1 gaussian!!!

Jup, negative Pixel values could happen in some cases. The way to go there is e.g. clipping at [0,1] resp. [0,255]. However, look at a filter
function. Do you see the maximum value? It's located at the center pixel and in most cases it's significantly larger than the rest of the function. In the end the sum of the wheighted pixel values will fall in [0,1] or [0,255] again.

Then 1D->2D. In many cases you can go from 1D to 2D (discrete) simply by a matrix multiplication. Assume a 1D binomial (not normalized) kernel with 3 entries:

B := [1 2 1]

Multiply it from the left by B^T and get

[1 2 1]
[2 4 2]
[1 2 1]

which is the 2D kernel (not normalized). However, a 1D convolution in one direction followed by a 1D convolution in the other direction will do the same job, will be easier to implement, and will be much faster!

Still cope with the window size?
Here the 2D Version for arbitrar(il:)y odd sizes:

int iImgWidth, iImageHeight, iKernelSize;
int iKS2 = iKernelSize / 2;
// for the outer loops you could use some slightly
// more sophisticated border handling ;)
for (int i=iKS2; i<iImgWidth-iKS2; i++) {
for (int j=iKS2; j<iImgHeight-iKS2; j++) {
float fAccu = 0;
for (int u=-iKS2; u<=iKS2; u++) {
for (int v=-iKS2; v<=iKS2; v++) {
fAccu += kernel[u+iKS2][v+iKS2]*image[i+u][j+v];
}}}}

Now simply implement it and use a single constant for your first test kernel (be it 1D or 2D), so you have a gold standard to compare with.
And don't forget to NORMALIZE!!!

Btw. ask yourself:
When I shrink an image by a factor of 2 should I use information from 100 pixels away, and when I shrink by a factor of 100 can a 2 pixel neighbourhood be large enough?
If you answer both questions with "NO" you're pointing in the right direction ...

Best
-- NR
.

Relevant Pages

  • Re: question about reconstruction windows with STFT-synthesis
    ... much wider than the frame size, that is an essential difference from the ... reconstruction window. ... About the filter length, what you describe seems to me like the ... due to convolution effects, which I take care of by padding some zeros ...
    (comp.dsp)
  • Re: newbie questions on OpenGL and C#. I am using NeHe example code
    ... > and 2) you can have the window covered by another window ... This implies that read pixels is not ... to put a red square down on the drawing surface. ... >> graphics card then you're rendering in software. ...
    (comp.graphics.api.opengl)
  • Re: Filtering kernel width
    ... , how wide should the window be, ... function leaves a realizable filter of finite size: ... becomes when it is convoluted with the function as more pixels ... Well I didn't see a problem with performing the convolution, ...
    (comp.graphics.algorithms)
  • Re: Filtering kernel width
    ... , how wide should the window be, ... function leaves a realizable filter of finite size: ... However it doesn't seem to really explain how many pixels you ... Assume a 1D binomial kernel ...
    (comp.graphics.algorithms)
  • Re: A "slanted edge" analysis program
    ... The range used by Imatest is from -6 to +10 in quarter pixel increments, and thus allows to handle at least a symmetrical PSF with a support of 13 pixels, which would be for a *very* blurry image. ... Wouldn't this avoid the change of LSF shape that using a single, ... you take the windowed DFT of the first 16 values ... Also, do you think a Hanning window is a reasonable choice for my purposes, or should I choose a different window type? ...
    (comp.periphs.scanners)