[Numpy-discussion] nd_image.affine_transform edge effects
Mon Mar 26 03:39:29 CDT 2007
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
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.
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
> 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
> Where needed, I think low-pass filtering should either be the
> responsibility of the main program or an option. It's not even
> 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
> which I think are fundamentally different because everything is
> on the grid, although I haven't sat down and proved it
> 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
> 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
> of the properties of different interpolation kernels:
> 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 :-).
> Numpy-discussion mailing list
More information about the Numpy-discussion