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

[Williams, Norman K]

There is no good solution to this problem. The ITK Metadata mechanism
would be a great solution if the ITK pipeline mechanism consisitently
propogated metadata down the pipeline.  There are challenges to how to do
that -- in the case of filters with more than one input, what metadata
gets propogated?


In the past the only solution seemed to be to explicitly save and
propogate this information.

On 8/22/11 10:32 AM, "Cory Quammen" <cquammen at cs.unc.edu> wrote:

>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
>_______________________________________________
>Powered by www.kitware.com
>
>Visit other Kitware open-source projects at
>http://www.kitware.com/opensource/opensource.html
>
>Kitware offers ITK Training Courses, for more information visit:
>http://kitware.com/products/protraining.html
>
>Please keep messages on-topic and check the ITK FAQ at:
>http://www.itk.org/Wiki/ITK_FAQ
>
>Follow this link to subscribe/unsubscribe:
>http://www.itk.org/mailman/listinfo/insight-developers



________________________________
Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
________________________________