- Olena - LRE

video papers
by Thierry GERAUD 02 Jun '06

02 Jun '06

nouveau (blink!) ; dans /mnt/doc/sip/image/video/papers/ : contents.bib albiol.00.icpr.pdf marques.99.icip.pdf ballerini.03.scia.pdf matsushita.02.mvc.pdf bang.02.icip.pdf mikolajczyk.04.eccv.pdf bauckhage.04.cvpr.pdf mittrapiyanuruk.05.wacv.pdf berclaz.06.cvpr.pdf okuma.04.eccv.pdf beymer.00.hum.pdf pece.02.pets.pdf biliotti.05.wacv.pdf peer.99.cvww.pdf broggi.00.ivs.pdf pless.00.pami.pdf chang.00.bmv.pdf polat.01.icip.pdf cristani.02.mvc.pdf pujol.00.icpr.pdf cucchiara.04.icpr.pdf ramoser.03.icip.pdf curio.00.its.pdf ricquebourg.00.pami.pdf cutler.00.pami.pdf sato.04.cviu.pdf dante.03.bmv.pdf sato.04.pr.pdf deshmukh.05.micv.pdf schofield.96.pr.pdf egmont.02.pr.pdf sherrah.00.icpr.pdf elgammal.01.iccv.pdf shimizu.03.tr.pdf elgammal.03.syllabus.pdf shimizu.04.ivs.pdf eng.04.icpr.pdf sidenbladh.03.ijcv.pdf fleuret.05.iccv.pdf stauffer.01.cvpr.pdf gavrila.04.ivs.pdf terada.99.icip.pdf haga.04.icpr.pdf verma.03.pami.pdf harasse.05.prcv.pdf vezhnevets.03.gpc.pdf haritaoglu.00.pami.pdf vu.02.wscg.pdf hsu.02.pami.pdf wixson.00.pami.pdf iketani.98.icpr.pdf wohler.00.icpr.pdf jang.02.pr.pdf wu.02.icip.pdf javed.02.mvc.pdf wu.03.cvpr.pdf jepson.03.pami.pdf wu.05.cvpr.pdf jia.04.cvpr.pdf wu.05.iccv.pdf kang.05.pr.pdf wu.06.pami.pdf karaulova.00.bmv.pdf yang.02.pami.pdf khan.05.pami.pdf zhao.02.icpr.b.pdf kim.03.dagm.pdf zhao.02.icpr.pdf lee.00.icpr.pdf zhao.02.mvc.pdf lerdsudwichai.05.pr.pdf zhao.04.cvpr.pdf marcenaro.02.icip.pdf zhao.04.pami.pdf marques.02.pr.pdf

1 1

Olena et G++ 3.3
by Roland Levillain 28 Apr '06

28 Apr '06

Ils ne s'aiment pas beaucoup (je doute qu'ils se marient et aient beaucoup d'enfants ensemble un jour) : make -k -C ~/src/oln/_build-g++-3.3/static/tests any make: entrant dans le répertoire « /home/levill_r/src/oln/_build-g++-3.3/static/tests » if g++-3.3 -DHAVE_CONFIG_H -I. -I../../../static/tests -I../.. -I../../../static -I../../../metalic -g -O2 -pipe -MT any.o -MD -MP -MF ".deps/any.Tpo" -c -o any.o ../../../static/tests/any.cc; \ then mv -f ".deps/any.Tpo" ".deps/any.Po"; else rm -f ".deps/any.Tpo"; exit 1; fi ../../../static/tests/any.cc:137: sorry, unimplemented: « method_call_expr » n'est pas supporté par dump_expr ../../../static/tests/any.cc:137: sorry, unimplemented: « method_call_expr » n'est pas supporté par dump_expr ../../../static/tests/any.cc:137: sorry, unimplemented: « method_call_expr » n'est pas supporté par dump_expr ../../../static/tests/any.cc:137: sorry, unimplemented: « method_call_expr » n'est pas supporté par dump_expr ../../../static/tests/any.cc:138: sorry, unimplemented: « method_call_expr » n'est pas supporté par dump_expr ../../../static/tests/any.cc:138: sorry, unimplemented: « method_call_expr » n'est pas supporté par dump_expr ../../../static/tests/any.cc:138: sorry, unimplemented: « method_call_expr » n'est pas supporté par dump_expr ../../../static/tests/any.cc:138: sorry, unimplemented: « method_call_expr » n'est pas supporté par dump_expr ../../../static/tests/any.cc:147: sorry, unimplemented: « method_call_expr » n'est pas supporté par dump_expr ../../../static/tests/any.cc:147: sorry, unimplemented: « method_call_expr » n'est pas supporté par dump_expr ../../../static/tests/any.cc:147: sorry, unimplemented: « method_call_expr » n'est pas supporté par dump_expr ../../../static/tests/any.cc:147: sorry, unimplemented: « method_call_expr » n'est pas supporté par dump_expr ../../../static/tests/any.cc:148: sorry, unimplemented: « method_call_expr » n'est pas supporté par dump_expr ../../../static/tests/any.cc:148: sorry, unimplemented: « method_call_expr » n'est pas supporté par dump_expr ../../../static/tests/any.cc:148: sorry, unimplemented: « method_call_expr » n'est pas supporté par dump_expr ../../../static/tests/any.cc:148: sorry, unimplemented: « method_call_expr » n'est pas supporté par dump_expr make: *** [any.o] Erreur 1 make: La cible « any » n'a pas pu être refabriquée à cause d'erreurs. make: quittant le répertoire « /home/levill_r/src/oln/_build-g++-3.3/static/tests » Notez le « sorry, unimplemented », tout à fait original. :)

1 0

Olena et le traitement d'image
by Nicolas Widynski 28 Feb '06

28 Feb '06

Quelques propositions concernant la facon simple et claire d'ecrire des algorithmes de traitement d'images : 1) Points, voisins et Dpoints. On voudrait acceder a un voisin particulier d'un point p. Actuellement, on peut faire : oln_type_of(I, point) p2(p.row() + 1, p.col()); -> syntaxe lourde on peut aussi faire ca plus proprement en passant par un dpoint oln_type_of(I, dpoint) dp(-1, 0); et ainsi effectuer une operation du type 'dp + p'. On aimerait peut-etre acceder a un point voisin de facon plus simple en equipant la classe 'point' du methode par exemple 'dp' qui declare le dpoint et effectue le calcul pour nous. Ex: ima[p.dp(-1,0)] -> on accede directement au point p translate du dpoint (-1, 0). 2) Sous-image. Il est parfois (souvent) genant de devoir soit rajouter un parametre de masquage a nos algorithmes soit creer une sous-image de notre image manuellement. Ex: on voudrait lancer un algorithme sous une sous-image de notre image I. Actuellement, on passe par un masque, ou on creer une sous-image manuellement. Contraintes : - La fenetre peut bien sur ne pas etre rectangulaire (c'est plus souvent une zone correspondant a un objet de notre image par exemple). - on souhaite pouvoir acceder a la bordure exterieure de notre fenetre. Ecrire une methode permettant de creer une fenetre simplement est assez difficile, pour l'instant je vois la solution de creer un masque et ainsi de creer une image morpher a partir de notre image de base et de notre masque. 3) Image de type structure. On souhaite souvent creer une image de vecteur, pour l'instant on passe par le vector de la STL puis on est oblige de passer par une methode .at('point') pour lancer une methode de notre type structure. Ex : ima.at(p).push_back(3); On aimerait avoir acces a des types vecteurs directement dans Olena, et donc ecrire la ligne du dessus plus simplement : ima[p].x = 3; 4) point-wise. On aimerait aussi pouvoir declarer un calcul sur un point de facon point-wise. Ex : pw(gradient, ima[p.dp(-1,0)] - ima[p.dp(0,1)]); //on declare la facon de calculer notre gradient dans une image. puis lorsque on fait appel a gradient[p], on calcule seulement a ce moment le gradient au point p. 5) Range des valeurs de notre image. On aimerait pouvoir modifier le range des valeurs de notre image simplement, ce qui revient effectuer un seuillage des valeurs min et max. ima.range().set_min(0); ima.range().set_max(255); ... FIXME : j'ai peut-etre oublie d'autres elements. -- Nicolas Widynski CSI 2007

3 5

reunion olena demain matin
by Reda Dehak 03 Oct '05

03 Oct '05

demain matin, on fait une reunion olena pour discuter des différents problèmes a résoudre ... etc

2 2

réunion
by Thierry GERAUD 29 Sep '05

29 Sep '05

prévue vendredi matin tous les ceusses concernés sont invités

3 2

oln 10.222: Adjust for G++ 4.0
by Roland Levillain 15 Sep '05

15 Sep '05

J'utilise encore Olena 0.10 pour SWT, et plusieurs outils que j'avais écrits ne passent plus l'édition de liens depuis la mise à jour des compilateurs G++ 3.3 et 3.4 dans Debian, à cause de ce bug : http://article.gmane.org/gmane.comp.graphics.crystalspace.general/6771 (... referenced in section `.rodata' of ...: defined in discarded section `.gnu.linkonce.t...) Il a donc fallu que je rende Olena 0.10 G++-4.0-compliant (en tout cas, la partie que j'utilise). Ce qui me fait penser qu'on pourrait terminer ce nettoyage et faire une release corrective de 0.10 qui soit compatible avec G++ 4.0, que l'on pourrait nommer Olena 0.11, ou plus modestement 0.10.1. Qu'en pensez-vous ? Index: ChangeLog Index: integre/ChangeLog Index: olena/ChangeLog Index: olena/oln/arith/logic.hh Index: olena/oln/core/window2d.hh Index: olena/oln/io/gz_stream.hh Index: config/oln.m4 --- ChangeLog Wed, 08 Sep 2004 18:56:06 +0200 thivol_d (oln/o/33_ChangeLog 1.37.1.16.1.17.1.19.1.18 600) +++ ChangeLog Thu, 15 Sep 2005 17:36:52 +0200 levill_r (oln/o/33_ChangeLog 1.37.1.16.1.17.1.19.1.18 600) @@ -1,3 +1,8 @@ +2005-09-15 Roland Levillain <roland(a)lrde.epita.fr> + + * config/oln.m4 (OLN_VERSION): Set to 0.10a. + Remove duplicate definition. + 2004-09-08 Damien Thivolle <damien(a)lrde.epita.fr> * config/oln.m4: Minor fix. --- integre/ChangeLog Sat, 26 Jun 2004 23:19:24 +0200 thivol_d (oln/q/35_ChangeLog 1.12.1.2.1.47 600) +++ integre/ChangeLog Thu, 15 Sep 2005 17:42:26 +0200 levill_r (oln/q/35_ChangeLog 1.12.1.2.1.47 600) @@ -1,3 +1,14 @@ +2005-09-15 Roland Levillain <roland(a)lrde.epita.fr> + + Adjust for G++ 4.0. + + * ntg/color/color.hh + (typetraits<color<ncomps, qbits, color_system> >::nb_comp): Make + it a static const unsigned instead of an enum. + * ntg/vect/cplx.hh (cplx<rect, T>::to_polar): Move the definition + of this function outside the declaration of cplx<rect, T>, so as + to have it know the size of cplx<polar, T>. + 2004-06-26 Damien Thivolle <damien(a)lrde.epita.fr> * ntg/core/internal/global_ops.hh: Make compliant to g++-3.4. --- olena/ChangeLog Thu, 24 Feb 2005 10:10:35 +0100 levill_r (oln/o/30_ChangeLog 1.27.1.36.1.3.1.11.1.5.1.64.1.47.1.93.1.27.2.3 600) +++ olena/ChangeLog Thu, 15 Sep 2005 17:20:50 +0200 levill_r (oln/o/30_ChangeLog 1.27.1.36.1.3.1.11.1.5.1.64.1.47.1.93.1.27.2.3 600) @@ -1,3 +1,14 @@ +2005-09-15 Roland Levillain <roland(a)lrde.epita.fr> + + Adjust for G++ 4.0. + + * oln/core/window2d.hh (neighb_type): Remove duplicate typedef. + * oln/topo/dmap.hh, oln/topo/dmap.hxx (operator[], operator()): + Return a copy, not a reference on a temporary. + * oln/arith/logic.hh: Remove superfluous semi-colons. + * oln/io/gz_stream.hh (zifstream, zofstream): Add forward + declarations. + 2005-02-24 Roland Levillain <roland(a)lrde.epita.fr> * oln/core/abstract/image.hh (oln_fwd_iter_type_): Fix macro --- olena/oln/arith/logic.hh Sat, 13 Mar 2004 17:58:18 +0100 van-vl_n (oln/b/24_logic.hh 1.6.1.4 600) +++ olena/oln/arith/logic.hh Thu, 15 Sep 2005 16:06:43 +0200 levill_r (oln/b/24_logic.hh 1.6.1.4 600) @@ -56,16 +56,16 @@ oln_arith_declare_unfixedtype_functor_(logic_not, ntg::bin, ! val); /// AND NOT operators. - oln_arith_declare_all_nongenericbinop_procs_(logic_and); + oln_arith_declare_all_nongenericbinop_procs_(logic_and) /// OR operators. - oln_arith_declare_all_nongenericbinop_procs_(logic_or); + oln_arith_declare_all_nongenericbinop_procs_(logic_or) /// AND NOT operators. - oln_arith_declare_all_nongenericbinop_procs_(logic_and_not); + oln_arith_declare_all_nongenericbinop_procs_(logic_and_not) /// NOT operator. - oln_arith_declare_nongenericunop_procs_(logic_not); + oln_arith_declare_nongenericunop_procs_(logic_not) } // end of arith --- olena/oln/core/window2d.hh Fri, 02 Apr 2004 16:00:03 +0200 van-vl_n (oln/c/14_window2d.h 1.22 600) +++ olena/oln/core/window2d.hh Thu, 15 Sep 2005 16:50:52 +0200 levill_r (oln/c/14_window2d.h 1.22 600) @@ -77,7 +77,6 @@ typedef struct_elt_traits< self_type >::iter_type iter_type; typedef struct_elt_traits< self_type >::neighb_type neighb_type; - typedef struct_elt_traits< self_type >::neighb_type neighb_type; ///< Type of neighbor. /*! --- olena/oln/io/gz_stream.hh Fri, 02 Apr 2004 18:35:36 +0200 van-vl_n (oln/f/17_gz_stream. 1.11 600) +++ olena/oln/io/gz_stream.hh Thu, 15 Sep 2005 17:20:09 +0200 levill_r (oln/f/17_gz_stream. 1.11 600) @@ -296,6 +296,10 @@ }; + // Forward declarations. + class zifstream; + class zofstream; + ///Define an interface for compressed file stream manipulation. class zfilestream_common : virtual public std::ios { --- config/oln.m4 Wed, 08 Sep 2004 18:56:06 +0200 thivol_d (oln/j/15_oln.m4 1.38.1.10 600) +++ config/oln.m4 Thu, 15 Sep 2005 17:45:58 +020Index: 10.221/olena/oln/topo/dmap.hh Index: olena/oln/topo/dmap.hxx Index: integre/ntg/vect/cplx.hh Index: integre/ntg/color/color.hh 0 levill_r (oln/j/15_oln.m4 1.38.1.10 600) @@ -648,7 +648,6 @@ ### # $Format: "m4_define([OLN_VERSION], [0.$ProjectMajorVersion$])"$ -m4_define([OLN_VERSION], [0.10]) m4_define([OLN_CONTACT], [olena-bugs(a)lrde.epita.fr] # OLN_COLLECTION([subdirs-variable-name], --- olena/oln/topo/dmap.hh Mon, 15 Mar 2004 17:40:54 +0100 van-vl_n (oln/p/2_dmap.hh 1.11 600) +++ olena/oln/topo/dmap.hh Thu, 15 Sep 2005 16:11:09 +0200 levill_r (oln/p/2_dmap.hh 1.11 600) @@ -690,11 +690,11 @@ to_image() const; /// Distance of a point p. - const T& + const T operator[](const point_type& p) const; /// Distance of a point2d(row, col). - const T& + const T operator()(coord row, coord col) const; private: --- olena/oln/topo/dmap.hxx Sat, 26 Jun 2004 23:19:24 +0200 thivol_d (oln/p/3_dmap.hxx 1.7.1.11 600) +++ olena/oln/topo/dmap.hxx Thu, 15 Sep 2005 16:16:57 +0200 levill_r (oln/p/3_dmap.hxx 1.7.1.11 600) @@ -321,14 +321,14 @@ } template <class T, class T2> - const T& + const T dmap<T, T2>::operator[](const point_type& p) const { return imap_[p] / ch_.coef; } template <class T, class T2> - const T& + const T dmap<T, T2>::operator()(coord row, coord col) const { return imap_(row, col) / ch_.coef; --- integre/ntg/vect/cplx.hh Wed, 30 Jul 2003 18:49:16 +0200 burrus_n (oln/t/19_cplx.hh 1.5 600) +++ integre/ntg/vect/cplx.hh Thu, 15 Sep 2005 16:49:38 +0200 levill_r (oln/t/19_cplx.hh 1.5 600) @@ -323,11 +323,9 @@ return cplx<rect, T>(-this->val_[0], -this->val_[1]); } + // Forward declaration. const cplx<polar, float_d> - to_polar() const - { - return cplx<polar, float_d>(magn(), angle()); - } + to_polar() const; }; @@ -423,6 +421,13 @@ }; template<class T> + const cplx<polar, float_d> + cplx<rect, T>::to_polar() const + { + return cplx<polar, float_d>(magn(), angle()); + } + + template<class T> inline std::ostream& operator<<(std::ostream& ostr, const cplx<rect, T>& rhs) { --- integre/ntg/color/color.hh Tue, 30 Mar 2004 12:40:46 +0200 van-vl_n (oln/t/20_color.hh 1.7 600) +++ integre/ntg/color/color.hh Thu, 15 Sep 2005 16:56:10 +0200 levill_r (oln/t/20_color.hh 1.7 600) @@ -56,7 +56,7 @@ template <unsigned> class color_system> struct typetraits<color<ncomps, qbits, color_system> > { - enum { nb_comp = ncomps }; + static const unsigned nb_comp = ncomps; typedef color<ncomps, qbits, color_system> self; typedef self ntg_type;

1 0

ACM Crossroad
by Akim Demaille 14 Sep '05

14 Sep '05

http://www.acm.org/crossroads/doc/cfas/sweng.html Call For Articles Crossroads, the Association for Computing Machinery Student Magazine Software Engineering (Summer 2006) The Crossroads editorial staff invites authors to submit articles dealing with topics drawn from several areas pertaining to software engineering. The following partial list of topics is provided to give prospective authors ideas for articles and is by no means exhaustive; other relevant topics will be considered. Papers that draw connections between two or more of these areas are especially welcome. * Client-Server Software * Component-based Software * Copyrights, Legal, Political and Ethical issues * Deliverables and Documentation * Software Reliability * Process Models and Life Cycles * Project Management (Planning, Estimations, Risk Management) * Software Architectures * Software Development Activities (Requirement Specification, Design, Programming, Testing, Maintenance) * Software Development Methodologies (Formal Methods, Object Oriented and UML) * Software Engineering Education * Software Standards * System Management * Web site Development

1 0

les joies des opérateurs en C++
by Thierry GERAUD 18 Jul '05

18 Jul '05

faites-moi penser à vous en parler...

1 0

De la copie d'image avec voisinage
by Roland Levillain 04 Jul '05

04 Jul '05

En débuggant du code utilisant Olena, j'ai passé du temps sur un problème avant de comprendre ce qui se passait, mais j'ai fini par trouver (ouf!). Un algo qui travaille sur une image avec voisinage, mais qui se fiche de son voisinage (la variante de l'érosion qui prend une fenêtre, par ex.) perd l'information de voisinage dans l'image de sortie. Quelque part, c'est normal, mais c'est assez dérangeant (on a toujours une image_with_nbh<>, mais son voisinage est vide). Voici un exemple qui illustre mon problème : #include <oln/core/2d/image2d.hh> #include <oln/morpho/erosion.hh> #include <oln/core/gen/image_with_nbh.hh> using namespace oln; int main () { image2d<int> ima1 (3, 3); typedef image_with_nbh<image2d<int>, neighborhood2d> ima_type; ima_type ima2 = join(ima1, neighb_c4()); std::cout << "ima2.nbh_get().card () = " << ima2.nbh_get().card () << std::endl; // A naive approach (the neighborhood is lost!). ima_type ima3 = morpho::erosion (ima2, win_c4p()); std::cout << "ima3.nbh_get().card () = " << ima3.nbh_get().card () << std::endl; // The cumbersome (but right) way. ima_type ima4 (morpho::erosion (ima2, win_c4p()).image(), ima2.nbh_get ()); std::cout << "ima4.nbh_get().card () = " << ima4.nbh_get().card () << std::endl; } Et voici ce qui se passe à l'exécution : brasilia ~/tmp/oln-tests % ./lost-nbh ima2.nbh_get().card () = 4 ima3.nbh_get().card () = 0 ima4.nbh_get().card () = 4 La construction de ima4 illustre le work-around que j'ai utilisé. (Je sais que la copie/affectation d'images est un problème dont nous avions déjà évoqué.)

2 1

Re: nouvelle publi 2
by Jerome Darbon 27 Apr '05

27 Apr '05

Thierry GERAUD wrote: > Jerome Darbon wrote: > >> l'article darbon.05.eusipco a été accepté à la conférence... >> >> A moi la Turquie... >> >> J. > > > cool :) > > tu dis : > << In this paper, we present fast algorithms for area opening and > closing on grayscale images. and decisions, is identical to the case > of an attribute opening. > [...] > Both algorithms have been implemented in C/C++ and compiled with full > optimizations. >> > > c'est implémenté dans olena ? non

2 5