[Insight-users] 3 questions (FFT filters)

[Jakub Bican]

Thanks Luis,

1) now, i fixed the code a little bit to the FFTW, but this is just a 
intermediate state during development.

I like the idea with factories and i will focus on that.

But there always must be something in the factory, that decides which 
filter to create, if both are available...


2) Perfect - the NumericTraits<>::RealType is the solution!

side question - why it is necessary to use the trick

itkStaticConstMacro(ImageDimension, unsigned int,
      ::itk::GetImageDimension<TInputImage>::ImageDimension );

instead of using

itkStaticConstMacro(ImageDimension, unsigned int,
      ImageType::ImageDimension);

?? (i am using the second option and it works)

3) This is used just in the test - i was not looking for the safest way;)

Thanks again,

	Jakub




Luis Ibanez napsal(a):
> 
> 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
>>
>>
> 
> 
>