[Insight-developers] Consistency in the output of forward/inverse FFT image filters

[Cory Quammen]

2011/8/22 Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr>:
>
> Le 19 août 11 à 18:00, Cory Quammen a écrit :
>
>> Gaetan,
>>
>> Do you have any ideas for neat tricks to figure out what the full
>> dimension of the transformed image should be given the half image? The
>> problem is that an image with size n (n even) yields a half image that
>> is the same size as the half image produced for an image with size
>> n+1.
>>
>> Currently, the FFT filters have a flag ActualXDimensionIsOdd that is
>> used to resolve this ambiguity. It would be fantastic if users didn't
>> have to set this to get the correct behavior. I haven't yet thought of
>> a way to figure out the full image size automatically, and Googling
>> hasn't revealed anything.
>
> The fft filters are setting a metadata value in the produced image to
> indicate its real size IIRC.
> Unfortunately, the metadata are not passed through the pipeline, so it can't
> be reused if there is a filter between the forward and the backward fft
> filters.
> That would be something nice to have in that case, but that's not always the
> case, so the metadata are simply not passed through the pipeline.

I think the metadata mechanism is the "old" style of handing this as
there is a comment that it is there for backwards compatibility. You
are right, this won't work because the metadata doesn't get passed
down the pipeline.

> Another option is to make the fft filter produce a second output for the
> ActualXDimensionIsOdd value. That output could be reused by the inverse fft
> filter.

Unfortunately, this won't work for the case where the frequency image
is read from a file. Another option I had in mind was for the
half-to-full complex image filter to traverse the pipeline to find a
forward FFT filter that produced the half image. The filter could then
get the original size from the forward FFT filter's input. It's not
too hard to think of cases where this wouldn't work, however, namely,
when reading a half image from a file. It's also kind of an ugly
hack...

> In all the cases, it would lead to some difficulties in the pipeline
> management, because this value must be known before the actuation of the
> pipeline to compute the size of the output image.

Agreed. I think I have a way to examine the half image to determine if
the input is even or odd in the X dimension, but doing so requires the
input to be updated prior to setting the output size information, so
it doesn't neatly fit in with ITK's pipeline architecture.

Maybe the answer is to require a second reference input from which the
size of the output image can be determined. For example,

FilterA::Pointer filterA = FilterA::New();
ForwardFFT::Pointer fft = ForwardFFT::New();
fft->SetInput( filterA->GetOutput() );
... do some processing on the frequency image
InverseFFT::Pointer ifft = InverseFFT::New();
ifft->SetInput( ...->GetOutput() );
ifft->SetSizeReferenceInput( filterA->GetOutput() )

Again, this doesn't work if you are reading the frequency image from a file...

Cory

>> Thanks,
>> Cory
>>
>> On Fri, Aug 19, 2011 at 11:10 AM, Cory Quammen <cquammen at cs.unc.edu>
>> wrote:
>>>
>>> [snip]
>>>>>
>>>>> That's a good suggestion that would simplify things. Are you proposing
>>>>> to make the VNL FFT filter always produce a half output image for real
>>>>> inputs?
>>>>
>>>> That's what I'm proposing.
>>>> It may have a cost for vnl filters, but hopefully it will be compensated
>>>> by
>>>> the lower amount of memory required for further transformations in the
>>>> frequency domain.
>>>
>>> Okay, sounds good to me. I'll get to work on implementing this.
>>>
>>> Cory
>>>
>>> --
>>> Cory Quammen
>>> Research Associate
>>> Department of Computer Science
>>> The University of North Carolina at Chapel Hill
>>>
>>
>>
>>
>> --
>> Cory Quammen
>> Research Associate
>> Department of Computer Science
>> The University of North Carolina at Chapel Hill
>
> --
> Gaëtan Lehmann
> Biologie du Développement et de la Reproduction
> INRA de Jouy-en-Josas (France)
> tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
> http://mima2.jouy.inra.fr  http://www.itk.org
> http://www.bepo.fr
>
>



-- 
Cory Quammen
Research Associate
Department of Computer Science
The University of North Carolina at Chapel Hill