Diplomarbeit. Bereitstellung kamerabasierter Eingabemethoden zur Nutzung in Adobe Flash Lite Anwendungen. Frank Ließner Matrikelnummer

Transkript

1 Diplomarbeit Bereitstellung kamerabasierter Eingabemethoden zur Nutzung in Adobe Flash Lite Anwendungen Frank Ließner Matrikelnummer Unter Betreuung von TU Dresden Fakultät Informatik Institut für Software- und Multimediatechnik Lehrstuhl für Mediengestaltung Hochschullehrer: Prof. Dr.-Ing. habil. R. Groh Betreuerin: Dipl.-Des. Anne Recknagel argonauten G2 GmbH Agentur für vernetzte Markeninteraktion Standort Berlin Betreuer: Stephan Lempert Betreuer (Konzept): Rolf Piechura

2 2

3 Selbstständigkeitserklärung Hiermit erkläre ich, dass ich diese Diplomarbeit selbstständig verfasst und keine anderen, als die angegebenen Quellen und Hilfsmittel benutzt habe. Alle Stellen der Arbeit, die wörtlich oder sinngemäß aus Veröffentlichungen oder aus anderweitigen fremden Äußerungen entnommen wurden, sind als solche kenntlich gemacht. Ferner erkläre ich, dass die Arbeit noch nicht in einem anderen Studiengang als Prüfungsleistung verwendet wurde. Frank Ließner Berlin, 28. Februar

4 4

5 1 Inhaltsverzeichnis 1 Inhaltsverzeichnis Einleitung Zielsetzung Struktur Anforderungen an den Leser Theoretischer Teil Verwandte Literatur Mobile Camera-Based User Interaction Foundation Flash Applications for Mobile Devices Forum Nokia Symbian Adobe Mobiltelefone Betriebssysteme für Mobiltelefone Programmiersprachen und Entwicklungsumgebungen für Mobiltelefone Kommunikation zwischen Flash Lite und anderen Programmiersprachen Bewegungserkennung in Bildersequenzen Optimieren der Bildsequenz Motion History Images Ecken und Kanten Template Matching Richtungserkennung Nokia CV Bibliothek Beispielanwendungen Bewegungserkennung durch Sensoren Theoretisches Verfahren Beispielanwendungen Theoretischer Aufbau Struktur Installation und Start der Anwendung Entwicklungsablauf Nutzen und Einsatz kamerabasierter Eingabe Praktischer Teil Entwicklungsumgebung Symbian Signed Programmierte Struktur Bilderkennung

6 Socket Server Flash Lite API Flash Lite Anwendung Installation auf dem Endgerät Starten der Anwendung Leistungsfähigkeit Systemvoraussetzungen Beispielanwendungen Testanwendung Schneekugel Landkarte Spiele Handymenü Blogreader Evaluierung der Beispielanwendungen Testdurchführung Testergebnisse Auswertung Optimierungsansätze Zusammenfassung Resultate Schlussfolgerung Ausblick Anhang...71 I. Schritt für Schritt Anleitung II. Fragebogen zur Evaluation III. Quellcode a. b. Bewegungserkennung der Symbian C++ Anwendung (MotionServerAppView.cpp)80 Socket Server der Symbian C++ Anwendung (SocketServer.cpp) c. Flash Lite Testanwendung (MotionDetectionTest.as) IV. Literaturverzeichnis V. Abbildungsverzeichnis VI. Glossar VII. Stichwortverzeichnis VIII. Inhalt der DVD

7 7

8 8

9 2 Einleitung Durch eine Verbreitung von 98% (vgl.[adobe Player 08]) ist der Adobe Flash Player zum defacto Standard bei interaktiven Webanwendungen geworden. Mit dessen mobiler Version, Adobe Flash Lite, wird nun auch der Markt der mobilen Endgeräte erobert. Zum aktuellen Zeitpunkt gibt es schon über 300 Millionen Flash Lite fähige Mobiltelefone weltweit und laut Adobe ist die Tendenz steigend: With over 300 Million Flash enabled mobile devices and handsets shipped so far, Adobe expects more than one billion Flash enabled devices to be available by 2010, [Adobe Presse 07]. Wie die Statistik im Jahr 2007 aussieht und sich laut [Strategy Analytics 08] schätzungsweise im Jahr 2008 entwickeln wird, zeigt ein Ausschnitt in Abbildung 1. Diese besagt, dass es im Jahr 2007 speziell in Deutschland Flash Lite fähige Endgeräte gab und diese Zahl 2008 auf steigen wird. Doch auch mit diesen, aus dem World Wide Web bekannten, Techniken bleiben Handys in ihren Fähigkeiten beschränkt. Der Grund dafür ist laut [Andriessen et al. 06]: When mobile devices are to be carried, the device itself has to be small and easy to transport. These basic requirements affects its overall performance to a large extend. So sind die Limitierungen erkennbar in der Netzwerkgeschwindigkeit, CPU, Speicher, Batterie, Netzwerkzugriff und der Bildschirmgröße (vgl. [Andriessen et al. 06]). Bei der Eingabe beschreibt [Andriessen et al. 06] weiter, wurden neue Möglichkeiten zur Interaktion entwickelt. Die am häufigsten Genutzten sind dabei die Eingabe per Stift oder Tastatur, die mit Ziffern und gleichzeitig 3-4 Buchstaben belegt sind. Abhängig von der Hardware gibt es auch noch spezielle Tasten für beispielsweise den Internet Browser oder der Kameraanwendung. Stellenweise gibt es auch verkleinerte Quertz Tastaturen, die genutzt werden können. Zudem haben Forscher taktile Interaktionsoberflächen demonstriert und eine Sprachsteuerung wird auch vereinzelt genutzt. Aus diesem Grund schreibt [Andriessen et al. 06] weiter: As Input of information in mobile devices turns out to be complicated and slow, design should try to minimize the need for data and text input. Genau an der besagten Stelle wird diese Arbeit anknüpfen. Mit Hilfe von Flash Lite soll Entwicklern die Möglichkeit gegeben werden, Anwendungen zu erstellen, die sich mit Hilfe einer, in das Mobiltelefon eingebauten, Kamera bedienen lassen. Durch einfaches Bewegen, Drehen oder Schütteln der Geräte werden so Befehle an die jeweilige Anwendung weitergeleitet und dort individuell verarbeitet. Somit wird den Nutzern eine andere Art der Eingabe gegeben. 2.1 Zielsetzung Den Schwerpunkt dieser Arbeit bildet die Entwicklung einer Schnittstelle zwischen Hardware und Flash Lite Anwendung. Die Schwierigkeit liegt dabei in der Sandbox, dem Sicherheitsmodell, das den Flash Lite Player umgibt. Diese stellt sicher, dass die Anwendungen aus Sicherheitsgründen nicht auf die Hardware oder lokale Dateien zugreifen dürfen. Dementsprechend ist es zurzeit nur durch Umwege möglich, Daten von der Kamera zu verarbeiten. Es muss dennoch ein Weg gefunden werden, mit der Kamera zu kommunizieren, ohne das Sicherheitsmodell der Sandbox zu verletzen. Wenn diese Schwierigkeit einmal überwunden ist, wird die entsprechende Anbindung in einer Schnittstelle gekapselt. Dadurch ist es möglich, kamerabasierte Anwendungen einfacher zu erstellen. Die Arbeit wird dabei nur beiläufig auf die Verfolgung von Markern oder Objekten in Videos, beziehungsweise Gesten in Bildsequenzen, eingehen. Der Hauptteil liegt in der Verarbeitung von Realbildersequenzen und einer daraus berechneten Bewegung. Im Schlussteil dieser Arbeit werden einige Anwendungen erstellt, die auf dem entwickelten Framework aufbauen und bezüglich ihrer Anwendbarkeit getestet werden. Diese Ergebnisse können einen wesentlichen Beitrag zur Entwicklung von Flash Lite Anwendungen leisten, welche hardwareseitige Funktionen nutzen und mit anderen Programmiersprachen kommunizieren. Zusätzlich entstehen neue Erkenntnisse über alternative Benutzereingaben, die über das herkömmliche Nutzen von Tastaturen, Maus oder Stifteingaben hinausgehen. 9

10 2.2 Struktur Zu Beginn werden grundlegende Techniken und Methoden für die Bewegungserkennung und der Kommunikation zwischen Hardware und Flash Lite betrachtet und bezüglich ihrer Nutzbarkeit für dieses Projekt bewertet. Nachdem die entsprechenden Basistechniken ausgewählt wurden, beginnt die Strukturierung und Umsetzung des Projektes. Es werden dabei an einigen Stellen Optimierungen diskutiert und Vorschläge für weitere Entwicklungen erarbeitet. Im Anschluss an die theoretischen Betrachtungen beginnt die Entwicklung des Programmcodes. Nach dessen Fertigstellung werden anschließend einige Beispielanwendungen entwickelt. Mit Hilfe einer Anleitung wird es anderen Entwick-lern ermöglicht, ohne größere Vorkennt-nisse, kamerabasierte Flash Lite Anwendung-en für Mobiltelefone zu entwickeln. Dabei wird Wert darauf gelegt, dass die Entwickler nur den Flash Lite Teil bearbeiten müssen. Die entstandenen Anwendungen werden durch verschiedene Testpersonen evaluiert. Diese Ergebnisse geben abschließend einen kleinen Überblick über die Nutzbarkeit einer kamerabasierten Eingabe in Flash Lite. Im Anhang dieser Arbeit befinden sich das Literaturverzeichnis für die hier genutzten Quellen, ein Abbildungsverzeichnis, ein Glossar und ein Stichwortverzeichnis. 2.3 Anforderungen an den Leser Für das Lesen dieser Arbeit werden Grundkenntnisse in der Programmierung, in Adobe Flash und in der englischen Sprache vorausgesetzt. Sollten dennoch einige Begriffe unklar sein, gibt es am Ende dieser Arbeit noch einen Glossar, in dem Abkürzungen beziehungsweise Fachbegriffe näher erklärt werden. Abbildung 1: Flash Lite Verteilung in West Europa (vgl. [Strategy Analytics 08]) 10

11 3 Theoretischer Teil Das Ziel dieses theoretischen Teils ist es, eine grundlegende wissenschaftliche Basis zu schaffen, auf die später im praktischen Teil aufgebaut werden kann. Dazu gehören die für diese Diplomarbeit wichtige Literatur, Grundlagen von Mobiltelefonen, entsprechende Programmiersprachen und Grundlagen zur Erkennung von Bewegungen in Bildsequenzen. Abschließend wird ein theoretischer Aufbau für die zu entwickelnde Anwendung erstellt, der die Grundlage für die praktische Umsetzung darstellen wird. 3.1 Verwandte Literatur Um das Thema der mobilen Endgeräte existieren nur wenige gedruckte Werke, da dieser Bereich sehr jung und in einer starken Entwicklungsphase ist. Diese Werke würden somit sehr schnell veralten. Doch andererseits gibt es viele Schriftstücke in digitaler Form, die schneller angepasst und somit aktueller gehalten werden können. Eine große Unterstützung und viele relevante Dokumente bieten beispielsweise Firmen, die Mobiltelefone, beziehungsweise die entsprechenden Techniken zur Verfügung stellen (zum Beispiel Nokia, Symbian oder Adobe). Die wichtigsten Schriftstücke werden im Folgenden kurz zusammengefasst Mobile Camera-Based User Interaction Als erstes Werk soll an dieser Stelle Mobile Camera-Based User Interaction (vgl. [Haro et al. Okt 05]) erwähnt werden, welches eine große Inspiration und Grundlage für diese Diplomarbeit ist. Darin wird die Realisierung einer kameragestützten Benutzereingabe behandelt. Genau wie in dieser Diplomarbeit wird dabei ein sehr verbreitetes Betriebssystem für Mobiltelefone genutzt, das Symbian S60. Für die Entwicklung der Beispielanwendungen wird dabei die Programmiersprache Symbian C++ eingesetzt. Diese ist die native Programmiersprache für Symbian S60 Mobiltelefone. Dieses Werk entstand mit Unterstützung von Nokia. Auf diese Firma wird später noch einmal eingegangen. Mobile Camera-Based User Interaction (vgl. [Haro et al. Okt 05]) beschreibt die Herangehensweise an das Thema der Bild- und Bewegungserkennung und gibt dafür Beispiele zur Berechnung. Dabei wird die Nutzung von Filtern und anderen Optimierungen beschrieben. Als praktische Arbeit wurden zum Schluss einzelne Beispielanwendungen entwickelt, um die Funktion der kamerabasierten Benutzereingabe zu simulieren Foundation Flash Applications for Mobile Devices Das nächste Werk Foundation Flash Applications for Mobile Devices (vgl. [Legget et al. 06]) ist vor allem im Hinblick auf Adobe Flash Lite interessant. Es bietet einen sehr guten Überblick über den aktuellen Stand von Flash Lite bis zur Version 2.1 des Players. Das Buch beginnt mit einem Überblick zum Thema mobiler Endgeräte und beschreibt die Erstellung einer einfachen Flash Lite Anwendung. Im zweiten Teil gehen die Autoren etwas mehr ins Detail und spezialisieren sich auf die Entwicklung und Besonderheiten von Anwendungen und Spielen. Im Anschluss wird die Verwendung von Video und Sound beschrieben und durch Beispiele veranschaulicht. Am Ende dieses Kapitels wird auf die Erweiterbarkeit von Flash Lite eingegangen, die besonders im Kontext dieser Diplomarbeit interessant ist. Denn dort werden mögliche Szenarien für die Kommunikation mit der Hardware des Mobiltelefons aufgezeigt. Im letzten Teil wird beschrieben, wie die erstellten Anwendungen für andere Nutzer am Besten zugänglich gemacht werden können. Gefolgt von einem Ausblick in die zukünftige Entwicklung von Flash Lite. Das Buch bietet einen sehr guten Einstieg in das Thema Flash Lite und stellt gleichzeitig Informationen für fortgeschrittenere Entwickler zur Verfügung. 11

12 3.1.3 Forum Nokia Im Bereich Mobilität ist Nokia das weltweit führende Unternehmen und leistet einen entscheidenden Beitrag zur Gestaltung und zum Wachstum der konvergierenden Internetund Kommunikationsbranche, [Nokia 07]. Ein Großteil der Nokiageräte basiert auf dem Betriebssystem Symbian, was kein Wunder ist, da Nokia mit 47,9% (vgl. [Symbian Teilhaber 08]) der größte Teilhaber an Symbian ist. Die genaue Aufteilung der Anteile ist in Abbildung 2 zu sehen. Abbildung 2: Anteile der einzelnen Unternehmen an Symbian (vgl. [Symbian Teilhaber 08]) Für Entwickler stellt Nokia eine gute Unterstützung bereit und bietet mit dem Forum Nokia (vgl. [Forum Nokia 08]) eine Plattform für die Entwicklung mobiler Anwendungen auf diesen Geräten. In diesem Forum werden Artikel zu verschiedenen Themen der Entwicklung, Beispielprogrammcodes, Tools und weitere themenbezogene Dinge angeboten. In dem Forum wurde zudem ein spezielles Flash Lite Unterforum eingeführt, welches sich mit dem Zusammenspiel von Nokia Telefonen und Flash Lite beschäftigt. Zudem bietet Nokia die Software Carbid C++ an (vgl. [Carbid 08]), die für das Programmieren von Symbian C++ Programmen genutzt werden kann Symbian Symbian entwickelt ein Betriebssystem für Mobiltelefone und lizenziert es an andere Hersteller. Auf dem Entwicklerportal von Symbian (vgl. [Symbian Developer 07]) finden sich vor allem Informationen über Symbian C++, die native Programmiersprache für Symbian Mobiltelefone. Zudem gibt es Literatur für Einsteiger und Fortgeschrittene, Beispielprogramme, Richtlinien, Empfehlungen für Entwicklungsumgebungen und andere themenbezogene Informationen. Durch Links können weitere Informationen von themenverwandten Seiten abgerufen werden. Wenn es um eine hardwarenahe Programmierung auf Symbian Mobiltelefonen geht, sollte diese Seite die erste Anlaufstelle sein. Einige Links des Portals führen auch auf die schon genannten Forum Nokia Seiten (vgl. [Forum Nokia 08]) und zeigen damit die enge Verknüpfung. 12

13 3.1.5 Adobe Auf der Internetseite von Adobe (vgl. [Adobe 08]) gibt es vor allem Informationen und weiterführende Links zu Flash Lite. Für die Entwickler wird eine Liste mit allen unterstützten Mobilgeräten und der aktuelle Flash Lite Player angeboten. Zudem gibt es auch Informationen über die Verbreitung des Flash Lite Players auf mobilen Endgeräten, wobei diese nicht nur Telefone sind, sondern auch Spielekonsolen oder Settop Boxen. Im Kontext dieser Arbeit werden jedoch speziell nur Telefone betrachtet, da Spielekonsolen beziehungsweise Settop Boxen in der Hardware zu sehr von Telefonen abweichen und zudem selten eine Kamera beinhalten. Abseits von der offiziellen Adobe Seite gibt es noch weitere Portale, Blogs oder Foren, auf die verlinkt wird. Parallel dazu gibt es in der Adobe Anwendung Flash CS3 eine Dokumentation zu allen Flash bezogenen Themen. 3.2 Mobiltelefone Eine aktuelle Prognose von [Bitkom 07] zeigt: Die Zahl der Mobilfunk-Anschlüsse in Deutschland steigt weiter [...]. Die Prognose zeigt, dass sich bis 2009 die Zahl der Mobiltelefone auf 100 Einwohner, sogar bis auf 117 erhöhen wird. Es ist also ein stetiges Wachstum in diesem Bereich zu verzeichnen. Eine grafische Aufbereitung dieser Entwicklung wird in Abbildung 3 gezeigt.. Abbildung 3: Prognose über die Entwicklung der Anzahl von Mobiltelefonen pro 100 Einwohner (Bitkom; auf Basis von EITO vgl. [Bitkom 07]) Sehr viele Personen können durch mobile Anwendungen erreicht werden. Durch Flash Lite ist nun eine Möglichkeit entstanden, die doch sehr unterschiedlichen Endgeräte, mit einheitlichen Nutzerschnittstellen auszustatten. Um Anwendungen für Mobiltelefone zu entwickeln, sind Kenntnisse über die Geräte, inklusive ihrer Fähigkeiten nötig. Aufklärung darüber bringt der folgende Teil. Dieser gibt einen kleinen Überblick über Betriebssysteme, die auf Mobiltelefonen zum Einsatz kommen. Danach werden die verschiedenen Programmiersprachen vorgestellt, mit denen Entwickler Anwendungen für Mobiltelefone schreiben können. Zum Schluss wird auf einige Eigenheiten von Flash Lite eingegangen, die besonders im Zusammenhang mit dieser Diplomarbeit wichtig sind. 13

14 3.2.1 Betriebssysteme für Mobiltelefone Mobiltelefone sind in ihrer Leistungsfähigkeit im Gegensatz zu Desktopcomputer beschränkt, sei es die Prozessorleistung, die Eingabe von Daten, die Bildschirmgröße und natürlich die Abhängigkeit von einem Akku. Aus diesem Grund müssen speziell angepasste Betriebssysteme auf diesen Geräten zum Einsatz kommen. Das Nächstliegende ist ein Betriebssystem, wie es bei Desktopcomputern eingesetzt wird, zu reduzieren und anzupassen. So geschieht es bei Microsoft Windows mit der mobilen Version Windows Mobile, Apple setzt sein Betriebssystem MacOS X ebenfalls auf seinem selbstentwickelten iphone ein. Zudem gibt es aber auch speziell für Mobiltelefone entwickelte Systeme wie Symbian. Die Verteilung der Betriebssysteme auf Smartphones zeigt die Abbildung 4. Canalys worldwide total smartphone device market - market shares for Q / Q (Includes Linux 'closed' phones in Asia and excludes PDAs) OS vendor Q207(m) % market Q206(m) % market market share unit growth share share growth Q2 06/Q2 07 Q206/Q207 Symbian % Linux % Access % Microsoft % RIM % iphone Others % Total 26.0m 100.0% 18.1m 100.0% 43.3% Abbildung 4: Verteilung der einzelnen Betriebssysteme auf Smartphones (Quelle: Canalys vgl. [Symbian Facts 08] ) Symbian Wie in Abbildung 4 zu sehen ist, ist Symbian mit 72,4% Marktanteil (2. Quartal 2007, vgl. [Symbian Facts 08]) das am meisten verbreitete Betriebssystem für Mobiltelefone. Auf diesem können verschiedene Bedienoberflächen aufgesetzt werden. Beispiele dafür sind S40, S60 (siehe Abbildung 5), S80, S90 oder UIQ (siehe Abbildung 6). Wobei S40 für Telefone im Massenmarkt, S60 für Smartphones und S80 und S90 für PDAs genutzt werden. UIQ ist hingegen für Geräte mit Stifteingabe entwickelt worden. 14

15 Abbildung 5: Nokia N73 mit Symbian Betriebssystem und der Oberfläche S60 3rd Edition (Bildquelle: [Nokia Presse 08]) Abbildung 6: Sony Ericsson P1i mit Symbian Betriebssystem und UIQ Oberfläche, die speziell für die Stifteingabe aufbereitet wurde (Bildquelle: [Sony Ericsson 08]) Symbian bietet zudem die Möglichkeit, eigene Anwendungen signieren zu lassen. Das Verfahren nennt sich symbian signed. Es bietet den Nutzern die Sicherheit, dass auch hardwarenahe Anwendungen keinen Schaden am Telefon verursachen. Eine genaue Beschreibung dieser Signierungsmöglichkeiten wird in Abschnitt 4.2 erklärt Linux Auf der Basis von Linux entstehen auch im mobilen Bereich offene Betriebssysteme. Beispielsweise ist laut Pressemeldung von [OpenMoko Presse 07] das Neo1973: [...]a completely integrated open source mobile communications platform. Das Neo1973 ist in Abbildung 7 zu sehen. Für den Massenmarkt ist es laut der Pressemeldung aber noch nicht tauglich. Der in Abbildung 4 aufgeführte 13,3 prozentige Marktanteil, resultiert aus der Verwendung als Betriebssystem in PDAs. In Smartphones wird es eher weniger genutzt. 15

16 Windows Mobile Abbildung 7: NEO1973 mit OpenMoko Betriebssystem auf Linux Basis (Bildquelle: [OpenMoko Neo 07]) Microsoft bietet mit Windows Mobile eine reduzierte Version seines Betriebssystems für mobile Geräte an. Hauptsächlich liegt auch hier der Einsatzbereich bei PDAs, nur wenige Smartphones werden mit Windows Mobile ausgestattet. Ein Beispiel ist das HTC P4350 (siehe Abbildung 8). Die Stärken dieser Plattform liegen in mobilen Officeanwendungen und bringen aus diesem Grund immer eine Qwertz Tastatur mit. Ein weiterer Standard auf diesen Geräten ist der Windows Media Player, der auch auf Desktopcomputern eingesetzt wird. Abbildung 8: HTC P4350 mit dem Betriebssystem Windows Mobile 5.0. Die Eingabe kann über Funktionstasten, Qwertz Tastatur oder Stift erfolgen (Bildquelle: [HTC 08]) 16

17 Research In Motion (RIM) Research In Motion (RIM) is a leading designer, manufacturer and marketer of innovative wireless solutions for the worldwide mobile communications market. (vgl. [RIM 07]), so der Text der eigenen Firmenbeschreibung. RIM ist bei Mobiltelefonen vor allem durch die BlackBerry Plattform bekannt. Diese ist darauf spezialisiert, Push anzubieten. Das bedeutet, dass s, die auf dem Server ankommen, direkt an das BlackBerry Endgerät weitergeleitet (gepushed) werden, ohne dass das Endgerät eine Anfrage stellen musste. Es kommt dabei eine Client-Server Architektur zum Einsatz und ein eigenes BlackBerry Protokoll. Da die Endgeräte speziell für dienste ausgelegt sind, besitzen sie immer eine Qwertz Tastatur, um die Eingabe zu vereinfachen. Ein BlackBerry 8820 mit Qwertz Tastatur ist in Abbildung 9 zu sehen MacOS X Abbildung 9: RIM BlackBerry 8820 mit Qwertz Tastatur (Bildquelle: [RIM Photo 07]) Mit der Veröffentlichung des iphone (siehe Abbildung 10) hat Apple ein neues Betriebssystem für mobile Geräte ins Spiel gebracht. Auf diesem Telefon kommt eine reduzierte Variante des MacOS X Betriebssystems zum Einsatz. Dementsprechend hat Apple kurze Entwicklungszeiten und kann vorhandene Entwicklungen von Macintosh Rechnern, durch wenige Anpassungen direkt auf das Mobiltelefon bringen. Das iphone bietet jedoch bis jetzt keine Unterstützung von Flash Inhalten, dennoch ist für Ende Februar ein eigenes SDK (Software Development Kit) angekündigt, mit dem Entwickler eigene Anwendungen schreiben können (vgl. dazu [Fscklog 08]). 17

18 Abbildung 10: Apples iphone mit MacOS X Betriebssystem (Bildquelle: [Apple Bilder 08]) Android Google selbst beschreibt Android als: the first complete, open and free mobile platform (vgl. [Android 08]). Das Android Framework ist noch relativ neu und in der Entwicklung aber Entwicklern und Herstellern von Mobiltelefonen, wird schon die Möglichkeit gegeben, ein Android SDK herunter zu laden und damit Anwendungen zu entwickeln (vgl. [Android Erklärung 08]). Dieses Framework erlaubt es alle Teile der mobilen Plattform selbst anzupassen und wieder zu verwenden. Zu den Features (vgl. [Android Erklärung 08]) gehört unter anderem die Vorbereitung für Camera, GPS, compass, and accelerometer, welches gleichzeitig aber abhängig von der verwendeten Hardware ist. Diese Vorbereitung lässt auch hier Bewegungserkennung durch eine Kamera, beziehungsweise durch Bewegungssensoren, zu. Im Folgenden wird eine Grafik gezeigt, die den Aufbau des Frameworks etwas näher zeigt. Wichtig in Bezug auf dieses Kapitel, ist dabei vor allem der untere Teil, denn Android basiert auf der Plattform Linux. Somit wird also auch hier ein Betriebssystem aus dem Desktopbereich auf mobilen Endgeräten verwendet. 18

19 Abbildung 11: Android Framework (Bildquelle: [Android Erklärung 08]) Programmiersprachen und Entwicklungsumgebungen für Mobiltelefone The only other thing that might limit you is your imagination. There really isn t much that can t be achieved with today s mobile technology, [Legget et al. 06]. Wie dieses Zitat zeigt, ist fast alles mit mobilen Geräten machbar. Um die mobilen Anwendungen erstellen zu können, müssen natürlich entsprechende Programmiersprachen bereitgestellt werden. Die wichtigsten Sprachen für die Erstellung mobiler Anwendungen sind: Symbian C++, Java 2 Micro Edition, Python und Flash Lite. Im folgenden Teil werden diese näher betrachtet und entsprechende Entwicklungsumgebungen erwähnt Symbian C++ Die native Programmiersprache für Mobiltelefone mit Symbian Betriebssystem ist Symbian C++. Die Sprache ist ähnlich zum klassischen C++. Durch die Hardwarenähe sind diese Programme sehr schnell bei der Ausführung und der Entwickler hat Zugriff auf das Dateisystem und alle Hardwareressourcen. Gleichzeitig muss sich der Entwickler aber auch um die Verwaltung des Speichers kümmern. Diese Möglichkeiten erfordern deswegen eine hohe Einarbeitungszeit und die entstehenden Programme können schnell Fehler enthalten. Um einen späteren Schaden auf den Telefonen auszuschließen, bietet Symbian eine Signierung für geprüfte Programme an. Dieser Prozess wird symbian signed genannt. Ohne diese Signierung können zwar Programme entwickelt werden, haben aber nur beschränkten Zugriff auf Hardwareressourcen. Zudem wird bei einer Installation dem Nutzer ein Hinweis gezeigt, dass diese Anwendung nicht signiert ist und Schaden am Telefon verursachen könnte. Für eine Signierung muss das fertige Programm an eine von Symbian freigegebene Prüfstelle geschickt werden. Diese prüft den Programmcode auf Fehler, ob allgemeine Standards eingehalten wurden und so weiter. Sind diese Tests erfolgreich abgeschlossen, bekommt der Entwickler ein Zertifikat mit dem er seine Anwendung signieren kann. Nun wird dem Endnutzer kein Hinweis mehr angezeigt und er kann sicher sein, dass diese Anwendung keine Schäden verursacht. Für Entwickler gibt es noch die Möglichkeit ein Entwicklerzertifikat auszustellen. Dieses ist nur für ein Telefon gültig und kann dort alle 19

20 Hardwareressourcen nutzen. Auf diese Zertifikate wird in Abschnitt 42 noch einmal näher hingewiesen. Für die Entwicklung von Symbian C++ Anwendungen werden verschiedene SDKs (Software Development Kits) angeboten. Diese beinhalten Beispielprogramme und alle notwendigen Programmbibliotheken. Als Entwicklungsumgebung kann Carbid C++ [Carbid 08] genutzt werden. Diese wird von Nokia entwickelt und ist sozusagen Standard für die Entwicklung von Symbian C++ Anwendungen. Es bietet eine ähnliche Oberfläche wie Eclipse (vgl. [Eclipse 07]) und ist somit für Entwickler von anderen Programmiersprachen einfach zu erlernen. In dieser Entwicklungsumgebung ist auch ein Emulator eingebaut, der es ermöglicht, die Programme direkt am Rechner zu testen. Leider bietet dieser Emulator keine Möglichkeit eine Kamera anzusprechen und ist daher für kamerabasierte Eingaben nur beschränkt nutzbar. Auf der Abbildung 12 wird ein Screenshot der Entwicklungsumgebung Carbid C++ gezeigt. Der schon erwähnte Emulator ist ebenfalls auf der rechten Seite der Abbildung zu sehen. Abbildung 12: Carbid C++ Entwicklungsumgebung, inklusive dem Emulator für S60 Telefone auf der rechten Seite 20

21 Java 2 Micro Edition Die Java 2 Micro Edition oder kurz J2ME ist eine Kollektion von Technologien und Spezifikationen, die seitens der Entwickler entsprechend ihren Bedürfnissen zusammengestellt werden können. Somit wird eine optimale Nutzung des Speichers, des Prozessors und der Ein- und Ausgabegeräte erreicht. Die Java ME Plattform ist unterteilt in Konfigurationen, Profile und Optionale Teile (siehe auch Abbildung 13). Mit Hilfe der Konfigurationen wird ein Basissatz an Bibliotheken spezifiziert, mit denen die Grundfunktionen bereitgestellt werden. Diese sind bezogen auf eine größere Spanne von Geräten und behandeln die Vernetzung der Geräte und die Prozessorleistung oder Speichergröße. Dementsprechend gibt es zwei Java ME Konfigurationen: Connected Limited Device Configuration (CLDC) Diese Konfiguration ist für kleine Wireless Geräte mit einer langsamen Internetverbindung und beschränkten Speicher- und Prozessorkapazitäten. Zwei Beispiele wären Mobiltelefone oder Personal Digital Assistants (PDAs). Connected Device Configuration (CDC) Für Geräte, die eine größere Prozessor- oder Speicherkapazität und eine gute Internet Verbindung aufweisen, wird diese Konfiguration genutzt. Beispiele für diese Geräte sind Settop Boxen, Internet Geräte oder eingebettete Server. Anhand von Profilen werden die oben genannten Konfigurationen durch speziellere APIs (Programmierschnittstellen), ergänzt und somit an die entsprechenden Zielgeräte angepasst. Mit Hilfe der optionalen Teile kann die Laufzeitumgebung mit zusätzlichen Funktionen ausgestattet werden, wie zum Beispiel Datenbank Konnektivität, Wireless Verbindungen, Multimedia, 3D Grafik und Web Services. Es werden durch diese einzelne Auswahl die Anzahl der zu übertragenden Daten reduziert und keine unnötigen Funktionen eingebaut. Abbildung 13: J2ME Konfigurationen Als Entwicklungsumgebung für Java bietet sich Eclipse (vgl. [Eclipse 07]) an. Diese Umgebung ist für Java Programme fast zur Standard Entwicklungsumgebung geworden. Es bietet eine Schnittstelle für Plugins, durch die die Funktionen von Eclipse erweitert werden können. Die Entwicklergemeinde bietet auch sehr viel solcher Plugins an und ermöglicht so einen vereinfachten Arbeitsablauf. Eines dieser Plugins ist das Sun J2ME wireless toolkit, damit lassen sich mobile Java Anwendungen entwickeln. Es bringt gleichzeitig einen Emulator für das Testen der Anwendungen mit. 21

22 Python Python umfasst mehrere Programmierparadigmen beziehungsweise die Art und Weise wie programmiert wird. Es wird die aspektorientierte, objektorientierte und funktionale Programmierung unterstützt. Allgemein wurde die Sprache entwickelt, um leicht lesbare Quellcodes zu entwickeln. Für Symbian Telefone gibt es Python for S60 ein Programm für die Interpretation von Python Skripten auf Symbian Handys (Interpreter genannt). Der Vorteil von Python ist, dass es sehr schnell erlernbar ist und der Entwickler sich gut in den bestehenden Code einlesen kann. Jedoch ist für die Ausführung immer ein Interpreter, also beispielsweise Python for S60 notwendig. Nutzer, die also Python Anwendungen auf ihrem Telefon nutzen möchten, müssen sich vorher diesen Interpreter installieren. Der Funktionsumfang ist ähnlich groß wie bei Symbian C++ jedoch gibt es nur wenige Funktionen für die Ausgabe von Grafiken Flash Lite Die Entwicklungsumgebung Adobe Flash hat von Hause aus, ab Version 8, schon die Möglichkeiten Flash Lite Anwendungen zu entwickeln. Dabei kann im Grunde genau so vorgegangen werden, wie mit klassischen Flashanwendungen, nur werden nicht alle Funktionen unterstützt. Zudem sollte natürlich auf die Besonderheiten von mobilen Endgeräten geachtet werden, wie die Bildschirmgröße, der Speicher oder die Leistungsfähigkeit und so weiter. Zu der normalen Entwicklungsumgebung gibt es ab der Version Flash CS3 noch DeviceCentral CS3, einen leistungsfähigen Emulator für Flash Lite Anwendungen. Mit DeviceCentral (siehe Abbildung 14) ist es möglich, die Anwendungen auf verschiedenen Endgeräten zu simulieren. Abbildung 14: Adobe DeviceCentral CS3 22

23 Dabei können verschiedene Situationen simuliert werden: eine Spiegelung auf dem Display oder ausgeschaltetes Hintergrundlicht. Zudem kann der eigene Rechner nach einem Test so kalibriert werden, dass er die Leistungsfähigkeit des entsprechenden Telefons simuliert. Durch regelmäßige Aktualisierungen werden die Profile, der zur Verfügung gestellten Telefone, auf dem aktuellen Stand gehalten. Für die skriptseitige Programmierung von Flash Lite Anwendungen kann Actionscript, die Scriptsprache von Flash, genutzt werden. Adobe Flash stellt aber nur einen relativ einfachen Scripteditor bereit. Deswegen kann bei größeren Projekten mit vielen Actionscript Dateien beispielsweise FlashDevelop [FlashDevelop 07] Verwendung finden. Diese Entwicklungsumgebung lässt sich gut mit Adobe Flash verknüpfen und bietet mehr Komfort bei der Erstellung von Actionscriptdateien Kommunikation zwischen Flash Lite und anderen Programmiersprachen Wie zu Beginn schon erwähnt wurde, besteht ein großes Hindernis bei der Kommunikation von Hardwarekomponenten mit Flash Lite. Grund dafür ist das Sicherheitsmodell von Flash Lite. Der Flash Lite Player befindet sich in einer Sandbox, dass heißt, es ist ihm nicht gestattet direkt auf die zugrundeliegende Hardware zuzugreifen. Um jedoch eine Bewegungsgesteuerte Nutzereingabe in Flash Lite Anwendungen zu verwenden, muss ein Weg gefunden werden mindestens Befehle zu empfangen. Grundlegend gibt es folgende Ansätze zur Kommunikation zwischen Flash und der entsprechenden Umgebung: External Interface Shared Object Lokale Textdatei FSCommand2 Befehl Socket Server Diese Punkte werden im folgenden Teil auf ihre Nutzbarkeit für eine Kommunikation zwischen Flash Lite und dem Mobiltelefon etwas näher betrachtet External Interface Das External Interface ist in Flash eingebaut, um Befehle von anderen Flash Anwendungen oder anderen Programmiersprachen zu empfangen. Es stellt die Möglichkeit bereit, eine Schnittstelle zu definieren, mit der kommuniziert werden kann. Diese bereitgestellte Funktion würde sich anbieten, jedoch ist sie nur in der normalen Adobe Flash Version verfügbar und wird durch Flash Lite nicht unterstützt. Sie würde das Sicherheitsmodell von Flash Lite verletzten und ist aus diesem Grund aus der mobilen Version entfernt worden Shared Object Ab der Version Flash Lite 2.0 gibt es die Möglichkeit Shared Objects anzulegen. Diese ermöglichen ein persistentes (dauerhaftes) Abspeichern von Daten auf dem Mobiltelefon. Diese Shared Objects könnten nun genutzt werden, um Daten abzulegen und mit einer anderen Anwendung darauf zuzugreifen. Jedoch gibt es auch hier Einschränkungen, die regeln, dass nur die Anwendung auf das entsprechende Shared Object zugreifen kann, welche es auch erstellt hat. Hier liegt ebnefalls der Grund im Sicherheitsmodell von Flash Lite, welches unterdrückt, dass Daten ausgetauscht werden können Lokale Textdatei In der Version Flash Lite 1.1 gab es die oben genannte Möglichkeit von Shared Objects noch nicht und es konnten keine Daten, wie zum Beispiel Einstellungen, Punktestände und so weiter auf dem Gerät gespeichert werden. Aus diesem Grund wurde nach Alternativen gesucht und es wurden Anwendungen wie write2file, in [Legget et al. 06] auf Seite 348 ff, geschrieben. Mit Hilfe dieser Anwendungen ist es möglich, Daten in einer lokalen Datei 23

24 abzulegen. Da die erstellte Datei direkt angegeben wird, besteht so auch die Möglichkeit, mit anderen Flash Lite Anwendungen diese Daten auszulesen. Das würde eine einfache Kommunikation zwischen Teilen außerhalb und der entsprechenden Flash Lite Anwendung realisieren. Der Nachteil an dieser Lösung ist, dass zwei Anwendungen nicht gleichzeitig auf eine Datei zugreifen können. Es muss also immer vor dem Schreibzugriff eine Prüfung stattfinden, ob die Datei gerade bearbeitet wird oder nicht. Für Anwendungen mit geringem Datenaustausch mag es eine Lösung darstellen, eine durchgehende Kommunikation ist somit jedoch nicht möglich. Im Fall einer kamerabasierten Benutzereingabe käme es zu einer durchgehenden Kommunikation, weil ununterbrochen Eingabebefehle geschickt werden. Die in [Legget et al. 06] auf Seite 348 ff beschriebene Anwendung, nutzt für die Umsetzung Symbian C++. Für die Entwicklung beziehungsweise Änderung sind also zu den Flash Lite auch Symbian C++ Kenntnisse nötig FSCommand2 Befehl Mit dem Befehl FSCommand2 ist es möglich, Informationen über Eigenschaften des Mobiltelefons zu erhalten. Beispielsweise kann mit fscommand2( GetBatteryLevel ); der Ladestatus der Batterie ausgelesen werden. Im Prinzip wird dadurch auch mit anderen Teilen außerhalb des Flash Lite Players kommuniziert. Diese Funktion ist jedoch auf die vordefinierten Befehle beschränkt und kann nicht beliebig erweitert werden. Es ist dabei auch kein Befehl vorhanden, der eine Kommunikation zwischen Flash und der Hardware zulässt Socket Server Mit dem Projekt Flyer (vgl. [Flyer 07]) wurde eine neue Möglichkeit zur Kommunikation mit der Gerätehardware entwickelt. Mit dem Flyer-Framework ist es möglich, von Flash Lite auf Telefonbucheinträge, Kamera oder ähnliches zuzugreifen. Doch wie wird das realisiert, wenn alle Schnittstellen unterbunden werden? Die Lösung ist seit der Version 2.1 von Flash Lite möglich. Denn seitdem werden Socket Verbindungen von Flash Lite unterstützt. Eine Socket Verbindung ist eine persistente Verbindung zwischen einem Clienten und einem Server, auf der Daten schneller als über Standardverbindungen getauscht werden können. Diese Fähigkeit wird vom Flyer-Framework genutzt, indem ein lokaler Python Socket Server auf dem Mobiltelefon eingerichtet wird. Dieser reagiert auf spezielle Befehle von Flash Lite und schickt entsprechende Datenströme zurück. Da es Python, im Gegensatz zu Flash Lite, möglich ist auf Hardware zuzugreifen werden die Daten über den lokalen Socket Server an die Flash Lite Anwendung weitergeleitet. Für die Flash Lite Anwendung ist es unwichtig mit welcher Netzwerkadresse sie sich verbindet (das kann also auch die Netzwerkadresse des lokalen Rechners sein). Für die Einrichtung des lokalen Socket Servers auf dem Telefon können jedoch auch andere Programmiersprachen als Python genutzt werden. So ist es auch möglich mit der Sprache des Betriebssystems, Symbian C++, auf entsprechende lokale Funktionen zuzugreifen und über einen Server zugänglich zu machen. Mit der Sprache Java, welche auch in den meisten Fällen installiert ist, ist das leider nicht möglich. Für Mobiltelefone wird eine spezielle Java Version genutzt, die keine Serverfunktionalitäten enthält (siehe dazu Abschnitt ). 24

25 3.3 Bewegungserkennung in Bildersequenzen Um eine Bewegung der Kamera eines Mobiltelefons zu erkennen, ist es notwendig, eine Sequenz von mehreren Bilder zu optimieren, zu analysieren und auszuwerten. Zu Beginn wird das Bild mit Filtern bearbeitet um bestimmte Bereiche zu erkennen, die auf eine Bewegung hindeuten. Diese Bereiche werden dann zwischen den einzelnen Bildern verglichen. Danach kann daraus auf eine Bewegung in eine bestimmte Richtung geschlossen werden. Für die Verarbeitung müssen die einzelnen Pixel des Bildes verarbeitet werden, was dazu führt, dass mit Zunehmen der Bildgröße auch der Umfang der Berechnung zunimmt. Ebenfalls ist die Anzahl der aufeinanderfolgenden Bilder in der zu betrachtenden Sequenz von Bedeutung. Um in dieses Thema etwas mehr Einblick zu bekommen, wird nun in diesem Teil etwas näher auf die Bewegungserkennung von Bildsequenzen eingegangen Optimieren der Bildsequenz Das Ziel der Bewegungserkennung in Bildsequenzen ist es, aus mehreren aufeinanderfolgenden Bildern einen Richtungsvektor zu errechnen. Das Ergebnis gibt also eine bestimmte Richtung und die Länge der Bewegung an. Zu Beginn ist es wichtig, wie viele aufeinanderfolgende Bilder verarbeitet werden sollen. Um dabei einen gut funktionierenden Wert auszuwählen, kann durch Ausprobieren verschiedener Werte getestet werden, wie viele Bilder die besten Ergebnisse liefern oder man orientiert sich an Angaben, die die entsprechende Literatur gibt. In [Haro et al. Okt 05] ist beschrieben, dass eine Sequenz von 3-5 Bildern ein optimales Ergebnis erzielt. Natürlich kann dies von Gerät zu Gerät variieren, da dieses eine gute Abwägung zwischen benötigter Rechenleistung und der Genauigkeit des Resultats ist. Nun müssen die einzelnen Bilder der Bildsequenz verarbeitet werden. Das heißt, es müssen Optimierungen an den Bildern erfolgen, um die folgenden Berechnungen schneller zu erledigen. Aus diesem Grund sollten die Bilder schon zu Beginn relativ klein sein. Sind sie es nicht, müssen sie zu Beginn verkleinert werden. Die Verkleinerung der Bildgröße verringert, genau wie die oben genannte Anzahl der Bilder, die Genauigkeit der Bewegungserkennung, lässt aber gleichzeitig eine schnellere Berechnung zu. Eine optimale Bildgröße hängt von der Ausgangsgröße ab. Bei einem Mobiltelefon liegt diese zwischen 128 x160 und 352 x 416 Pixel (auf Grundlage der aktuellen Nokia Modelle in Adobe DeviceCentral). Die Größe von 240 x 320 Pixel ist dabei am Meisten vertreten. Bei diesem Ausgangsmaterial sollten die Bilder wie in dem Quellcode der Nokia CV Bibliothek (vgl. [Nokia CVL 07]) auf 25 x 18 Pixel verkleinert werden. Für eine weitere Reduzierung der zu berechnenden Daten werden in den meisten Fällen die Bilder vorher in Graustufen umgewandelt. So ergeben sich nur noch 256 mögliche Farbwerten, die ein Pixel annehmen kann. Aus diesem Grundmaterial kann nun die Bewegung errechnet werden. Für die Berechnung gibt es verschiedene Herangehensweisen. Die Wichtigsten werden im Folgenden näher vorgestellt Motion History Images Eine visuelle Zusammenfassung einer Bewegung geben Motion History Images (MHI). Diese zeigen den Verlauf einer Bewegung in einem Bild. Abbildung 15 veranschaulicht dieses Prinzip anhand einer Bewegung einer Sportlerin, die ihren Arm hebt. In der oberen Zeile wird die Bewegung auf Graustufenbildern gezeigt und die Untere gibt diese Bewegung mit Hilfe von MHI wieder. 25

26 Abbildung 15: Motion History Images (Bildquelle: [Davis 07]) Um ein MHI zu erstellen, wird damit begonnen, zwischen dem ersten und zweiten Bild die Unterschiede zu erkennen. Das geschieht, indem jeder Pixel geprüft wird, ob er sich noch an der selben Stelle befindet, oder ob er sich verschoben hat. Dazu wird der Grauwert des Pixels ausgelesen und im zweiten Bild geschaut, ob sich an der Stelle der selbe Grauwert befindet. Ist das der Fall, wird dieser Punkt nicht weiter beachtet und im MHI als schwarzer Punkt angezeigt. Hat er sich jedoch bewegt, muss die Umgebung des Pixels durchsucht werden, wo dieser Grauwert jetzt auftaucht. Dieser Bereich beschränkt sich meist auf nur wenige Pixel, also beispielsweise ein Bereich von 3 x 3 Bildpunkten. Der Bereich muss relativ klein gewählt werden, da sich dieser Grauwert sicherlich oft in dem Bild wiederholt aber nichts mit dem Ausgangspunkt zu tun hat. Das erfordert aber auch die Einschränkung, dass lange, schnelle Bewegungen hier nicht erkannt werden können. Dabei würde sich der Bildpunkt zu weit und aus diesem Bereich heraus bewegen. Wurde der Wert nun in der näheren Umgebung gefunden, wird dieser Punkt durch einen hellen Wert im MHI repräsentiert. Sind alle Pixel in diesen ersten beiden Bildern der Sequenz verarbeitet, zeigt das MHI ein Schwarz-Weiß Bild, indem die hellen Bereiche für die Bewegung stehen. Dieses Verfahren wird nun auf alle weiteren Bilder der Sequenz angewandt. Die aktuellen bewegten Pixel werden wieder als helle Punkte eingezeichnet und die älteren abgedunkelt. So stellt das MHI letztendlich die Bewegung mit Grauwerten dar. Eine Bewegung verläuft also immer von den dunkleren Bereichen zu den hellen. MHI wurde vor allem dazu entwickelt, um Bewegungsgesten zu erkennen, die auf Grund des Verlaufs von hell zu dunkel einfacher bestimmt werden können. Eine weitere Nutzung von MHI sind kurze, schnelle Bewegungen wie sie zum Beispiel bei einem Schütteln der Kamera auftreten können. Andere Bewegungserkennungen könnten eine schnelle Bewegung nach rechts und kurz darauf nach links, in dem Sinne deuten, dass das Gerät sich immer noch am Ausgangspunkt befindet und sich nicht bewegt hat. Durch ein MHI werden aber helle Bereiche sichtbar, die bei einem Schütteln auf eine Bewegung hindeuten. Von dem errechneten MHI können bestimmte Statistische Berechnungen der Grauwerte solch ein Schütteln des Gerätes identifizieren. Diese Beschreibung, des Erstellens eines MHI, ist zusammengefasst dargestellt und wurde aus [Davis 07] entnommen, wo das Verfahren in allen Einzelheiten erläutert wird Ecken und Kanten Eine weitere Möglichkeit Bewegungen aus einer Bildsequenz zu erkennen, ist das Beobachten von Ecken und Kanten. Da in einem Bild aber nicht einfach so starke Kanten zu sehen sind, muss vorher ein weiterer Filter auf das Bild angewandt werden. Hierfür wird ein Sobelfilter genutzt. Dieser errechnet Kanten, welche wie auf Abbildung 16 demonstriert, angezeigt werden. 26

27 Abbildung 16: Ausgangsbild links und mit Sobel Filter in x und y Richtung bearbeitetes Ergebnis rechts Aus dem bearbeiteten Bild werden nun die Ecken und Kanten bestimmt, die sich verschoben haben. Die besten Ergebnisse ergeben dabei die Ecken, da bei den Kanten das Blendenproblem auftritt. Abbildung 17 veranschaulicht dieses Problem. Der Grund liegt darin, dass bei dem Vergleich zwischen zwei Bildern immer nur ein kleiner Abschnitt analysiert wird. Ist dieser Abschnitt eine Kante, kann der Bewegungsvektor nicht richtig bestimmt werden. Als Ergebnis kann nur der Bewegungsvektor senkrecht zur Kante berechnet werden. Wird eine Ecke für den Vergleich herangezogen wie in Bild b) zu sehen, ist der Bewegungsvektor genauer abzulesen. a b? Abbildung 17: Veranschaulichung des Blendenproblems Für den Vergleich von zwei Bildern wird also der Bereich der Ecken bevorzugt. Der Nachteil daran ist, dass diese Erkennung der Ecken rechenintensiver ist, als die Erkennung der Kanten (vgl. [Haro et al. Okt 05]). Um also eine weitere Optimierung zu erzielen, können auch nur die Kanten berechnet werden. Dazu wird der Sobel Filter jeweils nur in eine Richtung angewandt. Einmal in die x-richtung und einmal in die y-richtung (siehe Abbildung 18). Die beiden resultierenden Bewegungen werden zusammengerechnet und als Ergebnis wird 27

28 annähernd das Gleiche erreicht, wie es aus der Bestimmung der Ecken resultieren würde, jedoch mit weniger Rechenaufwand (vgl. [Haro et al. Dez 05]). Abbildung 18: Die Anwendung des Sobel Filters auf das Ausgangsbild aus Abbildung 16, links in x- Richtung und auf der rechten Seite in y-richtung Die Verschiebung der Kanten muss nun berechnet werden. Um durch Fehler im Bild und Bildrauschen keine falschen Werte zu bekommen, muss es einen bestimmten Schwellwert geben, bis zu dem die Kanten erkannt werden. Liegt der Wert höher, werden diese Punkte nicht mit berechnet. Dieser Schwellwert wird in der Literatur auch Threshold genannt. In [Haro et al. Dez 05] wird dafür ein optimaler Wert von 50 genannt. Weiter wird in [Haro et al. Okt 05] geschrieben: The 50 strongest features per frame are found [ ] und zeigt eine weitere Optimierung auf maximal 50 klar erkennbare Bereiche, die verglichen werden Template Matching Da es nicht sehr effektiv ist, jedes Pixel mit allen anderen zu vergleichen, kann das sogenannte Template Matching (vgl. [Haro et al. Dez 05]) genutzt werden. Dabei wird ein gewisser Bereich, beispielsweise 15 x 15 Pixel ausgewählt und mit den benachbarten Pixeln auf Übereinstimmung verglichen. Wie weiter in [Haro et al. Okt 05] geschrieben wird, ist dieser Prozess allein nicht sehr genau in der Erkennung von Bewegungen. Jedoch in Kombination mit der Kantenerkennung ist er geeignet, um ausreichend gute Ergebnisse zu erreichen. Vor allem im mobilen Bereich ist es daher ausreichend, da einerseits nur eine geringe Genauig-keit notwendig ist und andererseits diese Kombination geringere Rechenaufwände benötigt Richtungserkennung Das Ergebnis der verschiedenen Berechnungen der Richtungsvektoren, bringt jedoch noch keine eindeutige Richtung hervor. Vielmehr ergeben sich viele kleine Vektoren, die nicht immer in dieselbe Richtung zeigen müssen. Jeder verschobene Pixel, beziehungsweise jeder verschobene Bildteil, liefert einen Bewegungsvektor. Nun kann nicht einfach aus diesen verschiedenen Vektoren einer ausgewählt werden, dass würde zu großen Fehlern in der Berechnung führen. Eine mögliche Lösung ist es, den Durchschnitt aus den gesamten erzielten Vektoren zu berechnen. Der resultierende Bewegungsvektor repräsentiert dann eine zusammenfassende Bewegung des Bildes, was auch gewünscht ist. Weitere Optimierungen können an dieser Stelle erreicht werden, indem nicht nur der resultierende Vektor 28

29 zwischen zwei Bildern berechnet, sondern zusätzlich der Mittelwert aus mehreren Bildern berechnet wird. So können ein Wackeln oder ein kurzes Zögern in der Bewegung keine Fehler verursachen Nokia CV Bibliothek Nokia forscht an einem Projekt mit dem Namen Nokia Computer Vision Library, welches sich mit der Verarbeitung von Bildern beschäftigt. Als Ergebnis wurde nun die Version 1.0 der Nokia Computer Vision Library (kurz Nokia CV Library) veröffentlicht. Zu finden ist das Projekt unter [Nokia CVL 07]. Dort wird auch die entsprechende Dokumentation und Einführung im Umgang mit der Bibliothek bereitgestellt. Diese Symbian C++ Bibliothek erweitert im Grunde die Grafikfunktionen von Symbian S60 Geräten ab der 3rd Edition. Es bietet die Möglichkeit, Bilder zu verändern oder eine Bewegungserkennung durchzuführen. Wobei der letzte Punkt vor allem im Hinblick auf diese Arbeit wichtig ist. Die Nokia CV Library bietet nämlich die Möglichkeit, aus Bildfolgen direkt Bewegungsrichtungen und deren Intensität auszulesen. Weiterhin ist auch die Erstellung von Motion History Images möglich, was, wie schon erwähnt, die Erkennung von Bewegungsgesten und Schütteln zulässt Beispielanwendungen Es wurden schon einige Anwendungen entworfen und Prototypen entwickelt, die mit Hilfe einer kamerabasierten Nutzereingabe arbeiten. Auch in [Haro et al. Okt 05] ab Kapitel 5 gibt es einige Anschauungsbeispiele. Der Unterschied zu den hier in dieser Arbeit zu entwickelnden Anwendungen ist, dass sie nicht auf ein einheitliches Framework aufbauen und kein Flash Lite als Benutzerschnittstelle nutzen. Im Folgenden werden ein paar Prototypen gezeigt, die veranschaulichen, welche Möglichkeiten eine kameragesteuerte Eingabe bietet MINI Turn your Mobile Für die BMW Marke MINI wurde eine kamerabasierte Anwendung entwickelt. Diese ermöglicht, dem Nutzer durch horizontale Bewegungen des Mobiltelefons, das Auto auf dem Display zu drehen. Eine Demoversion dieser Anwendung ist auch auf der Webseite zu sehen (vgl. [Mini 07]). Ein Screenshot der Anwendung ist in Abbildung 19 aufgeführt. Abbildung 19: MINI Turn your Mobile, Bewegung eines Automodells durch Bewegung der Kamera (Bildquelle: [Mini 07]) 29