Discussion :

[Gautier_mic]

Bonjour,
Je suis bien conscient que ce sujet a déjà été discuté amplement. Mais, malgré mes recherches sur le forum, je me heurt et n'arrive pas à résoudre un problème effleuré dans un précédent post.

Voici ce que "pseudocode" disait :

Envoyé par winux32
Mon algorithme est-il bon ?

oui, en théorie il fonctionne.

En pratique, cela pose des problèmes si le contour n'est pas "propre" (par exemple des blocs de pixels agglutinés). Dans ce cas on risque soit d'oublier des pixels, ou soit de se perdre dans le parcours.

Justement ! Les contours, on les détecte visuellement bien (à coup de BFS dans les composantes connexes, puis DFS dès qu'on atteint une frontière pour repérer toute la frontière), mais on arrive pas à les stocker proprement dans une structure de données afin d'effectuer d'autres traitements par la suite.

Pour mettre toute la frontière d'une composante (dans une liste par ex), le parcours en profondeur, tel qu'on le fait, ne nous permet pas d'avoir les points les uns à la suite des autres... Pour éviter les configurations bizarres, pas le choix que de prendre le plus long chemin, et là, avec un DFS, et avec les configs "tas de pixels" (qu'on considère la 4 ou 8 adjacences), le parcours explose, exponentiellement.
On a bien pensé à utiliser un dynamique, ou mettre des balises pour éviter de recommencer des bouts de chemins qui sont uniques... mais pb niveau mémoire dans ce cas... non ?

Pour ce qui est de se débarrasser des "amas de pixels", on a essayé divers traitement, mais comme ces configurations sont trop "locales", y a pas vraiment moyen de s'en débarrasser, vu que fermeture, ouverture, etc bouchent de plus gros "trous" et même en les appliquant, on peut créer de ces "mauvais configurations".

Donc, voilà, si quelqu'un sait comment avoir les points de la frontière les uns à la suite des autres pour pouvoir traiter ça par la suite... (calcul de pente), nous lui en serons très très reconnaissant !

Merci d'avance !

[Gautier_mic]

J'ai trouvé comment me débrouiller avec la fonction cvFindContours. Mais quelqu'un connaît-il l'algorithme sous-jacent ?

[Gautier_mic]

Finalement, on a une solution fait-maison pour trouver ces contours !
Et elle marche plutôt bien =D,
comme vous pouvez le voir sur cette vidéo (de 40 secondes) : [ame="http://www.youtube.com/watch?v=Wiu7CY-mWBM"]YouTube- TIPE - Hand Tracking v1[/ame]

Cependant, il doit y avoir une configuration au niveau du contour problématique, car toutes les n frames (n variable et très grand, donc ça ne pose pas vraiment de problèmes), il semblerait qu'on ne trouve pas le contour de la main comme vous pouvez le voir sur la vidéo... (l'image est brièvement dénuée de marqueurs sur les mains)

On a pas trop d'idée d'où cela pourrait venir pour le moment... il y a beaucoup d'étapes qui pourrait faire rater la détection :/. Et ça ne vient pas forcément de notre algorithme de contour...

Avez-vous des idées pour debug efficacement ?

L'idéal serait d'avoir une image du flux qui est résistance à la détection. pour pouvoir afficher toutes les étapes et valeurs de retour de nos algos. Mais, je ne vois pas trop comment l'obtenir et comment l'isoler.
Quand bien même je l'obtiendrai en rajoutant quelques tests dans le code, la quantité de données à analyser serait assez importante, et le temps dont on dispose pour achever le projet touche à sa fin.

Peut-être le mieux est d'essayer de construire les différentes configurations == tas de pixels possibles et de lancer notre programme dessus pour voir s'il tourne bien sur tous ou non...
Mais j'ai du mal à m'imaginer comment construire ces images ?!
Le faire pixel par pixel sous gimp semble assez fastidieux si faisable.
Peut-être un petit script générant ces images, mais je n'ai aucune idée de comment m'y prendre...