* 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
* INSTALL,
* NEWS,
* README: update.
---
ChangeLog | 8 ++
INSTALL | 16 +++-
NEWS | 9 +-
README | 355 +++++++++++++++++++++++++++++++++++++++++++++++++++----------
4 files changed, 327 insertions(+), 61 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index b5ac9ba..76e466e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2009-07-06 Guillaume Lazzara <lazzara(a)lrde.epita.fr>
+
+ Update INSTALL, NEWS and README files.
+
+ * INSTALL,
+ * NEWS,
+ * README: update.
+
2009-07-03 Guillaume Lazzara <lazzara(a)lrde.epita.fr>
* configure.ac: Adjust warning flags if CXX is set to icpc.
diff --git a/INSTALL b/INSTALL
index 9a6bba1..946675f 100644
--- a/INSTALL
+++ b/INSTALL
@@ -30,9 +30,21 @@ Optional:
- the `texinfo' utilities from GNU
+ - latex2html
+
+ * to use various image types:
+ - libMagick++
+
+ - libTiff
+
+ - libGdcm
+
* to develop _in_ Olena:
- GNU Autotools (Autoconf 2.54, Automake 1.7)
+ * to develop _in_ Swilena (Python Bindings):
+ - Swig
+
1.2 Configuration
=================
@@ -213,7 +225,9 @@ programs with:
Olena has been tested on the following configurations :
System Compiler
-Linux g++ 4.0, 4.1, 4.2
+Linux g++ 3.3, 3.4, 4.0, 4.1, 4.2
+ icc 10.1, 11.0
+Linux-64 g++ 4.1
MacOS X g++ 4.0.1
diff --git a/NEWS b/NEWS
index e6aca6a..9d0de6c 100644
--- a/NEWS
+++ b/NEWS
@@ -14,9 +14,12 @@
The Swilena Python Shell (sps) allows interactive Olena
sessions.
- * Olena contains tools for Document Image Analysis developed
- in the context of the SCRIBO project
- (http://www.scribo.ws/).
+ * A reference documentation including a tutorial and a quick
+ reference guide have been started. They do not cover the
+ whole library yet.
+
+ * Olena includes some demos which use Milena, the core C++
+ library.
* Olena 0.11 February 21, 2007
diff --git a/README b/README
index d9a09cb..f887435 100644
--- a/README
+++ b/README
@@ -1,30 +1,241 @@
-Abstract
-********
+Copyright (C) 2009 EPITA Research and Development Laboratory (LRDE)
-This is a public testing version of Olena, a generic image processing
-library in C++.
+This file is part of Olena.
- Please read the files INSTALL for information about building and
-installing 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.
+
+The complete GNU General Public Licence Notice can be found as the
+'COPYING' file in the root directory.
+
+=======================
+ Introduction to Olena
+=======================
+
+Olena_, a platform dedicated to image processing.
+
+.. _Olena: http:://olena.lrde.epita.fr
+
+
+Overview
+========
- Olena is a project developed by the EPITA Research and Development
-Laboratory (<http://www.lrde.epita.fr>) since 1997. We did numerous
-prototypes and throwaway experiments before settling into the kind of
-programming paradigm which is finally here.
+Olena is a platform dedicated to image processing. At the moment it is
+mainly composed of a C++ library: Milena. This library features many
+tools to easily perform image processing tasks. Its main
+characteristic is its genericity: it allows to write an algorithm once
+and run it over many kinds of images (grey scale, color, 1D, 2D, 3D,
+...).
- The documentation does not cover the whole project yet. In the `doc/'
-directory you will find the first draft of a reference manual. It
-includes a quick reference guide and a tutorial. This is a good start.
-In `milena/tools', `milena/doc/tutorial/samples' and `milena/doc/examples'
-few sample programs are available. Most of them are already used to
-illustrate the tutorial.
-For the rest, we're afraid you will have to dig the code or e-mail us.
+Olena is a project developed by the `EPITA Research and Development
+Laboratory (LRDE)`__ since 1997. We did numerous prototypes and
+throwaway experiments before settling into the kind of programming
+paradigm which is finally here.
+
+__ http://www.lrde.epita.fr
+
+We do our image processing research using this library, but most
+importantly we have gathered (and still do) generic programming
+expertise from the library development.
+
+Yet, Olena is an ongoing development project. Few algorithms or
+definitions may change in a near future. A list of potential changes
+is maintained here :
+https://olena.lrde.epita.fr/FeaturesSubjectToChange.
+
+Likewise, the documentation does not cover the whole project yet. In the
+`doc/' directory you will find the first draft of a reference
+manual. It includes a quick reference guide and a tutorial. This is a
+good start. In `milena/tools' and `milena/doc/examples' few sample
+programs are available. Most of them are already used to illustrate
+the tutorial. For the rest, we're afraid you will have to dig the
+code or e-mail us.
Please direct any question or comments to <olena(a)lrde.epita.fr>, or
<olena-bugs(a)lrde.epita.fr>.
Olena also has a web page, located at
-<http://www.lrde.epita.fr/Olena>.
+<http://olena.lrde.epita.fr>.
+
+
+Installation
+============
+
+To install Olena on your system, type in the classical sequence at
+the command prompt::
+
+ ./configure
+ make
+ make install (as root)
+
+Note that an installation is specific to the compiler used to install
+it. Indeed, the call to ``./configure`` enables some workarounds and,
+consequently, users must compile with the same compiler to avoid
+compatibility problems.
+
+Between ``make`` and ``make install``, you may also want to run::
+
+ make check
+
+ ``make check`` will run the test suite to check the whole library.
+Running the test suite may require up several hours.
+
+
+Please read the INSTALL file for more information about building and
+installing Olena.
+
+
+Additional features
+-------------------
+
+Python bindings are provided thanks to Swilena. It is disabled by
+default because it requires extra dependencies: Swig. To enable the
+compilation of this module use::
+
+ ./configure --enable-swilena
+
+
+Sample tools are shipped in the tarball. To enable the compilation of
+ these tools use:: ./configure --enable-tools
+
+
+Sample applications are shipped in the tarball. To Enable the
+compilation of these applications use::
+
+ ./configure --enable-apps
+
+
+To read/write TIFF images with Olena, libtiff is required. To specify
+the base directory, use::
+
+ ./configure --with-tiff=/path/to/basedir
+
+
+To read/write GDCM images with Olena, libgdcm is required. To specify
+the base directory, use::
+
+ ./configure --with-gdcm=/path/to/basedir
+
+
+
+Layout of the tarball
+---------------------
+
+The Olena project directory layout is as follows:
+
+build-aux
+ Auxialiary tools used by the GNU Build System during ``configure``
+ and ``make`` stages.
+
+external
+ Sources of Shipped dependencies.
+
+
+m4
+ Portability macros from the ``gnulib`` library.
+
+milena
+
+ apps
+ Application examples.
+
+ mln
+ Header of the Milena library.
+
+ tests
+ The test suite.
+
+ doc
+ The documentation.
+
+ tools
+ Example tools.
+
+ mesh
+ Mesh images.
+
+ img
+ Test images.
+
+ demos
+ Demos of Milena.
+
+
+swilena
+ Python binding sources.
+
+
+Requirements
+============
+
+Olena has been tested on the following configurations:
+
+System Compiler
+Linux g++ 3.3, 3.4, 4.0, 4.1, 4.2
+ icc 10.1, 11.0
+Linux-64 g++ 4.1
+MacOS X g++ 4.0.1
+
+
+According to the wanted features, some dependencies may be required:
+
+
+To enable I/O with TIFF images, `libtiff`_ must be installed.
+
+.. _libtiff: http://www.libtiff.org/
+
+To enable I/O with GDCM images, `libgdcm`_ must be installed.
+
+.. _libgdcm: http://sourceforge.net/apps/mediawiki/gdcm/
+
+
+To support many image formats in Olena's I/O system, `libmagick++`_ must
+be installed.
+
+.. _libmagick++: Please see your distribution package manager.
+
+
+`Boost`_ may be needed if you want to support tuple accumulators.
+
+.. _Boost: http://www.boost.org/
+
+
+See Also
+========
+
+There are other sources of interest in the distribution.
+
+- Headline news about the project can be found in the file ``NEWS`` at
+ the root of the source tree.
+
+- The library reference HTML documentation, generated by Doxygen_, is
+ located in ``doc/user/html/``.
+
+.. _Doxygen: http://www.doxygen.org
+
+
+License
+=======
+
+Olena is released under the GNU General Public Licence. See the file
+``COPYING`` (at the root of the source tree) for details.
+
+
+Contacts
+========
+
+The team can be reached by mail at olena(a)lrde.epita.fr. Snail mail
+addresses follow.
+
+* Olena - LRDE
+
+ | Laboratoire de Recherche et Développement de l'EPITA
+ | 14-16 rue Voltaire
+ | 94276 Le Kremlin-Bicêtre CEDEX
+ | France
+
+
Bibliography
============
@@ -32,52 +243,82 @@ Bibliography
Further information about Olena can be found into the following related
papers:
- * Thierry Géraud, Yoann Fabre, Dimitri Papadopoulos-Orfanos, and
- Jean-François Mangin. `Vers une réutilisabilité totale des
- algorithmes de traitement d'images'. In the Proceedings of the
- 17th Symposium GRETSI on Signal and Image Processing, vol. 2,
- pages 331-334, Vannes, France, September 1999. In French
- (available in English as Technical Report 9902: `Towards a Total
- Reusability of Image Processing Algorithms').
-
- * Thierry Géraud, Yoann Fabre, Alexandre Duret-Lutz, Dimitri
- Papadopoulos-Orfanos, and Jean-François Mangin. `Obtaining
- Genericity for Image Processing and Pattern Recognition
- Algorithms'. In the Proceedings of the 15th International
- Conference on Pattern Recognition (ICPR'2000), IEEE Computer
- Society, vol. 4, pages 816-819, Barcelona, Spain, September 2000.
-
- * Alexandre Duret-Lutz. `Olena: a Component-Based Platform for
- Image Processing, mixing Generic, Generative and OO
- Programming'. In the Proceedings of the 2nd International
- Symposium on Generative and Component-Based Software Engineering
- (GCSE 2000), Young Researchers Workshop (published in
- "Net.ObjectDays2000"; ISBN 3-89683-932-2), pages 653-659,
- Erfurt, Germany, October 2000.
-
- * Alexandre Duret-Lutz, Thierry Géraud, and Akim Demaille. `Generic
- Design Patterns in C++'. In the Proceedings of the 6th USENIX
+ * `Vers une réutilisabilité totale des algorithmes de traitement
+ d'images`. Thierry Géraud, Yoann Fabre, Dimitri
+ Papadopoulos-Orfanos, and Jean-François Mangin. In the
+ Proceedings of the 17th Symposium GRETSI on Signal and Image
+ Processing, vol. 2, pages 331-334, Vannes, France,
+ September 1999. In French (available in English as Technical
+ Report 9902: `Towards a Total Reusability of Image Processing
+ Algorithms').
+
+ * `Obtaining Genericity for Image Processing and Pattern
+ Recognition Algorithms`. Thierry Géraud, Yoann Fabre, Alexandre
+ Duret-Lutz, Dimitri Papadopoulos-Orfanos, and Jean-François
+ Mangin. In the Proceedings of the 15th International Conference
+ on Pattern Recognition (ICPR'2000), IEEE Computer Society,
+ vol. 4, pages 816-819, Barcelona, Spain, September 2000.
+
+ * `Olena: a Component-Based Platform for Image Processing, mixing
+ Generic, Generative and OO Programming`. Alexandre Duret-Lutz.
+ In the Proceedings of the 2nd International Symposium on
+ Generative and Component-Based Software Engineering (GCSE 2000),
+ Young Researchers Workshop (published in "Net.ObjectDays2000";
+ ISBN 3-89683-932-2), pages 653-659, Erfurt, Germany, October
+ 2000.
+
+ * `Generic Design Patterns in C++`. Alexandre Duret-Lutz, Thierry
+ Géraud, and Akim Demaille. In the Proceedings of the 6th USENIX
Conference on Object-Oriented Technologies and Systems
- (COOTS'2001), pages 189-202, San Antonio, Texas, USA,
+ (COOTS'2001), pages 189-202, San Antonio, Texas, USA,
January-February 2001.
- * Thierry Géraud, Yoann Fabre, and Alexandre Duret-Lutz. `Applying
- Generic Programming to Image Processing'. In the Proceedings of
- the IASTED International Conference on Applied Informatics
- (AI'2001) - Symposium Advances in Computer Applications, ACTA
- Press, pages 577-581, Innsbruck, Austria, February 2001.
+ * `Applying Generic Programming to Image Processing`, Thierry
+ Géraud, Yoann Fabre, and Alexandre Duret-Lutz. In the
+ Proceedings of the IASTED International Conference on Applied
+ Informatics (AI'2001) - Symposium Advances in Computer
+ Applications, ACTA Press, pages 577-581, Innsbruck, Austria,
+ February 2001.
- * `Generic Implementation of Morphological Image Operators',
- Jérôme Darbon, Thierry Géraud, and Alexandre Duret-Lutz,
- submitted to International Symposium On Mathematical Morphology VI
- (ISMM 2002), April 3-5, 2002, Sydney, Australia.
+ * `Generic Implementation of Morphological Image Operators`, Jérôme
+ Darbon, Thierry Géraud, and Alexandre Duret-Lutz, submitted to
+ International Symposium On Mathematical Morphology VI (ISMM
+ 2002), April 3-5, 2002, Sydney, Australia.
+
+ * `Static C++ Object-Oriented Programming (SCOOP)`, Nicolas Burrus,
+ Alexandre Duret-Lutz, Thierry Géraud, David Lesage, and Raphaël
+ Poss. In the Proceedings of the Workshop on Multiple Paradigm
+ with OO Languages (MPOOL'03) Anaheim, CA Oct. 2003.
+
+ * `Generic Algorithmic Blocks Dedicated to Image Processing`,
+ Jérôme Darbon, Thierry Géraud, Patrick Bellot. In the proceedings
+ of ECOOP PHD Oslo, Norway June 2004.
+
+ * `Fast Color Image Segmentation Based on Levellings in Feature
+ Space`, Thierry Géraud, Giovanni Palma, Niels Van Vliet. In the
+ proceedings of the International Conference on Computer Vision
+ and Graphics (ICCVG) Warsaw, Poland, September 2004.
+
+ * `Semantics-Driven Genericity: A Sequel to the Static C++
+ Object-Oriented Programming Paradigm (SCOOP 2)`. Thierry Géraud,
+ Roland Levillain. In the proceedings of the 6th International
+ Workshop on Multiparadigm Programming with Object-Oriented
+ Languages
+ http://homepages.fh-regensburg.de/~mpool/mpool08/welcome.html
+ Paphos, Cyprus July 7, 2008.
+
+ * `Milena: Write Generic Morphological Algorithms Once, Run on Many
+ Kinds of Images`. Roland Levillain, Thierry Géraud, Laurent
+ Najman. In the proceedings of the 9th International Symposium on
+ Mathematical Morphology (ISMM) http://www.cs.rug.nl/~ISMM09/
+ Groningen, The Netherlands August 24 - 27, 2009.
- * `Static C++ Object-Oriented Programming (SCOOP)' Nicolas
- Burrus, Alexandre Duret-Lutz, Thierry Géraud, David Lesage, and
- Raphaël Poss. In the Proceedings of the Workshop on Multiple
- Paradigm with OO Languages (MPOOL'03) Anaheim, CA Oct. 2003.
You can download these papers and related materials from
<http://www.lrde.epita.fr/cgi-bin/twiki/view/Publications>
+
+.. Local Variables:
+.. mode: rst
+.. End:
--
1.5.6.5