NicolasRobidoux wrote:I chose the main branch so it covers [-4,4] for Sinc; this, in my understanding, covers 99% of the calls to it? (Correct me if I'm wrong.)
I imagine that since you are caching the row/column results you may call it with arguments outside of that range to fill some entries with zeros? (I have not looked at how you store the "matrix" of coefficients, so I don't know whether/how you pad with zeros to have a fixed band.)
If I remember it allocates the cache with just the required values to weigh the pixels in the specific row or column, within the filter's window of operations.
The Cylindrical EWA filter however caches 1000 values over a fixed 0 to 2 window (though the index values into this window is squared to avoid needing to calculate a square root to get actual elliptical radius). It currently uses a very blurry Gaussian filter by default, but I want to try other filters and will be looking at making those 1000 values (or so) cover filter window as appropriate. Of course it would use Besel functions rather than Sinc for cylindrical filtering.
Hmmm you do know that we actually have the Lagrange filter, which is a piece-wise polynomial representation of the sinc filter. Though the pieces can be disjoint, especially for an even number of pieces.
My re-design of resize was to basically make it a collection of functions which can be put together to generate both direct and windowed filters.
I think if you implement your polynomials as separate functions, then it will fit nicely into this scheme.
You then do not need to modify the existing functions. Though the optimization of 'Blackman' Filter, should remain.
The addition or changes then only needs to be added to the filter selection tables (in the filter setup function). Later in the setup, a check can be made for the range, and the polynomial sinc selection (or sinc selection) can be overridden as appropriate. Later expert options can then override those default selections. I already do something similar for the test between using a Sinc vs the Besel function depending on whether the filter is declared as being two pass rectangular (-resize), or one pass cylindrical (-distort).
This would be easy to install (just new table and function entries), allow automatic fall back if window range is too large, and after defaults worked out, allow expert options to override those function selection defaults. It also leaves the existing functions untouched, without if-then selections or other changes.
The advantage of this is that their will then be no 'window range' decision needed once the filter is setup, as it was already done and was merged into the filter function pointer. Both filters (Sinc and the polynomial Sinc filter or whatever it is called) will be available, either as default for 'named' filters, or via expert options.
After that a user selection of a 'Blackman' filter, can select the 'Blackman windowing function', and your 'polynomial sinc' unless an expert option overrides. Lanczos could then call your 'polynomial lanczos', without any windowing function. Clean an simple.
It may require a separate set of 'function' identifiers for the expert options, as opposed to user selected 'filter' identifiers, which use a table lookup to select 'common' function and window ranges. This separation of the two types of identifiers was something which I managed to avoid in my redesign, as each filter typically specified a specific function combination, however with the possibility of selecting 'Polynomial Sinc' over 'Trigonometric Sinc' that may no longer be the case.
I was indeed wondering if approximating, say, lanczos 2 or 3 directly fits in IM's resize.c. It appears that the answer is "not really."
A Lanczos approximation can be added. But it would not be a windowed 'sinc' filter but a direct filter, much like Gaussian, box, triangle, and the cubic filters.
In any case, thank you for considering our code for inclusion. Chantal and I were pretty elated when it made it in, and we'll be sad if it's pulled out. But we'll understand.
I can definitely see a place for it. IM has the widest image filter selection I know of, with expert controls to make any filter researcher happy! I made it that way on purpose, with many new additions added during that last redesign. As well as many bug fixes - Blackman before that redesign was being used directly and not being used a a sinc windowing filter -- Arrgghhhh -- though the expert controls still allow you to do this, if you really want. I don't see why we can't add even more!
Now that I have remembered what I was doing, I see I made some good decisions, and you code can fit in easilly with minimal impact to existing code. The only major change I see needed is a separate expert 'function' identifiers, verses user 'filter' identifiers, to allow differentiating the new polynomial functions verses the trigonometric functions.
Hmmm you may like to look at how I implemented 'Cubic' filters. I use the same function, but with different 'constants' for the different filters. You polynomial functions may be implemented in a similar way!
Now if we could just so something similar for the un-scaled 'interpolation' filters