Un peu de doc en plus, un peu seulement :(
A propos, processing.tpl est cassé avec le nouveau autogen.
Et je n'arrive pas à compiler swilena.texi avec le nouveau texinfo.tex
dans config/ installé par le dernier automake (release, pas essayé
avec cvs). Il génère des numéros de version bizarre dans
`swilena.toc'. Si qqn voit le pb, je suis preneur, "make -C
tools/swilena/doc clean all" après un "automake -fi".
Index: doc/ChangeLog
from Nicolas Burrus <burrus_n(a)lrde.epita.fr>
* ref/integre-ref.tex: Update.
* demo/tour.cc (main): Check i/o errors.
Index: integre/ChangeLog
from Nicolas Burrus <burrus_n(a)lrde.epita.fr>
* ntg/core/macros.hh (ntg_abstract_type): New macro.
Index: tools/swilena/ChangeLog
from Nicolas Burrus <burrus_n(a)lrde.epita.fr>
* doc/swilena.texi: Update.
Index: doc/demo/tour.cc
--- doc/demo/tour.cc Tue, 13 May 2003 22:55:53 +0200 burrus_n (oln/d/45_tour.cc 1.12 640)
+++ doc/demo/tour.cc Fri, 12 Dec 2003 17:19:14 +0100 burrus_n (oln/d/45_tour.cc 1.12 640)
@@ -330,6 +330,11 @@
// the type of the image you load/save. The extension
// is also used to guess the format to use.
image2d<int_u8> lena = load(IMGDIR "/lena.pgm");
+ if (!lena.has_impl())
+ {
+ std::cerr << "Could not load " << IMGDIR "/lena.pgm" << std::endl;
+ exit(1);
+ }
std::cout << "watershedling lena..." << std::endl;
save(morpho::watershed_seg<int_u8>(lena, neighb_c4()), "output.pgm");
Index: doc/ref/integre-ref.tex
--- doc/ref/integre-ref.tex Tue, 29 Jul 2003 13:26:24 +0200 palma_g (oln/g/34_ref-types. 1.11 640)
+++ doc/ref/integre-ref.tex Sat, 03 Jan 2004 15:38:20 +0100 burrus_n (oln/g/34_ref-types. 1.11 640)
@@ -4,10 +4,10 @@
{\integre} is a safe and efficient data types library, designed for
generic algorithm writing. Even if it is now independent from Olena,
-it was initially developed to provide value types for images'
-pixels. {\integre} implements basics types such as integers, floats,
+it was initially developed to provide value types for image pixels.
+{\integre} implements basics types such as integers, floats,
complexes, vectors but also more evolved types such as range (in the
-same spirit than Ada) or cycle.
+same spirit as Ada) or cycle.
By safe we wean that all operations (arithmetic, assignments, etc.)
are checked. If there is an overflow, the user is noticed, at compile
@@ -15,8 +15,8 @@
By efficient we mean that using {\integre} additional checks and
features should not decrease too much the overall performances. This
-is why {\integre} relies intensively on template code and meta
-programming.
+is why {\integre} relies intensively on template code and
+metaprogramming.
\subsection{Interactions with builtin types}
@@ -80,10 +80,10 @@
\item Reals
\begin{itemize}
- \item unsigned integer (\ahrefloc{ref-intu}{\code{int_u}})
- \item signed integer (\ahrefloc{ref-ints}{\code{int_s}})
- \item float with single precision (\ahrefloc{ref-floats}{\code{float_s}})
- \item float with double precision (\ahrefloc{ref-floatd}{\code{float_d}})
+ \item unsigned integer (\ahrefloc{ref-reals}{\code{int_u}})
+ \item signed integer (\ahrefloc{ref-reals}{\code{int_s}})
+ \item float with single precision (\ahrefloc{ref-reals}{\code{float_s}})
+ \item float with double precision (\ahrefloc{ref-reals}{\code{float_d}})
\end{itemize}
\item Enumerated
@@ -153,7 +153,7 @@
They are suffixed by \code{_type}, for example: \code{larger_type},
\code{cumul_type}, \code{abstract_type}, etc.
-Here is the list of common properties:
+Here is the list of the properties which almost all types have:
\subsubsection{\code{abstract_type}}
@@ -164,7 +164,8 @@
Here are the available abstract types:
-%\includeimage{abstract-types-hierarchy}{width=0.9\textwidth}
+%% FIXME: uncomment when dia files will be converted automatically.
+%%\includeimage{abstract-types-hierarchy}{width=0.9\textwidth}
\subsubsection{\code{ntg_type}}
@@ -332,12 +333,6 @@
Example: \code{int_u<8, saturate> u = 350; // u == 255}.
-\subsubsection{cycle}
-
-Assign the value modulo the value range of the type.
-
-Example: \code{int_u<8, saturate> u = 257; // u == 1}.
-
\subsubsection{unsafe}
Does nothing. Behaves almost the same way than builtin types. You
@@ -351,32 +346,173 @@
%%
-\section{\aname{sec-ref}{Types reference}}
+\section{\aname{sec-ref}{Type reference}}
\subsection{Hierarchy}
\integre\ types are organized hierarchically:
-%\includeimage{data-hierarchy}{width=0.9\textwidth}
+%% FIXME: uncomment when dia files will be converted automatically.
+%%\includeimage{data-hierarchy}{width=0.9\textwidth}
\subsection{\aname{ref-bin}{\code{bin}}}
-\subsection{\aname{ref-cplx}{\code{cplx}}}
+\code{bin} is a binary type whose values are \code{0} and \code{1}.
+Thus, it can be constructed from usual numerical values. Arithmetic
+operations are forbidden, and usual logical operations are defined
+(the same as builtin types). It can interact freely with \code{bool}.
+
+\subsection{\aname{ref-reals}{Real types (\code{int_u}, \code{int_s}, \code{float_s}, \code{float_d})}}
+
+Real types behave almost like their builtin equivalent. Arithmetic
+operators are defined between all of them, etc.
+
+\code{int_u} and \code{int_s} take two parameters, the first is the
+number of bits and the second the behavior. To define the range of
+possible values more precisely, you should consider the \code{range}
+type. Aliases have been defined for usual values:
+
+\begin{itemize}
+\item \code{int_uX} with \code{X} being a value of \code{8, 16, 32}
+ corresponds to \code{int_u<X, strict>}.
+\item \code{int_uXu} corresponds to \code{int_u<X, unsafe}.
+\item \code{int_uXs} corresponds to \code{int_u<X, saturate}.
+\end{itemize}
+
+The same aliases have been defined for \code{int_s}.
+
+\code{float_s} and \code{float_d} are actually aliases toward the
+corresponding builtin types. However, this should change in future
+releases of \integre.
+
+Here is an example using real types:
+
+\begin{lstlisting}{}
+#include <ntg/int.hh> // int_u and int_s
+#include <ntg/float.hh> // float_s and float_d
+
+using namespace ntg;
+
+int main()
+{
+ int_u8s a = 350; // actual value is 2^8 - 1 = 255
+ int_s16 b = 258;
+ int_u<6, saturate> c = 25;
+
+ float_s d = a + b + c;
+ float_d e = d + (a * b * c);
+}
+\end{lstlisting}
\subsection{\aname{ref-cycle}{\code{cycle}}}
-\subsection{\aname{ref-floatd}{\code{float_d}}}
+\code{cycle} is a decorator type. Giving a real type and an interval,
+\code{cycle} variables will ensure that their values remains in the
+given interval cycling around the bounds. An interval is either
+\code{bounded_u} or \code{bounded_s}, both taking two parameters, the
+lower and the upper bounds, the first accepting unsigned values and
+the second signed values. Float bounds cannot be defined since floats
+are not accepted as template parameters. The lower bound is inclusive
+whereas the upper bound is exclusive.
-\subsection{\aname{ref-floats}{\code{float_s}}}
+Arithmetic operations are performed on the underlying types, in the
+same way as if the type was not decorated by \code{cycle}.
+
+Example:
+
+\begin{lstlisting}{}
+#include <ntg/float.hh>
+#include <ntg/cycle.hh>
-\subsection{\aname{ref-ints}{\code{int_s}}}
+using namespace ntg;
-\subsection{\aname{ref-intu}{\code{int_u}}}
+int main()
+{
+ cycle<float_s, bounded_u<0, 360> > c1 = 360; // c1 == 0
+}
+\end{lstlisting}
\subsection{\aname{ref-range}{\code{range}}}
+\code{range} behaves almost like \code{cycle}, but its takes 3
+parameters, the decorated type, the interval and the behavior to use
+when a value is not in the interval.
+
+Example:
+
+\begin{lstlisting}{}
+#include <ntg/int.hh>
+#include <ntg/range.hh>
+
+using namespace ntg;
+
+int main()
+{
+ // fails at runtime
+ range<int_u8, bounded_u<0, 10>, strict> a = 11;
+}
+\end{lstlisting}
+
\subsection{\aname{ref-vec}{\code{vec}}}
+\integre\ provides vectors with a static length. \code{vec} takes two
+parameters, the size and the type of the elements.
+
+Usual arithmetic operations are defined both between two vectors and
+between a vector and one element. Arithmetic operations between a
+vector and one element apply the operator on each element of the
+vector. The multiplication of two vectors is the dot product.
+
+Example:
+
+\begin{lstlisting}{}
+#include <iostream>
+#include <ntg/vec.hh>
+#include <ntg/int.hh>
+
+using namespace ntg;
+
+int main()
+{
+ vec<10, int_u8> v1;
+ for (unsigned i = 0; i < 10; ++i)
+ v1[i] = i;
+ std::cout << v1 << std::endl;
+}
+\end{lstlisting}
+
+\subsection{\aname{ref-cplx}{\code{cplx}}}
+
+There are two kinds of representation for complexes, rectangular ($a +
+i * b$) and polar ($r * exp(i\theta)$). Conversions are implicit
+between the representations. A complex is rectangular representation
+is actually a vector of two elements, the real part and the imaginary
+part. So \code{cplx} takes two arguments, the representation and the
+type of the elements.
+
+Example:
+
+\begin{lstlisting}{}
+#include <iostream>
+#include <ntg/cplx.hh>
+
+using namespace ntg;
+
+int main()
+{
+ cplx<rect, int_u8> c1 (5, 12);
+ cplx<polar, float_s> c2 (5.2, 0.8);
+ c1 = c2;
+ std::cout << c1 << std::endl;
+ std::cout << c1 + c2 << std::endl;
+}
+\end{lstlisting}
+
%%
\section{FAQ}
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "oln-ref"
+%%% End:
Index: tools/swilena/doc/swilena.texi
--- tools/swilena/doc/swilena.texi Tue, 13 May 2003 22:29:01 +0200 burrus_n (oln/n/40_swilena.te 1.1.1.2 640)
+++ tools/swilena/doc/swilena.texi Sat, 03 Jan 2004 15:38:36 +0100 burrus_n (oln/n/40_swilena.te 1.1.1.2 640)
@@ -15,14 +15,14 @@
Interfacing Olena (Swilena) both in terms of usage and provided
functionality.
-Copyright @copyright{} 2002, 2003 @strong{L.R.D.E.}
+Copyright © 2002, 2003, 2004 @strong{L.R.D.E.}
@end copying
@titlepage
@title Swilena
@subtitle Edition @today
-@author Rapha@"el Poss
+@author Rapha@"el Poss and Nicolas Burrus
@end titlepage
@iftex
@@ -35,9 +35,6 @@
This documents is intended to describe Swilena, a simplified set of
wrappers around the image processing library Olena.
-@c FIXME
-@strong{WARNING: The documentation is currently off-sync with the sources and pertains to olena 0.7.}
-
@menu
* Introduction::
* Of SWIG and Swilena principles::
@@ -70,20 +67,25 @@
@table @strong
@item swilena
Contains definitions for pixel types.
-@item swilena1d, swilena2d, swilena3d
-Contain definitions for structural element, neighborhood and image types.
-@item swilena1d_convert, swilena2d_convert, swilena3d_convert
+@item swilena_image1d, swilena_image2d, swilena_image3d
+Contain definitions for image and point types.
+@item swilena_structelt1d, swilena_structelt2d, swilena_structelt3d
+Contain definitions for structural elements.
+@item swilena_conversion1d, swilena_conversion2d, swilena_conversion3d
Contain conversion functions between image types.
-@item swilena1d_morpho, swilena2d_morpho, swilena3d_morpho
+@item swilena_morpho1d, swilena_morpho2d, swilena_morpho3d
Contain morphological operators over images.
-@item ...
+@item swilena_arith1d, swilena_arith2d, swilena_arith3d
+Contain arithmetical operators over images.
@end table
The primary target language for Swilena is Python, because Python is
-the best supported back-end for SWIG. However, the SWIG definition files
-of Swilena are not bound to a particular interpreted language: any
-SWIG target language @emph{providing enough expressivity} can be used.
-Indeed, here are the required features from the interpreted language:
+the best supported back-end for SWIG. However, the SWIG definition
+files of Swilena are not bound to a particular interpreted language:
+any SWIG target language @emph{providing enough expressivity} can be
+used. Ruby modules are defined too, they are not documented here but
+they work almost the same way than Python modules. Here are the
+required features from the interpreted language:
@itemize @bullet
@item
@@ -96,10 +98,11 @@
them.
@end itemize
-Typically ``ideal'' target languages are Python, Perl5, Tcl, Scheme.
+Typically ``ideal'' target languages are Python, Ruby, Perl5, Tcl,
+Scheme.
-Currently, the source tree only knows about Python, but this should
-be fixed soon.
+Currently, the source tree only knows about Python and Ruby, but this
+may evolute in the future.
@unnumberedsubsec Using Swilena for Olena development
@@ -649,8 +652,7 @@
First, start Python and load the Swilena modules for 2D:
@example
->>> @kbd{from swilena import *}
->>> @kbd{from swilena2d import *}
+>>> @kbd{from swilena_image2d import *}
@end example
If everything succeeds, you can start creating images
@@ -663,13 +665,13 @@
>>> @kbd{i=image2d_u8(10, 10)}
>>> @kbd{for x in range(0, i.ncols(), 1):}
... @kbd{for y in range(0, i.nrows(), 1):}
-... @kbd{i.at(x, y).value(r.randint(0,255))}
+... @kbd{i.at(x, y) = r.randint(0,255)}
...
>>>
@end example
-The previous code creates an empty 2D image using 8-bit
-unsigned integers to store pixel values, with a size of 10x10 pixels. It then
+The previous code creates an empty 2D image using 8-bit unsigned
+integers to store pixel values, with a size of 10x10 pixels. It then
initalizes all pixels in the image using loops.
It is then possible to store this image in a file:
@@ -687,7 +689,7 @@
@example
>>> @kbd{i.load("lena.pgm")}
1
->>> @kbd{i.at(3,3).val()}
+>>> @kbd{i.at(3,3)}
162
>>>
@end example
@@ -695,9 +697,8 @@
Both @samp{load} and @samp{save} return a boolean set to 1 if the operation
succeeded, 0 else.
-
-As demonstrated in the previous example, Swilena images have methods. However,
-there are not many:
+As demonstrated in the previous example, Swilena images have
+methods. However, there are not many:
@table @samp
@item load
@@ -706,6 +707,8 @@
save the image to a file.
@item at
return a reference to the indicated pixel.
+@item set
+set the value of the indicated pixel.
@item ncols
return the number of columns in the image. This method is valid for 1D, 2D and 3D images.
@item nrows
@@ -718,7 +721,7 @@
and accepts a @samp{point} instead of coordinates as a pixel location:
@example
->>> @kbd{i.at(point2d(3, 3)).val()}
+>>> @kbd{i.at(point2d(3, 3))}
162
>>>
@end example
@@ -727,23 +730,15 @@
morphological operators are grouped in the @samp{*morpho} modules:
@example
->>> @kbd{import swilena2d_morpho}
->>> @kbd{i2=swilena2d_morpho.erosion(i, win_c4p())}
->>> @kbd{i3=swilena2d_morpho.dilation(i, win_c4p())}
-@end example
-
-Here is a convolution:
-
-@example
->>> @kbd{import swilena2d_convol}
->>> @kbd{ww=w_win2d_int()}
->>> @kbd{ww.add(-1,0,2).add(0,1,-2)}
->>> @kbd{i4=swilena2d_convol.convolve(i, ww)}
+>>> @kbd{import swilena_structelt2d}
+>>> @kbd{import swilena_morpho2d}
+>>> @kbd{i2=swilena_morpho2d.erosion(i, win_c4p())}
+>>> @kbd{i3=swilena_morpho2d.dilation(i, win_c4p())}
@end example
-These function are polymorphic and should work for nearly all
-image types. Refer to the following chapter (@pxref{API Reference})
-for a description of what are valid calls.
+These function are polymorphic and should work for nearly all image
+types. Refer to the following chapter (@pxref{API Reference}) for a
+description of what are valid calls.
@node API Reference
@chapter API Reference
@@ -764,24 +759,16 @@
@multitable @columnfractions .25 .25 .5
@item @strong{Swilena Type} @tab @strong{C++ Type} @tab @strong{Description}
@item @tab @tab
-@item int_u8 @tab oln::int_u8 @tab 8-bit unsigned integer
-@item int_u16 @tab oln::int_u16 @tab 16-bit unsigned integer
-@item int_u32 @tab oln::int_u32 @tab 32-bit unsigned integer
-@item int_s8 @tab oln::int_s8 @tab 8-bit signed integer
-@item int_s16 @tab oln::int_s16 @tab 16-bit signed integer
-@item int_s32 @tab oln::int_s32 @tab 32-bit signed integer
-@item int_u8s @tab oln::int_u8s @tab 8-bit saturated unsigned integer
-@item int_u16s @tab oln::int_u16s @tab 16-bit saturated unsigned integer
-@item int_u32s @tab oln::int_u32s @tab 32-bit saturated unsigned integer
-@item int_s8s @tab oln::int_s8s @tab 8-bit saturated signed integer
-@item int_s16s @tab oln::int_s16s @tab 16-bit saturated signed integer
-@item int_s32s @tab oln::int_s32s @tab 32-bit saturated signed integer
-@item bin @tab oln::bin @tab 1-bit value
-@item float_s @tab oln::float_s @tab single precision float
-@item float_d @tab oln::float_d @tab double precision float
-@item rgb_8 @tab oln::rgb_8 @tab 3-uple of 8-bit values
-@item rgb_16 @tab oln::rgb_16 @tab 3-uple of 16-bit values
-@item rgb_32 @tab oln::rgb_16 @tab 3-uple of 32-bit values
+@item int_u8 @tab ntg::int_u8 @tab 8-bit unsigned integer
+@item int_u32 @tab ntg::int_u32 @tab 32-bit unsigned integer
+@item int_s8 @tab ntg::int_s8 @tab 8-bit signed integer
+@item int_s32 @tab ntg::int_s32 @tab 32-bit signed integer
+@item bin @tab ntg::bin @tab 1-bit value
+@item float_d @tab ntg::float_d @tab double precision float
+@item cplx_rect @tab ntg::cplx<rect, float_d> @tab complex number in
+ rectangular representation.
+@item cplx_polar @tab ntg::cplx<polar, float_d> @tab complex number in
+ polar representation.
@end multitable
All pixel types are represented by classes in Swilena.
@@ -807,27 +794,6 @@
Set the value of the pixel.
@end table
-Color (RGB) pixel types share the following interface:
-
-@table @code
-@item r()
-return the red component of the pixel value as an integer.
-@item g()
-same, for green.
-@item b()
-same, for blue.
-@item r(integer value)
-set the red component of the pixel value from an integer.
-@item g(integer value)
-same, for green.
-@item b(integer value)
-same, for blue
-@item color(component)
-return the value of the specified color component (0,1,2) as an integer.
-@item color(component, integer vale)
-set the value of the specified color component (0,1,2) from an integer.
-@end table
-
The module name for these types is @strong{swilena}.
@node Point Types
@@ -874,60 +840,24 @@
@item @tab @tab
@item image1d_bin @tab oln::image1d<oln::bin> @tab ready
@item image1d_u8 @tab oln::image1d<oln::int_u8> @tab ready
-@item image1d_u16 @tab oln::image1d<oln::int_u16> @tab ready
@item image1d_u32 @tab oln::image1d<oln::int_u32> @tab ready
@item image1d_s8 @tab oln::image1d<oln::int_s8> @tab ready
-@item image1d_s16 @tab oln::image1d<oln::int_s16> @tab ready
@item image1d_s32 @tab oln::image1d<oln::int_s32> @tab ready
-@item image1d_u8s @tab oln::image1d<oln::int_u8s> @tab ready
-@item image1d_u16s @tab oln::image1d<oln::int_u16s> @tab ready
-@item image1d_u32s @tab oln::image1d<oln::int_u32s> @tab ready
-@item image1d_s8s @tab oln::image1d<oln::int_s8s> @tab ready
-@item image1d_s16s @tab oln::image1d<oln::int_s16s> @tab ready
-@item image1d_s32s @tab oln::image1d<oln::int_s32s> @tab ready
-@item image1d_float_s @tab oln::image1d<oln::float_s> @tab ready
@item image1d_float_d @tab oln::image1d<oln::float_d> @tab ready
-@item image1d_rgb_8 @tab oln::image1d<oln::rgb_8> @tab ready
-@item image1d_rgb_16 @tab oln::image1d<oln::rgb_16> @tab ready
-@item image1d_rgb_32 @tab oln::image1d<oln::rgb_32> @tab ready
@item @tab @tab
@item image2d_bin @tab oln::image2d<oln::bin> @tab ready
@item image2d_u8 @tab oln::image2d<oln::int_u8> @tab ready
-@item image2d_u16 @tab oln::image2d<oln::int_u16> @tab ready
@item image2d_u32 @tab oln::image2d<oln::int_u32> @tab ready
@item image2d_s8 @tab oln::image2d<oln::int_s8> @tab ready
-@item image2d_s16 @tab oln::image2d<oln::int_s16> @tab ready
@item image2d_s32 @tab oln::image2d<oln::int_s32> @tab ready
-@item image2d_u8s @tab oln::image2d<oln::int_u8s> @tab ready
-@item image2d_u16s @tab oln::image2d<oln::int_u16s> @tab ready
-@item image2d_u32s @tab oln::image2d<oln::int_u32s> @tab ready
-@item image2d_s8s @tab oln::image2d<oln::int_s8s> @tab ready
-@item image2d_s16s @tab oln::image2d<oln::int_s16s> @tab ready
-@item image2d_s32s @tab oln::image2d<oln::int_s32s> @tab ready
-@item image2d_float_s @tab oln::image2d<oln::float_s> @tab ready
@item image2d_float_d @tab oln::image2d<oln::float_d> @tab ready
-@item image2d_rgb_8 @tab oln::image2d<oln::rgb_8> @tab ready
-@item image2d_rgb_16 @tab oln::image2d<oln::rgb_16> @tab ready
-@item image2d_rgb_32 @tab oln::image2d<oln::rgb_32> @tab ready
@item @tab @tab
@item image3d_bin @tab oln::image3d<oln::bin> @tab ready
@item image3d_u8 @tab oln::image3d<oln::int_u8> @tab ready
-@item image3d_u16 @tab oln::image3d<oln::int_u16> @tab ready
@item image3d_u32 @tab oln::image3d<oln::int_u32> @tab ready
@item image3d_s8 @tab oln::image3d<oln::int_s8> @tab ready
-@item image3d_s16 @tab oln::image3d<oln::int_s16> @tab ready
@item image3d_s32 @tab oln::image3d<oln::int_s32> @tab ready
-@item image3d_u8s @tab oln::image3d<oln::int_u8s> @tab ready
-@item image3d_u16s @tab oln::image3d<oln::int_u16s> @tab ready
-@item image3d_u32s @tab oln::image3d<oln::int_u32s> @tab ready
-@item image3d_s8s @tab oln::image3d<oln::int_s8s> @tab ready
-@item image3d_s16s @tab oln::image3d<oln::int_s16s> @tab ready
-@item image3d_s32s @tab oln::image3d<oln::int_s32s> @tab ready
-@item image3d_float_s @tab oln::image3d<oln::float_s> @tab ready
@item image3d_float_d @tab oln::image3d<oln::float_d> @tab ready
-@item image3d_rgb_8 @tab oln::image3d<oln::rgb_8> @tab not ready
-@item image3d_rgb_16 @tab oln::image3d<oln::rgb_16> @tab not ready
-@item image3d_rgb_32 @tab oln::image3d<oln::rgb_32> @tab not ready
@end multitable
All image types are classes in Swilena.
@@ -948,15 +878,19 @@
Access the pixel at @samp{point}, which can be of type @samp{point1d}, @samp{point2d} or
@samp{point3d}.
@item at(dimensions)
-Access the pixel at point specified by one, two, or three coordinantes.
+Access the pixel at point specified by one, two, or three coordinates.
+@item set(point, value)
+Set the value of the pixel at @samp{point}.
+@item set(dimensions, value)
+Set the value of the pixel at the given coordinates.
@item ncols(), nrows(), nslices()
Retrieve the dimensions of the image.
@item load(filename), save(filename)
Input/output to files.
@end table
-The module names for these types are @strong{swilena1d},
-@strong{swilena2d} and @strong{swilena3d}.
+The module names for these types are @strong{swilena_image1d},
+@strong{swilena_image2d} and @strong{swilena_image3d}.
@node Structural Element Types
@section Structural Element types
@@ -968,12 +902,6 @@
@item window1d @tab oln::window1d
@item window2d @tab oln::window2d
@item window3d @tab oln::window3d
-@item w_win1d_int @tab oln::w_window1d<int>
-@item w_win2d_int @tab oln::w_window2d<int>
-@item w_win3d_int @tab oln::w_window3d<int>
-@item w_win1d_float @tab oln::w_window1d<float>
-@item w_win2d_float @tab oln::w_window2d<float>
-@item w_win3d_float @tab oln::w_window3d<float>
@end multitable
All these types family share the following interface:
@@ -1009,18 +937,6 @@
Return the union of this window and another.
@end table
-Also, members of the ``w_win'' (weighted windows) family
-share the following interface:
-
-@table @code
-@item add(dpoint, value), add(coordinates, value)
-Add the specified relative point to the window with weight.
-@item of_win(value, window)
-Create a weighted window from a non-weighted window.
-@item w(i)
-Return the weight of the i'nth ``dpoint'' in the window.
-@end table
-
Here are the corresponding instantiation functions, which
have the same name as their C++ counterpart:
@@ -1101,16 +1017,44 @@
@node Conversion Functions
@section Conversion Functions
-All image conversions share the same function name @code{convert}.
-This function takes the destination image as first argument,
-and the source image as second argument.
+An image can be converted into another kind of image if it their types
+are compatible. Several conversions are possible: with truncation,
+with stretching or direct.
-All conversions between images of scalar values are available.
+The naming scheme is simple, append the name of the destination type
+to the kind of conversion. For example, to perform a conversion from
+an image of @code{int_u32} toward an image of @code{int_u8} with
+stretching, use @code{stretch_to_int_u8(your_image_in_int_u32)}.
-RGB images cannot be converted to and from (yet).
+@unnumberedsubsec Reducing conversions
-The module names for these functions are @strong{swilena1d_convert},
-@strong{swilena2d_convert} and @strong{swilena3d_convert}.
+Stretching (@code{stretch_to}) and truncation (@code{bound_to}) are
+available.
+
+Here are the possible reduction conversions:
+
+@multitable @columnfractions .5 .5
+@item @strong{Source type} @tab @strong{Destination type}
+@item @tab
+@item int_u32 @tab int_u8
+@item int_s32 @tab int_s8
+@end multitable
+
+@unnumberedsubsec Direct conversions
+
+Direct conversions (@code{cast_to}) are possible between all scalar
+types. Some additional conversions are possible:
+
+@multitable @columnfractions .5 .5
+@item @strong{Source type} @tab @strong{Destination type}
+@item @tab
+@item bin @tab any scalar type
+@item any integer type @tab bin
+@end multitable
+
+The module names for these functions are
+@strong{swilena_conversions1d}, @strong{swilena_conversions2d} and
+@strong{swilena_conversions3d}.
@node Morpho Functions
@section Morpho Functions
@@ -1170,8 +1114,13 @@
FIXME: laplacian and hit_or_miss are missing.
-The module names for these functions are @strong{swilena1d_morpho},
-@strong{swilena2d_morpho} and @strong{swilena3d_morpho}.
+Some of them do not actually work with every image type. The exact
+list of supported algorithms for each kind of image should be added to
+the documentation. This list may evolve soon between Olena releases
+though.
+
+The module names for these functions are @strong{swilena_morpho1d},
+@strong{swilena_morpho2d} and @strong{swilena_morpho3d}.
@node Index and Table of contents
@unnumbered Index and Table of contents
@@ -1180,6 +1129,4 @@
@contents
-
-
@bye
Index: integre/ntg/core/macros.hh
--- integre/ntg/core/macros.hh Thu, 27 Nov 2003 11:26:27 +0100 burrus_n (oln/s/19_macros.hh 1.8 640)
+++ integre/ntg/core/macros.hh Sat, 03 Jan 2004 15:38:22 +0100 burrus_n (oln/s/19_macros.hh 1.8 640)
@@ -1,4 +1,4 @@
-// Copyright (C) 2001, 2002, 2003 EPITA Research and Development Laboratory
+// Copyright (C) 2001, 2002, 2003, 2004 EPITA Research and Development Laboratory
//
// This file is part of the Olena Library. This library is free
// software; you can redistribute it and/or modify it under the terms
@@ -49,6 +49,9 @@
| types accessors |
`----------------*/
+# define ntg_abstract_type(T) typename ntg::type_traits<T>::abstract_type
+# define ntg_abstract_type_(T) ntg::type_traits<T>::abstract_type
+
# define ntg_storage_type(T) typename ntg::type_traits<T>::storage_type
# define ntg_storage_type_(T) ntg::type_traits<T>::storage_type
