Hi 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.
That may be what happened. My test data are not easy for me to find right now! Thanks, Doug > > 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
