[Insight-developers] General design issues

[Brad King]

Hello, all:

Today I implemented a new class called "VTKImageImport" to allow the end
of a VTK pipeline to be connected to an ITK pipeline.  This complements
VTKImageExport which I wrote previously to connect the pipelines in the
opposite direction.  I used ImportImageFilter as a reference for the new
class.  However, when I first tried to connect an ITK pipeline beginning
with an import class, I got a compiler error since

itk::Image<float, 2, DefaultImageTraits<float, 2,
                       ValarrayImageContainer<unsigned long, float> > >

and

itk::Image<float, 2, DefaultImageTraits<float, 2,
                       ImportImageContainer<unsigned long, float> > >

are different image types.  This reveals a general problem in that two
images of the same pixel type and dimension cannot be interchanged if they
have different image traits, and in this case if they simply use different
memory allocation schemes.  I don't think this is the behavior we want.

The current design is a result of my proposal two summers ago for the Mesh
class to have its container types provided as traits assigned through a
template argument.  In hindsight, this seems like a bad idea.  We may want
to remove this "feature" in favor of a conventional superclass/subclass
approach to pixel containers.

Is anyone making use of the compile-time assigned image/mesh traits in a
filter, or is everyone using the defaults?  Are any such traits used in an
inner loop, or would there be no performance hit if they were run time?

As a reminder, image traits consist of:

Pixel container (default = itk::ValarrayImageContainer)
Index type (default = itk::Index<dimension>)
Offset type (default = itk::Offset<dimension>)
Size type (default = itk::Size<dimension>)
Region type (default = itk::ImageRegion<dimension>)

There is an inconsistency here because ImageRegion always uses itk::Index
and itk::Size for its IndexType and SizeType, which may make an image's
region incompatible with its size and index types!  The simple fix to this
is to remove the Index and Size types from the image traits, and always
get them from the Region trait.

Mesh traits consist of:

MaxTopologicalDimension (default = PointDimension)
CoordRep, coordinate representation type (default = float)
InterpolationWeight representation type (default = float)
CellPixelType (default = PixelType)
PointIdentifier
CellIdentifier
BoundaryIdentifier
CellFeatureIdentifier
PointType
PointsContainer
UsingCellsContainer
CellTraits
Cell base type
PointCellLinksContainer
CellLinksContainer
PointDataContainer
CellDataContainer
BoundariesContainer
BoundaryDataContainer

(Most container defaults are itk::VectorContainer)
(Most identifier defaults are unsigned long)

If any one of the above traits is changed, it automatically creates a Mesh
instantiation that is a distinct type from the default Mesh type, and they
cannot be used together!

We could just hardcode identifier types as unsigned long or some other
predefined type to get rid of many of these.

A run-time selected subclass of some container superclass would avoid the
container trait problem.  I think one virtual funciton call to get a
pointer to the data in a container will be trivial in comparison to the
length of the operation on that data.

Comments and suggestions based on the above observations are invited.
-Brad

Now that I'm thinking about general design/convention issues, I realize I
should probably rename "VTKImageImport" and "VTKImageExport" to
"VTKImportImageFilter" and "VTKExportImageFilter".  I chose the original
names since they are implemented using VTK terminology (since they
interface with VTK), but the new names are consistent with ITK
terminology.  Any thoughts on a policy for naming classes designed for
specific third-party systems?