Olena January 2004

olena@lrde.epita.fr

18 participants
18 discussions

by Astrid Wang

Est-il vraiment possible de compiler Swilena avec les options d'optimisation ? J'imagine bien qu'avec CXXFLAGS='-Wall -W -O0 -g', ça passe sans problème, mais avec les options par défaut, il n'y a pas moyen, je reste scotchée sur : make[5]: Entering directory `bibi/oln/tools/swilena/python' if g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I /usr/include/python2.3/ -I./../src -DOLN_EXCEPTIONS -I../../../metalic -I../../../metalic -I../../../integre -I../../../integre -I../../../olena -I../../../olena -O3 -finline-limit-1500 -MT swilena_morpho1d_wrap.o -MD -MP -MF ".deps/swilena_morpho1d_wrap.Tpo" \ -c -o swilena_morpho1d_wrap.o `test -f 'swilena_morpho1d_wrap.cxx' || echo './'`swilena_morpho1d_wrap.cxx; \ then mv -f ".deps/swilena_morpho1d_wrap.Tpo" ".deps/swilena_morpho1d_wrap.Po"; \ else rm -f ".deps/swilena_morpho1d_wrap.Tpo"; exit 1; \ fi ... depuis un certain temps déjà. En fait, je voudrais juste savoir si c'était la peine que j'attende jusqu'à après-demain ou si je ferais mieux de laisser tomber et de faire autrement. -- astrid T_T

21 years

*****SPAM***** Welcome to www.dumpsmarket.com

by ivan_alb＠agava.com

21 years

oln 10.54: Fix type of a zero value

by Niels Van Vliet

Index: olena/ChangeLog from Niels Van Vliet <niels(a)lrde.epita.fr> * oln/topo/dmap.hxx: Fix type of a zero value. Index: olena/oln/topo/dmap.hxx --- olena/oln/topo/dmap.hxx Thu, 07 Aug 2003 02:37:23 +0200 burrus_n (oln/p/3_dma p.hxx 1.7.1.8 640) +++ olena/oln/topo/dmap.hxx Fri, 23 Jan 2004 17:45:48 +0100 van-vl_n (oln/p/3_dma p.hxx 1.7.1.8 640) @@ -240,7 +240,7 @@ { typename image2d<V>::iter_type p(input); for (p = begin; p != end; ++p) - if (input[p] != ntg_zero_val(T)) + if (input[p] != ntg_zero_val(V)) { imap_[p] = T(0); nearest_point_map[p] = p;

21 years

*****SPAM***** Corel Ventura 241773

by 241773＠mail.com

Spam detection software, running on the system "kualalumpur.lrde.epita.fr", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or block similar future email. If you have any questions, see the administrator of that system for details. Content preview: OEM Software URI:http://www.mega-oem.info/?241773 Specials good thru 11/12/03. Please use discount code mail9221 to receive these prices. Software: Windows XP Suites, Adobe software, Clearance, Corel Draw/Corel Ventura, Games, 3D Studio Max, Operating Systems, Utilities. [...] Content analysis details: (11.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.3 NO_REAL_NAME From: does not include a real name 0.9 FROM_ENDS_IN_NUMS From: ends in numbers 0.7 ADDR_NUMS_AT_BIGSITE Uses an address with lots of numbers, at a big ISP 1.6 FROM_STARTS_WITH_NUMS From: starts with nums 0.1 HTML_FONTCOLOR_UNKNOWN BODY: HTML font color is unknown to us 0.1 HTML_TAG_BALANCE_A BODY: HTML has excess "a" close tags 0.0 HTML_MESSAGE BODY: HTML included in message 0.2 HTML_TAG_BALANCE_TABLE BODY: HTML is missing "table" close tags 0.1 HTML_FONT_BIG BODY: HTML has a big font 0.1 HTML_70_80 BODY: Message is 70% to 80% HTML 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts 0.6 DATE_IN_PAST_06_12 Date: is 6 to 12 hours before Received: date 1.1 RCVD_IN_DSBL RBL: Received via a relay in list.dsbl.org [<http://dsbl.org/listing?ip=24.201.128.38>] 2.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see <http://www.spamcop.net/bl.shtml?24.201.128.38>] 2.5 RCVD_IN_DYNABLOCK RBL: Sent directly from dynamic IP address [24.201.128.38 listed in dnsbl.sorbs.net] 0.1 RCVD_IN_SORBS RBL: SORBS: sender is listed in SORBS [24.201.128.38 listed in dnsbl.sorbs.net] 1.2 FROM_ALL_NUMS From an address that is all numbers (non-phone) The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor.

21 years

[oln 2003paradigm.78] Checkout failed.

by Noe

Bonne annee à tous, d'abord ! $ prcs checkout -r 2003paradigm.78 oln prcs: Checkout project `oln' version 2003paradigm.78. prcs: File `/tmp/noe/prcs/oln/o/30_ChangeLog,v:1.27.1.36.1.3.1.11.1.5.1.59' too short: expected 75966; recieved 75965 prcs: Command failed. Ce truc là, prcs2svn va avoir du mal à le gerer :) Sur le net, on trouve comme solution la commande `prcs admin rebuild', qui a fonctionné sur ma copie locale. Je ne sais pas si cette commande a des effets secondaires génants, aussi si un praticien en connait, serait-il sympa de les exposer. Dans le cas contraire, il faudrait la lancer sur le repository oln du labo ! -- Noe

21 years

*****SPAM***** Windows XP Service Pack 1 (Express) - Critical Update.

by windowsupdate＠microsoft.com

21 years

*****SPAM***** Clearance 241509

by 241509＠yahoo.com

Spam detection software, running on the system "kualalumpur.lrde.epita.fr", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or block similar future email. If you have any questions, see the administrator of that system for details. Content preview: Norton SystemWorks 2003 Software Suite Professional Edition Five Feature-Packed Utilities URI:http://www.padla-soft.biz/?241509 Specials good thru 11/12/03. Please use discount code mail9221 to receive these prices. [...] Content analysis details: (28.2 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.2 NO_REAL_NAME From: does not include a real name 2.7 ADDR_NUMS_AT_BIGSITE Uses an address with lots of numbers, at a big ISP 1.0 FROM_ENDS_IN_NUMS From: ends in numbers 0.6 FROM_STARTS_WITH_NUMS From: starts with nums 2.7 FROM_WEBMAIL_END_NUMS6 From webmail service and address ends in numbers 4.1 FROM_NUM_AT_WEBMAIL From address is webmail, but starts with a number 0.1 HTML_70_80 BODY: Message is 70% to 80% HTML 5.4 BAYES_99 BODY: Bayesian spam probability is 99 to 100% [score: 1.0000] 0.1 HTML_FONTCOLOR_UNKNOWN BODY: HTML font color is unknown to us 0.3 MIME_HTML_ONLY BODY: Message only has text/html MIME parts 0.1 HTML_MESSAGE BODY: HTML included in message 0.3 HTML_FONT_BIG BODY: HTML has a big font 0.2 HTML_TAG_BALANCE_A BODY: HTML has excess "a" close tags 0.1 BIZ_TLD URI: Contains a URL in the BIZ top-level domain 0.9 FORGED_YAHOO_RCVD 'From' yahoo.com does not match 'Received' headers 1.1 RCVD_IN_SORBS_HTTP RBL: SORBS: sender is open HTTP proxy server [68.252.97.107 listed in dnsbl.sorbs.net] 1.2 RCVD_IN_SORBS_MISC RBL: SORBS: sender is open proxy server [68.252.97.107 listed in dnsbl.sorbs.net] 0.1 RCVD_IN_SORBS RBL: SORBS: sender is listed in SORBS [68.252.97.107 listed in dnsbl.sorbs.net] 0.1 RCVD_IN_NJABL RBL: Received via a relay in dnsbl.njabl.org [68.252.97.107 listed in dnsbl.njabl.org] 0.7 RCVD_IN_DSBL RBL: Received via a relay in list.dsbl.org [<http://dsbl.org/listing?ip=68.252.97.107>] 0.5 RCVD_IN_NJABL_PROXY RBL: NJABL: sender is an open proxy [68.252.97.107 listed in dnsbl.njabl.org] 1.5 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see <http://www.spamcop.net/bl.shtml?68.252.97.107>] 2.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook 0.7 FROM_ALL_NUMS From an address that is all numbers (non-phone) 1.0 FORGED_OUTLOOK_HTML Outlook can't send HTML message only The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor.

21 years, 1 month

10.48: More documentation for integre and swilena.

by Nicolas Burrus

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

21 years, 1 month

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Olena January 2004