Rapport de projet tutoré

Transcription

1 Cité Descartes 5, bd Descartes Champs sur Marne MARNE LA VALLEE Ecole d'ingénieur IMAC 9 cours du Danube Serris Ecole d'ingénieur IMAC 2ème année Interactive Music Sensation Année Universitaire Romain Troche Benjamin Frydman Anthony Giroud Benjamin Kusnierek Thomas Pachoud Arnaud Van Den Daele Tuteurs : Venceslas Biri Jocelyne Kiss Martin Laliberté Emmanuel Dahan

2 Remerciements Nous tenons à remercier Venceslas Biri et Jocelyne Kiss pour nous avoir guidé tout au long du déroulement de ce projet. Nous remercions particulièrement Pascal Chaudeyrac pour ses nombreux et précieux conseils. Nous remercions enfin toute personne ayant aidé de près ou de loin au déroulement de ce projet : l'équipe de thésards pour le prêt de matériels, l'équipe des gardiens pour leur disponibilité, la société Pitch pour ses bracelets et enfin Adrien et Julien pour leurs aides diverses.

3 Fiche de présentation du projet Le projet Interactive Music Sensation est un projet destine aux concerts de musique électronique. Il permet d appliquer en temps reel des effets sonores de maniere sensible. L artiste peut ainsi par l expression du mouvement de ses mains jouer et moduler des effets sonores. Cela lui permettra de proposer une interprétation originale de sa musique a chaque représentation. Objectifs Le programme doit a partir d'un flux vidéo en temps réel analyser les signes et les mouvements des mains. Plusieurs types de sons doivent alors être synthétisés en fonction d'une grammaire de signes prédéfinis et varier en fonction du mouvement des mains. Dispositif de l'application Une webcam est disposée à deux mètres de hauteur pour filmer les mains sur un fond uni. Une seconde webcam est disposée de face. Les webcams sont branchées sur deux ordinateurs distincts, eux-mêmes reliés en réseau. Le musicien doit porter un bracelet de couleur à chaque poignet et avoir un fond uni dans son dos. Méthodes utilisées - Traitement d'images sur un flux vidéo - Analyse des signes via un réseau de neurones - Synthèse sonore sous PureData via une interface OSC - Programmation en langage Java - Echanges des données en réseaux Travail effectué Un premier serveur a été programmé pour analyser le flux vidéo de la webcam de haut et envoyer le numéro correspondant aux signes effectués. Un second serveur analyse le flux vidéo de la webcam de face et envoie les coordonnées x et z des deux mains. Un client interfacé avec PureData récupère les données des deux serveurs, les modifies si besoin et envoie les données. Un patch PureData permet d'analyser les données reçues via le protocole OSC, de synthétiser un son en fonction du numéro de signe et de le moduler en fonction des coordonnées. Enfin une application permet l'apprentissage du réseaux de neurones à partir d'images binarisées représentant les deux mains. Résultats Les résultats actuels ne permettent pas une utilisation de l'application en concert. Mais une base solide et exploitable a été codée et permettrait, avec quelques améliorations, de créer une réelle interactivité lors des concerts de musique électronique.

4 Sommaire 1. Introduction Présentation du projet Le geste instrumental et les nouvelles technologies Geste musical Cahier des charges Description générale du projet Méthodes de travail Système de modules Planning Etudes de faisabilité Flux vidéo Détection des mains Binarisation Erosion et dilatation Détection des bracelets Séparation des deux mains Traitement d'une main Détection des points caractéristiques Squelettisation Orientation de la main Détection des signes : le réseau de neurones Le perceptron Algorithme d'apprentissage Implémentation Reconnaissance de formes Etude d'une application de reconnaissance de formes : lecture des codes postaux Réalisation d'un perceptron avec une image binarisée Cartes auto-organisatrices Traitement Sonores Définition des besoins Max/MSP et PureData Présentation Comparaison Communication avec l'application centrale Protocole TCP/IP Protocole Midi Protocole OSC Génération sonore dans le patch PureData Synthèse sonore additive Lecture d'échantillons Midi Source audio externe Effets Mise en oeuvre du projet Organisation de l'application /53

5 9 Dispositif matériel Choix du langage Lecture du flux de webcam Application d'apprentissage du réseau de neuronnes Application WebcamTop Application WebcamFace Application principale Rôle Chaîne de traitement Récupération des données des mains Formatage des données Envoie des données à PureData Interpolation Interface et fonctionnalités utilisateur Configuration réseau Activation du rendu sonore Implémentation Application PureData Fonctionnement Patch technique Patch musical Résultats Dispositif de test Résultats visuels et sonores Bilan Bilan humain Bilan technique Perspectives Conclusion /53

6 1. Introduction Dans le cadre de notre deuxième année d'école d'ingénieur IMAC, nous avons réalisé un logiciel de synthèse sonore intitulé Interactive Music Sensation. Ce projet a été développé par Romain Troche, Benjamin Frydman, Anthony Giroud, Benjamin Kusnierek, Thomas Pachoud et Arnaud Van Den Daele. Le projet est encadré par M. Biri, Mme Kiss, M. Laliberté et M. Dahan. Interactive Music Sensation est un projet destiné aux concerts de musique électronique. Il permet d appliquer en temps réel des effets sonores de manières sensible. L artiste peut ainsi, par l expression du mouvement de ses mains créer différents sons et les moduler. Le but est de proposer une interprétation originale de sa musique à chaque représentation. Une partie importante du projet a été de se documenter sur les techniques existantes en matière de reconnaissance de formes et de mouvements. Une découpe du projet en modules a permis une répartition des tâches en fonction des attentes de chacun au sein du projet. De nombreux tests ont été nécessaire afin de définir et d'implémenter les techniques les plus adaptées, selon différentes contraintes d'utilisation. La mise en commun de tout ceci, dans la dernière partie du projet a alors permis de réaliser les premiers tests fonctionnels de l application. 3/53

7 2. Présentation du projet 1 Le geste instrumental et les nouvelles technologies Pour commencer nous devons nous interroger sur la relation du corps à l'instrument et plus précisément sur la nature du geste instrumental. Dans la musique traditionnelle, le musicien a un rapport intime, voire charnel avec son instrument. Avec l'instrument traditionnel on trouve un lien direct entre jeu,physiologie et instrument. Par exemple en jouant du piano le musicien joue avec le poids de sa main. Le corps est en quelque sorte, le premier instrument. Or avec les nouvelles technologies la physiologie n'intervient pas, le corps est peu important : il n' y a plus de repère physiologiques. Il ne se produit plus désormais de relation entre l'artiste et son instrument. Que ce soit dans les techniques de synthèse ou de C.A.O il n'est question que du son et non plus du geste. La relation du musicien à la machine n'est pas directe. Celle-ci peut s'exercer de deux manières: soit à l'aide d'une entrée sortie(clavier,souris, écran)il s'agit alors d'une relation hardware ou matérielle ; soit à l'aide d'interfaces graphiques, il s'agit d'une relation de type software ou logicielle. Les interfaces avec l'ordinateur sont toutes uniformes : le rapport corporel est le même que ce soit pour la synthèse de son ou bien un traitement de textes. De plus avec les interfaces graphiques tout est possible, la synthése sonore n'impose plus aucune contrainte physique ce qui entraine aussi la disparition de l'existence même d'une relation permettant l'expression du geste instrumental. 2 Geste musical Theremin en 1920 a construit un instrument électronique dont on joue en déplaçant les mains à proximité d'une antenne. Le geste est exploité avec nuance sans toutefois qu'un contact physique ne soit établi. A travers cet instrument l'expressivité gestuelle est transposée en sons. En 1970 Matthews et Moore réalisent un système hybride : le Groove. Dans ce système le musicien agit sur un manche de commande dont les mouvements sont captés et utilisés pour le contrôle des paramètres de synthèse. Il contrôle en temps réel, à la façon d'un chef d'orchestre, certains paramètres comme le tempo, l' intensité,le timbre, l' allure. Matthews a ainsi installer entre l'homme et l'ordinateur une relation de chef à orchestre. Ce concept de chef d'orchestre soutient que la relation désirée entre l'interprète et l'ordinateur n'est pas la même qu'entre le musicien et son instrument mais plutôt analogue entre le chef et l'orchestre. Nous avons alors deux approches du lien entre le geste et le son : -l'approche physique : le geste est considéré comme un phénomène physique dans la chaîne de production. Cette approche fait appel à la problématique du geste instrumental. -l'approche du comportement gestuel comme métaphore. Cette approche considère qu'il existe des dynamiques dans l'évolution énergétique du son qui sont comparables aux dynamiques gestuelles. Il s'agit de correspondance et non d'un véritable lien physique objectif. 4/53

8 adopte une approche intermédiaire : par le geste le musicien peut contrôler les propriétés du son car le mouvement de ses mains est relié à des variations sonores; par les signes il peut changer le type de son comme s'il changeait d'instrument. Nous avons alors une approche physique sur le son ainsi qu'une approche métaphorique. Enfin nous souhaitons aller plus loin dans cette approche métaphorique en déduisant à partir de la dynamique du geste des intentionnalités sur l'expression sonore tel un chef d'orchestre qui influence la manière dont les musiciens jouent les notes. 5/53

9 3. Cahier des charges 1 Description générale du projet Notre travail consiste à développer une interface qui, à partir de deux flux vidéos temps réels, puisse reconnaître et interpréter les signes et mouvements de mains. A partir de ces données, le logiciel PureData crée et module différents sons. Pour repérer la gestuelle et le mouvement des mains, nous utilisons deux caméras. L une est positionnée au dessus des mains, la seconde en face de l utilisateur. Celui-ci a la possibilité d effectuer différents signes, correspondant à différents effets sonores. Il peut alors les moduler en déplaçant ses mains dans l espace. Différentes contraintes seront imposées à l utilisateur. Tout d'abord, le nombre de signes est limité ainsi que l espace dans lequel il évolue. Cet espace est délimité par un cadre positionné sur la table ainsi que par un fond uni derrière l'utilisateur. Ceci permet d'obtenir une meilleure détection de la gestuelle. Pour faciliter cette détection, l'utilisateur devra porter un haut noir ainsi que deux bracelets de couleur bien distincte. D autre part, l'éclairage doit être fixe et suffisamment important afin d'éliminer le maximum d'ombres. Nous devons limiter les contraintes au maximum afin que l'installation soit la plus discrète possible. Les mains ne doivent notamment pas utiliser de dispositif technique comme des gants ou des diodes. 2 Méthodes de travail Afin de faciliter le travail nous avons décidé de créer un site Internet au début du projet. Celui-ci centralise les documents trouvés par chacun pouvant aider au développement du projet. Le site internet contient aussi les compte rendus de nos différentes réunions de travail. Nous avons effectué beaucoup de réunions au début du projet, afin de mettre en commun nos recherches sur les techniques de développement à utiliser. C'est ce qui a permis de bien définir le projet et d'effectuer tous ensemble le découpage en modules. 3 Système de modules Nous avons rapidement essayé de découper l'application en modules indépendant. Le but est de faciliter la répartition des tâches et de pouvoir travailler indépendamment les uns des autres. En déterminant précisément les données en entrée et en sortie de chacun des modules, nous pouvons les développer dans n'importe quel ordre. Nous avons déterminé que l'application nécessite une chaîne de six modules : récupération du flux vidéo, détection des mains, traitement des mains, détection des signes, détection des mouvements et traitement sonore. 6/53

10 Le module flux vidéo doit lire le flux vidéo d'une webcam et renvoyer une image de la vidéo dès qu'on en fait la demande. Le module de détections des mains récupère chacune des images du précédent module. Le but est de renvoyer deux images binaires stockés dans deux buffers de même taille et correspondant aux deux mains. Le module de traitement des mains doit extraire des images les informations pertinentes afin de préparer la reconnaissance de signes et de mouvements. Le module de détection des signes utilise ces images normalisés afin de déterminer le signe effectué sur chacune des mains. Il doit donc renvoyer deux entiers, correspondant aux deux signes. Le module de détection des mouvements utilise les images en sortie du module de détection des mains. A partir de ces images, il doit détecter différents types de mouvements et renvoie des informations sur ce mouvement. Enfin, le module de traitement sonore récupère les données en sortie des modules de détection de signes et de mouvements afin de déterminer quels traitements sonores doivent être effectués. Fig. 1 : Schéma des modules 7/53

11 4 Planning A partir du découpage précédent, nous avons déterminé un planning de travail en essayant de déterminer pour chacun des modules le temps nécessaire à son développement. Nous avions prévu deux phases de développement. Une première phase de codage des modules afin de valider rapidement la chaîne de traitements et une deuxième phase d'optimisation et de correction des éventuels bugs. Le planning initial se découpe ainsi : 8/53

12 Fig 2 : Planning initial 9/53

13 Ce planning n'a pas été respecté car la phase de recherche a durée beaucoup plus de temps que prévu. Il a en effet fallu passer beaucoup de temps à développer des programmes qui au final n ont pas été utilisés car non optimals à notre projet. La phase de tests a au final durée jusqu'au mois de mars et donc, le développement de l'application finale aura été au final relativement court. 10/53

14 4. Etudes de faisabilité 1 Flux vidéo Afin d'effectuer les premiers tests, nous avons décidé de travailler à partir de vidéos, filmés avec la webcam. Cela nous a permis de travailler à partir de la même vidéo de référence. Les premiers codes ont été développés en C++, et utilisent la libraire RT et plus particulièrement tout le travail sur la gestion des AVI. La seule partie à développer consistait donc en la façon de traiter la récupération des images de la vidéo. Deux méthodes étaient possibles, selon que la machine sur laquelle le programme allait être exécuté serait plus ou moins chargée et que l'on tolère plus ou moins de temps de latence entre demande de l'image et récupération. Une première approche consistait à stocker dans une file toutes les images de la vidéo et de les mettre à disposition pour être traitées une par une. Néanmoins à ce stade du projet, nous ne connaissions pas nos temps de rendu, et notamment si l'application serait temps réel. Dans le cas contraire (temps de traitement de l'image par le programme supérieur à 1/25 de seconde), la file se serait agrandie indéfiniment, et tout aurait été décalé. Cette solution fut très rapidement écartée, de même que ses variantes consistant à stocker les 3 ou 5 dernières images. Dans le cas où une machine s'occupe seulement d'une partie du projet (caméra de face seulement par exemple) et que l'on désire un très petit temps de latence entre la demande du serveur et le la réponse du traitement de l'image, chaque image de la vidéo doit être capturée et calculée, quand bien même le serveur ne demande pas les coordonnées : le programme doit tourner en boucle, et la vidéo est considérée comme un flux. Pour réaliser cette méthode, plutôt que d'utiliser une boucle classique, nous avons testé le système d'envoi de signaux pour la simuler. A chaque fin de traitement d'une image capturée, un signal est émis, ce qui relance le processus de capture et de traitement. Dans l'état, ce programme ne fait que capturer des images et les mettre à disposition, en en protégeant l'accès tant que les données de réponse ne sont pas totalement renseignées, alternant entre l'image courante et la précédente afin de toujours pouvoir renvoyer instantanément une réponse. L'orientation du projet permit une petite latence dans le temps de réponse pour la caméra de face, sur laquelle sont effectués moins de traitements. Aussi la solution 11/53

15 adoptée consiste simplement à capturer et traiter l'image actuelle de la vidéo. La vidéo est ici considérée comme un fichier à parcourir. L'image récupérée est celle de la différence entre le lancement de la vidéo (instant 0) et le moment de la requête (instant t). Cette méthode prend plus de temps, mais moins souvent, car elle ne s'effectue que lorsque les résultats de l'image vont effectivement être utilisés. Sachant qu'en suite, nous avons regroupé les ordinateurs faisant office de serveur et de caméra de face, cette solution devenait la plus efficace. Fig. 3 : Image de base 5 Détection des mains 1. Binarisation L'une des premières étapes de notre pipeline de traitements consiste à simplifier au maximum le nombre de composantes de l'image afin de simplifier les traitements suivant. Pour cela on effectue une binarisation de l'image. On parcours l'image afin de transformer l'image de la main en blanc sur fond noir. Pour cela, différentes solutions ont été envisagées. La première idée a été de faire une différence entre l'image courante et l'image de fond. On élimine alors tous les pixels dont la différence et inférieur à une valeur alpha. Cette méthode est très simple à implémenter, mais montre vite ses limites quand le fond varie légèrement. Pour accélérer le temps de traitements dans le calcul de la différence, nous sommes aussi passé en mode de couleur YUV, afin de ne travailler que sur deux composantes plutôt que trois. La deuxième technique utilisée consiste à enlever toutes les parties de l'image ayant une composante verte trop importante. Cette méthode à pour mérite d'être assez efficace, mais doit être initialisé à chaque fois, le fond pouvant varier en fonction des paramètres de la webcam. Lors du parcours d'image pour la binarisation, on recherche aussi la couleur des bracelets, afin d'enlever les bras de l'image de la main. Pour cela on recherche pour chaque pixel la couleur du bracelet, et on sauvegarde les coordonnées maximal des 2 bracelets. On élimine ensuite tout ce qui se trouve en dessous de ces bracelets. 12/53

16 Fig. 4 : Séparation du fond Enfin afin d'éliminer toutes les impuretés et bruit de l'image, on peut effectue une érosion et une dilatation. 2. Erosion et dilatation L'érosion, de même que la dilatation ne nécessitent pas une grande précision, leur but est uniquement de supprimer les parasites afin de n'obtenir que deux grands blocs distincts correspondant aux mains. Considérant que "l'imprécision" s'applique uniformément sur tout le contour de la main lors de l'érosion puis de la dilatation, le barycentre de la main (information recherchée) n'est pas, ou peu, modifié. La première méthode employée consiste à regarder, pour chaque pixel valide, s'il a au moins deux voisins valides (sur les quatre cardinaux considérés), auquel cas il est conservé, ou passé en pixel non valide dans le cas contraire. Deux applications sur cette méthode furent réalisées, une première mise en forme avec des tests classiques (if, else), la seconde appliquant directement le résultat selon un calcul par divisions entières. Le but était de comparer leurs temps de traitement respectifs. La seconde est plus longue de l'ordre d'un tiers par image. La seconde méthode consiste à prendre pour chaque pixel non valide ses quatre voisins cardinaux et à les considérer non valides eux aussi. Il n'y a pas de propagation, les résultats sont stockés ailleurs, pas dans l'image même. La zone de pixels non valides s'étend ainsi aux contours de la main lors de la première érosion, l'inverse s'effectue lors de la dilatation. Des imperfections subsistent : par exemple, si une ligne d'un seul pixel d'épaisseur appartient bien à la main, il sera supprimé lors de la première érosion, sans revenir par dilatation. Cette méthode a néanmoins l'avantage d'être rapide sur une image qui est très peu parasitée avec des formes marquées et épaisses pour la main. 3. Détection des bracelets Cette étape a pour but de détecter les deux extrémités gauche et droite du bracelet d'une main. Elle nécessite en entrée l'image binaire de cette main, accompagnée de la liste des pixels candidats à l'appartenance au bracelet et la position moyenne de ces 13/53

17 pixels. Nous avons tout d'abord envisagé de parcourir l'image horizontalement verticales par verticales pour détecter les pixels candidats les plus à gauche et ceux les plus à droite. Mais de nombreux pixels candidats ne sont en fait que des parasites qui n'appartiennent pas réellement au bracelet. Nous avons donc rapidement abandonné cette méthode. La technique que nous avons finalement implémentée se base sur le principe selon lequel les pixels parasites sont à la fois en quantité suffisamment négligeable par rapport aux pixels réels du bracelet et sont équitablement répartis autour de celui-ci. Ainsi, on admet que la position moyenne de tous les pixels candidats est située à l'intérieur de la tache du bracelet, ce qui est, dans la pratique, toujours le cas. Il aurait bien sûr été possible d'éliminer les parasites en ne conservant que la plus grosse tache candidate. Cet algorithme, que nous avions déjà implémenté pour la séparation des mains, est assez lourd à l'exécution. Puisque nous connaissons l'un des pixels de cette tache ainsi que la position moyenne des pixels candidats, nous pouvons directement détecter sa forme par propagation depuis ce même point. Sachant que les deux extrémités du bracelet sont les pixels les plus éloignés entre eux, nous commençons par lancer une propagation depuis la moyenne des pixels candidats pour détecter le pixel du bracelet le plus éloigné de celle-ci, qui est obligatoirement l'une des deux extrémités. Ensuite, il ne nous reste plus qu'à lancer une deuxième propagation depuis ce point pour détecter la deuxième extrémité. Fig. 5 : Détection bracelet gauche Fig. 6 : Détection bracelet droit 4. Séparation des deux mains Pour réaliser cette étape, on considère que l'image couleur en provenance de la webcam et contenant les deux mains a été binarisée par comparaison avec le fond, et que les pixels candidats à la détection de chacun des deux bracelets ont été repérés et 14/53

18 marqués, et leur position moyenne calculée. L'une des principales difficultés de cette étape est le fait que l'on va travailler sur plusieurs objets, c'est-à-dire identifier les deux mains dans l'image et en même temps reconnaître la main gauche de la main droite. Pour faciliter les traitements, nous avons interdit à l'utilisateur de croiser les mains, ce qui nous permet de considérer que la main droite sera toujours à droite de la gauche, et vice-versa. Mais là où les choses se compliquent, c'est que l'application va devoir être capable de gérer les cas où les deux mains sortent de l'image, ainsi que le cas où seule l'une des deux mains est présente, et le cas échéant être capable de l'identifier. Nous considérons que l'une ou l'autre des mains est présente à l'écran si son bracelet a été détecté. Il est effectivement possible que celle-ci soit bien présente même si son bracelet n'a pas été détecté, mais, d'un point de vue algorithmique, c'est la seule solution qui soit envisageable. En effet, à cause des variations de lumière et autres ombres non désirées, l'image binarisée comporte toujours un certain nombre de taches parasites. Pour éliminer ces parasites, nous avions envisagé deux méthodes : - effectuer une érosion suivie d'une dilatation, technique assez rapide en temps de traitement, mais absolument pas fiable, à partir du moment où la suite des traitements oblige à une image parfaite et sans plus aucun parasite. De plus, ces tâches peuvent avoir une taille variable. Une trop faible érosion ne suffirait pas à toutes les éliminer, et une trop forte risquerait d'endommager la main, surtout au niveau des doigts. - considérer que les deux mains sont obligatoirement les deux plus grosses formes dans l'image, et ne conserver que celles-ci tout en éliminant les autres. Le problème qui se pose ici concerne le cas où les deux mains ne sont pas présentes sur l'image, car des parasites seraient détectés à la place des mains manquantes. Les problèmes posés par la première méthode étant insurmontables par notre application tout en conservant un délai de traitement raisonnable, nous avons opté pour la seconde, dont les inconvénients pouvaient être réglés à partir du moment où l'on connaît à l'avance si chaque main est présente ou non à l'image. Pour ce faire, le seul élément que nous ayons à notre disposition à cette étape des traitements est la liste des pixels candidats à chaque bracelet. Voilà donc pourquoi nous sommes obligés d'assimiler la présence d'une main à celle de son bracelet. Pour signaler lorsqu'une ou les deux mains manquent à l'appel, une exception est levée, qui est spécifique à chaque cas de figure. L'on sait maintenant quelles mains sont présentes à l'image, ou alors, pour être plus exact, quelles mains on va devoir extraire, car il ne faut pas perdre de vue qu'une main peut être présente à l'image sans que son bracelet n'ait été détecté, soit lorsque celui-ci sort de l'image, soit à cause de mauvais réglages au niveau des couleurs et des seuils d'erreurs dans les données d'initialisation. Mais pourquoi ce cas pose-t-il tant de problèmes, alors que nous pourrions à première vue tout simplement considérer la main pseudo-absente comme une tache parasite, et ne conserver que la plus grosse forme de 15/53

19 l'image? La réponse tient au fait que cette main parasite pourrait dans certains cas être plus grosse que la main présente et dont le bracelet a été détecté, et serait donc extraite à la place de cette dernière. La solution que nous avons finalement retenue consiste à systématiquement récupérer les deux plus grosses formes, et, selon la nature du bracelet présent, ne conserver que celle la plus à gauche ou la plus à droite dans l'image. Cette solution, bien qu'elle semble fonctionner correctement, est assez lourde en termes de tests, à cause de la multiplicité des cas possibles. Lorsque la ou les mains ont été détectées et identifiées, deux nouvelles images sont créées et initialisées avec leurs données respectives, et sont prêtes pour la suite des traitements. Fig. 7 : Main gauche binarisée Fig. 8 : Main droite binarisée 6 Traitement d'une main 1. Détection des points caractéristiques Dans l'étape de reconnaissance de la forme des mains, plusieurs approches ont été tentées. L'une d'entre elles ramenait la main à un ensemble de points capables de décrire sa forme, ce sont les points caractéristiques. L'idée était de dire que les sommets et les creux visibles pouvaient être liés entre eux (sorte de fonction mathématique) d'une manière unique suffisant à décrire la main. Avec le recul, cela ressemble à simuler un système de reconnaissance, très proche du réseau de neurones, mais manuellement. Le travail était en réalité fastidieux car il fallait pour chaque signe, définir soi-même ce qui pouvait le représenter, et prendre en compte les variations. Une première tentative fut faite sur le signe de la main à plat avec les doigts écartés. Les sommets des doigts et les creux entre étaient évalués. Des méthodes 16/53

20 existent quand aux dérivées sur ces sommets, mais faisant appel à des connaissances qui n'étaient pas acquises, la méthode employée se révéla être un simple test de cas de coordonnées de pixels. Par exemple, pour un sommet, un parcours en ligne est effectué sur le contour, et l'on remarque que les indices de hauteur des pixels augmentent jusqu'à un maximum avant de redescendre. La moyenne horizontale des maximum locaux verticaux donnait un sommet. Nous nous apercevons très rapidement que le calcul pour cinq sommets et cinq creux devient rapidement long. De plus, cela ne concerne qu'un signe. Il faut donc effectuer l'algorithme sur chaque signe jusqu'à trouver un résultat correspondant satisfaisant. Cette méthode a rapidement été abandonnée du fait de sa complexité. Toutes ces étapes de reconnaissance furent directement déléguées au réseau de neurones. La robustesse d'une telle méthode n'a donc pas pu être évaluée sur toutes les formes de main. Fig. 9 : Détection des contours 17/53

21 Fig. 10 : Détection des points caractéristiques 2. Squelettisation Au tout début du développement de notre application, nous savions déjà que nous allions devoir utiliser un réseau de neurones pour la reconnaissance des signes, mais nous ne savions pas avec précision comment l'utiliser, et en particulier la nature des données que nous allions lui fournir en entrée. La première solution envisagée, et qui nous paraissait la plus logique, fut de squelettiser la main afin d'en identifier les principaux points caractéristiques, puis de transmettre ces points au réseau de neurones. Sachant que les points recherchés correspondent aux articulations (extrémités des doigts, articulations des phalanges, poignet), dans le cas où nous parvenions à squelettiser la main correctement, nous aurions pu sans problème modéliser tous les signes possibles. Idéalement, cette squelettisation aurait du avoir lieu en trois dimensions en effectuant une squelettisation 2D sur chacune des deux images, mais nous avons bien vite abandonné cette idée, à cause de la difficulté de séparer avec précision la main du fond sur l'image de face due à la présence du corps de l'utilisateur. Nous avons donc décidé de restreindre la variété des gestes reconnus à ceux clairement identifiables depuis la seule vue de dessus, et nous nous servirions de la vue de face pour détecter la position globale de la main en hauteur avec la couleur. Après quelques recherches dans le domaine, nous avons retenu deux techniques pour la détection des points caractéristiques : - tracer virtuellement un cercle autour de la paume de la main après avoir détecté son centre, détecter l'extrémité du doigt le plus long pour choisir un rayon de telle sorte qu'il coupe chacun des doigts ainsi que le poignet, parcourir ensuite ce cercle en repérant les points de coupures avec les doigts, calculer les vecteurs entre le centre de la paume et les intersections et enfin parcourir le doigt depuis le centre de la paume pour en détecter les extrémités. -détecter le contour de la main, le parcourir pour repérer les sommets des courbures, extraire les extrémités des doigts parmi les points repérés, et enfin reconstituer 18/53

22 les articulations des phalanges en connaissant proportionnellement à la longueur de chaque doigt. les positions de celles-ci On remarque d'emblée que la première méthode ne peut fonctionner qu'uniquement dans le cas où les doigts sont tous dépliés et suffisamment espacés, et que la main est positionnée à plat. Nous avons tenté une implémentation de cette technique, puis nous l'avons finalement abandonnée pour cette raison. La seconde méthode, basée sur les courbures, a le mérite de pouvoir théoriquement fonctionner même lorsque les doigts sont repliés, puisqu'il reste toujours des creux à la base des phalanges. Le problème qui se pose ici est l'impossibilité de détecter la position des articulations des phalanges, à partir du moment où l'on ne connaît pas la longueur des doigts et que ceux-ci sont positionnés à la verticale au lieu de l'horizontale, et que nous ne pouvons pas faire de squelettisation à partir de la vue de face. Nous rendant compte de l'impossibilité de squelettiser la main, nous nous sommes repliés sur une autre technique qui consiste à passer au réseau de neurones une image binaire complète au lieu de quelques points caractéristiques. 3. Orientation de la main Cette étape vise à préparer l'image pour le passage en entrée du réseau de neurones, ce qui implique de la remettre en position verticale puis de la redimensionner. Elle nécessite en entrée les données de l'image binarisée ainsi que les deux coordonnées des deux extrémités du bracelet. Pour replacer l'image en position verticale, nous devons tout d'abord détecter son angle de rotation actuel, ce qui implique de disposer d'un barycentre. Dans notre cas, nous prendrons le centre de la paume de la main. Pour détecter ce point, nous avons envisagé deux méthodes : -calculer la moyenne des pixels de la main. Cette méthode est simple et très rapide, mais absolument pas robuste, car la position résultante varie selon l'avancée du bras dans l'image. -utiliser une solution plus élaborée se basant sur la position du bracelet sur la main, supposée invariable, mais qui serait plus lente et plus coûteuse. Sachant que les problèmes posés par la première technique la rendent beaucoup trop aléatoire, nous avons décidé de procéder de la manière suivante : 1/ On commence par calculer le centre du bracelet, en faisant la moyenne entre ses deux extrémités. 2/ On calcul la moyenne des pixels de la main situés au dessus du bracelet, en supposant que la main ne sera jamais orientée à moins de -45 degrés et à plus de 45 degrés par rapport à la verticale, ce qui est, dans la pratique, toujours le cas. 3/ On calcul les coordonnées du vecteur [centre bracelet, centre main]. 19/53

23 4/ On calcule la taille du bracelet, c'est-à-dire la distance entre les deux extrémités. Cette distance nous donne un indice sur la taille de la main, qui peut varier selon son éloignement par rapport à la caméra. 5/ On remarque que le centre de la paume est globalement situé à 1,5 fois la taille du bracelet depuis le centre de celui-ci en direction de la moyenne des pixels de la main. On obtient un point invariable et stable même lorsque les doigts sont tous repliés. Maintenant que nous disposons de notre barycentre, la prochaine étape consiste à calculer l'angle de rotation de la main. Pour cela, la seule donnée exploitable que nous ayons sous la main est le segment [centre bracelet, barycentre], qui doit normalement être aligné avec le bras de l'utilisateur. En déterminant l'angle de ce segment, on obtient celui de la main. Maintenant que nous connaissons son angle de rotation, il nous faut la redresser. Pour cela, nous appliquons simplement à chaque pixel la rotation inverse. Finalement, afin de préparer l'image au passage dans le réseau de neurones, il nous faut ne conserver que la main séparée du bras. Celle-ci est recadrée en coupant au niveau du bracelet. Pour achever les traitements, il nous reste à redimensionner l'image pour lui donner une taille normalisée. Fig. 11 : Résultat final main gauche Fig. 12 : Résultat final main droite 7 Détection des signes : le réseau de neurones Le problème est le suivant : comment trouver une méthode pour reconnaître un signe fait par la main? Comment traduire ce signe en un ensemble de points? Comment classer ces ensembles de points qui n'ont aucun sens algébrique? Comment traiter les informations afin qu'elles soient assez rapides pour une application temps réel? Une solution semble être utilisée très régulièrement pour reconnaître les formes ce sont les réseaux de neurones. Le principe du réseau de neurones : imiter et adapter le comportement biologique du cerveau humain. Chaque neurone est une unite de calcul simple. Le fait de les associer permet la creation d une structure analytique evoluee avec une capacité d apprentissage. Cette théorie permet d'obtenir une interprétation plus ou moins exacte d un ensemble de donnees en fonction d une base d exemples préalablement apprise par le réseau. 1. Le perceptron 20/53

24 C'est un des premiers réseau de neurones, conçu en 1958 par Rosenblatt. Il est linéaire et monocouche. Il est inspiré du système visuel. La première couche représente la rétine. Les neurones de la couche suivante (unique d'où le qualificatif de monocouche) sont les cellules d'association, et la couche finale les cellules de décision. Les sorties des neurones ne peuvent prendre que deux états (-1 et 1 ou 0 et 1). La règle de modification des poids utilisée est la règle de Widrow-Hoff : si la sortie du réseau est égale à la sortie désirée, le poids de la connexion entre ce neurone et le neurone d'association qui lui est connecté n'est pas modifié. Dans le cas contraire le poids est modifié proportionnellement à la différence entre la sortie obtenue et la sortie désirée selon la loi de Hebb : w <= w + k (d - s) avec s la sortie obtenue, d la sortie désirée et k une constante positive. Fig. 13 : Le perceptron 1. Algorithme d'apprentissage 1/ Initialisation des poids et du seuil S à des valeurs (petites) choisies au hasard. 2/ Présentation d'une entrée El = (e1,... en) de la base d'apprentissage. 3/ Calcul de la sortie obtenue x pour cette entrée : a = (wi. ei) - S x = signe (a) ( si a > 0 alors x = +1 sinon a 0 alors x = -1 ) 4/ Si la sortie x du perceptron est différente de la sortie désirée d1 pour cet exemple d'entrée E1 alors modification des poids (μ le pas de modification) : wi(t+1) = wi(t) + μ.((d1 - x).ei) Rappel : d1= +1 si E est de la classe 1, d1= -1 si E est de la classe 2 et (d1- x) 5/ Tant que tous les exemples de la base d'apprentissage ne sont pas traités correctement (i.e. modification des poids), retour a l'étape Implémentation Un exemple de perceptron a été implémenté sans réellement savoir s'il serait judicieux d'utiliser un perceptron pour notre reconnaissance de signes. Le but principal était de coder un premier exemple de reseau de neurones afin de mieux comprendre la logique particulière à cette théorie. Le second était d'obtenir une base de code avant de procéder à des réseaux plus complexes. 21/53

25 Le premier problème a été la modélisation du réseau de manière orientée objet. Le langage orienté objet est très pertinent dans les réseaux de neurones car à chaque entité propre du réseau correspond une classe. Nous avons défini six classes : Neuron, Synapse, Layer, Perceptron, DataLearning et DataTest. La fonction de calcul de sortie et de calcul des nouveaux poids se situent sur le neurone. Les synapse entrant sur les neurones contiennent les valeurs insérées sur le réseau ainsi que les poids propres à chaque neurone. Le perceptron simple étant constitué d'un unique neurone, la sortie est binaire 0 ou 1. Le test du perceptron se fera sur l'apprentissage des règles de logique. Exemple de la la base d'apprentissage consitué des règles du ET logique: (1, 1) donne 1 (0, 1) donne 0 (1, 0) donne 0 (0, 0) donne 0 Les résultats sont concluant, le perceptron est capable d'apprendre toutes les règles de logique à part le ou exclusif ne pouvant être appris grâce à un perceptron à simple couche. 4. Reconnaissance de formes 1. Etude d'une application de reconnaissance de formes : lecture des codes postaux C'est dans la reconnaissance des caractères que les réseaux de neurones ont fait leurs preuves. La reconnaissance des codes postaux a été sans nul doute l'exemple le plus étudié. Pour chaque courrier une machine doit soit identifier le code soit indiquer qu'elle ne peut pas l'identifier et fais alors appel à un opérateur humain. A l'heure d'aujourd'hui le taux de rejet est inférieur à 5%. La reconnaissance des codes est basée sur la reconnaissance de chacun de ces chiffres séparément. Des bases de données de modèles manuscrits de grandes tailles sont disponibles depuis les années Elles sont composées de petites images de 16x16 pixels. Le premier exemple d'application de reconnaissances de formes a été développé aux laboratoires AT&T. Il s'agit d'un réseau de neurones connu sous le nom de LeNet qui utilise une représentation par pixel. Ce réseau réalise dans ses premières couches le pré-traitement et dans ses dernières couches la classification. De cette méthode nous retiendrons deux aspects dans notre projet. La première est de constituer une bases de données d'images correspondant aux différents signes de la main. La seconde est la représentation par pixels du réseau de neurones. Nous allons constituer un réseau qui prend en entrée les pixels d'une image. Par contre, le premier objectif de notre projet n'étant pas les reseaux de neurones nous ne ferons pas les prétraitements grâce au réseau de neurones. Ces pré-traitement seront réalisés dans les 22/53

26 précédents modules avec des techniques dîtes classiques de traitement d'image. De cette manière nous respectons la contrainte que chaque module est indépendant afin de pouvoir simuler le module de reconnaissance de signes tant que le réseau de neurones ne fournie pas de résultats concluant. 2. Réalisation d'un perceptron avec une image binarisée Pour ce test nous allors implémenter un perceptron qui prend en entrée une image binarisée Cela revient à prendre en entrée un tableau comprenant des 0 et des 1. La programmation objet du premier test du perceptron permet de changer simplement la configuration du réseau. Par rapport au perceptron permettant d'apprendre des règles de logique il suffit juste de changer le nombre de synapses entrant sur le neurone, passant de deux à 100x100 synapses. Fig. 14 : Reconnaissance avec un perceptron simple Les résultats sont concluants sur la base de données d'apprentissage. Par contre il ne reconnaît aucun signe en dehors de ceux appartenant à la base de données. Le résultat d'un perceptron à simple couche est beaucoup trop binaire, il ne permet pas d'approcher un résultat, il permet uniquement de classer les informations comme appartenant ou non à la base d'apprentissage. Il nous faut trouver une solution plus pertinente qui permet de deviner de quel model se rapproche le plus l'image. Il existe une solution qui sont les cartes auto-organisatrices. Elles sont un mélange des réseaux de neurones et des théories connexionistes. Lorsqu'une image est testée elle va activer une zone de la carte préalablement générée lors d'un apprentissage supervisé. L'intérêt est que quelque soit l'image il y a toujours une réponse du réseau. 3. Cartes auto-organisatrices Les applications qui utlisent les cartes auto-organisatrices sont assez récentes (1990) : carte phonétique, diagnostic de pannes, compression d'images, robotique, etc. Ces cartes s'organisent par rapport aux exemples d'entrée présentés en respectant les contraintes topologiques de l'espace d'entrée. Il y a mise en correspondance de l'espace d'entrée avec l'espace du réseau. Les zones voisines de l'espace d'entrée sont voisines sur la carte auto-organisatrice. A l'issue de l'apprentissage, chacun des neurones de la carte auto-organisatrice correspond à une zone de l'espace d'entrée. La figure ci-dessous 23/53

27 décrit le réseau organisé en une couche à deux dimensions. Chaque neurone Nk est connecté à un nombre n d'entrées au travers de n connexions plastiques de poids respectifs w. Il existe aussi des connexions laterales de poids fixes, excitatrices dans un proche voisinage. Fig. 15 : Organisation d'un réseau de neurones en carte auto-organisatrice Algorithme d'apprentissage de la carte auto-organisatrice dans le cas d'un vecteur d'entrée à deux composantes : 1/ Initialisation des poids à des valeurs aléatoires. 2/ Présentation d'une entrée El = (e1, e2). 3/ Calcul de la distance de chacun des neurones par rapport à e1 et e2 xj = wj1 - e1 + wj2 - e2 4/ Sélection du neurone le plus proche : Min(x)= xi 5/ Modification des poids pour le neurone choisi (i) et ses 4 plus proches voisins (k). μ et ß sont deux paramètres correspondant au pas de modification des poids. μ pour le neurone choisi et ß pour ceux du voisinnage. wi1 = wi1 + μ. (e1 - wi1) wi2 = wi2 + μ. (e2 wi2) wk1 = wk1 + ß. (e1 - wk1) wk2 = wk2 + ß. (e2 - wk2) 6) Tant que les performances sont insuffisantes : Retour à l'étape 2 et sélection de l'exemple suivant dans la base d'apprentissage. L'algorithme ci-dessus permet de former la carte d'apprentissage. Les cartes auto-organisatrices ont besoins d'informartions complémentaires par rapport au perceptron. En effet chaque neurone à besoin d'accéder à ses quatre plus proches voisins afin de répercuter la mis à jour de son poids aux neurones alentours. Lors de l'initialisation du neurone à un matrice de connexion est créé afin de pouvoir accéder 24/53

28 rapidement à un neurones et à ses voisins. Un autre probléme est lorsque la carte d'apprentissage est créée il faut pouvoir ensuite connaître les zones de la carte qui correspondent aux modèles. La carte auto-organisatrice permet de regrouper des données mais n'est pas un classeur de données. Chaque type de signe étant bien distinct la topographie des signes va influencer sur la topographie de la carte. Ainsi lors du test d'une nouvelle image, on cherche le neurone qui a la plus courte distance avec l'image ce qui nous indique la zone de la carte qui a la topographie la plus proche de l'image. Le problème est de savoir à quel modèle correspond la zone de la carte activée. Pour cela à la fin de l'apprentissage une carte des scores est calculée: pour toutes les images d'un modèle un fort score est attribué au neurone qui a la plus courte distance ainsi qu'à ses quatre neurones les plus proches. Fig. 16 : Carte en niveau de gris de la topologie du réseau de neurones Les résultats sont très concluant sur un nombre de modèle restreint à cinq. Le plus dur est de trouver les bon paramètres afin de savoir le nombre de neurones nécessaires et le nombre d'étape de l'apprentissage. Pour ces tests le réseau est constitué de 8x8 neurones et le nombre d'itération à été fixé à 700 pour un total d'une centaine d'image modèles. Contrairement aux appréhensions l'apprentissage est assez rapide (trois ou quatre minutes). La totalité des images modèles sont reconnus sans faute et les images les approchants sont aussi reconnues dans la quasi-totalité des cas. 8 Traitement Sonores 1. Définition des besoins Le projet a pour objectif d'être une application musicale interactive, basée sur la symbolique du geste et du mouvement. Afin de que le chaîne de traitement soit opérationnelle, l'interface de contrôle vidéo doit être couplée à un moteur audio capable de jouer des sons en fonction des données calculée par le coeur du système. Dès lors un certain nombre de questions se posent sur la manière de produire un contenu sonore. Doit-elle être implémentée au sein même de notre application ou vaut il mieux faire appel à un module externe? Le signal sonore doit-il être synthétisé par la machine, provenir d'un lecteur d'échantillons ou d'une source continue? Comment le module audio communiquera avec l'application centrale d'? Obtenir des réponses nécessite de se pencher sur les différents choix qui s'offre à nous pour adopter une solution efficace qui puisse être mise en oeuvre dans le temps imparti. 25/53

29 Il est important de cibler les points clés du projet. Le concept dominant est la forme d'interaction novatrice entre l'artiste et sa machine. Bien que l'application finale puisse se confondre avec un instrument de musique à part entière, il est essentiel de séparer l'interface de contrôle du générateur de son, principalement pour deux raisons : Cela permet de favoriser les possibilités d'adaptation et d'évolution. En effet, un artiste peut souhaiter utiliser avec ses propres solutions audios, auquel cas l'indépendance des systèmes se révèle indispensable. De plus, il serait dommage que le système interactif d' ne puisse pas dans le futur être utilisé dans des contextes différents, les applications y étant nombreuses (dessin 3d, jeux vidéo...) De plus, cela nous évite d'implémenter nous même un moteur de synthèse sonore. Cette tâche demanderait un temps de développement considérable en plus de l'acquisition des compétences nécessaires. Certes des API audios existent mais cette orientation irait à l'encontre des idées précédemment citées. L'utilisation d'un logiciel de traitement sonore indépendant ne peut se faire que si celui-ci rempli certains critères. Il doit pouvoir être interfacé à notre application via des protocoles réseaux standardisés. Cela garantie l'interopérabilité de l'application et permet de répartir la charges de travail sur plusieures machines inter connectées. Il doit également être orienté temps réel et proposer une architecture modulaire, afin de s'adapter au maximum a nos besoins. Enfin, la disponibilité de ressources - en particulier des instruments virtuels, modules d'effets, échantillonneurs serait un avantage certain pour mettre en place rapidement une solution musicale de qualité. 5. Max/MSP et PureData Il existe une offre relativement restreinte d'environnements audios satisfaisant nos critères. En effet seuls deux logiciels ont pu répondre à nos attentes : Max/Msp et PureData. Une étude s'impose pour déterminer lequel sera le plus à même de s'intégrer au projet. 26/53

30 Fig. 17 : Max/MSP 27/53

31 Fig. 18 : PureData 1. Présentation Max/Msp et PureData sont tous deux des environnements de programmation graphique modulaires pour la création musicale et multimédia. Ils sont aussi bien destinés aux musiciens, compositeurs, artistes, programmeurs ou chercheurs. Ils proposent une approche similaire, aussi bien dans la conception de patchs que dans le rendu sonore, Ces ressemblances ne sont pas si étonnantes que ça : Max/Msp a été développé par Miller Puckette et David Ziccarelli. À l'origine (au milieu des années 1980), ce logiciel devait rester gratuit mais l'ircam à décidé de le commercialiser. Quelques temps après, Miller s'est désolidarisé du développement du projet. David Ziccarelli crée alors la société Cycling'74 qui se donne comme but le développement commercial de Max/MSP. Miller Puckette a décidé de reprendre la conception de PureData pour faire un nouveau logiciel dans le but d'obtenir un logiciel libre et transportable à des fins musicales en temps réel. 2. Comparaison Malgré leur base commune il existe un certain nombre de points qui diffèrent : - Il est possible d'exporter les connaissances acquises de l'un vers l'autre, mais 28/53

32 pas les fichiers. - Les objets de base sont identiques, mais certains objets ne se nomment pas de la même façon. - Max/Msp bénéficie de plus de dix ans de recherches et d'ajouts, il est donc plus complet. - PureData dispose d'objets singuliers notamment pour des opérations de réseau qui n'ont pas d'équivalent sur Max/Msp. - Max/Msp est commercialisé par Cycling 74, PureData est un logiciel libre. - Max/Msp a une meilleure documentation. - Max/Msp est doté d'une Interface plus conviviale. - Max/Msp peut créer des applications standalone. - La gestion des traits de connections dans Max/Msp en traits droits et anguleux permet une meilleure visibilité. Au regard de ces différences, deux éléments on fait de PureData la solution que nous avons finalement adopté. Premièrement le logiciel a été pensé et conçu nativement pour faire des applications en réseaux, ce qui est particulièrement intéressant dans l'optique de développement que nous envisageons. Ensuite c'est un logiciel libre. Acquérir une licence d'utilisation de Max/Msp, même en accédant au tarif étudiant, reste un investissement coûteux. Les capacités de PureData sont largement suffisantes pour les traitements que nous comptons faire. De plus de nombreuses bibliothèques libres peuvent venir se greffer au logiciel pour lui apporter des fonctionnalités supplémentaires. 6. Communication avec l'application centrale Nous avons choisi d utiliser PureData pour le traitement de l information audio. Notre programme de reconnaissance doit être développé indépendamment de tout contexte logiciel externe mais suivre un protocole de communication qui soit implémenté par les deux applications. L'application centrale et PureData peuvent se trouver soit sur une même station de travail, soit sur deux ordinateurs en réseau. Nous allons donc étudier les protocoles qui rempliraient au mieux le service demandé. 1. Protocole TCP/IP C est la solution la plus courante pour faire communiquer différentes applications. Elle est depuis longtemps standardisée, et est implémentée dans tous les langages de programmations courants et dans PureData. Si le procédé est rapide a mettre en place et répond entièrement à nos spécifications, il soulève un problème tout autre : avoir une application globale figée et très fortement dépendante de PureData. En effet les données circulant dans les trames TCP/IP ne seront liées à aucune des normes utilisées dans le monde de l audio. Il serai nécessaire de développer un module PureData pour traiter les informations reçues. L application serait fonctionnelle mais aucunement portable (il 29/53

33 faudrait redévelopper un module de réception des données spécifique pour chaque logiciel de traitement sonore). On écarterait également toute possibilité de générer des sons ou des effets directement à partir de matériel hardware. 2. Protocole Midi La norme de communication de matériel audio par excellence. Aujourd hui le MIDI est reconnu par un très grand nombre de périphériques, ce qui démultiplierait les possibilités de notre interface. Cependant le protocole MIDI est très lié au matériel physique. Cela impliquerai que le logiciel de reconnaissance des mains soit sur un ordinateur, que PureData soit installé sur un autre ordinateur, et que ces deux machines soit reliées par un câble MIDI (elles doivent donc être équipées de cartes sons adaptées). L aspect logiciel est totalement inconnu de la norme MIDI. Faire tourner PureData et notre application sur une même machine serait très inconfortable, il faudrait a priori router la sortie midi de la carte son vers son entrée, physiquement, ou via les drivers. Il existe tout de même une alternative intéressante : les protocoles du type MIDI over IP, tels que DMIDI ou MWPP, qui permettent de transmettre des données MIDI sur un LAN standard. 3. Protocole OSC OpenSound Control (OSC) est un protocole récent, développé spécifiquement pour la communication d ordinateurs et de matériel multimédia sur le réseau. L OSC semble être une solution idéale puisqu il est standardisé, déjà implémenté dans quelques logiciels et synthétiseurs, et que c est une couche réseau de haut niveau. En outre le message OSC peut être transmis en Tcp/Ip, Wifi de manière transparente. Si ce protocole n'est implémenté nativement ni dans PureData ni dans les langages de programmation, il en existe des implémentations utilisables en rajoutant des librairies externes. OSC à également un autre avantage de taille : la possibilité de créer des adressages à l'intérieur même des applications, facilitant grandement le traitement des données reçues, celles-ci sont directement routées sur l'adresse spécifiée. Le seul point faible est que le protocole étant récent, il est plus difficile de trouver de la documentation ou des exemples d utilisation. Malgré une popularité moindre par rapport à Tcp/Ip et Midi, le protocole OSC s avère le plus adapté à la mise en œuvre de notre application. En effet, son intégration au sein d un éventail grandissant de logiciels audios promet au système de reconnaissance d d être fortement interopérable et ses possibilités d adressage interne rendent le développement de patchs audios bien plus aisé. 7. Génération sonore dans le patch PureData Si les différentes structures sont maintenant définies pour nous permettre de jouer des sons en fonctions des données transmises par le réseau, reste encore à réfléchir sur la manière de concevoir le patch audio. On appelle patch une implémentation d un ensemble d objets et de liens modélisant une application sonore. PureData contient une certaine quantité d objets de base qui permettent de faire du traitement du signal. Ainsi on y trouve des oscillateurs générant des sinusoïdes ou des signaux en dent 30/53

34 de scie, des opérateurs applicables sur les signaux, une fonction d enveloppe, un système d écoute. Reprenant les principe d un langage de programmation, des objets représentant des variables, chaînes de caractères, tableaux, boucles sont disponibles. L environnement PureData permet de créer de véritables applications, avec des entrées, des sorties, et d effectuer du traitement d informations. Si les fonctionnalités bas niveaux et la modularité, laisse un nombre de possibilités infinies, la complexité de développement en est par ailleurs complexifiée. Cette dernière propriété a une importance capitale pour le développement du patch audio. Elle soulève en effet l interrogation suivante : le logiciel PureData est-il adapté à la création d un contenu dit musical, requièrent l élaboration de sons complexes? Pour répondre à cette question, nous allons étudier les différents moyens d obtenir un rendu sonore sous PureData et évaluer le rapport entre la complexité des traitements, les possibilités d interactions et le temps de mise en œuvre. 1. Synthèse sonore additive La synthèse additive est une technique de synthèse qui permet de créer de nombreux timbres musicaux. Le timbre d un instrument est composé de multiples harmoniques ou partielles qui changent au cours du temps. Les signaux sonores sont issus d oscillateurs de fréquences et d amplitudes différentes, et sont additionnés pour former le signal final. Cette technique permet de modéliser des sons très réalistes ou bien complètement originaux. Si cette synthèse s avère simple à mettre en place au niveau théorique et au niveau logiciel (PureData possède typiquement les éléments nécessaires à sa mise en oeuvre), il est en revanche difficile de construire un son riche et mélodieux, à moins de gérer un grand nombre d oscillateurs, et de procéder à une longue étape de paramétrage. 2. Lecture d'échantillons Cette technique permet de jouer des sons qui ont au préalable été enregistrés sur un ordinateur. Contrairement à la synthèse additive où les signaux sonores sont intégralement générés par la machine, des sources sonores externes sont captées puis numérisées de façon à être stockées dans la mémoire de l ordinateur. L intérêt est de pouvoir de manière simple profiter de son complexes riches. En revanche les possibilités d interactions sont moindres, notamment au niveau fréquentiel. Modifier le pitch d un son échantillonné en temps réel n est pas envisageable. Les sons échantillonnés se montreront donc bien plus intéressants pour jouer des boucles rythmiques ou des sons non périodiques, peu dépendant d une fréquence fondamentale. De plus les possibilités de modulations sont variées et présentent un intérêt esthétique certain. On pensera notamment à la synthèse soustractive (consistant à supprimer des composantes fréquentielles) ou à la synthèse granulaire (travail sur les fragments de sons). 3. Midi Le Midi est une solution intéressante car elle permet d accéder à des banques de 31/53

35 sons très variées et de contrôler de nombreux paramètres. Rappelons que le Midi est un protocole de communication, et qu il ne génère pas de sons. Cependant il existe de très nombreux instruments pilotables à partir du protocole Midi. Il peut s agir soit d instruments virtuels, c'est-à-dire implémentés sous forme logicielle, ou bien de synthétiseurs hardware, branchés à la carte son du pc sur lequel est lancé PureData. Ces instruments peuvent recevoir toute sorte de signaux normalisés concernant par exemple, la hauteur d une note, la vélocité ou le volume ( les paramètres peuvent êtres très nombreux sur certains instruments ). Si cette solution semble avantageuse en terme de possibilités et de simplicité, la génération des sons étant déléguée aux instruments, elle nécessite des ressources processeur importantes, surtout si on souhaite gérer plusieurs instances d instruments virtuels. Le problème est analogue pour la communication avec des périphériques hardware, qui requiert une carte son adaptée, munie de plusieurs canaux Midi. Ce matériel est assez coûteux et ne pourra probablement pas être mis à notre disposition. 4. Source audio externe Cette solution rejoint la lecture d échantillons dans le sens où le son est échantillonné lors de sa numérisation, mais au lieu de déclencher la lecture des fichiers sons de manière événementielle, le flux sonore arrive ici de manière continue, par l entrée micro ou l entrée ligne de la carte son. Les possibilités de synthèses sont les mêmes que pour un signal échantillonné. 5. Effets Les effets en eux même ne génèrent pas de sons, mais ils augmentent de manière significative les possibilités de modulation. Le contrôle de la modulation du son ne se fait plus directement en changeant les paramètres du signal mais agissant paramètres de l effet. On peut reproduire ainsi une panoplie d effets bien connue des musiciens. Citons la distorsion, le chorus, le flanger, le délay parmi les plus utilisés. Ces effets ne sont toutefois pas inclus en tant que tel dans PureData et leur implémentation peut s avérer plus ou moins fastidieuse. Chacune de ces méthodes permettant de générer ou d altérer un son à ses avantages ses inconvénients. Aucune ne se révèle réellement meilleure que les autres. Au contraire, leur combinaison peut être la façon la plus aboutie d obtenir un contenu sonore à la fois riche en terme de rendu sonore et de possibilité de modulations. Le patch PureData de l application interconnectera donc au mieux ces différents éléments. Enfin, PureData dispose d une communauté active qui participe au développement d objets et de bibliothèques additionnelles. Ces ressources sont distribuées de manière libre. Il sera judicieux de les utiliser pour mener à bien l application sonore. 32/53

36 5. Mise en oeuvre du projet 1 Organisation de l'application Notre projet final est découpé en cinq applications. Initialement, nous avons fait le choix de séparer le projet en plusieures applications car techniquement, il était délicat voir impossible de travailler avec les deux webcams sur le même ordinateur. En effet, nous n'avons pas trouvé de technique pour récupérer deux flux vidéos provenant de deux webcams, celle-ci étant reconnues comme étant les même par nos applications de test. Positionner les deux webcams sur deux ordinateurs a un autre avantage : cela permet de séparer les traitements et donc de les accélérer afin d'arriver à des traitements en temps réel. La première application, exécutée indépendamment des autres permet de générer le fichier d'apprentissage du réseau de neurones à partir des différents signes et d'images binarisées correspondantes. Les quatre autres applications sont connectées entre elles et fonctionnent donc en même temps. Les traitements de chacunes des webcams ont été séparées en deux applications renvoyant chacune les données relatives à une webcam. Ces données sont envoyées à l'application principale qui sert à coordonner ces deux applications et à envoyer les données à l'application Pure Data. Cette dernière application se charge alors d'effectuer toute la partie synthèse sonore du projet. Les données entre les deux applications de webcam et l application principale sont transférées par réseau, via le protocole tcp/ip. Ces applications doivent donc être lancés sur des machines différentes communicant par réseau. L application Pure Data communique avec l application principale via le protocole OSC. Ces deux applications sont donc utilisées sur le même ordinateur. 9 Dispositif matériel L'installation nécessite au final un matériel relativement important. Au niveau informatique, l'installation utilise trois ordinateurs connectés en réseau via un HUB et trois câbles RJ45 droits. Deux des ordinateurs utilisent chacun une webcam, l'une filmant l'application de haut et l'autre filmant de face. Le troisième ordinateur ne nécessite pas d'autre matériel. Les deux webcams sont des Logitech Quickcam Pro La webcam filmant par le haut est positionnée via un portique sur lequel est tendu un drap noir pour faire un fond à la scène. La webcam de face est posée sur un pied (pied de caméra) face à l'utilisateur. Celui-ci positionne ses mains au dessus d'un support vert posé sur une table. L'utilisateur doit être habillé en noir, avec des manches longues. Il doit de plus posséder deux bracelets de deux couleurs différentes (un pour chaque main). Afin d'optimiser au mieux les traitements de reconnaissance de forme et de limiter les parasites sur l'image, il est nécessaire de calibrer au mieux la caméra avant toute utilisation de l'application. En effet, en jouant sur les paramètres de calibrage, on arrive 33/53

37 assez facilement à éliminer les ombres en modifiant la luminosité, en faisant ressortir au mieux les mains et en changeant légèrement la balance des blancs. Il est toutefois nécessaire de refaire une nouvelle acquisition de l'image de fond à chaque fois, celle-ci pouvant varier de couleur ou d'ombre en fonction des paramètres. Fig. 19 : Photo de l'installation 10 Choix du langage Après avoir beaucoup développé en langage C++, nous avons pris la décision de réaliser l'application finale en langage Java. Java est en effet un langage plus simple que le C++ et qui offre de nombreuses librairies très utiles pour ce projet comme par exemple la librairie JMF. Même si nous avons du recoder de nombreuses fonctions, notamment toutes les fonctions de traitement d'images, le gain de temps a été important. D'autre part, utiliser le Java nous permet de créer une application portable sur n'importe quel système d'exploitation, contrairement au C++ qui doit être recompilé sur chacune des machines. 11 Lecture du flux de webcam Les applications utilisant une webcam doivent pouvoir lire un flux vidéo. Une méthode est nécessaire au fonctionnement de notre programme : pouvoir récupérer l'image courante du flux vidéo. Pour la lecture de flux vidéo, nous avons utilisé l'api JMF de Sun. Celle-ci implémentant un grand nombre de méthodes permettant de traiter des flux multimédia (vidéo, audio...). La première implémentation de l'interface concerne la lecture de vidéo. Cette implémentation est commune à tous les systèmes d'exploitation (Linux, Windows, 34/53

38 MacOS...). Pour la lecture nous utilisons un Processor, qui nous permet de contrôler ses différents états de traitements, et de récupérer assez simplement l'image courante de la vidéo. Pour travailler sur la webcam, les méthodes sont relativement similaires, à cela prêt que la source provient d'une webcam et non d'un fichier vidéo en local. Nous faisons alors appel à un périphérique système pour récupérer ce flux. Cela n'a posé aucun problème sous Windows XP, mais ne fonctionne pas sous Vista. Par ailleurs, l'implémentation est différente sous Linux, et sous macos. En effet, Windows utilise pour la gestion des webcam le protocole vfw, tandis que Linux travaille sous v4l. Ces deux protocoles sont implémentés différemment, et donc le code doit être différent en fonction du système d'exploitation utilisé. 12 Application d'apprentissage du réseau de neuronnes Cette application ne fait pas partie en soit du logiciel mais elle n'en est pas moins importante pour la bonne exécution du programme. Les réseaux de neurones ont besoin dans un premier temps d'un apprentissage supervisé permettant de définir à quel type d'image correspond un signe. Une fois cette apprentissage terminé il n'est plus nécessaire d'utiliser ce programme. Le réseau apprend ainsi au fur et à mesure les différents signes de la main. L'application permet d'apprendre jusqu'à 5 modèles d'images différents. Il est possible de rajouter soit une image soit un ensemble d'images situé dans un dossier. Une fenêtre permet de visualiser la topologie de la carte auto-organisatrice. Cette topologie représentée en niveau de gris sert à connaître la fin de l'apprentissage. On considère l'apprentissage finie lorsque la topologie de la carte se stabilise car il n'y pas de tests d'arrêts dans l'algorithme d'apprentissage de la carte auto-organisatrice. Enfin il est possible de sauvegarder le réseau de neurones afin de l'intégrer dans l'application de reconnaissance de signes à partir du flux vidéo. Une fois l'algorithme d'un réseau de neurones mis en place, il faut ensuite trouver les paramètres optimaux pour le réseau. Le réseau est composé d'une carte de 1O sur 10 soit 100 neurones. L'entrée du réseau est constituée de l'ensemble des pixels de l'image soit 100x100 c'est à dire que synapses pointent sur chaque neurone. Ce qui nous fait un total d'un million de synapses sur tout le réseau. Les pas d'apprentissages μ et ß sont de 1 pour les neurones choisis et de 0.2 pour les neurones annexes. Afin de donner des ordres de grandeur, entre quarante et trente images sont nécessaires pour faire apprendre un signe et il nécessaire de passer prés de mille fois sur l'ensemble d'apprentissage afin que la carte se stabilise. Vingt-cinq à trente minutes sont alors nécessaires pour réaliser un apprentissage complet de l'ensemble d'apprentissage. 13 Application WebcamTop L'application Webcam top est un serveur qui va devoir renvoyer deux types d'informations à partir du flux vidéo : les signes effectuées par les deux mains et leurs coordonnées. Au démarrage de l'application plusieurs étapes sont nécessaires. La première est d'informer le numéro de port d'écoute. La seconde est de charger le réseau de neurones préalablement sauvegardé. Enfin aprés avoir initialiser le flux vidéo à partir de la webcam ou bien d'une vidéo il est possible de capturer une image qui va correspondre à l'image de fond( le panneau vert ). D'autres paramètres techniques sont réglables via un fichier xml chargé au démarrage de l'application. Ces informations 35/53

39 concernent principalement les teintes de couleur de la main et des bracelets ainsi que les différents taux d'erreurs. La chaîne des traitements appliqués à l'image provenant de la webcam positionnée en vue de dessus vise à générer deux images, une pour chaque main, qui soient prêtes à être envoyées au réseau de neurones. L'ensemble des classes relatives à ces traitements est regroupé au sein du package traitement. La chaîne complète est gérée par la classe TraitementMain, et plus spécifiquement dans la méthode process, qui prend en entrée un objet image (l'image brute de la vue de haut), et renvoie un tableau contenant les deux images redressées. Les deux classes les plus importantes sont les classes HandImage, qui gère les traitements depuis la prise en entrée de l'image vue de haut jusqu'à la détection des bracelets, et la classe ProcessedImage qui prend en entrée une image binaire avec les coordonnées des deux extrémités du bracelet et ressort une image redressée. 1/ Nous commençons par créer un objet HandImage à partir de l'image vue de haut, puis séparons les mains du fond pour obtenir une image binaire contenant les images des deux mains. 2/ On récupère les exceptions éventuellement renvoyées par la précédente fonction pour mettre à jour les variables de la classe Initialisation indiquant quelles mains ont été détectées. 3/ On sépare les deux mains et on remplit deux nouvelles HandImages avec les résultats obtenus pour chaque main. 4/ On crée le tableau des deux ProcessedImage à renvoyer, puis on initialise chaque élément avec les données des deux HandImage nouvellement créées. 5/ On lance les traitements de redressement sur chaque ProcessedImage. Ces traitements étant terminés, il ne nous reste plus qu'à retourner le tableau des résultats contenant pour chaque main sa positions x y ainsi qu'une image binarisée et redressée. A partir de ces images un objet ImageNormalise est créé. Cet objet permet de formater l'image pour le réseau de neurones. Afin d 'analyser le signe effectuée, chaque objet ImageNormalisé est ensuite envoyée au réseau de neurone via la fonction testmap de la classe CarteAuto. Elle va alors tester l'image sur la carte auto-organisatrice préalablement chargée au début de l'application. Nous obtenons alors le numéro du signe et ainsi toutes les données nécessaires sont prétes à être envoyées à la demande du client. 14 Application WebcamFace Le module de gestion de la caméra de face est une entité autonome qui a pour but, lorsque la demande lui en est faite, de retourner les barycentres des deux mains de l'image courante. Contrairement à la caméra du haut, les ombres sont beaucoup plus 36/53

40 prononcées, il n'y a pas de repère identifiable (bracelets), et la présence d'un utilisateur mouvant empêche de considérer un fond fixe dont nous soustrairions l'image en cours. Il a donc fallu imaginer une méthode différente de celle employée pour l'autre webcam. Nous avons décidé de travailler sur les couleurs plus que sur les formes. Une première tentative considérait un passage de l'image en TSV (teinte saturation valeur, ou HSV en anglais), pour un travail sur la teinte. Mais il s'est avéré que les mains apparaissaient parfois blanches et cela empêchait les comparaisons rapides en ne prenant que la teinte, de même que pour le noir. En somme, les distinctions nécessitaient trop de calculs. Aussi une autre méthode a été mise en place. Sachant que la scène est relativement homogène, fond, table, vêtements unis, il paraissait possible de leur affecter un trait commun permettant de les regrouper, et donc de sortir les mains. Les contraintes sont résumables à une seule condition technique : dans un codage RVB de l'image, seules les mains doivent avoir une composante rouge supérieure à 127 sur 255 (nous pouvons descendre jusqu'à 63 selon les conditions d'éclairage et de mise en scène de la pièce). Concrètement cela concerne les habits et la table servant de support psychologique à l'utilisateur, le fond. Ils peuvent être indifféremment de couleurs noire, bleue, verte (les test effectués le valident), et seules les mains doivent être apparentes (pas de bras, ce qui implique le port de manches longues). La première étape est un aplat des couleurs de l'image à huit couleurs RVB, chaque composante valant 0 ou 128 (en deux versions pour tester la plus rapide, une par tests communs et une par divisions entières). De là, les pixels valides sont ceux ayant une valeur R de 128, tout le reste est empiriquement une couleur bleue, verte ou noire, leur valeur R étant de 0. Cette valeur R est un parallèle à l'image binarisée de la méthode de la caméra du haut. Afin de prévenir les éventuels parasites, un déparasitage est effectué comme expliqué lors de l'érosion / dilatation ci avant. Ensuite, une protection sur l'algorithme de détection des mains est effectuée. L'image se voit modifiée par l'ajout d'une bordure intérieure noire qui va empêcher théoriquement la main de sortir de l'image. La main est coupée si elle dépasse. Pour le reste de l'algorithme, la main s'arrête logiquement un pixel avant le bord de l'image. Concrètement, cela permet au développeur comme à l'algorithme de ne pas avoir à traiter les cas des bords, toujours ennuyeux à protéger dans l'implémentation, et impliquant des tests supplémentaires. La perte de précision est nulle car, de toute façon, l'image ne fournit qu'une partie de la main. Le barycentre est donc dans tous les cas inexact comparé à la réalité physique. Enfin, la détection des "blocs" mains est effectuée de la manière suivante : - initialisation : balayage vertical en partant de la gauche jusqu'à trouver un pixel valide - mise en pile de ce pixel à l'indice 1 37/53

41 - ajout de ses coordonnées au total - traitement : parcours de la pile sur l'indice suivant (1 pour le premier tour) tant que la valeur de la pile est supérieure à 0 et prise de l'élément - ajout de ses coordonnées si le pixel est valide - considération de chaque pixel cardinal (haut bas gauche droite) - mise en pile à l'indice suivant si le pixel est valide, l'indice 0 sinon - finalisation : calcul du centre - même traitement en partant de la droite pour l'autre main La limite de cet algorithme est qu'il considère qu'il ne peut y avoir au maximum que deux blocs mains. Aussi, des parasites sur la gauche de la main gauche ou la droite de la main droite seront considérés comme étant le bloc main. Enfin, la méthode retenue pour le déparasitage consiste à grouper tous les pixels contigus en blocs et de voir quels sont les deux plus grands, sous entendu les mains. L'image finale ne contient que des pixels invalides, sauf ceux appartenant à ces deux blocs. Cette méthode est robuste (nombreux parasites, présence d'aucun pixel valide, etc.), plus rapide que les autres déparasitages jusqu'alors effectués, plus précise (aucun pixel valide n'est supprimé), et surtout plus sûre, car à la différence des érosions et dilatations, elle ne se limite pas à un nombre de fois prédéterminé qui pourrait laisser des parasites. Résultats de l'algorithme sur des images de test : Fig. 20 : Image de base Fig. 22 : Image déparatisée Fig. 21 : Image aplatie Résultats de l'algorithme sur les images de la webcam : 38/53

42 Fig. 23 : Image de base Fig. 25 : Image déparatisée Fig. 24 : Image aplatie 15 Application principale 1. Rôle Le projet se compose de trois unités de traitement essentielles à son bon fonctionnement. Un serveur qui récupère et analyse les données provenant de la camera de face, un autre serveur qui, de manière analogue, travail sur le flux vidéo de la camera dite top et un serveur chargé de générer du son en fonction des données issues des deux cameras. Or les deux serveurs qui détectent les signes et calcule les positions des mains ne peuvent communiquer directement avec l application sonore, à savoir le patch PureData, ce pour plusieurs raisons : Des problèmes de synchronisation : les deux serveurs ne travaillent pas à la même vitesse; les machines sont différentes, les algorithmes utilisés aussi. Etant donné qu ils ne se connaissent pas l un l autre, il n est pas possible d envoyer l ensemble des informations simultanément. PureData étant spécialisé dans le développement d architectures sonores, il n est pas adapté pour traité ce problème à la réception. De plus les données doivent être prétraitées et reformatées avant d être envoyées à PureData, afin de rééchelonner les valeurs et de construire les trames OSC. Une application centrale se révèle donc indispensable pour faire le lien entre les différents processus mis en œuvre dans le projet. De plus nous pourrons utiliser cette application pour ajouter des fonctionnalités qui aurait été difficilement implémentables sans une centralisation des données et des traitements. 8. Chaîne de traitement 1. Récupération des données des mains La première étape dans la chaîne de traitement de l application principale est la récupération des données des deux mains sur les serveurs associés aux webcams. Les données d une main ne sont considérées complètes que lorsque les 3 axes de positions et le signe de la main ont été renseignés ou le cas échéant définis comme non trouvés. Le fait que les serveurs top et face ont des temps de calcul différents implique que l application principale travaille au rythme du serveur le plus lent. Elle demande à un 39/53