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

[Cory Quammen]

Gaetan and Kent,

I haven't come up with a better solution than what is there, so I'll
modify the VNL filter to produce the half output for real inputs
without touching the current API.

Maybe someday it would be nice to add a second input whose largest
possible region is used to determine the expected output size of the
inverse transform. That approach should play better with the pipeline.
I'll leave that for another patch, though.

Cory

2011/8/26 Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr>:
>
> Le 22 août 11 à 17:32, Cory Quammen a écrit :
>
>> 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...
>
> Hi Cory,
>
> This is certainly the best API I've seen for those filters.
> The option ActualXDimensionIsOdd can still be used when reading from a file.
>
> Gaëtan
>
>
>>
>> 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
>
> --
> 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