18 Feb
2006
18 Feb
'06
12:20 p.m.
Nicolas Widynski <widyns_n(a)lrde.epita.fr> writes:
J'ai rien dit.
--
Giovanni Palma
EPITA - promo 2005 - LRDE
Mob. : +33 (0)6 60 97 31 74
Giovanni Palma wrote:
Oui et non, car si tu fait un push_back (ou l'équivalent, que je n'ai
plus en tête) des dpoints que tu veux utiliser dans un neighborhood,
tu peut itérer sur ton voisinage pour chaque points. Pour ma part je
trouve ça assez élégant et peut contraignant (une ligne par dpoint que
tu veux utiliser). Enfin peut être que mon jugement est biaisé ou que
je ne vois pas un exemple simple où cette méthode est mauvaise.
Nicolas Widynski <widyns_n(a)lrde.epita.fr>
writes:
Exact. La solution est mauvaise.
Cependant, d'un point de vue utilisateur, la syntaxe est lourde et peu
intuitive.
On est oblige de modifier entre chaque operation le dpoint pour
acceder a un autre point voisin. Ca parait evident dit comme ca, mais
ca reste tout de meme assez lourd. Quelques propositions concernant la facon simple
et claire d'ecrire
des algorithmes de traitement d'images :
J'ai quelques remarques, sur les points que tu présentes
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).
Je trouve que ce n'est que du sucre syntaxique, utile pour les
gens
que ne codent pas d'algo de façon générique (on a plus d'abstraction
de dimension dans l'exemple que tu donnes). Je pense personnellement
(ca n'engage que moi bien sûr) qu'utiliser des dpoints (avec un
voisinage pour les mettre dedans) reste assez propre et permet d'avoir
une bonne abstraction, de plus ce n'est pas quelque chose de
complètement tordu pour un utilisateur basique.
[...]
Ca change avec
le proto 1.0.
ima[p] renvoie un nouvel objet, il n'y a pas de version avec reference.
ima.at(p) renvoie une ref.
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;
J'avoue ne pas tout saisir là. Des types vecteurs sont déjà dispo
dans
olena (au moins la 0.10). Je ne vois pas non plus pourquoi on doit
utiliser une méthode at et non pas l'opérateur [] dans le cas
d'utilisation de stl (j'ai sûrement loupé quelque chose). [...]
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);
Là non plus je ne comprends pas tout. C'est quoi le but de la manip
?
faire un stretch ? Si oui, il existe des algo SÉPARÉ la classe image
pour le faire. J'insiste sur le séparé car il se passe quoi si on est
pas sur un type scalaire. Si c'est juste pour faire des checks, il y a
les types integre.