Rapport Vinsdscent an Glad On

ENSEEIHT Telequid

Projet de fin dtudes

Reconnaissance dimages sur smartphones

Vincent AngladonIMA 2013

Tutrice ENSEEIHT :Mme Graldine Morin

Tuteur entreprise :M. Benjamin Ahsan

Mars - septembre 2013

Rapport PFE TABLE DES MATIRES

Table des matires

1 Remerciements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1 Prsentation de Telequid 6

2.2 Prsentation du sujet 7

2.2.1 Le contexte 7

2.2.2 Les enjeux 7

2.2.3 La reconnaissance dimages 8

2.2.4 Le cahier des charges 8

3 Organisation du travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.1 Planning 10

3.2 Mthodologie 10

3.3 Organisation technique 10

4 La reconnaissance dimages sur smartphone . . . . . . . . . . . . . . . . . . . . 134.1 Les solutions concurrentes 13

4.2 Les appareils cibles 13

4.2.1 La famille iOS 13

4.2.2 La famille Android 14

4.2.3 Conclusion de ltude des caractristiques matrielles 14

4.3 Architecture 14

4.3.1 Le back-oce 15

4.3.2 Le back-end 17

4.3.3 Les applications mobiles 18

4.4 tat de lart sur la reconnaissance dimages 19

4.4.1 Historique 19

4.4.1.1 Direntes approches 19

4.4.1.2 Les solutions sur plateformes mobiles 21

Vincent Angladon Rvision 0.6 3/ 39

Rapport PFE TABLE DES MATIRES

4.4.2 Les outils 22

4.4.2.1 Les points dintrt et les descripteurs 22

4.4.2.2 Comparaison des descripteurs 23

4.4.2.3 Estimation de lhomographie 23

4.5 Lalgorithme de reconnaissance dimages et de tracking 24

4.5.1 Les points dintrt 24

4.5.2 Comparaison des descripteurs 27

4.5.3 Validation 27

4.6 Le tracking 28

4.7 Les optimisations 30

4.7.1 Optimisations CPU 30

4.7.1.1 La famille x86 30

4.7.1.2 La famille ARM 30

4.7.2 Optimisations mmoire 30

4.7.3 Les optimisations GPU 30

4.7.3.1 OpenCL 30

4.7.3.2 CUDA 31

4.7.3.3 OpenGL ES 2 31

5 Autres travaux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.1 UCheck 33

5.2 Ralit augmente urbaine 33

6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

8 Glossaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388.1 Scientique 38

8.2 Technique 38


Rapport PFE 1 REMERCIEMENTS

1 RemerciementsJe voudrais remercier en premier lieu mon encadrant, Benjamin Ahsan qui sest trs impliqu

dans la russite de mon projet et ma apport son soutien technique avec laide de Julien Andr,co-encadrant. Cette aide ma t grandement prcieuse pour rentrer dans les projets existants delentreprise, ainsi que lapprentissage et le perfectionnement de mes connaissances en ObjectiveCet GWT entre autre, technologies que jignorais avant le dbut de mon stage.

Je remercie galement toute lquipe LIGUM du laboratoire DIRO de luniversit Polytechniquede Montral et plus particulirement Pierre Poulin qui ma accueilli et encadr durant mon sjourau Canada. Je noublierai jamais laccueil trs chaleureux que jai reu au Qubec.

Je souhaite exprimer ma gratitude Frdric Bruel, patron de Telequid qui ma accord saconance, recrut au sein de la socit et a veill au bon droulement du projet.

Je remercie Graldine Morin, ma tutrice technique de lENSEEIHT, qui au travers de runionsponctuelles sest occupe de veiller au bon droulement du stage, lamlioration de mon rapportet de ma soutenance et ma permis de rejoindre lquipe LIGUM avec laide de Vincent Charvillat.


Rapport PFE 2 INTRODUCTION

2 Introduction2.1 Prsentation de Telequid

Telequid est une socit de R&D spcialise dans les technologies transmedia qui peuvent treutilises dans des applications de tlvision sociale, reconnaissance visuelle et la publicit inter-active. Lquipe technique est constitue de deux ingnieurs Enseeihtiens promo 2010 : BenjaminAhsan et Julien Andre. Frdric Bruel, fondateur et directeur gnral de la socit est galementun ancien diplm de lENSEEIHT.

La socit compte parmi ses clients de grands groupes tels que JC Decaux, France Tlvision,TF1, et Orange.

Un certain nombre dapplications mobile ont t dveloppes au sein de Telequid : iTagCode, un dmonstrateur permettant de faire de la reconnaissance dimages, de QR codes

et de codes barres. Lapplication rendue obsolte par uCheck a t retire de lApp StoredApple ;

uSnap dcline en versions iOS et Android est une application lance en partenariat avecla socit JC Decaux. Cette application permet de reconnatre un certain nombre dachespublicitaires dployes par JC Decaux et dy associer un contenu multimdia. Usnap reposesur une technologie de reconnaissance dimages robuste dveloppe en interne chez Telequid.Lapplication peut galement reconnatre les QR codes et les codes barres ;

uCheck disponible sur Google Play et lApp Store dApple, est le dmonstrateur derniregnration du moteur de reconnaissance dimages de Telequid. la dirence de uSnap, lemode de capture est continu, cest--dire quil nest pas ncessaire dappuyer sur un boutonpour prendre une photo qui sera analyse. Lapplication permet galement de reconnatre desvidos ;

alloTV est un guide de programmes TNT rapide et simple, disponible uniquement sur iPhone.Lapplication intgre un classement des programmes par acteurs et par popularit, un systmede recommandation de programmes, des infos sur les lms, les acteurs, un moteur de recherchepour retrouver un acteur ou un programme, des rappels Push, et permet de tweeter sur lesmissions en temps rel ;

iTag est une application second cran pour iPad permettant de consulter un programmetlvis enrichi. Lapplication reprend les fonctionnalits dAlloTV et dispose galement defonctionnalits pour partager le programme en cours, recevoir des recommandations de pro-gramme TV bases sur ses gots, de reconnaitre la chane en cours ; iTag est en cours dex-primentation par dimportants oprateurs telecom et groupes media.

Fig. 1 : Captures dcrans de uSnap, iTag v1 et alloTV dveloppes chez Telequid.

La socit propose une large palette de services et sdk, dont : iRead qui est la technologie de reconnaissance dimages utilise par uSnap et uCheck ; iSyncTV, une technologie de reconnaissance audio permettant de dterminer la chane TV

regarde ;



iZapTV permettant de partager les 30 dernires secondes de TV live regardes sur Twitteret Facebook ;

iSyncTV qui est un service de reconnaissance de publicits tlvises proposant de la publicitinteractive.

2.2 Prsentation du sujet2.2.1 Le contexte

La reconnaissance visuelle dimages sur smartphone est un domaine en pleine eervescence.Depuis Google Goggles qui a t la premire application grand public populaire orir ce service,on trouve aujourdhui une plthore dapplications permettant de reconnatre des tableaux dans desmuses, des couvertures de livres, des pochettes de CD ou de DVD, des publicits...1. De nombreuxmagasins comme Kiabi, But, IKEA, Leroy Merlin2 enrichissent dj leur catalogues avec du contenudestin aux smartphones accessible par reconnaissance dimages.

2.2.2 Les enjeuxTelequid proposait dans son catalogue actuel un certain nombre de solutions de reconnaissance

dimages destines des annonceurs souhaitant lier par exemple des aches publicitaires uncontenu web.

Lannonceur pouvait eectuer les actions suivantes : Ajouter et retirer des images reconnatre regroupes sous forme de campagnes Associer et modier les actions eectues sur le tlphone aprs reconnaissance de limageLapplication de reconnaissance dimages doit donc pouvoir se synchroniser avec les souhaits de

lannonceur.

Fig. 2 : Diagramme des interactions utilisateurs de uCheck : lannonceur peut crer des campagnesdannonces depuis le back-oce qui notie le serveur de reconnaissance des nouvelles images reconnatre ou celles rajouter. Les tlphones se synchronisent avec ce dernier interlocuteur.

An dviter que lutilisateur du smartphone ait installer une application par annonceur,certains annonceurs sont regroups au sein dune mme base de donnes. Chaque applicationmobile est donc spcique une base de donnes et peut reconnatre les images de chacun desannonceurs partageant la mme base de donnes.

Ces solutions reposaient toutes sur la mme architecture :1https ://www.recognize.im/site/showcaseApps2http ://www.moodstocks.com/gallery/



une application qui envoie un serveur les images issues de la camra ; un serveur qui soccupe du traitement de limage, et renvoie au tlphone limage reconnue

ainsi quune action associe cette image telle que louverture dune page web, le lancementdune vido

Lobjectif de mon stage tait de trouver des solutions, permettant de reporter le plus de calculspossibles sur un iPhone. Autrement dit, dvaluer les solutions permettant de faire de la recon-naissance dimages sur un iPhone, sans communiquer avec un serveur central, lexception dunephase dinitialisation o une synchronisation des images reconnatre et des actions associes auxreconnaissances sont eectues. Bien que de trs rares concurrents proposaient dj des solutionsde reconnaissance dimages en local, il ntait pas certain que les technologies utilises sur les ser-veurs de Telequid pour uCheck puissent tre portes sur mobile, faisant de ce sujet un projet derecherche et dveloppement.

Lavantage de reporter les calculs sur le tlphone est de pouvoir eectuer de la reconnaissancedimages sans accs Internet et de rduire les cots de fonctionnement par la suppression du serveurcentral. On limine galement la crainte de saturer la charge dun serveur, dit autrement, lestlphones nont plus besoin dtre brids sur le nombre dimages traiter par seconde. Nousverrons par la suite comment ces spcications ont volu au fur et mesure du droulement demon projet de n dtudes.

2.2.3 La reconnaissance dimages

On distingue quatre problmes voisins, classs du plus proche au plus loign de notre sujet :la reconnaissance cest lidentication dobjets prdnis au sein dune image. Un algorithme

de reconnaissance fera la dirence entre une assiette de cresson et une assiette de mche,alors quun algorithme de catgorisation aura pour nalit de placer ces deux images dans lamme classe ;

la recherche dimages par le contenu (content-based image retrieval) qui a pour nalit deretrouver des images dans une base de donnes en utilisant une autre image comme requte(la rponse est un ensemble dimages) ;

la dtection : savoir si un objet appartenant une catgorie donne se trouve sur une image et quel endroit. Pour garantir la vie prive des utilisateurs, Google a mis en place un algorithmede dtection des visages et des plaques dimmatriculations sur sa plateforme Google StreetView. Il ne sagit pas de reconnaissance puisque le but nest pas dauthentier les direntsvisages dtects. Les algorithmes de dtection sont pour la plupart bass sur du machinelearning. On citera notamment la mthode de Viola et Jones (cascade of features) ;

la catgorisation ou classication qui consiste attribuer une classe ou une tiquette uneimage donne. Par exemple, elle indiquera si une image donne est plutt de type plage ou montagne La catgorisation retourne systmatiquement un rsultat (une classe) pourtoute image avec une complexit temporelle souvent infrieure aux algorithmes de dtection.Certes, on pourrait placer chaque ache dans une catgorie distincte, et utiliser un algorithmede catgorisation mais cela ne serait pas judicieux dans notre cas tant donn que le cahierdes charges impose un taux derreur trs faible.

Quelle que soit la mthode, on peut remarquer la prsence dun foss smantique, cest--dire quela reprsentation utilise par lordinateur (descripteurs locaux par exemple) pour la reconnaissancena aucun rapport avec la smantique de limage, cest dire ce que peroit le cerveau humain.Notamment dans le cadre de notre application, on ne cherche pas dtecter la prsence dunrectangle avant de retrouver la bonne ache.

Dans notre cadre, il sagissait uniquement de reconnaissance.

2.2.4 Le cahier des charges

Lobjectif de notre tude tait de concevoir une application capable de reconnatre visuellementdes photos pouvant tre des aches publicitaires et de les suivre (tracking) ou dacher du contenuassoci limage reconnue. Les contraintes suivantes devaient tre respectes :



compatibilit avec iOS 5.0 ou avec la version 9 du SDK dAndroid ; un temps de rponse de la reconnaissance dimages infrieur une seconde sur un iPhone 4

et sur un Nexus 4 un tracking uide (10 Hz minimum) ; une reconnaissance des images robuste aux changements dchelle, dclairage, ainsi quaux

occlusions partielles ; un taux derreur de la reconnaissance minime (moins de 1 pour 3000 tests).Le nombre dimages maximal reconnatre ntait pas une contrainte. Lobjectif tait de pousser

les solutions leurs limites et dvaluer celles qui permettaient de reconnatre un nombre maximaldimages.

A contrario, le respect des taux dchec tait une contrainte forte qui a dtermin certains demes choix.


Rapport PFE 3 ORGANISATION DU TRAVAIL

3 Organisation du travail3.1 Planning

Un premier planning prvisionnel avait t bauch par mon encadrant, laissant deux semainesau dbut du stage pour la prise en main de lenvironnement Apple, lapprentissage de lobjectiveC,la conception dapplication pour iOS, le dveloppement en GWT et les recherches. Les deux moissuivants devaient tre consacrs au dveloppement et lvaluation dalgorithmes de calcul de pointsdintrt et de descripteurs optimiss pour des plateformes mobiles. Puis deux mois taient rservs la conception dune structure de donne permettant de comparer rapidement les descripteurs desimages reconnatre. Les mois restants devaient tre consacrs aux autres parties de la pipeline dereconnaissance ainsi qu la ralisation ventuelle dun back-oce.

Voici un rsum des direntes tapes eectives du stage (jusqu la rdaction du rapport) :Semaines tape / Jalon1 6 Recherches, conception de prototypes pour iOS et Android

grant la reconnaissance et le tracking.7 8 Appui sur divers projets internes.9 10 Optimisation des paramtres de la reconnaissance jouant sur la performance.11 13 Cration dun SDK, design et conception dun moteur de reconnaissance

modulaire. Rexion sur larchitecture globale du systme, dbut deconception du serveur calculant les points dintrt des images reconnatreet du back-oce

14 15 Amliorations, modications et tests de uCheck pour iOS et Android.Fin de conception du back-oce.

17 21 Recherches et tests sur la ralit augmente urbaine. Conception dune versionGLSL de lalgorithme de calcul de ot optique avec la mthode de Lucas-Kanade.

23 Corrections de bugs et tentatives doptimisations du tracking sous iOS24 Cration du SDK du produit ni et de lapplication de dmonstration.25 Conception dun plan de test du SDK, tests, obfuscation du SDK. Analyse de la

monte en charge du serveur de reconnaissance dimages uCheck.

3.2 MthodologieEn ralit, avec larrive dune version stable dOpenCV avant le dbut de mon stage, la partie

sur le calcul des points dintrt et la structure de recherche des descripteurs fut termine la secondesemaine. Cest ainsi que la ralisation dun prototype pour Android, de recherches sur le tracking,ainsi que dautres tches se sont grees au sujet.

La mthodologie de dveloppement retenue tait une mthode agile. Tous les jours, un pointrapide tait eectu avec mon encadrant o on discutait des tches eectues, de celles restantes.Ctait galement loccasion de parler des dicults rencontres et des direntes solutions decontournement envisageables.

3.3 Organisation techniqueAn de garder une trace date de mes rsultats pour la ralisation de mon rapport et avoir un

support lors des points quotidiens eectus avec mon encadrant technique, jai tenu un journal debord sous la forme de chiers textes non formats o jinscrivais toutes les tches eectues, lesnouvelles ides, les dicults, les rsultats, des notes techniques, les publications lues

Jai galement utilis des dpts Git pour tenir un historique des changements eectus au seindes nombreux projets sur lesquels jai travaill. Loutil Git ma grandement aid pour parcourir lepass des projet, notamment pour retracer lorigine de bogues, versionner des changements indpen-dant via lutilisation de branches et fusionner les direntes versions du moteur de reconnaissancedimages, utilis et adapt par lapplication iOS, lapplication Android et le serveur traitant lesimages du back-oce. Lutilisation de cette hygine de dveloppement ma permis davancer sans



..Avril-Septembre 2013

.

1

.

2

.

3

.

4

.

5

.

6

.

7

.

8

.

9

.

10

.

11

.

12

.

13

.

14

.

15

.

16

.

17

.

18

.

19

.

20

.

21

.

22

.

23

.

24

.

25

..

Prototypage applis

..

Recherches

..

Versions PC/iOS

..

Version Android

..

Tracking

..

Autres projets

..

Optimisations 1

..

Serveurs

..

Backend

..

Back-oce

..

Ucheck

..

Canada

..

AR urbaine

..

Tracking en shaders

..

Finalisation

..

Optimisations 2

..

SDK

..

Tests, obfuscation

Fig. 3 : Planning eectif.



craintes de pertes de changements. Git tait plus adapt pour cette tche que Subversion enseign lENSEEIHT et utilis pour versionner lensemble des projets de Telequid. En eet, avec svn,les commits sont noys dans la masse de lensemble des projets de lquipe, et la rcupration deschangements ainsi que le versionnage passe constamment par le rseau, ce qui est peu pratique.

Fig. 4 : Capture dcran de GitList, install sur un serveur distant pendant mon stage pour suivrevisuellement les volutions de mes dpts et avoir des sauvegardes incrmentales de mes projets.


Rapport PFE 4 LA RECONNAISSANCE DIMAGES SUR SMARTPHONE

4 La reconnaissance dimages sur smartphone4.1 Les solutions concurrentes

Une des premires missions que jai ralise a t la recherche des solutions concurrentes, lacomparaison des services et prix proposs, ainsi que lanalyse de leurs technologies et performances.

Il existe un nombre important de solutions commerciales concurrentes orant des services dereconnaissance dimages que je rsumerai succinctement. La plupart dentre-elles proposent seule-ment une architecture de type REST (o la reconnaissance de limage est dporte sur un serveur).On citera Recognize.im, Pongr, Kooaba, Cortexika et Google Goggles. Enn, un nombre assezrestreint propose un sdk permettant de faire de la reconnaissance dimages directement sur letlphone. On citera IQEngine, Moodstocks et Smartsy.

Durant cette analyse, jai eu loccasion de mettre en pratique mes connaissances en analyseforensique an de rvler les bibliothques utilises par les solutions concurrentes et leurs choixtechnologiques. Jai utilis divers outils pour extraire les applications des tlphones, convertir etextraire les chiers de lapplication, dcompiler, visualiser les symboles des bibliothques, extraireles chanes, sparer les architectures cibles Les rsultats de cette analyse ont permis de me confor-ter dans les choix eectus pour la ralisation du prototype, ainsi que de dcouvrir de nouvellesbibliothques.

4.2 Les appareils ciblesLtude des caractristiques techniques des appareils cibles a t dterminante dans certains

choix de spcication et de conception tels que : les tudes de faisabilit, les langages de program-mation, les frameworks, les options de compilation,

4.2.1 La famille iOSLa famille iOS tait le systme dexploitation prioritaire pour mes tests. Dune part, parce quil

reprsente une grand nombre dutilisateurs rpartis sur un faible nombre dappareils, et dautrepart pour des raisons internes. Le march est faiblement segment, mais liPhone5 et les tablettespossdent des ratio de rsolutions dcran direntes obligeant dvelopper parfois des interfacesspciques certains modles.

Les iPods taient exclus des appareils cibles ainsi que les modles ne pouvant tre mis jourvers iOS 5, soit les iPhone 1, 3G et 3GS. Ces derniers ont dailleurs quasiment disparu et sontcompltement dpasss en terme de performances. iOS 5 apportait des fonctionnalits clefs commeun support complet pour lARC, le module Core Image, GLKit (surcouche OpenGL ES), Enntous les appareils compatibles iOS5 ont le bon got dtre compatibles OpenGL ES 2.

Liphone 4 constitue le modle le moins puissant de tous les appareils cibles ainsi que de maplateforme de tests. Il est quip dun processeur Cortex-A8 800 MHz, mono-coeur, supportantles instructions NEON, dune RAM de 512 Mo et dun GPU PowerVR SGX 535 cadenc 200MHz. Il possde galement lensemble des instruments de mesure ncessaires pour eectuer de laralit augmente urbaine sur capteurs, savoir un gyromtre trois axes, un acclromtre, unmagntomtre et un GPS. Sa camra au ratio natif 4 :3 peut prendre des photos en 2592x1936 dersolution maximale. Elle possde un champ de vision horizontal de 61 et 47.5 vertical.

iOS a t conu de faon similaire OS X. On retrouve ainsi le mme noyau (XNU), la mmeABI (Mach-O), le mme framework (Cocoa), le mme outil de dveloppement (XCode). Le langagede programmation utilis pour crire des applications est lobjectiveC, un langage orient objet,dont la syntaxe particulire rappelle celle de SmallTalk : les appels de mthodes se font par passagede messages. Il est galement possible dutiliser lObjectiveC++ qui permet dintgrer du code C++dans du code ObjectiveC. Les applications peuvent ventuellement tre dveloppes en HTML5et Javascript, mais le code gnr est alors public, et il nest pas possible daccder toutesles fonctionnalits bas niveau ni de faire du calcul de faon performante. De plus le look andfeel de lapplication sera web et non pas iOS. Nanmoins ce choix est trs populaire au seinde la communaut des dveloppeurs dapplications mobiles. Enn, les quipes de Mono (qui ont



dvelopp une machine virtuelle .NET multi-plateforme ainsi quun compilateur C#) ont lancXamarin, un produit permettant de dvelopper en C# (un langage de trs haut niveau) pour iOS,OS X, Android, et Windows en partageant le mme code, sauf pour les vues. Les applications ontle mme look and feel que des applications natives et permet daccder aux classes Java (pourAndroid) ainsi quaux API natives (telle que UIKit). Cependant, les prix des licences annuellessont trois plus levs que pour une licence Apple, et il y a moins de support.

4.2.2 La famille AndroidLa famille Android est trs segmente en terme de performances, darchitectures, rsolutions

dcrans et de versions du systme dexploitation, rendant les essais sur cette plateforme secon-daires. Les processeurs des appareils sous Android peuvent tre des ARM, des x86 dINTEL, voiredes MIPS. Lappareil utilis pour la majorit des tests tait un Nexus 4, choisi pour sa prise encharge dAndroid 4.3 et qui ct performance se place dans la moyenne des tlphone rcent sousAndroid haut de gamme.

En comparaison avec liPhone 4, son processeur Qualcomm APQ8064 quadri-coeurs fait de luiune Formule 1.

Un HTC Wildre sous Android 2.2 a galement t utilis pour vrier que les modicationsque javais apport lapplication uCheck passaient bien sur les anciens modles ainsi que pour destests de performance. Son processeur armv6 Qualcomm MSM7225 mono-coeur faisait ple gureface celui liPhone 4.

Le dveloppement dapplications se fait en Java SE via lutilisation du SDK Android qui oreapproximativement les mmes possibilit que Cocoa pour iOS. Du code natif peut tre crit en C++et interfac au code Java via JNI. Il est galement possible dcrire des applications en HTML5 ouen C#

4.2.3 Conclusion de ltude des caractristiques matriellesLtude prcdente a permis dtablir les conclusions suivantes : la compilation vers les architecture cibles armv7 et armv7s sous iOS, armv7, armv6 et x86

pour Android ; lutilisation du C++ pour le dveloppement du moteur de reconnaissance dimages, li via

de lObjectiveC/C++ (sous iOS) et du Java-JNI (sous Android) ; lutilisation ventuelle dOpenGL ES 2 et non pas des versions 1 ou 3 ; les optimisations ventuelles via des instructions NEON, lutilisation doptions de compila-

tion gnrant des optimisations NEON, la prfrence vers des bibliothques exploitant cesoptimisations telles quOpenCV ou Eigen ;

lemploi du multi-threading et de bibliothques lutilisant an de proter pleinement des CPUmulti-coeur des iPhone4S/5 et des processeurs rcents des mobiles sous Android ;

la faisabilit dune application de ralit augmente urbaine.

4.3 ArchitectureLarchitecture du produit nal est dcoupe en plusieurs parties : un back-oce1 permettant aux annonceurs de crer des campagnes, ajouter des images

reconnatre, et des actions associes la reconnaissance des images. un backend traitant les images et vidos soumises par les annonceurs. des applications de reconnaissance dimages tournant sous iOS et Android.Le stockage des donnes est eectu par le biais de deux services : Une base de donnes PostgreSQL qui rfrence les clients, les campagnes, les images recon-

natre et les actions associes la reconnaissance.1Bien que ce front-end soit destin au client, nous ne lavons pas appel front-oce an de garder les dnominations

ct client. En eet, ce front-end va tre utilis par notre client pour dterminer les images reconnues par lesapplications installes par les clients de notre client.



Un bucket du service S3 dAWS (Amazon Web Service) an de garantir de la haute disponi-bilit sur les images, les vidos et les descripteurs des images.

Fig. 5 : Architecture nale du projet. Les ches noires reprsentent les interactions dun utilisateuravec un composant. Les ches vertes correspondent aux transactions eectues lors de lajout duneimage reconnatre, les rouges aux suppressions de ces images. Les numros prsents correspondent lordre des actions

Cette architecture a t conue en collaboration avec mon tuteur de stage la suite de plusieursitrations. Jai ralis lensemble des composants de cette architecture, lexception du back-oceo jai repris du code existant dun autre front-end que jai adapt.

Lorsquun annonceur connect via le frontend sur le serveur 1, ajoute une image reconnatre(che A), limage est uploade sur le bucket S3 (che 2) puis une rfrence est rajoute la basede donnes (che 1) et une notication est envoye au serveur de traitement des images (serveur2 via la che 3). Ce serveur rcupre limage sur le bucket (che 5), calcule ses points dintrt etses descripteurs, et vrie quune image similaire nest pas dj prsente. Si cette dernire conditionest vrie, les points dintrts sont renvoys au bucket (che 5) et une notication de succs estenvoye au front-end (che 6).

Lorsquune image est retire, limage est drfrence du serveur 2 (che 3), de la base dedonnes (che 1), et supprime du bucket s3 (che 2).

Lors du lancement de lapplication mobile, ce dernier va synchroniser sa liste des descripteursdes images et des actions de reconnaissance avec le back-oce.

4.3.1 Le back-oce

Le back-oce est crit en GWT et bas sur celui du produit uCheck.Il comporte : Une page dauthentication ; Une page de visualisation et de cration des campagnes ; Une page de visualisation, ajout, modication et suppression des images/vidos associes

une campagne ainsi que des actions qui sont associes leur reconnaissance.Lensemble des donnes ( lexception des images) proviennent dune base de donnes Post-

greSQL. Le schma est conu de telle sorte que plusieurs clients soient rattachs la mme base de



donnes an quils puissent utiliser la mme application pour reconnatre leurs images. Un clientpeut crer plusieurs campagnes, lesquelles peuvent contenir plusieurs contenus (images ou vidos reconnatre). Chaque contenu peut tre associ plusieurs urls qui sont des objets dnissant unlien, un texte et un tag.

La gestion de la base de donnes est faite la main sans laide de bibliothque dORM. Ceschma impose lutilisation de 4 jointures pour la rcupration de lensemble des images (avec leursurls associes) provenant dune base de donnes donne.

Fig. 6 : Schma des relations entre les tables utilises par le back-oce. Les cases en vert claircorrespondent aux clefs primaires. Schma ralis avec schmaSpy



Fig. 7 : Capture dcran de la page de modication des images et des actions associes aux recon-naissances de ces images.

Le back-oce met disposition des mobiles les actions associes chaque image sous formedun chier JSON. Lensemble des descripteurs est mis jour entre le mobile et le serveur via leback-oce galement. La description de ce mcanisme est dcrite dans la suite de ce rapport.

Je me suis galement occup du dploiement de ce service sur un serveur Tomcat7.

4.3.2 Le back-endBien que le back-oce soit constitu galement dune partie serveur que lon pourrait appeler

backend puisquelle gre la logique applicative du front-end, cest dire quelle va mettre jour lesmodles aprs avoir fait des vrications sur les entres de lutilisateur et lavertir en cas derreur. Ilfallait un autre service, plus apte faire des calculs intensifs et pouvant tre dtach du back-ocepour des raisons de cloisonnement applicatif. En eet, lorsquune image est uploade par lutilisa-teur, il faut vrier quil nexiste pas dj une image similaire en base, puis si cette condition estremplie, calculer les points dintrt et les descripteurs qui seront envoys aux tlphones et utilisspour les comparaisons avec les images suivantes. Nous appellerons calculateur-comparateur ceservice.

Le moteur de reconnaissance sur les tlphones tant dj crit en C++, il fut dcid dcrireun service en C++ galement qui communique avec le back-oce via des sockets et des requtesHTML. Pour simplier le dveloppement de ce service nous avons utilis la bibliothque QT5 ande grer la partie socket TCP et des threads de faon plus portable. Le dploiement a t test surdes serveurs Tomcat7.

Lorsquun usager a upload un contenu sur le back-oce qui la envoy au bucket s3, une trameTCP contenant lidentiant et des informations relatives ce contenu est envoye au calculateur-comparateur. Pour empcher que deux images identiques envoyes simultanment soient insresen base, une seule comparaison de limage est eectue la fois. An dviter davoir maintenirun verrou durant tout le processus de reconnaissance, le calculateur-comparateur naccepte quuneseule connexion la fois (les autres sont mises en attente de par le fonctionnement des sockets).La trame reue, le contenu traiter (identi par la trame) est tlcharg depuis le bucket s3, puisleurs points dintrt et descripteurs sont calculs. Cette tape est ncessaire car les tlphonesne comparent pas les images directement mais les descripteurs de ces images (qui ont le bon gotdtre plus lgers que les images) comme nous le dtaillerons par la suite. Ces derniers sont uploads



sur le bucket s3 puis compars aux autres descripteurs. Si la comparaison est ngative, on met jour notre structure de donnes, puis on notie le back-oce du succs de lopration en appelantune de ses servlets.

Chaque base de donnes est associe un ou plusieurs serveurs calculateur-comparateur. En au-cun cas un serveur ne gre plusieurs base de donnes. Dune part pour des raisons de cloisonnementet dautre part parce quil y a un verrou sur ltape danalyse/comparaison de limage situe enaval de la rception de la notication qui empcherait de traiter simultanment deux noticationscorrespondant des images de bases de donnes dimages direntes.

4.3.3 Les applications mobiles

Les applications mobiles dveloppes pour iOS et Android, sont les parties qui eectuent leplus de calculs, malgr les faible performances de ces plateformes. Comme expliqu prcdemmentle moteur de reconnaissance est crit en C++ et est commun aux deux OS retenus, ainsi quaucalculateur-comparateur. Seule la gestion de la camra et la synchronisation des descripteurs desimages reconnatre est dveloppe dans le langage natif de la plateforme considre. Le fonction-nement de la reconnaissance dimages est expose dans la suite de ce rapport.

Pour la version iOS, jai ralis un framework ainsi quune application de dmonstration, pourla version Android seulement une application de dmonstration.

Les applications synchronisent les descripteurs des images reconnatre avec le back-oce endeux tapes. Dans un premier temps le tlphone envoie une requte POST contenant la liste desidentiants des descripteurs prsents en local sur le tlphone. Le back-oce calcule lintersection decette liste avec la liste courante des descripteurs, et renvoie au format JSON deux listes contenantrespectivement les identiants des descripteurs tlcharger et de ceux supprimer. Dans unsecond temps, le tlphone tlcharge et supprime les chiers correspondant et peut enn gnrersa structure de recherche des descripteurs.

Fig. 8 : Graphique de ot de contrle de lAPI dcrivant les changements de modes entre lareconnaissance dimage et le suivi de limage reconnue.



Fig. 9 : Graphique de ot de contrle de lapplication de dmonstration.

4.4 tat de lart sur la reconnaissance dimages4.4.1 Historique

4.4.1.1 Direntes approchesDavid Lowe a t un des prcurseurs proposer une mthode robuste de reconnaissance

dimages. Dans sa publication prsentant SIFT [Low03], il propose la pipeline suivante : calcul des points dintrt et de leurs descripteurs via SIFT ; appariement des descripteurs ayant la norme L2 la plus proche ; La recherche des descripteurs

les plus proches (des images de rfrence) seectue laide dune variante de larbre-kdappele best-bin-rst ;

calcul de la transforme de Hough pour clustriser les descripteurs ayant le mme scalinget orientation (orientation et scaling normaliss avec les valeur du descripteur auquel il estappari) ;

estimation de la transformation ane.Bien que les descripteurs (reprsents par un vecteur de 128 ottants) permettent de discri-

miner de faon ecace les points dintrt, un grand nombre de points dintrt de larrire-planpeuvent tre apparis incorrectement et donner lieu des faux-positifs lors de ltape de dtec-tion. Lowe prconise ainsi de vrier la cohrence gomtrique (spatiale) des appariements en lesregroupant en clusters par le biais dune transforme gnralise de Hough implmente via unetable de hachage. la sortie de cette clustrisation il obtient des clusters correspondants des



descripteurs appartenant potentiellement la mme image de rfrence. Selon David Lowe, ap-pliquer RANSAC ou une mthode des moindres carrs cette tape pour obtenir directement latransformation (entre limage de rfrence, et la photographie contenant limage dtecte) seraitinecace car il reste encore cette tape plus de 50 % de points aberrants (outliers). Enn lesplus gros clusters sont soumis une tape de validation au cours de laquelle la transformationane entre les points apparis est calcule par la mthode des moindres carrs. David Lowe choisitdestimer une transforme ane car ses descripteurs ne sont invariant qu ces transformations etpour la raison quil sut de trois correspondances (en pratique davantage pour plus de robustesse)pour les dterminer.

Contrairement David Lowe, nous navons pas opt pour un seuil relatif (garder les apparie-ments dont la distance entre les descripteurs est infrieure k fois la deuxime meilleure distance,David Lowe prenant k = 0; 8). En eet, nous avons remarqu que sur certaines images, il pouvaity avoir trois descripteurs qui avaient une distance extrmement faible avec ceux de limage derfrence, les autres descripteurs correctement apparis ayant une distance faible ou moyenne avecceux de limage de rfrence. Dans cette situation, une valeur de k faible empchait la slection deplus de ces trois appariements. A contrario, avec dautres images, en particulier celles prsentantune zone de ou, la deuxime meilleure distance sera trs leve, et le trop grand nombre dapparie-ments pris en compte fera chouer ltape de validation gomtrique. Dun point de vue thorique,il ne nous paraissait pas non plus judicieux de dnir un seuil prenant en compte seulement lavaleur minimale de la distribution des distances entre les descripteurs. Nous avons ainsi opt pourun seuil global, qui donnent de meilleurs rsultats en pratique et pnalisant volontairement lesimages oues, qui nont pas lieu dtre compares des images de rfrences parfaitement nettes.

Une des limitations de la mthode de Lowe est la recherche, pour chaque descripteur de limagephotographie, du descripteur le plus proche parmi ceux des images de rfrence. En fonction dunombre dimages de rfrences prises en compte, cette recherche peut tre trs coteuse. De plus,lors de ltape dappariement des descripteurs, on remarque quun nombre non ngligeable dap-pariements sont faux. Il arrive frquemment que certains descripteurs dune image soient prochesde descripteurs dune autre image dentranement. Lide serait de pouvoir dterminer quels des-cripteurs sont les plus pertinents, et les considrer en priorit.

Gabriella Csurka propose dans son article [CDF04] de rduire le problme de catgorisationen un problme dapprentissage supervis multi-classes o une classe correspond une catgorievisuelle. Cette mthode intitule Bag of Keypoints consiste rduire une image en une liste dergions (features) qui sont caractrises sparment et values avec un histogramme dapparencedans les autres images, de la mme faon que la pertinence dun mot est value en fonction deson nombre doccurrences dans un jeu de documents. Les direntes tapes de lentranement delalgorithme sont les suivantes :

On calcule sur les images de rfrence des points dintrt et leurs descripteurs associs. On quantie (quantization) les descripteurs obtenus an de rduire le nombre de mots. Pour

cela, on rassemble les descripteurs en clusters : les centres des clusters dnissent les mots. Enreprenant lanalogie avec les mots, cette tape de clustrisation va permettre de considrerles mots tel que gomtrie, gomtries et gomtriquement correspondent un mmemot.

Chaque image est ainsi reprsente par un vecteur dont les composantes correspondent auxfrquences dapparition de chacun de ces mots. Les composantes des vecteurs sont ensuiter-ajustes avec des poids qui varient en fonction de la frquence dun mot dans lensemblede la base. On cre ensuite un annuaire invers dans lequel chaque mot va pointer vers lesimages dans lequel il apparat avec son occurrence.

Un classicateur de type Bayes ou SVM (Support Vector Machine) va permettre de dter-miner quels vocabulaires et paramtres du classicateur donnent les meilleurs rsultats decatgorisation.

Pour dterminer la photographie la plus proche dune image requte, on calcule le vecteur defrquence des mots de limage requte que lon compare avec les vecteurs des images dentranement.



Le taux derreur minimal obtenu par Gabriella Csurka est de 15%, ce qui peut paratre lev,mais en ralit, le taux derreur sans tape de validation, de la mthode de David Lowe est pluslev.

Une des limitation de lapproche bag of keypoints est que la clusterisation et lapprentissagesupervis pour la cration du vocabulaire sont coteux si le nombre dimages est important. Deplus il faut recommencer cette tape quand on rajoute une image dans la base de connaissances.

David Nistr and Henrik Stewnius [NS06] proposent une variante intitule Vocabulary Tree,utilise pour ranger les mots de faon hirarchique. Chaque nud est associ un cluster decaractristiques (features) qui est progressivement subdivis chaque hauteur, via lalgorithmeK-means, en arbre de clusters plus petits.

4.4.1.2 Les solutions sur plateformes mobilesEn 2005, Gerald Fritz et al. [FSP06] est lun des premiers proposer une solution de re-

connaissance sur mobile. A lpoque, la technologie ne permet pas deectuer les traitements enlocal. Son application externalise ainsi les calculs sur un serveur qui reconnat par classication dedescripteurs i-sift, le btiment dune photographie.

La mme anne, Jonathon S. Hare et Paul H. Lewis proposaient une application mobile dereconnaissance duvres darts [HL05] o la phase de reconnaissance tait galement eectuesur un serveur. Ltape de reconnaissance sappuie sur une approche bag of keypoints utilisantles descripteurs de SIFT, laquelle est ajoute une tape de validation gomtrique consistant dterminer lhomographie entre les descripteurs apparis entre les images requte et rfrence.

Un an plus tard, une autre tentative de reconnaissance doeuvre dart est ralise par HerbertBay et al. [BFG06] mais cette fois-ci les calculs sont eectus en local sur une tablette quipedun processeur Pentium M cadenc 1.7 GHz. De mme que dans la mthode de David Lowe, lesdescripteurs de SIFT sont apparis en utilisant un seuil relatif, mais au lieu dutiliser lalgorithmebest bin rst pour comparer les descripteurs, il eectue une recherche linaire. Herbert Bay et almontre quil possible datteindre des taux de reconnaissance quivalents en utilisant les descripteursSURF, avec un gain de rapidit de lordre de trois. Sur un corpus de 205 images de dimensions320x240, il arrive identier les uvres dart en une minute minimum et avec un taux de succssuprieur 84.5 %.

Gabriel Takacs et al. [TCG08] ont travaill sur laugmentation des btiments dune ville,o la reconnaissance des photos est eectue en local sur des tlphones portables de type NokiaN93, N95 et N5700 aux performances nettement infrieures celle dun iPhone 4. Lapplicationnest pas sans rappeler celle de la RATP qui permet dacher en ralit augmente les stationsde mtros et les lieux dintrt. En raison des performances de ces tlphones, la base de donnesdes descripteurs est tlcharge en fonction de la position de lutilisateur. De plus ils utilisentles donnes du GPS embarqu pour restreindre la recherche certaines cellules dune carte quiappellent loxels, voisines de la position de lutilisateur. Utilisant en entre un grand nombre dephotos ayant des zones communes, ils slectionnent les descripteurs qui apparaissent sur plusieursimages, permettant de rduire considrablement la base des descripteurs, calculs partir duneimplmentation maison de SURF. Ensuite ANN [AMN98] est employe pour les recherches dansla base des descripteurs. Enn la validation gomtrique est eectue en utilisant un modle ane.Gabriel Takacs et al. argumentent ce choix par le fait que lestimation dune homographie est pluscomplique estimer et ncessite davantage dappariements corrects (inliers), alors quun modleane donnerait des rsultats quivalents. Ce choix doit sexpliquer galement par le fait quenprenant des photos peu prs en face dun btiment, on conserve approximativement le caractreparallle des lignes des faades faisant face lobservateur.

Avec des images de taille moyenne 640x480, 250 points dintrt par image, 7000 descripteursdans la base, ils obtiennent une temps de reconnaissance de 2.8s, dont 2.4s pour SURF et uneconsommation mmoire de 1.8Mo pour la base des descripteurs. Larbre de recherche des descrip-teurs est reconstruit chaque changement de loxel, et ncessite 0.5s. En guise de comparaison,notre prototype actuel sur iPhone 4 eectue une reconnaissance sur des images de tailles 480x640



en 800ms, dont 400ms pour le calcul des points dintrt et de leurs descripteurs en utilisant ORB.Avec 256 images de rfrence comportant 400 points dintrt, la construction de notre index prend1s et ncessite 19Mo, tandis que la recherche dans la base des descripteurs seectue en 70ms avecLSH.

4.4.2 Les outils

4.4.2.1 Les points dintrt et les descripteursUne des tapes de la reconnaissance parmi les plus critiques est le calcul des points dintrt et

de leurs descripteurs locaux, qui sont des vecteurs reprsentant les caractristiques de limage auvoisinage dun point. Dune part, il sagit dune tape trs coteuse en calcul et dautre part, laqualit des points dintrt dtermineront la robustesse de la reconnaissance.

Mais tout dabord, pourquoi pour eectuer de la reconnaissance dimage, sacharne t-on uti-liser des points dintrt coupls des descripteurs dont la reprsentation pour un cerveau humainest plutt abstraite, alors quune image peut (comme le fait le cerveau humain) tre identie parson ensemble de formes et de couleurs qui pourraient tre obtenues informatiquement par segmenta-tion ? Tout dabord, les couleurs sont souvent altres par lclairage (couleur, intensit), des reetsIl faut ainsi tre trs tolrants sur les plages de valeurs acceptables pour distinguer des couleursdune palette donne. Ensuite, les algorithmes de segmentation sont trs coteux en temps de calculet il ny a pas dunicit de la segmentation. Cest trs suggestif de dire quune segmentation s1 estmeilleure quune segmentation s2. Selon les paramtres dnis, certaines rgions se retrouveronsfusionner et il sera trs dlicat de les apparier via des descripteurs de formes aux rgions de limagede rfrence, dautant plus ces formes auront subies des transformations homographiques. Tandisque les points dintrt et les descripteurs sont robustes tous ces changements, permettant lareconnaissance. Enn, une motivation minoritaire consiste dire que les algorithmes de calcul despoints dintrt et des descripteurs miment la faon dont la vision humaine fonctionnerait : par larecherches de contours ou de variations de gradients direntes chelles.

Un bon algorithme de calcul de points dintrt/descripteurs doit tre rptable, cest--dire quelon doit retrouver les mmes points dintrt/descripteurs sur des images direntes dune variationdclairage, dchelle, de rotation ou de changement de perspective. En mme temps les descripteurslocaux doivent tre assez discriminants an de permettre un meilleur taux dappariement. Ce justemilieu est tellement dlicat que les eorts pour amliorer linvariance des descripteurs aboutissentsouvent une perte de distinction des descripteurs.

Malgr son anciennet, SIFT [Low03] est souvent prsent comme la rfrence en matire derobustesse, ce qui sest concrtis lors de nos tests par les meilleurs taux dappariements. Toutefois,SIFT soure de deux gros dfauts : sa lenteur (4.8s sur un iPhone 4 pour une image de dimensions480x356) et la lourdeur de ses descripteurs (128 nombres virgule ottante).

SURF [BETVG08] nous a galement surpris concernant sa robustesse, mais du par sesperformances : 1.1s pour le calcul des points dintrt.

ORB [RRKB11] que nous avons retenu est bas sur une variante de FAST (pour les pointsdintrt) et de BRIEF (pour les descripteurs) rendu invariant aux rotations via la mthode deRosin. Les descripteurs dORB sont des vecteurs de 32 octets. Le choix de ne pas utiliser denombres virgule ottant ( contrario de SIFT et SURF ) plus coteux manipuler, se rvleparticulirement judicieux sur des plateformes mobiles.

Aujourdhui, des algorithmes de calculs de points dintrt et des descripteurs ont t spcia-lement conus pour tre performants sur des tlphones. On citera notamment Wei-Chao Chenet al. qui propose une optimisation de SURF [CXG07] CARD [AY11] de Mitsuru Ambai andYuichi Yoshida base sur des gradients orients et lalgorithme de Simon Taylor et Tom Drum-mond [TD09] bas sur lalgorithme FAST et dont les descripteurs proviennent dun apprentissagesupervis de fentres autour des mmes points dintrt dimages ayant subies des changements deperspective, dchelle et des ous gaussiens. Malheureusement, le code source de ces algorithmesnest pas publi et la licence des binaires de CARD interdit toute exploitation commerciale.



4.4.2.2 Comparaison des descripteursUne fois les descripteurs de limage reconnatre calcule, il faut les comparer lensemble

des descripteurs des images de rfrence. Avec 200 descripteurs par image, il nest pas raisonnabledeectuer une recherche linaire au-del de 5 images dans la base des descripteurs. Il faut donc unestructure de donnes adapte, orant si possible pour les recherches, une complexit temporelle eno(log(n)), o n est le nombre de descripteurs dans la base.

S. Arya et al. [AMN98] explique que si la condition 2d


correspondants aux plus faibles distances ont plus de chances dtre corrects (inliers), do lidede les considrer en priorit. Cest sur ce constat que se base PROSAC [cit05] qui promet un gainen performance dordre 100.

Toutefois, cest lalgorithme LMEDS que nous avons retenu (qui ncessite plus dinliers queRANSAC), car pour des performances nettement plus leves que RANSAC, nous obtenions desrsultats comparables. Ceci sexplique par le fait que lors de nos exprimentations, le taux dappa-riements errons tait souvent soit faible, soit trs lev. RANSAC aurait sans doute t intressantsi lon avait eu des cas avec autant dappariements errons que corrects.

4.5 Lalgorithme de reconnaissance dimages et de tracking

La pipeline retenue de reconnaissance dimages sinspire de la mthode de David Lowe et com-prend les tapes suivantes :

calcul des points dintrt et des descripteurs ; recherche des descripteurs les plus proches parmi ceux des images reconnatre et dtermi-

nation de limage potentiellement la plus proche ; validation via estimation de lhomographie.

Fig. 10 : La pipeline de reconnaissance dimages.

4.5.1 Les points dintrt

Le calcul des points dintrt et des descripteurs est la premire tape de la pipeline. Dans unpremier temps jai valu les performances de dirents algorithmes de calcul de points dintrtet de descripteurs sur des images de taille 480x360 et slectionn ceux ayant un temps de calculinfrieur 0.5s sur un iPhone4 pour 800 points dintrt. savoir FAST, BRISK, ORB et STARpour les dtecteurs et BRISK, BRIEF et ORB pour les descripteurs qui sont tous des descripteursbinaires, plus rapides calculer que leur pendant ottant.

Les candidats retenus ont ensuite t valus via un test de robustesse plutt naf qui consistait comparer la dirence des positions des coins de limage dtecte dont on avait estim lhomographieaprs application de lhomographie avec les vritables coins de limage.



Fig. 11 : Graphique en btons reprsentant lissue du test de robustesse, les moyennes pourchaque image de test des moyennes des sommes des carts entre les coins estims et leurs valeursexactes. Lorsque cette valeur dpassait 24 pour un couple dimages, lhomographie tait estimecomme errone et cette valeur tait conserve jusqu la n du test pour viter dtirer le graphiquegnr par le programme. Les tests ont t eectus ici sur tous les couples de dtecteur/extracteur,mme ceux considrs comme pas assez performants.

Le jeu dimages de tests tait gnr en utilisant le logiciel de modlisation 3D Blender, pluttquen appliquant des transformations homographiques des images issues de matrices dhomo-graphies alatoires. La raison cela tait que le cahier des charges autorisait le moteur de re-connaissance chouer si langle entre la normale de limage reconnatre et laxe Z du reprecamra tait trop important o si lcart de distance entre limage et la camra tait galementtrop grand. Cet angle et cette distance taient plus facilement paramtrables en passant par desimages de synthse. Un deuxime jeu dimages issues de photos des images reconnatre prisespar liPhone fut galement utilis ultrieurement. Le programme dvaluation naf crit en Pythonrecherchait de faon linaire, parmi tous les descripteurs calculs sur limage de rfrence, celui quitait le plus proche (au sens de plusieurs distances dont celle retenue fut la distance de Hamming)du descripteur de limage reconnatre, sans eectuer de validation croise. Une fois lensembledes appariements calculs, on gardait seulement ceux dont la distance tait infrieure un certainseuil multipli par la plus petite distance. Ce seuil tait ajust empiriquement en fonction desdescripteurs an dliminer le plus grand nombre dappariements incorrects (outliers).



Fig. 12 : Test de robustesse. gauche limage de rfrence. droite limage requte. Les cerclesreprsentent les points dintrt, les segments les appariements slectionns par le seuil. Le quadri-latre vert correspond limage des coins de limage de rfrence par lhomographie estime. Onnotera que malgr le seuillage des appariements, il y a un grand nombre doutliers.

Ce test tait naf dans le sens o il ne mesurait pas vraiment la robustesse intrinsque des pointsdintrt et des descripteurs mais plutt leur performance au sein dun algorithme de reconnaissanceprmatur. Pour faire bien, il aurait fallu dune part mesurer la rptabilit des dtecteurs sur desimages dont on connaissait linclination, la rotation, le changement de luminosit (en ne faisantvarier quun seul paramtre la fois) et projeter les points dintrt trouvs de limage de rfrencesur limage modie (via lhomographie suppose connue) puis valuer la dirence entre les pointsprovenant de cette projection avec ceux de limage modie.

Et dautre part raliser un test similaire pour les descripteurs o lon aurait compar la distanceentre des descripteurs situs sur des points quelconques de limage de rfrence avec leur projectionsitus sur limage modie.

A lissue de cette phase dvaluation, cest le couple de dtecteur/extracteur ORB/ORB qui futretenu. Toutefois conscient de la navet de mon valuation, jai conu mon architecture logiciellede faon pouvoir facilement changer ultrieurement de dtecteur ou dextracteur.

Plus tard, jai eectu des tests an de dterminer divers paramtres intervenant dans le calculdes points dintrt comme

le nombre de points dintrt. Le diminuer permet de diminuer les temps de calcul et les tempsde transfert (des descripteurs des images reconnatre qui sont synchroniss via le rseau),mais engendre des pertes de robustesse. En dessous de 150 points dintrt, la robustesse sedgrade rapidement. Au del de 500 descripteurs les gains en robustesse sont inmes. Unnombre de 200 points dintrt orait un bon compromis ;

lutilisation dun grille an de forcer une rpartition plus homogne des points dintrt, quidonnait certes de meilleurs rsultats dans certains cas o limage requte possdait des zonestrs contrastes localement (les points dintrt taient tous rpartis dans cette zone), maisconduisait une dgradation globale des rsultats ;

le choix entre le calcul des descripteurs sur des images en nuance de gris ou dans un espacede couleurs opposes. trangement, les rsultats ntaient pas meilleurs en espace de couleursopposes et les descripteurs se trouvs alourdis dun facteur 3 ;

la dimension des images dentrainement. Les points dintrt et descripteurs de ORB tantmoins robustes au scaling que ceux de SURF, la dcision fut prise de prendre des imagesde rfrence de taille similaire la taille des images traites sur le tlphone. Ce choix futconrm par les tests. De plus, plus la taille des images de rfrence ainsi que celles utilisespour le calcul est grande, meilleure sera la robustesse, au dtriment du temps de calcul.Les rsolutions 480x360 et 320x288 (qui sont des rsolutions natives de liPhone 4) furent



retenues.

4.5.2 Comparaison des descripteurs

La comparaison et la recherche des descripteurs constitue la seconde tape de la pipeline. Cettepartie tait le deuxime nerf de guerre du projet, aprs les descripteurs. La qualit et la rapiditde la reconnaissance dimage dpend normment de ses performances. Lobjectif de cette phaseest de pouvoir dterminer en un temps assez court (


Fig. 13 : Un cas pathologique o tous les appariements sont corrects, mais lhomographie estimeest trop approximative car ces appariements sont situs sur la mme ligne.

Fig. 14 : Captures dcran du prototype pour iPhone du moteur de reconnaissance lissue dela 5e semaine montrant la robustesse de la reconnaissance malgr les reets. Limage du chat estcorrectement reconnue dans les deux cas.

4.6 Le trackingLobjectif du tracking est de pouvoir suivre une image reconnue et dacher en sur-impression

une autre image.La pipeline de reconnaissance dimages ntait pas assez rapide pour dterminer en temps rel

les coordonnes dune image reconnue. Pour eectuer du suivi dimage, il existe des mthodes moinscoteuses et plus adaptes comme les algorithmes de calcul de ot optique. Pour simplier, un otoptique est un champ de vecteur qui reprsente le dplacement de chaque pixel entre deux imagessuccessives. Il est ainsi possible de dterminer rapidement et approximativement la position duncertain nombre des points dintrt de limage prcdente dans limage courante. Lalgorithmede Lucas-Kanade prsent dans OpenCV permet deectuer cette opration en moins de 100mspour une image de dimensions 320x288. En dterminant lhomographie entre les deux dernires



images on peut en dduire la transformation eectuer sur limage de sur-impression (qui est lamultiplication de toutes les homographies prcdentes).

Au bout dun certain nombre ditrations, la qualit du tracking se dgrade cause des pertesde prcision accumules par les homographies prcdentes et la diminution du nombre de pointsdintrt qui ont pu tre suivis. Le systme passe alors en mode de reconnaissance dimage an decalculer une nouvelle homographie.

Fig. 15 : Captures dcran de lapplication de dmonstration montrant lache du lm Jobs trackeet sur laquelle un bouton play est ach en sur-impression, ainsi que la liste des actions associes la reconnaissance de limage qui sache lorsque lutilisateur touche lache.



4.7 Les optimisationsPlusieurs optimisations on t envisages pour acclrer la latence du moteur de reconnaissance

et du tracking. Cette partie tait une des plus hasardeuse du projet, certaines tentatives nontpu porter leur fruits, ainsi peu de temps a t consacr cette tape en comparaison du tempsncessaire pour tester toutes les voies possibles.

4.7.1 Optimisations CPU4.7.1.1 La famille x86

Le backend, le serveur de reconnaissance et certains mobiles sous Android tournent sur desProcesseurs Intel de la famille x86. Sur ce type de processeur, il est possible dactiver lutilisation desinstructions SSE permettant de bncier dacclrations matrielle sur les calculs faisant intervenirdes vecteurs de nombre ottants. Aucun dveloppement spcique utilisant ces instructions na tralis, cependant les ags de compilations permettant den gnrer ont t activs.

4.7.1.2 La famille ARMLa famille ARM volue rapidement ce jour. On trouve de plus en plus de processeurs multi-

coeurs permettant de parallliser davantage de calculs. Sur les processeurs de la famille ARM ontrouve galement des instructions SIMD permettant deectuer du calcul vectoriel sur ottantsous le nom dinstructions NEON. Ces instructions ont linconvnient de ne pas tre entirementcompatibles avec le standard IEEE-754, contrario des VFP. Les VFP permettent galementdeectuer des calculs sur des vecteurs de ottant mais sans aucune paralllisation sur le traitementdes lments des vecteurs, rduisant leur intrt.

Aucun dveloppement na t eectu avec des instructions NEON. Des extraits de code enassembleur NEON ont toutefois t utilis pour la conversion des images en nuance de gris. gale-ment, quelques fonctions de conversion dimage utilisant le framework Accelerate qui appelle trscertainement des fonctions intrinsques NEON ou du DSP.

Ct OpenCV, peu doptimisations NEON ont t raliss. Les dveloppeurs ont prfr favori-ser les optimisations rserves aux puces nVidia Tegra3 par le biais dun sdk conu par nVidia. Ontrouve toutefois des essais rcents doptimisation NEON sur la branche de dev dOpenCV ralissur des oprations matricielles et quelques oprations basiques de traitement dimage, mais lesgains de performance sur les fonctions optimises est parfois nul. Ceci est probablement d au faitque ces instructions utilisent des registres spars, et que certaines fonctions optimises doiventeectuer un trop grand nombre de transfert de donnes entre ces registres.

4.7.2 Optimisations mmoireLa premire version du moteur de reconnaissance dimages ne pouvait pas charger une base de

plus de 2000 images. Au del, le processus ncessitait plus des 1Go disponibles et se faisait tuerpar le systme. Il a fallu adapter certains algorithmes et ajuster leurs paramtres pour aboutir une application pouvant charger plus de 4000 images sur 512Mo.

Au del des algorithmes, loptimisation de la mmoire repose selon les langages sur des rglesde programmation strictes.

En Java, on pense tre protg par le ramasse-miette, mais ce dernier ne peut pas faire demiracles, surtout dans le cas de rfrences cycliques. Il convient dutiliser des rfrences faiblespour aider le ramasse-miette. Pour les parties en C++ il a fallu oublier les mauvaises habitudes duJava et tre plus rigoureux. Lutilisation dinspecteurs de code et de prolers tel que Instrumentset Intel VTune Amplier se sont rvls dune aide trs prcieuse.

4.7.3 Les optimisations GPU4.7.3.1 OpenCL

OpenCL permet de mixer du code GPU et CPU. Cest un projet initi par Apple et reprispar le groupe Khronos. Il semblerait avoir t utilis dans certaines bibliothques dApple telle



que CoreImage, mais les dveloppeurs nont pas accs au framework. Il est nanmoins possibledeectuer du dveloppement OpenCL sur un iPhone jail break. 1

Lutilisation dOpenCL sur Android est possible sur quelques rares terminaux. Le trs faiblenombre de puces (dans le domaine du mobile) compatibles avec les spcications dOpenCL rendcette technologie peu attrayante.

Lutilisation de la bibliothque Aparapi (un projet initi par AMD) autoriserait plus de souplessedans lutilisation dOpenCL en convertissant automatiquement le bytecode Java en code OpenCL,si la puce graphique est compatible. Mais mis part quelques exprimentation il nexiste pasde portage ociel pour Android, sans doute d larrive de RenderScript. Cette technologiedisponible partir dAndroid 4.2, ore la possibilit de raliser des calculs intensifs et paralllisablessur les dirents coeurs du CPU, le GPU ainsi que les DSP. Toutefois le dveloppeur na pas lapossibilit de forcer lutilisation du GPU.

4.7.3.2 CUDACUDA est la technologie dveloppe par nVidia permettant galement dexploiter le GPU. Elle

est trs utilise sur PC, toutefois aucune des puces actuelles nVidia supportent CUDA. Il faudraattendre 2015 avec larrive des puces Logan et Parker pour pouvoir utiliser cette technologie.

4.7.3.3 OpenGL ES 2OpenGL ES 2 est une API destine lachage dlments 3D, mais pas au calcul. La seule

sortie possible est une image, toutefois celle-ci nest pas forcment destine tre ache surlcran. Il est ainsi possible dexploiter les calculs eectus sur le GPU. Deux parties seulementde la pipeline OpenGL ES 2 sont trs personnalisables : la gestion des vertices et des fragmentsvia lutilisation de shaders qui sont des programmes compils et excuts par le GPU. Les vertexshaders sont excuts paralllement pour chaque vertex du maillage, tandis que les fragmentsshaders sont excuts paralllement pour chaque fragment (chaque pixel, approximativement).

Dans le cadre du traitement dimage, ce sont les fragments shaders que jai principalementutilis. La comparaison de ltres simples (Sobel, ou Gaussien, convertion de couleurs, ) avec lesperformances dOpenCV tait trs prometteuse. titre dexemple, un ltre de Sobel tournait 14fps avec OpenGL ES contre 5fps avec OpenCV (sur CPU).

Le tracking tant plutt lent sur liPhone4, jai donc dcid dessayer de r-crire une fonction decalcul de ow optique via la mthode de Lucas-Kanade sur GPU, dautant plus que cet algorithmece paralllise trs bien. Le dveloppement de ces shaders fut lent et trs laborieux, en partie cause de la contrainte de ne pouvoir acher les valeurs de calculs. Jai donc ralis un prototypeen Octave imitant le code des shaders an de vrier tapes par tapes la justesse des imagesgnres. Limplmentation Octave a elle mme t valide par une implmentation indpendantede cet algorithme poste sur MathWorks.

Au bout de 2 semaines de dveloppement, les rsultats furent trs dcevants. Le temps de calculobtenu sur GPU tait de 70ms avec 1 itration et 1 niveau de pyramides gaussiennes, pour 65msavec OpenCV pour 5 itrations et 3 niveaux de pyramides gaussiennes sur une image de taille352x288 comprenant une centaine de points dintrt (cas dtude). Ces performances exception-nelles dOpenCV sont dues au fait que le ot optique nest pas calcul sur toute limage maisseulement sur les pixels possdant des points dintrt. En eet, avec une image comportant 2535points dintrt rpartis uniformment, le calcul du ot optique prend 425ms avec OpenCV. Il estgalement fort possible que les faibles performances de mes shaders taient dues mon inexp-rience. Chaque fabriquant de puces propose des outils de proling et doptimisation des shadersque je nai pas eu le loisir dessayer. Des performances plus prometteuses auraient certainement tobtenues en utilisant des outils plus adapts au dveloppement GLSL.

An de terminer et naliser le framework de reconnaissance dans les temps, cette phase dex-primentation avec les shaders fut avorte. En outre, il nest pas envisageable de saturer le GPU

1Preuve de concept : https://github.com/linusyang/opencl-test-ios



de calcul si un client a besoin dutiliser OpenGL ES pour de lachage 3D.

Fig. 16 : Comparaison entre le ot optique calcul sur une itration par des fragments shaderssur iOS et une version ralise sous Octave. Les couleurs reprsentent les angles dorientation desvecteurs.


Rapport PFE 5 AUTRES TRAVAUX

5 Autres travaux

Durant mon stage, jai eu loccasion de travailler ponctuellement sur divers projets dcrits danscette section.

5.1 UCheck

UCheck est la solution de reconnaissance dimages reposant sur le cloud. Bien que dploye de-puis un certain temps, la solution avait besoin dtre maintenue. En particulier, des changementsimportants ont t eectus concernant la communication avec le serveur, les actions de reconnais-sance que jai eu la charge de reporter sur lapplication Android. Je me suis galement occupde la rdaction de la documentation de lAPI, dun protocole de tests, de la validation de ces testset du redploiement de lapplication sur Google Play.

Jai travaill plus tard sur le backend, et en particulier la ralisation de tests de monte encharge des serveurs de reconnaissance.

Fig. 17 : Lapplication uCheck disponible sur Google Play.

5.2 Ralit augmente urbaine

Durant ma visite des laboratoires de recherche de lUniversit Polytechnique de Montral ,jai fait une parenthse sur le projet de reconnaissance dimages et de tracking pour aborder unsujet plus ambitieux : la ralit augmente urbaine. Toutefois, lissue dune phase de recherche etdexprimentations, il fut dcid dinterrompre le projet car la solution de tracking actuelle ntaitpas assez performante sur liPhone 4 pour raliser un prototype satisfaisant, et les autres pistesenvisages tait trop ambitieuses pour le temps restant.


Rapport PFE 5 AUTRES TRAVAUX

Fig. 18 : Version prliminaire dun prototype de ralit augmente urbaine. Cette applicationservait tester la compensation de lorientation donne par le magntomtre avec linclinaisonde lappareil, ainsi qu acher des tiquettes (ici St Aubin) synchronises avec les direntscapteurs, pendant que du suivi de points dintrt aliment chaque frame par de nouveaux pointsdintrt est eectu.


Rapport PFE 6 CONCLUSION

6 ConclusionDurant ce projet de n dtude jai eu le plaisir et la satisfaction de mener bien un projet

de R&D innovant. Les rsultats obtenus sont trs convainquants et dpassent les objectifs initiauxconcernant le nombre dimages pouvant tre reconnues sur le tlphone (jusqu 4900 et en moinsdune seconde). Comme dans tout projet, il demeure nanmoins des amliorations concernant lesperformances du systme, en particulier pour le tracking. Dautre problmes nont pas t adressspar choix, comme la gestion du ou, la dtection et le tracking simultan de plusieurs images et larecherche partielle visant tre plus robuste dans la discrimination dimages contenant par exemplele mme logo.

Fig. 19 : Impact du ou sur le calcul des appariements et lestimation de lhomographie. Les pointsdintrt sont dessins en bleu, les appariements reprsents par des lignes, et le quadrilatre vertreprsente limage des coins de limage de rfrence par lhomographie estime.

Avant de commencer mon stage, je ntais pas familier de lunivers Mac et navais jamais ralisdapplications mobiles. Ces six mois en entreprise mont permis denrichir considrablement mescomptences techniques via lapprentissage de nouveaux frameworks et API tel que : Android, Co-coa, GWT, OpenCV, OpenGL ES, QT, et lacquisition de nouveaux savoir-faires : obfuscation,reverse-enginering, Sur le plan scientique, jai pris conscience de limmensit de lunivers de lareconnaissance dimages ainsi que celui de la ralit augmente. Jai dcouvert lexistence de nom-breux algorithmes en traitement dimage, des structures de donnes complexes, me permettantde rsoudre certaines des problmatiques de mon sujet.

Si la ralit augmente sur mobile en est encore ses balbutiements, lavance constante destechnologies permet aujourdhui de concevoir des algorithmes de vision et de traitement dimagestoujours plus complexes et performants et de concevoir un avenir o les tlphones seront capablesde dtecter et suivre de faon robuste plusieurs objets simultanment, sans monopoliser lensembledes ressources disponibles.

Larrive dans les annes venir dOpenVX 2 (le pendant dOpenGL pour la vision sur cal-culateur) devrait permettre de contribuer prodigieusement lessor des algorithmes de traitementdimages et de jouir dun plus grand nombre dacclrations matrielles.

2http://www.khronos.org/openvx


Rapport PFE RFRENCES

7 BibliographieRfrences[AMN98] Arya S., Mount D. M., Netanyahu N. S., Silverman R., Wu A. Y. : An

optimal algorithm for approximate nearest neighbor searching xed dimensions. J.ACM. Vol. 45, Num. 6 (novembre 1998), 891923.

[AY11] Ambai M., Yoshida Y. : Card : Compact and real-time descriptors. In ComputerVision (ICCV), 2011 IEEE International Conference on (2011), pp. 97104.

[BETVG08] Bay H., Ess A., Tuytelaars T., Van Gool L. : Speeded-up robust features(surf). Comput. Vis. Image Underst.. Vol. 110, Num. 3 (juin 2008), 346359.

[BFG06] Bay H., Fasel B., Gool L. V. : Gool. interactive museum guide : Fast and robustrecognition of museum objects. In In Proc. Int. Workshop on Mobile Vision (2006).

[Bra00] Bradski G. :. Dr. Dobbs Journal of Software Tools (2000).[CDF04] Csurka G., Dance C. R., Fan L., Willamowski J., Bray C. : Visual categori-

zation with bags of keypoints. In In Workshop on Statistical Learning in ComputerVision, ECCV (2004), pp. 122.

[cit05] :. Matching with PROSAC - progressive sample consensus (2005), vol. 1.[CXG07] Chen W.-C., Xiong Y., Gao J., Gelfand N., Grzeszczuk R. : Ecient extrac-

tion of robust image features on mobile devices. In Proceedings of the 2007 6th IEEEand ACM International Symposium on Mixed and Augmented Reality (Washington,DC, USA, 2007), ISMAR 07, IEEE Computer Society, pp. 12.

[FSP06] Fritz G., Seifert C., Paletta L. : A mobile vision system for urban detectionwith informative local descriptors. In Proceedings of the Fourth IEEE InternationalConference on Computer Vision Systems (Washington, DC, USA, 2006), ICVS 06,IEEE Computer Society, pp. 30.

[HL05] Hare J. S., Lewis P. H. : Content-based image retrieval using a mobile device asa novel interface. 6475.

[IM98] Indyk P., Motwani R. : Approximate nearest neighbors : towards removing thecurse of dimensionality. In Proceedings of the thirtieth annual ACM symposium onTheory of computing (New York, NY, USA, 1998), STOC 98, ACM, pp. 604613.

[LJW07] Lv Q., Josephson W., Wang Z., Charikar M., Li K. : Multi-probe lsh : ecientindexing for high-dimensional similarity search. In Proceedings of the 33rd interna-tional conference on Very large data bases (2007), VLDB 07, VLDB Endowment,pp. 950961.

[Low03] Lowe D. G. : Distinctive image features from scale-invariant keypoints, 2003.[ML09] Muja M., Lowe D. G. : Fast approximate nearest neighbors with automatic al-

gorithm conguration. In In VISAPP International Conference on Computer VisionTheory and Applications (2009), pp. 331340.

[NS06] Nister D., Stewenius H. : Scalable recognition with a vocabulary tree. In Pro-ceedings of the 2006 IEEE Computer Society Conference on Computer Vision andPattern Recognition - Volume 2 (Washington, DC, USA, 2006), CVPR 06, IEEEComputer Society, pp. 21612168.

[RRKB11] Rublee E., Rabaud V., Konolige K., Bradski G. R. : Orb : An ecientalternative to sift or surf. In ICCV (2011), Metaxas D. N., Quan L., Sanfeliu A.,Gool L. J. V., (Eds.), IEEE, pp. 25642571.


Rapport PFE RFRENCES

[TCG08] Takacs G., Chandrasekhar V., Gelfand N., Xiong Y., Chen W.-C., Bism-pigiannis T., Grzeszczuk R., Pulli K., Girod B. : Outdoors augmented realityon mobile phone using loxel-based visual feature organization. In Proceedings of the1st ACM international conference on Multimedia information retrieval (New York,NY, USA, 2008), MIR 08, ACM, pp. 427434.

[TD09] Taylor S., Drummond T. : Multiple target localisation at over 100 fps. In BritishMachine Vision Conference (September 2009).


Rapport PFE 8 GLOSSAIRE

8 Glossaire8.1 Scientique

Terme DnitionDtecteur Anglicisme qui dsigne un algorithme de calcul de points dintrtsExtracteur Anglicisme qui dsigne un algorithme de calcul de descripteursFLANN (Fast Library for Approximate Nearest Neighbour) Bibliothque de recherche

rapide de voisins approximatifs dans des espaces de grande dimension. En fonc-tion du jeu de donnes, la bibliothque slectionne un algorithme ainsi quedes paramtres. Les structures de donnes utilises peuvent tre en autre desarbres-kd alatoires ou des arbres k-means hirarchiques.

Flot optique champ de vecteur de mouvement apparent entre deux images conscutives.Homographie Transformation 8 degrs de libert pouvant dcrire entre autre toutes les

projections dune camra du modle stnop. Les applications homographiquesne conservent que les droites.

LMEDS (Least MEDian of Sqares) algorithme destimation de paramtres base sur laminimisation dun problme non linaire.

LSH (Local Sensitivity Hash) algorithme de recherche de vecteurs voisins bas surdes tables de hashage construites de faon ce que leur probabilit de collisionsoit leve lorsque les vecteurs sont proches.

ORB (Oriented FAST and Rotated Brief) dtecteur et extracteur bass sur FAST etBRIEF

Point dintrt Point dune image reprsentant souvent un coin qui peut tre dtermin de fa-on robuste, de faon indpendante (jusqu une certaine limite) des variationsde changement dchelle, dillumination, de rotation et dangles de vue.

RANSAC (RANdom SAmple Consensus) Algorithme itratif destimation de paramtresdans un problme sur-contraint contenant des donnes aberrantes.

Transformation ane Transformation qui conserve les droites et les rapports de distances.

8.2 Technique

Terme DnitionABI (Application binary interface) spcie le format des chiers binaire rsultatnt

de la compilation (exemple les chiers .o). Ce format est spcique au systmedexploitation, et larchitecture du processeur.

APK (Application PacKage) est le format de chier des applications sous Android.ARC (Automatic Reference Counting) est un systme de gestion automatique de la

mmoire. A linstar de Java o un ramasse miette tourne en tache de fond dansla JVM pendant lexcution du code, lARC est statique. Cest dire que cest ltape de la compilation que le code source est analys et que des instructionssupplmentaires pour librer la mmoire ou retenir des rfrences sont ajoutes.

ARM (Advanced Risc Machine) dsigne une famille de processeurs instructionsrduite et basse consommation. Les processeurs ARM font gnralement partieintgrante de SoC.

AWS (Amazon Web Services) plateforme de cloud computing dAmazon.Back-oce Application darrire-boutique, orant une interface utilisateur rserv des

administrateurs qui permet de modier du contenu qui sera ach par unautre application qui peut tre un service web, ou une application mobile. Unback-oce est rserv des utilisateurs intermdiaires.

Backend Ensemble des logiciels qui fournissent les donnes au backend. Souvent desserveurs eectuant des calculs et en interaction avec des bases de donnes.

Cocoa Framework OS X et iOS orant un vaste panels de bibliothques permettantdeectuer de la capture vido, de la communication rseau, du traitementdimage sommaire, du parsing, des interfaces graphiques, mais surtout len-semble des types objets de base et arborescents.


Rapport PFE 8 GLOSSAIRE

DSP (Digital Signal Processor) unit de traitement du signal numrique. Lutilisa-tion des instructions du DSP permet par exemple de calculer matriellementdes transformes de Fourrier.

EABI (Embedded Application Binary Interface) ABI sur plateforme embarques.FPU (Floating Point Unit) unit de calcul ottant simple et double prcision.

Front-oce Application destine aux utilisateurs naux.Frontend Interface entre lutilisateur est le backend.GLSL Langage de programmation driv du C permettant dcrire des shaders pour

OpenGL.GWT (Google Web Toolkit) framework Java permettant de gnrer des interfaces

utilisateurs en HTML/AJAX/Javascript.ISP (Image Signal Processor) puce de traitement dimages, prsente souvent sur le

SoC du processeur. LISP est utilise notamment pour lauto-focus, la balancedes blancs, lexposition auto, la compression JPEG

MIPS (Microprocessor without Interlocked Pipeline Stages) architecture de proces-seurs RISC utiliss principalement pour les systmes embarqus.

NEON unit de calcul de type SIMD permettant lacclration de calculs vectoriels.Cest le pendant des instructions SSE sur x86.

OpenCV (Open Source Computer Vision Library) bibliothque C++ (avec des bindingsJava, Python, Matlab, ...) de vision assiste par ordinateur et de traitementdimage incluant des fonctions dapprentissage automatique et deiverses struc-tures de donnes. Cest un projet initi par Intel, actuellement open source. Laplupart des fonctions possdes divers optimisations CPU voire GPU.

ORM (Object Relational Mapping) fournit une traduction des entres dune tabledune base de donnes sous forme dobjets et du schma en classe.

REST/RESTful (Representational state transfer) Cest une architecture logicielle pour des sys-tmes distribus de type client-serveur sans tat avec diverses proprits. Unexemple typique sont certaines API de Google o on peut envoyer une requteHTTP un serveur et on reoit la rponse sous forme dun chier XML ouJSON.

RISC (Reduced Instruction Set Computing) famille de processeurs comportant unjeu dinstructions trs rduit mais optimis. Cest la famille la plus courante ensystme embarqu.

Shader Programme compil et excut sur le GPU permettant de modier nement lecomportement dune pipeline de rendu 3D telle que OpenGL ou DirectX.

SoC (System on Chip) circuit intgr regroupant divers composants tels quun pro-cessur, un GPU, de la RAM, un ISP, un co-processeur, , un DSP, de mmeque les micro-controlleurs.

SIMDVCS (Version Control System) systme de gestion de rvisions permettant une

quipe de dveloppeurs de grer les modications (fusion, historiques, versions,) apportes un projet. Parmi les logiciels de VCS les plus connus on citeraSVN et Git.

VFPU (Vector Floating Point Unit) unit de calculs ottant vectoriel. Les calculs sonttoutefois eectus de faon squentielle sur les lments des vecteurs, rendantles VFPU obsoltes depuis larrive des instructions NEON.


RemerciementsIntroductionPrsentation de TelequidPrsentation du sujetLe contexteLes enjeuxLa reconnaissance d'imagesLe cahier des charges

Organisation du travailPlanningMthodologieOrganisation technique

La reconnaissance d'images sur smartphoneLes solutions concurrentesLes appareils ciblesLa famille iOSLa famille AndroidConclusion de l'tude des caractristiques matrielles

ArchitectureLe back-officeLe back-endLes applications mobiles

tat de l'art sur la reconnaissance d'imagesHistoriqueDiffrentes approchesLes solutions sur plateformes mobiles

Les outilsLes points d'intrt et les descripteursComparaison des descripteursEstimation de l'homographie

L'algorithme de reconnaissance d'images et de trackingLes points d'intrtComparaison des descripteursValidation

Le trackingLes optimisationsOptimisations CPULa famille x86La famille ARM

Optimisations mmoireLes optimisations GPUOpenCLCUDAOpenGL ES 2

Autres travauxUCheckRalit augmente urbaine

ConclusionBibliographieGlossaireScientifiqueTechnique

Rapport Vinsdscent an Glad On

Documents

Transcript of Rapport Vinsdscent an Glad On