Bachelor Informatica
Spoorzoekertje in Augmented
Reality
Marlous Kottenhagen
8 juni 2018
Supervisor(s): Robert Belleman, Bert Bredeweg
Inf
orma
tica
—
Universiteit
v
an
Ams
terd
am
Samenvatting
Spoorzoekertje is een spel waarbij door middel van hints gezocht wordt naar een eindloca-tie. In dit onderzoek wordt gekeken naar hoe spoorzoekertje in AR gespeeld kan worden. Hierbij wordt onderzocht hoe virtuele objecten terug kunnen worden gezet op een gespeci-ficeerde locatie in de wereld en hoe deze positie behouden blijft. Hierbij is gekeken naar de mogelijkheid om dit door middel van het ORB feature herkenning algoritme te doen. Uit het onderzoek is het nog niet zeker of ORB een geschikt algoritme is om te gebruiken in spoorzoekertje.
Inhoudsopgave
1 Inleiding 7 1.1 Onderzoeksvraag . . . 7 2 Achtergrond 9 2.1 Augmented reality . . . 9 2.2 AR toolkits . . . 10 2.2.1 Vuforia . . . 10 2.3 HoloLens . . . 10 2.4 Feature herkenning en AR . . . 11 3 Object plaatsing 13 3.1 Feature herkenning . . . 13 3.1.1 SIFT . . . 13 3.1.2 SURF . . . 15 3.1.3 ORB . . . 16 3.1.4 Vergelijking en keuze . . . 18 3.2 Feature matching . . . 19 3.3 Positie transformatie . . . 20 3.3.1 Affiene transformatie . . . 20 3.3.2 Homografie transformatie . . . 21 4 Implementatie 23 4.1 Algemene implementatie . . . 234.2 Feature detectie en matching . . . 24
4.3 Object plaatsing . . . 25 4.4 Database . . . 26 5 Experimenten 29 5.1 Snelheid . . . 29 5.2 Nauwkeurigheid . . . 29 5.3 lichtintensiteit . . . 30 6 Resultaten 31 6.1 Snelheid . . . 31 6.2 Nauwkeurigheid . . . 31 6.3 Lichtintensiteit . . . 32 6.4 Verwerking resultaten . . . 33 7 Discussie 35 8 Conclusie 37 8.1 vervolgonderzoek . . . 37
A Experiment foto’s 41 A.1 . . . 41 A.2 . . . 42 A.3 . . . 43
HOOFDSTUK 1
Inleiding
Spoorzoekertje is een spel dat zowel door kinderen als volwassenen gespeeld kan worden. Hierbij moeten de spelers door middel van een serie hints het juiste pad volgen om zo bij de eindbestem-ming uit zien te komen. Dit kan gedaan worden met behulp van getekende pijlen op de weg of puzzels die opgelost moeten worden. De moeilijkheidsgraad van de hints hangt af van de leeftijd van de spelers.
Het doel van dit project is om een app te ontwikkelen waarmee spoorzoekertje gespeeld kan wor-den met behulp van augmented reality (AR). Hierbij worwor-den de verschillende hints weergegeven met behulp van AR. Wanneer de speler met zijn camera over de plek van een hint beweegt wordt deze zichtbaar voor de spelers.
Om spoorzoekertje in AR te kunnen verwezenlijken zijn er twee belangrijke deelonderzoeken. • Positie tracking: Voor de spoorzoekertje applicatie is het belangrijk dat de positie van de
speler nauwkeurig wordt bepaald. Als we weten waar de speler zich bevindt, kan dit handig in de applicatie worden toegepast. Zo kunnen we kijken in een gebied om de speler om te weten welke hints in de buurt zijn. Ook kan de positie van de speler gebruikt worden om te kijken of deze het juiste pad volgt.
• Beeldregistratie: Wanneer spoorzoekertje wordt gespeeld is het belangrijk dat de objecten op de juiste positie staan zodat deze juist ge¨ınterpreteerd worden door de spelers. Bij het gebruiken van de applicatie is het belangrijk dat de virtuele objecten op hun positie blijven staan en dat na het afsluiten van de app de virtuele objecten op de juiste positie worden teruggezet.
Figuur 1.1 weergeeft een flow chart van het verloop van de spoorzoekertje applicatie.
1.1
Onderzoeksvraag
Het onderzoek beschreven in deze scriptie gaat over het tweede deelonderzoek: beeldregistratie. Mijn onderzoeksvraag hierbij is ”Wat is een geschikte methode voor het plaatsen van een virtueel object in AR waarbij zijn positie behouden blijft ten opzichte van de werkelijke wereld?”
Om mijn onderzoeksvraag te kunnen beantwoorden beginnen we met een overzicht van de belang-rijkste literatuur rondom feature herkenning methodes. Features zijn punten in een afbeelding die herkenbaar zijn. Deze methodes worden aan de hand van de literatuur met elkaar vergeleken. Aan de hand van het literaire onderzoek wordt bepaald met welke methodes verder onderzocht gaan worden. Om te bepalen welke methodes geschikt zijn, worden ze beoordeeld aan de hand van een aantal eisen waaraan de methode moet voldoen om gebruikt te kunnen worden voor spoorzoekertje. Voor de gekozen methodes wordt onderzocht of ze inderdaad aan de eisen vol-doen door middel van een aantal experimenten en wordt gekeken of de methodes gebruikt zouden
Figuur 1.1: Flow chart verloop spoorzoekertje
kunnen worden voor de app.
Met behulp van de gekozen methode zal gekeken worden waar het object moet worden geplaatst. Hierbij wordt gekeken naar de features van de oorspronkelijke locatie en de features van de huidige locatie. Wanneer voldoende matches zijn gevonden wordt het object geplaatst en zal deze gezien kunnen worden door de spelers.
HOOFDSTUK 2
Achtergrond
2.1
Augmented reality
Augmented reality (AR) is het weergeven van virtuele objecten in de werkelijke wereld. Op twee verschillende manieren kan gebruik worden gemaakt van AR, met markers of markerless. Een marker is een visueel beeld waarop het virtuele beeld wordt geplaatst. De marker is een referentie voor het bepalen van de positie en schaal. Bij markerless AR worden virtuele beelden zonder gebruikt te maken van een marker in de wereld geplaatst. Voorbeelden hiervan zijn te zien in de figuren 2.1en 2.2.
Figuur 2.1: Een voorbeeld van mar-kerless AR.
Bron:http://acreelman. blogspot.com/2016/07/
\pokemon-and-source-criticism. html
Figuur 2.2: Een voorbeeld van AR met een marker.
Bron:https://library.vuforia. com/\articles/Training/ Image-Target-Guide
AR wordt gebruikt in verschillende mobiele applicaties. Zo wordt het veel gebruikt in mobiele spelletjes. Een voorbeeld hiervan is pokemon GO [12]. Pokemon GO is een mobiel spel waar-bij je pokemon kon vangen, deze pokemon kon je door middel van AR in de werkelijke wereld laten verschijnen. Maar AR wordt niet alleen gebruikt voor spelletjes. Met behulp van de Ikea app kunnen meubels in je kamer worden geplaatst[7]. Op deze manier kun je kijken hoe het in je kamer past voordat je het koopt. De Albert Heijn had een spaaracties waarbij verschillende dino plaatjes gebruikt konden worden als marker [6]. Zo kon je dino’s over je tafel laten wandelen. In spoorzoekertje zal gebruik worden gemaakt van markerless AR. Spoorzoekertje zal buiten worden gespeeld en het zoeken naar hints zal een stuk makkelijker zijn wanneer overal markers worden opgehangen.
2.2
AR toolkits
Er bestaan verschillende AR toolkits waarmee het mogelijk is om AR applicaties te cre¨eren. Voorbeelden hiervan zijn Vuforia, ARkit en ARcore [18][2][1]. Met behulp van deze toolkits is het mogelijk om een app te maken, gebruik makend van markerless of markerbased AR. Vuforia is een toolkit die gebruikt kan worden voor zowel Android als Apple, ARkit is ontwikkeld voor Apple en ARcore voor Android.
2.2.1
Vuforia
Vuforia kan gebruikt worden voor markerless AR. Dit kan worden gedaan met behulp van ground-planes [19]. Hierbij detecteert Vuforia horizontale oppervlakken die gebruikt kunnen worden om virtuele objecten neer te zetten. Het object op zijn plek gehouden met behulp van ankers. Een anker is een 6 degrees of freedom punt in de wereld, 6 degrees of freedom betekend dat het anker kan transleren en roteren in de x, y en z as. Deze ankers worden gebruikt om bij te houden waar het object staat in de wereld. Wanneer een object wordt geplaatst zal deze zijn positie in de wereld behouden. De gebruiker kan wegkijken met zijn telefoon en later weer naar dezelfde positie terugkijken om het object daar nog steeds te zien staan. Het gebruik van deze ankers kan alleen binnen de huidige sessie. Zodra de applicatie wordt afgesloten kunnen ze niet meer worden teruggevonden en op dezelfde positie worden teruggeplaatst.
Voor ons onderzoek wordt gekeken of het plaatsen van objecten gecombineerd kan worden met Vuforia groundplane. Hierbij zou dan door middel van het feature herkenning algoritme worden gezocht wanneer het object moet worden neergezet en wordt de plaats waar het object wordt neergezet bepaald. Wanneer deze in een Vuforia grounplane wordt neergezet kan om het object heen bewogen worden en lijkt het echt een onderdeel van de wereld.
2.3
HoloLens
De HoloLens is een draagbaar apparaat dat gebruikt kan worden voor het plaatsen van holo-grammen in de werkelijke wereld [11]. Holoholo-grammen zijn objecten gemaakt van licht of geluid die om je heen te zien zijn met behulp van de HoloLens. Deze hologrammen kunnen op een specifieke positie in de wereld worden geplaatst. Hierdoor kan je om het hologram heen lopen en zal deze op dezelfde positie in de wereld blijven staan. Een voorbeeld van een hologram gezien met een HoloLens wordt weergeven in figuur 2.3.
Figuur 2.3: Voorbeeld van een hologram die gezien kan worden door het dragen van de HoloLens. Bron:https://docs.microsoft.com/en-us/windows/mixed-reality/hologram
De hologrammen worden met behulp van een spatial anchor op hun positie gehouden. Deze ankers geven aan dat de HoloLens deze locatie moet tracken. De spatial anchors zijn persistent. Hiervoor wordt er een string key opgeslagen die door een applicatie kan worden gebruikt om het anchor later weer te kunnen identificeren.
Voor het onderzoek is de HoloLens interessant om te ontdekken hoe ze onthouden op welke locatie objecten stonden en of dit ook gebruikt zal kunnen worden in spoorzoekertje.
2.4
Feature herkenning en AR
In eerder onderzoek is gekeken naar het implementeren van een outdoor mobiele AR applicatie [16]. Deze applicatie geeft informatie weer over objecten die door de applicatie worden her-kend. In de applicatie wordt de huidige camera afbeelding vergeleken met afbeeldingen die in een database staan opgeslagen. Aan de hand van de locatie van de gebruiker wordt gezocht naar afbeeldingen uit de database die relevant zijn. Van de gevonden afbeeldingen worden features herkend met behulp van het SURF algoritme [3]. De afbeeldingen worden met de features in een boom structuur geplaatst. De features voor het huidige camerabeeld worden ook bepaald en vergeleken met de features in de boom. Hieruit worden de afbeeldingen gerangschikt op het aantal features die matchen met het huidige camera frame.
Uit dit onderzoek blijkt dat SURF en andere feature herkenning algoritme al eerder zijn gebruikt voor het herkennen van afbeeldingen en het plaatsen van virtuele objecten over de afbeelding. SURF zou ook een goede kandidaat kunnen zijn om te gebruiken in spoorzoekertje.
HOOFDSTUK 3
Object plaatsing
Voor het plaatsen van een object worden verschillende stappen doorlopen. Eerst wordt gekeken of het huidige beeld een locatie is waar het object wordt geplaatst. Vervolgens wordt gekeken waar het object in de wereld geplaatst moet worden. Hier worden de verschillende technieken beschreven die gebruikt zullen worden in de implementatie.
3.1
Feature herkenning
De hint wordt geplaatst zodra de speler de plek van de hint in beeld heeft. Om te kunnen her-kennen of het huidige beeld de juiste plek is wordt er gebruik gemaakt van image matching. Het frame van het moment waarop het object geplaatst is wordt vergeleken met het huidige frame op het moment van spelen. Wanneer er wordt geconstateerd dat het huidige frame een match is wordt het object geplaatst.
Om twee frames te kunnen matchen wordt gebruik gemaakt van features in de frames. Hier-voor zijn feature herkenning algoritmes nodig die zoeken naar deze features, ook wel keypoints genoemd. In deze paragraaf worden drie verschillende algoritmes uitgelegd en met elkaar verge-leken.
• Scale Invarient Feature Transform (SIFT) • Speeded Up Robust Features (FAST) • Oriented Fast and Rotated Brief (ORB)
Bij feature herkenning wordt er gezocht naar keypoints in een afbeelding. Features zijn goed herkenbare punten in een afbeelding. Deze keypoints zijn vaak plekken waar er een groot contrast bestaat tussen gradi¨enten van pixels. Vervolgens worden aan deze keypoints descriptors toegevoegd. Deze descriptors bevatten informatie over de ori¨entatie en locatie van het keypoint.
3.1.1
SIFT
Voor het berekenen van keypoints in een afbeelding kan SIFT worden onderverdeeld in vier hoofdstappen die worden gebruikt voor het detecteren en berekenen van de keypoints [9]. Deze zijn het detecteren van scale space extrema, het bepalen van locatie en de scale van een keypoint. Een ori¨entatie wordt meegegeven aan elk keypoint en er wordt een keypoint descriptor opgesteld. Om te bepalen waar keypoints zich bevinden wordt gezocht naar extrema in scale space. Een scale space is een continue functie die de afbeelding weergeeft in verschillende schalen. De scale space wordt gemaakt door middel van de convolutie van een afbeelding met een variabele scale Gaussian:
Waarbij L staat voor de geconvuleerde afbeelding, I de originele afbeelding en G is de gaussian functie, G(x, y, σ) = 2πσ12e−(x
2+y2/2σ2)
. σ staat voor de schaal. Vervolgens wordt de Difference-of-Gaussian van de scale space berekend. De Difference-Of-Gaussian wordt berekend door twee dicht bij elkaar liggende scales in de scale space van elkaar af te trekken:
D(x, y, σ) = L(x, y, kσ) − L(x, y, σ)
Van D(x, y, σ) worden vervolgens de maxima en minima gedetecteerd. Hiervoor wordt elke pixel vergeleken met zijn buren. De gevonden maxima en minima vormen samen de keypoints van de afbeelding.
Vervolgens wordt een fit uitgevoerd over de nabijgelegen data, de omliggende pixels, van keypoints om de locatie, schaal en ratio van principale curvatures te bepalen. Hiermee wordt gekeken of een keypoint een laag contrast heeft of geplaatst is langs een rand. Deze punten worden dan niet meer gezien als mogelijke keypoints.
Voor het berekenen van de locatie en scale wordt er gebruik gemaakt van de Taylor reeks, tot en met de tweede term, van de scale space functie D(x, y, σ).
D(x) = D +∂D T ∂x x + 1 2x T∂2D ∂x2x
Vervolgens wordt met behulp van deze functie de locatie van het extremum bepaald. Dit wordt gedaan door de afgeleide te nemen van bovenstaande functie in x en deze gelijk te stellen aan 0. Dit geeft de volgende formule
ˆ x = −∂ 2D−1 ∂x2 ∂D ∂x
. Wanneer ˆx > 0.5 in elke dimensie ligt het extremum dichter bij een ander sample point. Er wordt een nieuw sample point gekozen en de berekeningen worden opnieuw uitgevoerd. Wanneer het juiste sample point is gekozen wordt ˆx aan het sample point toegevoegd. Sample points met een laag contrast worden verwijderd. Dit wordt gedaan door te kijken naar de waarde van D(ˆx). Als deze waarde onder de 0.03 ligt wordt het keypoint verwijderd.
Om slecht gelokaliseerde keypoints langs de randen te verwijderen wordt gebruik gemaakt van een Hessian matrix. De Hessian matrix wordt gebruikt voor het berekenen van de principal cur-vurture. De principale curvurtures zijn gelijk aan de eigenwaarde van de Hessian matrix. Om te weten welke keypoints verwijderd moeten worden wordt gekeken naar de ratio van de principal curvurture, Determinant(H)T race(H) . Wanneer deze waarde kleiner is dan (r + 1)2/r, waarbij r een vooraf
bepaalde threshold is, wordt het keypoint bewaard.
Verder wordt aan elk keypoint een ori¨entatie meegegeven. Hierdoor kan de keypoint descriptor gerepresenteerd worden relatief aan deze ori¨entatie. Dit zorgt ervoor dat de keypoint descriptor invariant is onder rotatie. Om de ori¨entatie te bepalen van de descriptors wordt eerst de scale van een keypoint gebruikt voor het kiezen van een Gaussian smoothed afbeelding L. Vervolgens wordt voor elke image sample L(x, y) de gradient magnitude m(x, y) en ori¨entatie θ(x, y) be-paald. Van alle sample points in een bepaalde regio rondom het keypoint wordt van alle gradient ori¨entaties een orientatie histogram gemaakt. Deze bestaat uit 36 bins die 360 graden voorstel-len. De hoogste piek uit het ori¨entatie histogram vormt samen met alle lokale pieken die binnen 80% van de hoogste piek liggen de ori¨entatie van het keypoint.
Als laatste worden de descriptors voor de keypoints gevormd. Dit wordt gedaan door te kijken naar alle gradient magnitudes en ori¨entaties van alle sample points binnen een regio rondom een keypoint. De gevonden gradients worden vervolgens gewogen met behulp van een Gaussian window. De gradients worden in ori¨entatie histogrammen geplaatst in sample regio’s van 4x4. Elk ori¨entatie histogram heeft 8 bins, deze bins staan voor 8 verschillende richtingen. Deze ori¨entatie histogrammen worden toegevoegd aan de keypoint. Om het effect van verlichting te verminderen wordt de descriptor vector genormaliseerd en wordt het effect van grotere gradients verminderd.
3.1.2
SURF
Het SURF algoritme [3] zoekt eerst naar interest points in een afbeelding. Deze zijn vergelijkbaar met de keypoints uit SIFT. Vervolgens wordt net zoals bij SIFT een descriptor aan deze interest points toegevoegd.
SURF maakt gebruik van een Hessian matrix voor het detecteren van interest points. Hiervoor wordt gebruik gemaakt van integrale afbeeldingen. Dit is een afbeelding waarbij elke pixel de waarde heeft van zichzelf met daarbij alle waardes van de pixels boven en links van de pixel opgeteld. Een voorbeeld van het berekenen van een integrale afbeelding is te zien in Figuur 3.1 Dit zorgt voor een snellere computatie tijd. Er wordt gebruik gemaakt van een Hessian matrix omdat deze een goede performance heeft op het gebied van nauwkeurigheid. Er worden blob achtige structuren gevonden op plaatsen waar de determinant van de Hessian matrix het hoogst is. Blob structuren is een regio in de afbeeldingen waar een verschil te zien is met de rest van de omgeving. Dit kan een verschil in helderheid of kleur zijn. De gebruikte Hessian matrix is:
H(x, σ) =Lxx(x, σ) Lxy(x, σ) Lxy(x, σ) Lyy(x, σ)
Figuur 3.1: Voorbeeld van het berekenen van een integrale afbeelding. Bron:https://www.mathworks.com/help/images/integral-image.html
Om interest points in verschillende schalen te kunnen vinden wordt gebruik gemaakt van een scale space representatie. Box filters worden in verschillende groottes op de afbeeldingen gebruikt voor het cree¨eren van deze scale space. De scale space wordt opgedeeld in octaven, elk octaaf wordt vervolgens weer opgedeeld in een constant aantal scale levels. Zo heeft de eerste octaaf scale levels van 9x9, 15x15, 21x21 en 27x27. Vervolgens wordt voor de volgende octaven het filter size verhoogd met 6, 12, 24 en zo elke keer met 2 vermenigvuldigd. Door de grote veranderingen in schaal tussen de eerste filters is het samplen van de schalen vrij ruw. Hierom is ook een tweede manier ontwikkeld om de scale space te kunnen construeren. Deze methode verdubbelt eerst de grootte van de afbeelding. Het eerste filter heeft een grootte van 15x15. Voor de volgende octaaf wordt deze met 12 verhoogd en gaat het verder zoals in de eerste methode.
Vervolgens worden interest points gelokaliseerd, door middel van een non-maximum suppression in een 3x3x3 buurt. Er wordt gezocht naar lokale maxima over de verschillende schalen. Dit wordt gedaan met behulp van de Hessian matrix, de determinanten worden ge¨ınterpoleerd. Aan de gedetecteerde interest points worden descriptors toegevoegd. Hiervoor wordt eerst de ori¨entatie van de interest point bepaald. Dit wordt gedaan met behulp van de Haar wavelet
res-ponse. De Haar wavelet response wordt berekend in een circulaire buurt met straal 6s, waarbij de s voor de schaal staat. De wavelets hebben een grootte van 4s. Ook hier worden weer inte-grale afbeeldingen gebruikt om snel te kunnen filteren. De berekende wavelet responsen worden gewogen met een Gaussian. De responsen worden weergeven als een punt in de ruimte, hieruit wordt vervolgens de dominante ori¨entatie bepaald. Dit wordt gedaan door middel van een sliding window. Alle x en y waarde van de punten binnen de sliding window worden bij elkaar opgeteld. Deze opgetelde waarde vormen samen een ori¨entatie vector. De langste vector over alle windows wordt gebruikt als de ori¨entatie van het interest point.
Vervolgens wordt de descriptor aan de interest points toegevoegd. Hiervoor wordt er eerst een vierkante regio rondom de interest points geplaatst, deze heeft een grootte van 20s, waarbij s staat voor de schaal. De geplaatste vierkanten worden vervolgens onderverdeeld in subregio’s van 4x4. Voor elk vierkant wordt de Haar wavelet response berekend. De gevonden responsen worden eerst weer gewogen met een Gaussian. Voor elke subregio worden de x en y waarde van de responsen bij elkaar opgeteld, dit wordt ook gedaan voor de absolute waarde van x en y. Deze waarde vormen samen de descriptor van de interest points.
3.1.3
ORB
ORB [15] maakt gebruik van twee algoritmes, FAST [14] en BRIEF (Binary Robust Independent Elementary Features) [5]. FAST wordt gebruikt voor het detecteren van keypoints en BRIEF wordt gebruikt voor het berekenen van de bijbehorende descriptors. FAST en BRIEF zijn echter nog niet goed bruikbaar voor feature matching, FAST heeft nog geen ori¨entatie component in zijn feature vectoren zitten en BRIEF is invariant tegenover rotatie. Deze punten voegt ORB toe aan FAST en BRIEF.
Het FAST algoritme is gebaseerd op een segment test voor een hoek kandidaat p in een cirkel van 16 pixels.p wordt gezien als een hoek wanneer n naast elkaar gelegen pixels in de cirkel een hogere intensiteit hebben dan Ip+ t of allemaal een lagere intensiteit dan Ip− t. Ip is de intensiteit van
de hoek kandidaat en t is een gekozen threshold.
Om de segment test sneller te maken wordt in FAST gebruik gemaakt van machine learning. Eerst wordt er een hoek detector gemaakt voor een gegeven n. Dit wordt gedaan door eerst alle cirkels van 16 pixels uit een set van afbeeldingen te halen. Elke locatie op de cirkel kan een van drie staten hebben.
Sp→x= d, Ip→x ≤ Ip− t s, Ip− t Ip→x < Ip+ t b, Ip+ t Ip→x
Hierbij is x een punt op de cirkel waarbij x ∈ {1 . . . 16} en p → x geeft aan dat het gaat om pixel x relatief aan p.
Laat P de set zijn van alle pixels in de afbeeldingen. P kan onderveeld worden in drie subsets, Pd, Psen Pb. Pd bevat alle punten die donkerder zijn dan de hoek kandidaat met een treshold
t, Ps bevat alle punten die helderder zijn met een threshold t en Pb bevat alle punten die qua
intensiteit lijken op de hoek kandidaat. Vervolgens wordt de cirkel punt x gekozen die over de meeste info beschikt of de kandidaat pixel een hoek is. Dit wordt berekend door de entropie van Kp. Kp is een boolean die waar is wanneer p een hoek is. Van de gekozen x worden subsets
bepaald en begint het algoritme opnieuw. Dit wordt gedaan totdat de entropie van een subset gelijk is aan nul, alle p in de subset hebben dan dezelfde waarde voor Kp. Bovenstaand algoritme
genereert een beslisboom die alle hoeken uit de gegeven afbeeldingen kan classificeren.
Om ervoor te zorgen dat er niet meerdere features naast elkaar worden gedetecteerd wordt er gebruik gemaakt van nonmaximal suppression. Nonmaximal suppression is een methode om fea-tures te elimineren die te dicht bij elkaar liggen.
Wanneer voor een vaste waarde n, t groter wordt neemt het aantal gevonden hoeken af. In FAST is gekozen voor een waarde van n = 9, omdat deze de beste resultaten geeft. De hoeksterkte
van een punt wordt gegeven door de maximale waarde t waarvoor een punt wordt geclassificeerd als hoek. De beslisboom kan voor een waarde t een pixel classificeren als wel of geen hoek. Er kan gebruik worden gemaakt van de bisectiemethode om de waarde van t te bepalen waarvoor het punt voor het eerst wordt geclassificeerd als geen hoek. De bisectiemethode is een zoek algoritme waarbij de dataset steeds wordt gehalveerd totdat het juiste punt gevonden is. Voor FAST betekent dit dat er naar het middelpunt van de data wordt gekeken als deze waarde een 1 is, wel een hoek, moet er in de rechterhelft verder worden gezocht. Als de waarde 0 is, geen hoek, moet er in de linkerhelft verder worden gezocht.
Voor het toevoegen van een ori¨entatie aan de FAST keypoints maakt ORB gebruik van een intensity centroid. Hiervoor wordt eerst het moment berekend:
mpq=
X
x,y
xpypI(x, y)
Met behulp van het moment kan vervolgens de centroid berekend worden: C = m10
m00
m01
m00. Daarna wordt er een vector geconstrueerd vanuit het centrum van de hoek naar de centroid, −OC.−→ De ori¨entatie is gelijk aan de hoek van de vector en kan berekend worden door middel van θ = atan2(m01, m10). Om ook rekening te houden met rotatie wordt ervoor gezorgd dat de
momenten worden berekend door middel van een x en y gelegen in een circulaire regio met straal r. Verder voegt ORB nog een mogelijkheid aan FAST toe om multi-scale features toe te staan. Hiervoor wordt een scale piramide van de afbeelding gebruikt. Voor elk level van de piramide worden FAST features geproduceerd.
Het BRIEF algoritme wordt gebruikt voor het berekenen van de keypoint descriptors. BRIEF maakt gebruik van willekeurig classificatie bos en de Naive Bayesian classifier. Een willekeurig classificatie bos bestaat uit meerdere classificatie bomen. In een classificatie boom staat elke node voor een beslissing die gemaakt moet worden. De bladeren van de boom geven dan de classificatie aan. Een willekeurig classificatie bos bestaat uit meerdere classificatie bomen. Elke boom geeft zijn eigen classificatie. De classificatie die het meest uit het bos komt wordt geko-zen als de uiteindelijke classificatie. Naive Bayesian classifier is een classificatie methode die gebruikt maakt van de theorama van Bayes.
Het willekeurige classificatie bos en de Naive Bayesian classifier worden gebruikt voor het cre¨eren van een bit vector. Hiervoor worden er tests uitgevoerd over een patch, een deel van een plaatje van grote S × S. Deze test wordt alsvolgt gedefinieerd.
τ (p; x, y) :=1 if p(x) < p(y) 0 otherwise
P(x) is de pixel intensiteit in de smoothed versie van p op x = (u, v)T. De BRIEF descriptor is een nd-dimensionale bit-string gedefinieerd door nd binary tests.
Voor dat de tests voor het maken van de descriptor worden uitgevoerd wordt de patch gesmoothd. Dit wordt gedaan omdat bij de tests alleen wordt gekeken naar enkele pixels hierdoor zijn de test gevoelig voor ruis. Door het smoothen van de patch wordt dit effect verminderd. Voor het smoothen wordt gebruikt gemaakt van een Gaussian kernel.
Voor de tests moet nog bepaald worden welke locaties xi, yi binnen een patch gebruikt zullen
worden. Dit wordt gedaan door middel van een normaal verdeling, N (0,251S2).
Om BRIEF invariant te maken tegenover rotatie wordt BRIEF gestuurd aan de hand van de ori¨entatie van de keypoints. Er wordt een 2xn matrix opgesteld aan de hand van n binaire testen op locatie (xi, yi) .
S =x1, ..., xn y1, ..., yn
Door de patch ori¨entatie θ en de corresponderende rotatie matric te gebruiken kan er een gestuurde versie van S worden geconstrueerd. Hiermee staat de BRIEF operator gelijk aan gn(P, θ) := fn(p|(xi, yi) ∈ Sθ.
De hoek wordt elke keer met 12 graden verhoogd. Er wordt een lookup table geconstrueerd waarin vooraf berekende BRIEF patronen staan. Zo wordt er bepaald welke set van punten Sθ
wordt gebruikt voor het berekenen van de descriptor.
Het gebruik van de steered BRIEF zorgt voor een verlies in variantie. Om dit tegen te gaan moet er worden gezocht naar een goede subset van de binaire testen. Er wordt tussen all binaire tests gezocht naar testen met een hoge variantie, een mean in de buurt van 0.5 en die uncorrelated zijn.
3.1.4
Vergelijking en keuze
Om de verschillende keypoint detectie en descriptor algoritme met elkaar te kunnen vergelijken zijn er een aantal eisen opgesteld waaraan het algoritme moet voldoen om gebruikt te kunnen worden in spoorzoekertje. Deze vereisten zijn:
1. Snel: In de app moet in real-time gebruik gemaakt kunnen worden van de methode, dit houdt in dat in real-time berekend moet kunnen worden of de huidige frame wel of niet de juiste locatie is om het object te plaatsen. ALs dit niet real-time gebeurt kan het zijn dat de speler al met zijn mobieltje voorbij het punt is waar een object geplaatst zou moeten worden, wanneer het algoritme detecteert dat het object geplaatst moet worden. De app loopt dan achter op de werkelijkheid en zal te laat het object plaatsen waardoor deze op een verkeerd punt wordt teruggezet. Het algoritme wordt gezien als snel wanneer deze in real-time gebruikt kan worden. Wanneer wordt uitgegaan van 60fps zou dit betekenen je 16.67 ms per frame hebt voor het berekenen. Wanneer deze snelheid wordt bereikt is het algoritme snel genoeg.
2. Nauwkeurig: Dit houdt niet in dat op de mm het object op de juiste positie moet worden teruggezet. Wanneer een object een klein beetje is opgeschoven heeft dit geen invloed op de hint. Wel moet het algoritme robuust zijn. Het algoritme mag niet op een verkeerde plek denken dat de positie de juiste is en het object op een verkeerde plek plaatsen. Hierdoor zou de hint verkeerd begrepen worden en gaan de spelers een andere kant op dan de bedoeling was. Dit probleem wordt deels al verminderd doordat we rekening houden met de locatie van de speler. Er wordt alleen gezocht naar waar het object geplaatst moet worden wanneer de speler in de buurt is van de hint. Echter willen we nog steeds niet dat het object bijvoorbeeld aan de verkeerde kant van de straat wordt geplaatst. Een object is nauwkeurig geplaatst wanneer het in de juiste ori¨entatie staat ten opzichte van de speler en op de juiste positie zodat de hint correct wordt begrepen.
3. Licht algoritme: Als derde moet het algoritme niet al te zwaar zijn. Het algoritme wordt gerund op een mobiele telefoon. Wanneer het algoritme te zwaar is zal deze snel de batte-rijen leeg trekken en misschien zelfs wel het mobieltje laten oververhitten of de app laten vastlopen.
4. Invariant onder verschillende waardes van lichtintensiteit: Als laatste moet het algoritme invariant zijn onder verschillende waardes van lichtintensiteit. Het spel wordt buiten ge-speeld en het uitzetten van het spoor hoeft niet op de zelfde dag te gebeuren als wanneer het spel wordt gespeeld. Hierdoor kan het zo zijn dat het weer op deze dagen verschilt van elkaar. Het kan de ene dag heel zonnig zijn geweest en de volgende dag bewolkt. Het spel moet onder deze omstandigheden nog steeds gespeeld kunnen worden. Het algoritme wordt als invariant tegenover veranderingen in lichtintensiteit beschouwd wanneer onder verschillende waardes voor lichtintensiteit dezelfde keypoints worden gevonden en correct gematcht.
Tabel 3.1: vergelijking SIFT, SURF en ORB
SIFT SURF ORB
Snel 7 7 3
Nauwkeurig 3 3 3
Invariant onder
lichtintensiteit 3 3
-Licht algoritme - -
-In tabel 3.1 worden SIFT, SURF en ORB vergeleken in de vier eerder benoemde eisen. De checkmarks geven aan dat het algoritme voldoet aan de eis en de kruisjes geven aan dat dit niet zo is. Het streepje betekent dat het niet in de literatuur is gevonden.
In het onderzoek naar ORB staat een tabel met een vergelijking in snelheid tussen SIFT, SURF en ORB. Het gaat om de snelheid voor het detecteren en berekenen van de keypoints per frame. Hieruit blijkt dat ORB dit in 15.3 ms kan, SURF in 217.3 ms en SIFT in 5228.7 ms. Wanneer wordt gekeken naar een mogelijkheid voor een real-time werkend algoritme komen zowel SIFT als SURF niet in de buurt van 16.7 ms. In dezelfde paper staat ook de snelheid van ORB aangegeven op een mobiele telefoon. Op een mobiele telefoon duurt het 66 ms voor ORB om keypoints te kunnen detecteren en berekenen. Dit is al een stuk langzamer, maar wanneer bijvoorbeeld niet alle frames worden meegenomen maar tussendoor een aantal frames worden overgeslagen kunnen hiermee nog steeds realtime features in een afbeelding worden gevonden.
Karami et al hebben onderzoek gedaan naar de performance van SIFT, SURF en ORB in ver-vormde afbeeldingen [8]. Uit dit onderzoek is gebleken dat ORB het snelste algoritme is en de performance van SIFT in de meeste gevallen het beste is. Echter is de performance van SURF en ORB beter bij rotatie van 90 graden of een veelvoud hiervan en is de performance van SIFT en ORB ongeveer gelijk bij afbeeldingen met veel ruis. Uit het onderzoek kan gehaald worden dat alle drie de algoritmes de performance goed genoeg is om te gebruiken in spoorzoekertje. Zowel in de papers van SIFT als SURF wordt aangegeven dat ze features juist kunnen matchen onder verschillende waardes van lichtintensiteit. De feature vectoren van SIFT zijn invariant onder affiene veranderingen in verlichting en invariant tegenover camera verzadiging en verande-ring in verlichtingen die effect hebben op oppervlakken van 3D objecten. Door het gebruik van wavelet responses is SURF invariant tegenover veranderingen in verlichting.
Voor de implementatie is gekozen voor het gebruik van ORB. ORB kan gebruikt worden voor realtime applicaties, SIFT en SURF bieden hier geen mogelijkheid toe. De nauwkeurigheid voor feature matching van ORB is niet zo goed als SIFT, maar goed genoeg om te kunnen gebruiken voor de spoorzoekertje app. Over de performance van SURF onder variantie in lichtintensiteit kan nog geen uitspraak worden gedaan. Dit zal later in deze paper getest worden.
3.2
Feature matching
In de app worden twee beelden met elkaar vergeleken om te kijken of we op de locatie van een hint zijn. Hierbij worden de berekende features uit beide afbeeldingen met elkaar vergeleken. Voor het matchen worden de descriptors van de features aan elkaar gematcht. Voor het matchen wordt gebruikt gemaakt van de Hamming distance tussen de descriptors [13]. De Hamming dis-tance wordt berekend door te kijken hoeveel twee descriptors van elkaar verschillen. Met andere woorden er wordt gekeken hoeveel stappen nodig zijn om de ene descriptor om te zetten in de ander.
Voor het matchen van de descriptors uit de twee afbeeldingen wordt gebruik gemaakt van een Brute-Force Matcher. Deze Brute-Force matcher pakt een descriptor van de eerste afbeelding
en matched deze met alle descriptors uit de tweede afbeelding. Tussen elke match wordt de Hamming distance bepaald. Het bepalen van de Hamming distance gebeurt door middel van een bitwise XOR operatie tussen de twee descriptors. De descriptor uit de eerste afbeelding wordt gematcht aan de descriptor uit de tweede afbeelding waartussen de Hamming distance het laagst was. Dit wordt gedaan totdat elke descriptor uit de eerste afbeelding is gematcht aan een descriptor uit de tweede afbeelding.
3.3
Positie transformatie
De laatste stap voor het correct plaatsen is het transformeren van de originele positie van het object, wanneer deze is geplaatst, naar de nieuwe positie. Dit is om te zorgen dat het object op dezelfde positie in de werkelijkheid terecht komt. Om dit te verwezenlijken wordt gekeken naar een transformatie die de afbeelding van de originele locatie transformeert naar de afbeelding van de nieuwe locatie. Hieruit komt een matrix die gebruikt wordt op het object om deze te transformeren. Gekeken is naar het gebruik van twee verschillende transformeer matrices.
3.3.1
Affiene transformatie
Een affiene transformatie is een transformatie waarbij de meetkundige structuur hetzelfde blijft. Dit houdt in dat na transformatie punten, lijnen en vlakken nog steeds punten, lijnen en vlakken zijn. Ook zijn twee evenwijdige lijnen na de transformatie nog steeds evenwijdig aan elkaar. Een affiene transformatie kan bestaan uit een translatie, rotatie, shearing, schaling of een combinatie van deze vier. Figuur 3.2 laat deze vier verschillende transformaties zien.
Figuur 3.2: Affiene transformatie
Bron:http://nl.swewe.net/word_show.htm/?17548_1&Affiene_transformatie De matrix die bij deze affiene transformatie hoort is als volgt.
a b tx c d ty 0 0 1
Hierbij staan txen tyvoor de translatie en de matrix
a b c d
geeft de rotatie, schaling en shearing aan. De transformatie wordt uitgevoerd door de affiene transformatie matrix te vermenigvuldi-gen met een puntx y 1T
. Aan zowel het punt als aan de matrix is een homogeen co¨ordinaat toegevoegd. Het homogene co¨ordinaat is nodig om de translatie over het punt uit te kunnen voe-ren.
De affiene matrix kan gebruikt worden om een afbeelding te transformeren op een andere afbeel-ding. Hierbij wordt een puntx y 1T
getransformeerd naar een punt in een nieuw co¨ordinaten stelselx0 y0 1. Om de affiene matrix te kunnen berekenen moet er van minimaal drie punten
bekend zijn hoe deze vanaf de eerste afbeelding getransformeert zouden moeten worden naar de tweede afbeelding.
De bereking van de originele co¨ordinaten naar de nieuwe co¨ordinaten kan worden herschreven. Voor een punt ziet de berekening er als volgt uit.
x0 i y0i =xi yi 1 0 0 0 0 0 0 xi yi 1 a b tx c d ty
Deze berekening kan ook uitgeschreven worden voor 3 punten. Voor elk extra punt dat wordt toegevoegd aan de matrix komen er twee nieuwe co¨ordinaten bij aan de linker kant van de berekening en twee nieuwe rijen in de matrix. Deze berekening kan ook worden geschreven als q = M p. Hiermee kan de vector p worden berekend, p = M−1q. Het is lastig om drie paren van punten te vinden die precies op elkaar transformeren. Hierdoor kan de berekende vector p inaccuraat zijn. Om dit tegen te gaan wordt de kleinste-kwadraten oplossing van p bepaald. De kleinste-kwadraten methode zoekt naar de oplossing waarbij het verschil in het kwadraat tussen de daadwerkelijke data en de verwachte data zo klein mogelijk is. De uiteindelijke berekening van p is p = (MTM )−1MTq . De berekende vector kan dan worden herschreven als de matrix
voor de affiene transformatie.
3.3.2
Homografie transformatie
Homografie transformatie wordt ook wel perspectief transformatie genoemd. Een Homografie transformatie is een transformatie tussen twee vlakken. Hierbij kan elk punt van het ene vlak getransformeerd worden naar het andere vlak. Net zoals bij de affiene transformatie kan een ho-mografie transformatie bestaan uit een translatie, rotatie, schaling en shearing. In tegenstelling tot de affiene transformatie hoeven evenwijdige lijnen niet evenwijdig aan elkaar te blijven. Een homografie matrix kan gebruikt worden om 3D objecten in een 2D omgeving te plaatsen. Een homografie transformatie kan gebruikt worden om een afbeelding of object in 3D te trans-formeren. Hierdoor komt er perspectief in de afbeelding. Punten op de afbeelding die verder weg zijn worden kleiner gemaakt. De homografie transformatie wordt als volgt berekend.
s x0 y0 1 = a b c d e f g h i x y 1
Hierin is s de schaal factor. De berekening kan worden herschreven naar x0= ax + by + c
gx + hy + iy
0= dx + ey + f
gx + hy + i Wat weer kan worden herschreven als
x y 1 0 0 0 −x0x −x0y −x0 0 0 0 x y 1 −x0x −x0y −x0 a b c d e f g h i =0 0
Net zoals bij de affiene matrix kunnen extra punten worden toegevoegd aan de vectorx0i yi0T en aan de matrix. Om de homografie transformatie te kunnen berekenen zijn vier of meer pun-ten nodig. De vergelijking kan ook geschreven worden als M p = 0. Door het oplossen van deze vergelijking kan de homografie matrix bepaald worden. Wanneer er meer dan 4 punten worden gebruikt wordt gezocht naar de homografie matrix met de beste fit.
HOOFDSTUK 4
Implementatie
Voor de implementatie is gebruik gemaakt van OpenCV en C++ voor het implementeren van het ORB algoritme en de feature matching [4]. Unity en Vuforia zijn gebruikt voor het implementeren van de front-end, de camera en het plaatsen van objecten.
4.1
Algemene implementatie
Algorithm 1 Algemene implementatie spoorzoekertje
1: while true do
2: LatLon pos = GetLocation()
3: obj [ ] = objs = GetObject(pos, radius, database)
4: feat [ ] features = GetFeatures()
5:
6: for all Obj in objs do
7: isMatch = MatchFeature(Obj.feature, features)
8:
9: if isMatch then
10: Transform [ ][ ] posture = GetPosture(Obj.feature, features, Obj)
11: DrawObject(Obj, posture)
In de pseudocode 1 wordt aangegeven hoe de de positie bepaling en object plaatsing samen wer-ken in de uiteindelijke applicatie. Eerst zal in de applicatie worden bekewer-ken wat de locatie is van de speler. Met behulp van deze locatie wordt naar alle objecten gezocht die in een bepaalde range vanaf de speler zijn. Deze objecten worden uit de database gehaald en in een lijst geplaatst. Vervolgens worden van het huidige camera beeld de features berekend. Over alle objecten wordt ge¨ıtereerd. In elke iteratie worden de features van het huidige camera beeld gematcht aan de features van de hint. Wanneer de hint een match is wordt bepaald hoe het object geplaatst moet worden en zal deze aan de hand van die gegevens getekend worden.
Elke feature is opgebouwd uit een keypoint en de bijbehorende descriptor. Elk object en camera beeld is opgebouwd uit meerdere features.
Een object is als volgt opgebouwd: 1. id
2. LatLon positie 3. type
Elk object heeft een uniek id waarmee deze kan worden onderscheiden van de rest. Elk object heeft een positie waarop deze zich bevind in de werkelijke wereld. Verder heeft elk object een type die aangeeft wat voor soort object moet worden geplaatst. Als laatste wordt aan elk object een route id gekoppeld. Deze geeft aan of het object zich in de huidige route bevind.
4.2
Feature detectie en matching
De afbeeldingen die nodig zijn voor feature detectie worden vanuit Vuforia en Unity doorgestuurd naar C++. Hiervoor worden de afbeeldingen verkregen vanaf de Vuforia AR camera omgezet in bytes. Deze bytes worden aan een C++ functie als pointer meegeven. In C++ worden deze bytes weer omgezet naar een afbeelding.
Voor het detecteren en berekenen van ORB features en het matchen van de features is gebruik gemaakt van functies uit de OpenCV library. Het matching algoritme in openCV matcht alle gevonden features uit twee afbeeldingen zo goed mogelijk aan elkaar. Dit betekent dat veel matches niet correct zullen zijn. Om te bepalen of matches correct zijn wordt gekeken of de Hamming distance boven een bepaalde threshold ligt.
Figuur 4.1: Distance distributie van inliers en outliers in het ORB algoritme
Figuur 4.1 geeft een distributie van de afstand voor gevonden matches. Hierbij geven de door-getrokken lijnen de distributie voor inliers weer en de stippelijnen de distributie voor outliers. Wanneer correct tussen twee afbeeldingen een punt wordt gematcht wordt deze als inlier gezien. Wanneer twee verkeerde punten op de afbeelding wordt gematcht is het een outlier. Hiervan is rBRIEF het gebruikte algoritme in ORB. Uit dit figuur kan gehaald worden dat bij een afstand lager dan 80 de kans groter is dat de match een inlier is, dan de kans dat deze een outlier is. In de implementatie is gekozen om alleen de matches te nemen die een afstand van 48 of lager hebben. Bij een threshold van 48 is de kans dat een match een outlier is verwaarloosbaar klein. Er wordt door de lijst van matches gelopen en voor elke match wordt gekeken naar de Hamming distance. Wanneer de Hamming distance lager dan 32 is, wordt de match in een lijst van cor-recte matches geplaatst. De kans bestaat dat nog steeds incorcor-recte matches in de lijst staan. Om hier rekening mee te houden wordt er een threshold bepaald. Deze threshold geeft aan hoeveel correcte matches moeten bestaan voordat de afbeeldingen als een match worden beschouwd. In figuur 4.2 is naar het aantal gevonden matches per frame gekeken. Deze test is gedaan met behulp van een opgenomen video. Voor het maken van een video is een kort stukje over straat
gelopen waarbij de beelden zijn opgenomen. Uit deze video zijn een aantal frames gehaald om mee te testen. Deze frames staan in appendix A.1. Uit deze data kan gehaald worden dat een threshold van 75 gekozen kan worden voor het minimaal aantal matches wat nodig is om aan te geven dat een beeld een match vormt met de afbeelding. Er is bij de grafiek nog een kleine afwijkende piek te zien, deze piek wordt veroorzaakt doordat er een moment is waarbij een deel van de auto van frame 100 ook hier te zien is.
Figuur 4.2: Aantal gevonden matches met een Hamming distance groter dan 48 per frame gematched tegenover een frame genomen vanaf de afbeelding
4.3
Object plaatsing
Het plaatsen van een object gebeurt door middel van unity [17]. Elk object in unity heeft een transform waarmee de positie, rotatie en schaling worden aangegeven. De positie, rotatie en schaling hebben elk een X, Y en Z waarde. Wanneer een object verplaatst wordt in unity wordt dat gedaan door deze waarde aan te passen.
In C++ worden met behulp van een OpenCV functie de transformatie matrixen bepaald. Voor het plaatsen van de 3D objecten in unity wordt deze transformatie uitgevoerd over de positie van het object op moment van plaatsen. Om deze transformatie in unity uit te kunnen voeren zijn apart de translatie, rotatie en schaling van het object nodig. Hiervoor moeten de transformatie matrixen worden ontbonden.
Het is niet mogelijk om een affiene matrix te ontbinden. De translatie kan makkelijk uit de trans-formatie matrix worden gehaald. De rest van de matrix is een vermenigvuldiging van rotatie, schaling en shearing, waarbij niet terug te halen valt wat de waarde van de originele matrixen waren. Hierdoor kan een affiene matrix niet worden gebruikt voor een transformatie in unity. Voor het decomposeren van de homography matrix bestaat een functie in OpenCV. Deze functie ontbind de homography matrix in een rotatie matrix en translatie vector. Hoe de homografie matrix wordt ontbonden wordt omschreven in het onderzoek van E. Malis, M.Vargas en anderen
[10]. Om deze matrix te kunnen ontbinden moet de intrinsic camera matrix worden meegegeven aan de OpenCV functie.
fx 0 cx 0 fy cy 0 0 1
Hierbij zijn fxen fy de brandpuntafstanden tot de camera en cxen cyhet optische midden punt.
Het optisch midden punt kan worden bepaald door het midden punt van de afbeelding in pixels te nemen. cx= f rameW idth/2 en cy= f rameHeight/2. De brandpuntafstanden kunnen worden
bepaald met behulp van de field of view hoeken. Deze waarden kunnen verkregen worden met behulp van de Vuforia camera. De waarde van de field of view hoeken worden aangegeven door axen ay. De brandpuntsafstanden kunnen als volgt worden berekend:
fx= cx/tan(ax/2)
fy= cy/tan(ay/2)
Uit de ontbonden homografie transformatie komen vier mogelijke combinaties van translatie vectoren en rotatie matrixen. Uit deze combinaties moet vervolgens nog worden bepaald welke de correcte transformatie is. Hoe dit kan worden bepaald staat omschreven in het onderzoek van E. Malis, M. Vargas en anderen.
4.4
Database
Om de gegevens voor spoorzoekertje tussen verschillende sessies te kunnen gebruiken worden deze opgeslagen in een database. Figuur 4.3 geeft aan hoe de database is opgebouwd. Voor het spel spoorzoekertje wordt een route uitgezet. Elke route bestaat uit een uniek id, een naam en een moeilijkheidsgraad. Langs de route kunnen hints worden geplaatst. De hints bevatten een locatie met een latitude en longitude waar deze zich in de werkelijke wereld bevinden. Verder bevat het een type die aan geeft wat voor een object is geplaatst. Als laatste wordt de positie, rotatie en schaling van het object in de virtuele wereld opgeslagen. Positie, rotatie en schaling omvatten allemaal drie verschillende rijen in de tabel met een x, y en z waarde. In figuur 4.3 wordt dit aangegeven als een rij met een x, y en z waarde erin. Bij het plaatsen van een object worden de features van de frame op moment van plaatsen berekend. Deze features worden elk in een eigen tabel opgeslagen. Aan elke feature wordt een descriptor en keypoint gekoppeld.
HOOFDSTUK 5
Experimenten
Verschillende experimenten worden uitgevoerd voor het testen van ORB. Deze experimenten zijn gericht op de eisen genoemd in sectie 3.1.4. Er worden op drie verschillende gebieden experimen-ten uitgevoerd. Het eerste experiment kijkt naar de snelheid van de feature detectie en matching op een mobiele telefoon. Het tweede experiment kijkt naar de nauwkeurigheid van ORB. Hierbij wordt gekeken of voor de correcte frames wordt aangegeven dat een match is gevonden. Als laatste experiment wordt er gekeken naar de robuustheid van ORB onder verschillende waardes voor lichtintensiteit.
In de implementatie wordt een match toegestaan wanneer 75 of meer matches zijn gevonden met een Hamming distance lager dan 48. Alle frames met minder dan 75 keypoints zullen hierdoor nooit als match gezien worden. Deze zullen dan ook niet worden meegenomen in de experimenten.
5.1
Snelheid
Om te bepalen of ORB snel genoeg is om gebruikt te worden in AR wordt gekeken naar de snel-heid van het algoritme. Hiervoor wordt de snelsnel-heid gemeten voor het detecteren en berekenen van de features en het matchen van de gevonden features. Door deze twee snelheden samen te bekijken kan bepaald worden of ORB real time gebruikt kan worden op een mobiele telefoon. Deze testen worden uitgevoerd op een Samsung galaxy S7.
Voor het uitvoeren van het experiment is gebruik gemaakt van een live applicatie op de mobiele telefoon. Bij het opstarten van de applicatie worden de features uit het eerste frame berekend en opgeslagen in de applicatie. Deze frame wordt gezien als het frame waarin een object is geplaatst. Uit elk volgend frame worden vervolgens de features berekend. Deze features worden gematcht net de opgeslagen features in de applicatie. Van elk frame wordt de snelheid voor het berekenen van features bepaald en de snelheid van het matchen van deze gevonden features.
5.2
Nauwkeurigheid
In het experiment voor nauwkeurigheid wordt gekeken naar de robuustheid van de features die door ORB worden berekend. Hierbij wordt gekeken of het ORB algoritme op het juiste moment aangeeft dat een match is gevonden. Hierbij wordt gekeken of op het juiste moment een frame wordt gedetecteerd als locatie voor het plaatsen van een object.
Voor de uitvoering van het experiment is een video opgenomen waarbij een stuk over straat wordt gelopen. Hierbij wordt nagebootst hoe een speler om zich heen zal kijken op zoek naar hints. Van hetzelfde gelopen stuk zijn foto’s gemaakt als locaties waar hints zich bevinden. Deze foto’s zijn terug te vinden in appendix A.2. Deze foto’s zijn gedownscaled van een resolutie van
4032x3024 naar een resolutie van 1920x1080.
De video wordt frame voor frame uitgelezen en gematcht tegenover elke foto. Voor elk frame wordt bepaald hoeveel matches er zijn gevonden en of dit een match is. Met behulp van deze informatie kan worden gekeken of op het verwachte moment een match wordt aangegeven.
5.3
lichtintensiteit
Bij het experiment voor lichtintensiteit wordt gekeken naar de robuustheid van ORB onder ver-schillende waardes voor lichtintensiteit. Het doel van dit experiment is om te onderzoeken of afbeeldingen van dezelfde locatie onder een andere lichtintensiteit nog steeds juist aan elkaar gematcht worden.
Het experiment voor de lichtintensiteit is opgesteld in een donkere kamer waar zich een dimlicht bevindt. Hierbij wordt een korte video opgenomen door een mobiele telefoon die zich in een stabiele positie bevind. Aan het begin van het filmen stond het dimlicht volledig aan. Langza-merhand wordt het licht steeds lager gezet waarmee de lichtintensiteit vermindert. Uit de video worden drie frames gekozen als hint locaties. Deze frames staan in appendix A.3. Hiermee wordt gekeken of de lichtintensiteit van het moment van plaatsen invloed heeft op hoe deze zal worden gematcht. Frame A.12 is het middelste frame uit de video. Hierbij is het middelste frame gekozen zodat deze in het midden ligt tussen frame 0 en de laatste frame waarbij 75 keypoints of meer zijn gedetecteerd. Met behulp van deze frame wordt gekeken of een frame beter wordt gematcht met hoger of lagere waardes voor lichtintensiteit.
Voor het experiment worden de gekozen frames gematcht tegenover alle frames uit de video. Voor elk frame wordt gekeken naar het aantal gevonden matches en of ze als match worden herkend.
HOOFDSTUK 6
Resultaten
6.1
Snelheid
In tabel 6.1 staan verschillende tijds metingen voor feature detectie en feature matching. Hierin is te zien dat feature detectie en feature matching per frame gemiddeld ongeveer even snel zijn. Feature matching is met zijn langzaamste meting 10 ms langzamer dan feature detectie. Wanneer naar de snelste tijd wordt gekeken liggen feature detectie en feature matching dicht bij elkaar. Wanneer een frame met 0 keypoints wordt megenomen is dit voor beide 2 ms. Wanneer 0 niet wordt meegenomen is feature matching 1 ms langzamer dan feature detectie. Hieruit is op te merken dat de snelheid van feature matching een wijdere range omvat dan feature detectie.
Figuur 6.1 geeft de snelheden van feature detectie en feature matching weer tegenover het aantal keypoints per frame. Hieruit valt op dat zowel bij feature detectie als bij feature mat-ching er een stijgende lijn te zien is. Bij een hoger aantal keypoints in een frame worden feature matching en feature detectie langzamer.
Tabel 6.1: Gemiddelde snelheid, snelste tijd en langzaamste tijd van feature detectie en feature matching Gemiddelde tijd (ms) per frame Snelste tijd (ms) #keypoints = 0 Snelste tijd (ms) #keypoints >0 Langzaamste tijd (ms) Feature detectie 23.39 2 19 44 Feature matching 25.80 2 20 54
6.2
Nauwkeurigheid
Figuur 6.3 laat het aantal matches van de genomen foto zien tegenover alle frames uit het filmpje. Bij alle matches is de Hamming distance lager dan 48. De gebruikte foto’s staan in appendix A.2. Uit het figuur is af te lezen dat nergens meer dan 75 matches zijn gevonden tussen een foto en frame. Dit houdt in dat geen van de foto’s is gematcht met een frame uit het filmpje. Wel valt op dat foto 1 een piek heeft bij de laatste frames en foto 3 heeft een piek bij de eerste frames. Bij zowel foto 2 als foto 4 zijn geen duidelijke pieken te zien.
Figuur 6.1: Tijd in ms voor het detecteren van keypoints tegenover het aantal keypoints in een frame
Figuur 6.2: Tijd in ms voor het matchen van features tegenover het aantal keypoints in een frame
6.3
Lichtintensiteit
Figuur 6.4 geeft het aantal keypoints weer per frame. Hierbij heeft het eerste frame de hoogste lichtintensiteit. De lichtintensiteit neemt bij elke frame af. Uit dit figuur is af te lezen dat bij een lagere lichtintensiteit het aantal gevonden keypoints in het frame afneemt. Vanaf frame 245 worden er geen keypoints meer gedetecteerd. Het valt op dat het aantal keypoints per frame bij frame 140 weer omhoog gaat. Vanaf frame 190 daalt het aantal keypoints weer.
Tabel 6.2 geeft de range van frames weer die werden gevonden als match voor elke frame. De gebruikte frames hiervoor staan in appendix A.3. Hieruit valt op dat voor zowel frame 0 als frame 106 een groot aantal frames als match zijn gevonden. Frame 212 heeft alleen een match met zichzelf en wordt niet gematcht met een ander frame.
Figuur 6.3: Aantal matches met een Hamming distance lager dan 48 per foto tegenover elke frame in de video
Figuur 6.4: Aantal keypoints per frame waarbij de lichtintensiteit per frame afneemt frame 0 frame 106 frame 212
range gematchte frames 0-192 0-197 199-201 204 212
Tabel 6.2: De range van gevonden matches voor de frames 0, 106 en 212
dit figuur is af te lezen dat voor frame 0 het aantal gevonden matches per frame afneemt. Voor frame 106 is het aantal matches met een hogere lichtintensiteit bijna stabiel. Bij een lager licht-intensiteit neemt het aantal gevonden matches af. Voor frame 212 neemt het aantal matches toe wanneer de lichtintensiteit afneemt.
6.4
Verwerking resultaten
Aan de hand van de gevonden resultaten zal bepaald worden of ORB geschrikt is om te gebruiken in spoorzoekertje. In de discussie zullen deze resultaten nader verklaard worden. En zal gekeken
Figuur 6.5: Aantal matches per frame waarbij de lichtintensiteit per frame afneemt
HOOFDSTUK 7
Discussie
In tabel 6.1 staan de snelheden van feature detectie en feature matching. Gemiddeld kost het 23.39 ms voor feature detectie en 25.80 ms voor feature matching. Samen kost het ongeveer 50 ms per frame. Wanneer wordt uitgegaan van 60 frames per seconde, 16.7 ms per frame is dit niet snel genoeg. In het echt zal dit gemiddelde waarschijnlijk nog wat hoger liggen. Wanneer overdag buiten spoorzoekertje wordt gespeeld zal het bijna niet voorkomen dat maar geen of enkele matches zullen worden gevonden. Wanneer enkele frames worden overgeslagen zal het algoritme wel in real-time gebruikt kunnen worden. Hierbij wordt de aanname gemaakt dat het verschil tussen twee frames klein genoeg is om ervan uit te gaan dat niet niet gekeken hoeft te worden naar het plaatsen of verplaatsen van het object in het frame.
Uit figuur 6.3 valt te halen dat tussen alle foto’s uit appendixapd:1 minder dan 75 matches zijn gevonden. Dit betekend dat geen foto is aangegeven als een correcte match. Foto 3 heeft een piek aan het begin van de grafiek met 68 matches. Hier was ook verwacht dat deze foto gematcht zou worden. Deze zou correct gematcht worden wanneer de treshold voor het minimaal iets omlaag gehaald zou worden. De andere drie foto’s laten geen duidelijke pieken zien van posities waar deze gematcht zouden moeten worden. Dit zou kunnen komen doordat de foto’s net vanuit een andere hoek zijn genomen dan dat er met de video langs is gelopen en daardoor niet cor-rect gematcht konden worden. Bij foto 1 was verwacht dat wel een corcor-recte match zou worden gevonden omdat deze bijna zo voorkwam in de video. Deze resultaten waren ook onverwacht doordat in figuur 4.2 dezelfde video is gebruikt. Hier werden in de frames rondom de gekozen afbeelding uit de video wel veel matches gevonden. Hieruit kan geconcludeerd worden dat ORB niet nauwkeurig genoeg is in het matchen van de juiste afbeeldingen.
Bij de experimenten van nauwkeurigheid is gebruik gemaakt van afbeeldingen met een resolutie van 4032x3024 die zijn gedownscaled naar een resolutie van 1920x1080. Hierbij veranderen de verhoudingen van een foto van 4:3 naar 16:9. Deze downscaling kan tot gevolg hebben de ge-vonden keypoints verschillen van de keypoints uit de frames. Waardoor deze minder goed met elkaar worden gematcht.
Bij de experimenten voor nauwkeurigheid is ontdekt dat de resolutie van de afbeeldingen uit-maakt voor hoe goed deze matchen met elkaar. Bij de experimenten had de video een resolutie van 1920x1080 en de foto’s een resolutie van 4032x3024. Uit deze testen kwam ook als resultaat dat geen van de foto’s matcht met de frames uit de video. Hierbij werden geen pieken waarge-nomen bij foto 3.
Een oplossing voor het probleem rondom de nauwkeurigheid zou kunnen zijn, een kleiner deel van de foto te pakken die beter weergeeft waar het object zich bevind. Dit zorgt ervoor dat veel van de omgeving minder effect heeft op het vinden van de keypoints en het correct matchen. Hierdoor match je alleen nog maar het gedeelte waar het object daadwerkelijk staat in plaats van dat ook nog de omgeving van het object gematcht probeert te worden. Dit zou een hogere
nauwkeurigheid kunnen opleveren.
Een andere oplossing zou kunnen zijn om te kijken naar het percentage van correcte matches tussen twee afbeeldingen in plaats van te kijken naar een bepaalde hoeveelheid. Wanneer maar weinig features in een beeld worden gevonden is het lastiger om aan 75 matches met een bepaalde Hamming distance te komen. Wanneer wordt gekeken naar de verhouding van matches met een Hamming distance kleiner dan 48 en het totaal aantal matches kan dit probleem verholpen wor-den. Dit kan ervoor zorgen dat matches nauwkeuriger worden gevonwor-den.
Met een lage nauwkeurigheid zal het beter zijn om het object niet constant opnieuw te tekenen. Wanneer een speler op de juiste locatie staat waarop een hint locatie wel wordt herkend maar vervolgens net iets verplaatst en daardoor niet meer wordt herkend zal het object even in beeld springen en daarna weer verdwijnen. De huidige feature matching is hier niet stabiel genoeg voor. Een oplossing hiervoor zou kunnen zijn om een object maar een keer te tekenen en ver-volgens op een andere manier het object op zijn plek te houden. Bijvoorbeeld door te kijken naar de positie van de speler in de wereld en te kijken hoe deze ten opzichte tot het object beweegt. Figuur 6.4 laat het aantal keypoints per frame zien. Hierbij valt op dat vanaf frame 245 geen keypoints meer worden gevonden. Dit komt waarschijnlijk omdat vanaf dit punt de afbeeldingen te donker worden en er geen duidelijke randen meer worden gevonden. Dit geeft aan dat ORB feature matching niet zal werken in het donker. ORB kan alleen gebruikt worden wanneer het spel gespeeld wordt met een hogere lichtintensiteit. Uit figuur 6.2 valt op dat frame 212 alleen met zichzelf matched. In frame 212 werden precies 75 keypoints gedetecteerd. Doordat deze 75 keypoints met geen enkel andere frame precies matchen kan worden geconcludeerd dat verschillen ontstaan in de gevonden keypoints bij verschillende waardes van lichtintensiteit.
Wanneer wordt gekeken naar het aantal matches tegenover het afnemen van de lichtintensiteit valt frame 106 op in figuur 6.5. Hierbij is te zien dat wanneer de lichtintensiteit hoger wordt het aantal matches ongeveer stabiel blijven. Bij het afnemen van de lichtintensiteit neemt het aantal matches sterk af. Dit zou veroorzaakt kunnen worden doordat bij afbeeldingen met een lagere lichtintensiteit minder features worden gevonden. Dit kan tot gevolgen hebben dat ook minder features worden gematcht.
Verder zijn er nog een paar aspecten aan feature matching waar naar gekeken zal moeten worden voor verdere experimenten. Wanneer iemand vanaf de achterkant van de hint komt aanlopen zal deze niet geplaatst worden, omdat in het beeld geen features herkend zullen worden. Dit komt doordat dit beeld niet overeenkomt met het beeld waar features uit zijn gehaald. Hierdoor worden de hints niet op deze locatie geplaatst en kunnen hints gemist worden door spelers. Een oplossing hiervoor zou zijn om de hint locatie vanuit meerdere camera punten op te slaan in de database. Dit is geen optimale oplossing, omdat hierdoor de persoon die het pad instelt dit constant voor elke hint zou moeten doen. Daarnaast zullen meer features met elkaar gematcht moeten worden waardoor de applicatie langzamer wordt.
Een ander probleem kan ontstaan door het verschil in tijd van het uitzetten van het spoor en het spelen. In de verstreken tijd kan het zo zijn dat de opgeslagen locaties niet meer hetzelfde eruit zien. Voorbeelden van mogelijke veranderingen zijn auto’s die zijn verplaatst, plekken waar iets nieuws is gebouwd of juist iets is weggehaald. Door deze veranderingen kan het zijn dat de loca-tie niet meer op het juiste moment wordt gematcht en hierdoor hints niet meer worden geplaatst.
HOOFDSTUK 8
Conclusie
ORB bevat de functionaliteiten om gebruikt te worden in spoorzoekertje als wordt gekeken naar de snelheid en robuustheid onder lichtintensiteit. Wanneer vanuit gegaan wordt dat spoor-zoekertje alleen overdag gebruikt zal worden met voldoende lichtintensiteit. Als het gaat om nauwkeurigheid kan ORB niet gebruikt worden. Bij kleine veranderingen in het beeld worden deze nog correct gematcht. Wanneer de foto niet volledig genoeg overeen komt met de video zal deze niet gematcht worden en zullen veel hints niet worden geplaatst. Op mijn onderzoeksvraag: ”Wat is een geschikte methode voor het plaatsen van een virtueel object in AR waarbij zijn positie behouden blijft ten opzichte van de werkelijke wereld?” is dan ook nog geen duidelijk antwoord op te geven.
Voor ORB moet nog gekeken worden of deze nauwkeuriger wordt bij het aanpassen van de thres-holds voor de Hamming distance en het minimale aantal matches dat gevonden moet worden. In mijn implementatie is ook de waarde voor de scaleFactor aangepast van 1.2f naar 2.0f. Dit maakt ORB sneller maar ook onnauwkeuriger. Hier kan nog voor worden gekeken welke waarde voor scaleFactor de beste verhouding tussen snelheid en nauwkeurigheid geeft.
8.1
vervolgonderzoek
Als vervolgonderzoek kan worden gekeken naar het verbeteren van het huidige algoritme en meer experimenten uitvoeren met verschillende waardes voor de tresholds en de ScaleFactor. Verder kan gekeken worden naar een manier voor het decomposeren van transformatie matrixen die gebruikt kunnen worden in Unity voor het plaatsen van objecten.
Ook kan gekeken worden naar de besproken aanpassingen aan ORB in de discussie. Om te kijken wel effect het heeft om maar een klein deel van de afbeelding te pakken en deze te gebruiken voor het berekenen en matchen van features met de camera frames. Verder kan worden gekeken naar het effect op de nauwkeurigheid wanneer wordt gekeken naar het percentage correcte matches in plaats van naar het aantal.
Naast het kijken naar hoe ORB gebruikt kan worden voor spoorzoekertje kan gezocht worden naar een andere manier voor het vinden van de positie waar een object geplaatst zou moeten worden. Een manier die minder afhangt van de richting waarin de speler kijkt maar meer afhangt van de positie in de wereld, waardoor het voorwerp van verschillende kanten benaderd kan worden.
Bibliografie
[1] Android. url: https://developers.google.com/ar/ (bezocht op 06-06-2018). [2] Apple. url: https://developer.apple.com/arkit (bezocht op 06-06-2018).
[3] Herbert Bay e.a. “Speeded-Up Robust Features (SURF)”. In: Computer Vision and Image Understanding 110.3 (2008). Similarity Matching in Computer Vision and Multimedia, p. 346–359. issn: 1077-3142. doi: https://doi.org/10.1016/j.cviu.2007.09.014. url: http://www.sciencedirect.com/science/article/pii/S1077314207001555.
[4] G. Bradski. “The OpenCV Library”. In: Dr. Dobb’s Journal of Software Tools (2000). [5] Michael Calonder e.a. “BRIEF: Binary Robust Independent Elementary Features”. In:
Computer Vision – ECCV 2010. Red. door Kostas Daniilidis, Petros Maragos en Nikos Paragios. Berlin, Heidelberg: Springer Berlin Heidelberg, 2010, p. 778–792. isbn: 978-3-642-15561-1.
[6] Albert Heijn. url: https://www.ah.nl/over- ah/pers/persberichten/bericht?id= 1537844 (bezocht op 08-06-2018).
[7] Ikea. url: https://www.ikea.com/gb/en/customer-service/ikea-apps/ (bezocht op 08-06-2018).
[8] Ebrahim Karami, Siva Prasad en Mohamed S. Shehata. “Image Matching Using SIFT, SURF, BRIEF and ORB: Performance Comparison for Distorted Images”. In: CoRR abs/1710.02726 (2017). arXiv: 1710.02726. url: http://arxiv.org/abs/1710.02726. [9] David G Lowe. “Distinctive image features from scale-invariant keypoints”. In:
Internati-onal journal of computer vision 60.2 (2004), p. 91–110.
[10] Ezio Malis en Manuel Vargas. “Deeper understanding of the homography decomposition for vision-based control”. Proefschrift. INRIA, 2007.
[11] Microsoft. What is a hologram? url: https://docs.microsoft.com/nl-nl/windows/ mixed-reality/hologram (bezocht op 06-06-2018).
[12] niantic. url: https://www.pokemongolive.com/en/ (bezocht op 08-06-2018).
[13] OpenCV. url: https : / / docs . opencv . org / 3 . 0 - beta / doc / py _ tutorials / py _ feature2d/py_matcher/py_matcher.html (bezocht op 08-06-2018).
[14] E. Rosten, R. Porter en T. Drummond. “Faster and Better: A Machine Learning Approach to Corner Detection”. In: IEEE Transactions on Pattern Analysis and Machine Intelligence 32.1 (jan 2010), p. 105–119. issn: 0162-8828. doi: 10.1109/TPAMI.2008.275.
[15] E. Rublee e.a. “ORB: An efficient alternative to SIFT or SURF”. In: (nov 2011), p. 2564– 2571. issn: 1550-5499. doi: 10.1109/ICCV.2011.6126544.
[16] Gabriel Takacs e.a. “Outdoors Augmented Reality on Mobile Phone Using Loxel-based Visual Feature Organization”. In: Proceedings of the 1st ACM International Conference on Multimedia Information Retrieval. MIR ’08. Vancouver, British Columbia, Canada: ACM, 2008, p. 427–434. isbn: 978-1-60558-312-9. doi: 10.1145/1460096.1460165. url: http://doi.acm.org/10.1145/1460096.1460165.
[18] Vuforia. url: https://www.vuforia.com/ (bezocht op 06-06-2018).
[19] Vuforia. Ground Plane User Guide. url: https://library.vuforia.com/articles/ Training/ground-plane-guide.html (bezocht op 06-06-2018).
BIJLAGE A
Experiment foto’s
A.1
Figuur A.1: Frame 100 Figuur A.2: Frame 200
Figuur A.3: Frame 300 Figuur A.4: Frame 400
A.2
Figuur A.7: Hint locatie 1 Figuur A.8: Hint locatie 2
A.3
Figuur A.11: Lichtintensiteit: frame 1
Figuur A.12: Lichtintensiteit: frame 106
