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<I> > : public props <I> {
typedef I delegated_type;
};
template <typename I>
struct id_morpher
: public abstract::from_image_morpher< I, id_morpher<I> >
{
typedef abstract::from_image_morpher< I, id_morpher<I> > 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.
}
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.
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.
nouveau répertoire :
/mnt/doc/tsi/libs
destiné à regarder les bibliothèques dispo. elles sont
classées par langages :
lang.c:
megawave/ vista/ vsipl/
lang.c#:
ipinc#/
lang.c++:
cimg/ confidential__horus/ gill/ imlib3d/ mia/ olena/ vigra/
lang.cpp:
cppima/ devil/ imlab/ ipl98/ pandore/ qgar/ tip/
lang.java:
imagej/ java-image/ jiu/
lang.python:
image-sig/ ipl/ pil/ pyip/
comme vous pouvez le constater, je différencie :
lang.c = écrite en C ou en C++ qui a oublié son ++
lang.cpp = écrite en C++ (en vrai C++)
lang.c++ = écrite en C++ avec des template
(on peut considérer que ce n'est pas normal de ne pas
utiliser "template" au moins pour les types de données ;
si vous n'êtes pas d'accord, il suffit de le dire et de
dire pourquoi, et on peut en parler)
attention :
lang.c++/confidential__horus/ est confidentielle.
cette bibliothèque qu'a mentionnée jérôme à la réunion et
qui existe depuis plusieurs années *est* générique mais
n'est *pas* distribuée.
son mainteneur est ok pour nous la passer mais avec
interdiction de la diffuser.
on va enfin voir à quoi elle ressemble.
toute critique est la bienvenue (je me suis peut-être
viandé dans mon classement, etc.)
----------------------------------------------
From: Richard Massey <rjm(a)astro.caltech.edu>
Subject: Shapelets
To: damien.thivolle(a)lrde.epita.fr
Date: Tue, 31 Aug 2004 13:43:47 -0700 (PDT)
Hello Damien,
Google reveals that you are a fellow shapelet enthusiast. I was very
interested to view your slides from a recent resentation, and am now
curious to know if you have made any progress with galaxy morphology
classification, pattern recognition, or anything else with shapelets. I'm
keen to hear of any uses you may find!
Alexandre Refregier and I have just written a new paper on shapelets, in
which you may be interested. You can download it from
http://www.arxiv.org/abs/astro-ph/0408445
What exactly is the LRDE? The projects there sound fascinating. Anyway,
this is just a friendly hello from one shapeleteer to another,
Yours,
Richard Massey
California Institute of Technology 105-24
1200 E. California Blvd.
Pasadena, CA 91125, USA
Tel: +1 626 395 2654
Web: http://www.astro.caltech.edu/~rjm/
---------------------------------------------
Je lui répondrai demain.
--
Damien Thivolle
damien.thivolle(a)lrde.epita.fr
/mnt/doc/tsi/image/rdf/proceedings/icpr_04/
fonctionne avec xpdf (avec acroread, ça marche pas)
le répertoire /mnt/doc/tsi/image/proceedings/ a été créé
pour recenser tous les actes qu'on a (orthogonalisation)
pour l'instant, il contient le lien ./icpr_04
peut-être faut-il mieux inverser lien / localisation physique ?
(débat ouvert)
