[Insight-developers] transform internal types

M.Staring at lumc.nl M.Staring at lumc.nl
Thu May 6 04:14:02 EDT 2010


Hi Stefan, 

> 
> Hi Marius,
> 
> If you want to make the parametersValueType a template 
> parameter, 

No, I don't want to do that. Instead, I propose to move the
ParametersValueType typedef from TransformBase to Transform and change
it to TScalarType.

Then
	Transform< double, indim, outdim >
is identical to the previous definition.

However, backward compatibility problems occur:
1) Transform< float,  indim, outdim > is changed wrt the ParametersType
2) there is no ParametersType typedef in TransformBase anymore, so code
that uses TransformBase::ParametersType does not work anymore.

One way I can see to change this in a backward compatible way is:

#ifdef ITK_USE_TRANSFORM_SCALARTYPE_FOR_PARAMETERSTYPE
  typedef  ScalarType     ParametersValueType;
#else
  typedef  double         ParametersValueType;
#endif

where ITK_USE_TRANSFORM_SCALARTYPE_FOR_PARAMETERSTYPE defaults to false.

But that introduces yet another cmake option. (which we could get rid of
in ITK 4.0)

In other words, I have two questions:
1) Do people agree that this is a desirable change ?
2) I'm not sure how to change this in a backward compatible way. Maybe
someone on the list does ?

With kind regards,

Marius

> then that also has consequences for the 
> ImageToImageMetric->GetValue/GetDerivative functions, (so the
> ImageToImageMetric should also become templated over the 
> ParametersValueType), and the Optimizers. I don't think 
> that's desirable.
> 
> Kind regards,
> Stefan
> 
> On 4-5-2010 16:43, M.Staring at lumc.nl wrote:
> > Hi all,
> >
> > I have a question about the internal floating types that 
> are used in 
> > the itk::TransformBase and the itk::Transform classes.
> >
> > Currently, the TransformBase contains the typedef:
> >
> >    typedef  double  ParametersValueType;
> >
> > and the Transform:
> >
> >    typedef  Array2D<  double>   JacobianType;
> >
> > So, the ParametersType and the JacobianType are hard-coded to be 
> > doubles.
> >
> > For my application I like them to be floats.
> >
> > It seems intuitive to use the first template parameter of the 
> > Transform class for this. This template parameter namely is a 
> > PrecisionType / ScalarType. This PrecisionType then defines 
> the type 
> > of for example the input and output points, the rotation matrix for 
> > the affine transform, and the B-spline weights function type of the 
> > B-spline transform. So, in the end it determines the 
> precision of the 
> > output, regardless of the ParametersType being doubles.
> >
> > For example:
> > - The SetParameters() function in the 
> MatrixOffsetTransformBase copies 
> > the parameters to m_Matrix, which is defined as
> >    typedef Matrix<TScalarType, OutputSpaceDimension, 
> > InputSpaceDimension> MatrixType; so, defined as a float matrix if I 
> > choose TScalarType = float. The added precision of the parameters 
> > being double is immediately thrown away.
> >
> > Of course, using a double type can sometimes add some precision for 
> > intermediate computations. However, it would be nice to be 
> able to use 
> > floats if for a specific application float precision is all what is 
> > needed. But mainly, I would like to pass the parameters to the GPU, 
> > and not all GPUs support double precision.
> >
> >
> >
> > Is there a reason that ParametersValueType and JacobianType are 
> > hard-coded to be doubles ?
> >
> > -------------------------
> >
> > A solution to fix this would be to move the ParametersValueType 
> > typedef from the TransformBase to the Transform and change it to:
> >
> >    typedef  TScalarType  ParametersValueType;
> >
> > And also change
> >    typedef  Array2D<  TScalarType>   JacobianType;
> >
> > But I guess that would break backwards compatibility. A solution to 
> > that could be the use of a cmake variable and some #ifdefs.
> >
> > Does anyone see objections to these changes, or can you recommend a 
> > better fix?
> >
> > Regards,
> >
> > Marius Staring
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at 
> > http://www.kitware.com/opensource/opensource.html
> >
> > Kitware offers ITK Training Courses, for more information visit:
> > http://kitware.com/products/protraining.html
> >
> > Please keep messages on-topic and check the ITK FAQ at:
> > http://www.itk.org/Wiki/ITK_FAQ
> >
> > Follow this link to subscribe/unsubscribe:
> > http://www.itk.org/mailman/listinfo/insight-developers
> >    
> _______________________________________________
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
> 
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.html
> 
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-developers
> 


More information about the Insight-developers mailing list