[Insight-developers] General design issues

[Luis Ibanez]

Hi,


On Wed, 24 Oct 2001, Brad King wrote:
> 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.
>

Moving containers from being defined at compile time, to be defined
at run time through and base/derived/virtual mechanism could be ok
as long as we can manage to be sure that ImageIterators don't require
to use virtual function to get access to pixels.

In itk::Image, we currently can use any containter that is able to
provide a pointer to a contiguous block of memory. Our Iterators
assume this contiguity when they walk through image data. Image
data containers can be in a C++ hierarchy if they all provide a
GetBuffer() method returning a pointer to their internal memory.

In the case of the Mesh, we rely (so far) on the iterators provided
by the container. So it will be a matter of making sure that all the
 iterators of itk::Container derive from a common ContainerIterator
class. The disadvantage in this case is that every access to
mesh pixels, and cells will cost an indirection in a virtual table.

>
> 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?
>

It seems that most of the filters use the default traits.
The sensitive point are iterators, because they manage most of the
inner loops. The important type for iterators are the PixelAccessors,
which are not part of the types defined in ImageTraits.



>
> 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!
>

In the mesh we really need to use the traits, in particular for
setting the pixel type and for creating data types on the cells.

It could be interesting to implement and Adaptor mechanism similar
to what we have in itk::Image. We could eventually manage to make
a Mesh look as being of other type. Given that we can have control
over the Mesh iterators, the basic thing to add is to have CellAccessor
(analogous to PixelAccessor) in every Mesh Iterator (e.g. the
itk::Container iterators)

   // ignoring for a moment the SmartPointer notation..
  MeshAdaptor<Mesh_B>  meshAdaptor // this will look like a Mesh_B
  Mesh_A meshA;
  meshAdaptor->SetMesh( meshA );

Then, when using MeshIterators on meshAdaptor, we'll have to provide
CellAccessors, PointAccessors, PointDataAccesors and so on, that
will map the types in Mesh_A to the types in Mesh_B. There will be
a hit in performance, but this time it will only be paid by those
importing and exporting data, as opposed to regular users of the
Mesh class.


>
> 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?
>

We are using  "fltkNameClass"  for the Unsupported/Fltk directory,
and creating a "fltk" namespace for all those classes...
at the image of ITK...



Luis