[Insight-users] 3 questions (FFT filters)
Luis Ibanez
luis.ibanez at kitware.com
Sun Sep 17 14:56:49 EDT 2006
Hi Jakub,
1) Unfortunately there is no notion of priorities in the Factories.
Simply the first factory to respond will be the chosen one.
In practice you could have a default factory (e.g. VXL FFT), that
can be overridden by a user-defined factory (e.g. FFTW).
2) The trick
::itk::GetImageDimension<TInputImage>::ImageDimension
is needed if you are declaring the image in the class declaration
of the filter and if you are using VisualStudio 6.0.
Visual Studio has a deficiency in the order in which it evaluates
the integers from templates during the compilation passes. As a
result, it tends to define the image dimension as zero, when the
simple expression is used.
In order to support multiple platforms we are forced to use the
complex expression, but... in your case, if the simple expression
does the trick, then that is just fine.
Regards,
Luis
===================
Jakub Bican wrote:
>
> 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
>>>
>>>
>>
>>
>>
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
>
>
More information about the Insight-users
mailing list