[image] Snake (contour actif)

[batoub]

Voila j'ai codé ca moi-même (ca m'aide a voir si j'ai réellement bien compris)

Et voila le résultat sur une image type route :

http://www.imagup.com/imgs/1207213053.html

edit : on voit d'ailleurs qu'il a un petit problème en bas de l'image, il reconnait le bas de l'image comme un contour lors de mon passage dans Canny


Je vais essayer de le modifier en utilisant une valeur non binaire du contour mais en utilisant le gradient. En essayant de rendre la distance inversement proportionnel au gradient pour privilégier les distances par rapport aux contours fortement marqué.

Bonne idée ? ou Fausse pistes ?

[millie]

Envoyé par pseudocode

Je voyais l'algo comme un truc du genre :

On génère une carte d'élévation du terrain (donc noir à 0 mètre et blanc à 100m par exemple), on entoure le truc d'une grande corde avec des roues, et les roues avance vers le milieu (si une pente est trop élevé (on peut voir ça en utilisant le gradient pour la direction du terrain et en regardant la pente à cet endroit), alors la roue s'arrête))

A moins que tu ne considère que la valeur absolu de la pente, dans ce cas, il n'y a pas de soucis.

[pseudocode]

Envoyé par millie

On génère une carte d'élévation du terrain (donc noir à 0 mètre et blanc à 100m par exemple)

On génère une carte d'élévation du GRADIENT du terrain.

[pseudocode]

Envoyé par batoub

Je vais essayer de le modifier en utilisant une valeur non binaire du contour mais en utilisant le gradient. En essayant de rendre la distance inversement proportionnel au gradient pour privilégier les distances par rapport aux contours fortement marqué.

Bonne idée ? ou Fausse pistes ?

@batoub: En tout cas, c'est comme ca que j'ai fait.

[batoub]

Ok, je vais donc essayer d'améliorer un peu mon algo, en tout cas cette méthode est assez géniale, elle donne des résultats casiement similaire a la GVF. En tout cas, elle a trouvé sa place dans ma méthode

Pourquoi cette méthode est beaucoup moins utilisé que les GVF par exemple ?

[pseudocode]

Envoyé par batoub

Pourquoi cette méthode est beaucoup moins utilisé que les GVF par exemple ?

La carte des distances et le GVF n'ont pas de rapport. C'est juste que pour mon énergie de Snake j'ai approximé le GVF par le gradient de la carte des distances.

Prendre une fonction inversement proportionnelle à la carte des distances ca donne "visuellement" le meme résultat, mais ce n'est pas une approximation au sens mathématique. C'est a dire qu'on ne peut pas se choisir un EPSILON et affiner cette approximation jusqu'a atteindre la précision voulue.

[b_reda31]

Bonjour,
J'ai terminé l'implémentation de cet algorithme en utilisant les même méthodes d'énergie de cette contribution.
J'ai essayé de faire quelque essais en jouant sur les différents parametres pour tester chaque énergie mais les résultats ne sont pas très encourageants
J'ai fais quelques captures de mon application en ajoutant les différentes valeurs des parametres ainsi que le nombre d'itérations:


Vous remarquerez que lorsque Beta est non nul,le snake se déplace bien vers les endroits de fort gradient mais il y a une force qui attire le coté droit du snake vers la droite!!

J'ai pourtant implémenter la méthode CURVATURE de la même manière qu'il a été donnée dans la contribution !





D'un autre coté en mettant Beta à 0 afin de tester la méthode UNIFORMITY,Le résultat est carrément chaotique!!


Je vais continuer à vérifier mon code,si quelqu'un aurait une idée sur ce phénomène qu'il m'en fasse part svp...

[pseudocode]

hum... tu es sûr que ton "gradient vector flow" est bon ?

[b_reda31]

Envoyé par pseudocode

hum... tu es sûr que ton "gradient vector flow" est bon ?

Apparement Oui puisque ça converge bien vers les point de fort gradient?!

Je pense que le problème est dans l'énergie Interne.
Je vais quand même revérifier tous ça.

[b_reda31]

Je ne sais pas si c'est le manque de sommeil ou autre chose,mais là tout commence à se chambouler dans ma tête

Je vais essayer de résumer un peu la chose: (y a quelque chose qui cloche mais je ne sais pas ou)

Nous avons l'image originale qui est à droite dans l'application JAR de cette contribution.

Afin de déterminer l'énergie externe du snake il faut calculer la matrice FLOW qui est la la carte de distance normalisée du gradient binarisé de l'image originale....ouf
Donc il faut tout d'abord calculer le gradient de l'image originale (Sobel par ex),ensuite binariser le gradient.

à partir de gradient binaire il est donc possible de construire la carte de distance en utilisant un masque de chamfer selon cette contribution.
A ce stade nous avons une carte de distance normalisée FLOW,qui est appelée dans cette méthode :

Code :

1
2
3
4
5
6
7
8
private double f_gflow(Point cur, Point p) {
	// gradient flow
	int dcur = this.flow[cur.x][cur.y];
	int dp   = this.flow[p.x][p.y];
	double d = dp-dcur;
	return d;
}

J'ai utilisé le masque chamfer3 (new int[] {1,0,3},new int[] {1,1,4}) donc pour normaliser j'ai diviser tous les elements de la matrice FLOW par 3.Et voici FLOW que j'ai obtenu après normalisation:


Elle parait noir mais elle est juste trop sombre.



Et si je ne normalise pas FLOW voici ce que j'obtiens :

Envoyé par Pseudocode :

Cela n'a rien à voir avec les résultats que j'ai obtenu.
Aurais je fais une erreur quelque part?



FLOW et GRADIENT+FLOW est ce la même chose?


Merci d'avance pour vos réponses.

[pseudocode]

Envoyé par b_reda31

Afin de déterminer l'énergie externe du snake il faut calculer la matrice FLOW qui est la la carte de distance normalisée du gradient binarisé de l'image originale....ouf

1. Pour rectifier la vérité, le GVF n'a pas de rapport avec la carte des distances. C'est juste une approximation que j'ai choisi car c'est plus rapide à calculer.

2. il NE faut PAS normaliser la carte des distances. Dans mes posts, je l'ai normalisée uniquement pour la représenter sous forme d'une image en niveaux de gris. Dans le code, la matrice prends des valeurs entre 0 (pixel sur le pic de gradient) jusqu'à l'infini (enfin, jusqu'aux limites de l'image)

3. Je ne vois pas tes images car le serveur de ImagUp à l'air malade. Pour ce qui concerne mon image en niveau de gris, j'ai utilisé la formule "niveau_de_gris=Math.max(0,255-flow)". Mais c'est juste pour l'affichage de l'image. Dans le code on utilise les valeurs "brutes" de la carte des distances.

[b_reda31]

Envoyé par pseudocode

2. il NE faut PAS normaliser la carte des distances. Dans mes posts, je l'ai normalisée uniquement pour la représenter sous forme d'une image en niveaux de gris. Dans le code, la matrice prends des valeurs entre 0 (pixel sur le pic de gradient) jusqu'à l'infini (enfin, jusqu'aux limites de l'image)

Quand je disais "normaliser",c'etait par rapport au masque de Chamfer:

Si X est un point contours (Vaut 0)alors

Son voisinage avant normalisation:

4---3---4
3---X---3
4---4---3

Et apres normalisation :

4/3---1---4/3
1-----X---1
4/3---1---4/3

1. Pour rectifier la vérité, le GVF n'a pas de rapport avec la carte des distances. C'est juste une approximation que j'ai choisi car c'est plus rapide à calculer.

J'ai un petit problème concernant les notations:

GVF=GRADIENT+FLOW?
FLOW=Carte de distance?

Pour ce qui concerne mon image en niveau de gris, j'ai utilisé la formule "niveau_de_gris=Math.max(0,255-flow)". Mais c'est juste pour l'affichage de l'image. Dans le code on utilise les valeurs "brutes" de la carte des distances.

C'est exactement la question que je me suis posé.Merciiii à vous c'est beaucoup plus clair maintenant!

[pseudocode]

Envoyé par b_reda31

Quand je disais "normaliser",c'etait par rapport au masque de Chamfer

Ok. Donc là, oui, il faut normaliser. Cela fait partie integrante du calcul de Chamfer.

J'ai un petit problème concernant les notations:
GVF=GRADIENT+FLOW?
FLOW=Carte de distance?

FLOW = GVF = Gradient Vector Flow.

Dans mon approximation, c'est le vecteur gradient de la carte des distances (donc le gradient de la carte des distances du gradient ).

Dans la formule dans la methode f_gflow(), on cherche dans quelle direction ce vecteur "descend" le plus, et donc nous ammène vers le minimum local le plus proche dans la carte des distances.

C'est une approximation car, avec l'utilisation des masques de Chamfer, seule la "direction" est correcte. La "norme" est constante (=1) qu'on soit loin du minimum local.

[b_reda31]

Envoyé par pseudocode

FLOW = GVF = Gradient Vector Flow.

Dans mon approximation, c'est le vecteur gradient de la carte des distances (donc le gradient de la carte des distances du gradient ).

Alors si je comprend bien vous avez "approximé" le GVF en utilisant la carte de distance?
J'ai pu faire cette approximation pour l'énergie externe et ça marche très bien.Néanmoins cette approximation nécessite de binariser l'image avec un seuil que choisira l'utilisateur?!! c'est plutôt gènant ça
Connaissez vous une approximation du GVF qui ne m'oblige pas à binariser l'image (car le problème se situe au niveau du choix du Seuil de binarisation)

[pseudocode]

Envoyé par b_reda31

Connaissez vous une approximation du GVF qui ne m'oblige pas à binariser l'image (car le problème se situe au niveau du choix du Seuil de binarisation)

Le mieux c'est de calculer le vrai GVF. Cela dit, meme avec le vrai GFV, il y aura toujours le problème du choix de coefficients du snake.

[b_reda31]

Envoyé par pseudocode

Le mieux c'est de calculer le vrai GVF.

J'ai cherché sur google avec le mot clé GVF,hélas j'ai trouvé que des définitions très "analytiques dont je ne comprend le principe de calcu....
Auriez vous un lien qui pourra m'aider à implementer le vrai GVF comme vous dites,sinon juste le principe car la je suis un peu perdu.

Cela dit, meme avec le vrai GFV, il y aura toujours le problème du choix de coefficients du snake.

Oui certe,je voudrai juste pouvoir faire la comparaison entre les deux méthodes.

[pseudocode]

Envoyé par b_reda31

Auriez vous un lien qui pourra m'aider à implementer le vrai GVF comme vous dites,sinon juste le principe car la je suis un peu perdu.

c'est pourtant le 1er lien de google: http://iacl.ece.jhu.edu/pubs/p087c.pdf

1. Pour chaque pixel (x,y) on initialise u(x,y)=0 et v(x,y)=0
2. Pour chaque pixel (x,y) on recalcule u(x,y) et v(x,y) avec les formules (12a) et (12b) du document
3. retour a l'etape 2, jusqu'a convergence.

Sinon il y a des implémentations dans codesearch

[b_reda31]

Envoyé par pseudocode

c'est pourtant le 1er lien de google: http://iacl.ece.jhu.edu/pubs/p087c.pdf

Quand je parlais des articles très "analytiques" dont je n'ai compris le principe,celui que vous m'avez donné en fait justement partie

En tout cas je viens de l'imprimer, et je vais le relire à tête reposé.Peut être que demain je poserai une question plus utile concernant le GFV,car pour le moment je n y vois que du noir!
Merci

[b_reda31]

Envoyé par pseudocode

1. Pour chaque pixel (x,y) on initialise u(x,y)=0 et v(x,y)=0

Pourtant dans la source que vous m'avez donné u et v sont initialisés au GradientX,GradientY respectivement de la "edge map" (carte de contour)

2. Pour chaque pixel (x,y) on recalcule u(x,y) et v(x,y) avec les formules (12a) et (12b) du document

Voici les formules (12a) et (12b) j'ai retiré l'indiçage)

u=Mu*delta2(u)-(u-fx).(fx²+fy²)...(12a)
v=Mu*delta2(v)-(v-fy).(fx²+fy²)...(12b)

tel que :
f est la carte des contour (Edge map)
fx gradientX de f ,fy gradientY de f.

Pour ce qui est de Delta2 (Operateur Laplacien),je ne connais pas cet opérateur.Est ce le gradient du gradient?

La base du calcul du GVF repose sur le calcul de la Edge Map f ,Or c'est la première fois que j'entends ce terme ,Est ce tout simplement le gradient de l'image?

[benDelphic]

pour le laplacien
http://xphilipp.developpez.com/artic.../?page=page_12
http://www.developpez.net/forums/sho...d.php?t=513674
( c'est un Kernel de convolution pour un Edge detection)