Plus proche voisin approché (ANN)

Pour déterminer le plus proche voisin de i parmi les points détectés dans J, il est nécessaire de calculer les distances de i à tous ces points, ce qui est la tâche la plus consommatrice en temps de calcul, proposant une complexité quadratique en O(m2_{), m étant le nombre moyen de points} d’intérêt détectés dans une image.

Néanmoins, si l’utilisateur est prêt à tolérer de légères erreurs dans la recherche (retournant un point qui n’est pas le plus proche voisin, mais qui n’en n’est pas éloigné de façon significative), il est possible de gran- dement accélérer ces calculs, en utilisant les ANN (Approximate Nearest Neighbors) [4], offrant une complexité réduite à O(m_×log(m)).

Ce gain est dû à l’utilisation que font les ANN de structures de clus- tering de type kd-trees ou box-decomposition trees, une décomposition de l’espace à d dimensions, dans laquelle les points sont classés afin de res- treindre l’espace de recherche. Pour un point d’interrogation i, le plus proche ou les k plus proches voisins peuvent alors être déterminés en un nombre bien plus restreint d’opérations. N’importe quelle métrique de Minkowski peut être spécifiée pour le calcul des distances entre points.

6.2.1.3 Filtrage

Le choix du plus proche voisin au sens euclidien n’est pas un critère suffisant pour obtenir de bons appariements. Cet unique critère amène à un nombre important d’appariements faux, en particulier sur des images représentant des motifs qui se répètent, les descripteurs se ressemblant alors fortement. De plus, la mise en correspondance induite n’est pas né- cessairement réciproque : si le point j ∈ J est le plus proches voisins de i_∈ I, il n’est généralement pas vrai que i est le plus proche voisin de j.

Pour palier à ces défauts, une ou plusieurs étapes de filtrage des ap- pariements sont nécessaires. On présente ici deux filtrages différents : un simple et efficace, puis un autre plus robuste mais plus lourd. Ces deux filtrages peuvent être utilisés conjointement.

Deux plus proches voisins Une première idée naïve serait de défaus-

ser les paires dont la distance est inférieure à un seuil donné. Cela est cependant peu efficace, étant donné que certains descripteurs sont plus discriminants que d’autres. Lowe [144] propose une façon plus efficace et peu contraignante, nécessitant tout de même de déterminer pour un point i_∈ I les deux plus proches voisins j et j0 _∈ J, j étant le plus proche, de comparer leurs distances à i, puis de supprimer les appariements pour

lesquels le rapport de ces deux distances _dd₍(_i,ji,j0)) est inférieur à un seuil

donné. Lorsqu’un point a deux voisins proches dans l’espace des descrip- teurs, mais potentiellement éloignée dans l’espace de l’image, il est pré- férable de lever l’ambigüité en supprimant l’appariement. Lowe propose d’utiliser la valeur 0.8 comme seuil. Ses expériences montrent qu’avec ce filtrage, 90% des mauvais appariements sont supprimés, alors que 5% des bons seulement le sont. Cette efficacité est due au fait que lorsqu’un point est mal apparié, il arrive fréquemment que la distance au second plus proche voisin soit très similaire à celle au plus proche voisin.

Ce filtrage peut être vu comme une estimation de la densité des mau- vais appariements dans cette partie de l’espace des descripteurs.

RANSAC L’algorithme itératif RANSAC [54], pour RANdom SAmple

Consensus, est une méthode d’estimation des paramètres d’un modèle à partir d’un jeu d’observations contenant des outliers, échantillons aber- rants, ainsi que des inliers, échantillons correctes. L’algorithme suppose qu’il existe une procédure de détermination des paramètres d’un modèle à partir d’un sous-ensemble, généralement très réduit, des échantillons. L’exemple canonique d’utilisation du RANSAC est la régression linéaire, l’approche d’un jeu d’échantillons par une droite.

Itérativement, l’algorithme sélectionne au hasard un sous-ensemble d’échantillons, considérés comme des hypothétiques inliers, détermine les paramètres d’un modèle, puis teste tous les autres échantillons avec ces paramètres : si un point correspond bien au modèle, il est lui aussi consi- déré comme un possible inlier. Si un pourcentage suffisant des échan- tillons est labellisé comme hypothétiques inliers, le modèle est considéré comme raisonnablement bon. Il est alors ré-estimé à partir de tous les in- liers potentiels, et l’erreur globale des inliers relativement au modèle est évaluée. Toutes ces étapes sont répétées un nombre fini de fois, chaque itération produisant un modèle soit rejeté (trop peu d’inliers), soit retenu, avec une erreur d’approximation. Au final, le modèle proposant la plus petite erreur est retenu.

Dans notre cas, on cherche à estimer la matrice fondamentale caracté- risant la relation existante entre les points correspondants dans une paire d’images. Il existe des méthodes exactes de calcul d’une telle matrice fon- damental à partir de 7 paires de points [259], les sous-ensembles utili- sés à chaque itération du RANSAC sont donc de taille 7. Les apparie- ments considérés comme des outliers pour le modèle estimé sont rejetés, ce qui permet de supprimer jusqu’à 95% des mauvais appariements, tout en conservant la quasi-totalité des bons.

6.2.2 Algorithme GPU d’appariement de deux images

Malgré l’emploi de techniques et outils réduisant la complexité al- gorithmique de l’appariement de deux images tels les ANN (voir sec- tion 6.2.1.2), la mise en correspondance de N images, de complexité al- gorithmique O(N2), représente une charge de calculs encore trop lourde pour pouvoir être utilisé de façon interactive dans des applications de reconstruction 3D (ou du type de celle présentée dans la section 6.3).

Dans cette section, nous présentons une méthode implémenté sur GPU permettant d’accélérer, par rapport à une version CPU optimisée,

Résolution image HD (1920×1080) 960×540

CPU 3 12.3

GPU 8.5 30.2

GPU4_×4 15.0 60.1

Gain GPU/CPU 2.8 2.5

Gain GPU4×4/CPU 5 5

Table 6.1 – Vitesse de calcul (en Hz) et gain pour notre implémentation GPU des SURF, pour différentes méthodes et différentes tailles d’images. Seul le temps de détection des points d’intérêt et de leur échelle est pris en compte. La version CPU a été réimplémentée par nos soins ; la version GPU calcule le Hessien sur GPU en traitant les images les unes après les autres ; la version GPU4×4 fait de même en prenant les images 4 par 4.

les temps de calcul pour la mise en correspondance de N images (N pou- vant aller jusqu’à plusieurs centaines), chacune pouvant contenir plus de 1000 points d’intérêt.

6.2.2.1 Implémentation

Nous avons repris l’algorithme SURF de Bay et al. [10], en implémen- tant le calcul des descripteurs et la détermination des appariements sur GPU.

Détection et description Bien que ce ne soit pas notre contribution prin-

cipale, nous avons développé une version des SURF mixte CPU/GPU (les travaux de Terriberry et al. [228] n’étaient alors pas encore disponibles). Comme dans [215], les dérivées des images (les Hessiens) sont calculées sur GPU, alors que les descripteurs sont évalués sur CPU, à l’aide de la librairie originale [10]. Il est à noter que nous ne considérons pas le temps de calcul des descripteurs comme un bottleneck, étant donné que ces calculs ne sont fait qu’une fois par image, et que le problème auquel nous nous sommes attachés est d’accélérer l’appariement d’un ensemble d’images.

La table 6.1 présente quelques temps classiques pour l’extraction de points d’intérêt et le calcul de l’échelle par SURF, pour deux tailles d’images et pour différentes méthodes. Le temps de calcul du descripteur n’est pas pris en compte. CPU correspond à une version intégralement CPU des SURF, réimplémentée par nos soins. La version GPU est notre première version sur GPU dans laquelle les images sont traitées une par une ; ses temps prennent en compte le transfert de chaque image du CPU vers le GPU, le calcul du Hessien sur GPU, le transfert retour et la fin des calculs (sauf calcul du descripteur). La version GPU4×4 est la même que la précédente à la différence près que les images sont traitées quatre par quatre, y compris pour les transferts. On observe un gain de 2.5 en faveur de notre implémentation GPU par rapport à une implémentation CPU. Ce gain peut monter jusqu’à 5 en traitant les images quatre par quatre : Cg est en effet adapté à de tels calculs grâce à ses variables de type float4, vecteurs à 4 dimensions sur lesquelles une même opération peut être ap- pliquée parallèlement. De plus, en traitant les images quatre par quatre, on réduit le nombre de transferts (sans diminuer la quantité de données à transférer).

Appariement La méthode utilisée, de type brute force, est décrite avec la figure 6.9. mI m J u 4v m

T

T

T

Shader 1: Calcul des