[Insight-developers] General design issues

[Miller, James V (CRD)]

Brad,

We have hit upon "images with different containers" being different types before. I was able to
address the problem earlier by judicious casting to the ImageBase base class. Don't know if that
helps your case or not.

This is one of the things that I dislike about templates.  From the user perspective, there is no
difference in the two images types specified below. (On a side note, I am not sure whether we need
both types of image pixel containers.  I think the neighborhoods are the only places that make use of
any valarray concepts.)  Anyhow, as currently specified, the two image types below are distinct types
which causes problems when you try to assign a pointer to one to a pointer to the other, etc.

Since we rely heavily on the "types" of data objects, I would be in favor of reducing the number of
template parameters used in subclasses of DataObject. While I am not sure we have the same problem
with subclasses of ProcessObject, I think it is a good thing to try to reduce the number of template
parameters. We are currently struggling with ProcessObjects as to whether the user should have to
specify an output type, should the user be able to specify an internal precision used for
calculations, etc.




-----Original Message-----
From: Brad King [mailto:brad.king@kitware.com]
Sent: Wednesday, October 24, 2001 11:10 PM
To: Insight Developers
Subject: [Insight-developers] General design issues


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?

_______________________________________________
Insight-developers mailing list
Insight-developers@public.kitware.com
http://public.kitware.com/mailman/listinfo/insight-developers