Commit 265770f2 authored by Christophe Palmann's avatar Christophe Palmann

ENH: doxygen, added missing files (2)

parent 048d09fb
/**
*
* \mainpage Monteverdi 2
*
* <div align="center"><img src="logoVectoriel.png" alt="logoVectoriel.png"></div>
*
* \section intro Introduction
*
* Welcome to CNES' Monteverdi 2, an open-source software for image visualization
* and manipulation. It is built on top of Orfeo ToolBox and OTB-Ice libraries.
*
* \section homepage Home Page
*
* The Home Page of the project can be found at:
*
* http://www.orfeo-toolbox.org
*
* \section howto How to use this documentation
*
* This documentation describes the API of Monteverdi2 components. The overall
* design often uses the Model-View-Controller pattern.
*
* The interface is based on a <a href="http://qt-project.org">Qt</a> framework.
* The OTB-Ice library is in charge of image rendering.
*
*/
/**
\page BloxPage Blox Framework
\section BloxIntroduction Introduction
The itk::BloxImage object is a regular, rectilinear lattice of ``blocks''
in n-dimensional space. The word ``blox'' was chosen to bring to mind a
set of ``city blocks'' in 2D or ``building blocks'' in 3D. Being a
regular lattice, itk::BloxImage logically derives from itkImage. In an
itk::BloxImage, each pixel represents an isometric space-filling block of
geometric space, called an itk::BloxPixel. Each itk::BloxPixel generally
covers many pixels in the underlying image and is used to store a
variable number of image primitives (such as boundary points) or
features (such as medial nodes) gathered within that region of geometric
space. To do this, each itk::BloxPixel contains a linked list.
The itk::BloxImage object facilitates certain forms of analysis by
providing geometric hashing. For example, if boundary points are stored
in an itk::BloxImage, pairs of boundary points that face each other
(called ``core atoms'') can be found by searching relatively small
regions of geometric space that face each boundary point for appropriate
mates. Because an itk::BloxImage is rectilinear in geometric space (even
though the underlying image may not be) subsequent analysis can be
invariant to rotation and translation.
*/
/**
\page GeometryPage Geometry Concepts
Insight provide basic classe to represent geometrical concepts, alghought
the aim of the toolkit is not computational geometry, some of these elements
are necessary for common procedures in image processing.
This document present the different geometric concepts used in the toolkit,
as well as their relationships and how they can effectively be used.
At the beggining there was the Point
*/
/**
\page ImageSimilarityMetricsPage Image Similarity Metrics
\section MetricsIntroduction Introduction
It is a common task in image analysis to require to compare how
similar two image might be. This comparison may be limited to a
particular region of each image. \em Image Similarity Metrics are
methods that produce a quantitative evaluation of the similarity
between two image or two image regions.
This techniques are used as a base for registration methods because
they provide the information that indicates when the registration
process is going in the right direction.
A large number of Image Similarity Metrics have been proposed in the
medical image and computer vision community. There is no a \em right
image similarity metric but a set of metrics that are appropiated for
particular applications. Metrics fit very well the notions of tools
in a toolkit. You need a set of them because none is able to perform
the same job as the other.
The following table presents a comparison between image similarity
metrics. This is by no means an exhaustive comparison but will at
least provide some guidance as to what metric can be appropiated for
particular problems.
\subsection RegistrationMetrics Similarity Metrics
Metrics are probably the most critical element of a registration problem. The metric defines what the goal of the process is, they measure how well the Target object is matched by the Reference object after the transform has been applied to it. The Metric should be selected in function of the types of objects to be registered and the expected kind of missalignment. Some metrics has a rather large capture region, which means that the optimizer will be able to find his way to a maximum even if the missalignment is high. Typicaly large capture regions are associated with low precision for the maximum. Other metrics can provide high precision for the final registration, but usually require to be initialized quite close to the optimal value.
Unfortunately there are no clear rules about how to select a metric, other that trying some of them in different conditions. In some cases could be and advantage to use a particular metric to get an initial approximation of the transformation, and then switch to another more sensitive metric to achieve better precision in the final result.
Metrics are depend on the objects they compare. The toolkit currently offers <em> Image To Image </em> and <em> PointSet to Image </em> metrics as follows:
\li <b> Mean Squares </b> Sum of squared differences between intensity values. It requires the two objects to have intensity values in the same range.
\li <b> Normalized Correlation </b> Correlation between intensity values divided by the square rooted autocorrelation of both target and reference objects: \f$ \frac{\sum_i^n{a_i * b_i }}{\sum_i^n{a_i^2}\sum_i^n{b_i^2}} \f$. This metric allows to register objects whose intensity values are related by a linear transformation.
\li <b> Pattern Intensity </b> Squared differences between intensity values transformed by a function of type \f$ \frac{1}{1+x} \f$ and summed them up. This metric has the advantage of increase simultaneously when more samples are available and when intensity values are close.
\li <b> Mutual Information </b> Mutual information is based in an information theory concept. Mutual information between two sets measures how much can be known from one set if only the other set is known. Given a set of values \f$ A=\{a_i\} \f$. Its entropy \f$ H(A) \f$ is defined by \f$ H(A) = \sum_i^n{- p(a_i) \log({p(a_i)})} \f$ where \f$ p(a_i) \f$ are the probabilities of the values in the set. Entropy can be interpreted as a measure of the mean uncertainty reduction that is obtained when one of the particular values is found during sampling. Given two sets \f$ A=\{a_i\} \f$ and \f$ B=\{b_i\} \f$ its joint entropy is given by the joint probabilities \f$ p_(a_i,b_i) \f$ as \f$ H(A,B) = \sum_i^n{-p(a_i,b_i) * log( p(a_i, b_i) )} \f$. Mutual information is obtained by subtracting the entropy of both sets from the joint entropy, as : \f$ H(A,B)-H(A)-H(B) \f$, and indicates how much uncertainty about one set is reduced by the knowledge of the second set. Mutual information is the metric of choice when image from different modalities need to be registered.
*/
/**
\page ImageIteratorsPage Image Iterators
\section ImageIteratorsIntroduction Introduction
ImageIterators are the mechanism used in ITK for walking through the image
data.
You probably learned image processing with the classical access to the
image data using <b>"for loops"</b> like:
\code
const int nx = 200;
const int ny = 100;
ImageType image(nx,ny);
for(int x=0; x<nx; x++) // for all Columns
{
for(int y=0; y<ny; y++) // for all Rows
{
image(x,y) = 10;
}
}
\endcode
When what you \em really mean is:
\code
ForAllThePixels p in image Do p = 100
\endcode
ImageIterators gets you closer to this algorithmic abstraction.
They abstract the low-level processing of images from the particular
implementation of the image class.
Here is how an image iterator is used in ITK:
\code
ImageType::Pointer im = GetAnImageSomeHow();
ImageIterator it( im, im->GetRequestedRegion() );
it.GoToBegin();
while( !it.IsAtEnd() )
{
it.Set( 10 );
++it;
}
\endcode
This code can also be written as:
\code
ImageType::Pointer im = GetAnImageSomeHow();
ImageIterator it( im, im->GetRequestedRegion() );
for (it = it.Begin(); !it.IsAtEnd(); ++it)
{
it.Set( 10 );
}
\endcode
One important advantage of ImageIterators is that they provide support for
the N-Dimensional images in ITK. Otherwise it would be impossible (or at
least very hard) to write algorithms that work independent of the image
dimension.
Another advantage of ImageIterators is that they support walking a region
of an image. In fact, one argument of an ImageIterator's constructor
defines the region or portion of an image to traverse.
Iterators know a lot about the internal composition of the image,
relieving the user from these details. Your algorithm can go through
all the pixels of an image without ever knowing the dimension of the image.
\section IteratorTypes Types of Iterators
The order in which the image pixels are visited can be quite important for
some image processing algorithms and may be inconsequential to other
algorithms as long as pixels are accessed as fast as possible.
To address these diverse requirements, ITK implements a set
of ImageIterators, always following the "C" philosophy of :
"You only pay for what you use"
Here is a list of some of the different ImageIterators implemented in ITK:
- itk::ImageRegionIterator
- itk::ImageRegionReverseIterator
Region iterators don't define any specific order to walk over the pixels on
the image. The user can be sure though, that all the pixels inside the region
will be visited.
The following iterators allow to walk the image in specific directions
- itk::ImageLinearIteratorWithIndex Along lines
- itk::ImageSliceIteratorWithIndex Along lines, then along planes
Iterators in general can have <B>Read/Write</B> access to image pixels.
A family of iterators provides <B>Read Only</B> access, in order to
preserve the image content. These iterators are equivalent to "C"
const pointers :
\code
const * PixelType iterator;
\endcode
or to STL const_iterators:
\code
vector<PixelType>::const_iterator it;
\endcode
The class name of the iterator makes clears if it provides const access
or not. Some of the <TT>const</TT> iterators available are
- itk::ImageConstIterator
- itk::ImageConstIteratorWithIndex
- itk::ImageLinearConstIteratorWithIndex
- itk::ImageRegionConstIteratorWithIndex
- itk::ImageSliceConstIteratorWithIndex
\subsection NeighbohoodIteratorType Other Types of Iterators
Another group of iterators support a moving neighborhood. Here the
neighborhood can "iterate" over an image and a calculation can iterate
over the neighborhood. This allows N-dimensional implementations of
convolution and finite differences to be implemented succintly.
This class of iterators is described in detail on the page
\ref NeighborhoodIteratorsPage.
\subsection STL ImageIterators vs. STL Iterators
Given the breadth and complexity of ImageIterators, they are designed to
operate slightly differently than STL iterators. In STL, you ask a
container for an iterator that will traverse the container. Furthermore,
in STL, you frequently compare an iterator against another iterator.
Here is a loop to walk over an STL vector.
\code
for (it = vec.begin(); it != vec.end(); ++it)
{}
\endcode
ImageIterators, unfortunately, are more complicated than STL iterators.
ImageIterators need to store more state information than STL iterators.
As one example, ImageIterators can walk a region of an image and an
image can have multiple ImageIterators traversing different
regions simultaneously. Thus, each ImageIterator must maintain which region
it traverses. This results in a fairly heavyweight iterator, where
comparing two ImageIterators and constructing iterators is an
expensive operation. To address this issue, ImageIterators have a
slightly different API than STL iterators.
First, you do not ask the container (the image) for an iterator. Instead,
you construct an iterator and tell it which image to traverse. Here
is a snippet of code to construct an iterator that will walk a region
of an image:
\code
ImageType::Pointer im = GetAnImageSomeHow();
ImageIterator it( im, im->GetRequestedRegion() );
\endcode
Second, since constructing and comparing ImageIterators is expensive,
ImageIterators know the beginning and end of the region. So you ask the
iterator rather than the container whether the iterator is at the end of
a region.
\code
for (it = it.Begin(); !it.IsAtEnd(); ++it)
{
it.Set( 10 );
}
\endcode
\subsection IteratorsRegions Regions
Iterators are typically defined to walk a region of an image. ImageRegions
are defined to be rectangular prisms. (Insight also has a number of
iterators that can walk a region defined by a spatial function.)
The region for an iterator is defined at constructor time. Regions
are not validated, so the programmer is responsible for assigning a
region that is within the image. Iterator methods Begin() and End()
are defined relative to the region. See below.
\section IteratorAPI Iterator API
\subsection IteratorsPositioning Position
\subsection IteratorsIntervals Half Open Intervals - Begin/End
Like most iterator implementations, ImageIterators walk a half-open
interval. Begin is defined as the first pixel in the region. End is
defined as one pixel past the last pixel in the region (one pixel
past in the same row). So Begin points a valid pixel in the region
and End points to a pixel that is outside the region.
\subsection IteratorsDereferencing Dereferencing
In order to get access to the image data pointed by the iterator,
dereferencing is required. This is equivalent to the classical
"C" dereferencing code :
\code
PixelType * p; // creation of the pointer
*p = 100; // write access to a data
PixelType a = *p; // read access to data
\endcode
Iterators dereference data using <TT>Set()</TT> and <TT>Get()</TT>
\code
imageIterator.Set( 100 );
PixelType a = imageIterator.Get();
\endcode
\subsection IteratorsOperatorPlusPlus operator++
The ++ operator will move the image iterator to the next pixel,
according to the particular order in which this iterator walks
the imaage.
\subsection IteratorsOperatorMinusMinus operator--
The -- operator will move the image iterator to the previous pixel,
according to the particular order in which this iterator walks
the imaage.
\subsection IteratorsIteratorsBegin Begin()
Begin() returns an iterator for the same image and region as the current
iterator but positioned at the first pixel in the region. The current iterator
is not modified.
\subsection IteratorsIteratorsEnd End()
End() returns an iterator for the same image and region as the current
iterator but positioned one pixel past the last pixel in the region.
The current iterator is not modified.
\subsection IteratorsIteratorsGotoBegin GotoBegin()
GotoBegin() repositions the iterator to the first pixel in the region.
\subsection IteratorsGotoEnd GotoEnd()
GotoEnd() repositions the iterator to one pixel past (in the same
row) the last pixel in the region.
\subsection IteratorsIsAtBegin IsAtBegin()
IsAtBegin() returns true if the iterator is positioned at the first
pixel in the region, returns false otherwise. IsAtBegin() is faster than
comparing an iterator for equivalence to the iterator returned by Begion().
\code
if (it.IsAtBegin()) {} // Fast
if (it == it.Begin()) {} // Slow
\endcode
\subsection IteratorsIsAtEnd IsAtEnd()
IsAtEnd() returns true if the iterator is positioned one pixel past
the last pixel in the region, returns false otherwise. IsAtEnd()
is faster than comparing an iterator for equivalence to the iterator
returned by End().
\code
if (it.IsAtEnd()) {} // Fast
if (it == it.End()) {} // Slow
\endcode
\section IteratorFinalComment Final Comments
In general, iterators are not the kind of objects that users of the
toolkit would need to use. They are rather designed to be used by
code developers that add new components to the toolkit, like writting
a new Image filter, for example.
Before starting to write code that use iterators, users should consider
to verify if the particular operation they intend to apply to the image
is not already defined in the form of an existing image filter.
*/
/**
*
* \mainpage Orfeo Toolbox
*
* <div align="center"><img src="logoVectoriel.png" alt="logoVectoriel.png"></div>
*
* \section intro Introduction
*
* Welcome to CNES' ORFEO Toolbox (OTB). OTB is an open-source image processing
* software, designed for remote sensing applications.
*
* \section homepage Home Page
*
* The Home Page of the project can be found at:
*
* http://www.orfeo-toolbox.org
*
* \section howto How to use this documentation
*
* This documentation describes the API of the toolbox. You can start your
* visit by the Classes link above which details all available classes in OTB. The Modules
* link presents a hierarchy of classes organized according to their
* functionality. The Related Pages link presents design details, in
* particular the use of the data pipeline model and the philosophy of
* iterators.
*
*/
/**
\defgroup Thematic Thematic modules
The Orfeo Toolbox includes processing modules corresponding to radiometry, geometry, etc.
*/
/**
\defgroup Radiometry Radiometry modules
\ingroup Thematic
This category includes the elements related to the radiometry processing of the image.
*/
/**
\defgroup Projection Projection modules
\ingroup Thematic
This category includes the elements related to the geometry of the image: projection, orthorectification.
*/
/**
\defgroup FeatureExtraction FeatureExtraction modules
\ingroup Thematic
This category includes the elements related to feature extraction: texture indexes, etc.
*/
/**
\defgroup Textures Textures modules
\ingroup FeatureExtraction
This category includes the elements related to texture indexes.
*/
/**
\defgroup Visualization Visualization modules
Classes related to the visualization framework of OTB to enable an easy building of new simple applications with
a plugin system
*/
/**
\defgroup DataRepresentation Data Representation Objects
The Insight Toolkit includes several data representation objects such as
Image, Mesh, Pixel, Points, etc.
*/
/**
\defgroup ImageObjects Image Representation Objects
\ingroup DataRepresentation
This category includes the objects required to represent images in ITK.
*/
/**
\defgroup MeshObjects Mesh Representation Objects
\ingroup DataRepresentation
This category includes the objects required to represent meshes in ITK.
*/
/**
\defgroup PathObjects Path Representation Objects
\ingroup DataRepresentation
This category includes the objects required to represent paths in ITK.
*/
/**
\defgroup Geometry Geometry Representation Objects
\ingroup DataRepresentation
This category include the objects required to represent geometrical entities
like positions, vectors and space mappings.
A detailed description of the rationale for these classes can be found in
\ref GeometryPage
*/
/**
\defgroup DataAccess Data Access Objects
The Insight Toolkit includes several ways to access data through the user of
iterators, pointers, indexes, etc.
*/
/**
\defgroup TensorObjects Objects Related to Tensor Images
This category includes the objects required for representing diffusion tensor images in ITK.
*/
/**
\defgroup ImageAccess Image Access Objects
\ingroup DataAccess
*/
/**
\defgroup MeshAccess Mesh Access Objects
\ingroup DataAccess
*/
/**
\defgroup Iterators Iterators
\ingroup DataAccess
Iterators are the mechanism used to walk over the content of a particular data object.
They allow to define paths and directions along which the data should be walked through.
*/
/**
\defgroup ImageIterators Image Iterators
\ingroup Iterators
Image Iterators allow to go through the content of an image in a predefined way.
For a detailed description of iterators rationale see \ref ImageIteratorsPage
*/
/**
\defgroup DataProcessing Data Processing Objects
The Insight Toolkit includes several ways to process the data using objects such as adaptors, functions, filters, and
transforms.
*/
/**
\defgroup Filters Filters
\ingroup DataProcessing
Filters implement the operations on the pipeline architecture.
*/
/**
\defgroup ImageFilters Image Filters
\ingroup Filters
Image filters process input images and produce output images. Inputs are
unmodified. The pipeline architecture makes provisions for supporting
streaming by using packets of data defined by regions
\sa Image
\sa PhysicalImage
\sa ImageRegion
*/
/**
\defgroup MeshFilters Mesh Filters
\ingroup Filters
Mesh filters process input meshes and produce output meshes. Inputs are
unmodified.
\sa Mesh
*/
/**
\defgroup IntensityImageFilters Intensity Image Filters
\ingroup ImageFilters
Intensity Image filters only alter the values stored in image pixels.
\sa Image
\sa PhysicalImage
\sa ImageRegion
*/
/**
\defgroup MathematicalMorphologyImageFilters Mathematical Morphology Image Filters
\ingroup IntensityImageFilters
Mathematical morphology filters are a particular class of cellular automata.
They modify the value of a pixel based on the values of a neighborhood.
The neighborhood is now as the structured element.
\sa Image
\sa PhysicalImage
\sa ImageRegion
\sa BinaryMorphologicalFilterBase
*/
/**
\defgroup ImageEnhancement Image Enhancement Filters
\ingroup ImageFilters
Image enhancement filters process an image to enhance the appearance
of an image either for visualization purposes or for further processing.
Examples of image enhancement filters available in ITK are: anisotropic diffusion,
Gaussian filter, and histogram equalization.
*/
/**
\defgroup ImageFeatureExtraction Image Feature Extraction Filters
\ingroup ImageFilters
Image feature extraction filters process an image to extract features of interest
such as gradients, edges, distances, etc.
Examples of image feature extraction algorithms available in ITK are: image gradients,
first and second derivatives, and Danielson distance.
*/
/**
\defgroup GradientFilters Image Gradient Filters
\ingroup ImageFeatureExtraction