Masterarbeit. Studiengang Informatik. Dipl.-Inf. (FH) Michael Schäferling

Transkript

1 Masterarbeit Studiengang Informatik Dipl.-Inf. (FH) Michael Schäferling Entwurf eines FPGA-basierten Systems zur Merkmalsextraktion für optische Trackingverfahren. Erstprüfer: Prof. Dr. Gundolf Kiefer Zweitprüfer: Prof. Dr. Peter Rösch Abgabe der Arbeit: 9. Februar 2010 (WS 2009/10) Verfasser der Arbeit: Michael Schäferling Tulpenstraße Tapfheim Telefon: mike.sierra@freenet.de Fakultät für Informatik Telefon: Fax: Hochschule Augsburg University of Applied Sciences An der Fachhochschule 1 D Augsburg Telefon: Fax: poststelle@hs-augsburg.de

2 Kurzfassung Diese Arbeit beschäftigt sich mit der Extraktion von besonderen, auszeichnenden Merkmalen (Features) aus Bilddaten, welche zum Beispiel im Bereich optischer Trackingverfahren genutzt werden. Während zur Erkennung bzw. bei der Positionsbestimmung von Objekten oftmals noch Marker eingesetzt werden, versuchen moderne Verfahren die Objekte anhand bestimmter natürlicher Merkmale zu erkennen. In dieser Arbeit wird eine Plattform zur Extraktion solcher natürlicher Merkmale in Form eines System-on-Chip realisiert. Nachdem zunächst aus einer Reihe verfügbarer Algorithmen zur Feature-Extraktion SURF als ein Vertreter aktueller Algorithmen ausgewählt wird, ist dieser als Softwarelösung auf das Embedded-System zu portieren. Bei der Wahl der hierbei zu verwendenden Realisierung des SURF-Algorithmus fiel diese auf die OpenSource-Lösung OpenSURF. Weiterhin legt eine Laufzeitanalyse kritische Abschnitte im Bezug auf die Ausführungszeit des Algorithmus auf der Zielplattform offen. Basierend auf dieser Analyse wird ein besonders zeitkritischer Verarbeitungsschritt als Hardware-Modul realisiert, welches in die zuvor geschaffene Softwarelösung integriert wird. Abschließend findet eine erneute Laufzeitmessung statt, wobei nun der erreichte Speedup festgestellt und bewertet wird. Im Rahmen dieser Arbeit entstand schließlich ein System-On-Chip, welches zur Extraktion von natürlichen Merkmalen genutzt werden kann. Hierbei wird ein besonders rechenaufwändiger Verarbeitungsschritt durch ein Modul beschleunigt, welches durch konfigurierbare Hardware realisiert und selbst im Bezug auf dessen Leistungsfähigkeit und den damit verbundenen Flächenverbrauch konfigurierbar ist. Stichworte Hardware/Software-Codesign, Feature Extraktion, SURF, OpenSURF, Embedded Design, System-On-Chip. ii

3 An dieser Stelle möchte ich mich bei all denen bedanken, die mich bei der Anfertigung dieser Arbeit unterstützt haben. Besonders bedanke ich mich für die engagierte Betreuung bei Prof. Dr. Gundolf Kiefer, der mich und diese Arbeit durch vielseitige Anregungen und konstruktive Kritik bereichern konnte. Nicht zuletzt möchte ich meiner Familie danken, die mir das Studium und diese Arbeit durch ihre fortwährende Unterstützung ermöglicht und diese mit Anteilnahme verfolgt hat. iii

4 Inhaltsverzeichnis 1 Einleitung Motivation Zielsetzung und Abgrenzung Aufbau dieser Arbeit Grundlagen Merkmalsextraktion bei Bilddaten Markerbasierte Verfahren Markerlose Verfahren Verschiedene Ansätze markerloser Verfahren SURF Grundlagen Feature-Detektor Feature-Deskriptor Verfügbare Implementierungen OpenSURF Aufbau der Bibliothek Stand der Technik Softwarebasierte Merkmalsextraktion Portierung des Algorithmus auf die Zielplattform Verwendung der OpenCV-Bibliothek Realisierung des Dateizugriffs Optimierung der Software iv

5 4 Entwurf eines Spezialprozessors für die Determinantenberechnung Vorüberlegungen zur Steigerung der Performance Entwurf und Struktur des Moduls Implementierung des det build core Entwicklung der Hardware als VHDL-Modul Anbindung an den PLB durch die Toplevel-Module Die Steuerungslogik det build ctlr Logische Strukturierung durch fe line Berechnung des Filterkerns in fe ctlr Determinantenberechnung in fe core Integration des Hardware-Moduls in die Plattform Entwurf des Treibers und Integration in den Algorithmus Validierung Experimente und Ergebnisse Nutzung der Ressourcen des Virtex5-FPGA Laufzeitanalyse der Software Laufzeitanalyse des gesamten SURF-Algorithmus Laufzeitanalyse innerhalb des Feature-Detektors Laufzeitanalyse und Bewertung des Hardware-Moduls Messergebnisse aufgeschlüsselt nach Filterkernstufen Erweiterte Messungen und Optimierungen Zusammenfassung und Ausblick Zusammenfassung Darstellung möglicher Erweiterungsansätze Erweiterung und Optimierung des entworfenen Moduls Einbinden weiterer Funktionseinheiten und Module Anhang Xilinx ML507 Virtex-5 FPGA Evaluation Platform v

6 8.2 Erstellen des Projektes im XPS Einstellungen der Softwarekonfiguration Änderungen der Dateizugriffe in OpenCV für SysACE-Zugriffe 69 Abkürzungsverzeichnis 70 Abbildungsverzeichnis 72 Tabellenverzeichnis 74 Literaturverzeichnis 75 vi

7 1 Einleitung 1.1 Motivation Seit jeher ist es ein Ziel der Informatik, Maschinen wie z.b. Robotern oder im Speziellen Computern das Sehen beizubringen. Viele Gebiete, auch im Bereich der Unterhaltungselektronik, stellen einen wachsenden Anwendungsbereich des computergestützten Sehens, der so genannten Computer Vision, dar. Insbesondere Augmented Reality, die Erweiterung der natürlichen Umgebung um zusätzliche virtuelle Informationen, kann neben anderen Techniken wie zum Beispiel GPS zur groben Positionsbestimmung auch von Computer Vision profitieren und damit eine präzise Lokalisierung von Objekten erreichen [BHK09] [SWR + 09]. Der Vorgang des Sehens an sich soll dabei grob in zwei Schritte aufgeteilt werden: während der erste Schritt, nämlich die reine Erfassung von Bilddaten mittels eines Kamerasystems, mittlerweile problemlos möglich ist, bietet der zweite Schritt des Sehens - die Interpretation und inhaltliche Untersuchung der aufgenommenen Bilddaten - noch viele Möglichkeiten zur Verbesserung der bisher entwickelten technischen Lösungen. Mobile Geräte zur Erfassung und Erkennung von Bildinhalten stellen im Gegensatz zu Systemen mit stationären Standard-PCs besondere Anforderungen: sie bieten auf der einen Seite üblicherweise eine geringere Rechenleistung, was andererseits deren Energieverbrauch zugutekommt. Dabei soll das mobile System bei der Lösung der Aufgabe - in diesem Fall die Interpretation von Bilddaten - im Bezug auf Qualität und Geschwindigkeit einer stationären Lösung jedoch möglichst nahe kommen. Dass dies trotz der steigenden Leistungsfähigkeit 1

8 Kapitel 1 Einleitung mobiler Geräte noch immer eine Herausforderung darstellt belegen aktuelle Forschungsarbeiten [WSB09]. Bei vielen Anwendungen, wie beispielsweise dem Tracking von Objekten, ist es nötig Bilddaten zu interpretieren. Für diese Aufgabe werden unter anderem Algorithmen zur Merkmalsextraktion genutzt. Die damit in den Bilddaten gefundenen Merkmale werden in weiteren Schritten klassifiziert und stehen für darauf folgende Verarbeitungsstufen, wie beispielsweise das Matching, zur Verfügung. Es existieren mittlerweile viele verschiedene Lösungen, mit welchen sich solche interessanten Merkmale aus Bilddaten extrahieren lassen. Diese Algorithmen unterscheiden sich jedoch in den vorab genannten Eigenschaften, nämlich in der Geschwindigkeit, in welcher diese gefunden werden, und der Qualität der gewonnenen Merkmale. So ist zum einen ein bereits seit 1988 bekanntes und eingesetztes Verfahren die Kantendetektion nach Harris [HS88]. Zum anderen werden mit wachsender Erfahrung in diesem Forschungsbereich bis heute stetig neue, robustere Algorithmen entwickelt. Diese versuchen zwar einerseits die Qualität der extrahierten Merkmale zu verbessern, jedoch müssen sie andererseits aber auch versuchen den damit einhergehend wachsenden Rechenaufwand möglichst gering zu halten. Als Beispiel hierfür kann der im Jahre 2006 veröffentlichte SURF-Algorithmus genannt werden [BETG08], dessen Eigenschaften im Zuge dieser Arbeit noch näher erläutert werden. Besonders für rechen- und speicherintensive Probleme bieten sich für bestimmte Aufgabenstellungen oft Individuallösungen in Form von eigenständigen, von der eigentlichen CPU eines Systems losgelösten ASICs an: diese speziell für eine Anwendung zugeschnittenen integrierten Schaltkreise sind in der Lage eine spezielle Aufgabe wesentlich schneller und effizienter als eine universelle System-CPU ausführen, da sie speziell für diese eine Aufgabe entworfen wurden. Damit ist durch die sehr effiziente Lösung einer auf solche Chips ausgelagerten Problemstellung ein wesentlicher Geschwindigkeitszuwachs zu erwarten. Zudem kommt vor allem dem Embedded-Bereich für mobile Lösun- 2

9 Kapitel 1 Einleitung gen zugute, dass solche Lösungen oftmals auch einen Gewinn in Form von Einsparungen im Energieverbrauch relativ zur damit erreichbaren Performanz mit sich bringen können. Oftmals ist es bei der Entwicklung eines solchen Systems jedoch nicht möglich, ASICs fertigen zu lassen, da deren Produktion besonders in kleinen Stückzahlen sehr kostenintensiv ist. In diesem Fall bieten sich für die Realisierung einer Schaltung FPGAs an. Diese programmierbaren Logikbausteine bieten je nach Ausführung Platz für mehrere tausend Logikgatter und oftmals sogar integrierte Standard-CPUs. Damit lassen sich Hardwaremodule entwerfen, welche ASICs zwar in Energieverbrauch und Leistungsfähigkeit etwas nachstehen, jedoch aber schnell und kostengünstig realisiert werden können. 1.2 Zielsetzung und Abgrenzung Das Ziel dieser Arbeit ist der Entwurf und die Entwicklung eines Systems zur Extraktion von Merkmalen aus Bilddaten im Bereich optischer Trackingverfahren. Das hierbei eingesetzte Verfahren zur Merkmalsextraktion SURF wird in diesem Rahmen auch auf Performance-Engpässe hin untersucht. Auf dieser Untersuchung basierend soll das System durch den Einsatz konfigurierbarer Hardware beschleunigt werden. Das gesamte System wird als System-on-Chip im FPGA eines Entwicklungsboards realisiert, welches als Plattform für das Hardware/Software-Codesign dient. Im ersten Schritt wird der freie SURF-Algorithmus OpenSURF auf die Entwicklungsumgebung portiert. Anpassungen sind insbesondere in der OpenCV-Bibliothek zu erwarten, welche selbst vom OpenSURF-Algorithmus genutzt wird. Diese Portierung wird nun auf ihre Geschwindigkeit hin untersucht, wobei das Augenmerk auf rechenintensive Codeabschnitte gelegt wird. Aufbauend auf dieser Laufzeituntersuchung wird ein besonders zeitkriti- 3

10 Kapitel 1 Einleitung scher Codeabschnitt in Hardware ausgelagert. Hierzu wird ein Modul als Hardware/Software-Codesign entworfen, implementiert und in das System- On-Chip integriert. Der Softwarepart, welcher für die Steuerung des Hardwaremoduls nötig ist, wird in den OpenSURF-Algorithmus eingebunden und im letzten Schritt einer weiteren Geschwindigkeitsanalyse unterzogen. Schließlich kann damit der erreichte Speedup im Vergleich zur ursprünglichen reinen Softwarelösung festgestellt und bewertet werden. 1.3 Aufbau dieser Arbeit Zur Einführung werden zunächst in Kapitel 2 Grundlagen zur Objekterkennung in Bilddaten dargelegt. Es wird hierbei insbesondere auf Verfahren eingegangen, welche zur Lösung dieser Aufgabe natürliche Merkamale aus den Bilddaten extrahieren. Kapitel 3 beschreibt die allein auf Software basierende Ausführung der Merkmalsextraktion. Nachdem zunächst die Grundlagen zum Erstellen der nötigen Software-Plattform aufgezeigt werden, folgt hierauf die Beschreibung der Schritte um den eingesetzten Algorithmus auf der zur Verfügung stehenden Plattform ausführen zu können. Schließlich wird anhand dieser Lösung eine Laufzeitanalyse durchgeführt, welche besonders laufzeitintensive Codebereiche offenlegt. Basierend auf der Softwarelösung und den damit verbundenen Messungen aus dem vorhergehenden Kapitel werden in Kapitel 4 verschiedene Ideen zur Beschleunigung einer ausgewählten performancekritischen Funktion des Algorithmus vorgestellt. Anhand dieser Vorüberlegungen wird eine Hardwarestruktur entwickelt, welche die bestehenden Engpässe vermindert und die Performanz mit den Möglichkeiten von (programmierbarer) Hardware in diesem Bereich wesentlich steigern kann. Kapitel 5 beschäftigt sich nun mit der Umsetzung dieser Ideen in Form des Entwurfs und der Implementierung eines Hardware-Moduls. Hierbei werden 4

11 Kapitel 1 Einleitung die Aufgaben und Funktionen der verschiedenen Teilkomponenten beschrieben. Darauf folgend wird aufgezeigt wie das entwickelte Modul in das System eingebunden und validiert wurde. Im letzten Schritt wird nochmals eine Laufzeitanalyse durchgeführt, welche die erreichte Performancesteigerung darlegt. Die in dieser Arbeit durchgeführten Messungen und die daraus gewonnenen Ergebnisse werden in Kapitel 6 zusammengefasst. Dabei wird sowohl auf den Ressourcenverbrauch innerhalb des FPGAs, als auch auf die Performance- Analysen und die schließlich erreichte Performance-Steigerung eingegangen. Abschließend stellt Kapitel 7 eine Zusammenfassung der erzielten Ergebnisse dar und zeigt weitere Möglichkeiten auf, inwiefern das entwickelte System noch weiter optimiert werden könnte. 5

12 2 Grundlagen 2.1 Merkmalsextraktion bei Bilddaten Werden in der Bildverarbeitung, insbesondere im Bereich von Computer Vision und der Erweiterten Realität (engl. Augmented Reality), Bilddaten als Grundlage für Berechnungen verwendet, so muss dem zur Verfügung stehenden Bildinhalt eine Bedeutung zugewiesen werden. Hierdurch können Objekte, welche zunächst nur vom Menschen als solche zu erkennen sind, auch von technischen Systemen algorithmisch detektiert werden. Letztendlich können damit Objekte identifiziert und deren Position im Raum, bzw. auch die Position der Kamera relativ zum Objekt bestimmt werden [HZ03]. Dies ermöglicht es zum Beispiel zusätzliche Informationen bezüglich der Lage im Raum korrekt in das Bild einzufügen [HBESB09]. Die hierbei verwendeten Verfahren sollen zunächst in zwei Kategorien eingeteilt werden. Dies ist zum einen die Objekterkennung und das Tracking unter dem Einsatz von Markern. Auf der anderen Seite existieren jedoch auch marlerlose, auf natürlichen Merkmalen basierende Verfahren Markerbasierte Verfahren Diese Verfahren beruhen auf der Erkennung von Objekten mittels Markern, wobei die Szene vorab so vorzubereiten ist, dass die zu erkennenden Objekte beziehungsweise allgemein Bezugspunkte in der Szene mit wohlunterscheidbaren Markierungen versehen sind. In Abbildung 2.1 ist ein Raum dargestellt, welcher für einen Tracking-Wettbewerb im Rahmen der ISMAR 2009 mit solchen 6

13 Kapitel 2 Grundlagen Markern pra pariert wurde. Anhand dieser sollte die Geometrie des Raumes bestimmt und sich darin befindende Objekte lokalisiert werden. Abbildung 2.1: Im Rahmen eines Tracking-Wettbewerbs mit Markern pra parierter Raum Die Auswertung der Bilddaten erfolgt nun dadurch, dass in aufgenommenen Bildern nach diesen definierten Markierungen gesucht wird, was durch die Eindeutigkeit der zu identifizierenden Merkmale mit relativ geringem Aufwand rechnerisch erfolgen kann [LF05]. Ein Nachteil dieser Methode ist jedoch, dass die Erkennung der Marker fehlschla gt wenn diese (oft auch nur teilweise) in der Szene durch andere Objekte verdeckt werden. Dies kann unter anderem die Mo glichkeiten der Positionierung einer Kamera im Raum einschra nken. 7

14 Kapitel 2 Grundlagen Markerlose Verfahren Das zweite Verfahren, die markerlose Erkennung von Objekten, beruht auf der Detektion natürlicher Merkmale in den Bilddaten, die auch Features genannt werden. Natürliche Merkmale sind zum Beispiel Ecken und Kanten von Objekten. Kanten als Merkmal eines Objekts sind im Allgemeinen jedoch nicht optimal geeignet, da diese nicht einen bestimmten Punkt, sondern eine Punktmenge in Form einer Linie beschreiben. Besser geeignet sind Ecken, da deren Position jeweils durch einen Punkt genau definiert ist. Die über natürliche Merkmale enthaltene Information kann jedoch von Bild zu Bild stark variieren. So ändern sich beispielsweise jeweils die Lage und der Winkel einer zu erkennenden Ecke bei Aufnahmen aus verschiedenen Perspektiven. Da die genaue Beschaffenheit solcher natürlicher Merkmale also im Voraus meist nicht bekannt ist, erfordert deren Extraktion einen höheren rechnerischen Aufwand als es bei markerbasierten Trackingverfahren der Fall ist. Dieser Aufwand und die Güte der extrahierten Feature-Merkmale hängen jedoch stark von der eingesetzten Methode ab. Über solche Verfahren zur markerlosen Objekterkennung mittels Feature-Extraktion wird nun im Folgenden ein kurzer Überblick gegeben Verschiedene Ansätze markerloser Verfahren In diesem Kapitel werden nun zwei weitgehend etablierte und ein relativ aktuelles Verfahren zur Feature-Extraktion vorgestellt. Erstere sind zum einen der Eckpunkte-Detektor nach Harris und Stephens und zum anderen SIFT, welches nach der Detektionsphase zu jedem entdeckten Feature auch einen Deskriptor liefert. Als aktuelles Verfahren wird SURF vorgestellt, welches zwar viele Ähnlichkeiten mit SIFT aufweist, sich aber in wesentlichen Details von diesem unterscheidet. 8

15 Kapitel 2 Grundlagen Eckpunkte-Detektor nach Harris und Stephens Ein weit verbreiteter und vielfach bewährter Algorithmus zur Merkmalsextraktion, in diesem Fall durch Detektion von markanten Ecken und Punkten, ist der Harris Eckpunkte-Detektor. Dieser basiert auf dem Moravec-Detektor, dessen Funktionsweise sich folgendermaßen beschreiben lässt [HS88]: Ein Ausschnitt des Bildes wird untersucht, indem das Fenster w der Größe (u,v), das diesen Ausschnitt definiert, in den Richtungen x und y verschoben wird. Hierbei wird jeweils die Intensität I ausgewertet, die aus der Summe der im betrachteten Bildausschnitt w u,v liegenden Pixel gebildet wird. Mathematisch wird hier die gewichtete Summe der quadrierten Differenzen E über einen betrachteten Bildausschnitt w u,v verwendet, wobei die Verschiebung durch die Richtungsvektoren x und y ausgedrückt wird: E u,v (x,y) = u w u,v (I u+x,v+y I u,v ) 2 v Hierbei wird also der Unterschied der Intensität I des ursprünglichen Bildausschnitts im Vergleich zu der des verschobenen Fensters durch den Betrag von E ausgedrückt, wobei folgende Fälle eintreten können: Kleines E bei beliebigen (x, y): es wurde kein signifikanter Punkt gefunden, da sich die Intensität des betrachteten Fensters bei der Verschiebung in beliebige Richtungen nicht änderte. Großes E beim Verschieben in eine Richtung: es wurde eine Kante gefunden, denn entlang dieser Kante ist der Betrag von E relativ klein, ansonsten groß. Großes E bei beliebigen (x, y): es wurde eine Ecke, beziehungsweise ein Punkt gefunden. 9

16 Kapitel 2 Grundlagen Harris und Stephens erweiterten diese Methode nach Moravec so, dass einige von dessen Schwächen eliminiert wurden, nämlich die Eigenschaft, dass das Fenster lediglich im Bereich um 45 Grad verschoben werden kann, und die fehlende Rotationsinvarianz. Nach Umformung der oben aufgezeigten Formel lässt diese sich auch durch folgende äquivalente Gleichung darstellen: ( ) x E u,v (x,y) = (x y) M y mit M = u [ w u,v v I 2 x I x I y I x I y I 2 y ], wobei I x und I y hierbei die partiellen Ableitungen von I sind. Die Matrix M wird aufgrund ihrer Struktur auch als Hesse-Matrix bezeichnet. Wie bereits bei Moravec zeigt eine große Veränderung von E an, dass an der betrachteten Stelle eine interessante Struktur vorliegt. Durch die Untersuchung der Eigenwerte λ 1 und λ 2 von M lassen sich Aussagen über die detektierte Struktur treffen: sind beide Eigenwerte klein, so liegt eine relativ homogene Fläche vor. Wenn nur einer der beiden Eigenwerte groß ist, so liegt eine Kante vor. Sind beide Eigenwerte betragsmäßig groß, so weist dies auf eine detektierte Ecke hin. Da die Berechnung der Eigenwerte λ 1 und λ 2 jedoch einen hohen Rechenaufwand bedeutet, schlugen Harris und Stephens folgende Gleichung für die Bestimmung einer Ecke vor: R = λ 1 λ 2 κ (λ 1 + λ 2 ) 2 = det(m) κ spur 2 (M) = (I 2 x I 2 y (I x I y ) 2 ) κ (I 2 x + I 2 y ) 2 10

17 Kapitel 2 Grundlagen In den oben aufgezeigten Gleichungen stellt det(m) die Determinante der Matrix M und spur(m) die Spur der Matrix M dar, wobei letztere durch die Summe der Diagonalelemente von M berechnet wird. Mit dieser Methode ist es nun alleine durch die Bestimmung der partiellen Ableitungen am Punkt (x, y) möglich Ecken zu detektieren. Der Parameter κ muss jedoch je nach Anwendung empirisch ermittelt werden. Das berechnete R weist im Fall einer detektierten Ecke einen positiven Wert auf, ein negativer Wert deutet auf eine Kante hin und ein kleines R zeugt von einer homogenen Fläche. SIFT - Scale-invariant Feature Transform Dieses Verfahren wurde 1999 von David Lowe veröffentlicht [Low99]. Während der Harris Eckpunkte-Detektor alleine zum Extrahieren von Ecken geeignet ist, basiert SIFT auf der Erkennung von interessanten Punkten, welche jedoch nicht zwingend Ecken oder einzelne Bildpunkte darstellen müssen. Vielmehr stellen die detektierten Features markante Regionen im Bildbereich dar, welche in der Ausdehnung mehrere Bildpunkte umfassen. Zusätzlich zu ihren Koordinaten werden die Features in SIFT also auch durch ihre Umgebung im Bildbereich beschrieben, welche auch als BLOB (engl. Binary Large Object) bezeichnet wird. Der SIFT-Deskriptor ist invariant gegenüber Rotation und Skalierung des Bildes. SIFT besteht aus zwei Komponenten, wobei die erste Features erkennt (Feature Detektor) und die zweite diese Features in einer Datenstruktur (Feature Deskriptor) beschreibt, durch die beim Matching korrespondierende Features einander zugeordnet werden können [Low04]. Die Detektierung von Features erfolgt bei SIFT durch die Anwendung des Difference of Gaussians -Algorithmus (DoG). Hierbei erfolgt eine mehrfache Faltung des Bildes mit jeweils verschieden gewichteten Gauss-Filtern bei mehreren Auflösungsstufen. Durch DoG werden inhomogene Strukturen hervorgehoben, was den ersten Schritt in SIFT darstellt, nämlich die Erkennung von Extremwerten im Bildbereich über verschiedene Auflösungsstufen hinweg. 11

18 Kapitel 2 Grundlagen Hierbei findet auch eine Bereinigung der gefunden Features (bei SIFT auch Keypoints genannt) statt, indem Punkte, die in ihrer Umgebung kein Maximum darstellen, unterdrückt werden. Im zweiten Schritt werden die Features im Bezug auf Position und Skalierung durch Interpolation mit den Nachbarpunkten präzise lokalisiert. Ein Problem bei SIFT stellt die Tatsache dar, dass DoG sehr stark bei Kanten anspricht. Features, die Teil einer Kante sind, müssen also ebenfalls unterdrückt werden, was durch eine Betrachtung der Hesse-Matrix wie bei Harris gelöst wird [Low04]. Jedem Feature wird im dritten Schritt eine Orientierung zugewiesen. Anhand dieser kann der Deskriptor so berechnet werden, dass er invariant gegenüber einer Rotation des Bildes ist. Somit liegen nun Ort, Skalierung und Orientierung aller Features für den letzten Schritt vor, das Erstellen der Deskriptoren. Für jedes Feature werden unter der Berücksichtigung von dessen Orientierung jeweils der Betrag und die Richtung der Gradienten benachbarter Bildpunkte berechnet und gewichtet. Die umgebenden Nachbarpunkte werden in Subregionen mit je 4x4 Pixeln zusammengefasst, wobei zunächst die Gradienten für jeden einzelnen Pixel berechnet und deren Beträge in den Subregionen zu 45 -Vektoren diskretisiert und aufsummiert werden. Wenn nun also beispielsweise der Deskriptor für ein Feature anhand des Bereichs von 16x16 umgebenden Pixeln berechnet werden soll, so werden für diese zunächst jeweils die Gradienten gebildet und in 16 4x4-Subregionen aufgeteilt. Die Gradienten jeder Subregion werden nun in 45 -Vektoren diskretisiert und aufsummiert, wodurch je Subregion 8 Vektoren entstehen. Diese ergeben zusammen einen Deskriptor mit einer Größe von 128 Elementen, da nun aus 16 Subregionen je 8 Vektoren vorliegen. Es ist zwar auch möglich einen Bereich von 8x8 umgebenden Bildpunkten für die Deskriptorberechnungen zu verwenden, woraus eine Deskriptorgröße von 64 Elementen resultieren würde. Jedoch zeigen Untersuchungen, dass mit einem größeren Deskriptor bessere Ergebnisse erreicht werden [BSP07], wodurch in vielen Fällen der 128-wertige Deskriptor Verwendung findet. 12

19 Kapitel 2 Grundlagen 2.2 SURF Bei der Auswahl des Algorithmus, welcher im Rahmen dieser Arbeit untersucht und durch ein Hardware-Modul beschleunigt werden soll, fiel die Wahl auf den aktuellen SURF-Algorithmus. Das Akronym SURF steht hierbei für Speeded Up Robust Features, was im Deutschen etwa beschleunigte, robuste Merkmale bedeutet. Ein Grund für diese Entscheidung liegt vor allem darin begründet, dass bei der Entwicklung dieses Algorithmus - wie das Akronym SURF bereits nahe legt - der Fokus insbesondere darauf lag, robustere Features bei geringerem Rechenaufwand im Vergleich zu bisher existierenden Verfahren liefern zu können. Während SIFT gegenüber den bis dahin verfügbaren Algorithmen zur Merkmalsextraktion als Vorreiter galt, versucht SURF durch verschiedene Eigenschaften, welche in diesem Kapitel erläutert werden, eine herausragende Position einzunehmen. So konnten Johannes Bauer et al. in [BSP07] aufzeigen, dass SIFT in einigen Fällen zwar durch dessen Deskriptor das bessere Verhältnis und die höhere Gesamtzahl korrekter Matches aufweist, jedoch in diesen Punkten dicht von SURF gefolgt wird. Ein wesentlicher Vorteil von SURF gegenüber SIFT ist jedoch darin zu sehen, dass dessen Performanz und Effizienz von den in diesem Algorithmus eingesetzten Verfahren profitieren. Dies lässt erwarten, dass mit SURF pro Zeiteinheit mehr Features gefunden und aufgrund des kleineren SURF-Deskriptors eine größere Anzahl an Features gematcht werden kann. Ähnlich wie SIFT beschränkt sich auch SURF nicht auf die Detektion von Ecken, sondern beruht ebenfalls auf der Detektion und Beschreibung signifikanter BLOBs. Jedoch ist SURF ein recht aktuelles Verfahren, es wurde 2006 von Herbert Bay et al. veröffentlicht [BETG08]. Die Schritte zur Detektion von Features entsprechen grob denen des SIFT- Algorithmus, weiterhin ist auch SURF invariant gegenüber Rotation und 13

20 Kapitel 2 Grundlagen Skalierung. Es wurde jedoch wie bereits erwähnt bei dessen Entwicklung das Ziel verfolgt, eine robustere Detektionsrate, bessere Wiederholbarkeit und Unterscheidbarkeit der Features bei geringerem Rechenaufwand durch den Einsatz anderer mathematischer Verfahren in den einzelnen Teilschritten zu erreichen. Die einzelnen Schritte und deren Realisierung in SURF werden nun in diesem Kapitel erläutert. Dabei wird besonders auf die Details eingegangen, welche für das Verständnis des in Kapitel 4 vorgestellten Hardware-Moduls von wesentlicher Bedeutung sind Grundlagen SURF besteht zum einen aus einem Feature-Detektor, welcher herausragende BLOB-artige Strukturen erkennt. Zum anderen beschreibt der SURF-Deskriptor die detektierten Features und ermöglicht in weiteren Verarbeitungsschritten ein effizientes Matching. Im Folgenden werden diese Punkte dort detailliert beschrieben, wo es für das Verständnis des Kapitel 4.1 von Nöten ist. Zunächst werden jedoch zwei Techniken beschrieben, durch welche die hohe Effizienz des SURF-Algorithmus ermöglicht wird. Integralbilder In SURF werden im Zuge der Feature-Detektion und bei der Erstellung der Deskriptoren Filterkerne angewendet. Im Zuge der Faltungen der Filterkerne mit den Bilddaten werden so genannte Integralbilder genutzt. Diese haben die Eigenschaft, dass bei Flächenberechnungen der Aufwand der Summenbildung über die Bildpunkte einer Fläche stark reduziert wird. Unabhängig von der Größe der zu summierenden Fläche ist es hier mit gleichbleibend geringem Aufwand möglich das Ergebnis zu bestimmen, während bei einer gewöhnlichen Summation der 14

21 Kapitel 2 Grundlagen Aufwand mit wachsender Fläche steigt. Davon profitieren insbesondere die Faltungen, welche mit den in SURF eingesetzten Filterkernen durchgeführt werden. Auch diese Filterkerne werden im Verlauf dieses Kapitels vorgestellt. Erreicht wird dies durch folgendes Prinzip: Die Bildpunkte des Integralbildes sind so beschaffen, dass sie betragsmäßig die Summe der Bildpunkte des Rechtecks aufweisen, das vom entsprechenden Bildpunkt und dem Ursprung des Bildes aufgespannt wird. Jeder Bildpunkt X = (x, y) im Integralbild entspricht also dem Integral der Fläche zwischen ihm und dem Bildursprung: I (X) = i x i=0 j y I(i, j) j=0 Liegt nun ein Bild vor, so wird zunächst das entsprechende Integralbild berechnet. Anschließend kann mit gleichbleibendem Aufwand die Flächensumme einer beliebig großen Fläche bestimmt werden, wie es beispielhaft in Abbildung 2.2 dargestellt ist. Durch die Hesse-Matrix involvierte Filterkerne In SURF finden zwei wohlbekannte Filterkerne Anwendung. Bei der Detektion von Features wird eine Abwandlung des Gauss-Filters angewendet, welcher in der Bildverarbeitung für die Glättung bzw. das Weichzeichnen von Bilddaten eingesetzt wird. Für die Bestimmung der Deskriptoren bzw. der Orientierung detektierter Features findet das Haar-Wavelet Anwendung. Beide Filter profitieren in SURF von der Nutzung der Integralbilder, welche im vorhergehenden Abschnitt beschrieben werden. Da für die vorliegende Arbeit jedoch primär der Gauss-Filter von Interesse ist, soll dieser hier näher erläutert werden. Features werden bei SURF durch die Anwendung der Hesse-Matrix in Verbindung mit einem Gauss-Filterkern (beziehungsweise dessen partiellen zweiten 15

22 Kapitel 2 Grundlagen Abbildung 2.2: Summenberechnung über die Intensitäten eines Bildausschnitts mittels eines Integralbildes (vgl. [BETG08]) Ableitungen in x-, y- und xy-richtung) detektiert. Um einen Bildpunkt als Feature identifizieren zu können wird zunächst die Determinante der Hesse- Matrix H für den Ort X = (x,y) und eine Skalierung σ berechnet. Mit x und y werden die Koordinaten im Bildraum bezeichnet, die Skalierung σ beschreibt die Ausmaße des anzuwendenden Filterkerns. Durch eine darauf folgende Extremwertbetrachtung werden mögliche Kandidaten selektiert, beziehungsweise nicht geeignete Punkte unterdrückt. Die Hesse-Matrix H ist für die oben genannten Parameter definiert durch [ ] L xx (X,σ) L xy (X,σ) H(X,σ) = L xy (X,σ) L yy (X,σ) 16

23 Kapitel 2 Grundlagen mit den folgenden Gauss schen Ableitungen zweiter Ordnung: L xx (X,σ) = 2 x 2 g(σ) L yy (X,σ) = 2 y 2 g(σ) L xy (X,σ) = 2 xy g(σ) Würde das Bild mit den ursprünglichen partiellen zweiten Ableitungen des Gauss-Filters gefaltet, so wäre der rechnerische Aufwand abhängig von der Größe des Filterkerns. Durch die Struktur des originären Gauss-Filterkerns müssten alle von ihm abgedeckten Pixel in die Berechnung mit einfließen, da die involvierten Bildpunkte entsprechend der Gauss schen Glockenkurve individuell gewichtet werden. Bei einer Größe von 9x9 Pixeln sind hierbei also 81 Operationen (Speicherzugriffe und Gewichtungen der einbezogenen Bildpunkte) nötig, bei einer Filterkerngröße von 27x27 Pixeln wären es bereits 729 Operationen. Um diesen Aufwand zu minimieren werden in SURF Annäherungen der Gauss-Filterkerne verwendet. Diese angenäherten Filterkerne basieren auf dem Einsatz von Integralbildern und profitieren von deren Eigenschaft, dass für Summationen über beliebige rechteckige Flächen der rechnerische Aufwand hierfür stets konstant bleibt. Die angenäherten Filterkerne werden mit D xx, D yy und D xy bezeichnet und sind in Abbildung 2.3 dargestellt. Die schwarzen Bereiche werden hierbei mit dem Faktor -2 gewichtet, die weißen mit dem Faktor 1 und die grauen Bereiche fließen in die Antwort des jeweiligen Filterkerns nicht mit ein. Für die Antwort der D xx - und D yy -Filterkerne sind jeweils immer 8 Speicherzugriffe nötig, für den D xy -Filterkern sind es 16 (vgl. Abbildung 4.2, hier sind die für die Berechnungen benötigten Bildpunkte jeweils rot dargestellt). 17

24 Kapitel 2 Grundlagen Feature-Detektor Bei der Detektion von Kandidaten für Featurepunkte wird das Integralbild des ursprünglichen Ausgangsbildes verwendet. Die Determinante der Hesse-Matrix stellt dabei das Maß für die Qualifikation eines Bildpunktes als Feature dar, wobei durch die Anwendung der angenäherten Gauss-Filter eine Gewichtung der einzelnen Filterkerne benötigt wird. Die sonst auftretende Abweichung wird durch den Parameter ω kompensiert, wodurch die Determinante der Hesse- Matrix für die angenäherten Filterkerne wie folgt zu berechnen ist: det(h) = D xx D yy (ωd xy ) 2 Nach Bay sollte ω einen Wert von 0.91 besitzen [BETG08]. Für die Determinantenberechnung werden auf das Integralbild schließlich die angenäherten Gauss-Filterkerne angewendet, wovon jedoch die Randbereiche des Bildes, die aufgrund der Beschaffenheit des Filters nicht untersucht werden können, ausgenommen sind. Die Determinanten werden für die Bildpunkte in verschiedenen Auflösungsstufen des Bildes unter Verwendung von Filterkernen verschiedener Größe berechnet. Die jeweilige Auflösungsstufe des Bildes wird mit Oktave bezeichnet und stellt den Skalierungsbereich dar, die angewendete Filterkerngröße spiegelt sich im Begriff Intervall wieder. Die Anzahl der Intervalle, also die Abbildung 2.3: Angenäherte Gauss-Filterkerne D xx, D yy und D xy 18

25 Kapitel 2 Grundlagen Anzahl der Iterationen mit Filterkernen verschiedener Größe je Oktave, und die Anzahl der zu betrachtenden Ausflösungsstufen selbst, sind Parameter des SURF-Algorithmus. Die Antworten der unterschiedlich großen Filterkerne werden normiert, indem sie jeweils durch den flächenmäßigen Betrag des aktuellen Filters dividiert werden. Die Feature-Kandidaten werden in einer zweiten Stufe, der Non-Maximum- Suppression, nochmals untersucht. Ein Kandidat wird hierbei eliminiert, falls dessen Determinante nicht das lokale Maximum in seiner 3x3x3-Nachbarschaft über den Orts- und Skalierungsbereich darstellt oder einen individuell zu wählenden Grenzwert (Threshold) nicht überschreitet. Auch der Threshold stellt somit einen Parameter des SURF-Algorithmus dar. Die Werte der unterdrückten Kandidaten fließen jedoch in eine abschließende Interpolation über den Orts- und Skalierungsbereich mit ein, wodurch für die remanenten Featurepunkte eine präzise Positionsbestimmung im Subpixelbereich ermöglicht wird Feature-Deskriptor Durch den Feature-Detektor wurden die Positionen der Featurepunkte im Orts- und Skalierungsbereich ermittelt. Der zweite Bestandteil von SURF, der Feature-Deskriptor, liefert eine Beschreibung dieser Features, unter deren Verwendung die darauf folgende Matching-Phase schnelle und präzise Ergebnisse liefern kann. Das Erstellen des Deskriptors geschieht in mehreren Schritten, welche im Folgenden in einem kurzen Überblick dargestellt werden. Im ersten Schritt wird die Orientierung des Features im Ortsbereich durch die Anwendung von Haar-Wavelets festgestellt. Dies ist optional und muss nur dann durchgeführt werden, wenn eine Invarianz der Deskriptoren gegenüber Rotation gewünscht ist. Falls eine Szene im Bild immer in gleicher Ausrichtung dargestellt wird, so kann auf die Bestimmung der Orientierung verzichtet werden, wobei der Deskriptor als U-SURF ( U für upright ) bezeichnet wird. U-SURF kann schneller als SURF berechnet werden und ist dennoch robust 19

26 Kapitel 2 Grundlagen gegenüber Rotationen von etwa ±15 [BETG08]. Der eigentliche Deskriptor wird nun berechnet, indem zunächst auf die Pixel in der quadratischen 8x8-Umgebung des Featurepunktes Haar-Wavelets in x- und y-richtung angewendet werden. Diese 8x8-Umgebung ist gemäß der gegebenenfalls zuvor festgestellten Orientierung ausgerichtet. Nun werden die Filterantworten von vier benachbarten Pixel zusammengefasst, wodurch eine 4x4-Umgebung mit je einem 4-dimensionalen Deskriptor v = ( dx, dx, dy, dy ) entsteht. Diese bilden zusammengefasst den 64-dimensionalen (U-)SURF-Deskriptor Verfügbare Implementierungen SURF wurde an der Eidgenössischen Technischen Hochschule Zürich durch Herbert Bay et al. entwickelt. Auf der Projektseite [BG09] kann die originale Version von SURF heruntergeladen werden. Allerdings steht hier jedoch nur eine Bibliothek zur Verfügung, die Quellen selbst sind nicht frei erhältlich. Auf dieser Seite wird die Dokumentation zu SURF bereitgestellt. Es existiert eine Reihe von Software-Lösungen, deren Quellen offen sind und deren Lizenzen eine weitgehend freie Verwendung des Algorithmus zulassen. Im folgenden wird eine Auswahl dieser Realisierungen vorgestellt. Eine eigenständige Lösung stellt die Dlib C++ Bibliothek dar, welche gemeinsam mit der Dokumentation auf der Internetseite [Kin09] erhältlich ist. Diese Bibliothek liefert Lösungen für viele verschiedene Problemstellungen, wie etwa aus den Bereichen der Numerik, dem maschinellen Lernen, der Datenkompression und auch der Bildverarbeitung. Die Funktionen get surf points() und compute surf descriptor() stellen Funktionalitäten für die Feature- Extraktion bereit und liefern die Features mit den SURF-Deskriptoren für ein gegebenes Bild. Auch die freie OpenCV-Bibliothek [Ope09] besitzt eine Reihe von Methoden, 20

27 Kapitel 2 Grundlagen um aus Bilddaten Features zu ermitteln, welche für Trackingaufgaben geeignet sind. So bietet OpenCV zum einem Funktionen zur Erkennung von Eckpunkten (vgl. Harris Eckpunkte-Detektor in Kapitel 2.1.3), weiterhin stehen aber auch Funktionen für aktuelle Verfahren wie SURF bereit. Eine solche Funktion ist cvextractsurf(), welche die SURF-Deskriptoren für detektierte Features aus einem übergebenen Bild extrahiert. Die OpenCV-Bibliothek zeichnet sich zudem durch die Eigenschaft aus, dass mit ihrer Hilfe ein komplettes Augmented-Reality-System erstellt werden kann. Hierfür bietet sie weitere Funktionen an, zum Beispiel für das Finden der Homographie zwischen verschiedenen Bildern oder auch für die Kalibration von Kameras. Eine dritte, freie Implementierung des SURF-Algorithmus ist die OpenSURF- Bibliothek. Diese in C++ realisierte Implementierung hält sich stark an den von Bay veröffentlichten Algorithmus. Zudem ist sie sehr gut dokumentiert, was besonders den Einstieg in die Thematik der Feature-Detektion und speziell das Verständnis des SURF-Algorithmus erleichtert. OpenSurf wurde aus diesem Grund als Basis für die Entwicklung der Hardware ausgewählt und wird im folgenden Kapitel im Detail beschrieben. 2.3 OpenSURF Die OpenSURF-Bibliothek von Christopher Evans ist seit Januar 2009 auf der Projektseite [Eva09b] frei verfügbar und befindet sich seither in der Entwicklung. Sie ist in C++ realisiert und verwendet insbesondere für die nötigen Matrix-Berechnungen und die Dateizugriffe die OpenCV-Bibliothek. Christopher Evans legt in [Eva09a] dar, wie der SURF-Algorithmus im Allgemeinen funktioniert und wie dessen Teilstufen in OpenSURF realisiert werden. Im folgenden soll nun ein Einblick in OpenSURF gegeben werden. 21

28 Kapitel 2 Grundlagen Aufbau der Bibliothek Die OpenSURF-Bibliothek ist modular aufgebaut und nutzt häufig die OpenCV- Bibliothek, besonders für Berechnungen von Matrizen und Dateioperationen. Zur Verwaltung der Bilddaten wird ein Bildformat der OpenCV-Bibliothek genutzt, in welchem die geladenen Bilddaten gehalten werden. Die im Algorithmus benutzten Intergralbilder werden ebenfalls in diesem Format gespeichert. Auch zum Laden und eventuellen Speichern von und auf einem Datenträger werden in OpenSURF Methoden der OpenCV-Bibliothek genutzt. Die OpenSURF-Bibliothek selbst stellt Funktionen bereit, welche jeweils verschiedene Basismethoden von SURF implementieren und kombinieren. Dies sind zum einen Methoden zur Merkmalsextraktion und zum anderen Methoden zum Erstellen des Deskriptors. Die diversen Basismethoden werden nun kurz in der Reihenfolge beschrieben, wie sie üblicherweise in SURF durchschritten werden. Zur Übersicht werden die Teilstufen auch in Abbildung 2.4 dargestellt. Nach dem Laden eines Bildes wird dieses in ein Integralbild umgewandelt, wozu es jedoch zunächst in den Graustufenbereich konvertiert wird. Im Anschluss daran findet eine Skalierung der Bildwerte statt, wodurch die Daten im Bilddaten Berechnung des Integralbildes Bilddaten (integriert) Detektion der Features getipoints() Features Berechnung der Deskriptoren getdescriptors() Featuredeskriptoren Abbildung 2.4: Schematische Darstellung der Teilschritte von SURF 22

29 Kapitel 2 Grundlagen folgenden Ablauf des SURF-Algorithmus in Form von 32bit-Gleitkommazahlen verwendet werden. Im nächsten Schritt werden die Featurepunkte durch die Anwendung der Gauss- Filter und das Bilden der Determinanten der Hesse-Matrix für die Bildpunkte in verschiedenen Auflösungsstufen ermittelt (vgl. Kapitel 2.2.2). Es wird hierzu ein FastHessian-Objekt instantiiert, welches den Feature-Detektor in der Funktion getipoints() implementiert. In getipoints() werden zunächst die Determinanten durch die Funktion builddet() berechnet, wobei auch die SURF-Parameter, also die Anzahl der zu untersuchenden Auflösungsstufen (Oktaven) und der jeweils darauf anzuwendenden Filterkerne (Intervalle) berücksichtigt werden. Ein weiterer Parameter in OpenSURF bestimmt die initiale Schrittweite, die bei der Berechnung der Determinanten in der höchsten Auflösungsstufe anzuwenden ist, wobei dieser Wert bei der Determinantenberechnung in jeder weiteren Oktave verdoppelt wird. Um eine höhere Performanz zu erreichen ist dieser Parameter in OpenSURF standardmäßig auf den Wert 2 gesetzt. In einem zweiten Schritt findet in der Funktion getipoints() auch die Untersuchung der 3x3x3-Umgebung und die Unterdrückung von Werten statt, welche kein Maximum darstellen oder den manuell festgelegten Grenzwert, den Threshold, unterschreiten. Die unterdrückten Werte fließen jedoch in eine anschließende Interpolation der übrig bleibenden Featurepunkte bezüglich Ort und Auflösungsstufe mit ein. Nun kann für die gefundenen Features der Deskriptor ermittelt werden (vgl. Kapitel 2.2.3), wofür ein Surf -Objekt instantiiert wird. Dieses stellt die dazu benötigte Methode getdescriptors() bereit. Je nachdem ob ein U-SURF- oder SURF-Deskriptor benötigt wird, wird für den SURF-Deskriptor die Orientierung eines jeden Featurepunktes ermittelt - bei U-SURF entfällt dieser Schritt. Darauf folgend wird der eigentliche Deskriptor berechnet. Die gefundenen Featurepunkte können nun in Verbindung mit deren SURF-Deskriptoren zum Matching verwendet werden. Für diese Aufgabe steht im Quellcode von OpenSURF 23

30 Kapitel 2 Grundlagen ein einfacher Algorithmus bereit, welcher für zwei Listen mit Featurepunkten korrespondierende Paare ermittelt und diese visuell darstellen kann. 2.4 Stand der Technik Neben den in Kapitel vorgestellten SURF-Implementierungen existieren weitere Projekte, die den Algorithmus auf verschiedene Weisen durch Hardware-Unterstützung beschleunigen. Eine Variante des SURF-Algorithmus, deren Quellen nicht frei zugänglich sind und nur als Bibliothek bezogen werden kann, ist GPU SURF. Hierbei wurde SURF durch die Realisierung auf programmierbarer Grafikkarten-Hardware (GPGPU) mittels NVidia s CUDA beschleunigt. In der hierzu verfügbaren Veröffentlichung [CG08] sind die Ideen und Details zur Implementierung dokumentiert, weiterhin können von der Internetseite zur Veröffentlichung das Paper, die Bibliothek und das benötigte Tool-Kit bezogen werden. Noch während der Bearbeitungszeit dieser Masterarbeit wurde von einer Forschungsgruppe der Technischen Universität Prag eine Hardware- Implementierung des SURF-Algorithmus in einem FPGA publiziert. Die im Rahmen der TePRA09 veröffentlichte Arbeit FPGA based Speeded Up Robust Features [SKFP09] legt dar, dass auch diese Gruppe den Schritt der Feature- Detektion beschleunigen konnte. Diese Lösung unterscheidet sich jedoch von der in dieser Masterarbeit entwickelten Hardware-Beschleunigung. Deren Modul deckt den gesamten SURF-Detektor ab, wobei die Erstellung des Integralbildes, die Detektion der Features und zum Teil die Non-Maximum-Suppression miteinander verwoben wurden. Für die effiziente Pipiline-artige Struktur ist es dort nötig internen Speicher des FPGA (Block-RAM) zu nutzen, wozu im Gegensatz das in Kapitel 4 entworfene Modul gänzlich ohne internen Speicher auskommt. 24

31 3 Softwarebasierte Merkmalsextraktion Die Hardware-Plattform ist für diese Arbeit das in Kapitel 8.1 vorgestellte Evaluationsboard Xilinx ML507. Das Hardware-Modul, welches im Rahmen dieser Arbeit zur Beschleunigung des gewählten SURF-Algorithmus entwickelt wird, soll mittels einer standardisierten Schnittstelle an ein System-on-Chip angebunden werden, so dass auch die Integration in ein anderes System und damit dessen Wiederverwendung leicht möglich ist. Zunächst wurde also ein System-on-Chip erstellt, auf welches der bestehende Algorithmus als Software-Lösung zu portieren ist. Darauf aufbauend wird anschließend das eigene Hardware-Modul entwickelt. Die Vorgehensweise zum Erstellen einer Plattform in Form eines System- On-Chip für das in dieser Arbeit verwendete Evaluationsboard wird in Kapitel 8.2 näher beschrieben. 3.1 Portierung des Algorithmus auf die Zielplattform Als Grundlage für das zu entwerfende Hardware-Modul wird in dieser Arbeit die freie Software OpenSURF verwendet, welche in Kapitel 2.3 vorgestellt wird. Diese ist weitgehend portabel und kann direkt auf der Virtex5-Plattform, bzw. auf dem erstellten System-On-Chip (vgl. Kapitel 8.2) eingesetzt werden. Anpassungen sind jedoch an der OpenCV-Bibliothek und der Softwarekonfiguration des Systems vorzunehmen, da bei der vorliegenden Plattform der Dateizugriff über den integrierten SysACE-Controller getätigt wird. 25

32 Kapitel 3 Softwarebasierte Merkmalsextraktion Verwendung der OpenCV-Bibliothek Wie in Kapitel 2.3 erwähnt wird die OpenCV-Bibliothek insbesondere im Zuge der nötigen Berechnungen mit Matrizen und bei Dateizgriffen verwendet. Die OpenCV-Bibliothek stellt unter anderem viele Funktionen zur Grafik-Ausgabe bereit, welche auf dem eingesetzten System-On-Chip aber nicht eingesetzt werden können, da die Plattform nicht die nötigen Schnittstellen bietet. Aus diesem Grund wurde nur der Teil der OpenCV-Bibliothek auf die Zielplattform portiert, welcher für die Ausführung des OpenSURF-Algorithmus benötigt wird. Die Übernahme der Quelldateien gestaltete sich relativ einfach, lediglich die Funktionen, welche den Dateizugriff realisieren, mussten angepasst werden, was im folgenden Abschnitt noch näher erläutert wird Realisierung des Dateizugriffs Die zu bearbeitenden Bilddaten sind auf einer CompactFlash-Karte gespeichert. Um mittels des SysACE-Controllers auf die benötigten Daten zugreifen zu können, ist es zum einen nötig die Softwarekonfiguration der XPS-Plattform wie in Kapitel 8.3 beschrieben anzupassen. Weiterhin müssen die bestehenden Funktionen zum Deteizugriff in OpenCV geringfügig angepasst werden. Diese implementieren ursprünglich herkömmliche Unix-Dateizugriffe, welche für den direkten Dateizugriff auf der vorliegenden Plattform jedoch nur teilweise geeignet sind. Es ist nötig, hier jeweils das entsprechende Pendant für Zugriffe über den SysACE-Controller einzusetzen. Die nötigen Änderungen werden in Kapitel 8.4 dargelegt. 26

33 Kapitel 3 Softwarebasierte Merkmalsextraktion 3.2 Optimierung der Software Um festzustellen, welcher Teilabschnitt des SURF-Algorithmus in der vorliegenden Implementierung besonders rechenintensiv ist, und um damit über eine Grundlage für die weiteren Betrachtungen zur Optimierung zu verfügen, wurde nach der Portierung eine Laufzeitanalyse der Softwarelösung durchgeführt. Die Ergebnisse werden in Kapitel im Detail aufgezeigt. Zusammenfassend wurde durch die Laufzeitmessung der originalen Software-Lösung die Funktion getipoints() und damit der Schritt zur Detektion der Features als konstant rechenintensiv identifiziert. Um einen Geschwindigkeitszuwachs zu erreichen wurden nun Teile der OpenSURF-Implementierung in der Art verändert, dass die Berechnungen in diesem Codebereich nunmehr in Festpunktarithmetik ausgeführt werden - bislang wurden diese in Gleitkommaarithmetik durchgeführt. Diese Modifikation lässt einen gewissen Performancezuwachs erwarten, zudem lässt sich ein Hardware-Modul, wie es in einem späteren Kapitel dieser Arbeit entwickelt und in diese Funktion eingebunden wird, einfacher und platzsparender implementieren. Die Funktion getipoints() berechnet Feature-Punkte, für welche im darauf folgenden Schritt die Deskriptoren bestimmt werden. Innerhalb dieser Funktion werden zunächst in der Funktion builddet() die Deskriptoren berechnet, welche anschließend in der Nachbearbeitung in Form der Non-Maximum- Suppression (vgl. Kapitel 2.2.2) nochmals untersucht werden. Für die in builddet() auszuführenden Filterkernberechnungen werden die Daten des Integralbildes verwendet. Dieses wiederum wird aus den Daten des Ausgangsbilds berechnet (vgl. Kapitel 2.2.1), wobei diese ursprünglich auf den Bereich zwischen 0 (Schwarz) und 1 (Weiß) normiert sind. In der optimierten Version werden die Daten des Ursprungsbilds als Graustufenwerte im 8bit- Ganzzahlbereich interpretiert, wobei Schwarz durch den Wert 0 und Weiß durch den Wert 255 repräsentiert wird. Im Integralbild liegen die Daten nun 27

34 Kapitel 3 Softwarebasierte Merkmalsextraktion im 32bit-Ganzzahlenformat vor. Damit kann auch in der Funktion builddet() ein großer Teil der Gleitkommaoperationen durch Festpunktoperationen ersetzt werden. Es ist hier jedoch darauf zu achten, dass der gültige Zahlenbereich nicht verlassen wird. Um die Anpassung durchzuführen mussten im gesamten Projekt die Funktionen, welche auf dem Integralbild operieren, auf den neuen Zahlenbereich umgestellt werden. Im Wesentlichen mussten die im folgenden genannten Dateien des OpenSURF-Projekts modifiziert werden: Die Datei integral.cpp beinhaltet die Funktionen zur Erstellung des Integralbilds und zur Berechnung der Box-Integrale. Die Box-Integrale werden für das Bilden der Filterkerne benötigt (vgl. Kapitel 2.2.1). Die Bilddaten werden nunmehr im Ganzzahlbereich interpretiert. In der Datei fasthessian.cpp findet die Berechnung der Determinanten statt. Hier sind besonders in der Funktion builddet() aufwändigere Modifikationen nötig, welche im Folgenden näher erläutert werden. Wie vorhergehend erwähnt wurde, sind in der Funktion builddet() verschiedene Modifikationen nötig, damit die Determinantenberechnung in Festpunktarithmetik erfolgen kann. Zum einen muss der Parameter zur flächenbezogenen Normierung der Filterantworten (inverse area) angepasst werden. inverse area wird als die Inverse der quadrierten Kantenlänge des Filterkerns gebildet, welche durch die jeweils aktuelle Oktave und das Intervall definiert ist. Bei dieser Berechnung ist diese Inverse so an den Ganzzahlbereich anzupassen, dass eine möglichst hohe Genauigkeit erhalten bleibt, während bei der anschließenden Multiplikation mit den entsprechenden Filterantworten der gültige Zahlenbereich nicht verlassen werden darf. Weiterhin muss nun bei den anschließenden weiteren Multiplikationen, die zum Bilden der Determinante nötig sind (vgl. Kapitel 2.2.2), der 64bit- Ganzzahlbereich genutzt werden. In diesem Zuge wurde auch der Parameter ω modifiziert. In der ursprünglichen 28

35 Kapitel 3 Softwarebasierte Merkmalsextraktion OpenSURF-Implementierung wird für ω der Wert 0.9 verwendet. Durch die Wahl von ω 2 = 0.875, was einem Wert für ω von etwa 0,935 entspricht, kann die eigentlich auszuführende Multiplikation durch eine Shift-Operation in Verbindung mit einer Subtraktion ersetzt werden. Die Messungen und Ergebnisse zu dieser softwareseitigen Optimierung werden in Kapitel im Detail beschrieben. 29

36 4 Entwurf eines Spezialprozessors für die Determinantenberechnung Wie im Rahmen der Messungen in Kapitel festgestellt wurde, ist innerhalb des OpenSURF-Algorithmus der Codeabschnitt zur Detektion der Featurepunkte im Bezug auf die benötigte Ausführungszeit sehr beachtenswert. Bei weiterer Betrachtung (vgl. Kapitel 6.2.2) erwies sich in diesem Bereich die Funktion builddet() als besonders zeitintensiv. Aufgrund dieser Messungen befasst sich diese Arbeit nun weiter mit der Berechnung der Determinanten, welche für die Bestimmung der Featurepunkte benötigt werden. Im Folgenden werden nun Vorüberlegungen und Ideen zur Beschleunigung dieser Funktion vorgestellt, gefolgt von der Vorstellung der daraus resultierenden Hardware-Architektur und der Beschreibung der einzelnen Komponenten. 4.1 Vorüberlegungen zur Steigerung der Performance In diesem Abschnitt werden nun die grundlegenden Ideen zur Beschleunigung der Determinantenberechnung vorgestellt. Diese greifen an zwei allgemeinen Engpässen eines rechnergestützten Systems an, nämlich der Rechenleistung und dem Speicherdurchsatz, und fließen in den Entwurf des Hardware-Moduls in Kapitel 4.2 mit ein. 30

37 Kapitel 4 Entwurf eines Spezialprozessors für die Determinantenberechnung Berechnung der Determinanten mittels Festpunktarithmetik Die Berechnungen der Determinanten wurde im originalen OpenSURF- Algorithmus mittels Gleitkommaoperationen durchgeführt. Die Funktion builddet() wurde im Zuge dieser Arbeit, wie in Kapitel 3.2 beschrieben, so angepasst, dass sie möglichst ohne Gleitkommaarithmetik ausgeführt werden kann. Hierdurch wurde zum einen bereits bei der Softwarelösung ein beachtlicher Geschwindigkeitszuwachs erreicht, da Berechnungen mittels Festpunktarithmetik bereits allgemein schneller ausgeführt werden können. Weitaus interessanter ist jedoch im Hinblick auf den Entwurf eines Hardwaremoduls die Tatsache, dass dadurch auch das Design und die Implementierung des zu entwickelnden Hardware-Moduls erheblich vereinfacht wird. Bessere Ausnutzung der Speicherzugriffe Je betrachtetem Bildpunkt sind in der Funktion builddet() für die Berechnung der benötigten Filterantworten 32 Speicherzugriffe nötig. In Abbildung 4.3 ist die Struktur der auszuführenden Zugriffe zu erkennen. In diesem Bereich sind also sehr häufige und unregelmäßige Speichertransfers festzustellen. Weiterhin sind für die Berechnungen der Anworten der eingesetzten Filterkerne, wie sie in Kapitel aufgezeigt werden, je Speicherzugriff eine Addition bzw. Subtraktion nötig. Für die letztendliche Bestimmung der Determinante eines Bildpunkts sind zudem noch mehrere Multiplikationen nötig. Die Idee zur Beschleunigung der Funktion builddet() besteht nun darin, die Effizienz der Speicherzugriffe zu verbessern. So werden zum Beispiel für 16 Bildpunkte 512 Speicherzugriffe für die Berechnung der Antworten der Filterkerne benötigt. Jedoch werden für benachbarte Bildpunkte besonders bei geringer Auflösungsstufe und Filterkerngröße oft die selben Daten mehrfach aus dem Speicher gelesen. Das Ziel ist also die gelesenen Daten möglichst effizient zu nutzen. Dies kann dadurch erreicht werden, dass sie für die Berechnung von mehr als nur einer 31

38 Kapitel 4 Entwurf eines Spezialprozessors für die Determinantenberechnung Filterkernantwort genutzt werden, sofern diese auch in die Berechnungen für benachbarte Bildpunkte einfließen. Die Beschleunigung ist nun dadurch zu erreichen, dass die gelesenen Daten mehrfach für die Berechnungen sich überlappender Filterkerne genutzt werden und auf diese Weise die Anzahl der Speicherzugriffe verringert wird. Ein hoher Grad an Überlappung für die einzelnen Filterkerne ergibt sich, wenn die Bildpunkte, für welche die Determinanten berechnet werden sollen, so gewählt werden, dass diese möglichst quadratisch angeordnet sind. Eine mögliche Struktur der auf den Speicher auszuführenden Zugriffe für das oben genannte Beispiel mit 16 Bildpunkten ist in Abbildung 4.4 ersichtlich. Diese Abbildung zeigt die Struktur der zu lesenden Daten für eine 4x4-Anordnung der 16 Bildpunkte. Die Grundlage bilden hier 16 Filterkerne mit einer Größe von je 9x9 Pixeln, welche untereinander einen Abstand von zwei Bildpunkten besitzen - dies entspricht in der ursprünglichen OpenSURF- Implementierung der initialen Schrittweite in der höchsten Auflösungsstufe (vgl. Kapitel 2.3.1). Es lässt sich in der Abbildung leicht ablesen, dass für die gemeinsame Berechnung der Determinanten der 16 Bildpunkte lediglich 216 Werte nötig sind. Bei einer überlappenden Filterkernstruktur müssten somit nur 216 Werte im Vergleich zu den hierfür ursprünglich benötigten 512 Werten aus dem Speicher geladen werden. Parallelisierung der Determinantenberechnungen Bei Systemen mit nur einem Prozessor werden Anweisungen im Allgemeinen sequenziell ausgeführt. So werden auch die arithmetischen Operationen zur Determinantenberechnung bei der Softwarelösung nacheinander getätigt, wodurch die gesamte Rechenzeit für die Bestimmung aller Determinanten somit linear abhängig von der Anzahl der zu berechnenden Determinantenwerte ist. Durch den Einsatz von konfigurierbarer Hardware und die im vorhergehenden Abschnitt beschriebene Idee zur effizienteren Nutzung der Speicherzugriffe lassen sich die Berechnungen verschiedener Determinanten jedoch parallelisieren. Hierzu müssen durch die Hardware genügend Operationseinheiten 32

39 Kapitel 4 Entwurf eines Spezialprozessors für die Determinantenberechnung bereitgehalten werden, welche die vom Speicher gelesenen Daten verarbeiten können. Die Idee besteht nun darin, viele kleine, parallel arbeitende Funktionseinheiten in Hardware zu realisieren, welche die Determinantenberechungen unabhängig voneinander durchführen können. 4.2 Entwurf und Struktur des Moduls Der Entwurf der Hardware-Architektur wurde durch die Vorüberlegungen zur Steigerung der Performanz aus dem vorhergehenden Kapitel maßgeblich beeinflusst. Zum einen sind die zu verarbeitenden Daten in der Art aus dem Speicher zu lesen, dass eine möglichst effiziente Nutzung derselben möglich ist. Weiterhin sollen die Berechnungen der Determinantenwerte in vielen, kleinen Funktionseinheiten parallel abgearbeitet werden. Im Zuge des Entwurfs des gesamten Hardware-Moduls wurde besonderes Augenmerk auf ein effizientes, aber dennoch einfach verständliches Design gelegt. Der gesamte Core ist in mehrere Module aufgeteilt, wodurch das Design auch möglichst übersichtlich gestaltet werden sollte. Zudem ist es hierdurch möglich, dass das Modul zur Synthese konfigurierbar ist, indem bestimmte Module auch mehrfach instantiiert werden können (vgl. Kapitel 5). Die Struktur des gesamten Cores wird in Abbildung 4.1 dargestellt. Die Funktionsweise und der Aufbau der einzelnen Teilmodule wird in den folgenden Abschnitten erläutert. Generierung von Filter-Signalen in fe ctlr Die über schnelle Burst-Zugriffe aus dem Speicher gelesenen Bilddaten liegen immer an allen vorhandenen fe cores an, welche für die Berechnung der Deter- 33

40 mux master_access_control slave_register plb46_master_burst Konfigurationsdaten plb46_slave_single Kapitel 4 Entwurf eines Spezialprozessors für die Determinantenberechnung Bilddaten Bilddaten_Enable Enable fe_ctlr fe_core fe_core fe_core fe_core Bilddaten Determinanten Steuersignale Controller- Logik (Speicherund Line- Controller) fe_line Enable fe_ctlr mux fe_core fe_core fe_core fe_core Done fe_line mux PLB Enable Determinanten fe_line fe_ctlr fe_core fe_core fe_core fe_core mux Enable fe_ctlr fe_core fe_core fe_core fe_core fe_line mux det_build_core user_logic det_build_ctlr 1 Abbildung 4.1: Schematische Darstellung des det build core-moduls bei einer 4x4-Konfiguration minanten zuständig sind. Die einzelnen fe cores dürfen jedoch nur diejenigen Daten verarbeiten, welche tatsächlich in die Determinantenberechnung des jeweiligen Bildpunktes involviert sind. Die für die entsprechenden Filterkerne nötigen Bildpunkte sind in Abbildung 4.2 rot dargestellt. Aus diesem Grund benötigen die fe cores ein Enable-Signal, anhand dessen ein fe core entscheiden kann, ob zu einem bestimmten Zeitpunkt für die Berechnung relevante Bilddaten anliegen oder die Daten ignoriert werden müssen. Die Enable-Signale für den D xx -, D yy - und D xy -Filterkern können zusammengefasst werden. Die Zuordnung zu einem bestimmten Filterkern bleibt erhalten, da auch bei wachsender Filtergröße die Reihenfolge der zu aktivierenden Bild- 34

41 Kapitel 4 Entwurf eines Spezialprozessors für die Determinantenberechnung Abbildung 4.2: 9x9-Filterkerne für D xx, D yy und D xy mit den für die Integralberechnung relevanten Pixeln punkte im Bezug auf die einzelnen Filterkerne immer gleich bleibt. Abbildung 4.3 zeigt die daraus entstehenden Enable-Signale für die Berechnung eines Determinantenwerts auf. Dieses kombinierte Enable-Signal wird vom fe ctlr für die fe cores einer fe line generiert und an diese weitergeleitet. Bei der Berechnung der Determinanten von 16 benachbarten, quadratisch angeordneten Bildpunkten, wie es in Kapitel 4.1 erläutert wird, ergibt sich mit diesen kombinierten Filterkernen eine Struktur, wie sie in Abbildung 4.4 dargestellt wird. Abbildung 4.3: Aus der Kombination der 9x9-Filterkerne resultierende Enable- Signale 35

42 Kapitel 4 Entwurf eines Spezialprozessors für die Determinantenberechnung Abbildung 4.4: Enable-Signale bei einer 4x4-Konfiguration von 9x9- Filterkernen bei einer Schrittweite von 2 Determinantenberechnung im fe core Die Berechnung einer Determinante findet im Modul fe core gemäß der in Kapitel beschriebenen Funktionsweise des Feature-Detektors statt. Das Modul erhält die aus dem Speicher kommenden Daten des Integralbildes und führt die Berechnung durch, welche grob in folgenden Schritten abläuft: 1. In der ersten Phase werden die Filterantworten der D xx -, D yy - und D xy - Filterkerne (vgl. Kapitel 2.2.1) berechnet. Hierzu liefert die übergeordnete Logik die zu verarbeitenden Daten und die der Filterkernstruktur entsprechenden Enable-Signale. 2. In der Berechnungsphase wird aus den Filterantworten die Determinante in diesen Schritten berechnet: Normierung der Antworten im Bezug auf die Filterkerngröße durch Multiplikation mit dem Parameter inverse area (vgl. Kapitel 2.2.2). 36

43 Kapitel 4 Entwurf eines Spezialprozessors für die Determinantenberechnung Berechnung der temporären 64bit-Werte D xx D yy und (D xy ) 2 Berechnung der Determinante mittels Subtraktion des gewichteten (ωd xy ) 2 von D xx D yy, wobei die Gewichtung mit ω durch eine Shiftoperation und Subtraktion realisiert wurde (vgl. Kapitel 3.2). Strukturierung des Moduls durch fe lines Das Modul fe core kann im gesamten Modul mehrfach vorhanden sein, wobei eine logische Strukturierung durch eine Anordnung in Zeilen, den fe lines, stattfindet. Die Struktur eines gesamten Hardware-Moduls, also die Anzahl der der fe cores je fe line und die Anzahl der fe lines wird im Folgenden als n x m-konfiguration bezeichnet, wobei n für die Anzahl der fe lines und m für die Anzahl der fe cores steht. 37

44 5 Implementierung des det build core Nachdem in Kapitel 4 die Grundlagen und auch die Struktur des Hardware- Moduls dargelegt wurden, beschreibt dieses Kapitel Details zur Implementierung des Moduls. Hierbei wird zum einen die Hardware in Gestalt des det build core beschrieben, zum anderen wird auch die zum Betrieb der Hardware nötige Software in Form des zugehörigen Treibers erläutert. 5.1 Entwicklung der Hardware als VHDL-Modul Das gesamte Design des Coprozessors ist in der Art modular gestaltet, wie es in Kapitel 4.2 aufgezeigt wird. Die dort vorgestellte Struktur spiegelt sich in der Implementierung und somit auch in den Teilmodulen des gesamten Hardware-Moduls wieder. Im folgenden werden die Details zur Realisierung und Besonderheiten der einzelnen Komponenten erörtert Anbindung an den PLB durch die Toplevel-Module Das Hardware-Modul wird, bevor die eigentliche Determinantenberechnung stattfinden kann, softwareseitig über Slave-Register konfiguriert. Dies geschieht durch den Treiber, welcher die Schnittstelle zur Software hin bildet und in Kapitel 5.3 näher erläutert wird. Nach diesem Schritt kann der Core die Berechnungen durchführen. Die Toplevel-Module det build core und user logic 38

45 Kapitel 5 Implementierung des det build core Register-Nummer Verwendung 0 Adresse des Integralbilds 1 Bildbreite 2 Schrittweite Inverese-Area 3 Parameter W Parameter L 4 Adresse der Determinantenmatrix Tabelle 5.1: Verwendung der Slave-Register zur Parametrisierung des Hardware- Moduls abstrahieren die Slave-Zugriffe, welche zur Konfiguration des Moduls nötig sind, und die Master-Zugriffe des Moduls auf den PLB, durch die das Modul Daten aus dem Hauptspeicher lesen und in denselben schreiben kann. Diese beiden Module wurden mit Hilfe des EDK-eigenen Wizards zur Erstellung eines Peripherie-Moduls erstellt, wobei hier der softwareseitige Zugriff auf Slave-Register und die Unterstützung von Master-Zugriffen im Burstmodus aktiviert wurden. Die Parametrisierung und Aktivierung der Master-Zugriffe, welche im generierten Peripherie-Modul ursprünglich durch ein mittels Software beschreibbares Steuerregister realisiert waren, wurden in das interne Modul det build ctlr verlagert. Dies wird nachfolgend im Abschnitt dieses Moduls näher beschrieben. Die integrierten Slave-Register werden entsprechend der Treiber-Schnittstelle zur Software hin genutzt, wie es in Tabelle 5.1 und entsprechend in Kapitel 5.3 dargelegt wird. Im Modul user logic erfolgt auch die hardwareseitige Konfiguration des Hardware-Moduls. Diese wird durch die Konstanten FE CORES LG2 CONST, FE LINES LG2 CONST und STEPS MAX LG2 CONST festgelegt. Die ersten beiden Konstanten definieren wie viele Einheiten für die Berechnung der Determinanten erstellt werden und wie diese logisch organisiert sind. Mit der dritten Konstante muss die maximale Größe des Parameters für die Schrittweite steps festgelegt werden. Die Werte dieser Konstanten werden jeweils in das betroffene Modul weitergeleitet. Die nähere Bedeutung dieser Konstanten wird in den Kapiteln 39

46 Kapitel 5 Implementierung des det build core dargelegt, die die jeweiligen Module behandeln Die Steuerungslogik det build ctlr Im Modul det build ctlr ist durch einen Zustandsautomaten die Logik implementiert, welche den Ablauf der Determinantenberechung steuert. Dieses Modul erzeugt die Steuersignale für Master-Zugriffe auf den PLB und wertet die jeweiligen Statussignale der übergeordneten Module aus. Die Determinantenberechnung läuft im Allgemeinen nach folgendem Schema ab: 1. Die Berechnungsmodule (fe cores), welche logisch in fe lines angeordnet sind, werden zurückgesetzt und Daten des Integralbildes werden im Burstmodus aus dem Hauptspeicher angefordert. 2. Die Bilddaten liegen sequenziell am Modul an und werden von den Funktionseinheiten fe core verarbeitet, sofern ein Enable-Signal durch das Modul fe ctlr entsprechend der Filterkernstruktur ausgegeben wird. 3. Sobald alle Berechnungen getätigt wurden und die Determinanten bereitstehen, werden diese an die entsprechende Stelle der Determinantenmatrix im Haupstspeicher geschrieben. In diesem Modul wird entprechend der Konfiguration des Gesamtmoduls die Anzahl von fe lines instanziiert, wie sie durch die Konstante FE LINES LG2 CONST definiert ist. Weiterhin werden hier die Berechnungsergebnisse der einzelnen fe lines durch einen Multiplexer selektiert Logische Strukturierung durch fe line In einer fe line werden die Module des Typs fe core jeweils in der Anzahl instanziiert und verdrahtet, wie es durch die Konstante FE CORES LG2 CONST festgelegt ist. 40

47 Kapitel 5 Implementierung des det build core Damit die vom fe ctlr erzeugten Enable-Signale entprechend der Schrittweite, welche durch den Parameter steps definiert ist, rechtzeitig an dem enstprechenden fe core ankommen, werden diese durch ein Schieberegister verzögert. Durch die Konstante STEPS MAX LG2 CONST muss jedoch bereits vor der Synthese festgelegt werden, welche maximale Schrittweite durch das Hardware-Modul unterstützt werden soll, da die Breite dieses Schieberegisters direkt von dieser abhängt. Die Ergebnisse der fe cores werden nach deren Berechnung selektiv aus der fe line ausgegeben, wobei das gewünschte Datum durch einen Multiplexer ausgewählt wird Berechnung des Filterkerns in fe ctlr Durch die Burst-Zugriffe des Steuermoduls det build ctlr liegen an den Eingängen der fe cores auch Daten an, welche für die Berechnung einer Filterantwort nicht benötigt werden. Damit jedoch nur die tatsächlich benötigten Daten eines solchen Burst-Zugriffes vom jeweiligen fe core zur Determinantenberechnung herangezogen werden, benötigt dieser ein dem Filterkern entsprechendes Enable-Signal. Dieses wird jeweils vom fe ctlr einer fe line berechnet. Für diese Operation benötigt ein fe ctlr die L- und W-Werte des Filterkerns, welche ihm durch den Treiber von der Softwareseite her zur Verfügung gestellt werden. Die bei der Determinantenberechnung verwendeten Filterkerne werden in Abbildung 4.2 beispielhaft für eine Filterkerngröße von 9 mal 9 Bildpunkten dargestellt. Das von einem fe ctlr ausgegebene Enable-Signal stellt eine Vereinigung der einzelnen Filterkerne dar, welche in Abbildung 4.3 aufgezeigt wird. Dieses zeigt dem Modul fe core, welches dieses Signal auswertet, also ausschließlich an, dass aktuell gültige Daten anliegen, jedoch nicht auf welchen Filterkern (D xx, D yy oder D xy ) diese anzuwenden sind. Diese Zuordnung muss im verarbeitenden Modul - hier sind dies die Instanzen des fe cores - geschehen. 41

48 Kapitel 5 Implementierung des det build core Determinantenberechnung in fe core Die Berechnung der Determinanten findet in den fe cores statt, wozu diese die Bilddaten und das vom fe ctlr generierte Enable-Signal erhalten. Nach der Berechnung liefert das Modul ein Done-Signal und den resultierenden Determinantenwert. Beim Entwurf dieses Moduls wurde insbesondere auf geringen Ressourcenverbrauch geachtet. So werden für die arithmetischen Operationen lediglich ein 17-Bit-Multiplizierer und zwei 64-Bit-Addierer verwendet. Auch wurden die nötigen Multiplexer separat implementiert und verdrahtet, so dass das verwendete Synthesewerkzeug genaue Angaben über das gewünschte Design erhält, aber möglichst noch selbst eigene Optimierungen vornehmen kann. Daraus resultiert zum Beispiel die Multiplexerlogik vor den 64-Bit- Addierern, welche nicht mit den gesamten 64 Bit, sondern je mit Teilen zu 16 Bit belegt werden. So ist es möglich, Multiplexer mit möglichst wenigen Eingängen einsetzen zu können - in der vorliegenden Implementierung sind dies zum einen zwölf 6-zu-1-Multiplexer mit 16 Bit Datenbreite, welche den Eingängen der Addierer vorgeschaltet sind. Zum anderen werden zwei 6-zu-1- Multiplexer mit 17 Bit Datenbreite verwendet, welche mit den Eingängen des Multiplizieres verbunden sind. Auch im Bezug auf die effiziente Nutzung von Flipflops wurde darauf geachtet, dass Register möglichst oft wiederverwendet und mit geringen Datenbreiten implementiert werden. Schließlich müssen für die Berechnung der Filterantworten drei 32-Bit Register, für die Determinantenberechnung zwei 64-Bit Register und für die Speicherung des Laplace-Vorzeichens ein 1-Bit Register bereitgehalten werden. Im Sinne eines effizienten Moduldesigns war es auch nötig, ein 32-Bit Register für die temporäre Speicherung von Ergebnissen des Multiplizierers zu implementieren. Die Struktur des Operationswerks einer fe core-einheit wird in Abbildung 5.1 dargestellt. In dieser sind die benötigten Register, Multiplexer und arith- 42

49 Kapitel 5 Implementierung des det build core metischen Einheiten, nämlich die Addierer und der Multiplizierer enthalten. Weiterhin ist hier ersichtlich, wie die einzelnen Komponenten untereinander verbunden sind, insbesondere wie die Eingänge der verwendeten Multiplexer belegt sind. Das Synthese-Werkzeug XST von Xilinx erstellt die in VHDL beschriebenen, oben vorgestellten Elemente, wobei zur Steuerung des Operationswerks ein Zustandsautomat zum Einsatz kommt. Nach erfolgter Synthese eines fe core- Moduls belegt der Synthese-Report, dass hierdurch 306 Slice-Register und 579 Slice-Look-Up-Tables des Virtex-5-FPGAs belegt werden. Weiterhin wird für die Realisierung des Multiplizierers eine DSP48e-Einheit genutzt. Die maximal zu erreichende Frequenz beträgt für dieses Modul 134,750MHz, sofern Geschwindigkeit als Optimierungsziel bei normalem Aufwand festgelegt wird. Sollte Flächenverbrauch als Optimierungsziel bei normalem Aufwand gewählt werden, so sinkt die zu erreichende Frequenz für das Modul einerseits auf 121,192MHz, andererseits werden aber nur noch 268 Slice-Register, 557 Slice-Look-Up-Tables und weiterhin eine DSP48e-Einheit benötigt. 5.2 Integration des Hardware-Moduls in die Plattform Um das Hardware-Modul nutzen zu können muss dieses in das System eingebunden werden, so dass es durch den zugehörigen Treiber, welcher in Kapitel 5.3 dargestellt wird, angesprochen und genutzt werden kann. Zu diesem Zweck wird das Modul der Systemplattform hinzugefügt und in die selbige eingebunden. Hierzu ist es nötig das Modul master- und slaveseitig mit dem bereits vorhandenen PLB des Systems zu verbinden. Weiterhin ist dem Modul ein noch nicht vergebener Adressbereich zuzuweisen, über welchen der Treiber mit der Hardware kommunizieren kann. Nach erfolgter Integration und Konfiguration des Moduls kann das System 43

50 Kapitel 5 Implementierung des det build core '0' t_xx(31:0) t_yy(31:0) t_xy(31:0) Pixeldaten des Integralbilds + mux mux mux t_xxyy(63:0) t_xyxy(63:0) mux + lap_sign(0) OR addsub_acc(31:0) * Parameter mux inverse_area Abbildung 5.1: Schematische Darstellung des Operationswerks eines fe core- Moduls 44

51 Kapitel 5 Implementierung des det build core synthetisiert werden. Im Rahmen dieser Arbeit wurde ein Entwicklungsrechner mit einem Core2-Duo T5670 Prozessor mit 1,80GHz und 2 Gigabyte RAM benutzt. Die Zeit bis letztendlich ein Bit-File für die Konfiguration des FPGA zur Verfügung steht, beträgt bei diesem System etwa 90 Minuten für ein System mit integriertem Hardware-Modul zur beschleunigten Berechnung der Determinanten in einer 4x8-Konfiguration. 5.3 Entwurf des Treibers und Integration in den Algorithmus Das in dieser Arbeit entwickelte Modul wird durch den zugehörigen Treiber in den bestehenden OpenSURF-Algorithmus integriert. Beschreibung des Treibers Der Treiber abstrahiert einerseits die Parametrisierung und das Aktivieren der Hardware. Diese Aufgaben werden in der Funktion det build hw durch Zugriffe auf die Slave-Register des Hardware-Moduls realisiert. Diese Funktion besitzt folgende Parameter: int addr img: Die Adresse, ab welcher die für die Determinantenberechnung benötigten Bilddaten zu erwarten sind. int img width: Die Breite des gesamten Bildes. int inv area: Der durch die Software berechnete Parameter inverse area. int step: Die anzuwendende Schrittweite int param l: Der für die Berechnung des Filterkerns benötigte L-Parameter int param w: Der ebenfalls für die Berechnung des Filterkerns benötigte W-Parameter 45

52 Kapitel 5 Implementierung des det build core int addr det: Die Adresse, ab welcher die berechneten Determinantenwerte gespeichert werden sollen. Zum anderen stellt der Treiber die Funktion det build hw wait() bereit. Nach dem Aufruf derselben wird die Software so lange blockiert, bis das Hardware- Modul die Fertigstellung einer angestoßenen Determinantenberechnung signalisiert. Somit ergibt sich auf der Softwareseite folgender Ablauf: 1. Das Modul det build core wird durch die Software parametrisiert. 2. Direkt nach der Konfiguration wird durch den Treiber ein Go -Signal an das Hardware-Modul gesendet. 3. Das Hardwaremodul führt die Berechnungen durch und sendet zur Software hin abschließend ein Signal. 4. Die Software, welche auf diese Bestätigung wartet, kann nun mit der Bearbeitung fortfahren. Sofern weitere Berechnungen von Determinanten zu tätigen sind, wiederholen sich die oben genannten Schritte, ansonsten kann mit dem weiteren Algorithmus fortgefahren werden. Durch die Konfigurierbarkeit des Hardware-Moduls muss auch der Treiber so konfiguriert werden, dass der Hardware ihrer Konfiguration entsprechend große Blöcke zur Berechnung übergeben werden. Zu diesem Zweck werden in der Datei det build core.h die Parameter HW UNITS (dies entspricht dem Parameter FE CORES LG2 CONST des Hardware-Moduls) und HW LINES (als Pendant zu FE LINES LG2 CONST) eingeführt. Diese finden in den Funktionen Verwendung, die den Treiber aufrufen und im folgenden Abschnitt näher beschrieben werden. Integration in den OpenSURF-Algorithmus An die Stelle der bisherigen softwareseitigen Determinantenberechnung tritt nun das Hardware-Modul. Dieses wird durch den Treiber in den Algorithmus integriert, indem er also die ursprünglichen Berechnungen in der Funktion 46

53 Kapitel 5 Implementierung des det build core builddet() ersetzt. Für die durch die Hardware beschleunigte Berechnung der Determinanten wurde zum einen die neue Funktion builddethw() in das OpenSURF-Paket integriert. Die Determinanten werden in dieser neuen Funktion nun nicht mehr sequenziell berechnet, sondern es werden durch den angebundenen Core größere, der Konfiguration der Hardware entsprechende Bildbereiche verarbeitet. Die inneren Schleifen der ursprünglichen Funktion führen also in x- und y-richtung größere Schritte durch. Im verbleibenden Code werden im Wesentlichen lediglich die Berechnungen der Parameter für die Schnittstelle zur Hardware in Gestalt des Treibers ausgeführt. Die Parameter für den jeweils nächsten Aufruf von det build hw werden vor dem Warten auf die Quittierung des vorhergehenden Laufs berechnet. Damit wird der Prozessor auch während der hardwareseitigen Determinantenberechnungen sinnvoll genutzt und auch die Hardware kann nach einem abgeschlossenen Lauf direkt wieder aktiviert werden. Im Rahmen der Messungen, welche in Kapitel 6.3 dargestellt werden, ist ersichtlich, dass die in Kapitel 3.2 vorgestellte optimierte Software-Lösung in manchen Teilstufen der Determinantenberechnung ein besseres Laufzeitverhalten aufweist als es bei der Variante der Fall ist, welche hierfür ausschließlich das Hardware-Modul einsetzt. Wie in den Abbildungen 6.1, 6.2 und 6.3 zu erkennen ist, ist die Hardware-Lösung bis einschließlich der Filterkernstufe Oktave 1 / Intervall 1 wesentlich effizienter. Ab diesem Punkt stellt die Softwarevariante jedoch die bessere Lösung dar. Aus diesem Grund wurde eine weitere Funktion builddetcombined() implementiert, in welcher bei verschiedenen Filterstufen jeweils die effizientere Lösung gewählt wird. Die damit erzielten Ergebnisse werden in Abbildung 6.4 dargestellt. 47

54 Kapitel 5 Implementierung des det build core 5.4 Validierung Das gesamte, im Rahmen dieser Arbeit entwickelte Hardware-Modul wurde auf die Korrektheit der berechneten Ergebnisse hin überprüft. Auf das Gesamtmodul bezogen wurde dies insbesondere im Bereich der Determinantenberechnungen dadurch bewerkstelligt, dass unter anderem bei den finalen Geschwindigkeitsmessungen die mit dem Hardware-Modul berechneten Ergebnisse stets mit Refernzwerten aus der ursprünglichen Berechnung mittels Software verglichen wurden. Die korrekte Funktionsweise der äußeren Module det build core und user logic wurde bereits während der Entwicklung vorausgesetzt. Diese Module wurden zum einen durch das EDK generiert, zum anderen konnte deren korrekte Funktionsweise direkt durch die funktionierende Kommunikation über den PLB auch nach den eigenen Anpassungen festgestellt werden. Bei der Entwicklung der übrigen internen Module fanden Testbenches in Verbindung mit dem Simulator der ISE-Umgebung Verwendung. Testbenches unterstützen den Entwickler bereits in der Implementierungsphase der Module, indem beispielsweise mit Hilfe von Testdaten bereits die korrekte Funktionsweise der Module sichergestellt werden kann. So wurde beispielsweise auch bei der Entwicklung des fe core mittels definierter Eingangsdaten das jeweilige Endergebnis der durchgeführten Determinantenberechnung mit dem zu erwartenden Wert abgeglichen. 48

55 6 Experimente und Ergebnisse Dieses Kapitel legt die im Rahmen dieser Arbeit durchgeführten Messungen und die daraus abgeleiteten Folgerungen dar. Die Messergebnisse sind die Grundlage für die Entscheidungen bezüglich der getätigten Optimierungsschritte, wobei an den entsprechenden Stellen in dieser Arbeit auf die jeweiligen Messungen und Ergebnisse in diesem Kapitel verwiesen wird. 6.1 Nutzung der Ressourcen des Virtex5-FPGA Nach dem Erstellen eines neuen System-On-Chip, wie es in Kapitel 8.2 dargelegt wird, wurde festgehalten wie viele Logikeinheiten des verwendeten Virtex5-FPGA belegt werden. In Tabelle 6.1 wird die Anzahl an genutzten Logikeinheiten abhängig von der Aktivierung der FPU belegt. Logik-Einheiten (gesamt) SoC ohne FPU SoC mit FPU Slice Register (44 800) (10%) (16%) Slice LUTs (44 800) (8%) (17%) Slices (11 200) (23%) (36%) DSP48e (128) 0 (0%) 13 (10%) Tabelle 6.1: Durch das Basissystem verwendete Logikeinheiten des Virtex5- FPGA Nach erfolgter Integration des entwickelten Hardware-Moduls, wobei fortan ein SoC mit integrierter FPU verwendet wurde, und durchgeführter Synthese des 49

56 Kapitel 6 Experimente und Ergebnisse Gesamtsystems, konnte für verschiedene Hardware-Konfigurationen konnte eine Nutzung des FPGA festgestellt werden, wie sie in Tabelle 6.2 aufgezeigt wird. Logik-Einheiten (gesamt) SoC & HW-Modul (4x4) SoC & HW-Modul (4x8) Slice Register (44 800) (30%) (40%) Slice LUTs (44 800) (44%) (66%) Slices (11 200) (73%) (88%) DSP48e (128) 29 (22%) 45 (35%) Tabelle 6.2: Durch das System-On-Chip und das Hardware-Modul verwendete Logikeinheiten des Virtex5-FPGA 6.2 Laufzeitanalyse der Software Nachdem OpenSURF mit dem relevanten Teil der OpenCV-Bibliothek auf dem System durch die Anpassungen aus Kapitel 3.1 lauffähig war, wurden mehrere Laufzeitanalysen durchgeführt. Diese legen besonders laufzeitintensive Codeabschnitte offen und stellen damit eine Grundlage für die Überlegungen zur Beschleunigung des Systems dar. Die Messungen erfolgten jeweils dadurch, dass die Stände eines Zählers über die bereits vergangenen Taktzyklen des Systems - vor und nach dem zu messenden Codeabschnitt - voneinander subtrahiert wurden. Somit werden Messergebnisse gewonnen, welche für diese Fragestellung eine gute Genauigkeit aufweisen. Die Parameter des OpenSURF-Algorithmus wurden wie folgt gewählt, wobei dies auch die standardmäßig in OpenSURF gewählten Werte sind: Die Anzahl der zu berechnenden Oktaven wurde auf 3 festgelegt. Jede Oktave wurde in 4 Intervallen bearbeitet. Die initiale Schrittweite wurde, wie im originalen OpenSURF- Algorithmus, auf dem Wert 2 belassen. 50

57 Kapitel 6 Experimente und Ergebnisse Auch der Threshold wurde für Messungen von Software in Gleitkommaarithmetik auf dem Wert belassen, für die Messungen der Lösungen mit Einsatz der Festpunktarithmetik wurde der Wert gewählt, da in OpenSURF mit diesem annähernd die gleiche Anzahl an Features berechnet wird. Zur Bestimmung der Messergebnisse wurden im Rahmen dieser Arbeit drei verschiedene Bilder herangezogen: Img1 (457x630 Pixel) und Img2 (300x414 Pixel) sind die im Open- SURF enthaltenen Bilder einer Fassade (aufrecht und rotiert). Für Img1 wurden 565 Feature-Punkte gefunden, bei Img2 waren es 271. Test1 (1069x768 Pixel) ist ein Testbild welches diverse Motive enthält. In diesem Bild wurden 1649 Featurepunkte detektiert Laufzeitanalyse des gesamten SURF-Algorithmus Untersucht wurden im ersten Schritt zunächst alle Teilstufen des SURF- Algorithmus, welche für die Ermittlung der Deskriptoren benötigt werden. Dies ist zum einen die Funktion getipoints(), welche die Bestimmung der Featurepunkte durchführt, und zum anderen die Funktion getdescriptors(), in der die Berechnung der Deskriptoren stattfindet. Die Ergebnisse der Messungen werden in Tabelle 6.3 dargestellt, wobei auch jeweils die Varianten SURF und U-SURF gegenüber gestellt werden. Aus den gewonnenen Messdaten ist zum einen zu erkennen, dass der Zeitaufwand für die Bestimmung der Featurepunkte unabhängig von der gewählten SURF-Variante ist. Andererseits ist die Berechnung der Deskriptoren sehr wohl abhängig von dieser Wahl: bei U-SURF benötigt diese Berechnung etwa die Hälfte der Zeit für die Bestimmung der Featurepunkte, bei SURF liegt sie etwas über derselben. 51

58 Kapitel 6 Experimente und Ergebnisse getipoints() [U-SURF] getdescriptors() [U-SURF] Img Img Test getipoints() [SURF] getdescriptors() [SURF] Img Img Test Tabelle 6.3: Verbrauchte Taktyklen mit dem ursprünglichen SURF-Algorithmus (in Tausend) Weiterhin ist Allgemein zu beachten, dass der Berechnungsaufwand für die Deskriptoren direkt vom Schwellwert abhängt, welcher für die Klassifizierung eines Punktes als interessanter Punkt gewählt wird. Dieser Parameter ist anwendungsspezifisch zu wählen und variiert somit. Nach diesen Ergebnissen fiel die Wahl des weiter zu untersuchenden und damit zu optimierenden Codeabschnitts auf die Funktion getipoints(). Der Rechenaufwand hängt hier einzig von der Größe des zu verarbeitenden Bildes ab und ist somit bei gleicher Bildgröße für jeden Anwendungsfall konstant. Es ist jedoch grundsätzlich denkbar die Berechnung der Deskriptoren ebenfalls durch Optimierungen in der Software oder mittels (konfigurierbarer) Hardware zu beschleunigen, da auch diese - je nach Anwendungsfall und Anzahl gefundener Features - einen großen Anteil an der benötigten Ausführungszeit inne hat Laufzeitanalyse innerhalb des Feature-Detektors Nach der Optimierung der Software, wie sie Kapitel 3.2 beschrieben wird, konnte eine erneute Laufzeitmessung durchgeführt werden. Um nun nach dem Optimierungsschritt innerhalb der Funktion getipoints() besonders zeitintensive Codeabschnitte zu finden wurde auch diese mit der oben genannten Methode untersucht. Hierbei wurden die Zeiten folgender 52

59 Kapitel 6 Experimente und Ergebnisse Codebereiche betrachtet: zum einen die Funktion builddet(), welche die Determinanten für alle Bildpunkte bestimmt, zum anderen die weitere Behandlung der Determinanten-Matrix, nämlich die Anwendung der Non-Maximum- Suppression auf dieselbe. Tabelle 6.4 zeigt die erfassten Messdaten auf, zur Messung wurde das Bild Test1 verwendet. Determinantenberechnung Non-Maximum-Suppression U-SURF SURF Tabelle 6.4: Benötigte Zyklen innerhalb der Funktion getipoints() (in Tausend) Diese Messung zeigt einerseits, dass die Berechnungen zur Detektion der Feature-Punkte wie zu erwarten von der gewählten SURF-Variante unabhängig sind. Andererseits ist deutlich zu erkennen, dass das Bilden der Determinantenmatrix etwa 88% der Ausführungszeit der Funktion getipoints() beansprucht. Schließlich ist zu beachten, dass die Gesamtausführungszeit dieser Funktion durch die Umstellung auf Ganzzahlberechnungen bereits um etwa 33% gesenkt werden konnte. 6.3 Laufzeitanalyse und Bewertung des Hardware-Moduls Nach erfolgter Integration des in dieser Arbeit entwickelten Hardware-Moduls in das Gesamtsystem wurden mehrere Messungen bezüglich der Laufzeit durchgeführt. Für diese Messungen wurden die drei Bilder verwendet, auf welchen auch die in Kapitel 6.2 vorgestellten Softwaremessungen basieren. Die Laufeitanalysen wurden ebenfalls wie bei den vorhergehenden Untersuchungen durch das Messen der jeweils verstrichenen Takte durchgeführt. 53

60 Kapitel 6 Experimente und Ergebnisse Es ist bei der Betrachtung der Ergebnisse auch festzuhalten, dass hier das entwickelte Hardware-Modul mit 100MHz, dem Bustakt des PLB, betrieben wurde, wogegen die fest im FPGA integrierte PowerPC-CPU mit 200MHz getaktet war Messergebnisse aufgeschlüsselt nach Filterkernstufen In detaillierten Messungen wurde zunächst für die optimierte Software-Lösung mit Festpunktarithmetik und die Hardware-Lösung festgehalten, wie viel Zeit die Berechnungen in einer individuellen Filterkernstufe - also in Abhängigkeit von der entsprechendenden Oktave und dem Intervall - benötigen. Das Hardware-Modul wurde in einer 4x4-Konfiguration eingesetzt (4 fe lines mit je 4 fe cores). Die ermittelten Ergebnisse sind in den Tabellen 6.5, 6.6 und 6.7 dargelegt. Zudem werden diese Werte für die jeweiligen Bilddaten in den Abbildungen 6.1, 6.2 und 6.3 visualisiert. Okatve/Interval Software-Lösung Hardware-Lösung (4x4) 0/ / / / / / / / / / / / Tabelle 6.5: Aufschlüsselung der in builddet() benötigten Taktyklen nach Filterstufe (in Tausend) für Testbild Img1 54

61 Kapitel 6 Experimente und Ergebnisse Okatve/Interval Software-Lösung Hardware-Lösung (4x4) 0/ / / / / / / / / / / / Tabelle 6.6: Aufschlüsselung der in builddet() benötigten Taktyklen nach Filterstufe (in Tausend) für Testbild Img2 Es ist hier deutlich zu erkennen, dass insbesondere die Determinantenberechnungen in hohen Auflösungsstufen sehr zeitintensiv sind und einen großen Anteil an der gesamten Berechnungszeit innehaben. Mit dem Einsatz des entwickelten Hardware-Moduls kann jedoch gerade bei diesen hohen Auflösungen und kleinen Filterkerngrößen eine wesentlich niedrigere Laufzeit erreicht werden, als dies bei der entsprechenden Berechnung mittels Software der Fall ist. Mit wachsenden Schrittweiten und Filterkerngrößen schrumpft dieser Vorsprung jedoch, so dass die optimierte, reine Softwarelösung ab einer gewissen Grenze wieder effizienter wird. Die Berechnungszeiten bleiben bei der Softwarelösung aufgrund der gleichbleibenden Anzahl an Speicherugriffen des Prozessors auf den Speicher weitgehend konstant. Je zu berechnender Determinante werden immer 32 Bilddaten gelesen, wobei hier auch Caching-Strategien die zu erreichende Performanz beeinflussen. Nur bei wechselnder Auflösungsstufe beträgt die Berechnungszeit noch ein Viertel des vorhergehenden Berechnungsschritts. Das Laufzeitverhalten der Hardwarelösung lässt sich durch die Art und Weise erklären, wie durch sie auf die zu verarbeitenden Bilddaten zugegriffen wird. Während die Hardwarestruktur besonders bei hohen Auflösungen und kleinen 55

62 Kapitel 6 Experimente und Ergebnisse Okatve/Interval Software-Lösung Hardware-Lösung (4x4) 0/ / / / / / / / / / / / Tabelle 6.7: Aufschlüsselung der in builddet() benötigten Taktyklen nach Filterstufe (in Tausend) für Testbild Test1 Filterkerngrößen von den überlappenden Speicherzugriffen und somit von der mehrfachen Verwendung einmal gelesener Bilddaten profitiert, verschwindet dieser Vorteil zunehmend mit wachsenden Strukturen. Die in Abbildung 4.4 aufgezeigte Struktur wächst fortlaufend in der Größe, wodurch die Anzahl der Lücken in derselben ansteigt und die abgerufenen Daten nicht mehr so oft wiederverwendet werden können, wie es bei einer kompakten Struktur der Fall ist. Schließlich sinkt die Effizienz der durchgeführten Speicherzugriffe im Burst-Modus fortschreitend, da auch immer mehr nicht benötigte Daten aus dem Hauptspeicher gelesen werden. Dieses Problem ließe sich jedoch durch eine Erweiterung des Hardware-Moduls umgehen. Sofern der Burst-Modus im Vergleich zum gezielten Zugriff auf benötigte Daten weniger effizient ist, wäre es zum Beispiel möglich benötigte Daten mittels einer Zugriffstabelle selektiv aus dem Speicher zu lesen. 56

63 Kapitel 6 Experimente und Ergebnisse Erweiterte Messungen und Optimierungen In weiteren Messungen wurde das entwickelte Hardware-Modul auch in einer größeren Konfiguration in das System integriert. Hier wurde die 4x8- Konfiguration (4 fe lines mit je 8 fe cores) gewählt, da diese zum einen noch im verwendeten FPGA des Evaluationsboards Platz findet (vgl. Kapitel 6.1) und zum anderen eine derartige Konfiguration durch die längeren Burst-Zugriffe eine höhere Performance verspricht, als bei einer 8x4-Konfiguration zu erwarten wäre. Weiterhin wird für die Messungen unter Einbezug des Hardware-Moduls nunmehr die kombinierte Software-/Hardware-Lösung gewählt, wie sie in Kapitel 5.3 erläutert wird. Das hiermit erzielte Ergebnis wird speziell für das Bild Test1 in Abbildung 6.4 dargestellt. Es ist hier unter der Bezeichnung SW / HW(4x8) gut zu erkennen, dass die breitere 4x8-Filterkombination besonders in der ersten Oktave (0) einen wesentlichen Geschwindigkeitszuwachs mit sich bringt, was durch die effizienteren Speicherzugriffe mit doppelter Burstlänge erreicht wird. Zudem resultiert aus der 4x8-Konfiguration eine bessere Überlappung der einzelnen Filterkerne, so dass die benötigten Nutzdaten öfter verwendet werden können und auch insgesamt weniger nicht benötigte Speicherzugriffe stattfinden. Schließlich wurden für die Testbilder jeweils die gesamten Berechnungszeiten für die Determinantenwerte festgestellt. Die Messungen werden in Tabelle 6.8 dargestellt. Hier sind die ursprüngliche Softwarelösung, welche die Determinanten in Gleitkommaarithmetik berechnet, und die optimierte Softwarevariante der Hardwarelösung in zwei Konfigurationen gegenüber gestellt. Um den Einfluss der gewählten Hardware-Konfiguration aufzuzeigen wurden zum einen eine 4x4-Konfiguration und zum anderen eine 4x8-Konfiguration der Hardware gewählt. Aus Tabelle 6.8 wird ersichtlich, dass im Vergleich zur ursprünglichen Softwarelösung zwar bereits durch die optimierte Variante ein enormer Ge- 57

64 Kapitel 6 Experimente und Ergebnisse Orig. SW-Lsg. Opt. SW-Lsg. HW-Lsg. (4x4) HW-Lsg. (4x8) Img Img Test Tabelle 6.8: Für die Determinantenberechnungen benötigte Taktyklen (in Tausend) schwindigkeitszuwachs zu verzeichnen ist. Dieser Performance-Gewinn ließ sich durch den Einsatz des Hardware-Moduls in der 4x4-Konfiguration jedoch nochmals um etwa 40%, beziehungsweise in der 4x8-Konfiguration um rund 55% steigern, wobei zu beachten ist, dass die eigene Hardware sogar mit nur der halben Taktrate im Vergleich zur PowerPC-CPU betrieben wurde. Beim direkten Vergleich zwischen der originalen Softwarelösung und der größten in dieser Arbeit getesteten Hardwarekonfiguration ist schließlich festzustellen, dass das entwickelte Hardware-Modul nur noch rund 25% der bisherigen Ausführungszeit benötigt und die Determinantenberechnung damit um den Faktor 4 beschleunigt werden konnte. 58

65 Kapitel 6 Experimente und Ergebnisse Img Taktzyklen (in Millionen) Softw are Hardw are 0 0 / 0 0 / 1 0 / 2 0 / 3 1 / 0 1 / 1 1 / 2 1 / 3 2 / 0 2 / 1 2 / 2 2 / 3 Oktave / Intervall Abbildung 6.1: Ausführungszeiten der in builddet() ausgeführten Berechnungen, aufgeschlüsselt nach Filterstufe (Img1) Img Taktzyklen (in Millionen) / 0 0 / 1 0 / 2 0 / 3 1 / 0 1 / 1 1 / 2 1 / 3 2 / 0 2 / 1 2 / 2 2 / 3 Oktave / Intervall Softw are Hardw are Abbildung 6.2: Ausführungszeiten der in builddet() ausgeführten Berechnungen, aufgeschlüsselt nach Filterstufe (Img2) 59 Seite 2

66 Kapitel 6 Experimente und Ergebnisse Test Taktzyklen (in Millionen) Softw are Hardw are 0 0 / 0 0 / 1 0 / 2 0 / 3 1 / 0 1 / 1 1 / 2 1 / 3 2 / 0 2 / 1 2 / 2 2 / 3 Oktave / Intervall Abbildung 6.3: Ausführungszeiten der in builddet() ausgeführten Berechnungen, aufgeschlüsselt nach Filterstufe (Test1) Test1 (4x4 und 4x8) Taktzyklen (in Millionen) Softw are SW / HW(4x4) SW / HW(4x8) 0 0 / 0 0 / 1 0 / 2 0 / 3 1 / 0 1 / 1 1 / 2 1 / 3 2 / 0 2 / 1 2 / 2 2 / 3 Oktave / Intervall Abbildung 6.4: Ausführungszeiten der in builddetcombined() ausgeführten Berechnungen mit kombinierter Hard- und Softwarelösung (Test1) 60 Seite 6

67 7 Zusammenfassung und Ausblick 7.1 Zusammenfassung Mit dieser Arbeit wurde ein System-on-Chip erstellt, mit dem es möglich ist Feature-Punkte aus Bilddaten zu extrahieren. Dieses kann beispielsweise im Bereich der Augmented Reality oder allgemein für das Tracking von Objekten eingesetzt werden. Während im ersten Schritt eine reine Softwarelösung durch den Einsatz des OpenSURF-Algorithmus geschaffen wurde, konnte das System nach durchgeführter Performanceanalyse im zweiten Schritt durch Optimierungen und durch den Einsatz konfigurierbarer Hardware wesentlich beschleunigt werden. In diesem zweiten Schritt wurde ein Hardware-Modul erstellt, welches durch die Schnittstelle zum PLB eines SoC einfach in ein existierendes System eingebunden werden kann. Es ist bezüglich des Platzverbrauchs innerhalb eines FPGA und damit zusammenhängend in seiner Leistungsfähigkeit konfigurierbar und wurde auch im Rahmen der Arbeit auf die Korrektheit der Ergebnisse hin validiert. Dieses Modul implementiert den in Kapitel vorgestellten Feature-Detektor des SURF-Algorithmus, welcher durch die in Kapitel vorgestellten Methoden ohnehin bereits sehr stark optimiert ist, aber dennoch einen Engpass im Ablauf des SURF-Algorithmus darstellt. Der Feature- Detektor konnte im Rahmen dieser Arbeit durch effiziente Speicherzugriffe und parallele Ausführung arithmetischer Operationen im Umfeld der Determinantenberechnungen jedoch nochmals um ein vielfaches beschleunigt werden. 61

68 Kapitel 7 Zusammenfassung und Ausblick 7.2 Darstellung möglicher Erweiterungsansätze Obwohl durch die in dieser Arbeit entworfene Architektur das Hardware-Moduls eine enorme Performance-Steigerung bei der Bestimmung von Features erzielt wurde, wären noch weitere Modifikationen des Moduls denkbar, die nochmals einen Geschwindigkeitszuwachs versprechen. Diese Ideen konnten im Rahmen dieser Arbeit leider nicht realisiert werden, dennoch sollen sie im Folgenden in Kürze vorgestellt werden Erweiterung und Optimierung des entworfenen Moduls Das in dieser Arbeit entworfene Hardware-Modul kann durch Anpassungen so modifiziert werden, dass dessen Performanz nochmals gesteigert wird. Die hier vorgestellten Modifikationen sind vor allem im Steuerungsmodul des Cores vorzunehmen. So wäre es denkbar nur die Determinanten über die PLB-Master-Zugriffe zurückzuschreiben, welche ungleich Null sind. Es ist jedoch vor der Determinantenberechnung dafür zu sorgen, dass der für die Determinantenmatrix reservierte Speicherbereich vorab mit Nullen initialisiert ist. Eine weitere Möglichkeit zur Steigerung der Performanz wäre es, die Organisationsstruktur der fe cores zu ändern. Beim vorliegenden Modul wird zwar durch die Kombination mehrerer Filterkerne in x- und y-richtung ein hoher Überlappungsgrad im Rahmen der in einem Lauf zu berechnenden Determinanten erreicht. Allerdings müssen auch im Zuge der Berechnungen benachbarter kombinierter Filterkerne überlappende Bereiche mehrfach übertragen werden. Es wäre denkbar, die fe lines so in das Modul einzubinden, dass die dort eingebetteten fe cores nach dem Rückschreiben der berechneten Determinantenwerte 62

69 Kapitel 7 Zusammenfassung und Ausblick sofort wieder zur Verfügung stehen und weitere Berechnungen durchführen können. Die Berechnung der Determianten würde somit nun nicht mehr nur auf einen festen Block der Größe (fe cores-je-fe lines mal fe lines) ausgeführt werden, sondern sie wäre lediglich in der Breite durch die Anzahl der in einer fe line enthaltenen fe cores begrenzt. Eine solche Struktur könnte die lesenden Burst-Zugriffe auf den PLB insofern besser ausnutzen, als dass die bisher existente Blockstruktur, welche in der Höhe durch die Anzahl der fe lines begrenzt war, aufgelöst wird. Eine solche Struktur ist aber nur realisierbar, wenn ausreichend viele fe cores in den jeweils vorliegenden FPGA-Baustein und damit in das Hardware-Modul eingebunden werden können. Die hierfür mindestens benötigte Anzahl an fe cores lässt sich aus der maximalen einfachen Filterkerngröße und der kleinsten eingesetzten Schrittweite berechnen. Eine dritte Überlegung zur Steigerung der gesamten Performanz des Moduls wurde bereits in Kapitel 6.3 aufgezeigt. Die Idee besteht darin, die bisher implementierten Burst-Übertragungen ab einer bestimmten Filterkerngröße durch einfache Single-Zugriffe zu ersetzen. Im Zuge der Laufzeitanalysen konnte festgestellt werden, dass die optimierte Softwarelösung ab einer gewissen Filterkernstufe wieder performanter als die Hardwarelösung wird. Im Rahmen dieser Arbeit wurde diese Eigenschaft durch den Einsatz der jeweils schnelleren Lösung berücksichtigt. Es wäre jedoch auch möglich ab der festgestellten Effizienzgrenze auch in Hardware die Burstzugriffe dort, wo sie wenig performant sind, durch einfach Single-Zugriffe zu ersetzen. Hierfür wird jedoch eine Logik oder Look-Up-Tabelle benötigt, die die zu lesenden Adressen entsprechend der aktiven (roten) Bereiche eines kombinierten Filterkerns vorgibt, wie es beispielhaft in Abbildung 4.4 dargestellt ist Einbinden weiterer Funktionseinheiten und Module Im Zuge dieser Arbeit wurde ein Modul für die schnelle Berechnung der Determinanten aus einem Integralbild entworfen und implementiert. Doch auch weitere Bereiche des SURF-Algorithmus könnten durch Optimierung der 63

70 Kapitel 7 Zusammenfassung und Ausblick Software oder auch durch den Einsatz von Hardware beschleunigt werden. Ein möglicher Ansatzpunkt wäre hier beispielsweise die Berechnung des Integralbildes selbst, was ebenfalls eine für jedes vorliegende Bild zu tätigende Aufgabe darstellt. Weiterhin stellt die Berechnung der SURF-Deskriptoren einen ebenfalls sehr rechenintensiven Teil des gesamten Algorithmus dar, wie in Kapitel festgestellt werden konnte. Durch den Einsatz konfigurierbarer Hardware wäre es möglicherweise auch hier denkbar einen weiteren Performancegewinn zu erzielen. 64

71 8 Anhang 8.1 Xilinx ML507 Virtex-5 FPGA Evaluation Platform Zur Entwicklung eines System-on-Chip bieten verschiedene Hersteller programmierbarer Logikbausteine Lösungen in Form von Entwicklungsumgebungen an. So ist von Xilinx das Embedded Development Kit, kurz EDK, erhältlich, welches in dieser Arbeit zur Hard- und Softwareentwicklung benutzt wurde. Damit ein solches FPGA-basiertes System-on-Chip jedoch nicht nur entworfen, sondern auch evaluiert werden kann, offerieren die Hersteller ebenfalls eine Reihe gut ausgestatteter Entwicklungsboards. Je nach Ausführung stellen diese dem Entwickler neben dem eigentlichen FPGA ein breites Spektrum an bereits integrierten Modulen (z.b. Arbeitsspeicher oder nicht flüchtige Speicher) und Schnittstellen (beispielsweise Ethernet oder PCIe-Bus) an. Insbesondere für Hochschulen und hier im Bereich der Lehre und der angewandten Forschung stellen diese Boards eine preisgüstige Möglichkeit dar, beispielsweise auch Algorithmen für die Merkmalsextraktion auf einem solchen Embedded-Board zu evaluieren und Optimierungen in Form eigener Hardware-Module zu entwickeln und deren Performanz zu untersuchen. In dieser Arbeit wird das ML507-Board der Firma Xilinx als Hardware- Plattform eingesetzt [Xil09a], welches in Abbildung 8.1 dargestellt ist. Durch die reichhaltige Ausstattung bietet diese Plattform eine Vielfalt an Möglichkeiten, Versuche im Bereich des Entwurfs von Hardware/Software-Codesigns in Verbindung mit aktueller FPGA-Technologie durchführen zu können. 65

72 Kapitel 8 Anhang Abbildung 8.1: Xilinx ML507 Virtex-5 FPGA Evaluation Platform mit Programmieradapter Das Kernstu ck dieser Entwicklungsplattform bildet ein FPGA Xilinx Virtex-5 XC5VFX70T [Xil09c]. Dieser FPGA entha lt einen eingebetteten PowerPC440Kern, fu r eigene Logik stehen etwa Virtex-5-Slices zur Verfu gung - ab der Virtex-5 Serie wird als Einheit fu r Logikgatter die Bezeichnung Virtex-5 Slices verwendet, deren Anzahl im vorliegenden XC5VFX70T etwa Logikgattern entspricht. Eingebetteter Speicher in Form von Block-RAM ist in der Gro ße von 5328Kb integriert. Hierdurch mu ssen zum Beispiel fu r eine Anwendung, welche direkt nach der Programmierung des FPGA gestartet werden soll (wie z.b. ein minimaler Boot-Loader), keine Logikgatter verwendet werden. Stattdessen wird dieser Block-RAM mit dem Programmcode vorbelegt, welcher nach dem Programmieren des FPGA direkt ausgefu hrt werden kann. Daneben bietet diese Plattform eine Reihe unterschiedlicher Schnittstellen und Module, welche fu r Versuche in vielen Bereichen ermo glichen: Als Arbeitsspeicher sind 256MB DDR2-RAM in Form eines S0DIMM-Riegels vorhanden, außerdem ko nnen 1MB SRAM und 32MB Flash-Speicher verwendet werden. Gro ßere Datenmengen ko nnen auf einer CompactFlash-Karte gespeichert 66