[Insight-users] 3 questions (FFT filters)

[Luis Ibanez]

Hi Jakub,

1) Here are two options:

    1.1) Use only VNL: Since the known bugs in the vnl FFT
         have been fixed, you could simply rely on the VNL
         implementation that is distributed along with ITK.

    1.2) Use a Factory for bringing up VNL  or FFTW at run
         time. This is probably a more elegant option but
         also a bit more involved. You will find instructions
         on how to create Factories in the following tutorial:

   http://www.na-mic.org/Wiki/images/2/24/Insight-DesignPatterns.ppt

   The source code examples for that Tutorial can be found at:

   http://www.na-mic.org/Wiki/index.php/Image:ITKCourseExercises.zip


         With the factory mechanism you simpy define a common
         API for both the VNL and FFTW (or other) implementations
         and delegate the the last minute at run time the decision
         on which implementation to use.  The user simply have to
         register the appropriate factory with the FactoryBase.


2) You can easily overcome this problem by using Traits.
    You could simply use the RealType pixel trait defined
    in itkNumericTraits.h


     Like:

       typedef typename TInputImage::PixelType  InputPixelType;

       typedef itk::NumericTraits<InputPixelType>::RealType
                                          InternalFFTPixelType;


     For PixelTypes less than float, the RealType is float,
     while for float and double images it is Double.
     If that type distribution is not the want that you find
     appropriate, then you could define your own local traits.
     Something like FFTRealTypeTraits<>.


     Note that for "Dimension" you need a trick for getting
     the dimension out of the Input image.


     /** Image dimension. */
     itkStaticConstMacro(ImageDimension, unsigned int,
     ::itk::GetImageDimension<TInputImage>::ImageDimension );

     Finally you have the two elements needed for instantiating
     the image template:


     typedef itk::Image<
                   InternalFFTPixelType,
                   itkGetStaticConstMacro(ImageDimension) >
                                         InternalFFTImageType;





3) It is safer to use the trait that the image itself offers
    for the Origin:

        typename TInputImage::PointType  origin;
        movingImage->SetOrigin( origin );


    Note that you should *NOT* do this if the movingImage is
    the output of another filter. In such case you should
    rather us the ChangeInformationImageFilter.




   Regards,



      Luis




====================
Jakub Bican wrote:
> 
> Hello,
> 
> i am writing a new filter and i am facing following problems. The first 
> two problems are rather philosophic, while the last one is a compilation 
> error.
> 
> Thanks very much for the answers and advices,
>            Jakub
> 
> 
> 1) choosing class for FFT
> My filter is a mini-pipeline filter, that needs to perform FFT and IFFT 
> at several points of computation. As far as i know, there are two 
> possibilities for making FFT and IFFT - use fftw or vnl.
> 
> I want to write the filter as general as possible, so i don't want it to 
> be dependent on any of these exchangeable(?) possibilities. I consider 
> these options:
>    a) use constantly only fftw OR vnl (but which one of these should be 
> preffered in this case? and what of fftw is not available?)
>    b) choose the one, which is available during compilation ( I am not 
> sure how is this manageable now - if something like #ifdef USE_FFTW... 
> can be used, and which possiblity should be preffered if both are 
> available. )
>    c) let the user specify the possibility (e.g. filter->UseFFTWOn() ?)
>    b) let the user pass in the filter (e.g. 
> filter->SetRealToComplexConjugateFilter(...)) - this is very unhandy, as 
> the filter uses several instances of FFT and IFFT filters
> 
> 2) Instantiating FFT filter templates
> My filter is templated over input image type, but internally, i need to 
> compute FFT in floating point - float should be enough for my 
> computations. So there will be cast filter at the begginning of the 
> mini-pipeline, that will cast arbitrary input data type to my internal 
> floating point type - float.
> 
> But what if user passes in a double data? Than there is a risk while 
> casting data to float...
> 
> But if i use internally double, then i will be wasting resources for all 
> "smaller" data types.
> 
> Again, if there will be a template parameter that will determine this, 
> then the user will have to set something, that is internal for the filter.
> 
> 3) impossible to pass origin into image
> I need to manually set an origin of an image:
>  double origin[ Dimension ];
>  for (unsigned int i = 0; i < Dimension; i++)
>    {
>    origin[i] = 0.0;
>    }
>  movingImage->SetOrigin(origin);
> 
> during compilation, i get following error:
> test.cxx(109): error C2663: 'itk::ImageBase<VImageDimension>::SetOrigin' 
> : 3 overloads have no legal conversion for 'this' pointer
>        with
>        [
>            VImageDimension=2
>        ]
> 
> I am compiling on WinXP+MSVS.NET (2003)
> 
> 
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
> 
>