[Insight-users] FFT Class Issues: What do people think?

[Kent Williams]

I've cleaned up itk::FFTWRealToComplexConjugateImageFilter and 
itk::FFTWComplexConjugateToRealImageFilter, by using template 
specialization to hide the idiosyncracies of the FFTW API.  FFTW is a C 
library, so it has different function names and argument types for float 
and doubleFFTs.  I used template specialization on a helper class to 
provide consistent function signatures for float and double PixelTypes.  
If you try a different pixel type, you will now get a compile time 
error, as the default template is empty.

I'm in the process of addressing another problem: FFT (and other FFTs) 
that use 'Half Matrix' complex results have a problem dealing with 
inputs with the X (i.e. fastest moving dimension) -- the size of the 
output  is [((x div 2) + 1, y, z, etc].  But given itk's filter pattern, 
the IFFT can't recover the size of it's output from the size of its 
input: if the original X dimension was, for example, 2, the size of the 
complex result is 2.  If the original X dimension was 3, the size of the 
complex result is also 3.

The current implementation puts the original X dimension as metadata 
into the output image of the FFT. This works great as far as I know -- 
filters in general do pass along metadata down the pipeline.  But if you 
save the result of an FFT (an image of complex pixels) to a file, you 
may not get the metadata back.

So there are two ways to solve the problem.

1. Make it an error to process images where the X dimension is odd.
2. Add a function that allows you to set the original X dimension on the 
IFFT (i.e. itk::FFTComplexConjugateToRealImageFilter) before running the 
pipeline.

Solution 1 has the attraction of making it impossible to write a program 
that uses the filters incorrectly -- if you have an image with an 
odd-numbered X dimension, you can't run the filter.  All common image 
processing applications deal mostly with images that have an even X 
Dimension.

Solution 2 allows both even and odd X Dimensions in the IFFT output, but 
if your images' X Dimension are odd, and you forget to set the original 
X Dimension, then you may lose.  In other words, you _can_ use the 
filter incorrectly.

What do you-all think?  I've tentatively added a new method called 
SetActualXDimension to itk::FFTWComplexConjugateToRealImageFilter, but I 
don't know whether this is better than another method of preserving 
original image size.