#42 closed defect (fixed)
No direct 'c2r' IFFT functionality.
| Reported by: | Owned by: | eugene | |
|---|---|---|---|
| Priority: | high | Milestone: | |
| Component: | PSLib SDRS | Version: | unspecified |
| Severity: | normal | Keywords: | |
| Cc: |
Description
I noticed that the latest FFT API defines a complex->complex IFFT operation but
no complex->real IFFT operation. En lieu of that, however, there is a function
to extract the real portion from the complex result to effectively duplicate the
complex->real IFFT functionality of FFTW.
The problem is that that is most likely going to be more costly than the
straight 'c2r' FFTW function call as the complex component will be calculated
just to be thrown away. For a 512x512 image on the 2GHz Opteron, the c->c is
about 50% more costly than the c->r FFTW function call (from fftw.org).
Is there a real desire to operate on complex imagery in the spacial domain?
Should the IFFT direction just result in a psF32 image instead or should a
second function that performs a c->r IFFT be added?
-rdd

Yeah, you're right --- since our complex image will be generally be produced
from the FFT of a real image, we probably want to go back to a real image.
Perhaps we might make "int dir" in ps{Image,Vector}FFT into a menu:
+1: go forwards
+2: go forwards from a purely real image (this can probably be discerned by the
function from the psElemType)
-1: go backwards
-2: go backwards to a purely real image (i.e. c2r)