Legacy ImageMagick Discussions Archive

The article http://www.cg.tuwien.ac.at/research/vis ... indows.pdf (BibTeX data below) recommends the following values for the Kaiser alpha parameter when used as a Sinc window:
For 2 Sinc lobes: 5.36.
For 3 Sinc lobes: 8.93.
For 4 Sinc lobes: 12.15.
For 5 Sinc lobes: 15.4. Reading through quickly, it appears to me that their optimization approach is likely to more accurate reconstruction of smooth data, for example linear colour gradients.

So, what my grad student Adan Turcotte will quantitatively compare to other upsampling schemes is

Of course this suggests optimizing the Kaiser alpha for minimax reconstruction of affine gradients, which is a different optimization approach than the above authors, but with the same goal in mind.

Minimax reconstruction of affine gradients is the principle that identified the Keys cubics as being the best BC-splines for EWA use. viewtopic.php?f=22&t=19823

Interesting, esp. the connection between alpha and the "critical frequency": https://ccrma.stanford.edu/~jos/sasp/Ka ... pared.html

Another, that discusses the connection with other window functions (other than DPSS): http://help.scilab.org/docs/5.4.0-alpha ... indow.html

If I read between the lines what https://ccrma.stanford.edu/~jos/sasp/Ka ... pared.html is saying, and use the fact that the highest frequency representable in an image sampled in a direction parallel to one of the axes is .5, it would appear to me that a good rule of thumb is either alpha = (# of Sinc lobes) times pi or alpha = (# of Sinc lobes -1/2) times pi, depending whether we count bins at midpoints or at the original sampling points.

(Warning: In the above reference, the ImageMagick alpha is called beta, which is "the other alpha" multiplied by pi. If one used this alternate standard definition of alpha, the first rule of thumb would become that alpha = # of lobes.)

With the first rule of thumb, this gives alpha = 6.2831853071795865 for lobes=2, alpha = 9.4247779607693797 for lobes = 3, alpha = 12.566370614359173 for lobes = 4 and alpha = 15.707963267948966 for lobes = 5.
With the second, this gives alpha = 4.7123889803846899 for lobes=2, 7.8539816339 74483 for lobes=3, and alpha = 10.995574287564276 for lobes = 4, alpha = 14.13716694115407 for lobes = 5.

Note how the two rules of thumb bracket the optimized values given by Theussl, Hauser and Groller (top citation above).

All I know is the default value 6.5 is from the original zoom program which probably pre-dates that report.


I have not explored Kaiser much. However it also look like I have broken kaiser, (not that it would have been working) in my fix for Gaussian filter. I could get not data from that filter in filter:verbose! -- on my ToDo

Looks like an expansion of the filter docs for Kaiser is coming


Question which definition or alpha/beta do you think is more known. or will that need documenting too -- probably!
I doubt we have had any expert looking at Kaiser seriously at this point in time.

Beta/alpha are kind of evenly used. If you were to allow both, there would be less confusion, because if there is a beta, clearly alpha is not the same.

I did not do a full survey, but it looks like theoricians use "alpha/beta", and software uses "alpha" (which is the beta of the theoricians, equal to pi times the alpha of the theoricians).

Is Kaiser fixed in svn now? Adam's getting close to adding it to his suite.

Making the name of the key parameter beta would allow you to keep the current code unchanged (except for this name change) and would remove all confusion. What you have right now is what the theoreticians call beta.

NicolasRobidoux wrote:Beta/alpha are kind of evenly used. If you were to allow both, there would be less confusion, because if there is a beta, clearly alpha is not the same.

I did not do a full survey, but it looks like theoricians use "alpha/beta", and software uses "alpha" (which is the beta of the theoricians, equal to pi times the alpha of the theoricians).

Is Kaiser fixed in svn now? Adam's getting close to adding it to his suite.

Yes it is.

If you have the 'simplified' formula for Kaiser 'alpha/beta' use. I could add it to the SVN very quickly.

Currently the (simplified) Kaiser formula is... over a windowing range of 1.0

I think the best solution is to just rename alpha, beta. No confusion possible then. "Your" alpha is called beta by most of the theoreticians/textbooks, and the software people who call it alpha (like "you") don't use beta at all.
So, someone who does not know what beta is is forced to learn what they need to know to use the correct value: Do I multiply by pi, or not?

Using the theoreticians' alpha forces a multiplication by pi to get your current alpha (=their beta).

Also, as indicated in your own comments, you could deletefrom the Kaiser code (which would not make much difference since you normally use LUTs).

Regarding simplified formulas: You mean something like I did with SincFast? Or you meant the "pi" simplification business, which I was not very clear about?

No I mean the actual formula containing both alpha, and beta. Or are they really the same value
just one multiplied by PI.

I am trying to understand what I need to implement!

Is this Pseudo-code correct? Then Kaiser formula as before. but using beta instead of alpha Of course I'll report BOTH values in the verbose report.
Basically EXACTLY what should be implemented!


NOTE: I left the normalization in Kaiser function but if IO(0) ==> 1.0 then I am probably better off leaving it out.
Just as I did for the Gaussian filter, as it made comparison of filters much easier.


Future: I also want to add some convolution kernels called 'filter1d' and 'filter2d' that generates linear and cylindrical kernels based on the current filter settings, for direct use in -convolve (which is now an alias for -morphology Convolve). Of course I would include in radius and scale kernel arguments with defaults set to support and 1.0 (no-op filter) scaling.

I just never seemed to get around to going this.

Also also want to somehow include a kernel to image converter (probably a special input coder)
Technically this is similar to a convolve of a single white pixel, but without 'normalization'
or better still a de-normalization flag which scales the kernel values so the origin value = 1.0

To many things To Do!!!!!! Arrrggghhhh.....
Do you have any programming 'slaves' to spare?

Actually when I was doing convolves I learned that the Gaussian function is actually not the the exact function to use for generating 'discrete Gaussian convolution kernels'.

What you want is for each value to represent the area under that 'pixel' That is the difference in the start and end derivatives for that sample. Research showed that to be a Err() function! The result however is very similar to using that function directly.

It only really becomes noticeable when you apply the mathematical normalization on very small sigma. As sigma approaches zero, and the Gaussian curve becomes an 'impulse' the normalization factor started to head for infinity. That is the value at '0' becomes very large, but as the 'curve' width gets very small the area under the curve remains equal to 1.0.

I am sure that technically this also should be applied to re-sampling filters too but it seems it it just 'too hard' to deal with for little to no benefit, as you are more interested in normalizing the weights, rather than generating a 'discrete' function.

Hmmm Sorry I am rambling -- I'll shut up now. We now return you back to Kaiser Filters...

@Anthony: If I understand correctly, what you are talking about is "exact area filtering".
I used to be a strong believer. No more. In the orthogonal context, if you box filter the surface obtained by exact area filtering, you get an interpolant. So, more or less, dealing with point values is roughly equivalent to box filtering the "histopolant". And box filtering at the original grid resolution generally makes an awful lot of sense.
This connection is built into the Upsize GIMP plugin http://registry.gimp.org/node/19582: Box filtering (global) bi-quadratic histosplines gives something which basically is standard (global) bicubic spline interpolants. (In the plugin, the former is called "sharp", the latter is called "smooth".)
Yes, I know I'm simplifying, and not quite dealing with the precise question. But my opinion is that this direction (exact area methods) is a back back back back burner.

Topic moved to Developers Forum (where it is better suited - a link left in users forum)

A new topic was split from this involving Angled Blurs (using Convolution Kernels)
viewtopic.php?f=2&t=20985

anthony wrote: Is this Pseudo-code correct?

Code: Select all

    beta=6.5
    if "filter:beta" then  beta=value
    if "filter:alpha" then  beta=value*PI
    normalization=1/IO(beta)

Then Kaiser formula as before. but using beta instead of alpha

Code: Select all

   normalization   *   IO(beta*sqrt(1.0-x*x))

Yes, this is correct. But please send me an email when you make that change, because then I'll need to change immediately what Adam runs (since right now we use an alpha value which should be set as a beta value once you've change this bit of the API).