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