On Wed, Apr 11, 2007 at 08:10:24PM -0400, James Turner wrote:
> Hi Stefan,
>
> Sorry for the slow reply to this.
>
> > Thanks for spotting that. When I fix those lines, I see:
> >
> > [[ 3.901 3.099 2.099 1.1002 1.8998 2.901 ]
> > [ 3.901 3.099 2.
Hi Stefan,
Sorry for the slow reply to this.
> Thanks for spotting that. When I fix those lines, I see:
>
> [[ 3.901 3.099 2.099 1.1002 1.8998 2.901 ]
> [ 3.901 3.099 2.099 1.1002 1.8998 2.901 ]]
Actually, I think I made a mis
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 thi
> 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 see what's happening now. The input is supposed to
be interpolated and then r
> 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 SV
Very cool -- Thanks for digging into the code and making these fixes,
Stéfan! The ndimage C code is non-trivial for sure.
I'll test things out in the next couple of days.
Thanks again,
Zach
On Mar 28, 2007, at 10:25 AM, Stefan van der Walt wrote:
> On Wed, Mar 28, 2007 at 05:14:59PM +0200,
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
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 l
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 mainly a
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: o
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 Unse
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
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
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
Hello all,
Mystery solved, I think.
I downloaded Stéfan's Lena images and tried rotating them myself. As
far as I can tell, the artifacts are caused by numerical overflow, as
Lena is an unsigned 8-bit image.
If Lena is converted to floating-point before the rotation is
applied, and then th
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 eve
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 i
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
Hello again,
On Mar 23, 2007, at 7:56 AM, Travis Oliphant wrote:
>> I'm not sure what people normally do in computer graphics, since I'm
>> working more with natural band-limited images, but in the case of
>> Stefan's "rotate_artifacts" example, wouldn't it be appropriate to
>> use the 1st- or 0th
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-filterin
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 understan
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
>>mirr
Thanks for the explanation, Travis.
It now looks like there are 2 distinct issues getting mixed up here,
however. First, there is the issue of the mirror symmetry of the spline
algorithm affecting the data towards the edges, as described by Peter and
Travis (this is probably also what Anne is refe
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 broken (even on natural images
> with smooth variations) beca
Hi Zach,
> further I'm sorry to have caused Peter to be further bothered about
> this non-issue.
Don't worry -- I have let him know that we've probably figured it out.
I hope Stefan agrees.
> I now (hopefully) understand that the spline "pre-filter", while
> explicitly analogous to a traditi
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
> w
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 pr
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 allow
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
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, g
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
Hi James,
Would it be possible to ask Peter if he knows anything that could
help us resolve scipy ticket 213 ( http://projects.scipy.org/scipy/
scipy/ticket/213 )?
The basic issue is that ndimage.spline_filter seems to introduce
nasty ringing artifacts, which make all of the geometric transf
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.
Anne.
___
Numpy-discuss
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,
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 se
On Fri, Mar 16, 2007 at 11:49:56AM -0400, James Turner wrote:
> Hi Stefan,
>
> > I'd like to confirm that you see the same results when running your
> > script:
> >
> > [[ 4. 3. 2. 1.]
> > [ 4. 3. 2. 1.]]
> > [[-1. 3.12520003 2.11439991 1.0171 1.87479997 -1.]
> > [-
Hi Stefan,
> I'd like to confirm that you see the same results when running your
> script:
>
> [[ 4. 3. 2. 1.]
> [ 4. 3. 2. 1.]]
> [[-1. 3.12520003 2.11439991 1.0171 1.87479997 -1.]
> [-1. 3.12520003 2.11439991 1.0171 1.87479997 -1.]]
> [[-1.
Hi James
On Thu, Mar 15, 2007 at 06:01:55PM -0400, James Turner wrote:
> >Code snippets to illustrate the problem would be welcome.
>
> OK. I have had a go at producing a code snippet. I apologize that
> this is based on numarray rather than numpy, since I'm using STScI
> Python, but I think it s
James Turner wrote:
> Sorry I accidentally broke this thread in 2 (see thread of March 9).
>
> I tried manually adding the right reference in the mail header to
> continue the same thread, but obviously got it wrong (I think because
> I replied to the digest email instead of starting a new one). N
Sorry I accidentally broke this thread in 2 (see thread of March 9).
I tried manually adding the right reference in the mail header to
continue the same thread, but obviously got it wrong (I think because
I replied to the digest email instead of starting a new one). Not
sure whether there is a bet
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 und
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
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 that
43 matches
Mail list logo
