[Insight-developers] FFT Filter Question Again -- Overwriting input image?

[Kent Williams]

On Mon, 2003-11-17 at 11:39, Miller, James V (Research) wrote:

> 2. You can do something similar to ShiftScaleInPlaceImageFilter. This filter
> uses its input storage as its output storage, overwriting its input data
> with its output data. The key here is that is does it in a manner that is
> "pipeline safe".  Essentially, it passes the ownership of the input bulk
> data container to the output data object and informs the pipeline that its
> input has been "released".  

The one problem I see with this approach is that InPlaceImageFilter
requires the input and output image types to be the same.  The input of
of the FFTComplexConjugateToRealImageFilter has a pixel type of
std::complex<TPixel> and the output has a pixel type of TPixel.  TPixel
can be float or double.

Unless there's a way to do this that I'm missing, I would have an new
subclass of ImageToImageFilter, that would allow for different input and
output array sizes and pixel types and enforce the input and output
having the same in-core memory size.  All of the other pipeline
bookkeeping would be the same.

Another challenge is that  a Real to Complex tranform of N real numbers
has a result of 2/N + 1 complex numbers. This means that this size, N,
isn't recoverable from the image size of output image.  So I use the
MetadataDictionary to pass forward the real size of the input image as
part of the output image.

That confuses ME and I wrote it, so here's a concrete example:  The FFT
of an array of length 4 produces an output of length 3 (4 div 2 + 1),
but an array of length 5 also produces an output of length 3.  So in the
Complex-to-Real Inverse transform, the output size isn't known exactly,
unless it's carried along with the result of the FFT.

Perhaps another pattern needs to be applied to the FFT operation --
something similar to a UnaryFunctorImageFilter.  In that case, the
input, and output would be the input to the FFT, and the output would be
the result of the Inverse FFT. You'd pass in a function to operate on
the FFT results, but the input and output would be normal images, and
only the passed-in function would deal with the image in the frequency
domain.

The complication here is that the UnaryFunctorImageFilter works on a
pixel-by-pixel basis; the preferable case for FFT functor to work on the
whole image, since many operations -- e.g. frequency shifting -- need
global access to the image rather than individual pixels.