Re: Filtering kernel width

On May 15, 7:56 am, News Reader <n...@xxxxxxxx> wrote:
mike3 schrieb:
<snip>
No, obviously. But how much then should be used? Suppose we are
halving the image. If we take 2 pixels and use a kernel that is
symmetrical, then the 2 weights we get will be equal... so the choice
of kernel function becomes irrelevant for 2 pixels, 2x2 pixels, etc.
Suppose I was using a sinc filter, that has 1 lobe and is 0 outside
it.
The lobe comes down to 0 at each end. I I evaluate a 2 INTEGER
positions, say at 0 and 1, and the sinc is 1 at 0 and 0 at 1 (unless
we
use a higher width, so see earlier question), then we have used only
1 pixel, which defeats the whole point of the filter! We can't
evaluate at
-0.5 and 0.5, for example, as you said "evaluate at integral values"!

Well, as far as I can tell sinc(1) = sin(1)/1 = 0,01745 != 0
and I would bet that sinc(x)!= 0 for most integral values.

I guess I was thinking of sin(pi x)/(pi x) which _is_ 0 at +/-1. Also,

And yes, if you choose a symmetric 2x2 window the choice of the filter
function is irrelevant given that the function is symmetric. Do NOT use
even window sizes! And with 2x2 you picked a special case and I can tell
you another one: if you take a 1x1 kernel than ...
These obeservations (for 1x1 and 2x2) will not hold for larger sizes
except you use the box filter, which is essentially taking the mean of
all pixels.


Hmm. But how wide does one make the middle lobe of "sinc", for
example?

And what's this stuff about a "window function" (like Hamming, etc.)?
How
does that differ from the kernel?

Of
course even if you did that, sinc(-x) = sinc(x) so the result would be
equal weight to both pixels which is no better than averaging and we
could swap sinc out for a Gaussian or something and there'd be NO
change.

Of course you should use (quasi) symmetric filters as long as you work
with isotropic cases, so filter(x) == filter(-x). Why should a pixel
that is d units away to the left of the center pixel be wheighted other
than one in distance d to the right of the center pixel?

Tipp: Look at ODD kernels only! Even kernels aren't really "nice" to
handle neither in practice nor in theory!


And I guess I'm seeing some of the problems now then?

Ok now, back again to kernel width. I assume that you did not get why at
all you should filter. Suppose you have an image composed of 1 pixel
wide black and white lines. Now you want to resize by a factor of 1/2.
Let's first look at the naive solutions:


Well I sort of "get" the idea: it's about trying to get rid of the
high
frequency details, so when you downsample they don't "alias" into
nasty patterns as you skip all those inbetween pixels (like moire
effects,
etc.).

This is 1D notation for simplicity ...

1. You simply take every second pixel of the original image throwing
away the rest. If you do so the resulting image will be either black or
white depending which pixel Pix(2n) or Pix(2n+1) you throw away. Not
good. Why is that so? Because you do not respect any information from
the neighbouhood.

2. You simply calc the mean out of two pixels and end up with a medium
grey image. Ok that's better than 1 since you used information from a
small neighbourhood, but is it really good? No, cause the original
structure (the "ripples") of the image are gone.

3. You use a larger neighbourhood and e.g. a binomial filter like
[1 2 4 2 1]/10. Ok, lets have a look what happens when you convolve:
Let black be 0 and white be 1. We get

(0*1 + 1*2 + 0*4 + 1*2 + 0*1)/10 = 0.4 for a black pixel line and
(1*1 + 0*2 + 1*4 + 0*2 + 1*1)/10 = 0.6 for a white pixel line,
which are both significantly different from taking the mean = 0.5
Now, you could say when I now throw away every second pixel my image
will be either 0.4 or 0.6. That's right, but again here factor 2 is a
special case. Have a look what happens when zoomimg by a factor of 1/3
or in the case of 2 or 3 pixel wide lines ...

The trick in using filters is simply to take more of the neighbouhood
into account so that the "overall appearance" of the image is better
reflected. Since remote pixels are not "that important" than nearby
pixels, the wheight assigned to them by the filter function will be much
smaller than the wheight of the central pixel (in most cases). So in
general it is best that your kernel is as big as the whole image simply
to take all available information into account. In theory it would be
good if the kernel would be infinitely large, but then you run into
problems like missing image data aka border effects etc. So, as someone
else already stated the kernel should be as large as you can afford. My
suggestion was to choose a kernel between 3x3 and 11x11 for practical
applications and to check the outcomes for quality. Then choose the
smallest kernel that is satisfying you.


So one could, for example, make the kernel the next odd size larger
than
the amount one is dividing by (so if one is downsampling 2x2 one would
use
a 3x3 kernel, etc.).

Now, get something running with a kernel that is 3x3 and NOT 2x2. Use a
binomial filter [1 2 1]/4.0 and look at the result. Then use [1 2 4 2
1]/10 and look at the result. When you got this running try a gaussian
filter. If you have problems come back again and show what you did and
tell where you think the problem is.

Side note: the filtering as such is not only needed for anti-aliasing,
but in far more general settings. Some people just want to blur an image
for esthetic purposes.

So then basically that's what these filters do: they "blur" the image
in a
certain way before downsampling it. And using different types of
filter
yields a different "blur", smearing away the high-frequency details so
they
don't alias into nasty patterns upon downsampling.

Side note: the filtering as such is not only needed for anti-aliasing,
but in far more general settings. Some people just want to blur an image
for esthetic purposes. So on the Web there is plenty of material
concerned with image processing and filtering. I suggest you give google
a try and get additional info from there, since most of the things
written here have been written millions of times already. And have a
look at sourceforge & Co. since there should also be a bunch of coded
examples. There is also information on how to discretize a filter
function (especially for Gauss), i.e. which kernel size is needed to
sample the function such that it is represented up to some given
precision, i.e. when becomes the function that small that it does not
contribute any more, which in turn is most often the case when
filter(x) < 1/255. Since the absolute envelope of most filter functions
is strict monotonically decreasing you can definitely stop at that point
to sample your function. You still could use larger kernels, but despite
of a longer calculation times it will not have any effect on the outcome.

Best
-- NR

.

Relevant Pages

  • Re: Gaussian Implementation
    ... The first step is to create a kernel. ... you filter the color values. ... The inner-most pixel is called the ... // define 5x5 Gaussian kernel ...
    (comp.graphics.algorithms)
  • Re: Gaussian Implementation
    ...   I am here to get some direction from you guys. ... you filter the color values. ... The inner-most pixel is called the ... A 5*5 kernel leaves 2 rows and 2 columns at all edges unfiltered. ...
    (comp.graphics.algorithms)
  • Magic kernel for image zoom resampling?
    ... My need was to downsample an image by a factor of 8 in each direction ... To downsample or upsample by a factor of 2, use a kernel ... placed over every second pixel in each direction. ... The results for upsampling are astoundingly good, ...
    (sci.image.processing)
  • Re: Selective Gaussian -> Early test app posted
    ... >> Well, the problem with an arbitrary kernel, is that it imposes a ... >> gaussian kernel is separable, you can take advantage of this fact in ... can we take advantage of this for selective gaussian blur? ... is the value of some color component of a pixel at ...
    (borland.public.delphi.language.basm)
  • Gaussian Implementation
    ... The first step is to create a kernel. ... you filter the color values. ... The inner-most pixel is called the ... // define 5x5 Gaussian kernel ...
    (comp.graphics.algorithms)