Université Bordeaux 1, Master 1, mention Informatique,2007/2008

INF466 - Projet de Programmation

Mémoire final

Analyse de mouvementhumain 3D à base d’extraction

de squelette géométriqueFabrice Corlouer, Elamine Bellamine, Simon Gabet, Thomas Dumartin

4 Avril 2008

Chargé de TD : Pascal DesbaratsClient : Jean-Sébastien Franco

Résumé

L’analyse du mouvement humain est un sujet complexe de partla variété des situations et l’anatomie du corps de l’individu. En ef-fet, le corps humain est un objet 3D, doté d’articulations comportantplusieurs degrés de liberté, et capable d’effectuer une infinité de mou-vements à vitesse variable. Cette complexité soulève un problème inter-essant en vision par ordinateur qui est de trouver des représentationssimplifiées qui permettent d’analyser et d’interpréter toutes les infor-mations qu’elles contiennent. Il est donc nécessaire d’utiliser un mo-dèle ayant l’avantage de pouvoir contenir de nombreuses informationsconcernant le mouvement, et de conserver les propriétés topologiqueset géométriques de la forme analysée. De cette manière, le modèlede squelette permet de représenter un humain en mouvement com-portant toutes les caractéristiques citées précédemment. Nous avonsimplémenté des techniques intermédiaires qui sont l’extraction de sil-houette, la représentation volumétrique ainsi qu’un amincissement to-pologique, dans le but d’obtenir la représentation finale de notre projetqui est le squelette cinématique. Ces différentes représentations tridi-mensionnelles du mouvement humain sont affichées via une plate-formede visualisation graphique.

mots-clés : squelettisation, capture de mouvement, reconstruction3D, amincissement topologique.

Abstract

The human motion analysis is a complex subject, because of the va-rious situations and the anatomy of the person’s body. Actually, thehuman body is a 3D object, with articulations which have few degreesof freedom, and which be able to do an infinity of moves at variablespeed. That complexity lead us to find simplified techniques of repre-sentations, which allow us to analyze and interpret every informationsthat it contains. It is necessary to use a model which can containsmany informations about the movement and which be able to hang onthe geometricals and topologicals properties of the considerate form.So, the skeletal model afford to represent a human in movement withall the attributes we talk above. In order to obtain the final skeletalmodel, we have made three intermediates techniques, the silhouette ex-traction, the visual hulls, and a thinning algorithm to extract a voxelskeleton. These tridimensionnals representations of human motion aredisplayed by a graphical interface.

keywords : skeletal model, motion capture, 3D rebuild, voxel thin-ning.

2

3

Table des matières

1 Introduction au domaine d’application 91.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2 La capture de mouvement . . . . . . . . . . . . . . . . . . . . 10

1.2.1 La capture mécanique . . . . . . . . . . . . . . . . . . 101.2.2 La capture magnétique . . . . . . . . . . . . . . . . . . 111.2.3 La capture optique à marqueurs . . . . . . . . . . . . . 111.2.4 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . 121.2.5 Les systèmes de capture optique sans marqueurs . . . 12

1.3 La squelettisation . . . . . . . . . . . . . . . . . . . . . . . . . 131.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 131.3.2 Historique . . . . . . . . . . . . . . . . . . . . . . . . . 141.3.3 Définitions et propriétés . . . . . . . . . . . . . . . . . 141.3.4 Algorithme d’amincissement topologique . . . . . . . . 16

1.4 Domaines d’application . . . . . . . . . . . . . . . . . . . . . 17

2 Analyse de l’existant 202.1 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.1.1 Semocap . . . . . . . . . . . . . . . . . . . . . . . . . . 202.1.2 Commentaires . . . . . . . . . . . . . . . . . . . . . . . 22

2.2 Méthodes et algorithmes . . . . . . . . . . . . . . . . . . . . . 222.2.1 Extraction de silhouette . . . . . . . . . . . . . . . . . 222.2.2 Amincissement topologique . . . . . . . . . . . . . . . 23

2.3 Grimage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.4 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3 Introduction au projet 263.1 Buts et priorités . . . . . . . . . . . . . . . . . . . . . . . . . 263.2 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.3 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4 Cahier des charges 304.1 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . 30

4.1.1 Domaine d’action . . . . . . . . . . . . . . . . . . . . . 30

4

4.1.2 Robustesse . . . . . . . . . . . . . . . . . . . . . . . . 314.1.3 Vitesse d’exécution . . . . . . . . . . . . . . . . . . . . 314.1.4 Réalisme du résultat . . . . . . . . . . . . . . . . . . . 314.1.5 Extensibilité . . . . . . . . . . . . . . . . . . . . . . . . 324.1.6 Ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . 324.2.1 Chargement d’images . . . . . . . . . . . . . . . . . . 324.2.2 Pré-traitement des données . . . . . . . . . . . . . . . 334.2.3 Visualisations . . . . . . . . . . . . . . . . . . . . . . . 334.2.4 Changement de vue de la caméra . . . . . . . . . . . . 334.2.5 Modification des paramètres . . . . . . . . . . . . . . . 344.2.6 Sauvegarde du squelette . . . . . . . . . . . . . . . . . 34

4.3 Moyens logiciels . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5 Architecture et structures de données 365.1 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . 365.2 Description du diagramme . . . . . . . . . . . . . . . . . . . . 38

5.2.1 Application . . . . . . . . . . . . . . . . . . . . . . . . 385.2.2 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.2.3 Cameras . . . . . . . . . . . . . . . . . . . . . . . . . . 425.2.4 Exception . . . . . . . . . . . . . . . . . . . . . . . . . 435.2.5 Comparaison avec l’architecture prévue . . . . . . . . 43

5.3 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . 445.4 Structures de données . . . . . . . . . . . . . . . . . . . . . . 44

6 Algorithmes 466.1 Méthodes existantes . . . . . . . . . . . . . . . . . . . . . . . 46

6.1.1 Méthodes SAP par modélisation statistique . . . . . . 466.1.2 Méthode de soustraction de deux images consécutives 496.1.3 Méthode retenue . . . . . . . . . . . . . . . . . . . . . 50

6.2 Description de l’algorithme utilisé . . . . . . . . . . . . . . . . 516.3 Implémentation logicielle . . . . . . . . . . . . . . . . . . . . . 54

6.3.1 ImageBack . . . . . . . . . . . . . . . . . . . . . . . . 546.3.2 Silhouette . . . . . . . . . . . . . . . . . . . . . . . . . 55

7 Tests et résultats 567.1 Tests sur l’extraction de silhouette . . . . . . . . . . . . . . . 567.2 Risques encourus . . . . . . . . . . . . . . . . . . . . . . . . . 61

8 Extensions 628.1 Etat des lieux . . . . . . . . . . . . . . . . . . . . . . . . . . . 628.2 Extensions possibles . . . . . . . . . . . . . . . . . . . . . . . 638.3 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5

9 Bilan du projet 679.0.1 Organisation et difficultées . . . . . . . . . . . . . . . . 679.0.2 Utilisation des bibliothèques . . . . . . . . . . . . . . . 679.0.3 Conlusion . . . . . . . . . . . . . . . . . . . . . . . . . 68

Bibliographie 70

A Utilisation de l’application 71

6

Table des figures

1.1 Système prosthétique de capture de mouvement (source : http ://www.animazoo-europe.com/ - projet Gipsy) . . . . . . . . . . . . . . . . . . . 11

1.2 Exemple de squelette cinématique obtenu à l’aide de l’imagecorrespondante (source : [MBR06]) . . . . . . . . . . . . . . . 14

1.3 Exemples de squelettes pour des formes simples. (source :http ://fr.wikipedia.org/wiki/Squelettisation) . . . . . . . . . . 15

1.4 Illustration de l’amincissement topologique : à gauche la grillede voxel représentant l’objet original et à droite la même grilleayant subi l’application de l’algorithme (source :http ://fr.wikipedia.org/wiki/Squelettisation) . . . . . . . . . . 17

1.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.1 Le modèle biomécanique développé par Semocap afin d’inté-grer les propriétés spécifiques pour chaque personne. (source :www.riam.org/riam/upload/posters/Semocap.pdf ) . . . . . . . 21

2.2 Capture de l’interface iPoseR Semocap (source : [Kno07]) . . 22

3.1 Schéma de la structure du système de traitement des images . 283.2 Schéma du fonctionnement . . . . . . . . . . . . . . . . . . . . 29

6.1 Représentation graphique de l’espace RGB. ( source : http ://xa-vier.hubaut.info/coursmath/doc/thcoul/rgb.jpg) . . . . . . . . 47

6.2 Représentation graphique de l’espace HSV par un cône. (source :http ://www.aqra.ca/IMG/jpg/HSV_cone.jpg) . . . . . . . . . 48

6.3 Résultat obtenu par une soustraction de deux images consécu-tives.a)image(temps t0) b)image(temps t1) c)résultatde la détection du mouvement non seuillé. . . . . . . . . . . . 50

7.1 Test génération modèle statistique (visible2D)a)image originale b)modèle statistique . . . . . . . . . . . . . 57

7.2 Test extraction de silhouette a)image origine b)résultat de l’ex-traction SAP (visible2D) . . . . . . . . . . . . . . . . . . . . . 58

7

7.3 Variation des seuils H,S,V(seuilR,seuilG,seuilB,seuilH,seuilS,seuilV)a) (0.5, 2.0, 1.0, 12.0, 25.0, 0.0) ; b) (2.0, 2.0, 2.0, 2.0, 25,0)c) (2.0, 2.0, 2.0, 12.0, 8.0, 0.0) ; d) (3.0, 3.0, 3.0, 10, 20,1.0) 59

7.4 application d’opérations morphologiquesa) 1 érosion et 1 dilatation b)2 dilatation et 2 érosions . . . . 60

7.5 application d’opérations morphologiquesa) 1 érosion, 1 dilatation, 2 dilatations et 1 érosionb)1 érosion, 1 dilatation, 2 dilatations, 1 érosion, 2 érosionset 2 dilatations . . . . . . . . . . . . . . . . . . . . . . . . . . 61

8

Chapitre 1

Introduction au domained’application

1.1 Présentation

L’« analyse de mouvement humain » associée à la notion de « squelettegéométrique » font référence à l’« analyse de formes ». En effet la personnedont le mouvement est analysé peut tout à fait être identifié comme uneforme, de plus la squelettisation est par définition un outil d’analyse (et decodage) de formes, plus précisément une représentation simplifiée pour lareconnaissance de formes. De nos jours, nous avons de plus en plus besoind’obtenir des informations sur la forme du corps humain, et cela dans plu-sieurs secteurs, notamment dans la conception de vêtements, d’habitaclesd’automobile, de postes de pilotage, ou encore la conception de prothèses.Depuis longtemps, les chercheurs en vision par ordinateur traitent le pro-blème de la reconnaissance de formes à base de modèles.

Ces vingt dernières années, nous trouvons dans la littérature plusieurstravaux portant sur la reconnaissance d’objet 3D de forme libre. Les tests ef-fectués sont réalisés soit avec des images de synthèse, soit dans des conditionscontrôlées où des problèmes omniprésents dans les scènes 3D réelles (e.g. lefond, les ombrages) sont rarement pris en compte. Une nouvelle approche quiutilise le squelette des objets comme descripteur de formes a été développéeafin de pouvoir prendre en comptes ces différents problèmes. Il existe denombreuses applications pour les squelettes d’objets 2D et 3D dans le traite-ment d’images (codage, compression,...) et dans la vision par ordinateur engénéral. En effet, nous retrouvons dans le squelette de l’objet l’ensemble desa structure topologique et également la plupart des informations contenuesdans la silhouette de la forme analysée. Un autre avantage qu’il faut signaler,c’est le fait que de nature les squelettes ont une structure de graphe.

9

Dans cette introduction, afin de comprendre l’intérêt de notre projet etd’en délimiter le cadre, nous allons tout d’abord faire un tour d’horizon desméthodes de capture de mouvement humain existantes. Puis nous allonsprésenter le principe de squelettisation et introduire l’algorithme d’amincis-sement topologique dont nous allons nous servir. Ensuite nous étudierons lesdomaines d’application de l’analyse de mouvement humain à base de sque-lettisation afin d’illustrer notre travail. Enfin, nous introduirons notre projetà l’aide des différentes méthodes et techniques que nous allons utiliser.

1.2 La capture de mouvement

Les recherches menées sur l’interactivité homme-machine et la réalitévirtuelle sont à l’origine de divers systèmes de capture qui existent de nosjours. Elles donnent naissance à divers périphériques d’entrées tels que lessouris 2D et 3D, les joysticks, les écrans tactiles, les tablettes graphiques, lesgants de données, les visiocasques, les différents capteurs(i.e. magnétiques,optiques, à ultrasons), ou encore la reconnaissance de forme. Ces techniquesont été mises en place dans un premier temps pour instaurer un langagegestuel direct entre l’homme et la machine, et évoluent maintenant vers l’ac-quisition de données pour la reproduction parfaite du mouvement d’un êtrehumain. Ainsi, que ce soit dans l’industrie du jeu, du film, ou encore pour lamédecine ou la biomécanique, les systèmes de capture de mouvement sontd’une grande aide.

Il existe trois grandes catégories de capture de mouvement : mécanique,magnétique et optique, qui sont amplement décrites dans la thèse [Kno07].Nous allons nous contenter ici de dresser un petit historique et un bilanconcis de ces systèmes afin de bien cerner le cadre de notre projet.

1.2.1 La capture mécanique

Au début des années 80, Tom Calvert, professeur en informatique, fixe despotentiomètres sur un corps humain pour des études de chorégraphie et pourdétecter les anomalies du mouvement du corps. A partir d’un exo-squeletteconstitué de potentiomètres, placés sur le corps d’un être humain, le systèmecapture les angles de flexion entre les articulations des différents membres. Onles appelle systèmes prosthétiques. Même si ces systèmes semblent imposants,ils sont cependant encore utilisés en raison de leur faible coût, leur fiabilitéainsi que leur facilité d’utilisation. Toutefois le principal désavantage de cesystème reste la gène occasionnée pour l’acteur, ainsi il n’est pas recommandépour la capture de mouvements rapides et/ou amples.

10

Fig. 1.1 – Système prosthétique de capture de mouvement (source :http ://www.animazoo-europe.com/ - projet Gipsy)

1.2.2 La capture magnétique

En 1992, la société Protozoa utilise de nouveaux systèmes pour l’anima-tion d’un personnage de dessin animé, entièrement animé à partir d’un sys-tème de capteurs magnétiques disposés sur un acteur réel. Pour l’animationdu personnage, la capture magnétique révèle son principal avantage sur lacapture optique : la visualisation en temps réel du personnage virtuel animé,car les données des capteurs sont traitées en temps réel. Contrairement auxsystèmes prosthétiques, la capture magnétique constitue un faible encom-brement pour l’acteur. De plus la visualisation des mouvements en tempsréel est un atout pour le gain de temps. Cependant il existe des contraintes,tout d’abord les objets métalliques peuvent provoquer des imprécisions dansles mesures, et l’étendue des champs magnétiques posent des problèmes auniveau de l’environnement d’acquisition.

1.2.3 La capture optique à marqueurs

Les années suivantes, les premiers systèmes de capture optique voientle jour. En 1983, Ginsberg et Maxwell ( MIT ) utilisent le Op-Eye, un despremiers systèmes de capture optique, pour leurs recherches. Ils obtiennenten temps réel l’animation d’un personnage virtuel en basse définition, à par-tir de deux caméras et de diodes placées sur les membres d’un acteur réel.

11

Les systèmes de l’époque révèlent les premiers problèmes liés au matérielet à la technique. Les caméras ont une résolution et une fréquence d’échan-tillonnage trop faible. En 1989, Motion Analysis expérimente son système decapture optique sur la chanteuse virtuelle « Dozo ». Le système a pour objec-tif d’obtenir un mouvement réaliste sur l’ensemble du corps du personnage.La tâche s’avère laborieuse à cause du manque d’expérience et de la jeunessedu système de l’époque. Mais le résultat laisse présager un avenir certain.De nos jours, Motion Analysis propose un des systèmes les plus performantset précis du marché.

Ces systèmes fonctionnent à partir de marqueurs (diodes ou pastilles) réflé-chissants placés sur un acteur suivi par au moins deux cameras qui détectentles marqueurs. A partir des images fournies par les caméras, un logiciel cal-cule les positions 3D de chacun des marqueurs. Ce système constitue unfaible encombrement pour l’acteur qui doit juste porter de petits marqueurs.Cependant, il possède de grosses contraintes, tout d’abord au niveau de l’en-vironnement, il faut un espace parfaitement contrôlé (fond vert / bleu), etcertaines couleurs sont à proscrire afin de permettre un meilleur suivi desmarqueurs (pastilles réfléchissantes de couleurs, diodes). De plus, en termede coût du matériel nécessaire, ces systèmes deviennent peu rentables. Mêmes’ils permettent toutefois d’obtenir des résultats fiables et précis, le processusconsomme énormément de temps. Les animations extrêmement réalistes de-mandent en effet une période de post-production qui peut prendre plusieursjours pour une seule minute d’animation.

1.2.4 Synthèse

De nos jours, les systèmes de capture de mouvement les plus utilisés res-tent les systèmes prosthétiques, puis les systèmes à capteurs optiques avecmarqueurs qui ont fait leur preuve dans le monde de l’animation. Les sys-tèmes à marqueurs ont été très largement utilisés dès les premières décou-vertes dans ce domaine, mais possèdent actuellement de grosses difficultés,lors de la détection, la reconstruction et le suivi des marqueurs ainsi que lareconstruction des trajectoires des articulations du corps.

1.2.5 Les systèmes de capture optique sans marqueurs

L’évolution du matériel informatique et du matériel vidéo s’est extrê-mement accélérée depuis des années et a poussé de nombreux chercheurs asoulever le problème de la capture de mouvement directement depuis desvidéos en n’utilisant aucun marqueur. Ce système présente de nombreuxavantages : le coût de l’acquisition en terme de moyens financiers est énor-mément réduit. De plus on voit disparaître les contraintes vestimentaires del’acteur (du sportif, du patient, selon le domaine d’application) et également

12

les ports d’équipement sur la personne. L’approche générale de cette acquisi-tion du mouvement est de considérer un simple modèle cinématique (sans lesparamètres des « jonctions » ou « articulations ») et d’enregistrer ces modèlesavec les données provenant des vidéos (séquences d’images) afin de pouvoirsuivre ces paramètres et assurer un suivi du mouvement. La comparaisonentre les systèmes à marqueurs et sans marqueurs est décrite précisémentdans [Kno07].

Dans le cadre de notre projet, nous allons aller dans cette direction enutilisant une méthode de capture de mouvement par système optique sansmarqueurs. La description précise d’une technique d’analyse de mouvementhumain à base d’extraction de squelette qui utilise ce type de système estdéveloppée dans [MBR06]. Nous reviendrons sur cette technique dans notreintroduction au projet (cf. Chapitre 3).

1.3 La squelettisation

1.3.1 Introduction

Pour toute application nécessitant de caractériser un modèle 3D par saforme, en particulier dans le monde de l’animation, on cherche une repré-sentation structurée qui décrit le mieux possible la morphologie de l’objetanalysé, ou dans notre cas du corps humain. Décrire un objet par une repré-sentation de type « squelette » constitue une étape importante pour certainesapplications liées au traitement des images ou à la reconnaissance de formes.En effet l’avantage essentiel du squelette est de préserver, en grande partie,la structure topologique des objets ainsi que les informations contenues dansleur contour. Le squelette permet également de capturer au mieux la formede l’objet, pour correspondre à un squelette au sens anatomique. Un tel sque-lette peut ensuite servir de support pour de multiples utilisations, commeanimer l’objet, trouver des propriétés de la forme 3D, ou la comparer à uneautre représentation afin de la ranger dans une base de données par exemple.De plus, les squelettes présentent quelques propriétés très intéressantes, quiseront exposées dans la section suivante (Définitions et propriétés).

Les raisons évoquées au-dessus expliquent en partie pourquoi c’est une mé-thode qui a gagné l’intérêt de nombreux chercheurs. Dans cete partie, nousallons d’abord expliquer rapidement les origines de la squeletisation. Ensuite,nous exposerons certaines définitions et propriétés concernant la squeletti-sation qui seront utiles à la compréhension de notre projet. Enfin, depuisl’introduction du concept de squelette en tant que descripteur de formes,plusieurs algorithmes de squelettisation ont été proposés dans la littérature.Nous allons en étudier un en particulier connu sous le nom d’amincissement

13

topologique, que nous allons utiliser dans la partie finale de notre projet, etqui constitue à obtenir une représentation cinématique d’un squelette commele modèle ci-dessous.

Fig. 1.2 – Exemple de squelette cinématique obtenu à l’aide de l’image cor-respondante (source : [MBR06])

1.3.2 Historique

Le concept de squelette a été introduit pour la première fois par H. Blumen 1964 dans [Blu64], en vue de créer un nouveau descripteur de formes.Il utilise le concept de feu de prairie, c’est-à-dire, des feux provenant despoints de contour de l’objet et qui se propagent vers l’intérieur à vitesseconstante. Le squelette est alors formé par les points où les fronts de cesfeux s’intersectent. Ces points sont aussi appelés points d’extinction. Uneautre définition donnée par L. Calabi en 1965 considère le problème d’unpoint de vue topologique. Cette définition est basée sur le concept de boulesmaximales. Il définit le squelette d’un objet comme étant l’ensemble descentres de ses boules maximales. Une boule incluse dans un objet est ditemaximale s’il n’existe pas d’autres boules incluses dans l’objet la contenantentièrement.

Depuis la dernière décennie, de nouvelles définitions (qui seront exposéesdans la prochaine section) et approches du squelette ont vu le jour. Ellesseront exposées dans la section qui suit. Cela a permis un certain engouementpour la technique de squelettisation. Celle-ci s’est ouverte à de nombreuxdomaines d’application, que nous détaillerons dans la section 1.4.

14

1.3.3 Définitions et propriétés

Formellement, un squelette est une représentation géométrique d’un objetdans une dimension inférieure. Il permet de décrire d’une manière compacteles propriétés d’un objet, en particulier sa forme.

Fig. 1.3 – Exemples de squelettes pour des formes simples. (source :http ://fr.wikipedia.org/wiki/Squelettisation)

Dans le plan, le squelette d’un objet est un ensemble de lignes passanten son milieu appelé axe médian (« medial axis »). Dans un espace tridi-mensionnel, il existe deux types de squelettes : les squelettes surfaciques(« médial surfaces ») et les squelettes curvilignes. Les premiers sont consti-tués d’un ensemble de voxels de l’objet qui forment une surface d’épaisseurunité et les seconds sont constitués d’un ensemble de voxels de l’objet quiforment une courbe dans l’espace de largeur unité, souvent appelés squeletteshomotopiques. C’est de ce type de squelettes dont il s’agit dans notre projet.

Les squelettes présentent quelques propriétés intéressantes. La plupart sonténoncées dans [Mer04], nous allons les rappeler :

Invariance par translation et rotation : Le squelette est invariant partranslation et rotation. Étant donné une translation ou une rotationg et un objet X. Soit S(X) le squelette de l’objet X. Nous avonsS(g(X)) = g(S(X)).

Réversibilité : A partir des points du squelette et des rayons des boulesmaximales, il est possible de reconstruire la forme. Ainsi la squelettisa-tion est réversible à condition d’avoir mémorisé en chaque point p dusquelette, le rayon r(p) de la boule maximale centrée en p. La fonctionr est appelée fonction d’étanchéité.

Structure de graphe : Sous certaines hypothèses de régularité, il est pos-sible de montrer que le squelette a une structure de graphe, où lesnoeuds sont considérés comme des articulations et les arêtes commedes os. Ainsi, les techniques issues de la théorie de graphes peuventêtre appliquées directement aux objets.

Homotopie : Le squelette est topologiquement equivalent à l’objet origi-nal, autrement dit il a le même nombre de composantes connexes, le

15

meme nombre de trous et de cavités que l’objet original. Dans le plan,deux objets homotopes ont le même aspect et justifie l’utilisation dusquelette comme descripteur de formes.

Minceur : Le squelette est topologiquement mince, c’est-à-dire qu’il a unpixel d’épaisseur, sauf aux jonctions pour lesquelles un pixel ne suffitpas à garantir l’homotopie.

Localisation : Le squelette est situé au centre de l’objet.

1.3.4 Algorithme d’amincissement topologique

A l’heure actuelle, il existe plusieurs manières de calculer un squelette.Voici les principales :

– Par simulation des déplacements des fronts d’onde d’un feu de prairie(cf. Historique).

– Par extraction des lignes de crêtes dans une carte de distance. Une cartede distance est une image, ou chaque point est associé à la distanceentre ce point et le bord le plus proche. Les lignes de crêtes représententles maxima locaux.

– Par amincissement topologique. Nous allons détailler cette méthodedans ce qui suit.

– Par calcul analytique des axes médians. Cette technique consiste àmodéliser le contour de l’objet par des objets dont le squelette estconnu (des polygones) puis à rassembler les squelettes pour obtenir lesquelette global.

Les différentes techniques de squelettisation peuvent être classées en deuxcatégories. Les méthodes discrètes, telles que l’amincissement topologique,« le feu de prairie », les champs de potentiel et les cartes de distances. Et lesméthodes continues, essentiellement basées sur l’utilisation du diagramme deVoronoï. Dans le cas de l’utilisation de cette dernière méthode, le squeletteobtenu est topologiquement équivalent à l’objet car la représentation des ob-jets par leur contour conserve implicitement ces notions, il est de plus centréet fin car on utilise une représentation continue. Cependant, cette méthodepeut poser des problèmes lors des passages entre les domaines continus etdiscrets. De plus, la complexité des algorithmes et les temps de calculs sonténormes pour de grandes images. On peut en revanche s’intéresser aux mé-thodes discrètes, plus faciles à mettre en oeuvre et surtout plus rapides, et enparticulier à un algorithme appelé amincissement topologique (connu aussisous le nom de « voxel thinnning »). Nous utilisons cet algorithme dans notreprojet.

16

Cet algorithme prend en entrée une image volumique 3D qui est constituéede voxels (VOlumetric piCTure ELement), la plus petite entitée composantune image 3D (tout comme le pixel dans une image 2D). L’amincissementtopologique consiste à retirer au fur et à mesure les voxels du contour dela forme, tout en préservant ses caractéristiques topologiques. Pour ce faireil part du contour initial de l’objet, étudie la connexité de chaque voxel ducontour dans un voisinage, et enlève ceux dont la suppression n’affecte pasla topologie de l’objet. Le squelette est obtenu en érodant itérativement lescouches frontières de l’objet (dans notre cas du corps humain). Les pointssupprimables sont enlevés soit successivement, soit en parallèle, ou encore àl’aide d’opérations morphologiques. Ces méthodes conduisent à un squelettehomotope à l’objet (ou au corps humain) par construction, mince, géométri-quement représentatif mais pas forcément centré.

Fig. 1.4 – Illustration de l’amincissement topologique : à gauche la grillede voxel représentant l’objet original et à droite la même grille ayant subil’application de l’algorithme (source :http ://fr.wikipedia.org/wiki/Squelettisation)

1.4 Domaines d’application

L’analyse de mouvement à base d’extraction de squelette géométriquepossède de nombreuses applications dans des domaines qui ne sont pas for-cément tous liés à l’informatique, comme on pourrait le penser.

L’animation en général reste le domaine de prédilection de la capturede mouvement, celle-ci étant de plus en plus utilisée. Avec les grandes pro-ductions cinématographiques et des jeux-vidéos, ainsi que pour les séries

17

télévisées, on essaie de créer des images de synthèse où les personnages vir-tuels doivent être les plus semblables possibles aux êtres humains. Ceci n’estpas juste valable au niveau de l’apparence mais surtout au niveau des mou-vements des personnes. Cependant les systèmes existants, essentiellementde capture optique, nécessitent des moyens financiers et d’équipement trèslourds, et posent de grosses contraintes sur les conditions de travail (lieuxadéquats à la capture, équipements sur les personnes...).

Au niveau de la réalité virtuelle, l’utilisation de capture de mouvementlaisse entendre que la représentation du squelette soit crédible et assez fidèlepar rapport à l’anatomie humaine. Certains programmes d’entraînement mi-litaire utilisant la réalité virtuelle se servent de cette technique afin de recréerdes environnements dangereux, et ainsi optimiser le déplacement des soldatsdans ces environnements.

En médecine, la modélisation permet de voir en quoi un handicap in-fluence une consommation énergétique supplémentaire, et éventuellement detrouver des solutions viables afin de compenser ou réduire cet handicap (parexemple une prothèse plus adaptée à chaque personne). Certaines méthodesde traitement et de réhabilitation du corps humain utilisent la capture demouvement à base de squelettisation. Il y a également des liens entre lamédecine et l’anthropométrie, afin de vérifier l’évolution des mouvements etde certains membres du corps humain. Par exemple, la squelettisation peutêtre utilisée pour prévenir une malformation héréditaire du membre (e.g. unejambe) d’un jeune enfant, et ainsi localiser facilement le symptôme.

Dans le domaine sportif, on s’intéresse également à la consommationénergétique. Le but ici est de déterminer les techniques les plus performantespour exécuter une action, un geste, afin d’optimiser le mouvement dans lebut d’atteindre de meilleures performances physiques. Outre la recherche deperformances sportives, la squelettisation peut être utilisée pour la préven-tion des blessures, ou encore pour préparer un retour à l’activité afin devérifier les effets de soins orthopédiques sur des athlètes.

Pour ce qui est du design, la capture de mouvement utilisant la squeletti-sation a un rôle à jouer, principalement pour améliorer l’ergonomie d’objetsque l’homme utilise, de la manette de jeux-vidéos aux chaussures que l’onporte. Par exemple, la société Lectra (Cestas - Gironde) utilise cette mé-thode afin de procéder à une découpe automatique précise de vêtements, enutilisant un modèle 3D cinématique pour le test de ces textiles. Cela peutpermettre de trouver des coupes originales, et aussi d’économiser les tissusutilisés pour la conception de vêtements.

18

La biomécanique est aussi concernée, afin d’obtenir une meilleure com-préhension des mouvements humains, ce qui nous permet de développer desmodes mécaniques plus conformes au corps, plus fidèles. Le domaine militaires’intéresse naturellement de près à cette approche.

Il existe sinon quelques applications en compression de modèles et flux3D, ainsi qu’en architecture et en urbanisme, dans le cadre d’analyse mor-phologique, à l’aide de la squelettisation. Le mouvement et le comportementd’animaux peut également être analysé et compris avec cette méthode.

Fig. 1.5 –Illustration des principaux domaines d’application de la capture demouvement à base d’extraction de squelette géométrique : (a) l’anima-tion (source : http ://yeknan.free.fr/blog/images/dappersoft/ ) (b) laréalité virtuelle (source :http ://www.inrialpes.fr/grimage/photos/ )(c) la médecine (source : http ://mediatheque.epfl.ch/albums-alliance/Informatique-Communications/ ) (d) le domaine sportif(source : http ://www.vicon.com/applications/sports.html) (e) le design(source : http ://technology.newscientist.com)

19

Chapitre 2

Analyse de l’existant

Afin de bien délimiter les frontières de notre projet, nous nous sommesuniquement intéressés aux travaux existant dans le cadre de la capture demouvement optique sans marqueurs.

2.1 Interface

2.1.1 Semocap

La société Artefacto en collaboration avec Asica L’INRIA Rhône-Alpeset l’université de Rennes a développé un logiciel nommé Semocap 1. Ceprojet vise à développer un système de capture de mouvement économiqueen terme de ressources et d’équipement. Il possède des similarités avec notreprojet puisque le schéma global de traitement est quasi-identique. La seuledifférence notable est que nous allons utiliser un modèle biomécanique bienmoins élaboré que celui utilisé dans le projet Semocap (figure ci-dessous).Ce projet nous apporte des informations sur les problèmes liés à la captureet la modélisation de mouvement humain.

1http://www.artefacto.fr/semocap/

20

Fig. 2.1 – Le modèle biomécanique développé par Semocap afind’intégrer les propriétés spécifiques pour chaque personne. (source :www.riam.org/riam/upload/posters/Semocap.pdf )

Semocap permet d’afficher plusieurs résultats de représentations, commeles images avec les silhouettes ou le modèle 3D projeté dans les images,comme le démontre l’image ci-dessous. Cette figure nous donne des idéesconcernant l’interface de visualisation des représentations. Concernant l’im-plémentation des techniques de représentations tridimensionnelles, rien n’estclairement expliqué.

21

Fig. 2.2 – Capture de l’interface iPoseR Semocap (source : [Kno07])

2.1.2 Commentaires

L’interface proposée par Semocap est surement celle la plus proche denotre logiciel, même si elle permet de nombreux réglages supplémentaires(e.g.sauvegarde des fichiers, possibilité d’appliquer des textures ou autrestaitements aux images, multiples représentations). Les travaux concernantl’extraction du squelette depuis une capture de mouvement sans marqueurssont assez récents, c’est pourquoi il nous a été difficile de trouver d’autreslogiciels proposant nos caractéristiques auxquels nous comparer. Toutefois,nous avons étudié de nombreux travaux publiés sur le sujet nous informantdes méthodes et algorithmes à utiliser dans le cadre de notre projet. C’estce que nous allons voir dans la section suivante.

2.2 Méthodes et algorithmes

2.2.1 Extraction de silhouette

Principe L’extraction de silhouette, comme son nom l’indique, permetd’extraire d’une image la silhouette d’un acteur en ne gardant que les pointsappartenant à son corps et colore d’une couleur différente le fond et l’acteur.Cette étape est primordiale en terme de qualité afin d’avoir de bons résultats

22

pour les représentations suivantes. Concernant cette extraction, plusieurs al-gorithmes ont été étudiés. Tout d’abord, un algorithme interessant est celuidécrit dans [TFJT]. Le but de ce projet est de pouvoir enregistrer avec troiscaméras les mouvements d’un acteur, pour pouvoir créer un personnage vir-tuel aux mouvements réalistes. Une des étapes du projet est donc l’extractionde la silhouette, sur laquelle nous nous sommes atardés. Pour cela, 4 filtresont été implémentés :

Différence : création d’une image représentant la différence entre l’imagede fond (sans l’acteur) et l’image témoin (avec l’acteur).

Erosion : deux érosions consécutives permettent de supprimer les pixelsnoirs entourés en 4-voisinage par des pixels blancs.

Dilatation : contraire de l’érosion, permet de supprimer les pixels blancsentourés en 4-voisinage par des pixels noirs.

Suppression des amas de pixels : permet de ne garder que le plus grosamas de pixels et dupprimer le reste. Statistiquemet, la silhouette estcontenue dans cet amas. Cet algorithme récursif est le plus difficile àimplémenter.

Commentaires Cette technique, relativement simple à implémenter etfaible en complexité, ne permet pas d’obtenir des résultats corrects dansnotre cas. Elle est utilisée dans le cas de capture de muvement dans desconditions bien pariculières : fond blanc, acteur habillé en noir,... En effet,nous devons utiliser un algorithme qui puisse extraire une silhouette malgréla couleur du fond et des vêtements de l’acteur. Nous nous sommes alorspenchés sur la technique élaborée dans [Lem03]. Cette méthode correspondà nos besoins car malgré sa complexité assez conséquente, elle permet d’éli-miner les ombres tout en préservant la forme de l’acteur. Etant donnée quec’est cette méthode qui a été retenue, nous la détaillons largement dans lechapitre Algorithmes.

2.2.2 Amincissement topologique

Le principe de cet algorithme a été présenté dans l’introduction au do-maine d’application. Nous avons retenu un logiciel existant, composé de 3modules : Binvox, Thinvox et Viewvox 2, permettant respectivement la créa-tion d’un fichier de type grille de voxel, la lecture de ce fichier pour l’amin-cissement topologique de la grille qu’il contient, et enfin la visualisation deces fichiers. Le module Thinvox nous interesse particulièrement car c’est luiqui procède à l’amincissement d’une grille de voxels. Ce programme, dontles sources sont consultables, se base sur la méthode abordée dans [PK99].

2http://www.cs.princeton.edu/~min/thinvox/

23

2.3 Grimage

Les équipes Perception, Moais, Evasion et le service SED de GrenobleRhône-Alpes ont réalise une plate-forme immersive appelé Grimage [?]. Elleassocie modélisation 3D multi-caméras, simulation physique et calcul paral-lèle pour de nouvelles applications immersives 3D sans marqueurs.

Plusieurs caméras vidéo calibrées filment en continu l’espace d’interaction.Pour chaque jeu d’images acquises, le système utilise les informations 2D is-sues de chaque caméra pour calculer un modèle 3D des objets réels de lascène. Le calcul des modèles 3D s’effectue sans recourir à des marqueurs.L’utilisateur n’a pas besoin de s’équiper de capteurs passifs ou actifs. Le sys-tème ne nécessite pas non plus de phase d’apprentissage ou de reconnaissancedes objets présents dans l’espace d’interaction. Il n’est ainsi pas limité parles objets ou personnes qu’il peut reconstruire en 3D. C’est une différenceimportante de Grimage par rapport à des systèmes de capture de mouvementqui permettent de suivre les marqueurs dont est équipé l’utilisateur, mais nefournissent pas de modèle 3D global de cet utilisateur.

Les modèles 3D des objets réels sont calculés par l’algorithme EPVH« Exact Polyhedral Visual Hull » développé par Edmond Boyer et Jean-Sébastien Franco de l’équipe Perception de l’INRIA Rhône-Alpes. Cet algo-rithme calcule l’enveloppe visuelle des objets à partir des silhouettes issuesdes flux vidéos. Une enveloppe visuelle est le résultat de l’intersection descônes issus de la projection dans l’espace 3D des silhouettes 2D vues parles caméras. L’algorithme EPVH est exact, la projection du modèle 3D cal-culé sur les images provenant des caméras produit des silhouettes qui cor-respondent exactement à celles des objets réels vues par les caméras. Cesmodèles 3D sont ensuite envoyés vers la simulation pour le calcul des in-téractions avec les objets virtuels. Pour l’affichage à l’écran, les silhouettessont aussi texturées par plaquage des informations photométriques issues descaméras.

Les méthodes et techniques utilisées dans le projet Grimage sont de grandeenvergure et réunissent plusieurs spécialités informatiques (génie logiciel,image multimédia, réalité virtuelle). On notera certaines similitudes avecnotre projet, notamment au niveau des algorithmes d’extraction de silhouettes,de reconstruction d’enveloppe volumétrique. La différence notable résidedans le fait que cette plateforme permet une analyse et une reconstructionen temps réel, elle permet d’effectuer des simulations physiques très précises.Les algorithmes utilisés sont adaptables et permettent une intégration dansdes applications interactives telles que la réalité virtuelle.

24

2.4 Synthèse

La squelettisation, et de manière plus générale la capture de mouvementsans marqueurs, fait encore l’objet de nombreuses recherches et expérimen-tations à l’heure actuelle, en raison de sa nouveauté. Parmi ces chercheurs,le groupe Perception de l’INRIA Rhône-Alpes de Grenoble 3 est spécialiséedans l’interprétation des images et vidéos en terme de représentation visuelletridimensionnelle. De nombreux travaux ont donc été effectués et publiés.On pourra citer notamment l’article de Clément Ménier, Edmond Boyer, etBruno Raffin [MBR06] ainsi que la thèse de David Knossow [Kno07]. Ces dif-férents travaux nous permettent d’obtenir des informations techniques quantaux marches à suivre, aux algorithmes de squelettisation et autres méthodesà utiliser. Cependant les chaînes de traitements ne sont pas les mêmes pourl’amincissement topologique car nous n’utilisons pas la méthode de l’axemédian (« médial axis » [BB04] ) mais plutôt une méthode d’amincissementtopologique (« voxel thinning »).

3http ://perception.inrialpes.fr/

25

Chapitre 3

Introduction au projet

3.1 Buts et priorités

Dans notre projet, nous allons aborder une méthode de capture de mou-vement par système optique sans marqueurs. Le but de ce projet est de per-mettre la visualisation de représentations tridimensionnelles via une interfacegraphique. Nous allons procéder en suivant un schéma global de traitementde « Ménier et al. » [MBR06], dont la marche à suivre est expliquée dans laprochaine section. Toutefois il y a une différence essentielle entre le fonction-nement de [MBR06] et celui de notre projet : nous utilisons un algorithmed’amincissement topologique en travaillant sur des grilles de voxels afin d’ob-tenir le modèle du squelette, alors que [MBR06] utilise la transformation del’axe médian (« médial axis transform »).

Le but majeur constitue à pouvoir visualiser une représentation du sque-lette d’une personne à l’aide d’images représentant une séquence vidéo. L’uti-lisateur du logiciel doit pouvoir visualiser les différentes étapes de la construc-tion du squelette, à savoir la silhouette, l’enveloppe volumétrique de celle-ci,et la grille de vixels associée amincie. Ces représentations, obligatoires afin devérifier la bonne construction du squelette géométrique final, doivent pouvoirêtre visualisées toutes en même temps que les images sources.

La plus grande priorité est de pouvoir visualiser au moins une des représen-tations citées précedemment à travers une interface graphique ainsi que lesimages sources. L’utilisateur doit pouvoir contrôler la lecture de ces imagesen même temps que celle des représentations, que nous obtenons à l’aide destechniques suivantes.

26

3.2 Principe

Le point de départ est un jeu de données contenant les images qui pro-viennent de flux vidéo dont la position relative des caméras ainsi que leursparamètres de projection sont connus. Dans un premier temps, nous procé-dons à l’extraction de la silhouette de l’humain à analyser. Pour cela, nousutilisons d’abord les images provenant du jeu de données ne contenant pasl’humain que nous devons représenter. Nous calculons alors la moyenne descomposantes (RGB) de chaque pixel composant chacune des images. Ensuite,nous observons les images contenant l’humain, et comparons chaque pixel del’image avec la valeur moyenne trouvée précédemment. Ceci nous permetdonc d’isoler la silhouette du fond. Cette étape peut rencontrer quelquesdésagréments dû au bruit dans les images, d’où la nécessité de pouvoir agirsur la manière dont on compare les pixels des images contenant l’humainpar rapport aux autres. La thèse [Fra05] nous fournit de nombreuses infor-mations sur cette étape, que nous décrivons dans le chapitre Algorithmes etstructures de données.

Ensuite, nous cherchons à obtenir l’enveloppe volumétrique à partir del’extraction de silhouette effectuée précédemment. Elle est obtenue par pro-jection, cette notion est largement exposée dans [Lau94], dont nous rappelonsle principe. Pour un moment t donné, et pour chaque caméra, on projettechaque pixel qui constitue la silhouette d’une même scène sur une grille devoxel, à l’aide de la matrice de projection de chaque caméra contenue dansles jeux de données fournis.

Puis, nous allons effectuer une opération d’amincissement topologiquede la représentation volumétrique afin d’obtenir un squelette intermédiaire,comme expliqué plus en détail dans le chapitre précedent.

Enfin, la dernière étape de la reconstruction du squelette étant très com-plexe, cette tâche a été définie comme optionnelle par le client. Elle consistea créer un modèle de squelette comportant 22 degrés de liberté. Puis nousfaisons correspondre ce modèle avec le modèle intermédiaire afin d’affiner sareprésentation. L’ultime étape du projet est de mettre en place et visualiserune représentation du squelette cinématique suffisamment fidèle par rapportà l’anatomie du corps humain. Si le temps nous le permet, nous tenteronsd’intégrer d’autres fontionnalités comme la possibilité d’agir sur les visua-lisations à l’aide de paramètres comme le niveau d’amincissement, ou biend’enregistrer une séquence du modèle de squelette.

27

Fig. 3.1 – Schéma de la structure du système de traitement des images

3.3 Fonctionnement

Ci-dessous, le schéma du fonctionnement résumant la description précé-dente.

28

Fig. 3.2 – Schéma du fonctionnement

29

Chapitre 4

Cahier des charges

Dans ce chapitre, nous allons tout d’abord exposer les besoins fonction-nels et non fonctionnels de notre projet. Pour une meilleure clarté des infor-mations, les tests de validation ainsi que les risques sont introduits dans ladescription de nos besoins. Cela permet d’évaluer l’importance des besoinsainsi que leurs difficultés. Ensuite, nous présenterons les moyens logiciels quiseront employés au cours de nos travaux. En ce qui concerne les tests des be-soins fonctionnels nous allons utiliser des tests « boîtes noires », de plus afinde suivre l’évolution d’une analyse le système est doté de points de contrôlesitués après chaque phase importante de l’analyse. Ces derniers points serontabordés dans le chapitre Tests et résultats.

4.1 Besoins non fonctionnels

4.1.1 Domaine d’action

L’analyse du mouvement humain (suivi de sa reconstruction) se fait àpartir d’un lot d’images provenant d’une scène vidéo prise avec plusieurs ca-méras à différentes positions. Ces images sont au format .png. Ceci est notredomaine d’action. Les paramètres des caméras dont les images proviennentsont fournis sous forme de matrice de projection (matrice 3x4) et cela pourchaque caméra. Le domaine d’action est défini par des images provenant d’unflux vidéo, le risque étant que les images soient lourdes, et que le traitementsoit donc considérablement ralenti. C’est pourquoi il est proposé de choisircertains réglages intervenant dans la chaîne de traitement, comme la préci-sion de l’analyse effectuée. En effet les jeux de données utilisés dans le cadrede notre projet sont assez volumineux (quelques GigaOctets). Les ressourcesmatérielles prévues pour le développement de l’application sont les ordina-teurs du CREMI, cependant l’installation des bibliothèques nécessaires y estdifficile, il faut donc prévoir de travailler à l’aide de nos ordinateurs person-nels ou utiliser des médias amovibles (e.g. disques durs externes).

30

4.1.2 Robustesse

De plus, la robustesse est un paramètre important. Lors d’un chargementde données ou du traitement, le logiciel gère certaines erreurs par exceptions.En effet le traitement est composé de plusieurs phases et il est donc impor-tant de savoir exactement d’où provient l’(les) erreur(s) dans la chaîne detraitement au cas ou l’on obtient une erreur, un rapport d’incidents doit êtreainsi généré automatiquement. Ainsi à chaque étape importante, des testssur la justesse des données sont effectués, ainsi que sur le chargement defichiers. Le traitement par exception permet alors au logiciel d’éviter de seterminer anormalement, de prévenir l’utilisateur d’un disfonctionnement etdes erreurs que le programme a rencontré. Ceci permet également d’observerles représentations qui n’ont pas provoquées d’exceptions.

4.1.3 Vitesse d’exécution

Aussi, pour le confort de l’utilisateur ainsi qu’une bonne perception desmouvements, les séquences des représentations ont une vitesse d’affichagesupérieure ou égale à 10 images par seconde (dans le cas d’une carte gra-phique standard, de type Geforce 6600). Si l’affichage n’est pas satisfaisantou trop lent pour l’utilisateur, des réglages de détails et d’optimisation sontdisponibles. Enfin, le client demande que le logiciel offre un temps de ré-ponse inférieur à 1 seconde. A la vue des techniques actuelles, il est tout àfait possible de respecter ce temps de réponse.

4.1.4 Réalisme du résultat

Ensuite, le but de ce logiciel et de permettre d’analyser les mouvementshumains. Pour permettre une analyse pertinente, le logiciel doit assurer lacaractéristique d’affichage suivante : les représentations sont réalistes vis à visde la forme et des mouvements de l’humain analysé. Cela signifie qu’un efforttout particulier doit être réalisé sur l’implémentation des algorithmes propresà chaque représentation. Un compromis doit être fait entre ce besoin et leprécédent, car l’optimisation du résultat en terme de qualité peut accroîtrefortement la complexité de nos algorithmes, étant donné le nombre importantd’images à traiter. Celui-ci est de l’ordre de 8000 images dans notre jeu dedonnées.

On peut facilement tester la robustesse du programme, en provoquant desproblèmes volontairement. Par exemple, on peut fournir un jeu de donnéesdont les images sont au mauvais format, ou bien si l’on donne des réglagestotalement incohérents. Le programme doit être capable de continuer à fonc-tionner et de ne pas se terminer anormalement. La robustesse du programmepeut etre aussi testée en essayant des commandes qui nécessitent des initia-lisations préalables qui n’ont pas été effectuées, comme par exemple essayer

31

de lancer la vidéo avant de l’avoir chargée. Ce genre de problème doit êtregéré par le système d’exceptions.

4.1.5 Extensibilité

Enfin, lorsque l’utilisateur souhaitera tester différentes techniques de re-présentations qui n’ont pas été implémentées, l’ajout de ces nouvelles tech-niques, ainsi que leurs utilisations ne poseront pas de problème, d’où le soucisd’extensibilité. Cela est possible notamment grâce à l’architecture des classesproposées. L’utilisateur peut ainsi, s’il le souhaite, appliquer un traitementspécifique à un type de représentation sans être obligé de modifier et d’adap-ter une grande partie du code.

4.1.6 Ergonomie

L’interface est ergonomique pour un utilisateur expérimenté dans le do-maine de l’imagerie numérique. Il est possible qu’un novice nécessite untemps d’adaptation afin d’utiliser correctement le logiciel. L’interface estfaçonnée de sorte que l’utilisateur ait une accessibilité rapide aux différentesreprésentations, ainsi qu’à l’observation de la position des caméras, ou bienle réglage des différents paramètres (tel que la vue de laquelle on souhaiteobserver la scène par exemple). Afin de faciliter l’utilisation du logiciel, plusparticulièrement pour un novice, le logiciel possède un comportement pardéfaut, c’est a dire qu’il est possible de l’utiliser sans effectuer de réglages.Ainsi le chargement des images et des paramètres des camèras seront lesseules tâches obligatoires à effectuer.

L’ergonomie du logiciel peut être testée à travers un sondage sur plusieursmembres du CREMI, qui pourront juger si le programme est suffisammentfacile d’utilisation. Le sondage portera sur différentes caractéristiques liées àce besoin, telle que la facilité d’accès aux commandes, la visibilité des para-mètres courant, l’efficacité et la simplicité de naviguer à travers les différentesreprésentations, mais aussi la navigation dans les images du jeu de données.

4.2 Besoins fonctionnels

4.2.1 Chargement d’images

La méthode d’analyse que nous utilisons se déroule en trois phases in-termédiaires pour finalement aboutir sur une représentation simplifiée dupersonnage sous forme d’un squelette. L’interface que nous proposons per-met de visualiser les représentations graphiques issues des différentes phasesde l’analyse. Les séquences vidéo qui sont analysées doivent être au format

32

.png 1 et accompagnées d’un fichier texte contenant les paramètres des camé-ras. Ce format d’image apparaît comme le meilleur compromis entre légèretéet qualité, de plus il est utilisé sur les plates-formes de capture multi-camérastelle que la plate-forme "Grimage" 2.

4.2.2 Pré-traitement des données

Après avoir chargé les données (séquences vidéo, paramètres des caméras)l’utilisateur a la possibilité de lancer une analyse immédiatement grâce à uncomportement par défaut de l’interface. Cela signifie qu’un pré-chargementdes images et au moins d’une partie des représentations doit être fait avantde pouvoir lancer l’analyse des images.

4.2.3 Visualisations

Au niveau de l’affichage, l’utilisateur choisit les différentes phases qu’ilsouhaite observer. Elles peuvent être visualisées ensemble dans une mêmefenêtre ou individuellement en plein écran. Cette option est jugée facultativepar le client. A cela s’ajoute le flux vidéo original, celui-ci est constammentvisible en parallèle des autres visualisations, il est parfaitement synchroniséavec les différentes représentations, de plus une analyse trame par tramedevient possible grâce à une boîte de contrôle temporel similaire à un lecteurvidéo standard (lecture, stop, pause, suivant, précédent).

4.2.4 Changement de vue de la caméra

Les séquences utilisées sont filmées avec plusieurs caméras simultané-ment, ce qui offre la possibilité d’avoir plusieurs angles de vue, l’utilisateurpeut ainsi choisir la caméra qui servira de point de vue général pour les diffé-rentes représentations, pour faciliter cela les caméras sont représentées dansun espace 3D ce qui permet de voir très rapidement leur emplacement. Deplus, il est possible d’effectuer des déplacements dans l’espace 3D des scènes,c’est à dire des rotations et/ou translations de caméras autour d’une recons-truction afin de pouvoir l’observer sous différents angles,ainsi qu’une fonctionde zoom. Cela est possible avec l’utilisation de la bibliothèque QGLViewer.3

1[RFC2083]2plate-forme de capture multicaméras sans marqueurs de l’INRIA Rhônes-A1pes : http:

//www.inrialpes.fr/grimage/3Bibliothèque en C++ basée sur QT poluvant manipuler l’OpenGL : http://artis.imag.

fr/Software/QGLViewer/

33

4.2.5 Modification des paramètres

En ce qui concerne la précision des résultats, le système possède un com-portement par défaut permettant un rapport précision/rapidité moyen. Achaque phase de la chaîne de traitement certaines variables clefs agissent di-rectement sur la précision, l’utilisateur peut donc en modifier la valeur pouraffiner la précision des représentations. Ces réglages peuvent être ensuitesauvegardés pour une réutilisation ultérieure. Pour des raisons de commo-dité les informations relatives aux réglages actifs sont constamment visibles,ainsi que la résolution, le nombre d’images par seconde. Ce besoin est jugéoptionnel par le client mais il peut petre interessant de l’implémenter.

4.2.6 Sauvegarde du squelette

Enfin, le résultat et le but de l’analyse, c’est à dire la séquence représen-tant le squelette géométrique final, peut être sauvegardée. C’est une fonc-tionnalité que nous ajouterons si il nous reste du temps avant la fin du projet.Il est toujours utile de garder les résultats pour d’éventuelles comparaisonsou de futures réutilisations dans d’autres applications, comme par exemplela création d’un personnage virtuel ou d’un squelette d’animation à partirdu squelette enregistré.

4.3 Moyens logiciels

Les séquences d’images utilisées pour le développement sont des séquencesprécalibrées publiques sur le web. Elles sont disponibles sur le site de l’équipePerception de l’INRIA Rhône-Alpes : https://charibdis.inrialpes.fr.

Concernant le choix du langage d’implémentation, du fait que l’on travaillesur la bibliothèque d’interface graphique OpenGL, il apparaît bien plus inté-ressant de choisir le C ou le C++. De plus ce sont des langages déjà répandusdans le domaine de l’imagerie numérique. Par contre, le C++ est un langageobjet, contrairement au C qui est impératif, et qui donc ne propose ni poly-morphisme ni héritage. Dans un soucis de respect du besoin d’extensibilité,il s’avère plus pratique de pouvoir utiliser ces deux propriétés. En effet, ilsfacilitent grandement l’ajout de nouvelles techniques de représentation tridi-mensionelle puisque les classes déjà existantes nécessiteront peu de modifi-cations. De plus, nous utilisons la bibliothèque logicielle QT, développée enC++, qui offre des outils afin de faire notre interface graphique, et facilitel’accès aux données et à la gestion des files d’exécution. Cette bibliothèquecomporte également l’avantage d’une excellente portabilité.

Les traitements d’images nécessaires à la réalisation du logiciel, comme lechargement d’images à partir de vidéo, ou l’extraction de silhouette, vont

34

être délégués à une bibliothèque : OpenCV 4. Il s’agit d’une bibliothèquespécialisée dans le traitement d’image et la vision par ordinateur en langageC/C++, optimisée et proposée par Intel pour Windows et Unix. Elle com-prend un très grand nombre de fonctions qui correspondent à nos besoins,des plus simples (i.e. macros d’accès rapide aux pixels) aux plus complexes(i.e. calibrage de caméras)

Pour faciliter l’implémentation de la visualisation, et donc de l’interface,le logiciel peut s’appuyer sur une bibliothèque existante : libQGLViewer.C’est une bibliothèque basée sur Qt et OpenGL qui permet de gérer trèssimplement la caméra, la souris et l’ouverture des fenêtres OpenGL. Ellecompile sur toute architecture (Unix / MacOS / Windows).

Toutes les applications et bibliothèques utilisées lors de ce projet sontOpen Source, e qui nous permet d’utiliser les sources à notre guise.

4Open Source Computer Vision : http://opencvlibrary.sourceforge.net/

35

Chapitre 5

Architecture et structures dedonnées

5.1 Diagramme de classes

36

5.2 Description du diagramme

Comme indiqué sur le diagramme, l’architecture de notre logiciel se com-pose de quatre parties (regroupement d’une ou plusieurs classes) différentes,que nous allons détailler dans ce qui suit. Certaines relations entre les classessont colorisées pour une meilleure visibilité. La couleur rouge désigne l’en-semble des classes qui dépendent de MainGUI, et la couleur bleue désignel’ensemble des classes qui dépendent d’Exception.

5.2.1 Application

Application est un ensemble de classes qui constitue la base de l’architecturede notre logiciel. Cet ensemble compose l’interface graphique, qui est géné-rée par la bibliothèque logicielle QT. Son rôle est de permettre l’affichagedes différents objets (qui correspondent aux différentes étapes du traitementnécessaire pour la reconstruction du squelette humain) en s’appuyant surlibQGLViewer1 Application regroupe les classes en rapport direct avec lacréation de l’interface, les actions la concernant et les différents modulesd’affichage d’information ou d’images. Ce dossier contient les classes Main-GUI, ActionsGUI, Settings, Viewer et Strings.

MainGUI : Cette classe hérite de la classe QMainWindow de la biblio-thèque QT. Elle contient tous les éléments nécessaires à la création et l’af-fichage de l’interface, comme les menus, la barre d’outils, et les différents

1http ://artis.imag.fr/Software/QGLViewer/

38

widgets. Enfin, elle associe les différents contrôles de l’interface aux actionsconcernées. Pour cela, nous avons séparé celles-ci en deux sous-groupes, Ac-tionsGUI et Settings. Chacune de ces classes héritent de QMainWindow.MainGUI a des dépendances avec tous les autres fichiers se trouvant dansapplication pour la simple raison que chacune de ces classes participent àl’élaboration de l’interface.

ActionsGUI : Nous avons rassemblé ici toutes les méthodes permettantd’agir sur la video, c’est à dire son chargement, et toutes les actions en rap-port avec la manipulation de la séquence vidéo (play, pause, next, previous,stop). Pour cela, ActionsGUI a des dépendances avec toutes les classes, ex-cepté les classes concernant les différentes représentations, puisqu’elles sontgérées par DataGUI. Celles-ci sont dues au fait que les actions développéesici ont besoins d’informations calculées et/ou obtenues grâce aux méthodesdes autres classes (telle que le nombre d’image par seconde défini, nécessairepour l’action « play() »). Le cas de ThreadDisplay est différent, cette dé-pendance est du à notre besoin de rapidité concernant le temps de réponseet la vitesse d’affichage. ThreadDisplay nous permet donc d’effectuer les ac-tions de manière plus efficace. La dépendance à la classe Exception a poursimple but de répondre à notre besoin de robustesse. En effet, nous avonsbesoin d’effectuer des relevés d’exceptions quand c’est nécessaire, celles-ciétant définit dans la classe Exception.

Settings : Comme son nom l’indique, cette classe s’occupe de toutes lesactions concernant les réglages. Ceux-ci concernent la vitesse d’affichage, etla résolution des images. Nous avons préféré créer une classe Settings à partafin de permettre un ajout aisé de nouveaux paramètres de réglages pourrépondre à notre besoin d’extensibilité. De plus, nous avions prévu des ré-glages supplémentaires pour certaines formes (telle que la taille de la grillede voxel utilisée pour l’enveloppe volumétrique et le squelette cinématique),mais par manque de temps nous n’avons pas pu implémenter d’autres repré-sentations que la silhouette. C’est pourquoi nous avons préféré ne laisser queles réglages que l’on utilise. Cette classe ne possède comme dépendance quela classe MainGUI et Exception. La première est nécessaire pour accéder auxdifférents objets composant l’interface. La dépendance à Exception se justifiede la même manière que précédemment.

Viewer : Afin de permettre des mouvements de caméras dans les différentsmodèles en trois dimensions, nous avons créé une classe Viewer qui hérite deQGLViewer. La silhouette et la séquence vidéo de depart ne sont qu’en deuxdimensions, mais nous les affichont également avec Viewer, d’autant plus queles mouvements de caméras (qui n’ont pas de réel intérêt sur une image endeux dimension) peuvent être figés. Cette classe définit un objet permettant

39

d’allier QT et la bibliothèque openGL. Cette dernière est simple d’utilisationet très utile pour afficher ce que l’on souhaite à l’écran, aussi bien en deuxdimensions qu’en trois. Viewer ne comporte aucune dépendance.

ThreadDisplay : Pour obtenir un temps de réponse suffisament valable,ainsi que facilité et accélérer les différentes actions de l’interface lié à l’affi-chage des séquences vidéo, nous avons créé une classe ThreadDisplay. Celle-cihérite de la classe de QT QThread qui gère les threads avec les objets de la bi-bliothèque QT. La classe ThreadDisplay dépend des classes MainGUI, Dataet Exception. Les objets (des Viewer) qui afficheront les séquences sont défi-nis dans la classe MainGUI, c’est pourquoi cette dépendance est nécessaire.La classe Data quant à elle est justifiée par le fait que toutes les données desséquences sont gérées par elle. Enfin, différents problèmes peuvent survenirau sein de cette classe, c’est pourquoi la classe Exception est requise.

Strings : Dans le but d’avoir un accès simple à la plupart des chaines decaractères apparaissant dans l’interface, nous avons créé une classe permet-tant de les définir directement. Cette classe ne possède aucune dépendance.

5.2.2 Data

Data regroupe toutes les classes permettant de récupérer les données néces-saires aux différentes étapes de la reconstruction du squelette humain ainsique leur gestion, et les méthodes permettant de les obtenir.

40

Data : Il nous fallait une classe permettant de gérer les différents typesde données, et qui donne un accès simple à celles-ci pour toutes les classes.Nous avons créé une classe Data permettant de gérer toutes les images etles répertoires utilisées pour le traitement, et qui donne un accès au nombred’image composant la vidéo, au chemin amenant au répertoire de la video,et aux images. Le constructeur de Data n’est appelé qu’une fois, lors duchargement des images afin de garder en mémoire dans des tableaux desinformations citées précédemment. La classe Data ne comporte que deuxdépendances, qui sont Exception et MainGUI. La justification de celles-ciest la même que précédemment. Nous avons choisi des tableaux car ils sontsimples d’utilisation et suffisament rapide d’accès pour notre utilisation.

DataGUI : Pour nous permettre de gérer les différentes formes et d’effec-tuer les différentes initialisations, nous avons créé la classe DataGUI. Ellene contient actuellement que les méthodes concernant l’extraction de sil-houette. Elle se charge de gérer l’accès aux objets Silhouette, ImageBack etData. Cette classe comporte six dépendances. Tout d’abord MainGUI pouraccéder à certains objets de l’interface, et Strings pour accéder à différenteschaines de caractères apparaissant dans l’interface. Puis, Exception pour gé-rer les exceptions et les afficher. La classe Data est également nécessaire, afind’accéder aux images et aux répertoires. Aussi, DataGUI dépend de toutesles classes permettant d’obtenir les différentes représentations, telle que lasilhouette.

Cette partie regroupe également les différents types de réprésentations,qui sont également traités comme des « types de données ». Nous avons crééune classe objet par type de représentations, à savoir Silhouette, VoxelGrid,Skeleton (les classes VoxelGrid et Skeleton ne sont malheureusement qu’enprojet, et ne seront pas présenté ici). Les classes de celles-ci ont pour butde les définir et de proposer les méthodes permettant de les obtenir(e.g lafonction extract() de la silhouette). Actuellement seule la classe »Silhouette« est exploitable, les autres représentations n’ayant pas été implémentéespar manque de temps.

Silhouette : L’extraction de silhouette fait parti des représentations de-mandées. Nous avons créé cette classe dans le but de construire les sil-houettes. Cette classe contient la méthode d’extraction, ainsi qu’une fonc-tion permettant d’obtenir les images de fond (ImageBack). Silhouette dépenddonc de ImageBack, afin de pouvoir réaliser l’extraction, ainsi que de Data,pour permettre d’accéder aux images. Nous n’avons pas jugé utile d’effetuerde relevé d’exceptions dans cette classe, seuls les appels aux méthodes deData sont susceptibles de rencontrer des problèmes.

41

ImageBack : Comme nous l’expliquons dans notre chapitre sur les al-gorithmes utilisés, nous calculons ici les statistiques et les images de fondnécessaires à l’extraction de la silhouette. Pour accéder aux images, cetteclasse dépend de la classe Data.

Ce type d’architecture où l’on divise les méthodes de traitements en sous-classes et par type de données nous permet de répondre au besoin d’extensibilité.En effet, l’ajout d’une nouvelle méthode de traitement pour un type de don-née quelconque va nécessiter peu de modifications dans le code. Si le type dedonnée existe déjà, il faudra essentiellement ajouter une classe héritant d’untype de donnée existant et redéfinir les méthodes de traitement comme onle souhaite. Si le type de données n’existe pas, il faudra en créer un nouveauqui contiendra à son tour toutes les méthodes permettant de le traiter.Cette partie nous a posé de nombreuses difficultées, notamment parce queles données traitées sont nombreuses, mais également très diverses. De plus,nous n’avons implémenté au final que la partie extraction de silhouette. Parmanque de temps nous n’avons pu finir les classes VoxelGrid et Skeleton,mais nous avons préféré réaliser la structure que l’on souhaitait mettre enplace.

5.2.3 Cameras

Nous définissons ici des objets Cameras qui sont utilisés par les ActionsGUI.Une liste de Cameras est créée pour une question de facilité d’implémen-tation, en effet elle permet d’obtenir le nombre de caméras présentes dansla séquence vidéo chargée, et d’associer un numéro à chacune d’elles, afinde pouvoir les gérer individuellement. La classe Cameras comporte deux dé-pendances, Exception et MainGUI, justifiées de la même manière que pourSettings.

42

5.2.4 Exception

Afin de répondre à notre besoin de robustesse, nous avons implémenté plu-sieurs classes d’exceptions. Elles sont actuellement au nombre de six, mais enajouter de nouvelles de poseraient pas de soucis. Ces exceptions se contententde composer un message d’erreur. Chacune de ces classes hérite de Exception,afin de généraliser le traitement. La classe Exception se charge d’afficher lemessage d’erreur dans le rapport d’incident (onglet »Incidents Report « del’interface). Les méthodes et fonctions des classes précédentes peuvent ainsilever des exceptions contenues ici.

5.2.5 Comparaison avec l’architecture prévue

L’architecture prévue initialement n’a pas été totalement respectée. Eneffet, nous avions prévu que ce soit la partie application qui gère les ex-ceptions, alors que la plupart nos classes en ont besoin. Aussi, nous avionsprévu une classe abstraite de forme. Nous avons vite oublié cette idée, etnous avons simplement créé une classe par représentation, chacune d’elle hé-rite de la classe Data. Par manque de temps nous n’avons implémenté quela classe Silhouette. Peut-être avec plus de temps nous aurions mis en placeune généricitée dans l’utilisation des différentes représentations, mais nousavons préféré assurer l’utilisation de la silhouette plutôt que de commencerà mettre en place une classe générique. Toutefois cela reste un objectif pourl’usage futur de notre application.

43

5.3 Diagramme de séquence

Le diagramme de séquence suivant présente les différentes étapes qui sedéroulent durant un chargement de séquence vidéo.

5.4 Structures de données

Tout d’abord, du à l’utilisation du langage C++, nous avons été amenésà utiliser lorsque c’était nécessaire les types de données de la STL (« Stan-dard Template Library »), en particulier le type string qui est compatibleavec le type QString de QT. Au lieu d’utiliser des tableaux, nous avons tentéd’utiliser des vector de la STL, seulement l’accès et l’affectation d’une va-riable dans un tableau ont été plus aisées, c’est pourquoi nous utilisons destableaux, même si ils n’ont qu’une seule dimension.

Afin de nous familiariser avec QT, nous avons utilisé autant que possibleles différents types que proposent cette bibliothèque, par exemple pour l’accèsaux fichiers, avec QDir, QFile et QTextStream qui proposent des fonctionsappropriées aux traitements voulus. De plus les fonctions QT permettent degérer facilement les erreurs, ce qui participe à notre besoin de robustesse.Bien entendu, pour la création de l’interface, nous avons utilisé un grand

44

nombre d’objets de la bibliothèque QT, ce qui nous a permis de répondre ànotre besoin d’ergonomie.

En ce qui concerne le processus de calcul des représentations, nous avonsexploité un grand nombre de structure de la bibliothèque OpenCV, la plusutilisée étant IplImage*, qui est la structure générale d’une image sousOpenCV.Ceci nous a permis de facilement réaliser des traitements sur les images. Deplus les nombreux paramètres de cette structure nous permettent de jouersur la qualitée des images (telle que le nombre de bits codant chaque pixel) cequi nous permet, à travers des tests de trouver un compromis entre qualitéedu résultat et vitesse d’exécution.

45

Chapitre 6

Algorithmes

Dans cette section nous allons aborder les différentes méthodes d’extrac-tion de silhouette basées sur une soustraction de l’arrière-plan (SAP) parmodélisation statistique. La soustraction d’arrière-plan forme une grande fa-mille de techniques de detection de mouvement. De plus, elle est une desplus utilisées à cause de sa simplicité algorithmique et de sa complexité suf-fisament acceptable pour l’utilitée qu’on en a.

Nous allons uniquement présenter les algorithmes d’extraction de silhouetteet non pas ceux portant sur les autres représentations comme cela était prévucar nous n’avons pas pu les implémenter.

6.1 Méthodes existantes

Dans cette section nous allons présenter plusieurs techniques d’extrac-tion de silhouette, chacune d’entre elles possèdent des performances et unecomplexité différentes.

6.1.1 Méthodes SAP par modélisation statistique

Le principe de ces techniques reposent sur une estimation statistique dela scène, la silhouette sera detectée par la comparaison d’une image test, dite« témoin », et du modèle statique calculé auparavant. L’utilisation de cetteméthode nécessite tout de même certaines contraintes, les caméras utiliséespour filmer la scène doivent être immobiles, de plus la scène doit resterstatique (il ne doit pas y avoir de changement dans la scène (le fond)). Lesvariations de luminosités sont tolérées dans la mesure où elles ne sont pas tropbrutales. De plus cette méthode possède plusieurs types d’implémentationqui varient selon les capteurs utilisés pour capturer la scène.

46

Visible (2D) : Cette catégorie contient des méthodes de soustractiond’arrière-plan utilisant des images 2D dans le spectre visible. Un des mo-dèles de couleur le plus fréquemment utilisé pour la modélisation statistiqueest le RGB. Cet espace de couleur est modélisé par un cube où chacun desaxes du référentiel représente une composante de base, soient le rouge (R),le vert (G) et le bleu (B) comme le montre la figure ci-dessous. Une couleurparticulière est donc un point à l’intérieur (ou aux frontières) du cube et co-dée par trois nombres pouvant prendre une valeur comprise dans l’intervalle[0, 255].

Fig. 6.1 – Représentation graphique de l’espace RGB. ( source : http ://xa-vier.hubaut.info/coursmath/doc/thcoul/rgb.jpg)

La technique de base consiste à modéliser l’arrière-plan à partir de plu-sieurs images acquises séquentiellement. Pour chaque pixel de l’image, ainsique pour chacun des canaux (R, G et B), une moyenne et un écart-typesont calculés. Chaque pixel est classifié comme appartenant à la silhouetteou au fond. Lorqu’un pixel « test » doit être classifié, il faut tout d’abordlui soustraire la moyenne correspondante dans le modèle statistique. Il seraalors étiqueté comme un pixel appartenant à la silhouette seulement si lavaleur absolue du résultat dépasse un certain multiple de l’écart-type corres-pondant.

D’autres espaces de couleurs peuvent être utilisés pour la modelisationd’arrière-plan, comme YUV ou bien HSV. Ce dernier est souvent utilisé pourla détection de silhouette pour son invariance à la luminosité, il est representépar un cône (voir figure ci-dessous). L’axe principal V (Value) représente laluminance, elle varie entre 0 et 100% ; l’angle procure la couleur pure (teinte)

47

H (Hue) mais peut être normalisé et varier entre 0 et 100%. La distance parrapport à l’axe central fournit la saturation (i.e intensité de la couleur) S(Saturation) parfois appelée « pureté ».

Fig. 6.2 – Représentation graphique de l’espace HSV par un cône. (source :http ://www.aqra.ca/IMG/jpg/HSV_cone.jpg)

D’autres méthodes de SAP par modélisation statistique existent mais nesont pas traitées ici puisque leurs gains de performance et de complexité sonttrès nettement négligeables.

Thermographie infrarouge (2D) : Dans cette méthode d’extraction onutilise des images en niveau de gris en entrée. La valeur des pixels repré-sentent les températures observées dans la scène et capturées par un procedéde thermographie infrarouge. En ce qui concerne les algorithmes de détectionet de modélisation, ils sont quasiment identiques mis à part l’espace de cou-leur. En effet ici on ne traite plus qu’une seule composante ce qui simplifiele traitement de l’image. Le point fort de cette méthode est son invariance àla luminosité, car les valeurs représentent les températures observées et unchangement de luminosité n’agit pas sur ces valeurs, ce qui rend cette mé-thode robuste à un changement d’éclairage pendant la capture de la scène,permettant ainsi une utilisation nocturne. Son point faible réside dans le faitque le matériel nécessaire pour effectuer une capture thermographique infra-rouge est très couteux. Depuis quelques années des nouveaux systèmes plusabordables commencent à apparaître et permettront dans quelques années laconception de systèmes thermographique infrarouge à un prix relativementabordable. De plus les images capturées ont une résolution très faible ce quiprovoque une perte importante d’information de l’image.

48

Information de profondeur (3D) : L’utilisation d’informations tridi-mensionnelles (e.g capteur stéréoscopique) permet la réalisation d’une sous-traction d’arrière-plan très efficace. Pour cette méthode nous avons besoin,comme pour les méthodes précédentes, de calculer un modèle statistique del’arrière-plan. Dans ce cas le modèle statistique va contenir des valeurs dedistances entre les différentes composantes de la scène et la caméra. Un pointsera classifié comme appartenant à la silhouette lorsqu’il sera à une distancedifférente de celle trouvée dans le modèle statistique. Cependant cette mé-thode necéssite énormément de puissance de calcul et du matériel spécialiséet très couteux.

6.1.2 Méthode de soustraction de deux images consécutives

Cette méthode est extrèmement simple et possède une complexité ex-cellente, son principe est simple, il suffit de faire une soustraction de deuximages consécutives. Plus précisement on soustrait une image acquise à uninstant Tn par une autre prise à l’instant Tn+k, où k vaut géneralement 1.S’il n’y a aucun mouvement dans l’image Tn+k, l’image resultante va êtrevide, ce qui s’explique par le fait qu’il n’y a pas de changement radical decouleur et d’intensité des pixels. Ces deux images sont quasiment identiques,la seule différence qu’elles possèdent est du au bruit généré par les equipe-ments de capture. Dans le cas où une image contient un mouvement la valeurdes pixels « frontières » devraient changer radicalement de valeur ce qui aurapour résultat de faire apparaître les mouvements effectués dans la scène.

49

Fig. 6.3 – Résultat obtenu par une soustraction de deux images consécutives.a)image(temps t0) b)image(temps t1) c)résultat de la détectiondu mouvement non seuillé.

Cette méthode possède de nombreux avantages, elle nécessite très peude ressources en terme de puissance de calcul. De plus elle ne nécessite au-cune initialisation de modèle contrairement aux méthodes statistiques. Cecila rend très rapide, une soustraction demandant très peu de calcul, cette mé-thode serait donc parfaite au niveau du temps d’exécution et de la complexitépour une utilisation en temps réel. Cependant les résultats obtenus ne sontpas aussi éloquants que ceux utilisant un modèle statistique d’arrière-plan.Pour pouvoir exploiter ces résultats et afin de déterminer une silhouette, untraitement supplémentaire, plus particulièrement un seillage, est indispen-sable. Malgrès cela, la qualité du résultat n’est pas assez satisfaisante pourque nous retenions cette méthode.

6.1.3 Méthode retenue

Pour determiner quelle méthode nous allons utiliser, un compratif desavantages et inconvenients des différentes méthodes est necessaire, bien qu’au-cune d’entre elles ne respecte complètement les exigences de nos besoins.Nous allons voir laquelle s’en approche le plus.

Parmi les méthodes comparées ici nous pouvons déjà exclure la méthodeSAP (infrarouge 2D), les contraintes matèrielles nous empêchant de l’utili-ser. Nous avons besoin d’images capturées avec un equipement d’imagerieinfrarouge, hors nous travaillons avec des images RGB. En ce qui concernela méthode SAP (visible 3D), elle respecte nos besoins en ce qui concerne

50

Méthode Avantages Inconveniants

SAP - Algorithme peu complexe - Ombres non rejetées- Résultats clairs - Initialisation/scène statique

(visibe 2D) - Classification simple

SAP - Idem (Visible 2D)Thermographie - Eclairage faible ou nul - Initialisation/scène statique(infrarouge 2D) - Robustesse à l’eclairage - Coùt élevé du matèriel

- Robustesse aux ombres - Faible résolution des images

SAPinformation de - Information de profondeur -Initialisation/scène statique

profondeur -Robustesse aux ombres - Complexité et calculs(visible 3D) - Plusieurs caméras

Soustraction -Flexibilité d’utilisation - Mouvement obligatoired’images - Souplesse d’initialisation - Détection incomplète

consécutives - Faible complexité de - Ombres non rejetéesl’ algorithme de base

Tab. 6.1 – Tableau comparatif des différentes méthodes de détection desilhouette

l’élimination des ombres et sa précision, mais cependant sa complexité élevéeet la puissance de calcul nécessaire à son utilisation ne correspond pas à noscritères. La détection de la silhouette par soustraction d’images consécutivespossède d’excellents avantages tant sur le plan de la souplesse d’initialisationque sur le plan de la faiblesse de la complexité de son algorithme. Cependantle manque de précision de sa détection est un défaut trop important pourqu’on la retienne. Nous allons donc utiliser la SAP par modélisation statique2D, ceci dans le spectre visible de l’espace RGB. A cette SAP, on associe uneSAP (visible 2D) dans l’espace HSV, afin de supprimer les ombres.

6.2 Description de l’algorithme utilisé

La méthode retenue de soustraction d’arrière-plan regroupe les tech-niques basées sur l’utilisation d’images 2D dans le spectre visible. Celle-ciapparait comme la plus interessante pour notre projet. L’algorithme de sous-

51

traction d’arrière-plan (visible 2D) possède deux étapes importantes. Toutd’abord une initialisation obligatoire de notre modèle statistique puis unedétection de la silhouette. Il est important de préciser que les données quenous allons calculer vont être stockées dans des images, rendant ainsi leuraccès plus facile.

Initialisation : L’initialisation possède deux phases. Dans un premiertemps nous allons modéliser l’arrière plan avec les N premières images dela séquence vidéo. A partir de ces images, on calcule l’intensité moyennede chaque canal de chaque pixel. La formule (1.0) nous permet de calculerl’intensité moyenne d’un pixel donné .

µc(x, y) = 1N

∑Ni=0 Iic(x, y) (1.0)

où I est la Iième image d’initialisation , N quantités d’image utilisées, cle canal sélectionné.

Ensuite nous allons calculer l’écart-type ρ pour chaque pixel (i.e pourchacun de ses canaux).Cet interval va nous servir de seuil de détection dansla second étape. Cette opération nécessite habituellement le stockage des Npremières images. Pour contourner cette contrainte, reduire le consommationd‘espace mémoire et la puissance de calcul, deux accumulateurs sont utilisés.Soient S(x, y) pour stocker la somme des intensités des pixels et SC(x, y)pour emmagasiner la somme des carrés. Ces deux accumulations vont êtreexecutées successivement ce qui ne nécessitera donc qu’un seul des N imagesutilisées pour modéliser l’arrière-plan.

Une fois cette phase finie, les écarts-types peuvent alors être calculés enappliquant l’équation 1.1. Par ailleurs, nous réutilisons S(x, y) pour le calculde SC(x, y) ce qui nous évite des opérations supplémentaires et superflues.

ρc(x, y) =√

SCc(x,y)N − (Sc(x,y)

N )2 (1.1)

Extraction de l’avant-plan : Pour extraire une silhouette dans une image,il faut dabord lui soustraire le modèle de l’arrière-plan. Chaque pixel dontla différence en valeur absolue dépasse la valeur α × ρ est ensuite classifiécomme étant un pixel appartenant à la silouette. La variable α représenteune certaine fraction de l’écart-type. Ce paramètre va nous permettre defixer un niveau d’exclusion, rendant l’extraction plus ou moins précise selonla valeur de ce paramètre. Cette valeur sera située dans l’interval [2.0,4.0],passer outre cet interval engendrera une perte de précision significative. Unmasque de la silhouette peut alors être généré pour chaque canal à l’aide del’équation 1.2 :

mc(x, y) =

{1 si |Ic(x, y)− µc(x, y)| > αρc(x, y)

0 autrement(1.2)

52

où mc(x, y) représente le masque de la silhouette pour un canal c etIc(x, y) l’image d’entrée à analyser.

Dans cette équation nous représentons le masque de la silhouette pour unseul canal, dans notre projet nous utilisons des images avec 3 canaux (RGB),nous allons donc combiner les trois masques mr(x, y), mg(x, y),mb(x, y) àl’aide d’un opérateur « ET » logique. Ainsi lorsque l’appartenance d’un pixelest détectée sur les 3 canaux on classifie le pixel comme appartenant à lasilhouette.

M(x, y) = mr(x, y) ∪mg(x, y) ∪mb(x, y) (1.3)

Une fois cette opération complétée nous allons nous attaquer à la sup-pression des ombres. Pour ce faire nous allons convertir l’image à traiteret le modèle statistique d’arrière-plan dans l’espace HSV. Nous allons doncsoustraire de notre nouvelle image à traiter le modèle statistique convertidans l’espace HSV. Les pixels ombrés devraient posséder une couleur quasi-identique avec une luminosité plus faible. Nous allons utiliser la formule 1.4pour compléter le masque de la silhouette.Ici

mh(x, y) = |Ihsvh(x, y)− µhsvh(x, y)| < seuilH

ms(x, y) = |Ihsvs(x, y)− µhsvs(x, y)| < seuils

mv(x, y) = |Ihsvv(x, y)− µhsvv(x, y)| > seuilV

où mh(x, y) représente le masque hsv de la silhouette pour le canal H(teinte),ms(x, y) représente le masque hsv de la silhouette pour le canal S (Saturation)mv(x, y) représente le masque hsv de la silhouette pour le canal S (Luminance)Ihsvh(x, y) l’image d’entrée dans l’espace HSV pour le canal H.Ihsvs(x, y) l’image d’entrée dans l’espace HSV pour le canal S.Ihsvv(x, y) l’image d’entrée dans l’espace HSV pour le canal V.

Mhsv(x, y) =

{0 simh(x, y) ∪ms(x, y) ∪mv(x, y)

1 autrement

(1.4)Les seuils ont étaient fixés de manière à avoir un rendu maximal, seuilH=12,

seuilS=25, seuilV=0.

Une fois ces deux opérations complétées, il reste nécessaire d’effectuercertaines opérations morphologiques afin d’éliminer le bruit et les faussesdétections. Pour ce faire, nous appliquons une érosion puis une dilation,puis, deux dilatations et deux érosions, et finalement deux érosions et deuxdilations. Lors de nos tests, nous nous sommes rendus compte que l’applica-tion de deux érosions suivi de deux érosions supplémentaires n’avait pas les

53

effets que quatre érosions successives. De ce fait le nombre d’opérations mor-phologiques se trouve élevé, ce qui a des conséquences sur la complèxité denotre algorithme. Finalement, l’écart-type et le modèle statistique ne sontpas ajusté ou mis à jour pendant l’exécution de l’algorithme, mis à partlorsque l’on change le nombre d’images que l’on utilise pour initialiser lemodèle statistique.

6.3 Implémentation logicielle

Afin de réaliser la soustraction de l’arrière-plan, nous avons créé deuxclasses C++ en utilisant certaines fonctions de la bibliothèques OpenCVd’Intel, la classe ImageBack et la classe Silhouette.

6.3.1 ImageBack

La classe ImageBack possède les fonctions nécessaires pour initialiseret mettre à jour le modèle statistique. Afin de pouvoir interagir avec cetteclasse, certaines fonctions ont été créées. Principales fonctions publiques :

On rappelle que le modèle statistique ainsi que les écarts-types sont sto-ckés dans des image de type IplImage* (type de la bibliothèque OpenCV).

– getIntervalImage : Récupération de l’image contenant les écarts-types.– getAverageImage : Récupération du modèle statistique.– getAverageHsvImage : Récuperation du modèle statistique converti

dans l’espace HSV.– getBgImage : Récuperation d’une image de fond ou le personnage n’ap-

paraît pas. On lui applique une extraction, puis une soustration decelle-ci sur le masque de la silhouette nous permet de supprimer ungrande partie des bruits.

– setBgImage : Extraction effectuée sur une image ne contenant aucunacteur, afin d’obtenir un masque des bruits les plus persistants.

– setNbrOfBgImages : Modifie le nombre d’images utilisé pour initialiserle modèle statistique, ce qui nous permet de mettre à jour l’ensembledes statistiques de l’arrière-plan

Toutes ces statistiques sont calculées à l’initialisation et sont conservéesen mémoire pendant toute la durée de l’utilisation de l’application.

Optimisation : Il faut rappeler que la scène a été capturée sous plusieursangles (plusieurs caméras), ce qui implique que pour chaque caméra un mo-dèle statistique, un écart-type seront calculé. Ceci rend l’initialisation pluslongue et plus complexe, l’utilisation de threads devrait nous permettre d’ac-croitre la vitesse d’initialisation.

54

6.3.2 Silhouette

Cette classe contient les fonctions pour extraire une silhouette, elle contientune seul fonction publique. La première extraction se fait lors de l’appel auconstructeur qui va retourner le masque de la silhouette. La fonction Upda-teSilhouette(uint newImgCpt) ; va nous permettre d’incrémenter le numérode l’image à traiter.

Optimisation : L’application successive d’opérations morphologiques surle masque augmente le temps de calcul et donc la complexité de cette classe,il nous a parut évident qu’une nouvelle méthode de nettoyage du bruit nouspermettrait de réduire considérablement la complexité et le temps de calculd’une extraction.

55

Chapitre 7

Tests et résultats

7.1 Tests sur l’extraction de silhouette

Dans cette section, nous allons pouvoir observer quelques résultats obte-nus avec la méthode de soustraction d’arrière-plan par modélisation statis-tique (SAP visible 2D), ainsi que certains tests effectués en faisant varier lesparamêtres de notre algorithme.

Dans un premier temps, nous verifions si la SAP fonctionnne correcte-ment.

56

Fig. 7.1 – Test génération modèle statistique (visible2D)a)image originale b)modèle statistique

On génère le modèle statistique on voit bien ici qu’il est calculé correc-tement il ressemble beaucoup à l’image originale, on ne tient pas compte dupersonnage mais de l’arrière-plan. Quelques légères différences apparaissentsur la partie inférieure de l’image au niveau du cercle blanc. Ces petites dif-férences sont normales, il faut se remémorer que le modèle statistique est la« moyenne » de toutes les images de fond. Et ces différences correspondentaux bruits générés par les caméras.

Extraction de silhouette.Nous appliquons une extraction sur une séquence contenant un être hu-

main, ainsi nous allons pouvoir observer le resultat de la méthode SAP visible2D.

57

Fig. 7.2 – Test extraction de silhouette a)image origine b)résultat de l’ex-traction SAP (visible2D)

On peut observer le résultat sur l’image b), on constate que la silhouetteest effectivement extraite mais cependant les ombres résistent à notre mé-thode d’extraction. Pour la suite de notre projet nous avons besoin d’extrairedes silhouettes de bonnes qualitées où l’ombre n’apparait pas, nous allonsutiliser les images de l’espace HSV (image originale en HSV et modèle sta-tistique en HSV). Pour que les deux methodes se complètent on va inclurele test sur les images HSV dans le test des images RGB tels que :

si M(x,y) = 1 (équation 1.3)alors

si M_hsv(x,y) =0 (équation 1.4)alors I(x,y) appartient à silhouette

sinon I(x,y) n’appartient pas à silhouettefinsi

sinon I(x,y) appartient à silhouettefinsi

I : Image d’entrée M_hsv : Masque HSV de la silhouette M : Masque RGBde la silhouette

58

Fig. 7.3 – Variation des seuils H,S,V(seuilR,seuilG,seuilB,seuilH,seuilS,seuilV)a) (0.5, 2.0, 1.0, 12.0, 25.0, 0.0) ; b) (2.0, 2.0, 2.0, 2.0, 25, 0)c) (2.0, 2.0, 2.0, 12.0, 8.0, 0.0) ; d) (3.0, 3.0, 3.0, 10, 20,1.0)

On voit bien sur ces figures les effets des seuils sur la précision de la sil-houette, le seuil S agit plus particulièrement sur la detection de l’ombre plusil est petit et plus l’ombre est concidérée comme appartenant à la silhouette,le seuilH agit plus particulièrement sur l’arrière-plan lorqu’il est trop petit,il laisse apparaître des pixels de l’arrière-plan alors que s’il est trop grand lerésultat sera très dégagé.

nettoyage des bruitsAfin d’obtenir une silhouette d’une bonne précision nous allons appliquer

59

des opérations morphologiques sur cette dernière afin d’en supprimer unmaximum.

Fig. 7.4 – application d’opérations morphologiquesa) 1 érosion et 1 dilatation b)2 dilatation et 2 érosions

60

Fig. 7.5 – application d’opérations morphologiquesa) 1 érosion, 1 dilatation, 2 dilatations et 1 érosionb)1 érosion, 1 dilatation, 2 dilatations, 1 érosion, 2 érosions et 2 dilatations

On se rend compte que selon l’ordre dans lequel nous appliquons cestransformations, le résultat ne sera pas le même. Nous nous sommes aussiaperçu que effectuer deux opérations successives

7.2 Risques encourus

La réalisation d’un projet d’une telle envergure pour la première fois dansnotre scolarité nous fait faire face à une série de risques. Le risque majeurd’un tel projet est justement de ne pas arriver à le finir. C’est malheuresementnotre cas. Nous reviendrons sur ce risque dans le chapitre Bilan

61

Chapitre 8

Extensions

8.1 Etat des lieux

A ce jour, certaines fonctionnalités sont complètes, mais malheuresement,d’autres non. Les fonctionnalités ci-dessous sont complètes :

– Le chargement des images.– L’affichage des images.– L’affichage de la silhouette.– Le changement de vue de la caméra.– Le chargement des paramètres de calibration des caméras.

Seulement, par manque de temps et à cause de la difficulté du projet quenous avons mal géré, nous n’avons pas pu en arriver à bout. Dans le chapitresuivant, nous expliquons nos difficultés et les raisons du retard que nousavons pris dans le dveloppement de l’application.

Voici la liste des fonctionnalités prévues mais non implémentées, ou encoreincomplètes :

– Les méthodes de représentations 3D restantes : représentation volumé-trique, grille de voxel amincie et squelette géométrique.

– L’affichage de ces visualisations.– L’affectation des réglages. Nous avons néanmoins implémenté le coeur

des réglages avec des fonctions de sauvegarde, de chargement, de mo-dification des paramètres, mais par manque de temps et parceque cen’était pas une priorité, nous n’avons pas encore pu réaliser l’affecta-tion des réglages sur les visualiseurs.

– Nous avions prévu une « checkbox » afin de pouvoir mettre une desreprésentations en plein écran, mais nous le l’avons pas implémenté.Toutefois nous l’avons laissé dans l’interface pour un usage ultérieur.

62

Comme vous pouvez le constater, nous n’avons pas encore eu le tempsd’implémenter des fonctionnalités importantes pour l’extraction du squelette.Nous allons tout de même essayer d’ajouter quelques fonctionnalités d’ici laclôture définitive du Projet de Programmation.

8.2 Extensions possibles

Malgré le manque de fonctionnalités et la difficulté d’implémentation,nous prévoyons de revenir sur le projet dans un avenir proche, à la vue del’intêret de ce sujet. Notre but sera donc simplement de finir le développe-ment du logiciel tel que nous l’avions prévu. Nous pensons aussi à intégrerune hiérarchie de threads pour le calcul des représentations à afficher, afin depermettre un pré-chargement et un affichage plus rapide comparé au tempsde réponse actuel. Une fonctionnalité interessante serait de pouvoir enregis-trer n’importe quelle représentation sous forme d’images afin de construireun flux vidéo lisant les images. Ceci serait prévu en vue d’une réutilisationdu squelette géométrique en squuelette d’animation par exemple.

63

8.3 Planning

Nous avons éprouvé quelques difficultés à respecter le planning initia-lement annoncé. Tout d’abord, l’apprentissage des bibliothèques OpenCV,QGLViewer et QT nous a pris un temps bien plus important que prévu. Dansun premier temps, la bibliothèque OpenCV, meme si une documentation re-lativement détaillé existe, elle n’est pas particulièrement claire, ni accessible.Ensuite, QT et QGLViewer nous ont posé des difficultés du fait que ce sontdes outils récents. De ce fait, les documentations trouvées ne correspondentpas toujours avec les versions que l’on utilise, ou bien ne sont pas suffisa-ment précises. De plus, nous n’avions fait que très peu de programmation enlangage C++, quelques subtilitées qui diffèrent du langage JAVA (que nousavions beaucoup plus utilisé auparavant) ou du langage C nous ont pris dutemps supplémentaire.

Chapitre 9

Bilan du projet

Après avoir travailler sur ce projet plusieurs mois, nous revenons sur lesdifférentes étapes de sa production, de ce que nous sommes satisfait d’avoiraccompli et ce que nous aurions voulu faire différement.

9.0.1 Organisation et difficultées

Le PdP (Projet de Programmation) nous a mis pour la première fois de-puis le début de nos études dans une réelle situation de projet à long terme(relatif à la durée des semestres). Contrairement aux projets que nous avionseffectué précédemment, certains problèmes récurrents, telle que la difficultéeà s’organiser et à plannifier efficacement les différentes tâches à affectuer, oubien le soucis du travail en groupe, se sont avérés bien plus pénalisant qu’àl’accoutumé. En effet, nous avons surement mal jugé la quantitée de tra-vail à effectuer, ou plus exactement, sous-estimé la difficulté des différentestâches. Par exemple, nous avions initialement prévu que l’algorithme d’ex-traction de silhouette et toute la classe la concernée serait achevés en un peuplus d’une semaine. Or, les différentes méthodes d’extraction auquelles nousavions pensé n’ont pas donné de résultat suffisament convaincant. Il nous adonc fallu trouver différentes façon de procéder, pour finir par trouver celleactuellement implémentée. Ensuite, nous n’avions jamais effectué de travailen équipe à quatre, tous les autres projets que nous avions l’habitude defaire étaient réalisés à deux. La répartition des tâches n’a certainement pasété aussi efficace qu’il aurait fallu. Il nous est arrivé plusieurs fois de nousretrouver à travailler à plusieurs sur une même classe, au lieu de disperserde manière plus judicieuse les effectifs.

9.0.2 Utilisation des bibliothèques

Les bibliothèques que nous avons utilisées, à savoir principalement QT4et OpenCV, furent difficiles à appréhender. Leur apprentissage fut laborieux,mais représente une des satisfactions du projet. En effet, même si certaines

67

difficultées se posent toujours quant à leur utilisation, il s’avère qu’elles nousseront très certainement utiles prochainement. De plus, nous suivons tousactuellement un cursus en master Image&Son, ces bibliothèques sont doncidéales pour l’orientation que nous avons choisi.

9.0.3 Conlusion

Ce projet fut très enrichissant, pour les points vus précédemment, etprincipalement pour la découverte du travail et de l’implication nécessairepour un projet conséquent. Le temps est un facteur primordial, que l’onse doit de maitriser afin de pouvoir effectuer tout le travail prévu. Nousregrettons seulement de ne pas avoir pu réaliser toutes les fonctionnalitésque nous avions prévu, limitant quelque peu l’usage de l’application. Leprojet nous ayant vivement intéréssé, nous aurions voulu disposer de tempssupplémentaire afin d’achever toutes les fonctionnalités initialement prévues,d’autant plus que nous nous en sentons capables.

Bibliographie

[BB04] D. Brunner and G. Brunnett. Automatic bone generation for cha-racter animation using the discrete medial axis transformation.In Tagungsband Virtuelle und Erweiterte Realität, 1. Workshopder GI-Fachgruppe VR/AR,, pages 339–350, 2004.

[Blu64] H. Blum. A transformation for extracting new descriptors ofshape. In In Symposium on Models for the Perception of Speechand Visual Form, volume 2, pages 139–146, 1964.

[CKBH00] Kong Man Cheung, Takeo Kanade, J.-Y. Bouguet, and M. Holler.A real time system for robust 3d voxel reconstruction of humanmotions. In Proceedings of the 2000 IEEE Conference on Compu-ter Vision and Pattern Recognition (CVPR ’00), volume 2, pages714–720, June 2000.

[FB05] Jean-Sébastien Franco and Edmond Boyer. Fusion of multi-viewsilhouette cues using a space occupancy grid. Technical Report5551, INRIA, April 2005.

[Fra05] Jean-Sébastien Franco. Modelisation 3D a partir de silhouettesimages. PhD thesis, Institut National Polytechnique de Grenoble,Grenoble, France, December 2005.

[Kno07] David Knossow. Paramétrage et Capture Multicaméras du Mou-vement Humain. Phd. manuscript, INPG, INRIA, 655 avenue del’Europe, 38330 Montbonnot, April 2007.

[Lau94] A. Laurentini. The visual hull concept for silhouette-basedimage understanding. IEEE Trans. Pattern Anal. Mach. Intell.,16(2) :150–162, 1994.

[Lem03] Alexandre Lemieux. Système d’identification de personnes parvision numérique. Master’s thesis, Décembre 2003.

[MBR06] Clément Ménier, Edmond Boyer, and Bruno Raffin. 3d skeleton-based body pose recovery. In Proceedings of the 3rd InternationalSymposium on 3D Data Processing, Visualization and Transmis-sion, Chapel Hill (USA), june 2006.

[Mer04] Djamel Merad. Reconnaissance 2D/2D et 2D/3D d’objets à partirde leurs squelettes. PhD thesis, 2004.

69

[PK99] Kalman Palagyi and Attila Kuba. Directional 3d thinning using 8subiterations. In DCGI ’99 : Proceedings of the 8th InternationalConference on Discrete Geometry for Computer Imagery, pages325–336, London, UK, 1999. Springer-Verlag.

[TFJT] A Trouve, S. Fayolle, S. Juillard, and A. Trebuchet. Technicalreport.

Annexe A

Utilisation de l’application

Nous avons taché de réaliser une application simple d’utilisation, seule-ment le nombre de paramètres et de fichiers nécessaires à son fonctionnementcomplique quelque peu son utilisation. Les images des séquences vidéos desdifférentes caméras doivent respecter une certaine organisation. Un dossierracine, dans lequel se trouve un dossier pour chacune des caméras de la sé-quence que l’on souhaite traiter. Dans chacun des dossiers de caméras setrouvent toutes les images de la caméra concernée, classées par chronologiede la séquence. Le dossier racine ne doit contenir que les dossiers des ca-méras, si un autre fichier et/ou dossier est présent dans le dossier racine, ilsera interprété comme une caméra par l’application, ce qui aura pour consé-quence de provoquer un mauvais traitement. Nous ne sommes pas parvenusà éviter ce genre de comportement. Les fichiers de contenant les matrices deprojections des caméras, ainsi que leurs coordonnées, ne nécessitent aucuneorganisation particulière.

Mis à part ce problème d’arborescence des fichiers, l’application est rela-tivement simple d’utilisation. Grâce à notre gestion des exceptions, l’appli-cation n’a aucune raison de se terminer anormalement, même si l’on essaitd’effetuer des actions illogiques.

Une fois l’application lancée, nous avons la possibilité de régler certainsréglages, telle que le nombre de frame par seconde. Malheureusement nousn’avons pas eu le temps de rendre utile ce type de réglage. Il est aisé demettre des réglages par défaut. Les réglages courant peuvent être enregistrésdans un fichier à l’aide de l’action (nous avons créé un type ».stg « ), et cefichier pourra être chargé plus tard. Toutes ces commandes sont accessiblesdans »Settings « se trouvant dans la barre de menu, ou bien en utilisant lesraccourcis clavier associés, ou encore avec les boutons de la barre d’outils.

71

Nous avons aussi la possibilité de charger les paramètres des caméras (ma-trice de projection et coordonnées de chacune des caméras). Les différentesinformations relatives aux caméras sont disponibles dans l’onglet »Camera« (ou les raccourcis clavier, la barre d’outils). Par manque de temps nousn’avons pas exploité ces données. Aussi, la configuration du nombre de ca-méras utilisées (nombre de point de vue de la séquence) s’effectue durantle chargement des paramètres des caméras. Nous avons mis 8 caméras pardéfaut car c’est le nombre qui a été utilisé dans la principale séquence surlaquelle nous avons travaillé.

Enfin, afin de visualiser une séquence vidéo ainsi que son extraction (lesautres représentations n’étant pas disponibles), il est nécessaire de chargerles images. Les commandes se situent dans l’onglet »File « (raccourci clavieret bouton dans la barre d’outils sont également disponibles). Un fenêtre dedialogue demande alors de sélectionner le répertoire ou se trouve les dossiersdes images de chaque caméra. Après avoir sélectionné le dossier, une fenêtrede dialogue apparaît, il faut entrer un entier en paramètre. Ce nombre cor-respond au nombre d’images qui seront utilisées pour calculer les statistiquesde l’image de fond (la démarche est expliquée dans le chapitre Algorithme).Ce nombre influe énormément sur la vitesse de calcule, et évidemment, plusil est important, plus les calculs seront long à s’effectuer.

Une fois toutes ces actions accomplies, on peut observer la séquence video,ainsi que les silhouettes obtenues. On peut controler les séquences à l’aidedes commandes dans le menu »Video Stream « (des raccourcis clavier et desboutons dans la barre d’outils sont disponibles). Nous avons mis en placeles commandes »Stop « , »Pause « , »Play « , »Next Frame « , et »PreviousFrame «