ELECINF344/381

Partie interactive du site pédagogique ELECINF344/ELECINF381 de Télécom ParisTech (occurrence 2011).

Catégories

Détection de visages et reconnaissance faciale

Voici l’état des dernières réflexions sur la partie reconnaissance faciale du projet CASPER.

1) Acquisition du flux vidéo

Une première réflexion s’impose : il est inutile de faire de la reconnaissance faciale à 20fps, un test toutes les secondes est déjà largement suffisant. Le traitement n’a dès lors pas besoin d’une vitesse d’horloge phénoménale (on étudie les algos un peu plus loin), cependant la vitesse d’acquisition est déterminée par la caméra utilisée. On pense donc utiliser un DMA pour transférer le flux vidéo en SRAM. On utiliserait un double buffer : pendant que le DMA transfère une image dans une zone de la RAM, on travaille sur une image stockée dans une seconde zone. On pourrait dès lors utiliser 2 puces de SRAM, ce qui permettait d’avoir un double accès mémoire à moindre coût…

En travaillant à une résolution de 640*480, chaque pixel étant stocké sur 16 bits (5 bits pour rouge et bleu, 6 bits pour vert, comme sur cette caméra), une image prend 5Mbits… On pourrait aussi travailler en 320*240, ce qui ne fait plus que 1.2Mbits par image. Pour réduire la taille, on pourrait prendre directement les images encodées en JPEG (la caméra ci-dessus le propose par exemple), mais le coût de traitement ultérieur sera plus élevé… A étudier…

2) Détection des visages

On partirait sur la technique décrite dans cet article. Elle a l’avantage d’être très simple et beaucoup plus rapide que les méthodes à la Viola-Jones, ce qui permet de l’implanter avec des ressources de calcul réduites.

Le principe : on regarde la couleur de chaque pixel pour le classer en « peau / non peau ». On construit alors deux histogrammes représentant le nombre de pixels « peau », le premier en sommant sur chaque ligne, le second sur chaque colonne. On peut alors segmenter des « blobs » de peau dans l’image. A noter : cette technique peut donner des résultats plus ou moins aléatoires avec plusieurs visages sur la même image. On écarte ce cas pour commencer…

En 320*240 16bits, ça fait de l’ordre de 150000 accès mémoire 8bits pour parcourir l’image : rien d’insurmontable…

3) Reconnaissance faciale

On part sur la technique des « eigenfaces » (basée sur de l’analyse par composantes principales), technique assez ancienne qui a fait ses preuves.

Le principe : à partir d’une base de visages à différencier, on construit une base de vecteurs propres (les « eigenfaces ») de la matrice de covariance, sur laquelle on projette le visage à identifier. A partir des valeurs des composantes, on peut calculer la distance à chaque visage de la base, et reconnaître ainsi l’utilisateur. Un seuil peut permettre de rejeter le visage en cas de trop grande distance. Grâce à des astuces de calcul, la construction des vecteurs propres à partir de N images de M pixels peut se faire sur une matrice N*N, et non M*M, taille de la matrice de covariance initiale (ouf ! ca reste faisable…). A noter : la diagonalisation n’a besoin d’être faite que lors de changements de la base, chose somme toute rare et ponctuelle… De plus, rien n’empêcherait que ce calcul soit fait sur PC (puisque de toute manière on utilisera l’interface de configuration http pour associer les identités à chaque visage enregistré…).

Le gros de la reconnaissance est alors la projection du visage à tester sur la base (produit scalaire sur les M pixels de l’image pour chaque « eigenface »). Heureusement, cette technique ne nécessite pas une résolution très élevée, et peut fonctionner avec des images de 20*20 pixels, ce qui reste très raisonnable… Il faut simplement ajouter le coût du sous-échantillonage pour que tous les visages aient la même résolution…

Reste le stockage de la base d’ « eigenfaces ». En se donnant une limite de 10 visages à différencier, si chaque image fait 20*20 pixels et est codée en niveau de gris 8bits, 32 kbits suffisent…une mémoire de masse quelconque (flash, SDCard,…) partagée avec l’ensemble du système fait tout à fait l’affaire…

4) Mise en oeuvre

Reste la mise en oeuvre du tout, c’est-à-dire principalement le choix du microcontrôleur… Deux choix architecturaux s’opposent : un seul très gros microcontrôleur qui contrôle l’ensemble de CASPER, ou plusieurs microcontrôleurs dédiés chacun à une tâche. Cette deuxième solution a l’avantage d’autoriser à mettre en veille une partie des fonctionnalités s’il ne se passe rien : par exemple, mettre en veille la reconnaissance faciale s’il ne se passe rien, et la réactiver seulement si l’ambiance sonore dépasse un certain seuil (quelqu’un vient de claquer la porte par exemple), d’où une économie d’énergie (pour avoir le même effet avec un « gros » microcontrôleur, il faudrait en plus pouvoir modifier dynamiquement sa fréquence de fonctionnement, ce qui serait susceptible de perturber d’autres tâches (par exemple le traitement du son)). De plus, seuls les résultats intéressants seraient envoyés au contrôleur principal (« chef d’orchestre »), par le biais d’interruptions, ce qui facilite l’écriture du « comportement » de CASPER. En outre, les besoins en multi-tâche seraient beaucoup plus sommaires (inexistants ?).

On partirait donc sur un contrôleur milieu de gamme (référence à déterminer), quelques dizaines de MHz devant suffire pour toute cette partie « reconnaissance faciale ».

Sur le même sujet :

  1. Casper – Keypoints

Commentaires fermés.