[Insight-developers] Wrapping and hardcoded "float" and "doub
le" here and there.
Lorensen, William E (CRD)
lorensen@crd.ge.com
Tue, 8 Jan 2002 13:53:40 -0500
On a related wrapping note, with the recent CmakeListsTcl.txt, cable ends up generating VERY large
file names. cmakesetup0 is saying that it cannot create the files. I suspect the error is do to the
lengthy names. The files in trouble are the PointSet registration classes.
Bill
-----Original Message-----
From: Luis Ibanez [mailto:ibanez@choroid.cs.unc.edu]
Sent: Tuesday, January 08, 2002 11:20 AM
To: insight-Developers
Subject: [Insight-developers] Wrapping and hardcoded "float" and
"double" here and there.
Hi,
The Tcl wrapping is exposing a number of interesting inconsistencies
on the toolkit. In particular it seems that we have a number of
scattered hard oded types for coordinate representation here and
there.
For example,
1) itk::Mesh assumes by default that points are "float"
2) itk::ImageFunction assumes points to be "double"
3) itk::Transforms assume points to be "double"
This is pretty visible in the registration framework because a large
number or these classes are used together. So far the registration
examples were defining in detail the types of the classes involved but if
we try to set up a registration method using the defaults of the classes
the conflicting assumptions become visible.
For example, in the wrapping a "Mesh" is defined simply with
Mesh<float> taking default types for all the other template parameters.
An image is declared as Image<float,2>. Then, a declaration of
a registration method like:
itk::PointSetToImage....<$Image,$Mesh>
results in mixed types "double" and "float" because the interpolator
(deriving from Functions) assumes "double" points. Transfoms also
assume "double" points and the points provided by the Mesh are "float".
--
Possible solutions:
1) Agree in a basic type for itk::Point to be used by default
everywhere in the toolkit: (a) float (b) double
2) Add a couple of extra template parameters for those classes
that assume default types. Note that this defaults are not
only the ones that we provide in the template parameters in
case the user don't select anything, this defaults involve
also hardcoded "float" and "double" types that the user simply
cannot change even if he wants to.
3) Ignore the problem and work around by tailoring specific
types for the registration classes to be wrapped. At least
that will allow to wrap the classes and test for compilation
errors and for coverage.
Any votes ?
Thanks
Luis
_______________________________________________
Insight-developers mailing list
Insight-developers@public.kitware.com
http://public.kitware.com/mailman/listinfo/insight-developers