- Olena - LRE

Pages d'Olena
by Akim Demaille 04 Nov '04

04 Nov '04

La page d'Olena, http://www.lrde.epita.fr/cgi-bin/twiki/view/Projects/Olena, devrait être quelque peu allégée. Je suggère en particulier l'introduction d'une page OlenaPapers avec les publications et les rapports techniques. Loïc a mis ça en oeuvre pour Vaucanson, de la meilleure façon possible (avec des Search qui font que ça se met à jour tout seul). Cf. http://vaucanson.lrde.epita.fr/Papers (c'est miraculeux qu'elle marche cette URL !!!)

1 0

Re: 1732: Fix typos; use Doxygen's \arg for functions arguments
by Roland Levillain 22 Oct '04

22 Oct '04

>>>>> "Akim" == Akim Demaille <akim(a)epita.fr> writes: >>>> "Roland" == Roland Levillain <roland(a)lrde.epita.fr> writes: >> Arg, désolé. Je me suis inspiré de la documentation d'Olena, qui >> utilise \param pour les paramètres de templates, et \arg pour les >> arguments de fonctions. Akim> Alors il faut la corriger ! La doc de Doxygen montre ce pour quoi Akim> c'est fait \arg. Oui, je viens de la lire et j'ai vu la différence. (Je CC la ML Olena.)

1 0

Koala
by Akim Demaille 15 Oct '04

15 Oct '04

http://www.program-transformation.org/Tools/KoalaTools The Koala-tools package is a collection of tools operating on the Koala component definition language as developed by Philips Research. Koala is a component definition language used by Philips consumer electroniccs to model components (as C modules), composition (as C compilation and linking), and variability (as CPP macros and partial evaluation). The Koala component model consists of a component language, which supports definition of: * interfaces (both required and provided) * data types * components * diversity (by means of a diversity interfaces) * component compositions Component compositions consist of collections of components and wires that connect provides and requires interfaces (see picture below). [...]

1 0

des nouvelles du proto
by Thierry GERAUD 12 Oct '04

12 Oct '04

Cf. déjà dit, le proto supportait l' ``héritage conditionnel'' ; depuis cet été j'ai seulement défini la liste des abstractions correspondant aux images (ex : abstract::greylevel_image) un objectif est de pouvoir définir des morpheurs génériques le plus simplement possible. Le problème est double pour un tel morpheur : - avoir l'héritage qui va bien (résolu par l'utilisation des propriétés) - ne pas avoir à recoder les méthodes que le morpheur doit fournir. un exemple : les valeurs d'une image (ref) sont vues à travers une fonction (f) => une image morphée (ima). ima[p] renvoit donc f(ref[p]). on doit pouvoir appeler ima.size() pour accéder aux dimensions de l'image vue à travers f mais on n'a pas envie d'écrire cette méthode. si ce type de morpheur est implémenté par la classe fimage<I,F> avec I type de ref et F type de f, on doit redéfinir "op[]" et "op[] const" mais on ne veut pas coder fimage<I,F>::size(). En effet, d'après la description de ce morpheur, la méthode "size" n'est pas transformée (on doit avoir "ima.size()" est équivalent à "ref.size()). Pire, on ne connaît pas la liste des méthodes que l'on devraient écrire ! Si les données de ref sont stockées avec un buffer mémoire linéaire, on peut appeler ref.buffer() pour récupérer son adresse de début et "ref.buffer_size()" pour connaître sa taille (longueur). On doit donc pouvoir faire de même avec ima. En revanche, si ref n'est pas "linéaire", ima ne l'est pas non plus. Comment demander au programmeur qui doit définir la classe paramétrée "fimage" (et ses méthodes) de gérer tous ces cas ? soluce dans le proto, on définit des hiérarchies d'abstractions ; par exemple abstract::image dont un bout est donné ci-dessous : template <typename E> struct image : public internal::get_image_impl < image<E>, E > { unsigned npoints() const // abstract { return this->exact().impl_npoints(); } //... }; ici npoints() est une méthode abstraite et on code la liaison à la main (via this->exact().impl_) ce qui change par rapport à "avant" (hier et les jours encore avant), c'est le fait qu'on puisse récupérer des implémentations par défaut pour les méthodes. elles arrivent via l'héritage de internal::get_image_impl (notez le "get"). bien sûr, il faut écrire les implémentations par défaut (le "set" qui correspond au "get") : template <typename E> struct set_image_impl < image<E>, E> : public virtual image_impl<E> { unsigned impl_npoints() const { return this->delegate().npoints(); } //... }; vous voyez qu'ici, ce n'est pas "exact()" (liaison) qui est appelé mais "delegate()" (délégation). On ne rêve pas, une implémentation par défaut signifie qu'on a un objet concret quelque part qui nous fournit cet implémentation. Dans le cas d'un morpheur (ima), c'est bien sûr l'image morphée (ref). au bout du compte, un morpher "identité" (un morpheur qui ne change rien à l'image ciblée) s'écrit en quelques lignes : template <typename I> struct id_morpher; template <typename I> struct props < id_morpher > : public props { typedef I delegated_type; }; template <typename I> struct id_morpher : public abstract::from_image_morpher< I, id_morpher > { typedef abstract::from_image_morpher< I, id_morpher > super; id_morpher(const I& ref) : super(ref) { exact_ptr = this; } }; et pour vérifier que ça marche, on définit ref puis on appelle des méthodes attendues naturellement : int main() { image2d<int> ref(16, 64); std::cout << ref.npoints() << std::endl; // le morpheur qui en fout pas une : id_morpher< image2d<int> > ima(ref); std::cout << ima.npoints() << std::endl; // comme toute image std::cout << ima(5, 1) << std::endl; // car ref est 2d std::cout << ima.buffer_size() << std::endl; // car ref a un buf.lin. }

1 0

Re: [DOC] publications récupérées
by Thierry GERAUD 12 Oct '04

12 Oct '04

Thierry GERAUD wrote: > > tous ceux qui récupèrent des publis sur le net pour leur > recherche *devraient* poser les articles sur la partition > de documentation du labo (/mnt/doc/) > > cela afin que chacun puisse bénéficier de leurs trouvailles > et que tout le monde économise du temps > [...] de nouveaux répertoires et articles sur la morpho maths : /mnt/doc/computer_vision/morpho % ls -d1 * README clustering/ color/ connected_filters/ divers__a_trier/ fuzzy/ genericity/ levelling/ luc_vincent__a_trier/ self_dual/ theory/ wst/ un bon nombre d'articles de Luc Vincent ont été traduits de djvu en pdf (répertoire luc_vincent__a_trier/) le détail, en attendant de faire "mv" et d'ajouter les "*.bib" correspondants : /mnt/doc/computer_vision/morpho % ls * README clustering: barata.02.icpr.pdf fontaine.00.icpr.pdf vandenbroucke.98.icip.pdf bicego.03.emmcvpr.pdf geraud.01.icip.pdf xue.03.icip.pdf chen.98.itip.pdf postaire.93.pami.pdf zhang.00.icpr.pdf dornellas.00.icpr.pdf vandenbroucke.00.icpr.pdf color: README iwanowski.99.iciap.pdf salembier.98.itip.ps.gz dornellas.98.sibgrapi.pdf li.96.icip.pdf salembier.98.sp.ps.gz geraud.01.icip.pdf park.98.pr.pdf salembier.99.iicsvt.pdf geraud.01.icisp.pdf salembier.00.itip.pdf wegner.96.icip.pdf geraud.95.icip.pdf salembier.95.itip.pdf xue.03.icip.pdf gomila.99.icip.pdf salembier.96.itip.ps.gz hagyard.96.icip.pdf salembier.97.itcsvt.ps.gz connected_filters: BinaryImageAnalysis\ (bw).pdf meijster.98.eusipco.pdf BinaryImageAnalysis.pdf meijster.98.eusipco.ps.gz BinaryImageProcessing.pdf meijster.book/ CS340b.UnionFind.ps meine.04.bvm.pdf README meyer.98.ismm.pdf Report-375-1994.ps.ps moga.97.pami.pdf acton.98.itip.pdf monasse.00.itip.pdf andrade05.pdf morel.chap6.pdf arbelaez.03.vlsm.pdf najman.04.sdrr.pdf atine.pdf najman.04.svg.pdf ayala.02.tr.pdf najman.05.dam.pdf bertrand.04.svg.pdf neemuchwala.02.asilomar.pdf bieniek.00.pr.pdf nguyen.03.pami.pdf bieniek.98.ismm.ps.gz odobez.03.cbmi.pdf braganeto.99.ciss.pdf ramos.00.ecdl.pdf breuel.01.sdiut.pdf ramos.00.recpad.pdf brox.01.sitb.pdf rautio.pdf caselles.02.jmiv.pdf roerdink.00.fi.ps.gz cha.03.nar.pdf roerdink.00.pr.pdf chassignet.sujet.ps salembier.00.icpr.pdf coll.00.icpr.pdf salembier.00.icpr.ps.gz deandrade.99.mr.pdf salembier.00.itip.pdf dokladal.00.phd.pdf salembier.02.ismm.pdf eow.ball-detection.pdf salembier.95.itip.pdf felkel.01.tr.pdf salembier.98.itip.pdf fiorio.96.tcs.ps.gz salkin.04.slides.pdf gatica-perez.02.ismm.pdf sankar...pdf gatica.01.csvt.1.pdf serra.99.dgci.pdf gatica.01.csvt.2.pdf stoc99.ps gatica.01.ip.pdf stoev.00.iv.pdf gomila.99.icip.pdf stoev.00.wscg.pdf guichard.02.ismm.pdf union-find-problem.txt.txt haris.98.ip.pdf.pdf urbach.02.ismm.pdf hesselink.01.scp.ps.gz urbach.04.icpr.pdf hesselink.03.ipl.pdf vachier.01.gretsi.pdf jalba.03.icip.pdf vachier.01.icip.pdf lotufo.02.sibgrapi.pdf villalobos.02.ismm.pdf louverdis.02.hcai.pdf vincent.91.pami.pdf meijster..titlecon.pdf wayne.04.slides.pdf meijster.00.ismm.pdf wilkinson.00.icpr.pdf meijster.01.icip.pdf wilkinson.00.ismm.pdf meijster.02.pami.pdf wilkinson.02.icpr.pdf meijster.02.sip.pdf wood..isotoposimp.pdf meijster.95.caip.pdf yoram.99.cvpr.pdf meijster.95.csn.pdf young.02.ismm.pdf meijster.96.computation.pdf yu.02.icme-slides.pdf meijster.96.ismm.pdf yu.02.icme.pdf meijster.96.ismm.ps zanoguera.02.ismm.pdf divers__a_trier: arrighi-soille99.pdf* chunsun_paris99.pdf* suzuki.03.cviu.pdf* belaid.00.bn.pdf* nc04.ps.gz* fuzzy: barlas.doc.pdf bloomberg.00.jei.pdf koeppen.slides.pdf bloch.03.course.ps.gz dubois.03.ifsa.pdf koeppen.tut.pdf bloch.95.pr.pdf franke.00.icpr.pdf sinha.95.itfs.pdf genericity: darbon.02.ismm.pdf ornellas.99.sibgrapi.ps.gz ornellas.98.ismm.ps.gz vigra-handbook.ps.gz levelling: angulo.03.bi.pdf maragos.00.ivph.pdf serra.99.dgci.pdf butt.98.itip.pdf maragos.03.ijcv.pdf sofou.01.icip.pdf dornellas.00.icpr.pdf maragos.99.sp.pdf sofou.03.icip.pdf dornellas.98.sibgrapi.pdf meyer.00.jvcir.pdf terolvillalobos.02.ismm.pdf dornellas.99.sibgrapi.pdf meyer.02.ismm.pdf tzafestas.02.jmiv.pdf doulamis.01.icip.pdf meyer.99.sp.pdf vachier.04.jmiv.pdf heijmans.02.ismm.pdf papandreou.04.cvpr.pdf zanoguera.02.ismm.pdf jung.02.sibgrapi.pdf salembier.00.icpr.pdf manay.03.itip.pdf salembier.96.itip.pdf luc_vincent__a_trier: beucher.90.tdi.pdf tang.98.air.pdf vincent.92.nsp.pdf bloomberg.00.jei.pdf vincent.00.fi.pdf vincent.93.ip.pdf heijmans.92.jvcir.pdf vincent.89.as.pdf wilkinson.no-math.pdf jeulin.92.jvcir.pdf vincent.89.sp.pdf yanikoglu.98.pr.pdf rosen.94.usnjua.pdf vincent.91.pami.pdf yuille.92.jmiv.pdf serra.92.cssp.pdf vincent.91.sp.pdf self_dual: ageenko.00.prl.pdf heijmans.00.icip.pdf salembier.00.ismm.pdf ahmed...pdf heijmans.00.tr.pdf salembier.02.ismm.pdf ballester.01.cmla.ps heijmans.94.icip.pdf serra...pdf bangham.96.pami.pdf heijmans.98.istftsa.pdf sidiropoulos.97.itsp.pdf carolina.04.course.pdf lyberis...pdf thesis.upc.chap2.pdf charith.03.isispa.pdf ray...pdf vanvliet.02.course-1.pdf forbes.97.tr.ps ray.03.icip.pdf vanvliet.02.course-2.pdf hanbury.01.itip.pdf robinson.04.prl.pdf weber.01.nc.pdf theory: Heijmans_Zakopane_intro.ps.gz mmtutor.pdf hanbury.slides.pdf tarjan.cours.pdf wst: acton.98.itip.pdf najman.04.spie.pdf bertrand.04.spie.pdf najman.96.pami.pdf figueroa.98.eusipco.ps.gz najman.96.pami_answer.pdf gauch.93.pami.pdf najman.96.pami_comments.pdf haris.98.itip.pdf rainfall.pdf lapeer.02.miua.pdf roerdink.fi.01.pdf malpica.97.cyto.pdf shafarenko.ip.97.pdf najman.03.dgci.pdf vachier.02.ismm.pdf najman.04.spie.2.pdf

5 9

les conteneurs std::
by theo.lrde＠free.fr 02 Oct '04

02 Oct '04

avec le petit bout de code en fin de message, les images d'olena sont compatibles avec les conteneurs de la bibliothèque std et avec ses algos. pour un type I d'image, il suffit de former std::container< boxed > ou std::container< boxed<const I> > et pour accéder aux images, il suffit de sortir l'image de la boîte. avec un vecteur v : unbox(v[0]).npoints() // - - - - - - - - - - - - - - - - - - - - - - - - - - - - template <class T> struct boxed { boxed(T ref) : ref(ref) {} boxed(const boxed<T>& rhs) : ref(rhs.ref) {} boxed<T>& operator=(boxed<T>& rhs) { this->ref = rhs.ref; return *this; } operator T() { return ref; } T& unbox() { return ref; } const T& unbox() const { return ref; } friend class boxed<const T>; private: mutable T ref; }; template <class T> struct boxed <const T> { boxed(const T& ref) : ref(const_cast<T&>(ref)) {} boxed(const boxed<T>& rhs) : ref(const_cast<T&>(rhs.ref)) {} boxed(const boxed<const T>& rhs) : ref(const_cast<T&>(rhs.ref)) {} boxed<const T>& operator=(const boxed<const T>& rhs) { this->ref = const_cast<T&>(rhs.ref); return *this; } operator const T() const { return ref; } const T& unbox() const { return ref; } private: mutable T ref; }; template <class T> T& unbox(boxed<T>& b) {return b.unbox(); } template <class T> const T& unbox(const boxed<T>& b) {return b.unbox(); }

1 0

Prototype de biliotheque avec propriete
by Jerome Darbon 27 Sep '04

27 Sep '04

Niels et moi meme avons developpe un embryon (apres les autre qui ont avorte) de bibliotheque disponible a /home/lrde/prof/jerome/THESE/niels L'architecture repose principalement sur les idees de Czarnecki (composants et generateurs). Il y a certainement (i.e proba de 1) des bugs.

2 1

Iteration statique sur des voisinages
by Jerome Darbon 27 Sep '04

27 Sep '04

Idem. Un embryon d'iteration statique sur des fenetres. le code est mis en ligne : voir fichier main.s ~jerome/THESE/static

2 5

[HELP!] cvs et bibliothèque à récupérer
by Thierry GERAUD 08 Sep '04

08 Sep '04

j'ai besoin d'aide. je souhaite récupérer openmorpho : http://cvs.sourceforge.net/viewcvs.py/openmorpho/ mais je ne sais pas comment faire. est-ce qqu'un peut m'éclairer ? merci d'avance

2 2

[sondage] utilisation d'olena
by Thierry GERAUD 08 Sep '04

08 Sep '04

les ing1 qui ont utilisé olena ont répondu au sondage que vous trouverez en fin de message. voici une synthèse des réponses : La prise en main d'olena vous a semblé : Très facile 1 Facile 3 Plutôt facile Plutôt difficile 1 Difficile Très difficile Au final, quelle est votre impression sur olena ? Très favorable 2 Favorable 3 Plutôt favorable Plutôt défavorable Défavorable Très défavorable Facilité d'utilisation : Très bonne 3 Bonne 1 Plutôt bonne Plutôt mauvaise 1 Mauvaise Très mauvaise Documentation : Très bonne 1 Bonne Plutôt bonne 2 Plutôt mauvaise 1 Mauvaise 1 Très mauvaise Lisibilité des messages d'erreur : Très bonne Bonne 2 Plutôt bonne 2 Plutôt mauvaise 1 Mauvaise Très mauvaise Facilité de développement : Très bonne Bonne 4 Plutôt bonne 1 Plutôt mauvaise Mauvaise Très mauvaise Légèreté du processus de prototypage : Très bonne Bonne Plutôt bonne 4 Plutôt mauvaise 1 Mauvaise Très mauvaise Qualité de la distribution : Très bonne Bonne 1 Plutôt bonne 1 Plutôt mauvaise Mauvaise Très mauvaise ================================================= Questionnaire « utilisateur d'olena » PARTIE 1 --------- Aviez-vous déjà utilisé un outil de manipulation d'images ? (ce peut être une bibliothèque ou un logiciel de retouche d'images ou de création artistique) _ Oui /_/ Non /_/ Si oui, lequel/lesquels : ...................................... Aviez-vous déjà utilisé un outil de traitement d'images ? (tout sauf un logiciel de retouche d'images ou de création artistique) _ Oui /_/ Non /_/ Si oui, lequel/lesquels : ...................................... Aviez-vous déjà utilisé une bibliothèque de traitement d'images ? NB : bibliothèque = collection de routines = pas un outil interactif. _ Oui /_/ Non /_/ Si oui, laquelle/lesquelles : .................................. La prise en main d'olena vous a semblé : _ Très facile /_/ Facile /_/ Plutôt facile /_/ Plutôt difficile /_/ Difficile /_/ Très difficile /_/ Si votre réponse comporte « difficile », pourquoi ? (justifiez-vous) .................................................................... .................................................................... .................................................................... Au final, quelle est votre impression sur olena ? Très favorable /_/ Favorable /_/ Plutôt favorable /_/ Plutôt défavorable /_/ Défavorable /_/ Très défavorable /_/ Si votre réponse comporte « défavorable », pourquoi ? (justifiez-vous) .................................................................... .................................................................... ...................................................................... PARTIE 2 Il s'agit de cocher une case par colonne dans le tableau ci-dessous pour donner votre appréciation concernant différents aspects d'olena. Lisez tout d'abord svp les précisions qui sont données sous le tableau. ---------------+--------+--------+----------+--------+--------+-------+ |Facilité|Documen-|Lisibilité|Facilité|Légèreté|Qualité| |utilisaO|tation |des msgs |de dév. |du proto|distrib| appréciation | (*1) | (*2) |d'err (*3)| (*4) | (*5) | (*6) | ---------------+--------+--------+----------+--------+--------+-------+ Très bonne | | | | | | | ---------------+--------+--------+----------+--------+--------+-------+ Bonne | | | | | | | ---------------+--------+--------+----------+--------+--------+-------+ Plutôt bonne | | | | | | | ---------------+--------+--------+----------+--------+--------+-------+ Plutôt mauvaise| | | | | | | ---------------+--------+--------+----------+--------+--------+-------+ Mauvaise | | | | | | | ---------------+--------+--------+----------+--------+--------+-------+ Très mauvaise | | | | | | | ---------------+--------+--------+----------+--------+--------+-------+ (*1) Facilité d'utilisation. Il s'agit d'évaluer le niveau de simplicité d'utilisation d'olena par une personne qui connaît plutôt bien le C (mais qui a un peu de mal avec les pointeurs) et qui sait ce qu'est une classe et un appel de méthode en C++. On considère uniquement l'aspect « utilisateur d'une bibliothèque » (il n'est pas question ici de suggérer qu'une interface homme-machine serait utile pour un utilisateur non informaticien). (*2) Documentation. Il s'agit d'évaluer la clarté et la complétude de la documentation. On souhaite donc répondre à la question : « est-ce que la documentation est ok ? » (*3) Lisibilité des messages d'erreur. En C++, certains messages d'erreur sont obscurs pour un débutant ; passé ce stade d'initiation au langage et à un compilateur, on connaît alors les messages d'erreur usuels. Il reste alors les messages d'erreur que vous pouvez obtenir avec olena et qui ne sont dû qu'à olena. Par exemple : un appel à une routine avec un mauvais argument entraîne un message qui fait apparaître la signature de la routine d'olena => si cette signature est trop complexe, l'utilisateur sera dérouté. Le but de l'évaluation est ici d'apprécier la difficulté relative de la lisibilité des erreurs liées à une mauvaise utilisation d'olena par rapport à la lisibilité des erreurs liées à une mauvaise utilisation de la bibliothèque standard du C++ (la « STL »). (*4) Facilité de développement. On considère maintenant qu'il y a pas dans olena le traitement que vous devez réaliser (ce traitement est très spécifique à votre problème, ce n'est pas un opérateur « classique » de traitement). Il vous faut donc écrire par vous-même ce traitement : pour chaque point qui vérifie une propriété, regarder ses voisins, etc. Olena fournit des outils pour développer : des classes utilitaires (point, itérateurs, etc.), des méthodes (ima.size(), p.row(), etc.) et des routines (l'op + dans « pp = p + dp » par exemple). Il s'agit d'évaluer ici la facilité de développement grâce à ces outils. (*5) Légèreté du processus de prototypage. Vous êtes en phase de recherche d'une solution à un problème de reconnaissance des formes ; vous devez donc expérimenter, c'est-à-dire, faire des allers-retours incessants entre : « développement » d'une chaîne de traitement (en C++ avec des appels à olena), « test » de cette chaîne sur des images et matage des résultats, « modification » du code pour tenter d'améliorer les résultats, etc. La compilation en C++ est beaucoup plus lente qu'en C mais, pire, à cause d'olena elle est encore plus lente. Il s'agit d'exprimer ici votre degré de satisfaction (ou d'insatisfaction) lié à l'utilisation l'olena pour expérimenter des chaînes de traitement. (*6) Qualité de la distribution. Olena est distribué sur l'Internet sous licence GPL et sous la forme d'un fichier-archive compressé (.tar.gz) avec les outils classiques d'installation d'un tel projet (configure, make). Il s'agit ici d'évaluer la qualité de cette distribution.

4 11