Farbmarker auf Android

(1)

Fakultät für Elektrotechnik, Informatik und Mathematik

Bachelor Arbeit

Farbmarker auf Android

Thomas Karge Matrikelnummer: 3681485 E-Mail: tkarge@webmail.upb.de

Paderborn, den 18. Juli 2013

(2)

(3)

Eidesstattliche Erklärung

Hiermit versichere ich, die vorliegende Arbeit ohne Hilfe Dritter und nur mit den angegebenen Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, die aus den Quellen entnommen wurden, sind als solche kenntlich gemacht worden. Diese Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen.

Paderborn, den 18. Juli 2013

Thomas Karge

(4)

(5)

Danksagung

Danke, danke, danke...

(6)

(7)

Inhaltsverzeichnis

Danksagung v

1 Einführung 1

1.1 Motivation. . . 4

1.2 Zielsetzung . . . 4

1.3 Lösungsansatz. . . 4

1.4 Aufbau der Arbeit . . . 5

2 Grundlagen 7 2.1 Segmentierung eines Bildes . . . 7

2.1.1 Kantenbasierte Segmentierung . . . 7

2.1.2 Regionsorientierte Segmentierung . . . 9

2.1.2.1 Flood Filling . . . 9

2.1.2.2 Sequential Region Marking . . . 10

2.1.2.3 Farbbasierte Segmentierung mit Run Length Encoding 13 2.1.2.4 Statistische Repräsentation einer Region. . . 14

2.1.2.4.1 Momente der 0. Ordnung . . . 15

2.1.2.4.4 Region Merging mit statistischen Momenten 16 2.1.3 Zusammenfassung . . . 17

2.2 Objekterkennung anhand einer Segmentierung . . . 18

2.2.1 Attribute von CRAG; Color Region Adjacency Graph . . . . 18

2.2.2 Objekterkennung mit CRAG . . . 19

2.3 Die Entwicklungsumgebung . . . 20

2.3.1 Android - Konguration . . . 20

2.3.2 Android - Programiersprache . . . 21

2.3.3 Adnroid - Entwicklungsumgebung. . . 23

2.3.3.1 Konguration der Entwicklungsumgebung . . . 23

2.3.4 Das Android Projekt . . . 24

2.3.4.1 C-Code einbetten . . . 25

2.3.4.2 OpenCV vorbereiten . . . 26

2.3.5 Zusammenfassung . . . 26

Literaturverzeichnis 27

(8)

(9)

1 Einführung

Das menschliche Sehen ist ein Zusammenspiel zwischen den Augen und dem Gehirn.

Der Mensch sieht seine Umgebung, die Augen leiten die Informationen weiter und das Gehirn setzt diese schlieÿlich zu sinnvollen Zusammenhängen zusammen, sodass eine Orientierung im Raum möglich sowie dessen Charakter bewusst wird. Dafür nutzt unser Denkorgan zunächst seine Erfahrung und sein Wissen um die Dinge zu erfassen, die das Unterbewusstsein schlieÿlich logisch erkennt. So kann zum Beispiel eine Vase aufgrund ihrer Form und Farbe vom restlichen Hintergrund abgegrenzt und erkannt werden. Dieser ganz unbewusste und automatische Vorgang des Se- hens erscheint auf den ersten Blick als eine ganz simple Angelegenheit. Ein Mensch erkennt ohne groÿe Mühe eine komplette Landschaft und kann einzelne Objekte darin fokussieren. Doch wie lässt sich diese angeborene Fähigkeit auf künstliche, digital funktionierende Maschinen übertragen?

Bei der Bildverarbeitung passiert es immer wieder, dass die Komplexität eines Vor- ganges schlicht unterschätzt wird. Gerade die Bild Analyse, bei der es nicht nur um die Verbesserung der Bildqualität geht, sondern um die Extraktion einzelner Merkmale und die sinnvolle Interpretation dieser, stellt sich dabei als besonders anspruchsvolles und schwer zu lösendes Problem dar. Die Betrachtung von natür- lichen Landscapes beinhaltet die Aufnahme und Verarbeitung einer enormen In- formationsmenge. Aus diesem Grund wird in der Informationstechnik die Identi- zierung von Objekten über künstliche Landscapes realisiert. Sie abstrahieren ein Objekt auf wenige, aber eindeutige Eigenschaften, im Extremfall repräsentieren sie ein Objekt vollständig durch eine Codierung, die mit den eigentlichen Eigenschaften des Objektes nichts mehr zu tun hat. Ein bekanntes Beispiel sei der Barcode, der vor allem im Bereich der Waren- und Buchkennzeichnung Verwendung ndet.

Abbildung 1.1: Beispiel eines Strichcodes

Bereits in den 50er Jahren entwickelt, wird dieser Code noch heute aufgrund seines einfachen Aufbaus und seiner eektiven Lesbarkeit verwendet. Er kann sowohl von Kameras als auch durch einfache Laser ausgelesen werden. Hinter einer relativen

(10)

1 Einführung

simplen, 1-dimensionalen Kombination aus Linien, die sich nur durch ihre Breite unterscheiden, verbergen sich Informationen, mit denen ein Gegenstand eindeutig identiziert werden kann. Doch aufgrund der schlechten Relation von Datenmenge und Fläche, die wegen der 1-Dimensionalität dieser Codestruktur unvermeidlich ist, wurden bereits 2-dimensionale Codemuster als Nachfolger des Barcodes entwickelt.

Ein sehr bekanntes Beispiel ist der 1994 entwickelte QR-Code, der ebenfalls aus dem heutigem Alltag nicht mehr wegzudenken ist. In Europa ist er besonders durch seine Verwendung mit Smartphones bekannt. Die meisten App-Entwickler bieten als

Abbildung 1.2: QR-Code einer Android App

Download-Möglichkeit ein QR-Code an, der mithilfe der Smartphone-Kamera einge- lesen werden kann. Bei dem QR-Code handelt es sich dann um einen eingebetteten Link, der auf die entsprechende Seite im Google eigenen App-Verzeichnis 'Play Store' verweist, die gewünschte App kann direkt installiert werden. Eine weitere, sehr be- liebte Einsatzmöglichkeit ist das Anbieten von Zusatzinformationen, Beispielsweise in der Werbebranche. Viele Werbeplakate werden mit einem QR-Code versehen; der Nutzer muss nichts weiter tun, als sein Smartphone vor den QR-Code zu halten um weitere Informationen, Internet-Links oder die bereits erwähnten App's zu erhalten.

QR-Code zeichnet sich besonders durch seine variable groÿe Informationskapazität aus. In der umfassendsten Form beschreibt der QR-Code ein 177x177 Kästchen groÿes Feld und kann damit 7089 nummerische Zeichen darstellen. Demgegenüber steht die kleinste Form mit 21x21 Kästchen und einer Daten-Kapazität von 41 nummerische Zeichen, in Form von Micro QR-Code lässt er sich sogar auf ein 11x11 Kästchen groÿes Feld und 5 nummerische Zeichen reduzieren. Eine weitere wichtige

Abbildung 1.3: Vergleich von QR-Code Version 40 und Micro QR-Code M2

2

(11)

Eigenschaft von QR-Code ist die Möglichkeit, Redundante Informationen einzu- betten und dadurch eine Fehlerkorrektur einzubringen. Dabei wird dem Ausgangs- Code RS-Code (Reed-Solomon Code) beigefügt. RS-Code ist eine mathematische Fehlerkorrektur auf Byte Ebene, die bisher vor allem bei Musik-CDs und digitaler Funk-Kommunikation zum Einsatz kommt. Im QR-Code führt dies, je nach Grad des verwendeten RS-Codes, zu einem Kapazitätsverlust von bis zu 60%, im Gün- stigen Fall kann dafür aber eine Beschädigung des Codes auf 30% der Daten noch korrigiert werden.

Diese Ausarbeitung nimmt vordergründig die dahinter verborgenen (für den Nutzer kaum relevant, aber für die Informatik sehr spannend) Segmentierungs- und Erken- nungsalgorithmen auf, die dafür verwendet werden, bestimmte Objekte innerhalb eines Bildes zu erkennen und zu identizieren. Die Smartphone-Kamera erkennt die Codierung, entschlüsselt sie und präsentiert dem Nutzer die dahinter liegende In- formation.

Im C-Lab wurde eine alternative, farbliche Segmentierung entwickelt. Diese bedient sich neben den 2 räumlichen Dimensionen noch die farbliche Dimension. Im Zuge der Segmentierung wird das Eingabebild in eine Menge von Regionen unterteilt, wobei als Zugehörigkeitsmerkmal einer Region eine im Vorfeld denierte Ähnlichkeitsmaske dient. Die so gebildeten Regionen werden auf Basis einer Gauÿ- Normalverteilung in Form von sogenannten Momenten dargestellt, aus denen zur visuellen Anschauung Image Ellipsen generiert werden können.

Dem zugrunde liegend hat die Universität Paderborn farbliche Marker entwickelt, die mithilfe ihrer Segmentierung vermutlich besonders eektiv und robust erkannt und verfolgt werden können. Einsatzgebiet dieser Marker ist ein autonomes Robot-

Abbildung 1.4: Beispiel eines farbmarkers

ersystem, bei dem die einzelnen Roboter, die sogenannten Bebots[7], anhand der Marker erkannt und koordiniert werden.

Obwohl die Farbmarker keine Methodik zur Fehlerkorrektur vorsehen, lässt die Gröÿe der einzelnen Elemente auch bei Bewegung und gröÿerer Entfernung auf einen hohen Grad an Robustheit schlieÿen. Des weiteren besitzen die Farbmarker nur wenige einzelne Elemente, wodurch von einer ezienten Erkennung ausgegangen werden kann.

(12)

1 Einführung

1.1 Motivation

Im Bereich Smartphones und Tablets existieren unterschiedliche künstliche Land- scapes. Diese dienen vor allem dem Bereitstellen von Informationen, die auf statischen Oberächen angebracht und mit einem mobilen Endgerät ausgelesen werden können. Demgegenüber hat das C-Lab Marker entwickelt, mit denen Objekte identiziert werden können. Dabei ist eine Bewegung der zu Objekte in der Entwicklung der Marker berücksichtigt. Die Erkennung der Marker geschieht hierbei auf einem statischen System.

Die Motivation der Ausarbeitung besteht darin, diese beiden Konzepte zu verbinden.

Die vom C-Lab entwickelten Algorithmen der Segmentierung und Farbmarker- Erkennung sollen dabei mobilen Endgeräten zugänglich gemacht werden. Dadurch werden Einsatzgebiete denkbar, bei denen sowohl die künstlichen Landscapes, als auch die das erkennende System dynamisch sein können.

1.2 Zielsetzung

Ziel dieser Ausarbeitung ist es, die bestehende Segmentierung und Farbmarker- Erkennung des C-Lab auf das mobile Betriebssystem Android zu portieren. Die Segmentierung soll beliebiger Android-Software zugänglich gemacht werden. Zur Evaluierung muss ein Interface geschrieben werden, dass die Segmentierung veranschaulicht. Darauf aufbauend soll die Farbmarker-Erkennung auf Android realisiert werden. Dabei wird geprüft, welche zusätzlichen Informationen, wie Entfernung und Winkel zwischen Kamera und Farbmarker, aus der Segmentierung gewonnen werden können. Für das ganze Projekt soll ein Interface entwickelt werden, dass die Segmentierung und Farbmarker-Erkennung verwendet und möglichst anschaulich darstellt.

1.3 Lösungsansatz

Im Zentrum der Ausarbeitung steht die Segmentierung und Farbmarker-Erkennung des C-Labs. Um die bestehende Funktionalität und Korrektheit der im C-Lab re- alisierten Segmentierung möglichst nicht beeinträchtigen, wird die C-Code Imple- mentierung möglichst unverändert in eine Android konforme Bibliothek überführt.

Für diesen Schritt wird ein eigenes Interface geschrieben, um die Funktionalität und Korrektheit der Segmentierung zu überprüfen.

Darauf aufbauend wird die Farbmarker-Erkennung für Android portiert. Die auf Python aufbauende Software wird dabei in Java umgeschrieben. Zusätzlich wird in diesem Schritt geprüft, ob neben der eigentlichen Identizierung auch weitere Infor- mationen aus der Segmentierung geschlossen werden können.

Für die gesamte Realisierung wird ein Interface entwickelt, welches alle Ergebnisse der Ausarbeitung darstellen kann.

4

(13)

1.4 Aufbau der Arbeit

Der Aufbau der Arbeit erstreckt sich über vier Teilbereiche und einer anschlieÿenden Zusammenfassung.

Kapitel 2 (Grundlagen)

Da diese Ausarbeitung auf Grundlage unterschiedlicher Algorithmen aufbaut, werden im Vorfeld zunächst die Grundlagen erläutert. Dieses Kapitel sichtet allgemeine Hintergrundinformationen und stellt einige Lösungsansätze dar, die für die darauf folgenden Kapitel benötigt werden und ein besseres Verständnis der einzelnen Al- gorithmen ermöglicht. Kernpunkte dieses Kapitels ist die Festlegung der Hardware- und Softwareumgebung und eine allgemeine Veranschaulichung der Extraktion und Darstellung von Merkmalen innerhalb einer Bild Analyse.

Kapitel 3 (Implementierung einer Segmentierung)

Sind alle nötigen Grundlagen geklärt, wird im zweiten Schritt der vorhandene Code für die Segmentierung als Bibliothek für Adroid portiert. Zusätzlich wird eine Segmentierung mit der Bibliothek OpenCV umgesetzt. OpenCV ist eine groÿe Sammlung optimierter Algorithmen, die durchaus eine eektivere Lösung für das Problem der Segmentierung anbieten könnte. Beide Segmentierungen werden anschlieÿend miteinander verglichen. Es wird evaluiert, wie eektiv uns robust beide Implementierungen sind und wie gut sie sich eignen, um die Farbmarker-Erkennung umzusetzen. Anhand der Ergebnisse wird entschieden, welche Implementierung für den weiteren Verlauf der Arbeit verwendet wird.

Kapitel 4 (Implementierung der Farbmarker-Erkennung)

Darauf aufbauend wird eine Erkennungssoftware der Farbmarker realisiert. Zunächst wird aus dem auf Python basierendem Interface des C-Lab eine Android-konformes Interface erzeugt. Analog zu vorherigen Schritt wird auch für den Teil der Marker- Erkennung eine zusätzliche Implementierung auf Basis von OpenCV umgesetzt und beide Lösungen auf ihre Eigenschaften Eektivität und Robustheit untersucht. Dabei wird darauf geachtet, dass beide Implementierungen die gleichen Schnittstellen für das Android Interface besitzen.

Kapitel 5 (Erstellen eines Interfaces)

Im laufe der Realisierung wird zusätzlich überprüft, welche zusätzlichen Informatio- nen über die Farbmarker durch die Segmentierung neben der Eigentlichen Codierung noch gewonnen werden können. Im letzten Teil wird ein Android-Interface für die gesamte Umsetzung der Segmentierung und Marker-Erkennungen geschrieben.

Das Interface soll benutzerfreundlich und interaktiv gestaltet werden und alle aus

(14)

1 Einführung

der Segmentierung und Farbmarker-Erkennung gewonnenen Informationen veranschaulichen.

Kapitel 6 (Zusammenfassung)

In diesem Kapitel wird noch einmal zusammenfassend ein Rückblick auf die gesamte Arbeit gewährt. Auÿerdem stellt es mögliche Verbesserungen und Erweiterungen der entwickelten Software in Aussicht.

6

(15)

2 Grundlagen

Für das Verständnis dieser Ausarbeitung sind fundierte Kenntnis in einigen Bere- ichen der Bildanalyse und der eingesetzten Softwareumgebung notwendig. Dieses Kapitel setzt sich erst mit allgemeinen Techniken der Bildanalyse auseinander, auf die die vom C-Lab entwickelten Algorithmen und Software aufbauen und beschreibt anschlieÿend die eingesetzte Implementierungsumgebung mit dem angestrebte Be- triebssystem Android.

2.1 Segmentierung eines Bildes

Die Segmentierung eines Bildes ist einer der wesentlichen Schritte im Ablauf der Objekterkennung. Bei der pixelbasierten Segmentierung wird jeder Pixel einzeln betrachtet und aufgrund seines Grau- oder Farbwertes dem Hintergrund oder dem Vordergrund des Bildes zugeordnet. Den Pixeln wird dabei eine Benennung, ein sogenanntes Label, gegeben. Kantenbasierte Segmentierungen durchlaufen ein Bild und unterscheiden darin enthaltenene Formen aufgrund Ihrer Umrisse. Dadurch können, anders als bei der binären Segmentierung, auch die einzelnen Formen selbst zueinander unterschieden werden. Regionsorientierte Segmentierungen zielen darauf ab, die Pixel nach homogenität in unterschiedliche Formen zu verteilen. Jede zusam- menhängende Form wird dabei als eigene Region beschrieben und identiziert.

Die Segmentierung ist aber nicht nur ein wichtiger Schritt für die Objekterkennung, sondern auch ein sehr aufwendiger Prozess. Das resultiert daraus, dass im einfach- stem Fall jeder einzelne Pixel dem Vordergrund oder dem Hintergrund des Bildes zugeordnet und damit mindestens einmal besucht und auf seine Zugehörigkeiten untersucht werden muss. Daher existieren für die Regionen unterschiedliche Darstel- lungsformen, die darauf abzielen, die Informationen einer Region zu komprimieren und teilweise direkt aus dem verwendeten Segmentierungsverfahren resultieren.

2.1.1 Kantenbasierte Segmentierung

Kantenbasierte Segmentierungen zielen darauf ab, jene Pixel zu identizieren, welche sich zwischen zwei Regionen benden. Pavladis[11] beschreibt als einfach- ste Möglichkeit der Kantenerkennung die Verwendung von Filtern. Da solche Filter meist nur Kanten einer Orientierung erkennen, empehlt Pavladis, stets mehrere Filter auf ein Bild anzuwenden. Die nach Pavladis einfachsten Filter zur Kanten-

(16)

2 Grundlagen

erkennung sind

Hhoriz=





−1 −c −1

0 0 0

1 c 1





H_hvert =





1 0 −1 c 0 −c 1 0 −1





Wie die Namen schon sagen, ltert Hhoriz nach horizontalen und Hvert nach ver- tikalen Kanten und ergeben zusammen eine Kantenerkennung in horizontaler und vertikaler Dimension. Das Ergebnis ist ein binäres Bild, bei dem Kanten durch 1 und alle übrigen Pixel durch 0 dargestellt werden. Auf dieses Bild kann border following angewendet werden. Dies ist eine Segmentierung, die in einem Paper von Suzuki und Abe[13] beschrieben. Die Idee bei diesem Verfahren liegt darin, den Hintergrund des Bildes zu durchlaufen, bis ein Vordergrundpixel, in diesem fall ein Kantenpixel, besucht wird. Von diesem ausgehend hangelt sich das Verfahren an der anliegenden Kantenpixeln entlang, bis es wieder beim ersten ausgangspixel angekommen ist.

Abbildung 2.1: Kantensegmentierung nach border

following[13]; a) Ausgangsbild. b) Baum mit den Hintergrundregionen. c) Baum mit den Vordergrundregionen

Bei diesem Verfahren werden sowohl äuÿere, als auch innere und oene Konturen entdeckt. Mit den gefundenen Regionen wird ein Baum gespannt. Die einzelnen Regionen können direkt als chain code gespeichert werden.

Chain Node ist eine Art der Repräsentation von Pixelketten, bei der die Pixelkette anhand ihrer nächsten Elemente beschrieben wird, d.h. an jedem Pixel ist hinterlegt, in welcher Himmelsrichtung das nächste Pixel der Kette zu nden ist.

8

(17)

2.1 Segmentierung eines Bildes

Abbildung 2.2: Veranschaulichung von Chain Node mit 4 und 8 Himmelsrichtungen (aus Burger[4], S. 29

2.1.2 Regionsorientierte Segmentierung

Zu den bekanntesten Umsetzungen zählen die Algorithmen ood lling und sequential region marking. Burger beschreibt sie für binäre Bilder (z.B. schwarz weiÿ Bilder), mit einer Abwandlung der Metrik lassen sich aber auch Grauwert oder Farbbilder mit diesen Verfahren Segmentieren. ood lling geht von einzelnen Punkten aus und überprüft die umliegenden Pixel auf Zugehörigkeit zu der Region und eignet sich besonders gut für einen Einstieg in regionsorientierte Segmentierung. Sequential region marking hingegen durchläuft das gesamte Bild zeilenweise und Pixel für Pixel und ordnet sie in Regionen ein. Als drittes Verfahren wird auf Run Length Encoding, RLE, eingegangen. Dieses Verfahren kann sowohl zur Segmentierung als auch zur Repräsentation von Regionen verwendet werden und wird im ersten Schritt der Segmentierung vom C-Lab verwendet.

2.1.2.1 Flood Filling

Flood lling ist ein einfach zu implementierender Algorithmus. Die Idee wird bereits 1982 von Pavladis beschrieben und besteht darin, sich einen Pixel im Bild auszusuchen und als Startpunkt einer Region zu sehen. Von diesem ausgehend werden dann die umliegenden Pixel Schritt für Schritt anhand einer Ähnlichkeits-Metrik der Region hinzugefügt oder von ihr ausgeschlossen. Daher auch der Name: Wie eine Flüssigkeit, die in eine Form gegossen wird, füllt sich die Region nach und nach mit zugeordneten Pixeln. Für die Wahl des nächsten Startpunkt einer neuen Region kann der nächste, freie Pixel verwendet werden.

Burger beschreibt die Iplementierungsmöglichkeit von ood lling durch drei Herangehensweisen: recursiv, iterativ depth-rst und iterativ breadth-rst. Für Sys- teme mit eingeschränkten Ressourcen wie eingebetteten Systemen empelt sich vor

(18)

2 Grundlagen

allem die Variante iterativ breadth-rst, da sie nach Burger Speicher schonender ist als iteratif depth-rst und recursiv mit seinen rekursiven Aufrufen sehr viel Speich- er verbraucht und bei gröÿeren Regionen nicht mehr anwendbar ist. Wie Abb. 2.3 zeigt, spannt iterativ breadth-rst die Region ausgehend vom Startpixel gleichmäÿig in alle Richtungen auf, bis die Region vollständig erkannt ist. (näheres bezüglich implementation siehe (Burger 2009[4], S. 6 )).

Abbildung 2.3: Ablauf einer iterativ breadth-rst Segmentierung nach K Schritten (siehe (Burger 2009[4], S. 11))

2.1.2.2 Sequential Region Marking

Eine Speicherschonende alternative zu ood lling ist sequential region marking.

Diese Segmentierung kann in der von Burger beschriebenen Form nur auf binäre Bilder angewendet werden, bei denen die Pixel bereits durch die binäre Form in Vordergrund- und Hintergrundpixel unterteilt ist. Dabei werden die Pixel eines Bildes von links oben nach rechts unten abgearbeitet und für jeden Vordergrund- pixel geprüft, ob er zu einer anliegenden Region gehört. Für jede neu angefangene Region wird dabei ein neues Label verwendet. Aufgrund des strikten Durchgehen der Pixel von links oben nach rechts unten kommt es allerdings dazu, dass einzelne Regionen im ersten schritt von sequential region marking in mehrere Label getrennt werden. Im zweiten Schritt müssen diese geteilten Regionen gefunden und zur eigentlichen Region zusammengeführt werden.

Schritt 1: Erstes Labeling Der erste Schritt besteht aus einer vorläugen Zuordnung der Pixel. Sequential region marking durchläuft dabei jeden Pixel von links oben nach rechts unten und überprüft, ob er zur Region eines Nachbarpixels gehört, oder den Anfangspunkt einer neuen Region beschreibt. Abhängig von der Denition von Nachbarschaft besitzt ein Pixel 4 (N4) oder 8 (N8) Pixel Pixel in direkter Nachbarschaft, die auf ähnlichkeit geprüft werden können. Allerdings sind durch den Durchlauf von Sequential region marking von links oben nach

10

(19)

2.1 Segmentierung eines Bildes rechts unten nur die Pixel oberhalb und genau links neben dem betrachtetem Pixel entscheidend, da über die Zugehörigkeit der anderen Pixel noch keine Aussage festliegen kann. Somit sind für jeden Pixel bei N4 mit 2 und bei N8 mit 4 Nachbarpixeln interessant.

Abbildung 2.4: Veranschaulichung von Nachbarschaft (siehe (Burger 2009[4], S. 12))

Für ein betrachtetes Pixel können demnach 3 unterschiedliche Fälle auftreten:

Für den Fall, dass keiner der interessanten Nachbarn Vordergrund ist, wird der Pixel mit einem neuen Label markiert. Besitzen die Nachbarn Label einer Region, wird dem betrachtetem Pixel das gleiche Label gegeben. Benden sich Pixel mit unterschiedlichem Label in der interessanten Nachbarschaft, so wird der betrachtete Pixel dem niedrigerem Label zugeordnet. Aufgrund des Aufbaues von sequential region marking können sich nur zwei unterschiedliche Label in der Nachbarschaft eines Pixels benden. Ein solches Angrenzen zweier Regionen wird als collision bezeichnet und die angrenzenden Regionen als Paar in einer dynamischen Liste gespeichert.

(20)

2 Grundlagen

Abbildung 2.5: Erster Schritt von sequential region marking(siehe (Burger 2009[4], S. 13))

Schritt 2: Kollisionen lösen Das Auösen der Kollisionen ist nicht trivial. Das resultiert daraus, dass mehrere Regionen durch Transitivität miteinander verbunden sein können und somit identisch ist mit dem Problem, verbundene Komponenten in einem Graphen zu nden. Als Lösung des Problems wird auf Mengen zurückgegri- en. Zu Beginn existiert für jedes Label, welches in einem Kollisionspaar enthalten ist, eine Menge mit allen Pixeln, die mit diesem Label gekennzeichnet wurden. Für jedes Kollosionspaar wird dann geprüft, in welchen Mengen die Pixel mit den beteiligten Labeln enthalten sind. Sind dies unterschiedliche Mengen, so werden die Mengen miteinander vereint, indem alle Pixel einer Menge zur anderen hinzugefügt werden.

Am Ende benden sich die Pixel aller Kollosionspaare in der selben Menge und werden mit einem einheitlichem Label, zum Beispiel dem kleinsten in der Menge

12

(21)

enthaltenem Label, markiert.

2.1.2.3 Farbbasierte Segmentierung mit Run Length Encoding

Farbbasierte Segmentierungsverfahren zielen darauf ab, ein Bild anhand der farblichen Informationen zu unterteilen. Nach Cheng bietet das den Vorteil, dass Farben stabil gegenüber unterschiedlicher geometrischer Transformationen wie Rotation, Translation und Skalierung sind. Zudem verhalten sich Regionen einer Oberäche invariant gegenüber sich ändernden Lichtverhältnissen (siehe Cheng[5], S. 33 folgende). RLE liefert eine Segmentrierung, bei der einzeilige Regionen erzeugt werden. Anschlieÿend werden Regionen, die auf mehrere Zeilen verteilt sind, mithilfe eines Region Growing-Verfahrens zusammengeführt. Das C-Lab verwendet ein Region Mergin-Verfahren, welches sich der statistischen Momente einer Region bedient.

Jähne beschreibt RLE als Repräsentation von Regionen, die zeilenweise die benachbarten Pixel zu einer Region gruppiert, wenn diese einer vordenierten Ähnlichkeitsmetrik nach ähnlich sind. Diese Metrik kann auch farbliche Ähnlichkeit beschreiben, wodurch sich RLE für die farbliche Segmentierung eignet. Im folgenden wird RLE auf Basis eines Grauwertbildes erläutert, dieses Bild kann aber auch als ein Farbkanal eines Bildes interpretiert werden.

a) Grauwertbild

Originalzeile (hex): 12 12 12 20 20 20 20 25 27 25 20 20 20 20 20 20 Code (hex) 82 12 83 20 2 25 27 25 85 20

b) Binärbild

Originalzeile (hex): 1 1 1 1 1 1 0 0 0 1 1 1 0 0 1 0 0 0 0 0 1 1 1 1 1 1 1 1 Code (hex) 0 6 3 3 2 1 5 8

Abbildung 2.6: Veranschaulichung des Lauängencodes für a ein Grauwertbild und b ein Binärbild

(Jähne[8], S. 544)

Wie in 2.6 zu erkennen, lässt sich durch RLE je nach Homogenität und Art eines Bildes der Speicherverbrauch deutlich reduzieren. Mittels RLE lassen sich die Regionen während der Segmentierung also auch komprimieren. Bei den von Jähne gezeigten Beispielen werden nur exakt gleiche Pixel gruppiert, was dazu führt, das keinerlei Informationen des Bildes verloren gehen. Das originale Bild kann aus dem Abbild vollständig rekonstruiert werden. Anders verhält es sich, wenn die Pixel im RLE unter Verwendung einer Ähnlichkeitsmetrik Gruppiert werden2.7. Zwar kann dabei eine nahezu beliebige Komprimierung einer Bildzeile erreicht werden, mit zunehmendem Komprimierungsgrad gehen aber mehr Daten verloren, die nicht aus der Abbildung rekonstruiert werden können. Lediglich bei einem Binärbild lässt

(22)

2 Grundlagen

sich die Komprimierungsrate nicht variabel gestalten.

Originalzeile (hex): 12 13 14 20 20 21 22 22 21 21 21 20 13 10 Code a) (hex) 2 12 13 14 82 20 2 21 82 22 8 21 2 20 13 10 Code b) (hex) 83 13 82 19 86 22 2 20 13 10

Abbildung 2.7: Verwendung von RLE mit unterschiedlichen Metriken: Bei a werden nur exakt gleiche Pixel gruppiert während b die Pixel über Modulo 3 gruppiert werden

2.1.2.4 Statistische Repräsentation einer Region

Der Grundgedanke liegt dabei in der Idee, Regionen durch einige wenige Variablen so weit zu Beschreiben, dass eine Analyse im Sinne der Objekterkennung möglich ist. Erster Ansatz ist die Beschreibung einer Region anhand der Wahrscheinlichkeit, dass ein umliegender Pixel dieser Region zugehörig ist oder nicht. Diese Wahrschein- lichkeitsdichtefunktion lässt sich durch eine Gauÿ'sche Normalverteilung mit ihren statistischen Momenten beschreiben und graphisch als eine Schar von Höhenlinien, oder für eine bestimmte Wahrscheinlichkeitsgrenze als Ellipse, veranschaulichen[9].

Abbildung 2.8: a) Binäre Regionen und b) die Darstellung ihrer zweidimensionalen Dichtefunktionen durch Höhenlinien. aus (Jungmann[9], S. 45)

Im folgen wird veranschaulicht, wie alle für die Objekterkennung notwendigen geometrischen Eigenschaften einer Region aus den ersten 6 Momenten in konstanter Zeit berechnet werden können. Diese Momente selbst können nach Bruce[3] direkt aus der RLE überführt werden

Die folgenden Formeln werden von Stichling direkt oder indirekt beschrieben(Stichling[12], S. 82 folgende). Stichling beschreibt die Momente

14

(23)

eines Pixelbildes allgemein mit der Formel

m_pq =

height

X

y=1 width

X

x=1

x^py^qf(x, y)

Dabei beschreibt die Funktion f(x,y) die Zugehörigkeit des Pixel zu der entsprechenden Region. Für f(x,y) gilt also:

f(x, y) =

1, (x, y)∈Region 0, (x, y)6∈Region

Stichling führt im folgenden auf, dass es nach dieser Formel theoretisch eine un- endliche Anzahl an Momenten berechnet werden kann. Für die Beschreibung einer Ellipse, und damit ausreichend für die kompakte Umschreibung einer Region, werden die Momente bis zur 2. Ordnung benötigt.

2.1.2.4.1 Momente der 0. Ordnung Beim Moment der 0. Ordnung ergibt sich für x^p undy^q der Wert 1. Es ergibt sich die Formel

m00=X

y

X

x

f(x, y)

Diese Summe entspricht der Anzahl der Pixel, die zu der Region gehören, also die Masse der Region.

2.1.2.4.2 Momente der 1. Ordnung Bei den Momenten der 1. Ordnung ergibt sich entweder fürx^podery^qder Wert 1. Somit beschreiben die beiden Momente der 1. Ordnung die Summe aller x- und y-Werte.

m01=X

y

X

x

xf(x, y)

m10=X

y

X

x

yf(x, y)

Zusammen mit der Masse von Momentm₀₀ lassen sich die Mittelwerte für x und y und damit der Mittelpunkt der Region berechnen, die die Region Beschreiben soll.

cx = m₁₀ m00

, cy = m₀₁ m00

Die Zentralmomente µ_pq beschreiben die die Verschiebung der Schwerpunkte zum Ursprung und lassen sich durch die Basisfunktion (x-cx)^p(y-cy)^q erreichen. Davon ausgehend lässt sich eine allgemeine Formel für die deskreten Zentralmomente auf- stellen:

µpq =X

y

X

x

(x−cx)^p(y−cy)^qf(x, y)

(24)

2 Grundlagen

µ11 µ20 - µ02 ϕ θ

0 - 0 π/2

+ - 0> ϕ > - π/4 π/2> θ > π/4

+ 0 0 π/4

+ + π/4 > ϕ >0 π/4 > θ >0

0 0 0 0

- + 0> ϕ > - π/4 0> θ >-π/4

- 0 0 -π/4

- - π/4 > ϕ >0 -π/4 > θ >-π/2 Tabelle 2.1: Tabelle2.1Orientierung der groÿen Hauptachse

(nach Stichling[12], S 85)

2.1.2.4.3 Momente der 2. Ordnung Die Momente der 2. Ordnungm20,m02 und m₁₁und die dazugehörigen Zentralmomenteµ₂₀,µ₀₂undµ₁₁ werden laut Stichling auch Trägheitsmomente genannt. Sie beschreiben die Äusdehnung und die Orien- tierung der Hauptachse einer Region"[12]. Mit den Momenten bis zur 2. Ordnung lässt sich somit alle wichtigen Eigenschaften einer Region umschreiben. Anhand dieser 6 Momente lässt sich eine Ellipse konstruieren, welche die Region annähernd darstellt. Die Berechnung des Winkelsϕerfolgt sich mit Hilfe vonµ20,µ02undµ11:

ϕ01= 1 2tan⁻¹

2µ11

µ20−µ02

ϕ beschreibt dabei den Winkel einer Hauptachse der Region. Der Winkel θ der gröÿeren Hauptachse der Region lässt sich mithilfe der Tabelle2.1bestimmt. Unter verwendung der Zentralmomente 0. und 2. Ordnung lassen sich die Längen a und b der Hauptachsen berechnen:

a= s

2(µ₂₀+µ₀₂+p

(µ₂₀−µ₀₂)²+ 4µ²₁₁) µ00

b= s

2(µ20+µ02−p

(µ20−µ02)²+ 4µ²₁₁) µ₀₀

Stichling beschreibt die Momente m00, m10, m01,µ₂₀,µ₁₁und µ₀₂ als geometrische Momente.

2.1.2.4.4 Region Merging mit statistischen Momenten Werden in einem Seg- mentierungsalgorithmus Regionen durch Momente dargestellt, können diese durch Region Merging miteinander vereint werden. Für eine korrekte Laufzeitanalyse muss ersichtlich sein, wie schnell zwei Regionen miteinander verschmolzen werden können.

An dieser stelle wird gezeigt, wie Stichling zwei Regionen beliebiger Gröÿe miteinan-

16

(25)

2.1 Segmentierung eines Bildes der verschmilzt und die Momente der neuen Region in konstanter Zeit berechnet.

"Gegeben seien zwei Regionen R und R' durch die Repräsentationen (m00,m10,m01, µ₂₀,µ₀₂,µ₁₁) und (m⁰₀₀,m⁰₁₀,m⁰₀₁,µ⁰₂₀,µ⁰₀₂,µ⁰₁₁). Gesucht wird nun die Repräsen- tation (m⁰⁰₀₀, m⁰⁰₁₀, m⁰⁰₀₁, µ⁰⁰₂₀, µ⁰⁰₀₂, µ⁰⁰₁₁) der Region R, die alle Pixel aus R und R' enthält."(Stichling, [12] S. 85)

Bei den Momenten der 0. und 1. Ordnung handelt es sich reine Summen. Da die Summe zweier Summen mittles einer einfachen Addition in konstanter Zeit berechnet werden kann, ergibt sich für die Momente m⁰⁰₀₀, m⁰⁰₁₀ und m⁰⁰₁₀ lediglich die Formeln:

m⁰⁰₀₀=m₀₀+m⁰₀₀ m⁰⁰₁₀=m₁₀+m⁰₁₀

m⁰⁰₀₁=m₀₁+m⁰₀₁ Für µ₂₀ gilt:

µ⁰⁰₂₀=X

y

X

x

(x−c_x)²f⁰⁰(x, y)

Nach einigen Umformungsschritten gelangt Stichling zu der Formel µ⁰⁰₂₀=µ₂₀+m²₁₀

m00

+µ⁰₂₀+ m⁰²₁₀

m⁰₀₀ −m⁰⁰²₁₀ m⁰⁰₀₀

Die Berechnung von µ⁰⁰₂₀ lässt sich damit auf eine Summe reduzieren und erfolgt demzufolge in konstanter Zeit. Analog verhält es sich für µ⁰⁰₀₂ und µ⁰⁰₁₁ mit den Formeln:

µ⁰⁰₀₂=µ02+m²₀₁ m00

+µ⁰₀₂+ m⁰²₀₁

m⁰₀₀ −m⁰⁰²₀₁ m⁰⁰₀₀ µ⁰⁰₁₁=µ₁₁+m₁₀m₀₁

m00

+µ⁰₁₁+m⁰₁₀m⁰₀₁

m⁰₀₀ −m⁰⁰₁₀m⁰⁰₀₁ m⁰⁰₀₀

Insgesamt hat Stichling damit gezeigt, dass eine Verschmelzung von zwei Regionen, die durch die ersten 6 Momente repräsentiert werden, in konstanter Zeit umsetzbar ist.

2.1.3 Zusammenfassung

Erster Schritt für Objekterkennung im Bild ist die Segmentierung des Ausgansmate- rials. Dabei gibt es unterschiedliche Ansätze, bei denen vor allem Farbbasierte Seg- mentierungen eine hohe Objekterkennungsrate für unser Einsatzgebiet versprechen.

Das liegt an der Stabilität von Farben gegenüber geometrischer Transformationen.

Bei farblichen Segmentierungen muss bei der Segmentierung auf eine Repräsenta- tion geachtet werden, die die nachfolgenden Schritte möglichst ezient gestaltet.

Dabei zeichnet sich vor allem die Repräsentation durch statistische Momente aus, bei der eine Region anhand von 6 Momenten insofern ausreichend Beschrieben werden kann, dass alle für die Objekterkennung notwendigen Eigenschaften schnell aus

(26)

2 Grundlagen

diesen Momenten berechnet werden können. Zudem Lassen sich zwei Regionen in konstanter Zeit verschmelzen. Die Repräsentation einer Region durch statistische Momente lässt sich als Reduktion der Region auf eine Ellipse veranschaulichen.

2.2 Objekterkennung anhand einer Segmentierung

Die farblichen Eigenschaften eines Bildes lassen sich durch Histogramme genau Beschreiben. Darauf aufbauend kann sie Qualität eines Bildes und eine eingeschränk- te Segmentierung durchgeführt werden. Wie Cheng beschreibt, sind Histogramme aber nicht ausreichend, Objekte in einem Bild zu erkennen: Das Farbspiel eines Bildes kann zwar durch Histogramme beschrieben werden, nicht aber die genaue Positionierung der farbliche Regionen. Der von Cheng beschriebene Color Region Adjanency Graph, CRAG, löst dieses Problem, indem aufbauend auf eine Seg- mentierung ein Graph aufgespannt wird, mit dem Objekte bestehend aus mehreren Regionen erkannt werden können. CRAG ist ein Graph, deniert durch die 5-Tupel

CRAG= (V, E, V C, V S, ER)

V sei die Menge der Knoten des Graphen, wobei jeder Knoten einer Region der Seg- mentierung entspricht. E ist die Menge der Kanten, beschreibt also, welche Regionen direkt aneinander liegen. Mit VC werden die Farblichen Eigenschaften in Form von Farb-Histogrammen und mit VS die Masse der einzelnen Regionen beschrieben. Die farbliche Abweichung zweier angrenzender Regionen werden in ER fest gehalten.

2.2.1 Attribute von CRAG; Color Region Adjacency Graph

Die Kerneigenschaften V, E und VC sind laut Cheng ausreichend, um Objekte bei bekannter und gleichbleibender Entfernung, Winkel und Lichtverhältnissen zu erkennen. Objekte, die aus mehreren Regionen bestehen, werden aber bereits bei kleinen Winkel und Entfernungsabweichungen so stark verfälscht, dass eine Erken- nung nicht möglich ist. Vs wird dabei verwendet, um die Gröÿe nahestehender Regio- nen zueinander in Relation zu setzen. Dadurch lassen sich Neigung und Entfernung eines Objektes herausrechnen und dieses erkennen. Ähnlich verhält es sich mit einer Änderung der Lichtverhältnisse. Cheng weiÿt darauf hin, dass benachbarte Pixel, und in dem Sinne auch benachbarte Regionen, einer Oberäche, invariant auf sich ändernde Lichtverhältnisse sind. Daher Lassen sich Regionen mittels ER in Rela- tion zueinander setzen und gruppieren. Als weitere Möglichkeit lässt sich anhand einer Orientierungsäche berechnen, inwieweit die gegebenen Lichtverhältnissen von den Ausgangsverhältnissen abweichen und die Farbhistogramme der Regionen dem entsprechend korrigieren.

18

(27)

2.2 Objekterkennung anhand einer Segmentierung

Abbildung 2.9: Beispiel eines Ajdazenten Graphen; a) Veranschaulichung von CRAG: Knoten repräsentieren Regionen, benachbarte

Regionen werden durch Kanten verbunden. b) Ausgangsbild b) Segmentierung c)

Resultierender CRAG

2.2.2 Objekterkennung mit CRAG

Cheng weiÿt explizit darauf hin, dass ein 2D Objekt durch Rotation und Skalierung zwar seine Form verändert, nicht aber die Grundsätzlichen Eigenschaften der Ober- äche. Somit lässt sich ein Objekt durch einen einzelnen CRAG darstellen. Prinzip- iell lässt sich ein 3D Objekt auch durch einen CRAG darstellen, dieser setzt sich dabei aus den CRAG's des Objektes aus unterschiedlichen Blickwinkeln zusammen.

Die Suche eines Objektes in einem Bild gestaltet sich dann ähnlich einem Wachstum- sprozess. Zu Beginn wird eine Region, ein Knoten im im CRAG des Bildes, gewählt, der Teil eines Objektes sein kann. Um diesen wird ein anfänglich kleines Betrach- tungsfenster erstellt und ein Graph aufgebaut. Mit der Ausgangsregion verbundene Regionen werden auf mögliche Zugehörigkeit zu dem Objekt überprüft, ggf. dem Graphen hinzugefügt und das Betrachtungsfenster entsprechend vergröÿert. Lassen sich keine an den Graphen angrenzende Regionen mehr dem Graphen hinzufügen, ist der Algorithmus beendet und der Graph kann als CRAG des Objektes identiziert werden oder es handelt sich nicht um das gesuchte Objekt.

Cheng weiÿt darauf hin, dass diese Art der Objekterkennung bei einer Versuchsrei- he eine korrekte Erkennung von 95,6% und eine Fehlerkennung von lediglich 4,6%

aufweisen kann (Cheng[5], S.93). Eine Sehr detaillierte übersicht der Relations- und

(28)

2 Grundlagen

Abbildung 2.10: Ablauf der Objekterkennung mit CRAG; a) Eine Region wird als Ausgangsregion markiert und von einem Betrachtungsfenster umgeben. b) Die Anliegenden Regionen werden ausgewertet und das

Betrachtungsfenster entsprechend vergröÿert.

c) Der Graph wächst weiter. d) Sobald das Betrachtungsfenster nicht mehr vergröÿert werden muss, ist der Algorithmus beendet.

Transformationsformeln von CRAG können in der Veröntlichung von Cheng[5] S.

75 - 96 nachgeschlagen werden.

2.3 Die Entwicklungsumgebung

Als Hardwareumgebung wird auf das Samsung Galaxy SII LTE zurück gegrien. Es läuft mit Android 4.0.4 und bietet wie jedes Smartphone die notwendige Kamera- Unterstützung. Die im Laufe dieser Ausarbeitung erstellte Software sollte nach ihrer Fertigstellung von jedem Gerät unterstützt werden, auf dem Android ab Version 2.3.3 installiert ist und das eine Kamera besitzt. Im folgenden wird auf die Kong- uration des Betriebssystems Android und die Entwicklungsumgebung für Android eingegangen und berücksichtigt die Texte von Ableson[1], Darwin[6], Laganiere[10]

and Bradski[2].

2.3.1 Android - Konguration

Ein von Haus mit Android laufendes System benötigt keine aufwändige, spezielle Konguration. Software wird bei Android in Form sogenannter App's über die android-interne Softwareverwaltung 'Play Store' installiert. Für das Installieren eigener Software muss in den Einstellungen unter Anwendungen das Installieren von unbekannten Quellen erlaubt werden. Anschlieÿend kann jede App als '*.apk'

20

(29)

2.3 Die Entwicklungsumgebung über einen beliebigen Datei- Explorer installiert werden. Für die Verwendung von Android mit Teilen der Softwareerweiterung OpenCV wird die App 'OpenCV Man- ager' benötigt, welche über den 'Play Store' bezogen werden kann. Abbildung 2.11 veranschaulicht, wie der OpenCV Manager von anderen App's verwendet wird, die auf die OpenCV-Bibliothek zugreifen.

Abbildung 2.11: Zusammenspiel von OpenCV-App's und dem OpenCV Manager

2.3.2 Android - Programiersprache

Android ist ein auf Linux basierendes Betriebssystem, das sich allerdings in einigen wesentlichen Punkten von jeder Linux Distribution unterscheidet. Es wird stetig weiterentwickelt und neue Android-Versionen veröentlicht. Dabei ist Android ab- wärtskompatibel; eine App, die mit einer niedrigeren SDK-Version erstellt wurde, ist auch auf einem Gerät mit höherer Android- Version voll funktionsfähig.

Obwohl Android auf dem Linux Kernel 2.6 und später auch 3.x und somit auf der Programmiersprache C aufbaut, ist die für Linux übliche Ausführung von C- Code nicht möglich. Die direkte Ausführung von normalem Java-Code ist also nicht möglich. Abbildung 2.12verdeutlicht den untypischen Aufbau der Android- Distri- bution.

Durch diesen Aufbau gestaltet sich die Entwicklung für Android nicht so intuitiv wie für andere Betriebssysteme. Um dem entgegen zu wirken bietet Google spezielle

(30)

2 Grundlagen

Abbildung 2.12: Aufbau des Android Systemes

Bibliotheken, mit denen groÿe Teile des Softwaregerüstes vorgegeben werden.

Die Java-Bibliotheken, mit denen die Java-App's für Android entwickelt werden können, heiÿen SDK. Von der GUI-Schnittstelle bis zur Umsetzung der Software in Aktivitäten wird alles von der SDK bereitgestellt. Da es bei Java 7 zu Versionskon- ikten mit niedrigen Android SDK Versionen kommen kann, wird in dieser Arbeit Java Version 6 benutzt, um möglichst viele Android-Systeme ansprechen zu kön- nen.Eine direkte Unterstützung von C-Code ist bei Android nicht vorgesehen. Über die von Google bereitgestellten NDK Bibliothek kann C-Code in Android App's eingebettet werden. Dabei erzeugt die NDK aus dem C-Code eine dynamische Bib- liothek, welche dann zur Laufzeit von einer Java-App geladen und benutzt werden kann. Abbildung 2.13zeigt grob die Bibliotheks-Referenzierung einer Android App zum normalen Java-Code und dem C-Code. Als Schnittstelle dient das Java Native Interface, JNI.

22

(31)

2.3 Die Entwicklungsumgebung

Abbildung 2.13: Referenzierung von Java- und C-Code einer Android App

2.3.3 Adnroid - Entwicklungsumgebung

Als Entwicklungsumgebung wird die ADT-Version von Eclipse verwendet. Allge- mein bietet Eclipse eine übersichtliche Oberäche und gute Dokumentation zum Arbeiten mit Android und OpenCV. In der ADT-Version von Eclipse sind bereits die benötigten SDK und NDK PlugIns integriert. Das Compilieren aus einem Ter- minal heraus ist zwar grundlegend möglich, da Google alle notwendigen Tools in der Android SDK mitliefert, gestaltet sich aber durch die sehr genauen Vorgaben von der Erstellung eines Projektes über die Verlinkung bis zur tatsächlichen Kom- pilierung nicht praktikabel.

Für die Implementierung der Zielsetzung in dieser Ausarbeitung wird OpenCV benutzt, eine Bibliothek, die diverse Funktionen zur Bearbeitung von Bildmaterial beinhaltet. Für diese Ausarbeitung ausschlaggebend ist das Abgreifen der Bilder einer Kamera und unterschiedliche Implementationen für die Segmentierung und Objekterkennung in Bildern. Für Android bietet OpenCV eine eigene Bibliothek, die manuell compiliert und mit dem eigentlichen Projekt verknüpft wird. Dadurch erhält man die volle Funktionalität von OpenCV für die Android-Umgebung.

2.3.3.1 Konguration der Entwicklungsumgebung

Grundsätzlich unterscheidet sich die Konguration der Entwicklungsumgebung unter Windows nicht besonders von der unter Linux. Der einzige Unterschied besteht im Setzen des richtigen Java Build Path unter Windows, was unter Linux nicht notwendig ist. Zur Evaluierung auf einem realem Gerät müssen auf Windows lediglich die entsprechenden Treiber installiert werden.

Mithilfe des ADT-Internen SDK-Manager lassen sich die gewünschten SDK- Versionen beziehen, mit denen die Software implementiert werden soll. Für die Verwendung von OpenCV wird die SDK Android 4.2 (API 17) benötigt. Für die eigentliche implementation wird in dieser Ausarbeitung auf Android 2.3.3 (API 10)

(32)

2 Grundlagen

zurückgegrien, um möglichst viele Android Geräte anzusprechen. Zudem werden die Android Tools benötigt. Anschlieÿend werden die Verlinkungen in Eclipse richtig gesetzt. Die allgemeinen Einstellungen werden in den 'Window/Preferences' vorgenommen. Unter Android sollte bei SDK Location der absolute Pfad zur An- droid SDK eingetragen sein. In diesem Fall '$(ADT Bundle)/sdk'. Darunter werden alle installierten Android Versionen aufgeführt. Unter 'Android/NDK' muss der Pfad zur Android NDK angegeben werden, also '$(ADT Bundle)/android-ndk-r8d'.

Zusätzlich wird unter 'Java/Compiler' als Compiler compliance level Version 1.6 ausgewählt.

2.3.4 Das Android Projekt

Google schreibt für Android App's in der Entwicklung einen genau denierten Projekt-Aufbau vor. Ohne diesen lässt sich ein App nicht kompilieren. Dabei hebt sich vor allem die strikte Trennung zwischen den funktionalen und visuellen Kom- ponenten: Die funktionalen Komponenten werden in Java Quellcode programmiert, während die visuelle Darstellung der App in der Extensible Markup Language, XML, beschrieben wird.

Im Kern jedes Android Programmes bendet sich eine Activity. Alle visuellen Eingaben und Ausgaben werden von einer Activity aufgenommen und verarbeitet.

Während ein Programm auf einem Android System abläuft, kann es weitere Activi- ties starten und beenden, wobei sie die in Abbildung2.14unterschiedliche Zustände durchlaufen. Zu jedem Android-Projekt gehört die Datei AndroidManifest.xml.

Ohne diese Datei kann kein Android-Projekt compiliert werden. Ihre wichtigsten Inhalte sind die verwendete Android API Version, eine Auistung aller enthaltenen Aktivitäten sowie eine Liste aller benötigten Berechtigungen, die die generierte App benötigen soll (z.B. Speicher-, Kamera- oder Internetzugri).

Die Java Ressourcen liegen wie bei anderen Programmiersprachen im Ordner src. Hier benden sich alle Aktivitäten. Der src Ordner enthält nur Java-Code, eingebetteter C-Code muss in einem gesonderten Ordner abgelegt werden, da Eclipse automatisch versucht, alle Dateien in diesem Ordner als Java-Code zu interpretieren.

Im Ordner res benden sich alle Oberächen-bezogenen Dateien. Im Unterordner Layout werden in Form von .xml Dateien alle Oberächen beschrieben. Eclipse bietet dabei eine Live Ansichts- und Bearbeitungsmöglichkeit. Die Oberächen kön- nen per Baukastenprinzip zusammengebaut oder direkt im xml-Format beschrieben werden. Hierbei ist zu beachten, dass alle Formen von Variablen, Strings, Integer etc., nicht direkt gesetzt werden können, sondern für jede Variable im Unterordner values ein Eintrag in der string.xml erzeugt und diese verlinkt wird.

24

(33)

2.3 Die Entwicklungsumgebung

Abbildung 2.14: Vereinfachte Darstellung der Zustände einer Activity

2.3.4.1 C-Code einbetten

Per Rechtsklick auf dem Projekt und 'Android Tools/Add Native Support' wird die Unterstützung für C-Code im Projekt hinzufügt. Der C-Code wird als .so Bibliothek eingebettet. Der gesamte C-Code muss im Ordner JNI abgelegt und alle weiteren Ordner in den Einstellungen den C/C++ Ressourcen hinzugefügt werden.

Die im C-Code verwendeten Bibliotheken werden in der Datei Android.mk verlinkt und für die Unterstützung von OpenCV werden sowohl die OpenCV.mk als auch die nativen Bibliotheken von OpenCV eingebunden. LOCAL_ MODULE beschreibt den Namen der Bibliothek und unter LOCAL_ SRC_ FILES werden alle zur Bib- liothek gehörenden Source Dateien aufgelistet.

Beispiel einer Android.mk Datei:

LOCAL_PATH := \$(call my-dir)

OPENCV_PATH := /home/user/adtbundle/

OpenCV-2.4.3-android-sdk/sdk/native/jni

(34)

2 Grundlagen

NDK_PATH := /home/user/adtbundle/

android-ndk-r8d/sources/cxx-stl/gnu-libstdc++/4.6 include \$(CLEAR_VARS)

include \$(OPENCV_PATH)/OpenCV.mk LOCAL_MODULE := BA-Segmentation LOCAL_SRC_FILES := BA-Segmentation.cpp LOCAL_C_INCLUDES += \$(NDK_PATH)/include

LOCAL_C_INCLUDES += \$(NDK_PATH)/libs/armeabi-v7a/include LOCAL_C_INCLUDES += \$(OPENCV_PATH)/include

include \$(BUILD_SHARED_LIBRARY)

Im Java-Code werden die in C-Code geschriebenen Funktionen zur Laufzeit über die JNI-Schnittstelle angesprochen.

2.3.4.2 OpenCV vorbereiten

Damit OpenCV in einem Projekt verwendet werden kann, muss zuvor das Projekt 'OpenCV Library - 2.4.3' aus den OpenCV examples importiert werden und in den Projekteigenschaften des eigentlichen Projektes unter Android - Reference als Library angegeben werden. Das 'OpenCV Library - 2.4.3' Projekt muss dabei vollständig compiliert werden und in seinen Projekteigenschaften unter Android Reference als Is Library markiert sein. 'OpenCV Library - 2.4.3' kann nur kompiliert werden, wenn als Java Compiler mindestens Java 1.6 ausgewählt ist.

2.3.5 Zusammenfassung

Als Softwareumgebung wird Eclipse mit SDK und NDK PlugIns sowie der 'OpenCV für Android'-Bibliothek verwendet. Im Vorfeld müssen die SDK und NKD in den allgemeinen Eclipse-Eigenschaften richtig verlinkt und Java 1.6 ausgewählt werden.

Jedes Projekt lässt sich über die Android Tools per Rechtsklick C-Code tauglich machen. Dieser bendet sich im Unterordner JNI, wird als .so Bibliothek compiliert und mittels JNI Schnittstelle dem Java-Code zugänglich gemacht. Das OpenCV Library Projekt muss geönet und jedem Projekt als Bibliothek zugeordnet werden, damit diese OpenCV nutzen können. Alle benötigten Header-Ordner für den C-Code können in der Android.mk im JNI Ordner eingebunden werden. Anschlieÿend kann die generierte C-Code Bibliothek im Java-Code geladen und benutzt werden.

26

(35)

Literaturverzeichnis

[1] W. Frank Ableson, Robi Sen, and Chris King. Android in action. Manning Pubs Co Series. Manning Publications Company, 2011.

[2] Gary Bradski and Adrian Kaehler. Learning OpenCV: Computer Vision with the OpenCV Library. O'Reilly Media, 2008.

[3] James Bruce, Tucker Balch, and Manuela Veloso. Fast and inexpensive color image segmentation for interactive robots. In Proceedings of the 2000 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS '00), volume 3, pages 2061 2066, October 2000.

[4] Wilhelm Burger and Mark J. Burge. Principles of Digital Image Processing:

Core Algorithms. Undergraduate topics in computer science. Springer, 2009.

[5] Jian Cheng. Color-based Object Detection and Positioning. Logos Verlag Berlin, 2003.

[6] I.F. Darwin. Android Cookbook. O'Reilly Media, 2012.

[7] Stefan Herbrechtsmeier, Ulf Witkowski, and Ulrich Rückert. Bebot: A mod- ular mobile miniature robot platform supporting hardware reconguration and multi-standard communication. In Progress in Robotics, Communications in Computer and Information Science. Proceedings of the FIRA RoboWorld Congress 2009, volume 44, pages 346356, Incheon, Korea, 2009. Springer.

[8] Bernd Jähne. Digitale Bildverarbeitung. Springer, 2005.

[9] Alexander Jungmann. Objekterkennung durch bewegungsanalyse von bild- merkmalen.

[10] Robert Laganiere. Opencv 2 Computer Vision Application Programming Cook- book. Packt Publishing, Limited, 2011.

[11] Theodosios Pavlidis. Algorithms for gracs and image processing. Springer, 1982.

[12] Dirk Stichling. VisiTrack - Inkrementelles Kameratracking für mobiele Echtzeit- systeme. Shaker, 2004.

[13] Satoshi Suzuki and Keiichi Abe. Topological structural analysis of digitized binary images by border following. CVGIP, 30(1):3246, April 1985.