1 Einleitung

Diese Arbeit ist Bestandteil eines Projektes an der FH Wiesbaden im Wintersemester 08/09 im Rahmen der Vertiefungsveranstaltung "3D-Rekonstruktion und Modellierung" bei Prof. Dr. Schwanecke. Ziel des Projektes ist es, eine Carrerabahn eigenständig von einem Computer mittels eines Kamerasystems steuern zu lassen.

1.1 Problemstellung

Vor dieser Arbeit ist das Projekt auf dem Stand, dass der Computer die Pixelwerte des Schwerpunktes des Carreraautos in einem Videobild bestimmen und es über zweidimensionale Prüfbereiche im Bild beschleunigen kann.
Der nächste Schritt in dem Projekt ist die Projektion des Pixel-Schwerpunktes in die Ebene in der Realwelt, in der sich auch die Carrerabahn befindet. Dies soll relativ zur Position und Ausrichtung der Kamera erfolgen, um das gesamte System dynamischer zu machen. Bisher wurde die Kamera positioniert, und danach wurden nach einigen Testfahrten rechteckige Bereiche in dem Videobild markiert, in denen das Auto unterschiedlich beschleunigt werden sollte, falls sich dessen Schwerpunkt darin befindet. Durch die Projektion des Schwerpunktes in die Realwelt relativ zur Kamera lassen sich diese Prüfbereiche einmal festlegen und abspeichern, da sie jetzt nicht mehr realtiv zum Videobild angeben werden müssen. Nach diesem Schritt soll man also die Kamera so aufstellen können, dass möglichst viel von der Carrerabahn im Bild ist. Danach bestimmt das Programm die Pose der Kamera und projiziert relativ dazu die Prüfbereiche und den Schwerpunkt auf die selbe Ebene in der Realwelt.
Diese Arbeit befasst sich mit dem daurch auftretenden Problem der Bestimmung der extrinsischen Parameter der Kameras. Die extrinsischen oder äußeren Parameter einer Kamera sind die drei Positionswerte in X-, Y- und Z-Richtung sowie die drei Rotationswinkel um die erwähnten Achsen (auch genannt Pose).
Wir benötigen sie in unserem Projekt, um einen räumlichen Bezug zwischen den Kameras und unserem lokalen Projekt-Koordinatensystem herzustellen. Somit können wir zunächst die Projektion von Pixeln in die Carrerabahnebene durchführen und später mit mehreren Kameras die räumliche Position der Objekte, die wir in den Videobildern erkannt haben, rekonstruieren.

1.2 Aufbau der Arbeit

Die Arbeit besteht aus zwei großen Blöcken. Im ersten Block werden die heutigen Ansätze beim Verfahren zur Bestimmung der extrinsichen Parameter in der Theorie erläutert.
Im zweiten Abschnitt wird die Softwarebibliothek ARToolkit Plus vorgestellt, die dieses Verfahren effizient implementiert. Hierzu werden zunächst Aufbau und Struktur erläutert und danach die einzelnen Funktionen und deren Verwendung im Detail erklärt.

2 Theorie

2.1 Grundidee

Die Grundidee ist, dass man einen Bezugsgegenstand in der Realwelt filmt, dessen Parameter exakt bekannt sind (Position, Orientierung, Ausmaße). Dadurch wird die reale Umgebung in ein lokales Koordinatensystem überführt. Umliegende Objekte, die in diesem Koordinatensystem erkannt wurden, können dadurch durch vorheriges Vermessen in Bezug zu dem bekannten Gegenstand gebracht werden.
Als Bezugsgegenstand verwendet man hierzu sogenannte ID-Marken. Sie sind meist quadratisch und enthalten ein eindeutiges, asymmetrisches Muster. Dieses Muster kann entweder ein sehr simples Bitmuster (Abb. 2.1.1) oder eine komplexere Bitmapgrafik (Abb 2.1.2) sein.


Abb 2.1.1 - Marke mit 6x6 Bitmuster.

Abb 2.1.2 - Marke mit Bitmapmuster.

Diese Marken müssen mit Methoden der Bildverarbeitung in den aufgenommenen Bildern erkannt und anhand ihres ID-Musters indentifiziert werden. Ist dies geschehen, müssen die Daten ihrer Eckpunkte und Kanten bestimmt und gespeichert werden. Danach kann man auf Grund der Verzerrung mit Hilfe linearer Algebra die extrinsischen Kameraparameter bestimmen.

2.2 Bildverarbeitungsschritte

Ausgehend von einem Grauwertbild (Abb. 2.2.1) wird dieses zunächst mittels eines Schwellwertes binarisiert (Abb. 2.2.2).
Anschließend werden mittels eines Filters (in der Praxis das Sobel-Filter) die Kantensegmente extrahiert (Abb. 2.2.3).


Abb 2.2.1 - Grauwertbild mit Marke.

Abb 2.2.2 - Binarisiertes Bild.

Abb 2.2.3 - Kantenbild nach Sobel-Filter.

2.3 Hough-Transformation

Grundlage für die Hough-Transformation ist das Kantenbild aus dem letzten Bildverarbeitungsschritt. Dadurch sind alle Pixel bekannt, die möglicherweise zu einer Kante einer Marke gehören (die weißen Bereiche im Bild).
Die Hough-Transformation nutzt die Geradendarstellung in der Hesse'schen-Normalform (Abb. 2.3.1):

d = x * cos(alpha) + y * sin(alpha)


Abb 2.3.1 - Veranschaulichung der Hesse'schen-Normalform.

Bei dieser Gleichung ist eine Gerade eindeutig durch die Parameter d (den kleinsten Abstand zum Koordinatenursprung) und den Winkel alpha (der Winkel zwischen der x-Achse und der Orthogonalen zur Geraden durch den Ursprung) definiert. Nomalerweise benutzt man diese Gleichung, um zu überprüfen, ob ein Punkt auf einer Geraden liegt. D.h. d und alpha sind bekannt, und x und y werden in die Gleichung eingesetzt.
In unserem Fall ist es genau umgekehrt. Wir kennen bereits alle Punkte der möglichen Geraden (die Pixelkoordinaten). Die Unbekannten sind hierbei d und alpha. Offensichtlich liegen aber nicht alle diese Pixel tatsächlich auf einer Kante der Marke bzw. überhaupt auf einer relevanten Kante.
Um herauszufinden, welche Pixel zu einer deutlichen Geraden gehören, überführt man sie in einen sogenannten Dualraum.
Dazu setzt man jedes Pixel(x,y) in die Geradengleichung ein und errechnet mit allen beliebig diskretisierten alpha-Werten die letzte Unbekannte d.
Als Ergebnis erhält man eine Datensammlung, in der für jede aufgetretene Kombination (alpha, d) die Häufigkeit des Auftretens gespeichert wurde. Dies lässt sich gut im Parameterraum (alpha,d) veranschaulichen (Abb 2.3.2 und Abb 2.3.3).


Abb 2.3.2 - Eingabebild mit drei Kanten.

Abb 2.3.3 - Parameterraum (alpha,d) mit drei deutlichen Maxima.

Je heller die Punkte im diesem Parameterraum sind, desto häufiger kam die Kombination aus d und alpha vor. Deutliche Maxima bedeuten, dass viele der extrahierten Pixel auf einer Geraden liegen, die durch diese Pramameter definiert ist. Somit haben wir die Geradengleichungen der relevante Geraden im Bild ermittelt.
Abschließend werden die Eckpunkte der Marken durch Schneiden der Geraden ermittelt.
Geradengleichungen und Eckpunkte werden für spätere Schritte gspeichert.

2.4 Berechnung

Für die Berechnung der extrinsischen Kameraparameter spielen drei Koordinatensysteme eine Rolle: Das Markenkoordinatensystem, das Bildschirmkoordinatensystem und das Kamerakoordinatensystem (Abb. 2.4.1).


Abb 2.4.1 - Zusammenhang der drei Koordinatensysteme.

Man kennt nun bereits die Eckkoordinaten der Marke im Markenkoordinatensystem und im Bildschirmkoordinatensystem sowie die Geradengleichungen der Kanten im Bildschirmkoordinatensystem. Außerdem kennt man die intrinsische Kameramatrix P, mit der Kamerakoordinaten in Bildschirmkoordinaten transformiert werden können.
Berechnet werden soll die Matrix Tcm, die Markenkoordinaten in Kamerakoordinaten transformiert (Abb. 2.4.2).


Abb 2.4.2 - Transformationsmatrix Tcm zum Tranfsmormieren vom Markenkoordinaten in Kamerakkordinaten.

Es ergibt sich ein Gleichungssystem mit zwölf Unbekannten. Da aber nur sechs Freiheitsgrade berechnet werden sollen, muss R3x3 eine Orthonormalmatrix sein, die die Rotation um die drei Achsen beschreibt.
Um das Gleichungssystem zu lösen müssen zunächst die Korrespondenzen zwischen den Eckpunkten bzw. den Kanten der Marke im Bildschirm- und Markenkoordinatensystem hergestellt werden.
Dazu wird die Marke im Bildschirmkoordinatensystem mit der Transformationsmatrix Tms normalisiert (entzerrt) (Abb. 2.4.3).


Abb 2.4.3 - Transformationsmatrix Tms zum Normalisieren der Marke im Bildschirmkoordinatensystem..

Es ergibt sich ein Gleichungssystem mit acht Unbekannten. Es lässt sich lösen, indem die Koordinaten der Eckpunkte aus Kamera- und Markenkoordinatensystem in die Gleichung eingesetzt werden.


Abb 2.4.4 - Verzerrte Marke.

Abb 2.4.5 - Ergebnis der Normalisierung.

Um herauszufinden, welche Ecke der Marke im Bild zu welcher Ecke der Marke im Markenkoordinatensystem gehört, bzw. um welche Marke es sich handelt, findet der Musterabgleich statt.
Hierzu werden das Originalmuster und die normalisierte Marke mit XOR verknüpft. Bei ausreichender Übereinstimmung gilt die Marke als erkannt und die Korrespondenzen werden abgespeichert. Andernfalls wird die Marke um 90° gedreht, und der Musterabgleich wird erneut durchgeführt (Abb. 2.4.6).


Abb 2.4.6 - Musterabgleich.

Aus dem letzten Schritt ist bekannt welche zwei Kanten im Bild welche zwei parallelen Kante der echten Marke abbilden.
Daraus erhalten wir zwei Gleichungspaare (Abb. 2.4.7).


Abb 2.4.7 - Gleichungspaar zweier Kanten im Bild.

Außerdem ist die intrinsische Kameramatrix P bekannt (Abb 2.4.8).


Abb 2.4.8 - Intrinsische Kameramatrix P.

Durch Ersetzten von x, y und z in g1 und g2 durch hxs, hys und h erhält man die Ebenengleichnungen e1 und e2, die die beiden Geraden im Kamerakoordinatensystem enthalten (Abb. 2.4.9).


Abb 2.4.9 - Ebenenpaar zweier abgebildeter paralleler Seiten mit eingezeichneten Normalenvektoren..

Als nächstes bildet man die beiden Normalenvektoren der Ebenen n1 und n2. Deren normiertes Kreuzprodukt u1 ist der Einheitsrichtungsvektor der beiden parallelen Kanten. Wiederholt man den Vorgang für das andere Kantenpaar, erhält man u2.
Theoretisch müssten u1 und u2 senkrecht aufeinander stehen. Praktisch müssen sie aber aufgrund von Ungenauigkeiten bei der Bildverarbeitung korrigiert werden (Abb. 2.4.10). Somit erhält man r1 und r2.


Abb 2.4.10 - Korrekturschritt von u1 und u2.

Das Kreuzprodukt von r1 und r2 ist der Vektor r3. Damit ist die Rotationskomponente R3x3 aus Tcm durch Transponieren der drei Vektoren bestimmt (Abb 2.4.11)


Abb 2.4.11 - Matrix Tcm mit markierter Rotationskomponente R3x3.

Somit verbleiben als Unbekannte in Tcm die drei Verschiebungswerte tx, ty und tz. Dieses Gleichungsystem ist durch die vier bekannten Punktkorrespondenzen überbestimmt und lässt sich mit dem least-square-Verfahren lösen.

3 Das ARToolkit Plus

Das ARToolkit Plus ist eine Open Source C++ Softwarebibliothek, die Funktionen zur Kamerakalibrierung, Markenerkennung, Markenerzeugung und der Bestimmung der extrinsischen Kameramatrix (aus Punkt 2) bereitstellt. Es lässt sich unter allen großen Entwicklungsumgebungen (Linux, Windows, Mac OS) installieren.
Entwickelt wurde das Toolkit, um Projekte, die sog. Augmented Reality nutzen, schnell und effizient zu implementieren.

3.1 Augmented Reality

Die Augmented Reality (dt. "angereicherte Wirklichkeit") ist, wie die Virtual Reality (VR), ein Teil des großen Computergrafikbereiches Mixed Reality. Hierbei werden im Gegensatz zur Virtual Reality keine kompletten virtuellen Umgebungen, die die Realwelt abbilden, erzeugt, sondern es werden virtuelle Inhalte in die Realwelt integriert und mir ihr vermischt.

Eine einfache AR-Anwendung sähe so aus, dass man mit einer Webcam eine Erkennungsmarke filmen könnte und auf dem Bildschirm darauf ein virtuelles, dreidimensionales Objekt, welches mit dem Videobild überlagert würde, sähe. Dieses Objekt würde von der Anwendung in Echtzeit perspektivisch an die Marke in der Realwelt angepasst dargestellt und live auf das Videobild gezeichnet werden (siehe Abb 3.1.1).


Abb 3.1.1 - Ein Beispiel für eine AR-Anwendung. Der Würfel wurde mit OpenGL auf das Videobild gezeichnet. Der Untergrund ist real.

Die Anwendungen sind mit unserem Projekt insofern verwandt, als dass auch sie darauf basieren, dass die extrinsischen Kameraparameter ermittelt werden können. Sie werden hierbei verwendet, um die virtuellen Objekte zu relativ zur Kamera zu transformieren. Daher können wir das ARToolkit Plus verwenden, um in unserem Projekt die Beschleunigungsbereiche im Videobild auf der Carrerabahn einzuzeichnen bzw. um den erkannten Schwerpunkt vom Bildschirmkoordinatensystem in die Markenebene zu projizieren.

3.2 Unterschiede vom ARToolkit Plus zum ARToolkit

Das ARToolkit wurde von H. Kato und M. Billinghurst entwickelt. Es ist in der Programmiersprache C geschrieben.

Das ARToolkit Plus ist ein Weiterentwicklung des ARToolkit. Es ist ein Nebenprodukt eines handheld AR-Projektes an der Technischen Universität Graz. Es ist in der Programmiersprache C++ geschrieben und daher, im Gegensatz zum ARToolkit, objektorientiert aufgebaut.
Der Hauptunterschied zwischen den beiden Toolkits ist die Handhabung der Marken. Das alte ARToolkit behandelt alle Marken als komplexes Bitmap-Muster. Dadurch wird der Musterabgleich rechenintensiv und bei ähnlichen Mustern ungenau. Die Marken müssen zum Programmstart eingelesen und ihnen eine ID zugewiesen werden.
Das ARToolkit Plus hingegen beinhaltet 4096 vorgefertigte Marken. Diese liegen als PNG-Dateien vor und lassen sich beliebig skaliert ausdrucken. Jedem dieser Muster sind intern bereits IDs zugeordnet. Sie werden als 6x6 Bitfeld eingelesen und als solches für die Identifizierung verwendet. Dadurch wird der Musterabgleich wesentlich unaufwändiger als bei dem alten Verfahren mit den Bitmap-Mustern. Es können auch große Anzahlen von Marken ohne Leistungseinbrüche erkannt werden. Zudem ist die Dicke des Markenrandes parametrierbar, was die Markenerkennung bei größeren Distanzen erleichtert. Es gibt allerdings auch nach wie vor die Möglichkeit, eigene Muster im Bitmap-Format einzulesen und zu erkennen.
Das ARToolkit Plus unterstützt BCH-Kodierung (Bose-Chaudhuri-Hocquenghem) für die Marken. Deshalb können sie mit Hilfe eines CRC-Algorithmus (cyclic redundancy check) teilweise rekonstruiert werden, sollte es zu kleinen Bildfehlern kommen.

Ein weiterer Unterschied im Bezug auf die Marken ist die Funktionalität für die Erkennung mehrerer zusammengehöriger Marken.
Das ARToolkit unterstützt zwar die Verwendung mehrerer Marken, liefert aber lediglich die ID der zuerst erkannten Marke zurück. Die restlichen Marken werden als nicht erkannt behandelt.
Mit dem ARToolkit Plus haben Entwickler die Möglichkeit, die Anzahl sowie die IDs aller erkannter Marken zu bestimmen.
Auch müssen bei der Verwendung der vorgefertigten Marken nicht die IDs zugwiesen werden, da diese bereits intern gespeichert sind.

Das ARToolkit Plus ist allgemein wesentlich stabiler als die Ursprungsversion. Dies gilt sowohl für die größere Unempfindlichkeit in Bezug auf Ungenauigkeiten bei den Markenangaben (Position, Kantenbreite etc.), als auch für die Beleuchtungsabhängigkeit. Letztere wird durch automatisches Thresholding und Kompensieren des radialen Helligkeitsabfalls einiger Kameras erreicht (Abb. 3.2.1 - 3.2.3). Das hat den Vorteil, dass auch Marken in den Ecken des Bildes noch erkannt werden können.


Abb 3.2.1 - Eingabebild mit Helligkeitsabfall.

Abb 3.2.2 - Binärbild ohne Kompensierung.

Abb 3.2.3 - Binärbild mit Kompensierung.

Abschließend sollte hierzu noch erwähnt werden, dass das ARToolkit Plus keine Funktionen zur Kameraansteuerung oder zum Einlesen von Bildern mehr beinhaltet.

Zusammenfassend lässt sich also leicht begründen, warum wir für das Projekt das ARToolkit PLus verwenden. Da der Aufbau mit der Carrerabahn und den Kameras mehrere Quadratmeter groß ist, ist es wichtig, dass mehrere Marken richtig verarbeitet werden können. Dies gilt insbesondere, weil der Aufbau so dynamisch wie möglich sein soll, was auch beinhaltet, dass die Position der Kamera und deren Sichtfeld möglichst frei wählbar sind und nicht immer alle Marken im Bild sein müssen. Somit erscheint das ARToolkit Plus nach den oben angeführten Punkten die bessere und stabilere Wahl.

3.3 Aufbau und Funktionsweise

Das ARToolkit Plus ist sehr übersichtlich aufgebaut und lässt sich in wenigen Schritten in ein Programm einbinden, wie in den nächsten Abschnitten beschrieben wird. Grundlegend ist es in zwei verschiedene Klassen unterteilt. Die "TrackerSingleMarker" und die "TrackerMultiMarker Klassen".
Es gibt drei Haupt-Headerdateien.
Die TrackerSingleMarker.h wird eingebuden, wenn nur eine Marke pro Bild erkannt werden soll.
TrackerMultiMarker.h wird bei der Verwendung mehrerer eingebunden.
Als dritte Headerdatei gibt es noch die Tracker.h. Sie sollte allerdings hauptsächlich benutzt werden, um Kompatibilität zu altem ARToolkit-Code zu sichern.
Außerdem bietet das ARToolkit Plus eine Schnittstelle zu einer Logger-Klasse. Ein solcher Logger kann dem Tracker zugewiesen werden und dient zur Verarbeitung von Fehlermeldungen und Informationen des Trackers.
Beispiel-Implementierung:

class MyLogger : public ARToolKitPlus::Logger{
void artLog(const char* nStr){
printf(nStr);
}
};

Die groben Programmierschritte sind relativ überschaubar (Abb. 3.3.1). Zunächst wird eine Instanz des gewünschten Trackers erzeugt, und er wird eingestellt.
In der Hauptroutine des Programms wird das aktuelle Bild eingelesen und an den Tracker übergeben. Dieser erkennt mittels eines Funktionsaufrufs alle Marken und berechnet die extrinsische Kameramatrix.
An diese gelangt man durch einen weiteren Funktionsaufruf und kann sie danach z. B. in OpenGL-Funktionen verarbeiten.


Abb 3.3.1 - Programmablauf einer AR-Anwendung.

3.4 Verwendung des SíngleTrackers

Verwendet man den Singletracker, kann eine Marke pro Bild erkannt werden. Ihre ID wird durch Abgleichen mit den vorhandenen Muster herausgefunden, sodass man nicht vorher angeben muss, nach welcher Marke gesucht wird. Ihr Mittelpunkt wird automatisch als Ursprung des Markenkoordinatensystems gesetzt, falls er nicht explizit angeben wird. Deswegen muss man bei dieser Variante nur noch die Randbreite der verwendeten Marken angeben, damit Sie erkannt werden können.

ARToolKitPlus::TrackerSingleMarker *tracker = new ARToolKitPlus::TrackerSingleMarkerImpl<6,6,6, 1, 8>(width,height);

Instanziiert einen MarkenTracker für ID-Marken für Marken mit einem 6x6 Bitmuster. Die Parameter width und height sind hierbei die Bildkantenlängen.

tracker->getDescription();

Liefert eine textuelle Beschreibung des zuvor erstellten Trackers in Form eines Strings.

MyLogger logger;
tracker->setLogger(&logger);

So erzeugt man einen Logger und übergibt ihn an den Tracker.

tracker->setPixelFormat(ARToolKitPlus::PIXEL_FORMAT_LUM);

Setzt das Pixelformat der erwarteten Eingabebilder auf Graustufen. Als Standartwert ist RGB888 (PIXEL_FORMAT_RGB) eingestellt.

tracker->init("calibfile.dat", 1.0f, 1000.0f);

Initialisiert den Tracker mit der Kamerakalibrierungsdatei sowie der Near- und Farplane für die Projektionsmatrix. Es handelt sich um eine boolean-Funktion, die bei Fehlschlagen des Initialisierens false als Rückgabewert liefert.

tracker->setPatternWidth(80);

Setzt die Kantenlänge der Marken. Werte werden in Millimeter angegeben.

tracker->setBorderWidth(0.125f);

Setzt die Kantenstärke relativ zur Kantenlänge. In diesem Fall ist die Kante genauso breit wie die Kästen im 6x6 Muster (ein Achtel).

tracker->setMarkerMode(ARToolKitPlus::MARKER_ID_BCH);

Gbit an ob die BCH-Kodierung verwendet werden soll oder nicht (Default: ARToolKitPlus::MARKER_ID_SIMPLE ).

//tracker->setThreshold(150);
tracker->activateAutoThreshold(True);

Threshold kann entweder konstant gesetzt oder dynamisch für jedes Bild berechnet werden.

tracker->setUndistortionMode(ARToolKitPlus::UNDIST_LUT);

Setzt das Bildverbesserungsverfahren. Mit UNDIST_NONE wird es ausgestellt, UNDIST_STD aktiviert das alte langsamere Verfahren und UNDIST_LUT aktiviert ein schnelles Look-Up-Table-Verfahren, das besonders effizient gegen Bewegungsunschärfe ist.

tracker->activateVignettingCompensation(True);

Aktiviert die Funktion zum Kompensieren des radialen Helligkeitsabfalls.

tracker->calc(pixel_array);

Dies ist die Hauptfunktion des ARToolkit Plus. Sie identifiziert die Marke und berechnet die extrinsische Kameramatrix. Ihr Rückgabewert ist die ID der zuerst erkannten Marke. Sie erwartet const unsigned char* als Datensatz der Bildpunkte.

tracker->getConfidence();

Gibt in Form einer Gleitkommazahl zwischen 0.0 und 1.0 an, mit welcher Sicherheit die Marke erkannt wurde.

tracker->getModelViewMatrix();

Liefert einen float* auf die extrinsische Kameramatrix im OpenGL-Stil (column-major).

3.5 Verwendung des MultiTrackers

Verwendet man den Multitracker, können mehrere Marken pro Bild erkannt werden, die wie eine große Marke zusammenhängen (Abb 3.5.1).


Abb 3.5.1 - Markenkoordinatensystem mit mehreren zusammenhängenden Marken.

Der Hauptunterschied bei der Verwendung des Multitrackers ist, dass eine Markenkonfigurationsdatei benötigt wird. In dieser Konfigurationsdatei stehen die Anzahl der verwendeten Marken, IDs, das globale Zentrum, zu dem sie positioniert wurden, ihre Kantenlänge, ihre Kantenstärke und eine Transformationsmatrix, die ihre Positionierung bzw. Orientierung relativ zu ihrem globalen Zentrum beschreibt (Abb 3.5.2).


Abb 3.5.2 - Format der Markenkonfigurationsdatei.

ARToolKitPlus::TrackerMultiMarker *tracker = new ARToolKitPlus::TrackerMultiMarkerImpl<6,6,6, 1, 8>(width,height);

Die Instanziierung des Multitrackers erfolgt analog zum SingleTracker.

tracker->init(“calibfile.dat”, “markerconfigfile.cfg”, 1.0f, 1000.0f);

Beim Initialisierungsschritt muss diesmal als zweiter Parameter die Markenkonfigurationsdatei angegeben werden.

tracker->calc()

Der Rückgabewert dieser Funktion ist diesmal nich die ID der zuerst erkannten Marke, sondern die Anzahl der erkannten Marken.

tracker->getDetectedMarkers();

Liefert ein Array mit den IDs der erkannten Marken zurück.

tracker->getMultiMarkerConfig();

Mit dieser Funktion kann man während des Programmablaufs auf die aus der Markenkonfigurationsdatei eingelesenen Daten zugreifen.