File: itk-module.cmake

package info (click to toggle)
insighttoolkit5 5.4.3-5
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid, trixie
  • size: 704,384 kB
  • sloc: cpp: 783,592; ansic: 628,724; xml: 44,704; fortran: 34,250; python: 22,874; sh: 4,078; pascal: 2,636; lisp: 2,158; makefile: 464; yacc: 328; asm: 205; perl: 203; lex: 146; tcl: 132; javascript: 98; csh: 81
file content (84 lines) | stat: -rw-r--r-- 3,849 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
set(DOCUMENTATION
    "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 itk::QuadEdgeMesh class.
  - A derived class from itk::FunctionBase when the method leaves the mesh
  constant.
  - A derived class from itk::QuadEdgeMeshFunctionBase when the method modifies the
  mesh (typically in the case of Euler operators).
  - As a classic ITKMesh filter.

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:
  - Really atomic, lightweight and general purpose methods like
  itk::QuadEdgeMesh::ComputeNumberOfPoints are left within the
  itk::QuadEdgeMesh mesh class.
  - Heavier methods and less often called like
  itk::QuadEdgeMeshBoundaryEdgesMeshFunction were implemented as derived
  classes of itk::FunctionBase.
  - Methods with the same weight (measured e.g. in number of lines of code) but
  that modify the considered mesh, like itk::BoundaryEdgesMeshFunction, were
  implemented as derived classes of itk::MeshFunctionBase. Still the mesh
  modifications are really limited and concern a couple edges.
  - More specialized methods, with a wider scope and that require a
  copy of the mesh should follow the classical ITK filter pattern and inherit
  from itk::MeshToMeshFilter.")

itk_module(
  ITKQuadEdgeMesh
  ENABLE_SHARED
  PRIVATE_DEPENDS
  ITKMesh
  COMPILE_DEPENDS
  ITKCommon
  TEST_DEPENDS
  ITKTestKernel
  ITKMesh
  DESCRIPTION
  "${DOCUMENTATION}")