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

[Gaëtan Lehmann]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: Ceci est une signature ?lectronique PGP
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110826/ffb62880/attachment.pgp>