Soutenance mémoire
Segmentation Mean-Shift
L’estimateur de la densité du gradient, le Mean-Shift utilise différentes gammes de valeurs, répertoriées dans deux domaines, pour, entre autres, produire une segmentation d’image. L’espace du maillage est connu comme le domaine spatial (« spatial domain ») tandis que les informations des pixels (niveau de gris, couleurs…) sont représentées dans ce l’ on appelle le « range domain » (domaine des attributs). Les pixels comportent donc 5 informations : X, Y et R, G, B ou H, S, V . Le principe de cet algorithme est de rechercher les « modes » ou maxima locaux de densité d’une répartition donnée.
La segmentation d’une image par cette méthode se déroule en deux étapes :
On associe (par convergence) tout d’abord à chaque pixel de l’image, le mode le plus proche,
Puis, on fusionne les pixels d’un même mode pour former une région.
Durant le processus itératif, l’algorithme recherche dans une aire donnée (en fonction du rayon spatial) le centre des masses (= maxima local) de densité. La distance entre le point initial et le centre des masses de la zone forme le vecteur Mean-Shift (figure 5)
Segmentation Connected Components
L’objectif de cet algorithme est d’effectuer la segmentation par composant es connexes avec un critère de segmentation défini par l’utilisateur (CNES, 2013). Ce critère est une équation appliquée à chaque pixel de l’image.
Après que la segmentation ait été appliquée, l’algorithme labellise les objets : un niveau de gris différent est attribué à chaque composante.
Segmentation Watershed
La segmentation par ligne de partage des eaux considère une image de niveau de gris comme un relief topographique dont on simule l’inondation (Wikipedia Foundation, 2013). On calcule le gradient de l’image. Les hautes intensités (proches du blanc) forment les sommets des collines et les basses intensités (proches du noir) forment les vallées. Lorsque le processus commence, chaque vallée est remplie par de l’eau. Chaque vallée a sa propre couleur. Lorsque deux bassins de couleurs différentes se rencontrent, on crée une ligne de partage qui empêche leur fusion. Lorsque tout le relief est sous l’eau, le processus s’arrête. Les lignes de partage des eaux forment alors notre résultat (OpenCV dev Team, 2014).
Segmentation Morphological profiles based
Cette méthode de segmentation d’image utilisant la morphologie mathématique est fondée sur deux outils principaux : la transformation en bassins versants de l’image et la transformation homotopique qui résout le problème de la sur-segmentation et introduit la notion de marqueurs des objets à segmenter. Les marqueurs des objets à segmenter permettent, avant l’application du Watershed, de savoir quelles sont les zones d’intérêt et quelles sont les zones d’arrière-plan. Dans l’utilisation basique de la segmentation par ligne de partage des eaux, la distinction de ces zones n’est pas faite, ainsi on se retrouve avec des lignes détectées qui ne devraient pas l’être. Pour y remédier, on applique une modification homotopique qui change le minima de l’image par un autre, l’équivalent des marqueurs d’arrière-plan (il enlève du processus les zones qui ont été considérées comme arrièreplan par l’utilisateur) (Meyer, 1992).
Python : Scikit-Image
Présentation de Scikit-Image
Scikit-Image est une bibliothèque d’algorithmes pour le traitement d’image dans le langage de programmation Python. Elle est open-source.
Elle propose principalement les 5 algorithmes suivants :
Edge Based Segmentation,
Region based Segmentation,
Random walker,
Felzenszwalb,
Segmentation Edge Based
Un moyen simple pour segmenter une image est de choisir un seuil sur la base de l’histogramme des niveaux de gris de cette image. Malheureusement, appliquer un seuil sur une image peut produir e un résultat dans lequel il manque de nombreuses zones d’intérêt (valeurs en-dessous du seuil supprimées).
Pour ce faire, nous obtenons tout d’abord les contours en utilisant le détecteur Canny edgedetector.
L’algorithme fonctionne de la manière suivante :
1- Filtrage gaussien (Passe-Bas) pour limiter le bruit de l’image
2- Calcul des gradients des niveaux de gris de l’image par filtrage de Canny (Passe-Haut). Pour cela, il calcule le gradient vertical puis le gradient horizontal et termine en obtenant de ces deux derniers la norme des gradients.
3- Seuillage par Hysteresis avec un seuil haut et un seuil bas pour détecter les points de contour.
4- Squelettisation des contours. C’est-à-dire amincissement des contours à 1 pixel. Dans le cas de contours larges, il garde le pixel qui à la plus forte norme dans la direction du gradient.
5- Ces contours (formant des régions) sont ensuite remplis en utilisant une morphologie mathématique, ceci ne fonctionne que si les contours sont fermés .
6- Élimination des objets de petite taille par la mise en place d’une taille minima le.
Segmentation Region Based (~Watershed)
Tout d’abord, nous trouvons une carte d’élévation en utilisant le gradient de Sobel de l’image (nous pouvons appliquer un masque pour limiter la zone de traitement). Puis, nous trouvons des marqueurs de l’arrière-plan et des régions d’intérêt en nous fondant sur les valeurs extrêmes des niveaux de gris de l’image.
Pour terminer, nous utilisons la transformée en bassins versants pour « remplir » les zones de la carte d’élévation à partir des marqueurs déterminés ci-dessus. La transformée en bassins versants est expliquées plus profondément dans la partie 3.1.4..
Segmentation Random Walker
De la même manière que le précédent algorithme, le Random walker détermine la segmentation d’une image à partir d’un ensemble de marqueurs d’étiquetage (de régions d’intérêt et d’arrière plan) (Scikit-image development team, 2014). Une équation de diffusion est r ésolue avec les traceurs initialisés à la position des marqueurs. Le coefficient de diffusion est plus grand si les pixels voisins ont des valeurs similaires, de sorte que la diffusion soit difficile à travers des gradients élevés. Chaque pixel reçoit l’étiquette du marqueur connu qui a la plus forte probabilité d’être atteint e au cours de ce processus de diffusion.
Segmentation Felzenszwalb
Cet algorithme de segmentation d’image a un paramètre d’échelle qui influe sur la taille des segments (Scikit-image development team, 2014). Une image RGB verra ses 3 canaux traités individuellement. Pour former le résultat final, l’algorithme ne gardera que les segments appa rtenant aux 3 canaux (intersection des 3 canaux). La taille réelle et le nombre de segments peuvent varier considérablement en fonction du contraste local.
Post-traitement
A la fin du traitement par notre algorithme Region based segmentation, nous obtenons un résultat binaire. Nous avons, entre autres, des petites régions détectées comme étant des pierres (alors que ce sont plus souvent des ombres) et des zones enclavées dans les pierres qui, par une différence de couleur trop importante avec le reste des pierres, ont été classées comme de l’arrière-plan (figure30).
Nous cherchons à remédier à ce problème par un post-traitement : l’utilisation de la fonctionnalité remove_small_objects. Cette dernière, permet à partir d’une valeur fixée par l’utilisateur de rechercher dans l’image toutes les régions qui sont formées à partir d’un nombre de pixels inférieur à ce chiffre. Puis, elle supprime toutes ces régions. Comme nous l’avons dit, nous avons deux types de régions à supprimer. La seconde (les zones enclavées) possède des valeurs de pixels à 0. Or notre fonctionnalité ne recherche que les objets dont les pixels ont des valeurs supérieurs à 1. Nous avons donc procédé de la manière suivante.
Etude de l’Algorithme retenu
Lors de ces tests nous avons travaillé avec l’image test et l’image de la figure 1.
Nous avons ré-échantillonné ces deux images à différentes tailles de pixels pour appliquer à chaque résultante nos tests décrits en 3.3.2. . Par ce procédé, nous avons cherché à déterminer une taille de pixel relativement idéale (taille de pixel optimale pour un traitement automatique le meilleur qui soit).
Lors des tests, nous avons procédé au traitement d’image via l’algorithme sélectionné précédemment le Region based segmentation. Les résultats ont été produits sans l’option remove_small_objects puis avec, pour nous permettre de comparer une fois de plus l’impact qu’il peut avoir sur la qualité des résultats.
Concernant la première image test, nous avons fixé les paramètres de seuils d’arrière-plan à 50 et de région d’intérêt à 130 (figure 32).
Les données ne décèlent qu’une pierre non détectée. Cela est dû au fait que les pavés sont assez bien définis (contraste important entre un pavé et le sol). De plus, les indices numéro 1 et 2, nous indiquent que les résultats s’améliorent lorsque l’on sous-échantillonne l’image jusqu’à 0,125 mais qu’ils se dégradent au delà. Cela nous laisserait penser que la taille de pixel optimale pour un traitement qui soit le meilleur possible ( concernant cette image test) se trouverait aux alentours de 4,8 mm.
Néanmoins, si nous comparons les résultats des deux images, nous nous apercevons qu’il n’y a pas de taille optimale universelle de pixels. Nous ne l’avons pas trouvé pour la première image test mais cette dernière, dont les contours des pierres sont très bien définis, peut être très bien résolue (taille de pixel inférieure à 1 mm). Quant à la seconde image, dont les pollutions sont nombreuses (graviers et terres dont les variations provoquent des éclaircissements et des ombres, ce qui implique des gradients forts ; niveaux de gris divers au sein d’une même pierre…), le traitemen t n’est plus le même : il faut absolument baisser la définition de l’image pour limiter un maximum les gênes occasionnées par le sol (autre que pavé) sans pour autant que l’image soit si floue qu’on ne distingue plus correctement la limite des pierres.
Développement d’une interface graphique
Concernant cette première partie du projet, (détection des contours de pierres et briques sur un mur de façade par la segmentation d’une image numérique) nous n’avons pas trouvé d’outil dédié à une telle démarche.
Nous avons fait le choix suivant : créer par nos propres moyens, à l’aide du langage de programmation Python, un outil possédant une interface graphique avec laquelle l’utilisateur p eut interagir.
L’écriture de ce programme comporte 2 parties :
la programmation de l’interface graphique,
la compréhension et l’implémentation informatique de l’algorithme de traitement d’image.
Interface graphique
Concernant la réalisation de l’interface graphique, nous avons choisi le langage de programmation Python. Il existe au sein de ce der nier diverses bibliothèques de widgets pour les interfaces. La plus courante et la plus simple d’utilisation es t Tkinter. Le choix possible, plus complet et plus complexe, de la bibliothèque PyQT (simple lien entre Python et QT ) n’a pas été retenu puisque nous n’avons pas besoin des fonctionnalités supplémentaires que peut proposer PyQT. De plus, durant un certain temps, nous pensions pouvoir nous contenter de l’interface déjà programmée via la bibliothèque de MatPlotLib (figur e 34).
Cette interface paraissait parfaite puisqu’elle nous permettait de visualiser et d’enregistrer nos résultats (2) très facilement. De plus, elle bénéficiait d’un zoom (1). Cependant, nous nous sommes rapidement rendu compte que l’interface enregistrait le résultat qu’elle affichait (ce dernier étant dégradé pour être affiché à l’écran). Nous avons alors écarté cette solution, même si lors de nos tests des algorithmes, elle nous a été d’une grande aide car rapide d’utilisation (peu de programmation pour visualiser nos résultats). Commençons par découvrir la conception de la fenêtre principale qui a été développée avec Tkinter (figure 35).
Implémentation du traitement d’image
Entre le moment où l’on ouvre une image, le moment où on applique le traitement d’image et le dernier moment où l’on enregistre notre résultat, notre image peut changer très souvent de type (codages flottant, entier, booléen…). La gestion de ces images est un point problématique que nous avons réglé à travers l’utilisation de différentes bibliothèques : la bibliothèque Scikit-Image permettait de traiter l’image et la bibliothèque Pillow permettait l’ouverture, l’enregistrement des images ainsi que la modification de leur type.
De plus, on peut ouvrir une image avec une certaine fonction d’une bib liothèque donnée puis une fonction suivante, d’une autre bibliothèque, nécessite en entrée un type précis d’objet qui n’est pas celui fourni par la première fonction. Par exemple, les fonctions de la bibliothèque Scikit ne peuvent ouvrir que des images au format JPEG alors que nous souhaitons pouvoir accéder à des données du type .PNG ou encore .TIFF. Il a donc fallu utiliser la fonction d’une autre bibliothèque (Pillow = « PIL »), qui peut ouvrir plus d’une trentaine de type d’images différentes. Puis nous avons converti cette image dans un format que peuvent comprendre les fonctions de Scikit.
Autre exemple, la fonction remove_small_object qui permet de retirer de notre résultat les composantes faisant moins d’une certaine surface (en pixel) ne fonctionne qu’avec des données de type booléen.
Nous obtenons à la fin de notre traitement un tableau dont les cases (→ pixels si transformé en im age) sont à 1 (ou 255) lorsque ce sont des pierres et 0 sinon.
Le résultat final du programme de segmentation automatique est un raster (image binaire).
Description vectorielle
Par la fonctionnalité d’Arcgis, nous convertissons l’image raster en un fichier vectoriel ne comprenant que les contours des pierres et briques. L’étape suivante consiste à modifier le fichier vectoriel pour qu’il devienne l’équivalent d’une « vérité terrain » (c’est-à-dire corriger les contours que l’utilisateur considère faux). S’offrent alors à nous plusieurs choix : nous utilisons soit Arcgis, soit Inkscape soit nous produisons notre outil par nos propres moyens en Python. Nous avons écarté la dernière solution pour cause de temps, produire un tel outil aurait été chronophage alors qu’il existe déjà des programmes le permettant : autant se concentrer sur des points plus importants. Le CAPRA utilisant déjà le pack Arcgis pour dessiner ses vérités terrains à la main, on opta pour cette solution.
Transformation raster ↔ vecteur
Le logiciel ArcMap bénéficie de ce qu’on appelle des « ArcToolBox » (ou Boîte à outils). Ces dernières représentent la majorité des fonctions de traitement présentes dans le logiciel. Entre autres, dans la catégorie « Outils de conversion », deux sous-parties nous intéressent particulièrement : « A partir d’un raster » et « vers raster ». On y trouve respectivement, l’outil « raster vers polygones » permettant de convertir un fichier raster en un fichier vectoriel puis l’outil « polygone vers raster » permettant de faire l’opération inverse.
Lorsque l’on clique sur « OK », le résultat est alors produit, enregistré et affiché dans ArcMap.
Quant au second outil, il permet beaucoup plus d’options. Comme précédemment, nous entrons en premier le fichier vecteur puis nous choisissons le champ de données (le plus souvent utilisez ici le champ Gridcode). Mais cette fois-ci, le choix du champ est très important. Lors du dessin du raster, ce sont les valeurs du champ sélectionné qui vont être attribuées à chacun des pixels. Pour terminer, nous devons fixer 3 paramètres. Le premier est la méthode d’attribution des valeurs à chaque pixel. Dans le cas ou nous n’aurions pas coché la simplification des polygones lors de la création du fichier vectoriel, cette option est facultative. Sinon, voici la différence explicite entre les 3 choix possibles:
« CELL_CENTER : Le polygone qui se superpose au centre de la cellule détermine l’attribut à affecter à la cellule.
MAXIMUM_AREA : L’entité unique qui présente la plus grande surface à l’intérieur de la cellule détermine l’attribut à affecter à la cellule.
MAXIMUM_COMBINED_AREA : Si la cellule contient plusieurs entités de même valeur, les surfaces de ces entités sont combinées. L’entité combinée à la plus grande surface contenue dans la cellule détermine la valeur à attribuer à la cellule. » (ESRI, 2013)
Le second paramètre est le champ de priorité : dans le cas où deux entités se superposent, il détermine celle qui aura la préséance.
Le dernier paramètre est la taille des cellules, il suffit d’indiquer la taille de nos pixels souhaitée en mètre.
Ces outils permettent de passer rapidement d’un vecteur à un raster et vice versa mais ne provoquent-ils pas une diminution de la précision générale du fichier ?
Pour vérifier cela, nous avons effectué l’expérience suivante : à partir d’un raster produit par notre programme Python (figure 42), nous avons converti celui-ci en un fichier vectoriel par le premier outil puis nous avons converti ce dernier résultat en raster par le second outil (figure 43). Pour conclure, nous avons comparé le raster final à celui de départ. Notez que la case « simplifier les polygones » n’a pas été utilisée.
Classification des pierres en 7 catégories
Avec l’aide du CAPRA, nous avons pu établir une liste de 7 catégories de pierre. Ces 7 catégories représentent la majorité des pierres que peut rencontrer l’association du CAPRA lors de l’étude des maçonneries locales.
Présentation des catégories de pierre et extraction de leurs caractéristiques
L’homme, dans son processus de reconnaissance des pierres, fait l’analogie entre certains aspects de la pierre considérée et des caractéristiques des catégories de pierre. Procéder ainsi lui permet de savoir à quelle catégorie la pierre correspond.
Dans notre classification automatique des pierres, nous avons cherché à simuler ce que l’œil de l’homme pouvait interpréter. Ce dernier, en voyant une pierre, observe la pierre sur différents points : sa forme, son aspect ou encore sa couleur. Nous avons donc souhaité étud ier les pierres sur ces différents points et en avons tiré, pour terminer, des critères spécifiques à chacune des catégories de pierre. ArcMap offre un outil permettant facilement de produire des statistiques sur la forme des pierres (aire, périmètre, valeurs de la meilleure ellipse englobante…). Pour cela, il nécessite de connaître la taille des pixels afin de procéder aux calculs. Mais si nous souhaitons des résultats corrects, il nous faut connaître la taille de pixel de nos échantillons, ce qui n’est pas le cas !
Pour commencer, nous avons, grâce au CAPRA, obtenu des imagettes représentatives de chaque catégorie (figure 4). Nous avons commencé par étudier les canaux R , G, B des pierres puis nous avons continué sur les canaux H, S, V. Pour chaque canal, nous avons étudié le comportement des valeurs minimales, maxim ales, de la moyenne des valeurs des pixels dans chaque pierre, ainsi que des écarts-types. Rappelons que les canaux R, G, B et H, S, V sont directement liés. Cependant, les canaux H, S, V peuvent faire apparaître certains aspects des pierres que ne pourraient pas révéler les canaux R, G, B et vice versa.
Nous pouvons trouver en annexe n°3 à n°16 les tableaux résultants de ce travail. Les tableaux sont indexés dans l’ordre alphabétique des pierres, et pour chacune d’elle, on trouve les mesures prises concernant les 6 canaux cités précédemment.
Critères d’appartenance à une catégorie et règles de classification
Pour établir les critères de chaque catégorie de pierre, nous avons observé (sur les échantillons) l’étendue générale des valeurs des paramètres concernés. Prenons l’exemple du canal rouge de la brique (annexe n°3, canal rouge). On observe que les valeurs moyennes sont étalées entre 98 et 133. Ces extrêmes forment la plage du critère « Rouge » de la catégorie « Brique ».
Conclusions
L’objectif de ce travail de fin d’étude était d’établir un outil permettant la détection automatique des contours de pierres d’un mur puis la classification automatique de ces pierres. Cet outil devait aussi permettre à l’utilisateur de retoucher les résultats produits puisque le traitement informatique ne pouvait être parfait. Cet out il, au final, devait permettre aux utilisateurs (archéologues) de gagner du temps puisqu’à ce jour, ils produisent ces résultats en les traitant entièrement manuellement sous informatique.
Premièrement, nous avons développé un outil dans le langage de programmation Python qui permet de détecter les contours des pierres. Nous avons implémenté comme méthode de segmentation le region based segmentation (~Watershed), un algorithme de traitement d’image sélectionné dans une des bibliothèques à notre disposition (libre d’accès). Ce dernier, après avoir acquis en entrée le fichier raster (image de la façade), génère un fichier raster de sortie dont les pixels sont caractérisés comme étant dans des pierres ou le contraire. Cet outil bénéficie, de plus, d’une interface graphique pour que l’utilisateur puisse dialoguer avec lui en toute simplicité.
Nous avons souhaité que l’utilisateur puisse retoucher ce résultat automatique. Nous avons donc pour cela utilisé le logiciel Arcgis et ses outils déjà configurés pour modifier des entités vectorielles. De plus, ce dernier offrait la possibilité de convertir des fichiers r aster en vecteur.
Pour terminer, nous avons traité la classification des pierres dans notre projet. Il a été établi avec l’aide du CAPRA que ces derniers distinguaient 7 principales catégories de pierre dans leurs travaux locaux. Nous avons donc pu établir quelques caractéristiques propres à chacune d’elle pour en déduire des paramètres et des critères d’appartenance. Au final, nous obtenions une classification supervisée de chaque pierre via des règles d’appartenance.
Du point de vue du traitement de l’image, le sujet principal n’était pas de rechercher une solution optimale (algorithme(s) dédiés à la segmentation de pierres). Nous avons préférer étudier l’ensemble du projet, tout en n’approfondissant pas certain point tel la segmentation des pierres. Il reste donc de nombreuses recherches à produire de ce côté ci. Par exemple, notre algorithme sélectionné ne permet pas de détecter à la fois les pierres claires et les pierres foncées d’une image.
Une solution à ce problème serait de mettre en place un système de quadrillage de l’image. Au début nous sélectionnons 3 fenêtres (l’une avec une pierre claire, l’une avec une pierre foncée et la troisième avec du fond comme seulement des joints), chacune de ces fenêtres dispose donc de son propre histogramme. Puis, dans chaque découpe rectangulaire de l’image faite par le quadrillage, nous regardons l’histogramme de la fenêtre et le comparons à nos 3 histogrammes définis précédemment.
Ainsi, nous pouvons appliquer à chaque fenêtre un traitement différent, si c’est une pierre claire, foncée… etc. Pour terminer, il ne reste qu’à rassembler les segmentations produites sur chaque fenêtre.
Autre aspect de la segmentation, cette dernière demande à l’utilisateur de fixer des paramètres. Si nous approfondissons les algorithmes, il y aura certainement d’autres paramètres à fixer. Il serait donc bon d’établir un outil qui génère automatiquement ces paramètres en vue d’obtenir un traitement optimum.
Au niveau de la structure même de notre outil, elle reste, malgré le travail effectué, relativement sommaire. L’écriture, à l’aide de la bibliothèque Tkinter , n’est pas poussée. Elle n’offre pas suffisamment de solutions pour le confort de l’utilisateur. Une meilleure gestion des boîtes de dialogue, comme nous l’avons vu, est envisagée (ex : regroupement des choix de paramètres en une seule fenêtre). De plus, des fonctionnalités comme un zoom, une preview du résultat… pourraient être ajoutées au programme. Cependant, la bibliothèque Tkinter ne suffirait peut être pas pour gérer les évènements générés par ces fonctionnalités. Concernant la dernière partie du projet, la classification supervisée est fonctionnelle. Nous obtenons un résultat néanmoins insatisfaisant: environ 4 pierres sur 5 sont mal classées (suivant la classification). Cela est certainement dû au fait que cette classification se repose sur des critères radiométriques fortement liés à la lumière ambiante. Il se propose alors à nous 3 solutions.
La première, nous ajoutons d’autres critères pour caractériser nos classes (comme des paramètres de forme).
La seconde serait d’analyser l’influence des échantillons utilisés dans la création des paramètres de classe pour en établir de meilleurs. La prise de photographie par HDR serait une bonne solution pour éliminer l’effet de la lumière ambiante.
La troisième solution serait que, par une interface graphique, l’utilisateur puisse choisir une pierre de chaque catégorie présente sur son image. L’outil génèrerait ensuite automatiquement les caractéristiques de chaque classe en prenant comme échantillons de départ les pierres sélectionnées par l’utilisateur. De manière générale, nous pouvons améliorer les règles de décisions d’appartenance à chaque catégorie puisqu’elle se résume à une addition et une soustraction actuellement. Nous avons fait le choix de programmer l’interface graphique de l’outil de segmentation en Python et d’utiliser celle du logiciel ArcMap pour les outils de classification. Malheureusement nous avons étudié et découvert la possibilité d’user de l’interface d’ArcMap pour nos outils en fin de projet.
Nous n’avons pas eu le temps d’explorer cette nouvelle solution pour l’outil dans sa globalité. Il faudrait étudier la possibilité d’associer notre outil de segmentation à ArcMap (comme pour les outils de classification) : l’utilisation de la bibliothèque Tkinter ne serait alors plus nécessaire.
Ce projet présente deux points qui se confrontent : le premier oblige l’utilisateur à trouver et régler de nombreux paramètres pour pallier à la grande diversité de murs à traiter, tandis que le deuxième prône la simplicité d’utilisation pour l’utilisateur qui est un archéologue et non pas un féru de traitement d’image.
Pour conclure, il faut retenir la chose suivante : les aspects segmentation et classification de ce projet reste fortement à développer puisque nous n’avons pas eu le temps de les approfondir. Néanmoins, il existe de nombreuses solutions possibles .
|
Table des matières
1. Introduction
2. Présentation du contexte
3. Segmentation
3.1. Orfeo ToolBox/Monteverdi
3.1.1. Présentation de l’OTB
3.1.2. Segmentation Mean-Shift
3.1.3. Segmentation Connected Components
3.1.4. Segmentation Watershed
3.1.5. Segmentation Morphological profiles based
3.2. Python : Scikit-Image
3.2.1. Présentation de Scikit-Image
3.2.2. Segmentation Edge Based
3.2.3. Segmentation Region Based (~Watershed)
3.2.4. Segmentation Random Walker
3.2.5 Segmentation Felzenszwalb
3.3. Expérimentations
3.3.1 Prétraitement
3.3.2. Protocole d’expérimentation
3.3.3. OTB
3.3.4. Scikit
3.3.5. Post-traitement
3.3.6. Etude de l’Algorithme retenu
4. Développement d’une interface graphique
4.1. Interface graphique
4.2. Implémentation du traitement d’image
5. Description vectorielle
5.1. Transformation raster ↔ vecteur
5.2. Modification du vectoriel
6. Classification des pierres en 7 catégories
6.1. Présentation des catégories de pierre et extraction de leurs caractéristiques
6.2. Critères d’appartenance à une catégorie et règles de classification
6.3. Implémentation des critères dans Arcgis à travers la classification automatique
6.4. Résultats
7. Conclusions
Table des figures
Table des annexes
Télécharger le rapport complet
