diff --git a/SoftwareGuide/Art/CompositeExamplePipeline.fig b/SoftwareGuide/Art/CompositeExamplePipeline.fig
new file mode 100755
index 0000000000000000000000000000000000000000..a4b83f8ca23e821229ac2cebcb0b40aab23b031f
--- /dev/null
+++ b/SoftwareGuide/Art/CompositeExamplePipeline.fig
@@ -0,0 +1,71 @@
+#FIG 3.2 Produced by xfig version 3.2.5-alpha5
+Landscape
+Center
+Metric
+A4
+100.00
+Single
+-2
+1200 2
+6 1575 2295 2475 2610
+5 1 0 1 0 7 50 -1 -1 0.000 0 0 0 0 2025.000 2475.000 2025 2340 2160 2475 2025 2610
+1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 2025 2475 64 64 2025 2475 2089 2475
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 1575 2475 1935 2475
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 2160 2475 2475 2475
+-6
+6 7650 2295 8550 2610
+5 1 0 1 0 7 50 -1 -1 0.000 0 0 0 0 8100.000 2475.000 8100 2340 8235 2475 8100 2610
+1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 8100 2475 64 64 8100 2475 8164 2475
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 7650 2475 8010 2475
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 8235 2475 8550 2475
+-6
+6 2833 2869 7346 3330
+6 3733 2969 4581 3240
+5 1 0 1 0 7 50 -1 -1 0.000 0 0 0 0 4183.000 3105.000 4183 2970 4318 3105 4183 3240
+1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 4183 3105 64 64 4183 3105 4247 3105
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 3733 3105 4093 3105
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 4318 3105 4581 3105
+-6
+6 5596 2969 6433 3240
+5 1 0 1 0 7 50 -1 -1 0.000 0 0 0 0 5983.000 3105.000 5983 2970 6118 3105 5983 3240
+1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 5983 3105 64 64 5983 3105 6047 3105
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 5596 3105 5893 3105
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 6118 3105 6433 3105
+-6
+1 2 0 1 0 7 50 -1 -1 0.000 1 0.0000 6896 3094 450 225 6446 2869 7346 3319
+1 2 0 1 0 7 50 -1 -1 0.000 1 0.0000 3283 3105 450 225 2833 2880 3733 3330
+1 2 0 1 0 7 60 -1 -1 0.000 1 0.0000 5093 3105 496 206 4597 3105 5589 3105
+4 0 0 50 -1 0 12 0.0000 4 135 705 2968 3150 Gradient\001
+4 0 0 50 -1 0 12 0.0000 4 150 630 6613 3150 Rescale\001
+4 1 0 50 -1 0 12 0.0000 4 150 825 5095 3166 Threshold\001
+-6
+1 2 0 1 0 7 50 -1 -1 0.000 1 0.0000 1125 2475 450 225 675 2250 1575 2700
+1 2 0 1 0 7 50 -1 -1 0.000 1 0.0000 9000 2475 450 225 8550 2250 9450 2700
+2 1 2 1 0 7 50 -1 -1 3.000 0 0 -1 0 0 2
+ 2475 2475 7650 2475
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 3
+ 7345 3090 7650 3090 7650 2475
+2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5
+ 7785 3735 7785 1800 2205 1800 2205 3735 7785 3735
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3
+ 1 1 1.00 60.00 120.00
+ 2475 2475 2475 3105 2833 3105
+4 0 0 50 -1 0 12 0.0000 4 135 570 855 2520 Reader\001
+4 0 0 50 -1 0 12 0.0000 4 135 510 8820 2520 Writer\001
+4 0 0 50 -1 0 12 0.0000 4 195 2535 3780 2160 CompositeExampleImageFilter\001
diff --git a/SoftwareGuide/Art/CompositeFilterStages.fig b/SoftwareGuide/Art/CompositeFilterStages.fig
new file mode 100755
index 0000000000000000000000000000000000000000..82957f73c380dc1ab9eae12c0e16f925ecabb6d2
--- /dev/null
+++ b/SoftwareGuide/Art/CompositeFilterStages.fig
@@ -0,0 +1,61 @@
+#FIG 3.2 Produced by xfig version 3.2.5-alpha5
+Landscape
+Center
+Metric
+A4
+100.00
+Single
+-2
+1200 2
+6 1575 2295 2475 2610
+5 1 0 1 0 7 50 -1 -1 0.000 0 0 0 0 2025.000 2475.000 2025 2340 2160 2475 2025 2610
+1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 2025 2475 64 64 2025 2475 2089 2475
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 1575 2475 1935 2475
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 2160 2475 2475 2475
+-6
+6 3375 2295 4275 2610
+5 1 0 1 0 7 50 -1 -1 0.000 0 0 0 0 3825.000 2475.000 3825 2340 3960 2475 3825 2610
+1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 3825 2475 64 64 3825 2475 3889 2475
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 3375 2475 3735 2475
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 3960 2475 4275 2475
+-6
+6 5175 2295 6075 2610
+5 1 0 1 0 7 50 -1 -1 0.000 0 0 0 0 5625.000 2475.000 5625 2340 5760 2475 5625 2610
+1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 5625 2475 64 64 5625 2475 5689 2475
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 5175 2475 5535 2475
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 5760 2475 6075 2475
+-6
+6 6975 2295 7875 2610
+5 1 0 1 0 7 50 -1 -1 0.000 0 0 0 0 7425.000 2475.000 7425 2340 7560 2475 7425 2610
+1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 7425 2475 64 64 7425 2475 7489 2475
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 6975 2475 7335 2475
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 7560 2475 7875 2475
+-6
+1 2 0 1 0 7 50 -1 -1 0.000 1 0.0000 1125 2475 450 225 675 2250 1575 2700
+1 2 0 1 0 7 50 -1 -1 0.000 1 0.0000 2925 2475 450 225 2475 2250 3375 2700
+1 2 0 1 0 7 50 -1 -1 0.000 1 0.0000 4725 2475 450 225 4275 2250 5175 2700
+1 2 0 1 0 7 50 -1 -1 0.000 1 0.0000 8325 2475 450 225 7875 2250 8775 2700
+1 2 0 1 0 7 50 -1 -1 0.000 1 0.0000 4725 2475 2340 900 2385 1575 7065 3375
+1 2 0 1 0 7 50 -1 -1 0.000 1 0.0000 6538 2464 450 225 6088 2239 6988 2689
+4 0 0 50 -1 0 12 0.0000 4 150 555 855 2520 Source\001
+4 0 0 50 -1 0 12 0.0000 4 195 555 2655 2520 Stage1\001
+4 0 0 50 -1 0 12 0.0000 4 180 555 4455 2520 Stage2\001
+4 0 0 50 -1 0 12 0.0000 4 165 375 8145 2520 Sink\001
+4 0 0 50 -1 0 12 0.0000 4 180 885 4320 1890 Composite\001
+4 0 0 50 -1 0 12 0.0000 4 180 690 6255 2520 Stage...n\001
diff --git a/SoftwareGuide/Examples/CMakeLists.txt b/SoftwareGuide/Examples/CMakeLists.txt
index 6b8aa742e5e2c34971871a6aaa267e4e36c00590..49d7770c8cb76d4f72a85432fc2d4a5ac3c8e91d 100644
--- a/SoftwareGuide/Examples/CMakeLists.txt
+++ b/SoftwareGuide/Examples/CMakeLists.txt
@@ -157,6 +157,10 @@ SET( OTB_EXAMPLES_SRCS
${OTB_SOURCE_DIR}/Examples/DataRepresentation/Image/Image2.cxx
${OTB_SOURCE_DIR}/Examples/DataRepresentation/Image/Image3.cxx
${OTB_SOURCE_DIR}/Examples/DataRepresentation/Image/Image4.cxx
+ ${OTB_SOURCE_DIR}/Examples/DataRepresentation/Image/ImageAdaptor1.cxx
+ ${OTB_SOURCE_DIR}/Examples/DataRepresentation/Image/ImageAdaptor2.cxx
+ ${OTB_SOURCE_DIR}/Examples/DataRepresentation/Image/ImageAdaptor3.cxx
+ ${OTB_SOURCE_DIR}/Examples/DataRepresentation/Image/ImageAdaptor4.cxx
${OTB_SOURCE_DIR}/Examples/DataRepresentation/Image/RGBImage.cxx
${OTB_SOURCE_DIR}/Examples/DataRepresentation/Image/VectorImage.cxx
${OTB_SOURCE_DIR}/Examples/DataRepresentation/Image/Image5.cxx
@@ -180,6 +184,7 @@ SET( OTB_EXAMPLES_SRCS
${OTB_SOURCE_DIR}/Examples/Filtering/BinaryThresholdImageFilter.cxx
${OTB_SOURCE_DIR}/Examples/Filtering/ThresholdImageFilter.cxx
${OTB_SOURCE_DIR}/Examples/Filtering/CannyEdgeDetectionImageFilter.cxx
+ ${OTB_SOURCE_DIR}/Examples/Filtering/CompositeFilterExample.cxx
${OTB_SOURCE_DIR}/Examples/StartExamples/MeanImageFilter.cxx
${OTB_SOURCE_DIR}/Examples/BasicFilters/LeeImageFilter.cxx
${OTB_SOURCE_DIR}/Examples/FeatureExtraction/AlignmentsExample.cxx
diff --git a/SoftwareGuide/Latex/ImageAdaptors.tex b/SoftwareGuide/Latex/ImageAdaptors.tex
index 5aa0177300fa8fa990215bc2d2d87d5c3bc11cca..ac68b08f92b4d4ba9cfe54807ed0973c9b5038fe 100755
--- a/SoftwareGuide/Latex/ImageAdaptors.tex
+++ b/SoftwareGuide/Latex/ImageAdaptors.tex
@@ -23,7 +23,7 @@ example is to take an image of pixel type \code{unsigned char} and
present it as an image of pixel type \code{float}. The motivation for
using image adaptors in this case is to avoid the extra memory
resources required by using a casting filter. When we use the
-\doxygen{CastImageFilter} for the conversion, the filter creates a
+\doxygen{itk}{CastImageFilter} for the conversion, the filter creates a
memory buffer large enough to store the \code{float} image. The
\code{float} image requires four times the memory of the
original image and contains no useful additional information. Image
@@ -46,37 +46,29 @@ adaptors are defined for many single valued and single parameter
functions such as trigonometric, exponential and logarithmic
functions. For example,
\begin{itemize}
-\item \doxygen{ExpImageAdaptor}
-\item \doxygen{SinImageAdaptor}
-\item \doxygen{CosImageAdaptor}
+\item \doxygen{itk}{ExpImageAdaptor}
+\item \doxygen{itk}{SinImageAdaptor}
+\item \doxygen{itk}{CosImageAdaptor}
\end{itemize}
The following examples illustrate common applications of image adaptors.
\section{Image Casting}
\label{sec:ImageAdaptorForBasicCasting}
-\ifitkFullVersion
\input{ImageAdaptor1.tex}
-\fi
\section{Adapting RGB Images}
\label{sec:ImageAdaptorForRGB}
-\ifitkFullVersion
\input{ImageAdaptor2.tex}
-\fi
\section{Adapting Vector Images}
\label{sec:ImageAdaptorForVectors}
-\ifitkFullVersion
\input{ImageAdaptor3.tex}
-\fi
\section{Adaptors for Simple Computation}
\label{sec:ImageAdaptorForSimpleComputation}
-\ifitkFullVersion
\input{ImageAdaptor4.tex}
-\fi
\section{Adaptors and Writers}
diff --git a/SoftwareGuide/Latex/Iterators.tex b/SoftwareGuide/Latex/Iterators.tex
index c988a94b8b54584dc102b4bd622350445784cdc4..22ed13429c908392867867fe3dc1950464d9c5da 100644
--- a/SoftwareGuide/Latex/Iterators.tex
+++ b/SoftwareGuide/Latex/Iterators.tex
@@ -43,7 +43,7 @@ container type, and dimensionality. Because ITK image iterators are
specifically designed to work with \emph{image} containers, their interface and
implementation is optimized for image processing tasks. Using the ITK
iterators instead of accessing data directly through the
-\doxygen{itk}{Image} interface has many advantages. Code is more
+\doxygen{otb}{Image} interface has many advantages. Code is more
compact and often generalizes automatically to higher dimensions, algorithms
run much faster, and iterators simplify tasks such as multithreading and
neighborhood-based image processing.
@@ -82,11 +82,11 @@ non-const iterator cannot be instantiated on a non-const image pointer.
Const versions of iterators may read, but may not write pixel values.
Here is a simple example that defines and constructs a simple image iterator
-for an \doxygen{itk}{Image}.
+for an \doxygen{otb}{Image}.
\small
\begin{verbatim}
- typedef itk::Image<float, 3> ImageType;
+ typedef otb::Image<float, 3> ImageType;
typedef itk::ImageRegionConstIterator< ImageType > ConstIteratorType;
typedef itk::ImageRegionIterator< ImageType > IteratorType;
diff --git a/SoftwareGuide/Latex/SoftwareGuide.tex b/SoftwareGuide/Latex/SoftwareGuide.tex
index c555d574feed85eed766309a86efb63cefec7399..bdd582fdfade43fa350809a42dad08731c8ff2d2 100644
--- a/SoftwareGuide/Latex/SoftwareGuide.tex
+++ b/SoftwareGuide/Latex/SoftwareGuide.tex
@@ -152,14 +152,12 @@ colorlinks,linkcolor={blue},citecolor={blue},urlcolor={blue},
-\ifitkPrintedVersion
+%%\ifitkPrintedVersion
%% \input{Cover.tex}
-\fi
+%%\fi
-\ifitkFullVersion
\input{Abstract.tex}
\input{Contributors.tex}
-\fi
@@ -195,16 +193,13 @@ colorlinks,linkcolor={blue},citecolor={blue},urlcolor={blue},
\part{Introduction}
-\ifitkFullVersion
\input{Introduction.tex}
\input{Installation.tex}
\input{SystemOverview.tex}
-\fi
\part{User's guide}
-\ifitkFullVersion
\input{DataRepresentation.tex}
\input{ReadWrite.tex}
\input{Filtering.tex}
@@ -213,24 +208,15 @@ colorlinks,linkcolor={blue},citecolor={blue},urlcolor={blue},
\input{ChangeDetection.tex}
\input{Classification.tex}
\input{Visualization.tex}
-\fi
%%% \input{Applications.tex}
-%%%\part{Developper's guide}
-\ifitkFullVersion
+\part{Developper's guide}
\input{Iterators.tex}
-\fi
-
-\ifitkFullVersion
\input{ImageAdaptors.tex}
-\fi
-
-\ifitkFullVersion
\input{WriteAFilter.tex}
-\fi
\backmatter
@@ -253,10 +239,10 @@ colorlinks,linkcolor={blue},citecolor={blue},urlcolor={blue},
\InputIfFileExists{SoftwareGuide.ind}
-\ifitkPrintedVersion
-\cleardoublepage
+%%\ifitkPrintedVersion
+%%\cleardoublepage
%%% \input{MarketingMaterial.tex}
-\fi
+%%\fi
diff --git a/SoftwareGuide/Latex/WriteACompositeFilter.tex b/SoftwareGuide/Latex/WriteACompositeFilter.tex
new file mode 100755
index 0000000000000000000000000000000000000000..7642389965d66c27672881049859bcf7677e3dfe
--- /dev/null
+++ b/SoftwareGuide/Latex/WriteACompositeFilter.tex
@@ -0,0 +1,77 @@
+
+\section{How To Write A Composite Filter}
+
+In general, most ITK/OTB filters implement one particular algorithm,
+whether it be image filtering, an information metric, or a
+segmentation algorithm. In the previous section, we saw how to write
+new filters from scratch. However, it is often very useful to be able
+to make a new filter by combining two or more existing filters, which
+can then be used as a building block in a complex pipeline. This
+approach follows the Composite pattern \cite{Gamma1995}, whereby the
+composite filter itself behaves just as a regular filter, providing
+its own (potentially higher level) interface and using other filters
+(whose detail is hidden to users of the class) for the implementation.
+This composite structure is shown in
+Figure~\ref{fig:CompositeFilterStages}, where the various
+\code{Stage-n} filters are combined into one by the \code{Composite}
+filter. The \code{Source} and \code{Sink} filters only see the
+interface published by the \code{Composite}. Using the Composite
+pattern, a composite filter can encapsulate a pipeline of arbitrary
+complexity. These can in turn be nested inside other pipelines.
+
+\begin{figure}
+ \centering
+ \includegraphics[width=0.9\textwidth]{CompositeFilterStages.eps}
+ \itkcaption[Composite Filter Concept]{A Composite filter encapsulates a number of other filters.}
+ \label{fig:CompositeFilterStages}
+\end{figure}
+
+\subsection{Implementing a Composite Filter}
+
+There are a few considerations to take into account when implementing a
+composite filter. All the usual requirements for filters apply (as
+discussed above), but the following guidelines should be considered:
+
+\begin{enumerate}
+
+\item The template arguments it takes must be sufficient to instantiate all of
+the component filters. Each component filter needs a type supplied by either
+the implementor or the enclosing class. For example, an
+\code{ImageToImageFilter} normally takes an input and output image type (which
+may be the same). But if the output of the composite filter is a classified
+image, we need to either decide on the output type inside the composite filter,
+or restrict the choices of the user when she/he instantiates the filter.
+
+\item The types of the component filters should be declared in the header,
+ preferably with \code{protected} visibility. This is because the
+ internal structure normally should not be visible to users of the class,
+ but should be to descendent classes that may need to modify or customize
+ the behavior.
+
+\item The component filters should be private data members of the composite
+ class, as in \code{FilterType::Pointer}.
+
+\item The default constructor should build the pipeline by creating the
+ stages and connect them together, along with any default parameter
+ settings, as appropriate.
+
+\item The input and output of the composite filter need to be grafted on to
+ the head and tail (respectively) of the component filters.
+
+\end{enumerate}
+
+This grafting process is illustrated in Figure~\ref{fig:CompositeExamplePipeline}.
+
+
+\subsection{A Simple Example}
+
+\begin{figure}
+ \centering
+ \includegraphics[width=0.9\textwidth]{CompositeExamplePipeline.eps}
+ \itkcaption[Composite Filter Example]{Example of a typical composite filter. Note that the output of the last filter in the internal pipeline must be grafted into the output of the composite filter.}
+ \label{fig:CompositeExamplePipeline}
+\end{figure}
+
+\input{CompositeFilterExample.tex}
+
+%---------------------------------------------------------------------------
diff --git a/SoftwareGuide/Latex/WriteAFilter.tex b/SoftwareGuide/Latex/WriteAFilter.tex
index 77f09be53faad599f7c78856dab9fc632432cd72..9b57473e2f808562429d8c13011c92cede8f95cb 100755
--- a/SoftwareGuide/Latex/WriteAFilter.tex
+++ b/SoftwareGuide/Latex/WriteAFilter.tex
@@ -40,20 +40,20 @@ information.
\index{mapper}
\item A \textbf{data object} represents and provides access to
- data. In ITK, the data object (ITK class \doxygen{DataObject}) is
- typically of type \doxygen{Image} or \doxygen{Mesh}.
+ data. In ITK, the data object (ITK class \doxygen{itk}{DataObject}) is
+ typically of type \doxygen{otb}{Image} or \doxygen{itk}{Mesh}.
\index{data object}
- \item A \textbf{region} (ITK class \doxygen{Region}) represents a
+ \item A \textbf{region} (ITK class \doxygen{itk}{Region}) represents a
piece, or subset of the entire data set.
\index{region}
- \item An \textbf{image region} (ITK class \doxygen{ImageRegion})
+ \item An \textbf{image region} (ITK class \doxygen{itk}{ImageRegion})
represents a structured portion of data. ImageRegion is implemented
- using the \doxygen{Index} and \doxygen{Size} classes
+ using the \doxygen{itk}{Index} and \doxygen{itk}{Size} classes
\index{image region}
- \item A \textbf{mesh region} (ITK class \doxygen{MeshRegion})
+ \item A \textbf{mesh region} (ITK class \doxygen{itk}{MeshRegion})
represents an unstructured portion of data.
\index{mesh region}
@@ -78,7 +78,7 @@ information.
\index{RequestedRegion}
\item The \textbf{modified time} (represented by ITK class
- \doxygen{TimeStamp}) is a monotonically increasing integer value that
+ \doxygen{itk}{TimeStamp}) is a monotonically increasing integer value that
characterizes a point in time when an object was last modified.
\index{modified time}
@@ -117,7 +117,7 @@ ITK filter is to identify the number and types of input and
output. Having done so, there are often superclasses that simplify
this task via class derivation. For example, most filters in ITK take
a single image as input, and produce a single image on output. The
-superclass \doxygen{ImageToImageFilter} is a convenience class that
+superclass \doxygen{itk}{ImageToImageFilter} is a convenience class that
provide most of the functionality needed for such a filter.
Some common base classes for new filters include:
@@ -162,8 +162,8 @@ for an overview of multi-threading in ITK.)
An important note: the GenerateData() method is required to allocate memory
for the output. The ThreadedGenerateData() method is not. In default
-implementation (see \doxygen{ImageSource}, a superclass of
-\doxygen{ImageToImageFilter})
+implementation (see \doxygen{itk}{ImageSource}, a superclass of
+\doxygen{itk}{ImageToImageFilter})
\code{GenerateData()} allocates memory and then invokes
\code{ThreadedGenerateData()}.
@@ -281,14 +281,14 @@ particular size (i.e., region). It may be that the user asks to process a
region of interest within a large image, or that memory limitations result in
processing the data in several pieces. For example, an application may
compute the memory required by a pipeline, and then use
-\doxygen{StreamingImageFilter} to break the data processing into several pieces.
+\doxygen{itk}{StreamingImageFilter} to break the data processing into several pieces.
The data request is propagated through the pipeline in the upstream
direction, and the negotiation process configures each filter to produce
output data of a particular size.
The secret to creating a streaming filter is to understand how this
negotiation process works, and how to override its default behavior by using
-the appropriate virtual functions defined in \doxygen{ProcessObject}. The next
+the appropriate virtual functions defined in \doxygen{itk}{ProcessObject}. The next
section describes the specifics of these methods, and when to override
them. Examples are provided along the way to illustrate concepts.
@@ -334,7 +334,7 @@ to the output (via \code{DataObject::CopyInformation()}). Remember, information
is metadata describing the output, such as the origin, spacing,
and LargestPossibleRegion (i.e., largest possible size) of an image.
-A good example of this behavior is \doxygen{ShrinkImageFilter}. This filter
+A good example of this behavior is \doxygen{itk}{ShrinkImageFilter}. This filter
takes an input image and shrinks it by some integral value. The result is that
the spacing and LargestPossibleRegion of the output will be different to that
of the input. Thus, \code{GenerateOutputInformation()} is overloaded.
@@ -388,13 +388,13 @@ three methods that the filter developer may choose to overload.
or other region boundary effects.
\end{itemize}
-\doxygen{RGBGibbsPriorFilter} is an example of a filter that needs to
+\doxygen{itk}{RGBGibbsPriorFilter} is an example of a filter that needs to
invoke \code{EnlargeOutputRequestedRegion()}. The designer of this
filter decided that the filter should operate on all the data. Note
that a subtle interplay between this method and
\code{GenerateInputRequestedRegion()} is occurring here. The default
behavior of \code{GenerateInputRequestedRegion()} (at least for
-\doxygen{ImageToImageFilter}) is to set the input RequestedRegion to
+\doxygen{itk}{ImageToImageFilter}) is to set the input RequestedRegion to
the output's ReqestedRegion. Hence, by overriding the method
\code{EnlargeOutputRequestedRegion()} to set the output to the
LargestPossibleRegion, effectively sets the input to this filter to
@@ -404,7 +404,7 @@ filter, and therefore the pipeline, does not stream. This could be
fixed by reimplementing the filter with the notion of streaming built
in to the algorithm.)
-\doxygen{GradientMagnitudeImageFilter} is an example of a filter that needs to
+\doxygen{itk}{GradientMagnitudeImageFilter} is an example of a filter that needs to
invoke \code{GenerateInputRequestedRegion()}. It needs a larger input requested
region because a kernel is required to compute the gradient at a pixel. Hence
the input needs to be ``padded out'' so the filter has enough data to compute
@@ -453,7 +453,7 @@ Filters that can process data in pieces can typically multi-process
using the data parallel, shared memory implementation built into the
pipeline execution process. To create a multithreaded filter, simply
define and implement a \code{ThreadedGenerateData()} method. For
-example, a \doxygen{ImageToImageFilter} would create the method:
+example, a \doxygen{itk}{ImageToImageFilter} would create the method:
\small
\begin{verbatim}
@@ -562,17 +562,15 @@ Some of these are described below:
\end{description}
Much more useful information can be learned from browsing the source in
-\code{Code/Common/itkMacro.h} and for the \doxygen{Object} and
-\doxygen{LightObject} classes.
+\code{Code/Common/itkMacro.h} and for the \doxygen{itk}{Object} and
+\doxygen{itk}{LightObject} classes.
%
% Section on how to write composite filters
%
-\ifitkFullVersion
\input{WriteACompositeFilter.tex}
-\fi
%