[Insight-developers] GradientVectorFlowImageFilter internal image type

[Gaëtan Lehmann]

Le 10 janv. 09 à 20:36, Karthik Krishnan a écrit :

>
>
> Gaëtan Lehmann wrote:
>>
>> Le 10 janv. 09 à 16:20, Karthik Krishnan a écrit :
>>
>>> Gaëtan Lehmann wrote:
>>>> template <class TInputImage, class TOutputImage, class  
>>>> TInternalPixel=double>
>>>> class ITK_EXPORT GradientVectorFlowImageFilter : public  
>>>> ImageToImageFilter<TInputImage, TOutputImage>
>>>>
>>>> There shouldn't be any backward compatibility issue that way. I  
>>>> don't know well that class though, so I have an important question:
>>>> Does that change look reasonable? I mean, is it relevant to use a  
>>>> different internal pixel type than double - float for example?
>>> I don't think it makes sense to use the class with any internal  
>>> pixel type other than float or double. Actually, the input images  
>>> (and output images) supplied should also be float/double. The  
>>> filter internally computes the laplacian image using the internal  
>>> pixel type. Double precision is also needed to account for the  
>>> diffusion of the gradient vectors.
>>>
>>> I would just wrap the class for double and float alone.
>>
>> My problem comes from this method:
>>
>>    itkSetMacro(LaplacianFilter, LaplacianFilterPointer);
>>
>> The LaplacianFilter currently uses double as pixel type, whatever  
>> are the input or the output image types, so that method expose a  
>> filter type which is not available most of the time, because the  
>> default real type wrapped in wrapitk is float. The result is a  
>> warning at build time and an unusable SetLaplacianFilter() in the  
>> target languages. Changing the internal pixel type (used in the  
>> laplacian filter type) to the one used in the input and the output  
>> image would avoid the problem with the SetLaplacianFilter() method.
>> An easy way to fix the problem, but if it produce wrong result  
>> because the double precision is required for the internal image  
>> type, that's also a wrong way to fix that problem.
>>
>> With that fix, I would wrap the types
>>
>>  itk::GradientVectorFlowImageFilter< itk::Image<float, 2>,  
>> itk::Image<float, 2>, float >
>>  itk::GradientVectorFlowImageFilter< itk::Image<float, 3>,  
>> itk::Image<float, 3>, float >
>>
>> by default, and/or
>>
>>  itk::GradientVectorFlowImageFilter< itk::Image<double, 2>,  
>> itk::Image<double, 2>, double >
>>  itk::GradientVectorFlowImageFilter< itk::Image<double, 3>,  
>> itk::Image<double, 3>, double >
>>
>> if the user has chosen to wrap double.
>> But does it make sense to have itk::Image<float, 2> used for the  
>> laplacian, when input and output image are itk::Image<float, 2>?
> Sure. It makes sense to wrap the following 4 combinations alone.
>
> itk::GradientVectorFlowImageFilter< itk::Image<float, 2>,  
> itk::Image<float, 2>, float >
> itk::GradientVectorFlowImageFilter< itk::Image<float, 3>,  
> itk::Image<float, 3>, float >
> itk::GradientVectorFlowImageFilter< itk::Image<double, 2>,  
> itk::Image<double, 2>, double >
> itk::GradientVectorFlowImageFilter< itk::Image<double, 3>,  
> itk::Image<double, 3>, double >
>

Thanks Karthik.
I'll go that way

Gaëtan

>
> Thanks
> --
> karthik
>
>>
>>>
>>>
>>> thx
>>> -- 
>>> karthik
>>>>
>>>> Regards,
>>>>
>>>> Gaëtan
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Insight-developers mailing list
>>>> Insight-developers at itk.org
>>>> http://www.itk.org/mailman/listinfo/insight-developers
>>>>
>>>
>>> -- 
>>> Karthik Krishnan
>>> R & D Engineer,
>>> Kitware Inc,
>>> Ph:  518 371 3971 x119
>>> Fax: 518 371 3971
>>>
>>
>
> -- 
> Karthik Krishnan
> R & D Engineer,
> Kitware Inc,
> Ph:  518 371 3971 x119
> Fax: 518 371 3971
>

-- 
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://voxel.jouy.inra.fr  http://www.mandriva.org
http://www.itk.org  http://www.clavier-dvorak.org

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