[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-gsl] 2d FFTs, DCTs, etc.
From: |
Brian Gough |
Subject: |
Re: [Help-gsl] 2d FFTs, DCTs, etc. |
Date: |
Mon, 15 May 2006 20:24:36 +0100 |
Dimitris Papavasiliou writes:
> I needed to perform a 2D DCT for image processing and since speed wasn't
> such an absolutely critical issue (although welcome of course) I thought
> I'd implement it using GSL instead of FFTW. In the spirit of unifying
> all our numerical needs (which the GSL seems to be serving well enough)
> under a common interface I thought I'd implement this as a GSL package
> as well which might later be incorporated into GSL itself.
>
> Until now I have basically only radix2 DCTs (type II and inverse which
> is essentially type III) implemented for one and two dimensions. I also
> created a couple of wrappers for the FFT functions that work with
> vectors and matrices.
Hello,
Thanks for your message.
The Mixed radix FFTs in GSL are a reimplementation of FFTPACK. The DCT
and DST from FFTPACK were not implemented though due to lack of
resources. From my point of view, that would be the first priority to
add to the existing ffts.
> b) Is there a reason why there are no vector/matrix interfaces to the
> fft functions (in constrast to the wavelets routines)?
The normal GSL convention is that we don't duplicate array and vector
functions as the vector functions are just a wrapper with v->data,
v->stride, v->size arguments. Some functions do have these, but it's
historical. A vector wrapper could be useful if people want that, but
I'd like to keep it out of gsl itself as it means there are twice as
many functions to maintain and test.
> c) Is there a reason why there are no two-dimensional fft routines? For
> real data there would be the problem of computing them in-place I
> suppose but for complex data computation is pretty simple using
> row-column decomposition.
At the time I wrote the FFTs I was looking for a good multidimensional
solution.
I did not find anything that was substantially better than the user
calling the FFT on the rows and columns themselves, so I did not
implement anything.
--
Brian Gough