Rapport Vinsdscent An Glad On

ENSEEIHT
Telequid
Projet de fin dtudes
Reconnaissance dimages sur smartphones
Vincent Angladon
IMA 2013
Tutrice ENSEEIHT :
Mme Graldine Morin
Tuteur entreprise :
M. Benjamin Ahsan
Mars - septembre 2013
Rapport PFE
TABLE DES MATIRES
Table des matires
Remerciements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1
Prsentation de Telequid
2.2
Prsentation du sujet
2.2.1
Le contexte
2.2.2
Les enjeux
2.2.3
La reconnaissance dimages
2.2.4
Le cahier des charges
Organisation du travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1
Planning
10
3.2
Mthodologie
10
3.3
Organisation technique
10
La reconnaissance dimages sur smartphone . . . . . . . . . . . . . . . . . . . . 13
4.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
3/ 39
Rvision 0.6
Rapport PFE
4.4.2
TABLE DES MATIRES
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
Autres travaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1
UCheck
33
5.2
Ralit augmente urbaine
33
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Glossaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.1
Scientique
38
8.2
Technique
38
Vincent Angladon
Rvision 0.6
4/ 39
Rapport PFE
REMERCIEMENTS
1 Remerciements
Je 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 de
lentreprise, ainsi que lapprentissage et le perfectionnement de mes connaissances en ObjectiveC
et GWT entre autre, technologies que jignorais avant le dbut de mon stage.
Je remercie galement toute lquipe LIGUM du laboratoire DIRO de luniversit Polytechnique
de Montral et plus particulirement Pierre Poulin qui ma accueilli et encadr durant mon sjour
au 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 sa
conance, 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 runions
ponctuelles sest occupe de veiller au bon droulement du stage, lamlioration de mon rapport
et de ma soutenance et ma permis de rejoindre lquipe LIGUM avec laide de Vincent Charvillat.
Vincent Angladon
Rvision 0.6
5/ 39
Rapport PFE
INTRODUCTION
2 Introduction
2.1 Prsentation de Telequid
Telequid est une socit de R&D spcialise dans les technologies transmedia qui peuvent tre
utilises dans des applications de tlvision sociale, reconnaissance visuelle et la publicit interactive. Lquipe technique est constitue de deux ingnieurs Enseeihtiens promo 2010 : Benjamin
Ahsan et Julien Andre. Frdric Bruel, fondateur et directeur gnral de la socit est galement
un 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 Store
dApple ;
uSnap dcline en versions iOS et Android est une application lance en partenariat avec
la socit JC Decaux. Cette application permet de reconnatre un certain nombre daches
publicitaires dployes par JC Decaux et dy associer un contenu multimdia. Usnap repose
sur 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 dernire
gnration du moteur de reconnaissance dimages de Telequid. la dirence de uSnap, le
mode de capture est continu, cest--dire quil nest pas ncessaire dappuyer sur un bouton
pour prendre une photo qui sera analyse. Lapplication permet galement de reconnatre des
vidos ;
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 systme
de recommandation de programmes, des infos sur les lms, les acteurs, un moteur de recherche
pour retrouver un acteur ou un programme, des rappels Push, et permet de tweeter sur les
missions en temps rel ;
iTag est une application second cran pour iPad permettant de consulter un programme
tlvis enrichi. Lapplication reprend les fonctionnalits dAlloTV et dispose galement de
fonctionnalits pour partager le programme en cours, recevoir des recommandations de programme TV bases sur ses gots, de reconnaitre la chane en cours ; iTag est en cours dexprimentation 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 ;
Vincent Angladon
Rvision 0.6
6/ 39
Rapport PFE
2 INTRODUCTION
iZapTV permettant de partager les 30 dernires secondes de TV live regardes sur Twitter
et Facebook ;
iSyncTV qui est un service de reconnaissance de publicits tlvises proposant de la publicit
interactive.
2.2 Prsentation du sujet
2.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 des
muses, des couvertures de livres, des pochettes de CD ou de DVD, des publicits...1 . De nombreux
magasins comme Kiabi, But, IKEA, Leroy Merlin2 enrichissent dj leur catalogues avec du contenu
destin aux smartphones accessible par reconnaissance dimages.
2.2.2
Les enjeux
Telequid proposait dans son catalogue actuel un certain nombre de solutions de reconnaissance
dimages destines des annonceurs souhaitant lier par exemple des aches publicitaires un
contenu 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 limage
Lapplication 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 campagnes
dannonces 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 application
mobile est donc spcique une base de donnes et peut reconnatre les images de chacun des
annonceurs partageant la mme base de donnes.
Ces solutions reposaient toutes sur la mme architecture :
1 https
2 http
://www.recognize.im/site/showcaseApps
://www.moodstocks.com/gallery/
Vincent Angladon
Rvision 0.6
7/ 39
Rapport PFE
INTRODUCTION
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 lancement
dune vido
Lobjectif de mon stage tait de trouver des solutions, permettant de reporter le plus de calculs
possibles sur un iPhone. Autrement dit, dvaluer les solutions permettant de faire de la reconnaissance dimages sur un iPhone, sans communiquer avec un serveur central, lexception dune
phase dinitialisation o une synchronisation des images reconnatre et des actions associes aux
reconnaissances sont eectues. Bien que de trs rares concurrents proposaient dj des solutions
de reconnaissance dimages en local, il ntait pas certain que les technologies utilises sur les serveurs de Telequid pour uCheck puissent tre portes sur mobile, faisant de ce sujet un projet de
recherche et dveloppement.
Lavantage de reporter les calculs sur le tlphone est de pouvoir eectuer de la reconnaissance
dimages sans accs Internet et de rduire les cots de fonctionnement par la suppression du serveur
central. On limine galement la crainte de saturer la charge dun serveur, dit autrement, les
tlphones nont plus besoin dtre brids sur le nombre dimages traiter par seconde. Nous
verrons par la suite comment ces spcications ont volu au fur et mesure du droulement de
mon 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 la
mme classe ;
la recherche dimages par le contenu (content-based image retrieval) qui a pour nalit de
retrouver 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 algorithme
de dtection des visages et des plaques dimmatriculations sur sa plateforme Google Street
View. Il ne sagit pas de reconnaissance puisque le but nest pas dauthentier les dirents
visages dtects. Les algorithmes de dtection sont pour la plupart bass sur du machine
learning. On citera notamment la mthode de Viola et Jones (cascade of features) ;
la catgorisation ou classication qui consiste attribuer une classe ou une tiquette une
image donne. Par exemple, elle indiquera si une image donne est plutt de type plage
ou montagne La catgorisation retourne systmatiquement un rsultat (une classe) pour
toute image avec une complexit temporelle souvent infrieure aux algorithmes de dtection.
Certes, on pourrait placer chaque ache dans une catgorie distincte, et utiliser un algorithme
de catgorisation mais cela ne serait pas judicieux dans notre cas tant donn que le cahier
des charges impose un taux derreur trs faible.
Quelle que soit la mthode, on peut remarquer la prsence dun foss smantique, cest--dire que
la reprsentation utilise par lordinateur (descripteurs locaux par exemple) pour la reconnaissance
na 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 dun
rectangle 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 visuellement
des photos pouvant tre des aches publicitaires et de les suivre (tracking) ou dacher du contenu
associ limage reconnue. Les contraintes suivantes devaient tre respectes :
Vincent Angladon
Rvision 0.6
8/ 39
Rapport PFE
2 INTRODUCTION
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 maximal
dimages.
A contrario, le respect des taux dchec tait une contrainte forte qui a dtermin certains de
mes choix.
Vincent Angladon
Rvision 0.6
9/ 39
Rapport PFE
ORGANISATION DU TRAVAIL
3 Organisation du travail
3.1 Planning
Un premier planning prvisionnel avait t bauch par mon encadrant, laissant deux semaines
au 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 mois
suivants devaient tre consacrs au dveloppement et lvaluation dalgorithmes de calcul de points
dintrt 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 des
images reconnatre. Les mois restants devaient tre consacrs aux autres parties de la pipeline de
reconnaissance ainsi qu la ralisation ventuelle dun back-oce.
Voici un rsum des direntes tapes eectives du stage (jusqu la rdaction du rapport) :
Semaines
16
78
9 10
11 13
14 15
17 21
23
24
25
tape / Jalon
Recherches, conception de prototypes pour iOS et Android
grant la reconnaissance et le tracking.
Appui sur divers projets internes.
Optimisation des paramtres de la reconnaissance jouant sur la performance.
Cration dun SDK, design et conception dun moteur de reconnaissance
modulaire. Rexion sur larchitecture globale du systme, dbut de
conception du serveur calculant les points dintrt des images reconnatre
et du back-oce
Amliorations, modications et tests de uCheck pour iOS et Android.
Fin de conception du back-oce.
Recherches et tests sur la ralit augmente urbaine. Conception dune version
GLSL de lalgorithme de calcul de ot optique avec la mthode de Lucas-Kanade.
Corrections de bugs et tentatives doptimisations du tracking sous iOS
Cration du SDK du produit ni et de lapplication de dmonstration.
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 Mthodologie
En 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 seconde
semaine. 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 point
rapide 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 de
contournement envisageables.
3.3 Organisation technique
An 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 de
bord sous la forme de chiers textes non formats o jinscrivais toutes les tches eectues, les
nouvelles 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 sein
des nombreux projets sur lesquels jai travaill. Loutil Git ma grandement aid pour parcourir le
pass des projet, notamment pour retracer lorigine de bogues, versionner des changements indpendant via lutilisation de branches et fusionner les direntes versions du moteur de reconnaissance
dimages, utilis et adapt par lapplication iOS, lapplication Android et le serveur traitant les
images du back-oce. Lutilisation de cette hygine de dveloppement ma permis davancer sans
Vincent Angladon
Rvision 0.6
10/ 39
Rapport PFE
3 ORGANISATION DU TRAVAIL
.
1
Avril-Septembre 2013
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.
Vincent Angladon
Rvision 0.6
11/ 39
Rapport PFE
ORGANISATION DU TRAVAIL
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 des
changements 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 suivre
visuellement les volutions de mes dpts et avoir des sauvegardes incrmentales de mes projets.
Vincent Angladon
Rvision 0.6
12/ 39
Rapport PFE
4 LA RECONNAISSANCE DIMAGES SUR SMARTPHONE
4 La reconnaissance dimages sur smartphone

4.1 Les solutions concurrentes
Une des premires missions que jai ralise a t la recherche des solutions concurrentes, la
comparaison 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 de
reconnaissance dimages que je rsumerai succinctement. La plupart dentre-elles proposent seulement 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 assez
restreint propose un sdk permettant de faire de la reconnaissance dimages directement sur le
tlphone. On citera IQEngine, Moodstocks et Smartsy.
Durant cette analyse, jai eu loccasion de mettre en pratique mes connaissances en analyse
forensique an de rvler les bibliothques utilises par les solutions concurrentes et leurs choix
technologiques. Jai utilis divers outils pour extraire les applications des tlphones, convertir et
extraire les chiers de lapplication, dcompiler, visualiser les symboles des bibliothques, extraire
les chanes, sparer les architectures cibles Les rsultats de cette analyse ont permis de me conforter dans les choix eectus pour la ralisation du prototype, ainsi que de dcouvrir de nouvelles
bibliothques.
4.2 Les appareils cibles
Ltude 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 programmation, les frameworks, les options de compilation,
4.2.1
La famille iOS
La 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 dautre
part pour des raisons internes. Le march est faiblement segment, mais liPhone5 et les tablettes
possdent des ratio de rsolutions dcran direntes obligeant dvelopper parfois des interfaces
spciques certains modles.
Les iPods taient exclus des appareils cibles ainsi que les modles ne pouvant tre mis jour
vers iOS 5, soit les iPhone 1, 3G et 3GS. Ces derniers ont dailleurs quasiment disparu et sont
compltement dpasss en terme de performances. iOS 5 apportait des fonctionnalits clefs comme
un support complet pour lARC, le module Core Image, GLKit (surcouche OpenGL ES), Enn
tous 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 ma
plateforme de tests. Il est quip dun processeur Cortex-A8 800 MHz, mono-coeur, supportant
les instructions NEON, dune RAM de 512 Mo et dun GPU PowerVR SGX 535 cadenc 200
MHz. Il possde galement lensemble des instruments de mesure ncessaires pour eectuer de la
ralit augmente urbaine sur capteurs, savoir un gyromtre trois axes, un acclromtre, un
magntomtre et un GPS. Sa camra au ratio natif 4 :3 peut prendre des photos en 2592x1936 de
rsolution 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 mme
ABI (Mach-O), le mme framework (Cocoa), le mme outil de dveloppement (XCode). Le langage
de 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 passage
de messages. Il est galement possible dutiliser lObjectiveC++ qui permet dintgrer du code C++
dans du code ObjectiveC. Les applications peuvent ventuellement tre dveloppes en HTML5
et Javascript, mais le code gnr est alors public, et il nest pas possible daccder toutes
les fonctionnalits bas niveau ni de faire du calcul de faon performante. De plus le look and
feel de lapplication sera web et non pas iOS. Nanmoins ce choix est trs populaire au sein
de la communaut des dveloppeurs dapplications mobiles. Enn, les quipes de Mono (qui ont
Vincent Angladon
Rvision 0.6
13/ 39
Rapport PFE
LA RECONNAISSANCE DIMAGES SUR SMARTPHONE
dvelopp une machine virtuelle .NET multi-plateforme ainsi quun compilateur C#) ont lanc
Xamarin, 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 ont
le mme look and feel que des applications natives et permet daccder aux classes Java (pour
Android) ainsi quaux API natives (telle que UIKit). Cependant, les prix des licences annuelles
sont trois plus levs que pour une licence Apple, et il y a moins de support.
4.2.2
La famille Android
La famille Android est trs segmente en terme de performances, darchitectures, rsolutions

dcrans et de versions du systme dexploitation, rendant les essais sur cette plateforme secondaires. Les processeurs des appareils sous Android peuvent tre des ARM, des x86 dINTEL, voire
des MIPS. Lappareil utilis pour la majorit des tests tait un Nexus 4, choisi pour sa prise en
charge dAndroid 4.3 et qui ct performance se place dans la moyenne des tlphone rcent sous
Android haut de gamme.
En comparaison avec liPhone 4, son processeur Qualcomm APQ8064 quadri-coeurs fait de lui
une Formule 1.
Un HTC Wildre sous Android 2.2 a galement t utilis pour vrier que les modications
que javais apport lapplication uCheck passaient bien sur les anciens modles ainsi que pour des
tests de performance. Son processeur armv6 Qualcomm MSM7225 mono-coeur faisait ple gure
face celui liPhone 4.
Le dveloppement dapplications se fait en Java SE via lutilisation du SDK Android qui ore
approximativement 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 ou
en C#
4.2.3
Conclusion de ltude des caractristiques matrielles
Ltude 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 compilation gnrant des optimisations NEON, la prfrence vers des bibliothques exploitant ces
optimisations telles quOpenCV ou Eigen ;
lemploi du multi-threading et de bibliothques lutilisant an de proter pleinement des CPU
multi-coeur des iPhone4S/5 et des processeurs rcents des mobiles sous Android ;
la faisabilit dune application de ralit augmente urbaine.
4.3 Architecture
Larchitecture 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 reconnatre et les actions associes la reconnaissance.
1 Bien 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 les
applications installes par les clients de notre client.
Vincent Angladon
Rvision 0.6
14/ 39
Rapport PFE
Un bucket du service S3 dAWS (Amazon Web Service) an de garantir de la haute disponibilit sur les images, les vidos et les descripteurs des images.
Fig. 5 : Architecture nale du projet. Les ches noires reprsentent les interactions dun utilisateur
avec un composant. Les ches vertes correspondent aux transactions eectues lors de lajout dune
image 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 plusieurs
itrations. Jai ralis lensemble des composants de cette architecture, lexception du back-oce
o 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 base
de donnes (che 1) et une notication est envoye au serveur de traitement des images (serveur
2 via la che 3). Ce serveur rcupre limage sur le bucket (che 5), calcule ses points dintrt et
ses descripteurs, et vrie quune image similaire nest pas dj prsente. Si cette dernire condition
est vrie, les points dintrts sont renvoys au bucket (che 5) et une notication de succs est
envoye au front-end (che 6).
Lorsquune image est retire, limage est drfrence du serveur 2 (che 3), de la base de
donnes (che 1), et supprime du bucket s3 (che 2).
Lors du lancement de lapplication mobile, ce dernier va synchroniser sa liste des descripteurs
des 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 PostgreSQL. Le schma est conu de telle sorte que plusieurs clients soient rattachs la mme base de
Vincent Angladon
Rvision 0.6
15/ 39
Rapport PFE
donnes an quils puissent utiliser la mme application pour reconnatre leurs images. Un client
peut crer plusieurs campagnes, lesquelles peuvent contenir plusieurs contenus (images ou vidos
reconnatre). Chaque contenu peut tre associ plusieurs urls qui sont des objets dnissant un
lien, un texte et un tag.
La gestion de la base de donnes est faite la main sans laide de bibliothque dORM. Ce
schma impose lutilisation de 4 jointures pour la rcupration de lensemble des images (avec leurs
urls associes) provenant dune base de donnes donne.
Fig. 6 : Schma des relations entre les tables utilises par le back-oce. Les cases en vert clair
correspondent aux clefs primaires. Schma ralis avec schmaSpy
Vincent Angladon
Rvision 0.6
16/ 39
Rapport PFE
Fig. 7 : Capture dcran de la page de modication des images et des actions associes aux reconnaissances de ces images.
Le back-oce met disposition des mobiles les actions associes chaque image sous forme
dun chier JSON. Lensemble des descripteurs est mis jour entre le mobile et le serveur via le
back-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-end
Bien 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 les
modles aprs avoir fait des vrications sur les entres de lutilisateur et lavertir en cas derreur. Il
fallait un autre service, plus apte faire des calculs intensifs et pouvant tre dtach du back-oce
pour des raisons de cloisonnement applicatif. En eet, lorsquune image est uploade par lutilisateur, il faut vrier quil nexiste pas dj une image similaire en base, puis si cette condition est
remplie, calculer les points dintrt et les descripteurs qui seront envoys aux tlphones et utiliss
pour les comparaisons avec les images suivantes. Nous appellerons calculateur-comparateur ce
service.
Le moteur de reconnaissance sur les tlphones tant dj crit en C++, il fut dcid dcrire
un service en C++ galement qui communique avec le back-oce via des sockets et des requtes
HTML. Pour simplier le dveloppement de ce service nous avons utilis la bibliothque QT5 an
de grer la partie socket TCP et des threads de faon plus portable. Le dploiement a t test sur
des serveurs Tomcat7.
Lorsquun usager a upload un contenu sur le back-oce qui la envoy au bucket s3, une trame
TCP contenant lidentiant et des informations relatives ce contenu est envoye au calculateurcomparateur. Pour empcher que deux images identiques envoyes simultanment soient insres
en base, une seule comparaison de limage est eectue la fois. An dviter davoir maintenir
un verrou durant tout le processus de reconnaissance, le calculateur-comparateur naccepte quune
seule 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, puis
leurs points dintrt et descripteurs sont calculs. Cette tape est ncessaire car les tlphones
ne comparent pas les images directement mais les descripteurs de ces images (qui ont le bon got
dtre plus lgers que les images) comme nous le dtaillerons par la suite. Ces derniers sont uploads
Vincent Angladon
Rvision 0.6
17/ 39
Rapport PFE
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 appelant
une de ses servlets.
Chaque base de donnes est associe un ou plusieurs serveurs calculateur-comparateur. En aucun cas un serveur ne gre plusieurs base de donnes. Dune part pour des raisons de cloisonnement
et dautre part parce quil y a un verrou sur ltape danalyse/comparaison de limage situe en
aval de la rception de la notication qui empcherait de traiter simultanment deux notications
correspondant 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 le
plus de calculs, malgr les faible performances de ces plateformes. Comme expliqu prcdemment
le moteur de reconnaissance est crit en C++ et est commun aux deux OS retenus, ainsi quau
calculateur-comparateur. Seule la gestion de la camra et la synchronisation des descripteurs des
images reconnatre est dveloppe dans le langage natif de la plateforme considre. Le fonctionnement 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, pour
la version Android seulement une application de dmonstration.
Les applications synchronisent les descripteurs des images reconnatre avec le back-oce en
deux tapes. Dans un premier temps le tlphone envoie une requte POST contenant la liste des
identiants des descripteurs prsents en local sur le tlphone. Le back-oce calcule lintersection de
cette liste avec la liste courante des descripteurs, et renvoie au format JSON deux listes contenant
respectivement les identiants des descripteurs tlcharger et de ceux supprimer. Dans un
second temps, le tlphone tlcharge et supprime les chiers correspondant et peut enn gnrer
sa structure de recherche des descripteurs.
Fig. 8 : Graphique de ot de contrle de lAPI dcrivant les changements de modes entre la

reconnaissance dimage et le suivi de limage reconnue.
Vincent Angladon
Rvision 0.6
18/ 39
Rapport PFE
Fig. 9 : Graphique de ot de contrle de lapplication de dmonstration.

4.4 tat de lart sur la reconnaissance dimages
4.4.1
Historique
4.4.1.1 Direntes approches
David 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-kd
appele best-bin-rst ;
calcul de la transforme de Hough pour clustriser les descripteurs ayant le mme scaling
et orientation (orientation et scaling normaliss avec les valeur du descripteur auquel il est
appari) ;
estimation de la transformation ane.
Bien que les descripteurs (reprsents par un vecteur de 128 ottants) permettent de discriminer de faon ecace les points dintrt, un grand nombre de points dintrt de larrire-plan
peuvent tre apparis incorrectement et donner lieu des faux-positifs lors de ltape de dtection. Lowe prconise ainsi de vrier la cohrence gomtrique (spatiale) des appariements en les
regroupant en clusters par le biais dune transforme gnralise de Hough implmente via une
table de hachage. la sortie de cette clustrisation il obtient des clusters correspondants des
Vincent Angladon
Rvision 0.6
19/ 39
Rapport PFE
descripteurs appartenant potentiellement la mme image de rfrence. Selon David Lowe, appliquer RANSAC ou une mthode des moindres carrs cette tape pour obtenir directement la
transformation (entre limage de rfrence, et la photographie contenant limage dtecte) serait
inecace car il reste encore cette tape plus de 50 % de points aberrants (outliers). Enn les
plus gros clusters sont soumis une tape de validation au cours de laquelle la transformation
ane entre les points apparis est calcule par la mthode des moindres carrs. David Lowe choisit
destimer une transforme ane car ses descripteurs ne sont invariant qu ces transformations et
pour 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 appariements 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 pouvait
y avoir trois descripteurs qui avaient une distance extrmement faible avec ceux de limage de
rfrence, les autres descripteurs correctement apparis ayant une distance faible ou moyenne avec
ceux de limage de rfrence. Dans cette situation, une valeur de k faible empchait la slection de
plus de ces trois appariements. A contrario, avec dautres images, en particulier celles prsentant
une zone de ou, la deuxime meilleure distance sera trs leve, et le trop grand nombre dappariements 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 la
valeur minimale de la distribution des distances entre les descripteurs. Nous avons ainsi opt pour
un seuil global, qui donnent de meilleurs rsultats en pratique et pnalisant volontairement les
images 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 limage
photographie, du descripteur le plus proche parmi ceux des images de rfrence. En fonction du
nombre 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 dappariements sont faux. Il arrive frquemment que certains descripteurs dune image soient proches
de descripteurs dune autre image dentranement. Lide serait de pouvoir dterminer quels descripteurs sont les plus pertinents, et les considrer en priorit.
Gabriella Csurka propose dans son article [CDF 04] de rduire le problme de catgorisation
en un problme dapprentissage supervis multi-classes o une classe correspond une catgorie
visuelle. Cette mthode intitule Bag of Keypoints consiste rduire une image en une liste de
rgions (features) qui sont caractrises sparment et values avec un histogramme dapparence
dans les autres images, de la mme faon que la pertinence dun mot est value en fonction de
son nombre doccurrences dans un jeu de documents. Les direntes tapes de lentranement de
lalgorithme 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. En
reprenant lanalogie avec les mots, cette tape de clustrisation va permettre de considrer
les mots tel que gomtrie, gomtries et gomtriquement correspondent un mme
mot.
Chaque image est ainsi reprsente par un vecteur dont les composantes correspondent aux
frquences dapparition de chacun de ces mots. Les composantes des vecteurs sont ensuite
r-ajustes avec des poids qui varient en fonction de la frquence dun mot dans lensemble
de la base. On cre ensuite un annuaire invers dans lequel chaque mot va pointer vers les
images dans lequel il apparat avec son occurrence.
Un classicateur de type Bayes ou SVM (Support Vector Machine) va permettre de dterminer quels vocabulaires et paramtres du classicateur donnent les meilleurs rsultats de
catgorisation.
Pour dterminer la photographie la plus proche dune image requte, on calcule le vecteur de
frquence des mots de limage requte que lon compare avec les vecteurs des images dentranement.
Vincent Angladon
Rvision 0.6
20/ 39
Rapport PFE
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 plus
lev.
Une des limitation de lapproche bag of keypoints est que la clusterisation et lapprentissage
supervis pour la cration du vocabulaire sont coteux si le nombre dimages est important. De
plus 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 de
caractristiques (features) qui est progressivement subdivis chaque hauteur, via lalgorithme
K-means, en arbre de clusters plus petits.
4.4.1.2 Les solutions sur plateformes mobiles
En 2005, Gerald Fritz et al. [FSP06] est lun des premiers proposer une solution de reconnaissance sur mobile. A lpoque, la technologie ne permet pas deectuer les traitements en
local. Son application externalise ainsi les calculs sur un serveur qui reconnat par classication de
descripteurs i-sift, le btiment dune photographie.
La mme anne, Jonathon S. Hare et Paul H. Lewis proposaient une application mobile de
reconnaissance duvres darts [HL05] o la phase de reconnaissance tait galement eectue
sur un serveur. Ltape de reconnaissance sappuie sur une approche bag of keypoints utilisant
les 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 Herbert
Bay et al. [BFG06] mais cette fois-ci les calculs sont eectus en local sur une tablette quipe
dun processeur Pentium M cadenc 1.7 GHz. De mme que dans la mthode de David Lowe, les
descripteurs de SIFT sont apparis en utilisant un seuil relatif, mais au lieu dutiliser lalgorithme
best bin rst pour comparer les descripteurs, il eectue une recherche linaire. Herbert Bay et al
montre quil possible datteindre des taux de reconnaissance quivalents en utilisant les descripteurs
SURF, avec un gain de rapidit de lordre de trois. Sur un corpus de 205 images de dimensions
320x240, il arrive identier les uvres dart en une minute minimum et avec un taux de succs
suprieur 84.5 %.
Gabriel Takacs et al. [TCG 08] ont travaill sur laugmentation des btiments dune ville,
o la reconnaissance des photos est eectue en local sur des tlphones portables de type Nokia
N93, N95 et N5700 aux performances nettement infrieures celle dun iPhone 4. Lapplication
nest pas sans rappeler celle de la RATP qui permet dacher en ralit augmente les stations
de mtros et les lieux dintrt. En raison des performances de ces tlphones, la base de donnes
des descripteurs est tlcharge en fonction de la position de lutilisateur. De plus ils utilisent
les donnes du GPS embarqu pour restreindre la recherche certaines cellules dune carte qui
appellent loxels, voisines de la position de lutilisateur. Utilisant en entre un grand nombre de
photos ayant des zones communes, ils slectionnent les descripteurs qui apparaissent sur plusieurs
images, permettant de rduire considrablement la base des descripteurs, calculs partir dune
implmentation maison de SURF. Ensuite ANN [AMN 98] est employe pour les recherches dans
la 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 plus
complique estimer et ncessite davantage dappariements corrects (inliers), alors quun modle
ane donnerait des rsultats quivalents. Ce choix doit sexpliquer galement par le fait quen
prenant des photos peu prs en face dun btiment, on conserve approximativement le caractre
parallle des lignes des faades faisant face lobservateur.
Avec des images de taille moyenne 640x480, 250 points dintrt par image, 7000 descripteurs
dans la base, ils obtiennent une temps de reconnaissance de 2.8s, dont 2.4s pour SURF et une
consommation mmoire de 1.8Mo pour la base des descripteurs. Larbre de recherche des descripteurs 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
Vincent Angladon
Rvision 0.6
21/ 39
Rapport PFE
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 prend
1s et ncessite 19Mo, tandis que la recherche dans la base des descripteurs seectue en 70ms avec
LSH.
4.4.2
4.4.2.1
Les outils
Les points dintrt et les descripteurs
Une 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 au
voisinage dun point. Dune part, il sagit dune tape trs coteuse en calcul et dautre part, la
qualit des points dintrt dtermineront la robustesse de la reconnaissance.
Mais tout dabord, pourquoi pour eectuer de la reconnaissance dimage, sacharne t-on utiliser des points dintrt coupls des descripteurs dont la reprsentation pour un cerveau humain
est plutt abstraite, alors quune image peut (comme le fait le cerveau humain) tre identie par
son ensemble de formes et de couleurs qui pourraient tre obtenues informatiquement par segmentation ? Tout dabord, les couleurs sont souvent altres par lclairage (couleur, intensit), des reets
Il faut ainsi tre trs tolrants sur les plages de valeurs acceptables pour distinguer des couleurs
dune palette donne. Ensuite, les algorithmes de segmentation sont trs coteux en temps de calcul
et il ny a pas dunicit de la segmentation. Cest trs suggestif de dire quune segmentation s1 est
meilleure quune segmentation s2. Selon les paramtres dnis, certaines rgions se retrouverons
fusionner et il sera trs dlicat de les apparier via des descripteurs de formes aux rgions de limage
de rfrence, dautant plus ces formes auront subies des transformations homographiques. Tandis
que les points dintrt et les descripteurs sont robustes tous ces changements, permettant la
reconnaissance. Enn, une motivation minoritaire consiste dire que les algorithmes de calcul des
points dintrt et des descripteurs miment la faon dont la vision humaine fonctionnerait : par la
recherches de contours ou de variations de gradients direntes chelles.
Un bon algorithme de calcul de points dintrt/descripteurs doit tre rptable, cest--dire que
lon doit retrouver les mmes points dintrt/descripteurs sur des images direntes dune variation
dclairage, dchelle, de rotation ou de changement de perspective. En mme temps les descripteurs
locaux doivent tre assez discriminants an de permettre un meilleur taux dappariement. Ce juste
milieu est tellement dlicat que les eorts pour amliorer linvariance des descripteurs aboutissent
souvent une perte de distinction des descripteurs.
Malgr son anciennet, SIFT [Low03] est souvent prsent comme la rfrence en matire de
robustesse, 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 dimensions
480x356) et la lourdeur de ses descripteurs (128 nombres virgule ottante).
SURF [BETVG08] nous a galement surpris concernant sa robustesse, mais du par ses
performances : 1.1s pour le calcul des points dintrt.
ORB [RRKB11] que nous avons retenu est bas sur une variante de FAST (pour les points
dintrt) et de BRIEF (pour les descripteurs) rendu invariant aux rotations via la mthode de
Rosin. Les descripteurs dORB sont des vecteurs de 32 octets. Le choix de ne pas utiliser de
nombres virgule ottant ( contrario de SIFT et SURF ) plus coteux manipuler, se rvle
particulirement judicieux sur des plateformes mobiles.
Aujourdhui, des algorithmes de calculs de points dintrt et des descripteurs ont t spcialement conus pour tre performants sur des tlphones. On citera notamment Wei-Chao Chen
et al. qui propose une optimisation de SURF [CXG 07] CARD [AY11] de Mitsuru Ambai and
Yuichi Yoshida base sur des gradients orients et lalgorithme de Simon Taylor et Tom Drummond [TD09] bas sur lalgorithme FAST et dont les descripteurs proviennent dun apprentissage
supervis de fentres autour des mmes points dintrt dimages ayant subies des changements de
perspective, dchelle et des ous gaussiens. Malheureusement, le code source de ces algorithmes
nest pas publi et la licence des binaires de CARD interdit toute exploitation commerciale.
Vincent Angladon
Rvision 0.6
22/ 39
Rapport PFE
4.4.2.2 Comparaison des descripteurs
Une 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 raisonnable
deectuer une recherche linaire au-del de 5 images dans la base des descripteurs. Il faut donc une
structure de donnes adapte, orant si possible pour les recherches, une complexit temporelle en
o(log(n)), o n est le nombre de descripteurs dans la base.
S. Arya et al. [AMN 98] explique que si la condition 2d << n (o d est la dimensions des
descripteurs) nest pas vrie, alors les structures de donnes arborescentes classiques sont inecaces. Lorsque d est suprieur 2, il faut sacrier la complexit spatiale pour obtenir une recherche
en temps logarithmique. Do la proposition de chercher un candidat approximatif, cest--dire
proche un epsilon prs du plus proche voisin. Ils proposent une structure de donnes intitule
arbre BBD (balanced box-decomposition) qui permet une recherche linaire avec une complexit
spatiale linaire et un temps de construction quasi-linaire.
La mme anne, Piotr Indyk et Rajeev Motwani proposent LSH (local sensitivity hashing)
[IM98]. Lide de base de LSH est dutiliser des fonctions de hachage qui auront une forte probabilit de collision pour des vecteurs proches. Pour eectuer une recherche, on calcule les empreintes
(hashs) dun vecteur requte en utilisant ces fonctions de hachage. On slectionne ainsi des candidats que lon trie en fonction de leur distance avec le vecteur requte an de slectionner les k
plus proches voisins parmi ces candidats. Toutefois, dans le cas o le nombre de donnes est trs
important, LSH requiert plus dune centaine de tables de hachage pour assurer que des vecteurs
proches auront des empreintes proches.
Qin Lv et al. a propos depuis une variante de LSH intitule Muliprobe LSH [LJW 07] permettant de corriger ce dfaut. Cest limplmentation de LSH qui a t retenue dans la bibliothque
OpenCV.
[ML09]
En 2009, Davig G. Lowe et Marius Muja ont tudi les rsultats de certaines variantes des
kd-tree sur divers jeux de donnes an de proposer un algorithme permettant de slectionner la
meilleure variante de kd-tree avec les meilleurs paramtres partir dun chantillon du jeu de
donnes utiliser et des contraintes de lutilisateur : complexit spatiale, complexit temporelle de
cration de larbre et complexit temporelle des recherches.
Daprs les auteurs, il ny a pas de meilleur algorithme pour un jeu de donnes donn. Selon la
prcision des rsultats escompte, selon les proprits des donnes (forte corrlations entre dimensions, ), les paramtres de chacun des algorithmes (nombre darbres, nombre de ls, ...) ont aussi
leur limportance.
En particulier, si les vecteurs proviennent dune distribution uniforme, les performances seront
comparables une recherche linaire.
OpenCV [Bra00] propose une implmentation de FLANN bas sur cet article, qui semble en
eet utiliser par dfaut les multiple randomized kd-trees comme structure de donnes, car les
rsultats retourns ne sont pas toujours identiques pour un mme vecteur de recherche et une base
de recherche donne.
4.4.2.3 Estimation de lhomographie
Une fois que lon a dtermin limage de rfrence qui intervenait avec le plus grand nombre
dappariements de limage requte, la dtection nest pas termine. An de rduire le nombre
de faux-positifs, on va estimer la position des coins de limage reconnue et vrier que ces coins
dnissent un quadrilatre convexe peu aplati. Pour estimer la position de ces coins, nous avons
choisi de calculer lhomographie entre les points dintrt apparis des deux images.
tant souvent sujet un grand nombre dappariements incorrects (outliers), nous avons utilis
dans un premier temps RANSAC dont les performances laissaient dsirer (jusqu 1.2s pour 200
appariements dans le pire des cas). Lestimation de cette homographie peut tre calcule moindre
cot en utilisant un priori : les distances entre les descripteurs apparis. En eet, les appariements
Vincent Angladon
Rvision 0.6
23/ 39
Rapport PFE
correspondants aux plus faibles distances ont plus de chances dtre corrects (inliers), do lide
de les considrer en priorit. Cest sur ce constat que se base PROSAC [cit05] qui promet un gain
en performance dordre 100.
Toutefois, cest lalgorithme LMEDS que nous avons retenu (qui ncessite plus dinliers que
RANSAC), car pour des performances nettement plus leves que RANSAC, nous obtenions des
rsultats comparables. Ceci sexplique par le fait que lors de nos exprimentations, le taux dappariements errons tait souvent soit faible, soit trs lev. RANSAC aurait sans doute t intressant
si 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 comprend les tapes suivantes :
calcul des points dintrt et des descripteurs ;
recherche des descripteurs les plus proches parmi ceux des images reconnatre et dtermination 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 un
premier temps jai valu les performances de dirents algorithmes de calcul de points dintrt
et de descripteurs sur des images de taille 480x360 et slectionn ceux ayant un temps de calcul
infrieur 0.5s sur un iPhone4 pour 800 points dintrt. savoir FAST, BRISK, ORB et STAR
pour les dtecteurs et BRISK, BRIEF et ORB pour les descripteurs qui sont tous des descripteurs
binaires, 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 lhomographie
aprs application de lhomographie avec les vritables coins de limage.
Vincent Angladon
Rvision 0.6
24/ 39
Rapport PFE
Fig. 11 : Graphique en btons reprsentant lissue du test de robustesse, les moyennes pour
chaque image de test des moyennes des sommes des carts entre les coins estims et leurs valeurs
exactes. Lorsque cette valeur dpassait 24 pour un couple dimages, lhomographie tait estime
comme errone et cette valeur tait conserve jusqu la n du test pour viter dtirer le graphique
gnr 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, plutt
quen appliquant des transformations homographiques des images issues de matrices dhomographies alatoires. La raison cela tait que le cahier des charges autorisait le moteur de reconnaissance chouer si langle entre la normale de limage reconnatre et laxe Z du repre
camra tait trop important o si lcart de distance entre limage et la camra tait galement
trop grand. Cet angle et cette distance taient plus facilement paramtrables en passant par des
images de synthse. Un deuxime jeu dimages issues de photos des images reconnatre prises
par liPhone fut galement utilis ultrieurement. Le programme dvaluation naf crit en Python
recherchait de faon linaire, parmi tous les descripteurs calculs sur limage de rfrence, celui qui
tait 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 lensemble
des appariements calculs, on gardait seulement ceux dont la distance tait infrieure un certain
seuil multipli par la plus petite distance. Ce seuil tait ajust empiriquement en fonction des
descripteurs an dliminer le plus grand nombre dappariements incorrects (outliers).
Vincent Angladon
Rvision 0.6
25/ 39
Rapport PFE
Fig. 12 : Test de robustesse. gauche limage de rfrence. droite limage requte. Les cercles
reprsentent les points dintrt, les segments les appariements slectionns par le seuil. Le quadrilatre vert correspond limage des coins de limage de rfrence par lhomographie estime. On
notera 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 points
dintrt et des descripteurs mais plutt leur performance au sein dun algorithme de reconnaissance
prmatur. Pour faire bien, il aurait fallu dune part mesurer la rptabilit des dtecteurs sur des
images dont on connaissait linclination, la rotation, le changement de luminosit (en ne faisant
varier quun seul paramtre la fois) et projeter les points dintrt trouvs de limage de rfrence
sur limage modie (via lhomographie suppose connue) puis valuer la dirence entre les points
provenant de cette projection avec ceux de limage modie.
Et dautre part raliser un test similaire pour les descripteurs o lon aurait compar la distance
entre des descripteurs situs sur des points quelconques de limage de rfrence avec leur projection
situs sur limage modie.
A lissue de cette phase dvaluation, cest le couple de dtecteur/extracteur ORB/ORB qui fut
retenu. Toutefois conscient de la navet de mon valuation, jai conu mon architecture logicielle
de faon pouvoir facilement changer ultrieurement de dtecteur ou dextracteur.
Plus tard, jai eectu des tests an de dterminer divers paramtres intervenant dans le calcul
des points dintrt comme
le nombre de points dintrt. Le diminuer permet de diminuer les temps de calcul et les temps
de 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 se
dgrade rapidement. Au del de 500 descripteurs les gains en robustesse sont inmes. Un
nombre de 200 points dintrt orait un bon compromis ;
lutilisation dun grille an de forcer une rpartition plus homogne des points dintrt, qui
donnait certes de meilleurs rsultats dans certains cas o limage requte possdait des zones
trs contrastes localement (les points dintrt taient tous rpartis dans cette zone), mais
conduisait une dgradation globale des rsultats ;
le choix entre le calcul des descripteurs sur des images en nuance de gris ou dans un espace
de couleurs opposes. trangement, les rsultats ntaient pas meilleurs en espace de couleurs
opposes et les descripteurs se trouvs alourdis dun facteur 3 ;
la dimension des images dentrainement. Les points dintrt et descripteurs de ORB tant
moins robustes au scaling que ceux de SURF, la dcision fut prise de prendre des images
de rfrence de taille similaire la taille des images traites sur le tlphone. Ce choix fut
conrm par les tests. De plus, plus la taille des images de rfrence ainsi que celles utilises
pour 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
Vincent Angladon
Rvision 0.6
26/ 39
Rapport PFE
retenues.
4.5.2
Comparaison des descripteurs
La comparaison et la recherche des descripteurs constitue la seconde tape de la pipeline. Cette

partie tait le deuxime nerf de guerre du projet, aprs les descripteurs. La qualit et la rapidit
de la reconnaissance dimage dpend normment de ses performances. Lobjectif de cette phase
est de pouvoir dterminer en un temps assez court (<400ms) pour tous les descripteurs de limage
reconnatre, les descripteurs les plus proches parmi ceux de toutes les images reconnatre. Soit
moins de 2ms pour la recherche dun descripteur. Une fois les descripteurs apparis, on dtermine
les images de rfrence qui interviennent dans le plus grand nombre dappariements. Ces images
candidats sont ensuite values par la phase de validation. Des tests plus pousss ont montr que
si limage candidate correspondant au plus dappariements nest pas valide, la suivante (ayant le
deuxime plus grand nombre dappariements) nest jamais valide.
Une premire tentative consista utiliser lalgorithme FLANN (implmentation dOpenCV)
avec une distance de Hamming, qui donna des rsultats trs dcevants.
Dans un second temps, limplmentation de lalgorithme LSH multiprobe dOpenCV fut valu
avec des rsultats plus convainquants. Sur un jeu de 80 images requte et 74 images de rfrence
( reconnatre), seules 5 images nont pas t correctement reconnues (limage candidat tait incorrecte).
Un des inconvnients de limplmentation actuellement est lobligation de reconstruire lindex
de la structure de recherche aprs lajout de nouveaux descripteurs et chaque dmarrage de lapplication. De plus la srialisation de cette structure de donnes nest pas possible, mais heureusement
le temps de construction de lindex ne prend que 7 secondes pour 4900 images.
4.5.3
Validation
La validation est la troisime tape de la pipeline. Le cahier des charges imposait que le taux
de faux-positifs soit trs faible. Laccent a donc t mis sur la phase de validation an de ltrer
toutes les images mal reconnues par ltape prcdente.
Durant cette phase, les plus proches voisins des descripteurs de limage reconnue et de limage
reconnatre sont de nouveau calculs par recherche linaire et un seuillage des appariements est
eectu comme dans lapplication de test de robustesse. Certes, cette tape a dj t ralise avec
LSH prcdemment, mais avec un nombre dappariements infrieur. Les tests ont montr que le
sacrice en temps de calcul (20ms) est ngligeable face au gain en nombre dappariements corrects
supplmentaires obtenus. En eet, pour dterminer lhomographie entre limage requte et limage
de rfrence, les divers algorithmes destimation tels que RANSAC et LMEDS ont besoin dun ratio
de 40% dinliers. RANSAC et LMEDS donnaient exprimentalement les mmes rsultats, mais les
temps de calcul trs variables de RANSAC (jusqu 120ms en cas dchec destimation) ont donn
raison LMEDS.
Une fois lhomographie dtermine, celle-ci est applique aux quatre coins de limage. Une
dernire fonction calcule les angles sur le quadrilatre obtenu an de vrier quils correspondent
un quadrilatre peu aplati.
A lissue de cette tape, le taux de faux positif tait infrieur 1/10000 toutefois, le taux
dimages correctement reconnues non valides pouvait dpasser les 5%, d des chec destimation
de lhomographie dans la majorit des cas.
Vincent Angladon
Rvision 0.6
27/ 39
Rapport PFE
Fig. 13 : Un cas pathologique o tous les appariements sont corrects, mais lhomographie estime
est trop approximative car ces appariements sont situs sur la mme ligne.
Fig. 14 : Captures dcran du prototype pour iPhone du moteur de reconnaissance lissue de

la 5e semaine montrant la robustesse de la reconnaissance malgr les reets. Limage du chat est
correctement reconnue dans les deux cas.
4.6 Le tracking
Lobjectif 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 moins
coteuses et plus adaptes comme les algorithmes de calcul de ot optique. Pour simplier, un ot
optique est un champ de vecteur qui reprsente le dplacement de chaque pixel entre deux images
successives. Il est ainsi possible de dterminer rapidement et approximativement la position dun
certain nombre des points dintrt de limage prcdente dans limage courante. Lalgorithme
de Lucas-Kanade prsent dans OpenCV permet deectuer cette opration en moins de 100ms
pour une image de dimensions 320x288. En dterminant lhomographie entre les deux dernires
Vincent Angladon
Rvision 0.6
28/ 39
Rapport PFE
images on peut en dduire la transformation eectuer sur limage de sur-impression (qui est la
multiplication de toutes les homographies prcdentes).
Au bout dun certain nombre ditrations, la qualit du tracking se dgrade cause des pertes
de prcision accumules par les homographies prcdentes et la diminution du nombre de points
dintrt qui ont pu tre suivis. Le systme passe alors en mode de reconnaissance dimage an de
calculer une nouvelle homographie.
Fig. 15 : Captures dcran de lapplication de dmonstration montrant lache du lm Jobs tracke

et 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.
Vincent Angladon
Rvision 0.6
29/ 39
Rapport PFE
4.7 Les optimisations

Plusieurs 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 nont
pu porter leur fruits, ainsi peu de temps a t consacr cette tape en comparaison du temps
ncessaire pour tester toutes les voies possibles.
4.7.1
4.7.1.1
Optimisations CPU
La famille x86
Le backend, le serveur de reconnaissance et certains mobiles sous Android tournent sur des
Processeurs Intel de la famille x86. Sur ce type de processeur, il est possible dactiver lutilisation des
instructions SSE permettant de bncier dacclrations matrielle sur les calculs faisant intervenir
des vecteurs de nombre ottants. Aucun dveloppement spcique utilisant ces instructions na t
ralis, cependant les ags de compilations permettant den gnrer ont t activs.
4.7.1.2
La famille ARM
La famille ARM volue rapidement ce jour. On trouve de plus en plus de processeurs multicoeurs permettant de parallliser davantage de calculs. Sur les processeurs de la famille ARM on
trouve galement des instructions SIMD permettant deectuer du calcul vectoriel sur ottant
sous le nom dinstructions NEON. Ces instructions ont linconvnient de ne pas tre entirement
compatibles avec le standard IEEE-754, contrario des VFP. Les VFP permettent galement
deectuer des calculs sur des vecteurs de ottant mais sans aucune paralllisation sur le traitement
des lments des vecteurs, rduisant leur intrt.
Aucun dveloppement na t eectu avec des instructions NEON. Des extraits de code en
assembleur NEON ont toutefois t utilis pour la conversion des images en nuance de gris. galement, quelques fonctions de conversion dimage utilisant le framework Accelerate qui appelle trs
certainement des fonctions intrinsques NEON ou du DSP.
Ct OpenCV, peu doptimisations NEON ont t raliss. Les dveloppeurs ont prfr favoriser les optimisations rserves aux puces nVidia Tegra3 par le biais dun sdk conu par nVidia. On
trouve toutefois des essais rcents doptimisation NEON sur la branche de dev dOpenCV ralis
sur des oprations matricielles et quelques oprations basiques de traitement dimage, mais les
gains de performance sur les fonctions optimises est parfois nul. Ceci est probablement d au fait
que ces instructions utilisent des registres spars, et que certaines fonctions optimises doivent
eectuer un trop grand nombre de transfert de donnes entre ces registres.
4.7.2
Optimisations mmoire
La 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 tuer
par 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 rgles
de programmation strictes.
En Java, on pense tre protg par le ramasse-miette, mais ce dernier ne peut pas faire de
miracles, surtout dans le cas de rfrences cycliques. Il convient dutiliser des rfrences faibles
pour aider le ramasse-miette. Pour les parties en C++ il a fallu oublier les mauvaises habitudes du
Java et tre plus rigoureux. Lutilisation dinspecteurs de code et de prolers tel que Instruments
et Intel VTune Amplier se sont rvls dune aide trs prcieuse.
4.7.3
4.7.3.1
Les optimisations GPU

OpenCL
OpenCL permet de mixer du code GPU et CPU. Cest un projet initi par Apple et repris
par le groupe Khronos. Il semblerait avoir t utilis dans certaines bibliothques dApple telle
Vincent Angladon
Rvision 0.6
30/ 39
Rapport PFE
que CoreImage, mais les dveloppeurs nont pas accs au framework. Il est nanmoins possible
deectuer du dveloppement OpenCL sur un iPhone jail break. 1
Lutilisation dOpenCL sur Android est possible sur quelques rares terminaux. Le trs faible
nombre de puces (dans le domaine du mobile) compatibles avec les spcications dOpenCL rend
cette technologie peu attrayante.
Lutilisation de la bibliothque Aparapi (un projet initi par AMD) autoriserait plus de souplesse
dans lutilisation dOpenCL en convertissant automatiquement le bytecode Java en code OpenCL,
si la puce graphique est compatible. Mais mis part quelques exprimentation il nexiste pas
de portage ociel pour Android, sans doute d larrive de RenderScript. Cette technologie
disponible partir dAndroid 4.2, ore la possibilit de raliser des calculs intensifs et paralllisables
sur les dirents coeurs du CPU, le GPU ainsi que les DSP. Toutefois le dveloppeur na pas la
possibilit de forcer lutilisation du GPU.
4.7.3.2 CUDA
CUDA 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 faudra
attendre 2015 avec larrive des puces Logan et Parker pour pouvoir utiliser cette technologie.
4.7.3.3 OpenGL ES 2
OpenGL 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 sur
lcran. Il est ainsi possible dexploiter les calculs eectus sur le GPU. Deux parties seulement
de la pipeline OpenGL ES 2 sont trs personnalisables : la gestion des vertices et des fragments
via lutilisation de shaders qui sont des programmes compils et excuts par le GPU. Les vertex
shaders sont excuts paralllement pour chaque vertex du maillage, tandis que les fragments
shaders sont excuts paralllement pour chaque fragment (chaque pixel, approximativement).
Dans le cadre du traitement dimage, ce sont les fragments shaders que jai principalement
utilis. La comparaison de ltres simples (Sobel, ou Gaussien, convertion de couleurs, ) avec les
performances 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 de
calcul de ow optique via la mthode de Lucas-Kanade sur GPU, dautant plus que cet algorithme
ce 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 prototype
en Octave imitant le code des shaders an de vrier tapes par tapes la justesse des images
gnres. Limplmentation Octave a elle mme t valide par une implmentation indpendante
de cet algorithme poste sur MathWorks.
Au bout de 2 semaines de dveloppement, les rsultats furent trs dcevants. Le temps de calcul
obtenu sur GPU tait de 70ms avec 1 itration et 1 niveau de pyramides gaussiennes, pour 65ms
avec OpenCV pour 5 itrations et 3 niveaux de pyramides gaussiennes sur une image de taille
352x288 comprenant une centaine de points dintrt (cas dtude). Ces performances exceptionnelles dOpenCV sont dues au fait que le ot optique nest pas calcul sur toute limage mais
seulement sur les pixels possdant des points dintrt. En eet, avec une image comportant 2535
points dintrt rpartis uniformment, le calcul du ot optique prend 425ms avec OpenCV. Il est
galement fort possible que les faibles performances de mes shaders taient dues mon inexprience. Chaque fabriquant de puces propose des outils de proling et doptimisation des shaders
que je nai pas eu le loisir dessayer. Des performances plus prometteuses auraient certainement t
obtenues en utilisant des outils plus adapts au dveloppement GLSL.
An de terminer et naliser le framework de reconnaissance dans les temps, cette phase dexprimentation avec les shaders fut avorte. En outre, il nest pas envisageable de saturer le GPU
1 Preuve
de concept : https://github.com/linusyang/opencl-test-ios
Vincent Angladon
Rvision 0.6
31/ 39
Rapport PFE
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 shaders
sur iOS et une version ralise sous Octave. Les couleurs reprsentent les angles dorientation des
vecteurs.
Vincent Angladon
Rvision 0.6
32/ 39
Rapport PFE
5 AUTRES TRAVAUX
5 Autres travaux
Durant mon stage, jai eu loccasion de travailler ponctuellement sur divers projets dcrits dans
cette section.
5.1 UCheck
UCheck est la solution de reconnaissance dimages reposant sur le cloud. Bien que dploye depuis un certain temps, la solution avait besoin dtre maintenue. En particulier, des changements
importants ont t eectus concernant la communication avec le serveur, les actions de reconnaissance que jai eu la charge de reporter sur lapplication Android. Je me suis galement occup
de la rdaction de la documentation de lAPI, dun protocole de tests, de la validation de ces tests
et du redploiement de lapplication sur Google Play.
Jai travaill plus tard sur le backend, et en particulier la ralisation de tests de monte en
charge 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 un
sujet plus ambitieux : la ralit augmente urbaine. Toutefois, lissue dune phase de recherche et
dexprimentations, il fut dcid dinterrompre le projet car la solution de tracking actuelle ntait
pas assez performante sur liPhone 4 pour raliser un prototype satisfaisant, et les autres pistes
envisages tait trop ambitieuses pour le temps restant.
Vincent Angladon
Rvision 0.6
33/ 39
Rapport PFE
AUTRES TRAVAUX
Fig. 18 : Version prliminaire dun prototype de ralit augmente urbaine. Cette application
servait tester la compensation de lorientation donne par le magntomtre avec linclinaison
de lappareil, ainsi qu acher des tiquettes (ici St Aubin) synchronises avec les dirents
capteurs, pendant que du suivi de points dintrt aliment chaque frame par de nouveaux points
dintrt est eectu.
Vincent Angladon
Rvision 0.6
34/ 39
Rapport PFE
6 CONCLUSION
6 Conclusion
Durant 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 initiaux
concernant le nombre dimages pouvant tre reconnues sur le tlphone (jusqu 4900 et en moins
dune seconde). Comme dans tout projet, il demeure nanmoins des amliorations concernant les
performances du systme, en particulier pour le tracking. Dautre problmes nont pas t adresss
par choix, comme la gestion du ou, la dtection et le tracking simultan de plusieurs images et la
recherche partielle visant tre plus robuste dans la discrimination dimages contenant par exemple
le mme logo.
Fig. 19 : Impact du ou sur le calcul des appariements et lestimation de lhomographie. Les points
dintrt sont dessins en bleu, les appariements reprsents par des lignes, et le quadrilatre vert
reprsente 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 ralis
dapplications mobiles. Ces six mois en entreprise mont permis denrichir considrablement mes
comptences techniques via lapprentissage de nouveaux frameworks et API tel que : Android, Cocoa, 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 la
reconnaissance dimages ainsi que celui de la ralit augmente. Jai dcouvert lexistence de nombreux algorithmes en traitement dimage, des structures de donnes complexes, me permettant
de rsoudre certaines des problmatiques de mon sujet.
Si la ralit augmente sur mobile en est encore ses balbutiements, lavance constante des
technologies permet aujourdhui de concevoir des algorithmes de vision et de traitement dimages
toujours plus complexes et performants et de concevoir un avenir o les tlphones seront capables
de dtecter et suivre de faon robuste plusieurs objets simultanment, sans monopoliser lensemble
des ressources disponibles.
Larrive dans les annes venir dOpenVX 2 (le pendant dOpenGL pour la vision sur calculateur) devrait permettre de contribuer prodigieusement lessor des algorithmes de traitement
dimages et de jouir dun plus grand nombre dacclrations matrielles.
2 http://www.khronos.org/openvx
Vincent Angladon
Rvision 0.6
35/ 39
Rapport PFE
RFRENCES
7 Bibliographie
Rfrences
[AMN 98]
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 Computer

Vision (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 robust
recognition of museum objects. In In Proc. Int. Workshop on Mobile Vision (2006).
[Bra00]
Bradski G. :. Dr. Dobbs Journal of Software Tools (2000).
[CDF 04]
Csurka G., Dance C. R., Fan L., Willamowski J., Bray C. : Visual categorization with bags of keypoints. In In Workshop on Statistical Learning in Computer
Vision, ECCV (2004), pp. 122.
[cit05]
:. Matching with PROSAC - progressive sample consensus (2005), vol. 1.
[CXG 07]
Chen W.-C., Xiong Y., Gao J., Gelfand N., Grzeszczuk R. : Ecient extraction of robust image features on mobile devices. In Proceedings of the 2007 6th IEEE
and 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 detection
with informative local descriptors. In Proceedings of the Fourth IEEE International
Conference 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 as

a novel interface. 6475.
[IM98]
Indyk P., Motwani R. : Approximate nearest neighbors : towards removing the

curse of dimensionality. In Proceedings of the thirtieth annual ACM symposium on
Theory of computing (New York, NY, USA, 1998), STOC 98, ACM, pp. 604613.
[LJW 07]
Lv Q., Josephson W., Wang Z., Charikar M., Li K. : Multi-probe lsh : ecient
indexing for high-dimensional similarity search. In Proceedings of the 33rd international 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 algorithm conguration. In In VISAPP International Conference on Computer Vision
Theory and Applications (2009), pp. 331340.
[NS06]
Nister D., Stewenius H. : Scalable recognition with a vocabulary tree. In Proceedings of the 2006 IEEE Computer Society Conference on Computer Vision and
Pattern Recognition - Volume 2 (Washington, DC, USA, 2006), CVPR 06, IEEE
Computer Society, pp. 21612168.
[RRKB11]
Rublee E., Rabaud V., Konolige K., Bradski G. R. : Orb : An ecient

alternative to sift or surf. In ICCV (2011), Metaxas D. N., Quan L., Sanfeliu A.,
Gool L. J. V., (Eds.), IEEE, pp. 25642571.
Vincent Angladon
Rvision 0.6
36/ 39
Rapport PFE
RFRENCES
[TCG 08]
Takacs G., Chandrasekhar V., Gelfand N., Xiong Y., Chen W.-C., Bismpigiannis T., Grzeszczuk R., Pulli K., Girod B. : Outdoors augmented reality
on mobile phone using loxel-based visual feature organization. In Proceedings of the
1st 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 British
Machine Vision Conference (September 2009).
Vincent Angladon
Rvision 0.6
37/ 39
Rapport PFE
GLOSSAIRE
8 Glossaire
8.1 Scientique
Terme
Dtecteur
Extracteur
FLANN
Flot optique
Homographie
LMEDS
LSH
ORB
Point dintrt
RANSAC
Transformation ane
Dnition
Anglicisme qui dsigne un algorithme de calcul de points dintrts
Anglicisme qui dsigne un algorithme de calcul de descripteurs
(Fast Library for Approximate Nearest Neighbour) Bibliothque de recherche
rapide de voisins approximatifs dans des espaces de grande dimension. En fonction du jeu de donnes, la bibliothque slectionne un algorithme ainsi que
des paramtres. Les structures de donnes utilises peuvent tre en autre des
arbres-kd alatoires ou des arbres k-means hirarchiques.
champ de vecteur de mouvement apparent entre deux images conscutives.
Transformation 8 degrs de libert pouvant dcrire entre autre toutes les
projections dune camra du modle stnop. Les applications homographiques
ne conservent que les droites.
(Least MEDian of Sqares) algorithme destimation de paramtres base sur la
minimisation dun problme non linaire.
(Local Sensitivity Hash) algorithme de recherche de vecteurs voisins bas sur
des tables de hashage construites de faon ce que leur probabilit de collision
soit leve lorsque les vecteurs sont proches.
(Oriented FAST and Rotated Brief) dtecteur et extracteur bass sur FAST et
BRIEF
Point dune image reprsentant souvent un coin qui peut tre dtermin de faon robuste, de faon indpendante (jusqu une certaine limite) des variations
de changement dchelle, dillumination, de rotation et dangles de vue.
(RANdom SAmple Consensus) Algorithme itratif destimation de paramtres
dans un problme sur-contraint contenant des donnes aberrantes.
Transformation qui conserve les droites et les rapports de distances.
8.2 Technique
Terme
ABI
APK
ARC
ARM
AWS
Back-oce
Backend
Cocoa
Vincent Angladon
Dnition
(Application binary interface) spcie le format des chiers binaire rsultatnt
de la compilation (exemple les chiers .o). Ce format est spcique au systme
dexploitation, et larchitecture du processeur.
(Application PacKage) est le format de chier des applications sous Android.
(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 dans
la 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 instructions
supplmentaires pour librer la mmoire ou retenir des rfrences sont ajoutes.
(Advanced Risc Machine) dsigne une famille de processeurs instructions
rduite et basse consommation. Les processeurs ARM font gnralement partie
intgrante de SoC.
(Amazon Web Services) plateforme de cloud computing dAmazon.
Application darrire-boutique, orant une interface utilisateur rserv des
administrateurs qui permet de modier du contenu qui sera ach par un
autre application qui peut tre un service web, ou une application mobile. Un
back-oce est rserv des utilisateurs intermdiaires.
Ensemble des logiciels qui fournissent les donnes au backend. Souvent des
serveurs eectuant des calculs et en interaction avec des bases de donnes.
Framework OS X et iOS orant un vaste panels de bibliothques permettant
deectuer de la capture vido, de la communication rseau, du traitement
dimage sommaire, du parsing, des interfaces graphiques, mais surtout lensemble des types objets de base et arborescents.
Rvision 0.6
38/ 39
Rapport PFE
DSP
EABI
FPU
Front-oce
Frontend
GLSL
GWT
ISP
MIPS
NEON
OpenCV
ORM
REST/RESTful
RISC
Shader
SoC
SIMD
VCS
VFPU
Vincent Angladon
GLOSSAIRE
(Digital Signal Processor) unit de traitement du signal numrique. Lutilisation des instructions du DSP permet par exemple de calculer matriellement
des transformes de Fourrier.
(Embedded Application Binary Interface) ABI sur plateforme embarques.
(Floating Point Unit) unit de calcul ottant simple et double prcision.
Application destine aux utilisateurs naux.
Interface entre lutilisateur est le backend.
Langage de programmation driv du C permettant dcrire des shaders pour
OpenGL.
(Google Web Toolkit) framework Java permettant de gnrer des interfaces
utilisateurs en HTML/AJAX/Javascript.
(Image Signal Processor) puce de traitement dimages, prsente souvent sur le
SoC du processeur. LISP est utilise notamment pour lauto-focus, la balance
des blancs, lexposition auto, la compression JPEG
(Microprocessor without Interlocked Pipeline Stages) architecture de processeurs RISC utiliss principalement pour les systmes embarqus.
unit de calcul de type SIMD permettant lacclration de calculs vectoriels.
Cest le pendant des instructions SSE sur x86.
(Open Source Computer Vision Library) bibliothque C++ (avec des bindings
Java, Python, Matlab, ...) de vision assiste par ordinateur et de traitement
dimage incluant des fonctions dapprentissage automatique et deiverses structures de donnes. Cest un projet initi par Intel, actuellement open source. La
plupart des fonctions possdes divers optimisations CPU voire GPU.
(Object Relational Mapping) fournit une traduction des entres dune table
dune base de donnes sous forme dobjets et du schma en classe.
(Representational state transfer) Cest une architecture logicielle pour des systmes distribus de type client-serveur sans tat avec diverses proprits. Un
exemple typique sont certaines API de Google o on peut envoyer une requte
HTTP un serveur et on reoit la rponse sous forme dun chier XML ou
JSON.
(Reduced Instruction Set Computing) famille de processeurs comportant un
jeu dinstructions trs rduit mais optimis. Cest la famille la plus courante en
systme embarqu.
Programme compil et excut sur le GPU permettant de modier nement le
comportement dune pipeline de rendu 3D telle que OpenGL ou DirectX.
(System on Chip) circuit intgr regroupant divers composants tels quun processur, un GPU, de la RAM, un ISP, un co-processeur, , un DSP, de mme
que les micro-controlleurs.
(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 citera
SVN et Git.
(Vector Floating Point Unit) unit de calculs ottant vectoriel. Les calculs sont
toutefois eectus de faon squentielle sur les lments des vecteurs, rendant
les VFPU obsoltes depuis larrive des instructions NEON.
Rvision 0.6
39/ 39

Rapport Vinsdscent An Glad On

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Rapport Vinsdscent An Glad On

Încărcat de

Drepturi de autor:

Formate disponibile

ENSEEIHT

Projet de fin dtudes

Reconnaissance dimages sur smartphones

Mars - septembre 2013

TABLE DES MATIRES

Table des matires

Le cahier des charges

La reconnaissance dimages sur smartphone . . . . . . . . . . . . . . . . . . . . 13

Les solutions concurrentes

Les appareils cibles

Conclusion de ltude des caractristiques matrielles

Les applications mobiles

tat de lart sur la reconnaissance dimages

4.4.1.1 Direntes approches

4.4.1.2 Les solutions sur plateformes mobiles

TABLE DES MATIRES

4.4.2.1 Les points dintrt et les descripteurs

4.4.2.2 Comparaison des descripteurs

4.4.2.3 Estimation de lhomographie

Lalgorithme de reconnaissance dimages et de tracking

Les points dintrt

Comparaison des descripteurs

4.7.1.1 La famille x86

4.7.1.2 La famille ARM

Les optimisations GPU

Ralit augmente urbaine

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

La reconnaissance visuelle dimages sur smartphone est un domaine en pleine eervescence.

une application qui envoie un serveur les images issues de la camra ;

Le cahier des charges

compatibilit avec iOS 5.0 ou avec la version 9 du SDK dAndroid ;

Fig. 3 : Planning eectif.

4 LA RECONNAISSANCE DIMAGES SUR SMARTPHONE

4 La reconnaissance dimages sur smartphone

LA RECONNAISSANCE DIMAGES SUR SMARTPHONE

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

Conclusion de ltude des caractristiques matrielles

Ltude prcdente a permis dtablir les conclusions suivantes :

4 LA RECONNAISSANCE DIMAGES SUR SMARTPHONE

Le back-oce est crit en GWT et bas sur celui du produit uCheck.

LA RECONNAISSANCE DIMAGES SUR SMARTPHONE

4 LA RECONNAISSANCE DIMAGES SUR SMARTPHONE

LA RECONNAISSANCE DIMAGES SUR SMARTPHONE

Les applications mobiles

Fig. 8 : Graphique de ot de contrle de lAPI dcrivant les changements de modes entre la

4 LA RECONNAISSANCE DIMAGES SUR SMARTPHONE

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

4.4.1.1 Direntes approches

David Lowe a t un des prcurseurs proposer une mthode robuste de reconnaissance

LA RECONNAISSANCE DIMAGES SUR SMARTPHONE

4 LA RECONNAISSANCE DIMAGES SUR SMARTPHONE

4.4.1.2 Les solutions sur plateformes mobiles

LA RECONNAISSANCE DIMAGES SUR SMARTPHONE

4 LA RECONNAISSANCE DIMAGES SUR SMARTPHONE

4.4.2.2 Comparaison des descripteurs

LA RECONNAISSANCE DIMAGES SUR SMARTPHONE

4.5 Lalgorithme de reconnaissance dimages et de tracking

Fig. 10 : La pipeline de reconnaissance dimages.

Les points dintrt

4 LA RECONNAISSANCE DIMAGES SUR SMARTPHONE

LA RECONNAISSANCE DIMAGES SUR SMARTPHONE

4 LA RECONNAISSANCE DIMAGES SUR SMARTPHONE

Comparaison des descripteurs