![](https://secure.gravatar.com/avatar/ad13088a623822caf74e635a68a55eae.jpg?s=120&d=mm&r=g)
On Mon, Mar 22, 2010 at 8:17 PM, Nico Schlömer <nico.schloemer@gmail.com> wrote:
If it is much faster than the n-dimensional fft convolution
For me it is about 60(!) times faster, see the attached graph (mind the log scaling). I had NxN data with NxN kernels convolved.
The source code for producing the figure is attached as well.
be worth writing a fftconvolve2 What remains to be checked is the ratio for the case where the kernel is a lot smaller than the data. If that turns out to be equally fast, I don't see any reason to keep the current implementation of scipy.signal.fftconvolve.
I'm using it (or tried to use it) also for 3d data, so we still want to keep the nd version. You could file an enhancement ticket for a fftconvolve2d A few weeks ago there was also the remark in a thread that signal.convolve2d is faster than the nd version. I'm not an image processing person, so I don't know what the optimal convolution behavior for this is, and what could be a replacement for stsci.convolve. There is also a convolution in ndimage but I have no idea about it's performance, and I don't know if scikits.image has any special convolutions.
Anyway, this may also be related to that other discussion going on about FFTW. I'm not sure what the current status about FFT implementations in SciPy is, but at first glance there seem to be quite a few really, which to me seems redundant and unhelpful.
Does anyone have more insight here?
fftw has been removed from scipy. scipy.fft and numpy.fft are plain vanilla. cheers, Josef
Cheers, Nico
_______________________________________________ SciPy-User mailing list SciPy-User@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-user