[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