11-03-2015, 05:29 PM
Il consiste à considérer les bords des pixels (carrés) au lieu des pixels eux-mêmes (généralement, on considère leur centre.
Un pixel n'est plus vu comme un point avec une couleur (comme c'est le cas avec les textures 3D par exemple) mais comme un aplat de couleur carré dont les bords constituent la frontière.
Je je prends cette image, l'algo considère la moitié de gauche (sans filtrage 3D donc) et non la partie de droite (filtrage, aka gradient progessif entre deux pixels).
Du coup, on a une grille constitué des bords des pixels. Chaque segment (bord de pixel) touche 2 pixels, donc il est facile de savoir si ce segment est une frontière ou non (on compare la couleur des deux pixels). On a donc, pour chaque segment de la grille, un boolean indiquant si ce segment est une frontière. On vire les segments non-frontaliers, et on a le contour des objets (à simplifier par le JS précédent).
Pour une image 10x10, on a donc une grille de 10x10 carrés en 10 colonnes et 10 lignes, donc 11 colonnes de bords (x10 segments par colonne) et 11 lignes de bords (x10 segments par ligne), soient 110+110 segments (220).
Autre exemple plus simple, pour une image de 3x3 pixels (9 carrés donc), on a 4x4=16 sommets et 4x3+4x3=24 segments, et ce sont eux que l'on considère pour calculer le contour des objets (plutôt que de considérer le centre des pixels).
Dans le cas d'exemple de 100x100, l'algo créerait donc une grille de 101x101 sommets (qui englobe l'image), et construirait les 101x100+101x100=20200 segments entre ces sommets pour créer la grille, puis l'algo ne garderait que les segments qui constituent une frontière entre deux pixels de couleur différente (en pratique, mieux vaut construire la grille de 101x101 sommets, puis pour chaque sommet, ne construire que les segments qui sont une frontière entre deux pixels de couleur différente; c'est nettement moins lourd en mémoire que de construire toute la grille pour ensuite supprimer les segments qui ne sont pas des frontières entre pixels de couleur différente).
Un pixel n'est plus vu comme un point avec une couleur (comme c'est le cas avec les textures 3D par exemple) mais comme un aplat de couleur carré dont les bords constituent la frontière.
Je je prends cette image, l'algo considère la moitié de gauche (sans filtrage 3D donc) et non la partie de droite (filtrage, aka gradient progessif entre deux pixels).
Du coup, on a une grille constitué des bords des pixels. Chaque segment (bord de pixel) touche 2 pixels, donc il est facile de savoir si ce segment est une frontière ou non (on compare la couleur des deux pixels). On a donc, pour chaque segment de la grille, un boolean indiquant si ce segment est une frontière. On vire les segments non-frontaliers, et on a le contour des objets (à simplifier par le JS précédent).
Pour une image 10x10, on a donc une grille de 10x10 carrés en 10 colonnes et 10 lignes, donc 11 colonnes de bords (x10 segments par colonne) et 11 lignes de bords (x10 segments par ligne), soient 110+110 segments (220).
Autre exemple plus simple, pour une image de 3x3 pixels (9 carrés donc), on a 4x4=16 sommets et 4x3+4x3=24 segments, et ce sont eux que l'on considère pour calculer le contour des objets (plutôt que de considérer le centre des pixels).
Dans le cas d'exemple de 100x100, l'algo créerait donc une grille de 101x101 sommets (qui englobe l'image), et construirait les 101x100+101x100=20200 segments entre ces sommets pour créer la grille, puis l'algo ne garderait que les segments qui constituent une frontière entre deux pixels de couleur différente (en pratique, mieux vaut construire la grille de 101x101 sommets, puis pour chaque sommet, ne construire que les segments qui sont une frontière entre deux pixels de couleur différente; c'est nettement moins lourd en mémoire que de construire toute la grille pour ensuite supprimer les segments qui ne sont pas des frontières entre pixels de couleur différente).