Diplomarbeit Motion Tracking mit Webcams

Transcrição

STUDENTEN
Stephan Graf, Sascha Hofer, Martin Schindler
BETREUENDER DOZENT
Marcus Hudritsch
EXPERTE
Dr. Peter Fornaro
AUFTRAGGEBER
Marcus Hudritsch
DA09_0405
Muttenz, Dezember 2004
Diplomarbeit Motion Tracking
Vorwort
An dieser Stelle soll ein Danke an all diejenigen ausgesprochen werden, die das Zustandekommen dieser Diplomarbeit ermöglicht haben.
Ganz besonders danken möchten wir uns bei Herrn Marcus Hudritsch für die hervorragende Zusammenarbeit und die tatkräftige Unterstützung in allen Angelegenheiten, sowie
seinen kritischen Fragen und guten Ratschlägen, die uns sicher zum Ziel geführt haben.
Des weiteren einen speziellen Dank an Herrn Knobel und seinen Mitarbeitern der Firma
IFE in Laufen, sowie Herrn Thomas Scheidegger alias NETMaster für ihre hilfreichen
Tipps.
Zu guter Letzt danken wir unseren Eltern, die durch ihre finanzielle und sonstige Unterstützung, das Studium erst möglich machten.
Seite 2 von 107
Abstract
Das digitale Erkennen und Erfassen von Bewegung im Raum gehört sicherlich zu den faszinierendsten Gebieten der Informatik. Mitunter gehört es aber auch zu den komplexeren
Problemen.
Die Diplomarbeit Motion Tracking mit Webcams wurde von Herrn Hudritsch, Dozent an der
Fachhochschule beider Basel, im Anschluss an die gleichnamige Projektarbeit initiiert.
Die grundsätzliche Machbarkeit eines Motiontrackings auf der Basis von Webcams wurde
im Rahmen der Projektarbeit erwiesen und in einer ersten Form umgesetzt. Zu Beginn der
Diplomarbeit wurde als Ziel vereinbart, die Benutzeroberfläche der vorangegangenen Projektarbeit als Client-Server Architektur umzusetzen, welche unabhängig von der Anzahl
Kameras sein soll. Ein weiterer Punkt war die weitgehende Automatisierung der Kalibrierung.
Die Diplomarbeit zeichnete sich durch ein breites Spektrum an verwendeten Technologien, wie COM, DirectShow unter .NET, C++, C-Sharp und Multithreading aus. Aber auch
Fachwissen in Elektronik und handwerkliches Geschick sowie die praktische Umsetzung
der Kenntnisse in Bildverarbeitung und verteilten Anwendung waren gefragt.
Im Rahmen einer weiterführenden Arbeit könnte eine Umsetzung der 3D-Daten in einem
Robotersystem, 3D-Animationssoftware oder Spieleanwendung ein Thema sein.
Seite 3 von 107
Inhaltsverzeichnis
1.
Einleitung..................................................................................................................7
1.1. Umfang der Diplomarbeit ........................................................................................8
1.1.1. Hauptziele ........................................................................................................8
1.1.2. Erweiterte Ziele ................................................................................................8
1.1.3. Erreichte Ziele ..................................................................................................8
2.
Erarbeitete Grundlagen ...........................................................................................9
2.1. Grundlagen Motion Tracking ..................................................................................9
2.2. Auswahl Kameras...................................................................................................9
2.3. Kalibrierung ..........................................................................................................10
2.4. Featurepunkt Extraktion........................................................................................11
2.4.1. Evaluation der kontrastreichen Punkte...........................................................11
2.4.2. LED von Umgebung unterscheiden ...............................................................12
2.4.3. LED von anderem LED unterscheiden...........................................................12
2.4.4. LED erfassen und Position berechnen...........................................................13
2.4.5. LED Identifikation mittels Tracking und Farbe................................................13
2.5. Synchronisation der Kameras...............................................................................14
3.
DirectShow .............................................................................................................15
3.1. COM - The Component Object Model ..................................................................16
3.2. DirectShow Filter ..................................................................................................17
3.3. DirectShow Interfaces...........................................................................................18
3.3.1. ICaptureGraphBuilder2 ..................................................................................18
3.3.2. IGraphBuilder .................................................................................................18
3.3.3. IBaseFilter ......................................................................................................18
3.3.4. IMediaFilter ....................................................................................................18
3.3.5. IMediaControl.................................................................................................19
3.3.6. IMediaEventEx ...............................................................................................19
3.3.7. IMediaSeeking ...............................................................................................19
3.3.8. IMediaPosition................................................................................................19
3.3.9. IMediaEvent ...................................................................................................19
3.3.10. Implementation in C# .....................................................................................19
3.4. DirectShow Filter Graph Manager ........................................................................21
3.5. Erstellen eines Filter Graphen ..............................................................................22
3.6. Capturing mit DirectShow .....................................................................................24
3.7. Steuerung der Eigenschaften in den Code implementieren..................................25
4.
Softwarekonzept ....................................................................................................27
4.1. Der Client..............................................................................................................28
4.1.1. Filter-Server ...................................................................................................28
Seite 4 von 107
4.1.2. 2D-Tracker (IPAN) .........................................................................................29
4.1.3. Client Netzwerkmodul ....................................................................................29
4.1.4. Kalibrierung ....................................................................................................29
4.1.5. TSAI-Converter ..............................................................................................29
4.1.6. DirectShow Graph..........................................................................................30
4.1.7. Klassenstruktur des Clients............................................................................31
4.2. Der Server ............................................................................................................32
4.2.1. Server Netzwerkmodul...................................................................................32
4.2.2. Auto Assoziation ............................................................................................33
4.2.3. 3D-Tracker .....................................................................................................33
4.2.4. OpenGL .........................................................................................................33
4.2.5. Klassenstruktur des Servers ..........................................................................33
5.
Interprozesskommunikation (IPC) ........................................................................34
5.1. Einleitung ..............................................................................................................34
5.2. Anforderungen ......................................................................................................34
5.3. Protokoll................................................................................................................35
5.3.1. Verbindungsrelevante Informationseinheiten .................................................35
5.3.2. Datentransport bezogene Informationseinheiten............................................35
5.3.3. Verbindungsaufbau und Abbau......................................................................36
5.3.4. Heartbeat .......................................................................................................37
6.
Datenstruktur .........................................................................................................38
6.1. FPFrame/Color .....................................................................................................39
6.2. FPFrameArray/Container......................................................................................40
7.
2D-Tracker ..............................................................................................................41
7.1. Einleitung ..............................................................................................................41
7.2. Das Featurepoint Tracking Problem .....................................................................42
7.3. Definition Featurepoint Tracking Problem.............................................................43
7.4. Anforderungen ......................................................................................................43
7.5. Evaluation .............................................................................................................44
7.6. Tracking Algorithmus ............................................................................................45
7.6.1. Beschreibung .................................................................................................45
7.6.2. Initialisierung ..................................................................................................46
7.6.3. Fortführendes Tracking ..................................................................................47
7.6.4. Postprocessing...............................................................................................47
7.6.5. Kostenfunktion ...............................................................................................48
7.6.6. Typische Trackerparameter ...........................................................................51
8.
3D-Tracker ..............................................................................................................53
8.1. Synchronisation ....................................................................................................53
8.2. Berechnung der 3D-Position.................................................................................54
8.3. Schnitt zweier windschiefen Geraden...................................................................55
Seite 5 von 107
8.4.
8.5.
8.6.
Töpfe und Kugeln .................................................................................................56
Bone-Model (Knochenmodell) ..............................................................................58
Epipolarlinie ..........................................................................................................59
9.
Transformfilter .......................................................................................................60
10. Kalibrierung............................................................................................................62
11. Featurepunkt-Bodypunkt-Assoziation .................................................................71
12. Hardware.................................................................................................................73
12.1. Computer ..............................................................................................................73
12.2. Client-Rechner:.....................................................................................................73
12.3. Server-Rechner: ...................................................................................................73
12.4. Installierte Software ..............................................................................................73
12.5. Webcam ...............................................................................................................74
12.6. Kalibrierungswürfel ...............................................................................................75
12.7. LED Exoskelett .....................................................................................................76
12.7.1. Schema Stromversorgung LED-Exoskelett ....................................................77
12.7.2. Bestückungsplan Stromversorgung LED Exoskelett ......................................78
12.7.3. Stückliste Stromversorgung LED Exoskelett ..................................................78
12.7.4. Technische Daten LEDs ................................................................................79
13. Ausblick ..................................................................................................................80
14. Quellenverzeichnis ................................................................................................81
14.1. Literatur ................................................................................................................81
14.2. Internet .................................................................................................................82
15. Anhang....................................................................................................................83
15.1. Testreihen.............................................................................................................83
15.2. Protokolle..............................................................................................................90
15.3. Wochenrapporte ...................................................................................................99
15.4. Abbildungen........................................................................................................105
15.5. Ehrlichkeitserklärung ..........................................................................................106
15.6. Diplomarbeits CD-ROM ......................................................................................107
Seite 6 von 107
1.
Einleitung
Motion Tracking ist ein Verfahren, um die Koordinaten eines Raumpunktes in Echtzeit zu
bestimmen und zu verfolgen. Einerseits müssen im Raum die interessanten Punkte vom
restlichen Bild unterschieden werden (Featurepunkt Extraktion) - und das von mehreren
Kameras gleichzeitig (Synchronisation) - andererseits müssen die Punkte auch identifiziert
und über einen Zeitraum hinweg zuverlässig verfolgt werden können (Featurepoint Tracking) und schliesslich müssen Beziehungen zwischen den unterschiedlichen Kamerabildern hergestellt werden, so das identische Bildpunkte auch richtig in den 3-Dimensionalen
Raum zurückgerechnet werden können (3D-Tracking). Damit bei diesen Umrechnungen
die korrekten Resultate herauskommen, müssen alle Kameras optimal zueinander positioniert sein (Kamera-Setup) und es muss eine Beziehung zwischen aufgenommenem Bild
und der Realität hergestellt werden (Kalibrierung).
Erst wenn all diese Dinge - jedes für sich und alle miteinander - korrekt funktionieren, ist
ein korrektes Tracking überhaupt möglich. (GUI-Applikation/Engine)
Ziel dieser Diplomarbeit war es, ein funktionierendes Motiontracking System aufzubauen,
das aus kostengünstigen und allgemein erhältlichen Komponenten zusammengesetzt ist
und trotzdem brauchbare Resultate liefert.
Seite 7 von 107
1.1. Umfang der Diplomarbeit
Es wurden 6 Hauptziele und einige erweiterte Ziele definiert. Mit dem Erreichen der
Hauptziele sind die Anforderungen des Auftraggebers erfüllt. Die Nebenziele werden je
nach Verlauf der Diplomarbeit realisiert.
1.1.1. Hauptziele
•
Kalibrierung automatisieren
•
Applikation überarbeiten
Æ Integration aller Bauteile der Projektarbeit
Æ GUI erweitern
Æ Client-Server Architektur
Æ Remote Control wichtiger Funktionen des Clients über den Server
•
Übertragung von 2D-Daten aus DirectShow in die Applikation
•
Speicherformate für 2D- und 3D Daten definieren
•
Gespeicherte Videos laden und verarbeiten
•
3D Tracker anpassen und optimieren
1.1.2. Erweiterte Ziele
•
FP zu BP Assoziation automatisieren (z.B. durch Standardschemas abhängig von
der Kameraperspektive)
•
Kontrolle des Clients aus der Serverapplikation aus
•
Realtime Tracking
•
Exoskelett verbessern: Aufhängung / Farben: mehr unterschiedlich farbige LEDs
•
Verbesserung des Setups: Ortsunabhängigkeit/Lichtunabhängigkeit -> erhöhtes
Budget erforderlich (z.B. Vorhänge/Zelt/Abgedunkelter Raum etc.)
•
Bewegungsglättung
1.1.3. Erreichte Ziele
Die Hauptziele der Diplomarbeit wurden vollumfänglich erreicht. Die automatische Assoziation konnte ebenfalls realisiert werden. Auch das Realtime Tracking konnte erfolgreich in
die Praxis umgesetzt werden.
Seite 8 von 107
2.
Erarbeitete Grundlagen
2.1. Grundlagen Motion Tracking
Der Einsatzbereich von Motion Tracking reicht von Überwachungssystemen über Robotik
bis zur Unterhaltungsindustrie. Neben teuren elektromagnetischen Techniken bieten sich
Lösungen mit Echtzeit-Videobildanalyse an, insbesondere seit so genannte Webcams
schon für 100-200 Fr. erhältlich sind. Um die Koordinaten eines Raumpunktes eindeutig zu
bestimmen, braucht es im Minimum 2 Videobilder desselben Punktes aus zwei verschiedenen Blickrichtungen. Eine Schwierigkeit bei mehreren Videobildern ist deren Synchronisation. Gelingt es nicht, mehr als eine Webcam an einem PC anzuschliessen, so müssen
mehrere PCs mit je einer Webcam über ein Netzwerk synchronisiert werden.
2.2. Auswahl Kameras
Folgende Webcams standen zu Beginn zur Auswahl:
Logitech QuickCam
Logitech QuickCam
Philips ToUcam
Sony Ezee Kit
Pro USB (Dark
Pro 4000
Pro PCVC 730K
CMR PC-4
Focus Ring)
Nach einer umfassenden Analyse der Bildqualität und Eigenschaften der vier Kameras,
entschieden wir uns für die Logitech QuickCam Pro 4000, welche am wenigsten rauscht
bei Dunkelheit, ausserdem werden die Treiber von Logitech immer noch weiterentwickelt,
was man z.B. von Philips nicht behaupten kann.
Seite 9 von 107
2.3. Kalibrierung
Punkte in einem Bild oder einem Video müssen später in einem 3D Raum dargestellt werden. Dazu wird das Tsai Camera Calibration Tool, kurz Tsai, verwendet. Dieses Programm kann durch einfache Übergabe einer Liste mit X, Y, Z (Weltkoordinaten) und U, V
(Bildkoordinaten) von Punkten eine Kalibrierungsdatei erstellen, welche die nötigen Parameter für die weiteren Berechnungen beinhaltet.
Weitere Berechnungen, welche verwendet werden, sind Umwandlungen von Bild- zu
Weltkoordinaten und umgekehrt. Bildkoordinaten sind einfach zu ermitteln, zur Verfügung
stehen Photoshop oder ein ähnliches Produkt. Der Arbeitsplatz auf einer Fläche von 7,2m
x 3,6m wurde anhand eines Rasters auf dem Boden markiert. Bei den Schnittpunkten des
Rasters wurden an der Decke Fäden montiert, an welchen in einem Abstand von 70 cm
Holzkugeln aufgehängt sind, welche uns als zusätzliche Kalibrierungspunkte dienen. So
stehen im Idealfall insgesamt 52 Kalibrierungspunkte zur Verfügung.
Abb. 2-1 Testraum Motion Tracking
Bei der Umwandlung von Welt- zu Bildkoordinaten wurde eine Genauigkeit von +/- 3 Pixel
erreicht. Umgekehrt wurde eine Genauigkeit von +/- 5 cm pro Punkt erreicht. Diese Werte
sind abhängig von der Kamera (Auflösung, Qualität der Bilder) und deren Kalibrierung.
Seite 10 von 107
2.4. Featurepunkt Extraktion
Die Aufnahme und Detektion von kontrastreichen Punkten ist ein nicht ganz einfaches Unterfangen und es gibt ganze Bücher über Wege, wie man dies umsetzen kann. Um aber
den Umfang der Projektarbeit nicht zu sprengen, wurden im Setup die Umgebungsbedingungen optimiert, um innert der zur Verfügung stehenden Zeit brauchbare Resultate liefern zu können.
Die wichtigste davon, ist das Abdunkeln der Umgebung, um störende Hintergrundeffekte
zu unterdrücken. Um so kontrastreiche Punkte zu erzeugen, ist damit eine Lichtquelle
praktisch vorgeschrieben.
2.4.1. Evaluation der kontrastreichen Punkte
Zu Beginn der Testreihe standen folgende Objekte zur Auswahl:
Tannenbaumbeleuchtung
LED
Zuerst wurde mit Glühbirnen und danach mit LEDs experimentiert. Wobei die Glühbirnen
zwar besser sichtbar waren als die LEDs, aber leider vor allem vom Stromverbrauch her
problematisch waren(Man hätte Stromkabel gebraucht). Die LEDs wiederum leuchteten
zwar in Batteriebetrieb, waren dafür aber sehr stark richtungsabhängig und damit nicht aus
allen Richtungen genügend stark sichtbar. Ausserdem waren sie zu klein, um mit typischen Webcam Auflösungen gut detektiert werden zu können.
Diesen Problemen konnten wir mit Hilfe von Pingpongbällen Herr werden. Wir steckten die
ungleichmässig leuchtenden LEDs in weisse Pingpongbälle. Diese diffundierten einerseits
Seite 11 von 107
die Lichtabstrahlung genügend stark, so dass die Richtungsabhängigkeit keine Rolle mehr
spielte und andererseits wurde dadurch, das nun nicht mehr der relativ kleine LED Leuchtkörper, sondern der gesamte Pingpongball leuchtete, die Detektion erheblich verbessert.
2.4.2. LED von Umgebung unterscheiden
Erkennung anhand von Farbton, bzw. Helligkeitsschwellwert der überschritten wird.
•
Implementation eines Transformfilters, der alle Pixel eines Frames welche einen
Helligkeitswert unterhalb des Schwellwerts haben auf Schwarz setzt.
2.4.3. LED von anderem LED unterscheiden
Im Normalfall lassen sich LEDs klar wegen der räumlichen Trennung von anderen LEDs
unterscheiden. Allerdings entstehen Probleme, wenn die räumliche Trennung nicht gewährleistet ist (Überlappungen). Durch verschiedene Farben liesse sich da Abhilfe schaffen, allerdings ist dies möglicherweise problematisch, da die Raumbeleuchtung und die
Ausrichtung der LEDs zur Kamera in die Farbtöne einfliesst.
•
Implementation eines weiteren Transformfilters, der von den verbleibenden hellen
Pixeln Vergleiche mit vorgegebenen Grundfarbtönen vornimmt und sie in die jeweils
am besten passende Grundfarbe umwandelt.
Nach der Farbkonvertierung erhalten wir für jeden Frame ein Bild aus Farbflecken, aus der
man auch überlappende LEDs, anhand der Farbe klar unterscheiden kann.
Abb. 2-2 Anordnung der LEDs
Seite 12 von 107
2.4.4. LED erfassen und Position berechnen
Benachbarte helle Pixel desselben Farbtons müssen nun zu Gruppen zusammengefasst
werden. Aus jeder Gruppe wird der Positionsschwerpunkt berechnet, der der Position eines LEDs entspricht. Mögliche Probleme sind durch Spiegeleffekte entstandene Zerteilung
der hellen Pixelregion in mehrere Einzelteile und dadurch überschüssige fehlerhaft erkannte LEDs.
•
Implementation eines Detektoralgorithmus, der uns zusammengehörende Pixelregionen in LED Zonenobjekten zusammenfasst.
•
Implementation eines LED Zonenobjektes mit Methode zur Berechnung von Pixelschwerpunkt und Methode zur Kalkulation der Punktmenge, die der Zone angehören.
•
Evt. Implementation eines Detektors, der fehlerhafte oder ungültige Zonen entdeckt
bzw. geteilte Zonen zusammenfasst.
2.4.5. LED Identifikation mittels Tracking und Farbe
Die vorherigen Schritte reduzieren die Trackingaufgabe auf das so genannte Featurepunkt
Tracking Problem, welches sich mit Punktmengen in einer Sequenz von Frames befasst.
Aufgabe ist es, einen geeigneten Algorithmus zu finden bzw. zu implementieren, der die
Trajektorien der Punkte erfasst.
Was die Identifikation der LEDs betrifft, so werden diese zu Beginn der Sequenz manuell
identifiziert. Danach müssen sie anhand von Bewegungstracking mit Feature Point Algorithmen erfasst bleiben. Farbkennung von potentiell verwechslungsträchtigen LEDs ermöglicht eine verbesserte Identifikation und dient als Unterstützung für den Feature Point
Algorithmus.
•
Analyse und Evaluation existierender Feature Point Algorithmen
•
Wahl und Implementation eines geeigneten Algorithmus, der uns schliesslich einen
Array von detektierten Punkten samt Identifikation liefert.
An dieser Stelle ist das Tracking auf 2-Dimensionaler Ebene abgeschlossen und die Daten
werden zwecks Entzerrung und Transformation in Weltkoordinaten weitergegeben.
Seite 13 von 107
2.5. Synchronisation der Kameras
Damit alle Kameras zeitgleich mit dem Tracking beginnen, haben wir unseren Transformfilter so erweitert, dass er bei einer plötzlichen Verdunkelung des Raums ausgelöst wird.
Die Aufnahme startet, wenn zu Beginn der Aufnahme das Licht eingeschaltet ist, und nach
einigen Sekunden der Aufnahme ausgeschaltet wird. Genau zu diesem Zeitpunkt beginnen dann alle Kameras mit der Detektion und die Synchronisation ist so während des
Starts gewährleistet.
Seite 14 von 107
3.
DirectShow
DirectShow (früher ActiveMovie) ist eine Multimedia Architektur welche von Microsoft entwickelt wurde. Sie wird von Microsoft frei zur Verfügung gestellt, als ein Teil von DirektX.
DirectShow teilt die Verarbeitung von verschiedenen Multimedia Tasks wie Video Playback in verschiedene Sets von Schritten auf, bekannt als Filter. Filter haben eine gewisse
Anzahl von Input und Output Pins welche man zusammen verbinden kann. Das generische Design von diesem Verbindungsmechanismus ermöglicht es, dass Filter auf unterschiedlichste Weisen verbunden werden können. Dies ermöglicht dem Entwickler das eigene Filter und Effekte in den Filter Graph eingebaut werden können, weshalb wir uns
dann auch für DirectShow entschieden haben. DirectShow Filter Graphen werden vor allem für das abspielen von Videos benutzt (in welchem der Filter verschiedene Funktionen
liefert wie File Parsing, Video und Audio De-Multiplexing, sowie Dekompression und Rendering) und sie werden häufig eingesetzt für Video-, Audio recording und editing. Interaktive Tasks wie DVD Navigation sind auch erfolgreich eingebunden in DirectShow.
Abb. 3-1 Aufbau einer DirectShow Applikation
Seite 15 von 107
3.1. COM - The Component Object Model
Dies ist ein Mechanismus zur Identifizierung und Kommunikation zwischen ApplikationsKomponenten in einer generischen Art und Weise. Die COM Kommunikation findet über
Interfaces oder Gruppen von Funktionen statt. ActiveX basiert z.B. auf COM. Eine Gruppe
von Funktionen ist fest definiert (beinhaltet alle Parameter und Rückgabe Werte) und identifiziert sich über eine einmalige 128-bit Interface ID (globally-unique id oder GUID). Ein
COM Objekt wird durch einen Aufruf an die WIN32 API erstellt und gibt einen Pointer zu
einem spezifischen Interface zurück. Das Model basiert auf einer abstrakten C++ Klasse.
Wie eine abstrakte Basis Klasse, kann ein Objekt verschiedene Interfaces implementieren:
jedes Interface besitzt dabei QueryInterface Methoden welche es erlauben ein anderes
Interface im selben Objekt zu finden.
Applikation
DirectShow
Control
COM Interfaces
MCI
DirectShow
Filter Graph Manager
Source Filter
Media Source
Tranform Filter
Renderer Filter
Media Destination
Abb. 3-2 Kommunikation über COM Interfaces
Seite 16 von 107
3.2. DirectShow Filter
DirectShow Applikationen benutzen einen Graph von Filtern um Multimedia Daten zu verarbeiten. Typischerweise fliessen Multimedia Daten durch den Graph von einem Source
File aus zu einem Zielgerät oder Fenster mit welchem die Applikation die Operation kontrolliert, aber in gewissen fällen will die Applikation die Daten selber verwalten oder empfangen also bedeutet dies nur bereitgestellte Kontrolle.
Ein typischer Graph welcher eine Video Datei wiedergibt, zeigt
•
einen Source Filter, verantwortlich Daten von einem File ( oder URL) zu lesen.
•
ein Parser Filter welcher die Ausgabe von Audio und Video Daten separiert und sie
zum passenden Decoder weitergibt.
•
einen Decoder für die Dekompression der Video Daten.
•
ein Rendering Filter für Audio und Video welche die dekomprimierten Daten nimmt
und sie abspielt oder zeichnet.
Abb. 3-3 Typischer DirectShow-Filtergraph
Filter sind COM Objekte welche ein Set von COM Interfaces bieten, prinzipiell IBaseFilter.
Sie können eine beliebige Anzahl von Input und Output Pins aufweisen (Objekte werden
durch IBaseFilter::EnumPins entnommen) welche ein Set von Pin Interfaces (IPin) beinhalten. Wenn Pins von zwei Filtern miteinander verbunden werden, erhalten die Pins einen
übereinstimmenden Media Type welcher den Austausch von Daten definiert. Der Media
Type wird dann auf jedem anderen Interface zur Verfügung gestellt, welcher benutzt wird
um Daten auszutauschen.
Seite 17 von 107
Um ein File abzuspielen wird DirectShow verwendet, eine Applikation kreiert einen Filter
Graph Manager, dieser fragt das Objekt an einen Graphen zu erstellen, der für das File
verwendet wird. Die Applikation kann dann auch, für das abspielen und anhalten des Files,
das IMediaControl Interface verwenden.
DirectShow Filter sind alle User Mode Code. Für equivalente Funktionalität im Kernel
Mode, sollte man WDM Streaming benutzen.
3.3. DirectShow Interfaces
3.3.1. ICaptureGraphBuilder2
ICaptureGraphBuilder ist ein Interface welches einen allein stehenden Filter benutzen
kann der mehr als ein Pin von jeder Kategorie besitzt.
z.B. können gewisse Devices Video und Audio aufnehmen.
3.3.2. IGraphBuilder
IGraphBuilder ist abgeleitet von IFilterGraph, dieses Interface besitzt einen intelligenten
Verbindungsaufbau der einzelnen Filter. Es unterstützt das erstellen von Graphen durch
automatische Selektion und Verbindung von geeigneten Filtern.
3.3.3. IBaseFilter
Alle Multimedia Komponenten können dieses Interface benutzen.
Dieses Interface abstrahiert ein Objekt welches Input und Output Verbindungen herausschreibt und dynamisch aggregiert werden kann.
3.3.4. IMediaFilter
Unterstützt die Synchronisation und einen Aktivitäts-Status: IBaseFilter ist abgeleitet von
diesem Interface, alle Filter unterstützen IMediaFilter. Ausser ein paar Objekten (wie z.B.
Plug-In Control Verteiler) unterstützen IMediaFilter aber nicht IBaseFilter.
IMediaFilter ist wiederum abgeleitet von IPersist, so dass alle Filter die Funktion GetClassID() unterstützen.
Seite 18 von 107
3.3.5. IMediaControl
Steuerung eines Videostreams mittels Funktionen wie abspielen, anhalten, pause, usw.
3.3.6. IMediaEventEx
Gibt an wenn ein Mediastream zu ende ist.
3.3.7. IMediaSeeking
Sucht oder ruft die angegebene Position des Mediastreams auf.
3.3.8. IMediaPosition
Ähnlich zu IMediaSeeking auch hier kann die Position des Mediastreams angegeben werden.
3.3.9. IMediaEvent
Unterstützt ein Event Anzeigeschema, asynchron zu der Applikation.
Dieses Interface verhält sich so als wenn Events in einem Queue gehalten werden. Ein
Aufruf von IMediaEventSink::Notify ersetzt den Event in diesem Queue. Beim Aufruf GetEvent wird das erste Element des Queues entfernt und kehrt zurück. Elemente kehren
zurück in der Reihenfolge in welcher sie anstehen (es gibt kein Prioritäts Schema). Der
Handle Event ist ein Signalstatus für den Fall das der Queue nicht leer ist.
3.3.10.
Implementation in C#
Wenn einmal alle Interfaces in C# definiert wurden, können sie ähnlich aufgerufen werden,
wie es in C++ der Fall wäre:
// ======== C++ code to create the COM instance of Filter Graph ========
JIF(CoCreateInstance(CLSID_FilterGraph, NULL, CLSCTX_INPROC_SERVER,
IID_IGraphBuilder, (void **)&pGB));
// Have the graph builder construct its the appropriate graph automatically
JIF(pGB->RenderFile(wFile, NULL));
// QueryInterface for DirectShow interfaces
JIF(pGB->QueryInterface(IID_IMediaControl, (void **)&pMC));
....
Seite 19 von 107
... CoCreateInstance wird mit Activator.CreateInstance ersetzt, und QueryInterface ist ein
einfacher cast in C#:
// ======== C# code to create the COM instance of Filter Graph ========
Type comtype = null;
object comobj = null;
try {
comtype = Type.GetTypeFromCLSID( Clsid.FilterGraph );
if( comtype == null )
throw new NotSupportedException( "DirectX (8.1 or higher) not
installed?" );
comobj = Activator.CreateInstance( comtype );
graphBuilder = (IGraphBuilder) comobj; comobj = null;
int hr = graphBuilder.RenderFile( clipFile, null );
if( hr < 0 )
Marshal.ThrowExceptionForHR( hr );
mediaCtrl
= (IMediaControl)
graphBuilder;
Im Projekt DShowNET sind die wichtigsten DirectShow Interfaces nach C# umgeschrieben
worden.
Die Library wurde von NETMaster erstellt und kann unter
http://www.codeproject.com/cs/media/directshownet.asp heruntergeladen werden
\DirectShow\
\DShowNET\
\DsBugWO.cs
\DsControl.cs
\DsCore.cs
\DsDevice.cs
\DsDVD.cs
\DsExtend.cs
\DsUtils.cs
\DsUuids.cs
\QEdit.cs
// the DirectShow interface definitions :
// workaround for a bug
// ported from control.odl
// ported from axcore.idl
// device enumerator, helper functions
// DVD interfaces from dvdif.idl
// ported from axextend.idl
// utility classes, SDK Common sources
// UUIDs and CLSIDs from uuids.h
// grabber interfaces from qedit.idl
Seite 20 von 107
3.4. DirectShow Filter Graph Manager
Eine DirectShow Applikation interagiert mit einem Filter Graph Manager. Dieser spielt eine
zentrale Rolle für die Kontrolle der Applikation und ist verantwortlich für das erstellen und
kontrollieren des Graphs, dabei verändert der Verteilungsstatus die Information der Filter.
Der Filter Graph Manager ist ein COM Objekt welches mit CoCreateInstance erstellt wird.
Um einen Graph zu erstellen, wird das Interface IGraphBuilder verwendet, entweder vorübergehend in einer Datei oder direkt durch einfügen und verbinden von Filtern. Filter
können indirekt verbunden werden, in diesem Fall verwendet der Filter Graph Manager so
genannte Transform Filter, welche notwendig sind um Data Types zu transformieren, so
dass eine Verbinden erstellt werden kann.
Zusätzlich zu den Grundlegenden Graph-Building Services, kann der Filter Graph Manager als "single point of control" agieren. Die Applikations-Rückfragen für die Kontrolle und
den Status des Interfaces vom Filter Graph Manager, implementieren die Interfaces beim
Aufruf des Graphs. Z.B., ist IMediaControl::Run beim Aufruf der Run Methode von jedem
Filter implementiert (in einer gewählten Reihenfolge: Die Threading Regeln von DirectShow sind so gestaltet, dass man sicher sein kann, dass keine Filter ihren eigenen ThreadBenutzungsstatus ändern müssen. Ohne diese Regeln könnte z.B. ein Deadlock ausgelöst
werden: Grund weshalb der Filter Graph Manager für diese Aufgabe zuständig ist).
Dieser Mechanismus ist erweiterbar via plug-in distributors. Man kann ein COM Objekt als
Distributor für jedes Interface welches momentan vom Filter Graph nicht unterstützt wird
registrieren. D.h. wenn die Applikation für dieses Interface auf dem Filter Graph Manager
rückfragt, schaut die Applikation in der Registry nach einem Distributor Key und wird dann
das Objekt laden. Der Distributor ist beim Aufruf der Filter im Graphen verantwortlich für
die Implementation des Interfaces. Dies liefert einen Erweiterungsmechanismus, so dass
der Filter benutzerdefinierte Interfaces implementieren kann welche ungeschützt geradewegs zur Applikation gehen, sobald es eine Visual Basic Applikation ist. All diese Standard
Control Interfaces sind implementiert als plug-in Distributors in DirectShow. In der Theorie
sind diese ersetzbar, da sie sie aber miteinander verwoben sind, ist die Ersetzbarkeit in
der Praxis schwierig umzusetzen.
Seite 21 von 107
3.5. Erstellen eines Filter Graphen
Wenn man in einer Applikation ein Video oder Media File wiedergeben möchte, so muss
man eine Kopie des Filter Graph Managers erstellen, es wird dann mit „RenderFile“ ein
Graph erstellt welcher eine angegebene Datei oder URL wiedergibt. Der Graph Manager
wird erstellt als ein Graph von Filtern um die angegebene Datei abzuspielen. Die Applikation kann auch selber Graphen bilden, modifizieren oder einen Capture Graph Builder
verwenden um Graphen für spezifische Tasks zu verwenden. Es gibt auch ein visuelles
Tool namens Graph Editor, welches mit DirectX installiert wird, in welchem man verschiedene Filter einfügen und zu einem Graphen verbinden kann.
Wenn man RenderFile anspricht, startet der Filter Graph Manager mit der Auswahl eines
Source Filters für die Datei die angegeben wurde. Es wird eine Tabelle in der Registry
verwendet welche ein Set von Offsets enthält, sowie Masken und Test Bytes um das File
zu überprüfen. Diese gibt eine CLSID des Filters zurück welche für den Source Filter verwenden wird. Weiteres in der DirectShow Dokumentation unter „Registering a custom file
type“.
Es wird dann jeder Output Pin des Souce Filters gerendert. Dies geschieht indem der Filter Graph Manager versucht mit jedem möglichen Filter zu verbinden. Wenn ein neuer Filter verbunden ist, versucht der Filter Graph Manager mit demselben Prozess den Output
Pin beim aktuellen Filter zu rendern. Ein Limit der Tiefe verhindert, dass er einen undefinierten Bereich erreicht. Nach etwa 5 Schritten ohne dass der Pin gerendert wurde gibt er
auf, geht einen Schritt zurück und versucht es mit einem anderen Filter. Nur der „Merit Valaue“ schützt jeden Graph davor mit endlosen Null Filtern gefüllt zu werden. Wenn ein Filter versucht eine Verbindung aufzubauen, verwendet er QueryInternalConnections um
herauszufinden welcher Output Pin es nun braucht um zu rendern.
Filter mit denen versucht wird eine Verbindung aufzubauen: Alle Filter welche im Graph
freie Input Pins besitzen, sowie alle die in der Registry vorhanden sind. Es wird zuerst mit
jedem Filter im Graph versucht eine Verbindung aufzubauen, bevor neue Filter instanziert
werden. Das macht es einfach eigene Filter hinzuzufügen (einfach in den Graph einfügen
bevor der Befehl RenderFile aufgerufen wird. Merke das Media Typen spezifisch genug
sind, so dass der Graph nur den Platz auswählt in dem der Filter gebraucht wird). Wenn
Seite 22 von 107
man einen Filter hat welcher Audio und Video rendert, so wird der Filter einmal zu einem
Video Stream verbunden und der Graph versucht dann auch den Filter für den Audio
Stream zu verbinden.
Es wird nur dann versucht einen Filter von der Registry zu holen, wenn er mit dem richtigen Media Type und Subtype registriert ist. Jeder Filter in der Registry besitzt einen Mertit
Value, diese werden für die Reihenfolge gebraucht. Man kann einen Filter als Wild-Card
Input registrieren (GUID_NULL als Media Type oder als Subtype). Der Filter kann auch
seine Output Pins registrieren: Für das rendering ist dies aber nicht wichtig, aber es wird
dazu benutzt um eine „Verbindungs“-Operation mit einem Filter zu bewerkstelligen. Auch
zu bedenken ist, dass die Information in der Registry uns davor bewahrt unnötig Filter zu
laden. Wenn ein Filter einmal geladen ist, wird die Media Type Information immer vom Pin
entnommen und nicht von der Registry.
RenderFile wird nur einen return true liefern wenn alle Output Pins von dem ausgewählten
Source Filter komplett gerendert wurden (zu vergleichen mit QueryInternalConnections).
Wenn dies fehlschlägt, aber trotzdem ein paar Outputs gerendert werden können, so
werden sie zurückgehen zu dem „best-so-far“ Graph. Dieser gibt zurück, dass die Aktion
nicht erfolgreich war. Der best-so-far ist derjenige Graph welcher der höchste Anteil von
Output Pins mit dem am wenigsten Filtern rendert.
Seite 23 von 107
3.6. Capturing mit DirectShow
Um in DirectShow mit einem Video Device wie einer Webcam zu kommunizieren, muss
man einen CaptureGraph aufbauen.
Dieser wird in verschiedenen Schritten aufgebaut
•
Zuerst muss eine Instanz des ICaptureGraphBuilder2 erstellt werden, welche ähnlich funktioniert wie IGraphBuilder.
•
Danach wird eine AVI Mux-Filter erstellt welcher direkt mit dem File Writer-Filter
verbunden wird. Um den File Writer zu erzeugen, muss auch der Dateipfad übergeben werden.
•
Jetzt muss nur noch der CaptureGraph gerendert werden. Dies geschieht über den
Smart Tee-Filter welcher über mehrere Output Pins verfügt.
•
Mit Hilfe des Smart Tees kann danach auch noch ein "Preview Window" erzeugt
werden.
Instanz ICaptureGraphBuilder2
Guid clsid = Clsid.CaptureGraphBuilder2;
Guid riid = typeof(ICaptureGraphBuilder2).GUID;
comobj = DsBugWO.CreateDsInstance( ref clsid, ref riid );
Console.WriteLine("Capture Graph wurde erzeugt");
capGraph = (ICaptureGraphBuilder2) comobj; comobj = null;
AVI Mux und File Writer werden erstellt:
Guid sub = MediaSubType.Avi;
hr = capGraph.SetOutputFileName( ref sub, fileName, out mux, out sink );
Avi Mux
File Writer
Capture Graph wird erstellt:
Guid cat = PinCategory.Capture;
Guid med = MediaType.Video;
hr = capGraph.RenderStream( ref cat, ref med, capFilter, null, mux ); // stream to file
Capture
Capture
Avi Mux
File Writer
Logitech Quickcam Pro 4000
Smart Tee
Source Filter
Capture Graph wird mit dem Kompressor SampleGrabber erweitert und als Preview ausgegeben:
cat = PinCategory.Preview;
med = MediaType.Video;
hr = capGraph.RenderStream( ref cat, ref med, capFilter, baseGrabFlt, null ); // preview window
Capture
Capture
Avi Mux
File Writer
SampleGrabber
Video Renderer
Smart Tee
Source Filter
Preview
Seite 24 von 107
3.7. Steuerung der Eigenschaften in den Code implementieren
Wenn die Pin-Eigenschaften des Capture Devices angewählt werden erscheint folgendes
Eigenschaftsfenster:
Abb. 3-4 Pin-Eigenschaftsfenster Logitechwebcam
Gewisse Funktionen wie Einzelbildrate, Farbspektrum oder Ausgabegrösse können automatisch gesteuert werden. Dazu muss Device-Filter alleine dastehen, darf also nicht gerendert sein
IAMStreamConfig streamConfig=null;
streamConfig=comObj as IAMStreamConfig;
if(streamConfig == null)
{
Console.WriteLine("IAMStreamConfig not present");
return false;
}
AMMediaType media = new AMMediaType();
streamConfig.GetFormat(out media);
VideoInfoHeader videoInfoHeader = (VideoInfoHeader)
Marshal.PtrToStructure( media.formatPtr, typeof(VideoInfoHeader) );
videoInfoHeader.BitRate=10;
videoInfoHeader.BmiHeader.Width=640;
videoInfoHeader.BmiHeader.Height=480;
videoInfoHeader.BmiHeader.ImageSize=1327104;
videoInfoHeader.AvgTimePerFrame = 30;
Marshal.StructureToPtr(videoInfoHeader, media.formatPtr, false);
streamConfig.SetFormat(media);
return true;
Seite 25 von 107
Wenn die Eigenschaften des Capture Devices im Falle einer WebCam angewählt werden
erscheint folgendes Eigenschaftsfenster:
Abb. 3-5 Eigenschaftsfenster der Logitech Webcam
Auch hier können gewisse Funktionen wie Helligkeit, Kontrast oder Sättigung automatisch
im Code gesteuert werden.
IAMVideoProcAmp videoProc=null;
videoProc=comObj as IAMVideoProcAmp;
if(videoProc == null)
{
Console.WriteLine("IAMVideoProcAmp not present");
return false;
}
VideoProcAmpFlags flag
int pvalue;
= new VideoProcAmpFlags();
videoProc.Get(VideoProcAmpProperty.Brightness, out pvalue, out flag);
pvalue = 34;
videoProc.Set(VideoProcAmpProperty.Brightness, pvalue, flag);
return true;
Seite 26 von 107
4.
Softwarekonzept
Die Applikation wurde anhand einer Client-Server Architektur aufgebaut.
Dabei können beliebig viele Clients mit dem Server Verbunden werden, so dass der Benutzer unabhängig von der Anzahl der Kameras ist. Die Berechnung und Darstellung der
3D-Daten sind beide auf dem Server verankert, dies ermöglicht eine robuste und schnelle
Verarbeitung der 3D-Daten.
Abb. 4-1 Client-Server Architektur
Seite 27 von 107
4.1. Der Client
Bei der Konzipierung der Client-Applikation wurde darauf geachtet, dass der Client modular aufgebaut ist. Somit ist der Client unabhängig von dem verwendeten Gerät, d.h. es
kann eine Logitech Webcam oder aber auch eine DV-Kamera benutzt werden.
Weiter ist es dem Benutzer auch erlaubt auf Videodateien zurückzugreifen was z.B. für
eine Demonstration ohne Kamerageräte von grossem Nutzen sein kann.
Es ist vorgesehen, dass an jeder Client Maschine nur 1 Client mit entsprechender Webcam gestartet wird. Es ist aber durchaus möglich, dass bei einem entsprechend leistungsstarken Rechner auch mehrere Clients gleichzeitig gestartet werden können. Dies ermöglicht dem Benutzer eine höchstmögliche Flexibilität mit dem Umgang des Clients.
Client
2D-Tracker
(IPAN)
Filter-Server
DirectShow
Graph
Snapshot
Kalibrierung
Client
Netzwerkmodul
Kalib
Parameter
TSAI-Converter
Abb. 4-2 Datenfluss des Clients
Der Client verfügt über verschiedene Module wie Kalibrierung, IPAN-Tracker, Client Netzwerkmodul, DirectShow Graph, Filter-Server und TSAI-Converter.
4.1.1. Filter-Server
Die 2D-Daten welche aus dem DirectShow Modul herausgelesen werden, werden hier
gebuffert und dann an das 2D-Trackermodul übergeben.
Seite 28 von 107
4.1.2. 2D-Tracker (IPAN)
Das Trackermodul bereitet die 2D-Daten auf und verbindet diese zu so genannten Trajektorien. Die getrackten 2D-Daten werden an das Client Netzwerkmodul gesendet.
4.1.3. Client Netzwerkmodul
Das Client Netzwerkmodul ist für die Kommunikation zwischen Server und Client zuständig. 2D-Daten und die TSAI Daten werden mittels Serialisierung an den Server gesendet.
Auch ist es möglich Informationen vom Server zu empfangen, da dieses Modul bidirektional aufgebaut ist.
4.1.4. Kalibrierung
Das Kalibrierungsmodul erhält die Bildinformationen (Bitmap) aus dem DirectShow Graph.
Anhand von diesem Bitmap werden dann verschiedene Punkte im Bild herausgelesen um
diese dann unter Zuhilfenahme von TSAI in Kalibparameter umzuwandeln.
4.1.5. TSAI-Converter
Der TSAI-Converter erhält die Kalibparameter von dem Kalibrierungsmodul die Daten
werden konvertiert und anschliessend an das Client Netzwerkmodul gesendet.
Seite 29 von 107
4.1.6. DirectShow Graph
Der DirectShow Graph wurde so aufgebaut, dass er möglichst viel Funktionalität beinhaltet. Dies erleichterte den Aufbau des Clients erheblich, denn es braucht dazu die Instanzen der einzelnen Filter nur einmal zu erzeugen und somit können mit diesem Filter alle
Aufgaben bewältigt werden, ohne dass der Filter komplett neu aufgebaut werden muss.
SWFilter (Transformfilter)
Null Renderer
SampleGrabber
Null Renderer
Infinite Pin Tee Filter
Source Filter
Feature des Graphen:
- Video Einstellungen
- Video Vorschau
- Grabbing
- Aufnahme
- Motiontracking
Video Renderer
AVI Mux
File Writer
Abb. 4-3 Aufbau des DirectShow Filtergraph
Dieser DirectShow Graph ist fähig:
•
ein Video als Vorschau anzuzeigen
•
einzelne Bilder aus dem Video herauszuschreiben (grabben)
•
Videos aufzunehmen und im gewünschten Format abzuspeichern
•
anhand eines eigens dafür geschriebenen Transformfilters die einzelnen Bilder zu
analisieren und die FeaturePoints aus dem 2D-Bild herauszulesen
Seite 30 von 107
4.1.7. Klassenstruktur des Clients
Main
1
DeviceSelector
clsClientController
frmClient
1
1
uscTracker
clsCalibration
clsVideo
uscVideo
clsCapture
uscCapture
uscCalibration
clsTracker
clsNetworkClient
1
Filters
IPictureGrabber
FilterGraphController
clsFilterServer
clsIPANTracker
1
IFPsink
1
1
SampleGrabber
IFPsource
VideoGrabber
FPDetector
ISWFilter
clsFPnetReceiver
clsFPnetSink
Abb. 4-4 Klassendiagramm Client
Seite 31 von 107
4.2. Der Server
Bei der Konzipierung der Server-Applikation wurde darauf geachtet, dass der Verbindungsaufbau möglichst stabil ist. Auch hier wurde ein modulares Design verwendet, welches beliebig viele Clients ermöglicht, die mit einem Server eine Verbindung aufnehmen
können.
Abb. 4-5 Datenfluss der Serverapplikation
Der Server verfügt über verschiedene Module wie Server Netzwerkmodul, 3D-Tracker,
Auto Assoziation und ein OpenGL-Modul
4.2.1. Server Netzwerkmodul
Hier kommen alle Daten zusammen welche von den Clients gesendet werden, diese bleiben in diesem Modul erhalten solange der Server am laufen ist.
Seite 32 von 107
4.2.2. Auto Assoziation
Dieses Modul ist für das Assoziieren der Daten zuständig, die von den Clients gesendet
wurden. D.h. es werden hier Featurepoints zu den entsprechenden Bodypoints zugeordnet
und dies anhand eines vorgegebenen Assoziierungs-Modells.
4.2.3. 3D-Tracker
Hier werden mittels Informationen aus Assoziation und Netzwerkmodul die Daten so zusammengefügt das daraus 3D-Daten entstehen.
4.2.4. OpenGL
Die 3D-Daten werden hier 3-dimensional Dargestellt und in einem OpenGL Fenster ausgegeben.
4.2.5. Klassenstruktur des Servers
Abb. 4-6 Klassendiagramm Server
Seite 33 von 107
5. Interprozesskommunikation (IPC)
5.1. Einleitung
Unser Softwarekonzept sieht vor, alle Teile, die pro Kamera einzeln betrieben werden
müssen, in eine Client Applikation aufzuspalten, und diejenigen Teile, die alle Kameras
gleichermassen betreffen in einer Serverapplikation zu halten. Damit diese beiden Applikationen zusammenarbeiten können, muss zwischen Ihnen eine Verbindung zum Informationsaustausch aufgebaut werden.
Es existieren verschiedenste Möglichkeiten der Interprozesskommunikation, wie z.B. Pipes, Message Queues, RPC, Shared Memory, etc. - Nachfolgend wurden die gegebenen
Anforderungen des Motiontrackingprojektes an IPCs definiert um eine Auswahl treffen zu
können.
5.2. Anforderungen
•
Bidirektionale Kommunikation: Die Natur des Motiontrackings macht es nötig,
eine bidirektionale Kommunikation zu implementieren. Die Clients müssen pro aufgenommenes Frame Informationen an den Server senden. Der Server wiederum
muss den Clients Synchronisationsdaten und Kontrolldaten senden.
•
Stehende Verbindung: Jede Sekunde müssen von allen Clients 30 Datenpackete
gesendet werden. Zusammen würden sich so bei 5 Kameras 150 Verbindungsanfragen pro Sekunde anstauen. Daher ist eine stehende Verbindung für den Datentransport Pflicht.
•
Maschinen übergreifende Kommunikation: Zwar ist ein leistungsstarker PC
durchaus in der Lage, Daten von mehr als einer Kamera gleichzeitig zu verarbeiten, aber für fünf Kameras reicht es dann doch nicht, sei es aus Gründen der Performanz oder fehlender USB Anschlüsse. Es müssen also auch Verbindungen zwischen mehreren PCs möglich sein.
Aufgrund der oben genannten Anforderungen wurde entschieden, eine stehende TCP/IP
Verbindung mit Sockets zu realisieren.
Seite 34 von 107
5.3. Protokoll
In diesem Kapitel wird das Client-Server Kommunikationsprotokoll definiert. Dies umfasst
die Definition der vorkommenden Informationseinheiten, sowie die Art ihrer Verwendung
bei Verbindungsauf- und abbau und bei der Datenübertragung.
5.3.1. Verbindungsrelevante Informationseinheiten
NewConnection: Ein NewConnection enthält ein String mit einer ConnectionID und optional einen String mit dem Hostnamen des Clients.
CloseConnection: CloseConnection wird jeweils dann gesendet, wenn eine Seite den
Abbruch der Verbindung wünscht.
Error: Eine Errornachricht enthält einen String mit einer Fehlermeldung und einen Integer
mit Fehlernummer. Sie dient zum Mitteilen von aufgetretenen Fehlern sowohl Client- wie
auch Serverseitig.
5.3.2. Datentransport bezogene Informationseinheiten
Message: Eine Message enthält einen String mit einer Nachricht.
MessageObject: MessageObjects sind alle Informationseinheiten, die eine zu einem
String serialisierbare Instanz einer bestimmten Klasse enthalten. Beim Datentransfer wandelt das MessageObject die Datenklasse vorübergehend in einen String um, aus dem
beim Empfang wieder eine Objektinstanz mit denselben Eigenschaften erzeugt werden
kann.
Folgende Datenobjekte können von MessageObjects transportiert werden:
•
FeaturePointFrames: Enthält alle Trackingrelevanten Daten eines einzelnen von
der Kamera aufgenommenen Frames. Dieses Packet ist das am meisten verwendete, da jeder Client bei Standardeinstellungen mit der Wiederholrate der WebCam
solche Packete abschickt.
•
TsaiConverter: Diese Datenstruktur, enthält alle Kalibrierungsdaten und wird vom
Client zum Server transportiert.
Seite 35 von 107
•
SyncSignal: Enthält Synchronisationsmerkmale - wird in regelmässigen Intervallen
vom Server and den Client gesendet.
•
Play: Enthält Anweisungen des Servers zum Abspielen eines Videos auf den
Clients.
•
Record: Enthält Anweisungen des Servers zur Aufnahme eines Videos auf den
Clients.
5.3.3. Verbindungsaufbau und Abbau
Ein Verbindungsaufbau wird per Definition von der Seite des Clients aufgebaut. Der Server öffnet zu Beginn einen Port und wartet auf eingehende Verbindungen.
Client
Server
Ein Client initiiert eine Verbindung, in dem er ein
NewConnection Packet mit seinem gewünschten
NewConnection
AnfragePrüfung
NewConnection
…………
Verbindung
etabliert
CloseConnection
Identifikationsnamen sendet. Der Server prüft diese
Information und entscheidet letztendlich, ob die Verbindung gültig ist. In diesem Fall sendet er als Bestätigung das NewConnection Packet an den Client zurück. Gegebenenfalls wurde darin die ConnectionID
angepasst, um Kollisionen mit gleichnamigen Clients
Client
Server
NewConnection
zu vermeiden. Clients müssen dies berücksichtigen.
Ist aus irgendeinem Grunde keine Verbindung möglich, sendet der Server ein Errorpacket mit der Angabe, warum die Verbindung gescheitert ist.
Seite 36 von 107
5.3.4. Heartbeat
Da relativ viele Clients zu einem einzigen Server verbunden werden müssen, wurde der
Verbindungsaufbau weitgehend automatisiert: Sobald ein Server gestartet wird, beginnt er
auf einem vereinbarten Multicast Kanal in regelmässigen Intervallen ein Heartbeatsignal
mit seinen Verbindungsdaten auszusenden. Dadurch kann jeder Client die benötigten Daten jederzeit aus dem Netz empfangen und eine Verbindung aufbauen.
Vollautomatischer Client: Wird ein Client gestartet, wartet er auf den Empfang eines
Heartbeats und verbindet in der vollautomatischen Variante automatisch auf den ersten
Server, dessen Signal er empfängt.
Halbautomatischer Client: Während der Testphase, als mehrere Server gleichzeitig liefen, stellte sich der vollautomatische Verbindungsaufbau als problematisch heraus: Es
konnte kein Einfluss darauf genommen werden, auf welchen Server sich ein Client verbinden soll, da er sich automatisch auf den erstbesten Server verband, dessen Signal er
empfing. Daher wurde eine Halbautomatische Variante entwickelt, die dem User erlaubt,
den Server aus den empfangenen Verbindungsdaten zu manuell auszuwählen.
Seite 37 von 107
6.
Datenstruktur
Die Featurepunkte welche zu jedem Frame aus einem Videostream extrahiert werden,
gelangen in eine Datenstruktur "FeaturePoint". Diese werden dann als eine Menge von
Punkten, samt Farbinformation in der Datenstruktur "FPFrame" abgelegt.
clsFPFrameArrayColor
clsFPFrameColor
1
*
*
clsFPFrame
*
*
1
1
1
clsFPFrameArray
FeaturePointData
*
clsFeaturePoint
1
*
1
*
1
clsFPFrameArrayContainer
Seite 38 von 107
6.1. FPFrame/Color
In FPFrame sind die Punkte als Menge von Punkten abgelegt. Die Farbinformation wird
hier verwendet um die einzelnen Punkte nach Farbe zu sortieren und sie einem entsprechenden Farbtopf zu zuteilen. Diese Aufgabe übernimmt FPFrameColor welche 3 Töpfe
enthält, die Töpfe unterscheiden die Farben rot, grün und blau.
Diese Unterteilung nach Farbe ist für den Tracker notwendig. Da die Farben helfen, die
Anzahl potentieller Zuweisungskandidaten zu reduzieren.
FPFrame
FPFrameColor
R
G
B
Seite 39 von 107
6.2. FPFrameArray/Container
Die einzelnen FPFrames werden für das 3D-Tracking in ein Array von FPFrames geschrieben, zudem wird anhand des FPFrameArrays direkt die Synchronisation durchgeführt. In jedem FPFrame wird auch ein Sync-Wert übergeben welcher die Synchronisation
erst möglich macht.
Zusätzlich werden diese Arrays von FPFrames noch in einen so genannten FPFrameArrayContainer geschrieben, damit später eine evtl. Rekonstruktion des ganzen Trackings
möglich ist. FPFrameArrayContainer stellt eine Art History dar welche während des ganzen Trackings erhalten bleibt.
FPFrame
clsCamera
clsCamera
clsCamera
clsCamera
Frame 1
1
1
1
1
2
1
1
1
1
3
1
2
1
1
4
2
2
2
2
5
2
2
2
2
6
2
2
2
2
7
3
3
2
2
8
3
3
3
3
9
3
3
3
3
10
3
4
3
4
11
4
4
4
4
12
5
4
4
5
FPData
FPData
FPData
FPData
Zeit
Kameras
FPFrameArray
FPFrameArray
Container
Abb. 6-1 Darstellung eines Featurepoint Framearray Containers
Seite 40 von 107
7.
2D-Tracker
7.1. Einleitung
Nach der Extraktion der Featurepunkte aus dem Videostream existiert nun zu jedem Frame eine Menge von Punkten, samt Farbinformation. Was diesen Punkten aber fehlt, ist die
Beziehung von einem Frame zum nächsten. Es muss also die Frage gestellt werden, welcher Punkt aus Frame f zu welchem Punkt im darauf folgenden Frame gehört. (Abb. 7-1)
Zwar bietet die Farbe eine Hilfe – ein roter Punkt erscheint auch in jedem anderen Frame
als roter Punkt. Mit dieser Randbedingung wird das Problem des Findens zusammengehöriger Punkte bereits auf ein Drittel der ursprünglichen Menge reduziert(Abb. 7-2) - letztendlich führt die ungenügende Unterscheidbarkeit zwischen den Featurepunkten aber immer
wieder dazu, dass man zum Grundproblem zurückkehrt (Abb. 7-3): Gegeben seien zwei
Punktemengen von welchen die Punkte aus der ersten Menge mit maximal je einem Punkt
der zweiten Menge verbunden werden müssen.
Abbildung 7-1:
Abbildung 7-2:
Abbildung 7-3:
Welche Punkte von Frame f ent-
Farben helfen, die Anzahl potentieller
Das Grundproblem
sprechen welchen Punkten von
Zuweisungskandidaten zu reduzieren.
bleibt aber erhalten.
Frame f+1?
Seite 41 von 107
7.2. Das Featurepoint Tracking Problem
Um nun doch noch eine Korrespondenz zu erzeugen, verbleibt über ein Frame hinweg
gesehen nur noch die Ortsinformation der jeweiligen Punkte. Mit einer „Nearest Neighbour“ Methode könnten so Verbindungen geschaffen werden. Dabei besteht aber die Gefahr, dass Punkte falsch verbunden werden (Abb. 7-4 u. 7-5), wenn sich zwei nicht zusammen gehörige, gleichfarbige Punkte überkreuzen. Bei der Verteilung der Lichtpunkte
am Körper wurde berücksichtigt, dass solche Situationen nicht übermässig auftreten. Aufgrund der vielfältigen Kameraperspektiven können Überkreuzungen nicht ausgeschlossen
werden, es muss sogar davon ausgegangen werden, dass sie regelmässig auftreten.
Abbildung 7-4:
Abbildung 7-5:
Eine Überkreuzung wie sie in der Reali-
Eine falsche Verbindung, wie sie mit der „Nearest Neighbour“ Methode berechnet wird.
Es stellt sich nun die Frage, wie trotzdem eine robuste Assoziation der Featurepunkte von
Frame zu Frame ermöglicht werden kann.
Als Lösung bietet sich hier die Idee an, Punkte nicht nur allein von ihrer Ortsinformation
abhängig zu verbinden, sondern darüber hinaus physikalische Rahmenbedingungen der
Bewegung als Entscheidungskriterium einfliessen zu lassen.
1. Trägheit Æ Weiche Bewegung
Ein Featurepunkt ist letztendlich eine Aufnahme einer realen Masse und seine Bewegung unterliegt deshalb der Trägheit. Daher wird ein Featurepunkt nicht von einem Frame auf das nächste den Geschwindigkeitsvektor abrupt, sondern allmählich in einer fliessenden Bewegung verändern.
2. Limitierte Geschwindigkeit
Eine weitere Einschränkung betrifft die Geschwindigkeit, welche abhängig vom aufMuttenz, Dezember 2004
Seite 42 von 107
genommenen Sichtbereich und Aufnahmeobjekt ist. Daraus lässt sich immer eine
maximale Geschwindigkeit bestimmen.
Diese Einschränkungen bilden zusammen mit der gegebenen Problemstellung das Featurepoint Tracking Problem.
7.3. Definition Featurepoint Tracking Problem
Das Featurepoint Tracking Problem ist ein Bewegungskorrespondenzproblem unter
folgenden Annahmen:
1.
Ununterscheidbare Punkte
2.
Weiche Bewegungen
3.
Limitierte Geschwindigkeiten
4.
Kurze Überdeckungen
Hierzu existieren bereits verschiedene Algorithmen [6]. Jeder dieser Algorithmen hat spezifische Vor- und Nachteile. Daher werden nachfolgend die Anforderungen an einen solchen Algorithmus im Rahmen der Diplomarbeit bestimmt, um Auswahlkriterien für einen
Kandidaten zu definieren.
7.4. Anforderungen
Ein Tracking Algorithmus wie er für das Motiontracking Projekt benötigt wurde, muss verschiedenen Anforderungen genügen.
•
Performanz: Um Echtzeitaufnahmen an den Grenzwerten der Hardware zu ermöglichen, muss das System den Algorithmus mindestens 30 Mal pro Sekunde ausführen können.
•
Robustheit bei hoher Geschwindigkeit: Da konkret menschliche Motorik erfasst
werden soll und die Kameras maximal 30 Frames pro Sekunde aufnehmen können,
bewegen sich die Featurepunkte bei hastigen Bewegungen schnell um 30 bis 40
Pixel pro Frame. Eine hohe Geschwindigkeit für solche Algorithmen.
•
Robustheit bei Zittern: Das Grundrauschen einer Webcam, führt zu leichtem zittern der erfassten Punkte. Dieser Effekt fällt bei raschen Bewegungen nicht ins
Seite 43 von 107
Gewicht, wird aber zum Problem, wenn sehr langsame bzw. stehende Punkte
getrackt werden sollen.
•
Automatische Initialisierung: Der Algorithmus muss in der Lage sein, seine Trajektorien selbständig zu initialisieren, ohne dass Eingriffe von aussen nötig sind, da
ansonsten aufwändige Initialisierungsschritte durch den Bediener von Nöten wären.
•
Teiltrajektorien ausreichend: Es ist nicht zwingend nötig, einen bestimmten Featurepunkt konstant auch über Unterbrüche hinweg zu detektieren, da diese Information durch die Redundanz mehrerer Kameras in der 3D Berechnung einfacher und
sicherer gewonnen werden kann. Nichtsdestotrotz wäre natürlich auch hier eine gute Leistung für die Qualität des Trackings von Vorteil, sie ist aber kein muss.
Letztendlich ist es eine Frage des Zusammenspiels der teilweise gegensätzlichen Anforderungen, inwiefern ein Tracker geeignet oder nicht geeignet ist. Was nützt ein perfekt
arbeitender Algorithmus, wenn er maximal 5 Bilder pro Sekunde verarbeiten kann?
7.5. Evaluation
Eine Evaluation existierender Algorithmen, und die damit verbundene Implementation aller
interessanten Tracker, hätte den zeitlichen Rahmen der Projekt- und Diplomarbeit gesprengt. Aus diesem Grund wurde als Entscheidungshilfe die umfassenden Tests der
„Image and Pattern Analysis Group“ der ungarischen technischen Hochschule verwendet.[6]
Diese Gruppe analysierte im Rahmen ihrer Tätigkeit verschiedene Featurepunkt Tracking
Algorithmen auf Ihre Effizienz und Fehleranfälligkeit. Unter anderem auch eine Eigenentwicklung, den IP97 Algorithmus, welcher in den Bereichen Performanz und Robustheit bei
hohen Geschwindigkeiten Bestwerte erreichte. Ausserdem erfüllte er auch die Selbstinitialisierungs-Bedingung. Alleinig die Robustheit bei zitternden Punkten ist nicht gewährleistet,
weil der Algorithmus Richtungsänderungen auf maximal 90° einschränkt – also ungeeignet
für schnelle Richtungswechsel bei langsamen Geschwindigkeiten, wie sie typisch für zitternde Bewegungen sind.
Seite 44 von 107
Alle getesteten Algorithmen hatten aber entweder eine ähnliche Einschränkung oder wiesen Nachteile in anderen Anforderungsbereichen auf, die kritischer eingestuft wurden –
z.B. fehlende Selbstinitialisierung.
Aus diesen Gründen wurde entschlossen, einen Algorithmus auf Basis des IP97 Trackers
zu implementieren, der an die Anforderungen des Motiontracking Projektes angepasst
wurde.
7.6. Tracking Algorithmus
7.6.1. Beschreibung
Abgeleitet vom IP97 Algorithmus basiert der im Rahmen der Diplomarbeit erstellte Tracker
auf dem Prinzip konkurrierender Trajektorien. Betrachtet werden in jeder Iteration jeweils
die Punkte von drei aufeinander folgenden Frames. Erfüllt ein solches Tripel von Punkten
bestimmte, nachfolgend beschriebene Bedingungen, wird aus Ihnen eine so genannte
x
y
y
Frame
fx-1
fx
fx+1
Frame
fx-1
fx
fx+1
Hypothese gebildet. Eine Hypothese ist ein Kandidat für einen potentiellen Trajektorienverlauf, der in einem weiteren Schritt mit einer so genannten Kostenfunktion bewertet wird. Ist
diese Bewertung für jede Hypothese erfolgt, werden anhand ihrer Kosten die billigsten
(=besten) Hypothesen als definitive Trajektorien weiterverwendet. In einem „Postprocessing“ Schritt können noch beliebige Ergänzungen vorgenommen werden, welche das Tracking verbessern.
Seite 45 von 107
7.6.2. Initialisierung
f1
f2
f3
Abbildung 7-8:
Die drei ersten Frames eines typischen Trackingprozesses. Die gestrichelten Kreise markieren die
Suchbereiche für Punkte, die eine Hypothese mit dem Ausgangspunkt in f2 bilden dürfen.
Bei der Initialisierung beginnt der Tracker für jeden Punkt in Frame 2 eine Suche im vorhergehenden und nachfolgenden Frame. Die Grenze des Suchbereichs ist durch die festgesetzte, maximal erlaubte Geschwindigkeit vorgegeben. Das heisst je höher die erlaubte
Geschwindigkeit, desto geringer die Performanz des Trackers, weil er mehr potentielle
Hypothesen analysieren muss. Im typischen Fall findet der Tracker pro Punkt in f2 mehrere
sich konkurrierender Hypothesen.
In einem zweiten Schritt werden für alle gefundenen Hypothesen mittels einer Kostenfunktion eine Wertigkeit zwischen 0 und 1 berechnet. Je besser die Hypothese, desto kleiner
sind die resultierenden Kosten für die Hypothese.
An diesem Punkt werden bereits Hypothesen verworfen, deren Kosten einen bestimmten
Schwellwert überschreiten. Der Schwellwert liegt typischerweise im Bereich zwischen 0.6
bis 0.8. Je niedriger der Wert, desto schneller der Tracker, dafür werden möglicherweise
korrekte Korrespondenzen nicht erkannt. Umgekehrt besteht bei höheren Werten wiederum eine erhöhte Fehleranfälligkeit für falsch erkannte Verbindungen.
Im dritten Schritt wird dann anhand der Kosten eine Auswahl an nicht kollidierenden Hypothesen getroffen, aus denen die endgültigen Trajektorien gebildet werden.
Seite 46 von 107
7.6.3. Fortführendes Tracking
In jedem Frame kann ein Punkt maximal 2 Verbindungen haben, eine Vorwärts- und eine
Rückwärtsverbindung. Ein Link zeigt an, dass ein Punkt zu einem Nachbar verbunden
wurde und enthält einen Verschiebungsvektor, der zur Berechnung der Hypothesenkosten
verwendet wird.
fx-1
fx
fx+1
Abbildung 7-9:
Fortführendes Tracking (fx, x>2) – die schwarzen Linien zeigen symbolische Vorwärts- und Rückwärtsverknüpfungen. Nur die rot markierten Punkte bilden komplett neue Hypothesen. Gelbe erweitern einen bestehenden Trajektor und grüne Punkte wurden bereits im Iterationsschritt des vorhergehenden Frames verknüpft und müssen daher nicht mehr berücksichtigt werden.
Im Unterschied zum Initialisierungsschritt bestehen im fortführenden Tracking bereits solche Verbindungen.
Der Trackingschritt geht vom Prinzip her gleich vor, wie die Initialisierung. Der einzige Unterschied ist die Verwendung dieser gegebenen Verbindungen aus vorhergehenden Iterationen. Dadurch kann die Anzahl zu prüfender Hypothesen bereits im Vorfeld reduziert und
damit die Performanz des Trackers verbessert werden.
7.6.4. Postprocessing
Postprocessing beschreibt den Arbeitsschritt nach jeder Trackingiteration. In diesem
Schritt kann die Qualität des Trackings unter Betrachtung von mehr als 3 Frames noch
verbessert werden.
Seite 47 von 107
In Frage kämen Trajektorglättungen oder das Verbinden unterbrochener Trajektorien über
mehrere Frames hinweg. Beide Schritte wurden aber im Rahmen der Diplomarbeit an dieser Stelle ausgelassen. Zur Begründung:
•
Trajektorglättungen verändern Daten - da die Daten später noch einem 3D Tracking
Prozess als Grundlage dienen sollen, ist dies zu diesem Zeitpunkt noch nicht erwünscht.
•
Um Teiltrajektorien über mehrere Frames hinweg zu verbinden, ist ein grosser
Suchbereich nötig. Bei hohen Bewegungsgeschwindigkeiten vergrössert sich der
Suchbereich nach ein paar Frames sehr schnell auf das ganze Bild. Dadurch wird
der Algorithmus sehr fehleranfällig und verbraucht viel Rechenzeit bei zweifelhaftem Gewinn. Ausserdem kann der 3D Tracker diese Bindungen immer noch nachträglich und erst noch zuverlässiger herstellen, da er, im Gegensatz zum 2D Tracker, die Informationen anderer Kameras zur Verfügung hat und dank dieser Redundanz mit grösserer Sicherheit arbeiten kann.
7.6.5. Kostenfunktion
r
a
r
a
r
b
r
b
fx-1, fx, fx+1
Die Kostenfunktion stellt das eigentliche Herzstück des Trackers dar. Sie entscheidet, ob
eine Hypothese gut oder schlecht ist. Anhand der 3 an einer Hypothese beteiligten Featurepunkte wird ein Wert zwischen Null und Eins berechnet. Je besser die Bewertung der
Hypothese, desto niedriger ist der Wert der Funktion.
Die Basis der Kostenfunktion wie sie hier verwendet wurde, stammt von Sethi and Jain
und bewertet Änderungen im Betrag und der Richtung der Geschwindigkeit. Anhand von
Seite 48 von 107
Gewichtungsfaktoren bestimmen sie, welche dieser beiden Eigenschaften wie stark bewertet wird.
Richtungsänderung: Die Cosinusfunktion ist bereits eine optimale Kostenfunktion für
Richtungsänderungen, da sie für Winkel zwischen 0° und 90° Werte zwischen Null und
Eins annimmt. Mit Hilfe des Skalarproduktes lässt sie sich leicht aus den beiden Vektoren
a und b berechnen.
f (ϕ )
1
f (ϕ ) = cos(ϕ )
r r
a ⋅b
ϕ
r = cos( ϕ )
f (ϕ ) = r
| a |*|b |
180°
Das Problem ist hierbei, dass die Funktion so nur Richtungsänderungen von maximal 90°
erlaubt. Daher wurde die Funktion so angepasst, dass sie Winkel bis 180° verträgt.
f (ϕ )
1
f (ϕ ) =
r r
1 1 a ⋅b
1 1
r = + cos(ϕ )
f (ϕ ) + r
2 2 | a |*| b | 2 2
1 1
+ cos(ϕ )
2 2
ϕ
180°
Geschwindigkeitsänderung: Das Quadrat ist das optimale Viereck, um mit minimalem
Umfang eine gegebene Fläche einzuschliessen. Diese Eigenschaft wurde ausgenutzt, um
die Kostenteilfunktion für Geschwindigkeitsänderungen herzuleiten.
Aus den Beträgen der beiden Geschwindigkeitsvektoren errechnet sich der Flächeninhalt
eines Rechteckes:
r
r
F =| a | * | b |
Seite 49 von 107
Aus diesem wiederum berechnet sich die Seitenlänge des flächengleichen Quadrates:
a
=
Quadrat
F
=
r
r
| a | * | b |
Bildet man nun das Verhältnis der Umfänge, beider Figuren, erhält man eine gaussähnliche Glockenfunktion, die abhängig vom Verhältnis der Vektorlängen eine Zahl zwischen
Null und Eins bildet. Je ähnlicher die Seitenlängen, desto näher bei Eins liegt diese Zahl.
Abbildung 7-10
Die gaussähnliche Glockenkurve wurde anhand
1
von Geschwindigkeiten mit 2er Potenzen berechnet. Das heisst, ein Wert von 10 bedeutet eine
Geschwindigkeitsänderung um den Faktor 1024
zur Ausgangsgeschwindigkeit. Ein Wert von 2
0
-10
entspricht dem Faktor 4
-6
-2
2
6
10
Gewichtete Kostenfunktion: Aus den beiden Teilfunktionen berechnet sich die effektive
Kostenfunktion. Da beide Funktionen ihr Maximum bei optimalen Trajektorien erreichen,
subtrahiert man ihre Funktionswerte von 1. So erhält man eine Kostenfunktion, die bei optimalen Trajektorien ein Minimum aufweist.
Die beiden Teilwerte wiederum werden mit je einem eigenen Gewichtungskoeffizienten
(ω a , ω b ) versehen, die zusammenaddiert 1 ergeben.
Daraus erfolgt die komplette Kostenfunktion, wie sie im Tracker zum tragen kommt:
r
r
r r
⎛
⎞
⎛
2 * | a | * | b | ⎞⎟
a ⋅b
⎜
r
r ⎟⎟ + ω b 1 −
δ = ω a ⎜⎜1 − r
r
⎜
+
|
a
|
*
|
b
|
a
b
|
|
|
| ⎟⎠
⎠
⎝
⎝
Dynamisch gewichtete Kostenfunktion: Wie bereits erwähnt, funktioniert diese Kostenfunktion sehr effizient bei sich bewegenden Featurepunkten, da hier das durch Bildrauschen verursachte Flimmern nicht zum tragen kommt. Bei langsamen Geschwindigkeiten
oder gar bei stehenden Featurepunkten, dominiert das Zittern, und die Kostenfunktion versagt.
Seite 50 von 107
Aus diesem Grund werden die Gewichtungsfaktoren (ω a , ω b ) dynamisch abhängig vom
Betrag der Geschwindigkeit der Verschiebungsvektoren berechnet. Ab unterschreiten einer bestimmten Normgeschwindigkeit v nrm wird der Koeffizient für Richtungsänderungen
ω a graduell verkleinert, bis er schliesslich bei erreichen einer Minimalgeschwindigkeit auf
Null gesetzt wird, so das Richtungsänderungen komplett ignoriert werden. Auch der Geschwindigkeitsbetrag ist bei niedrigen Geschwindigkeiten sehr volatil, daher wird auch sein
Koeffizient ab unterschreiten von v nrm graduell verkleinert. Er darf aber nie Null werden, da
sonst keine Vergleichsbasis mit konkurrierenden Hypothesen mehr besteht.
Mit diesen Anpassungen ist ein robustes Tracking auch bei rauschendem Videobild problemlos möglich.
7.6.6. Typische Trackerparameter
Der 2D Tracker verfügt über verschiedene Parameter, die die Trackingleistung massgeblich beeinflussen.
•
Geschwindigkeitslimit v max : 40
Durch das Limit wird der Suchbereich des Trackers vergrössert oder verkleinert,
was die Anzahl gefundener Hypothesen, und damit die Performanz, massgeblich
beeinflusst.
•
Kostenlimit δ max : 0.7
Durch das Kostenlimit werden sehr schlechte Hypothesen bereits vor den detaillierten Tests ausgeschlossen und die Anzahl zu testender Hypothesen damit verringert.
•
Normgeschwindigkeit v nrm : 10
Ab Geschwindigkeiten > v nrm werden die Gewichtungskoeffizienten mit ihren Standardwerten verwendet, darunter werden sie graduell verkleinert bis v min erreicht
wird.
•
Minimalgeschwindigkeit v min : 2
Unterhalb dieser Geschwindigkeit wird der Gewichtungskoeffizienten für Richtungs-
Seite 51 von 107
änderungen ω a auf Null gesetzt und auch der Koeffizient für ω b Geschwindigkeitsänderungen wird auf kleinere Werte gesetzt.
•
Gewichtungskoeffizient für Richtungswechsel ω a : 0.9
Richtungswechsel sind besonders bei hohen Geschwindigkeiten aufgrund der
Trägheit sehr schwierig zu vollziehen.
•
Gewichtungskoeffizient für Geschwindigkeit ω b : 0.1
Geschwindigkeitsänderungen spielen hauptsächlich dann eine Rolle, wenn es darum geht, Hypothesen mit ähnlichen Richtungswechseln zu klassifizieren, oder aber
wenn die Gesamtgeschwindigkeit recht niedrig ist (v < v nrm ) .
Seite 52 von 107
8.
3D-Tracker
Nachdem die 2D-Daten von jedem Client beim Server angekommen sind, wird der 3DTracker aktiv. Die Aufgabe des 3D-Trackers ist es, aus mehreren getrackten 2D-Daten die
3D-Position zu berechnen.
Abb. 8-1 Aus mehreren 2D-Daten werden 3D-Daten berechnet
8.1. Synchronisation
Als erstes muss das Problem der Synchronisation gelöst werden. Das heisst, es muss sichergestellt werden, dass der 3D-Tracker bei jedem Frame zeitgleiche Daten von den
Clients erhält. Dazu werden die einzelnen Frames mit einem Zeitsignal vom Server markiert, welches jede Sekunde erhöht wird. Der Server synchronisiert sich nun auf den
Client, welcher zuerst ein höheres Zeitsignal zurückschickt und verwirft diejenigen Frames
der anderen Clients, die noch das alte Zeitsignal senden.
Seite 53 von 107
8.2. Berechnung der 3D-Position
Ein 2D-Punkt eines Kamerabildes wird in einem dreidimensionalen Raum als Gerade dargestellt.
Z
?
?
V
U
X
Y
Abb. 8-2 Projektion einer Geraden auf einen Punkt
Eine solche Gerade ist definiert mit zwei Raumpunkten. Der eine Punkt entspricht genau
der Kameraposition. Der andere Punkt wird mit Hilfe des Tsai Algorithmus berechnet. Die
Funktion "Image_coord_to_world_coord" berechnet aus den 2D-Bildkoordinaten und einem festen dritten Koordinatenwert einen weiteren Punkt im Raum.
Seite 54 von 107
8.3. Schnitt zweier windschiefen Geraden
Damit ein Punkt in einem dreidimensionalen Raum lokalisiert werden kann braucht es die
2D-Daten von mindestens 2 Kameras.
Z
V
V
U
X
Y
U
Abb. 8-3 Eindeutige Bestimmung des 3D-Punktes mit 2 Kameras
Im Idealfall schneiden sich die beiden Geraden. Aufgrund der begrenzten Auflösung der
Webcams, sowie der Berechnung des Schwerpunktes eines Featurepunktes werden sich
diese Geraden nie genau schneiden.
Seite 55 von 107
Deshalb braucht es hier eine Berechnung des kleinsten Abstandes zweier windschiefen
Geraden. Der Mittelpunkt M des kürzesten Abstandes der Geraden G1 und G2 bildet das
Zentrum des Punktes im Raum.
z
G2
d
G1
M
x
y
Abb. 8-4 Abstand zweier windschiefen Geraden
Die Anzahl der möglichen Schnittpunkte A berechnet sich so: A =
n ⋅ (n − 1)
, wobei n die
2
Anzahl Kameras ist, die den Featurepunkt sehen. Bei 5 Kameras ergeben sich also 10
Schnittpunkte. Der Mittelwert aller Schnittpunkte ist das Zentrum des Bodypunktes. Bei
Messungen ergab sich bei einem korrekten Tracking ein typischer Abstand d von 0 bis
5mm. Werte die darüber liegen, lassen auf eine falsche Assoziation schliessen. Diese Distanz kann also als Entscheidung dienen, eine falsche Verbindung zu lösen.
8.4. Töpfe und Kugeln
Pro Farbe gibt es einen 3D-Tracker. Jeder Featurepunkt hat eine eindeutige ID, die nach
der automatischen Assoziation einem Bodypunkt zugeordnet wird. Die Zuordnung erfolgt
nach dem Prinzip "Töpfe und Kugeln". Ein Bodypunkt entspricht einem Topf der gefüllt
werden muss. Jeder Bodypunkt erwartet gleich viele Featurepunkte wie die Anzahl Kameras. Die Featurepunkte entsprechen den Kugeln. Solange die Trajektor-ID dieselbe ist, wie
nach der Assoziation, ist die Zuordnung eindeutig.
Seite 56 von 107
2
1
3
Kamera 1
1
1
2
Kamera 2 4
2
2
3
1
3
Kamera 4
2
3
1
Kamera 5
Kamera 3
Fuss rechts
Knie links
Ellbogen links
Schulter rechts
Abb. 8-5 Featurepoints vor der Zuordnung
1
1
1
2
4
Fuss rechts
3
2
2
Knie links
1
2
2
3
Ellbogen links
3
3
1
Schulter rechts
Abb. 8-6 Zugeordnete Featurepoints
Seite 57 von 107
Wenn nun eine Kamera, welche alle Featurepunkte gesehen hat, nur einen Featurepunkt
verliert, und diesen später wieder findet, so ist die Zuordnung immer noch eindeutig.
Nun gibt es verschiedene Fälle, bei denen auf Anhieb keine eindeutige Zuordnung möglich
ist. Es verschwindet zum Beispiel bei einer Kamera, welche nur 3 von 4 blauen Featurepunkten sieht, ein weiterer blauer Featurepunkt. Tauchen nun einer oder beide fehlenden
blauen Featurepunkte wieder auf, so ist die Zuteilung nicht klar. Damit diese Punkte trotzdem wieder zugeordnet werden können, muss mit Hilfe der 3D-Information aus den anderen Kameras, der richtige Featurepunkt geschätzt werden.
8.5. Bone-Model (Knochenmodell)
Ein weiteres Hilfsmittel zur korrekten Zuordnung oder zum lösen von falschen Verbindungen ist die Verwendung eines Bonemodels. Das bedeutet, dass jede Verbindung zweier
Bodypunkte eine bestimmte Elastizität besitzt. Eine Verbindung von der Schulter zum Ellbogen hat eine kleinere Elastizität als eine Verbindung zwischen der Schulter und der Hüfte. Falls der 2D-Tracker zum Beispiel die Featurepunkte der rechten Hand und der rechten
Hüfte vertauscht, bemerkt dies der 3D-Tracker im ersten Moment noch nicht. Erst wenn
sich die beiden Featurepunkte wieder voneinander entfernen, werden die Verbindungen
vom rechten Ellbogen zur rechten Hand immer länger. Dann muss diese falsche Assoziation gelöst und wieder korrekt verbunden werden.
Seite 58 von 107
8.6. Epipolarlinie
Falls keine 3D-Information vorhanden ist, das heisst ein Bodypunkt wird nur noch von einer Kamera gesehen, so kann zumindest der Suchbereich mit Hilfe der Epipolarlinie auf
eine Gerade im Kamerabild beschränkt werden.
Kamera 1 sieht den Punkt P als Projektion P'
Es wird eine Ebene aufgespannt mit den Stützpunkten O1, O2 und P. Wobei O1 und O2 die
optischen Zentren der beiden Kameras sind und P der Raumpunkt ist. Diese so genannte
Epipolarebene wird mit den beiden Kamerabildern geschnitten. Die Schnittgeraden der
Epipolarebene und der Kamerabildebene heissen Epipolarlinien. Daraus folgt, dass sich
der Punkt P' auf der Epipolarlinie der Kamera 2 befinden muss. Somit muss P'' der richtige
Punkt sein und P''' der falsche.
Epipolarebene
P
Kamerabild 1
P'
Kamerabild 2
Epipolarlinien
P'''
P''
O1
O2
Abb. 8-7 Epipolarebene mit den zwei Epipolarlinien
Seite 59 von 107
9.
Transformfilter
Funktionsweise:
1. Zonen suchen (rekursiv)
2. kleine Zonen löschen
3. benachbarte Zonen mit gleicher Farbe zusammenfassen
4. Schwerpunkt berechnen
5. Parameter via Netzwerk der Clientapplikation senden
Die Funktion transform() des Transformfilters wird pro Frame einmal aufgerufen.
Das Frame wird zeilenweise von unten links nach oben rechts abgearbeitet.
Sobald ein Pixel gefunden wird, der über einem einstellbaren Schwellwert liegt, wird die rekursive Funktion „suche“
aufgerufen. Der gefundene Pixel wird in eine Liste eingetragen.
Seite 60 von 107
Im Videoframe wird der Pixel auf schwarz gesetzt. Für
jeden der 8 Nachbarpixel wird die Funktion ebenfalls aufgerufen bis die ganze Zone erfasst wurde. Es gibt 3 Bedingungen, damit ein Pixel in die Zone aufgenommen
wird.
1. Der Pixel muss über dem Schwellwert liegen.
2. Der Pixel muss auf der gleichen Zeile sein, wie die
Maske zeigt.
Damit wird verhindert, dass sich Zonen am linken und
rechten Bildrand zu einer Zone verschmelzen.
3. Der neue Pixel muss die gleiche Farbe haben wie der
vorhergehende Pixel der Zone.
Falls die Zone weniger als eine einstellbare Anzahl Pixel
beinhaltet, wird sie aus der Zonenliste gelöscht.
Ansonsten wird der Mittelpunkt und die Farbe der Zone
berechnet.
Danach geht die Suche weiter und zwar dort wo das erste
Pixel der Zone gefunden wurde.
Sobald das ganze Frame durchsucht wurde, werden
Zonen, welche die selbe Farbe haben und näher als 10
Pixel in x- oder in y-Richtung zueinander sind,
zusammengefasst. Ein neuer Mittelpunkt wird berechnet.
Als letztes werden die X-Y-Parameter und die Farbe via
Netzwerk der Clientapplikation geschickt.
Seite 61 von 107
10. Kalibrierung
Ein wichtiger Bestandteil eines Motion Tracking Systems ist die Kalibrierung der Kameras.
Diese ist erforderlich damit ein Zusammenhang zwischen dem Weltkoordinatensystem
und dem Bildkoordinatensystem hergestellt werden kann. Eine weit verbreitete Möglichkeit
der Kamerakalibrierung ist die Methode von Roger Tsai. Durch Angabe einer Menge von
Punkten (xw, yw, zw) im Weltkoordinatensystem und dem messen der zugehörigen Punkte
(xi, yi) auf dem Kamerabild kann eine Kamera kalibriert werden. Wir verwenden zur Kalibrierung einen Würfel mit einem schachbrettähnlichen Muster. Der Würfel hat auf jeder Seite 36 Quadrate, welche uns 36 Referenzpunkte liefern. Somit können pro Kamera maximal
108 Punkte detektiert werden.
Abb. 10-1 Originalkamerabild des Würfels
Abb. 10-2 Gefundene Schwerpunkte einer Würfelseite
Seite 62 von 107
Bei der Kalibrierung werden folgende Parameter ermittelt:
Die 5 inneren (intrinsischen) Parameter definieren die Abbildung zwischen den 3DWeltkoordinaten in mm und den 2D-Bildkoordinaten in Pixeln.
Dazu gehören:
-
f
Abstand zwischen der Bildebene und dem optischem
Zentrum (Brennweite)
-
kappa1
Koeffizient der radialen Linsenverzerrung
-
Cx, Cy
Koordinaten des Ursprungs der Bildebene
-
sx
Horizontaler Skalierungsfaktor
Die 6 äusseren (extrinsischen) Parameter definieren den Zusammenhang zwischen
dem Weltkoordinatensystem und dem Kamerakoordinatensystem.
Dazu gehören:
-
Rx,Ry,Rz Rotationswinkel für die Transformation zwischen den
Weltkoordinaten und den Kamerakoordinaten
-
Tx,Ty,Tz Translationsvektor für die Transformation zwischen den
Weltkoordinaten und den Kamerakoordinaten
Zusätzlich zu diesen 11 variablen Parametern gibt es 6 feste von der Kamera abhängige
intrinsische Parameter:
-
Ncx
Anzahl der Sensorelemente des CCD in horizontaler
Richtung
-
Nfx
Anzahl der Pixel in horizontaler Richtung des FrameGrabberbildes
-
dx
Horizontaler Abstand zwischen den CCD-Sensorpixeln
-
dx
Vertikaler Abstand zwischen den CCD-Sensorpixeln
-
dpx
Effektive Breite eines Pixels im FrameGrabberbild
-
dpy
Effektive Höhe eines Pixels im FrameGrabberbild
Seite 63 von 107
yw
xc
zw
Φ
vi
Ψ
zc
Θ
yc
ui
xw
Abb. 10-3 Bezeichnungen Kamera- Bild- und Weltkoordinatensystem
Damit der Algorithmus von Tsai funktioniert müssen folgende Punkte eingehalten werden:
•
Es werden mindestens 7 und maximal 500 Referenzpunkte benötigt.
•
Der Abstand zwischen dem nächsten und dem am weitesten entfernten Referenzpunkt sollte möglichst gleich gross sein wie der Abstand zwischen der Kamera und
dem nächsten Referenzpunkt.
yw
zw
x
x
xw
Abb. 10-4 Distanz Kamera-Würfel entspricht Länge des Würfels
Seite 64 von 107
•
Der Weltursprung darf nicht in der Nähe des Zentrums vom Kamerablickfeld sein.
•
Der Weltursprung darf nicht in der Nähe der Y-Achse des Kamerakoordinatensystems sein.
•
Die Referenzpunkte sollten möglichst den Teil des Bildes umfassen, in der sich
später die zu trackende Person bewegt.
•
Eine nicht coplanare Kalibrierung ist genauer als eine coplanare.
Dieses Verfahren wurde bereits in der Projektarbeit angewandt. Jedoch mussten die Koordinaten der einzelnen Referenzpunkte aus einem Screenshot sehr mühsam von Hand
ausgelesen werden. Dies dauerte bis zu einer Stunde pro Kamera.
Ein Hauptziel dieser Diplomarbeit war es, die Kalibrierung der Kameras zu automatisieren
und damit den Zeitaufwand um ein vielfaches zu reduzieren.
Damit dies möglich ist, müssen die Kalibrierungspunkte mit Hilfe der Bildverarbeitung erkannt werden. Also bauten wir einen Kalibrierungswürfel, der auf jeder Seite ein Schachbrettmuster besitzt. Der Würfel hat eine Kantenlänge von 120cm und dessen Seiten bestehen aus einem Muster mit Quadraten von 10cm Kantenlänge. Dies ergibt pro Würfelseite 36 Quadrate. Eine Detektion der Quadrateckpunkte ist aufgrund der schlechten Qualität der Webcambilder schwierig. Deshalb werden statt der Eckpunkte die Schwerpunkte
detektiert.
Wegen Beleuchtungseffekten erscheint der Abstand zwischen zwei blauen Quadraten grösser als das Quadrat
selbst, obwohl beide in Wirklichkeit gleich gross sind.
Deshalb würde eine solche Detektion der Eckpunkte zu
falschen Referenzpunkten führen.
Seite 65 von 107
Damit die Schwerpunkte berechnet werden können
muss man den Suchbereich einschränken. Da bekannt ist, wo sich die Quadrate ungefähr befinden,
wird, ausgehend von den Eckpunkten des Würfels,
ein lineares Gitter berechnet. Die Schnittpunkte dieses Gitters bilden den Startpunkt für die Suche
nach dem Schwerpunkt.
Zuerst wird das Webcambild respektive eine Würfelseite in ein Binärbild umgewandelt.
Dazu wird ein Schwellwert berechnet, damit sich die Quadrate vom weissen Hintergrund
besser abheben. Wegen den digitalen Effekten muss das Histogramm geglättet werden,
um einen zuverlässigen Schwellwert zu finden.
Histogramm einer Würfelseite
Häufigkeit
900
800
700
600
500
400
Original
Geglättet
300
200
100
0
Grauwert
Abb. 10-5 Histogramm einer Würfelseite vor und nach der Glättung
Seite 66 von 107
// Histogramm glätten
for (i=5;i<251;i++)
{
histogramm2[i] = (
Die Glättung des Histogramms
histogramm[i-5]+
histogramm[i-4]+
histogramm[i-3]+
histogramm[i-2]+
histogramm[i-1]+
histogramm[i+0]+
histogramm[i+1]+
histogramm[i+2]+
histogramm[i+3]+
histogramm[i+4]+
histogramm[i+5])/11;
}
geschieht durch eine
Mittelwertbildung von 11 benachbarten Histogrammwerten. Nach
viermaligem durchlaufen der
Schlaufe ist das Histogramm soweit
geglättet, dass die beiden lokalen
Maximas detektiert werden können. Dann wird das lokale Minimum dazwischen berechnet, welches den eigentlichen Schwellwert für die Binärisierung darstellt.
Bereich für
Histogramm
berechnen
Histogramm
bilden
Histogramm
glätten
Lokales Minimum
zwischen den
beiden Maxima
suchen
Binärbild erstellen
Abb. 10-6 Schematischer Ablauf zum Finden des Schwellwerts
Seite 67 von 107
Ausgehend von diesem Binärbild wird nun der Schwerpunkt gesucht.
Entweder ist der Startpunkt ein weisser Pixel (S1), dann
wird spiralförmig der nächstgelegene schwarze Pixel geS2
sucht. Oder der Startpunkt ist schon schwarz (S2), dann
wird der nächstgelegene Randpixel gesucht.
S1
Falls der Randpixel zu weit vom Startpunkt entfernt ist,
wird kein Schwerpunkt berechnet. Es muss davon ausgegangen werden, dass der Startpunkt an einem falschen
Ort war.
Ist der Randpixel gefunden, wird nach dem Freemancode
S1
der Rand der Figur im Gegenuhrzeigersinn abgesucht.
Solange bis man wieder beim ersten Randpixel angekommen ist, werden nun jeweils die X-Koordinaten und YKoordinaten der Randpixel aufsummiert und durch die
Anzahl Randpixel geteilt. Man erhält so den Schwerpunkt.
Seite 68 von 107
Dies ist das Resultat einer Schwerpunktberechnung einer Würfelseite.
Damit die Kamera kalibriert werden kann, müssen
mindestens zwei Seiten berechnet werden.
Diese gemessenen 2D-Bildkoordinaten werden
zusammen mit den zugehörigen 3DWeltkoordinaten dem Tsai-Programm übergeben.
Dort werden dann die extrinsischen und intrinsischen Kameraparameter berechnet.
Auszug aus der Liste mit den Kalibrierungspunkten.
Pro Zeile ein Punkt mit xw, yw, zw in mm und xi, yi in Pixeln
Mit einer erfolgreichen Kalibrierung ist es nun möglich
Umrechnungen zwischen 3D-Weltkoordinaten und 2DBildkoordinaten zu machen.
Ebenso kann die genaue Position der Kamera in Bezug
auf das Weltkoordinatensystem berechnet werden.
Die rote Umrandung des Würfels ist die berechnete Position des Würfels, also eine Transformation von 3D-Punkten ins 2-dimensionale Kamerabild.
Seite 69 von 107
Schematischer Ablauf einer Kalibrierung
Bild laden
Würfelseite
wählen
Eckpunkt
anklicken
Nein
Ja
4 Punkte?
Ja
Raster OK?
Nein
Raster löschen
Nein
Würfelseite
wählen
Ja
Neue Seite?
Nein
Kameratyp wählen
Kalibrieren
Kalibrierung
OK?
Ja
Fertig
Seite 70 von 107
11. Featurepunkt-Bodypunkt-Assoziation
Bevor man mit einem Tracking der einzelnen Bodypoints anfangen kann, müssen diese
zuerst assoziiert werden. Das heisst bei jedem Kamerabild muss definiert werden, welcher
Featurepoint zum entsprechenden Bodypoint gehört.
Bei einer manuellen Assoziation wird jeder Featurepoint mit der Maus ausgewählt und der
zugehörende Bodypoint ebenfalls. Das bedeutet bei 13 Bodypoints pro Kamera 26 Mausklicks. Bei 5 Kameras sind dies schon 130 Klicks. Ein Ziel dieser Diplomarbeit bestand
darin, diese Assoziation zu automatisieren.
Damit dies möglich ist, muss die zu trackende Person am Anfang eine Grundposition einnehmen. Zum Beispiel mit ausgestreckten Armen in Richtung negative X-Achse schauend
und auf dem Weltkoordinatenpunkt (600, 600, 0) stehend.
Danach wird ein 3D-Modell auf jedes Kamerabild projiziert und mit den aktuellen Featurepoints verglichen. Mit einem Leastsquare-Verfahren werden dann die Featurepoints den
Bodypoints zugeordnet.
2D-Modell
3D-Modell
Projektion
Kamera 1
Vergleich
2D-Modell
Kamera 2
Vergleich
2D-Modell
Kamera n
Vergleich
Abb. 11-1 Idee der automatischen Assoziation
Seite 71 von 107
Zur Überprüfung des Ergebnisses einer automatischen Assoziation werden die gefundenen Verbindungen eingezeichnet. Es kann vorkommen, dass eine Assoziation fehlschlägt,
wenn sich die Person nicht in der Grundposition befindet, oder aber falsche Featurepoints
gefunden werden. Letzteres tritt auf, wenn die Lichtverhältnisse ungünstig sind und andere
Gegenstände als die LED-Pingpongbälle als Featurepoints erkannt werden.
Abb. 11-2 Korrekt assoziiertes Modell
Seite 72 von 107
12. Hardware
12.1. Computer
Es wurden gesamthaft 6 Rechner verwendet, auf 5 Rechnern wurde der Client installiert
mit je 1 Webcam und auf einem Rechner wurde der Server installiert.
12.2. Client-Rechner:
•
2 Desktop Computer HP Vectra (2.0 GHz)
•
2 Desktop Computer HP Compaq (3.0 GHz)
•
1 Desktop Computer HP x2100 (2.0 GHz)
12.3. Server-Rechner:
•
1 Desktop Computer HP Compaq (3.0 GHz)
12.4. Installierte Software
•
Windows XP
•
Visual Studio .NET 2003
•
DirektX 9.0 SDK
Seite 73 von 107
12.5. Webcam
5 Stück des Typs Logitech Quickcam Pro 4000 wurden für das Tracking verwendet.
Sensortyp
ICX098BQ von Sony oder LZ24BP von Sharp
Grösse
1/4" VGA CCD Progressive Scan
Video Auflösung
640 (H) x 480 (V)
Effektive Pixel
659 (H) x 494 (V)
Pixel Pitch
5.6um (H) x 5.6um (V)
Sensorgrösse
4.6mm (H) x 3.97mm (V)
Bildwiederholrate
Maximal 30 Bilder pro Sekunde
Das USB-Anschlusskabel der Webcam darf mit einem maximal 4.5 Meter langen USBKabel verlängert werden.
Seite 74 von 107
12.6. Kalibrierungswürfel
Der Kalibrierungswürfel besteht aus 3mm Pavadex einseitig weiss beschichtet. Die Kanten
sind innen verstärkt mit Holzleisten 18mm x 18mm. Das Schachbrettmuster besteht aus
farbiger selbstklebender Folie. Der Würfel ist auf 4 Rollen montiert und somit einfach verschiebbar.
120
120
5
10
5
10
10
10
120
6
Masse in cm
Abb. 12-1 Massangaben des Kalibrierungswürfels
Abb. 12-2 Kalibrierungswürfel
Seite 75 von 107
12.7. LED Exoskelett
Das Exoskelett besteht aus 13 Leuchtdioden, welche in Pingpongbälle eingelassen sind.
Das ganze wird von einer Elektronik gesteuert, welche von 4 Akkus vom Typ Mignon
gespiesen wird. Da die LEDs einen relativ schmalen Abstrahlwinkel von 8° respektive 15°
haben, wird durch die diffuse Oberfläche der Pingpongbälle eine relativ gleichmässige
Ausleuchtung erreicht.
Die Pingpongbälle werden mit Klettverschluss an der Person befestigt.
LED
Pingpongball
Abb. 12-3 Aufbau LED-Pingpongball
Seite 76 von 107
12.7.1.
Schema Stromversorgung LED-Exoskelett
Seite 77 von 107
12.7.2.
Bestückungsplan Stromversorgung LED Exoskelett
12.7.3.
Stückliste Stromversorgung LED Exoskelett
Typ
Wert
D1 – D26
Diode
BAV18
Q1 – Q13
Transistor
BC546
R1 – R13
Widerstand
10kΩ
R14 – R17
Widerstand
12Ω
R18 – R26
Widerstand
15Ω
Seite 78 von 107
12.7.4.
Typ
Technische Daten LEDs
Grenzwerte
Kennwerte
URV
IVmcd
Wellen-
UFV
Abstrahl-
Leucht-
Gehäuse-
Preis
bei
länge
bei
winkel
farbe
farbe
CHF
20mA
nm
20mA
+/- φ
IFmA
Beschreibung
L5-B91G
5
30
2000
470
3.6
15°
Blau
Glasklar
4.60
L5-G81N
5
30
6000
525
3.5
15°
Grün
Glasklar
4.60
L5-R91H
5
50
8000
615
1.9
8°
Rot
Glasklar
1.70
Seite 79 von 107
13. Ausblick
Im Rahmen einer weiterführenden Arbeit könnte eine Umsetzung der 3D-Daten in einem
Robotersystem, 3D-Animationssoftware oder Spieleanwendung ein Thema sein. Damit
dies möglich ist, müssen die 3D-Daten in ein bekanntes 3D-Speicherformat umgewandelt
werden.
Diese Diplomarbeit befasst sich mit dem Verfolgen kontrastreicher Punkte. Mit einer Erweiterung des Trackers könnten auch allgemeine Formen oder Objekte verfolgt und dargestellt werden.
Die Realisierung eines Trackings mit stereoskopischer Anordnung der Kameras wäre ein
denkbarer Ansatz, um z.B. einem Roboter die Fähigkeit zu geben, sein Umfeld dreidimensional zu erfassen und sich so zu orientieren.
Entwickeln einer Featurepointextraktion, die auch unter allgemeinen Umgebungsbedingungen zuverlässig funktioniert. Denkbar wäre auch eine Erweiterung, die es ermöglichen
würde eine ganze Szenerie dreidimensional zu erfassen und darzustellen.
Alternative Methoden der Kalibrierung erarbeiten, welche z.B. ohne aufwändige, sperrige
Hardware (Würfel) realisiert werden kann.
Seite 80 von 107
14. Quellenverzeichnis
14.1. Literatur
[1]
Girola, Rolf: Mathematik, Vorlesungsskript (2003)
[2]
Hudritsch, Marcus: Computergrafik II, Vorlesungsskript (2004)
[3]
D. Pesce, Mark: Programming Microsoft® DirectShow® for Digital Video and
Television (2003)
ISBN 0-7356-1821-6
[4]
Rogerson, Dale: Inside COM (1996)
ISBN 1-57231-349-8
[5]
Sethi, I. K. and Jain, R.: Finding trajectories of feature points in a monocular image
sequence (1987)
IEEE Trans. Pattern Analysis and Machine Intelligence, 9:56-73
Seite 81 von 107
14.2. Internet
[6]
Chetverikov, Dmitry & Verestóy, Judit: Featurepoint Tracking Algorithms (1998)
http://visual.ipan.sztaki.hu/psmweb/psmweb.html
[7]
Datenblätter zum Sensor (LZ24BP und ICX098BQ)
http://www.datasheetarchive.com
[8]
DirectShow Transform Filter AppWizard:
http://www.ifp.uiuc.edu/~chenyq/research/Utils/DShowFilterWiz/DShowFilterWiz.html
[9]
Fahey, Colin C# OpenGL Wrapper:
http://www.colinfahey.com/opengl/csharp.htm
[10] Geraint Davies Consulting Ltd – DirectShow
http://www.gdcl.co.uk/dshow.htm
[11] Low, Brian DirectX Capture:
http://www.codeproject.com/cs/media/directxcapture.asp
[12] NETMaster DShowNET:
http://www.codeproject.com/cs/media/directshownet.asp
[13] Tsai Camera Calibration Software:
http://www-cgi.cs.cmu.edu/afs/cs.cmu.edu/user/rgw/www/TsaiCode.html
Seite 82 von 107
15. Anhang
15.1. Testreihen
Ein massgeblicher Indikator für die Qualität des Trackings, ist der Fehler zwischen gemessenen und wirklichen Längen. Um die Genauigkeit des Tracking Systems zu evaluieren,
wurde eine Testreihe mit einem 1m langen Holzstab durchgeführt.
Dabei war entscheidend, dass sich die Länge des Stabes von 1m in der virtuellen Realität
im Idealfall gar nicht verändert. Der Stab wurde im Raum verschiedentlich positioniert, um
anschliessend eine Messung vorzunehmen. Dabei wurden erstaunlich gute Resultate erreicht, welche einen maximalen relativen Fehler von 1.5% bis -1.6% aufzeigte.
Z [cm]
Y [cm]
240
360
120
240
Länge:
0
120
rel. Fehler: 1.0%
-120
-120
X [cm]
0
120
240
Testresultat
0
-120
X [cm]
0
120
1010mm
abs. Fehler: 10mm
240
Z [cm]
Y [cm]
240
360
120
240
Länge:
0
120
rel. Fehler: 1.5%
-120
-120
X [cm]
0
120
240
0
-120
Testresultat
X [cm]
120
1015mm
abs. Fehler: 15mm
240
Seite 83 von 107
Z [cm]
Y [cm]
240
360
120
240
Länge:
0
120
rel. Fehler: 0.9%
-120
-120
X [cm]
0
120
240
Testresultat
0
-120
X [cm]
0
120
1009mm
abs. Fehler: 9mm
240
Z [cm]
Y [cm]
240
360
120
240
Länge:
0
120
rel. Fehler: 0.7%
-120
-120
X [cm]
0
120
240
Testresultat
0
-120
X [cm]
0
120
1007mm
abs. Fehler: 7mm
240
Z [cm]
Y [cm]
240
360
120
240
Länge:
0
120
rel. Fehler: 0.7%
-120
-120
X [cm]
0
120
240
0
-120
Testresultat
X [cm]
0
120
1007mm
abs. Fehler: 7mm
240
Seite 84 von 107
Z [cm]
Y [cm]
240
360
120
240
Länge:
0
120
rel. Fehler: 0.6%
-120
-120
X [cm]
0
120
240
Testresultat
0
-120
X [cm]
0
120
1006mm
abs. Fehler: 6mm
240
Z [cm]
Y [cm]
240
360
120
240
Länge:
0
120
rel. Fehler: 0.5%
-120
-120
X [cm]
0
120
240
Testresultat
0
-120
X [cm]
0
120
1005mm
abs. Fehler: 5mm
240
Z [cm]
Y [cm]
240
360
120
240
Länge:
0
120
rel. Fehler: 0.7%
-120
-120
X [cm]
0
120
240
0
-120
Testresultat
X [cm]
0
120
1007mm
abs. Fehler: 7mm
240
Seite 85 von 107
Z [cm]
Y [cm]
240
360
120
240
Länge:
0
120
rel. Fehler: 0.4%
-120
-120
X [cm]
0
120
240
Testresultat
0
-120
X [cm]
0
120
1004mm
abs. Fehler: 4mm
240
Z [cm]
Y [cm]
240
360
120
240
Länge:
0
120
rel. Fehler: 0.6%
-120
-120
X [cm]
0
120
240
Testresultat
0
-120
X [cm]
0
120
1006mm
abs. Fehler: 6mm
240
Z [cm]
Y [cm]
240
360
120
240
Länge:
0
120
rel. Fehler: 0.6%
-120
-120
X [cm]
0
120
240
0
-120
Testresultat
X [cm]
0
120
1006mm
abs. Fehler: 6mm
240
Seite 86 von 107
Z [cm]
Y [cm]
240
360
120
240
Länge:
0
120
rel. Fehler: 0.4%
-120
-120
X [cm]
0
120
240
Testresultat
0
-120
X [cm]
0
120
1004mm
abs. Fehler: 4mm
240
Z [cm]
Y [cm]
240
360
120
240
Länge:
0
120
rel. Fehler: 1.4%
-120
-120
X [cm]
0
120
240
Testresultat
0
-120
X [cm]
0
120
1014mm
abs. Fehler: 14mm
240
Z [cm]
Y [cm]
240
360
120
240
Länge:
0
120
rel. Fehler: 1.1%
-120
-120
X [cm]
0
120
240
0
-120
Testresultat
X [cm]
0
120
1011mm
abs. Fehler: 11mm
240
Seite 87 von 107
Z [cm]
Y [cm]
240
360
120
240
Länge:
0
120
rel. Fehler: 1.2%
-120
-120
X [cm]
0
120
240
Testresultat
0
-120
X [cm]
0
120
1011mm
abs. Fehler: 12mm
240
Z [cm]
Y [cm]
240
360
120
240
Länge:
0
120
rel. Fehler: 0.0%
-120
-120
X [cm]
0
120
240
Testresultat
0
-120
X [cm]
0
120
1000mm
abs. Fehler: 0mm
240
Z [cm]
Y [cm]
240
360
120
240
Länge:
0
120
rel. Fehler: -1.6%
-120
-120
X [cm]
0
120
240
0
-120
Testresultat
X [cm]
0
120
984mm
abs. Fehler: -16mm
240
Seite 88 von 107
Z [cm]
Y [cm]
240
360
120
240
Länge:
0
120
rel. Fehler: -0.2%
-120
-120
X [cm]
0
120
240
0
-120
Testresultat
X [cm]
0
120
998mm
abs. Fehler: -2mm
240
Seite 89 von 107
15.2. Protokolle
Vorbereitung Kickoff-Meeting Diplomarbeit Motion Tracking
Datum: 20. Okt. 2004
Ort:
Diplomarbeitsplatz im 2. Stock im AI
Planungsziele für 1. Woche
- Fixierung der Zielliste
- Budgetplanung
- Schulerfordernisse evaluieren und Angehensweise planen
- Arbeitsaufteilung
- Milestoneplanung
- Planung der Dokumentationsstruktur
- Tagesplanung -> 8:30 -> 17:00
z.B. 16:00-17:00 Doku bzw. Tagebuch
Hauptziele
- Kalibrierung automatisieren
- GUI überarbeiten -> Integration aller Bauteile -> Client Server Architektur -> Remote
Control des Clients über den Server
- Übertragung von 2D Daten von Directshow auf Software über Netz
Seite 90 von 107
- Speicherformate definieren für 2D und 3D Daten
- Applikation die gespeicherte Videos lädt und verarbeitet (Anstatt Realtime Daten)
- Bodypointtracker -> 3D Tracker perfektionieren
Erweiterte Ziele
- Mehr als RGB detektieren -> CMY
- Exoskelett verbessern: Aufhängung / Farben: mehr unterschiedliche LEDs
- FP zu BP Assoziation automatisieren. Zum Beispiel durch Standardschemas abhängig
von der Kameraperspektive
- Verbesserung des Setups: Ortsunabhängigkeit/Lichtunabhängigkeit -> erhöhtes Budget
erforderlich z.B. Vorhänge/Zelt/Abgedunkelter Raum etc.
- Bewegungsglättung
- ServerClient Kameraansteuerung: Automatisierung/ Komplette Kontrolle vom Server aus
Nice to have
CD mit installier und brauchbarer Softwareversion des Motiontracking Projekts.
Dokumentation
Klare Hard- und Softwarerequirements
(z.B. Kalibrierwürfel/Kameras/Kabel/Pc’s und Software)
Seite 91 von 107
Hardwareliste
Hardware der FHBB:
- 3 x HP Workstation x2100 mit 17“ Flachbildschirm, Tastatur, Maus
- 2 x HP Vectra ohne Bildschirm
- 1 x Switch Zyxel
- 1 x Hub
- 10 x Netzwerkkabel
- 4 x Logitech Quickcam Pro 4000
- 4 x USB Verlängerung 4.5m
Sonstige Hardware:
1 Exoskelett mit 13 LED mit Klettverschlussbefestigung
4 einzelne LED
Seite 92 von 107
Protokoll:
Datum
Arbeitsplatz
Projektmitglieder
20.10.04
2.Stock AI
S. Graf, S. Hofer, M. Schindler
Anwesende
Marcus Hudritsch (Betreuender Dozent)
Sascha Hofer
Martin Schindler (Projektleiter, Protokollführer)
Stephan Graf
Abwesende
Ablauf
Es wurden die Punkte besprochen gemäss der beiliegenden Vorbereitungsliste
fürs Kickoffmeeting.
Für die Kommunikation der Serversoftware stehen zwei Varianten zur Auswahl:
COM-Objekte und Netzwerkkommunikation. Wir haben uns für das Netzwerk
entschieden.
Es wird ein Tagebuch geführt, welches jeweils vor den wöchentlichen Treffen
abgegeben wird.
Herr Hudritsch wird ein neues Bewertungsraster erstellen und dies mit Herr
Fornaro (Experte) besprechen und anschliessend uns mitteilen.
Zusätzlich zur Dokumentation wird eine Internetseite erstellt, wo die Diplomarbeit
erklärt wird. Æ sehr wichtig
Logitech Kameratreiber aus dem 40MB grossen Installationspaket extrahieren.
3 zusätzliche Webcams wurden bestellt (Komplette Hardwareliste im Anhang)
Ziele auf nächstes Treffen
- Stephan wird sich um ein neues GUI kümmern
- Sascha kümmert sich um die Netzwerkkommunikation
- Martin baut einen Kalibrierungswürfel und den Kalibrierungsalgorithmus
Nächste Sitzung
Mittwoch 27.10.2004, 13:00 Uhr, Projektplatz 2. Stock AI
Seite 93 von 107
Protokoll:
Datum
Arbeitsplatz
Projektmitglieder
28.10.04
2.Stock AI
Anwesende
Sascha Hofer
Martin Schindler (Projektleiter)
Stephan Graf (Protokollführer)
Abwesende
Ablauf
Martin hat angefangen das Kalibrierungstool TurboCalib zu entwickeln. Dabei
gab es Probleme mit der Auflösung der Webcam, da die Bilder
Komprimierungsartefakte aufweisen und dies für das bestimmen der Eckpunkte
nicht optimal ist.
Stephan hat ein erstes Konzept für die Client Applikation aufgebaut und
angefangen die Client Applikation zu entwickeln es wurden neue DirectShow
Interfaces eingebunden um Eigenschaften in der Applikation zu steuern.
Sascha hat sich mit der Serialisierbarkeit der Featurepoint Daten beschäftigt,
sowie einer Kommunikation mehrerer Kameras über das Netzwerk, dabei gab es
anfangs Probleme mit der CPU Auslastung welche inzwischen behoben werden
konnte.
- Martin wird versuchen mit einer evtl. Segmentierung oder Würfel Extraktion
(Klick auf Fläche, Template Matching, Bilinear verdoppelte Auflösung) eine voll
automatische Kalibrierung zu entwickeln, damit keine Eckpunkte mehr
ausgewählt werden müssen. Anhand von einem Raster sollen erste
Kalibrierungen mit TSAI getestet und verbessert werden.
- Stephan schaut sich VirtualDub an und schaut ob man gewisse Capturing
Features daraus in die Client Applikation übernehmen kann. Auch sollten
verschiedene Kompressionsfilter für die Applikation zur Verfügung stehen. Evtl.
Hardware Kompression testen ob mit USB 2.0 nicht mehr vorhanden.
Herausfinden warum Artefakte bei Kanten entstehen.
- Sascha wird sich weiter mit der Netzwerkkommunikation der Filter und der
Serialisierbarkeit von Daten beschäftigen, sowie anfangen den IPAN-Tracker zu
implementieren.
Nächste Sitzung
Seite 94 von 107
Protokoll:
Datum
Arbeitsplatz
Projektmitglieder
3.11.04
2.Stock AI
Anwesende
Martin Schindler (Projektleiter, Protokollführer)
Stephan Graf
Abwesende
Sascha Hofer (Zivilschutz)
Ablauf
Aufgrund des Treffens mit Herrn Krummen hat Martin eine Schwerpunktdetektion
statt einer Eckpunktdetektion (zu ungenau) implementiert. Die Anzahl Kalibpunkte
reduziert sich zwar auf 1/4, reicht aber trotzdem noch um eine genaue
Kalibrierung zu erzielen. Der „Normalized Calibration Error“ ist bei ca. 3 bis 5
(Webcam). Ein Test mit einer DV-Kamera führte zu einer unbrauchbaren
Kalibrierung. Der Grund ist noch unbekannt.
Stephan hat UserControls erstellt für die Clientapplikation und eine
Klassenstruktur Graphcontroller erstellt. Diverse Interfaces aus IDL’s nach C#
portiert. Strukturaufbau der Clientapplikation überarbeitet. UserControl Capture
erstellt und in Clientapplikation eingebaut.
- Stephan wird die Klassenstruktur des Graphcontrollers in die Clientapplikation
einbinden.
- Martin wird herausfinden wieso es Unterschiede bei der Kalibrierung zwischen
der DV-Kamera und der Webcam gibt. Applikation muss unabhängig von der
Auflösung und des Kameramodells sein. Automatischen Schwellwert pro
Würfelseite berechnen (Histogramm).
Nächste Sitzung
Seite 95 von 107
Protokoll:
Datum
Arbeitsplatz
Projektmitglieder
10.11.04
2.Stock AI
Anwesende
Stephan Graf
Sascha Hofer (Protokollführer)
Abwesende
Ablauf
Martin hat das Kalibrierungssystem fertiggestellt und demonstriert die exzellenten
Resultate, welche dank korrekten intrinsischen Kameraparametern nun möglich
sind. Mit dem System lässt sich nun auch die Kameraposition auf wenige cm
genau bestimmen.
Stephan hat die Einbindung des Graphcontrollers in den Client abgeschlossen.
Es lassen sich nun auch Einzelbilder aus dem Videostrom herausgrabben.
Sascha hat den 2D Tracker soweit in den Client eingebunden, das nun ein
Realtime 2D Tracking ablaufen kann.
- Martin wird die verschiedenen Fälle im 3D Tracking analysieren. Implementation
eines Autoassoziationsystems zur Initialisierung des 3D Trackers.
- Stephan wird den Client auch auf DV Kameras anwendbar machen.
- Sascha wird die Netzwerkkommunikation soweit verbessern, dass eine
realistischere Bandbreite benötigt wird.
- Alle: Den Client fertig implementieren und mit der Serverseite beginnen.
Nächste Sitzung
Seite 96 von 107
Protokoll:
Datum
Arbeitsplatz
Projektmitglieder
17.11.04
2.Stock AI
Anwesende
Sascha Hofer
Abwesende
Ablauf
Sascha hat die Netzwerkübertragung fertig gestellt und die Datenrate wurde
auf 20% reduziert. Er hat die Clientstruktur aufgeräumt. Ein Treffen mit Herrn
Knobel von der Firma IFE wurde auf den 24.11.04 vereinbart.
Martin hat die FP-BP Assoziation auf der Client Seite funktionstauglich
implementiert, basierend auf dem LeastSquare verfahren. Hat den Fehler bei
der Kalibrierung gefunden der wegen Binarisierung in der Histogrammanalyse
aufgetreten ist. 3D Tracker wurde angepasst und umgeschrieben (unabhängig
von den Kameras). Auch die Problemfälle FP-BP wurden analysiert und eine
Tabelle nach Worst Case erstellt.
Stephan hat die Einbindung FPDetectors in den Client abgeschlossen. Es
lassen sich mittels herausgelesener Bilder die FeaturePoints ohne SWFilter
detektieren. Nun ist eine Auswahl zwischen FPDetector und SWFilter ist
möglich.
- Martin wird die automatische FP-BP-Assoziation auf dem Server integrieren.
- Stephan wird ein DV Video aufnehmen und in VirtualDub testen wie viele
Frames aufgenommen worden sind und ob es beim abspielen eine konstante
Framerate ergibt. Im Client sollte zusätzlich noch eine ViedoSource angegeben
werden können. Mit dem Server GUI beginnen.
- Sascha wird den Netzwerkcode verbessern um eine weitere Reduktion der
Datenrate zu erreichen und wird versuchen den Tracker zu verbessern.
Nächste Sitzung
Seite 97 von 107
Protokoll:
Datum
Arbeitsplatz
Projektmitglieder
24.11.04
2.Stock AI
Anwesende
Sascha Hofer
Abwesende
Ablauf
Sascha hat die Netzwerkmodule überarbeitet. Die Serialisierung wurde verbessert
und eine Reduktion der Datenrate von 50 auf 15kB/sec. wurde erreicht.
Probleme des 2D-Trackers wurden analysiert und Lösungsansätze erarbeitet.
Martin hat die LED's umgestellt auf Netzbetrieb, die Puppe wurde eingekleidet.
FP-BP-Assozitation wurde auf dem Server implementiert.
Stephan hat auf dem Server GUI eine dynamische Client Anzeige implementiert,
welche nur die verbundenen Clients anzeigt. Der Client wurde erweitert damit
auch Video Daten getrackt werden können
- Martin wird den TUK-Controller in den Server implementieren.
- Stephan wird die Anzeigeparameter der Clients im Server implementieren. Das
3D Fenster im Server implementieren.
- Sascha wird die Lösungsansätze für den 2D-Tracker implementieren und testen,
dadurch sollte die Qualität der vom Client gelieferten Daten optimiert werden.
Nächste Sitzung
Seite 98 von 107
15.3. Wochenrapporte
Wöchentlicher Raport
Woche 1
Die ersten drei Tage waren wir beschäftigt mit Arbeitsplatz einrichten, Material
bestellen, Projektarbeit aufarbeiten.
Am Mittwoch fand das Kickoff-Meeting statt. Die Ziele wurden klar definiert, und die
Arbeit wurde aufgeteilt. Ausserdem wurde auf allen PC’s Sourcesafe und
Remotecontrol eingerichtet. Die Maschine mit der Sourcesafedatenbank wird täglich
gespiegelt. Ein Laserdrucker wurde noch installiert.
Am 21.10 haben wir ein erstes Client-Server Konzept aufgestellt. Schema hängt an
der Pinwand.
Material für Würfel bestellt (Kosten ca. 130.-)
Probleme unter .NET beim Kompilieren von Strmbase.lib.
22.10
Analyse vom MT3Force. Problem mit Absturz des Programms herausgefunden.
Erste Tests mit Clientapplikation und Filtergraphen.
Filter mit Netzwerkcode erweitert und erfolgreich mit Server verbunden.
Probleme mit CPU-Auslastung wegen Netzwerkkommunikation.
Kalibrierungstool TurboCalib. Umwandlung in Binärbild. Zeichnen und Berechnen der
Schnittpunkte des Schachbrettmusters.
25.10
Multifunktionaler Graph in .NET.
Unabhängige Reihenfolge beim Anklicken der 4 Eckpunkte.
Ursache der hohen CPU-Auslastung gefunden (Übermässig viele
Datenübertragungen über 10’000 pro Sekunde) Problem durch Bufferung behoben.
Treffen mit Andreas Krummen am 1.11.04 (Muster- und Schachbrettdetektion)
26.10
Konzept zur Verschmelzung Filtereigenschaftsfenster mit der Clientapplikation
erfolgreich getestet.
Würfel zusammengebaut.
Brainstorming zum Clientklassenkonzept.
Ideen zu Ablauf und den Datenflüssen im Trackermodul erarbeitet.
Martin Schindler
Sascha Hofer
Stefan Graph
Seite 99 von 107
Woche 2
Sascha hat sich mit Remoting und Serialisierung beschäftigt und hat einen
Belastungstest mit Featurepoints laufen lassen, der zu einer Auslastung
500KByte/sec führt. Weiterer Test mit eigener Serialisierung durchgeführt -> keine
Verbesserung in der Performanz. Man muss sich also Gedanken machen um eine
LowLevel Implementierung oder aber eine Verbesserung des Datenmodels (Nicht
jeder Featurepoint einzeln senden sondern ein ganzes Frame. Tests hierzu stehen
noch aus). Implementation Filterserver und Parser für Filterserver. Anpassung der
IPAN-Datenstruktur und IPAN-Tracker für die neuen Bedürfnisse.
Nächstes Ziel: 2D-Tracker lauffähig im Client.
Stephan hat UserControls erstellt für die Clientapplikation. Klassenstruktur
Graphcontroller erstellt. Diverse Interfaces aus IDL’s nach C# portiert. Strukturaufbau
der Clientapplikation überarbeitet. UserControl Capture erstellt und in
Clientapplikation eingebaut.
Nächstes Ziel: Klassenstruktur Graphcontroller in Clientapplikation einbinden.
Martin hat eine Berechnung des Schwerpunkts eines Vierecks implementiert.
Eine Detektion der Eckpunkte ist mit dem Webcambild zu ungenau und kommt
deshalb nicht in Frage. Darum Schwerpunktdetektion. Nachteil: 36 statt 144 Punkte
pro Seite. Erste Tests zeigen, dass 36 Punkte ausreichen.
Nächstes Ziel: Berechnung der Kameraposition mit Hilfe der TSAI-Parameter (evtl.
Matrixklasse implementieren). Zuverlässigkeit verbessern.
Martin Schindler
Sascha Hofer
Stephan Graf
Seite 100 von 107
Woche 3
Martin hat die Berechnung der Kameraposition sowie einen automatischen
Schwellwert implementiert. Tests mit einer anderen DV-Kamera zeigten, dass die
intrinsischen Parameter der beiden Kameras unterschiedlich sind und diese einen
wesentlichen Einfluss auf die Kalibrierung haben.
Die Darstellung ist jetzt unabhängig von der Auflösung des Kamerabildes.
Implementation von TurboCalib in Clientapplikation.
Nächste Ziele: Automatische FP-BP-Assoziation
Sascha hat den Tracker lauffähig implementiert. Ca. 60% Auslastung auf dem 2GHz
Rechner bei 30fps.
Nächsten Ziele: Interface fertig machen damit Tracker im Client konfigurierbar ist.
Netzwerkservermodul im Client implementieren.
Stephan hat die Klassenstruktur des Graphcontrollers in die Clientapplikation
eingebunden. Grabber so implementiert, dass es möglich ist smooth ein Video
abzuspielen bei welchem jedes Bild einzeln als Bitmap ausgelesen und angezeigt
wird mit 30fps.
Nächsten Ziele: FP-Detektor nach C# umschreiben, über die einzelnen Bitmap laufen
lassen und Performanztest machen.
Martin Schindler
Sascha Hofer
Stephan Graf
Seite 101 von 107
Woche 4
Martin:
Automatische FP-BP-Assoziation fertig implementiert.
Fehler in der Kalibrierung korrigiert.
Dokumentation zur Kalibrierung erstellt.
TUK-Algorithmus analysiert und angepasst (unabhängig von der Anzahl Kameras)
Verschiedene Problemfälle des Trackings aufgezeichnet.
Nächste Ziele: Integrieren der automatischen FP-BP-Assoziation in den Server.
Sascha
Netzwerk Clientseitig und Serverseitig fertig implementiert. Datenrate auf 20%
reduziert. Weitere Reduktion möglich.
Clientstruktur aufgeräumt.
Treffen mit Herrn Knobel von der Firma IFE vereinbart.
Basisstruktur des Servers erstellt.
Nächste Ziele: Tracker verbessern
Stephan
SW-Filter nach C# portiert und zum laufen gebracht. Auswahl möglich zwischen
SWFilter und FP-Detector.
Dokumentation angefangen über Directshow.
Nächste Ziele: Server-GUI
Martin Schindler
Sascha Hofer
Stephan Graf
Seite 102 von 107
Woche 5
Martin
Puppe eingekleidet
Netzteil für LED’s
FP-BP-Assoziation in den Server integriert.
Dokumentation erweitert.
Nächste Ziele: TUK-Controller und 3D-Fenster
Sascha
Netzwerkmodule überarbeitet.
Serialisierung verbessert und dadurch eine Reduktion der Datenrate von 50 auf
15kB/sec. Als Nebeneffekt wurde auch erfreulicherweise die Auslastung des Servers
auf wenige Prozente reduziert.
Noch bestehende Probleme des 2D-Trackers analysiert und Lösungsansätze
erarbeitet.
Nächste Ziele: Lösungsansätze implementieren und testen. Absicht: Qualität der vom
Client gelieferten Daten optimieren Æ Fehler auf ein Minimum reduzieren.
Stephan
Server Gui, Clients werden dynamisch angezeigt wenn ein neuer Client startet. Bei
jedem Client wird die aktuelle Framerate angezeigt.
Im Client wurde die Funktionalität so erweitert, dass auch mit Videodateien getrackt
werden kann.
Nächste Ziele: Anzeigeparameter der Clients im Server implementieren.
Martin Schindler
Sascha Hofer
Stephan Graf
Seite 103 von 107
Woche 6
Martin
TUK-Controller implementiert
Nächste Ziele: Doku
Sascha
Netzwerkcode und Client erweitert (Syncsignal).
Verschiedene Bugs behoben.
Nächste Ziele: Doku, Synchronisation
Stephan
Anzeigeparameter der Clients im Server implementiert.
3D-Fenster integriert.
Auflösung im Client auf 640x480 Standard.
Nächste Ziele: Doku
Martin Schindler
Sascha Hofer
Stephan Graf
Seite 104 von 107
15.4. Abbildungen
Abb. 2-1 Testraum Motion Tracking...................................................................................10
Abb. 2-2 Anordnung der LEDs...........................................................................................12
Abb. 3-1 Aufbau einer DirectShow Applikation ..................................................................15
Abb. 3-2 Kommunikation über COM Interfaces .................................................................16
Abb. 3-3 Typischer DirectShow-Filtergraph .......................................................................17
Abb. 3-4 Pin-Eigenschaftsfenster Logitechwebcam...........................................................25
Abb. 3-5 Eigenschaftsfenster der Logitech Webcam .........................................................26
Abb. 4-1 Client-Server Architektur .....................................................................................27
Abb. 4-2 Datenfluss des Clients.........................................................................................28
Abb. 4-3 Aufbau des DirectShow Filtergraph.....................................................................30
Abb. 4-4 Klassendiagramm Client .....................................................................................31
Abb. 4-5 Datenfluss der Serverapplikation.........................................................................32
Abb. 4-6 Klassendiagramm Server ....................................................................................33
Abb. 6-1 Darstellung eines Featurepoint Framearray Containers......................................40
Abb. 8-1 Aus mehreren 2D-Daten werden 3D-Daten berechnet........................................53
Abb. 8-2 Projektion einer Geraden auf einen Punkt...........................................................54
Abb. 8-3 Eindeutige Bestimmung des 3D-Punktes mit 2 Kameras ....................................55
Abb. 8-4 Abstand zweier windschiefen Geraden ...............................................................56
Abb. 8-5 Featurepoints vor der Zuordnung ........................................................................57
Abb. 8-6 Zugeordnete Featurepoints .................................................................................57
Abb. 8-7 Epipolarebene mit den zwei Epipolarlinien..........................................................59
Abb. 10-1 Originalkamerabild des Würfels.........................................................................62
Abb. 10-2 Gefundene Schwerpunkte einer Würfelseite .....................................................62
Abb. 10-3 Bezeichnungen Kamera- Bild- und Weltkoordinatensystem..............................64
Abb. 10-4 Distanz Kamera-Würfel entspricht Länge des Würfels ......................................64
Abb. 10-5 Histogramm einer Würfelseite vor und nach der Glättung.................................66
Abb. 10-6 Schematischer Ablauf zum Finden des Schwellwerts .......................................67
Abb. 11-1 Idee der automatischen Assoziation..................................................................71
Abb. 12-1 Massangaben des Kalibrierungswürfels............................................................75
Abb. 12-2 Kalibrierungswürfel............................................................................................75
Seite 105 von 107
15.5. Ehrlichkeitserklärung
Hiermit bestätigen die unterzeichnenden Autoren dieser Diplomarbeit, dass alle nicht klar
gekennzeichneten Stellen von Ihnen selbst erarbeitet und verfasst wurden.
Ort und Datum
Unterschrift
Muttenz, 23.12.2004
Stephan Graf
Sascha Hofer
Martin Schindler
Seite 106 von 107
15.6. Diplomarbeits CD-ROM
Seite 107 von 107

Diplomarbeit Motion Tracking mit Webcams

Transcrição

Documentos relacionados

vorlage für das titelblatt einer magisterarbeit bzw. diplomarbeit

überarbeitete Dokumentation

Themen für Diplomarbeiten und Dissertationen

Red Bull Art of Motion 2014

diplomarbeit - Virtual Vehicle

Derivate im Kommunalgeschäft

Visuelles Tracking von Nagerfüßen - Computer Vision

Risikobewertung von Wasserkraftanlagen

Individual movement characteristics Looking outside speech

"Der Filter des Heiligen Geistes" oder