Outils d’édition de vérité terrain

Présentation générale

Une autre question soulevée au cours de mes travaux de thèse était de savoir comment évaluer efficacement un algorithme de détection, et notamment celui des panneaux de limitation de vitesse mis en place dans les travaux présentés dans ce mémoire. Il est certes possible d’appliquer l’algorithme développé sur une longue séquence (scénario) de test et de relever manuellement les résultats (i.e. le nombre de bonnes et de non détections) mais cela s’avère très fastidieux et peu précis. En effet, au cours du travail de recherche et de développement d’une méthode de détection (ou autre), les algorithmes mis en place évoluent forcément soit par le changement des jeux de paramètres utilisés afin d’affiner au mieux les résultats, soit tout simplement parce que de nouvelles méthodes sont implémentées. Idéalement, après chaque tentative d’amélioration d’un processus, il faudrait évaluer l’apport des changements afin d’être sûr que ces derniers améliorent bien les résultats. Or il est clair que pour évaluer systématiquement son algorithme après chaque modification sur un scénario de test, même court d’une dizaine de minutes, il est nécessaire d’automatiser ces tests. Il existe de nombreux logiciels d’annotation vidéo disponibles. Le plus connu et le plus utilisé d’entre eux est sans doute le logiciel Viper – Video Performance Evaluation Resource (Doermann, et al., 2000). Mais on peut aussi citer les logiciels Anvil – Video Annotation Research Tool (Kipp, 2001), ODViS – Open Development Environment for Evaluation of Video Surveillance Systems (Jaynes, et al., 2002),… Une liste non exhaustive mais assez complète peut être trouvée dans (Travis Rose, 2007). Dans ces travaux, (Travis Rose, 2007) relève de nombreux points sur l’impossibilité d’utiliser un outil existant pour l’annotation de ces séquences de travail, dont entre autres : – Les outils existants ne fournissent pas toutes les fonctionnalités voulues. – Il n’y a pas de support pour des formats vidéos non standards. – Ils ne supportent pas l’annotation de vidéo de plus de 10 min. – Ils ne supportent pas l’annotation de vidéo issues de plusieurs caméras – Ils ne supportent pas des synchronisations précises entre de multiples vidéos Bien que certains de ces points soient discutables, il est aisé de relever un certains nombre de ces points dans le cas des séquences rtMaps : le support des vidéos rtMaps ne sera jamais pris en compte par les autres logiciels d’annotation vidéo, ils ne supportent pas les synchronisations précises entre de multiples sources, et aussi, ils ne fourniront pas l’ensemble des fonctionnalités voulues. De ce constat est né SamGT (GT étant l’acronyme de Ground Truth) : un logiciel capable de lire et d’annoter des séquences rtMaps afin de réaliser des fichiers dits de vérité terrain (ground truth en Outils développés Alexandre Bargeton – Centre de Robotique – Mines ParisTech – 2009 167 anglais, fichiers contenant la position des objets à détecter pour chacune des images d’une vidéo), couplés à un package rtMaps (un ensemble de modules) pouvant comparer automatiquement les résultats d’un algorithme par rapport au fichier de vérité terrain préalablement édité par un opérateur humain. Tout l’intérêt et l’originalité résident dans l’utilisation du package rtMaps, qui, comme son nom l’indique, fonctionne nativement sous notre plateforme de prototypage, l’algorithme mis en place n’aura donc pas besoin d’être adapté (i.e. aucun besoin de traduire les résultats dans un format donné) afin de pouvoir être évalué avec SamGT.

L’édition de fichier de vérité terrain

L’éditeur La conception de l’éditeur de fichier de vérité terrain du logiciel SamGT est, à l’instar de la conception d’un algorithme sous rtMaps, réalisé de façon modulaire. Ainsi comme le résume la Figure 174, cet éditeur est conçu de façon à n’être en fait qu’un « moteur » récupérant les images frame par frame dans un flux vidéo et appliquant une série de plugins (i.e. d’algorithmes) sur une image (qui sera donc modifiée) avant de l’afficher. Figure 174 – Schéma de fonctionnement modulaire de l’éditeur SamGT Les différents types de flux vidéo reconnus par l’éditeur (qui est, pour rappel, un logiciel indépendant de la plateforme rtMaps) sont bien entendu ceux supportés nativement par rtMaps (des formats vidéo propriétaires gérant la datation de chaque image à la microseconde) tel que les formats RAW et JSEQ, mais aussi ceux pouvant être habituellement utilisés sur ordinateur tel que le format AVI et les images vidéo provenant d’une Webcam. Chaque image extraite, ainsi que les interactions utilisateur (clic sur l’image, déplacement de la souris, texte saisi au clavier,…) sont ensuite envoyées au travers de tous les plugins activés (i.e. choisis et paramétrés par l’utilisateur). Il est de ce fait possible de développer des plugins complexes pour l’éditeur de SamGT, tel qu’un éditeur de vérité terrain, un plugin de traitement d’image ou d’extraction de sous-image,… Séquence rtMaps AVI Webcam Vidéo Plugin SamGT Editeur Vérité Terrain Traitement d’image Extraction d’image héritage dialogue Outils développés Alexandre Bargeton – Centre de Robotique – Mines ParisTech – 2009 168 Tous ces modules sont bien sûr normalisés et héritent tous d’un même module parent (concept de l’héritage en programmation), permettant de bien définir les fonctionnalités que doit implémenter chaque composant et notamment des fonctionnalités d’intégration graphique dans l’éditeur, un plugin pouvant donc définir ensuite ses propres fenêtres et paramètres visuels. Il a ainsi été possible par exemple, d’encapsuler facilement les appels des méthodes des fonctions de reconnaissance de la bibliothèque OpenCV (Figure 175), de créer des plugins à affichage complexe, comme l’édition de diagramme de traitement d’image (Figure 176) manipulant ses propres plugins (Figure 177) ; et bien sûr, ce qui nous intéresse ici, la création de fichiers de vérité terrain (Figure 178). Définition d’un plugin de traitement d’image sous SamGT Figure 178 – Création d’une vérité terrain sous SamGT b) Le format de fichier Le format des fichiers de vérité terrain générés (d’extension « .gt ») a été défini afin de pouvoir être facilement lisible par un opérateur humain ou par une machine, et d’être évolutif (i.e. supporter l’ajout de nouveaux types ou sous-types d’objet détectables sans détériorer les anciens « formats »). Ainsi comme le montre l’Exemple 4, un fichier GT est un fichier texte dont chaque ligne correspond à un objet détectable dans une image. Par exemple, si 2 panneaux apparaissent sur une seule image, 2 lignes seront présentes dans le fichier, chacune d’elle correspondant à l’un des panneaux. Cet exemple montre aussi que les données sont formatées de façon très stricte dans le fichier, permettant une lecture logicielle aisée.