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 :
Justement ! Les contours, on les détecte visuellement bien http://gautier_marti.zouig.org/contours.jpg (à 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.Citation:
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.
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 !
