[Insight-developers] transform internal types

[M.Staring at lumc.nl]

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