Thanks for the information and the paper link, James. I certainly appreciate the perspective, and now see why the anti-aliasing and reconstruction filtering might best be left to clients of a resampling procedure.
Hopefully at least some of the kinks in the spline interpolation (to date: obligate mirror boundary conditions, extra edge values, integer overflow) can be smoothed out. I can't guarantee that I'll have the time or expertise to deal with ni_interpolation.c, but I'll try to give it a shot some time here. Zach On Mar 26, 2007, at 1:16 AM, James Turner wrote: > PS... (sorry for all the posts, for anyone who isn't interested...) > >> Agreed, it looks like aliasing. Nevertheless, any resampling >> procedure is supposed to deal with this internally, right? Either by >> lowpass filtering (traditional case), or by spline fitting (spline >> case as described by Unser and understood by me) -- it shouldn't be >> letting aliasing bubble through, correct? > > In the general case, I don't think it is appropriate for the > resampling > procedure to use low-pass filtering internally to avoid artefacts, > except perhaps when downsampling. It probably makes sense for computer > graphics work, but there are cases where the input data are band > limited to begin with and any degradation in resolution is > unacceptable. > Where needed, I think low-pass filtering should either be the > responsibility of the main program or an option. It's not even > possible > for the resampling procedure to prevent artefacts in every case, since > the aliasing in a badly undersampled image cannot be removed post > factum (this is for undersampled photos rather than artificial > graphics, > which I think are fundamentally different because everything is > defined > on the grid, although I haven't sat down and proved it > mathematically). > I'm also not sure how the procedure could decide on the level of > smoothing needed for a given dataset without external information. > > Of course intermediate-order splines will probably keep everyone > happy, > being reasonably robust against ringing effects without causing much > smoothing or interpolation error :-). > > By the way, I think you and Stefan might be interested in a medical > imaging paper by Lehmann et al. (1999), which gives a very nice > overview > of the properties of different interpolation kernels: > > http://ieeexplore.ieee.org/Xplore/login.jsp?url=/ > iel5/42/17698/00816070.pdf?arnumber=816070 > > For what it's worth, I'd agree with both of you that the numeric > overflow should be documented if not fixed. It sounds like Stefan has > figured out a solution for it though. If you make sense of the code in > "ni_interpolation.c", Stefan, I'd be very interested in how to make it > calculate one less value at the edges :-). > > Cheers, > > James. > > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion@scipy.org > http://projects.scipy.org/mailman/listinfo/numpy-discussion _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
