ITK  5.4.0
Insight Toolkit
Classes
Module ITKQuadEdgeMesh
+ Collaboration diagram for Module ITKQuadEdgeMesh:

Classes

class  itk::QuadEdgeMeshFrontBaseIterator< TMesh, TQE >::FrontAtom
 
class  itk::GeometricalQuadEdge< TVRef, TFRef, TPrimalData, TDualData, PrimalDual >
 
class  itk::QuadEdge
 
class  itk::QuadEdgeMesh< TPixel, VDimension, TTraits >
 
class  itk::QuadEdgeMeshBaseIterator< TQuadEdge >
 
class  itk::QuadEdgeMeshBoundaryEdgesMeshFunction< TMesh >
 
class  itk::QuadEdgeMeshConstFrontIterator< TMesh, TQE >
 
class  itk::QuadEdgeMeshConstIterator< TQuadEdge >
 
class  itk::QuadEdgeMeshConstIteratorGeom< TGeometricalQuadEdge >
 
class  itk::QuadEdgeMeshEulerOperatorCreateCenterVertexFunction< TMesh, TQEType >
 
class  itk::QuadEdgeMeshEulerOperatorDeleteCenterVertexFunction< TMesh, TQEType >
 
class  itk::QuadEdgeMeshEulerOperatorFlipEdgeFunction< TMesh, TQEType >
 
class  itk::QuadEdgeMeshEulerOperatorFlipEdgeFunctionEnums
 
class  itk::QuadEdgeMeshEulerOperatorJoinFacetFunction< TMesh, TQEType >
 
class  itk::QuadEdgeMeshEulerOperatorJoinVertexFunction< TMesh, TQEType >
 
class  itk::QuadEdgeMeshEulerOperatorSplitEdgeFunction< TMesh, TQEType >
 
class  itk::QuadEdgeMeshEulerOperatorSplitFacetFunction< TMesh, TQEType >
 
class  itk::QuadEdgeMeshEulerOperatorSplitVertexFunction< TMesh, TQEType >
 
class  itk::QuadEdgeMeshExtendedTraits< TPixelType, VPointDimension, VMaxTopologicalDimension, TCoordRep, TInterpolationWeightType, TCellPixelType, TPData, TDData >
 
class  itk::QuadEdgeMeshFrontBaseIterator< TMesh, TQE >
 
class  itk::QuadEdgeMeshFrontIterator< TMesh, TQE >
 
class  itk::QuadEdgeMeshFunctionBase< TMesh, TOutput >
 
class  itk::QuadEdgeMeshIterator< TQuadEdge >
 
class  itk::QuadEdgeMeshIteratorGeom< TGeometricalQuadEdge >
 
class  itk::QuadEdgeMeshLineCell< TCellInterface >
 
class  itk::QuadEdgeMeshPoint< TCoordRep, VPointDimension, TQuadEdge >
 
class  itk::QuadEdgeMeshPolygonCell< TCellInterface >
 
class  itk::QuadEdgeMeshScalarDataVTKPolyDataWriter< TMesh >
 
class  itk::QuadEdgeMeshTopologyChecker< TMesh >
 
class  itk::QuadEdgeMeshToQuadEdgeMeshFilter< TInputMesh, TOutputMesh >
 
class  itk::QuadEdgeMeshTraits< TPixel, VPointDimension, TPData, TDData, TCoordRep, TInterpolationWeight >
 
class  itk::QuadEdgeMeshZipMeshFunction< TMesh, TQEType >
 

Detailed Description

The QuadEdgeMesh module contain a specialized set of Mesh classes intended to represent 2-manifolds embedded in a N-Dimensional space. This family of classes provides a consistent representation of oriented surfaces and therefore they are used as a base for implementing common mesh filters and operations. They are commonly used for representing the output of image segmentation algorithms.

Some QuadEdgeMesh algorithms are based on iterating various connectivity operators e.g. curvature driven surface deformation. Many of those connectivity altering operators (e.g. the Euler operators) are lightweight in the sense that they only modify very limited regions of a QuadEdgeMesh: they typically act within the range of couple edges of distance from a considered vertex, edge or face.

On the one side, those atomic operations cannot be implemented as "classical" ITK filters since each filter invocation yields a new copy of the input mesh as its output: this would drastically increase the memory consumption. In fact, those atomic operations have a too much finer grain to be implemented as filters: the filter is more at the scale of the application of a large number of such atomic operations.

One the other hand, those atomic operations cannot be implemented as methods of the itk::QuadEdgeMesh class (or a derived one) at the risk of rapid code bloat.

Making a thematic regrouping within derived classes was discarded because this would force an end user to multiple inheritance which can prove to be a drag in a templated context.

Eventually, QuadEdgeMesh algorithms were implemented as function object: the loosely coupling of those operation methods with the targeted QuadEdgeMesh object and heavier invocation syntax are a small price to pay in exchange for optimal memory usage and end user modularity.

But itk::FunctionBase could not be inherited since its itk::FunctionBase::Evaluate method promises to leave its argument (the mesh we want to modify in our case) untouched.

Hence the itk::QuadEdgeMeshFunctionBase class was created whose main difference with itk::FunctionBase is that its itk::QuadEdgeMeshFunctionBase::Evaluate method allows to modify the considered mesh.

When considering a new QuadEdgeMesh method there are four possible "slots" to implement it:

The choice of the slot is a mere matter of trade-off and in order to keep itk::QuadEdgeMesh tiny and humanly readable key decision factors can be the occurrence of the calls and the human level complexity of the code.

With those criteria in mind the following choices were made: