Optimisation d'algorithmes de traitement d'images sur une architecture utilisant le GPGPU Rapport de stage ST40 - P2013

Transcription

1 Optimisation d'algorithmes de traitement d'images sur une architecture utilisant le GPGPU Rapport de stage ST40 - P2013 AUBREE Loïs Département Informatique Filière Imagerie, Interaction et Réalité Virtuelle Centre de Robotique et Vision industrielles - CRVI 205,rte Mrg-Bourget G6V 6Z9 - Lévis (Québec) Tuteur en entreprise M. Moulay Akhloufi Suiveur UTBM M. Stéphane Galland

2 Mots clefs Algorithmique - Optimisation - GPU - GPGPU - CUDA - OPENCL traitement d'images Québec Aubrée Loïs Rapport de stage ST40 - P2013 Résumé Ce rapport de stage est destiné à présenter les travaux effectués lors de mon stage ST40 de l'université de Belfort-Montbéliard. Le sujet de mon stage a été l'optimisation d'algorithme de traitement d'images sur une architecture utilisant le GPGPU. Deux sujets de recherche particulier m'ont été proposés. L'un concernant la comparaison d'algorithmes de détection de points caractéristiques invariants dans une image sur GPU et le second sujet portait sur la comparaison d'algorithmes de labellisation de régions connexes. Je commence dans ce rapport par présenter l'entreprise et le contexte dans lequel s'est inscrit mon stage. Ensuite je présente les technologies utilisées pour la réalisation du stage. Ensuite je présente les deux sujets sur lesquels mon stage s'est porté pour finir sur une partie d'analyse et une conclusion. Le deuxième sujet ayant abouti à l'écriture d'un article, j'ai fait le choix de l'inclure en annexe de ce rapport. Centre de Robotique et de Vision Industrielles - CRVI 205,rte Mrg-Bourget G6V 6Z9 - Lévis (Québec)

3 Sommaire Remerciements:... 2 Introduction :... 3 Présentation de l entreprise :... 4 Organigramme de l'entreprise:... 5 Bibliothèque IVL:... 5 Présentation du stage:... 6 Formation sur les bibliothèques de GPGPU (CUDA/OPENCL)... 6 L'architecture CUDA:... 7 OPENCL: Le GPGPU pour le traitement d'image: Travail réalisé: Sujet 1: Comparaison d'algorithmes de points caractéristiques invariants Travail effectué: Difficultés rencontrées: Sujet 2: Comparaison d'algorithmes de labellisation de régions connectées sur images binaires utilisant le GPGPU Principe de fonctionnement de labellisation: Principe de fonctionnement de Rosenfled/PLatz: Travail effectué: Tests: Analyses : Estimation du gain apporté à l'entreprise : Conclusion : Références : Annexes :... 34

4 Remerciements: Je souhaite tout d abord remercier Moulay Akhloufi, Directeur Recherche et Développement mais aussi tuteur de mon stage, pour m avoir permis de travailler au sein du CRVI (Centre de Robotique et de Vision Industrielle) pendant ces 6 mois. Ensuite, je tiens à remercier le Directeur de l'entreprise, Alain Bordeleau, ainsi que tous les membres du personnel pour leur accueil chaleureux et leur bonne humeur même durant la rugueuse période de froid. Pour finir je remercie Lucie Boutou, une autre étudiante de l UTBM pour m avoir supporté et avec qui j ai pu découvrir le Québec.

5 Introduction : Ce stage de 6 mois au Centre de Robotique et de Vision Industrielle de Lévis (Québec) a été réalisé dans le cadre l unité de valeur ST40 «stage professionnel» de l Université de Technologie de Belfort-Montbéliard. Ce rapport est destiné à présenter le travail qui m a été demandé de réaliser. Mon stage s est déroulé comme un travail de recherche où deux sujets (études) précis m ont été accordés. Je commencerais par présenter l entreprise et le contexte dans lequel s est inscrit mon stage et, ensuite, j expliquerais le travail réalisé en deux grandes parties. Je conclurais ce rapport sur une analyse du travail effectué ainsi que des observations. Dans les annexes de ce rapport se trouve l'article que j'ai produit sur le deuxième sujet. Celui-ci étant en anglais, j'ai choisi de le traduire en partie pour apporter une explication des recherches, en français, dans la partie travail effectué du deuxième sujet de stage.

6 Présentation de l entreprise : Le CRVI (Centre de Robotique et de Visions Industrielles) est une entreprise fondée en Elle a pour but d'aider les PME manufacturières québécoises par la recherche, le développement technologique et le transfert de connaissances dans les domaines, de la robotique, de la vision des commandes et des procédés industriels. Le CRVI est donc une entreprise offrant des expertises et des services en robotique (simulation de systèmes robotisés, conception et développement de cellules robotisées,...) et des services en vision industrielle comme le développement et l'implantation de systèmes d'inspection et de mesures en temps réel ou guidage optique de robot. L'effectif de l'entreprise est d'une vingtaine de personne en incluant les nombreux stagiaires que l'entreprise accueil. Les locaux du CRVI sont positionnés dans le bâtiment du Cegep de Lévis-Lauzon. Lévis est une ville située sur la rive sud du saint Laurent juste en face de la capitale nationale du Québec, Québec City. Le CRVI est en partenariat étroit avec le cégep puisqu'il accueille des élèves du cégep pour effectuer des stages ou des projets ainsi que des professeurs du cégep pour leur fournir un espace de travail. M.Akhloufi, lui même, est enseignant au sein du cégep Lévis- Lauzon.

7 Organigramme de l'entreprise: Mon statut de stagiaire en laboratoire de recherche me positionnait en marge de cet organigramme au même niveau que l'équipe de programmation. Toutefois, les chargés de projets, programmeurs et M. Akhloufi ont été disponibles pour apporter une aide sur mes sujets. Pour ce qui est des conditions de travail, Lucie et moi étions dans un bureau à part et nous avions pour chacun un bureau et un ordinateur attribué. Les ordinateurs étaient à la propriété du CRVI et nous pouvions apporter notre propre ordinateur portable pour travailler. Bibliothèque IVL: La bibliothèque IVL est un bibliothèque favorisant le développement de produit de vision industrielles et de robotiques. Cette bibliothèque est développée et maintenue entièrement par le CRVI. L'équipe de programmation du CRVI est chargée de développer des nouveaux modules dans la bibliothèque afin de l'adapter aux solutions techniques que le centre propose à ces clients.

8 Présentation du stage: Le sujet de stage qui m'a été proposé concerne l'optimisation d'algorithmes de traitement d'images en utilisant les architectures GPGPU (general-purpose processing on graphics processing units). C'est à dire optimiser les algorithmes de traitement d'images en bénéficiant de la capacité massivement parallèle des processeurs graphiques. Les algorithmes de traitement d'images étant relativement nombreux, le choix du domaine sur lequel je devais me pencher a été fait sur place aux besoins de l'entreprise. Mon travail s'est inscrit dans un programme de recherche en amont d'une implémentation des algorithmes dans la bibliothèque IVL et en amont du développement d'une solution technique chez un particulier. L'objet de mon travail a été de comparer des algorithmes existants en traitement d'images en trouvant et implémentant des solutions sur GPGPU. Le travail de recherche s'est divisé en 3 parties. Tout d'abord avec la formation sur les bibliothèques permettant la programmation sur GPGPU. Ensuite deux parties de recherches ont été menées pour une comparaison d'algorithmes spécifiques. La première ayant été abrogée, les comparaisons n'ont pas été mené jusqu'à la présentation de résultats. Je présenterais toutefois dans ce rapport le sujet de ma première étude. Ensuite la seconde recherche a permis l'implémentation et la comparaison avec succès d'algorithmes de traitement d'images jusqu'à la présentation des résultats et l'écriture d'un article. Formation sur les bibliothèques de GPGPU (CUDA/OPENCL) Les activités récentes des principaux constructeurs de circuits électroniques comme NVIDIA montrent que les futurs systèmes informatiques seront "hybrides" par nature. C'est à dire que ces systèmes reposeront sur l'intégration de deux composants principaux. Les CPU (central process unit) multi-cœurs continueront à intégrer de plus en plus de cœurs en évitant les obstacles d'alimentation, de parallélismes et de mémoires. Et l'usage des GPU(graphics processing units) pour des calculs spécialisés ou massivement parallélisables sera de plus en plus banalisé. En effet depuis quelques années les performances en calcul virgule flottante des GPU dépassent largement celles des CPU classiques et la programmation d'algorithmes parallèles sur GPU est devenue autant, voir plus, accessible que sur CPU multi-cœur. Tout indique que l'avenir des ordinateurs, du portable au supercalculateur reposera sur un une architecture hybride, combinant ces deux composants. Le domaine du traitement d'images et de la vision n'est aussi pas épargné par l'avancée des systèmes hybrides. En effet un bon nombre d'algorithmes de traitements d'images repose sur

9 une architecture ou peuvent être traduit en une structure parallèle fournissant un gain considérable pour certains algorithmes. Le CRVI propose des systèmes de vision pour la mesure et l'inspection, et ces systèmes sont destiné au temps réel. C'est pourquoi l'avancée de l'usage de systèmes hybrides pour le traitement d'images oblige le CRVI à instaurer des algorithmes GPU dans la bibliothèque IVL et à proposer des solutions techniques utilisant ces systèmes pour garantir leur concurrence sur le marché de la vision. Depuis 2006, des sociétés comme NVIDIA, AMD et Khronos Group propose des solutions pour rendre la programmation GPGPU accessibles au plus grand nombre tout en favorisant l'intégration et la compatibilité des nouveaux processeurs graphiques aux bibliothèques permettant de programmer ces systèmes hybrides. A ce jour, sur le marché des GPGPU, deux solutions sont concurrentielles, CUDA qui est une solution dont NVIDIA est propriétaire et OpenCL qui est une solution libre visant à favoriser la programmation sur systèmes hybrides multiplateformes. L'architecture CUDA: CUDA désigne plus particulièrement un tout. Il s'agit autant de la technologie matérielle que la bibliothèque permettant de programmer sur le matériel compatible. En 2006, cinq ans après la sortie des carte GeForce 3, NVIDIA sorti la première carte graphique utilisant l'architecture CUDA, la Geforce 8800GTX. Cette nouvelle architecture à pour effet de surpassé les restrictions imposées par les GPU précédents en introduisant de nouveaux composants circuit. De là, le groupe NVIDIA démarra le développement de la bibliothèque pour programmer sur cette nouvelle architecture et rendre la programmation sur GPU accessible à tous. A la différence des architectures précédentes qui utilisaient les ressources de traitement en vertex et en pixel shaders, l'architecture CUDA unifie ces deux traitements et permet surtout d'assigner à chaque unité arithmétiques et logique (ALU) un programme pour réaliser des traitements généraux. La grande innovation apporté par NVIDIA sont des ALU utilisant des jeux d'instructions pour réaliser des traitements généraux (norme IEEE sur les ALU) plutôt que simplement des traitements graphiques. De plus les unités d'exécutions peuvent lire et écrire n'importe où en mémoire et également accéder à un cache de mémoire partagée. Toutes ces fonctionnalités permettent au GPU CUDA d'exceller dans les traitements généraux.

10 L'image ci-dessus montre le déroulement d'un appel à un noyaux d'exécution sur CUDA. Ce scénario est identique pour OpenCL que je décrirais ultérieurement dans ce rapport. Ce processus mets bien en lumière l'hétérogénéité du système et le fonctionnement des instructions sur architectures hybrides. Le CPU reste maitre de l'application c'est à dire qu'il ordonne les instructions et le GPU est assigné à des tâches très particulières (les noyaux). En CUDA, les noyaux sont écrits dans un langage similaire au C et le code des noyaux d'exécution destiné au GPU doit être compilé par un compilateur propre à CUDA, le compilateur NVIDIA CUDA Compiler Driver NVCC. Structurellement CUDA utilise pour communiquer les noyaux à la carte graphique un système de blocs d'exécution comportant eux mêmes des threads (unités d'exécution). Un thread est un appel au noyau. Il a autant d'appel d'exécutions de noyaux qu'il y a de threads. Les threads sont donc répartis dans des blocs destinés à être exécuté en parallèle sur un processeur graphique. Il ne peut y avoir plus de blocs et le nombre de thread par bloc est également limité. À l'heure actuelle les cartes graphiques ayant un score supérieur à 2.0 ne peuvent exécuter plus de 1024 threads par bloc. Les blocs sont aussi regroupés en grille et une grille ne peut pas contenir plus de blocs.

11 Exemple de programme CUDA: code noyau: global void add( int *a, int *b, int *c, int N){ int tid = blockidx.x; // traite l'élément à cet indice if (tid < N) c[tid] = a[tid] + b[tid]; } code CPU: int main(void){ int a[n],b[n],c[n]; // N entier int *dev_a,*dev_b,*dev_c; HANDLE_ERROR(cudaMalloc((void**)&dev_a, N * sizeof(int))); HANDLE_ERROR(cudaMalloc((void**)&dev_b, N * sizeof(int))); HANDLE_ERROR(cudaMalloc((void**)&dev_c, N * sizeof(int))); /** On remplit les tableaux a et b ***/ HANDLE_ERROR(cudaMemcpy(dev_a,a, N * sizeof(int),cudamemcpyhosttodevice)); HANDLE_ERROR(cudaMemcpy(dev_b,b, N * sizeof(int),cudamemcpyhosttodevice)); add<<<n,1>>>(dev_a,dev_b,dev_c,n); HANDLE_ERROR(cudaMemcpy(c,dev_c,N * sizeof(int),cudamemcpydevicetohost)); /** on affiche c **/ } cudafree(dev_a); cudafree(dev_b); cudafree(dev_c); Le code donné en exemple est un code permettant l'appel à un noyaux procédant à l'ajout de deux vecteurs a et b, les résultats de cette addition de vecteur sont stockés dans un troisième vecteur c. On voit bien ici la facilité de mise en place des fonctions CUDA. Bien qu'il s'agisse d'un exemple simple plusieurs éléments ne sont pas communs. Tout d'abord, les fonctions cudamalloc et cudamemcpy sont présentes pour effectuer l'allocation et la copie des vecteurs dans la mémoire de la carte graphique. La carte graphique ne possédant pas la main sur la mémoire principale. Il s'agit ici de la seule façon de faire transiter des données entre les deux mémoires et de fournir les données à la carte graphique. Ensuite l'appel au noyaux add s'effectue avec un appel comportant des triples chevrons. Ceci indique à la carte graphique la façon dont le programme veut lancer les threads. Le premier paramètre des chevrons indique le nombre de blocs de thread que l'on veut lancer pour le

12 programme et le second paramètre indique simplement le nombre de threads que doit comporté un bloc. Dans notre cas on souhaite donc lancer un bloc de un thread pour chaque addition d'éléments à traiter. On aurait aussi très bien pu lancer 1 bloc de N threads pour effectuer le calcul. Dans ce cas, le seul inconvénient est que les vecteurs ne doivent pas avoir plus de 1024 éléments. Le traitement sur un nombre de données dépassant les limites imposées par le matériel oblige à réaliser un combinaison de blocs et de threads pour effectuer la tâche. Enfin pour connaitre la place des éléments des vecteurs traités CUDA mais à disposition des numéros d'index. threadidx détermine à quel place se trouve le thread dans le bloc en traitement et blockidx détermine la place du bloc dans la grille. Grâce à cela et en connaissant les dimensions des blocs et de la grille (blockdim, griddim), il est possible de déterminer quel élément est actuellement en traitement. Formation: Ne connaissant pas l'architecture CUDA et la programmation GPGPU en général avant ce stage, je me suis donc accordé, avant tout lancement sur le premier sujet, deux semaines de formation sur cette architecture. Le site internet de NVIDIA est très bien documenté et propose un grand nombre de tutoriaux possibles. J'ai aussi suivi le livre "CUDA par l'exemple" de Jason Sanders et Edward Kandrot qui propose une très belle introduction au fonctionnement de l'architecture CUDA et à l'élaboration de premiers programmes l'utilisant en CUDA C. J'ai notamment codé certains programmes de traitement d'images simples comme l'inversion de couleur ou le passage de filtre gaussien pour me familiariser avec la 2D en CUDA, l'utilisation de la mémoire globale, partagée et de texture. OPENCL: OpenCL est une API (Application Programming Interface) développée par le Khronos Group. Elle permet la programmation de systèmes hétérogènes combinant processeur multi-cœur et GPU. Les avantages qu'opencl permet d'obtenir face à CUDA sont un format libre et ouvert, le multiplateformes, une concentration de GPU supportés plus importante puisque OpenCL n'est pas propriétaire et que Khronos Group collabore avec tous les constructeurs de GPU pour affiner cette API.

13 Techniquement, OpenCL est une combinaison entre API et un langage dérivé du C. Elle permet tout comme CUDA d'exécuter des noyaux d'instructions sur le GPU et de récupérer les résultats dans le code destiné au CPU. Toutefois, OpenCL agit différemment de CUDA puisqu'elle n'utilise pas de compilateur propre. En effet, l'ensemble des noyaux d'exécution sont stockés dans un fichier.cl et celui-ci n'est pas compilé mais interprété à l'exécution par l'api OpenCL. Les noyaux sont écrits dans le langage dérivé du C que l'api sait interpréter. L'API quand à elle est maintenue dans plusieurs langages (C,Python,Java...) favorisant encore une fois le caractère multiplateforme de l'interface. Formation d'un programme OpenCL: La création d'un programme OpenCL nécessite plusieurs étapes. Tout d'abord, OpenCL demande la création d'un contexte d'exécution pour récupérer des données sur l'architecture dans laquelle il évolue. Ensuite il est possible de créer une queue d'instructions. Celle ci permet placer les appels aux noyaux dans la boucle d'exécution. Afin de récupérer les noyaux d'un programme OpenCL dans le fichier.cl, il est nécessaire de créer un objet cl_program qui lit et stocke l'ensemble du fichier.cl dans une chaine de caractères. L'étape de construction du programme est la plus importante car c'est à ici que le programme est interprété et que les informations des noyaux sont stockés dans le programme. Il est alors aisé de créer un objet noyaux cl_kernel en cherchant dans le cl_program le noyaux par son nom. Cet objet noyaux est ensuite destiné à être placé dans la queue d'instructions pour être exécuter. Tout objet présent dans la mémoire CPU et nécessaire pour le noyaux doit être copié dans la mémoire tampon de la carte graphique. À l'aide de la fonction clcreatebuffer, il est possible d'allouer de l'espace pour ces objets. Il en est de même pour stocker les résultats du noyaux. Ceux ci peuvent être récupérer ensuite par le programme CPU et sont extrait vers la mémoire principale.

14 Figure 1 - chaine de création d'un programme OpenCL Exemple d'un noyaux OpenCL: kernel void add( global int * a, global int *b, global int* c, const unsigned n) { int id= get_global_id(0); if (id<n) c[id]= a[id] + b[id]; } Ce noyaux permet d'additionner les vecteurs a et b et de stocker les résultats dans un autre vecteur c. Tout comme pour CUDA, les threads sont réunis en grilles et il est possible de récupérer la position de ce thread dans le noyaux à l'aide des fonctions get_global_id et get_local_id. Ici il est aussi passé en paramètre la taille des vecteurs pour s'assurer de ne pas dépasser en mémoire. le kernel signifie à OpenCL que la fonction est une fonction noyaux et global indique les paramètres sont des objets de la mémoire globale sur le GPU. Lors de l'allocation des mémoires tampons les vecteurs a et b auront la permission en lecture seulement et le vecteur c en lecture/écriture.

15 Formation: Je me suis aussi familiariser avec OpenCL tout au long du stage en regardant des exemples et des tutoriaux proposer sur différents sites internet. Il est difficile d'évaluer mon temps de formation à cette API puisqu'elle s'est déroulé en continue sur le stage. Toutefois je peux dire qu'une première semaine de formation a été nécessaire pour découvrir le fonctionnement et réaliser des tests. Le GPGPU pour le traitement d'image: L'ensemble des algorithmes étudiés ici sont des algorithmes destinés à des applications 2D. Concrètement lors des parcours sur images, l'idée du traitement de pixels à pixels est prohibée. Sur GPU, le traitement des pixels d'une image ne se fait pas les uns à la suite des autres mais en parallèle. Dans le cas basique, on définie alors un thread par pixel. C'est à dire que pour un thread créé, un pixel est traité. La position du thread dans les blocs et sur la grille de traitement est alors étroitement liée avec celle sur l'image. Une des optimisations importante est que l'on peut aussi découper l'image en plusieurs blocs afin de traiter celle-ci plus rapidement en utilisant tous les processeurs graphiques. Le GPU reste toutefois non utile pour les algorithmes nécessitant un parcours obligatoire pixel par pixel.

16 Travail réalisé: Sujet 1: Comparaison d'algorithmes de points caractéristiques invariants Le premier travail qui m'a été confié, était de comparer les algorithmes de détection de points d'intérêts invariants dans une image. Les points caractéristiques invariants sont des objets permettant de caractériser une image en essayant de détecter et d'identifier certaines parties ou points clés dans l'image. On peut ainsi utiliser ses points d'intérêts comme descripteurs locaux de l'image. Les descripteurs locaux ont pour but de décrire le contenu visuel local de l'image. Ensemble ces descripteurs fournissent une grande information sur le contenu visuel global. Une image ainsi décrite pourra par la suite être comparée à d'autres images. Connaissant le contenu visuel de ses images, on peut alors déterminer des similitudes entre celles ci. Des exemples d'application des points caractéristiques sont le pattern matching (reconnaissance d'un motif dans une images), reconstruction panoramique, reconnaissance d'objets ou de formes (par exemple, un visage), etc.. Figure 2- Application de pattern matching utilisant le descripteur SURF Les descripteurs d'images sont très utilisés dans le domaine du traitement d'images et constituent la plupart des avancées techniques dans le domaine de la reconnaissance. Ce sont des algorithmes puissants permettant une multitudes d'applications. Toutefois des recherches sont encore très activement menée car les outils de détection de points d'intérêts et de reconnaissances ne sont pas encore optimaux.

17 Les points d'intérêts dit invariants représentent les points d'intérêts les plus robuste face aux variations possible. En admettant que l'on est deux images de la même scène (représentant les mêmes objets ou même personnes) mais prises à deux points de vue différents ou a des moments différents dans la journée. Les objets dans les images seront les mêmes mais il subiront indéniablement des variations sur l'image. Les trois grandes variations que l'on peut obtenir sur une image sont l'échelle, la rotation, la luminosité. L'échelle représentent un effet de "zoom" dans l'image, les objets sont les mêmes mais la taille change d'une image à l'autre. La rotation est liée au phénomène de changement de prise de vue. La luminosité correspond aux variations des sources lumineuses éclairant la scène. Les points caractéristiques invariant propose une certaine stabilité dans la détection et une description plus robuste du contenu visuel de l'image. Le premier algorithme introduisant des points d'intérêts invariants pour la description d'image fut développé par David G. Lowe en 1999 à l'université de la Colombie-Britanique, avec le célèbre algorithme SIFT (Scale-invariant feature transform). L'idée d'utiliser des points d'intérêt locaux remonte aux travaux de Hans Moravec en 1981 sur la recherche de correspondance entre deux images stéréoscopiques. Depuis de nombreux travaux et améliorations du détecteur de Moravec se sont ajoutés notamment avec les travaux de Harris et Stephen mettant au point le non moins célèbre détecteur de Harris. Mais ce n'est qu'en 1999 que l'on peut parler de détecteur de point d'intérêt invariants avec les travaux de Lowe présentés en conférence ICCV (International Conference on Computer Vision). Lowe publiera aussi des améliorations en 2004 dans la revue International Journal of Computer. De part l'avancé des systèmes hétérogènes et les nouveaux travaux déployés sur les points d'intérêts invariants, M.Akhloufi m'a proposé de mener une recherche pour ainsi comparer les différentes implémentations GPGPU des algorithmes de détection. En me basant sur une recherche bibliographique, je devais alors sélectionner les algorithmes paraissant les plus performants. Pour chaque solution des articles ont été publiés, ils présentent pour la plupart des tests de performances ainsi qu'une comparaison à d'autres algorithmes déjà existants. Plusieurs de ces algorithmes ont déjà eu une implémentation sur GPU existante.

18 Travail effectué: Les algorithmes sur lesquelles je me suis concentré sont les suivants: SIFT[1] : il reste un très bon algorithme pour certain type d'applications (reconstruction d'images panoramique, par exemple). Il s'avère être un des algorithmes les plus stables face aux variations d'échelles et de rotations mais il est très couteux en temps d'exécution. Ceci le rend impossible à utiliser pour des applications en temps réel. Il existe aussi de nombreuses variantes améliorant sensiblement les performances de l'algorithme notamment le PCA-SIFT qui procède à une analyse en composante principale sur les descripteurs. Pour ma part je me suis intéresser à l'implémentation de SIFT présente dans la bibliothèque de traitement d'images OpenCV pour la partie CPU et je me suis procuré les sources du projet SiftGPU[8]. Un autre inconvénient de SIFT est que l'algorithme développé par David G. Lowe est protégé par un brevet détenu par l'université de Colombie-Britanique. Le code source de l'implémentation de SIFT n'est donc pas disponible dans OpenCV et les implémentations libres de cet algorithme ne sont pas l'algorithme original mais des algorithmes se basant sur les explications fournies par l'article de Lowe. SURF[4](Speeded Up Robust Features) : Développé par Herbert Bay en 2006, SURF est devenu l'algorithme le plus utilisé pour les applications de mise en correspondance de point d'intérêts. Il est fortement inspiré des descripteurs SIFT et il est célèbre pour sa robustesse accrue et surtout pour une accélération importante face à SIFT. SURF rend possible des applications en temps réel. Une implémentation de SURF est présente dans OpenCV à la fois pour le GPU et le CPU. ORB[5](Oriented FAST and Rotated BRIEF) est un descripteur binaire développé par le Willow Garage. Une implémentation CPU et GPU sont déjà présent dans OpenCV. FREAK[6](Fast Retina Keypoint): c'est un descripteur simulant la réponse sensorielle de l'oeil humain. Il est présenté comme un descripteur plus robuste et plus performant que SURF. Il est le plus récent des descripteurs de la liste. Un implémentation de FREAK est présente dans OpenCV pour le CPU. Tous les algorithmes de mise en correspondance de points d'intérêts se divise en deux étapes, la détection (création des descripteurs) et le matching ( la mise en correspondance). L'étape que l'on cherche à évaluer dans ce sujet est la détection mais celle-ci ne peut s'évaluer qu'après avoir mis en correspondance points entre deux images. Pour effectuer les tests des différents algorithmes, j'ai réalisé une application en C/C++ permettant de charger une image et d'effectuer une batterie de test sur celle-ci. L'interface de la l'application est développée à l'aide de Qt et l'application avait pour but de combiner les différentes implémentations trouvées des algorithmes de points d'intérêts pour ainsi faciliter les tests et les rendre plus accessibles.

19 Le second sujet m'a été donné au cours de la réalisation de cette interface. Cette interface de test permet alors, à l'état de d'avancée actuel, d'effectuer un test sur GPU et CPU pour les algorithmes SURF et ORB. FREAK et SIFT ne fonctionnent que pour le CPU. Les tests sont réalisables pour les trois variations dites précédemment dans ce rapport, l'échelle, la rotation et la luminosité. L'utilisateur a besoin de charger une image et de créer des transformations qui s'appliquent sur l'image chargée de l'interface. L'interface génère donc des images au fur et à mesure pour ensuite les mettre en correspondance avec l'image d'origine. Pour la mise en correspondance des deux images, originale et de test, une détection des points intérêts est effectué sur les deux images ensuite une opération de matching est réalisable. La mise en correspondance des descripteur des deux images est possible. En réalité, un descripteur est un vecteur sur lequel des opérations de distance sont réalisables. L'opération de matching dite brute de force est simplement une comparaison de distance entre chaque vecteur (descripteur) et sont couplés les points étant les plus proches. Cette approche est certainement pas la plus appropriée puisque qu'elle ne prend pas en compte les transformations effectuer sur l'image de test. L'utilisation du brute de force pour des images de rotations, par exemple, va conduire à un couplage de points d'intérêts pour le moins aléatoires sans respecter la transformation. Il est donc important d'utiliser une autre forme de matching. La mise en correspondance assisté d'une découverte de la transformation affine qui a pu être réalisée sur l'image test est beaucoup plus convaincante et permet d'éviter beaucoup d'erreur de couplage de points. Grâce aux descripteurs des deux images, il est possibles d'obtenir la matrice fondamentale. L'idée de l'utilisation de cette matrice découle du fait qu'entre deux images à mettre en correspondance, il existe une transformation affine dont la matrice peut être extraite. A l'aide de tous les échantillons (points d'intérêts), on peut déterminer la matrice fondamentale de cette transformation en utilisant l'algorithme de RANSAC. La méthode cv::findfundementalmat de la bibliothèque de traitement d'images OpenCV permet de déterminer la matrice fondamentale et ainsi obtenir une mise en correspondance plus précise des points d'intérêts. Les performances d'un algorithmes de détection de points d'intérêts invariant sont testés sous plusieurs façons. Tout d'abord, la stabilité permet de définir si un algorithme reste stable selon les transformations appliquées à l'image. Le nombre de points couplés entre les deux images doit rester au mieux identique entre deux tests de transformations. L'algorithme doit aussi être robuste sur les points d'intérêts trouvés. Un algorithme est bon s'il détecte des points d'intérêts représentant le même contenu visuel dans les images d'une même scène. Enfin l'algorithme doit être le plus rapide possible pour effectuer la détection et la mise en correspondance.

20 Difficultés rencontrées: Certaines difficultés n'ont pas pu me permettre de mener à terme ce sujet. La mauvaise compréhension des concepts mathématiques mis en jeu dans ces algorithmes est en grande partie la cause des difficultés rencontrées. L'apprentissage des concepts mathématiques m'a fait perdre beaucoup de temps et souvent bloqué avant de me lancer sur la phase de recherche d'implémentations existantes. De plus l'interface pour favoriser la comparaison des algorithmes n'était effectivement pas nécessaire pour mener à bien les tests et n'a fait rendre la tâche plus difficile. Pour effectuer l'implémentation des solutions ne relevant pas d'opencv. Il a été très difficile pour moi d'extraire les algorithmes des autres projets, n'étant déjà pas à l'aise avec le fonctionnement interne de ces algorithmes. De plus ayant pour but d'unifier ces projets dans une seule interface, j'ai eu en effet une perte de temps à traduire les projets récupérés pour leur permettre de fonctionner sur l'interface. Ces erreurs m'ont permis d'aborder le deuxième sujet avec une autre vision du travail demandé.

21 Sujet 2: Comparaison d'algorithmes de labellisation de régions connectées sur images binaires utilisant le GPGPU. Ce deuxième sujet m'a été attribué sur la seconde partie du stage au milieu du troisième mois. Il s'avérai plus adapté au niveau de mes compétences en traitement d'images et mathématiques. Ce sujet était aussi plus encré dans l'activité de l'entreprise puisque cet étude s'inscrit préalablement à un implémentation de solution technique chez un client direct du CRVI. Les compétences acquises par la formation et par l'étude du premier sujet m'ont aidée aussi à avancer plus rapidement dans mes recherches. Ceci m'a permis de proposer sur ce sujet des solutions valides et j'ai pu présenter des résultats. Principe de fonctionnement de labellisation: Sur une image binaire, on peut considérer deux choses: le fond de l'image, en noir et les objets ou régions en blanc sur l'image. L'étiquetage (ou labellisation) de l'image repose sur cette considération. Le principe est de détecter les régions blanches de l'image en leur attribuant à chacune un label(numéro d'identification) différent. Pour une image binaire, on produit une image dite de labels qui comportera, pour chaque pixel de l'image binaire, le label qu'il lui est associé.

22 La figure ci-dessus montre une image binaire, fond blanc et objets noirs. L'image de label produite après le passage d'un algorithme de labellisation devrait être sous la forme de l'image de droite. Tous les pixels possèdent un label et les pixels connectés à la même régions ont la même valeur de label. Les pixels sont connectés de deux manières en 4 ou 8 connexité. La connexité 4 signifie que les pixels voisins Nord, Ouest, Sud et Est sont de même nature que le pixel courant. La connexité 8 s'applique aux 8 voisins du pixels courant. Les pixels sont connectés s'ils valident la propriété de connectivité. Dans le cas d'une image binaire la propriété est valide si deux pixels voisins appartiennent tous les deux au fond ou tous les deux aux objets. Le premier algorithme de labellisation fut développé en 1966 par Rosenfeld et Platz. Cet algorithme est enseigné en traitement d'image car il est intuitif et permet de comprendre le concept de parcours d'images. La solution de Rosenfeld et Platz permet de labelliser l'image en deux parcours d'image ou deux passes.

23 Principe de fonctionnement de Rosenfled/PLatz: L'algorithme de Rosenfeld/Platz parcours l'image de droite à gauche et de haut en bas en balayant un à un les pixels de l'image binaire. A la première passe, l'algorithme effectue un balayage de l'image. Selon le degré de connexité (4 ou 8), le test de connectivité se fait sur 2 ou 4 voisins, les voisins Nord et Est pour une connexité 4 et les voisins Nord-est, Nord, Nord-ouest et Est pour une connexité 8. A chaque pixel l'algorithme agit ainsi : Si le pixel parcouru appartient au fond de l'image, alors il reçoit le label 0 dans l'image de labels. Si le pixel est un pixel objet et qu'un voisin valide la propriété de connectivité alors le pixel courant reçoit le même label que ce voisin dans l'image de labels. Si le pixel est un pixel objet et que plusieurs voisins valident la propriété de connectivité alors le pixel courant reçoit le plus petit des labels des voisins connectés et l'on stocke dans une table d'équivalence tous les labels des autres voisins connectés. Si le pixel est un pixel objet et qu'aucun des voisins ne valide la propriété de connectivité alors un nouveaux label unique est attribué au pixel courant dans l'image de labels. La seconde passe est une passe dite de résolution de labels. En effet après la première passe tous les labels des régions connectées ne sont pas encore attribués définitivement. Certains pixels connectés n'ont pas le même label. Toutefois grâce à la première passe une table d'équivalence a été construite. Cette table permet de stocker tous les labels validant la propriété de connectivité. La deuxième passe a pour but de balayer l'image de label pour attribuer à chaque pixel le plus petit des labels équivalents.

24 Figure 3- Labellisation d'une image en 4-connexité L'algorithme Rosenfeld/Platz n'est pourtant pas optimal et même très couteux en temps d'exécution. En effet pour de grandes images par exemple, la table d'équivalence devient rapidement très difficile à résoudre et fait chuter les performances de l'algorithme. C'est pourquoi il ne fait pas parti des algorithmes étudiés dans cette recherche. Les algorithmes présentés par la suite sont déjà plus performant que celui-ci sur une implémentation CPU. Les algorithmes de labellisation sont utilisés dans beaucoup d'applications de traitement d'images et vision industrielles, les applications que peut permettre ce type d'algorithme sont le comptage de régions dans une scène, vérifier de la connectivité de deux régions, faire des calculs d'aires que prend les régions dans l'image, etc. Les algorithmes de labellisation peuvent donner des informations utiles pour des classifieurs menant à la reconnaissance de formes par exemple. Dans la vision industrielle, cela peut être utile dans les opérations de contrôle sur les lignes de production (exemple : contrôle de qualité).

25 Travail effectué: Dans un premier temps, j'ai procédé à une recherche bibliographique sur les avancées algorithmes dans ce domaine. Ensuite en me basant sur les articles déjà établis, j'ai procédé à une sélection d'algorithmes offrant de bonnes performances sur CPU pour ensuite les traduire sur GPU. La difficulté résidait dans la parallélisassions des algorithmes qui de base ne le sont pas. Je me suis particulièrement intéressé à quatre types d'algorithmes. L'algorithme de propagation de voisins (Neighbor Propagation) : Cet algorithme réalise la labellisation de l'image en plusieurs passes jusqu'à convergence. Le point d'arrêt de la labellisation s'effectue lorsque plus aucun label n'est modifié durant une passe. A l'initialisation l'image de label se voit attribuer un label unique par pixel selon les valeurs matricielles. Figure 4 - Valeurs matricielles pour une image 5 par 5 Ensuite l'algorithme effectue un balayage de l'image pixel par pixel. Pour chaque pixel, le voisinage en 4 ou 8 connexité est extrait. Si des pixels de ce voisinage valident la propriété de connectivité alors le pixel courant se voit attribuer le plus petit des labels des voisins valides. Si le label du pixel courant est déjà plus petit que les labels des voisins valides alors aucun changement de label n'est opéré. L'image ci-dessous montre une résolution par l'algorithme de propagation de voisins. Figure 5- L'algorithme de Propagation de voisinage non parallèle

26 Implémentation sur GPU: Une version parallèle de cet algorithme est réalisable. Chaque pixel est traité par un thread et pour chaque thread, on charge le pixel courant et son voisinage dans les deux images, binaire et de labels. Le critère d'attribution du label est équivalent à la version non parallèle de l'algorithme. L'image de label évolue à chaque itération jusqu'aux même critère de convergence. L'image ci-dessous montre la labellisation de la même image. Celle-ci se réalise en 6 itérations sur l'image. Le gain de performances est déjà intuitif puisqu'aucune tâche de balayage d'image n'est effectuée. On appel simplement N fois un noyau exécuté en parallèle. Figure 6 - Exécution du l'algorithme de propagation de voisins sur GPU en 6 itérations L'algorithme de propagation de voisins directionnel (Directional Neighbor Propagation): L'algorithme de la propagation de voisins directionnel découle de la propagation de voisin. L'idée n'est pas ici de traiter les pixels uns à uns mais d'effectuer la labellisation selon les lignes et les colonnes. Cet algorithme effectue aussi la labellisation en plusieurs itérations jusqu'à ce qu'aucun des labels ne soit modifié durant une passe. L'algorithme propage donc les labels dans les 4 directions, de haut en bas, de bas en haut, de gauche à droite et droite à gauche. Les labels propagés sont les plus petits labels. Un label est propagé sur la ligne ou la colonne si le label suivant est plus grand et que le pixel suivant vérifie la propriété de connectivité avec le pixel courant. Implémentation sur GPU: Ici un thread n'est pas attribué pour un pixel mais pour le traitement d'une ligne complète. Une itération pixel à pixel est pratiquée le long de cette ligne pour propager les plus petits labels. Le gain de performance est donné par la parallélisassions des traitements en lignes et en colonnes. Pour la version GPU de l'algorithme toutes les lignes et colonnes sont traitées en même temps. L'image ci-dessous montre une itération de l'algorithme dans les 4 directions de l'images.

27 Figure 7 - Une itération de l'algorithme de propagation de voisin directionnel L'algorithme d'équivalence de labels (Label equivalence): L'algorithme d'équivalence de labels est une méthode de labellisation en passes multiples. Cet algorithme utilise deux images de labels pour mener à bien cette tâche. La deuxième image de labels introduite ici va permettre de stocké effectivement des équivalences de labels. Toutefois il ne s'agit pas là d'une table d'équivalence comprenant toutes les équivalences d'un label. En effet pour de grandes images, une table d'équivalence peut atteindre une taille considérable. Les recherches ont montré que l'utilisation d'une table d'équivalence comme dans l'algorithme de Rosenfeld/Platz n'est pas une solution acceptable. Ce rejet de la table d'équivalence et d'autant plus fort par l'utilisation des GPU. Les GPU possèdent assez peu de mémoire et les accès répétés en mémoire sont la cause de pertes de performances considérables. Les temps d'accès en mémoire sur GPU sont souvent bien supérieurs aux temps de calcul fournis par les ALU. C'est pourquoi cet algorithme propose une solution autre. L'idée de cet algorithme est de sauvegarder, dans une seconde image de labels, la plus petites valeur de label des voisins vérifiant la propriété de connectivité. Pour effectuer la labellisation les deux images de labels L1 et L2 sont initialement créées avec les valeurs matricielles et l'algorithme effectue trois étapes distinctes. Étape de balayage (Scanning) : Cette première étape effectue un balayage de l'image. Pour chaque pixel si des pixels voisins vérifient la propriété de connectivité alors le label du plus petit de ces voisins est stocké dans la l'image de label L2 pour le pixel courant. Si aucun label voisin validant la propriété n'est plus petit que le label du pixel courant alors le label courant est gardé.

28 Étape d'analyse(analysis): L'étape d'analyse est l'étape la plus importante car elle va résoudre les équivalences. Celle-ci effectue une recherche de chaine de labels pour déterminer le label réel à attribuer à chaque pixel. Après l'étape de balayage, l'algorithme se trouve en possession des deux images L1 et L2. L1 n'a pas été modifiées et garde les anciennes valeurs de labels alors que L2 a subit le balayage. Admettons un pixel p ayant pour label 5 dans L1 et le label 2 dans L2. C'est à dire que ce pixel p possède un voisin q ayant, lui même, le label 2 dans L1. En admettant que ce même voisin q possède le label 1 dans L2 alors cela veut dire qu'il est aussi voisin d'un autre pixel ayant le label 1 dans L1. Le label que doit obtenir le pixel p n'est donc pas celui de du pixel q mais bien de ce dernier pixel car il s'agit d'un pixel connecté à la même région et que son label est plus petit que le label du pixel q. L'Étape d'analyse va alors effectuer une compression de chemin pour obtenir le plus petit label de la région connectée. Le critère d'arrêt de cette compression de chaine s'effectue lorsque le chemin arrive à un label dit "racine". C'est à dire un label possédant le même label à la fois dans L1 et dans L2. Une fois ce chemin parcouru les labels de L2 sont remplacés par les labels racines. Il est important de remarquer que l'opération de compression de chemin peut s'avérer très couteuse. Étape de labellisation(labelling): Cette étape assigne les labels de L2 à ceux de L1. L'algorithme peut alors réitérer ces trois étapes jusqu'à ce qu'aucun label de L1 ne soit modifié lors de l'étape de labellisation. Implémentation sur GPU: Un thread est assigné au traitement d'un pixel. Ce thread charge le pixel et son voisinage ainsi que les deux images de labels. Le traitement est ainsi effectuer en parallèle pour offrir de grande performance de labellisation.

29 Figure 8 - Une itération de l'algorithme d'équivalence de label - les labels racines sont en rouge L'algorithme d'o'connell(o'connell algorithm): L'algorithme de Sean O'Connell[2] est une approche différente de la labellisation. Il respect particulièrement la considération d'existence de fond et d'objets dans une image binaire. L'initialisation de l'algorithme est fait selon les valeurs matricielles en partant de l'index 1. Tout les pixels du fond se voient attribués le label 0. Ceci à pour conséquence de marquer réellement un écart entre le fond et les objets. Ensuite, l'algorithme se sépare en 4 grandes étapes, le balayage sur les colonnes, le traitement sur les colonnes, la mise à jour des racines et la mise à jour des enfants. Le balayage sur les colonnes: Cette première étape effectue une propagation colonne par colonne du plus haut label. Figure 9 - première étape de l'algorithme de O'Connell

30 Le traitement des colonnes: Cette étape peut être séparée en trois autres sous-étapes. Le rassemblement des voisins: Cette étape effectue un traitement colonne par colonne et pour chaque pixel de la colonne à droite de la colonne courante, on recherche un voisin de plus haut label. Si un pixel de plus haut degré est découvert alors le pixels racine attaché au pixel courant prend la valeur du pixel de haut label. Figure 10 - Application de l'étape de découverte de voisins La mise à jour des colonnes: Cette étape permet de refléter tout changement effectué sur les racines afin de mettre à jour les enfants. Figure 11 - Mise à jour des colonnes La rétrodiffusion: Tout la recherche de voisin la rétrodiffusion procède à une recherche des voisins dans le sens inverse. Lorsqu'un pixel voisin de plus haut degré est trouvé, on met à jour le label du pixel racine attaché au pixel courant.

31 Figure 12 - Étape de rétrodiffusion La mise à jours des racines: La mise à jour des racines et une étape permettant de résoudre les problèmes de chainage de racines. L'algorithme va parcourir l'image de label pour déterminer quelle est la racine réel de la régions connectée. Pour descendre dans la chaine, un test est réalisé sur chaque racine. Si le label de la racine ne correspond pas à la valeur matricielle initialement associé c'est qu'il existe un chemin menant à une racine réelle pour la région connecté. La mise à jour des enfants: Figure 13 - résolution d'une chaine de racine Une fois le problème de chainage résolu, on procède à la mise à jour des enfants colonne par colonne. Figure 14 - Mise à jour des enfants

32 Pour effectuer la comparaison des algorithmes, j'ai tout d'abord développé leur version CPU. Pour les versions GPU, deux implémentations de chaque algorithme ont été réalisée, une sur CUDA et l'autre en OPENCL. Au final une implémentation en CPU,CUDA et OpenCL a été réalisée pour les 3 premiers algorithmes. Par manque de temps, l'algorithme de Sean O'Connell n'a fonctionné que sous OpenCL. La traduction de cet algorithme en CUDA a débuté dans les derniers jours de mon stage. Je n'ai pas eu le temps de résoudre les bugs de compilation pour me permettre d'effectuer des tests. Tests: Les tests ont été fait sur une carte graphique NVIDIA Geforce 680 GTX, une carte graphique très récente. La première comparaison des algorithmes a été faite selon la taille d'une image que l'on grossit 30 fois pour obtenir autant d'échelles de la même images. Ce test à pour but d'évaluer les performances des algorithmes en fonction du nombre de pixels à traiter. Il est important de garder la même image pour le nombre de régions connectées ne diffère pas d'un test à l'autre. Un autre test a été effectué sur un set de 100 images binaires tirées de la base de donnée "The Berkeley Segmentation Dataset and Benchmark ". Afin de binariser les images, un seuillage a d'abord été fait sur chaque image à la volée. L'intérêt de cette expérimentation est de déterminer la stabilité des algorithmes par rapport au nombre de régions dans l'images et leur répartition aléatoire. Les résultats montrent que la bibliothèque CUDA permet de meilleur performances qu'opencl. Et surtout permet de conclure sur l'importance de l'utilisation des GPU par rapport aux CPU sur les algorithmes de labellisation, surtout pour les images de grandes tailles. Les résultats obtenus sont présents dans la catégorie "results" de l'article placé dans les annexes de ce rapport.

33 Analyses : J'ai pu apprendre à travers ce stage à mener une recherche en totale autonomie, ce qui je pense m'apporte une grande expérience dans le domaine de la recherche et une bonne capacité à effectuer du travail en solitaire. Pour ce qui est du travail réalisé, mon regret est de ne pas avoir adopté une bonne méthodologie de recherche sur le premier sujet qui m'a été proposé, ce qui m'a gêné en deux points. Premièrement par une période de blocage de mes recherches sur ce sujet et ensuite par une perte de temps pour l'étude du deuxième sujet. J'explique mon échec sur le premier sujet par une négligence bibliographique et surtout par une mauvaise compréhension des notions mathématiques utilisées dans les algorithmes de points caractéristiques invariants. Toutefois je pense que le changement de sujet m'a permis de me remettre en confiance et m'a permis de présenter un travail et des résultats, ce qui je pense n'aurai pu être possible pour un stage de 6 mois pour ma part sur le premier sujet. Estimation du gain apporté à l'entreprise : L'estimation du gain apporté à l'entreprise est pour moi difficile à réaliser puisque que je n'ai pas eu à apporter de réelle solution technique à un problème posé ou même de reprogrammer pour la bibliothèque IVL des fonctionnalités d'autres bibliothèques propriétaires. Les recherches bibliographiques, l'article produit et les résultats obtenus apportent un gain de temps notable à l'équipe de programmation. L'estimation du gain monétaire résulte dans la non perte d'argent pour le CRVI puisque le stage était non rémunéré et il est pour moi difficile de chiffrer en argent le travail réalisé. Mon travail étant de la recherche, je ne suis pas surpris de ne pas pouvoir faire l'estimation en argent puisque le laboratoire de recherche n'est pas directement relié aux bénéfices de l'entreprise.