* demos/graph/region_adjacency_graph.cc: do not draw the vertex
associted to the background.
* doc/Makefile.am: Add borders to documentation images.
* doc/ref_guide/ref_guide.tex,
* doc/tutorial/tutorial.tex: Fix typos.
* mln/make/box2d.hh,
* mln/estim/min_max.hh.
* mln/accu/stat/min_max.hh,
* mln/core/concept/image.hh,
* mln/core/routine/exact.hh: Reheader.
* mln/data/compute.hh: Update doc.
* mln/transform/hough.hh: Fix an unused variable.
* mln/world/inter_pixel/is_separator.hh: Fix indentation add doc.
* mln/world/inter_pixel/separator_to_pixels.hh: move debug code
between NDEBUG guards.
---
milena/ChangeLog | 27 +++++++
milena/demos/graph/region_adjacency_graph.cc | 13 ++--
milena/doc/Makefile.am | 2 +-
milena/doc/ref_guide/ref_guide.tex | 74 +++++++++-----------
milena/doc/tutorial/tutorial.tex | 70 ++++++++-----------
milena/mln/accu/stat/min_max.hh | 3 +-
milena/mln/core/concept/image.hh | 3 +-
milena/mln/core/routine/exact.hh | 3 +-
milena/mln/data/compute.hh | 4 +-
milena/mln/estim/min_max.hh | 3 +-
milena/mln/make/box2d.hh | 3 +-
milena/mln/transform/hough.hh | 16 +++--
milena/mln/world/inter_pixel/is_separator.hh | 39 ++++++-----
.../mln/world/inter_pixel/separator_to_pixels.hh | 8 ++
14 files changed, 148 insertions(+), 120 deletions(-)
diff --git a/milena/ChangeLog b/milena/ChangeLog
index 2689703..99015ff 100644
--- a/milena/ChangeLog
+++ b/milena/ChangeLog
@@ -1,5 +1,32 @@
2009-07-06 Guillaume Lazzara <guillaume.lazzara(a)lrde.epita.fr>
+ Small fixes.
+
+ * demos/graph/region_adjacency_graph.cc: do not draw the vertex
+ associted to the background.
+
+ * doc/Makefile.am: Add borders to documentation images.
+
+ * doc/ref_guide/ref_guide.tex,
+ * doc/tutorial/tutorial.tex: Fix typos.
+
+ * mln/make/box2d.hh,
+ * mln/estim/min_max.hh.
+ * mln/accu/stat/min_max.hh,
+ * mln/core/concept/image.hh,
+ * mln/core/routine/exact.hh: Reheader.
+
+ * mln/data/compute.hh: Update doc.
+
+ * mln/transform/hough.hh: Fix an unused variable.
+
+ * mln/world/inter_pixel/is_separator.hh: Fix indentation add doc.
+
+ * mln/world/inter_pixel/separator_to_pixels.hh: move debug code
+ between NDEBUG guards.
+
+2009-07-06 Guillaume Lazzara <guillaume.lazzara(a)lrde.epita.fr>
+
* mln/transform/internal/distance_functor.hh: Split declaration and
implementation.
diff --git a/milena/demos/graph/region_adjacency_graph.cc
b/milena/demos/graph/region_adjacency_graph.cc
index 80ecd4b..44a2f17 100644
--- a/milena/demos/graph/region_adjacency_graph.cc
+++ b/milena/demos/graph/region_adjacency_graph.cc
@@ -137,11 +137,12 @@ namespace mln
dpoint2d br(3,3);
mln_piter(V) p(ima_v.domain());
for_all(p)
- {
- box2d b(p + tl, p + br);
- b.crop_wrt(ima.domain());
- data::fill((ima | b).rw(), convert::to<mln_value(I)>(ima_v(p)));
- }
+ if (p.id() != 0)
+ {
+ box2d b(p + tl, p + br);
+ b.crop_wrt(ima.domain());
+ data::fill((ima | b).rw(), convert::to<mln_value(I)>(ima_v(p)));
+ }
return ima;
}
@@ -205,7 +206,7 @@ int main()
/// Construct a vertex image.
mln_VAR(ima_v, make::vertex_image(g, basin_centers, mean_values));
- /// Construct a edge image.
+ /// Construct an edge image.
mln_VAR(ima_e, make::edge_image(ima_v, dist()));
io::ppm::save(make_debug_graph_image(input_ppm, ima_v, ima_e, literal::white),
diff --git a/milena/doc/Makefile.am b/milena/doc/Makefile.am
index e837ea2..57c3810 100644
--- a/milena/doc/Makefile.am
+++ b/milena/doc/Makefile.am
@@ -160,7 +160,7 @@ $(srcdir)/figures.stamp: $(FIGURES_SRCDIR)/*.p*m
echo "Converting $$img to PNG"; \
name=`basename $$img` \
ext=`echo $$name | cut -d '.' -f 2`; \
- convert -scale 250 $$img \
+ convert -scale 250 -bordercolor black -border 2x2 $$img \
$(FIGURES_SRCDIR)/`basename $$img $$ext`png \
|| eval $$failcom; \
done
diff --git a/milena/doc/ref_guide/ref_guide.tex b/milena/doc/ref_guide/ref_guide.tex
index 3bfb50e..dec1885 100644
--- a/milena/doc/ref_guide/ref_guide.tex
+++ b/milena/doc/ref_guide/ref_guide.tex
@@ -83,16 +83,6 @@
\begin{latexonly}
\maketitle
-\section*{Copying this document}
-Copyright \copyright{} 2008, 2009 LRDE.
-
-Permission is granted to copy, distribute and/or modify this document under
-the terms of the GNU Free Documentation License, Version 1.2 or any later
-version published by the Free Software Foundation; with the Invariant Sections
-being just ``Copying this document'', no Front-Cover Texts, and no Back-Cover
-Texts.
-
-A copy of the license is provided in the file COPYING.DOC.
\tableofcontents
\end{latexonly}
@@ -173,7 +163,7 @@ $ sudo make install
%**************************
\doxysection{generality}{Generality}
-The following tutorial explains the basic concepts behind Olena and how to use
+The following tutorial explains the basic concepts behind Olena and how to use
the most common objects and routines.
This tutorial includes many code examples and figures. In order to make this
tutorial easier to understand, we will mainly talk about 2D images. This is
@@ -222,11 +212,11 @@ Olena's tarball is structured as follow:
\item technical: technical doc.
\item tutorial: code sample and tutorial.
\end{itemize}
- \item img: a set of sample images.
+ \item img: a set of sample images.
\item mesh: a full example which uses Olena.
\item mln: the library. Contains only headers.
\item tests: test suite.
-% \item tools :
+% \item tools :
\end{itemize}
\item swilena: Python bindings for Olena.
\end{itemize}
@@ -393,7 +383,7 @@ is it's own bounding box.
Output:
\doxyoutput{box2d-bbox}
-A \type{p\_array} does not have the bbox
+A \type{p\_array} does not have the bbox
method since its sites do not have to be adjacent. Maintaining such information, in
order to keep getting the bbox in constant time, would be time and memory
consuming. Instead of providing a method directly in \type{p\_array}, an algorithm is
@@ -466,7 +456,7 @@ The value type can be one of the builtins one:
Other data types are also available:
\begin{tabular}{l|l}
-Value type & underlying data type \\
+Value type & underlying data type \\
\hline
\type{float01\_8} & \type{unsigned long} \\
\type{float01\_16} & \type{unsigned long} \\
@@ -498,7 +488,7 @@ types is actually ``type\_name.hh". For instance, for \type{rgb8}
the header wil
%**************************
\doxysection{imadomain}{Domain}
The site set contains the sites which compose the image. Sites are based on a
-grid so the image depends on that grid as well.
+grid so the image depends on that grid as well.
It means that a 2D images can only be defined by sites based on a 2D grid.
Likewise, an \type{image2d} will always have its bouding box defined by a \type{box2d}.
@@ -564,7 +554,7 @@ Some operations can be performed on the border. The functions are
located in
\bigskip
%
\begin{tabular}{l|p{8cm}}
-Routine & Description \\
+Routine & Description \\
\hline
adjust & Increase the border thickness if it is inferior to a minimum. \\
duplicate & Assign the border with the duplicate of the edges of this image.\\
@@ -597,12 +587,12 @@ The extension supports the following operations. These functions are
located in
\bigskip
%
\begin{tabular}{l|p{10cm}}
-Routine & Description \\
+Routine & Description \\
\hline
adjust & Adjust the extension given a structural element.\\
adjust\_duplicate & Adjust the size of the extension given a structural element and
duplicate the image inner boundary.\\
adjust\_fill & Adjust the size of the extension given a structural element and fill
it with a value.\\
-duplicate & Duplicate the values of the image inner boundary in the extension.\\
+duplicate & Duplicate the values of the image inner boundary in the extension.\\
fill & Fill the extension with a given value.\\
\end{tabular} \\
@@ -750,7 +740,7 @@ Currently, Olena supports the following input image formats:
\item PFM
\item PGM
\item PNM
- \item PPM
+ \item PPM
\end{itemize}
This support is provided through two headers for each type, \header{save.hh} and
@@ -817,7 +807,7 @@ There are several ways to access/modify an image
``\var{ima}'':
\end{itemize}
Most of the time, images can be modified and these two methods can be used both
-to read a value and modify it. Both methods are equivalent.
+to read a value and modify it. Both methods are equivalent.
\doxycode{ima2d-3}
Output:
\doxyoutput{ima2d-3}
@@ -873,7 +863,7 @@ In Olena, there are both the window and neighborhood concept. A window
can be
defined on any site around a central site which may also be included.
A neighborhood is more restrictive and \must not include the central site.
Therefore these two concepts are really similar and are detailed together in
-this section.
+this section.
By default, structural elements are centered. The central site is located at the
origin of the grid: ``\var{literal::origin}''. With \type{image2d}, the central
site is
@@ -895,7 +885,7 @@ win\_c8p & 8-connectivity & \winceight \\
\end{tabular}
%
\bigskip
-%
+%
\subsubsection*{1D Predefined windows}
@@ -1078,7 +1068,7 @@ constant-time.
\doxysection{sitespsitensite}{From psite to site}
In the last example there was an image of type \type{I} such as \type{I::site}
-!= \type{I::psite}.
+!= \type{I::psite}.
In that case, an object of type \type{I::psite} is actually convertible towards an
object of type \type{I::site}. Furthermore, a \type{psite} shall behave as if it was a
\type{site}.
@@ -1187,7 +1177,7 @@ use the \code{for\_all()} loop: \code{data::fill()} and
\code{data::paste()}.
Important note: macros for iterators exist in two versions:
``\code{mln\_*iter}'' and ``\code{mln\_*iter\_}''. The difference is that
the
first version \must be used in templated function whereas the second one \must be
-used in non templated functions.
+used in non templated functions.
If you want a list of all the macros available in Olena, please refert to
section \doxyref{macros}.
@@ -1207,12 +1197,12 @@ In the Olena library, all image types behave like image2d:
the user never has to use "new / delete" (the C++ equivalent for the C
"malloc / free") so she does not have to manipulate pointers or to
directly
access memory.
-
+
$\rightarrow$ Olena prevents the user from making mistakes;
\item Image data/values can be shared between several variables and the memory
used for image data is handled by the library.
-
+
$\rightarrow$ Memory management is automatic.
\end{itemize}
@@ -1245,11 +1235,11 @@ Output:
\hline
Routine name & Description \\ \hline
duplicate() & creates a deep copy of an object. Any shared data is
-duplicated. \\
+duplicated. \\
-data::fill() & fill an object with a value. \\
+data::fill() & fill an object with a value. \\
-data::paste() & paste object data to another object. \\
+data::paste() & paste object data to another object. \\
labeling::blobs() & find and label the different components of an image. \\
@@ -1292,7 +1282,7 @@ val)}. When forgetting the \code{rw()} call, it does not compile.
%**************************
\doxysection{pasteop}{Paste}
We then define below a second image to play with. As you can see this image has
-data for the sites (5, 5) to (14, 14) (so it has 100 sites).
+data for the sites (5, 5) to (14, 14) (so it has 100 sites).
\doxycode{paste-call-1}
Output:
@@ -1342,7 +1332,7 @@ Output: \\
Then label this image thanks to \code{labeling::blobs()}:
\doxycode[2]{labeling-compute}
-
+
Output: \\
\begin{center}
@@ -1362,7 +1352,7 @@ This parameter \must be of the same type as the returned image
value.
\textbf{Full namespace} & mln::logical \\
- \textbf{Routine(s)} & not\_(),
+ \textbf{Routine(s)} & not\_(),
not\_inplace() \\
\hline
\end{tabular}
@@ -1495,7 +1485,7 @@ Then, use \code{labeling::compute()} with the bbox accumulator:
\code{labeling::compute()} hold an accumulator for each component, which means it
returns an array of accumulator results.
-In this case, it returns an array of \type{box2d}.
+In this case, it returns an array of \type{box2d}.
\textbf{Important note:} since \code{labeling::blobs()} labels the component from 1 and
set the background to 0, we will want to iterate from 1 to nlabels included.
@@ -1506,7 +1496,7 @@ Output:
\subsection{Routines based on accumulators and *::compute()}
In order to make the code cleaner, small routines are available for the
-most used accumulators.
+most used accumulators.
Currently there are the following routines:\\
@@ -1551,7 +1541,7 @@ boolean. These functions are actually a sort of predicate. A common
point to value function used in the given image. C functions can also be used as
predicate by passing the function pointer.
-You can easily get a \type{Function\_p2b} by comparing the value returned
+You can easily get a \type{Function\_p2b} by comparing the value returned
by a \type{Function\_p2v} to another Value.
The following sample codes illustrate this feature.
@@ -1580,7 +1570,7 @@ Output:
\doxysubsection{restrictpred}{Restrict an image with a predicate}
In the following example, we aim at extracting a component from an image and
-create a new image with it.
+create a new image with it.
First, find and label the components.
\doxycode[2]{fill-subdomain}
@@ -1672,7 +1662,7 @@ You can extend the range of supported files by installing
third-parties librarie
\begin{itemize}
\item ImageMagick: support for usual images (PNG, TIFF, JPEG, ...)
- \item GDCM: support for DICOM medical images
+ \item GDCM: support for DICOM medical images
\end{itemize}
\doxysection{ioim}{ImageMagick}
@@ -1708,14 +1698,14 @@ You can extend the range of supported files by installing
third-parties librarie
%\begin{htmlonly}
%\doxychapter{2}{}
%\end{htmlonly}
-\doxychapter{graphandima}{Graphes and images}
+\doxychapter{graphandima}{Graphs and images}
%FIXME: REWRITE
%**************************
\doxysection{graphdesc}{Description}
-Olena enables the possibility of using graphes with images.
-Graphes can help you to handle directly parts of an image and represent their
+Olena enables the possibility of using graphs with images.
+Graphs can help you to handle directly parts of an image and represent their
relationship.
Specific data can be associated to each vertex and/or edges.
@@ -1770,7 +1760,7 @@ Output:
\doxymoutput[1]{graph-iter}
Graphs have iterators like any other site sets and also provide
-specific iterators in order to iterate over graphes in a more intuitive way.
+specific iterators in order to iterate over graphs in a more intuitive way.
Iteration over the adjacent edges of all the vertices:
\doxycode[2]{graph-iter}
diff --git a/milena/doc/tutorial/tutorial.tex b/milena/doc/tutorial/tutorial.tex
index 168160f..3d2e847 100644
--- a/milena/doc/tutorial/tutorial.tex
+++ b/milena/doc/tutorial/tutorial.tex
@@ -80,16 +80,6 @@
\begin{latexonly}
\maketitle
-\section*{Copying this document}
-Copyright \copyright{} 2008, 2009 LRDE.
-
-Permission is granted to copy, distribute and/or modify this document under
-the terms of the GNU Free Documentation License, Version 1.2 or any later
-version published by the Free Software Foundation; with the Invariant Sections
-being just ``Copying this document'', no Front-Cover Texts, and no Back-Cover
-Texts.
-
-A copy of the license is provided in the file COPYING.DOC.
\tableofcontents
\end{latexonly}
@@ -154,7 +144,7 @@ There are two ways of getting Milena on the web:
\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,
+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
@@ -202,7 +192,7 @@ $ sudo apt-get install subversion
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
+Once you have SVN installed, go to the directory where you would like to
download Olena and create a new directory.
\begin{verbatim}
@@ -210,7 +200,7 @@ $ cd $HOME
$ mkdir olena
$ cd olena
\end{verbatim}
-
+
Then 'checkout' (download) the repository with the following command.
\begin{verbatim}
@@ -223,7 +213,7 @@ Enter the 'trunk' directory.
$ cd trunk
\end{verbatim}
-You are now ready to configure the directory and install Milena as described
+You are now ready to configure the directory and install Milena as described
in section \ref{tuto2}.
We invite you to take a look at the description of the directory structure
(section \ref{tuto1dirstruct}).
@@ -265,7 +255,7 @@ $ cd olena-1.0
\end{verbatim}
-You are now ready to configure the directory and install Milena as described
+You are now ready to configure the directory and install Milena as described
in section \ref{tuto2}.
We invite you to take a look at the description of the directory structure
(section \ref{tuto1dirstruct}).
@@ -334,7 +324,7 @@ List of \hpath{milena}'s subdirectories:
\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.
+ The directory hierarchy respects \hpath{milena/mln}'s.
\item \dir{tools} --- Small tools written with milena. They can be used as examples.
@@ -433,17 +423,17 @@ This tutorial is not the only documentation of Milena. Other
documents are avail
\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
+ and each concept in the library is detailed. This is the reference document for any
\textit{end user} 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
+ 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.
+ The documentation is provided as comments in these file.
\end{itemize}
@@ -505,10 +495,10 @@ There are other ways to get to know what is the status of the
project.
\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.
+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.
+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.
@@ -522,7 +512,7 @@ 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.
+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,
@@ -553,7 +543,7 @@ If you want to reach us directly, you can contact one of the following
people:
%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.
+will be installed.
Milena's examples and tests are compiled on the following platforms:
\begin{itemize}
@@ -594,7 +584,7 @@ If you got the sources from a package/tarball, you can skip this
section. Go
to section \ref{tuto2configure}.
If you downloaded the sources from the SVN repository, you must launch a
-script before configuring the build directory.
+script before configuring the build directory.
Run the following:
\begin{verbatim}
@@ -666,13 +656,13 @@ 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.
+steps, the build directory should be in the Milena sources root directory.
\begin{verbatim}
$ cd /my/path/to/olena-1.0/build
\end{verbatim}
-If you did not change the default install path prefix, set to
+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}
@@ -701,13 +691,13 @@ A description of the installation content is also available in
section
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
+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}.
+\hpath{milena/doc/examples}.
To compile the examples simply run:
\begin{verbatim}
@@ -938,11 +928,11 @@ compiler.
With g++ and MinGW, the option is \B{-I$<$path$>$}.
\begin{verbatim}
-$ g++ -Ipath/to/mln my_program.cc
+$ g++ -Ipath/to/mln my_program.cc
\end{verbatim}
For other compilers, please look at the documentation and search for ``include
-path''.
+path''.
\doxysubsection{tuto3liblink}{Library linking}
@@ -962,7 +952,7 @@ 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
+$ g++ -DNDEBUG -Ipath/to/mln my_program.cc
\end{verbatim}
\doxysubsection{tuto3compoptimflags}{Compiler optimization flags}
@@ -976,7 +966,7 @@ their impact on the compilation and execution time.
\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.
+ 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
@@ -1000,7 +990,7 @@ 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
+$ g++ -ggdb -Ipath/to/mln my_program.cc
\end{verbatim}
Note that you \B{MUST NOT} compile with \var{-DNDEBUG} since assertions will be
@@ -1008,7 +998,7 @@ disabled.
Once compiled, restart the program with GDB.
\begin{verbatim}
-$ gdb ./my_program
+$ gdb ./my_program
\end{verbatim}
In the GDB console, run it again.
@@ -1018,7 +1008,7 @@ In the GDB console, run it again.
When an assertion fails, in the GDB console simply type:
\begin{verbatim}
-(gdb) bt
+(gdb) bt
\end{verbatim}
The full backtrace will be printed out and you will be able to find from where
@@ -1041,7 +1031,7 @@ are printed out in the backtrace as you can see in the following
example:
\doxysubsection{tuto3traces}{Traces}
Sometimes, compiling for GDB without optimization flags and with debug
-assertions enabled could lead to execution time dramatically high.
+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.
@@ -1147,7 +1137,7 @@ then the image itself which stores the values.
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.
+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.
@@ -1224,7 +1214,7 @@ Currently, Olena supports the following input image formats:
\item PFM
\item PGM
\item PNM
- \item PPM
+ \item PPM
\end{itemize}
This support is provided through two headers for each type, \header{save.hh} and
@@ -1404,7 +1394,7 @@ First, we just need to declare this square which is actually a site
set, a
\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.
+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
@@ -1513,7 +1503,7 @@ The two routines are :
be compared.
\end{itemize}
-Let's see a common use case.
+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.
diff --git a/milena/mln/accu/stat/min_max.hh b/milena/mln/accu/stat/min_max.hh
index a0032b8..edc43dd 100644
--- a/milena/mln/accu/stat/min_max.hh
+++ b/milena/mln/accu/stat/min_max.hh
@@ -1,4 +1,5 @@
-// Copyright (C) 2007, 2008, 2009 EPITA Research and Development Laboratory (LRDE)
+// Copyright (C) 2007, 2008, 2009 EPITA Research and Development
+// Laboratory (LRDE)
//
// This file is part of Olena.
//
diff --git a/milena/mln/core/concept/image.hh b/milena/mln/core/concept/image.hh
index 6f8d123..9340a17 100644
--- a/milena/mln/core/concept/image.hh
+++ b/milena/mln/core/concept/image.hh
@@ -1,4 +1,5 @@
-// Copyright (C) 2007, 2008, 2009 EPITA Research and Development Laboratory (LRDE)
+// Copyright (C) 2007, 2008, 2009 EPITA Research and Development
+// Laboratory (LRDE)
//
// This file is part of Olena.
//
diff --git a/milena/mln/core/routine/exact.hh b/milena/mln/core/routine/exact.hh
index e45490b..30e03e1 100644
--- a/milena/mln/core/routine/exact.hh
+++ b/milena/mln/core/routine/exact.hh
@@ -1,4 +1,5 @@
-// Copyright (C) 2007, 2008, 2009 EPITA Research and Development Laboratory (LRDE)
+// Copyright (C) 2007, 2008, 2009 EPITA Research and Development
+// Laboratory (LRDE)
//
// This file is part of Olena.
//
diff --git a/milena/mln/data/compute.hh b/milena/mln/data/compute.hh
index 3ddac78..bca7a38 100644
--- a/milena/mln/data/compute.hh
+++ b/milena/mln/data/compute.hh
@@ -43,7 +43,7 @@ namespace mln
/// Compute an accumulator onto the pixel values of the image \p input.
///
- /// \param[in] a_ An accumulator.
+ /// \param[in] a An accumulator.
/// \param[in] input The input image.
/// \return The accumulator result.
///
@@ -51,7 +51,7 @@ namespace mln
//
template <typename A, typename I>
mln_result(A)
- compute(const Accumulator<A>& a_, const Image<I>& input);
+ compute(const Accumulator<A>& a, const Image<I>& input);
/// Compute an accumulator onto the pixel values of the image \p input.
diff --git a/milena/mln/estim/min_max.hh b/milena/mln/estim/min_max.hh
index 84f45cb..6f72715 100644
--- a/milena/mln/estim/min_max.hh
+++ b/milena/mln/estim/min_max.hh
@@ -1,4 +1,5 @@
-// Copyright (C) 2007, 2008, 2009 EPITA Research and Development Laboratory (LRDE)
+// Copyright (C) 2007, 2008, 2009 EPITA Research and Development
+// Laboratory (LRDE)
//
// This file is part of Olena.
//
diff --git a/milena/mln/make/box2d.hh b/milena/mln/make/box2d.hh
index f9f242f..b417f42 100644
--- a/milena/mln/make/box2d.hh
+++ b/milena/mln/make/box2d.hh
@@ -1,4 +1,5 @@
-// Copyright (C) 2007, 2008, 2009 EPITA Research and Development Laboratory (LRDE)
+// Copyright (C) 2007, 2008, 2009 EPITA Research and Development
+// Laboratory (LRDE)
//
// This file is part of Olena.
//
diff --git a/milena/mln/transform/hough.hh b/milena/mln/transform/hough.hh
index 19ed1b0..61d1b4d 100644
--- a/milena/mln/transform/hough.hh
+++ b/milena/mln/transform/hough.hh
@@ -30,6 +30,7 @@
///
/// Compute the hough transform.
+
# include <mln/core/image/image2d.hh>
# include <mln/data/fill.hh>
@@ -61,12 +62,12 @@ namespace mln
///
/// \param[in] input_ A binary image.
///
- /// \return A 2D image of float. Rows are used for the distance and
- /// columns are used for the angles. Angles go from 0 to 359.
- /// Distance goes from 0 to the maximum distance between the center and a
- /// corner.
- /// The site having the maximum value indicates through its column index
- /// the document inclination.
+ /// \return A 2D image of float. Rows are used for the distance
+ /// and columns are used for the angles. Angles go from 0 to 359.
+ /// Distance goes from 0 to the maximum distance between the
+ /// center and a corner.
+ /// The site having the maximum value indicates through its column
+ /// index the document inclination.
//
template <typename I>
image2d<float>
@@ -76,6 +77,7 @@ namespace mln
# ifndef MLN_INCLUDE_ONLY
+
namespace internal
{
@@ -90,6 +92,7 @@ namespace mln
} // end of namespace mln::transform::internal
+
template <typename I>
image2d<float>
hough(const Image<I>& input_)
@@ -106,7 +109,6 @@ namespace mln
unsigned
ncols = geom::ncols(input),
nrows = geom::nrows(input);
- int compt = 0;
int maxRho = (int)(sqrt((ncols * nrows)
+ (ncols * nrows))
+ 0.5);
diff --git a/milena/mln/world/inter_pixel/is_separator.hh
b/milena/mln/world/inter_pixel/is_separator.hh
index deddae3..e168c8e 100644
--- a/milena/mln/world/inter_pixel/is_separator.hh
+++ b/milena/mln/world/inter_pixel/is_separator.hh
@@ -46,8 +46,12 @@ namespace mln
namespace inter_pixel
{
+
+ /// Functor returning whether a site is a separator in an
+ /// inter-pixel image.
struct is_separator : public Function_v2b< is_separator >
{
+
typedef bool result;
template <typename P>
@@ -55,28 +59,29 @@ namespace mln
template <typename P>
bool operator()(const Site_Proxy<P>& p) const;
+
};
# ifndef MLN_INCLUDE_ONLY
- template <typename P>
- inline
- bool
- is_separator::operator()(const Gpoint<P>& p_) const
- {
- const P& p = exact(p_);
- return p.row() % 2 + p.col() % 2 == 1;
- }
-
- template <typename P>
- inline
- bool
- is_separator::operator()(const Site_Proxy<P>& p) const
- {
- mlc_is_a(mln_site(P), Gpoint)::check();
- return this->operator()(exact(p).to_site());
- }
+ template <typename P>
+ inline
+ bool
+ is_separator::operator()(const Gpoint<P>& p_) const
+ {
+ const P& p = exact(p_);
+ return p.row() % 2 + p.col() % 2 == 1;
+ }
+
+ template <typename P>
+ inline
+ bool
+ is_separator::operator()(const Site_Proxy<P>& p) const
+ {
+ mlc_is_a(mln_site(P), Gpoint)::check();
+ return this->operator()(exact(p).to_site());
+ }
# endif // ! MLN_INCLUDE_ONLY
diff --git a/milena/mln/world/inter_pixel/separator_to_pixels.hh
b/milena/mln/world/inter_pixel/separator_to_pixels.hh
index f1f1bea..12b9c8d 100644
--- a/milena/mln/world/inter_pixel/separator_to_pixels.hh
+++ b/milena/mln/world/inter_pixel/separator_to_pixels.hh
@@ -72,12 +72,14 @@ namespace mln
P& p1 = exact(p1_);
P& p2 = exact(p2_);
+# ifndef NDEBUG
{
// Pre-condition.
is_separator is_separator_;
mln_precondition(is_separator_(s));
(void) is_separator_;
}
+# endif // ! NDEBUG
// FIXME: 2D only.
if (s.row() % 2)
@@ -93,6 +95,7 @@ namespace mln
p2 = point2d(s.row(), s.col() + 1);
}
+# ifndef NDEBUG
{
// Post-conditions.
is_pixel is_pixel_;
@@ -100,6 +103,7 @@ namespace mln
mln_postcondition(is_pixel_(p2));
(void) is_pixel_;
}
+# endif // ! NDEBUG
}
template <typename Ps, typename P>
@@ -112,15 +116,18 @@ namespace mln
P& p1 = exact(p1_);
P& p2 = exact(p2_);
+# ifndef NDEBUG
{
// Pre-condition.
is_separator is_separator_;
mln_precondition(is_separator_(s));
(void) is_separator_;
}
+# endif // ! NDEBUG
separator_to_pixels(s.to_site(), p1, p2);
+# ifndef NDEBUG
{
// Post-conditions.
is_pixel is_pixel_;
@@ -128,6 +135,7 @@ namespace mln
mln_postcondition(is_pixel_(p2));
(void) is_pixel_;
}
+# endif // ! NDEBUG
}
# endif // ! MLN_INCLUDE_ONLY
--
1.5.6.5