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

[Miller, James V (Research)]

Kent, 
 

Here are a few options:

1. As you said, you can copy the input to a temporary storage that the FFT
routines are munge as they calculate the given FFT.

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".  If there was another consumer of the input to
the ShiftScaleInPlaceImageFilter, the pipeline mechanism would force the
preceding filter to re-execute to regenerate its output.  All of the
pipeline management in this case in done in itkInPlaceImageFilter.  There
are two routines provided AllocateOutputs() and ReleaseInputs().  The
AllocateOutputs() routine in this case transfers the ownership of the input
data to the output data object.  You will NOT need to this with the FFT.
The ReleaseInputs() calls the superclass' method (which checks whether the
user wanted the inputs to be released) and the forces input 0 to be released
(since it was passed to the output).  So if you provide an implementation of
ReleaseInputs() in your FFT class that does the same thing as
InPlaceImageFilter::ReleaseInputs() then you can have the FFT routines munge
the input buffer yet operate safely in the pipeline mechanism.

Jim

-----Original Message-----
From: Kent Williams [mailto:norman-k-williams at uiowa . edu]
Sent: Monday, November 17, 2003 12:17 PM
To: insight-developers at itk . org
Subject: [Insight-developers] FFT Filter Question Again -- Overwriting
input image?


In some exchanges with the FFTW developers, they've indicated something
that I hadn't fully realized: If you do an Inverse Complex to Real FFT,
FFTW wants to use its input as scratch space, thereby destroying the
input image. I'm not sure, but I suspect a lot of FFT implementations do
the same thing.

But it seems like the standard behavior in an ITK pipeline is to leave a
filter's inputs intact; ImageToImage filter returns const InputImageType
from it's GetInput method.

So here's my question: Should I modify the filter to copy the input to a
scratch array, and work on that?  Or is it sufficient to document that
the filter scrambles it's input image?

This seems like a place where the ITK pipeline pattern is at odds with
the normal way of working with FFTs.  Most of the applications do the
forward and reverse transforms in place, meaning the forward transform
replaces its input with its complex result, and the inverse transform
overwrites it's complex input with the real results.



_______________________________________________
Insight-developers mailing list
Insight-developers at itk . org
http://www . itk . org/mailman/listinfo/insight-developers