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@lrde.epita.fr> * ref/integre-ref.tex: Update. * demo/tour.cc (main): Check i/o errors. Index: integre/ChangeLog from Nicolas Burrus <burrus_n@lrde.epita.fr> * ntg/core/macros.hh (ntg_abstract_type): New macro. Index: tools/swilena/ChangeLog from Nicolas Burrus <burrus_n@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