Olena

olena@lrde.epita.fr

325 discussions

by Roland Levillain

I've started to write a small set of rules and propositions w.r.t Olena 1.0's coding style: https://trac.lrde.org/olena/trac.cgi/wiki/CodingStyle The document should also be the place to discuss and establish the naming conventions for the project (identifiers, file names, etc.). This is just a beginning (lots of TODO, most not mentioned). Some paragraphs are tagged as ``Questions'', and are open to discussions. Everybody's welcome to the discussion!

18 years, 6 months

Re: [gistr][olena] compilation

by Roland Levillain

"Arnaud Leroy" <leroy.arnaud(a)gmail.com> writes: > Bonsoir, > À propos de ce problème de compilation, avec une version snapshot > d'Olena, la a260 : > - En essayant sous une BSD (version 6.x, récente quoi), AUCUN > problème. ./configure et make / make install font bien leur travail > (normal me direz vous). Good news! > - La même opération sous MinGW/MSYS réagit toujours de la même > manière sous Windows : sh.exe fork, tente de parcourir les > répertoires sans rien trouver à faire, et le nombre de process > augmente linéairement au cours du temps ... Il ne reste qu'à > 'killer' le process principal et rien n'est donc possible. Étrange. Il faudra que l'on teste. > - Je n'ai pas réessayé sous Mandriva, car je n'ai pas eu accès au PC > au moment voulu. > Conclusion : > Il est possible que pour Mandriva, au moment de compiler, je n'avais > pas les droits d'accès aux répertoires ; c'est une hypothèse qu'un > des membres du groupe de projet a évoqué, mais je n'ai pas le > souvenir d'avoir vu des 'access denied' à la compilation. > Pour Windows, ca doit être du à MinGW/MSYS, d'autant plus que de > base, peu de commandes existent (un g++ décent notamment, pas de > more, ni su, etc.), et pas non plus de répertoire /usr ! Pour compiler/installer Olena, il faut grosso modo : - un Bourne Shell (/bin/sh) ; - Make ; - un compilateur C++ récent (à partir de g++ 3.4, ou bien le Intel C++ Compiler, mais ça fait longtemps qu'on a pas testé) ; - Doxygen, GraphViz et PDFLaTeX si tu recompiles la documentation (ce qui ne devrait pas arriver, sauf si tu modifies le code d'Olena avant de taper `make') ; - SWIG 1.3.29 + Python (>= 2.3) + Ruby (>= 1.8) si tu compiles Swilena. A priori, la présence de /usr n'est pas indispensable -- si ce n'est qu'Olena essaiera de s'installer par défaut dans /usr/local, en créant tous les répertoires nécessaires si besoin est (sauf si --prefix désigne un autre préfixe d'installation). > --prefix semble ne pas suffire, et je soupçonne donc l'environnement > trop exotique de MSYS d'être responsable de la chose. Au final, peu > de certitudes, mieux vaut utiliser une distribution unix décente. En > quelques minutes, on a eu après compilation une petit exe (hum un > fichier compilé quoi) qui applique quelques filtres à une image. Le > rêve. C'est super ! :) > Merci en tout cas de vos réponses et conseils, si j'ai du nouveau > sur des OS exotiques (windaube/MSYS), je vous ferai signe. Merci ! On est très preneurs d'informations pour améliorer la compatibilité d'Olena sur diverses plate-formes (notamment MinGW/MSYS et Cygwin). Roland

18 years, 6 months

Re: [gistr][olena] compilation

by Roland Levillain

"Arnaud Leroy" <leroy.arnaud(a)gmail.com> writes: > Bonsoir, Bonjour, > Tout d'abord, après l'écriture de ce mail, je me rends compte que je suis un > peu trop verbeux. Voir la section "Mes questions" si vous voulez aller à > l'essentiel. > J'aimerai utiliser la bibliothèque Olena dans mon projet de fin d'études. > Pour cela j'ai téléchargé les sources (0.10) dans le but de compiler une > bibliothèque utilisable dans mon proj. Plutôt que d'utiliser la release 0.10 (qui date de 2004), il vaut mieux récupérer une version « snapshot » d'Olena 0.10a ici : http://www.lrde.epita.fr/~levill_r/olena/snapshots/ En effet, ces snapshots bénéficient de nombreuses améliorations quant à la compatibilité avec des outils récents (compilateurs C++, SWIG, etc.). (Au passage, la page https://olena.lrde.epita.fr/cgi-bin/twiki/view/Olena/Download#CurrentOlenaB… référence toutes les versions d'Olena disponibles.) > Malheureusement, sans succès. J'ai d'abord essayé avec MSYS (ok > windows c'est pas l'idéal), puis sous mandriva. De mémoire, je crois que nous n'avons pas testé Olena 0.10 sous MinGW/MSYS. Et idem pour Cygwin (ou alors, ça fait très longtemps). Nous sommes en revanche preneurs d'informations à ce sujet ! (Nous disposons d'une build farm avec un hôte Cygwin, mais il est hors service actuellement.) > Résueltat : toujours la même ; le configure a l'air de se passer > correctement, mais au moment de faire make, il entre et sort des > répertoires sans rien compiler ... En fait, c'est (relativement) normal : Olena 0.10 est une bibliothèque « presque » uniquement constituée d'en-têtes C++, et aucun code n'est compilé par défaut. Cependant, j'ai dit « presque » : en effet, Olena 0.10 est livré d'une part avec des outils en ligne de commande, pour appliquer des filtres sur des images depuis un shell, par exemple ; et d'autre part, la bibliothèque dispose de bindings vers Python et Ruby (via SWIG). Tous ces outils sont compilés par défaut, à moins que tu n'invoques configure avec l'option `--without-tools'. > Ma dernière option a été de récupérer à la main ce qui me semblait > nécessaire, seulement c'est une tâche relativement fastidieuse, > récupérer les hh et hxx, d'autant que seules certaines > fonctionnalités me sont nécessaire (comme les dilatations-erosions > (fermeture) sur des image2d). C'est un peu l'horreur, j'ai passé 2 > jours à essayer de compiler tout ca sur MSYS ... La procédure d'utilisation d'Olena est mal documentée ; en pratique, il suffit de faire ./configure --prefix=PREFIX # éventuellement, avec --without-tools make make install # nécessite les permissions ad hoc # pour écrire dans PREFIX où PREFIX est le lieu où tu veux installer Olena. Par défaut, PREFIX = /usr/local, ce qui nécessite le plus souvent des permissions d'administrateur. Je conseille personnellement l'installation dans un répertoire comme $HOME/local/olena-0.10 : ./configure --prefix=$HOME/local/olena-0.10. make make install Ensuite, ton utilisation d'Olena dépend de la façon dont est gérée ton projet : * si tu n'utilise pas les Autotools, fait en sorte de passer l'option `-I' idoine à ton compilateur. Cela peut se faire via la variable CXXFLAGS d'un Makefile, par exemple. En reprenant l'exemple ci-dessus : CXXFLAGS = -I$HOME/local/olena-0.10/include * si tu utilises les Autotools, tu peux bénéficier du support du fichier oln.m4 installé dans PREFIX/olena-0.10/share/aclocal/oln.m4. Grosso modo, il suffit de : 1. ajouter ces lignes au fichier configure.ac de ton projet : # ------------------------------------------------------------- # Remove any debugging and optimization flag from CXXFLAGS to # please Olena configuration system (seen in Olena's # configure.ac). if test ! ${CXXFLAGS+set}; then CXXFLAGS="" fi # Look for a C++ compiler. AC_LANG([C++]) AC_PROG_CXX # Olena. AC_WITH_OLN # Set CXXFLAGS_DEBUG, CXXFLAGS_OPTIMIZE and CXXFLAGS_STRICT. AC_CXX_FLAGS # ------------------------------------------------------------- 2. bootstrapper ton projet en informant aclocal de la présence de oln.m4 : export ACLOCAL='aclocal -I ~/local/olena-0.10/share/aclocal' autoreconf -f -v -i (ces commandes peuvent être placées dans un script `bootstrap' pour éviter d'avoir à les retaper, le cas échéant). 3. configurer le projet en indiquant où se situent les headers d'Olena : ./configure --with-oln=$HOME/local/olena-0.10/include Dans tous les cas, tu devrais pouvoir utiliser les structures de données (images, points, itérateurs, etc.) et algorithmes ainsi : // ----------------------------------------------------------------- // test.cc // Binary data type. #include <ntg/bin.hh> // Use oln::image2d and 2d tools. #include <oln/basics2d.hh> // A simple algorithm. #include <oln/level/fill.hh> int main() { // A 2d binary image of 3 rows per 3 columns. oln::image2d<ntg::bin> ima(3, 3); // Fill it with « true ». oln::level::fill(ima, true); // And so on. // ... } // ----------------------------------------------------------------- > --------------------- > Mes questions > > J'ai fait le projet d'analyse d'image l'année dernière (puzzle), dans lequel > on utilisait la lib compilée. Serait-il encore en votre possession (logins : > leroy_a et richar_t) ? Sur ce point, il faut voir avec Théo. > Y a-t-il possibilité de récupérer une lib compète compilée (32 bits), je > sais c'est pas l'idéal mais bon ca éviterait des calvities précoces. Non ; mais tu peux compiler les outils en ligne de commande (c'est fait par défaut, sauf si tu passes --without-tools à configure). Il seront installés dans PREFIX/olena-0.10/bin. Malheureusement, ces outils ne sont compilés que pour des images en niveaux de gris sur 8 bits, et il y a peu d'algorithmes. Tu peux aussi jeter un coup d'oeil à Swilena (cf. tools/swilena), mais c'est plus complexe, et il te faudra une connaissance minimal de SWIG, et de Python et/ou Ruby. N'hésite pas à poser des questions sur la liste de diffusion olena(a)lrde.epita.fr, nous sommes plusieurs à y être abonnés. Roland

18 years, 6 months

Fwd: [Boost-users] [boost] Review of Generic Image Library (GIL) begins today, Oct5, 2006

by Johan Oudinet

Adobe se met a faire sa propre bibliotheque d'images en C++ et cherche a s'integrer dans Boost... leurs objectifs semblent proches de ceux d'Olena (cf la description plus bas) ---------- Forwarded message ---------- From: Tom Brinkman <reportbase(a)gmail.com> Date: Oct 5, 2006 11:40 AM Subject: [Boost-users] [boost] Review of Generic Image Library (GIL) begins today, Oct5, 2006 To: boost(a)lists.boost.org The review of Generic Image Library (GIL) begins today, October 5, 2006, and continues through October 15, 2006. Please download the library at: http://opensource.adobe.com/gil. Minor change are being made regularly (daily), so check the site often for updates. I highly recommend viewing the 55 minute Breeze presentation describing the library at: http://opensource.adobe.com/gil/presentation/index.htm A tutorial is available at: http://opensource.adobe.com/gil/gil_tutorial.pdf A design guide is availage at: http://opensource.adobe.com/gil/gil_design_guide.pdf Description: The Generic Image Library (GIL) is a C++ library that abstracts the image representation from operations on images. It allows for writing the image processing algorithm once and having it work for images in any color space, channel depth and pixel organization, or even synthetic images, without compromising the performance. GIL has an extension mechanism that allows for adding extra functionality. Two extensions are currently provided – one for image I/O and one for handling images whose properties are specified at run-time. Review questions: Please always explicitly state in your review, whether you think the library should be accepted into Boost. You might want to comment on the following questions: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Tom Brinkman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users -- Johan

18 years, 7 months

Re: [Olena] Header guards

by Akim Demaille

>>> "Roland" == Roland Levillain <roland(a)lrde.epita.fr> writes: > Currently, header guards have this form: > OLENA_CORE_ABSTRACT_IMAGE_HH // for oln/core/abstract/image.hh in Olena > STATIC_VTYPES_HH // for stc/vtypes.hh in Static > but they don't really match the file paths. I'd prefer to use the > namespace as a prefix rather than the project name. The guards taken > as examples above would then read: > OLN_CORE_ABSTRACT_IMAGE_HH // for oln/core/abstract/image.hh in Olena > STC_VTYPES_HH // for stc/vtypes.hh in Static > What do you think? That's nicer, and easier to automate, I would say.

18 years, 7 months

Compile Issue

by Andre Hauptfleisch

Morning, I'd like to use parts of the Olena framework, but am unable to compile the project. I've attached the shell output. Could you please advise? -- Best, Andre Hauptfleisch Student Researcher Address: Meraka Institute Building 43, Office B142 Pretoria Brummeria South Africa T: +27 (0)12 841 2814 M: +27 (0)82 5722 469 F: 086 617 9666 (SA only) E: ahauptfleisch(a)csir.co.za http://ict4eo.meraka.csir.co.za http://andreh.wordpress.com xmpp:ahauptfleisch@jabber.org -- This message is subject to the CSIR's copyright, terms and conditions and e-mail legal notice. Views expressed herein do not necessarily represent the views of the CSIR. CSIR E-mail Legal Notice http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html CSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.html For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal Notice send a blank message with REQUEST LEGAL in the subject line to CallCentre(a)csir.co.za. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support.

18 years, 7 months

Header guards

by Roland Levillain

Currently, header guards have this form: OLENA_CORE_ABSTRACT_IMAGE_HH // for oln/core/abstract/image.hh in Olena STATIC_VTYPES_HH // for stc/vtypes.hh in Static but they don't really match the file paths. I'd prefer to use the namespace as a prefix rather than the project name. The guards taken as examples above would then read: OLN_CORE_ABSTRACT_IMAGE_HH // for oln/core/abstract/image.hh in Olena STC_VTYPES_HH // for stc/vtypes.hh in Static What do you think?

18 years, 8 months

Template metaprogramming in D

by Roland Levillain

Il y a peut-être des idées à prendre au langage D en matière de programmation statique, notamment pour Scool (pour plus tard) : http://www.digitalmars.com/d/templates-revisited.html Je n'ai parcouru cette page que brièvement, mais des bouts de code comme template factorial(int n) { static if (n == 1) const factorial = 1; else const factorial = n * factorial!(n-1); } ou void test() { typedef int fp(int); assert( is(fp == function) ); } font fichtrement penser à des constructions de Scool !

18 years, 11 months

video papers

by Thierry GERAUD

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

18 years, 11 months

Olena et G++ 3.3

by Roland Levillain

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. :)

19 years

← Newer
1
...
9
10
11
12
13
14
15
...
33
Older →

Jump to page:

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