Hi James
On Wed, Apr 04, 2007 at 08:29:50PM -0400, James Turner wrote:
It looks like the last output value is produced by reflecting the
input and then interpolating, but presumably then the first value
should be 3.9, for consistency, not 3.1? Does that make sense?
Aargh. I think I
OK, that was a one-line patch. Please test to see if there are any
subtle conditions on the border that I may have missed. I know of one
already, but I'd be glad if you can find any others :)
Thanks, Stefan! That looks much better.
Today I finally had time to figure out the basics of SVN,
Hi,
I notice now that we've been having this discussion on the wrong list
-- oops! We're nearly done, though.
On Mon, Mar 26, 2007 at 04:16:51AM -0400, James Turner wrote:
For what it's worth, I'd agree with both of you that the numeric
overflow should be documented if not fixed. It sounds
On Wed, Mar 28, 2007 at 05:14:59PM +0200, Stefan van der Walt wrote:
As for the values at the edges, I'm still working on it.
OK, that was a one-line patch. Please test to see if there are any
subtle conditions on the border that I may have missed. I know of one
already, but I'd be glad if you
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
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:
Hello folks,
Hmm, this is worrisome. There really shouldn't be ringing on
continuous-tone images like Lena -- right? (And at no step in an
image like that should gaussian filtering be necessary if you're
doing spline interpolation -- also right?)
That's hard to say. Just because it's
On Sat, Mar 24, 2007 at 01:41:21AM -0400, James Turner wrote:
That's hard to say. Just because it's mainly a continuous-tone image
doesn't necessarily mean it is well sampled everywhere. This depends
both on the subject and the camera optics. Unlike the data I usually
work with, I think
On Sat, Mar 24, 2007 at 03:25:38PM -0700, Zachary Pincus wrote:
If Lena is converted to floating-point before the rotation is
applied, and then the intensity range is clipped to [0,255] and
converted back to uint8 before saving, everything looks fine.
Thanks, Zachary! I can confirm that.
Hi Zach,
Based on my reading of the two excellent Unser papers (both the one
that ndimage's spline code is based on, and the one that Travis
linked to), it seems like a major point of using splines for
interpolation is *better* behavior in the case of non-band-limited
data than the
Hi Stéfan,
Agreed, but the aliasing effects isn't not the problem here, as it
should be visible in the input image as well.
It's a bit academic now that Zach seems to have found the answer, but
I don't think this is true. Aliasing is *present* in the input image,
but is simply manifested as
Stefan van der Walt wrote:
On Thu, Mar 22, 2007 at 04:33:53PM -0700, Travis Oliphant wrote:
I would rather opt for changing the spline fitting algorithm than for
padding with zeros.
From what I understand, the splines used in ndimage have the implicit
mirror-symmetric boundary
James Turner wrote:
By the way, ringing at sharp edges is an intrinsic feature of higher-
order spline interpolation, right? I believe this kind of interpolant
is really intended for smooth (band-limited) data. I'm not sure why
the pre-filtering makes a difference though; I don't yet understand
Hello all,
On Mar 23, 2007, at 3:04 AM, Stefan van der Walt wrote:
On Thu, Mar 22, 2007 at 11:20:37PM -0700, Zachary Pincus wrote:
The actual transform operators then use these coefficients to
(properly) compute pixel values at different locations. I just
assumed that the pre-filtering was
Hi Zach,
Hmm, this is worrisome. There really shouldn't be ringing on
continuous-tone images like Lena -- right? (And at no step in an
image like that should gaussian filtering be necessary if you're
doing spline interpolation -- also right?)
That's hard to say. Just because it's mainly a
The people at STScI put me in touch with Peter Verveer, the author of
nd_image. Unfortunately Peter is currently unable to maintain the code
(either in numarray or scipy), but he did send me some comments on the
problem discussed in this thread. Here's what he said:
James.
-
Hi James,
Yes,
On Thu, Mar 22, 2007 at 02:41:52PM -0400, Anne Archibald wrote:
On 22/03/07, James Turner [EMAIL PROTECTED] wrote:
So, its not really a bug, its a undesired feature...
It is curable, though painful - you can pad the image out, given an
estimate of the size of the window. Yes, this sucks.
Stefan van der Walt wrote:
On Thu, Mar 22, 2007 at 02:41:52PM -0400, Anne Archibald wrote:
On 22/03/07, James Turner [EMAIL PROTECTED] wrote:
So, its not really a bug, its a undesired feature...
It is curable, though painful - you can pad the image out, given an
estimate of the
Hi Zachary,
OK - I sent Peter the URL for your post...
Cheers,
James.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
On Thu, Mar 22, 2007 at 04:33:53PM -0700, Travis Oliphant wrote:
I would rather opt for changing the spline fitting algorithm than for
padding with zeros.
From what I understand, the splines used in ndimage have the implicit
mirror-symmetric boundary condition which also allows them to
By the way, ringing at sharp edges is an intrinsic feature of higher-
order spline interpolation, right? I believe this kind of interpolant
is really intended for smooth (band-limited) data. I'm not sure why
the pre-filtering makes a difference though; I don't yet understand
well enough what the
Hello all,
By the way, ringing at sharp edges is an intrinsic feature of higher-
order spline interpolation, right? I believe this kind of interpolant
is really intended for smooth (band-limited) data. I'm not sure why
the pre-filtering makes a difference though; I don't yet understand
well
Thanks, Stefan.
In [25]: import numpy as N
In [26]: x = N.array([[4,3,8,1],[4,3,8,1.]])
In [27]:
ndi.geometric_transform(x,shift,output_shape=(2,6),prefilter=False,order=0,cval=-1)
Out[27]:
array([[-1., 3., 8., 1., 8., -1.],
[-1., 3., 8., 1., 8., -1.]])
Your example seems to
Hi Stefan,
Thanks for the suggestions!
Is this related to
http://projects.scipy.org/scipy/scipy/ticket/213
in any way?
As far as I can see, the problems look different, but thanks for
the example of how to document this. I did confirm that your example
exhibits the same behaviour under
Hi James
On Fri, Mar 09, 2007 at 08:44:34PM -0300, James Turner wrote:
Last year I wrote a program that uses the affine_transform()
function in numarray to resample and co-add datacubes with WCS
offsets in 3D. This function makes it relatively easy to handle
N-D offsets and rotations with a
Last year I wrote a program that uses the affine_transform()
function in numarray to resample and co-add datacubes with WCS
offsets in 3D. This function makes it relatively easy to handle
N-D offsets and rotations with a smooth interpolant, which is
exactly what I wanted. However, I am finding
26 matches
Mail list logo
