[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