[Insight-users] Cordinate representation in transforms and meshes

[Tomáš Kazmar]

Hi all,

  recently I found somtheing that seems to me as an inconsistency in
representing coordinates in ITK. If you create a mesh the default type
for coodrinate representation is float. On the other hand in transforms
a double is used. Can anyone explain why it is so? Was it a design
decision? Because sometimes it causes troubles and inefficiency.

Here follows my understanding of the problem:

The inconsistency would be acceptable if you were to decide what
representation to use. But in some transforms doubles are "hardwired"
(every transform that is used with a metric derived from CostFunction)
and you are forced to use doubles.

You can see what I mean if you try to change CoordinateRepType
from double to float at line 119 of
Examples/Registration/DeformableRegistration4.cxx
With double all is ok, with float you get an error from
ResampleImageFilter and ImageRegistrationMethod. The first is easily
resolved but not the latter:

DeformableRegistration4.cxx:164: error: no matching function for call to 'itk::ImageRegistrationMethod<itk::Image<float, 2u>, itk::Image<float, 2u> >::SetTransform(itk::SmartPointer<itk::BSplineDeformableTransform<float, 2u, 3u> >&)'
/home/baf/tks/itk-src-cvs/Insight/Code/Algorithms/itkImageRegistrationMethod.h:142: note: candidates are: void itk::ImageRegistrationMethod<TFixedImage, TMovingImage>::SetTransform(typename itk::ImageToImageMetric<TFixedImage, TMovingImage>::TransformType*) [with TFixedImage = itk::Image<float, 2u>, TMovingImage = itk::Image<float, 2u>]

Problem is in definition of RegistrationType::TransformType which
is taken from MetricType where it is created as
Transform<CoordinateRepresentationType,...> which in turn is
set to be a double as ParametersValueType in CostFunction. From
the users point of view it is not possible to change it. So when you
want to use a registration method it forces you to use doubles as
coordinate representation in your TransformType and efectively
anywhere else unless you want to convert points back and forth
between itk::Point<double, ...> and itk::Point<float, ...>.

Last month there was also a thread that was in fact about this
inconsistency:
http://public.kitware.com/pipermail/insight-users/2007-September/023515.html

Maybe I have overlooked something and this has some solution,
I would definetely like to hear that:)


Regards,
Tomas