Hmmm, I'll have to investigate that -- the BAD stuff used to work, though I didn't make a formal test procedure for it (bad craig!)
There is a well known all-NaN/all-BAD problem with most FFT methods - if even one pixel is NaN/BAD in either input array, it will poison the whole output, while direct methods can (more correctly) ignore the bad value. Is that what happened? If so, then we probably need to be smarter about how FFT methods handles bad values. Best, Craig On Feb 20, 2009, at 2:47 PM, Doug Hunt wrote: > Hi all: I also have noticed bad results with convolveND when it > used the > FFT path. What I got for some input data was all NaNs, whereas the > direct > method gave reasonable results. > > Another bug I noticed was that the 'truncate' option is not setting > bad > values correctly near the boundaries (from the convolveND man page): > > The (default) truncate option marks all the near-boundary pixels as > BAD if you have bad values compiled into your PDL and the > array's > badflag is set. > > I ended up having to manually set bad values at the start and end of > the > input array. > > Regards, > > Doug > > > > [email protected] > Software Engineer IV > UCAR - COSMIC, Tel. (303) 497-2611 > > On Fri, 20 Feb 2009, hernan gonzalez wrote: > >> fftconvolve seems indeed broken. >> >> my $p1 = pdl(1,0,0,0); >> my $p2 = pdl(1,0,0,0); >> fftconvolve($p1,$p2); >> print $p1 . "\n"; >> >> results in >> >> [1.75 -0.25 -0.25 -0.25] >> >> >> It seems that the result is missing the DC component (as if the fft >> had supressed the 0-freq value) and a factor 2 is missing somewhere. >> >> Hern?n >> >> >>> Andreas Michalowski michalowski at ifsw.uni-stuttgart.de >> >> A simple example is like this: I convolve two 1D piddles, the first >> is >> zero except for one value which is 1. The second one has a gaussian >> shape. I expect as the result a piddle which contains a gaussian >> shape >> converging to zero far away from the center. >> >> The resulting piddle shows the expected gaussian shape but is not >> converging to zero, instead of that to a negative constant value. It >> seems that the result has a negative offset. >> If I do the convolution with "convolve" instead of "fftconvolve" the >> result is exactly what I expect. >> >> Does someone has an idea why fftconvolve has this (for me) unexpected >> and (for me) incorrect behavior? >> >> Many thanks! >> >> Andreas >> >> _______________________________________________ >> Perldl mailing list >> [email protected] >> http://mailman.jach.hawaii.edu/mailman/listinfo/perldl >> > > _______________________________________________ > Perldl mailing list > [email protected] > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl > _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
