Övervakningssystem för inomhusmiljöer

Examensarbete

15 högskolepoäng, grundnivå.

Övervakningssystem för inomhusmiljöer

Surveillance Systems for Indoor Environments

Filip Johansson Ali Karabiber

Examen: Kandidatexamen 180 hp Handledare: Bengt Nilsson Huvudämne: Datavetenskap Examinator: Jonas Forsberg Program: Systemutveckling

Resumé

Övervakningssystem har haft en viktig roll i samhället under en lång period. Syftet med dessa systemen har inte ändrats, det är alltid säkerhetsaspekten som har varit huvudpunkten. Effektiviteten på ett övervakningssystem beror oftast på den mänskliga faktorn, någon måste bearbeta bildflödet som spelas in för att dra definitiva slutsatser. Under senare år har dessa övervakningssystem, i takt med teknologins utveckling, blivit mer intelligenta. Metoder som tillämpar automatisk analysering av en given bild har introducerats, vissa av dessa tekniker har redan hunnit bli en standard. Denna studie ska utveckla en prototyp som använder sig av tekniken och stresstesta för att identifiera eventuella brister. Det är i grunden en feasibility study som ska visa vad som kan uppnås med begränsade resurser. Med en funktionell prototyp tillgänglig skall diverse stresstester specifieras för att mäta systemets gränser. Resultatet har överlag varit positiva men ett antal kritiska brister identifierades.

Abstract

Security systems have always had an important role in society for a long time. The purpose of these systems has always remained primarily focused on the security aspect. In most cases the efficiency of current security systems depend on human factors. The frames have to be processed by a person to reach a definitive conclusion. In recent years, security systems have become increasingly intelligent as technology continues to develop. Methods that implement automatic analysis of any given frame in a video have been introduced and some of these methods are already standardized. The aim of this study is to develop a prototype and stress test it to identify possible flaws. This study is primarily a feasibility study to show the possibilities of what can be achieved with limited resources. With a fully functional prototype available a series of stress tests will be specified to measure the system’s limits. The results have been positive overall but a number of critical flaws have been identified.

Keywords: Computer vision, surveillance, motion detection, image processing, Aforge

Definitionslista

Nedan följer en lista över engelska eller svårförstådda ord som förekommer i studien. FPS, Frames-Per-Second – Innebär hur många bilder per sekund som hanteras.

Motion detection, rörelsedetektering – Metod för att upptäcka rörelser och förändringar mellan två bilder.

Line-of-Sight – I denna studie används detta uttryck när vi syftar på systemets synfält. Alltså den synlinjen från webbkameran till ett givet objekt i miljön där systemet opererar.

Grayscale – Gråskala. Färgförklaringen för bilder som endast innehåller nyanser av grått, från vitt till svart.

Bitmap – En digital bild som består av en matris med fyrkantiga rutor, även kallade pixlar.

Matris – En datastruktur bestående av nästlade listor.

Referensbild, bakgrundsbild – I denna studie syftar dessa begrepp på en bild som används av systemet för att jämföra mot den nuvarande bilden som hämtats från webbkamerans videoström.

Innehållsförteckning

1 Inledning ... 1 1.1 Bakgrund ... 1 1.2 Frågeställning ... 1 1.3 Problemdiskussion ... 1 1.4 Syfte ... 2 1.5 Avgränsning ... 2 2 Metod ... 2

2.1 Prototyp och bibliotek ... 2

2.2 Tester och stresstester ... 3

2.3 Feasibility Study ... 4 2.4 Metoddiskussion ... 4 3 Teori ... 4 3.1 Tidigare forskning ... 4 3.2 Aforge ... 5 3.3 Computer Vision ... 5 3.4 Image Processing... 5 3.5 Motion Detection ... 8 4 Prototyp ... 9

4.1 Verktyg och utvecklingsmiljö ...10

5 Testfall och resultat ...11

5.1 Testfall 1 - Orientering ...11

5.2 Testfall 2 - Färg ...12

5.3 Testfall 3 - Användardefinierade fokuszoner ...13

5.4 Testfall 4 - Längre avstånd ...13

5.5 Testfall 5 - Rörliga objekt ...14

5.6 Testfall 6 - Okontrollerade bakgrundsmiljöer ...15

5.7 Testfall 7 - Ändringar i belysning ...16

5.8 Testfall 8 – Övervakning av ett specifikt objekt ...17

5.9 Testfall 9 - Mindre objekt och mer transperans ...18

5.10 Testfall 10 – Skuggor och ljussättning ...19

5.11 Testfall 11 – Adaptiv lösning ...19

6 Analys och Diskussion ...21

6.1 Analys och Diskussion av de enkla testfallen ...21

6.2 Analys och diskussion av de avancerade testfallen ...22

6.2.1 Testfall 6 - Okontrollerad bakgrundsmiljö ...22

6.2.2 Testfall 7 - Ändringar i belysning ...22

6.2.3 Testfall 8 – Övervakning av ett specifikt objekt ...23

6.2.4 Testfall 9 - Mindre objekt och mer transparens ...23

6.2.5 Testfall 10 – Skuggor och ljussättning ...23

6.2.6 Testfall 11 – Adaptiv lösning ...23

7 Slutsats ...24

7.1 Framtida forskning ...24

1

1 Inledning

1.1 Bakgrund

I dagens samhälle blir mer och mer teknik “smart”, därför kan det tyckas naturligt att även övervakningssystem utvecklas i samma riktning. Med dagens kraftfulla processorer och högupplösta kameror kan ett övervakningssystem hantera fler uppgifter med högre precision än tidigare teknik har tillåtit. Många av dessa system har gått från att vara helt analoga där övervakningsfilmen spelades in på kassettband till att bli mer och mer digitaliserade. Genom att överföra uppgiften till ett datorbaserat system kan prestandan ökas och kostnaden minskas.

Övervakningssystemen har idag en viktig roll i dagens samhälle med ett flertal användningsområden. Det mest självklara och mest relevanta för den här studien är ur ett säkerhetsperspektiv för att förhindra eller hjälpa till att identifiera lagbrytare, till exempel vid inbrott och snatteri i affärer (1). Effektiviteten beror i de flesta fall på den mänskliga faktorn, för att ett snatteriförsök skall identifieras eller helt enkelt bevisas krävs det att någon bearbetar bildflödet som kommer in från övervakningssystemen. I takt med den stadigt och ständigt utvecklande teknologin har ett flertal övervakningssystem börjat använda sig av teknik som behandlar och utför diverse operationer på en given bild. Den här teknologin används till exempel i våra mobiltelefoner idag (2).

1.2 Frågeställning

På vilket sätt är det möjligt att med begränsade resurser implementera ett övervakningsystem som kan utföra olika beräkningar beroende på det logiska tillståndet i bildvyn?

1.3 Problemdiskussion

För att kunna besvara frågeställningen krävs det att vi har ett övervakningssystem som kan utföra diverse tester i inomhusmiljöer. I slutändan kommer testerna genomföras med en egenkonstruerad prototyp. Vi har valt att för att kunna hålla deadline och studien på en rimlig nivå så exkluderar vi faktorer som spelar in vid övervakning utomhus som olika årstider och väder. Komplexiteten och omfattningen på prototypen hade ökat avsevärt, därav valet att skapa en prototyp som gör en sak bra istället för en prototyp som gör flera saker mindre bra.

För att testa hur effektiv prototypen är efter en utvecklingsperiod på sex veckor så har vi valt att utföra diverse stresstester och på så sätt identifiera bristerna som finns i prototypen. Testerna ska utgöra grunden till resultatet och avgöra om prototypen är lyckad i den mening att den utför sina funktioner på ett stabilt sätt. Bristerna och

2 andra intressanta resultat kommer sedan analyseras för att komma fram till vad som kan göras för att förbättra och lösa de eventuella problemen.

1.4 Syfte

Syftet med denna studie är att undersöka om det går att implementera ett övervakningsystem som dels har motiondetection och dels kan identifiera fyra olika logiska tillstånd och utifrån dessa utföra ytterligare beräkningar. De logiska tillstånden baseras på förändringar i bilden, till exempel ett logiskt tillstånd kan vara att en given dörr är stängd och i ett annat tillstånd är den öppen. Målet är att uppnå ett flexibelt övervakningsystem som kan appliceras på många olika område för att lösa en mängd uppgifter. Systemet blir en prototyp som utvecklas med begränsade resurser och standardhårdvara. För att utföra denna feasibility study testas prototypen i inomhusmiljöer för att se om systemet klarar av givna uppgifter. Det är även av intresse att utforska prototypens svagheter genom att identifiera dessa genom stress testing. Dessa svagheter jämförs med andra liknande system för att se om det finns gemensamma brister för denna typ av system.

1.5 Avgränsning

För att undvika yttre, störande faktorer som inte går att påverka som solljus och väder beslutades att endast utföra testerna av prototypen i en inomhusmiljö med kontrollerad belysning. Endast en webbkamera används vid testerna. Studien och prototypen tar inte upp inspelning, lagring eller kommunikationen som sker i ett övervakningssystem. Inte heller den etiska och kulturella aspekten av videoövervakning. Det huvusakliga målet är att låta en dator identifiera logiska tillstånd och utifrån dessa reagera på rörelser i bild.

2 Metod

2.1 Prototyp och bibliotek

För att kunna besvara vår frågeställning och studiens syfte så konstrueras en mjukvaruprototyp som testas i olika scenario. Denna metod (3) är vanlig för att enkelt kunna testa och verifiera en del i en tänkt lösning. Genom att skapa en prototyp så är det möjligt att testa den tänkta funktionaliteten och upptäcka fel eller andra missar som utvecklarna kan ha glömt. På detta sätt är det även möjligt att se till att produkten lever upp till kraven som kunden har.

Anledningen till att en prototyp används i denna studie är för att kunna testa och verifiera de tänkta teorierna som bygger på Computer Vision. Genom att skapa prototypen så är det möjligt att implementera exakt de funktioner och logik som krävs för att besvara studiens frågeställning och syfte.

3

För att kunna framställa en prototyp som stresstesterna skulle genomföras med identifierades tre populära programmeringsbibliotek och metoder som stödjer computer vision och image processing. Biblioteken som identifierades var Matlab (4), OpenCV (5)och Aforge (6). Matlab har en utmärkt dokumentation och stöd för att utföra de uppgifter som krävs i studiens prototyp men eftersom det är ett helt obekant språk för oss så valdes detta bort. Att utveckla prototypen i Matlab hade inneburit en extra tidskostnad.

OpenCV är ett bibliotek som används i bland annat Python. När det handlar om computer vision med den bildbehandling i realtid så är OpenCV ett av de mest kraftfulla biblioteken som finns tillgängligt. Dock så innebär konstruktionen av ett användargränssnitt i Python mycket mer jobb än i C# och Visual Studio. OpenCV finns dock tillgängligt som ett bibliotek för .NET och därmed C# under namnet EmugCV. Anledningen till varför OpenCV valdes bort var på grund av den undermåliga dokumentationen.

Aforge valdes för att det ansågs vara tillräckligt för vårt ändamål. Förutsättningarna för att skapa en prototyp som uppfyller studiens kriterier finns och dokumentationen är utmärkt. Biblioteket finns tillgängligt för programmeringsspråket C# och det är tillräckligt kraftfullt för att med enkelhet lösa de uppgifter som krävs i denna studie. Dessutom är C# ett välbekant språk för oss vilket är en avgörande faktor.

2.2 Tester och stresstester

“The purpose of stress testing is to tax the system to a “breaking point” to find bugs that could be potentially harmful. Stress testing is used to ensure that data is not corrupted or lost in the event of such a failure. This kind of testing is vital for Business Continuity and Disaster Recovery planning.“ (7)

Detta är det generella konceptet och meningen med stresstester av mjukvarusystem idag. Det är kritiskt att utföra dessa tester för att försäkra sig om att systemet klarar att utföra sina uppgifter trots att belastningen är högre än normalt. Utan stresstester så kan ett system som är i bruk klara av att köra sålänge den normala och förväntade belastningen råder. Dock så kan problem och buggar snabbt yttra sig så fort belastningen ökar eller något oväntat inträffar. Med ett stresstest så kan dessa problem ringas in och förebyggas innan systemet tas i bruk.

För att undersöka hurvida prototypens kapacitet och studiens frågeställning är möjliga så utförs just tester och stresstester. Genom att utföra detta så är det möjligt att identifiera vad systemet klarar av och vilka svagheter som finns. Att undersöka var systemet brister gör det möjligt att förstå vad det är som leder till problemen och hur dessa kan lösas. Därför är denna typen av tester kritiska för studien.

I studien så pressas inte systemet till den punkten då det kraschar utan till dess att fel börjar att upptäckas. Testerna av prototypen utförs genom att först bekräfta att den tänkta uppgiften kan lösas och därefter försvåras utmaningen till dess att brister eller problem kan identifieras.

4 Genom att granska liknande studier och system så kan en del generella problem identifieras och testas specifikt för denna studie.

2.3 Feasibility Study

Att göra en feasibility study innebär att testa om en idé är gångbar eller ej. Hofstrand och Holz-Clause (8) menar att en feasibility study kan avgöra om det är värt att lägga tid och pengar på en idé eller om det är bättre att välja en annan. Detta är den grundläggande faktorn för denna studie hurvida det är möjligt att implementera övervakningssystemet. Att genomföra denna feasibility study blir dels en bekräftelse och dels en utgångspunkt för vidare forskning

2.4 Metoddiskussion

I denna studie används en prototyp för att besvara frågeställningen och uppnå studiens syfte. Det är dock möjligt att angripa denna studie på andra sätt. Ett av dess tillvägagångssätt är att utföra intervjuer och samtidigt samla fakta från diverse forskningsartiklar. Faktainsamlingen måste då vara ännu djupare än den som har gjort i denna studie. Intervju är en datainsamlingsmetod där en utvald person blir ombedd att svara på frågor angående ett utvalt ämne. Weiss (9) menar att en intervju ger ett fönster till det förflutna där vi som undersöker kan få en inblick hur personen upplevde situationen och vilka känslor som spelade in. Genom att intervjua utvecklare som jobbar med övervakningsystem kan det vara möjligt att ta reda på hurvida det finns en chans att besvara studiens frågeställning. Det är dock omöjligt att verifiera om det verkligen fungerar i praktiken, det som till synes kan se bra ut i teorin. Genom att samtidigt studera tidigare forskning och förstå vad de har stött på för problem och hur de har löst dem så är det möjligt att dra slutsatser vad som kan vara möjligt att implementera. Att använda dessa metodologier istället för en prototyp kan ge en djupare förståelse för övervakningssystem och intervjuer kan vara ett sätt att samla in expertisåsikter kring frågeställningen. Anledningen till att prototyp valdes istället är att den metodologin tillåter forskaren att bekräfta hurvida implementeringen lyckades eller ej. Som tidigare nämnt är det svårare att i en studie som denna dra en fullständig slutsats om det endast finns teoretiskt empiri. Därför passar prototyp som en metod för att besvara frågeställningen i denna studie.

3 Teori

3.1 Tidigare forskning

Förstudien visar att det redan har gjorts en hel del inom det här området. Det är av allmänt intresse att utveckla de gamla övervakningssystemen till nya, smartare system som dels är effektivare och dels kan anpassa sig bättre till att lösa specifika uppgifter. Det har funnits applikationer med inriktning på övervakning som automatiskt identifierar objekt (10). Genom att ha flera kameror kopplade till samma

5 system blir det möjligt att täcka ett större geografiskt område och med hjälp av algoritmer kan ett och samma objekt följas över flera kameravyer.

3.2 Aforge

Aforge.NET Framework (6,11) är ett ramverk som finns tillgängligt till programmeringsspråket C#. Det är ett bibliotek som används inom fält som berör Computer Vision och Image Processing.

3.3 Computer Vision

Computer Vision är samlingsbegreppet för att låta en dator tolka, analysera bilder och därefter utföra beräkningar mot dessa. Detta är ett mycket brett och populärt ämne som på senare tid har expanderats ut till allt från mobiltelefoner, robotar och övervakningssystem (2). Den generella grundprincipen för Computer Vision är att en kamera skickar bilder till en dator som utför beräkningar för att förstå vad som händer framför kameran. Baserat på dessa beräkningar så reagerar datorn och utför därefter uppgifter som kan vara allt ifrån styrning av en robot eller att bara presentera informationen på ett mer tilltalande sätt än bara råa bilder för en användare. Tillväxten av computer vision beror även på att dyr personal kan ersättat av en dator som endast har ett inköpspris samt service- och driftkostnader. Dessutom elimineras fel på grund av den mänskliga faktorn.

Tack vare att dagens teknik tillåter snabbare och kraftfullare datorer till en mindre storlek så kan Computer Vision appliceras på ett bredare fält. Idag kan bilar vara utrustade med kamerasystem som kan hjälpa föraren med körningen och upptäcka potentiella risker. Stillbildskameror har inbyggd ansikts-detektering som bland annat kan utlösa fotograferingsfunktionen när den känner att ett ansikte ler. Maskiner som kan med en kamera skanna av en papperssida med text och därefter läsa upp texten med en syntetröst genom högtalare underlättar livet för personer med lässvårigheter. Detta är bara några få av dagens användningsområde för Computer Vision, som tidigare nämnt så är tekniken inte den begränsande faktorn idag, utan snarare fantasin och statliga regulationer (2).

3.4 Image Processing

Varje bild består av en matris av arrayer där varje array innehåller pixlarna som utgör bilden. Dessa pixlar kan ha olika nyanser och färger. Genom att iterera genom denna matris så kan varje pixel analyseras och jämföras med andra pixlar. I ett övervakningssystem är det viktigt att hitta en balans mellan bildupplösning och kvalité för att uppnå maximal prestanda för den givna uppgiften. Dagens standard för megapixelkameror i övervakningssammanhang ligger på en upplösning av 640x480 pixlar (12). Detta innebär att när bilden ska analyseras ska systemet granska 307200 pixlar och jämföra eller utföra beräkningar på dessa. Detta kan ske upp till 25 bilder i sekunden baserat på kamerans Frame Per Second.

6 För att systemet ska kunna förstå och tolka vad som händer framför kameran måste varje bild analyseras. Detta steg är avgörande för hur systemet ska reagera och vad det ska uppfatta för att lösa den givna uppgiften. Processen för detta blir en iterering som pågår så länge som kamerans videoström kan hämtas. Systemet hämtar videoströmmen från kameran och för varje bild i utförs analyseringen och beräkningarna. Beroende på vilken uppgift som ska utföras av systemet så kan filter appliceras på varje bild för att underlätta processen. Nedan förklaras och illustreras filterna och stegen för bildprocesseringen. Denna process sker varje gång en ny bild hämtas från videoströmmen, detta räknas som en cykel.

Steg 1

Figur 1: Visar aktuella bilden från kamerans videoström

Här hämtas bitmapen från videoströmmen och bilden ovan visar hur den ser ut innan någon manipulation skett. I detta läget så skickas hela eller en del av bitmapen in i en metod som tillsammans med en referensbitmap jämför dessa två pixel för pixel hur bra de stämmer överens. Referensbitmapen är den bild som användaren väljer att ha som ett logiskt läge. Metoden som anropas returnerar ett flyttal som representerar hur många procent matchning där är mellan de två bitmapsen. På detta sätt kan systemet identifiera vilket logiskt läge det befinner sig i. Denna jämförelse görs 1 till 4 gånger för varje bitmap som hämtas ut videoströmmen beroende på hur många logiska lägen användaren har definierat. Den referensbitmap som stämmer mest överens procentuellt sett blir alltså bakgrundsbilden resten av cykeln.

För att öka precisionen i jämförelse kan användaren välja att markera en del av bilden för att endast utföra jämförelsen på detta område.

Steg 2

7 Metoden som senare används för att urskilja förändringar, alltså rörelser i synfältet kräver att de två bilderna som ska jämföras är 8 eller 16 bits per pixel och gråskalade, alltså svårt och vita. För att uppnå detta används filtret Grayscale (13) som finns inbyggt i Aforge. Detta filter returnerar en gråskalad version av den givna bitmapen. Steg 3

Figur 3: Visar exempel på jämförelser mellan bild från videoström med referensbild I detta steg jämförs den aktuella bilden från videoströmmen med referensbilden för att hitta det som skiljer sig mellan dem (14). Varje pixel jämförs med den motsvarande pixeln i den andra bitmapen för att se hur mycket de skiljer sig (15). I denna bild har en hand förts fram framför kamerans synfält. I en webbkamera så kan färgen och nyansen i varje pixel konstant ändras trots att kameran filmar samma scen utan att något i området har ändrats. För att systemet ska kunna bortse från dessa små förändringar i pixlarna så används ett tröskelvärde i jämförelsemetoden. Detta tröskelvärde kan justeras för att eliminera bruset men fortfarande vara tillräckligt känsligt för att upptäcka ett föremål som flyttas. I prototypen som används vid testerna så har användaren möjlighet att via ett skjutreglage ställa in detta tröskelvärde.

Steg 4

Figur 4: Visar exempel på detektering av rörelse

Steg 4 utförs beroende på om användaren har definierat förbjudna zoner i referensbilderna eller inte. De pixlar som utgör rörelsen eller förändringen ringas in i röda rektanglar. Om det finns förbjudna zoner definierade så kontrollerar systemet att

8 dessa röda rektanglar inte förekommer inom det förbjudna området. För att utföra denna kontrollen så används metoden IntersectsWith (16). Denna metod tar emot två rektanglar och returnerar antingen True eller False. Det innebär att om en röd rektangel kommer in på det förbjudna området upptäcks detta av IntersectsWith-metoden.

3.5 Motion Detection

Motion detection (17) kan utföras på olika sätt. Ett sätt för systemet är att identifiera objekt och följa dessa bild för bild, men den vanligaste typen av motion detection är att systemet jämför varje ny bild som hämtas från kameran med en referensbild. Denna jämförelse görs pixel för pixel. Referensbilden kan antingen vara en statisk bild, föregående bild i videoströmmen eller en adaptiv bild som anpassar sig över tiden. En statisk bild är en stillbild som tas och som sedan utgör bakgrunden för scenen, denna bild jämförs med varje ny bild som kommer in från kameran. Varje pixel i de båda bilderna jämförs och om någon avviker registreras detta. På detta sätt kan förändringar i scenen upptäckas och noteras som rörelse. Den andra metoden jämförs varje ny bild från kameran med den föregående bilden. För att uppnå en mer dynamisk jämförelse kan man använda en adaptiv referensbild. Det är en blandning av de två andra metoderna och innebär att referensbilden blir en bakgrundsbild som anpassar sig över tiden. Det vill säga att referensbilden blir en genomsnittsbild av X antal bilder inom tidsloppet T. Genom att använda denna metoden blir referensbilden en dynamisk bakgrund som hela tiden anpassar sig efter omgivningen. Det innebär att om till exempel ljuset i omgivningen ändras över tiden så anpassas referensbilden efter detta.

De olika metoderna för referensbilden har för- och nackdelar som måste avvägas av utvecklaren beroende på vilken uppgift systemet ska utföra och hur omgivningen ser ut. Genom att använda en statisk referensbild så kan systemet bli mycket precist och upptäcka små förändringar i scenen men det kommer att ha problem att hantera förändringar i miljön som inte ska registreras som en avvikelse. Exempel på en sådan förändring kan vara en skugga från solen som faller från ett objekt i bilden, denna skugga kommer att sakta flyttas över tiden efterhand som solen flyttar sig. Systemet med den statiska referensbilden kommer till slut att registrera detta som en rörelse. Genom att använda en adaptiv referensbild så kommer samma scenario inte att utgöra ett problem eftersom denna metoden hela tiden anpassar sig till förändringar i bilden.

9

4 Prototyp

Figur 5: Visar prototypens gränssnitt

Prototypens gränssnitt har nio områden av intresse som bilden ovan visar. Först och främst så finns det en “Live video stream” [område 1] som visar det aktuella bildflödet i realtid. Bildflödet för den här studien kommer från en standardwebbkamera på en windows-pc. Alla tillgängliga kameror som finns installerade på enheten identifieras och presenteras i menyn [område 8].

Intresseområden “Static background 1...4” [område 2, 3, 4, 5] används för att ta stillbilder från bildflödet. Dessa stillbilder utgör referensbilderna vilka systemet använder för att hitta rörelse och förändringar i omgivningen. Stillbildernas funktioner delas upp i två delar för användaren. Den första funktionen är möjligheten att definiera otillåtna regioner på bilden. En jämförelse mellan stillbilden och bildflödet kan identifiera om objekt har visat rörelse inom ramen som användaren ritar upp. Oftast är användaren inte intresserad av hela bildvyn utan bara ett specifikt område. I det här fallet markeras det specifika området genom att rita en blå rektangel som täcker regionen av intresse. Operationen genomförs genom att klicka ned höger musknapp och justera storleken på rektangeln enligt behov. Indikatorn [område 9] visar vilken av stillbilderna som stämmer bäst överens med bildflödet genom att visa en färg.

10 Svart - Static background 1

Röd - Static background 2

Blå - Static background 3

Gul - Static background 4

Genom att justera skjutreglaget [område 6] kan känsligheten för motion detection ändras. Effekten av att öka detta värde minskar känsligheten för förändringar i jämförelsen mellan videoströmmen [område 1] och de fyra olika referensbilderna [område 2, 3, 4, 5].

Figur 6: Visuell illustration av fokuszoner

Jämförelserna sker pixel för pixel och med en markering på stillbilden elimineras ointressanta områden vilket gör att små förändringar lättare kan fångas upp.

Figur 7: Visar meddelandet som signalerar att rörelse har skett i en förbjuden zon Denna bildruta illustrerar meddelandet till användaren då rörelse har identifierats i ett förbjudet område. Baserat på vilket logiskt tillstånd systemet befinner sig i när rörelsen sker skrivs dess nummer ut. I detta fall är det Static background 1, alltså logiskt tillstånd 1.

4.1 Verktyg och utvecklingsmiljö

Prototypen utvecklas i utvecklingsmiljön Microsoft Visual Studio 2010 med programmeringsspråket C# och biblioteket Aforge som komplement. Det grafiska

11 användargränssnittet är designat med standardkomponenter som finns tillgängligt i Visual Studio 2010.

Systemet körs på en bärbar HP-dator med följande specifikationer: - Windows 7 Home Premium

- AMD Turion Dual-Core @ 2.3GHz - 4 GB RAM

- ATI Mobility Radeon HD 5470 Creative Live Cam Video IM VF0220

Tekniska specifikationer för webbkameran (18): 1.3-Megapixel

640x480 VGA sensor 30 FPS Video recording USB-anslutning

5 Testfall och resultat

Testerna som genomförs sker med syftet att verifiera och identifiera brister i applikationen. Testfallen prioriteras efter svårighetsgrader och kategoriseras i mindre delar. Dessa delar består av logiska operationer, identifiering av rörelser och en kombination av dessa. Testerna delas upp i tester mot en ljus/vit bakgrund med hög konstrast till objekten och tester som körs mot en mer realistisk bakgrund där kontrasten mellan objekt och bakgrund är lägre.

5.1 Testfall 1 - Orientering

Första testfallet utförs för att bevisa att prototypen klarar av att utföra grundläggande jämförelser.

Syftet med det här testfallet är att fastställa om applikationen kan avgöra skillnaden på liknande objekt som skiljer sig åt orienteringsmässigt.

12 Figur 7: Visar det korrekta resultatet av testfall med inriktning på orientering

Resultatet av detta testfall visar att systemet klarar av att identifiera vilket logiskt läge som det ska befinna sig i utan svårigheter. Denna slutsats dras baserat på vilka rektanglar som finns med i bild och deras orientering. Vi noterade dock att om rektanglarna flyttades för långt i sid- eller höjdled från dess tänka position så fick systemet svårt att avgöra vilket tillstånd som rådde.

5.2 Testfall 2 - Färg

Det här testfallet följer samma kriterier som föregående testfall med ett par skillnader. Istället för två oranga pappersobjekt ersätts det högra objektet med ett grönt sådant i referensbild 4. Orienteringen på det nya objektet ändras även det till en lodrät position. Syftet med detta är fastställa om applikationen kan skilja på två identiska referensbilder med färg som den enda skillnaden.

Figur 8: Visar det korrekta resultatet av testfall med inriktning på färg

Trots att det endast var färgen på den ena rektangeln som skilde de två tillstånden åt så klarade systemet av att bestämma att tillstånd 4 var det som stämde bäst överens med videoströmmen. Även här noterades att rektanglarnas placering inte får avvika för

13 mycket från deras position i de olika logiska tillstånden. Var denna avvikelse för stor så hade systemet svårt att bestämma det logiska tillståndet.

5.3 Testfall 3 - Användardefinierade fokuszoner

Upplägget på testfall 3 följer exakt samma struktur som det första testfallet. Här introduceras de användardefinierade fokuszonerna vilket gör att en specifik region av bilden markeras. Den markerade regionen blir automatiskt bildytan som jämförs istället för hela bilden. Syftet är se om det sker en förändring i resultaten jämfört med testfall 1. Detta test utförs för att verifiera att de användardefinierade fokuszonerna funkar.

Figur 9: Visar det korrekta resultatet av testfall med inriktning på fokuszoner

Resultatet av detta test visar att systemet klarar av att identifiera vilket tillstånd som råder. De definierade fokuszonerna har ingen påverkan på resultatet i detta test.

5.4 Testfall 4 - Längre avstånd

I testfall 4 ersätts det högra oranga objektet med ett grönt objekt. Avståndet mellan kameran och objekten ändras från 2 meter till 5 meter. Anledningen till detta är för att göra objekten mindre och fastställa om det blir svårare för applikationen att ge ett korrekt svar på jämförelserna.

14 Figur 10: Visar det korrekta resultatet av testfall med inriktning på avstånd

Systemet hade inga problem med att redovisa rätt tillstånd trots den nya avståndsfaktorn.

5.5 Testfall 5 - Rörliga objekt

I detta testet introduceras rörliga objekt för att slå fast om det rörliga objektet identifieras samtidigt som de logiska beräkningarna utförs. Här är även syftet att se om applikationen redovisar korrekt resultat även om det rörliga objektet skymmer synfältet för en av de oranga pappersrektanglarna.

15 Figur 12: Visar ett felaktigt resultat av testfall med inriktning på rörliga objekt

Testet visade att systemet i de flesta fall klarar av att redovisa det korrekta tillståndet även när det finns rörliga objekt i vyn. En brist uppdagades dock när det rörliga objektet bröt synfältet för ett av de statiska pappersobjekten. Applikationen visade ett resultat som stämde bäst överens med referensbild 1 istället för det förväntade resultatet med referensbild 2.

5.6 Testfall 6 - Okontrollerade bakgrundsmiljöer

Från och med detta testfall ändras bakgrunden från att ha en hög kontrast gentemot objekten till en okontrollerad bakgrundsmiljö i form av belysning och störningsobjekt. Omgivningen förändras till en naturlig miljö som i det här fallet är ett klassrum med objekt som bord och stolar.

Syftet med det här testfallet är att definiera två saker. Det ena är att om dörren till klassrummet är öppet så är det tillåtet att rörelse sker i rummet. Om dörren är stängd däremot, så har vi definierat två regioner som markerar otillåtna områden. Om det sker någon rörelse inuti dessa regioner så ska applikationen uppmärksamma detta. Detta kommer gå till som att två referensbilder kommer tas varav det ena har tillståndet öppen dörr och det andra en stängd dörr. Referensbilden med öppen dörr kommer ej att ha några användardefinierade zoner medans referensbilden med stängd dörr innehåller två fokuszoner.

Kamerans position är placerad högt upp i ett av hörnen av rummet för att täcka så stort område av rummet som möjligt.

16 Figur 13: Visar rörelse i bildvyn med en öppen dörr

Figur 14: Visar rörelse i bildvyn med en stängd dörr

Testfallet visade att systemet klarar av att utföra sina beräkningar även i okontrollerade miljöer. I detta fallet var det tillåtet att vistas i rummet när dörren var öppen. Applikationen varnade inte användaren i detta tillståndet. När dörren stängdes och de otillåtna zonerna började att gälla var applikationen pålitlig med att varna användaren så fort rörelse registrerades i de otillåtna zonerna.

5.7 Testfall 7 - Ändringar i belysning

Ett test specifierades för att se hur applikationen beter sig vid plötsliga ändringar i belysning. Upplägget är identiskt med föregående testfall. Skillnaden är att syftet med detta testfall är att notera hur applikationen beter sig vid ändringar i belysning. I det här fallet något enkelt som att tända och släcka en lampa.

Scenariot för detta är att ha alla taklampor tända när dörren är öppen och en av dem släckt när dörren är stängd.

17 Figur 15: Visar ett felaktigt resultat i testfall med inriktning på ändringar i belysning Applikationen klarade av att utföra sina beräkningar i tillståndet med dörren öppen och tänt ljus. I tillståndet med stängd dörr så visade den däremot en tydlig brist då det släckta ljuset identifierades som rörelse i de otillåtna regionerna. Applikationen klarade inte av detta testfallet.

5.8 Testfall 8 – Övervakning av ett specifikt objekt

En viktig aspekt för övervakningssystem är att kunna fokusera på ett objekt som är värdefullt. I detta testfall markeras området kring objektet med en rektangel för förbjudet område. Syftet är att notera vilket resultat applikationen kommer redovisa om föremålet flyttas eller rörs vid.

För att genomföra detta har föregående upplägg använts sett till kamerans position. Ett objekt har placerats på ett av borden och markerats som viktig i applikationen. Testet genomförs när ett främmande objekt försöker flytta på föremålet av intresse.

Figur 16: Visar det korrekta resultatet av testfall med inriktning på övervakning av objekt

18 Testet visar att systemet klarar av att upptäcka om det specifika objektet flyttas eller manipuleras.

5.9 Testfall 9 - Mindre objekt och mer transperans

Upplägget för detta scenario är mycket likt föregående testfall. Det kommer finnas tillfällen då objektet som är värdefullt har en låg kontrast jämfört med bakgrunden. I detta testfall är det markerade objektet en 0.5 liters PET-flaska med transperanta egenskaper. Objektet är litet och har en låg kontrast till bakgrunden. Testet genomförs genom att en person flyttar på flaskan för att se om systemet registrerar förändringen. Syftet är att notera om applikationen märker av denna förflyttning.

Figur 17: Visar upplägget för testfall med inriktning på mindre och mer transperanta objekt

Figur 18: Visar ett felaktigt resultat av testfall med inriktning på mindre och mer transperanta objekt

Applikationen klarade inte av att registrera förflyttningarna av föremålet i detta testfall. Systemet visade brister genom att inte registrera när objektet flyttades.

19

5.10 Testfall 10 – Skuggor och ljussättning

Prototypen som har använts hittills har använt sig av statiska referensbilder. En teori som uppdagades tidigt i utvecklingen var att applikationen skulle få svårt att hänga med när det gäller naturliga ändringar i belysning. Det vill säga att om en referensbild innehåller solljus så kommer den så småningom reagera på rörelser i bilden som beror på att solens position har ändrats.

Kameran är riktad mot en vägg som visar att solljus kommer in via flera fönster. Första fasen i testet är att ta en referensbild och sedan vänta tio minuter för att se om applikationen reagerar på rörelser orsakade av solljuset.

Figur 19: Visar resultatet av testfall med inriktning på skuggor och ljussättningen efter tio minuter

Resultatet uppvisar stora brister i prototypen i de fall där skuggor förflyttas över tiden. Jämförelsen mellan en referensbild som togs tio minuter innan den nuvarande bilden i bildflödet visar felaktiga varningar. Varningarna beror på att skuggorna på väggen ändrar position i takt med att solljuset som kommer in via fönstren ändras i beroende av solens position.

5.11 Testfall 11 – Adaptiv lösning

I detta testfall provas teorin om en adaptiv bakgrundsbild som referensbild. Detta utförs med en liknande prototyp. Om rörelse upptäcks markeras detta med en röd rektangel i bilden. Testet genomförs i samband med testfall 10 och även här är tidsintervallet mellan start och stopp 10 minuter.

20 Figur 20: Visar resultatet från den adaptiva lösningen

Resultatet av testfall 11 visar att den adaptiva lösningen klarar av att hantera de små, men konstanta förändringarna i ljussättningen och skuggorna.

5.12 Identifierade brister och problem

Genom att stresstesta prototypen så kunde några brister och problem identifieras. Dessa presenteras här.

1. Referensobjektets position avviker - Testerna visade att om objekten, till exempel rektanglarna i testerna flyttas för långt från sin position i någon rörelseaxel så kan detta förvirra systemet.

2. Line-of-Sight-brytning - alltså när sikten till objektet som systemet ska övervaka tillståndet hos bryts så ökar risken för felbedömning av systemet. Detta påvisas i testfall 5.

3. Förändringar i ljussättningen. Det visade sig att när en av taklamporna släcktes räckte det för att systemet skulle registrera detta som en rörelse eller förändring. Detta påträffades dels i testfall 7 och i testfall 10.

4. Kamouflerat objekt - I testfall 9 så visade det sig att objekt som har låg kontrast till bakgrunden är svåra att identifiera och spåra för systemet.

21

6 Analys och Diskussion

Testfallen specifierade tidigare i studien kan kategoriseras ytterligare för att framhäva den underliggande strukturen. Dessa nya kategorier kan beskrivas som enkla/lätta/simpla och mer avancerade testfall. De testfall som hamnar i den första kategorin har generellt sett enklare uppgifter och störningsmoment än de mer avancerade testfallen. Uppdelningen är:

Enkla tester

Testfall 1 - Orientering Testfall 2 - Färg

Testfall 3 - Användardefinierade fokuszoner Testfall 4 - Längre avstånd

Testfall 5 - Rörliga objekt Avancerade tester

Testfall 6 - Okontrollerad bakgrundsmiljö Testfall 7 - Ändringar i belysning

Testfall 8 - Värdefulla objekt

Testfall 9 - Mindre objekt, mer transperans och hastighetstest Testfall 10 - Skuggor i konstant rörelse till följd av solljus Testfall 11- Adaptiv lösning

6.1 Analys och Diskussion av de enkla testfallen

Att dessa testfall hamnar i denna kategori baseras på var och hur de utfördes. Att låta systemet identifiera logiska tillstånd baserat på färgade rektanglar mot en ljus bakgrund är en lätt uppgift. Detta tack vare den höga kontrasten mellan objekt och bakgrund. Det innebär att i scenario som liknar dessa ska systemet kunna utföra sina uppgifter med ett lågt antal fel. Det är dock högst osannolikt att ett riktigt scenario har så pass optimal ljussättning, kontraster och låga antal störningsmoment som dessa testfall har.

Omar Javed och Mubarak Shah (10) menar att ett övervakningssystem alltid kommer att ha problem med de dagar då ljussättningen ändras konstant, till exempel molniga dagar. Detta störningsmoment dock har eliminerats i denna studie genom att utföra testerna inomhus.

Det problem som hade störst påverkan på prestandan var i testfall 5, det tillfället då systemets visuella kontakt med referensobjekten bröts av en person som ställde sig i vägen. Detta är ett konstant problem för många övervakningsystem menar Omar Javed och Mubarak Shah (10). En lösning på detta kan vara att implementera ett övervakningsystem där flera kameror används. Shah, Javed och Khurram Shafique (19) utnyttjar fler kameror i deras studie för att dels kunna täcka större ytor och dels för att kunna följa intressants objekt från fler vinklar. Detta minskar sannolikheten att systemets visuella kontakt med ett objekt bryts.

22 Prototypen visade prov på att den klarar av att redovisa korrekt resultat i de flesta fall som involverar kontrast, användardefinierade fokuszoner och rörliga objekt i kontrollerade miljöer med varierande avstånd. Genom att utföra dessa tester och dessutom få positiva resultat innebar att systemet var redo för svårare scenario.

6.2 Analys och diskussion av de avancerade testfallen

Gemensamt för dessa tester är att de genomförs i okontrollerade inomhusmiljöer. Det sker ingen manipulering av belysning eller placering av objekt för att göra systemets beräkningar lättare eller svårare. Eftersom att dessa tester återspeglar en mer realistisk miljö så är det här prototypen provas för mer verkliga situationer. I detta avsnitt analyseras och diskuteras de avancerade testfallen enskilt.

6.2.1 Testfall 6 - Okontrollerad bakgrundsmiljö

I testfall 6 ser vi prov på systemets potential när användardefinierade fokuszoner används. Genom att låta dörren vara referensobjektet för det logiska tillståndet kan systemet utföra rätt beräkningar. Detta testfall kan översättas till följande pseudokod: IF Door is open:

track moving object;

draw rectangle around moving object; IF Door is closed:

track moving object;

draw rectangle around moving object; IF rectangle intersects with forbidden zone

notify user;

Trots den nya bakgrunden och sämre kontraster så klarar systemet ändå sin uppgift. Detta visar att prototypen kan användas i liknande miljöer och för riktiga användningsområde. Problem kan dock uppstå om det referensobjekt som bestämmer det logiska läget kan ha ett mellanläge. I ett optimalt fall har referensobjektet endast ett binärt tillstånd, 1 eller 0, till eller från. Detta är dock inte givet i verkligheten eftersom till exempel en dörr kan ha ett mellanläge, halvöppen/halvstängd. Detta kan leda till en tvetydighet som systemet har svårt att tolka.

6.2.2 Testfall 7 - Ändringar i belysning

Detta testfall bekräftar teorier (10) om att förändringar i ljussättningen i bilden har en negativ effekt på övervakningssystem. Genom att använda en statisk referensbild i jämförelsen för att hitta rörelser som denna prototyp bygger på ökar känsligheten för förändringar i ljuset ännu mer. Genom att implementera en adaptiv referensbakgrund som Javed, Shah och Shafique (19) har i sitt system kan de små förändringarna i ljuset överkommas. Däremot är det svårt att kontra så stora förändringar som testfall 7 innebar. Ett sätt kan vara att ändra tröskelvärdet för rörelsekänsligheten på prototypen, det leder till att förändringar i ljus inte registreras som en rörelse. Att ändra detta tröskelvärde har dock en bieffekt som innebär att systemet missar mindre

23 objekt som kan vara intressanta att följa. Därför innebär tröskelvärdet en avvägning för hur användaren vill att systemet ska reagera.

6.2.3 Testfall 8 – Övervakning av ett specifikt objekt

Genom att utföra testfall 8 visar systemet upp sin förmåga att kunna bevaka ett intressant objekt och larma om detta manipuleras. Det visar även upp hur flexibelt systemet blir genom att låta användaren definiera dels förbjudna zoner och dels fokuszoner där systemet gör jämförelsen för logiska tillstånd.

6.2.4 Testfall 9 - Mindre objekt och mer transparens

I testfall 9 visade det sig att prototypen lider av samma problem med kamouflage som Javed och Shah (10) nämner i deras studie. Den transparenta flaskan smälter in i bakgrunden genom den låga kontrasten mot väggen. Detta är ett problem som är svårt att överkomma i Computer Science. En del av problemet är kamerans upplösning och bildkvalité, denna faktor måste avvägas beroende på resten av systemet. Grgic och Delac (20) menar på att kamerans placering har en avgörande betydelse för resultatet och att kameraupplösningen kontra avståndet till objektet bildar en korrelation. Att använda en kamera med hög upplösning innebär att systemet blir tvunget att analysera fler pixlar vid varje iterering. Detta bidrar till ett långsammare system, speciellt om flera kameror ska användas samtidigt.

6.2.5 Testfall 10 – Skuggor och ljussättning

Testfall 10 bevisar problemet med skuggor och förändringar i ljuset vilka leder till komplikationer i beräkningarna. Trots att detta testfall utfördes inomhus så påverkades det ändå av solljuset. Det är svårt att komma runt det faktum att skuggorna från solens ljus är i konstant rörelse, att försöka att stanna solen ligger bortom denna studies ramar.

6.2.6 Testfall 11 – Adaptiv lösning

Resultatet av testfall 11 visar att svagheterna som identifierades i testfall 10 har förvandlats till styrkor i en alternativ prototyp. I testet jämförde vi hur ett liknande system men med en adaptiv bakgrundsbild (21) klarade solens påverkan på ljussättningen. Resultatet visade tydligt att en adaptiv bakgrund som hela tiden, långsamt anpassas klarar av denna typ av miljö bättre. Det måste dock nämnas att ett objekt som rör sig tillräckligt långsamt inte upptäcks av ett system som har en adaptiv referensbild eller bakgrundsbild. Rör objektet sig tillräckligt långsamt smälter det in i bakgrunden och denna svaghet kan exploateras. Detta är inte möjligt i ett system med en statisk referensbild eller bakgrundsbild.

Resultatet av testerna säger att systemet och konceptet med logiska tillstånd kan fungera om de grundläggande problemen kan överkommas. Trots många brister bevisar prototypen hur anpassningsbart och flexibelt ett övervakningssystem kan bli när en dator utför uppgifterna. Genom att låta användaren själv definiera logiska tillstånd, förbjudna zoner och fokuszoner kan systemet bli mycket mångsidigt.

24

7 Slutsats

Resultaten som har framkommit under studiens gång visar att det finns en stor potential inom ämnen som behandlar computer vision och image processing. Testresultaten uppvisar även att de brister som vi har stött på i vår applikation har varit brister som upptäckts i tidigare studier. Vi är övertygade om att dessa brister kommer överkommas förr eller senare i takt med den ständigt utvecklande teknologin. Syftet med studien var att utveckla en funktionell prototyp med begränsade resurser som främst skulle kunna utföra generella uppgifter i inomhusmiljöer. Bland de primära funktionerna återfanns bland annat beräkningar som behandlade och jämförde olika logiska tillstånd. Genom att använda programmeringsspråket C# och biblioteket Aforge.Net är det möjligt att implementera ett övervakningssystem med kapacitet att känna igen logiska tillstånd och utföra ytterligare beräkningar. Vi anser att prototypen som har framställts motsvarar både de primära och sekundära kriterier som specifierats av oss. Denna slutsats har vi kommit fram till genom den andra fasen i studien, stresstesterna.

Testerna gav oss möjligheten att bedöma hur systemet hade presterat vid applicering i inomhusmiljöer. Det var onekligen så att idéer som förbättrade systemets existerande funktioner och även helt nya tillämpningar föddes under testfasen. En av dessa idéer var, som tidigare nämnt, den adaptiva lösningen som löser problemen med små förändringar i miljön.

Slutligen går det att fastställa teorin om att övervakningsystem med logiska tillstånd är en möjlighet för att uppnå ett mångsidigt och flexibelt system. Det finns dock hinder och problem som måste övervinnas innan det kan användas kommersiellt.

7.1 Framtida forskning

Studien visar att det möjligt att utveckla en fullt funktionell applikation under en utvecklingsperiod på sex veckor och dessutom med begränsade resurser. Bristerna och problemen som framgår genom testerna är en viktig avstamp för framtida studier inom ämnet. Kan dessa överkommas är det möjligt att skapa ett kommersiellt övervakningsystem med stor flexibilitet.

8 Litteraturförteckning

1. Thiel G. Automatic CCTV Surveillance - Towards the VIRTUAL GUARD. Aerospace and Electronic Systems Magazine, IEEE. 2000 July; 15(7).

2. Baksheev A, Erumihov V, Kornyakov K, Pulli K. Realtime Computer Vision with OpenCV. Queue. 2012 April; 10(4).

3. Bowman D. Information Management Architect - What is a Prototyping Methodology? [Online].; 2009 [cited 2013 April 7. Available from:

http://www.information-management-25

architect.com/prototyping-methodology.html.

4. Mathworks. Mathworks - MATLAB. [Online]. [cited 2013 April 7. Available from:

http://www.mathworks.se/products/matlab/.

5. OpenCV. OpenCV. [Online]. [cited 2013 April 7. Available from: http://opencv.org/.

6. Aforge.NET. Aforge.NET Framework. [Online]. Available from: http://www.aforgenet.com/. 7. Tescom. Tescom - Load Testing and Stress Testing. [Online]. [cited 2013 April 7. Available

from: http://www.tescom-intl.com/Our-Solutions/Load-and-Stress-Testing.html.

8. Hofstrand D, Holz-Clause M. IOWA State University - What is a Feasibility Study? [Online].; 2009 [cited 2013 June 3. Available from:

https://www.extension.iastate.edu/agdm/wholefarm/html/c5-65.html.

9. Weiss RS. Learning From Strangers: The Art and Method of Qualitative Interview Studies New York: The Free Press; 1995.

10. Javed O, Shah M. Tracking and Object Classification for Automated Surveillance. In ECCV '02 Proceedings of the 7th European Conference on Computer Vision-Part IV; 2002; London. p. 343-357.

11. Kirillov A. CodeProject - AForge.NET open source framework. [Online].; 2007. Available from: http://www.codeproject.com/Articles/16859/AForge-NET-open-source-framework. 12. Bodell P, Fullerton E. VDTSI. [Online]. [cited 2013 April 7. Available from:

http://www.vdtsi.com/milestone/8.pdf.

13. Aforge.NET. Aforge.NET Framework - Grayscale Filter. [Online]. Available from:

http://www.aforgenet.com/framework/docs/html/d7196dc6-8176-4344-a505-e7ade35c1741.htm.

14. Kirillov A. CodeProject - Motion Detection Algorithms. [Online].; 2007. Available from:

http://www.codeproject.com/Articles/10248/Motion-Detection-Algorithms.

15. Aforge.NET. Aforge.NET Framework - Difference Filter. [Online]. Available from:

http://www.aforgenet.com/framework/docs/html/673023f7-799a-2ef6-7933-31ef09974dde.htm.

16. MSDN. MSDN - Microsoft. [Online]. [cited 2013 April 7. Available from:

http://msdn.microsoft.com/en-us/library/system.drawing.rectangle.intersectswith.aspx. 17. Aforge.NET. Aforge.NET Framework - Motion Detection. [Online]. Available from:

http://www.aforgenet.com/framework/features/motion_detection_2.0.html. 18. XPCGEAR. www.xpcgear.com. [Online]. [cited 2013 April 7. Available from:

http://www.xpcgear.com/vf0220.html.

19. Javed O, Shafique K, Shah M. Automated Visual Surveillance in Realistic Scenarios. MultiMedia, IEEE. 2007 January; 14(1).

20. Delac K, Grgic M, Grgic S. SCface --- surveillance cameras face database. Multimedia Tools and Applications. 2011 February; 51(3).

21. Thorne B. The Python Papers Monograph - Introduction to Computer Vision in Python. [Online].; 2009 [cited 2013 April 7. Available from:

26 22. Javed O, Shafique K, Shah M. Automated Visual Surveillance in Realistic Scenarios. IEEE