utilisation des cartes graphiques pour la vision par ordinateur

Utilisation des cartes graphiques pour lavision par ordinateur

RAPPORT DE STAGE

2006-2007

Master 2 Recherche

Specialite Image, Information et Hypermedia

par

Emmanuel DELAPLACE

Directeur : M. Patrice Dalle Professeur d’universite UPS, Toulouse

Rapporteur : Mme Geraldine Morin Maıtre de conferences INP, Toulouse

Encadrants : M. Alain Crouzil Maıtre de conferences UPS, ToulouseM. Benoıt Bocquillon Doctorant UPS, Toulouse

Institut de Recherche en Informatique de Toulouse — UMR 5505

Resume

Ce rapport de stage vise a presenter l’utilisation des techniques GPGPU pour la vision par ordinateur.Nous presentons tout ce qui permet d’exploiter les ressources des cartes graphiques. Ensuite, nous donnonsun etat de l’art sur tous les outils mathematiques qui ont ete implementes sur GPU. Ces outils pouvant etreutile pour la vision par ordinateur. Puis, nous presentons un autre etat de l’art concernant l’utilisation desGPU pour la vision par ordinateur. Enfin, nous presentons une implementation sur GPU d’un algorithmemise en correspondance stereoscopique.

Mots-cles : vision par ordinateur, mise en correspondance, carte graphique, GPU, GPGPU, pro-grammation shader.

i

« La seul arme que je tolere, c’est le tire-bouchon »

Jean Carmet

iii

Remerciements

« Un seul mot, use,

mais qui brille comme

une vieille piece

de monnaie : merci ! »

Pablo Neruda

Je serai court mais sincere.Je tiens a remercier toute l’ equipe TCI a travers Monsieur Patrice Dalle et particulierement MonsieurAlain Crouzil, pour avoir ete mon encadrant, et Monsieur Benoıt Bocquillon pour avoir ete mon co-encadrant (et bien sur, merci pour le cafe).Merci a Monsieur Mathias Paulin de l’equipe VORTEX pour m’avoir permis d’utiliser les machines del’equipe.Merci les copains et aussi stagiaires : Guigui, Mathieu, Adrien, Julien, Virginie.Merci aux autres stagiaires, faiseurs de mots croises et aussi amis : Mika, Aurore, Francois, Sylvain.Merci a DoodooFred, frere de toujours.Merci aux copains qui ne sont pas stagiaires : Theo, Lili, Steph, Olivier, Mike.Merci la famille.Je remercie bien evidemment ceux qui doivent l’etre et que j’oublie.

Table des matieres

1 Introduction 1

1.1 Vision par ordinateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Carte graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Objectifs du stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Programmation du processeur graphique 5

2.1 Pipeline graphique DirectX 9 et OpenGL 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Pipeline graphique DirectX 10 et OpenGL 2.1 . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Elements programmables des cartes graphiques . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3.1 Carte graphique avec pipeline DirectX 9 et Opengl 2.0 . . . . . . . . . . . . . . . . 6

2.3.2 Carte graphique avec pipeline DirectX 10 et OpenGL 2.1 . . . . . . . . . . . . . . 7

2.4 Programmation shader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4.2 Shade trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4.3 RenderMan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4.4 The PixelFlow shading system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4.5 SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4.6 DirectX HLSL et GLSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4.7 Cg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4.8 RenderMonkey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4.9 Ashli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4.10 PyGPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4.11 Scout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4.12 CGiS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4.13 Bibliotheques : Accelerator, Glift, Brahma . . . . . . . . . . . . . . . . . . . . . . . 11

2.4.14 Bibliotheques pour la vision par ordinateur : OpenVIDIA, Flog, GPUCV . . . . . 11

2.4.15 CTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.16 CUDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.17 Resume des outils pour la programmation GPU . . . . . . . . . . . . . . . . . . . . 12

2.4.18 Exemple de programmation shader en GLSL . . . . . . . . . . . . . . . . . . . . . 13

2.5 Programmation GPGPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.5.1 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.5.2 Brook et Sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.5.3 Core Image et Quartz Composer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

vii

3 Utilisation de la carte graphique en vision par ordinateur 213.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2 Outils mathemathiques sur GPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.1 Operations sur les flottants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.2 Multiplication matricielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.3 Calcul matriciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.4 Resolution d’une equation ou d’un systeme d’equations . . . . . . . . . . . . . . . 233.2.5 LCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2.6 Resolution des equations d’Euler . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2.7 Diagramme de Voronoı . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2.8 Filtrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2.9 Ondelettes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.10 Tableau recapitulatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.3 Utilisation de la carte graphique en vision par ordinateur . . . . . . . . . . . . . . . . . . 263.3.1 Mise en correspondance et calcul de la carte de disparites . . . . . . . . . . . . . . 263.3.2 Reconstruction 3D a partir d’images . . . . . . . . . . . . . . . . . . . . . . . . . . 283.3.3 Mosaıque d’images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3.4 Transformation d’image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3.5 Segmentation d’image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3.6 Detection de contours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.3.7 Reconnaissance d’objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.3.8 Analyse du mouvement et suivi d’objet . . . . . . . . . . . . . . . . . . . . . . . . 323.3.9 Tableau recapitulatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4 Mise en correspondance sur GPU 374.1 Mise en correspondance par correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.1.2 Mesure de correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2 Mise en correspondance sur GPU en utilisant le langage GLSL . . . . . . . . . . . . . . . 404.2.1 Quelques indications sur le langage GLSL . . . . . . . . . . . . . . . . . . . . . . . 404.2.2 Algorithme de mise en correspondance avec GLSL . . . . . . . . . . . . . . . . . . 424.2.3 Comparaison CPU/GPU en termes de performance . . . . . . . . . . . . . . . . . 46

5 Conclusion 49

viii

Table des figures

1.1 Dispositif pour la vision par ordinateur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Une carte graphique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 Pipeline graphique DirectX 9 et OpenGl 2.0. . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Pipeline graphique DirectX 10 et OpenGL 2.1. . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Pipeline graphique programmable DirectX 9 et OpenGL 2.0. . . . . . . . . . . . . . . . . 62.4 Pipeline graphique programmable DirectX 10 et OpenGL 2.1. . . . . . . . . . . . . . . . . 72.5 Architecture PixelFlow (extrait de [Molnar 92]). . . . . . . . . . . . . . . . . . . . . . . . 82.6 Structure d’un programme GLSL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.7 Cg et les API graphique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.8 Read Back. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.9 Copy to Texture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.10 Render to Texture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.11 Copy to VBO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.12 Render to VBO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.13 G80 : render to Stream Buffer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.14 GPGPU : utilisation de plusieurs noyaux. . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1 Algorithme ORDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2 Plans glissants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.3 Reconstruction du relief avec un modele deformable. . . . . . . . . . . . . . . . . . . . . . 283.4 Algorithme 2+1 phase-shifting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.5 Algorithme VideoOrbits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.6 Correction d’une image. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.7 Segmentation d’image. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.8 SIFT sur GPU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.9 SIFT sur GPU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1 Mise en correspondance par correlation avec une zone de recherche. . . . . . . . . . . . . . 374.2 Texture en GLSL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.3 Comparatif des cartes graphiques presentent sur le marche. . . . . . . . . . . . . . . . . . 47

5.1 RapidMind. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

ix

Liste des tableaux

2.1 GPUCV. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Outils pour la programmation GPU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3 Bibliotheques utilisant le GPU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4 Methodes de programmation GPGPU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1 Outils mathematiques sur GPU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2 Utilisation de la carte graphique en vision par ordinateur. . . . . . . . . . . . . . . . . . . 34

4.1 Mesures de correlation croisee. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.2 Types vecteurs en GLSL et leurs accesseurs. . . . . . . . . . . . . . . . . . . . . . . . . . . 404.3 Fonctions GLSL predefinies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.4 Temps de calcul en secondes pour une mise en correspondance stereoscopique. . . . . . . . 46

xi

Liste des Algorithmes

1 Mise en correspondance par correlation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 Mise en correspondance avec GLSL : algorithme pour le fichier main.c. . . . . . . . . . . 423 Mise en correspondance avec GLSL : algorithme pour le fichier fragment.frag. . . . . . . 434 Mise en correspondance avec GLSL : algorithme pour la mesure NCC. . . . . . . . . . . . 435 Mise en correspondance avec GLSL : algorithme pour la mesure ZNCC. . . . . . . . . . . 456 Mise en correspondance stereoroscopique avec le CPU. . . . . . . . . . . . . . . . . . . . . 46

xiii

Chapitre 1

Introduction

L’utilisation de l’informatique dans le monde qui nous entoure est devenue banale. L’homme essaied’inculquer a des machines une vision humaine et meme une vision plus performante pour permettre aune machine de realiser ce que l’humain ne peut pas faire. Dans le monde de la robotique, de la medecine,de la domotique ou meme du ludique, la vision est un domaine de realisation important. Etant donneque notre vision se fait en « temps reel », c’est-a-dire de facon quasi-instantanee, il est alors necessaired’essayer d’obtenir un traitement des images le plus rapide possible. Les organes des machines qui nouspermettent de traiter ces images sont un ou plusieurs processeurs et une ou plusieurs cartes graphiques.Le sujet de ce rapport concilie donc la vision par ordinateur et l’utilisation des cartes graphiques et desprocesseurs pour obtenir une amelioration des temps de traitement des images.

1.1 Vision par ordinateur

L’objectif de la vision par ordinateur, appelee aussi vision artificielle, est de reproduire la vision humainea l’aide d’un ordinateur. Le dispositif general pour la vision par ordinateur peut etre illustre par la figure1.1.

Fig. 1.1 – Dispositif pour la vision par ordinateur.

Les elements importants sont donc :

– la scene : elle correspond a ce qui est vu ; c’est l’environnement qui est percu ;– le capteur : c’est le dispositif materiel qui permet d’obtenir les images. Par analogie, c’est ce qui

correspond a l’œil humain. Le capteur peut etre une ou plusieurs cameras, un ou plusieurs

1

2 Chapitre 1. Introduction

appareils photographiques, etc.– l’unite de traitement : c’est la ou est realise le traitement des donnees. C’est dans cette unite de

traitement que se trouve la carte graphique.

1.2 Carte graphique

Fig. 1.2 – Une carte graphique.

La carte graphique est un composant d’une unite de traitement qui permet de convertir des donneesnumeriques en donnees graphiques pouvant etre affichees sur un peripherique de sortie (ecran, retro-projecteur, etc.). La carte graphique possede les composants suivants :

– le processeur graphique : il est aussi appele GPU (Graphical Processing Unit), c’est le cœur dela carte graphique. C’est la ou sera realise tout le traitement d’une image. Il comporte le pipelinegraphique mais aussi des unites de calcul arithmetiques et logiques ;

– la memoire video (frame buffer) : c’est la memoire qui permet de stocker l’image avant qu’ellene soit affichee ;

– le RAMDAC : il correspond aux initiales de Random Access Memory Digital-Analog Converter.Ce composant permet de transformer les donnees numeriques d’une image, stockee dans lamemoire video, en signal analogique pour etre affiche ;

– le bios video : cette memoire contient des informations propres a la carte graphique ;– le bus : c’est le connecteur qui permet de relier la carte graphique a une carte mere. Le bus AGP

etait un bus cree a cet effet, mais il est aujourd’hui remplace par le bus PCI Express ;– les connectiques : elles permettent de relier la carte graphique a un ecran, a un televiseur, etc.

1.3 Objectifs du stage

On va donc s’interesser a l’utilisation des GPU dans le domaine de la vision par ordinateur. Lesprincipaux objectifs de ce travail de recherche sont donc les suivants :

– effectuer un etat de l’art sur la programmation des GPU ;– effectuer un etat de l’art sur les outils mathematiques qui ont ete implementes sur GPU et qui

peuvent servir a la vision par ordinateur ;– effectuer un etat de l’art sur l’utilisation des GPU pour la vision par ordinateur ;– proposer l’implementation d’un algorithme de vision par ordinateur permettant de tirer le meilleur

parti du parallelisme GPU/CPU.

1.3. Objectifs du stage 3

Le CPU (Central Processor Unit) est le processeur central d’un ordinateur. Il permet d’effectuerdivers traitements et de gerer les ressources d’un ordinateur.

Chapitre 2

Programmation du processeur graphique

2.1 Pipeline graphique DirectX 9 et OpenGL 2.0

DirectX et OpenGL sont des API graphiques. Une API (Application Programming Interface) definit lamaniere dont un programme peut communiquer avec d’autres programmes. OpenGL et DirectX offrentune specification qui permet l’affichage d’une scene 3D. Le pipeline graphique est la representation d’unesuite de plusieurs unites de traitement ayant pour but d’afficher une scene 3D a l’ecran (voir figure 2.1).Les constructeurs de cartes graphiques implementent physiquement le pipeline graphique.

Vertexprocessor

CullingClipping

AssemblageRasterization

Fragmentprocessor

TestsTraitements

Framebuffer

Textures

Fig. 2.1 – Pipeline graphique DirectX 9 et OpenGl 2.0.

Les elements qui constituent le pipeline sont :

– vertex processor : il recoit une serie de coordonnees qui correspond au sommets (vertices) d’unescene. Le vertex processor exerce une serie de transformations sur les coordonnees des sommets(changements de repere) et c’est dans cette unite que va etre calcule le niveau l’eclairage dechaque sommet (vertex ) ;

– culling : cette operation permet d’eliminer certains polygones d’une scene qui sont caches pard’autres polygones (back-face culling) et de supprimer des objets (ensemble de polygones)d’une scene qui sont caches par un autre objet (occlusion culling) ;

– clipping : cette operation permet d’eliminer les parties de la scene qui ne sont pas dans le cone devision ;

– assemblage : c’est l’assemblage des sommets pour former des primitives (segments, polygones,etc.) ;

– rasterization : cette operation construit une image 2D de la scene du point de vue de la camera.Les elements de la scene sont projetes sur l’image de la camera, puis discretises pour formerles fragments (futurs pixels). L’eclairage des sommets (projetes et discretises sur l’image) estextrapole aux autres fragments ;

5

6 Chapitre 2. Programmation du processeur graphique

– pixel processor ou fragment processor : le fragment processor a pour role d’appliquer les tex-tures sur chaque fragment de l’image. On associe une couleur a chaque fragment en prenant encompte l’eclairement calcule precedemment et la couleur du texel a appliquer ;

– tests et traitements : dans cette unite du pipeline, on realise divers tests comme le test alpha(transparence), le test de profondeur, le test du stencil, etc. ; on trouve aussi le traitement dubrouillard, l’alpha blending, etc. ;

– frame buffer : c’est la memoire video ;– texture : une texture est une image qui a vocation a etre « collee » sur un polygone.

2.2 Pipeline graphique DirectX 10 et OpenGL 2.1

Depuis novembre 2006, une nouvelle architecture logique (voir figure 2.2) est apparue [Blythe 06].Elle reprend l’architecture logique du pipeline graphique DirectX 9 et Opengl 2.0 avec l’ajout de l’unitegeometry processor. Cette unite permet l’ajout de sommet dans un maillage.

processorCullingClipping

Fragmentprocessor

TestsTraitements

Framebuffer

Textures

GeometryAssemblageVertexprocessor

Rasterization

Fig. 2.2 – Pipeline graphique DirectX 10 et OpenGL 2.1.

2.3 Elements programmables des cartes graphiques

2.3.1 Carte graphique avec pipeline DirectX 9 et Opengl 2.0

Aujourd’hui, il est possible de programmer les cartes graphiques. L’idee est d’injecter des programmesdans les differentes parties du pipeline graphique. On ecrit le code de ces programmes que l’on appellevertex shader et fragment shader. Ces programmes, sont executes respectivement par le vertex processor

et le fragment processor (voir figure 2.3).

Fragment TestsTraitements

Textures

shaderFramebuffer

AssemblageRasterization

ClippingCullingVertex

shader

Fig. 2.3 – Pipeline graphique programmable DirectX 9 et OpenGL 2.0.

2.4. Programmation shader 7

2.3.2 Carte graphique avec pipeline DirectX 10 et OpenGL 2.1

L’idee reste la meme que celle du pipeline DirectX 9 et OpenGL 2.0 auquel est rajoute le geometry

processor qui est, lui aussi, programmable (geometry shader) (voir figure 2.4).

Fragmentshadershader

Vertex Assemblage Geometryshader

RasterizationClippingCulling

Textures

Tests FramebufferTraitements

Fig. 2.4 – Pipeline graphique programmable DirectX 10 et OpenGL 2.1.

2.4 Programmation shader

2.4.1 Introduction

De nombreux langages de programmation shader ont ete developpes [McCool 04a, Mitrovıc 03][Proudfoot 01, Owens 05] pour la realisation de scene 3D. Le but de ces langages est de :

– permettre de faire un traitement particulier d’une surface pour la rendre realiste ;– permettre de creer des procedures pour traiter des surfaces et permettre d’eliminer des effets indesira-

bles ;– rendre la texture directement applicable sur une surface ;– prendre en compte le « temps reel » : la couleur d’un point d’une surface peut changer en fonction

du temps, de la distance et de l’angle de la vue.

2.4.2 Shade trees

L’idee des langages shader vient de Robert L. Cook [Cook 84]. Il existait des modeles qui permettaientde representer les ombres. Ce sont les modeles de Gouraud, Phong, Blinn, Turner, etc. Il a propose unnouveau modele pour le calcul des ombres en utilisant une structure arborescente, ainsi qu’un langagepour decrire ce nouveau modele. Avant les travaux de Cook, le calcul des ombres se faisait en deuxetapes :

– on determinait les parametres qui modelisent l’apparence d’une surface ;– on utilisait ces parametres avec une fonction qui permettait de creer les ombres et qui etait predefinie.

L’idee de Cook est de supprimer cette fonction. Il represente, par un nœud d’un arbre, des operationselementaires (produit scalaire, normalisation de vecteur, etc.). Le calcul de l’ombre en un point se fait enparcourant l’arbre en allant des feuilles a la racine. La valeur finale du point se trouve donc a la racinede l’arbre.


2.4.3 RenderMan

RenderMan a ete developpe par la societe Pixar [Pixar 07a]. Son utilisation commence avec le filmYoung Sherlock Holmes en 1985. RenderMan [Pixar 07b, Pixar 05] est compose de :

– une interface (The RenderMan Interface), qui permet la communication entre un logiciel de modelisa-tion et un programme de rendu 3D ;

– un langage shader (The RenderMan Shading Language) qui permet d’implementer les fonctionnalitesdefinies par l’interface.

Le langage de programmation RenderMan ressemble beaucoup au langage C-ANSI.

Ce langage propose la programmation de trois types de shader :

– un shader qui permet de definir la couleur d’un point d’une surface en fonction des sources lumi-neuses ;

– un deuxieme shader qui permet de definir la couleur d’un point d’une surface en fonction des pro-prietes de cette surface ;

– un dernier type de shader qui permet de gerer la couleur d’une lumiere a travers un volume.

L’interface ne prend pas en compte la notion de rendu « temps reel ». Mais aujourd’hui, grace a latechnologie, on peut tout a fait faire du « temps reel » avec RenderMan.

2.4.4 The PixelFlow shading system

Dans les annees 1990, on voit l’apparition d’un systeme appele PixelFlow [Olano 98, Molnar 92]. Cesysteme avait pour objectif d’etre « temps reel ». Il utilise l’API OpenGL. L’idee avec PixelFlow estde decomposer une image (operation appelee « tiling ») et de traiter les differentes decompositions enparallele. On a donc une architecture du systeme basee sur la parallelisation du traitement (voir figure2.5).

Fig. 2.5 – Architecture PixelFlow (extrait de [Molnar 92]).

Avec ce systeme, un langage shader a ete cree : the pfman shading language. Ce langage de program-mation est proche de la syntaxe du C et il est egalement tres proche de RenderMan.


2.4.5 SSL

Le langage SSL (Stanford Shading Language) est a l’origine des autres langages shader qui l’ont suivi. Ila ete developpe a partir de 1999. La premiere version etait tres proche du langage Lisp mais, aujourd’hui,il ressemble au C-ANSI et utilise l’API OpenGL [Mark 01].Le langage permet de developper deux shaders : un qui gere les sources lumineuses et un autre qui gereles surfaces. Ces deux shaders sont alors compiles dans un autre langage intermediaire produisant despipeline programs. Ces pipeline programs sont de trois sortes : ceux qui operent sur les sommets, ceuxqui operent sur les polygones et ceux qui operent sur les applications des textures. Ces pipeline programs

seront alors compiles en code de bas niveau pour le CPU ou le GPU. Cette decomposition en pipeline

programs et a l’origine de la programmation actuelle.

2.4.6 DirectX HLSL et GLSL

DirectX HLSL (High-Level Shading Language) et GLSL (OpenGl Shading Language) sont des langagesshaders qui ont ete developpes par Microsoft et 3D Lab pour HLSL et l’ARB (Architecture Review Board)pour GLSL. Ce dernier etait l’organisme qui s’occupait du standard OpenGL pour GLSL (aujourd’hui,c’est The Khronos group). Ces deux langages utilisent soit l’API graphique DirectX, pour HLSL, etOpenGL pour GLSL. Ces deux langages sont donc independants de l’architecture de la carte graphique.Il faut donc juste que la carte graphique supporte certaines extensions. Ces deux langages utilisent lepipeline graphique que nous avons presente precedemment. On cree donc deux types de shader : le vertex

shader et le pixel shader (voir figure 2.6).

Pour GLSL [Brumme 03, Rost 04], la carte graphique doit supporter quatre extensions qui sont les sui-vantes : GL ARB shading language, GL ARB shader objects, GL ARB vertex shader et GL ARB fra-gment shader. Depuis l’API graphique OpenGL 2.0, ces extensions font parties de la specification OpenGL.Donc, une carte graphique supportant l’API OpenGL 2.0 peut-etre programmee avec GLSL. La syntaxede GLSL est proche du langage C.

Fig. 2.6 – Structure d’un programme GLSL (extrait de [Ananth 07b]).


Pour DirectX HLSL [Mitchell 05, McCool 03a], la carte graphique doit supporter l’API graphiqueDirectX 9. La syntaxe de ce langage est proche du C-ANSI. Il n’est pas tres utilise du fait que NVIDIAet Microsoft se sont associes pour creer le langage shader Cg.

2.4.7 Cg

Le langage Cg (C for graphics) a ete developpe en collaboration avec la societe NVIDIA et Micro-soft [Mark 03, NVIDIA 07a, Fernando 03]. La syntaxe de Cg est proche du langage de programmationC/C++. Ce langage permet une programmation quelle que soit l’API graphique, DirectX ou OpenGL(voir figure 2.7). Il est donc interessant du fait de sa portabilite. Olivier Nocent [Nocent 07] a ecrit desclasses en C++, qui utilisent Cg, pour simplifier l’ecriture des shaders : c’est la bibliotheque GLOOSE(Object Oriented Shading Environment for OpenGL).

Fig. 2.7 – Le compilateur de Cg adapte le code selon l’API utilisee (extrait de [Fernando 03]).

2.4.8 RenderMonkey

RenderMonkey a ete developpe par la societe ATI et par 3D Lab. Il a ete propose a la communautedes developpeurs en 2002 [ATI 07]. L’utilisation de RenderMonkey est independante de l’API graphique.RenderMonkey est un environnement de programmation (IDE) avec une interface graphique pour l’uti-lisateur. RenderMonkey se presente donc plutot comme un editeur de shader qui permet de creer desshaders GLSL et HLSL.

2.4.9 Ashli

Ashli (Advanced Shading Language Interface) a ete aussi developpe par ATI [Bleiweiss 03]. CommeRenderMan, il presente une interface qui permet de faire le lien entre une application et un environnementde creation 3D. Ashli propose aussi une API qui permet son utilisation dans du code C/C++.

2.4.10 PyGPU

PyGPU est un langage de programmation shader base sur le langage Python [Lejdfors 05] et OpenGL.PyGPU offre des fonctions sur les images qui permettent de travailler dans plusieurs espaces de couleur(RGB, YUV, gray scale, CMYK, etc.). Avec ce langage, on peut specifier les fonctions Python qui doiventetre executees par le GPU et celles qui doivent etre executees par le CPU.


2.4.11 Scout

Scout est un langage de programmation concu pour la visualisation et l’analyse de donnees[McCormick 04]. Il utilise l’API OpenGL. Ce langage ne semble pas etre tres utilise.

2.4.12 CGiS

Le langage CGiS (Computer Graphics in Scientific programming) [Fritz 04] reprend l’idee de la pa-rallelisation du traitement des donnees et du concept de flux et de noyau de (voir 2.5.2). Lorsque l’onprogramme avec CGiS on definit trois parties : Code, Control et Interface. La partie Code corresponda la declaration des fonctions a executer sur une donnee. La partie Control permet de creer un tableaude toutes les donnees a traiter en parallele. Enfin, la partie Interface permet de declarer les donnees. Celangage utilise Cg et C.

2.4.13 Bibliotheques : Accelerator, Glift, Brahma

Accelerator est une bibliotheque developpee par Microsoft. Elle permet de creer des programmes quitraitent des donnees en parallele [Tarditi 05].

Glift est une bibliotheque dont le but est de faciliter la programmation shader. Elle utilise le C++ etCg [Lefohn 06].

Brahma est une bibliotheque pour les plateformes .NET qui permet d’exploiter les ressources GPU[Ananth 07a].

2.4.14 Bibliotheques pour la vision par ordinateur : OpenVIDIA, Flog, GPUCV

La bibliotheque OpenVIDIA a pour objectif de permettre d’utiliser une ou plusieurs cartes graphiquespour pouvoir faire du traitement d’images en « temps reel »[OpenVIDIA 07]. Cette bibliotheque est baseesur le langage C/C++ et l’API OpenGL. Cette bibliotheque propose un detecteur de contours (Canny)et de coin, des outils pour le suivi : de couleur, de coin, de peau, des outils de correction de contraste etde luminosite ainsi que l’implementation de VideoOrbits (algorithme pour creer une mosaıque d’images).

Flog (Filter Library On GPU ) est une bibliotheque qui permet d’implementer l’application de filtresur des images en utilisant le GPU [Chiara 04]. Cette bibliotheque genere du code source Cg.

La bibliotheque GPUCV correspond a l’implementation de la bibliotheque OpenCV sur GPU[Farrugia 06]. Elle utilise le langage GLSL et ameliore les performances, en terme de temps d’execution,d’OpenCV (voir table 2.1).

OpenCV GPU

3×3 erosion 24 ms 3.0 ms

5×5 erosion 31 ms 8.5 ms

RGB to XYZ 11 ms 0.6 ms

RGB to HSV 18 ms 1.7 ms

Binary threshold 1.0 ms 0.7 ms

Tab. 2.1 – Comparaison entre OpenCV et GPUCV pour une image de 1024 × 1024 (extrait de[Farrugia 06]).


2.4.15 CTM

CTM (Close To Metal) [Segal 06], anciennement appele DPVM (Data Parallel Virtual Machine),permet un acces de bas niveau a la carte graphique, c’est-a-dire sans passer par l’API graphique. CTMest developpe par ATI/AMD. CTM est compose de trois parties differentes : la premiere est la Command

Processor qui permet de gerer les commandes envoyees par une application ; la partie Memory Controller

permet le controle de la memoire de la carte graphique ; la derniere partie est la Data Parallel Array, quiest chargee de traiter les donnees en memoire. Le traitement a realiser est ecrit dans un pseudo-langaged’assemblage.

2.4.16 CUDA

CUDA (CompUte Driver API ) n’est utilisable qu’avec des cartes graphiques NVIDIA GeForce 8[NVIDIA 07b]. Ce langage permet d’acceder au GPU sans passer par l’intermediaire des API graphiques.CUDA propose un SDK (Software Development Kit) qui s’utilise avec le langage C. Notons qu’avecCUDA il existe deux bibliotheques : CUBLAS (CompUte Basic Linear Algebra Subprogram) et CUFFT(CompUte Fast Fourier Transform). CUBLAS correspond a la bibliotheque BLAS (Basic Linear Algebra

Subprogram). CUFFT est une bibliotheque qui implemente des algorithmes de la transformee de Fourier.

2.4.17 Resume des outils pour la programmation GPU

Le tableau 2.2 donne un apercu global des outils qui permettent la programmation des cartes gra-phiques. Les langages RenderMan, GLSL, HLSL et Cg sont actuellement les plus utilises. Le tableau 2.3presente les bibliotheques qui font appel au GPU. Ils sont peu utilises sauf OpenVidia.

API graphique Syntaxe Reference

Shade trees [Cook 84]

RenderMan OpenGL/DirectX C [Pixar 07b] [Pixar 05]

PixelFlow OpenGL C [Olano 98]

RTSL OpenGL C [Mark 01]

HLSL DirectX C [Mitchell 05] [McCool 03a]

GLSL OpenGL C [Brumme 03][Rost 04]

Cg OpenGL/DirectX C/C++ [Mark 03] [NVIDIA 07a]

RenderMonKey OpenGL/DirectX [ATI 07]

Ashli OpenGL/DirectX C [Bleiweiss 03]

PyGPU OpenGL Python [Lejdfors 05]

Scout OpenGL [McCormick 04]

CGiS OpenGL/DirectX C++/Cg [Fritz 04]

CTM Assembleur [Segal 06]

CUDA C [NVIDIA 07b]

Tab. 2.2 – Outils pour la programmation GPU.


Nom Langage Reference

Bibliotheques pour la vision OpenVIDIA C/C++ [OpenVIDIA 07]par ordinateur Flog C,Cg [Chiara 04]

GPUCV C/C++ [Farrugia 06]

Autres bibliotheques Accelerator C# [Tarditi 05]Glift C++ [Lefohn 06]Brahma .NET [Ananth 07a]

Tab. 2.3 – Bibliotheques utilisant le GPU.

2.4.18 Exemple de programmation shader en GLSL

L’exemple ci-dessous est tire d’un tutoriel disponible sur le Web [Ananth 07b]. Ce programme donnel’image, du point de vue de la camera, d’une theiere qui a une couleur unie et qui tourne. On a troisfichiers : minimal.ver, minimal.fra et main.c . Le resultat s’affiche dans une fenetre.

Le fichier minimal.ver contient le code qui sera execute par le vertex processor :

void main()

{

/* Transforme les coordonnees des sommets exprimees dans le repere scene,

/ en coordonnees exprimees dans le repere camera */

gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;

}

Le fichier minimal.fra contient le code qui sera execute par le fragment processor :

void main()

{

/* On donne la couleur voulue aux fragments de la theiere */

gl_FragColor = vec4(0.4,0.4,0.8,1.0);

}


Le fichier main.c contient diverses fonctions. La fonction setShaders() permet l’initialisation des sha-ders.

void setShaders()

{

char *vs = NULL,*fs = NULL;

/* Creation des shaders */

v = glCreateShader(GL_VERTEX_SHADER);

f = glCreateShader(GL_FRAGMENT_SHADER);

/* Recuperation des codes sources des shaders vertex et fragment */

vs = textFileRead("minimal.vert");

fs = textFileRead("minimal.frag");

const char * vv = vs;

const char * ff = fs;

/* Attachement des codes sources */

glShaderSource(v, 1, \&vv, NULL);

glShaderSource(f, 1, \&ff, NULL);

free(vs);

free(fs);

/* Compilation des shaders */

glCompileShader(v);

glCompileShader(f);

/* Creation d’un programme. Un programme contient au plus un vertex shader

/ et un fragment shader */

p = glCreateProgram();

/* Attachement des shaders au programme */

glAttachShader(p,v);

glAttachShader(p,f);

/* Edition des liens */

glLinkProgram(p);

/* Fonction qui permet l’utilisation du programme */

glUseProgram(p);

}


La fonction renderScene() qui trace la theiere :

void renderScene(void){

/* Initialisation de bit de variable OpenGL */

glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);

/* Initialisation de la matrice de transformation */

glLoadIdentity();

/* Placemment de la camera */

gluLookAt(0.0,0.0,5.0,0.0,0.0,-1.0,0.0f,1.0f,0.0f);

/* Placement d’une source d’eclairage */

glLightfv(GL_LIGHT0, GL_POSITION, lpos);

/* On fait tourner la theiere selon un pas a */

glRotatef(a,0,1,1);

/* Tracage de la theiere */

glutSolidTeapot(1);

/* Incrementation du pas de rotation */

a+=0.1;

glutSwapBuffers();

}


La fonction main() :

int main(int argc, char **argv)

{

/* Creation de la fenetre d’affichage */

glutInit(&argc, argv);

glutInitDisplayMode(GLUT_DEPTH|GLUT_DOUBLE|GLUT_RGBA);

glutInitWindowPosition(100,100);

glutInitWindowSize(320,320);

glutCreateWindow("Exemple simple");

/* Definition de la fonction qui gere le trace de la scene */

glutIdleFunc(renderScene);

/* Activation du test de profondeur, affectation de la

/ couleur blanc au fond de la scene et activation du

/ back-face culling */

glEnable(GL_DEPTH_TEST);

glClearColor(1.0,1.0,1.0,1.0);

glEnable(GL_CULL_FACE);

/* Initialisation de GLEW (bibliotheque qui permet la gestion

/ des extensions OpenGL */

glewInit();

/* Initialisation des shaders */

setShaders();

/* Execution */

glutMainLoop();

return 0;

}

2.5 Programmation GPGPU

2.5.1 Concept

La programmation GPGPU (General-Purpose Computation Using Graphics Hardware) [GPGPU 07]consiste a utiliser les differents elements du GPU pour pouvoir arriver a un resultat recheche. Du pointde vue du developpeur, la programmation avec la carte graphique revient a traiter un flux de donnees quipasse par le pipeline graphique. Il peut programmer le vertex, le fragment et le geometry processor. Pourcela, plusieurs methodes peuvent etre mises en œuvre. La premiere facon de proceder est la methode duRead Back (voir figure 2.8) : le CPU envoie les donnees au pipeline qui sont traitees par les differentesunites programmees. Le CPU peut alors recuperer l’image stockee dans le frame buffer.

2.5. Programmation GPGPU 17

CPU Vertexprocessor

Fragmentprocessor

Framebuffer

Fig. 2.8 – Read Back.

La deuxieme facon de faire est d’utiliser les textures (Copy to Texture) ce qui permet d’eviter derepasser par le CPU lors de la realisation de plusieurs passes (voir figure 2.9). De plus, le debit desdonnees, a la sortie du frame buffer, est superieur au debit que le bus peut assurer. Le bus est alorsun « goulot d’etranglement ». L’image contenue dans le frame buffer est copiee dans l’unite de texture.Cette possibilite existe depuis les cartes graphiques de type NV40 (NVIDIA GeForce 6) et R520 (ATIX1300), donc depuis les annees 2004-2005. Notons que l’utilisation du vertex processor est alors « court-circuitee »lors de l’utilisation en plusieurs passes du fragment processor.

CPU Vertexprocessor

Fragmentprocessor

Framebuffer

Textures

Fig. 2.9 – Copy to Texture.

On peut aussi eviter de passer par le frame buffer en copiant l’image, restituee par le fragment processor,directement dans une texture : c’est la methode du Render to Texture (voir figure 2.10). Il devient inutilede passer par le frame buffer si on ne veut pas afficher l’image a l’ecran.

CPU Vertexprocessor

Fragmentprocessor

Textures

Fig. 2.10 – Render to Texture.

Une autre methode est d’utiliser le VBO (vertex buffer object) (voir figure 2.11). Le VBO est tressimilaire au vertex array mais avec plus de modes de transfert des donnees. Un vertex array est letableau des sommets qui sera traite par le vertex processor. Cette methode permet de reutiliser le vertex

processor.


CPU Vertexprocessor

Fragmentprocessor

TexturesVBO

Fig. 2.11 – Copy to VBO.

On peut copier directement l’image issue du fragment processor dans le VBO : c’est la methode duRender to VBO (voir figure 2.12). Cette methode permet d’eviter le transfert des donnees : fragment

processor vers textures, puis textures vers VBO.

CPU Vertexprocessor

Fragmentprocessor

VBO

Fig. 2.12 – Render to VBO.

Avec l’arrivee de la carte graphique GeForce 8 de NVIDIA, on a donc le geometry shader en plus. Onpeut recuperer les donnees traitees juste apres le geometry processor.

CPU Vertexprocessor

Geometryprocessor

Fragmentprocessor

Stream buffer

Fig. 2.13 – G80 : render to Stream Buffer.

Le tableau 2.4 donne l’utilisation des vertex shader, fragment shader, textures, VBO et du frame buffer

selon les methodes qui ont ete presentees.

2.5. Programmation GPGPU 19

Methodes Plusieurs Vertex Geometry Fragment Textures VBO Frame Stream

passes processor processor processor buffer buffer

Read non x x xBack

Copy oui x x xto

Texture

Render oui x xto

Texture

Copy oui x x x xto VBO

Render oui x x xto VBO

Render to oui x x x xStream

Buffer

Tab. 2.4 – Methodes de programmation GPGPU.

La programmation GPGPU offre le concept de flux (stream) et de noyau (kernel) : le Stream Computing

Model. Le flux correspond a l’ensemble des donnees qui vont etre traitees. Les donnees du flux sontindependantes entre elles. Le noyau correspond au traitement a appliquer a chaque donnee. Pour parvenirau resultat recherche, il est souvent necessaire d’utiliser plusieurs noyaux (voir figure 2.14). Les donneesvont etre chargees souvent dans une texture ou dans le VBO. Le noyau sera execute par le fragment

processor et le vertex processor.

Données Résultatintermédiaires

Noyaux nNoyaux 1Données

Fig. 2.14 – GPGPU : utilisation de plusieurs noyaux.

2.5.2 Brook et Sh

Brook et Sh sont deux metalangages de programmation. Ils permettent une programmation sans avoirune connaissance de l’architecture logique des GPU, et utilisent les concepts de noyau et de flux.

Brook [Buck 04] est un metalangage du langage C.Sh a ete concu par Michael MCool a l’universite de Waterloo [Sh 07, McCool 04b]. Il est base sur le

langage C++. L’avantage de ces langages est de pouvoir programmer sans connaıtre la structure d’unpipeline graphique. leur inconvenient est de rajouter encore une « couche » : Brook ou Sh ⇒ HLSL ouGLSL ⇒ DirectX ou OpenGL ⇒ pilote de la carte graphique. Les performances obtenues ne sont doncpas optimales.


2.5.3 Core Image et Quartz Composer

Core Image [Apple 07] est une bibliotheque disponible sur la plateforme MAC OS X tiger. Elle fournietrois classes : ClImage, ClKernel, ClFilter. La classe ClImage permet de manipuler les images. Ces imagesseront traitees par un ou plusieurs noyaux contenus dans la classe ClFilter. Un noyau est declare grace ala classe ClKernel. Core image analyse les differents noyaux et les execute selon l’ordre le moins couteux.Quartz Composer est un logiciel avec une interface graphique qui permet de creer des noyaux. Ce logicielutilise Core Image.

Chapitre 3

Utilisation de la carte graphique envision par ordinateur

3.1 Introduction

Ce chapitre a deux objectifs. Le premier est de repertorier les outils mathematiques qui ont eteimplementes sur GPU. Le deuxieme est de dresser un etat de l’art de l’utilisation du GPU pour lavision par ordinateur. Pour les outils mathematiques sur GPU, on peut etablir les categories suivantes :

– operations sur les flottants ;– multiplication matricielle ;– calcul matriciel ;– resolution d’une equation ou d’un systeme d’equations ;– LCP (Linear Complementarity Problem) ;– resolution des equations d’Euler ;– diagramme de Voronoı ;– convolution ;– ondellettes.

De meme, concernant les outils de vision faisant appel au GPU, on peut definir les categories suivantes :

– mise en correspondance, calcul de la carte de disparites ;– reconstruction 3D a partir d’images ;– creation de mosaıque d’images ;– transformation d’image ;– segmentation d’image ;– detection de contour ;– reconnaissance d’objet ;– analyse du mouvement et suivi d’objet.

3.2 Outils mathemathiques sur GPU

3.2.1 Operations sur les flottants

Guillaume de Gracca et David Defou [Gracca 06] proposent l’implementation, sur GPU, d’operationsflottantes en utilisant Brook. Ils utilisent les theoremes de « split » et de multiplication de Dekker[Dekker 72] ainsi que le theoreme de Knuth [Knuth 98] pour l’addition. Ils implementent aussi les algo-rithmes proposes par Lauter [Lauter 05] pour les operations d’addition et de multiplication.

21

22 Chapitre 3. Utilisation de la carte graphique en vision par ordinateur

3.2.2 Multiplication matricielle

E. Scoot Larsen et David McAllister [Larsen 01] proposent une implementation sur GPU de la multi-plication matricielle. Les matrices sont chargees en memoire comme des textures. Par exemple, soient :

A =

[1 23 4

]

et B =

[5 67 8

]

, on a AB =

[19 2243 50

]

.

Les auteurs utilisent une methode par tranches (slice). La premiere tranche est obtenue par la multi-plication terme-a-terme des elements de deux matrices (multiplication de Hadamard). Cette operationse realise sur GPU. La premiere matrice est obtenue par duplication de la premiere colonne de A et laduplication de la premiere ligne de B. On obtient ainsi la premiere tranche :

premiere tranche =

[1 13 3

]

�

[5 65 6

]

=

[5 615 18

]

On calcule de meme la deuxieme tranche en prenant la seconde colonne de A et la seconde ligne de B.On obtient :

deuxieme tranche =

[14 1628 32

]

La multiplication matricielle de A par B est alors obtenue en additionnant les deux tranches, operationrealisee sur GPU.

AB =

[5 615 18

]

+

[14 1628 32

]

=

[19 2243 50

]

.

L’utilisation de cette methode necessite plusieurs passes dans le GPU.

Dans [Fatahalian 04], les auteurs implementent la methode precedente, mais utilisent les canaux destextures (rouge, vert, bleu, alpha) pour faire de la multiplication matricielle par bloc.

Dans [Hall 03], les auteurs proposent une implementation de la multiplication matricielle « classique »

sur GPU. On a donc une seul passe dans le GPU. Ils ameliorent l’algorithme en calculant le produitmatriciel par bloc. Ils utilisent les canaux des textures (rouge, vert, bleu, alpha).

3.2.3 Calcul matriciel

Adam Moravanszky [Moravanszky 03] utilise DirectX 9 pour implementer sur GPU diverses operationsmatricielles. Les operations sont les suivantes :

– assignation : chargement d’une matrice sur GPU ;– addition de deux matrices : A = B + C ;– multiplication deux matrices : A = BC ;– multiplication transposee de deux matrices : A = CTB ;– operateur dot : operateur qui correspond a un produit scalaire : dot(a,b) = aTb ;– norme au carre d’un vecteur ;– multiplication de matrice par un scalaire ;– addition des elements d’une matrice au produit scalaire ;– element maximun d’une matrice ;– element minimum d’une matrice ;– operateur mad (multiply add) : A = A + Bc ou A = B + Cd ou A = A + BC ;– operateur madad : A = B + (C + D)D.

Dans [Kruger 03], les deux auteurs proposent aussi l’implementation sur GPU de divers operateurs surles vecteurs ainsi que sur les matrices : addition, multiplication, maximum, minimum, etc.

3.2. Outils mathemathiques sur GPU 23

3.2.4 Resolution d’une equation ou d’un systeme d’equations

Nico Galoppo, Naga K. Govindaraju, Michael Henson et Dinesh Manocha [Galoppo 05] proposent uneimplementation sur GPU de la decomposition LU d’une matrice ainsi qu’une resolution d’un systemelineaire de la forme Ax = b par la methode de Gauss-Jordan. Une decomposition LU consiste a mettreune matrice A sous la forme du produit de deux matrices de forme bien particuliere. La premiere matriceL, (pour low), est une matrice triangulaire inferieure a diagonale unite. La deuxieme U est une matricetriangulaire superieure. Par exemple, pour une matrice de taille 3 × 3 :

A = LU =

1 0 0l21 1 0l31 l32 1

u11 u12 u13

0 u22 u23

0 0 u33

La resolution de Ax = b par la methode Gauss-Jordan consiste a calculer la matrice A−1. Les auteursposent une matrice A′ sous la forme [A|b]. Par iterations successives, en faisant des combinaisons lineairesentre les lignes du systeme (pivot de Gauss), ils cherchent a avoir A′ sous la forme :

A′ =

1 0 0 | x0 1 0 | y0 0 1 | z

ou (x, y, z) est la solution recherchee. Les matrices sont chargees comme des textures. Les operations sefont a l’aide du fragment shader.

Jens Kruger et Rudiger Westermann [Kruger 03] implementent diverses operations sur les matriceset sur les vecteurs qu’ils utilisent pour realiser la resolution d’un systeme de la forme Ax = b par lamethode du gradient conjugue. La matrice A doit etre une matrice symetrique positive et creuse. Lesauteurs donnent aussi une petite description de la resolution sur GPU de la methode iterative de Gauss-Seidel. Leur objectif est de resoudre les equations de Navier-Stokes qui modelisent le mouvement d’unfluide.

Adam Moravanszky [Moravanszky 03] utilise les operateurs qu’il a implementes, sur GPU, pour resou-dre un systeme lineaire Ax = b avec la methode du gradient conjugue.

Dans [Goodnight 03], les auteurs veulent resoudre l’equation suivante : k∇2T = −S (equation dePoisson), ou T est la temperature, k une constante et S une source de chaleur. Cette equation permet demodeliser la temperature dans un espace comportant une source de chaleur. Pour resoudre cette equation,ils utilisent la methode de multigrilles. Ils discretisent l’espace en une grille et ils cherchent la temperatureen chaque point de la grille. Ils appliquent de facon iterative le laplacien (∇2) sur cette grille jusqu’al’obtention de la convergence. Le laplacien est approche par une operation de convolution qui est realiseepar le GPU : ∇2Ui,j ' Ui−1,j + Ui,j−1 + Ui,j+1 − 4Ui,j . Pour etudier la convergence, ils utilisent le residu∇2T + S. Ils appliquent un certain nombre de fois le laplacien, puis calculent une grille de residus. Cettegrille est interpolee en une grille de resolution superieure. Ils appliquent ensuite le laplacien (n fois) surcette grille des residus. Ils interpolent de nouveau cette grille avec la resolution de depart et l’utilisentpour affiner la grille de depart. L’operation se repete jusqu’a l’obtention de la convergence.

Dans [Bolz 03] les auteurs implementent une resolution du systeme Ax = b, ou A est une matricecreuse. Ils utilisent la methode du gradient conjugue d’une part et la methode multigrilles d’autre part.


3.2.5 LCP

Adam Moravanszky [Moravanszky 03] utilise des operateurs, implementes sur GPU, pour resoudre leprobleme de complementarite lineaire Linear Complementarity Problem. Pour cela, il utilise la methodede Jacobi. Le LCP est un probleme d’optimisation. Il se presente sous la forme :

x ≥ 0 (3.1)

Ax + b ≥ 0 (3.2)

xT (Ax + b) = 0 (3.3)

A et b sont donnes et x est a trouver. A doit etre une matrice definie positive. Il utilise l’algorithmede la methode iterative de Jacobi.

3.2.6 Resolution des equations d’Euler

Dans [Hagen 06], les auteurs proposent une implementation sur GPU de la resolution des equationsd’Euler qui modelisent la dynamique des gaz parfaits (conservation de la masse, de l’energie et de laquantite de mouvement). Soit, dans un espace a trois dimensions :

ρρuρvρwE

t

+

ρuρu2 + p

ρuvρuw

u(E + p)

x

+

ρvρuv

ρv2 + pρvw

v(E + p)

y

+

ρwρuwρvw

ρw2 + pw(E + p)

z

=

000gρ

gρw

z

Avec ρ la densite, (u, v, w) le vecteur vitesse, p la pression, g l’acceleration gravitationnelle et E l’energietotale. La notation [ ]t correspond a la derivee partielle par rapport au temps. La resolution est effectueecomme pour l’equation de Poisson (voir 3.2.4) en utilisant la methode multigrilles.

3.2.7 Diagramme de Voronoı

Soit S un ensemble de points, de segments ou de polygones (appeles aussi sites) d’un espace dedimension d. La cellule de Voronoı V (p) d’un site p est l’ensemble des points de l’espace dont p estle site le plus proche. Le diagramme de Voronoı correspond a la partition de l’espace forme par lescellules de Voronoı.

Dans [Hoff III 99], les auteurs implementent le calcul de la distance entre divers types de site et lespoints de l’espace sur le GPU. La dimension de l’espace est de deux ou trois.

3.2.8 Filtrage

Matthias Hopf et Thomas Ertl [Hopf 00] utilisent le GPU pour accelerer l’application d’operateursmorphologiques sur des images. Ces operateurs peuvent etre une erosion, une dilatation, une ouvertureou une fermeture. L’image est chargee sur le GPU comme une texture et l’operation est effectuee par lefragment processor. L’operation consiste en l’application de filtres qui sont donc non lineaires.

Les memes auteurs dans [Hopf 99a], proposent une methode pour faire une operation sur GPU deconvolution 3D sur un volume. La convolution discrete 3D peut s’ecrire sous cette forme :

f(x, y, z) =∑

i1,i2,i3

k(i1, i2, i3)f(x + i1, y + i2, z + i3)),

3.2. Outils mathemathiques sur GPU 25

ou f est la donnee a convoluer, k est un filtre et f , le resultat. Les auteurs se placent dans le cas d’un filtreseparable, on a donc k(i1, i2, i3) = k(i1)k(i2)k(i3). On peut donc ecrire la suite d’operations suivante :

f1(x, y, z) =∑

i1

k(i1)f(x + i1, y, z) (3.4)

f2(x, y, z) =∑

i2

k(i2)f1(x, y + i2, z) (3.5)

f(x, y, z) =∑

i3

k(i3)f2(x, y, z + i3) (3.6)

Les deux premieres equations sont realisees par une convolution 2D a realiser sur les plans du volumediscretise. La troisieme equation est realisee par une convolution 1D. La realisation de cette convolution3D se fait avec le GPU en deux passes.

3.2.9 Ondelettes

Matthias Hopf et Thomas Ertl [Hopf 99b] proposent une implementation de la decomposition en on-delettes sur GPU. Cette methode consiste a decomposer une image en d’autres images de resolutionsinferieures. Pour cela, ils utilisent des filtres passe-haut et passe-bas. Cette operation se fait par convolu-tion et est realisee par le GPU. Les auteurs utilisent les filtres de Haar ou de Daubechies.

3.2.10 Tableau recapitulatif

Categories Methode Implementation Reference

Operations sur les flottants Brook [Gracca 06]

Multiplication matricielle Methode par tranches SIMD [Larsen 01][Fatahalian 04]

Methode « classique » Non precisee [Hall 03]

Calcul matriciel DirectX 9 [Moravanszky 03]Non precisee [Kruger 03]

Resolution d’un systeme Resolution de Gauss-Jordan Non precise [Galoppo 05]ou d’une equation Resolution de Gauss-Seidel Non precise [Kruger 03]

Gradient conjugue Non precisee [Kruger 03]DirectX 9 [Moravanszky 03]Non precisee [Bolz 03]

Laplacien, multigrilles Non precisee [Goodnight 03]Multigrilles Non precisee [Bolz 03]

Resolution des equations Multigrilles Non precisee [Hagen 06]d’Euler

LCP Jacobi DirectX 9 [Moravanszky 03]

Diagramme de voronoı Non precise [Hoff III 99]

Filtrage Filtre non lineaire 2D Non precise [Hopf 00]Filtre lineaire 3D Non precise [Hopf 99a]

Ondelettes Non precise [Hopf 99b]

Tab. 3.1 – Outils mathematiques sur GPU.


3.3 Utilisation de la carte graphique en vision par ordinateur

3.3.1 Mise en correspondance et calcul de la carte de disparites

La carte de disparites est construite dans le cadre de la mise en correspondance stereoscopique. Ladisparite est le vecteur deplacement entre un pixel de l’image de gauche et son correspondant dans l’imagede droite. La carte de disparites est calculee par rapport a une image de reference (l’image de gauche oul’image de droite).

Minglun Gong et Ruigang Yang [Gong 05a] utilisent des images segmentees, selon la couleur, pourguider la mise en correspondance par correlation. Ils utilisent les methodes d’optimisation WTA (winner-

take-all) et SO (scanline optimization) pour determiner le meilleur correspondant. La carte de disparitesest generee par le GPU.

Alan Brunton, Chang Shu et Gerhard Roth [Brunton 06] proposent une implementation, sur GPU,de la methode de propagation de croyance (belief propagation) de Felzenszwalb and Huttenlocher. Cettemethode utilise le modele des champs de Markov. La propagation de croyance est une methode d’optimi-sation globale. Qungxiong Yang, Liang Wang, Ruigang Yang, Shengnan Wang, Miao Liao et David Nister[Yang 06] ont eux aussi presente une implementation sur GPU de la methode de propagation de croyancepour la stereovision. Cristopher Zach, Konrad Karner et Horst Bischof [Zach 04] calculent la carte desdisparites avec une mise en correspondance hierarchique des pixels par correlation. Ils creent des pyra-mides d’images, chaque etage d’une pyramide correspond a l’image a une resolution differente. La cartede disparites est affinee a chaque etage de la pyramide en fonction de l’etage precedent. Les images sontchargees dans la memoire graphique comme des textures et le calcul des etages des pyramides se fait surGPU. Le calcul des scores de correlation se fait egalement sur GPU. Ils utilisent les mesures SAD (sum

of aboslute differences) ou SSD (sum of squared differences). Ruigang Yang et Marc Pollefeys [Yang 03]utilisent la mesure SSD ainsi qu’une approche adaptative pour la taille de la fenetre de correlation. Dans[Yang 04a] on retrouve la meme demarche que precedemment. Ils ajoutent l’utilisation de la verificationbi-directionnelle (cross-checking). L’idee de la verification bi-directionnelle est de calculer aussi la cartede disparites en prenant l’autre image comme reference. On compare les deux cartes, les pixels avec desdisparites contradictoires ne sont pas prise en compte. Cette operation se fait aussi a l’aide du GPU. JanWoetzel and Reinhard Koch [Woetzel 04] calculent une carte de disparites en utilisant plusieurs cameras.Ils utilisent la mesure TSSD (truncated sum of squared difference) et la methode locale d’optimisationWTA. Karl Jonsson [Jonsson 03] fait de la mise en correspondance hierarchique avec la mesure SSD.Il utilise DirectShow et Direct3D. Direct3D est un composant de l’API graphique DirectX qui permetl’utilisation des ressources GPU. DirectShow, qui fait partie lui aussi de DirectX, permet l’affichage et lacapture video ainsi que la creation de filtres pouvant etre appliques sur ces videos.

Minglun Gong et Yee-Hong Yang [Gong 05b] proposent un algorithme qu’ils appellent algorithmeORDP (the Orthogonal Reliability-based Dynamic Programming Algorithm). Cet algorithme utilise leCPU et le GPU (voir figure 3.1). Il est base sur la programmation dynamique. Il s’agit tout d’abordde calculer une matrice M qui contient les couts des correspondances possibles entre les pixels et derechercher le chemin de cout minimal dans M. Pour cette etape, ils utilisent le GPU.

3.3. Utilisation de la carte graphique en vision par ordinateur 27

Fig. 3.1 – Algorithme ORDP (extrait de [Gong 05b]).

Ruigang Yang, Greg Welch et Gary Bishop [Yang 02] reconstruisent une image d’un point de vuea partir d’images issues de cinq points de vue differents. Pour cela, ils utilisent la methode des plansglissants (sweep plane). L’idee est de discretiser l’espace 3D en plusieurs plans paralleles a une image dereference (voir figure 3.2).

Fig. 3.2 – Plans glissants (extrait de [Yang 02]).

Cette image de reference est projetee sur ces plans. On cherche le meilleur correspondant, dans lesimages projetees, des pixels des images des autres points de vue. Cette recherche est effectuee avec unemesure de correlation de type SSD. Cette selection et le calcul des scores sont realises par le GPU.


Dans [Cornelis 05], les auteurs reprennent la methode des plans glissants, mais avec la prise en comptedes problemes d’occultation, de zone homogene, et d’ambiguıte. Ils integrent la contrainte de voisinageau probleme en imposant que les voisins d’un point doivent etre a une profondeur voisine. Ils utilisentaussi une approche hierarchique. Ces problemes sont resolus a l’aide de l’application d’un filtre qui estimplemente sur GPU. Indra Geys, Thomas P. Kininckx et Luc Van Gool [Geys 04a] utilisent les plansglissants et les coupures de graphes (graph cut). Le CPU est utilise pour les coupures de graphes et leGPU pour les plans glissants.

3.3.2 Reconstruction 3D a partir d’images

La reconstruction 3D consiste a reconstruire le relief d’une scene 3D a partir d’une ou de plusieursimages.

Julien Mairal, Renaud Keriven et Alexandre Chariot [Mairal 05b, Mairal 05a] utilisent un modeledeformable avec une methode variationnelle. Leur objectif est de pouvoir faire une reconstruction durelief avec des videos issues de deux ou trois cameras. Ils creent un maillage qu’ils deforment jusqu’aobtenir la forme de l’objet. La deformation finale est obtenue grace a une minimisation d’une fonctiond’energie (critere). Ce critere est, ici, la somme des carres des differences entre les niveaux de gris. Laminimisation est obtenue par la methode de la descente de gradient. Pour accelerer les temps de calcul,ils utilisent le GPU.

Fig. 3.3 – Reconstruction du relief avec un modele deformable : a gauche le maillage obtenu, a droite lemaillage avec une texture de l’objet (extrait de [Mairal 05b]).

Cristopher Zach, Andreas Klaus, Bernard Reitinger et Konrad Karner [Zach 03] utilisent eux aussi unmaillage dont les positions des sommets sont estimees a l’aide d’un carte de profondeur. L’estimation despositions des sommets du maillage est iterative. Ils utilisent la multiresolution, le nombre de sommetsdu maillage et la resolution des images etant augmentes a chaque iteration. Pour le calcul de la carte deprofondeur, la mesure de correlation SAD est utilisee.

Ruigang Yang, Marc Pollefeys, Hua Yang et Greg Welch [Yang 04b] font de la reconstruction du reliefavec plusieurs cameras (jusqu’a cinq). Ils calculent une carte de disparites pour estimer la profondeur.La mise en correspondance se fait par correlation avec une fenetre adaptative et la mesure SSD. Cettemise en correspondance est realisee par le GPU.

Dans [Labatut 05] les auteurs font de la reconstruction du relief sur GPU avec la methode de shape

reconstruction [Pons 05]. Ils utilisent une sequence video. Ils font de la mise en correspondance en utilisantla mesure de correlation NCC (normalized cross-correlation). Cette operation est realisee par le GPU.


Pour chaque camera la carte de profondeur est calculee avec la par triangulation sur GPU. Chaquepixel et son correspondant sont projetes dans l’espace selon le point de vue. Cela permet d’obtenir laposition du point de la scene correspondant a un pixel et donc de determiner sa profondeur. Song Zhang,Dale Royer et Shing-Tung Yau [Zhang 06] proposent une implementation, sur GPU, de l’algorithme 2+1

phase-shifting pour estimer le relief. Cet algorithme permet a partir de trois images (deux images ou l’ona projete sur l’objet l’ombre d’une grille et une image de l’objet) de reconstruire le modele en 3D (voirfigure 3.4).

Fig. 3.4 – Algorithme 2+1 phase-shifting (extrait de [Zhang 06]).

3.3.3 Mosaıque d’images

Une mosaıque d’images correspond a une image construite avec plusieurs images.Dans [Fung 05a, Fung 02, Fung 04a], les auteurs reconstruisent un panoramique a partir d’images. Ils

utilisent l’algorithme VideoOrbits. La relation entre les pixels des images est donnee par une homographie.L’estimation de cette homographie revient a resoudre un systeme d’equations lineaires. Cette resolutionce fait sur le GPU (voir figure 3.5) et ils utilisent une approche multiresolution.

3.3.4 Transformation d’image

La transformation d’une image consiste a corriger une image selon une deformation geometrique ouphotometrique.

Dans [Fung 05a], James Fung presente un exemple d’un fragment shader qui permet de corriger uneimage qui a subi une distorsion radiale due au capteur. Dans [Johnson 06], l’auteur propose une correctiond’image sur GPU selon le schema de la figure 3.6. Il propose la correction perspective d’une image, lacorrection photometrique et la correction d’une distorsion due a l’utilisation d’une lentille d’objectifphotographique.


Fig. 3.5 – Algorithme VideoOrbits. En noir, les etapes qui sont traitees sur GPU (extrait de [Fung 05a]).La creation de la pyramide d’images multiresolution est faite sur GPU. L’estimation des parametres etla comparaison de ces parametres selon la resolution est elle aussi faite avec le GPU.

Fig. 3.6 – Correction d’une image (extrait de [Johnson 06]).


3.3.5 Segmentation d’image

La segmentation d’image correspond a l’obtention d’une partition de l’image en regions, suivant uncertain critere.

Joseph Kider et Liming Zhao [Kider 05] representent une image par une matrice dont les elementsde la matrice expriment la relation entre les pixels. Une matrice peut aussi etre la representation d’ungraphe. Pour partitionner le graphe en plusieurs sous-graphes (ce qui revient a segmenter l’image), ilsutilisent l’algorithme des coupes normalisees. La mise en œuvre de cet algorithme necessite de nombreusesmultiplications matricielles qui sont realisees par le GPU.

Dans [Griesser 05], Andreas Griesser segmente les images selon l’arriere plan et le premier plan avantd’une image. L’auteur propose une implementation de la methode de Mester [Mester 01] en utilisant leGPU.

Indra Geys at Luc Van Gool [Geys 04b] segmentent aussi les images selon l’arriere plan et le premierplan. Ils utilisent une sequence video, la methode des plans glissants et la methode d’optimisation descoupures de graphes (voir figure 3.7).

Fig. 3.7 – Segmentation en premier plan et arriere plan avec la methode des plans glissants et des coupuresde graphes. La methode des plans glissants est executee sur le GPU et la methode d’optimisation descoupures de graphes est effectuee par le CPU (extrait de [Geys 04b]).


3.3.6 Detection de contours

La detection de contours consiste a identifier les contours des objets presents dans une image.Cynthia Bruyns and Bryan Feldman [Bruyns 03] utilisent la transformee de Fourier pour filtrer les

images : Rconv = I ∗F = FFT−1(FFT [I]∗FFT [F ]) ou I est l’image, F un filtre et FFT une transformeede Fourier. Ils utilisent ensuite Rconv pour identifier les limbes des objets. Le calcul de la transformee deFourier est executee par le GPU.

Dans [Fung 05a], James Fung propose une implementation du detecteur de Canny sur GPU.Cris Aimone, Steve Mann et James Fung, dans [Fung 05b], donnent la methode de l’implementation

de la tranformee de Hough sur GPU. C’est cette implementation qui est utilisee dans la bibliothequeOpenVIDIA.

Robert Strzodka, Ivo Ihrke et Marcus Magnor [Strzodka 03] utilisent une implementation du detecteurde Canny pour detecter les contours des objets. La detection des contours est faite par le GPU. Puis ilsrealisent une approximation polygonale des contours a l’aide d’une transformee de Hough implementee,elle aussi, sur GPU.

3.3.7 Reconnaissance d’objet

La reconnaissance d’objet consiste a identifier un objet de forme particuliere dans une image. JamesFung and Steve Mann [Fung 04b] utilisent un espace propre (eigenspace) pour reconnaıtre l’objet dansune image. Un espace propre est un ensemble de vecteurs propres qui ont une valeur propre commune.Cet espace est determine a l’aide d’une base d’images qui represente l’objet sous divers angles de vue.Ils creent une matrice A avec les vecteurs propres. A peut s’ecrire sous la forme UΣVT (decompositionen valeurs singulieres (singular value decomposition)). Ces valeurs singulieres permettent de definir unesignature de l’objet, et de le reconnaıtre ensuite dans une image.

3.3.8 Analyse du mouvement et suivi d’objet

Robert Strzodka et Cristoph Garbe [Strzodka 04] proposent une methode d’estimation du flux optiquesur GPU. Cette methode est appliquee au suivi d’un groupe de personnes et a l’analyse du sanguindans une angiographie. Ils utilisent l’equation de contrainte du flux optique (equation des gradients) etils font l’hypothese de champs de deplacements localement constants. Pour chaque pixel, ils disposentd’un systeme surdetermine d’equations lineaires pour lequel ils procedent a une estimation au sens desmoindres carres totaux. Le vecteur deplacement est alors determine en calculant les vecteurs et les valeurspropes du tenseur de structure spatio-temporel. Ce calcul est realise en utilisant la methode de Jacobique les auteurs ont implemente sur GPU. La visualisation du resultat est aussi effectuee par le GPU ensuperposant une carte de couleurs sur les images initiales.

Dans [Sinha 06], les auteurs implementent deux algorithmes sur GPU. Le premier est l’algorithme SIFT(Scale Invariant Feature Transform) qui extrait des points qui restent invariants, selon la translation, larotation, le changement d’echelle et les variations photometriques, dans les images (voir figure 3.8). Ledeuxieme est l’algorithme KLT qui suit des points dans un flux d’images (voir figure 3.9).

Francis Kelly et Anil Kokaram [Kelly 04] utilisent la mise en correspondance par correlation pour faireune interpolation d’image afin d’estimer le mouvement. Pour cela, ils utilisent la mesure SAD ainsi qu’uneminimisation de la fonction DFD (Displaced Frame Difference) pour trouver le vecteur qui represente lemouvement.

James Fung [Fung 05a] propose une implementation du suivi d’une main sur GPU. Le GPU est utilisepour l’application de filtres de convolution et pour le calcul des moments sur les images.


Fig. 3.8 – SIFT sur GPU (extrait de [Sinha 06]).

Fig. 3.9 – KLT sur GPU (extrait de [Sinha 06]).


3.3.9 Tableau recapitulatif

Categorie Technique utilisee Code Reference

Carte de disparites Image des gradients Non precise [Gong 05a]Carte de profondeur Propagation de croyance HLSL [Brunton 06]

Non precise [Yang 06]Correlation GLSL [Zach 04]

Non precise [Yang 03][Yang 04a]

Cg [Woetzel 04]Non precise [Jonsson 03]

ORDP HLSL [Gong 05b]Plans glissants Non precise [Yang 02]

[Cornelis 05]Plans glissants Non precise [Geys 04a]Coupures de graphes

Reconstruction Maillage Cg [Mairal 05b]3D a partir GLSL [Zach 03]d’images Estimation de la profondeur : GLSL [Yang 04b]

correlationShape measurement Non precise [Labatut 05]

[Labatut 06]2+1 phase-shifting Cg [Zhang 06]

Mosaıque d’images VideoOrbits GLSL [Fung 02]Cg [Fung 05a]Non precise [Fung 04a]

Transformation image Distorsion radiale Cg [Fung 05a]Correction perspective Cg [Johnson 06]photometrique, distortion

Segmentation d’image Coupe normalisee Non precise [Kider 05]Methode de Mester Non precise [Griesser 05]Plans glissants, coupures de graphes Non precise [Geys 04b]

Detection de contour Transformation de Fourier Cg [Bruyns 03]Detecteur de Canny Cg [Fung 05a]Transformee de Hough Openvidia [Fung 05b]Detecteur de Canny Non precise [Strzodka 03]Transformation de Hough

Reconnaissances d’objets Espace propre Non precise [Fung 04b]

Analyse du mouvement Flot optique Non precise [Strzodka 04]et suivi d’objet KLT, SIFT Cg [Sinha 06]

Mise en correspondance Non precise [Kelly 04]Convolution, moments Cg [Fung 05a]

Tab. 3.2 – Utilisation de la carte graphique en vision par ordinateur.


Le tableau 3.2 donne un recapitulatif de l’utilisation des cartes graphiques en vision par ordinateur.De nombreux travaux ont ete realises en vision par ordinateur utilisant le GPU. Cela montre bien quel’utilisation du GPU est un atout pour la mise en œuvre de diverses techniques pour la vision parordinateur.

Chapitre 4

Mise en correspondance sur GPU

Dans ce chapitre, nous presentons une strategie d’implementation d’une methode de mise en cor-respondance stereoscopique sur GPU. Nous utiliserons une mise en correspondance stereoscopique parcorrelation [Chambon 05].

4.1 Mise en correspondance par correlation

4.1.1 Introduction

La mise en correspondance stereoscopique est une operation qui s’applique a sur un couple d’image :une image de gauche et une image de droite. Il s’agit de trouver le correspondant d’un pixel de l’imagede gauche dans l’image de droite. La recherche du correspondant dans l’image de droite se fait dans unezone de recherche (region of interest) (voir figure 4.1) .

Correspondant

Zone de

Pixel droitPixel gauche

Image gauche Image droite

Recherche

Fig. 4.1 – Mise en correspondance par correlation avec une zone de recherche.

Pour estimer la ressemblance de deux pixels, issus de deux images images, ont utilise une mesure decorrelation. Cette mesure de correlation prend en compte le voisinage des pixels (fenetre de correlation)et permet d’evaluer leur ressemblance.

37

38 Chapitre 4. Mise en correspondance sur GPU

Pour mettre les pixels de deux images stereoscopiques en correspondance, on peut appliquer l’algo-rithme general 1.

Pour chaque pixel de l’image de gauche pi,jg faire

1. Construire l’ensemble Eg des pixels voisins de pi,jg

2. Pour chaque pixel de l’image de droite pl,kd et de la zone de recherche faire

2.1 Construire l’ensemble Ed des voisins de pi,jg

2.2 Effectuer la mesure de correlation des deux ensemblesEg et Ed

3. Choisir le pixel de l’image de droite qui donne le meilleur score de correlation

Algorithme 1 – Mise en correspondance par correlation.

4.1.2 Mesure de correlation

La mesure de correlation permet donc d’evaluer la ressemblance de deux ensembles de pixels. Il existeplusieurs familles de mesures [Chambon 05]. Nous utiliserons la famille des mesures de correlation croisee.

4.1.2.1 Notations et operateurs de base

Nous utiliserons les notations suivantes :– la taille des fenetres de correlation est note Nf . L’ensemble Eg (respectivement Ed) est stocke dans

le vecteur fg (respectivement fd). Les composantes de ces vecteurs sont des entiers, compris entre 0 et255 pour exprimer un niveau de gris, ou un vecteur a trois dimensions pour exprimer la couleur dansl’espace RVB (Rouge Vert Bleu). Chaque composante de ce vecteur couleur est un entier comprisentre 0 et 255. On a donc :– pour une image en niveau de gris :

fl = (... fkl ...)T

ou fkl est l’element k du vecteur fl et l designe indifferemment g ou d ;

– pour une image en couleur :fl = (... ck

l ...)T

ou ckl = (rk

l , vkl , bk

l )T est la couleur RVB du pixel k dans fl.

Nous utiliserons les operateurs suivants :– les normes LP avec P ∈ N

∗ :– pour une image en niveau de gris :

‖fl‖P =

Nf−1∑

k=0

|fkl |

P

1/P

;

– pour une image couleur :

‖fl‖P =

Nf−1∑

k=0

‖ckl ‖

PP

1/P

avec ‖ckl ‖

PP = (rk

l )P + (vkl )P + (bk

l )P .

Nous noterons ‖fl‖= ‖fl‖2;

4.1. Mise en correspondance par correlation 39

– le produit scalaire :– pour une image en niveau de gris :

fg.fd =

Nf−1∑

k=0

fkg fk

d ;

– pour une image couleur :

fg.fd =

Nf−1∑

k=0

rkgrk

d + vkgvk

d + bkgb

kd;

– le vecteur des moyennes :– pour une image en niveau de gris :

fg = (moy(fg) . . . moy(fg)︸︷︷︸

Nf colonnes

)T

ou

moy(fg) =1

Nf

Nf−1∑

k=0

fkl ;

– pour une image en couleur :

fg =1

Nf( 1 . . . 1

︸︷︷︸

Nf colonnes

)T

Nf−1∑

k=0

rkl

Nf−1∑

k=0

vkl

Nf−1∑

k=0

bkl

4.1.2.2 Caracteristiques des mesures

Pour chaque mesure, nous avons les caracteristiques suivantes :– l’intervalle de variation des mesures ;– les invariances par rapport aux changements de luminosite. Nous considerons trois types d’inva-

riance :– invariance de type gain, notee G : Mes(afg,bfd) = Mes(fg,fd) avec a, b ∈ R

∗ ;– invariance de type biais, notee B : Mes(a + fg,b + fd)=Mes(fg,fd) avec a, b ∈ R

∗ ;– invariance de type gain et biais, notee GB : Mes(afg+b,cfd+d) = Mes(fg,fd) avec avec a, b, c, d ∈ R

∗.

4.1.2.3 Mesures de correlation croisee

Les mesures de correlation croisee, notee CC (Cross-Correlation), sont les suivantes :– la mesure de correlation croisee normalisee, notee NCC (Normalized Cross-Correlation) :

NCC(fg,fd) =fg.fd

‖fg‖‖fd‖.

Les valeurs de cette mesure appartiennent a l’intervalle [0 ;1]. Cette mesure donne 1 quand les deuxensembles sont identiques. Elle possede une invariance de type gain.

– la mesure de correlation croisee centree normalisee, notee ZNCC (Zero mean Normalized Cross-

Correlation) :

ZNCC(fg,fd) =(fg − fg).(fd − fd)

‖fg − fg‖‖fd − fd‖.

Les valeurs de cette mesure appartiennent a l’intervalle [-1 ;1]. Cette mesure donne 1 quand les deuxensembles sont identiques. Elle possede une invariance de type gain et biais.


– la mesure de Moravec, notee MOR :

MOR(fg,fd) =2(fg − fg).(fd − fd)

‖fg − fg‖2+‖fd − fd‖2

Les valeurs de cette mesure appartiennent a l’intervalle [-1 ;1]. Cette mesure donne 1 quand les deuxensembles sont identiques. Elle possede une invariance de type biais.

Le tableau (voir table 4.1) resume les mesures evoquee ci-dessus.

Nom Notation Definition Intervalle Type

Correlation croisee normalisee NCCfg .fd

‖fg‖‖fd‖[0 ;1] G

Correlation croisee centree normalisee ZNCC(fg−fg).(fd−fd)

‖fg−fg‖‖fd−fd‖[-1 ;1] GB

Moravec MOR2(fg−fg).(fd−fd)

‖fg−fg‖2+‖fd−fd‖2[-1 ;1] B

Tab. 4.1 – Mesures de correlation croisee.

4.2 Mise en correspondance sur GPU en utilisant le langage GLSL

Dans cette partie nous decrivons l’implementation d’une mise en correspondance sur GPU en utilisantle langage GLSL [Rost 04].

4.2.1 Quelques indications sur le langage GLSL

4.2.1.1 Types de donnees

Le langage GLSL fournit plusieurs types de donnees. Il offre trois types de bases qui sont : les flottants(float), les entiers (int) et les booleens (bool). Associe a ces types, GLSL propose le type vecteur avecdeux, trois et quatre elements de type flottant, entier ou booleen : vec2, vec3, vec4 pour des vecteurs detype flottant ; ivec2, ivec3, ivec4 pour des vecteurs de type entier ; bvec2, bvec3, bvec4 pour des vecteursde type booleen. Les elements des vecteurs sont accessibles de la maniere presentee dans le tableau 4.2.Il est possible d’acceder directement a plusieurs elements d’un vecteur. Par exemple, soit un vecteurdefini de la maniere suivante : vec4 V1. On peut ecrire : vec2 V2=V1.gb. L’initialisation d’un vecteur sefait, par exemple, de la maniere suivante : vec4 V1= vec4(0.0), vec3 V2= vec3(0.0,1.0,2.0). On obtientV1 = (0.0 0.0 0.0 0.0)T et V2 = (0.0 0.1 2.0)T .

Type vec2 vect vec3 vect vec4 vect

Accesseurs vect.x vect.r vect.s vect.x vect.r vect.s vect.x vect.r vect.svect.y vect.g vect.t vect.y vect.g vect.t vect.y vect.g vect.t

vect.z vect.b vect.p vect.z vect.b vect.pvect.w vect.a vect.q

Tab. 4.2 – Types vecteurs en GLSL et leurs accesseurs.

Le type matrice est lui aussi definie. Les elements de ce type matrice sont des flottants. Les dimensionspossibles des matrices sont de 2 × 2 (mat2) , 3 × 3 (mat3) et 4 × 4 (mat4). Soit Mat une matrice detype mat4, l’ecriture Mat[1][1] permet de recuperer l’element situe a la deuxieme ligne et a la deuxiemecolonne. Si on ecrit Mat[2], on recupere la troisieme colonne (type vec4).

4.2. Mise en correspondance sur GPU en utilisant le langage GLSL 41

4.2.1.2 Fonctions GLSL presdefinies

Le langage GLSL fournit de nombreuses fonctions trigonometriques, exponentielles, geometriques,matricielles ,etc. (voir tableau 4.3). La liste presentee ici n’est pas exhaustive. Certaines de ces fonctionssont cablees dans la carte graphique et leur utilisation peut alors faire diminuer les temps de calcul.

Type Syntaxe Description

Trigonometrique float sin(float radians) Calcule le sinus d’un anglevec{i} sin(vec{i} x) exprime en radians.float cos(float radians) Calcule le cosinus d’un anglevec{i}cos(vec{i} x) exprime en radians.float tan(float radians) Calcule la tangente d’un anglevec{i} tan(vec{i} x) exprime en radians.

Exponentielle float pow(float x, float y) Calcule xy.vec{i} pow(vec{i} x,vec{i} y)float exp(float x) Calcule ex.vec{i} exp(vec{i} x)float log(float x) Calcule log(x) avec x > 0.vec{i} log(vec{i} x)float sqrt(float x) Calcule la racine carree de x,vec{i} sqrt(vec{i} x) avec x ≥ 0.float inversesqrt(float x) Calcule l’inverse de lavec{i} inversesqrt(vec{i} x) racine carre de x, avec x > 0.

Geometrique float length(float x) Calcule la norme euclidienne :vec{i} length(vec{i} x) sqrt(x[0]x[0] + x[1]x[1]...).float distance(float x, float y) Calcule la distance euclidienne :vec{i} distance(vec{i} x, float y) length(x − y).float dot(float x, float y) Calcule le produit scalaire :vec{i} dot(vec{i} x, float y) (x[0]y[0] + x[1]y[1]...).vec3 cross(vec3 x, vec3 y) Calcule le produit vectoriel.float normalize(float x) Rend x unitaire.vec{i} normalize(vec{i} x)

Matricielle mat{i} matrixCompMult(mat{i} X, mat{i} Y ) Calcule le produit matriciel.

Autres float abs(float x) Calcule la valeur absolu.vec{i} abs(vec{i} x)float min(float x,float y) Calcule le minimumvec{i} min(vec{i} x,vec{i} y) entre x et y.vec{i} min(vect{i} x, float y)float max(float x,float y) Calcule le maximumvec{i} max(vec{i} x,vec{i} y) entre x et y.vec{i} max(vect{i} x, float y)vec{i} mod(vect{i} x, vec{i} y) Calcule le modulo.

Tab. 4.3 – Fonctions GLSL predefinies. La notation vec{i} a pour signification : vec2, vec3 ou vec4. Dememe, mat{i} signifie mat2, mat3 ou mat4.


4.2.1.3 Textures et les Couleurs en GLSL

Les textures sont representees dans l’espace [0 ;1]×[0 ;1] (voir figure 4.2).

0 1

0

1h

lImage Texture

0

0

Fig. 4.2 – Texture en GLSL : h et l representent la hauteur et la largeur de l’image en pixels.

Si le vecteur deplacement d’un pixel a un pixel voisin, dans une image, est egal a (1, 1)T . Dans unetexture ce meme deplacement sera egal a ( 1

l ,1h)T .

Une composante couleur, en GLSL, est codee sur l’intervalle [0 ;1].

4.2.2 Algorithme de mise en correspondance avec GLSL

Ecrire un traitement en GLSL peut se resumer a ecrire trois fichiers : vertex.ver, fragment.fra etmain.c.

Le fichier main.c contient le code necessaire pour realiser l’algorithme 2.

1. Initialisation avec GLUT1.1 Initialisation du contexte OpenGL de la fenetre d’affichage1.2 Attachement des fonctions de rendu, de controle des touches, etc.

2. Initialisation des extensions OpenGL avec GLEW3. Creation des textures associees aux images a mettre en correspondance4. Initialisation des shaders

Algorithme 2 – Mise en correspondance avec GLSL : algorithme pour le fichier main.c.

GLUT (OpenGL Utility Toolkit) est une bibliotheque qui permet de gerer des fenetres OpenGL etl’interaction avec le systeme (clavier, souris, etc.). GLEW (OpenGL Extension Wrangler Library) est unebibliotheque qui permet de gerer les extensions OpenGL. Pour afficher une texture dans une fenetre, ontrace un quadrilatere de la dimension de l’image sur lequel on applique la texture de l’image.

Le fichier vertex.ver contient le code qui permet d’effectuer un traitement sur les sommets de lascene. Dans notre cas, nous ne realisons aucun traitement.

Le fichier fragment.ver contient le code qui realise le traitement a effectuer sur chaque element amettre en correspondance suivant l’algorithme 3. Ce code permet de donner la disparite entre les deux


correspondants. Nous utilisons donc les methodes : Read Back, Copy to Texture, Render to Texture. Lesimages sont des textures, le traitement a effectuer est ecrit dans un fragment shader et le resultat estaffiche soit dans une texture, soit dans le frame buffer.

1. Pour chaque element de la zone de recherche faire1.1 Calculer le score de correlation1.2 Si le score est le meilleure, garder le correspondant associe

2. Calculer de la disparite3. Afficher de la disparite

Algorithme 3 – Mise en correspondance avec GLSL : algorithme pour le fichier fragment.frag.

float mesuremax = 0.0 ;vec2 correspondant= vec2(0.0) ;1. Pour tous les pixels de la zone recherche :

Pour i de 0 a tailleR faireCalculer offsetRvec3 mesure = vec3(0.0) ;1.1 Pour chaque pixel de la fenetre de correlation :

Pour j de 0 a tailleC faireCalculer offsetC1.1.1 Recuperer les elements pour le calcul du score :

vec3 tempg = textureImageGauche(coord+offsetC) ;vec3 tempd = textureImageDroite(coord+offsetC+offsetR) ;

1.1.2 Calculer le score :score = score+vec3(dot(tempg,tempd),

dot(tempg,tempg),dot(tempd,tempd)) ;

1.2 Calculer le score finale :float scoreFinal = score.x∗inversesqrt(score.y,score.z) ;

1.3 Selectionner le meilleur correspondant :Si (max(scoreMax, scoreFinal)) > scoremax alors

scoreMax = scoreFinal ;correspondant = coord+offsetR ;

2. Calculer la disparite :float disparite = distance(coord,correspondant) ;

3. Afficher la disparite

Algorithme 4 – Mise en correspondance avec GLSL : algorithme pour la mesure NCC.


On definit :– tailleC : taille de la fenetre de correlation ;– tailleR : taille de la zone de recherche ;– offsetC : valeur permettant l’acces aux elements des textures dans la fenetre de correlation ;– offsetR : valeur permettant l’acces aux elements des textures dans la zone de recherche ;– coord : coordonnees de l’element a mettre en correspondance.Pour la realisation d’une mise en correspondance avec la mesure NCC, on utilise l’algorithme 4. Les

variables utilisees sont :– scoreMax : permet de stocker le meilleur score ;– correspondant : permet de stocker le meilleur correspondant associe au meilluer score ;– score : vecteur pour le calcul du score, score = (fg.fd ‖fg‖ ‖fd‖)

T ;– tempg et tempd : stockent la valeur couleur d’un pixel de l’image de gauche et de l’image de droite ;– disparite : valeur de la disparite entre le pixel de gauche et son correspondand de l’image de droite.De meme, pour la realisation d’une mise en correspondance avec la mesure ZNCC, on utilise l’algo-

rithme 5. Pour calculer le score de cette mesure, il faut calculer la moyenne de la valeur des pixels dans lafenetre de correlation, d’ou les variables moyenneGauche et moyenneDroite. Le vecteur score correspondau vecteur ((fg − fg).(fd − fd) ‖fg − fg‖ ‖fd − fd‖)

T .Pour l’utilisation de la mesure de Moravec, l’algorithme est le meme que pour la mesure ZNCC sauf

que le calcul final du score est different. Au lieu de : float scoreFinal =score.x∗inversesqrt(score.y,score.z),on a : float scoreFinal = 2.0∗score.x/(score.y+score.z).


float mesuremax = 0.0 ;vec2 correspondant= vec2(0.0) ;1. Pour tous les pixels de la zone recherche :

Pour i de 0 a tailleR faireCalculer de offsetRvec3 mesure = vec3(0.0) ;1.1 Calculer les moyennes :

vec3 moyenneGauche = vec3(0.0) ;vec3 moyenneDroite = vec3(0.0) ;Pour chaque pixel de la fenetre de correlation :

Pour k de 0 a tailleC faireCalculer offsetCmoyenneGauche + = textureImageGauche(coord+offsetC) ;moyenneDroite + = textureImageDroite(coord+offsetC+offsetR) ;

moyenneGauche = moyenneGauche/tailleC ;moyenneDroite = moyenneDroite/tailleC ;

1.2 Pour chaque pixel de la zone de correlation :Pour j de 0 a tailleC faire

Calculer offsetC1.2.1 Recuperer les elements pour le calcul du score :

vec3 tempg = textureImageGauche(coord+offsetC)-moyenneGauche ;vec3 tempd = textureImageDroite(coord+offsetC+offsetR)

-moyenneDroite ;1.2.2 Calculer le score :

score + = vec3(dot(tempg,tempd),dot(tempg,tempg),dot(tempd,tempd)) ;

1.4 Calculer la mesure finale :float scoreFinal =score.x∗inversesqrt(score.y,score.z) ;

1.3 Selectionner le meilleur correspondant :Si (max(scoreMax,scoreFinal)) > scoreMax alors

scoreMax = scoreFinal ;correspondant = coord+offsetR ;

2. Calculer la disparite :float disparite = distance(coord,correspondant) ;

3. Afficher la disparite

Algorithme 5 – Mise en correspondance avec GLSL : algorithme pour la mesure ZNCC.


4.2.3 Comparaison CPU/GPU en termes de performance

Nous avons mesure les temps mis pour realiser un mise en correspondance stereoscopique en utilisantle CPU et le GPU. La carte graphique utilisee est une NVIDIA GeForce 8800 GTX et le CPU est unAMD 64 X2 4800+. Les tests sont realises sur un couple d’images couleur de dimension 384×288. Lestailles des fenetres de correlation sont : 5×5, 7×7, 9×9 et 11×11. Les tailles des zones de recherche sont :11×11, 15×15 et 21×21. Les resultats sont consignes dans le tableau 4.4.

Fenetre de CPU GPU Zone decorrelation 5×5 7×7 9×9 11×11 5×5 7×7 9×9 11×11 recherche

17.95 33.47 53.9 77.5 0.01 0.01 0.01 0.01 11×11NCC 31.41 57.54 92.87 133.10 0.01 0.01 0.01 0.01 15×15

55.58 103.3 166.11 239.05 0.01 0.01 0.01 0.02 21×21

30.06 56.09 89.09 129.86 0.02 0.02 0.02 0.02 11×11ZNCC 52.58 98.76 157.92 208.00 0.02 0.02 0.02 0.03 15×15

94.43 176.68 284.02 408.8 0.02 0.02 0.02 0.03 21×21

29.51 55.47 89.26 129.13 0.02 0.02 0.02 0.02 11×11Moravec 51.86 97.44 156.74 226.27 0.02 0.02 0.02 0.02 15×15

93.33 175.2 281.2 406.16 0.02 0.02 0.02 0.02 21×21

Tab. 4.4 – Temps de calcul en secondes pour une mise en correspondance stereoscopique.

L’algorithme implemente pour le CPU differe de celui pour le GPU (voir algorithme 6). Les resultatsobtenus pour le CPU sont mediocres. L’algorithme peut-etre optimise en utilisant le fait que les proces-seurs possedent plusieurs cœurs. Toutefois, les temps de calculs effectues sur le GPU sont extremementrapides.

1. Construire un tableau TabGauche contenant tout les pixels dela fenetre de correlation de l’image gauche

2. Pour chaque pixel de la zone de recherche faire :2.1 Construire un tableau TabDroite contenant tout les pixels de

la fenetre de correlation de l’image droite2.2 Calculer les scores en utilisant TabDroite et TabGauche2.3 Selectionner le meilleur correspondant2.4 Calculer la disparite

3. Afficher les diparites

Algorithme 6 – Mise en correspondance stereoroscopique avec le CPU.


Les cartes graphiques NVIDA GeForce 8 ont une capacite de calcul largement superieur aux autrescartes graphiques que l’on trouve sur le marche informatique (voir 4.3). Les temps de calculs seraientsans doute plus importants, mais resteraient quand meme meilleur que ceux du CPU.

Fig. 4.3 – Comparatif des cartes graphiques presentent sur le marche (extrait de : www.tt-hardware.com).L’appelation GX2 correspond a l’utilisation de deux cartes graphiques en meme temps. La carte graphiquede reference est la GeForce 7900 GT.

Chapitre 5

Conclusion

Dans ce rapport, nous avons donc presente la programmation GPU, un etat de l’art sur les methodesde vision par ordinateur utilisant le GPU, ainsi qu’une utilisation du langage GLSL pour la mise encorrespondance stereoscopique de pixels par correlation. L’utilisation du GPU permet d’effectuer untraitement sur un ensemble de donnees plus rapidement qu’avec un CPU. Dans le domaine de la visionpar ordinateur, sont donc concernees de nombreuses applications comme l’imagerie medicale, la visionpour la robotique etc. Mais, plus generalement, de nombreux autres domaines sont concernes [GPGPU 07]tels que : les bases de donnees [Govindaraju 04], l’audio [Whalen 04], etc.

Fig. 5.1 – RapidMind : plateforme de developpement pour CPU, GPU et Cell (extrait de [McCool 03b]).

La programmation GPGPU est donc propice a toutes les applications qui demande un traitement dedonnees massivement paralleles. Aujourd’hui, la programmation GPGPU n’est pas une chose aisee, ilest difficile de « debugger »un programme realise avec ce type de programmation. La programmationGPGPU va considerablement se developper au cours des annees qui vont arriver. On voit l’apparition

49

50 Chapitre 5. Conclusion

d’environnement de developpement permettant l’utilisation des CPU et des GPU. Par exemple, Rapid-Mind [Analytics 07, McCool 03b, RapidMind 07] permet l’exploitation de CPU multicœurs, des proces-seurs Cell et des GPU (voir figure 5.1). Il en est de meme pour Neoptica [Neoptica 07a, Neoptica 07b]et PeakStream [PeakSTream 07a, PeakSTream 07b] qui permettent au developpeur d’utiliser les CPUmulticœurs et les GPU. Le constructeur ATI/AMD annonce, pour les annees a venir, un projet qui apour objectif de creer un processeur appele MPU Media Processor Unit comportant un CPU et un GPU.

Le GPU va donc etre utilise de facon courante et pour des taches autres que des applications « gra-phiques ».

Bibliographie

[Analytics 07] Clabby Analytics. Parallelizing Applications for Multi-Core Processors : The Ra-pidMind Solution. Rapport Technique, RapidMind, mai 2007.

[Ananth 07a] B. Ananth. Site pour Brahma. 2007.brahma.ananthonline.net.

[Ananth 07b] B. Ananth. Tutorial GLSL. 2007.www.lighthouse3d.com/opengl/glsl/.

[Apple 07] Apple. Site pour Core image. 2007.www.apple.com/fr/macosx/features/coreimage/.

[ATI 07] ATI. Site pour RenderMonkey. 2007.ati.amd.com/developer/rendermonkey/index.html.

[Bleiweiss 03] A. Bleiweiss et A. Preetham. Ashli : Advanced Shading Language Interface. Rap-port Technique, ATI Research, 2003.

[Blythe 06] D. Blythe. The Direct3D 10 system. ACM Transactions on Graphics, 25(3) :724–734,2006.

[Bolz 03] J. Bolz, I. Farmer, E. Grinspun et P. Schroder. Sparse matrix solvers on the

GPU : conjugate gradients and multigrid. ACM Transactions on Graphics, 22(3) :917–924, 2003.

[Brumme 03] S. Brumme. The OpenGL Shading Language. 2003. Cours, Hasso Plattern Institut,Universite de Postdam, Allemagne.

[Brunton 06] A. Brunton, C. Shu et G. Roth. Belief Propagation on the GPU for Stereo Vi-

sion. Dans The 3rd Canadian Conference on Computer and Robot Vision, page 76,Washington, DC, USA, 2006. IEEE Computer Society.

[Bruyns 03] C. Bruyns et B. Feldman. Image Processing on the GPU : a Canonical Example.Rapport Technique, University of California Berkeley, 2003.

[Buck 04] I. Buck, T. Foley, D. Horn, J. Sugerman, K. Fatahalian, M. Houston etP. Hanrahan. Brook for GPUs : stream computing on graphics hardware. ACM

Transactions on Graphics, 23(3) :777–786, 2004.

[Chambon 05] S. Chambon. Mise en correspondance stereoscopique d’images couleur en presence

d’occultations. These de doctorat, Universite Paul Sabatier, France, decembre 2005.

[Chiara 04] R. De Chiara, U. Erra et V. Scarano. Flog : graphics hardware accelerated imageprocessing library. Rapport Technique, Universite de Salerno, 2004.

[Cook 84] R. L. Cook. Shade trees. Dans The 11th annual conference on Computer graphicsand interactive techniques, pages 223–231, New York, NY, USA, 1984. ACM Press.

51

52 Bibliographie

[Cornelis 05] N. Cornelis et L. Van Gool. Real-Time Connectivity Constrained Depth Map Com-

putation Using Programmable Graphics Hardware. Dans IEEE Computer SocietyConference on Computer Vision and Pattern Recognition, volume 1, pages 1099–1104,Washington, DC, USA, 2005. IEEE Computer Society.

[Dekker 72] T. J. Dekker. A floating technique for extending the available precision. Numerische

Mathematik, 18(3) :224–242, 1972.

[Farrugia 06] J. Farrugia, P. Horain, E. Guehenneux et Y. Alusse. GPUCV : A framework

for image processing acceleration with graphics processors. Dans CDROM de IEEEInternational Conference on Multimedia, juillet 2006.

[Fatahalian 04] K. Fatahalian, J. Sugerman et P. Hanrahan. Understanding the efficiency of

GPU algorithms for matrix-matrix multiplication. Dans ACM SIGGRAPH/EURO-GRAPHICS conference on graphics hardware, pages 133–137, New York, NY, USA,2004. ACM Press.

[Fernando 03] R. Fernando et M. J. Kilgard. The Cg Tutorial : The Definitive Guide to Pro-grammable Real-Time Graphics. Addison-Wesley Professional, 2003.

[Fritz 04] N. Fritz, P. Lucas et P. Slusallek. CGiS, a new Language for Data-Parallel

GPU Programming. Dans The 9th International Workshop Vision, Modeling, andVisualization, pages 241–248, 2004.

[Fung 02] J. Fung, F. Tang et S. Mann. Mediated Reality Using Computer Graphics Hardware

for Computer Vision. Dans The 6th IEEE International Symposium on WearableComputers, page 83, Washington, DC, USA, 2002. IEEE Computer Society.

[Fung 04a] J. Fung et S. Mann. Computer vision signal processing on graphics processing units.Dans IEEE International Conference on Acoustics, Speech, and Signal Processing,pages 83–89. IEEE Computer Society, 2004.

[Fung 04b] J. Fung et S. Mann. Using Multiple Graphics Cards as a General Purpose Paral-

lel Computer : Applications to Computer Vision. Dans International Conference onPattern Recognition, pages 805–808, Washington, DC, USA, 2004. IEEE ComputerSociety.

[Fung 05a] J. Fung. Computer vision on the GPU in GPU gems 2 : Programming Techniques forHigh-performance Graphics and General Purpose Computation, Chapitre 40, pages651–667. Addison-Wesley, 2005.

[Fung 05b] J. Fung et S. Mann. OpenVIDIA : parallel GPU computer vision. Dans The 13thannual ACM international conference on Multimedia, pages 849–852, New York, NY,USA, 2005. ACM Press.

[Galoppo 05] N. Galoppo, Naga K. Govindaraju, M. Henson et Di. Manocha. LU -GPU :

Efficient Algorithms for Solving Dense Linear Systems on Graphics Hardware. DansThe 2005 ACM/IEEE Super computing conference, page 3, Washington, DC, USA,2005. IEEE Computer Society.

[Geys 04a] I. Geys, T. P. Koninckx et L. VAN Gool. Fast Interpolated Cameras by Combining

a GPU based Plane Sweep with a Max-Flow Regularisation Algorithm. Dans The3D Data Processing, Visualization, and Transmission, 2nd International Symposium,pages 534–541, Washington, DC, USA, 2004. IEEE Computer Society.

[Geys 04b] I. Geys et L. J. Van Gool. Extended view interpolation by parallel use of the GPU

and the CPU. Dans Proceedings of the SPIE, volume 5665, pages 96–107, decembre2004.

Bibliographie 53

[Gong 05a] M. Gong et R. Yang. Image-Gradient-Guided Real-Time Stereo on Graphics Hard-

ware. Dans The Fifth International Conference on 3-D Digital Imaging and Modeling,pages 548–555, Washington, DC, USA, 2005. IEEE Computer Society.

[Gong 05b] M. Gong et Y. Yang. Near Real-Time Reliable Stereo Matching Using Programmable

Graphics Hardware. Dans IEEE Computer Society Conference on Computer Visionand Pattern Recognition, volume 1, pages 924–931, Washington, DC, USA, 2005.

[Goodnight 03] N. Goodnight, C. Woolley, G. Lewin, D. Luebke et G. Humphreys. A multigridsolver for boundary value problems using programmable graphics hardware. RapportTechnique, University of Virginia, 2003.

[Govindaraju 04] N. K. Govindaraju, B. Lloyd, W. Wang, M. Lin et D. Manocha. Fast computation

of database operations using graphics processors. Dans The 2004 ACM SIGMODinternational conference on Management of data, pages 215–226, New York, NY, USA,2004. ACM Press.

[GPGPU 07] GPGPU. Site pour la programmation GPGPU. 2007. www.gpgpu.org.

[Gracca 06] G. Da Gracca et D. Defour. Implementation of float-float operators on graphicshardware. Rapport Technique, Universite de Perpignan, 2006.

[Griesser 05] A. Griesser. Real-Time, GPU-based, Foreground-Backgroung Segmentation. Rap-port Technique, Computer Vision Lab, Swiss Federal Institute of Technology, Zurich,2005.

[Hagen 06] T. R. Hagen, K. Lie et J. R. Natvig. Solving the Euler Equations on Graphics

Processing Units. Dans Computational Science – ICCS 2006, volume 3994 de LNCS,pages 220–227. Springer, 2006.

[Hall 03] J. Hall, N. Carr et J. Hart. Cache and bandwidth aware matrix multiplication onthe GPU. Rapport Technique, University of Illinois, 2003.

[Hoff III 99] K. E. Hoff III, J. Keyser, M. Lin, D. Manocha et T. Culver. Fast Computation of

Generalized Voronoi Diagrams Using Graphics Hardware. Computer Graphics, 33 :277–286, 1999.

[Hopf 99a] M. Hopf et T. Ertl. Accelerating 3D Convolution using Graphics Hardware. DansProc. Visualization 1999, pages 471–474. IEEE, 1999.

[Hopf 99b] M. Hopf et T. Ertl. Hardware-Based Wavelet Transformations. Dans Workshop ofVision, Modelling, and Visualization, pages 317–328, 1999.

[Hopf 00] M. Hopf et T. Ertl. Accelerating Morphological Analysis with Graphics Hardware.Dans Workshop on Vision, Modelling, and Visualization, pages 337–345, 2000.

[Johnson 06] T. Johnson, F. Gyarfas, T. Skarbez, P. Quirk, H. Towles et H. Fuchs. Multi-

Projector Image Correction on the GPU. Dans Workshop on Edge Computing UsingNew Commodity Architectures, mai 2006.

[Jonsson 03] K. Jonsson. Shader-based Stereo Matching with local Algorithms. These de doctorat,Universite de Lund, Suede, septembre 2003.

[Kelly 04] F. Kelly et A. Kokaram. Fast image interpolation for motion estimation using

graphics hardware. Dans N. Kehtarnavaz et P. A. Laplante, editeurs, Real-TimeImaging VIII. Proceedings of the SPIE, volume 5297, pages 184–194, mai 2004.

[Kider 05] J. Kider et L. Zhao. Fast Normalized Cut for Image Segmentation on the GPU.Rapport Technique, Universite of Pennsylvanie, 2005.

54 Bibliographie

[Knuth 98] D. Knuth. The Art of Computer Programming, Seminumerical Algorithms, volume 2.Addison-Wesley Professional, 1998.

[Kruger 03] J. Kruger et R. Westermann. Linear algebra operators for GPU implementation

of numerical algorithms. Dans ACM SIGGRAPH 2003 Papers, pages 908–916, NewYork, NY, USA, 2003. ACM Press.

[Labatut 05] P. Labatut, R. Keriven et J. Pons. A GPU implementation of level set multiviewstereo. Rapport Technique, CERTIS-ENPC, novembre 2005.

[Labatut 06] P. Labatut, R. Keriven et J. Pons. A GPU Implementation of Level Set Multiview

Stereo. Dans Computational Science – ICCS 2006, volume 3994 de LNCS, pages 212–219. Springer, 2006.

[Larsen 01] E. Scott Larsen et D. McAllister. Fast matrix multiplies using graphics hardware.Dans CDROM de The 2001 ACM/IEEE conference on Supercomputing, New York,NY, USA, 2001. ACM Press.

[Lauter 05] C. Q. Lauter. Basic building blocks for a triple-double intermediate format. RapportTechnique, Ecole Normale Superieur de Lyon, 2005.

[Lefohn 06] A. Lefohn, J. M. Kniss, R. Strzodka, S. Sengupta et J. D. Owens. Glift : Generic,

Efficient, Random-Access GPU Data Structures. ACM Transactions on Graphics,25(1) :60–99, janvier 2006.

[Lejdfors 05] C. Lejdfors et L. Ohlsson. PyGPU : A high-level language for high-speed imageprocessing. Rapport Technique, Universite de Lund, Suede, 2005.

[Mairal 05a] J. Mairal, R. Keriven et A. Charior. Fast and efficient dense variational stereo on

GPU. Dans The 3rd International Symposium on 3D Data Processing, Visualizationand Transmission, 2005.

[Mairal 05b] J. Mairal, R. Keriven et A. Charior. A GPU implementation of variational stereo.Rapport Technique, CERTIS-ENPC, mai 2005.

[Mark 01] W. R. Mark. Stanford Real-Time Procedural Shading System. Dans SIGGRAPH 2001Conference Proceedings, pages 159–170, avril 2001.

[Mark 03] W. R. Mark, R. S. Glanville, K. Akeley et M. J. Kilgard. Cg : a system for

programming graphics hardware in a C-like language. ACM Transactions on Graphics,22(3) :896–907, 2003.

[McCool 03a] M. McCool. Introduction to the DirectX 9 High Level Shading Language. RapportTechnique, Microsoft Corporation, juillet 2003.

[McCool 03b] M. McCool, K. Wadleigh, B. Henderson et H. Lin. Performance Evaluation ofGPUs Using the RapidMind Development Platform. Rapport Technique, RapidMindet Hewlett Packard Company, octobre 2003.

[McCool 04a] M. McCool. Shading Language Overview. Rapport Technique, Microsoft Corpora-tion, avril 2004.

[McCool 04b] M. McCool, S. Du Toit, T. Popa, B. Chan et K. Moule. Shader algebra. DansACM SIGGRAPH 2004 Papers, pages 787–795, New York, NY, USA, 2004. ACMPress.

[McCormick 04] P. McCormick, J. Inman, J. P. Ahrens, C. Hansen et G. Roth. Scout : A

Hardware-Accelerated System for Quantitatively Driven Visualization and Analysis.Dans The conference on Visualization, pages 171–178, Washington, DC, USA, 2004.IEEE Computer Society.

Bibliographie 55

[Mester 01] R. Mester, T. Aach et L. Dumbgen. Illumination-invariant change detection using

a statistical colinearity criterion. Dans The 23rd DAGM-Symposium on Pattern Re-cognition, pages 159–170, 2001.

[Mitchell 05] J. L. Mitchell, M. Y. Ansari et E. Hart. Advanced Image Processing with DirectX9 Pixel Shaders, Chapitre 4. Wolfgang Engel, 2005.

[Mitrovıc 03] B. Mitrovıc. Real-time Shading Languages. Rapport Technique, Universite deVienne, 2003.

[Molnar 92] S. Molnar, J. Eyles et J. Poulton. PixelFlow : High-speed rendering using image

composition. Computer Graphics, 26(2) :231–240, 1992.

[Moravanszky 03] A. Moravanszky. Dense Matrix Algebra on the GPU. Rapport Technique, NovodeXAG, 2003.

[Neoptica 07a] Neoptica. Programmable Graphics : The Future of Interactive Rendering. RapportTechnique, Neoptica, mars 2007.

[Neoptica 07b] Neoptica. Site pour Neoptica. 2007. www.neoptica.com/news.html.

[Nocent 07] O. Nocent. Site pour GLOOSE. 2007. leri.univ-reims.fr/˜nocent/gpu.html.

[NVIDIA 07a] NVIDIA. Site de NVIDIA pour Cg. 2007. www.developer.nvidia.com/page-/cg main.html.

[NVIDIA 07b] NVIDIA. Site pour CUDA. 2007. developer.nvidia.com/object/cuda.html.

[Olano 98] M. Olano et A. Lastra. A shading language on graphics hardware : the PixelFlow

shading system. Dans The 25th annual conference on Computer graphics and interac-tive techniques, pages 159–168, New York, NY, USA, 1998. ACM Press.

[OpenVIDIA 07] OpenVIDIA. Site pour OpenVIDIA. 2007. openvidia.sourceforge.net/.

[Owens 05] J. D. Owens, D. Luebke, N. Govindaraju, M. Harris, J. Kruger, A. E. Lefohn

et T. J. Purcell. A Survey of General-Purpose Computation on Graphics Hardware.Dans Eurographics 2005, State of the Art Reports, pages 21–51, 2005.

[PeakSTream 07a] PeakSTream. The PeakSTream PlaTform : High productivity software developmentfor multi-core processors. Rapport Technique, PeakStream, 2007.

[PeakSTream 07b] PeakSTream. Site pour PeakSTream. 2007. www.peakstreaminc.com.

[Pixar 05] Pixar. Specification de RenderMan. novembre 2005. renderman.pixar.com/products/rispec/rispec pdf/RISpec3 2.pdf.

[Pixar 07a] Pixar. Site de Pixar et de RenderMan. 2007. renderman.pixar.com.

[Pixar 07b] Pixar. Site de RenderMan. 2007. www.renderman.org.

[Pons 05] J. Pons, R. Keriven et O. Faugeras. Modelling Dynamic Scenes by Registering

Multi-View Image Sequences. Dans IEEE Computer Society Conference, volume 2,pages 822–827, juin 2005.

[Proudfoot 01] K. Proudfoot, W. R. Mark, S. Tzvetkov et . Hanrahan. A real-time procedural

shading system for programmable graphics hardware. Dans The 28th annual conferenceon Computer graphics and interactive techniques, pages 159–170, New York, NY, USA,2001. ACM Press.

[RapidMind 07] RapidMind. Site pour RapidMind. 2007. www.rapidmind.net.

[Rost 04] R. J. Rost. OpenGL Shading Language. Addison-Wesley Professional, 2004.

[Segal 06] M. Segal et M. Peercy. A performance-oriented data parallel virtual machine forGPUs. Rapport Technique, ATI Technologies, Inc, 2006.

56 Bibliographie

[Sh 07] Sh. Site pour Sh. 2007. libsh.org.

[Sinha 06] S. N. Sinha, J. Frahm, M. Pollefeys et Y. Genc. GPU-based Video FeatureTracking And Matching. Rapport Technique, Universite de North Carolina at ChapelHill, mai 2006.

[Strzodka 03] R. Strzodka, I. Ihrke et M. Magnor. A Graphics Hardware Implementation of

the Generalizes Hough Transform for fast Object Recognition, Scale, and 3D Pose

Detection. Dans 12th International Conference on Image Analysis and Processing,pages 188–193. IEEE Computer Society, 2003.

[Strzodka 04] R. Strzodka et C. Garbe. Real-Time Motion Estimation and Visualization on Gra-

phics Cards. Dans The conference on Visualization 2004, pages 545–552, Washington,DC, USA, 2004. IEEE Computer Society.

[Tarditi 05] D. Tarditi, S. Puri et J. Oglesby. Accelerator : simplified programming of graphicsprocessing units for general-purpose uses via data parallelism. Rapport Technique,Microsoft Research, decembre 2005.

[Whalen 04] S. Whalen. Audio and the Graphics Processing unit. 2004.

[Woetzel 04] J. Woetzel et R. Koch. Real-time multi-stereo depth estimation on GPU with ap-

proximative discontinuity handling. Dans The 1st European Conference on VisualMedia Production, pages 245–254, 2004.

[Yang 02] R. Yang, G. Welch et G. Bishop. Real-Time Consensus-Based Scene Reconstruction

Using Commodity Graphics Hardware. Dans The 10th Pacific Conference on Compu-ter Graphics and Applications, pages 225–225, Washington, DC, USA, 2002. IEEEComputer Society.

[Yang 03] R. Yang et M. Pollefeys. Multi-Resolution Real-Time Stereo Commodity Graphics

Hardware. Dans IEEE Computer Society Conference on Computer Vision and PatternRecognition, volume 1, pages 211–217, 2003.

[Yang 04a] R. Yang, M. Pollefeys et S. Li. Improved Real-Time Stereo on Commodity Graphics

Hardware. Dans The 2004 Conference on Computer Vision and Pattern RecognitionWorkshop (CVPRW’04), volume 3, page 36, Washington, DC, USA, 2004. IEEE Com-puter Society.

[Yang 04b] R. Yang, M. Pollefeys, H. Yang et G. Welch. A Unified Approach to Real-

Time, Multi-Resolution, Multi-Baseline 2D View Synthesis and 3D Depth Estimation.International Journal of Image and Graphics, 4 :1–25, 2004.

[Yang 06] Q. Yang, L. Wang, R. Yang, S. Wang, M. Liao et D. Nister. Real-Time Global

Stereo Matching Using Hierarchical Belief Propagation. Dans The British MachineVision Conference, pages 324–327, 2006.

[Zach 03] C. Zach, A. Klaus, B. Reitinger et K. Karner. Optimized Stereo Reconstruction

Using 3D Graphics Hardware. Workshop of Vision, Modelling, and Visualization, aout2003.

[Zach 04] C. Zach, K. Karner et H. Bischof. Hierarchical Disparity Estimation with Pro-

grammable Graphics Hardware. Dans WSCG’2004 SHORT Communication papersproceedings, pages 275–282, 2004.

[Zhang 06] S. Zhang, D. Royer et S. Yau. GPU-assisted high-resolution, real-time 3-D shape

measurement. Optics Express, 14(20) :9120–9129, 2006.

Index

Equation d’Euler, 24Equation de Poisson, 23Shape reconstruction, 282+1 phase-shifting algorithm, 29

Accelerator, 11Analyse du mouvement, 32

Brahma, 11Brook, 19

Calcul Matriciel, 22Carte de disparites, 26Carte de profondeur, 26Cg, 10CGiS, 11Core Image, 20Correlation, 26, 32, 37CTM, 12CUDA, 12

Detecteur de Canny, 32Detection de contour, 32

Espace propre, 32

Filtrage, 24Flog, 11

GLSL, 9, 40GPGPU, 16

Copy to Texture, 17Copy to VBO, 17G80, 18Read Back, 16Render to VBO, 18

GPUCV, 11Gradient conjugue, 23

HLSL, 9

Image des gradients, 26

KLT, 32

LCP, 23, 24

Mesure de correlation, 38MOR, 40NCC, 39, 44ZNCC, 39, 45

Mise en correspondance, 26, 37, 42Mosaıque d’images, 29Multigrilles, 23Multiplication matricielle, 22

Ondelettes, 25Operations flottantes, 21OpenVidia, 11ORDP, 26

Pipeline graphique, 5–7PixelFlow, 8Plans glissants, 27Propagation de croyance, 26PyGPU, 10

Quartz Composer, 20

Reconnaissance, 32Reconstruction 3D, 28RenderMan, 8RenderMonkey, 10

Scout, 11Segmentation d’image, 31Sh, 19Shade trees, 7SIFT, 32SSL, 9Suivi d’objet, 32Systeme lineaire, 23

Transformee de Hough, 32Transformation d’image, 29

57

58 Index

VideoOrbits, 29Voronoı, 24

utilisation des cartes graphiques pour la vision par ordinateur

Documents