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

[Gaëtan Lehmann]

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.

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.

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.

Gaëtan


>
> 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

-------------- 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/20110822/8c5ff950/attachment.pgp>