%% Copyright (C) 2008, 2009, 2011 EPITA Research and Development
%% Laboratory (LRDE)
%%
%% This file is part of Olena.
%%
%% Olena is free software: you can redistribute it and/or modify it under
%% the terms of the GNU General Public License as published by the Free
%% Software Foundation, version 2 of the License.
%%
%% Olena is distributed in the hope that it will be useful,
%% but WITHOUT ANY WARRANTY; without even the implied warranty of
%% MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
%% General Public License for more details.
%%
%% You should have received a copy of the GNU General Public License
%% along with Olena.  If not, see <http://www.gnu.org/licenses/>.


%%%%%%%%%%%%%%%%%%%%%%
% Milena's tutorial. %
%%%%%%%%%%%%%%%%%%%%%%

\documentclass{report}

%\usepackage{hevea}


\usepackage{html}
\usepackage{graphicx}
\usepackage{makeidx}
\usepackage{xcolor}
\usepackage{color}
\usepackage{hyperref}
\usepackage{pgf}

% FIXME: Consider using the package FiXme from Didier Verna instead.
%\newcommand{\tofix}[1]{{\color{red}(FIXME: #1)}}
\newcommand{\tofix}[1]{}


\title{Olena -- Tutorial}
\author{LRDE}
\date{}
\makeindex

\input{doxyfuns.sty}
\input{milena.sty}

\begin{document}


% Doxygen use only - Generate the left menu.
%Write foreword below.
\begin{htmlonly}
\backslash endhtmlonly

\backslash page tutorial Tutorial
- \backslash subpage tuto1
- \backslash subpage tuto2
- \backslash subpage tuto3
- \backslash subpage tuto4
- \backslash subpage tuto5
- \backslash subpage tuto6
- \backslash subpage tuto7
- \backslash subpage tuto8

\backslash htmlonly
\end{htmlonly}

\begin{latexonly}
\maketitle

%====================================
\chapter*{Copyright}

Copyright (C) 2009 EPITA Research and Development Laboratory (LRDE).


This document is part of Olena.


Olena is free software: you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free
Software Foundation, version 2 of the License.


Olena is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
for more details.


You should have received a copy of the GNU General Public License
along with Olena.  If not, see $<$http://www.gnu.org/licenses/$>$.


\tableofcontents

\end{latexonly}


%====================================
\doxychapter{tuto1}{Welcome}

Welcome to Milena's tutorial.





%**************************
\doxysection{tuto1howotlearn}{How to learn Milena}

Milena is only a subpart of Olena but tends to be a large system too.
Therefore it is not possible to present all the functionalities in a
tutorial.


Milena targets several audiences: \textit{assemblers},
\textit{designers}, \textit{providers} and
\textit{architects}. \textit{Assemblers} want to apply and assemble
algorithms to solve image processing, pattern recognition or computer
vision problems, \textit{designers} build new algorithms,
\textit{providers} are interested in developing their own data
structures and extend an existing library and \textit{architects} are
basically developpers extending the core library.


Whatever the kind of user you are, the key to learning how to use
Milena is to become familiar with its palette of objects and the way
of combining them.

As an \textit{assemblers}, you may start with this simple tutorial and the Quick
tour \tofix{ref}. They describe and illustrate the key features of the library.
\textit{Assemblers} getting familiar with Milena and \textit{designers}, should
take a look at the  Quick Reference Guide \tofix{ref!}.
It is a more detailed explanations of the library's features.

\textit{Assemblers} and \textit{designers} may be also interested by all the
examples provided with the documentation and the tutorial. The source code is
available in \hpath{milena/doc/examples} \tofix{ref} and is usually pointed
out and commented by the documentation.

Taking a look at the test suite is also a good idea. The tests usually focus on
a single functionality and handle several use cases which may overlap your needs.
The test suite is located in \hpath{milena/tests} \tofix{ref?}.

Still not enough information? More information about all the routines is
available in the User HTML documentation \tofix{ref}.
It mainly targets \textit{designers} and \textit{providers}.
The latter may also be interested by the Developer HTML documentation
(not available yet).



%**************************
\doxysection{tuto1obtainingthelib}{Obtaining the library}

There are two ways of getting Milena on the web:
\begin{itemize}
  \item Download a tarball/package from the website,
  \item Checkout the SVN repository.
\end{itemize}

Downloading a package or a tarball is the best choice for a new user. Except
for nightly builds which are packages generated every night from the SVN repository,
packages and tarballs contain only a released version of Milena. It guaranties a
certain quality: no building issues, no bugs (ok, maybe some...), \ldots

This tutorial is based on the latest released version of Milena. Therefore,
if you decide to use the SVN version, you may notice different behaviors or results
compared to what it is described in this document.

Using the SVN version implies some drawbacks: the code might crash, not
compile or produce incorrect results.
Besides, The SVN version is always up to date and you may find new functionalities,
bug fixes and new syntax improvements.
This version targets users familiar with build systems and compilation issues.
We strongly advise you to not use it for production use.



%**************************
\doxysection{tuto1downloading}{Downloading the library}



%download page.

%--------------------------
\doxysubsection{tuto1downloadingsvn}{Downloading from SVN}

First, be sure that SVN is already installed on your system.
Open a terminal and type:

\begin{verbatim}
$ svn --version --quiet
1.4.6
\end{verbatim}

You should see your version of SVN installed. If you read 'Command not found'
then you need to install SVN.

Usually, systems providing packages reference SVN's package as 'subversion'.

To install SVN on Debian or Ubuntu, run:

\begin{verbatim}
$ sudo apt-get install subversion
\end{verbatim}

For other distributions, please refer to the user documentation of your system.

Once you have SVN installed, go to the directory where you would like to
download Olena and create a new directory.

\begin{verbatim}
$ cd $HOME
$ mkdir olena
$ cd olena
\end{verbatim}

Then 'checkout' (download) the repository with the following command.

\begin{verbatim}
$ svn co https://svn.lrde.epita.fr/svn/oln/trunk
\end{verbatim}

Enter the 'trunk' directory.

\begin{verbatim}
$ cd trunk
\end{verbatim}

You are now ready to configure the directory and install Milena as described
in section \doxyref{tuto2}.
We invite you to take a look at the description of the directory structure
(section \doxyref{tuto1dirstruct}).
If you encounter any issues in the installation process or if you have any
question, do not forget to join the mailing lists (section \doxyref{tuto1mailinglists})
and/or use the other documentations resources (section ref{tuto1documentation}).





%--------------------------
\doxysubsection{tuto1downloadingpackages}{Downloading packaged releases}

%details.

Milena's packages can be downloaded from:

\href{http://www.lrde.epita.fr/Olena/Download}{http://www.lrde.epita.fr/Olena/Download}

On this page you will find the latest and past releases.
Currently, we provide only '.tar.gz' and 'tar.bz2' archives.

Once downloaded, you just need to uncompress the archive.

For the '.tar.gz' archive:
\begin{verbatim}
$ tar zxvf olena.tar.gz
\end{verbatim}

For the '.tar.bz2' archive:
\begin{verbatim}
$ tar jxvf olena.tar.bz2
\end{verbatim}

Then, enter the new created directory:
\begin{verbatim}
$ cd olena
\end{verbatim}


You are now ready to configure the directory and install Milena as described
in section \doxyref{tuto2}.
We invite you to take a look at the description of the directory structure
(section \doxyref{tuto1dirstruct}).
If you encounter any issues in the installation process or if you have any
question, do not forget to join the mailing lists (section
\doxyref{tuto1mailinglists}) and/or use the other documentations resources
(section \doxyref{tuto1documentation})).



%**************************
\doxysection{tuto1mailinglists}{Join the mailing lists}

Regardless your use of Olena, we strongly advise you to join our mailing lists.
This is the best way to keep up to date about new releases, bug
notifications/fixes and future updates.
This is also a good opportunity to tell us what you would like to find in
Milena and what could be improved.

Currently four mailing-lists are available:

\begin{tabular}{l l}
\textbf{Olena}		& Discussion about the project Olena  \\
\textbf{Olena-bugs}	& Bugs from Olena projects	      \\
\textbf{Olena-core}	& Internal list for the Olena project \\
\textbf{Olena-patches}	& patches for the Olena project	      \\
\end{tabular}

You can subscribe to these mailing lists at the following address:

\begin{center}
\begin{verbatim}
https://www.lrde.epita.fr/mailman/listinfo/
\end{verbatim}
\end{center}

Just click on the name of the mailing list you want to subscribe to and fill
out the form.



%**************************
\doxysection{tuto1dirstruct}{Directory structure}

Milena's directory is composed of several subdirectories. In order to help
you finding what you need, you will find a description of all these
subdirectories.


\vspace{0.5cm}
List of \hpath{milena}'s subdirectories:
\begin{itemize}

\item \dir{apps} --- A full example of a 3D mesh visualisation tool. It
  uses milena.

\item \dir{doc} --- THE directory you must know. Contains all the
  documentation material.

\item \dir{img} --- A set of common test images. They are used in the
  test suite. Feel free to use it in your programs.

\item \dir{mesh} --- A set of 3D meshes. They can be used with the full
  example located in \hpath{milena/apps}.

\item \dir{mln} --- The core of the library. Contains all the library headers.

\item \dir{tests} --- The test suite. Is it subdivided in sub directories.
  The directory hierarchy respects \hpath{milena/mln}'s.

\item \dir{tools} --- Small tools written with milena. They can be used as examples.

\end{itemize}


\vspace{0.5cm}
List of \hpath{mln}'s subdirectories:
\begin{itemize}
  \item \dir{accu} --- Set of Accumulators.
  \item \dir{algebra} --- Algebraic structures like vectors or matrices.
  \item \dir{arith} --- Arithmetical operators.
  \item \dir{binarization} --- Routines to binarize an image.
  \item \dir{border} --- Image border related routines.
  \item \dir{canvas} --- Generic canvas. They define generic ways of browsing
  an image, compute data, \dots.
  \item \dir{convert} --- Automatic conversion mechanism.
  \item \dir{core} --- Core of the library. Here you can find the image types,
  the site set types and basic concepts.
  \item \dir{data} --- Routines that modify image data.
  \item \dir{debug} --- Debug related routines.
  \item \dir{display} --- Display images on the screen.
  \item \dir{draw} --- Draw geometric objects in an image.
  \item \dir{essential} --- Set of essential headers for 1,2,3-D manipulations.
  \item \dir{estim} --- Compute data on image values.
  \item \dir{extension} --- Image extension manipulation.
%  \item \dir{extract} --- FIXME: extract will be removed and replaced by thru().
  \item \dir{fun} --- Set of functions applying on sites, values, \ldots
  \item \dir{geom} --- Functions related to image geometry.
  \item \dir{graph} --- Graph related routines.
  \item \dir{histo} --- Histogram related functions.
  \item \dir{io} --- I/O related routines.
  \item \dir{labeling} --- Labeling related routines.
%  \item \dir{level} --- Point-wise operators on levels.
  \item \dir{linear} --- Linear operators.
  \item \dir{literal} --- Generic image values such as zero, black, white \ldots
  \item \dir{logical} --- Logical operators.
  \item \dir{make} --- Small routines to construct images, windows, \ldots
  \item \dir{math} --- Mathematical functions.
  \item \dir{metal} --- Metallic macros/structures. Static library helping
  developing doing static tests.
  \item \dir{morpho} --- Mathematical morphology.
  \item \dir{norm} --- Norm computation.
  \item \dir{opt} --- Optional routines. Routines which may work on a
  specific image type only.
  \item \dir{pw} --- Point-wise image related routines.
  \item \dir{registration} -- Registration related routine.
  \item \dir{set} --- Set related routines.
  \item \dir{subsampling} --- Sub-sampling related algorithms.
  \item \dir{tag} --- Tag traits.
  \item \dir{test} --- Definition of predicates.
  \item \dir{topo} --- Complex related structures.
  \item \dir{trace} --- Debug trace mechanism.
  \item \dir{trait} --- Internal traits mechanism.
  \item \dir{transform} --- Algorithms based on the data::transform.
  \item \dir{util} --- Various utilitarian classes.
  \item \dir{value} --- Set of value types which can be used in an image.
  \item \dir{win} --- Set of various window kinds.
\end{itemize}


The source code and the material of the documentation is available in \hpath{
milena/doc}.
List of \hpath{doc}'s subdirectories:
\begin{itemize}
\item \dir{examples} --- All the source code of the documentation examples.
\item \dir{benchmark} --- Some benchmarks.
\item \dir{tools} --- Small tools used for generating documentation /
  building examples.

\item \dir{tutorial} --- Tutorial sources.
\item \dir{white\_paper} --- White paper sources.
%\item \dir{technical} --- Technical documentation. (DEPRECATED)
\item \dir{ref\_guide} --- Reference guide sources.
\item \dir{figures} --- Reference figures for documentation generation.
\item \dir{outputs} --- Reference outputs for documentation examples.

\end{itemize}




%**************************
\doxysection{tuto1documentation}{Documentation}

This tutorial is not the only documentation of Milena. Other documents are available:

\begin{itemize}
  \item \dir{White paper} --- A small document of few pages presenting the key
  features of the library. It intents to give a big picture of the library.

  \item \dir{Quick tour} --- It aims at giving an overview of Milena's possibilities.
  It does not only give the concepts but illustrate them with small sample
  codes.

  \item \dir{Quick reference guide} --- Presents in details all the main
  functionalities of Milena.
  Hints and full examples are also provided. The sample codes are commented
  and each concept in the library is detailed. This is the reference document for any
  \textit{assembler} and \textit{algorithm designer}.

  \item \dir{HTML user doc} --- The full documentation of the library. The full
  API is described in details. Each part of the library is classified by
  categories and the source code is directly accessible from the documentation.
  This is the reference document for any \textit{algorithm designer} and/or
  \textit{provider of data structures}.

  \item \dir{Header files} --- Every object or algorithm is declared in a '.hh' file.
  The documentation is provided as comments in these file.
\end{itemize}


%**************************
\doxysection{tuto1community}{Community and Support}

Even though Milena is currently developed by the LRDE in EPITA, we are open
for new contributors.

\begin{itemize}
  \item If you are a user, please send us feedback about the library.
  Did you find what you wanted? Do you miss something?

  \item Please report bugs and defects in the API. Mailing lists are the best
  way for reporting that (section \doxyref{tuto1mailinglists}).

  \item Developers, if you write cool open source programs or algorithms with Milena,
  send them to us. We may ship your code with Olena and/or add it to
  our download page.

  \item Educators, if you use Olena for your courses and you are ready to
  share your materials, you can send it to us through our mailing-lists.

  \item We are also interested in partnership or commercial use of Milena.
  If you are interested, contact us directly (\doxyref{tuto1contacts}).

\end{itemize}


%**************************
\doxysection{tuto1projectstatus}{Project status}

If you want to stay tuned to Milena's development, the best way is probably
the mailing-lists (section \doxyref{tuto1mailinglists}).

There are other ways to get to know what is the status of the project.

\begin{itemize}
\item Olena's trac\\
      \href{https://trac.lrde.org/olena}{https://trac.lrde.org/olena} \\
      Here is the road-map, the current open tickets/bugs/improvements which
      are taken in consideration. A source browser is also available.

\item Olena's Buildfarm \\
      \href{https://buildfarm.lrde.org/buildfarm/oln/}{https://buildfarm.lrde.org/buildfarm/oln/} \\
      The official build-farm. Every night and after each commit, tests
      are compiled and run. The build-farm can show you whether it is safe
      to update your svn copy of Milena or not\ldots

\item Test failures \\
      \href{http://www.lrde.epita.fr/dload/olena/test-failures-daily.html}{http://www.lrde.epita.fr/dload/olena/test-failures-daily.html} \\
      Through this page, you can see exactly which tests do not compile or pass.
      This page is updated every night.

\end{itemize}


%**************************
\doxysection{tuto1briefhistory}{A brief history of Milena}

The Olena project aims at building a scientific computation platform oriented
towards image processing, image recognition, and artificial vision.
This environment is composed of a high performance generic library (Milena),
a set of tools for shell scripts, together with, in the more distant future,
an interpreter (a la Octave, MatLab etc.) and a visual programming environment.

The Olena project started in 2000 from a small prototype on 2-D images.
From November 2001 to April 2004, this prototype evolved from version 0.1 to 0.10.
More image types were supported and the level of genericity expected from the
library was partially obtained. During these three years, the prototype was used
to experiment with genericity and to try to meet our objectives.
In February 2007, Olena 0.11 was released to conform modern C++ compilers.
At that time, the code was not enough readable though and the compilation time
was too long.

Since June 2007 up to now, The library of the Olena platform is called Milena
and the library has been rewritten. The programming  paradigm has been
simplified: the code is more readable and the compilation time is acceptable.
The level of genericity still meets our objectives though.

Milena is now getting ready for being considered as stable and distributable.
The core of the library is getting frozen and we aim at enriching the library,
its documentation and the related tools.


%**************************
\doxysection{tuto1contacts}{Contacts}

If you want to reach us directly, you can contact one of the following people:

\begin{itemize}
  \item Thierry Geraud - Project Manager - thierry.geraud@lrde.epita.fr
  \item Jonathan Fabrizio - jonathan.fabrizio@lrde.epita.fr
  \item Yann Jacquelet - yann.jacquelet@lrde.epita.fr
  \item Guillaume Lazzara - guillaume.lazzara@lrde.epita.fr
  \item Roland Levillain - roland.levillain@lrde.epita.fr
\end{itemize}



\vspace{2cm}
\begin{center}
  \tutotocnext{tuto2}
\end{center}



%====================================
\doxychapter{tuto2}{Installation}

%pre-requis/compatibility
This section describes the installation process of Milena.
Do not forget that Milena is a library, not a program. Therefore, no program
will be installed.

Milena's examples and tests are compiled on the following platforms:
\begin{itemize}
  \item Apple Tiger Darwin 8, PowerPC, GCC 4.0.1
  \item Apple Leopard Darwin 10.5, X86-64, GCC 4.0.1, 4.2
  \item Linux, i486, GCC 3.3, 4.1, 4.2, 4.3
  \item Linux, x86-64, GCC 4.1
\end{itemize}

We guaranty that Milena compiles on these platforms, e.g. Linux and Unix
platforms. It may compiles on other platforms though but we have not tested.
If you did, and you succeeded, please let us know in order to update this
section.

Milena is known NOT to work with GCC-2.95.


Milena is actively developed under Unix systems. As a result, the build system
is based on the Autotools.
Autotools make sure that every dependencies are resolved before compiling
or installing a program.

Milena is different from usual libraries in a way that nothing needs to be
compiled to use it. The library itself is composed of headers which must be
included when you need them.
Then, your application will be compiled with the parts of the library used in
that program. That's all.

So, why do we have a build system? It is useful for installing the library on
your system, generating the doc and compiling the test suite and the examples.



%**************************
\doxysection{tuto2bootstrap}{Bootstrap (SVN Sources)}

If you got the sources from a package/tarball, you can skip this section. Go
to section \doxyref{tuto2configure}.

If you downloaded the sources from the SVN repository, you must launch a
script before configuring the build directory.

Run the following:
\begin{verbatim}
$ cd /my/path/to/olena
$ ./bootstrap
\end{verbatim}

Running 'bootstrap' can take a while. Some files are generated during this
process.
When it's done, you are ready to configure the build directory.



%**************************
\doxysection{tuto2configure}{Configure}

First, make sure you are at the root directory of the milena source:

\begin{verbatim}
$ cd /my/path/to/olena
\end{verbatim}

First, create and enter a build directory:
\begin{verbatim}
$ mkdir build
$ cd build
\end{verbatim}

We are now about to configure the build directory. This process will create
the necessary files to compile documentation, examples and tools and prepare the
installation.

Note that once the configuration ends the build directory cannot be
moved elsewhere without following the following steps again.

\textbf{Important Note}: the installation path prefix must be chosen at this step.
By default, Milena will be installed in /usr/local but you may like to install
it elsewhere. To do so, pass the option \textit{-{}-prefix=/installation/path/prefix}
to the configure script (see below). Replace '/installation/path/prefix' with the
wanted installation path prefix.

now, you can run:
\begin{verbatim}
$ ../configure
\end{verbatim}
OR
\begin{verbatim}
$ ../configure --prefix=/installation/path/prefix
\end{verbatim}

The configure script will perform various tests. If there is no dependency
issues, the last lines shown before the prompt are:

\begin{verbatim}
config.status: creating config.h
config.status: executing depfiles commands
$
\end{verbatim}

And if you type the following command, a '0' is printed out.
\begin{verbatim}
$ echo $?
0
$
\end{verbatim}

The build directory is now configured, the library can be installed.



%**************************
\doxysection{tuto2install}{Install}

First, be sure to be in the build directory. If you followed the previous
steps, the build directory should be in the Milena sources root directory.

\begin{verbatim}
$ cd /my/path/to/olena/build
\end{verbatim}

If you did not change the default install path prefix, set to
\hpath{/usr/local}, you will need to have administrator privileges to
perform the installation. Then, you may type:
\begin{verbatim}
$ sudo make install
\end{verbatim}
You will be prompted for the administrator password.

Otherwise, if you set the install path prefix to a directory own by your
user, simply type:
\begin{verbatim}
$ make install
\end{verbatim}

When the installation is finished, you are done. Milena is installed on your
system. But maybe you would like to build the examples? This is described
in section \doxyref{tuto2optionalcomp}.

A description of the installation content is also available in section
\doxyref{tuto2installcontent}.



%**************************
\doxysection{tuto2optionalcomp}{Optional compilation}

The library itself does not need to be compiled, therefore installing
Milena does not require compilation.

Though, some examples and tools are provided with the library and must be
compiled if you want to use them.

\doxysubsection{tuto2examples}{Examples}

Examples are part of the documentation. The sources are located in
\hpath{milena/doc/examples}.

To compile the examples simply run:
\begin{verbatim}
$ cd /my/path/to/olena/build/milena/doc/examples
$ make
\end{verbatim}

These examples can produce outputs and images. May be you would like
to run all the examples and take a look at the outputs? To do so, run:
\begin{verbatim}
$ cd /my/path/to/olena/build/milena/doc/examples
$ make examples
\end{verbatim}

Text and image outputs will be respectively stored in
\hpath{build/milena/doc/outputs} and \hpath{build/milena/doc/figures}.



\doxysubsection{tuto2tools}{Tools}

Few tools are provided with Milena. They can be considered as full program
examples.

Currently two tools are available: \\

\begin{tabular}{l l}
area\_flooding.cc & \tofix{description} \\
\hline
seed2tiling.cc & \tofix{description} \\
\end{tabular}

%
\bigskip
%

To build these tools, run:
\begin{verbatim}
$ cd /my/path/to/olena/build/milena/tools
$ make
\end{verbatim}


\doxysubsection{tuto2tests}{Tests}

The test suite used for Milena's development is shipped with the library.
It is usually useless for simple users and tends to be used by developers
extending the library.

In order to build and run it, just do the following:
\begin{verbatim}
$ cd /my/path/to/olena/build/milena/tests
$ make check
\end{verbatim}

Running the test suite is memory and CPU consuming and will take a while.


%**************************
\doxysection{tuto2installcontent}{Installation content}

Once installed, Milena's files are located in the installed path prefix
you passed to the configure script or in the default path /usr/local.

In the installation path prefix, Milena's files are located in:

\begin{itemize}
  \item include/mln/ --- The library. All the headers are located here.
  \item share/olena/images --- Mesh sample files which may be used with
  example programs.
  \item share/olena/doc --- HTML and PDF documentation.
\end{itemize}

\vspace{2cm}
\begin{center}
  \tutotoc{tuto1}{tuto3}
\end{center}


%====================================
\doxychapter{tuto3}{Getting started with Milena}

%**************************
\doxysection{tuto3getfamiliargen}{Getting familiar with genericity}

One of Milena's main features is its genericity. In order to understand how to
take benefit of it, let's see what genericity really means for us and how it is
illustrated in the library.

A \B{Generic algorithm} is written once, without duplicates, and works on
different kinds of input.

Let's have a look to a small example. In any image processing library, we may be
interested in a small routine to fill an image with data. A common
implementation would look like this one:

\doxyrawcode{tuto3/fill_non_generic}

See milena/doc/examples/tuto3/fill\_non\_generic.cc.


In this example, there are a lot of \B{implicit} assumptions about the input:
\begin{itemize}
  \item The input image has to be 2D;
  \item Its definition domain has to be a rectangle starting at (0,0);
  \item Data cannot be of a different type than \type{unsigned char};
  \item Image data need to be stored as a 2D array in RAM.
\end{itemize}
So, what would happen if we would like to use it for 3D images, use rgb8 as
value or even work on a region of interest?

This implementation would require to be re-implemented and the user would have to
deal with the various versions of the fill routine. For the developer, it is error
prone, redundant and hard to maintain. For the user, it is confusing and forces
to always think about what he is manipulating.
According to our definition, this algorithm is clearly \B{not} generic.

This is not acceptable and that's why Milena is developed considering
genericity and user/developer friendliness.

With Milena, the previous example would be written as follow:

\doxycode{fill}

In this version, the routine can take any kind of image types as arguments. So
it is for the values: the expected type depends on the value used in the
given image.
The \code{for\_all} loop is also significantly generic to support any kind of
images since the iterator guarantees it will pass through every sites.

This code is more generic and remains really close to the common description of
the generic algorithm.

As a result, with this algorithm we can fill an image,...
\doxycode[3]{fill}
\doxyfigure[2]{fill}{3cm}

... Or fill only a region of interest (a set of points).
\doxycode[2]{fill}
\doxyfigure[1]{fill}{3cm}



%**************************
\doxysection{tuto3firstgenalgo}{First generic algorithm}
In this section, we will introduce several routines/tools which are useful while
writing generic algorithms. It is more important to focus on these
routines/tools than what this program actually does.


Here is the full example:

\doxycode[1]{tuto3_first_routine}
Let's see the different parts of the algorithm.


\doxycode[2]{tuto3_first_routine}
The prototype is restrictive enough, readable and still generic.
We use concepts to statically check that the generic type passed as
parameter is what the routine expects. The ``exact'' image type is \type{I}. For
instance an image of type \type{image2d} inherits from \type{Image$<$image2d$>$}. So
an \type{image2d} is an \type{Image$<$I$>$}.
Note that the return type of this function is defined by a macro.
\code{mln\_concrete} is a macro hiding tricky mechanisms (traits) used in Milena.
The important point to remember is that a generic function should not return
\type{I} directly but \code{mln\_concrete(I)} instead.


\doxycode[3]{tuto3_first_routine}
Like any Milena's routine, note that we use \code{trace}. This debugging tool
will be detailed in section \doxyref{tuto3debughints}.


\doxycode[4]{tuto3_first_routine}
Since the function take some arguments as concept objects, these object cannot
be used as such. Indeed, concepts are empty shells only used for dispatching and
concept checking, that's the reason why they are parameterized with their exact
type. The exact type let us know what is the real type of the object. To get an
object with the exact type, simply call \code{exact()}.
Of course, it is always a good idea to add few preconditions to help during
debug.


\doxycode[5]{tuto3_first_routine}
In this portion of code, the image is labeled and the number of sites per label
is computed. This code does not depend on the image type at all. Again, a macro
\code{mln\_ch\_value} (``mln change value'') helps us. \code{labeling::blobs} is
a routine returning an image of the same kind as the input image but with a
different value. \code{mln\_ch\_value} enables the possibility of doing that,
whatever the image type \type{I} and whatever its value type, it returns the
same image type with a different value type.


\doxycode[6]{tuto3_first_routine}
The output image is declared here. Like any variable, it must be initialized at
some point. To do so, \code{initialize()} is provided. It is a generic routine
which can initialize the geometry of any image kind with another image of the
same kind.
After this call, \var{output} has a valid domain and is valid. It can be used in
an algorithm, here \code{data::fill}, to have its values modified.
Note that the value passed to \code{data::fill} is also generic. The library
includes few generic common values from which any value type can convert to.
\code{literal::one} is one of them. It is a generic one value which can convert
to every value type in the library.


\doxycode[7]{tuto3_first_routine}
In this part, every region from the labeled image, of which cardinality is lower
than 10 sites, is set to \val{literal::zero} in \var{output}.
Once again, a generic value is used in order to avoid constraints on the image
value type.


\doxycode[8]{tuto3_first_routine}
Don't forget to close the trace before exiting the function. Then return the
result.



%FIXME: add an example to show how a routine behavior depends on its arguments.
%       => cf. des images etendues ou non et un parcours de voisinage.


%**************************
\doxysection{tuto3compilhints}{Compilation}

\doxysubsection{tuto3howtocompile}{Include path}

If Milena has been installed in a custom directory, e.g. not /usr/include or
/usr/local/include, the path to the library headers must be passed to the
compiler.

With g++ and MinGW, the option  is \B{-I$<$path$>$}.
\begin{verbatim}
$ g++ -Ipath/to/mln my_program.cc
\end{verbatim}

For other compilers, please look at the documentation and search for ``include
path''.


\doxysubsection{tuto3liblink}{Library linking}
As it is usually expected when using a library, no library linking is needed for
the library itself.
Milena is a ``header only'' library and is compiled ``on demand'' with your
program.

If you use specific input/output you may need to link your program with the
right graphic library. For more information, please refer to section
\doxyref{inputoutput} in the Quick Reference Guide.


\doxysubsection{tuto3compildndebug}{Disable Debug}
By default, Olena enables a lot of internal pre and post conditions. Usually,
this is a useful feature and it should be enabled. It can heavily slow down a
program though and these tests can be disabled by compiling using -DNDEBUG:

\begin{verbatim}
$ g++ -DNDEBUG -Ipath/to/mln my_program.cc
\end{verbatim}

\doxysubsection{tuto3compoptimflags}{Compiler optimization flags}

In this section you will find remarks about the compiler optimization flags and
their impact on the compilation and execution time.


\doxysubsubsection{tuto3compoptimgcc}{GCC}

\begin{itemize}
  \item \B{-O0}, combined with -DNDEBUG, it leads to the fastest compilation
  time. The execution is somewhat slow though since dispatch functions and one
  line members are not inlined by the compiler.
  \item \B{-O1}, best compromise between compilation time and execution time.
  \item \B{-O2}, \B{-O3}, combined with -DNDEBUG, it leads to the best execution
  time. However these optimizations dramatically slow down the compilation and
  requires much more memory at compile time.
\end{itemize}

\doxysubsubsection{tuto3compoptimother}{Other compilers}

Currently, we have not tested different optimization flags with other
compilers. If you did, please report us your results.



%**************************
\doxysection{tuto3debughints}{Debug hints}

\doxysubsection{tuto3gdbhints}{Using assertions and GDB}
As said above, Milena already includes a lot of post and pre conditions.
Thus, if you made a mistake in your code there is a high probability that it
will be detected at run time. If an assertion fails, we advice you to compile
with the following options:

\begin{verbatim}
$ g++ -ggdb -Ipath/to/mln my_program.cc
\end{verbatim}

Note that you \B{MUST NOT} compile with \var{-DNDEBUG} since assertions will be
disabled.
Once compiled, restart the program with GDB.

\begin{verbatim}
$ gdb ./my_program
\end{verbatim}

In the GDB console, run it again.
\begin{verbatim}
(gdb) run <any parameter you may want to pass to the program>
\end{verbatim}

When an assertion fails, in the GDB console simply type:
\begin{verbatim}
(gdb) bt
\end{verbatim}

The full backtrace will be printed out and you will be able to find from where
the error come from. The filenames, the line numbers and the parameters values
are printed out in the backtrace as you can see in the following example:

\begin{verbatim}
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7d00640 in raise () from /lib/i686/cmov/libc.so.6
#2  0xb7d02018 in abort () from /lib/i686/cmov/libc.so.6
#3  0xb7cf95be in __assert_fail () from /lib/i686/cmov/libc.so.6
#4  0x0804e094 in mln::image2d<bool>::has (this=0xbff32f34, p=@0xbff32f3c)
    at /lrde/stockholm/lazzara/svn/olena/git/oln/milena/mln/core/image/image2d.hh:442
#5  0x0804e6d7 in mln::image2d<bool>::operator() (this=0xbff32f34, p=@0xbff32f3c)
    at /lrde/stockholm/lazzara/svn/olena/git/oln/milena/mln/core/image/image2d.hh:460
#6  0x080490b0 in main () at test.cc:18
\end{verbatim}



\doxysubsection{tuto3traces}{Traces}
Sometimes, compiling for GDB without optimization flags and with debug
assertions enabled could lead to execution time dramatically high.
If the function parameter values are not necessary for debugging,
a good alternative is the trace system provided in Milena.
Each time a routine is called, a trace log is written.

This trace allows to follow the stack trace at runtime. It also provides the
time passed in each function call if the call last at least 10ms.

In order to enable traces in a program, set the related global variable to
true:
\begin{verbatim}
...
trace::quiet = true;
...
\end{verbatim}

Since it's a global variable, at anytime in the source code, the trace can be
enabled/disabled.

Traces are enabled:
\doxycode[1]{tuto3_trace}
\code{labeleling::blobs} is run and the debug is then disabled.
\doxycode[2]{tuto3_trace}

The previous code will produce the following trace:

\begin{verbatim}
labeling::blobs {
  core::initialize {}
  data::fill {
    data::fill_with_value {
      data::impl::fill_with_value_one_block {
        data::memset_ {
          data::impl::memset_ {}
        } data::memset_
      } data::impl::fill_with_value_one_block
    } data::fill_with_value
  } data::fill
} labeling::blobs - 0.08s
\end{verbatim}

As you can see, \code{labeling::blobs} is located just after having set
\var{trace::quiet} to \val{true} so its trace is part of the output.
\code{geom::bbox}'s trace is not part of the output though since traces have
been disabled just before it is called.


\doxysubsection{tuto3debugroutines}{Debug routines}
Milena also provides a lot of debug tools. Here is a small list of the tools:
\begin{itemize}
  \item mln::debug::println, print an image in the console.
  \doxycode[1]{tuto3_println}
  \doxymoutput[1]{tuto3_println}

  \item mln::debug::println\_with\_border, print an image in the console withs
  its border.
  \doxycode[2]{tuto3_println}
  \doxymoutput[2]{tuto3_println}

  \item mln::labeling::colorize, colorize a label image with random colors.
  \doxycode[1]{tuto3_colorize}

  \begin{center}
    \begin{tabular}{c c c}
      \doxyfigure[1]{tuto3_colorize}{3cm} & ~\huge{$\rightarrow$}~ &
      \doxyfigure[2]{tuto3_colorize}{3cm} \\
    \end{tabular}
  \end{center}


  \item mln::labeling::superpose, Superpose two images.

  \item mln::labeling::filename, easily format debug file names.

\end{itemize}


%A very simple processing chain; the target is the end-user!
%
%OR (?)
%this chain plus a sample tiny generic algorithm
%
%** misc
%/!\ step by step...
%compilation time w.r.t compilation options (O1, DNDEBUG).

\vspace{2cm}
\begin{center}
  \tutotoc{tuto2}{tuto4}
\end{center}


%====================================
\doxychapter{tuto4}{Data representation}

This chapter aims at explaining how images are stored and which objects compose
an image in Milena. We will start to talk about the localization of a pixel and
then the image itself which stores the values.


%**************************
\doxysection{tuto4sites}{Sites}

A pixel is an element having both information, localization and
value. In Milena, we make a difference between a pixel, a pixel value and a pixel
location. Thus, in order to refer to a pixel location, we have the site concept.
A site can be any kind of localization element.
For instance, in an image defined on a 2D regular grid, it is a 2D point with
\var{row} and \var{col} coordinates.

\doxycode{tuto4_point2d}

Output:
\doxyoutput{tuto4_point2d}

The image site type is defined by its underlying site set.


%**************************
\doxysection{tuto4sitesets}{Site sets}

Site sets are mainly used to define image domains. They hold all the available
sites in an image, consequently they do not store any values.

Site sets can used as standalone containers.

A list of available site sets is available in section \doxyref{siteset}.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% MOVE PARTS OF THE NEXT CHAPTERS RIGHT HERE. %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%--------------------------
\doxysubsection{tuto4createsiteset}{Creating a site set}

In this section, we will detail how to create common site sets.

The most used site set is \type{mln::box}. The main reason is that
common images have this kind of domain. Since it is a plain set only
two sites are needed to define a box: the top left corner, \var{pmin},
and the bottom right corner, \var{pmax}.

By default, \var{pmin} is set to \val{(0,0)} so a box can be
constructed from given \var{pmax} coordinates:

\doxycode[1]{tuto4_site_set_create}

This box is defined from \val{(0,0)} to \val{(4,4)} :

\doxymoutput[1]{tuto4_site_set_create}

A box can also starts from a site different from \val{(0,0)}.

\doxycode[4]{tuto4_site_set_create}

This box is defined from \val{(0,0)} to \val{(4,4)} :

\doxymoutput[3]{tuto4_site_set_create}


Another common site set is \type{p\_array}. It contains only sites which have been added to it.

\doxycode[2]{tuto4_site_set_create}

This site only contains :

\doxymoutput[2]{tuto4_site_set_create}


%--------------------------
\doxysubsection{tuto4accesstosites}{Getting access to sites}



%**************************
\doxysection{tuto4images}{Images}

In milena, an image is seen as a composition of both a site set and a function
mapping a site to a value.

%--------------------------
\doxysubsection{tuto4createimate}{Creating an image}

In this section, we will detail how to create common images.

%--------------------------
\doxysubsection{tuto4readimage}{Reading an image from a file}

%--------------------------
\doxysubsection{tuto4accessdata}{Accessing data}



\vspace{2cm}
\begin{center}
  \tutotoc{tuto3}{tuto5}
\end{center}



%====================================
\doxychapter{tuto5}{Load and save images}

After this step you should know how to:
\begin{itemize}
\item load an image,
\item save an image.
\end{itemize}

\vspace{2cm}
Currently, Olena supports the following input image formats:
\begin{itemize}
  \item PBM
  \item PFM
  \item PGM
  \item PNM
  \item PPM
\end{itemize}

This support is provided through two headers for each type, \header{save.hh} and
\header{load.hh}.
They are located in \hpath{mln/io/$<$image-format$>$/}.

Once the right header is included, the image can be loaded:

\doxycode{ima-load}

If you wan to save an image, simply call the save routine in the proper namespace:
\doxycode{ima-save}

According to the image value type, the proper file format must be chosen.
The supported file formats and their associated image value types are listed
in section \doxyref{imaio}.

\vspace{2cm}
\tutotoc{tuto4}{tuto6}



%====================================
\doxychapter{tuto6}{Create your first image}

After this step you should know how to:
  \begin{itemize}
    \item create an image,
    \item display an image in console mode.
  \end{itemize}

\doxysee{tuto2_first_image.cc}


\vspace{2cm}
First, declare an array of bool which will represent the image grid. Each each
cell in this grid is a site and each cell contains a value, \val{true} or
\val{false}.
\doxycode[1]{tuto2_first_image}

From that grid, simply call make::image to get an image initialized with that
data.
\doxycode[2]{tuto2_first_image}
This way of initializing an image is the most common one. However, there are
several other ways described in section \doxyref{imacreate}.


To be sure that the data is correctly initialized, it is possible to display the
image in the standard output using debug::println.
\doxycode[3]{tuto2_first_image}
Output:
\doxyoutput{tuto2_first_image}

Finally, you may want to save the image. Since we use bool as image value, the
PBM format is the best choice. Therefore, we use io::pbm::save.
\doxycode[4]{tuto2_first_image}

The output image looks like the following: \\

\doxyfigure{tuto2_first_image}{3cm}

In this first step we used a boolean image. Many other value types are available
though. A more detailed description can be found in section
\doxyref{imapossvalues}.

\vspace{2cm}
\begin{center}
  \tutotoc{tuto5}{tuto7}
\end{center}


%====================================
\doxychapter{tuto7}{Read and write images}

After this step you should know how to:
  \begin{itemize}
    \item modify/initialize image values,
    \item copy and paste data to an image.
  \end{itemize}


\doxysee{tuto3_rw_image.cc}

\vspace{2cm}
First create an empty color image with a \var{box2d} of 40x40 as domain.
\doxycode[1]{tuto3_rw_image}

If you want to initialize the image with the color red, simply call data::fill as follows:
\doxycode[2]{tuto3_rw_image}

Updating a site value is also possible using \code{operator()} or the
\code{opt::at()} routine. Here we create a blue square of 10x10 pixels from site
(20, 20) to (30, 30).
\doxycode[3]{tuto3_rw_image}
\doxycode[4]{tuto3_rw_image}

The corresponding image: \\

\doxyfigure[1]{tuto3_rw_image}{3cm}

An image can also be initialized/modified thanks to another image.
Let's load a new image.
\doxycode[5]{tuto3_rw_image}
\var{lena} looks like: \\

\doxyimg{small-enlarged}{3cm}

If we want to initialize \var{ima} with \var{lena}, we can use \code{data::fill}:
\doxycode[6]{tuto3_rw_image}
Output: \\

\doxyfigure[2]{tuto3_rw_image}{3cm} \\
Note that to fill an image with some data, the image domain \must be smaller
or equal to the data.

Likewise, it is possible to paste data from an image to another:
\doxycode[7]{tuto3_rw_image}
Output: \\

\doxyfigure[3]{tuto3_rw_image}{3cm}

More details can be found in sections \doxyref{imaaccessmodval}, \doxyref{fillop} and \doxyref{pasteop} in
the reference guide.

\vspace{2cm}
\begin{center}
  \tutotoc{tuto6}{tuto8}
\end{center}


%====================================
\doxychapter{tuto8}{Regions of interest}

After this step you should know how to:
  \begin{itemize}
    \item take benefit of Olena's genericity,
    \item work only on a region of interest in an image.
  \end{itemize}

\doxysee{tuto4_genericity_and_algorithms.cc}
\vspace{2cm}

In the previous step, we used the routine \code{data::fill} in order to change
the values of an image. It was convenient since we did not need to write any
loop by hand. The problem was that we could not specify which region to fill
with data. This point leads us to talk about the genericity in Olena.
All along this example we will use the routine \code{data::fill} to illustrate
the possibilities in Olena but note that every image types passed to the
routine in this example could be passed to any algorithm in the library
expecting an image.

One main feature of Olena is to be able to easily work on regions of interest in
images. According to the way a region of interest is defined, a specific image
type is associated. Therefore, each algorithm knows exactly what it is working
on and can behave differently in order to be the most efficient as possible.


All along this step, we will use the following image \var{lena} declared as
follow:

\doxycode[1]{tuto4_genericity_and_algorithms}
\doxyimg{small-enlarged}{3cm}

\code{data::fill} has the following prototype:
\doxyrawcode{fill-proto}
So keep in mind that the first argument we will try to construct in each
example is an image. Note that this image \must be writable, e.g. non-const.


%**************************
\doxysection{tuto4imadomainsiteset}{Image domain restricted by a site set}

Here, we would like to fill a small square with green in \var{lena}. We want
this square to be of size 20x20 and to be located at (20,20).
First, we just need to declare this square which is actually a site set, a
\type{box2d}.
\doxycode[2]{tuto4_genericity_and_algorithms}

Then, we just need to tell \code{data::fill} that we would like to fill the
image \var{lena} but only in this restricted part of the image domain.
\doxycode[3]{tuto4_genericity_and_algorithms}
Operator '$|$' can be read 'restricted to'. So below, we wrote 'image \var{lena}
restricted to the region of interest \var{roi}'. Actually this is not directly
\var{lena} which is restricted but its domain.

Note the use of \code{rw()} which is mandatory due to C++ limitations. In C++,
the image created by \code{lena $|$ roi} is \code{const}, e.g. read-only, though
\code{data::fill} expect a \code{non-const} image, e.g. read-write. \code{rw()}
is a workaround to make it read-write.

\begin{center}
  \begin{tabular}{c c c}
    \doxyimg{small-enlarged}{3cm} & ~\huge{$\rightarrow$}~ & \doxyfigure[1]{tuto4_genericity_and_algorithms}{3cm} \\
    \multicolumn{3}{c}{Fill with blue a region of interest defined by a
      \type{box2d}.} \\
  \end{tabular}
\end{center}


%**************************
\doxysection{tuto4imadomainfun}{Image domain restricted by a function}

Sometimes it may not be easy to construct a site set to restrict an image. For
instance, if we would like to fill with green one point out of two in the whole
image, we \textbf{do not want} to write anyloop or construct any site set by hand:
\doxycode[4]{tuto4_genericity_and_algorithms}
\doxycode[5]{tuto4_genericity_and_algorithms}

A shorter way to get exactly the same result, is to define that behavior by a
function. In Milena, a function \code{fun::p2b::chess} is available and does
exactly what we want. Like if it was a site set, simply restrict the image with
the function.

%
%Paste code of p2b::chess?
%

\doxycode[6]{tuto4_genericity_and_algorithms}
\begin{center}
  \begin{tabular}{c c c}
    \doxyimg{small-enlarged}{3cm} & ~\huge{$\rightarrow$}~ & \doxyfigure[2]{tuto4_genericity_and_algorithms}{3cm} \\
    \multicolumn{3}{c}{Fill with green a region of interest defined by a
      \type{Function}.} \\
  \end{tabular}
\end{center}

Note that the functions provided by default in Olena are actually functors.
Thus, they must be constructed like any object which why it is written
\code{lena $|$ fun::p2v::chess()} and not \code{lena $|$ fun::p2v::chess}.


%FIXME: Talk about C functions once it is possible in Milena.


%**************************
\doxysection{tuto4imadomainmask}{Image domain restricted by a mask}

Sometimes instead of having a site site or a function defining the regions of
interest we want to work on, we may have a binary image, e.g. a mask. When a
site has its value set to true, it means it will be considered as part of the
masked image domain. Otherwise, it will not.

We construct a mask, \var{mask}. It is initialized with the same geometry properties as
\var{lena}
(domain, extension...).
\doxycode[7]{tuto4_genericity_and_algorithms}

Then, we cannot restrict directly \var{lena} with \var{mask}. These two images
have the same domain, so \code{lena $|$ mask.domain()} would not do anything.
\var{mask} is a classical image, there is not specific type for mask images.
Therefore, we need to express that we want that binary image to be considered as
a mask.
\doxycode[8]{tuto4_genericity_and_algorithms}
\code{pw::value(mask)} makes explicit the fact that \var{mask} is actually a
mask. It means, that for each site of \var{mask}, if its value is set to
\val{true}, then the value associated to this site in \var{lena} must be set
to green.
In this example, we use two images for two different use case: \var{lena} store
the result and the modifications make by the algorithm and \var{mask} allows the
algorithm to know whether it must treat a site or not.

\begin{center}
  \begin{tabular}{c c c c}
    \doxyimg{small-enlarged}{3cm}  &
    \doxyfigure[3]{tuto4_genericity_and_algorithms}{3cm} &
    ~\huge{$\rightarrow$}~ &
    \doxyfigure[4]{tuto4_genericity_and_algorithms}{3cm}  \\
    \multicolumn{4}{c}{Fill with green a region of interest defined by a mask
      image.} \\
  \end{tabular}
\end{center}


%**************************
\doxysection{tuto4imadomainpredicate}{Image domain restricted by a predicate}

Restricting by a predicate is exactly like restricting with a function. We want
to talk about that separately in order to present the small routines available.
They enable the user to write quick and efficient predicate/function.

The two routines are :
\begin{itemize}
  \item pw::value(Image), as seen in a previous section, it is a way to express
  'for each site value in Image'.
  \item pw::cst(Value), it is a way to specify a value to which a site value can
  be compared.
\end{itemize}

Let's see a common use case.
First, we binarize lena according to specific criterions, only site values with
specific colors are set to true in \var{lena\_bw}. Others are set to false. This
image will be used in order to label the components.
Let's consider a labeled image \var{label}. Each component of \var{lena} is labeled with a unique index.
Now, we consider that that our region of interest is a component with id 16.
Then we want to express 'for each site \var{fill} its value in \var{lena} if its
value in \var{label} is equal to 16'.
\doxycode[9]{tuto4_genericity_and_algorithms}


\doxycode[10]{tuto4_genericity_and_algorithms}

\begin{center}
  \begin{tabular}{c c c c}
    \doxyimg{small-enlarged}{3cm}  &
    \doxyfigure[5]{tuto4_genericity_and_algorithms}{3cm} &
    ~\huge{$\rightarrow$}~ &
    \doxyfigure[6]{tuto4_genericity_and_algorithms}{3cm}  \\
    \multicolumn{4}{c}{Fill with green a region of interest defined by its
      label.} \\
  \end{tabular}
\end{center}


%Disabled until thru_image/fun_image provide working read/write access.
%
%%**************************
%\doxysection{tuto4component}{Image component restricted to a domain}
%
%%FIXME: be more verbose?
%
%It is also possible to restrict an image to one of its component and apply
%various operators upon it. In the following code, the green component of
%this color image is extracted and filled with the maximum value allowed.
%Other components such as red and blue are left unchanged.
%
%\doxycode[11]{tuto4_genericity_and_algorithms}
%
%\begin{center}
%  \begin{tabular}{c c c c}
%    \doxyimg{small-enlarged}{3cm}  &
%%   \doxyfigure[7]{tuto4_genericity_and_algorithms}{3cm} &
%    ~\huge{$\rightarrow$}~ &
%    \doxyfigure[8]{tuto4_genericity_and_algorithms}{3cm}  \\
%    \multicolumn{4}{c}{Set the image green component to its maximum value.} \\
%  \end{tabular}
%\end{center}
%
%
%Thanks to Milena's genericity, it is also possible to combine this operator
%with others. Here the green component is extracted from a region of interest
%and only that part is modified.
%
%\doxycode[12]{tuto4_genericity_and_algorithms}
%
%\begin{center}
%  \begin{tabular}{c c c c}
%    \doxyimg{small-enlarged}{3cm}  &
%    ~\huge{$\rightarrow$}~ &
%    \doxyfigure[9]{tuto4_genericity_and_algorithms}{3cm}  \\
%    \multicolumn{4}{c}{Set the green component of a region of interest
% to its maximum value.} \\
%  \end{tabular}
%\end{center}



\vspace{2cm}
\begin{center}
  \tutotocprev{tuto7}
\end{center}


%\end{htmlonly}


\end{document}
