DEGREE PROJECT, IN , FIRST LEVEL STOCKHOLM, SWEDEN 2014
Automatisk detektering av
förutbestämda former i olika miljöer
JOAKIM FORSLUND
Automatisk detektering av förutbestämmda former i olika miljöer
Degree project in Information and Software systems Stockholm, Sweden 2014 Joakim Forslund
Automatisk detektering av f¨ orutbest¨ ammda former i olika milj¨ oer
Joakim Forslund, joforsl@kth.se Handledare: Fredrik Lundevall, flu@kth.se Examinator: Johan Montelius, johanmon@kth.se
Med f¨orstudie skriven gemensamt med: Gustav Lundstr¨om, guslun@kth.se March 31, 2014
Abstract
Den h¨ar rapporten m¨ater i vilka milj¨oer det g˚ar att hitta f¨orutbest¨amda former med OpenCV och en ”off-the-shelf” webkamera.
This project measures in which environments a predetermined shape can be found with OpenCV and ”off-the-shelf” webcameras.
F¨ orord
Jag vill tacka Gustav Lundstr¨om som jag har jobbat tillsammans med under projektet. Han hoppade p˚a med kort varsel och var snabbt tvungen att s¨atta sig in i koden. Tack ¨aven till Davis Ersson, vart arbete med DotDetector denna rapport baseras p˚a.
Inneh˚ all
Abstract i
F¨orord ii
1 Introduktion 1
1.1 Bakgrund och problemmotivering . . . 1
1.2 Overgripande syfte . . . .¨ 2
1.3 Avgr¨ansningar . . . 2
1.4 M˚al . . . 2
1.5 Rapportens struktur . . . 3
2 Tidigare arbete 4 2.1 Lasertraq . . . 4
2.2 Laser Pointer Tracking in Projector-Augmented Architectural Environments . . . 4
2.3 Laser Point Interaction . . . 5
2.4 A Practical System for Laser Pointer Interaction on Large Displays . . . 5
3 Teori 6 3.1 Bildomvandling . . . 6
3.1.1 Gr˚askalning . . . 6
3.1.2 Thresholding . . . 7
3.2 Konturanalys . . . 8
3.2.1 H¨amta konturdata fr˚an bild . . . 8
3.2.2 Polygon-f¨orenkling . . . 8
4 Metod 9 4.1 Tester av systemet . . . 9
5 Konstruktion 10 5.1 Multipla Thresholds . . . 11
5.2 Dynamiska Thresholds . . . 11
5.3 H¨orn-detektering . . . 12
6 Resultat 13
6.1 M¨atresultat . . . 14
7 Slutsatser 16 7.1 Analys . . . 16
7.2 Diskussion . . . 17
7.3 Konsekvensanalys . . . 18
7.4 Framtida arbete . . . 18
Kapitel 1
Introduktion
Denna rapport bygger vidare p˚a ett projekt kallat DotDetector, i huvudsak kodat av David Ersson. DotDetector ¨ar ett system som, med hj¨alp av en webkamera, kan hitta pricken fr˚an en laserpekare p˚a en v¨agg och anv¨anda den som en HID (Human Input Device).
DotDetector fungerar i nul¨aget s˚a v¨al att det g˚ar att anv¨anda p˚a ett vettigt s¨att. Men f¨or att anv¨anda det kr¨avs att man ¨ar ganska insatt i hur systemet fungerar. I b¨orjan av varje k¨orning m˚aste vissa delar av systemet kalibreras beroende p˚a hur milj¨on ser ut i rummet d¨ar det anv¨ands. De viktiga milj¨o- faktorerna ¨ar ljuset i rummet, och vinkeln mellan kameran och v¨aggen som anv¨ans som rityta f¨or laserpekaren. Beroende p˚a hur dessa tv˚a faktorer ser ut m˚aste systemet st¨alla in en viss exponeringstid f¨or kameran, och skapa en transformationsmatris som kompenserar f¨or kamerans vinkel mot v¨aggen.
I nul¨aget ¨ar denna kalibrering manuell och inte helt trivial. Jag har f˚att i uppdrag att ut¨oka funktionaliteten hos DotDetector genom att automatisera den geometriska kalibreringen. Detta har jag l¨ost genom att visa en testbild med en f¨orutbest¨amd symbol i varje h¨orn (h¨arefter kallade ’kalibrerings- former’). Sedan har jag skrivit mjukvara som hittar dessa kalibrerings- former, och skickar deras positioner till rutinen som ber¨aknar den s¨okta transformationsmatrisen. Som systemet fungerade innan var anv¨andaren sj¨alv tvungen att i en bild markera positionerna f¨or ritytans h¨orn.
1.1 Bakgrund och problemmotivering
Grunden till DotDetector lades f¨or ungef¨ar tv˚a och ett halv ˚ar sedan. D˚a fick jag och n˚agra studiekamrater m¨ojlighet att anv¨anda tekniken p˚a Naturhis- toriska Riksmuse´et’s planetarium Cosmonova. F¨orfattaren lyckades ¨overtyga personalen p˚a muse´et att l˚ata oss anordna aktiviteter d¨ar under sektionens mottagning av nya studenter i slutet av sommaren 2012. D˚a vi funderade
p˚a vad vi skulle vilja g¨ora f¨or aktiviteter f¨or de nya studenterna lades en ide fram om att bygga ett spel liknande Nintendo’s gammla klassiker ”Duck Hunt”. Vi ville anv¨anda en laserpekare som HID (Human Input Device) eftersom det skulle till˚ata m˚anga spelare sammtidigt och passade bra till f¨oruts¨attningarna i sj¨alva lokalen. Det har (tyv¨arr) inte blivit n˚agot spel till Cosmonova ¨an, men det projektet utvecklades till DotDetector-projektet, som denna rapport i sin tur bygger p˚a.
Anledningen till att vi vill vidareutveckla DotDetector i denna rapport ¨ar fr¨amst att ¨oka anv¨andarv¨anligheten. Om DotDetector ska kunna anv¨andas av gemene man, som inte ¨ar intresserad eller insatt i hur systemet fungerar, m˚aste det vara enklare att komma ig˚ang. M˚albilden ¨ar att DotDetector bara ska vara ett genomskinligt interface mellan h˚ardvara och applikationer. Det ska inte beh¨ovas n˚agon handp˚al¨aggning fr˚an anv¨andaren f¨or att det ska fungera.
1.2 Overgripande syfte ¨
Syftet f¨or detta arbete ¨ar att bygga ett system som automatiskt kan sk¨ota den geometriska kalibreringen av DotDetector-programmet.
1.3 Avgr¨ ansningar
I denna rapport har jag valt att arbeta under vissa begr¨ansningar f¨or vilken h˚ardvara som f˚ar anv¨andas, och under hur sv˚ara f¨orh˚allanden som detek- teringen m˚aste fungera. Endast ”off-the-shelf” projektorer och webkameror anv¨ands, och kameran ska inte ha h¨ogre uppl¨osning ¨an 640 X 480 pixlar.
Processorkraften som kr¨avs f¨or bildbehandlingen f˚ar inte ¨overstiga vad som kan f¨orv¨antas av en vanlig dussin-laptop. Detekteringen ska fungera med h¨og tr¨affs¨akerhet under normal rumsbelysning.
1.4 M˚ al
M˚alet med denna rapport ¨ar att reda ut inom vilka environment-parameters man, med god tr¨affs¨akerhet, automatisk i mjukvara kan identifiera f¨orut- best¨ammda geometriska former i digitala bilder.
1.5 Rapportens struktur
I kapitel 3 redovisas tidigare arbete innom ¨amnet.
Kapitel 4 beskriver grundl¨aggande teori som beh¨ovs f¨or att f¨orst˚a rapporten.
Kaptiel 5 beskriver hur arbetet har bedrivits och hur programmet har tes- tats.
Kaptiel 6 beskriver hur ShapeDetector fungerar.
Kapitel 7 redovisar resultaten av de m¨atningar som gjorts.
Kaptiel 8 beskriver f¨orfattarens egna slutsatser kring projektet.
Kapitel 2
Tidigare arbete
Att kalibrera kameror med hj¨alp av m¨onsterigenk¨anning ¨ar ett v¨alk¨ant prob- lem. Det anv¨ands i m˚anga olika typer av Augmented Reality implementa- tioner. Fr˚an enkla system som DotDetector med st¨od f¨or en kamera, till sys- tem som t¨acker alla v¨aggar i ett rum och anv¨ander flera, ibland roterande, kameror.
2.1 Lasertraq
Ett tidigare projekt som liknar v˚art ¨ar LaserTraq. Det ¨ar ocks˚a gjort f¨or att just hitta pricken fr˚an en laser-pekare m.h.a en kamera och anv¨anda den som Human Input Device. Det har st¨od f¨or att anv¨anda laserpekare i olika f¨arger samtidigt, och kan hantera inl¨asning fr˚an mer ¨an en kamera. Det har dock ingen autokonfigurering utan b˚ade geometri- och kamerainst¨allningar m˚aste g¨oras manuellt. LaserTraq-projektet har laddats ner totalt ca 1450 g˚anger och uppdaterades senast 20081.
2.2 Laser Pointer Tracking in Projector-Augmented Architectural Environments
Artikeln Laser Pointer Tracking in Projector-Augmented Architectural En- vironments2 beskriver ett system f¨or att hitta en laser-prick, och projicera bilder p˚a alla v¨aggar i ett rum. Systemet anv¨ander b˚ade en r¨orligt s.k. PTZ- kamera och en fast kamera som en typ av referenspunkt. H¨ar m˚aste b˚ade interna parametrar i den r¨orliga kameran och ”rumsberoende” parametrar konfigureras.
1https://code.google.com/p/lasertraq/, 2014-04-17
2http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88.2730&rep=rep1&type=pdf, 2014-03-24
2.3 Laser Point Interaction
Laser Point Interaction3 beskriver ett system som ¨ar v¨aldigt likt DotDetec- tor. Det hittar en laser-prick, med en kamera, p˚a en v¨agg. De anv¨ander dock ett m¨onster med 25 prickar f¨or kalibrering av kameran, ist¨allet f¨or 4 former som i DotDetector. Det framg˚ar inte om kalibreringen ¨ar automatisk eller inte.
2.4 A Practical System for Laser Pointer Interac- tion on Large Displays
Systemet i denna artikel ¨ar ¨aven det mycket likt DotDetector och det som beskrivs i 3.34. H¨ar anv¨ands en bild med horisomtella och vertikala linjer som kalibrerings-bild. Detta f¨or att systemet ska kunna kompensera ¨aven f¨or f¨orvr¨angning i bilden som uppst˚ar p.g.a. ”fish-eye” effekter i kamerans lins. Vi har inte m¨arkt av n˚agra problem med s˚adan f¨orvr¨angning i DotDe- tector.
F¨orfattarna har ¨aven uppm¨arksammat problemet med att anv¨anda ett kon- stant Threshold-v¨arde. De har dock en annan l¨osning. Under kalibreringen tas ett antal bilder d¨ar projektorn visar en helt vit p˚a ritytan. Dessa bilder anv¨ands sedan som en referens i den senare detektionen. F¨or att hitta laser- pricken f¨ors¨oker systemet hitta en punkt vars ljusstyrka ligger ett visst v¨arde
¨
over referens-v¨ardet.
3http://icie.cs.byu.edu/Papers/LaserPointer.pdf, 2014-03-24
4http://dl.acm.org/citation.cfm?id=1101637
Kapitel 3
Teori
Om man vill f¨orst˚a de tekniska detaljerna kring hur problemet har l¨osts kr¨av lite f¨orkunskap i tv˚a omr˚aden: hur en bild omvandlas fr˚an f¨argskala till svart-vit, och hur mjukvara analyserar en bild f¨or att hitta konturer. F¨or mer detaljer h¨anvisas l¨asaren till OpenCV’s dokumentation1.
Grundtanken i systemet ¨ar att en bild l¨ases in fr˚an kameran och behand- las f¨or att skapa en bild enbart best˚aende av helt svarta och helt vita pixlar. Denna behandlade bild analyseras sedan f¨or att hitta m¨onster. Hur man v¨aljer att g¨ora konturanalysen och bildbehandlingen har mycket stor p˚averkan p˚a slutresultatet. I slut¨andan ¨ar det konturanalysen som faktiskt hittar de former vi letar efter, men bildbehandlingen best¨ammer hur effektiv denna analys kan vara. Det ¨ar d¨arf¨or viktigt att optimera b˚ada dessa steg f¨or det t¨ankta anv¨andningsomr˚adet.
3.1 Bildomvandling
Syftet med bildbehandlningen ¨ar att, fr˚an den inl¨asta bilden, skapa en ny bild med s˚a mycket kontrast som m¨ojligt mellan de former vi ¨ar intresserade av att hitta, och bakgrunden. Detta sker i tv˚a steg, varav det f¨orsta ¨ar ganska trivialt.
3.1.1 Gr˚askalning
I f¨orsta steget g¨or vi om bilden till gr˚askala i en enkel transformation. Varje pixel i den gr˚askalade bilden best¨ams av RBG v¨arderna i orginalbilden.
Gr˚askalningen ¨ar anpassad f¨or att beh˚alla s˚a mycket av informationen om ljuset i bilden som m¨ojligt. Detta passar v˚ar till¨ampning bra d˚a vi vill f˚a fram mycket kontrast i bilden.
3.1.2 Thresholding
N¨asta steg ¨ar betydligt viktigare f¨or den efterf¨oljande konturanalysen ¨an gr˚askalningen. N¨ar vi ¨ar klara med gr˚askalningen har vi en bild d¨ar varje pixel har ett v¨arde mellan 0 och 255. F¨or konturanalysen vill vi dock ha en bild d¨ar varje pixel antingen har v¨ardet 0 eller 255. Detta kallar vi f¨or en
’bin¨ar bild’, eftersom varje pixel har ett av endast tv˚a m¨ojliga v¨arden.
Konverterigen fr˚an gr˚askala till bin¨ar bild sker genom att vi f¨orst v¨aljer ett v¨arde mellan 0 och 255. Detta kallar vi v˚art ’tr¨oskelv¨arde’, eller p˚a engelska
’threshold value’. Sedan g˚ar vi igenom den gr˚askalade bilden pixel f¨or pixel.
Varje pixel i den gr˚askalade bilden som har ett v¨arde under tr¨oskelv¨ardet s¨atts till vit, och alla pixlar ¨over tr¨oskelv¨ardet s¨atts till svart (eller tv¨artom om s˚a ¨onskas, det spelar ingen roll f¨or konturanalysen). Valet av tr¨oskelv¨arde har mycket stor p˚averkan p˚a hur effektiv konturanalysen ¨ar.
Figure 3.1: Tv˚a bin¨ara bilder skapade fr˚an samma orginalbild med olika Threshold-v¨arden. Olika konturer framtr¨ader i de olika bilderna.
3.2 Konturanalys
N¨ar den bin¨ara bilden ¨ar klar kan vi p˚ab¨orja konturanalysen. Precis som med bildomvandlingen sker detta i tv˚a steg, varav det f¨orsta ¨ar ganska trivialt.
F¨orst h¨amtar vi alla konturer vi hittar i bilden, sedan analyserar vi dem f¨or att plocka ut de former vi ¨ar intresserade av.
3.2.1 H¨amta konturdata fr˚an bild
N¨ar vi tar ut konturerna ur den bin¨ara bilden kommer alla slutna omr˚aden i bilden r¨aknas som en kontur. Varje kontur sparas i en datastruktur kallad
’CvSeq’. En CvSeq best˚ar i sin tur av en serie koordinat-punkter (i x,y rymd), d¨ar varje koordinat ¨ar ett ’h¨orn’ av konturen. En kontur kan ha godtyckligt antal h¨orn. Algoritmen som letar efter konturer str¨avar efter att ge varje kontur s˚a m˚anga h¨orn som m¨ojligt, d˚a detta ger oss mer exakt data p˚a hur objekten i bilden ser ut.
3.2.2 Polygon-f¨orenkling
Efter att konturerna har h¨amtats ur bilden f¨orenklas dem med hj¨alp av Ramer–Douglas–Peucker’s algoritm2. Denna f¨orenkling reducerar, p˚a ett intelligent s¨att, antalet h¨orn i varje kontur. F¨orenklingen g¨ors f¨or att f˚a ut mer korrekta former fr˚an koturdatat. P˚a grund av brus och d˚alig uppl¨osing p˚a bildk¨allan kan en kontur f˚a fler punkter ¨an vad den motsvarande for- men i bilden har h¨orn. Bruset och bild-artefakter kommer ofta med i den bin¨ara bilden och ger upphov till st¨orningar n¨ar vi g¨or konturanaly- sen. K¨ansligheten p˚a f¨orenklingsalgoritmen har stor inverkan p˚a hur korrekt form-detektering systemet uppn˚ar.
Figure 3.2: Afrikas kontur f¨orenklad med RDP-algoritmen
Kapitel 4
Metod
Utvecklingen har skett uteslutande i C med Linux som operativsystem i botten. Detta val kom ganska naturligt eftersom DotDetektor ¨ar byggt p˚a samma s¨att. D˚a de b˚ada systemen ska kopplas samman i slut¨andan k¨andes det l¨ampligt att g¨ora dem s˚a kompatibla som m¨ojligt fr˚an b¨orjan.
C som programmeringsspr˚ak l¨ampar sig ¨aven ganska v¨al f¨or detta projekt, eftersom kalibreringsrutinen m˚aste g¨ora relativt tunga ber¨akningar i realtid och C ¨ar ett mycket snabbt spr˚ak. Vissa l¨osningar hade varit enklare att implementera i t.ex. Java, men f¨orfattaren g¨or bed¨ommningen (detta har dock inte testats) att prestandan hade f˚att lida i s˚a fall.
4.1 Tester av systemet
Mycket av utvecklingstiden har lagts p˚a att testa systemet. Eftersom det
¨
ar v¨aldigt sv˚art att p˚a f¨orhand bed¨omma exakt vad en ¨andring av en del av system kommer f˚a f¨or effekt p˚a slutresultatet, var det betydligt enklare att
’k¨anna sig fram’ n¨ar parametrar skulle optimeras eller tv˚a olika l¨osningar stod mot varandra. Efter varje ¨andring s˚a k¨ordes systemet i en stabil testmilj¨o och en bed¨ommning gjordes om detekteringen blev b¨attre eller s¨ammre.
Ett par olika milj¨oer har anv¨ands f¨or tester. Den f¨orsta, och kanske mest relevanta, var IN-Sektionen’s sektionslokal Kistan i Forum-byggnaden. Sys- temet har testats med en i lokalen monterad projektor av vanlig kontorsmod- ell och varierad bakgrundsbelysning. Denna milj¨o ¨ar en bra approxima- tion p˚a en kontorsmilj¨o d¨ar systemet ¨ar t¨ankt att anv¨andas. Sedan har tester ocks˚a gjorts i milj¨oer med betydligt mindre ljus ¨an i Kistan, fr¨amst i f¨orfattarens l¨agenhet. I de mest p˚afrestande tester som gjorts var l¨agenheten helt nedsl¨ackt. Endast ljuset fr˚an ett par datorsk¨armar var tillr¨ackligt f¨or att systemet skulle hitta en f¨orutbest¨ammd form ritad p˚a ett anteckningsblock, ungef¨ar 5x5cm stor, p˚a ett avst˚and av 40-50cm.
Kapitel 5
Konstruktion
F¨or att l¨osa uppgiften har jag utvecklat ett system kallat ShapeDetec- tor. Den st¨orsta anstr¨angningen under utvecklingen har varit att f˚a sys- temet helt automatiskt. Ett av kraven ¨ar som sagt att konfigureringen ska ske helt utan handp˚al¨aggning fr˚an anv¨andaren. De liknande projekt som vi fann under litteraturstudien kr¨avde alla n˚agon form av manuella inst¨allningar. Det st¨orsta problemet var att systemet m˚aste g˚a att anv¨anda i varierande ljusf¨orh˚allanden, och det visade sig snabbt vara om¨ojligt att hitta en inst¨allning som fungerade tillr¨ackligt bra i alla milj¨oer. Systemet beh¨over med andra ord dynamiskt kunna hitta ett Threshold-v¨arde som passar f¨or de aktuella f¨orh˚allandena. F¨orst d¨arefter kan det b¨orja s¨oka efter de former som ska hittas. Detta m˚aste ocks˚a ske inom en rimlig tid ur anv¨andarsynpunkt.
Det var med andra ord flera del-problem som beh¨ovde l¨osas:
1. Hur ska systemet automatiskt hitta ett Thresholding-v¨arde d¨ar alla konturer som beh¨ovs f¨or konfigureringen syns i den bin¨ara bilden?
2. Hur ska systemet skilja p˚a konfigurerings-konturer och ¨ovriga kon- turer?
3. Kan systemet l¨osa dessa uppgifter p˚a ett tidsspann av ett par sekun- der?
Varje fr˚aga har f˚att en mekanik i systemet som l¨oser just den uppgiften.
Underrubrikerna 6.1, 6.2 och 6.3 svarar p˚a fr˚aga 3, fr˚aga 1 och fr˚aga 2 re- spektive. Anledningen till att fr˚agorna och svaren inte st˚ar i samma ordning
¨
ar att rapporten som helhet blir mer l¨attf¨orst˚aelig om systemet f¨orklaras i den ordningen.
5.1 Multipla Thresholds
Som beskrevs i rubrik 4.1 sker konturanalysen inte p˚a bilden systemet h¨amtar fr˚an kameran utan p˚a en bin¨ar bild med enbart svarta och vita pixlar.
Aven om omvandlingen fr˚¨ an r˚a kamera-bild till bin¨ar bild inte ¨ar helt triv- ial ber¨akningsm¨assigt, s˚a tar det betydligt l¨angre tid f¨or kameran att ex- ponera en ny bild ¨an vad dessa ber¨akningar tar. Tiden mellan att bin¨ar- konverteringen ¨ar klar och att systemet f˚ar in en ny bild fr˚an kameran ¨ar bortsl¨osad ber¨akningstid. I en naiv implementation skulle systemet i detta l¨age ligga och v¨anta p˚a en ny bild i ett blockerande anrop till kameran.
ShapeDetector anv¨ander denna tid till n˚agot anv¨andbart. Ist¨allet f¨or att bara generera en bin¨ar bild per bildruta fr˚an kameran, anv¨ander ShapeDe- tector m˚anga olika v¨arden f¨or att generera lika m˚anga olika bin¨ara bilder.
Varje bin¨ar bild analseras sedan separat av konturanalys-algoritmen. P˚a f¨orfattarens laptop hinner upp till 20 bin¨ara bilder genereras per bildruta om kamerans exponerinstid ¨ar 1/30 sekunder.
Multipla Thresholds hj¨alper oss p˚a s˚a s¨att att vi f˚ar ut mer konturinfor- mation per bildruta per tidsenhet ¨an om vi bara anv¨ant ett v¨arde. Det kan ungef¨ar liknas vid att ta en bild med m˚anga olika exponeringstider.
Beroende p˚a hur ljuset i rummet ser ut, kommer vissa detaljer i bilden framtr¨ada tydligare vid vissa exponeringstider. P˚a samma s¨att framtr¨ader olika konturer vid olika Threshold-v¨arden. De multipla bin¨ara bilderna blir som olika lager av ljus som s¨oks av var f¨or sig. En kalibrerings-kontur kan vara helt osynlig i ett lager men fullt synligt i ett annat.
5.2 Dynamiska Thresholds
F¨or att kunna hantera olika ljusf¨orh˚allanden utan n˚agon manuell inst¨allning, kr¨avs att systemet sj¨alv dynamiskt kan avg¨ora vilka Threshold-v¨arden som
¨
ar l¨ampliga under k¨orning. Detta l¨oser ShapeDetector genom att imple- mentera en feedback-loop i mekanismen som beskrivs i kapitel 6.1 ovan.
N¨ar konturanalysen av ett Threshold-lager i mekanism 6.1 ¨ar avslutad, rap- porterar rutinen som g¨or konturanalysen ett m¨atv¨arde tillbaka till en central arbitrator. M¨atv¨ardet best˚ar av hur m˚anga meningsfulla konturer som hit- tades i lagret. Meningsfulla i det h¨ar fallet betyder konturer som har en area st¨orre ¨an 50 pixlar, f¨or att filtera ut brus. Arbitrators uppgift ¨ar sedan att s˚alla ut lager som inte har tillr¨acligt bra m¨atv¨arden och ge ut nya Threshold- v¨arden som dessa lager ska arbeta med i n¨asta bildruta.
Det finns tv˚a fall d˚a arbitratorn ¨andrar Threshold-v¨ardet f¨or ett lager. F¨orst,
om m¨atv¨ardet f¨or ett lager ¨ar under ett minsta till˚atna v¨arde. Eller, om inget lager ligger under det minsta till˚atna v¨ardet, s˚a ¨andras ist¨allet Threshold- v¨ardet f¨or det lager med l¨agst m¨atv¨arde. I det f¨orst fallet kan Threshold- v¨ardet f¨or alla lager ¨andras mellan tv˚a bildrutor. Om inget lager ligger under det minsta v¨ardet ¨andras bara ett lager, det med l¨agst m¨atv¨arde. Ett specialfall ¨ar om ett lager har hittat en kalibrerings-form. Lagret kommer rapportera detta tillbaka till arbitratorn, som d˚a inte kommer att ¨andra p˚a det lagrets Threshold-v¨arde mellan den nuvarande och n¨astf¨oljande bildruta oavsett lagrets m¨atv¨arde. Nya Threshold-v¨arden f¨or lager som skall ¨andras slumpas fram i intervallet 0 till 255. En kontroll g¨ors sedan s˚a att inget annat lager anv¨ander den framslumpade siffran som Threshold just nu. En ny siffra slumpas fram om en krock har uppst˚att. Tv˚a lager kan allts˚a aldrig ha samma Threshold-v¨arde. Med denna algoritm kan arbitratorn g˚a fr˚an att ha 0 i m¨atv¨arde i samtliga lager, till att hitta samtliga kalibreringsformer i bilden, p˚a 6-7 bildrutor.
5.3 H¨ orn-detektering
I varje bin¨ar bild som genereras f¨ors¨oker ShapeDetector hitta fyra stycken kalibrerings-former, en f¨or varje h¨orn p˚a ritytan. N¨ar alla 4 h¨orn syns i en bild skickas deras positioner till rutinen som ber¨aknar transformations- matrisen. F¨or att matrisen ska bli r¨att m˚aste ShapeDetector dock lista ut vilken kalibreringsform som motsvarar vilket h¨orn. Allts˚a vilken form som
¨
ar ¨ovre v¨anstra h¨ornet, vilken som ¨ar det nedre h¨ogra, osv. Detta l¨oser den med en enkel implementation av pythagoras sats. Den kalibreringsform som ligger n¨armast ett visst h¨orn i bilden fr˚an kameran anses vara motsvarande h¨orn p˚a ritytan. Om kameran st˚ar n˚agorlunda plant relativt ritytan fungerar denna algoritm mycket bra. Men om kameran roteras ¨over 45 grader med- eller moturs (eller plaseras upp-och-ner) blir den f¨orvirrad.
Kapitel 6
Resultat
F¨or att se hur v¨al ShapeDetector klara uppgiften beh¨over vi ett objektivt m˚att p˚a detta. Jag har valt att m¨ata hur m˚anga bildrutor det tar f¨or sys- temet att g¨ora en geometrisk kalibrering. Exponeringstiden f¨or kameran
¨
ar inst¨alld p˚a 45ms under alla m¨atningar. M¨atningarna har gjorts i IN- Sektionens sektionslokal Kistan, p˚a olika avst˚and fr˚an ritytan och med olika ljusniv˚aer i rummet. Belysningen best˚ar av lysr¨or kopplade till en dimmer, s˚a det ¨ar relativt enkelt att justera bakgrundsbelysningen.
4 olika m¨atningar gjordes f¨or att testa olika scenarion. I m¨atning 1 och 2 stog kameran vinkelr¨att mot v¨aggen p˚a 4.5m avst˚and. M¨atning 2 gjordes ¨aven den med kameran vinkelr¨att mot v¨aggen, men p˚a 6.5m avst˚and. M¨atning 3 gjordes p˚a 4m avst˚and med kameran placerad i ca 45 graders vinkel mot v¨aggen.
4,5m valdes som avst˚and d˚a det k¨anns som ett avst˚and som skulle kunna anv¨andas i en vanlig kontorsmilj¨o. 6,5m och 4m valdes f¨or att det var det l¨angsta avst˚andet kameran kunde placeras fr˚an ritytan i 90 resp. 45 graders vinkel, p˚a grund av lokalens fysiska utformning och dess tekniska utrustning.
Resultaten i m¨atning 1 och 2 skiljer sig v¨aldigt mycket ˚at trots att de till synes utf¨ordes under samma f¨oruts¨attningar. Det blev s˚a f¨or att det uppen- barades ett fenomen under m¨atning 1 som ShapeDetector inte var t¨ankt att hantera. Detta analyserars i mer detalj i stycke 8.1 och f˚ar d¨ar sin f¨orklaring.
6.1 M¨ atresultat
M¨atv¨ardet anger hur m˚anga bildrutor ShapeDetector beh¨ovde f¨or en kali- brering.
M¨atning 1: 4.5m avst˚and, vinkelr¨att mot v¨aggen.
1-10 11-100 100+ Lyckades ej
0 2 4 6 8 10
0 0 0
10 10
0 0 0
antal bildrutor
antalm¨atningar
Belysning t¨and Belysning sl¨ackt
M¨atning 2: 4.5m avst˚and, vinkelr¨att mot v¨aggen.
1-10 11-100 100+ Lyckades ej
0 2 4 6 8 10
7
2
1
0 10
0 0 0
antal bildrutor
antalm¨atningar
Belysning t¨and Belysning sl¨ackt
M¨atning 3: 4.5m avst˚and, 45 grader vinkel.
1-10 11-100 100+ Lyckades ej
0 2 4 6 8 10
2
6
2
0 10
0 0 0
antal bildrutor
antalm¨atningar
Belysning t¨and Belysning sl¨ackt
M¨atning 4: 6.5m avst˚and, vinkelr¨att mot v¨aggen.
1-10 11-100 100+ Lyckades ej
0 2 4 6 8 10
0 0 0
10 10
0 0 0
antal bildrutor
antalm¨atningar
Belysning t¨and Belysning sl¨ackt
Kapitel 7
Slutsatser
7.1 Analys
Fr˚an m¨atningarna i Kistan vill jag dra ett par slutsatser. F¨orst, att Shape- Detector klarar kalibering i nedsl¨ackta rum bra. Den klarar konsekvent att hitta alla 4 kalibrerings-former i f¨orsta bildrutan b˚ade p˚a 4,5 och 6,5 meters avst˚and, ¨aven om kameran inte placeras vinkelr¨att mot v¨aggen.
Sedan n¨ar vi ¨okar bakgrundsbelysningen kan vi se ett par intressanta fenomen.
Fr˚an m¨atning 2 ser vi att p˚a 4,5m avst˚and lyckas kalibreringen, men efter betydligt fler bildrutor. 9 av 10 m¨atningar ligger p˚a under en sekund (med 45ms exponeringstid blir en sekund ungef¨ar 22 bildrutor), och en m¨atning p˚a strax ¨over 2 sekunder. Jag tror att denna variation beror p˚a vilka v¨arden som den dynamiska Threshold-mekanismen (beskriven i stycke 6.2) slumpar fram. I den m¨atningen med h¨ogt v¨arde har arbitratorn satt ”fel”
Thresholding-v¨arden f¨or lagrena under l¨angre tid ¨an i de m¨atningarna med l˚aga v¨arden. Det h¨ar fenomenet syns tydligare i resultaten fr˚an m¨atning 3.
Detta visar att arbitratorn b¨or f¨orb¨attras f¨or att ge mer konsekventa resul- tat. Till exempel genom att man m¨ater den totala ljusstyrkan i bilden och viktar arbitratorn mot h¨ogre eller l¨agre Threshold-v¨arden beroende p˚a hur ljusstark bilden ¨ar.
Resultaten fr˚an m¨atning 1 visar ocks˚a en intressant sak. I den m¨atningen f¨oll det sig att takbelysningen skapade en ganska skarp skugga som f¨oll ¨over halva kalibreringsformen i ¨ovre h¨ogra h¨ornet. N¨ar m¨atningarna gjordes s˚a kunde jag se att det var just den formen som var sv˚ar att hitta. Jag kunde
¨
aven se att den del av formen som var skuggad tolkades som en form, medan den ljusare delen tolkades som en annan, separat form. Systemet ¨ar allts˚a k¨ansligt f¨or skiftande ljusstyrka i olika delar av samma kalibreringsform.
Detta st¨ammer ocks˚a v¨al ¨overens med vad vi vet om konturdetekteringen i
formen att synas i olika bin¨ara bilder. Med lite tur hittar kanske arbitratorn till slut ett Threshold-v¨arde d¨ar hela formen ¨and˚a syns i bilden. Men d˚a kalibreringen i m¨atning 1 aldrig lyckades, oavsett hur l¨ange arbitratorn fick f¨ors¨oka, s˚a verkar det kunna falla sig s˚a illa att f¨or stora ljusskillnader inte kan hanteras om bin¨ara bilder anv¨ands som grund f¨or konturdetekteringen.
Det finns helt enkelt inget Threshold-v¨arde d¨ar hela formen syns i en bild.
Detta ¨ar inte ett enkelt problem att l¨osa, d˚a det i s˚a fall skulle kr¨avas att sys- temet kan pussla ihop en kalibrerings-form fr˚an olika delar som hittas i olika Threshold-lager. En annan sak v¨ard att notera ¨ar att jag l¨oste problemet med den st¨orande skuggan genom att g¨ora f¨onstret som visar kalibrerings- bilden mindre p˚a ritytan, f¨or att p˚a s˚a vis undvika den skuggade delen av v¨aggen. Trots att kalibrerings-formerna gjordes mindre s˚a f¨orb¨attrades re- sultatet avsev¨art. Systemet ¨ar allts˚a betydligt mer k¨ansligt f¨or skuggor ¨over kalibrerings-former ¨an f¨or storleken p˚a formerna.
I m¨atning 3 ser vi ocks˚a att det ¨ar jobbigare f¨or systemet att g¨ora en kali- brering i skarpa vinklar mot v¨aggen. Jag tror detta beror p˚a att kalibrerings- formerna blir mindre i bilden fr˚an kameran ju skarpare vinkeln till v¨aggen
¨ ar.
7.2 Diskussion
Overlag klarar ShapeDetector sin uppgift bra. M˚¨ alet var att unders¨oka i vilka f¨orh˚allanden man med god tr¨affs¨akerhet kan urskilja f¨orutbest¨amda former med mjukvara. ¨Aven om det fortfarande finns m˚anga f¨orb¨attringar att g¨ora, s˚a tycker jag att ShapeDetector klarar av ett relativt brett spann av f¨oruts¨attningar utan n˚agon manuell konfiguration. Den klarar av variationer i ljusf¨orh˚allanden, kameras position relativt de former som ska uppt¨ackas, och variationer i formernas storlek och utseende. Den ger ¨aven v¨aldigt ex- akta och stabila koordinater f¨or formens position, och det ¨ar v¨aldigt liten risk f¨or ”false positives”. ShapeDetector klarar dessutom av sin uppgift v¨aldigt snabbt ¨aven med billig h˚ardvara.
Framf¨or allt b¨or arbitratorn som v¨aljer ut Threshold-v¨arden f¨orb¨attras. Fr˚an m¨atresultaten tycker jag att det tydligt framg˚ar att det ¨ar l˚angt ifr˚an op- timalt att slupa fram nya v¨arden. Medelv¨ardet f¨or hur m˚anga bildrutor en kalibrering tar ¨ar ganska ok, men det ¨ar f¨or stor variation mellan h¨ogsta och l¨agsta v¨ardet. En arbitrator som p˚a ett mer intelligent s¨att kan r¨ora sig mot optimala Threshold-v¨arden verkar enligt mig vara det b¨asta s¨attet att l¨osa detta. Den borde ocks˚a kunna utf¨ora en kalibrering ¨aven om kalibrerings- formerna hittas i olika Threshold-lager. Om den kunde det s˚a tror jag att kalibreringar skulle lyckas i ¨annu s¨ammre f¨orh˚allanden, och antagligen ocks˚a snabbare.
7.3 Konsekvensanalys
F¨orhoppningsvis kan denna typ av autokalibrering g¨ora nya s¨att att inter- agera med datorer mer tillg¨angliga f¨or allm¨anheten.
7.4 Framtida arbete
1. F¨orb¨attra s¨attet som arbitratorn v¨aljer Threshold-v¨arden. Ist¨allet f¨or att slumpa fram dem b¨or de v¨aljas p˚a ett mer intelligent s¨att. N˚agon typ av viktning mot h¨ogre eller l¨agre v¨arden beroende p˚a hur totala ljuset i bilden ¨ar ett alternativ.
2. Se till att systemet kan avl¨asa former som delvis ¨ar skuggade.
3. Implementera n˚agon typ av brus-reducering.
TRITA ICT-EX-2014:69