Ontwikkeling van een beeldverwerkingsalgoritme om voertuigen te tellen

Hogeschool West-Vlaanderen Master Industriële Wetenschappen: Electronica-ICT Voorzitter: prof. ir. F. De Pauw

Ontwikkeling van een beeldverwerkingsalgoritme om voertuigen te tellen door Jasper Desmadryl

Promotoren: prof. ir. F. De Pauw, Howest ing. Koen Janssens, Traficon dr. Stefan Schulte, Traficon

Scriptie ingediend tot het behalen van de academische graad van Master in de Industri¨ ele Wetenschappen: elektronica-ICT optie MIT Academiejaar 2012–2013

VOORWOORD

i

Voorwoord Toen ik vorig jaar de omschrijving van deze masterproef las, was de keuze snel gemaakt. Ik ben de laatste jaren vaak ge¨ıntrigeerd geweest bij het zien van computervisie applicaties en door deze masterproef heb ik er enorm veel over kunnen bijleren. Het was een druk jaar, maar het heeft me veel voldoening gegeven. Er zijn tal van mensen die, elk op hun manier, hun steentje hebben bijgedragen en die ik wil bedanken. In de eerste plaats Koen Janssens, m’n promotor bij Traficon. Hij heeft het project op de voet gevolgd en beantwoordde m’n talloze vragen telkens klaar en duidelijk. Ook aan Stefan Schulte en de andere werknemers in Traficon heb ik veel gehad. Hun interesse en feedback waren erg belangrijk voor me. Verder wil ik Filip De Pauw, m’n promotor bij Howest, bedanken om m’n masterproef te begeleiden. Hij had het erg druk, maar was toch altijd bereid om de presentaties bij te wonen en de scriptie na te lezen. Tenslotte bedank ik m’n ouders voor de steun en m’n vrienden voor het leuke jaar.

Jasper Desmadryl, juni 2013

TOELATING TOT BRUIKLEEN EN PUBLICATIE OP DSPACE

ii

Toelating tot bruikleen en publicatie op DSpace

“De auteur geeft de toelating deze scriptie, evenals alle nuttige en praktische informatie omtrent deze scriptie, op te nemen in een daartoe speciaal opgezette DSPace databank (http://dspace.howest.be) en deze databank via internet toegankelijk te maken voor alle mogelijke ge¨ınteresseerden. De auteur geeft eveneens toelating de scriptietekst te gebruiken voor afgeleide producten, zoals daar zijn: abstractenverzamelingen en catalogi. Tenslotte geeft de auteur ook de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie.”

Jasper Desmadryl, juni 2013

Ontwikkeling van een beeldverwerkingsalgoritme om voertuigen te tellen door Jasper Desmadryl Scriptie ingediend tot het behalen van de academische graad van Master in de Industri¨ ele Wetenschappen elektronica-ICT: optie MIT Academiejaar 2012–2013 Promotoren: prof. ir. F. De Pauw, Howest ing. Koen Janssens, Traficon dr. Stefan Schulte, Traficon Hogeschool West-Vlaanderen Associatie Universiteit Gent Master Industriële Wetenschappen: Electronica-ICT Voorzitter: prof. ir. F. De Pauw

Samenvatting Verkeer en transport is en blijft een belangrijk onderdeel van onze samenleving. In België bijvoorbeeld, verzamelt het agentschap wegen en verkeer al een tiental jaar allerhande informatie over de wegen. Die gegevens bevatten onder meer tellingen van voertuigen, reistijden, bezettingsgraden, . . . Na analyse kan dit alles helpen om verkeersstromen beter en efficiënter te sturen. In deze masterproef concentreren we ons op het tellen van voertuigen. Nu worden voertuigen meestal gedetecteerd met behulp van inductieve lussen die in het wegdek zitten. Deze gaan echter snel stuk bij vriesweer of wanneer er regelmatig zware voertuigen over rijden. Traficon, een West-Vlaamse KMO gespecialiseerd in video-analyse, heeft hiervoor een alternatief ontwikkeld. Ze ontwikkelden voor deze taak beeldverwerkingsalgoritmes die kunnen draaien op intelligente camera’s. Dit is een goedkopere en minder intrusieve methode die bovendien betrouwbaarder is. Maar ook met deze methode zijn nog een aantal problemen. De camera’s moeten bijvoorbeeld vooraf gekalibreerd worden. Het is nodig om detectievakken op het beeld te plaatsen die de rijstroken waar de voertuigen passeren markeren. Het nadeel van deze methode

is dat het algortime onvoorspelbaar gedrag vertoont als bestuurders tussen 2 rijstroken inrijden, bijvoorbeeld tijdens het inhalen. Het voertuig wordt dan met wat geluk toch correct gedetecteerd, maar vaak resulteert dit in valse detecties. Het zorgt er ook voor dat het algoritme onbruikbaar is op wegen waar rijstrookmarkeringen minder nadrukkelijk aanwezig zijn of waar bestuurders ze negeren. Tijdens deze masterproef ontwikkelen we een beeldverwerkingsalgoritme dat deze problemen probeert te verhelpen. Tijdens de initiële fase worden, op basis van de literatuurstudie, verschillende algoritmes uitgeprobeerd en geëvalueerd. Deze evaluatie gebeurt op een geautomatiseerde manier met behulp van ground truth data afkomstig van geannoteerde videobestanden. Uiteindelijk wordt gekozen voor een methode op basis van voorgrond/achtergrond segmentatie. Met deze methode kunnen de bewegende delen (de voertuigen) uit elk videoframe in realtime worden achterhaald. Na de segmentatie volgen nog verschillende andere onderdelen die bijvoorbeeld de blobs analyseren en tracken. Ten slotte gebeurt het tellen op basis van een aantal condities waaraan de blob moet voldoen. Als dit het geval is, wordt de blob als geteld gemarkeerd zodat hij in volgende frames niet opnieuw wordt geteld. In een volgende stap wordt het beste algoritme op de TrafiCam ge¨ımplementeerd. Dit is een camera van Traficon met zowel een cameramodule en een verwerkingseenheid in één behuizing. Hier worden nog een aantal optimalisaties uitgevoerd zodat het algoritme snel genoeg is om op het embedded systeem de frames te verwerken. We kunnen besluiten dat deze vernieuwende methode om voertuigen te detecteren de vermelde problemen oplost. De kalibratie wordt overbodig en de voertuigen worden betrouwbaarder geteld als ze tussen rijstroken inrijden. Onze methode creëert echter ook een aantal nieuwe problemen die met de beperkte rekenkracht op een embedded systeem moeilijk op te lossen zijn. Een correcte detectie van voertuigen is cruciaal voor de verdere onderdelen in het algoritme. Soms worden voertuigen die dicht bij elkaar rijden tijdens de segmentatie als één bewegend object gezien waardoor er een voertuig te weinig wordt geteld. De detectie verloopt ook moeilijk als de voertuigen traag rijden. Hierdoor gaan ze geleidelijk aan deel uitmaken van de achtergrond. Er zijn dus zeker nog mogelijkheden voor verder werk, maar de nieuwe methode die door ons werd ontwikkeld is zeker en vast een stap in de goeie richting om videosurveillance betrouwbaarder te maken.

Trefwoorden Traficon, verkeersanalyse, beeldverwerkingsalgoritme, realtime, voertuigdetectie, telling

Development of an image processing algorithm to count vehicles Jasper Desmadryl Supervisor(s): prof. ir. F. De Pauw, ing. Koen Janssens, dr. Stefan Schulte Abstract—Because transportation is such an important part of our society, it’s useful to gather statistical information about it. This data can be used to see where new investments are needed or to optimise traffic flows. Our goal is to build a reliable video surveillance application to count vehicles along highways. For this task, we develop an image processing algorithm that is capable of running in real-time on an embedded system. Our approach fixes numerous problems with the methods in use today, partly because of the high level localisation of vehicles. Keywords— Traficon, video surveillance, image processing algorithm, real-time, vehicledetection, embedded systems

I. I NTRODUCTION OWADAYS , vehicle counting is mainly performed with inductive loops. However, there are two big disadvantages with this method. First, the road has to be closed to install them. Second, they break easily in freezing weather or by heavy vehicles. Traficon, a small business from West Flanders, built an alternative solution to detect these vehicles. They made an intelligent camera that can capture images of the road and process them onboard. By doing this, they created an easy to install product that has shown to perform better. There are still some difficulties though. Every new camera has to be calibrated so the algorithm knows where to expect the vehicles (an installer has to mark the lanes). Furthermore, false detections can occur when a vehicle rides between two lanes. Our approach copes with both problems. An algorithm is proposed that is lane independent and requires no calibration. In the algorithm, the vehicles are located first. After that, they are tracked between frames and finally they are counted. We started by creating a prototype to test existing algorithms for localisation. These were evaluated with a custom made test framework. Based on the results of this, the best algorithm was ported to the TrafiCam, i.e., the brand name of one of the camera’s of Traficon. The reminder of this abstract is as follows. In section II we show how our algorithm is structured and give our motivation behind the various design choices. The results are discussed in section III. Finally, section IV ends this paper with the conclusions and points out directions for future work.

N

II. M ETHOD A. Localisation Like in most image processing algorithms, our first task is to localise the objects of interest. The literature defines two big groups of algorithms for this. On the one hand, we have the appearance-based methods and along the other, the motionbased methods. In our case, an appearance based algorithm would train a

model of a vehicle. That model can be used to search for vehicles in each video frame. Popular algorithms are based on Haar features[1] and histogram of oriented gradients[2]. These methods deliver, depending on the quality of the model, very good results. But they are unfortunately not fast enough to run on an embedded system like the TrafiCam. The other group, i.e. the motion-based methods, are a lot faster. Actually, these algorithms don’t vehicles. They detect moving objects, but that’s almost the same since we have prior knowledge of the environment. By using information from several frames, these methods first construct a background model (figure 1b). The absolute difference between the background and each new frame gives us the foreground image. By thresholding it we get a binary image that is white at moving objects and black otherwise (figure 1c).

(a) Frame

(b) Background

(c) Foreground

Fig. 1: Foreground/background segmentation Several methods to construct a background model were evaluated during the development of the prototype. Each method has its advantages and disadvantages. We focus on the fast algorithms with a linear complexity, like the running average method[3], the approximate median[4] and the running gaussian[5]. These perform the segmentation sufficiently well. The foreground is further enhanced by applying a median filter with a 3 × 3 kernel. Prior to the segmentation, each incoming frame is downsampled (with a factor 6) using the nearest neighbour technique to speed up the process. B. Blob analysis The next step of the algorithm is to describe the blobs from the segmentation. You can see the result from this in figure 2b. Each blob is described with a bounding box and a center of gravity. It’s computational expensive to calculate these descriptors on the whole frame. Therefore, it’s compressed first (lossless) with a run-length encoding scheme. Each continuous row of white pixels is represented with a start coördinate and a length, which we call a run. After that, the runs are labeled with some number such that each pair of connected runs has the same one. Two runs on consecutive rows are defined as ’connected’ with equation (1).

the direction in which the vehicle is heading. The given predicate is made for cars that drive away from the camera. This is calculated on the basis of the previous positions of the blob. A vehicle is eventually marked as counted if he crosses a virtual line on the image. The line is placed in the middle of the screen since the blobs are most visible there. III. R ESULTS (a) Original frame

(b) Blobs

The algorithm is evaluated using ground truth data coming from several annotated videos. This data was stored in a xml Fig. 2: Blob analysis file and contains a node for each detected vehicle together with several attributes (detection time, lane number, type, . . . ). The This was constructed in a way so that we get 8-connected pixels. time at which the algorithm detects a vehicle is checked against Note that because the image is compressed, it’s not necessary to the entries in the ground truth. If a vehicle was seen by the algorithm and it’s also in the associate a label with each pixel separately. This is advantaground truth, we have a true positive. This is the ideal case. geous for the processing time and memory usage. When the algorithm misses a vehicle, we have a false negative. If it counts one that isn’t there, we have a false positive. This Connected = RunBelow.Left() ≤ CurrRun.Right() + 1 AND data can further be analysed by calculating the sensitivity (3) and the precision (4). RunBelow.Right() ≥ CurrRun.Left() − 1 (1) TP (3) Sensitivity = Now that each blob has a unique number, it’s possible to calTP + FN culate the descriptors. The bounding box can be found by iterTP Precision = (4) ating the runs associated with the blob and storing the extremes TP + FP (leftmost, top, rightmost and bottom). The center of gravity can Several algorithms with varying parameters were evaluated in be found with the two first moments and the zeroth. If the zeroth moment (the number of white pixels) is smaller than 500, this way on a HPC. On average, a segmentation with the running average method and a threshold of 60 gives the best results. On the blob is ignored because it’s too small to be a vehicle. This concludes the spatial processing of the frame. The last the 4 challenging testvideos, we obtain a precision of 86.27% two steps are both temporal because information from several and a sensitivity of 90.39%. frames is used. IV. C ONCLUSION AND FUTURE WORK C. Tracking By using prior knowledge of the environment, we were able Localising and counting the vehicles in each individual frame to detect the vehicles in real-time using a background segmentais not enough because we should only count the unique vehicles. tion. The real-time constraints were achieved by downsampling In order to do that, the vehicles have to be tracked. This means the frames and by compressing the foreground early on. The performance can be increased by tuning more parameters that for each detected vehicle in the current frame, the correand adjusting the tracker. The latter can be improved by matchsponding one in the previous one has to be found. If a match is ing blobs against a predicted location or by adding extra features found, information about the previous states of the blob can be to the blob for disambiguation. At a later stage, additional infortransferred. mation like the speed of the vehicle, the lane and the type can be Finding those corresponding vehicles is done by location. Becalculated after detection. cause if two blobs are close to each other, chances are high that they match. The same distance measure, i.e. the bounding box R EFERENCES distance, as in [6] is used for this. D. Counting A blob is counted if it satisfies the following conditions: NewCar = (NOT Track[i].Counted) AND (Track[i].Direction.Y < 0) AND (Track[i].PreviousCentroid.Y > Line) AND (Track[i].Centroid.Y ≤ Line) (2) The first condition states that each previously counted blob can be safely ignored. The other 3 conditions are dependent on

[1] P. Viola and M. Jones, “Rapid object detection using a boosted cascade of simple features,” Proceedings of the 2001 IEEE Computer Society Conference on Computer Vision and Pattern Recognition. CVPR 2001, vol. 1, pp. I–511–I–518, 2001. [2] R. Willems, “Evaluatie van een beeldverwerkingsalgoritme voor de detectie van fietsers door middel van Histograms of Oriented Gradients,” M.S. thesis, Katholieke Hogeschool Sint-Lieven, 2012. [3] Chia-Jung Pai, Hsiao-Rong Tyan, Yu-Ming Liang, Hong-Yuan Mark Liao, and Sei-Wang Chen, “Pedestrian detection and tracking at crossroads,” Pattern Recognition, vol. 37, no. 5, pp. 1025–1034, May 2004. [4] Liang Wang, Tieniu Tan, Huazhong Ning, and Weiming Hu, “Silhouette analysis-based gait recognition for human identification,” Pattern Analysis and Machine . . . , vol. 25, no. 12, pp. 1505–1518, 2003. [5] Christopher Richard Wren, Ali Azarbayejani, Trevor Darrell, and Alex Paul Pentland, “Pfinder : Real-time tracking of the human body,” vol. 19, no. 7, pp. 780–785, 1997. [6] Andrew Senior, Arun Hampapur, and YL Tian, “Appearance models for occlusion handling,” Image and Vision . . . , 2006.

INHOUDSOPGAVE

vii

Inhoudsopgave Voorwoord

i

Toelating tot bruikleen en publicatie op DSpace

ii

Overzicht

iii

Extended abstract

v

Inhoudsopgave

vii

Gebruikte afkortingen

ix

1 Inleiding 2 Literatuurstudie 2.1 Lokalisatie van voertuigen . . . . . 2.1.1 Appearance-based methods 2.1.2 Motion-based methods . . . 2.1.3 Besluit . . . . . . . . . . . . 2.2 Tracking . . . . . . . . . . . . . . . 2.3 Besluit . . . . . . . . . . . . . . . .

1

. . . . . .

3 Ontwerp 3.1 Prototype . . . . . . . . . . . . . . . 3.1.1 Keuze programmeeromgeving 3.1.2 Motivatie . . . . . . . . . . . 3.1.3 Verkenning . . . . . . . . . . 3.1.4 Implementatie . . . . . . . . . 3.1.5 Besluit . . . . . . . . . . . . . 3.2 TrafiCam . . . . . . . . . . . . . . . 3.2.1 Hardware . . . . . . . . . . . 3.2.2 Constraints . . . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

3 3 3 5 11 11 13

. . . . . . . . .

14 14 14 15 16 17 18 18 18 19

INHOUDSOPGAVE 3.3

viii . . . . . . . . . . .

21 21 22 23 24 24 25 26 28 29 30

. . . . . . . .

31 31 31 33 36 38 39 40 42

5 Besluit en toekomstperspectieven 5.1 Verbeteringen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Toevoegingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43 44 44

A Resultaten per video

46

Bibliografie

49

Lijst van figuren

51

3.4

3.5 3.6 3.7

Voorgrond-achtergrond segmentatie 3.3.1 Technieken . . . . . . . . . 3.3.2 Downsampling . . . . . . . 3.3.3 Postprocessing . . . . . . . Blob vorming . . . . . . . . . . . . 3.4.1 Run-length codering . . . . 3.4.2 Labeling . . . . . . . . . . . 3.4.3 Blobs . . . . . . . . . . . . . Tracking . . . . . . . . . . . . . . . Tellen . . . . . . . . . . . . . . . . Besluit . . . . . . . . . . . . . . . .

4 Resultaten 4.1 Prototype . . . . . . . . . . 4.1.1 Geannoteerde video’s 4.1.2 Vergelijking . . . . . 4.1.3 Rapport . . . . . . . 4.2 TrafiCam . . . . . . . . . . 4.2.1 Offline-GUI . . . . . 4.2.2 Online (in the field) . 4.3 Besluit . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . .

. . . . . . . .

GEBRUIKTE AFKORTINGEN

Gebruikte afkortingen Blob

Binary large object

CImg

C++ Template Image Processing Toolkit

CMOS

Complementary metal-oxide-semiconductor

CPU

Central processing unit

Codec

Coder-decoder

FN

False negative

FP

False postive

GT

Ground truth

HOG

Histogram of oriented gradients

HPC

High performance computer

HTML

HyperText markup language

KMO

Kleine of middelgrote onderneming

LSB

Least significant bit

NumPy

Numeric python

OpenCV

Open source computer vision library

PIL

Python imaging library

REPL

Read-eval-print loop

RTSP

Real Time Streaming Protocol

SciPy

Open source library of scientific tools

SIFT

Scale-invariant feature transform

SSH

Secure shell

ix

GEBRUIKTE AFKORTINGEN TP

True positive

UML

Unified modeling language

VOC

Visual object classes

VXL

Vision-something-libraries

XML

Extensible markup language

x

INLEIDING

1

Hoofdstuk 1 Inleiding Verkeer en transport is en blijft een belangrijk onderdeel van onze samenleving. In België bijvoorbeeld, verzamelt het agentschap wegen en verkeer al een tiental jaar allerhande informatie over de wegen. Die gegevens bevatten onder meer tellingen van voertuigen, reistijden, bezettingsgraden, . . . Na analyse kan dit alles helpen om verkeersstromen beter en efficiënter te sturen. In deze masterproef concentreren we ons op het tellen van voertuigen. Er wordt een nieuw algoritme geschreven die een aantal problemen verhelpt met het algoritme dat momenteel bij Traficon1 in gebruik is. Momenteel worden voertuigen vooral geteld met behulp van inductive loops (figuur 1.1a). Dit zijn metalen lussen die onder het wegdek zitten, meestal ter hoogte van open afritten. Hierdoor vloeit een stroom die een magnetisch veld opwekt. Wanneer een voertuig over de lus rijdt, wordt dat veld verstoord waarop vervolgens een detector reageert. Het is echter een nadeel dat de weg telkens moet worden afgesloten om deze lussen te plaatsen. Bovendien gaan ze ook snel stuk door de zware voertuigen die van de weg gebruik maken of de vrieskou in de winter. Daarom worden deze inductieve lussen vaak vervangen door camera’s. Traficon biedt hiervoor een goedkope oplossing. De camera’s zijn snel te plaatsen en je kan er bovendien meer en betrouwbaarder informatie mee verzamelen (figuur 1.1b). Maar ook hier zijn er nog een aantal verbeteringen mogelijk. Vooraleer de detectie kan starten, moeten de camera’s gekalibreerd worden. Er moeten onder andere detectievakken op de rijbaan worden gelegd zodat het algoritme weet waar de voertuigen passeren. Hierdoor is het algoritme afhankelijk 1

West-Vlaamse KMO gespecialiseerd in videoanalyse voor verkeerstoepassingen. traficon.be), op 29 december 2012 overgenomen door FLIR Systems, Inc.

(http://www.

INLEIDING

(a) Inductieve lus in het wegdek

2

(b) Camera’s langs de weg

Figuur 1.1: De 2 meest gebruikte methoden om voertuigen te detecteren van de rijstroken en kan het onvoorspelbaar gedrag kan vertonen als voertuigen hiertussen rijden. Dit kan bijvoorbeeld voorkomen tijdens het inhalen van een ander voertuig. Soms wordt het voertuig dan 2x geteld, andere keren helemaal niet. Dit heeft verder als gevolg dat het algoritme onbruikbaar is op wegen waar rijstrookmarkeringen minder nadrukkelijk aanwezig zijn of waar bestuurders ze negeren. Tijdens deze masterproef wordt onderzoek gedaan naar een vernieuwend algoritme om voertuigen te tellen dat onder andere rijstrookonafhankelijk is en geen kalibratie vereist. In het volgende hoofdstuk wordt een overzicht gegeven van de huidige technieken om voertuigen te lokaliseren en te tracken. Hoofdstuk 3 gaat dieper in op de ontwikkeling van het algoritme door alle onderdelen ervan te bespreken. Vervolgens wordt het algoritme geëvalueerd aan de hand van ground truth data afkomstig van geannoteerde opnames. Tenslotte wordt een besluit geformuleerd en bespreken we nog een aantal mogelijke verbeteringen.

LITERATUURSTUDIE

3

Hoofdstuk 2 Literatuurstudie Om voertuigen te tellen moet in elk frame telkens de locatie van iedere auto, moto, vrachtwagen, . . . gekend zijn. Voor mensen is dit in de meeste gevallen bijzonder makkelijk, maar voor computers is dit nog vaak een uitdaging. Onderzoek naar nieuwe algoritmen wordt aangemoedigd door tal van wedstrijden betreffende objectdetectie, waarvan de Pascal VOC challenge de bekendste is. In 2.1 worden 2 methodes besproken om voertuigen te lokaliseren. Eens de locatie gekend is, moeten voertuigen worden getrackt tussen frames om op een hoger niveau te kunnen redeneren. Dit wordt besproken in 2.2.

2.1 2.1.1

Lokalisatie van voertuigen Appearance-based methods

Appearance-based methoden maken gebruik van visuele informatie om een bepaald object te lokaliseren. Een auto van langs achteren gezien heeft bijvoorbeeld altijd 2 wielen, 2 achterlichten, een nummerplaat, . . . Deze informatie kan in een model gegoten worden en door het met een willekeurige afbeelding te vergelijken kan de locatie van iedere auto worden gevonden. De eerste stap van deze methode is het opstellen van het model met een classifier. Dit moet éénmalig gebeuren en staat los van de detectie. Zo’n model kan automatisch gecreëerd worden door het te trainen met honderden afbeeldingen. Het is belangrijk dat de afbeeldingen in je trainingsset van goeie kwaliteit zijn en dat er ook afbeeldingen tussen zitten die het object niet bevatten. Uit iedere afbeelding worden kenmerkende eigenschappen of features opgeslagen. Daarna probeert de classifier een verband te zoeken tussen de features uit de

2.1 Lokalisatie van voertuigen

4

afbeeldingen die het object bevatten en de features uit de afbeeldingen die het object niet bevatten. In het Viola-Jones detectieframework, de eerste detector waarmee goeie resultaten werden behaald, worden Haar features gebruikt[1]. Andere feature descriptors zijn histogram of oriented gradients[2], histogram of optical flow, . . . In figuur 2.1 zie je een aantal modellen die werden opgesteld met HOG features.

Figuur 2.1: Enkele HOG modellen

Met het model kunnen de objecten gevonden worden in een afbeelding of videoframe. De eenvoudigste manier om dit te doen is aan de hand van een sliding window. Het model wordt over de afbeelding geschoven en er wordt gezocht naar plaatsen waar ze sterk overeenkomen. In figuur 2.2 zie je een voorbeeld van een fietserdetectie.

Figuur 2.2: Sliding window methode met HOG model

Samen met een goed model kan deze methode zeer goede resultaten behalen. Het grote nadeel is echter dat het erg rekenintensief is. Daarbovenop heb je met 1 model niet genoeg.


5

Je hebt een model nodig per soort object dat je wil detecteren. Dus om voertuigen te lokaliseren heb je een apart model nodig voor auto’s, bestelwagens, vrachtwagens, . . . Er moeten eventueel ook nog extra modellen gemaakt worden voor de verschillende kijkrichtingen. Zelfs met de vele optimalisaties die de laatste jaren werden gevonden, is deze methode niet geschikt om realtime te draaien op een embedded systeem.

2.1.2

Motion-based methods

Motion gebaseerde methoden pakken het lokalisatieprobleem anders aan dan de appearance gebaseerde. We modelleren een voertuig als een object met een bepaalde grootte dat zich lineair voortbeweegt. Dit is een drastische veralgemening want alles dat beweegt wordt in dit geval als voertuig gezien. Doordat we weten dat de camera enkel in verkeerssituaties wordt gebruikt, is dit aanvaardbaar. Het wordt straks duidelijk dat door deze veralgemening de posities van de voertuigen op een efficiënte manier kunnen gevonden worden. Segmentatie Om de locatie van de bewegende objecten (de voertuigen) te vinden, heb je sowieso informatie nodig uit meerdere frames. Als je een aantal opeenvolgende videobeelden bekijkt, zal het opvallen dat een groot deel van de pixels weinig variëren in de tijd. Deze statische pixels noemen we de achtergrond. Hiertoe behoren bijvoorbeeld de rijbaan, de lucht, de vegetatie, . . . Wat ons meer interesseert, is de voorgrond. Dit zijn de gebieden waar beweging plaats vindt. Een voorgrond/achtergrond segmentatie is een veel gebruikte techniek om de voorgrond van de achtergrond te scheiden. Het resultaat is een binaire afbeelding met pixels die ofwel 0 (achtergrond) of 1 (voorgrond) zijn. De eerste stap is het vinden van de achtergrond. Eens die is gekend, kunnen we gemakkelijk de segmentatie uitvoeren. In vergelijking (2.1) zie je dat we de pixel op 1 zetten als er een groot verschil is tussen het huidig frame I en de achtergrond B. In het simpelste geval is T een constante die experimenteel werd bepaald. In [3] gebruiken ze een lokale threshold Tij , gelijk aan 2.5 keer de standaarafwijking op die positie.  1 |I − B | > T (voorgrond) ij ij Fij = (2.1) 0 otherwise (achtergrond)


6

In figuur 2.3c zie je het resultaat van een segmentatie. Een goeie schatting van de achtergrond is essentieel om een goed resultaat te krijgen. Er bestaan heel wat methoden om de achtergrond te vinden. We bespreken eerst de moeilijkheden die hiermee gepaard gaan en geven dan een overzicht van de meest gebruikte methoden.

(a) Huidig frame

(b) Schatting achtergrond

(c) Segmentatie voorgrond

Figuur 2.3: Segmentatie

Het vinden van een goeie achtergrond is niet evident als er voorgrondobjecten zoals auto’s zichtbaar zijn. Hoe kun je immers weten wat er achter dat object zit? Als je de momentopname bekijkt, is dit inderdaad onmogelijk. Daarom gaan we informatie uit meerdere frames gebruiken om de achtergrond te modelleren. Als we aannemen dat de achtergrond het grootste deel van de tijd in beeld is, kunnen we met een aantal statistische operaties een goeie schatting vinden. Eens de achtergrond is gekend, moet hij nog altijd worden ge¨ update met informatie uit de nieuwe frames. Door een plotse of een graduele lichtsverandering zou het model immers verouderd kunnen raken waardoor het niet meer representabel is. In (2.2) zie je een methode die de achtergrond éénmalig leert door het gemiddelde te nemen van de eerste k frames. Deze simpele methode werkt het best als er tijdens de leerfase geen voorgrondobjecten in beeld komen. k

1X Iij Bij = k i=1

(2.2)

Zoals gezegd is het beter om ons achtergrondsmodel constant te updaten met informatie uit het nieuwe frame. In [4] wordt hiervoor een running average filter gebruikt. Bij = (1 − α) ∗ Bij + α ∗ Iij

(2.3)


7

In vergelijking (2.3) is α de learning rate. Dit is het aandeel van het nieuwe frame dat in de achtergrond wordt opgenomen. Het is de bedoeling dat er een mooi gemiddelde ontstaat waar weinig te zien is van voorgrondobjecten. We kunnen de achtergrond ook vinden aan de hand van de mediaan van de laatste L frames[5]. Dit is een goeie benadering als de achtergrond langer dan L/2 frames zichtbaar was en dat is wel meestal zo. Veel frames bijhouden op een embedded systeem is echter niet haalbaar en daarom werd een benadering voorgesteld. Er wordt een schatting gemaakt van de mediaan (initieel 128) die volgens (2.4) wordt aangepast. De achtergrond B is dan gelijk aan M .     Mij + 1 if Iij > Mij (2.4) Mij = Mij − 1 if Iij < Mij    Mij otherwise In de vorige 2 methodes zullen traag bewegende voorgrondobjecten het achtergrondmodel gaan vervuilen. In extreme gevallen zal het voorgrondobject zelfs worden opgenomen in de achtergrond. Om dit te voorkomen kan er een terugkoppeling gemaakt worden van het segmentatieresultaat zodat de achtergrond conditioneel wordt ge¨ update. In [6] wordt dit een relevantie feedback genoemd. In vergelijking (2.5) zie je een mogelijke implementatie van deze verbetering.  update(B , I , α) F == 0 ij ij ij Bij = (2.5) Bij otherwise De achtergrondpixel wordt enkel ge¨ update als het de vorige keer ook als achtergrond werd geclassificeerd. Om te voorkomen dat een pixel vast komt te zitten als voorgrond kan de achtergrond op die positie toch om de 5 a` 10 iteraties op de normale manier worden aangepast. De vorige 2 methodes werken snel, zijn adaptief en geven goeie resultaten. In sommige gevallen is het wel een probleem dat er maar 1 model voor de achtergrond wordt gebruikt. Stel dat we een bepaalde pixel in de buurt van een boom observeren, dan kunnen we misschien 3 clusters van veelvoorkomende waarden onderscheiden: het groen van een blaadje, het bruin van de stam en het blauw van de lucht. Maar toch moeten ze allemaal als achtergrond worden geclassificeerd. In [7] wordt een mixture of gaussians gebruikt om meerdere achtergrondmodellen bij te houden. Iedere pixel wordt beschreven als een combinatie van maximum k gaussiaanse functies. In de segmentatiestap worden de pixels uit het huidige


8

frame vergeleken met de gaussiaanse functies. Als ze niet in de buurt liggen, worden ze als voorgrond geclassificieerd. Dit is 1 van de meest gebruikte segmentatiemethoden en in [8] wordt een survey gedaan over alle varianten en verbeteringen. De besproken methodes worden vaak toegepast omdat ze snel zijn en laag in geheugenverbruik. Er bestaan echter nog een aantal andere methodes. Vaak worden gelijkaardige resultaten behaald als met de mixture of gaussians. Enkele voorbeelden zijn kernel density estimators[9], wallflower[10], eigenbackgrounds[11] en de recent ontwikkelde ViBe[12]. Om de achtergrond op te stellen wordt bij deze methodes verwacht dat de n laatste frames worden bijgehouden. Blob analyse Na de segmentatie kunnen we de positie van de voertuigen vinden met connected component labeling. In het resultaat van de segmentatie correspondeert iedere groep witte pixels of blob met een bewegend object. Met connected component labeling geven we elke blob een uniek nummer. In figuur 2.4b werd het resultaat gevisualiseerd. Alle pixels die deel uit maken van de blob linksboven kregen bijvoorbeeld het nummer 1, dat we met oranje lieten corresponderen.

(a) Resultaat segmentatie

(b) Resultaat labeling

Figuur 2.4: Connected component labeling

Nu elke blob een uniek nummer heeft kunnen we deze gemakkelijk van elkaar scheiden tijdens berekeningen. Met behulp van momenten kunnen we onder andere de grootte en het zwaartepunt van elke blob vinden[13]. Het moment µ met orde m+n wordt gedefinieerd


9

in (2.6). Aangezien we het moment steeds rond (0, 0) berekenen zijn ci en cj nul. µm,n

h−1 X w−1 X = (i − ci )n (j − cj )m Fij

(2.6)

i=0 j=0

De grootte van een blob is gelijk aan het moment met orde 0 (2.7). Dit zijn het aantal witte pixels. h−1 X w−1 X µ0,0 = Fij (2.7) i=0 j=0

De grootte van een blob kunnen we onder andere gebruiken om false positives weg te filteren. Dit zijn kleine groepen witte pixels die onterecht als voorgrond werden geclassificeerd tijdens de segmentatie. Alle blobs met een kleine oppervlakte kunnen in verdere stappen veilig genegeerd worden omdat ze onmogelijk een voertuig kunnen zijn[14]. Het zwaartepunt van een blob, gedefinieerd in (2.8), kunnen we gebruiken als de positie. Later kan dit ook gebruikt worden om de blob te tracken tussen frames. µ1,0 µ0,1 , (2.8) zwaartepunt = µ0,0 µ0,0 De momenten met orde 1 kunnen we berekeningen zoals in vergelijking (2.9) en (2.10). µ1,0 =

h−1 X w−1 X i=0 j=0

µ0,1 =

h−1 X w−1 X i=0 j=0

j × Fij

(2.9)

i × Fij

(2.10)

Om µ1,0 te bereken, sommeren we de x coordinaat van elke witte pixel. De x-coordinaat van het zwaartepunt vinden we door de som te delen door het aantal witte pixels. Het is dus eigenlijk gewoon een gemiddelde. Het berekenen van de y-coordinaat van het zwaartepunt gebeurt analoog. Nu we weten waarvoor zo’n labeling nuttig is, kunnen we eens kijken welke algoritmes hiervoor bestaan. Aangezien het resultaat altijd hetzelfde is, verschillen ze enkel op vlak van snelheid en geheugenverbruik. Er kan wel nog een onderscheid gemaakt worden op de manier waarop de connectiviteit binnen een blob wordt gedefinieerd. Binnen een blob kun


10

je een pad van witte pixels tekenen tussen elk paar pixels. De manier waarop dit pad mag gevormd worden, wordt bepaald door de connectiviteit. Zoals je ziet in figuur 2.5 mag je bij een 4-connectiviteit niet diagonaal gaan, bij een 8-connectiviteit wel. Het tweede geval is dus iets minder streng waardoor grotere blobs kunnen gevormd worden.

(a) 4-connected

(b) 8-connected

Figuur 2.5: Connectiviteit buren

Het oorspronkelijke algoritme om connected components te labelen werd ontwikkeld door Rosenfeld en Pfaltz in 1966[15]. Er bestonden hier al langer algoritmes voor maar dit was het eerste specifiek voor afbeeldingen. Het doel is dus om alle voorgrondpixels die aan elkaar hangen te groeperen door er hetzelfde label aan toe te kennen. De 4-connected labeling, die we hier bespreken, wordt gevonden in twee afzonderlijke stappen. Eerst gaat men de afbeelding rij per rij en van links naar rechts scannen. Door op deze manier je afbeelding te doorlopen weet je dat de vorige pixel en de pixel erboven al werden bezocht. Voor iedere voorgrondspixel onstaan er 4 situaties: • Vorige pixel is 0 en pixel erboven is 0 Geef de huidige pixel een nieuw label dat nog niet werd gebruikt. • Vorige pixel is 1 en pixel erboven is 0 Neem het label van de vorige pixel over. • Vorige pixel is 0 en pixel erboven is 1 Ongeveer dezelfde situatie als daarnet, maar nu wordt het label van de pixel erboven overgenomen. • Vorige pixel is 1 en pixel erboven is 1

2.2 Tracking

11

Neem het label van de vorige pixel over en controleer of het label van de vorige pixel en de pixel erboven gelijk zijn. Als ze niet gelijk zijn, moeten hun labels samen worden opgeslaan zodat ze later kunnen samengevoegd worden. Ze behoren immers tot dezelfde blob. In sommige situaties is het dus mogelijk dat tijdens het scannen verschillende labels aan 1 blob werden toegekend. De afbeelding wordt een tweede keer doorlopen om dit op te lossen. Het label dat elke pixel kreeg wordt opnieuw geëvalueerd en vervangen door het kleinst mogelijke label dat ermee overeenkomt. Na deze tweede stap heeft elke blob een uniek label. Het kan gebeuren dat de lijst met overeenkomstige labels erg groot wordt. Hierdoor is het niet efficiënt om het kleinste label te vinden tijdens de tweede stap. Door de labels op te slaan in een disjoint-set kan het juiste label in O(1) gevonden worden[16]. In [17] wordt de lijst eerst verwerkt vooraleer de tweede stap wordt uitgevoerd. Het resultaat is een look-up table die elk label mapt naar het correcte.

2.1.3

Besluit

Op dit punt hebben we 2 verschillende methoden besproken om voertuigen te detecteren. De eerste methode maakte gebruik van visuele informatie waardoor het een betrouwbare methode is. De andere methode maakte enkel gebruik van bewegingsinformatie waardoor het een erg snelle methode is. In ons geval, waar we op zoek gaan naar een algoritme dat kan draaien op een embedded systeem, is de keuze snel gemaakt. Daarom wijden we niet verder uit over de appearance-based methoden en focussen we ons op de andere methode. In het volgende puntje wordt besproken hoe de blobs tussen frames getrackt worden.

2.2

Tracking

Met blob analyse is het perfect mogelijk om te weten hoeveel voertuigen er in 1 frame aanwezig zijn. Maar om een correcte telling uit te voeren is dit niet genoeg. Je moet weten welke blobs al werden geteld en welke niet. Met tracking kunnen we tussen 2 frames de corresponderende blobs linken. Hierdoor kunnen per blob bijvoorbeeld de vorige posities worden bijgehouden en een markering of hij al dan niet werd geteld.

2.2 Tracking

12

Het linken gebeurt op basis van 1 of meerdere blobeigenschappen. In [18] worden blobs getrackt op basis van hun bounding box en zwaartepunt. Een bounding box is de kleinste rechthoek die rond de blob kan getekend worden. Als de frame rate hoog genoeg is, zal een blob maar een beperkte afstand afleggen tussen 2 frames. De kans is dus groot dat twee blobs matchen als de afstand ertussen klein is. Om de corresponderende blobs te vinden wordt een distance matrix opgesteld. Deze bevat de afstand tussen elk paar blobs in het huidig frame en het vorige. Om de afstand tussen 2 bounding boxes te vinden wordt de bounding box distance gebruikt (figuur 2.6). Als het zwaartepunt van de ene blob in de ander ligt, is de afstand 0. Als dit niet het geval is, dan wordt de kleinste afstand van 1 van de zwaartepunten naar de bounding box van de andere blob genomen. Tijdens het tracken levert dit betere resultaten op dan de euclische afstand.

Figuur 2.6: Bounding box distance

De afstand wordt uiteindelijk vervangen door een 1 als hij kleiner is dan Dthres of een 0 als hij groter dan of gelijk is. In tabel 2.1 zie je een voorbeeld waar 4 blobs uit het huidig frame worden gelinkt aan 5 uit het vorig.

Blob1 Blob2 Blob3 Blob4

Blob1 1 0 0 0

Blob2 0 0 1 0

Blob3 0 1 0 0

Blob4 0 0 0 1

Blob5 0 0 0 1

Resultaat Match Match Match Merge

Tabel 2.1: Distance matrix

Naast de normale situatie, waar blobs één op één worden gelinkt, kunnen er zich nog 4 andere voordoen. In de laatste regel van de tabel zag je er al 1 van.

2.3 Besluit

13

1. Er komt een nieuwe blob in beeld 2. Er verdwijnt een blob 3. Twee blobs versmelten in elkaar (merge) 4. Een blob splitst in twee blobs (split) Vooral het derde geval is een moeilijke situatie. Wanneer 2 voertuigen dicht bij elkaar rijden vormen ze 1 blob. Dit is natuurlijk niet gewenst omdat het leidt tot false negatives. Door extra features in de blob te gaan tracken kunnen deze occlusies vaak opgelost worden. In [18] wordt hiervoor van elke blob kleureninformatie bijgehouden, in [19] de contouren en in [20] de hoeken. Na een versmelting van 2 blobs kan met de features een onderscheid tussen 2 voertuigen gemaakt worden. Door een Kalman filter te gebruiken kan de tracker stabieler gemaakt worden[21]. Deze filter is vergelijkbaar met de kleinste kwadratenmethode waarbij een best passende lijn door een reeks punten wordt gevonden. Deze punten zijn in ons geval de vorige posities van het voertuig. Door dit systeem uit te breiden met de snelheid, de versnelling en de koers kan de volgende positie van het voertuig voorspeld worden. Zelfs als het voertuig tijdelijk geoccludeerd is kan er toch een betrouwbaar resultaat worden geleverd.

2.3

Besluit

Om voertuigen te lokaliseren, zagen we in de literatuur twee trends. We hebben enerzijds de appearance-based methoden. Deze gebruiken visuele informatie van het voertuig om de detectie in elk frame uit te voeren. Meestal wordt hiervoor eerst een model getraind aan de hand van een trainingsset. Daarna kan dit gebruikt worden bij de lokalisatie. Anderzijds hebben we de methoden die op basis van temporele informatie de voertuigen detecteren. Er wordt verondersteld dat de positie van elk voertuig verandert ten op zichte van z’n positie in het vorige frame. Een voorgrond-achtergrondsegmentatie kan deze bewegende delen snel vinden. Om op een hoger niveau te kunnen redeneren moeten deze voertuigen nog getrackt worden tussen frames. Op die manier kan informatie worden overgedragen zoals het feit of het voertuig al dan niet werd geteld. In het volgend hoofdstuk wordt een methode ontwikkeld om in realtime voertuigen te tellen.

ONTWERP

14

Hoofdstuk 3 Ontwerp Tijdens de ontwerpfase van de masterproef wordt gestart met het ontwikkelen van een prototype om met behulp van computervisie voertuigen te tellen. Hierdoor kunnen verschillende componenten worden uitgeprobeerd en geëvalueerd in een beperkte tijd. In een later stadium, wanneer een goeie methode wordt gevonden, kan het algoritme worden overgezet naar de TrafiCam. Dit is een embedded systeem van Traficon met een camera- en verwerkingsmodule in 1 behuizing. Op zo’n systeem is de rekenkracht beperkt waardoor verschillende bibliotheken niet kunnen worden gebruikt en waardoor specifiekere methoden nodig zijn. In de sectie van het prototype (sectie 3.1) wordt vooral de architectuur van het algoritme besproken. Daarna wordt in sectie 3.2 de TrafiCam en de uitdagingen van een embedded systeem besproken. Vanaf sectie 3.3 wordt dan dieper ingegaan op de implementatie van de verschillende componenten, specifiek voor de TrafiCam.

3.1 3.1.1

Prototype Keuze programmeeromgeving

Er bestaan min of meer 3 programmeertalen die goed geschikt zijn om computervisie applicaties mee te ontwikkelen. Dit zijn C++, Matlab en Python. Doordat ze alle 3 Turing-volledig zijn kan er bijvoorbeeld van elk C++ programma, een equivalent in Python worden geschreven. Het omgekeerde kan bijgevolg ook. De manier waarop dit gebeurt zal natuurlijk wel verschillen. De benodigde tijd zal anders zijn, de prestaties van het geschreven programma, de complexiteit van de code, . . . Het loont dus de moeite om de 3 opties van naderbij te bekijken. C++ is de oudste taal van de 3 en wellicht ook de meeste complexe. De taal werd in

3.1 Prototype

15

1983 ontwikkeld door Bjarne Stroustrup en is sindsdien één van de meest populaire. Een argument dat vaak wordt gebruikt om C++ te gebruiken, is het feit dat de gecompileerde programma’s erg snel zijn. Voor computervisie zijn er verschillende nuttige bibliotheken voorhanden zoals OpenCV, libCVD, CImg, VXL, . . . Matlab is een softwareomgeving die wordt gebruikt om allerhande wiskundige toepassingen mee te ontwikkelen. De resulterende programma’s zijn wat trager dan die geschreven in C++, maar Matlab wordt vaak geprezen voor z’n snelle ontwikkelingstijd. Met alle ingebouwde toolboxes zijn er enorm veel functies voorhanden waarmee snel resultaten kunnen bereikt worden. Er zijn ook functies om zaken te plotten, een REPL, een ge¨ıntegreerde debugger, . . . Python is net zoals C++ voor allerhande applicaties geschikt, maar kan het best worden vergeleken met Matlab. Ook hier wordt vaak de nadruk gelegd op een snelle ontwikkelingstijd. Python heeft een grote standaard bibliotheek en er wordt vaak voor de grap gezegd: ”Batteries included”. Een aantal nuttige bibliotheken voor computervisie zijn onder andere: PIL, Matplotlib, NumPy, SciPy, .. Er bestaan ook bindings naar de OpenCV library.

Matlab en Python lijken de aantrekkelijkste programmeertalen omdat je er snel mee je ideeën kan omzetten in code. Meestal gaat men ook als volgt te werk. Er wordt een prototype gemaakt in Matlab of Python, en daarna wordt het programma herschreven in C++. Er is echter nog een argument waarmee geen rekening werd gehouden. Alle algoritmes voor de TrafiCam moeten in C++ worden geschreven. Daarom wordt gekozen om het prototype ook in deze taal te ontwikkelen. Hierdoor wordt er al een nuttige ervaring opgedaan met C++ en kan er later code worden hergebruikt bij de implementatie op de TrafiCam. Tijdens het ontwikkelen van het prototype kan op deze manier ook al tussenin een beeld worden gevormd van de performantie van het uiteindelijke algoritme.

3.1.2

Motivatie

Een prototype is vooral nuttig om snel zaken uit te proberen en te evalueren. In de literatuur staan natuurlijk al veel methodes met hun resultaten beschreven. De omgeving en de context waarin die gebruikt worden, komt echter vaak niet overeen met die van ons. Daarom werden een hele reeks methoden zelf ge¨ımplementeerd en geëvalueerd in verkeerssituaties. Om niet telkens van nul te moeten beginnen, wordt gebruik gemaakt

3.1 Prototype

16

van de veel gebruikte bibliotheek OpenCV en de extensie CvBlobs. Die laatste werd onafhankelijk van OpenCV ontwikkeld en voorziet een aantal uitbreidingen.

3.1.3

Verkenning

Er werd in de literatuurstudie al een onderscheid gemaakt tussen appearance gebaseerde en motion gebaseerde detectiemethodes. We zijn gestart met uit elke categorie een methode te implementeren. Uit de eerste categorie, een implementatie op basis van het Viola-Jones algoritme. En uit de tweede, een implementatie met feature tracking.

(a) Viola-Jones

(b) Optical flow

Figuur 3.1: Lokalisatie

Voor het Viola-Jones algoritme wordt een haarclassifier gebruikt die werd getraind met afbeeldingen van auto’s (figuur 3.1a). In sommige gevallen worden bestelwagens ook gedetecteerd, maar moto’s en vrachtwagens leiden tot false negatives. Hiervoor zouden nog extra classifiers moeten worden getraind. Dit algoritme werd gekozen omdat er al modellen voorhanden waren en omdat het een referentie is geweest voor de ontwikkeling van andere detectiealgoritmes. We kunnen echter besluiten dat dit algoritme niet performant genoeg is, doordat de gewenste frame rate niet wordt behaald. De tweede manier gaat in elk frame de sterke hoeken detecteren en die tracken tussen frames (figuur 3.1b). Daarna kunnen alle dichtbijgelegen hoeken die bovendien van positie veranderen worden geclusterd tot een voertuig. Deze laatste stap hebben we niet uitgevoerd omdat het detecteren van de hoeken en het tracken ervan al te lang duurde. Methoden die tot een gelijkaardig resultaat komen (bv. block estimation) zijn ook niet geschikt. Bovenstaande resultaten zijn geen verrassing, maar dankzij de functies uit OpenCV kon dit toch snel gecontroleerd worden. Detectie met voorgrond-achtergrond segmentatie is een techniek die meer wordt gebruikt in real-time toepassingen. Hierop hebben we ons

3.1 Prototype

17

dan ook geconcentreerd. Op basis van de OpenCV functies wordt een video processing pipeline gevormd om voertuigen te tellen. Verder in dit hoofdstuk worden de details van elk component eruit besproken, maar eerst hebben we het over het vinden van een geschikte architectuur voor het prototype.

3.1.4

Implementatie

In afbeelding 3.2 zie je de voorgestelde pipeline om voertuigen te tellen. In de eerste stap wordt een voorgrond-achtergrond segmentatie gedaan om de bewegende objecten te vinden. Het resultaat daarvan (een voorgrondmasker) wordt opgekuist bij het postprocessen. Daarna wordt het binaire beeld gelabeld en worden er blobs gevormd. Die blobs worden vervolgens getrackt tussen beelden. Tenslotte worden de blobs (voertuigen) geteld. Voor elke stap in de pipeline bestaan er verschillende algoritmes die voor de taak kunnen worden gebruikt. Voor de eerste stap, het segmenteren, zagen we bijvoorbeeld verschillende methodes die leiden tot verschillende resultaten (sectie 2.1.2). In het prototype is het de bedoeling dat voor elke stap uit de pipeline een implementatie kan worden gekozen en dat die dan kunnen worden gecombineerd tot een volwaardig algoritme om voertuigen te tellen. Hierdoor ontstaan er verschillende versies die losstaand van elkaar kunnen worden getest.

Figuur 3.2: De pipeline van het algoritme

Om dit flexibel op te lossen wordt gebruik gemaakt van een variant van het strategy pattern. Dit is een software design pattern waarbij het gedrag van de algoritmes die een klasse gebruikt, veranderd kan worden tijdens het runnen. In afbeelding 3.3 zie je een gestripte versie van het UML schema. De klasse Algorithm bevat alle onderdelen uit de pipeline zoals de segmentatiemethode, de postprocessingmethode, ... Ieder onderdeel wordt voorgesteld door een abstracte klasse waarvan concrete implementaties kunnen overerven. Elke implementatie moet op die manier maar een aantal functies hebben en is voor de rest vrij om de taak op zijn manier te implementeren. Met de verschillende Set methoden kunnen onderdelen uit een algoritme gemakkelijk worden vervangen door andere. De objectcreatie van de verschillende onderdelen gebeurt niet in de klasse Algorithm zelf, maar wordt door

3.2 TrafiCam

18

de Set methoden gedelegeerd naar verschillende statische factories (niet zichtbaar in het UML diagram). Algorithm m_Segmentation : SegmentationBase ... m_Counter : VehicleCounterBase Algorithm(SegmentationMethod : String, ...) SetSegmentation(Method : String) : void ... SetVehicleCount(Method : String) : void ProcessFrame(Frame : Image) : void ...

RunningAverage m_LearningRate : float RunningAverage(LearningRate : float) UpdateBackground() : void TakeDifference() : void ...

SegmentationBase m_Background : Image UpdateBackground() : void TakeDifference() : void ProcessFrame() : int GetForeground() : Image ...

ApproximateMedian m_Threshold : int ApproximateMedian(Threshold : int) UpdateBackground() : void TakeDifference() : void ...

Figuur 3.3: Vereenvoudigd UML diagram van het prototype

3.1.5

Besluit

Op basis van het prototype kunnen al verschillende observaties worden gemaakt over de kwaliteit en de prestaties van verschillende algoritmes. Dankzij de flexibele structuur kan elk algoritme losstaand van andere worden getest. De resultaten hiervan staan in hoofdstuk 4. Hiermee wordt in volgende secties binnen dit hoofdstuk rekening gehouden.

3.2

TrafiCam

3.2.1

Hardware

Na het prototype volgt een implementatie op de TrafiCam (figuur 3.4). Dit is zoals gezegd een compacte, aluminium behuizing met daarin een camera- en een verwerkingsmodule. Door deze modules te integreren, verkreeg Traficon een makkelijk te installeren en gebruiksvriendelijk product. Het is ook een voordeel dat er hierdoor in de firmware kan vertrouwd worden op bepaalde specificaties van de camerasensor, zoals de resolutie.

3.2 TrafiCam

19

Figuur 3.4: De TrafiCam

De rekenkracht van de verwerkingsmodule is een stuk minder dan die op bijvoorbeeld een desktop computer. De CPU (MX535) heeft een kloksnelheid van 800MHz en heeft 512MB werkgeheugen. Dit zorgt voor een aantal uitdagingen en in het volgend puntje wordt besproken wat dit betekent voor de verwerkingstijd van elk videoframe.

3.2.2

Constraints

De CMOS sensor in de cameramodule neemt 25 beelden per seconde en geeft vervolgens een interrupt. Op die manier krijgt de software om de 40ms een signaal dat er een nieuw beeld werd genomen. In de interrupthandler wordt dan met de Update functie het beeld gekopieerd van het videogeheugen naar het lokaal geheugen (listing 2). De verwerking van het beeld gebeurt ergens anders omdat het een vuistregel is om het afhandelen van de interrupt zo snel mogelijk te doen. Het is de Run functie die de verwerking voor z’n rekening neemt (listing 1). Die wordt door de hoofdthread constant aangeroepen in een oneindige lus. Het is dus niet zo dat hij zoals de interrupt op vaste tijdstippen zal uitgevoerd worden. Het aantal keren dat de Run functie per seconde wordt opgeroepen hangt af van de tijd die hij nodig heeft om 1 frame te verwerken. Met de variabele m HasWork worden de interrupthandler en de hoofddtread gesynchroniseerd. Hierdoor wordt de Run functie maar eenmaal uitgevoerd op elk nieuw frame en wordt het lokaal geheugen niet overschreven met het nieuwe frame als de Run functie nog bezig is.

3.2 TrafiCam void VehicleCount::Run() { // no work if (!m_HasWork) return;

20 void VehicleCount::Update( const video::ImageFrame& Frame) { // skip frame (not done with previous) if (m_HasWork) return;

/* process the new frame */ /* make a local copy * of the frame */

// done m_HasWork = false; }

// indicate that there’s work m_HasWork = true; } Listing 1: Main thread (process a frame)

Listing 2: Interrupt (get a frame)

Listing 3: Synchronisatie tussen de verwerkingsthread en de interrupt

Het tweede deel van de laatste zin van de vorige paragraaf is erg belangrijk, want wat gebeurt er precies als de Run functie nog bezig is wanneer een nieuw frame binnenkomt? Doordat er 25 interrupts zijn per seconde (1 voor elk frame), zijn er 40 milliseconden beschikbaar om elk frame te verwerken. Als die tijd in de Run functie wordt overschreden, wordt er een frame overgeslaan. Er wordt in de interrupthandler immers geen nieuw frame gekopieerd tot de Run functie op het einde de variabele m HasWork terug op false zet. In figuur 3.5 zie je dat het verwerken van frame 3 langer duurt dan gewenst. Hierdoor wordt het vierde frame overgeslagen waardoor informatie kan gemist worden en het tracken van blobs bijvoorbeeld moeilijker wordt. Doordat er een groter tijdsverschil zit tussen de blobs die moeten gematcht worden, zijn de corresponderende minder eenduidig te achterhalen.

3.3 Voorgrond-achtergrond segmentatie

21

Figuur 3.5: CPU-gebruik bij het verwerken van frames

In de volgende secties wordt elk component van de pipeline om voertuigen te tellen besproken met de nadruk op de performantie. Hiermee moet, zoals aangetoond, rekening gehouden worden om tot een goed resultaat te komen. We beginnen bij de eerste stap en gaan in volgorde verder tot we komen bij het tellen van voertuigen.

3.3 3.3.1

Voorgrond-achtergrond segmentatie Technieken

Voor de segmentatie op de TrafiCam zelf worden een aantal methoden geselecteerd op basis van hun tijds- en geheugencomplexiteit. In beide gevallen is het gewenst dat de complexiteit lineair is in functie van het aantal pixels. We wensen ook dat de constante factor zo laag mogelijk is. Die is afhankelijk van het werk dat moet worden gedaan dat niet afhankelijk is van het aantal pixels. Aan deze beperkingen voldoen 3 methoden: 1. Running average 2. Running gaussian average 3. Approximate median Bij het segmenteren gaan deze methoden het nieuwe frame een eerste maal doorlopen om het achtergrondsmodel te updaten. En een tweede maal om het voorgrondmasker te berekenen door het verschil van het frame en de achtergrond te thresholden. Naast de afbeelding waar het resultaat inkomt en het achtergrondmodel, is er bij deze methoden geen extra geheugen nodig.


(a) Approximate median

(b) Running average

22

(c) Running gaussian avg

Figuur 3.6: Vergelijking tussen 3 snelle segmentatiemethoden

Deze 3 methoden geven doorgaans gelijkaardige resultaten zoals in figuur 3.6. Toch bestaan er een aantal situaties waar de sterktes en zwaktes van elke methode naar voren komen. In hoofdstuk 4 wordt hier dieper op ingegaan.

3.3.2

Downsampling

Om de segmentatie en de rest van de stappen in de pipeline sneller te doen verlopen, kan elk nieuw frame worden gedownsampeld. Hierbij wordt de hoogte h en de breedte w verkleind met een bepaalde factor tot een nieuwe hoogte h0 en een nieuwe breedte w0 . Als een afbeelding in de 2 dimensies met bijvoorbeeld een factor 6 wordt gedownsampeld, dan zitten in het resultaat dus 62 keer minder pixels. Dit levert meteen een grote prestatiewinst bij het segmenteren. In de volgende paragrafen worden hier 3 methoden voor beschreven en wordt een geschikt algoritme gekozen. Downsampling met de nearest neighbour techniek gaat het snelst, maar levert ook de minst kwaliteitsvolle resultaten. Het algoritme start met geheugen te alloceren voor de kleinere, gedownsampelde afbeelding. Daarna wordt de kleinere afbeelding denkbeeldig uitgerokken en over het origineel gelegd. Tenslotte wordt voor elke pixel in de resultaatafbeelding, de pixel uit het origineel overgenomen die er het dichtst bij ligt. In (3.1) wordt nog eens wiskundig beschreven hoe uiteindelijk het gedownsampelde beeld D wordt gevuld met waardes uit het originele frame F . De indices i en j zijn zoals gewoonlijk de rij en de kolom in de afbeelding. Bij het invullen van een aantal openeenvolgende waarden voor i0 en j 0 kan er gezien worden dat er bij het kopiëren gewoon pixels uit het origineel beeld worden overgeslagen.


Di0 j 0 = Fij waarbij i = i0 ·

23

h w en j = j 0 · 0 0 h w

(3.1)

Andere manieren zijn onder andere de bilineaire en de bicubic technieken. Hier wordt ook rekening gehouden met de pixels rondom de dichtste pixel die wordt overgenomen. Hierdoor wordt een beter resultaat bekomen. Hiervoor is wel meer rekenkracht nodig want er moeten meer bewerkingen worden uitgevoerd. In afbeelding 3.7 zie je een vergelijking tussen de nearest neighbour techniek en de bicubic techniek. Het verschil valt vooral op bij het bekijken van de randen.

(a) Origineel frame

(b) Nearest neighbour

(c) Bicubic

Figuur 3.7: Gedownsampelde frames (factor 10)

Er wordt gekozen voor de nearest neighbour techniek omdat, in tegenstelling tot de afbeeldingen hierboven, de verschillen amper zichtbaar zijn in het segmentatieresultaat. De snellere methode krijgt dus de voorkeur. In het volgende hoofdstuk wordt de invloed van de downsample factor op het resultaat besproken.

3.3.3

Postprocessing

Nadat het gedownsampelde beeld werd gesegmenteerd in voor- en achtergrond, wordt al een eerste postprocessing stap uitgevoerd. We zien dat de voorgrondmaskers in figuur 3.6 veel salt and pepper noise bevatten. Dit zijn ofwel witte pixels die voorkomen in zwarte gebieden, ofwel zwarte pixels in witte gebieden. Met behulp van een mediaanfilter kunnen deze doeltreffend worden geëlimineerd terwijl de randen van de blobs toch worden behouden. Zoals je in figuur 3.8 kan zien, verbetert de kwaliteit van het voorgrondmasker hierdoor. De blobs krijgen een betere samenhang doordat de meeste ruis verdwijnt.

3.4 Blob vorming

24

(a) Zonder filter

(b) Mediaan filter

Figuur 3.8: Resultaat van een mediaan filter

Een mediaan filter die wordt toegepast op een binair beeld, wordt ook vaak een majority filter genoemd. Als de nullen en enen uit de neighbourhood worden gesorteerd, dan is de middelste waarde in feite de waarde die het meest voorkomt. Door deze observatie is het sorteren overbodig geworden en moet er gewoon een telling gebeuren. Een 3 × 3 kernel was in ons geval al genoeg om de gewenste resultaten te halen. In de volgende sectie worden nog een aantal andere technieken aangehaald om de kwaliteit van het beeld te verbeteren. Deze worden echter toegepast op een gecomprimeerde versie van het frame.

3.4 3.4.1

Blob vorming Run-length codering

De volgende stap in de pipeline is het vormen van blobs. Het is rekenkundig natuurlijk erg kostelijk om telkens alle operaties op dat volledig beeld te laten lopen. Daarom wordt het eerst (verliesloos) gecomprimeerd zodat volgende stappen sneller kunnen worden uitgevoerd. Met run-length codering worden alle opeenvolgende witte pixels in een rij gecodeerd tot een startpositie en een lengte. In figuur 3.9b zie je de compacte representatie van 3.9a. Deze techniek is uiterst effectief omdat er in ons geval maar 2 mogelijke waarden in het beeld zitten. Met de zwarte pixels (achtergrond) wordt geen rekening gehouden omdat we voor het tellen enkel ge¨ınteresseerd zijn in de voorgrond, die overeenkomt met de voertuigen.

3.4 Blob vorming

25

(a) Segmentatiemasker

(b) De runs (start+lengte)

Figuur 3.9: Runlength encoding

Om de runs te vormen, worden de pixels van de afbeelding dus nog een laatste keer rij per rij overlopen. De runs worden opgeslagen in een simpele datastructuur die de beginpositie en de lengte bevat. Daarom was het belangrijk om voor deze stap het beeld al een eerste keer op te kuisen. Moest dit niet worden gedaan, dan zouden er veel overbodige runs inzitten met een kleine lengte ten gevolgde van ruis.

3.4.2

Labeling

Bij het labelen gaan we op zoek naar de runs die met elkaar verbonden zijn. Die runs geven we dan hetzelfde nummer (label) zodat we straks weten dat ze tot dezelfde blob behoren. Dit wordt ge¨ımplementeerd door rij per rij en per run te kijken naar de runs op de rij eronder. Runs op opeenvolgende rijen die niet verbonden zijn kunnen genegeerd worden. Het predicaat om dit te controleren staat beschreven in (3.2). De Left functie geeft de xcoördinaat van de start van de run terug. De Right functie is gelijk aan de som van Left() en de lengte van de run. De beschreven vergelijking laat toe dat runs elkaar diagonaal raken. In het predicaat wordt gekeken of de run eronder verder ligt dan de 2 extrema waarbij de runs elkaar net zouden raken. Verbonden = RunBelow.Left() ≤ CurrentRun.Right() + 1 AND RunBelow.Right() ≥ CurrentRun.Left() − 1

(3.2)

Wanneer wordt vastgesteld dat 2 runs (op opeenvolgende rijen) verbonden zijn, onstaan er 2 gevallen:

3.4 Blob vorming

26

1. Als de run op de volgende rij nog geen label heeft, dan kan het label worden overgenomen van de huidige run. 2. Indien de run op de volgende rij wel al een label heeft, dan wordt het label van die run (en de andere met dat label) vervangen door het label van de huidige run. Dit kan gezien worden als een merge operatie waarbij 2 groepen runs worden samengevoegd tot 1. Als een run op een bepaalde rij wordt vastgesteld die nog geen label heeft, wordt er één toegekend die nog niet werd gebruikt. Dit geval komt voor als een run niet raakt met een run op de rij erboven of bij runs die op de eerste rij liggen. Op die manier krijgen alle runs een label dat aangeeft met welke andere ze verbonden zijn. Het algoritme is een single-pass algoritme dat in de praktijk goed presteert. Doordat het voorgrondmasker wordt gecomprimeerd, heeft niet elke pixel apart een label nodig, maar kan dit met de runs worden geassocieerd. Door het algoritme op een hoger niveau uit te voeren, onstaat een snelheidswinst en wordt er minder geheugen gebruikt.

3.4.3

Blobs

Nu moet enkel nog de gewenste informatie verzameld worden van elke blob. De bounding box kan bijvoorbeeld worden gevonden door de extrema van elke run met eenzelfde label op te slaan. Dit is de meest linkse positie, de meeste rechtse, de laagste positie en de hoogste. Het zwaartepunt kan gevonden worden met de momenten die werden besproken in de literatuurstudie. In figuur 3.10b worden deze zaken gevisualiseerd.

3.4 Blob vorming

27

(a) Origineel frame

(b) Gelabelde blobs + attributen

Figuur 3.10: Visualisatie van het vormen van blobs

Het is misschien al opgevallen dat de kwaliteit van het beeld uit figuur 3.10b een stuk beter is dan dat in figuur 3.8b. Dit komt omdat er ondertussen al een tweede postprocessing operatie werd uitgevoerd. Hier filteren we de blobs op basis van hun grootte µ0,0 (3.4). Blobs met minder dan 500 pixels worden verwijderd. Deze subjectieve waarde werd bepaald door in verschillende videofragmenten de grootte van de verschillende blobs te gaan analyseren. Vervolgens werd gekeken bij welke grootte ze nog relevant zijn. De gegeven waarde is wel de grootte van de blob in het originele beeld dat een resolutie van 640 op 480 pixels heeft. µ0,0 moet dus eerst worden vermenigvuldigd met de 2 downsample factoren om de echte grootte ervan te bekomen. Op basis van deze gegevens wordt een predicaat bekomen dat aangeeft of een blob moet worden behouden of niet (3.3). Keep = µ0,0 ×

h w × 0 > 500px 0 h w

(3.3)

Doordat blobs niet meer worden voorgesteld door pixels maar door runs, verandert de definitie van de verschillende attributen. In vergelijking (3.6) staat de nieuwe afleiding voor de x-coördinaat van het zwaartepunt. De berekening van de y-coördinaat gebeurt analoog.

3.5 Tracking

28

µ0,0 =

n−1 X

Runs[i].Length()

(3.4)

i=0

µ1,0

n−1 X = Runs[i].Left() × Runs[i].Length() + i=0

1 × Runs[i].Length() × (Runs[i].Length() − 1) 2 Zx =

µ1,0 µ0,0

(3.5) (3.6)

De gedachte bij het berekenen van het zwaartepunt blijft wel hetzelfde. Voor de xcoördinaat van het zwaartepunt willen we terug het gemiddelde vinden van alle x-coördinaten uit de blob. Door het labelen komt elke blob overeen met n runs met eenzelfde id. Hierdoor kunnen de runs snel van elkaar worden gescheiden om de berekeningen uit te voeren. De verschillende stappen van de berekening worden hieronder besproken. 1. Het aantal x-coördinaten is gelijk aan de som van de lengte van elke run (3.4). 2. De som van de x-coördinaten bespreken we met een voorbeeldje. Neem een bepaalde run die start bij 50 en een lengte heeft van 4 (50, 51, 52, 53). De eerste term uit (3.5) maakt de som van de gemeenschappelijke delen (50 × 4). De tweede term telt de som van de rest erbij (0, 1, 2, 3). 3. Tenslotte wordt de deling gemaakt van de som en het aantal om het gemiddelde dat we zochten te bekomen (3.6). Hier eindigt de spatiale verwerking van het frame. Met behulp van voorgrond-achtergrond segmentatie en blob analyse worden alle voertuigen in elk frame gevonden. Deze voertuigen worden vervolgens beschreven door een bounding box en een zwaartepunt. De volgende 2 stappen en tevens de laatste, zijn temporeel doordat er informatie uit meer dan 1 frame tegelijk wordt geanalyseerd.

3.5

Tracking

Voor het tracken wordt een aangepaste versie gebruikt van de tracking module uit de CvBlob bibliotheek. Die implementeert het algoritme uit [18] dat al in sectie 2.2 van de literatuurstudie werd besproken.

3.6 Tellen

29

De module is echter geschreven in C, daarom wordt hij voor een groot deel omgevormd zodat er een object georiënteerde stijl wordt gebruikt. Hierdoor kan dit stuk van de pipeline beter aansluiten bij de rest. Ook worden alle delen die gebruik maken van de OpenCV bibliotheek verwijderd of aangepast. Dit zou een te grote dependency zijn voor het project.

3.6

Tellen

Op dit punt is er genoeg informatie om de voertuigen te tellen. Van elke blob kennen we de vorige posities (dit houden we bij) en dus ook de richting die hij uitgaat. Als een voertuig een denkbeeldige lijn passeert en het in de juiste richting gaat, dan wordt het als geteld gemarkeerd. Het is nodig om de blob expliciet als geteld te markeren omdat het zwaartepunt soms verspringt. Zelfs al beweegt het voertuig in een bepaalde richting, dan kan het gebeuren dat het zwaartepunt dit occasioneel niet doet. Als dit zich voordoet bij de lijn, kan het voertuig meerdere malen geteld worden. De lijn bevindt zich in de helft van het scherm omdat op dat punt de blobs het best zichtbaar zijn. In figuur 3.11 zie je de visualisatie hiervan. Wanneer een blob de lijn passeert, worden de diagonalen van de bounding box ingekleurd. De dunne lijn die achter de voertuigen zichtbaar is, zijn de vorige posities die met elkaar verbonden zijn. Deze informatie is afkomstig van de tracker. Het detecteren van een nieuw voertuig kunnen we samenvatten in volgende vergelijking (3.7). Deze conditie wordt voor elke actieve track gecontroleerd. Eerst wordt gekeken of het voertuig al een vorige keer werd geteld. Daarna wordt de richting van het voertuig gecontroleerd. Als die kleiner is dan 0, dan betekent dit dat er van ons weg wordt gereden. Tenslotte wordt getest of de lijn wordt overschreden. Hierbij wordt verwacht dat het zwaartepunt zich de vorige keer onder de lijn bevond en nu dus erop of erboven. Met deze 4 testjes kan op een hoog niveau betrouwbaar worden gecontroleerd of er een nieuw voertuig passeerde. De oorsprong ligt voor alle duidelijkheid linksboven in het beeld.

NewCar = (NOT Track[i].Counted) AND (Track[i].Direction.Y < 0) AND (Track[i].PreviousCentroid.Y > Line) AND (Track[i].Centroid.Y ≤ Line)

(3.7)

3.7 Besluit

30

Figuur 3.11: Voertuigen met vorige posities

3.7

Besluit

Op basis van een prototype werd tot een algoritme gekomen om voertuigen te tellen in realtime. In de eerste fase werden verschillende methoden verkend en geëvalueerd. Uiteindelijk werd gekozen om de detectie te doen a.d.h.v. voorgrond-achtergrond segmentatie. Op basis hiervan kon een raamwerk worden gemaakt waarbij ieder onderdeel makkelijk te vervangen is door een ander. Nadat een goede methode werd gevonden, werd dit uitgewerkt op de TrafiCam. In het volgende hoofdstuk wordt besproken hoe de verschillende algoritmes werden getest. Daarna worden de resultaten hiervan gegeven en besproken.

RESULTATEN

31

Hoofdstuk 4 Resultaten In dit hoofdstuk worden de prestaties van verschillende algoritmes uit het prototype besproken. Er wordt eerst uitgelegd hoe de tests op een geautomatiseerde manier worden uitgevoerd. Daarna volgt een overzicht van de resultaten. De nadruk ligt op het evalueren van het prototype omdat het algoritme op de TrafiCam hier op gebaseerd is. Op het einde van het hoofdstuk worden nog een aantal parameters besproken die een invloed kunnen hebben op de prestaties.

4.1 4.1.1

Prototype Geannoteerde video’s

Om de verschillende algoritme’s uit het prototype te testen, wordt gebruik gemaakt van geannoteerde video’s die door Traficon ter beschikking worden gesteld. Elke video gaat gepaard met een XML bestand dat de ground truth bevat (voorbeeld in listing 4). Deze werden opgesteld door een werknemer met behulp van een annotatietool die binnen Traficon werd ontwikkeld. Op interessante momenten kan hiermee de locatie van de voertuigen vastgelegd worden. Alle annotaties kunnen op het eind worden geëxporteerd naar een XML bestand die dan de correcte informatie bevat waarmee er vergeleken kan worden.

4.1 Prototype

32

...

Entry="7160" Entry="8270" Entry="8576" Entry="8726" Entry="8974"

Exit="7188" Exit="8298" Exit="8606" Exit="8756" Exit="9003"

/> /> /> /> />

Listing 4: Gestripte XML met de ground truth

Elke regel in zo’n XML bestand bevat informatie (zoals de rijstrook) over 1 voertuig. De entry en de exit attributen zijn het frame nummer waarop het voertuig de detectiezone binnenrijdt en terug verlaat. Wij maken in de algoritme’s geen gebruik van zulke zones, noch maken we onderscheid tussen rijstroken. Daarom wordt deze data voor het testen vereenvoudigd en zeggen we dat een voertuig wordt gedetecteerd op framenummer 1 × (Entry + Exit). 2 Om de output van de algoritme’s met de ground truth data te kunnen vergelijken, moet hij in hetzelfde formaat staan. Dit betekent dat wij ook moeten weten op welk framenummer een voertuig geteld wordt. Deze informatie staat zoals je ziet in figuur 4.1 linksboven, maar deze cijfers zijn voor een computer moeilijk te lezen. Daarom werd door Traficon bovenaan het frame een makkelijker te lezen codec voorzien. Elke codec begint met een preamble die bestaat uit 6 grote blokken: wit-zwart-wit-zwart-wit-zwart. Daarna volgt een binaire code die het framenummer voorstelt. Een overgang van zwart naar wit in een blok is een 1 en een overgang van wit naar zwart is een 0. In onderstaande figuur is dit 010101001000. . . (LSB eerst), wat inderdaad gelijk is aan 298. Bij het detecteren van een voertuig wordt deze codec telkens gedecodeerd naar een framenummer. Hierdoor kan de link gelegd worden tussen de output van het algoritme en de ground truth data.

Figuur 4.1: Bovenste deel van een videoframe met de codec

4.1 Prototype

4.1.2

33

Vergelijking

In figuur 4.3 wordt het hele evaluatieproces nog eens gevisualiseerd. We hebben langs de linkerkant de resultaten van een bepaald algoritme en langs de rechterkant de ground truth. Beide leveren de framenummers waarop een voertuig werd gedetecteerd.

Figuur 4.2: De framenummers worden in bins gestopt

Deze tijdstippen worden dan in bins van 30 seconden gestopt om ze met elkaar te kunnen vergelijken (figuur 4.2). Elke bin komt overeen met het aantal voertuigen dat in die periode werd gedetecteerd. Deze transformatie is nodig omdat er geen gegevens beschikbaar zijn over de positie van de detectiezone. Het is dus niet zo dat het detectiepunt van de voertuigen in de ground truth hetzelfde is als bij ons (de lijn). Daarom moeten we groepen voertuigen met elkaar vergelijken in plaats van individuele. Dertig seconden leek een goed compromis om als grootte voor de bins te nemen. 1. Groot genoeg zodat er weinig fouten zijn door detecties bij de overgang van bins. In de ground truth zou het voertuig kunnen gedetecteerd zijn aan het begin van een bin terwijl het algoritme hem detecteert aan het eind van de vorige bin. 2. Klein genoeg om dubbele fouten binnen een bin die elkaar tenietdoen te beperken. Een false positive en een false negative kunnen elkaar per slot van rekening opheffen.

Een bin van een halve minuut komt overeen met een interval van 25 ∗ 2 ∗ 30 framenummers (=1500), want de video’s spelen aan 25 frames per seconde. Er wordt nog eens ×2 gedaan omdat de video’s interlaced zijn waardoor de framenummers per 2 omhoog gaan. De eerste bin wordt overgeslagen omdat die in sommige gevallen niet volledig gevuld is. In de testdata zitten bijvoorbeeld video’s die niet op frame 0 beginnen.

4.1 Prototype

34

Figuur 4.3: Vergelijking met ground truth

Voor elke bin kunnen dan het aantal true positives (TP), het aantal false positives (FP) en het aantal false negatives (FN) berekend worden. Een TP betekent dat er een voertuig was en geteld werd. Dit is het geval waar we naar streven. Een FP betekent dat er geen voertuig was, maar het algoritme heeft er toch 1 geteld. Een FN betekent dat er een voertuig was, maar het algoritme zegt van niet. In tabel 4.4 staan een aantal voorbeeldbins waarop dit wordt toegepast.

4.1 Prototype

35

Figuur 4.4: Verwerking resultaten

De som van de resultaten van elke bin zijn een maatstaf voor de kwaliteit van het algoritme. Deze kunnen verder geanalyseerd worden door de sensitivity (4.1) en de precision (4.2) te berekenen. De sensitivity geeft als een percentage aan, hoeveel voertuigen die passeerden werden geteld door het algoritme. De precision daarentegen, geeft aan hoeveel procent van de getelde voertuigen, effectief voertuigen waren. Meestal is er tussen deze 2 waarden een verband. Een streng algoritme zal een grote precision hebben maar zal, doordat het hierdoor meer voertuigen mist, een lagere sensitivity hebben. Een laks algoritme kan doordat het bijna alles als voertuig ziet een hoge sensitivity hebben, maar zal dan weer een lage precision hebben. Een goed evenwicht vinden tussen de 2 is vaak een moeilijke taak. TP TP + FN TP Precision = TP + FP

Sensitivity =

(4.1) (4.2)

Als we dit tenslotte even toepassen op het voorbeeldje uit tabel 4.4 dan is de sensitivity 97.2% en de precision 92.1%. Om dit te berekenen werden de opgetelde TP’s, FP’s en FN’s van alle intervallen gebruikt (onderste rij). Hierdoor krijgt elk voertuig dat geteld werd eenzelfde gewicht. Een andere manier zou zijn om eerst per interval de sensitivty en de precision te berekenen en dan dan het gemiddelde van alle intervallen te nemen. Dan krijgt elk interval eenzelfde gewicht. Uitschieters hebben hier bijvoorbeeld minder invloed op het uiteindelijke resultaat. Beide methoden hebben zo hun voor- en nadelen maar meestal wordt de eerste methode gebruikt omdat die het eerlijkst is. In onze resultaten wordt het om die reden ook zo gedaan.

4.1 Prototype

4.1.3

36

Rapport

In de laatste stap van het testframework worden de resultaten weggeschreven naar een HTML bestand. Op elk filmpje worden alle algoritmes toegepast en de output hiervan wordt telkens vergeleken met de ground truth. Als er m filmpjes zijn en n algoritmes, dan doet het testprogramma m × n iteraties. Deze geneste loop is ook zichtbaar in listing 5. ReportWriter Writer("TestOutput/index.html"); for (int i = 0; i < m; ++i) // m geannoteerde filmpjes { // bereken het aantal detecties per interval in de ground truth AnnotationReader XmlReader(Movie[i].XmlPath); vector XmlIntervals = XmlReader.GetIntervals(INTERVAL); // header met info over dit filmpje Writer.WriteVideoInfo(Movies[i].Name); for (int j = 0; j < n; ++j) // n algoritmes { // run het algoritme en sla de detecties per interval op MovieReader AlgoReader(Algorithm[j]); vector MovieIntervals = AlgoReader.GetIntervals(Movie[i].Path, INTERVAL); // vergelijk de detecties afkomstig van de ground truth met // die door het algoritme en schrijf het resultaat weg Writer.WriteAlgoResults(XmlIntervals, MovieIntervals); } // grafiekje met de resultaten Writer.WriteGraphData(); } Listing 5: Generatie van het rapport

Met de klasse AnnotationReader wordt de XML met de ground truth gelezen. De klasse MovieReader wordt gebruikt om een algoritme op een filmpje toe te passen. Tussenin wordt met de Writer klasse de gewenste output weggeschreven naar het HTML bestand.

4.1 Prototype

37

Om meer inzicht te krijgen in de prestaties van elk algoritme apart wordt de threshold parameter van een aantal segmentatiemethoden aangepast tijdens de evaluatie. Elke methode wordt gerund met een threshold van 20, 25, 30, 35, 40, 45, 50, 60, 70 en 100. Doordat dit een rekenintensieve taak is, wordt gebruik gemaakt van de high performance computer of kortweg HPC van Traficon. Hier kon via SSH het testprogramma worden opgezet en uitgevoerd. De tests duurden uiteindelijk zo’n 30 uur. De resultaten hiervan staan in figuur 4.5. Per algoritme wordt het gemiddelde van de resultaten over de 6 testfilmpjes genomen zodat er een algemeen beeld kan gevormd worden. De resultaten van elk filmpje apart kunnen in bijlage A gevonden worden. De mixture of Gaussians en de running Gaussian methoden variëren niet in de grafiek. Dit komt omdat deze methoden niet afhankelijk zijn van een globale threshold, maar van de standaard deviatie.

Figuur 4.5: Gemiddelde resultaten

Het ideale algoritme ligt in de hoek rechtsboven. Hier worden alle voertuigen perfect gedetecteerd en geteld, wat een precision en een sensitivity van 100% oplevert. De running

4.2 TrafiCam

38

average methode leunt hier het dichtst bij aan. Met een threshold van 60 wordt een sensitivity van 90.39% en een precision van 86.27% behaald. Om nog betere resultaten te behalen zou de test kunnen herhaald worden met meer variatie in de parameters. Bij de running average methode heb je bijvoorbeeld nog de learning rate die kan worden aangepast. Ook de tracker bevat een aantal parameters die de werking van het geheel be¨ınvloeden. Maar het zou vooral nuttig zijn om ook eens de parameters van de running gaussian en de mixture of gaussian methoden te laten variëren. Nu hebben we een minder goed zicht van de prestaties hiervan.

4.2

TrafiCam

Het prototype diende om de prestaties van verschillende algoritmes te evalueren en het beste te selecteren. Toch is het ook belangrijk om de prestaties van het herschreven algoritme op de TrafiCam te bepalen. Hier zijn namelijk een aantal zaken anders in vergelijking met het prototype: 1. Het downsamplen van ieder frame 2. De run-length codering (geen invloed) 3. Een frame kan overgeslagen worden

Het is echter niet zo eenvoudig om in deze omgeving geautomatiseerd tests uit te voeren. Een algoritme op de TrafiCam kun je immers niet zien als een losstaand programma. Het maakt deel uit van een groot framework waarbij het algoritme van een bepaalde klasse overerft en hierdoor een aantal virtuele methoden moet implementeren zoals een Configure en een Run. Die methoden worden dan op de juiste momenten aangeroepen, maar verder heb je geen controle. Het is bijvoorbeeld niet mogelijk om zoals bij het prototype dit algoritme op te nemen in een testframework dat de prestaties automatisch analyseert. Traficon heeft hiervoor een eigen systeem, maar door de nieuwe aanpak van ons algoritme is het hierin niet te integreren. Het TrafiCam framework kan zowel offline als online draaien. Offline betekent dat het op de computer kan worden uitgevoerd waarbij er bepaalde componenten van de hardware gesimuleerd worden. Als het online draait, loopt het effectief op de hardware van de TrafiCam. Beide worden in volgende puntjes besproken.

4.2 TrafiCam

4.2.1

39

Offline-GUI

De offline-GUI is in feite een ontwikkelhulp om in de beginfase het algoritme mee uit te testen. Het is mogelijk om het algoritme uit te voeren op een opgegeven filmpje in plaats van op camerabeelden. In figuur 4.6 vind je een screenshot van deze omgeving. De output van het algoritme kan worden getoond door op het inputbeeld te tekenen met de voorziene functies uit het framework. Links onder wordt in dit geval het aantal getelde voertuigen geplaatst.

Figuur 4.6: Offline GUI

Er kan ook informatie worden opgevraagd over de verwerkingstijden van elk frame. Die staan voor verschillende downsample factoren als een histogram afgebeeld in figuur 4.7. De gemiddelde verwerkingstijden liggen redelijk dicht bij elkaar omdat het algoritme op de desktop draait. Op de TrafiCam zelf is een factor 6 nodig om de gemiddelde verwerkingstijd laag genoeg te houden zodat het realtime draait. De prestaties van het algoritme blijven goed doordat de voertuigen zelfs op zo’n kleine resolutie nog steeds voldoende zichtbaar zijn.

4.2 TrafiCam

40

Figuur 4.7: Vergelijking verwerkingstijd

Tijdens het optimaliseren was een algemene verwerkingstijd zoals hier niet genoeg om inzicht te krijgen in de bottlenecks. Hiermee wordt enkel informatie verkregen over de totale tijd die de Run methode nodig heeft om een frame te verwerken. Om gedetailleerdere informatie te verkrijgen maakten we gebruik van very sleepy 1 . Hiermee konden kritische delen in de code, zoals de segmentatie, gericht geoptimaliseerd worden.

4.2.2

Online (in the field)

De resultaten op de camera zelf zijn natuurlijk het belangrijkst. Om die te evalueren werd een testopstelling gemaakt bij de tunnel in Wevelgem (figuur 4.8). Op maandag 13 mei 2013 vanaf 11.20u heeft het algoritme 25 minuten lang de voertuigen geteld. De resultaten konden via een RTSP stream bekeken worden en werden opgeslagen op de computer. 1

C/C++ CPU profiler for Windows (http://www.codersnotes.com/sleepy/sleepy)

4.2 TrafiCam

41

(a) Testlocatie bij de tunnel in Wevelgem

(b) De TrafiCam

Figuur 4.8: Evaluatie van het algoritme online

Het algoritme kan, zoals eerder gezegd, niet automatisch geëvalueerd worden op de TrafiCam. Daarom hebben we handmatig de video-opname (figuur 4.9 doorlopen en de true positives, false negatives en false positives geteld. Dit is ook de reden waarom geen langere opname werd gemaakt.

Figuur 4.9: Snapshot video-opname

Met het algoritme wordt een sensitivity van 94.9% en precision van 97.99% behaald (eerste 20 minuten van de opname). Dit ligt in de lijn van de prestaties met het prototype. Het algoritme is dus, ondanks de verschillen met het prototype, even goed.

4.3 Besluit

4.3

42

Besluit

Met behulp van een testframework worden alle algoritmes uit het prototype geëvalueerd. Om nog meer inzicht te krijgen in de prestaties worden ook verschillende thresholds voor de segmentatie getest. De output wordt telkens vergeleken met ground truth data waardoor de precision en de sensitivity nauwkeurig kunnen worden berekend. Het beste algoritme gebruikt bij de segmentatie een running average met een threshold van 60. Hierbij wordt gemiddeld op de testfilmpjes een sensitivity van 90.39% en een precision van 86.27% bekomen. Het testen van het algoritme op de TrafiCam is moeilijker doordat het ge¨ıntegreerd is in een framework. Doordat het al uitvoerig werd getest tijdens het maken van het prototype is dit minder erg. Toch zijn er een aantal zaken anders. We hebben de prestaties visueel gecontroleerd op de offline-gui en aan de hand van opnames op de TrafiCam zelf. Het downsamplen heeft positieve gevolgen voor de verwerkingstijd, terwijl de prestaties hoog blijven.

BESLUIT EN TOEKOMSTPERSPECTIEVEN

43

Hoofdstuk 5 Besluit en toekomstperspectieven In dit werk werd een beeldverwerkingsalgoritme ontwikkeld om voertuigen te tellen. Er is geen kalibratie vereist doordat voertuigen over heel het frame worden gedetecteerd. Dit gebeurt aan de hand van een voorgrond/achtergrond segmentatie. Hiermee worden bewegende objecten gevonden maar doordat de camera’s langs de weg staan, weten we dat dit effectief voertuigen zijn. De snelle segmentatie ligt aan de basis van het behalen van de realtime constraints. Deze stap wordt verder versneld door de beelden vooraf te downsamplen. Het resultaat van de segmentatie wordt vervolgens gecomprimeerd met behulp van een run length codering zodat de blobdescriptoren efficiënt berekend konden worden. Omdat we natuurlijk de unieke voertuigen willen tellen over alle frames, werden deze blobs getrackt. De correspondentie tussen blobs in opeenvolgende frames wordt gevonden op basis van de locatie. In de laatste stap worden de voertuigen geteld wanneer ze aan een aantal condities voldoen. Tijdens het prototype werden een heel aantal algoritmes om voertuigen te localiseren uitgeprobeerd. Enkel de motion gebaseerde methoden waren peformant genoeg om realtime te draaien. We hebben verschillende varianten hiervan uitgeprobeerd met een variërende threshold. De output werd telkens vergeleken met de ground truth data om de resultaten te bekomen. Op alle testfilmpjes was de running average methode gemiddeld gezien het best. Er werd met een threshold van 60, een sensitivity van 90.39% en een precision van 86.27% bekomen. Op de TrafiCam hebben we de resultaten niet op een geautomatiseerde manier kunnen controleren. Het algoritme dat tijdens deze masterproef werd ontwikkeld, kan als basis dienen voor een full-scale video surveillance applicatie die geen kalibratie vereist. Met een uitgebreidere evaluatie en eventueel meer rekenkracht kunnen de prestaties van het algoritme nog verder

5.1 Verbeteringen

44

verbeterd worden. Door de vernieuwde aanpak om voertuigen te tellen, worden al veel problemen met de huidige methoden overwonnen.

5.1

Verbeteringen

De problemen met het huidig algoritme van Traficon zijn met dit nieuwe algoritme opgelost. Er is geen kalibratie meer vereist en voertuigen die tussen 2 rijstroken rijden, worden nu ook correct geteld. Er is echter nog altijd verbetering mogelijk. Traagrijdend verkeer en voertuigen die dicht bij elkaar rijden worden vaak niet goed gedecteerd (ook met de huidige methode van Traficon). Hieronder staan 3 mogelijke verbeteringen. 1. De blob van dichtrijdende voertuigen splitsen aan de hand van extra features die worden getrackt (bv. met SIFT). 2. De prestaties zouden ook omhoog kunnen gaan als de schaduwen worden verwijderd. Er kan eventueel een thermische camera gebruikt worden. Hiermee zijn de dynamische schaduwen sowieso niet zichtbaar. 3. Er zou kunnen worden overgeschakeld naar een appearance gebaseerde methode om voertuigen te detecteren bij traagrijdend verkeer. Doordat de auto’s langer in beeld zijn, is het perfect mogelijk om een meer rekenintensieve methode te gebruiken.

5.2

Toevoegingen

Naast de tellingen kan er ook extra informatie over de voertuigen achterhaald worden. Sommige klanten vinden het bijvoorbeeld nuttig om de rijstrook van de getelde voertuigen te weten. Door onze aanpak is deze informatie verloren gegaan. Het is echter perfect mogelijk om dit achteraf terug te achterhalen. Bij het tellen kan de x-coördinaat van de blob immers worden opgeslagen. Na een bepaalde periode zullen op iedere rijstrook clusters van die coördinaten ontstaan die de positie aangeven. Als hierna een nieuw voertuig wordt geteld, kan het bij de rijstrook van de dichtste cluster gerekend worden. Verder kan ook de snelheid en het type van het elk voertuig worden berekend. Hiervoor heb je wel een bepaalde referentieafstand nodig in het frame. Die is zonder een handmatige kalibratie moeilijk te bepalen. Het is eventueel wel mogelijk om de wegmarkeringen te

5.2 Toevoegingen

45

detecteren. De strepen die de rijstroken scheiden liggen op een vaste afstand van elkaar. Aan de hand van een aantal referentieafstanden kan het perspectief vervolgens berekend worden en daarna de snelheid. Het type voertuig kan worden berekend a.d.h.v. de lengte. Meestal wordt een onderscheid gemaakt tussen moto’s, auto’s en vrachtwagens. De richting van het verkeer zou ook automatisch kunnen berekend worden tijdens een leerfase. Deze richting kan geassocieerd worden met de rijstrook die met de clusters kan worden bepaald. Op die manier kan er zelfs een aparte telling gebeuren voor auto’s in beide richtingen. Om een beter beeld te krijgen van deze mogelijke uitbreidingen werd er een visualisatie van gemaakt (figuur 5.1). Hier zijn de klasse en de snelheid van het voertuig zichtbaar. De gedetecteerde rijbaan en de richting van het verkeer worden aangeduid met een pijl.

Figuur 5.1: Toekomstperspectieven

RESULTATEN PER VIDEO

46

Bijlage A Resultaten per video

(a) Snapshot videosequentie

(b) Resultaten

Figuur A.1: Resultaten in Brussel part 1 (vlot verkeer)



47

(b) Resultaten

Figuur A.2: Resultaten in Brussel part 2 (file)


(b) Resultaten

Figuur A.3: Resultaten in Brussel Watec (traagrijdend verkeer)


(b) Resultaten

Figuur A.4: Resultaten in Singapore Thomson 2 (opkomend verkeer zichtbaar)



48

(b) Resultaten

Figuur A.5: Resultaten in Singapore


(b) Resultaten

Figuur A.6: Resultaten in Brisbane (veel schaduwen)

BIBLIOGRAFIE

49

Bibliografie [1] P. Viola and M. Jones. Rapid object detection using a boosted cascade of simple features. Proceedings of the 2001 IEEE Computer Society Conference on Computer Vision and Pattern Recognition. CVPR 2001, 1:I–511–I–518, 2001. [2] R. Willems. Evaluatie van een beeldverwerkingsalgoritme voor de detectie van fietsers door middel van Histograms of Oriented Gradients. Master’s thesis, Katholieke Hogeschool Sint-Lieven, 2012. [3] Christopher Richard Wren, Ali Azarbayejani, Trevor Darrell, and Alex Paul Pentland. Pfinder : Real-time tracking of the human body. 19(7):780–785, 1997. [4] Chia-Jung Pai, Hsiao-Rong Tyan, Yu-Ming Liang, Hong-Yuan Mark Liao, and SeiWang Chen. Pedestrian detection and tracking at crossroads. Pattern Recognition, 37(5):1025–1034, May 2004. [5] Liang Wang, Tieniu Tan, Huazhong Ning, and Weiming Hu. Silhouette analysisbased gait recognition for human identification. Pattern Analysis and Machine . . . , 25(12):1505–1518, 2003. [6] JM Milla and SL Toral. Computer vision techniques for background modelling in urban traffic monitoring. Urban Transport and . . . , (September), 2010. [7] C. Stauffer and W.E.L. Grimson. Adaptive background mixture models for real-time tracking. Proceedings. 1999 IEEE Computer Society Conference on Computer Vision and Pattern Recognition (Cat. No PR00149), pages 246–252, 1999. [8] T Bouwmans, F El Baf, and B Vachon. Background modeling using mixture of gaussians for foreground detection - A Survey. Recent Patents on Computer Science, 1(3):219–237, 2008.

BIBLIOGRAFIE

50

[9] Ahmed Elgammal, David Harwood, and Larry Davis. Non-parametric model for background subtraction. Computer Vision ECCV 2000, 2000. [10] Kentaro Toyama and John Krumm. Wallflower: Principles and practice of background maintenance. Computer Vision, 1999, (September), 1999. [11] J Rymel, J Renno, and D Greenhill. Adaptive eigen-backgrounds for object detection. . . . , 2004. ICIP’04. 2004 . . . , 2004. [12] Olivier Barnich and Marc Van Droogenbroeck. ViBe: a universal background subtraction algorithm for video sequences. IEEE transactions on image processing : a publication of the IEEE Signal Processing Society, 20(6):1709–24, June 2011. [13] G. Bradski and A. Kaehler. Learning OpenCV, computer vision with the OpenCV library, pages 252–254. O’reilly Media, Inc., 2008. [14] Y. Bogomolov, G. Dror, S. Lapchev, E. Rivlin, and M. Rudzsky. Classification of Moving Targets Based on Motion and Appearance. Procedings of the British Machine Vision Conference 2003, pages 44.1–44.10, 2003. [15] A Rosenfeld and JL Pfaltz. Sequential operations in digital picture processing. Journal of the ACM (JACM), 1966. [16] Connected-component labeling. http://en.wikipedia.org/wiki/ Connected-component_labeling, 2012. [Online; accessed 9-December-2012]. [17] Frederick M Waltz and John W V Miller. A comparison of connected-component algorithms. [18] Andrew Senior, Arun Hampapur, and YL Tian. Appearance models for occlusion handling. Image and Vision . . . , 2006. [19] U C Berkeley, Dieter Koller, and Joseph Weber. Robust Multiple Car Tracking with Occlusion Reasoning. 1994. [20] Qi Zang and Reinhard Klette. Object classification and tracking in video surveillance. Computer Analysis of Images and Patterns, 2003. [21] Nathan Funk. A study of the kalman filter applied to visual tracking. University of Alberta, Project for CMPUT, pages 1–26, 2003.

LIJST VAN FIGUREN

51

Lijst van figuren 1.1

De 2 meest gebruikte methoden om voertuigen te detecteren . . . . . . . .

2.1 2.2 2.3 2.4 2.5 2.6

Enkele HOG modellen . . . . . . . . . . . Sliding window methode met HOG model Segmentatie . . . . . . . . . . . . . . . . . Connected component labeling . . . . . . . Connectiviteit buren . . . . . . . . . . . . Bounding box distance . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

4 4 6 8 10 12

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11

Lokalisatie . . . . . . . . . . . . . . . . . . . . . . De pipeline van het algoritme . . . . . . . . . . . Vereenvoudigd UML diagram van het prototype . De TrafiCam . . . . . . . . . . . . . . . . . . . . CPU-gebruik bij het verwerken van frames . . . . Vergelijking tussen 3 snelle segmentatiemethoden Gedownsampelde frames (factor 10) . . . . . . . . Resultaat van een mediaan filter . . . . . . . . . . Runlength encoding . . . . . . . . . . . . . . . . . Visualisatie van het vormen van blobs . . . . . . . Voertuigen met vorige posities . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

16 17 18 19 21 22 23 24 25 27 30

4.1 4.2 4.3 4.4 4.5 4.6 4.7

Bovenste deel van een videoframe met de codec De framenummers worden in bins gestopt . . . . Vergelijking met ground truth . . . . . . . . . . Verwerking resultaten . . . . . . . . . . . . . . . Gemiddelde resultaten . . . . . . . . . . . . . . Offline GUI . . . . . . . . . . . . . . . . . . . . Vergelijking verwerkingstijd . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

32 33 34 35 37 39 40

. . . . . .

. . . . . .

. . . . . .

. . . . . . .

2

LIJST VAN FIGUREN

52

4.8 4.9

Evaluatie van het algoritme online . . . . . . . . . . . . . . . . . . . . . . . Snapshot video-opname . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41 41

5.1

Toekomstperspectieven . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

A.1 A.2 A.3 A.4 A.5 A.6

Resultaten Resultaten Resultaten Resultaten Resultaten Resultaten

46 47 47 47 48 48

in in in in in in

Brussel part 1 (vlot verkeer) . . . . . . . Brussel part 2 (file) . . . . . . . . . . . . Brussel Watec (traagrijdend verkeer) . . Singapore Thomson 2 (opkomend verkeer Singapore . . . . . . . . . . . . . . . . . Brisbane (veel schaduwen) . . . . . . . .

. . . . . . . . . . . . . . . . . . zichtbaar) . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

Ontwikkeling van een beeldverwerkingsalgoritme om voertuigen te tellen

Recommend Documents