Beispiel

maremare Augmented Reality EnvironmentDiplomarbeitim Studiengang Medieninformatikder Technischen Fachhochschule Berlinvorgelegt vonNikolai Ruhe, Matrikelnummer 70 71 25Daniel Sadilek, Matrikelnummer 70 72 97erste Gutachterin: Prof. Dr. Fanny-Michaela Reisinzweiter Gutachter: Prof. Dr. Heinrich P. GodbersenEingereicht am 2. August 2004Nikolai Ruhe · Hobrechtstraße 78 · 12043 Berlin · Tel. 0 30/61 62 92 40 · mail@nikopol.deDaniel Sadilek · Im Rosengrund 23 · 12347 Berlin · Tel. 0 30/70 13 18 70 · daniel@sadilek.de

Kurzfassung – Diese Diplomarbeit stellt dasmare Environment vor, das als Basis für die Erstellungvon Augmented-Reality-Anwendungendienen soll. Für die Entwicklung von mare warenzwei Schwerpunkte vorgegeben:Zum einen wurden Interaktionskomponentenfür die Erstellung von Benutzerschnittstellen,speziell zur Systemsteuerung, als Erweiterungder OpenInventor-Klassenbibliothek entwickelt.Die Interaktionskomponenten sind sokonzipiert, dass sie sich sowohl mit den klassischenDesktop-Interaktionsgeräten bedienenlassen als auch mit der neu entwickelten Handgestensteuerung.Zum anderen wurde eine auf Videobildanalysebasierende Erkennung von Handgesten realisiert,um die Hand als »Interaktionsgerät« verwendenzu können. Das eingesetzte Verfahrenist eine Erweiterung des Elastic Graph Matching.Die entwickelten Erweiterungen sind dieModellierung von Graphverformungen, dieVerwendung einer Auflösungspyramide undTracking.Abstract —This diploma thesis introduces themare environment, which will function as abasis for future augmented reality applications.Our aims during the development ofmare were as follows:Our first aim was to develop interaction componentsthat facilitate the creation of userinterfaces, with an emphasis on system control.These components were designed as anextension of the OpenInventor class library.The implementation enables their use withboth classic desktop interaction devices andthe newly implemented hand gesture interaction.Our second aim was the development of handgesture interaction based on video imagerecognition. This enables the hand to be an»interaction device«. The used recognitionmethod is an extension of the Elastic GraphMatching method. The developed extensionsare modeling of Graph Deformation, usage ofa Resolution Pyramid and Tracking.

InhaltInhaltLiteraturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Abbildungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Tabellenverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Definitionsindex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Danksagungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Konventionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Einleitung1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.1 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Einführung in mare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Grundlagen – Hauptteil I3 Fachliches Umfeld und Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . 293.1 Fachliches Umfeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.1.1 Einordnung der Augmented Reality . . . . . . . . . . . . . . . . . . . . . . . . . . 293.1.2 Head Mounted Displays für die Augmented Reality . . . . . . . . . . . . . 323.1.3 Systemsteuerung als Interaktionsaufgabe . . . . . . . . . . . . . . . . . . . . . 353.1.4 Interaktionsgeräte für die Augmented Reality . . . . . . . . . . . . . . . . . . 363.2 Stand der Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.2.1 DWARF – Distributed Wearable Augmented Reality Framework . . 383.2.2 amire – Authoring Mixed Reality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.2.3 Studierstube – Augmented Reality Project . . . . . . . . . . . . . . . . . . . . . 403.3 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.4 Verwendete Methoden, Werkzeuge und Bibliotheken . . . . . . . . . . . 434 Vorüberlegungen und Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.1 Entwicklungsebenen, Rollen und Use-Cases . . . . . . . . . . . . . . . . . . . 444.1.1 Beispiel-Use-Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.2 Die mare-Geste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.3 Die mare-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533

InhaltInteraktionsschnittstelle – Hauptteil II5 Interaktionsschnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.1 Anforderungen an die Interaktionsschnittstelle . . . . . . . . . . . . . . . . . 585.1.1 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.1.2 Nichtfunktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.2 Exkurs Szenegraphbibliotheken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.3 Erweiterung von OpenInventor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.3.1 OpenInventor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.3.2 mare-Komponenten als Szenenobjekte . . . . . . . . . . . . . . . . . . . . . . . 625.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636 Darstellungskomponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646.1 Überdeckungen in der Augmented Reality . . . . . . . . . . . . . . . . . . . . 646.2 Überdeckung in mare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656.3 MareSceneKit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697 Interaktionskomponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707.1 Vorüberlegungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707.2 Grafische Gestaltung der Interaktionskomponenten . . . . . . . . . . . . . 717.3 Ergebnisse des experimentellen Prototypings . . . . . . . . . . . . . . . . . 727.4 GuiKit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737.5 Containmenthierarchie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767.6 Panel und Label . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787.7 Button . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807.7.1 Responder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 827.7.2 Implementierung von Button . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837.7.3 Erzeugung eines ActionEvents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847.7.4 CheckBox und RadioButton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847.8 Rotor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867.9 Ereignisbehandlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887.9.1 OpenInventor Globale Felder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897.9.2 OpenInventor Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907.9.3 Observer Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917.9.4 Ereignisweiterleitung am Beispiel eines Buttons . . . . . . . . . . . . . . . . 937.9.5 Ereignisse in mare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 957.10 Konstruktion durch Prototypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 967.11 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974

InhaltGestenerkennung – Hauptteil III8 Auswahl zu untersuchender Erkennungsverfahren . . . . . . . . . . . . 1018.1 Anforderungen an das Erkennungsverfahren . . . . . . . . . . . . . . . . . . . 1018.1.1 Anforderungen an ein ideales Erkennungsverfahren . . . . . . . . . . . . 1018.1.2 Anforderungen an das umzusetzende Erkennungsverfahren . . . . . 1048.2 Verfahren zur Gestenerkennung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1078.2.1 Gestenmodellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1078.2.2 Gestenanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1088.2.3 Gestenerkennung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1118.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1119 Shape Context Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1129.1 Einführung in das Shape Context Matching . . . . . . . . . . . . . . . . . . . . 1129.2 Verbesserungsmöglichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1139.3 Verbesserung durch Verwendung der Kantenorientierung . . . . . . . . 1139.4 Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11610 Elastic Graph Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11710.1 Exkurs Elastic Graph Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11710.2 Formalisierungen und Weiterentwicklungen in mare . . . . . . . . . . . . 12510.2.1 Formalisierung der Graphtransformation . . . . . . . . . . . . . . . . . . . . . . 12510.2.2 Definition von Funktor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12710.2.3 Modellierung von Graphverformung . . . . . . . . . . . . . . . . . . . . . . . . . 13010.2.4 Verwendung einer Gaußschen Pyramide . . . . . . . . . . . . . . . . . . . . . . . 13410.2.5 Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13810.2.5.1 Vorüberlegungen zum Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13810.2.5.2 Erforschende Nummerierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14010.2.5.3 Abbruchbedingung und Initialbedingung . . . . . . . . . . . . . . . . . . . . . 14410.2.5.4 Trackingzustand der Erkennung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15010.3 Erkennung der mare-Geste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15210.3.1 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15310.3.2 Konfiguration der Anpassungsschritte . . . . . . . . . . . . . . . . . . . . . . . . 15510.4 Objektorientierte Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15810.4.1 Modellierung von Graphen und Bunchgraphen . . . . . . . . . . . . . . . . . 15810.4.2 Graphtransformation durch Functor . . . . . . . . . . . . . . . . . . . . . . . . . . 15910.4.3 Bewertung der Graphübereinstimmung durch Estimator . . . . . . . . . 16210.4.4 Konfiguration und Durchführung der Graphanpassung . . . . . . . . . . 1645

Inhalt10.4.4.1 MatchingStep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16410.4.4.2 Optimizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16410.4.4.3 Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16610.4.4.4 Instanzbeispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16710.4.5 Erkennung der mare-Geste durch GestureRecognition . . . . . . . . . . 16910.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170Beispielanwendung – Hauptteil IV11 Eine Beispielanwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173Schluss12 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18112.1 Interaktionsschnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18112.2 Gestenerkennung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18213 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18413.1 Interaktionsschnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18413.2 Gestenerkennung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18614 Resümee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188AnhangA I Übersicht über das mare-Modul Interaktionsschnittstelle . . . . . . . . . 189A II Übersicht über das mare-Modul Gestenerkennung . . . . . . . . . . . . . 191B OpenInventor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195C Szenegraphdiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198D Szenegraphen von Interaktionskomponenten . . . . . . . . . . . . . . . . . . 2006

LiteraturverzeichnisLiteraturverzeichnis[Amire04] Autor unbekannt, AMIRE – authoring mixed reality,http://www.amire.net, Stand Juli 2004.[Azuma97] R. T. Azuma, A Survey of Augmented Reality in Presence: Teleoperators and Virtual Environments,Vol. 6, No. 4, 1997.[BBKMRRSW01] M. Bauer, B. Bruegge, G. Klinker, A. MacWilliams, T. Reicher, S. Riß, C. Sandor,M. Wagner, Design of a Component-Based Augmented Reality Framework in Proceedings of TheSecond IEEE and ACM International Symposium on Augmented Reality (ISAR), Seiten 45–54, 2001.[BKLP01] D. A. Bowman, E. Kruijff, J. J. LaViola Jr., I. Poupyrev, An Introduction to 3-D User InterfaceDesign in Presence: Teleoperators and Virtual Environments, Vol. 10, No. 1, Seiten 96–108,2001.[BLLLS01] L. Bretzner, I. Laptev, T. Lindeberg, S. Lenman, Y. Sundblad, A Prototype System forComputer Vision Based Human Computer Interaction, Technical report, 2001.[BMP02] S. Belongie, J. Malik, J. Puzicha, Shape Matching and Object Recognition Using ShapeContexts in IEEE Transactions On Pattern Analysis And Machine Intelligence, Vol. 24, No. 24,Seiten 509–522, 2002.[DS01] K. Dorfmüller-Ulhaas, D. Schmalstieg, Finger Tracking for Interaction in Augmented Environmentsin Proceedings of The Second IEEE and ACM International Symposium on AugmentedReality (ISAR), 2001.[FP03] D. A. Forsyth, J. Ponce, Computer Vision - A Modern Approach, ISBN 0-13-085198-1, PrenticeHall, Upper Saddle River, 2003.[GHJV96] E. Gamma, R. Helm, R. Johnson, J. Vlissides, Entwurfsmuster: Elemente wiederverwendbarerobjektorientierter Software, ISBN 3-89319-950-0, Addison-Wesley, Bonn, 1996.[IB96] M. Isard, A. Blake, Contour tracking by stochastic propagation of conditional density in ProceedingsEuropean Conference on Computer Vision, Vol. 1, Seiten 343–356, 1996.[KBWF99] H. Kato, M. Billinghurst, S. Weghorst, T. Furness, A Mixed Reality 3D ConferencingApplication, Technical Report R-99-1, Seattle: Human Interface Technology Laboratory, Universityof Washington, 1999.[KOYTK95] T.Kanade, K. Oda, A. Yoshida, M. Tanaka, H. Kano, Video-Rate Z Keying: A NewMethod for Merging Images, Technical Report, 1995.[Loy02] G. Loy, Fast Computation of the Gabor Wavelet Transform, Digital Image ComputingTechniques and Applications, 21.-22. Januar, Melbourne, Australien, 2002.[LWWMH03] H. S. Loos, D. Wieczorek, R. P. Würtz, C. von der Malsburg, B. Horsthe, Computerbasedrecognition of dysmorphic faces in European Journal of Human Genetics, 11,Seiten 282–292, 2003.[MTUK94] P. Milgram, H. Takemura, A. Utsumi, F. Kishino, Augmented Reality: A class of displayson the reality-virtuality continuum, SPIE Vol. 2351 in Telemanipulator and Telepresence Technologies,Seiten 282–292, 1994.7

Literaturverzeichnis[NHA03] J. R. New, E. Hasanbelliu, M. Aguilar, Facilitating User Interaction with Complex Systemsvia Hand Gesture Recognition, to appear in Proceedings of the 2003 Southeastern ACM Conference,2003.[PBWI96] I. Poupyrev, M. Billinghurst, S. Weghorst, T. Ichikawa, The Go-Go Interaction Technique:Non-Linear Mapping for Direct Manipulation in VR in Proceedings of ACM Symposium on UserInterface Software and Technology (UIST '96), Seiten 79–80, 1996.[Pötzsch04]: M. Pötzsch, Gabor Wavelet Transformation,http://www.neuroinformatik.ruhr-uni-bochum.de/VDM/research/computerVision/imageProcessing/wavelets/gabor/contents_d.html, Stand Juli 2004.[Preim99] B. Preim, Entwicklung interaktiver Systeme, ISBN 3-540-65648-0, Springer-Verlag, Berlin-Heidelberg, 1999.[PSH97] V. I. Pavlovic, R. Sharma, T. S. Huang, Visual Interpretation of Hand Gestures for Human-Computer Interaction: A Review in IEEE Transactions On Pattern Analysis And MachineIntelligence, Vol. 19, No. 7, Seiten 677–695, 1997.[Schmalstieg01] D. Schmalstieg, Collaborative Augmented Reality, Habilitationsschrift eingereichtan der Technischen Universität Wien, Technisch-Naturwissenschaftliche Fakultät, 2001.[SG97] Z. Szalavári, M. Gervautz, The Personal Interaction Panel – a Two-Handed Interface forAugmented Reality in Proceedings EUROGRAPHICS 97, Seiten 335–346, 1997.[Shneiderman02] B. Shneiderman, User Interface Design, Deutsche Ausgabe, ISBN 3-8266-0753-8,mitp, Bonn, 2002.[TM96] J. Triesch, C. von der Malsburg, Robust Classification of Hand Postures against ComplexBackgrounds in Proceedings of the Second International Conference on Automatic Face andGesture Recognition '96, 1996.[TM01] J. Triesch, C. von der Malsburg, A System for Person-Independent Hand Posture Recognitionagainst Complex Backgrounds in IEEE Transactions On Pattern Analysis And Machine Intelligence,Vol. 23, No. 12, Seiten 1449–1453, 2001.[TM02] J. Triesch, C. von der Malsburg, Classification of hand postures against complex backgroundsusing elastic graph matching in Image and Vision Computing 20, Seiten 937–943, 2002.[TSTC03] A. Thayananthan, B. Stenger, P. H. S. Torr, R. Cipolla, Shape Context and Chamfer Matchingin Cluttered Scenes in Proceedings Conference on Computer Vision and Pattern Recognition,Vol. I, Seiten 127–133, 2003.[UML01] Object Management Group, OMG Unified Modeling Language Specification, Version 1.4,2001.[Watt02] B. Watt, 3D-Computergrafik, 3. Auflage, ISBN 3-8273-7014-0, Pearson Studium, München,2002.[WB04] G. Welch, G. Bishop, An Introduction to the Kalman Filter, TR 95-041, Department of ComputerScience, University of North Carolina at Chapel Hill, 2004.[Wernecke94] J. Wernecke, The Inventor Mentor, Release 2, ISBN 0-201-62495-8, Addison-Wesley,Boston, 1994.8

AbbildungsverzeichnisAbbildungsverzeichnisAbbildung 1: Lesegraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Abbildung 2: Reality-Virtuality Continuum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Abbildung 3: Die drei Is der Virtual Reality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Abbildung 4: Optical-See-Through-System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Abbildung 5: Video-See-Through-System mit Kopftracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Abbildung 6: Video-See-Through-System mit Markererkennung . . . . . . . . . . . . . . . . . . . . . . . . 34Abbildung 7: Amires Rollenverteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Abbildung 8: PIP ohne und mit Interaktionskomponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Abbildung 9: Direkte Manipulation virtueller Objekte mit getracktem Handschuh . . . . . . . . . 42Abbildung 10: Entwicklungsebenen, Rollen und Use-Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Abbildung 11: Die mare-Handhaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Abbildung 12: Das Aktivieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Abbildung 13: Eine Hand mit Gestencursor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Abbildung 14: Die mare-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Abbildung 15: Überdeckung von AR-Objekten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Abbildung 16: Darstellungsreihenfolge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Abbildung 17: Szenegraphdiagramm von MareSceneKit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Abbildung 18: Die MareSceneKit-Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Abbildung 19: Panel mit Interaktionskomponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Abbildung 20: Ergebnisse des experimentellen Prototypings . . . . . . . . . . . . . . . . . . . . . . . . . . 72Abbildung 21: Aufbau des GuiKit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Abbildung 22: Schnittstelle von GuiKit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Abbildung 23: Die Klasse Container . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Abbildung 24: Panel vor inhomogenem Hintergrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Abbildung 25: Szenegraphdiagramm von Label . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Abbildung 26: Die Klassen Panel und Label . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Abbildung 27: Die drei Zustände von Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Abbildung 28: Die Klasse Responder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Abbildung 29: Die Transitionen zwischen den drei Zuständen eines Responders . . . . . . . . . . 82Abbildung 30: Szenegraph von Button . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Abbildung 31: Die Klasse Button . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Abbildung 32: CheckBox und RadioButton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Abbildung 33: Schnittstellen von CheckBox und RadioButton . . . . . . . . . . . . . . . . . . . . . . . . . . 86Abbildung 34: Die Interaktionskomponente Rotor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Abbildung 35: Die Klasse Rotor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Abbildung 36: Interaktion mit dem Rotor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Abbildung 37: Ereignisverteilung mit EventProvidern und Listenern . . . . . . . . . . . . . . . . . . . . . 91Abbildung 38: Implementierung des Observer-Pattern als Template-Klassen . . . . . . . . . . . . . 929

AbbildungsverzeichnisAbbildung 39: Implementierung der Ereignisbehandlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Abbildung 40: Ereignisweiterleitung am Beispiel eines Buttons . . . . . . . . . . . . . . . . . . . . . . . . 94Abbildung 41: Schnittstelle der Klasse Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Abbildung 42: Histogrammindices für den Kantenkontext eines Punktes . . . . . . . . . . . . . . . . . 114Abbildung 43: Kantenkontext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Abbildung 44: Formkontext und Kantenkontext kombiniert . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Abbildung 45: Hand mit erfolgreich angepasstem Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118Abbildung 46: Gabor Wavelet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119Abbildung 47: Gabor Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Abbildung 48: Bestandteile eines Bunchjets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Abbildung 49: Aufbau eines Bunchgraphtemplates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Abbildung 50: Parameterraum eines Verschiebungsfunktors . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Abbildung 51: Parameterraum eines Skalierungsfunktors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Abbildung 52: Rechtecknummerierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Abbildung 53: Freiheitsgrade einer Hand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Abbildung 54: Extremformen einer Hand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133Abbildung 55: Alternierende Nummerierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Abbildung 56: Bubblebijektion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Abbildung 57: Compositenummerierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Abbildung 58: Bilder einer Videosequenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Abbildung 59: Ähnlichkeitsfunktionsantworten I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146Abbildung 60: Ähnlichkeitsfunktionsantworten II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147Abbildung 61: Ähnlichkeitsfunktionsantworten III . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147Abbildung 62: Häufigkeitsverteilung der Ähnlichkeitsfunktionsantworten II und III . . . . . . . . . 148Abbildung 63: Trackingzustände . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150Abbildung 64: Bereiche für korrekte Erkennung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Abbildung 65: Beispiele aus der Testsequenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154Abbildung 66: Erkennungsgenauigkeit für die Zeigefingerspitze . . . . . . . . . . . . . . . . . . . . . . . 154Abbildung 67: Klassendiagramm Graph und BunchGraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159Abbildung 68: Klassendiagramm Functor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160Abbildung 69: Klassendiagramm Estimator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163Abbildung 70: Klassendiagramm MatchingStep, Optimizer und Matching . . . . . . . . . . . . . . . 165Abbildung 71: Objektdiagramm MatchingStep, Optimizer und Matching . . . . . . . . . . . . . . . 167Abbildung 72: Sequenzdiagramm Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168Abbildung 73: Klassendiagramm GestureRecognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170Abbildung 74: Screenshot aus der Anwendung mit Ausbaupfad und Button . . . . . . . . . . . . . 174Abbildung 75: Klassendiagramm der Beispielapplikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17510

TabellenverzeichnisTabellenverzeichnisTabelle 1: Auszeichnungsformen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Tabelle 2: Ereignistypen in mare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Tabelle 3: Funktionale Anforderungen an das umzusetzende Erkennungsverfahren . . . . . . . 105Tabelle 4: Nicht-funktionale Anforderungen an das umzusetzende Erkennungsverfahren . . . 105Tabelle 5: Erkennungsergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Tabelle 6: Die besten gefundenen Anpassungsschritte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15611

DefinitionsindexDefinitionsindexAbbruchbedingung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144adjustTemplate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Ähnlichkeitsfunktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Aktivieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51alternierende Nummerierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47AR-Objekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Ausgangsposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Aussparobjekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Bunchgraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Bunchgraphtemplate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Bunchjet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Compositenummerierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Darstellungskomponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Diffusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132erforschende Nummerierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Erforschung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Erforschungsindex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Funktor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127Gabor Jet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Gabor Wavelet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119Gesamtparameterraum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138Gestencursor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Graphtemplate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118Graphübereinstimmung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118Hochskalieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136Initialbedingung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Interaktionskomponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Interaktionsschnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Kante eines Bunchgraphen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Kante eines Graphen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118Kantenkontext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Knoten eines Bunchgraphen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Knoten eines Graphen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118Konstrukt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44lokalen Bildeigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11812

Definitionsindexmare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47mare-Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47mare-Anwendungs-Use-Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48mare-Anwendungsinstanz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48mare-Entwickler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47mare-Environment-Use-Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47mare-Geste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52mare-Handhaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Parameterortsvektor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Parameterraum einer Transformationsfunktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Parametervektor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Position eines Graphen in einem Parameterraum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Rolle Anwendungsentwickler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Rolle mare-Anwendungsentwickler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Rolle Monteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Selektion und Manipulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Systemsteuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Szeneobjekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Szeneobjekt als Konstrukt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61TemplateAnpassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138Transformationsfunktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Transformationsparameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126upscale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136VR-Objekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Zeigen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5113

DanksagungenWir danken Prof. Dr. Fanny-Michaela Reisin und Dipl.-Inf. Andreas Romahn fürdie konstruktive Betreuung der Diplomarbeit und fachliche Unterstützung undProf. Dr. Heinrich P. Godbersen für strukturelle Anregungen.14

KonventionenVerwendete AuszeichnungsformenNormaler Text, mathematischeFunktionenBetonter Text,mathematische Variablen,Marken-, Produkt- undFirmennamenKlassen, Attribute, OperationenEinführung vonKlassenTabelle 1: AuszeichnungsformenFontAvenir Light,11 PunktAvenir Light oblique,11 PunktCourier,11 PunktCourier halbfett,11 PunktBeispielWenn Fliegen hinterFliegen fliegen, fliegenFliegen Fliegen nach.Das heißt: Wenn nFliegen hinter m Fliegenfliegen, fliegen n Fliegenm Fliegen nach.ResponsivePanelResponsivePanelDefinitionen werden in der folgenden Form dargestellt:Eine Definition ist die genaue Bestimmung eines Begriffes durchBeschreibung seines Inhalts. Eine Definition wird in einen Kasten,wie den diese Definition umschließenden, eingefasst und das definierteWort wird fett und kursiv hervorgehoben.SpracheSoweit eingängige deutsche Übersetzungen englischer Fachbegriffe existieren,verwenden wir diese.Der besseren Lesbarkeit halber verwenden wir für die dritte Person Singular nurdie männliche Form, womit aber jedesmal ein Mensch beliebigen Geschlechtsgemeint ist.15

Die Verwendung des Wortes »wir« deutet auf eine von den Autoren dieserArbeit eingeführte Bezeichnung oder gewählte Vorgehensweise hin und ist nichtder einbeziehende Plural.DiagrammeDie dargestellten UML-Klassendiagramme zeigen der besseren Verständlichkeitwegen nur die entwurfsrelevanten Attribute und Operationen, Implementierungsdetailsbleiben verborgen. So wurden auch C++ Storage- und Accessmodifierweggelassen. Klassen, die nicht Bestandteil von mare, sondernvon verwendeten Bibliotheken sind, werden in den UML-Klassendiagrammen mitgrauem Hintergrund dargestellt.Im Teil Interaktionsschnittstelle werden Szenegraphdiagramme eingesetzt, die inAnhang C beschrieben werden.BegriffeDer Begriff »Objekt« wird in dieser Arbeit in drei Bedeutungen verwendet:Objekt im softwaretechnischen Sinne, Objekt der stofflichen Welt und Objektder Computergrafik. Um die verschiedenen Bedeutungen des Wortes »Objekt«klar zu trennen, verwenden wir an den Stellen, an denen Missverstände auftretenkönnten, die eindeutigen Begriffe »Softwareobjekt« für Objekte im softwaretechnischenSinne, »Realobjekt« für Objekte der stofflichen Welt und »VR-Objekt« für Objekte der Computergrafik.Der Begriff »Tracking« wird sowohl in der Augmented Reality als auch in derComputer Vision verwendet. Um zwischen den unterschiedlichen Bedeutungenzu unterscheiden, verwenden wir für das Tracking im Sinne der AugmentedReality immer den Begriff »AR-Tracking«. Wenn »Tracking« für sich steht, ist dasTracking im Sinne der Computer Vision gemeint.Weiterhin sei darauf hingewiesen, dass der Begriff »Modell« in drei Bedeutungenverwendet wird: Modell im softwaretechnischen Sinne, Modell eines VR-Objekts und Modell einer Gestik. Da die jeweilige Bedeutung durch den Kontexteindeutig ist, verwenden wir jedesmal den Begriff »Modell«.16

Einleitung

1 Einleitung1 EinleitungTechnische Anlagen, Maschinen und Geräte werden zunehmend komplexer undexistieren auf Grund sich verkürzender Entwicklungszyklen in immer größererModellvielfalt. Heute sind Produktion und Montage größtenteils automatisierteProzesse, wohingegen Reparatur und Demontage noch weitgehend manuelleTätigkeiten erfordern.Während spezialisierte Maschinen bei der Produktion für ein Modell konfiguriertwerden können, erfordern Demontage und Reparatur größere Flexibilität. Dadiese Art von Arbeit noch nicht von Maschinen erbracht werden kann, kommtder manuellen Demontage besonderes Gewicht zu – und damit auch dereninformationstechnischer Unterstützung. Dabei stellt die Augmented Reality einevielversprechende Schlüsseltechnologie dar.Im Gegensatz zur Virtual Reality, die einen Menschen in eine vollständig computergenerierteUmgebung versetzt, wird in der Augmented Reality die Sicht desMenschen auf die Realität um virtuelle Objekte erweitert – die Realität wird mitvisuellen Informationen angereichert (augmented). Zum Beispiel könnenTechnikern bei der Flugzeugwartung Kabelverläufe angezeigt werden, was denVerzicht auf Pläne möglich macht. Die Techniker sehen die Kabel wie durch eineRöntgenbrille auch hinter Verkleidungen.Für eine effektive Unterstützung des Menschen ist es notwendig, dass dieser mitdem Augmented-Reality-System interagieren kann, um zum Beispiel die Auswahlder visualisierten Informationen beeinflussen zu können. Diese Systemsteuerungund ihre Realisierung durch eine Benutzerschnittstelle ist ein kritischer Bestandteilvon Augmented-Reality-Anwendungen. Deswegen muss ein besonderesAugenmerk auf das Design der Benutzerschnittstelle und auf die verwendeteInteraktionstechnik gerichtet werden.Im Gegenssatz zu üblichen Computerschnittstellen ist in der Augmented Realityzu beachten, dass der Mensch auch mit Gegenständen der Realität interagierenmuss. Die Interaktionstechnik des Augmented-Reality-Systems darf ihn dabeinicht einschränken.In dieser Arbeit wird eine gestenbasierte Interaktionstechnik vorgestellt, die erstmaligin der Augmented Reality die Systemsteuerung ohne behindernde Zusatzgeräteermöglicht.19

1 Einleitung1.1 Aufbau der ArbeitDiese Arbeit ist in Einleitung, vier Hauptteile und Schluss gegliedert.Abbildung 1 zeigt diese Teile in einem Lesegraph.Abbildung 1: LesegraphHauptteil II und Hauptteil III können unabhängig voneinander gelesen werden,bauen aber auf Hauptteil I auf. Für das Verständnis der Beispielanwendung inHauptteil IV sollte Hauptteil II gelesen worden sein.Im Anschluss an dieses Kapitel folgt eine Einführung in mare, die ein beispielhaftesAnwendungsszenario präsentiert.Hauptteil I beginnt mit dem 3. Kapitel. In diesem wird der Gegenstandsbereichdieser Arbeit in das fachliche Umfeld eingeordnet und der Stand der Forschungund Entwicklung skizziert. Weiterhin wird die Aufgabenstellung definiert und eswerden die für die Lösungsfindung und -umsetzung verwendeten Methoden,Werkzeuge und Bibliotheken genannt. Das darauf folgende Kapitel enthält Vorüberlegungenbezüglich der Entwicklungsebenen und Rollen, eine Beschreibungder verwendeten mare-Geste sowie einen Überblick über die Architektur vonmare.20

1 EinleitungHauptteil II behandelt die Interaktionsschnittstelle mit ihren grafischen und interaktivenBestandteilen. Kapitel 5 enthält die Definition der Anforderungen an dieInteraktionsschnittstelle. In den beiden darauf folgenden Kapiteln werden dieDarstellungs- und Interaktionskomponenten sowie die Ereignisbehandlung beschrieben.Hauptteil III stellt die Gestenerkennung dar und beginnt mit Kapitel 8. In diesemwerden die Anforderungen an das Gestenerkennungsverfahren festgelegt undauf diese Bezug nehmend zwei mögliche Verfahren ausgewählt, die in den darauffolgenden zwei Kapiteln untersucht werden.Hauptteil IV präsentiert in Kapitel 11 eine Beispielanwendung, die dasAnwendungsszenario aus der Einführung umsetzt, und bietet so einen Überblicküber die Nutzung von mare.Im Schlussteil, beginnend mit Kapitel 12, wird die Arbeit zusammengefasst undein Ausblick auf mögliche zukünftige Entwicklungsrichtungen gegeben sowie einabschließendes Resümee gezogen.21

2 Einführung in mare2 Einführung in mareIn diesem Kapitel wird ein einfaches Anwendungsszenario dargestellt, das eineninformellen und intuitiven Zugang zum Einsatz von mare ermöglicht.Bei dem Anwendungsszenario handelt es sich um die Demontage einer Waschmaschine.Im Allgemeinen steht für die Demontage eines Gerätes eine Demontagesequenzzur Verfügung, die die Demontageschritte beschreibt. Durch denEinsatz von Augmented Reality können einem Monteur während der Demontagefür jeden Demontageschritt die notwendigen Informationen zur Verfügunggestellt werden. In diesem Anwendungsszenario sind die Demontageinformationendas nächste zu demontierende Bauteil und der Ausbaupfad, dem entlangdas Bauteil geführt werden muss.Nebenstehend ist ein Monteur bei Verwendungeines AR-Systems zu sehen. Er hateine AR-Brille aufgesetzt und hinter ihmsteht eine zu demontierende Waschmaschine.22

2 Einführung in mareDie AR-Brille, durch die der Monteur dieUmwelt visuell wahrnimmt, ist ein sogenanntesVideo-See-Through-System. In dieVorderseite der AR-Brille ist eine Videokameraintegriert. Diese nimmt Videobilderaus der Perspektive des Monteurs auf, dieihm über die eingebauten Bildschirmegezeigt werden.Die aufgenommenen Videobilder könnenvon dem Computer des AR-Systems analysiertund angereichert werden:Dieser sucht in den Bildern nach dem ander Waschmaschine angebrachten schwarzenQuadrat, welches als »Marker« bezeichnetwird. Die gefundene Bildpositiondes Markers, dessen Größe und perspektivischeVerzerrung ermöglichen es, die Videobilderperspektivisch korrekt mit denDemontageinformationen anzureichern.23

2 Einführung in mareDie angereicherten Bilder werden demMonteur durch die Bildschirme der Brilleangezeigt.Neben der Markierung des nächsten auszubauendenBauteils und dessen Ausbaupfadsieht der Monteur links oben im Videobildeinen Button, über den er später dieInformationen für den nächsten Demontageschrittanfordern kann.Der Monteur kann, durch die Demontageinformationenunterstützt, das Bauteil ausbauen.Dabei folgt er dem angezeigtenAusbaupfad.Nach dem Ausbau des Bauteils muss derMonteur beim nächsten Demontageschrittunterstützt werden. Er muss dem AR-Systemalso mitteilen, dass die Informationenfür den nächsten Demontageschritt angezeigtwerden sollen. Mit mare kann dieseSystemsteuerung auf folgende Weise realisiertwerden:24

2 Einführung in mareZur Interaktion mit dem System hält derMonteur seine Hand wie in nebenstehenderAbbildung vor die Kamera der Brille.Dabei hat die Hand die gezeigte Haltung.An der Stelle der Hand wird ein kreisförmigerCursor angezeigt. Der Cursor folgtden Handbewegungen des Monteurs: seinDurchmesser und seine Bildposition werdendurch die Stellung von Daumen- undZeigefingerspitze bestimmt.Wenn der Monteur seine Hand in dieserHaltung über den Button bewegt, leuchtetdieser auf.Um den Button zu betätigen, führt er Daumen-und Zeigefingerspitze zusammen, alswürde er etwas greifen. Der Button ändertdadurch seine Farbe, und die mit ihm verbundeneFunktion wird ausgeführt – ähnlicheines Mausklicks auf einen Button in einemWindows-Programm.Durch die beschriebene Geste hat derMonteur den Button betätigt und so dasAR-System veranlasst, die Informationenfür den nächsten Demontageschritt anzuzeigen.Der Monteur kann die Demontagefortsetzen.25

Hauptteil IGrundlagen

3 Fachliches Umfeld und Aufgabenstellung3 Fachliches Umfeld und AufgabenstellungDer Gegenstandsbereich dieser Arbeit ist die Systemsteuerung von AR-Anwendungen, die mit Video-See-Through-Systemen verwendet werden.Im nächsten Abschnitt wird dieser Gegenstandsbereich thematisch in das fachlicheUmfeld eingeordnet. Dazu wird das Verhältnis von Augmented Reality undVirtual Reality beschrieben und Video-See-Through-Systeme mit Optical-See-Through-Systemen verglichen. Weiterhin wird die Systemsteuerung als eine derInteraktionsaufgaben in dreidimensionalen Umgebungen vorgestellt sowie einÜberblick über Interaktionsgeräte für die Augmented Reality gegeben.Im darauf folgenden Abschnitt wird der Stand der Technik skizziert, dann dieAufgabenstellung dieser Arbeit festgelegt und schließlich werden die für die Lösungsfindungund -umsetzung verwendeten Methoden, Werkzeuge und Bibliothekenaufgeführt.3.1 Fachliches Umfeld3.1.1 Einordnung der Augmented RealityDie Augmented Reality ist verwandt mit der Virtual Reality. Um das Verhältniszwischen diesen beiden Begriffen festzulegen, hat [MTUK94] den Begriff »Reality-VirtualityContinuum« geprägt. Dieses Kontinuum wird auch häufig mit demNamen des ersten Autors von [MTUK94] bezeichnet: »Milgram-Continuum«.Abbildung 2: Reality-Virtuality Continuum(Vgl. [MTUK94])Abbildung 2 zeigt das Kontinuum 1 . An den gegenüberliegenden Seiten liegenReality (im Folgenden Realität) und Virtuality (im Folgenden Virtualität), die das1 In der Originaldarstellung sind die Grenzen, des Kontinuums mit »Real Environment« und»Virtual Environment« bezeichnet. Wir vermeiden den Begriff »Environment« an dieser Stelleum Missverständnissen mit dem softwaretechnischen Begriff »Environment« vorzubeugen. In[MTUK94] werden die Begriffe »Reality« und »Real Environment« beziehungsweise »Virtuality«und »Virtual Environment« synonym verwendet.29

3 Fachliches Umfeld und AufgabenstellungKontinuum begrenzen. Der Bereich des fließenden Übergangs von der Realitätin die Virtualität wird als Mixed Reality bezeichnet. Die Augmented Virtuality isteine Form der Mixed Reality, die näher an der Virtualität einzuordnen ist, währenddie Augmented Reality näher an der Realität liegt. Im Folgenden wirdnäher auf die einzelnen Begriffe eingegangen.Realität (Reality)Mit Realität ist die reale Welt gemeint, die (natürlich) den physikalischenGesetzen folgt.Virtualität (Virtuality)Die Virtualität, auch Virtual Reality genannt, istim Gegensatz zur Realität komplett synthetischund wird durch einen Computer erzeugt, der einModell für die erzeugte Welt haben muss. DiesesModell kann entweder der realen Welt nachempfundensein oder es ist eine Phantasiewelt,in der auch andere »Natur«- gesetze gelten können.Abbildung 3: Die drei Is der VirtualRealityVirtual-Reality-Systeme lassen sich anhand der sogenannten drei Is beschreiben:Immersion, Interaktion, Imagination (Abbildung 3).ImmersionMit Immersion wird das Eintauchen eines Menschen in die Virtualität, das Erlebnisin der virtuellen Welt zu sein, bezeichnet.Um Immersion zu erreichen sind Ausgabegeräte notwendig, die die Sinne desMenschen anregen. Der wichtigste Sinn für das Erreichen von Immersion ist derSehsinn. Ausgabegeräte, die diesen Sinn anregen, sind zum Beispiel HeadMounted Displays (HMDs). Das sind Bildschirme, die so am Kopf des Menschenbefestigt werden, dass sie direkt vor dessen Augen sind. Ein weiteres Ausgabegerätfür den Sehsinn ist die Cave, auch Cube genannt, bei der der Mensch sichin einem Raum befindet, dessen Wände Rückprojektionsflächen sind, auf die von30

3 Fachliches Umfeld und Aufgabenstellungaußen Bilder projiziert werden. Die Immersion ist für den Menschen besondershoch, wenn ihm stereoskopische Bilder präsentiert werden. Bei den HMDs kanndies realisiert werden, indem separate Bildschirme für die Augen zwei unterschiedlicheBilder zeigen. In der Cave kann mit polarisiertem Licht zur Projektionund einer Brille mit Polarisationfiltern gearbeitet werden.InteraktionInteraktion bedeutet, dass der Mensch auf die virtuelle Welt Einfluss nehmenkann. Die Interaktion ist gut, wenn sie für den Menschen intuitiv ist. Dies ist dannder Fall, wenn sie der Interaktion in der Realität entspricht. Intuitive Interaktionist aber auch möglich, wenn andere Interaktionstechniken verwendet werden.Beispielsweise wurde in [PBWI96] die sogenannte »Go-Go-Interaktionstechnik«entwickelt, bei der die Idee eines verlängerbaren Armes umgesetzt wird, indemder Abstand einer virtuellen Hand vom Körper des Menschen durch eine nichtlineareFunktion aus dem Abstand der reellen Hand vom Körper abgeleitet wird.Die wichtigste Interaktionsart ist die Möglichkeit, dass der Mensch seine Positionin der virtuellen Welt verändern kann. Dafür sind unterschiedliche Interaktionstechnikenmöglich, die auf unterschiedlichen Interaktionsgeräten basieren. Beispielsweisegibt es die Möglichkeit, dass der Mensch seine Position in der virtuellenWelt ändert, indem er seine reale Position verändert. Um die reale Positionermitteln zu können, sind Interaktionsgeräte, wie magnetische oder optischeTracker, notwendig. Der Mensch könnte seine Position auch durch Verwendungeiner indirekten Interaktionstechnik verändern, die zum Beispiel auf einer normalenComputer-Maus als Eingabegerät basiert.ImaginationMit Imagination wird das Erlebnis des Menschen bezeichnet, nicht nur in, sondernTeil der Virtualität zu sein. Imagination entsteht, wenn zur Immersion dieMöglichkeit der Interaktion tritt. Je höher die Imagination, desto stärker empfindetein Mensch die virtuelle Welt als seine Wirklichkeit.31

3 Fachliches Umfeld und AufgabenstellungAugmented VirtualityDie Augmented Virtuality ist Teil der Mixed Reality und bedeutet, dass die Virtualitätmit Anteilen der Realität angereichert wird. Ein mögliches Einsatzgebietist zum Beispiel bei Flugzeugherstellern zu finden: Da die Kosten für Flugzeugederart hoch sind, dass keine Ausstellungsmodelle wie von Autos zur Verfügungstehen, besteht die Notwendigkeit des Einsates von Virtual Reality, um Kundendie Ausstattung ihres Flugzeuges zu präsentieren. Dabei besteht die Anforderung,dass die virtuelle Darstellung so realistisch wie möglich erscheint. Um dieszu erreichen, werden Fotos von realen Sitzbezügen, Teppichen und so weiter alsTexturen in der Virtualität verwendet.Augmented RealityDie Augmented Reality ist auch Teil der Mixed Reality und bedeutet, dass dieRealität mit Anteilen der Virtualität angereichert wird. Einsatzgebiete sind zumBeispiel in der Medizin, Montage, Routenplanung, Unterhaltung und dem Militärzu finden. Je nach Einsatzgebiet gibt es viele Möglichkeiten, die Realität mit Virtualitätanzureichern. Zu nennen sind zum Beispiel Projektionen auf den Körpereines Patienten, die einem Arzt beispielsweise die Lage der inneren Organe undder durchzuführenden Schnitte anzeigen können. Eine Form von Augmented Realitysind auch die sogenannten Head Up Displays (HUDs), die einem FlugzeugpilotenInformationen wie Höhe, Treibstoffvorrat etc. in sein Gesichtsfeld einspiegeln.Im Kontext dieser Arbeit sind nur die Head Mounted Displays, auch Head WornDisplays genannt, für die Augmented Reality von Interesse, die im nächsten Abschnittvorgestellt werden.3.1.2 Head Mounted Displays für die Augmented RealityBei den Head Mounted Displays wird zwischen den Optical-See-Through- undden Video-See-Through-Systemen unterschieden.32

3 Fachliches Umfeld und AufgabenstellungOptical-See-Through-SystemeAbbildung 4 zeigt den Aufbau eines Optical-See-Through-Systems. Der Menschhat einen unvermittelten Blick auf die reale Welt. Damit virtuelle Objekte für denMenschen sichtbar gemacht werden können, schaut dieser durch halbdurchlässigeSpiegel (je Auge einen), die in der Abbildung als »Optical combiners«bezeichnet werden. Diese spiegeln Monitorbilder in das Bild der realen Welt ein.Durch Verwendung der Spiegel wird die Menge des Lichts, die die Augen desMenschen erreicht, eingeschränkt.Damit die Bilder, die die Monitore zeigen, an die Position des Menschen in derrealen Welt angepasst werden können, ist ein Tracker, der die Position desKopfes bestimmt, Teil des Optical-See-Through-Systems. Die von diesemermittelten Positionsdaten werden von dem Computer genutzt, der die über dieMonitore anzuzeigende virtuelle Szene generiert.Abbildung 4: Optical-See-Through-System(Abbildung aus [Azuma97])Video-See-Through-SystemeAbbildung 5 zeigt den Aufbau eines Video-See-Through-Systems. Im Gegensatzzum Optical-See-Through-System hat der Mensch dabei nur einen, durch Monitorevor seinen Augen, vermittelten Blick auf die reale Welt. Damit in den Monitorenein Bild der realen Welt angezeigt werden kann, ist eine Kamera oder sindzwei Kameras für stereoskopisches Sehen Teil des Systems. Die von der Kamerabeziehungsweise den Kameras aufgenommenen Videobilder werden mit dencomputergenerierten Bildern zusammengefasst und über die Monitore ausgegeben.33

3 Fachliches Umfeld und AufgabenstellungAbbildung 5: Video-See-Through-System mit Kopftracking(Abbildung aus [Azuma97])Damit die computergenerierten Bilder der Position des Menschen in der realenWelt angepasst werden können, gibt es zwei Möglichkeiten. Zum einen kann,wie bei den Optical-See-Through-Systemen, ein Tracker für die Kopfpositionverwendet werden (Abbildung 5), oder es kann ein Ansatz gewählt werden, derauf der Erkennung von Markern basiert (Abbildung 6).Abbildung 6: Video-See-Through-System mit Markererkennung(Abbildung 5 modifiziert)Dafür müssen Marker in der Umgebung des Menschen angebracht werden, diedurch eine Markererkennung in den Bildern der Videokamera gefunden werden.[KBWF99] beschreibt, wie aus der Position, Größe, Verzerrung eines Markerabbildsim Videobild die Position des Markers relativ zur Kamera berechnet werdenkann. Mit dieser Information und dem Wissen, wo in der Realität die Marker angebrachtsind, kann die Markererkennung die Kopfposition errechnen, die vomComputer für die Generierung der Szene genutzt wird.34

3 Fachliches Umfeld und Aufgabenstellung3.1.3 Systemsteuerung als Interaktionsaufgabe[BKLP01] unterscheidet zwischen folgenden Interaktionsaufgaben bei dreidimensionalenBenutzerschnittstellen: Navigation, Selektion und Manipulation, Systemsteuerung.NavigationDie Navigation ist eine Interaktionsaufgabe, deren Ziel es ist, dieBetrachterposition zu verändern.Nach [BKLP01] ist die Navigation die gängigste Interaktionsaufgabe in den meistengroßen dreidimensionalen Umgebungen.Da in der Augmented Reality Realitätund Virtualität überlagert werden, kann die Navigation nur durch physischeBewegung des Menschen erfolgen. Navigationstechniken, wie sie in der VirtualReality möglich sind, beispielsweise Navigation durch Handbewegungen, sindausgeschlossen.Selektion und ManipulationDie Selektion und Manipulation ist eine Interaktionsaufgabe, derenZiel es ist, Objekte zu selektieren, zu positionieren und zu rotieren.In der Augmented Reality kann Objekt sowohl Realobjekt, wie auch VR-Objektheißen. Mit Realobjekten kann wie gewohnt interagiert werden. Für VR-Objekteist nach [BKLP01] der klassische Ansatz, den Menschen mit einer virtuellen Handauszustatten. Das ist ein 3D-Cursor, häufig geformt wie eine menschliche Hand,dessen Bewegungen von denen eines Hand-Trackers abhängen.SystemsteuerungDie Systemsteuerung ist eine Interaktionsaufgabe, bei der eineAnweisung ausgeführt wird, um entweder den Zustand des Systemsoder den Interaktionsmodus zu verändern.Ein typisches Beispiel für die Systemsteuerung ist das Anwendungsszenario ausder Einführung. Dort werden die virtuellen Objekte (Bauteilmarkierung und Aus-35

3 Fachliches Umfeld und Aufgabenstellungbaupfad) nicht direkt, sondern durch Änderung des Systemzustandes verändert.(Der Systemzustand ist der aktuelle Demontageschritt.)3.1.4 Interaktionsgeräte für die Augmented RealityDie in der Augmented Reality verwendeten Interaktionsgeräte sind zum einenaus Virtual Reality Systemen übernommen und zum anderen aus den technischenGegebenheiten der AR-Systeme und den veränderten Anforderungen vonAR-Anwendungen neu entwickelt worden.Wie in der Virtual Reality finden traditionelle Geräte aus dem Desktopbereichwie Maus, Tastatur und Joystick keine Verwendung.Ausnahme bildet die Tastatur, die in einer Abwandlung in einer speziellen verkleinertenVariante für die Anbringung am Arm vorliegt. Problematisch ist dieungewohnte Körperhaltung bei der Eingabe und das unter Umständen negativauf die Bewegungsfreiheit wirkende Vorhandensein der Tastatur selbst – unabhängigvon deren Benutzung.Im Folgenden wird ein Überblick über die in AR-Anwendugen anzutreffendenGeräte gegeben:DatenhandschuheZu den aus der Virtual Reality bekannten Geräten gehören die verschiedenenVarianten der Datenhandschuhe, die auf vielfältige Art zur Systemsteuerungverwendet werden können. Datenhandschuhe messen die Haltung der Finger,um daraus Gesten abzulesen.Eine Variante arbeitet mit Licht, das durch in den Handschuhfingern eingearbeiteteGlasfaserschlaufen gesendet wird und je nach Fingerstellung die Lichtstärkeverändert. Die Messung der Lichtstärke ermöglicht eine Modellierung von Handgesten.Eine andere Art der Datenhandschuhe besteht aus einem mechanischen Exoskelettfür die Hand, das für jeden Benutzer angepasst und kalibriert werden muss.Auch dieses ermöglicht die Erfassung der Fingerstellung und deren Abbildungzu Handgesten.36

3 Fachliches Umfeld und AufgabenstellungDer Pinchglove ist ein Handschuh, an dessen Fingerkuppen elektrische Kontakteangebracht sind. Durch das Zusammenführen des Daumens mit den anderenFingerspitzen lassen sich unterschiedliche Selektionssignale erzeugen.Um mit Datenhandschuhen direkt manipulativ zu arbeiten, werden sie häufig inVerbindung mit magnetischem Tracking eingesetzt. Dieses dient der Bestimmungvon Position und Lage der Hand im Raum, was ein direktes Selektierenund Interagieren mit virtuellen Objekten ermöglicht.3D-Maus/Magic WandDie Funktionsweise der 3D-Maus entspricht herkömmlichen 2D-Mäusen mit derErweiterung auf sechs Freiheitsgrade. Üblicherweise verfügt eine 3D-Maus überein magnetisches Trackingsystem zur Positions- und Lagebestimmung im Raumund eine oder mehrere Tasten zur Aktivierung von Funktionen. Mit diesem Interaktionsgerätwerden in vielen VR-Anwendugen sowohl Selektion und Manipulation,als auch Navigation durchgeführt. Zur Navigation kann die Maus auf ein Zielgerichtet werden und dann mit einer Taste eine Kamerafahrt in die gezeigteRichtung begonnen werden.Pen and Tablet/Personal Interaction PanelDas Personal Interaction Panel [SG97] besteht aus zwei unabhängig voneinandergehaltenen Teilen eines Interaktionsgerätes, bei dem mit einem Stift auf ein Tablettprojizierte Interaktionskomponenten gesteuert werden. Die Raumlage vonTablett und Stift wird durch optisches oder magnetisches Tracking bestimmt.Der Vorteil gegenüber einer 3D-Maus oder einem getrackten Handschuh ist,dass mit dem Stift das haptisch wahrnehmbare Tablett berührt wird. Der Benutzerhat so nicht das Gefühl, mit dem leeren Raum zu interagieren.Das Tablett eignet sich sehr gut für Systemsteuerungsaufgaben – es ähnelt einerSchalttafel, bei der die Bedienelemente virtuelle Objekte sind. Zur Interaktionsind beide Hände notwendig.37

3 Fachliches Umfeld und AufgabenstellungVerwendbarkeit in der Augmented RealityDie vorgestellten Geräte basieren alle auf Hardware, die in die Hand genommen(3D-Maus, Magic Wand) oder bei Pinchglove und Datenhandschuh angezogenwerden muss. Dies schränkt den Benutzer bei der Interaktion mit nicht virtuellenGegenständen ein.Die Kombination mit einem Magnetfeldtracker beschränkt den Aktionsradius aufGrund der Reichweite des Magnetfeldes und der Verkabelung der Sensoren.Sprache mittels MikrophonDie Sprachsteuerung nimmt eine Sonderstellung ein – sie ist weder im Desktopbereichnoch im VR-Bereich verbreitet. Es ist noch nicht abzusehen, welche Rollesie in der Augmented Reality spielen wird. Vorteil der Sprachsteuerung ist, dassdafür nur ein Mikrofon notwendig ist und sonst keine einschränkende Technikverwendet werden muss. Ein Nachteil der Sprachsteuerung ist, dass Befehlenicht einfach ausgewählt werden können, sondern vorher erlernt werden müssen,und dass sie abhängig von Umgebungsgeräuschen ist.3.2 Stand der TechnikIm Folgenden wird ein Überblick über andere AR-Environments gegeben. DieÜberschneidungen mit mare sind allerdings gering, da entweder die Systemsteuerungvon AR-Anwendungen gar nicht betrachtet wird oder wenn, dann unterVerwendung zusätzlicher Interaktionsgeräte.3.2.1 DWARF – Distributed Wearable Augmented Reality FrameworkIn »Design of a Component-Based Augmented Realty Framework«[BBKMRRSW01] beschreiben Bauer u.a. das an der Technischen UniversitätMünchen entwickelte AR-System DWARF.Das primäre Ziel des Projektes ist die Entwicklung einer Plattform zur Erforschungvon Augmented Reality mit tragbaren Computern 2 . Es soll ein Rapid Pro-2 engl. »wearable Computer«38

3 Fachliches Umfeld und Aufgabenstellungtotyping-System entstehen, mit dem schnell neue Ideen in der AR-Forschunggetestet werden können.Um diese Ziele zu realisieren wurde ein komponentenbasiertes Softwareframeworkentwickelt, das die anfallenden Aufgaben der AR umsetzt. In diesemFramework besteht ein AR-System aus einem heterogenen, dynamischen Netzwerkin dem wiederverwendbare Dienste durch Manager verwaltet werden. JederDienst ist ein Prozess, der potentiell auf einer separaten Hardwarekomponentelaufen kann und eine bestimmte Funktion anbietet oder benötigt. Um dieDienste einfach kombinierbar zu machen, werden sie in Modulen gebündelt, dieHard- und Software zusammenfassen.In DWARF gibt es die Module TrackingModule, UserApplicationModule und InteractionModule.3.2.2 amire – Authoring Mixed RealityDas amire Projekt wird als EU Projekt von verschiedenen Partnern aus Industrieund Forschung entwickelt [Amire04]. Kern des Projektes ist es, ein System zuschaffen, das nicht nur von Experten benutzbar ist, sondern das es als Autorenumgebungermöglicht, dass Entwickler aus anderen Forschungsfeldern dieMixed Reality in ihren Projekten verwenden können.Zu diesem Zweck wird ein Framework entwickelt, das verschiedene Komponentenanbietet, die in einer AR-Anwendung benötigt werden. Diese Komponentenlassen sich durch die Autorenumgebung anordnen, parametrisieren und verbinden.Abbildung 7: Amires Rollenverteilung39

3 Fachliches Umfeld und AufgabenstellungAußerdem sollen innerhalb des Projektes die vielen Ansätze, die für die MixedReality entwickelt wurden, zusammengeführt und so Synergieeffekte ausgenutztwerden. Dies wird anhand einer Datenbank erreicht, die AR-Ansätze, Systemeund Hardwarekomponenten (in amire als »Gem« bezeichnet) nach Kategorieeneinteilt. Durch Wrapper werden diese zu Komponenten des Frameworks und somitnutzbar.Amire beschäftigt sich also vornehmlich mit der Nutzbarmachung und Integrationvorhandener Technologieen. Es wird der Versuch angestellt, anfallende Aufgabenbei der Erstellung von AR-Anwendungen verschiedenen Rollen zuzuordnen(Abbildung 7).3.2.3 Studierstube – Augmented Reality ProjectDas Studierstube-Projekt der TU Wien (in Zusammenarbeit mit dem FraunhoferCRCG, Inc., Providence) ist eine Umgebung zur Entwicklung kollaborativer AugmentedReality Anwendungen und wird von seinen Urhebern auch als »augmentedreality operating system« bezeichnet (vgl. [Schmalstieg01]).Das Konzept beinhaltet ein auf OpenInventor basierendes Software-Framework»Studierstube API« dessen Funktionalität es ermöglicht, AR-Anwendungen mitverschiedenenen Hardware-Setups zu entwickeln. Dazu gehören Optical- und Video-See-Through-Systemesowie spezielle Projektionstechniken.Abbildung 8: PIP ohne und mit InteraktionskomponentenDer eigentliche Kern des Frameworks liegt aber in den zur Verfügung gestelltenKomponenten der Benutzerschnittstelle und dem Konzept der Interaktion: Das»Personal Interaction Panel« (PIP). Das PIP ist eine flache Tafel, die in einer Hand40

3 Fachliches Umfeld und Aufgabenstellunggehalten wird, während mit einem Stift in der anderen Hand darauf interagiertwerden kann (siehe Abbildung 8). Position und Lage von Tafel und Stift werdendurch magnetisches Tracking verfolgt, so dass der Computer auf die Interaktionreagieren kann. Das PIP wird in der Regel mit virtuellen Interaktionskomponentenvisuell angerereichert und kann dadurch verschiedene Interaktionszweckeerfüllen.Das Studierstube Projekt konzentriert sich auf die kollaborative Arbeit in AR-Umgebungen,wobei die Präsentation und Interaktion mit AR-Objekten im Vordergrundsteht. Zur Interaktion mit dem System ist die Verwendung beider Händenotwendig.Finger Tracking for interaction in AEDorfmüller-Ulhass u.a. beschreiben in [DS01] eine Anwendung zur Verfolgungdes Zeigefingers einer Hand. In der Anwendung wird gezeigt, wie durch direkteManipulation virtuelle Schachfiguren gesteuert werden können. Durch Krümmungdes Zeigefingers können Schachfiguren angehoben und bewegt werden.Die gelöste Interaktionsaufgabe ist also nicht die Systemsteuerung, sondernSelektion und Manipulation.Abbildung 9: Direkte Manipulation virtueller Objekte mit getracktem HandschuhZur Verwendung des Interaktionssystems muss der Benutzer einen optisch markiertenHandschuh tragen, wie in Abbildung 9 dargestellt. Mittels Tracking durchstereoskopische Kameras wird die Raumlage der drei Glieder des Zeigefingersverfolgt, so dass daraus ein dreidimensionales, kinematisches Modell berechnetwerden kann. Dieses Modell dient als Grundlage zur Bestimmung der Gesten,die die Interaktion steuern.41

3 Fachliches Umfeld und Aufgabenstellung3.3 AufgabenstellungZielstellungZielstellung dieser Diplomarbeit ist die Entwicklung eines Environments, das dieErstellung von AR-Anwendungen für die Verwendung mit Video-See-Through-Systemen ermöglicht.Zum einen sollen Interaktionskomponenten zur Systemsteuerung von AR-Anwendungenals Erweiterung der OpenInventor-Klassenbibliothek entwickelt werden.Zum anderen soll ein Verfahren zur videobasierten Erkennung von zeigendenHandgesten entwickelt werden, das die Steuerung der Interaktionskomponentenermöglicht.AbgrenzungEs soll keine konkrete Anwendung entwickelt werden. Auch soll kein Autorensystemfür die Erstellung von AR-Anwendungen entwickelt werden.Es soll kein fertiges Produkt, sondern ein Prototyp entwickelt werden.Die Interaktion beschränkt sich auf die Systemsteuerung, Selektion und Manipulationsowie Navigation werden nicht betrachtet.Das Problem, die anreichernde Virtualität an der Realität auszurichten, wird nichtbehandelt.3.4 Verwendete Methoden, Werkzeuge und BibliothekenMare ist als objektorientierte C++ Klassenbibliothek implentiert.Zur objektorientierten Modellierung wird die Unified Modelling Language, Version1.4 verwendet [UML01].Zur Modellierung von OpenInventor Szenegraphen werden Szenegraphdiagrammeverwendet ([Wernecke94], Seite ix f.). Anhang C enthält eine Beschreibungder Szenegraphdiagramme, wie sie in dieser Arbeit verwendet werden.42

3 Fachliches Umfeld und AufgabenstellungAls IDEs für die Erstellung des Programmcodes kamen Apples Xcode(http://developer.apple.com/tools/xcode/) und KDevelop(http://www.kdevelop.org/) zum Einsatz. Als Buildtool wurde Trolltechs qmake inder Version 1.06c (http://www.trolltech.com) und zur Generierung der Code-Dokumentation Doxygen in der Version 1.3.6 (http://www.doxygen.org)verwendet. Code und Dokumente wurden in einem Subversion 1.0 Repositoryverwaltet (http://subversion.tigris.org).Verwendete Bibliotheken sind:– Coin 2.2.1 http://coin3d.org– Qt 3.2.2 http://www.trolltech.com– SoQt 1.02 http://coin3d.org– boost 1.31.0 http://boost.org– OpenCV beta3.1 http://www.intel.com/research/mrl/research/opencv/– ARToolKit 2.6.1 http://www.hitl.washington.edu/artoolkit43

4 Vorüberlegungen und Überblick4 Vorüberlegungen und ÜberblickDieses Kapitel stellt die Grundlage für die folgenden Hauptteile II und III dar. Imersten Abschnitt werden die Entwicklungsebenen festgelegt und diesen Rollenund Use-Case-Arten zugeordnet. Im darauf folgenden Abschnitt wird die mare-Geste definiert. Im letzten Abschnitt dieses Kapitels wird ein Überblick über dieArchitektur von mare gegeben.4.1 Entwicklungsebenen, Rollen und Use-CasesDieser Abschnitt definiert die verschiedenen Entwicklungsebenen mit ihrenRollen und Use-Cases, die bei der Entwicklung von mare zu beachten sind.Bei der Betrachtung der Ebenen verwenden wir die Begriffe »Konstrukt« und»Konzept«. Da diese in unterschiedlichen Bedeutungen verwendet werden, seidie hier verwendete Bedeutung verdeutlicht:Mare soll die Basis für eine Vielzahl von AR-Anwendungen sein.Konzepte sind die Abstraktionen von Gemeinsamkeiten dieser Anwendungen.Beispielsweise ist für viele AR-Anwendungen die Verwendungdes Konzepts »gestensteuerbarer Button« sinnvoll.Ein Konstrukt ist ein Gebilde von mare, das für die Umsetzungeines Konzepts für eine AR-Anwendung genutzt werden kann. DieKonstrukte, die mare bereitstellt, finden sich nicht zwangsläufig alsseparate Einheit, beispielsweise als Klasse, in dem Modell vonmare wieder. So ist das Konstrukt für die Umsetzung des Konzepts»gestensteuerbarer Button« über mehrere Klassen verteilt, von deneneinige auch Bestandteil anderer Konstrukte sind.Abbildung 10 zeigt die vier Ebenen, zwischen denen wir unterscheiden: Dieoberste in der Abbildung dargestellte Ebene ist die Objektebene, dann folgenModellebene, Metamodellebene und schließlich die Ebene, auf der sich dieRolle des mare-Entwicklers befindet. 33 Um die Zusammenhänge aller im Abschnitt zu definierenden Begriffe darzustellen, habenwir die UML-Notation für Use-Case-Diagramme verwendet und diese durch Gedankenblasenund Aufteilung in Ebenen erweitert.Zu beachten ist, dass die vertikale Anordnung der Metaebenen nicht der üblichen Darstellungsreihenfolgeentspricht, bei der die Objektebene unten liegt. Der Grund ist die Verwendungder Gedankenblasen.44

Objektebenemare-Anwendungsinstanz(Objekte einer laufenden Anwendung)ModellebeneInstanz vonarbeitet mitmare-Anwendungs-Use-Casesmare-Anwendung(Modell einer Anwendung)Use-Cases definieren AnforderungenNächsten DemontageschrittanzeigenMonteurReparaturanweisungenanfordernMetamodellebenezum Teil Instanz vonentwickeltmare-Environment-Use-CasesErstellen eines Buttonsmare(Teil-Metamodell vieler Anwendungen)Use-Cases definieren AnforderungenErstellen eines DialogsentwickeltKonstrukt für Systemsteuerungs--konzept bereitstellenAnwendungsentwicklermare-EntwicklerAbbildung 10: Entwicklungsebenen, Rollen und Use-Cases

nicht drucken, für Entwicklungsebenen Ausklappseite

4 Vorüberlegungen und ÜberblickAls Einstiegspunkt in die Betrachtung der Ebenen dient mare.mare ist ein Environment, dessen Konstrukte instanziiert werden, umdie Systemsteuerung einer AR-Anwendung zu erstellen, die dannzur Ausführung gebracht wird.mare wird entwickelt von den mare-Entwicklern.mare-Entwickler sind Entwickler von Konstrukten für mare. Die Autorendieser Arbeit sind mare-Entwickler.Bei der Entwicklung von mare müssen die mare-Entwickler die Nutzung vonmare vor Augen haben. Dies wird in der Abbildung durch die Gedankenblaseverdeutlicht, die von der Rolle »mare-Entwickler« ausgeht und die die mare-Environment-Use-Cases in der Metamodellebene enthält.Die mare-Environment-Use-Cases sind Use-Cases auf der Metamodellebene,die die Verwendung von mare beschreiben. Sie definierendie Anforderungen an mare.In der Abbildung sind beispielhaft zwei mare-Environment-Use-Cases aufgeführt,die die Erstellung von Buttons und Dialogen behandeln. Tatsächlich mussein mare-Entwickler an eine größere Zahl möglicher Verwendungen von maredenken. Der Akteur der mare-Environment-Use-Cases ist der mare-Anwendungsentwickler.Die Rolle mare-Anwendungsentwickler (auch Rolle Anwendungsentwickler)ist eine Rolle der Metamodellebene. Ein Anwendungsentwicklerist ein Softwareentwickler, der mare verwendet.Anwendungsentwickler instanziieren die Konstrukte von mare, um eine mare-Anwendung zu erstellen.Eine mare-Anwendung oder Anwendung ist zum Teil eine Instanzvon mare. Sie befindet sich auf der Modellebene.Die Instanziierung von mare geschieht dadurch, dass ein AnwendungsentwicklerProgrammcode schreibt, der die vom mare-Entwickler bereitgestelltenKonstrukte verwendet. Tatsächlich befinden sich auf der Modellebene eine Vielzahlvon mare-Anwendungen, von denen eine beispielhaft dargestellt ist.47

4 Vorüberlegungen und ÜberblickZu einer AR-Anwendung gehört mehr als nur der Systemsteuerungsanteil. Deswegenist mare kein vollständiges Metamodell für mare-Anwendungen sondernkann immer nur ein Ausschnitt aus einem solchen sein.Wenn ein Anwendungsentwickler eine mare-Anwendung entwickelt, muss erdie Nutzung der Anwendung vor Augen haben, was in der Abbildung wiederdurch eine Gedankenblase verdeutlicht wird. In diesem Fall geht sie von demAnwendungsentwickler aus und sie enthält die mare-Anwendungs-Use-Cases inder Modellebene.mare-Anwendungs-Use-Cases sind Use-Cases auf derModellebene, die die Verwendung einer mare-Anwendungbeschreiben. Sie definieren die Anforderungen an die mare-Anwendung.In der Abbildung sind beispielhaft zwei mare-Anwendungs-Use-Cases einerAnwendung aufgeführt: Der Use-Case »Nächsten Demontageschritt anzeigen«,der dem Anwendungsszenario aus der Einführung entspricht, und ein weitererdenkbarer Use-Case »Reparaturanweisungen anfordern«. Eine übliche mare-Anwendung wird mehr als zwei mare-Anwendungs-Use-Cases enthalten.Die Akteure der mare-Anwendungs-Use-Cases sind abhängig von der modelliertenAnwendung. Beispielhaft verwenden wir für diese Arbeit den Monteur alsAkteur der mare-Anwendungs-Use-Cases.Die Rolle Monteur wird beispielhaft für Rollen verschiedenstermare-Anwendungen verwendet. Sie befindet sich auf derModellebene.Ein Monteur wird durch eine Instanz einer mare-Anwendung bei seiner Arbeitmit Realobjekten unterstützt. Ein Realobjekt ist beispielsweise die Waschmaschineaus dem Einführungskapitel.Eine mare-Anwendungsinstanz ist eine zur Ausführung gebrachte,also instanziierte mare-Anwendung. Sie befindet sich auf der (Software)-Objektebene.48

4 Vorüberlegungen und Überblick4.1.1 Beispiel-Use-CasesUm die Bedeutung der verschiedenen Ebenen darzustellen, werden in diesemAbschnitt beispielhaft ein mare-Anwendungs- und ein mare-Environment-Use-Case aufgestellt.Als Beispiel für einen mare-Anwendungs-Use-Cases dient der Use-Case für dasAnwendungsszenario aus dem Einführungskapitel: »Nächsten Demontageschrittanzeigen« 4 .NameZielAkteurVorbedingungBeschreibungNächsten Demontageschritt anzeigenDas nächste auszubauende Bauteil ist markiert unddessen Ausbaupfad wird angezeigt.MonteurDie Demontagesequenz ist noch nicht beendet.1. Monteur aktiviert den »Weiter«-Button durch Ausführender mare-Geste.2. Das System blendet die gerade gezeigten Demontageinformationenaus und die Informationen für dennächsten Demontageschritt ein.Als Beispiel für einen mare-Environment-Use-Case dient der Use-Case »Erstelleneines Buttons«, dessen Akteur der Anwendungsentwickler ist.4 Da die Use-Cases ausschließlich der Illustration dienen, haben wir für diese ein einfachesSchema verwendet und Punkte wie Auslösendes Ereignis, Erweiterungen oder Alternativenausgespart.49

4 Vorüberlegungen und ÜberblickNameZielAkteurVorbedingungBeschreibungErstellen eines ButtonsDie Anwendung enthält einen weiteren Button.AnwendungsentwicklerDer durch den Button zu steuernde Teil derAnwendung existiert.Der Anwendungsentwickler schreibt Programmcode...1. zur Instanziierung eines Buttons.2. der die Eigenschaften Name, Größe, Position, Beschriftungdes Buttons festlegt.3. zur Ereignisbehandlung, der ausgeführt wird, wennder Button durch die mare-Geste aktiviert wird undder die Funktionalität des Buttons implementiert.4. der den Button zu einem Container hinzufügt.Eine bestimmte Instanz dieses mare-Environment-Use-Cases, nämlich die Erstellungeines Weiterbuttons, führt zur Entstehung von Programmcode, der denmare-Anwendungs-Use-Case »Nächsten Demontageschritt anzeigen« ermöglicht.Der entsprechende Programmcode ist in der Beispielanwendung, Kapitel11 zu finden.4.2 Die mare-GesteAnforderungenAn die Gestik, mit der mare-Anwendungen gesteuert werden sollen, sindfolgende Anforderungen zu stellen:1 Ausführbar:Die Gestik muss von möglichst jedem Benutzer ohne vorheriges physischesTraining auszuführen sein und sie darf keine unangenehmenoder ungesunden Bewegungen beinhalten.2 Analysierbar:Das Erscheinungsbild der Gestik aus Sicht des Gestikulierenden und damitaus Sicht der Kamera in der AR-Brille muss genügend signifikante50

4 Vorüberlegungen und ÜberblickMerkmale besitzen, damit es erfolgreich einer Computer Vision Analyseunterzogen werden kann.3 Unterscheidbar:Die Gestik muss sich von der üblichen Tätigkeit des Benutzers abheben,um eine unbeabsichtigte Steuerung der Anwendung auszuschließen.DefinitionDie von uns gewählte Gestik, die diese Anforderungen erfüllt, besteht aus dermare-Geste. Diese basiert auf der mare-Handhaltung:Die mare-Handhaltung ist eine greifendeHandhaltung, bei der Daumen und Zeigefingerin einer Ebene parallel zur Bildebeneder Kamera in der AR-Brille liegen.Die mare-Geste teilt sich in zwei Phasen auf: Zeigen und Aktivieren.Zum Zeigen positioniert der Monteur seine Hand im Bild so, dassder Mittelpunkt zwischen Zeigefinger- und Daumenspitze an der Positionim Bild liegt, auf die er zeigen möchte.Wenn an der Position im Bild, auf die der Monteur zeigt, eine Interaktionskomponentedargestellt wird, dann zeigt der Monteur auf diese. 5Zum Aktivieren führt der Benutzer Zeigefinger-und Daumenspitze zusammen, so, alswürde er zugreifen, und danach wieder auseinander,als würde er loslassen. Die Interaktionskomponenteauf die dabei gezeigtwird, wird dadurch aktiviert.Abbildung 12: Das Aktivieren5 Auf welche Interaktionskomponente gezeigt wird, wird durch Verfolgung eines Sehstrahlsermittelt, der durch den Mittelpunkt zwischen Zeigefinger- und Daumenspitze geht. Die ersteInteraktionskomponente, die von dem Sehstrahl getroffen wird, ist die, auf die gezeigtwird.51

4 Vorüberlegungen und ÜberblickDefinition der mare-Geste:Die mare-Geste ist eine Handgeste, die in der mare-Handhaltungausgeführt wird und aus den Phasen Zeigen und Aktivieren besteht.GestencursorIm Gegensatz zur Maus ist die mare-Geste eine unvermittelte Steuerung: DerMonteur bewegt seine Hand direkt zu der Interaktionskomponente, die er aktivierenmöchte. Trotzdem bekommt er eine Rückmeldung über seine Handhaltungdurch einen kreisförmigen Cursor. Sein Durchmesser und seine Bildpositionwerden durch die Stellung von Daumen- und Zeigefingerspitze bestimmt. Wirbezeichnen den Cursor als Gestencursor:Der Gestencursor ist ein kreisförmiger Cursor,der der Hand in mare-Handhaltungderart folgt, dass sein Mittelpunkt die Positionmarkiert, auf die gezeigt wird und seinDurchmesser dem Abstand von DaumenundZeigefingerspitze entspricht.Der Grund für die Verwendung des Gestencursors ist zum einen, dass kein realesGestenerkennungsverfahren perfekt ist und die Rückmeldung des Gestencursorsdem Monteur die Möglichkeit gibt, Fehlerkennungen nachzuvollziehen und diemare-Geste noch einmal auszuführen. Zum anderen werden mit der mare-Geste Interaktionskomponenten gesteuert, die in das Videobild »gezeichnet«werden und halbtransparent die Hand überdecken. Der Gestencursor erlaubt esdem Monteur die Position seiner Hand auch hinter den Interaktionskomponentenwahrzunehmen.52

4 Vorüberlegungen und Überblick4.3 Die mare-ArchitekturFolgendes Diagramm gibt einen Überblick über die Architektur von mare.Abbildung 14: Die mare-ArchitekturDas mare Augmented Reality Environment besteht aus den Modulen Interaktionsschnittstelle,Gestenerkennung, ARToolKit-Wrapper und Videobildquelleund baut auf den Fremdbibliotheken OpenInventor und ARToolKit auf.Der Systemsteuerungsanteil einer mare-Anwendung wird auf Basis der Interaktionsschnittstellevon mare realisiert. Zudem kann die Anwendung denARToolKit-Wrapper aus mare, OpenInventor und weitere Fremdbibliothekenverwenden.53

4 Vorüberlegungen und ÜberblickDas Modul Interaktionsschnittstelle ist eine Erweiterung von OpenInventor undstellt Interaktionskomponenten zur Verfügung, die durch die mare-Geste gesteuertwerden können. Zudem ist es für die Anzeige des Videobildes zuständig.Die Gestenerkennung analysiert Bilder aus der Videobildquelle und erzeugtGestenereignisse, die von den Interaktionskomponenten verarbeitet werden.Das Modul Videobildquelle stellt einen objektorientierten, abstrahierten Zugriffauf unterschiedliche Videoquellen zur Verfügung.Der ARToolKit-Wrapper stellt einen objektorientierten Zugriff auf die Funktionalitätder Markererkennungsbibliothek ARToolKit zur Verfügung und kann voneiner mare-Anwendung verwendet werden, um VR-Objekte an Marker zu binden.Die Module Interaktionsschnittstelle und Gestenerkennung werden in denHauptteilen II und III beschrieben. Die Module Videobildquelle und ARToolKit-Wrapper sind zwar für eine vollständige mare-Anwendung wichtig, liegen abernicht im Fokus dieser Arbeit, der Systemsteuerung, und werden deswegen nichtnäher betrachtet.54

Hauptteil IIInteraktionsschnittstelle

ÜberblickIn diesem Teil werden die Bestandteile der grafischen Interaktionsschnittstellevon mare beschrieben. Der Teil beginnt mit der Definition der Anforderungenan die Interaktionsschnittstelle, es folgt ein Exkurs zu der verwendeten Szenegraphbibliothek.Anschließend werden die nicht interaktiven Darstellungskomponentenbeschrieben, gefolgt von dem wichtigsten Gegenstand diesesTeils, den Interaktionskomponenten.

5 Interaktionsschnittstelle5 InteraktionsschnittstelleDie mare-Interaktionsschnittstelle bietet eine Schnittstelle zwischen Mensch undComputer, die in vielen AR-Anwendungen zur Systemsteuerung benötigt wird.Zur visuellen Darstellung ihrer Bestandteile nutzt sie dreidimensionale Computergrafikin Form von VR-Objekten.Durch Computergrafik gezeichnete dreidimensionale Körper, dieperspektivisch korrekt dargestellt werden, heißen VR-Objekte.Die Aufgaben der Interaktionsschnittstelle sind zum einen die computergrafischeDarstellung der visuellen Komponenten einer mare-Anwendung und zum anderendie Bereitstellung von interaktiven Komponenten zur Systemsteuerung.Das mare-ModulInteraktionsschnittstelle besteht aus Darstellungskomponentenund Interaktionskomponenten. Die Klassen derInteraktionsschnittstelle sind im Namespace mare::gui definiert.Wie aus obiger Definition hervorgeht, teilt sich die Interaktionsschnittstelle inzwei Bereiche:DieDarstellungskomponenten sind VR-Objekte, die der grafischenDarstellung von Teilen der Interaktionsschnittstelle dienen, dieselbst keine Interaktion erlauben.Bei herkömmlichen (zweidimensionalen) Interaktionsschnittstellen kann man dieDarstellungskomponenten zum Beispiel mit der Schreibtisch-Metapher vergleichen– sie bieten ein Umfeld und Hintergrund für die Interaktionskomponenten.DieInteraktionskomponenten sind die vom Benutzer zur Interaktionmit dem System verwendeten VR-Objekte. Sie sind ereignissensitivund dienen sowohl der Eingabe als auch der Ausgabe vonInformationen der mare-Anwendung.Zu den Interaktionskomponenten gehören Klassen wie Button und Label. Solcheeinfachen Interaktionskomponenten lassen sich zu komplexeren Interaktionskomponentenzusammensetzen.Eine Übersicht über die Klassen der Interaktionsschnittstelle befindet sich in AnhangA.57

5 InteraktionsschnittstelleAR-Anwendungen sind dadurch charakterisiert, dass sie eine weitere Art visuellwahrnehmbarer Objekte anzeigen: die VR-Objekte, die die reale Szene anreichern.In einer AR-Anwendung zur Waschmaschinenreparatur könnte dies zumBeispiel ein in das Videobild eingeblendeter Ausbaupfad eines Bauteils sein.Diese Komponenten sind nicht Bestandteil der mare-Interaktionsschnittstelle,sondern werden von der AR-Anwendung erzeugt und kontrolliert 6 . Ihre Darstellungwird allerdings durch die Interaktionsschnittstelle koordiniert, wie in Abschnitt6.1 bis 6.3 beschrieben wird.AR-Objekte sind VR-Objekte, die von der AR-Anwendung zur Anreicherungder realen Szene benutzt werden.In AR-Anwendungen, die Video-See-Through-Systeme verwenden, werden dieAR-Objekte auf das Videobild gezeichnet.5.1 Anforderungen an die InteraktionsschnittstelleIm Folgenden werden die Anforderungen an die grafische Interaktionsschnittstellefür mare-Anwendungen festgelegt. Dabei werden die besonderen Bedingungenin der Augmented Reality mit Video-See-Through-Systemen berücksichtigt.5.1.1 Funktionale Anforderungen1 Videobild Anzeige und Aktualisierung:Das Videobild aus einem Video-See-Through-System muss als Bildhintergrundangezeigt werden und mit einer vorgegebenen Frequenz aktualisiertwerden.2 Anzeige von AR-Objekten:Es muss möglich sein, AR-Objekte auf das Videobild zu zeichnen.3 Lösung des Verdeckte-Objekte-Problems:Es soll die Möglichkeit geben, AR-Objekte so zu platzieren, dass sie hinterrealen Objekten des Videobildes liegen und so (teilweise) von diesenverdeckt werden.6 Obwohl auch die Interaktionskomponenten aus VR-Objekten bestehen, die über das Videobildgezeichnet werden, werden sie nicht als AR-Objekte bezeichnet.58

5 Interaktionsschnittstelle4 Darstellung von Interaktionskomponenten:Es muss die Möglichkeit existieren, interaktive Bestandteile zur Steuerungder Anwendung zu platzieren, darzustellen und benutzbar zumachen.5 Darstellung des Gestencursors:Es soll ein Cursor angezeigt werden, der den Gesten des Benutzersfolgt.5.1.2 Nichtfunktionale Anforderungen6 Beachtung der Gestensteuerung:Die Interaktionskomponenten sollen angemessen sein für die Bedienungdurch Gesten. Die Interaktionskomponenten dürfen nicht zu klein oderdetailliert sein, da die Gestensteuerung nicht dieselbe Genauigkeit bietet,die man von der Maus als Eingabegerät gewöhnt ist.7 Verdeckung der Sicht des Benutzers vermeiden:Da das Videobild in der undurchsichtigen AR-Brille für den Benutzer dievisuelle Schnittstelle zur Realität bildet, ist es besonders wichtig, dass dieInteraktionskomponenten das Videobild nicht so stark abdecken, dassdie Orientierung beeinträchtigt wird.8 Erkennbarkeit der Interaktionskomponenten:Die Gestaltung der Interaktionskomponenten muss mit besondererRücksicht auf die Anforderungen der Augmented Reality vorgenommenwerden. Die Interaktionskomponenten sollen in Video-See-Through-Systemen leicht erkennbar sein und sie müssen sich ausreichend vor verschiedenenHintergründen abheben. Da die Lesbarkeit durch die Brillenicht so hoch ist wie auf einem schärferen Monitor, muss die Textdarstellungbesonders groß und klar erfolgen.9 Konfigurierbarkeit:Die Interaktionskomponenten sollen in ihrer Gestaltung veränderbarsein.10 Erweiterbarkeit und Wiederverwendbarkeit:Es soll ohne großen Aufwand möglich sein, neue Interaktionskomponentenzu entwickeln. Die vorhandenen Interaktionskomponenten sollen beider Entwicklung von neuen Komponenten wiederverwendbar sein.59

5 Interaktionsschnittstelle11 Einfache API:Die Verwendung der Interaktionsschnittstelle soll für (im Bereich VRerfahrene) Anwendungsentwickler einfach sein.5.2 Exkurs SzenegraphbibliothekenZur Darstellung von Computergrafik hat sich OpenGL als grundlegende 3D-Grafikbibliothekweitgehend durchgesetzt – sowohl bei den Betriebssystemen, alsauch bei der Hardware. Die Programmierschnittstelle von OpenGL ist allerdingsals prozedurale C-API ausgeführt und beschränkt sich auf reine Zeichenbefehle,wie »zeichne Polygon«, »lade Textur«, »lösche Bildspeicher«.In vielen Bereichen der Computergrafik werden aber objektorientierte Ansätzebenötigt, die es ermöglichen, komplexe Szenen auf einfachere Art zu beschreiben,als durch eine lange Abfolge von Zeichenbefehlen. Zur Beschreibung vondreidimensionalen VR-Objekten wurden Datenstrukturen entwickelt, die diegeometrische Form und Anordnung der VR-Objekte darstellen.Das Konzept Szeneobjekt bezeichnet Informationseinheiten zurBeschreibung eines VR-Objektes: Form, Größe, Farbe, Oberflächentextur,Position im Raum und andere Charakteristika. Für jedeArt von Information gibt es einen Typ von Szeneobjekt. Szeneobjektekönnen auch Informationen zur Umgebung enthalten, zumBeispiel zur Beleuchtung. Außerdem gibt es Szeneobjekte zurGruppierung, die andere Szeneobjekte enthalten können.Szeneobjekte alleine stellen keine vollständigen VR-Objekte dar – erst ihre Kombination(zum Beispiel Position, Form und Farbe) ergibt sichtbare VR-Objekte.Zur Kombination werden Szeneobjekte typischerweise als Hierarchie in Formeines Szenegraphen angeordnet.EinSzenegraph ist ein azyklischer, gerichteter Graph, dessen KnotenSzenenobjekte sind. Die Kanten stellen die »Ist-Enthalten-In«-Beziehung der Szeneobjekte untereinander dar. 7 Szenegraphen beschreibendreidimensionale Objekte oder Szenen mit allen Charakteristika,die durch die enthaltenen Szeneobjekte definiert werden.7 Genau: Ein Szeneobjekt darf in 0 bis n anderen Szeneobjekten enthalten sein. Ein(Gruppierungs-) Szeneobjekt darf 0 bis n andere Szeneobjekte enthalten. Es darf keinSzeneobjekt in sich selbst (auch nicht indirekt) enthalten sein.60

5 InteraktionsschnittstelleZur Darstellung (dem Rendering) der Szene wird über den Szenegraph traversiertund für jedes Szeneobjekt eine Methode zum Rendering aufgerufen.Durch Verwendung von Szenegraphen, kann sich der Anwendungsentwickler aufdie Modellierung von dreidimensionalen Objekten und die Festlegung ihrerEigenschaften konzentrieren, statt auf ihre Darstellung durch Zeichenbefehle.5.3 Erweiterung von OpenInventorDie mare-Interaktionsschnittstelle ist als Erweiterung der OpenInventor-Klassenbibliothekimplementiert. Anhang B gibt einen Überblick über dieses objektorientierteC++ Klassenframework. Aufbauend auf den Szeneobjekt-Klassen ausOpenInventor, ergeben die Darstellungs- und Interaktionskomponenten eineKlassenhierarchie (siehe Anhang A), deren Bestandteile einzeln durch Instanziierunggenutzt, durch Assoziation zu komplexeren Komponenten verbundenoder durch Vererbung weiter spezialisiert werden können. Aufteilung in voneinandererbende Klassen wird in der Hierarchie intensiv genutzt, um Funktionalitätenzu trennen und die Wiederverwendbarkeit zu erhöhen.5.3.1 OpenInventorEin großer Teil der in OpenInventor definierten Klassen beschreibt die verschiedenenSzeneobjekte, die OpenInventor anbietet. Alle diese Klassen erben vonder gemeinsamen abstrakten Basisklasse SoNode.Szeneobjekt als Konstrukt bezeichnet ein Objekt einer Klasse, dievon der abstrakten Basisklasse SoNode aus OpenInventor erbt.Alle Klassen aus OpenInventor lassen sich an dem Präfix »So« oder »Sb« erkennen.In UML-Diagrammen werden sie von den in mare implementierten Klassendurch einen grauen Hintergrund unterschieden.In der Literatur zu OpenInventor [Wernecke94] wird eine grafische Beschreibungvon Szenegraphen vereinbart, die auch hier zur Beschreibung der Komponentender Interaktionsschnittstelle verwendet wird. Diese Form der Darstellung wird inAnhang C beschrieben.61

5 Interaktionsschnittstelle5.3.2 mare-Komponenten als SzenenobjekteEin wichtiges Designkriterium beim Entwurf der Interaktionsschnittstelle war es,alle Klassen (indirekt) von OpenInventorsSoNode erben zu lassen und die Konformitätzu den in OpenInventor üblichen Programmierrichtlinien einzuhalten.Dadurch sind alle Komponenten auch Szeneobjekte, was eine Reihe von Vorteilenergibt:– Szeneobjekte können an beliebigen Stellen in Szenegraphen eigesetztwerden. Dadurch wird eine sehr variable Verwendbarkeit erreicht – zumBeispiel könnte die Klasse ImageBackground (die zur Wiedergabe desVideobildes entwickelt wurde) verwendet werden, um fotografisch erzeugteBildhintergründe in Szenen einzufügen.– OpenInventor bietet Mechanismen für die persistente Speicherung vonSzeneobjekten. Das bedeutet, dass beispielsweise vollständige Benutzerschnittstelleneiner mare-Anwendung mittels eines dafür vorgesehenenWerkzeuges erstellt werden und dann im Inventor-Dateiformat gespeichertwerden könnten. Ein mare-Anwendungsprogrammierermüsste GUI-Bestandteile dann nicht selbst (durch Schreiben von Code)zusammenbauen, sondern könnte sie durch Verwendung eines einzelnenBefehls aus einer Datei laden.– Andere Mechanismen aus OpenInventor, wie das Referenzzählen mitautomatischer Destruktion unbenutzter Objekte oder die Fähigkeit zurRegistrierung von Observern 8 , werden unterstützt.– Anwendungsentwickler können ihre Erfahrung mit OpenInventor beimEntwurf von mare-Anwendungen nutzen. Der Programmierstil kannbeibehalten werden.– Bestehende Virtual-Reality-Anwendungen, die auf OpenInventor basieren,können mit minimalem Aufwand für die Augmented Reality portiertwerden.Als Nachteil ergibt sich allerdings die enge Kopplung an die OpenInventor-Bibliothek.Es ist im derzeitigen Entwicklungsstand nicht möglich die mare-Interaktionsschnittstellemit einer anderen 3D-Szenegraphbibliothek zu nutzen. Es wärewünschenswert in einer späteren Version von mare diese enge Kopplung zu lö-8 Dafür werden in OpenInventorSoSensor-Objekte verwendet, die bei Änderung desZustands eines Szeneobjekts eine Callbackfunktion aufrufen.62

5 Interaktionsschnittstellesen und die Möglichkeit zur Anbindung zum Beispiel an OpenSG oder Java3Dzu ermöglichen.5.4 ZusammenfassungDas mare-Modul Interaktionsschnittstelle setzt sich aus Darstellungskomponentenund Interaktionskomponenten zusammen. Die hier formulierten Anforderungenan die Interaktionsschnittstelle sollen die Benutzbarkeit des mare-Environmentsüber das in der Einführung beschriebene Anwendungsszenario hinausgewährleisten.63

6 Darstellungskomponenten6 DarstellungskomponentenDie Darstellungskomponenten sind die Komponenten der Interaktionsschnittstelle,die der nicht interaktiven, grafischen Darstellung dienen. Dazu gehörenSzeneobjekte, die zum Beispiel das Videobild zeichnen und die grafische Darstellungdes Cursors. Die Darstellungskomponenten können auch unabhängigvon den Interaktionskomponenten zur Erstellung von sehr einfachen AR-Anwendungenverwendet werden, die ohne Benutzerschnittstelle funktionieren.6.1 Überdeckungen in der Augmented RealityDie Darstellung der 3D-Computergrafik in der Augmented Reality muss besondereAnforderungen erfüllen: Anders als in der reinen Virtual Reality, muss dervirtuelle Anteil der Darstellung (die AR-Objekte) mit einem realen Bild in Übereinstimmunggebracht werden – dies ist nötig, um den immersiven Eindruck unddie Imagination (siehe Abschnitt 3.1.1) zu erreichen.Aufeinander abgestimmt werden müssen:– Geometrische Übereinstimmung:Die AR-Objekte müssen am richtigen Ort und in der richtigen Lage dargestelltwerden. Die für die perspektivisch richtige Darstellung auf demVideobild nötige Transformationsbestimmung übernimmt das AR-Tracking.– Zeitliche Übereinstimmung:Die Darstellung der virtuellen und der realen Anteile muss simultan undsynchron erfolgen. Wenn die Darstellung der virtuellen Anteile den realenAnteilen zeitlich nachläuft, ergibt sich ein schwimmender Effekt, derdie Imagination stört.– Räumliche Verdeckung:Objekte der realen Welt, die bezüglich des Betrachters vor Objekten dervirtuellen Welt liegen, müssen diese verdecken – und andersherum. DieseProblematik muss von der 3D-Grafik-Darstellung in der AR-Anwendungberücksichtigt werden.An einem Beispiel soll das Problem der Verdeckung von AR-Objekten durch realeObjekte in einem AR-System beschrieben werden:64

6 DarstellungskomponentenIn Video-See-Through-Systemen werden die virtuellen Objekte auf ein Videobildgezeichnet. Dies ist immer dann fehlerfrei möglich, wenn sich alle virtuellen Objektenäher am Betrachter als alle realen Objekte befinden. Wenn sich aber einvirtuelles Objekt hinter einem realen Objekt (auf dem Videobild) befindet, mussder verdeckte Teil bei der Darstellung ausgespart werden (siehe Abbildung 15).Um die Aussparung zu ermöglichen, müssen die realen Objekte als Modelle(Szeneobjekte) vorliegen und ihre Position und Lage im Raum bekannt sein. 9Aussparobjekte sind Szeneobjekte, die reale Objekte modellierenund dazu dienen, die Verdeckung des Videobildes zu kontrollieren.Abbildung 15: Überdeckung von AR-ObjektenBei der Darstellung virtueller Objekte über realen Szenen muss die räumliche Verdeckung beachtetwerden, um den Tiefeneindruck nicht zu stören. Das rote AR-Objekt scheint auf dem Tisch zuliegen, wenn die Überdeckung nicht berücksichtigt wird.6.2 Überdeckung in mareDie für mare entwickelte Realisierung des Aussparens nutzt die Reihenfolge desZeichnens und den Z-Buffer 10 der OpenGL-Implementierung. Die Darstellungeines Frames erfolgt in vier Schritten:9 In der Regel übernimmt diese Aufgabe das AR-Tracking.10 Der von Catmull 1975 entwickelte Z-Buffer Algorithmus ist ein Verfahren der Computergrafikzur Bestimmung der Sichtbarkeit von Bildpunkten. Im Z-Buffer wird während des Rendernsfür jeden Bildpunkt der z-Wert (Entfernung vom Betrachter) gespeichert. Vor dem Zeichnenjedes Bildpunktes wird an der entsprechenden Stelle im Z-Buffer geprüft, ob vorher schonein Pixel gezeichnet wurde, der den neuen Bildpunkt verdeckt – und, wenn ja, wird diesernicht gezeichnet (vergleiche [Watt02], Seite 217f.).65

6 Darstellungskomponenten1. Bildspeicher und Z-Buffer löschen.2. Zeichnen der Aussparobjekte.Dabei werden Tiefeninformationen inden Z-Buffer geschrieben.3. Überschreiben des Bildspeichers mit demVideobild.Die Tiefeninformation im Z-Buffer bleibtdabei erhalten.4. Zeichnen der AR-Objekte (unterBerücksichtigung des Z-Buffers).Abbildung 16: DarstellungsreihenfolgeEs ist vorstellbar, das Verfahren für nicht modellierte Elemente, wie zum Beispieldie Hände des Benutzers, zu erweitern. Dabei könnte eine AR-Brille mit Stereo-Kamera verwendet werden, die zur Gewinnung von Tiefeninformationen verwendetwird und deren Daten direkt in den Z-Buffer geschrieben werden.6.3 MareSceneKitUm die oben beschriebene Darstellungsreihenfolge für die Interaktionsschnittstellezu realisieren, stellt das mare Environment die Klasse MareSceneKit zurVerfügung. Die von OpenInventors SoSceneKit erbende Klasse dient als Wur-66

6 Darstellungskomponentenzel des Szenegraphen einer mare-Anwendung. Sie gibt mit geeigneten Gruppierungsobjektendie Anordnung der Bestandteile vor. Das MareSceneKiterweitert so die Elternklasse um die Funktionalität, die für AR-Anwendungenbenötigt wird.Die Implementierung als NodeKit ermöglicht die effektive Zusammenfassungverschiedener Szeneobjekte zu einem komponierten Szeneobjekt.blaue Darstellung:geerbte Szeneobjekteaus SoSceneKitMareSceneKitschwarze Darstellung:neue Szeneobjekteaus MareSceneKitguiKitcamerarealitybackgroundlightvirtualityrealityOverlayAbbildung 17: Szenegraphdiagramm von MareSceneKit(vereinfachte Darstellung, vollständiges Szenegraphdiagramm in Anhang D)Abbildung 17 zeigt den Szenegraphen von MareSceneKit. Zusätzlich zu denSzeneobjekten der Elternklasse aus OpenInventor (Wurzelobjekt, Kamera- undLichtobjekte) enthält MareSceneKit die folgenden Bestandteile:1. ein Gruppierungsobjekt als Container für Aussparobjekte (»reality«),2. einImageBackground-Szeneobjekt zur Darstellung des Videobildesüber den Aussparobjekten (»background«),3. ein Gruppierungsobjekt als Container für AR-Objekte (»virtuality«),4. ein Gruppierungsobjekt zur Darstellung eines Drahtgittermodells derAussparungsobjekte (»realityOverlay«),5. einGuiKit-Szeneobjekt (»guiKit«) zur Verwaltung der Interaktionskomponenten(siehe Abschnitt 7.4).67

6 DarstellungskomponentenDie Szeneobjekte des Szenegraphen werden bei Traversionen, also auch beimRendern, zuerst von oben nach unten, dann von links nach rechts bearbeitet.Dies ist wichtig, um die richtige Reihenfolge beim Rendern der oben beschriebenenSzeneobjekte sicherzustellen.Alle neu hinzugefügten Teile können bei Bedarf an- oder abgeschaltet werden.Dafür gibt es entsprechende Zugriffsmethoden. Die Schnittstelle der KlasseMareSceneKit wird in Abbildung 18 gezeigt.SoNodeSoBaseKitSoSceneKitrealitybackgroundvirtualityrealityOverlayguiKitMareSceneKit– m_timer: SoTimerSensor+ MareSceneKit()# ~MareSceneKit()+ getRealityEnabled(): bool+ setRealityEnabled(bool): void+ getRealityOverlayEnabled(): bool+ setRealityOverlayEnabled(bool): void+ getVirtualityEnabled(): bool+ setVirtualityEnabled(bool): void+ getImageBackgroundEnabled(): bool+ setImageBackgroundEnabled(bool): void+ getGuiKitEnabled(): bool+ setGuiKitEnabled(bool): void+ getVirtualityRoot(): SoSeparator+ getRealityRoot(): SoSeparator+ getGuiKit(): GuiKit+ initClass(): void– updateVideoImage(): void– timerCallback(data: void, sensor: SoSensor): voidAbbildung 18: DieMareSceneKit-KlasseRealityOverlayIn der Implementierungs- oder Testphase einer mare-Anwendung kann esäußerst hilfreich sein, die unsichtbaren Aussparobjekte (die eigentlich nur den Z-Buffer beschreiben) sichtbar zu machen. Zu diesem Zweck wird das Szeneobjekt,das die Aussparobjekte enthält und durch das Videobild verdeckt wird, nach derDarstellung des Videobildes noch einmal in den Szenegraphen eingesetzt. Dadurchwird ein Drahtgittermodell der Aussparobjekte gezeichnet. Die Darstellungder Aussparobjekte als Drahtgittermodell lässt sich durch die MethodengetRealityOverlayEnabled und setRealityOverlayEnabled kontrollieren.68

6 DarstellungskomponentenVideobilddarstellung und -aktualisierungNeben der Anordnung der Szenegraphbestandteile ist MareSceneKit auch fürdie Darstellung und Aktualisierung des Videobildes verantwortlich. Da es inOpenInventor keine Möglichkeit gibt, ein Bild als Hintergrund der Szene zuverwenden, implementiert mare dazu eine eigene Klasse: ImageBackground.Zur Aktualisierung des Videobildes instanziiert ein MareSceneKit-Objekt imKonstruktor ein SoTimerSensor 11 -Objekt, das mit vorgegebener Frequenz dieVideobildquelle auf neue Bilder überprüft. Sobald ein neues Bild verfügbar ist,wird es an das eingebettete ImageBackground-Szeneobjekt (»background«)weitergegeben und dadurch ein erneuter Renderingvorgang angestoßen.6.4 ZusammenfassungDasMareSceneKit ermöglicht die Darstellung von Szeneobjekten unter Berücksichtigungder in der Augmented Reality nötigen Aussparung. Darüberhinausleistet das MareSceneKit die Darstellung des Videobildes und desCursors und bildet die Basis für die Interaktionskomponenten.11 SoTimerSensor ist eine von OpenInventor bereitgestellte Timer-Klasse, deren Objekte miteiner vorgegebenen Frequenz eine Callbackfunktion aufrufen. Der Aufruf wird allerdings nurzu definierten Zeitpunkten des Threads ausgeführt, in dem OpenInventor läuft. Dadurch istsichergestellt, dass eine durch den Callback ausgeführte Veränderung des Szenegraphennicht während einer Szenegraphtraversion (wie dem Rendering) auftritt.69

7 Interaktionskomponenten7 InteraktionskomponentenDie Interaktionskomponenten sind die Komponenten der Interaktionsschnittstelle,die vom Benutzer zur Interaktion mit dem System verwendet werden. In herkömmlichen2D-GUIs haben sie ihre Entsprechung in den häufig als »Widgets«bezeichneten Fenstern, Buttons und Menüs. In der Literatur findet man denBegriff der »3D-Widgets« für ihre dreidimensionalen Varianten, zum Beispiel in[Preim99].7.1 VorüberlegungenInteraktionskomponenten dienen zur Gestaltung von Benutzerschnittstelleneiner mare-Anwendung und werden in eine 3D-Szene eingeblendet, statt in einFenster eines herkömmlichen GUI-Frameworks.Fenster aus 2D-GUI-Frameworks haben drei wichtige Aufgaben:– Sie begrenzen die grafische Ausdehnung der enthaltenen GUI-Elemente.– Sie Gruppieren die einzelnen, enthaltenen Elemente, so dass sie zumBeispiel zusammen bewegt oder ausgeblendet werden können.– Sie bieten den Elementen einen Hintergrund.Eine mare-Anwendung wird zwar selbst in einem (begrenzenden) Fenster aufdem Monitor dargestellt – der dargestellte 3D-Raum hat aber keine durch dieBenutzerschnittstelle vorgegebenen Grenzen.Wollte man die Metapher des Fensters, das Bedienelemente enthält und ihrenDarstellungsbereich beschränkt, in den 3D-Bereich übernehmen, wäre dasErgebnis eine quaderförmige Schachtel, die ihren Inhalt umschließt. Um die enthaltenenBedienelemente zu sehen und zu benutzen, müsste diese Schachtelaber transparent sein oder eine offene Seite haben. Insgesamt ergibt sich einwenig intuitiv zu benutzendes Konstrukt, da man es ja gewöhnt ist, Gegenständevon außen anzufassen und zu bedienen. Außerdem würde es die Gestaltung derInteraktionskomponenten geometrisch sehr einschränken.In mare gibt es deshalb keine Komponente zur geometrischen Begrenzung.Trotzdem können Interaktionskomponenten zu Gruppen zusammengefasst (undgemeinsam bewegt) werden. Diese Möglichkeit der Gruppierung und die70

7 InteraktionskomponentenFunktion, einen Hintergrund für darauf angeordnete Interaktionskomponentenzu bieten, wird in mare durch ein Panel (siehe Abschnitt 7.6) geboten.7.2 Grafische Gestaltung der InteraktionskomponentenDie Gestaltung der Interaktionskomponenten wurde in mare mit besondererRücksicht auf die in Kapitel 5 formulierten Anforderungen 6 bis 8 vorgenommen.Um Anforderung 7 (Verdeckung der Sicht des Benutzers vermeiden) zu erfüllen,wurden großflächige Komponenten wie das Panel halbtransparent gestaltet, sodass der Benutzer das dahinter liegende Videobild noch wahrnehmen kann (sieheAbbildung 19). Trotzdem müssen die Komponenten sich ausreichend vor verschiedenenHintergründen abheben (Anforderung 8, Erkennbarkeit). Sowohl vorhellen, dunklen oder sehr komplexen als auch wechselnden und bewegten Hintergründenmüssen die Interaktionskomponenten gut erkennbar sein, damit einesichere Bedienung gewährleistet bleibt.Abbildung 19: Panel mit Interaktionskomponenten vor dunklem und hellem Hintergrund71

7 Interaktionskomponenten7.3 Ergebnisse des experimentellen PrototypingsDie Gestaltung der Komponenten hat sich darauf konzentriert, klare Formenohne feine Details zu finden (zur Erüllung von Anforderung 6, Beachtung derGestensteuerung), deren Erkennbarkeit vor wechselnden Hintergründen hochist. Um die optimale Erkennbarkeit und Benutzbarkeit zu erreichen, wurdendurch experimentelles Prototyping verschiedene Formen mit Kombinationen vonFarben und Tranzparenzgraden getestet. Dabei hat sich die Klarheit und Erkennbarkeitvon zweidimensionalen Komponenten als deutlich höher erwiesen als dievon komplexeren, dreidimensional geformten VR-Objekten (siehe Abbildung 20).Abbildung 20: Ergebnisse des experimentellen PrototypingsDie beste Erkennbarkeit wurde mit der zweidimensionalen Variante (rechts unten) erzielt.Diese Zweidimensionalität passt auch zu der gewohnten Anordnung von Bedienelementen:Technische Geräte aus der realen Welt, wie Stereoanlagen, Computertastaturenoder Schalttafeln von technischen Anlagen besitzen in der RegelFlächen mit nebeneinander angeordneten Schaltern, Beschriftungen und Anzeigen(vergleiche [Preim99], Seite 16f.).Aus dieser Schalttafel-Metapher wurden die Panels (siehe Abschnitt 7.6) entwickelt,mit darauf anzuordnenden Labels, Buttons, Checkboxen und ähnlichengrundlegenden Bedienelementen.Da die Interaktionskomponenten als Szeneobjekte implementiert werden, könnensie natürlich beliebig im Raum transformiert – also auch in ihrer Größe verändert– werden. Es liegt demzufolge in der Verantwortung des mare-Anwendungsentwicklers,die Interaktionskomponenten les- und benutzbar anzuordnen.72

7 InteraktionskomponentenDie grafische und geometrische Erscheinung aller Interaktionskomponenten lässtsich durch den mare-Anwendungsentwickler verändern, sofern ihm die vorgegebenenModelle nicht zusagen oder ihr Aussehen anderen Vorgaben angepasstwerden soll.7.4 GuiKitEinGuiKit-Objekt wird in einer mare-Anwendung dazu verwendet, die Interaktionskomponentenvom Rest des Szenegraphen zu trennen. Üblicherweise wirdes nicht explizit instanziiert, sondern als Teil des MareSceneKits erzeugt, daseine Zugriffsmethode getGuiKit anbietet. Das GuiKit ist im MareSceneKitganz rechts oben plaziert (siehe Abbildung 17), so dass es beim Rendern alsletztes Szeneobjekt traversiert wird.GuiKitin mare implementierte,spezialisierte Szeneobjekte:BufferClearCursorcamera clear lightstransformchildrencursorAbbildung 21: Aufbau des GuiKit(vereinfachte Darstellung, vollständiges Szenegraphdiagramm in Anhang D)Die vom GuiKit verwalteten Interaktionskomponenten werden in dem Gruppierungsszeneobjekt»children« gesammelt.Die Trennung der Interaktionskomponenten von den Darstellungskomponentenist vor allem wichtig, um die Darstellung der Interaktionskomponenten unabhängigvom Rest der Szene beeinflussen zu können. Dabei sind folgende Aspekte zubeachtenden:73

7 Interaktionskomponenten– Die Perspektive:Da die Interaktionskomponenten unabhängig von aktuellen Kameraeinstellungender Szene immer direkt vor dem Benutzer in einem definiertenGesichtsfeld erscheinen sollen, muss eine eigene Kameraeinstellungnur für die Interaktionskomponenten möglich sein. Dazu dient das Szeneobjekt»camera«. Auch die Transformation der Interaktionskomponenten(durch das »transform«-Szeneobjekt) hat natürlich einen Einfluss aufdie Darstellung.– Die Beleuchtung:Die Darstellung der Interaktionskomponenten sollte nicht mit dem aktuellenSzenelicht geschehen, da es sonst möglich wäre, dass sie ungünstigoder gar nicht beleuchtet werden. Für eine unabhängige Beleuchtungkann im GuiKit der »lights« -Teil benutzt werden.– Die Verdeckung:Die Interaktionskomponenten werden in einem bestimmten Abstandzum Betrachter dargestellt. Wenn ein anderes Szeneobjekt näher amBetrachter liegt, ist es möglich, dass die Interaktionskomponenten dahinterverdeckt werden. Dies wird durch Verwendung des dafür entwickeltenBufferClear-Objektesverhindert, dass den Z-Buffer löscht undso eine Verdeckung ausschließt.ImplementierungDasGuiKit dient also als Container für Interaktionskomponenten und erbt vonder Klasse Container (siehe nächster Abschnitt) eben diese Fähigkeit. Damit istauch die Möglichkeit gegeben, alle Interaktionskomponenten gemeinsam zutransformieren – zum Beispiel um sie an einen anderen Maßstab anzupassen.Um dem Problem der Verdeckung durch AR-Objekte zu begegnen, ist imGuiKit das BufferClear-Szeneobjekt vorgesehen. Es dient dazu, den Z-Buffervor dem Zeichnen der Interaktionskomponenten zu löschen. Durch Löschender Tiefeninformationen werden die Interaktionskomponenten unabhängig vonihrer Position gegenüber AR-Objekten immer zuvorderst gezeichnet.74

7 InteraktionskomponentenContainerGuiKit+ GuiKit()# ~GuiKit()+ setCameraEnabled(enabled: bool): void+ getCameraEnabled(): bool+ setLightEnabled(enabled: bool): void+ getLightEnabled(): bool+ setCursorEnabled(enabled: bool): void+ getCursorEnabled(): bool+ getCamera(): SoPerspectiveCamera+ getBufferClear(): BufferClear+ getLightGroup(): SoGroup+ processEvent(event: GestureEvent): void– mouseCallback(SoEventCallback): void+ initClass(): voidAbbildung 22: Schnittstelle von GuiKitNeben der Containerfunktion und der Entkoppelung vom Rest der Szene, dientdasGuiKit dazu, den Gestencursor darzustellen, der durch den Benutzergesteuert wird. Dazu dient das »cursor«-Szeneobjekt, dass den Gestencursoranhand der Parameter Position, Durchmesser und Deckkraft zeichnet. DieseParameter erhält das GuiKit durch Empfang von Gestenereignissen (sieheAbschnitt 7.9.5).Außerdem werden in GuiKit OpenInventor Mausereignisse in Gestenereignisseübersetzt, damit die Interaktionskomponenten zu Testzwecken auch durch dieMaus gesteuert werden können.75

7 Interaktionskomponenten7.5 ContainmenthierarchieContainer-Objekte dienen dazu, Interaktionskomponenten zu gruppieren. DaContainer Basisklasse aller implementierten mare Interaktionskomponentenist, können diese beliebig hierarchisch angeordnet werden – das heißt, jederInteraktionskomponente können andere Interaktionskomponenten untergeordnetwerden. 12 Zum Beispiel könnte einem Button ein Textobjekt als zusätzlicheInformation untergeordnet werden.Typischerweise wird die Container-Funktionalität bei Panels genutzt, die imnächsten Abschnitt beschrieben weren.Wie bereits dargelegt, bietet mare keine »Behältnis-Metapher« im Sinne einesräumlich umschließenden Gefäßes – also geometrisch begrenzendes Containment(siehe Abschnitt 7.1). Es gibt aber weitere Gründe, eine hierarchischeAnordnung zu unterstützen:– logische Anordnung:Interaktionskomponenten sollen zu logischen Einheiten zusammengefasstwerden können (ein Panel fasst die Buttons und Labels, die aufihm dargestellt werden, zusammen). Dadurch können zum Beispiel Unterobjektezusammen mit ihrem Elternobjekt aktiviert oder deaktiviertwerden.– geometrische Anordnung:Untergeordnete Komponenten werden zusammen mit dem Elternobjekträumlich transformiert.– Komposition im softwaretechnischen Sinne:Die Lebenszeit von Unterobjekten wird durch die Lebenszeit ihrer Elternobjektebegrenzt.– Ereignisbehandlung:Elternobjekte können Ereignisse an Unterobjekte weiterleiten.12 Es wäre aber auch denkbar, Interaktionskomponenten zu entwickeln, die nicht dieFunktionalität des Containers haben. Solche Interaktionskomponenten würden vonGuiComponent erben. GuiComponent ist der Basistyp aller Interaktionskomponenten undwird überall dort in mare benutzt, wo Interaktionskomponenten polymorph verwendetwerden.Container und GuiComponent existieren in der Vererbungshierarchie alsgetrennte Klassen, um den Typ der Interaktionskomponenten unabhängig von derFunktionalität des Containers implementieren zu können.76

7 InteraktionskomponentenSzeneobjekte und Interaktionskomponenten als UnterobjekteAls Unterobjekte können nicht nur Interaktionskomponenten zu Containernhinzugefügt werden, sondern beliebige Szeneobjekte. Dadurch könnenInteraktionskomponenten mit allen Eigenschaften versehen werden, dieOpenInventor-Szeneobjekte bieten. Indem zum Beispiel in einer mare-Anwendung eine zusätzliche Lichtquelle an einer bestimmten Stelle eingefügtwird, könnte eine Interaktionskomponente vor anderen hervorgehoben werden.ImplementierungContainer bedient sich des von OpenInventor verwendeten Kompositionsmusters(siehe Abbildung 23 und Anhang B) anhand eines enthaltenen SoGroup-Objektes und delegiert Methodenaufrufe zum Hinzufügen, Entfernen oderAbfragen von Unterobjekten an dieses.SoNode*«EventProvider»Container«Listener»GuiComponentSoGroup+ Container()# ~Container()+ getNumChildren(): unsigned int+ getChild(childNum: int): T+ getChild(childName:String): T+ addChild(newChild: SoNode): void+ removeChild(child: SoNode): void+ removeAllChildren(): void+ isChild(node: SoNode): bool+ getChildrenEnabled(): bool+ setChildrenEnabled(enabled: bool)+ initClass(): voidAbbildung 23: Die Klasse ContainerDas assoziierte SoGroup-Objekt enthält die Unterobjekte des ContainersErweitert wird die OpenInventor-Funktionalität durch die Template-Member-FunktionengetChild(int childNum) und getChild(String childName), die das zurückgelieferte Unterobjekt auf korrektenTyp prüfen und immer den Template-Typ zurückliefern (oder eine Exceptionauslösen). Durch Verwendung dieser Methoden können typsicher unterschiedlicheTypen aus Containern abgefragt werden. Das Typecasting entfällt.77

7 InteraktionskomponentenEreignisbehandlung in Containern 13Damit Unterobjekte die GuiEvents erhalten, die der Container empfängt, werdensie in processEvent durch Ausführen von fireEvent an alle registriertenListener weitergeleitet. Da alle Interaktionskomponenten beim Hinzufügen zuContainern als Listener registriert werden, erhalten sie somit die Ereignisseihres Elternobjektes.Die Funktionen zum Hinzufügen und Entfernen von Unterobjekten (addChild,removeChild,removeAllChildren) prüfen vor der Delegation an dasSoGroup-Objekt, ob es sich bei dem übergebenen Szeneobjekt um eine Interaktionskomponentehandelt (vom Typ GuiComponent). Diese werden in dieListe der GuiEvent-Listener aufgenommen (beziehungsweise aus ihr entfernt).Dadurch entsteht parallel zum Szenegraphen ein weiterer (baumförmiger) Graph,dessen Knoten die GuiComponent-Objekte sind, und dessen Kanten die»Empfängt-Ereignisse-von« Beziehung der EventProvider und Listenerdarstellen.7.6 Panel und LabelDie im vorherigen Abschnitt beschriebenen Container können zur logischenGruppierung von Interaktionskomponenten verwendet werden – sie haben aberkeine visuelle Repräsentation. Zur Zusammenfassung von Interaktionskomponentenauf einem gemeinsamen (visuellen) Hintergrund, bietet mare die Panel-Klasse.Panels entsprechen in etwa den Fenstern aus 2D-Benutzerschnittstellen,obwohl sie kein grafisches Clipping implementieren. Sie setzen die Schalttafel-Metapher (siehe Abschnitt 7.3) um.Panels sind Container für andere Interaktionskomponenten und bieten dieseneine rechteckige Grundfläche. Die weiße, halbtransparente Fläche mit dünnerschwarzer Umrandung ist vor den meisten Hintergründen gut sichtbar – auchvor bewegten Videobildern mit abwechselnd hellen und dunklen Stellen (sieheAbbildung 24). Die Sicht auf dahinter liegende VR-Objekte und das Videobildwird von Panels aufgrund ihrer Transparenz nicht vollständig verdeckt. Trotzdemwird eine sichtbare Grundfläche für andere Interaktionskomponentengeschaffen, die diesen einen visuellen Zusammenhalt gibt.13 Die Ereignisbehandlung wird ausführlich in Abschnitt 7.9 besprochen.78

7 InteraktionskomponentenAbbildung 24: Panel vor inhomogenem HintergrundImplementierungPanels erben von Container und fügen Szeneobjekte zur Darstellung derGrundfläche und ihrer Umrahmung hinzu. Sie bieten Methoden zur Einstellungder Größe und Position der Grundfläche.Labelblaue Darstellung:geerbte Szeneobjekteaus Containerschwarze Darstellung:neue Szeneobjekteaus LabeltransformpanelSoShapeKitdecorationSoShapeKitlabelSoShapeKitchildrenAbbildung 25: Szenegraphdiagramm von Label(vereinfachte Darstellung, vollständiges Szenegraphdiagramm in Anhang D)79

7 InteraktionskomponentenDie Klasse Label erbt von Panel und fügt ein Szeneobjekt zur Darstellung vonText hinzu (siehe Abbildungen 25 und 26). Sie dient hauptsächlich zur Beschriftungvon anderen Komponenten oder zur Darstellung von Hinweisen und Informationstafeln.Die Klasse bietet Methoden um den Text der Beschriftung einzustellen,wobei es möglich ist, die Größe des Panels automatisch an die vomText benutzte Fläche anpassen zu lassen.ContainerPanel+ Panel()+ Panel(size: SbVec2f, trans: SbVec3f)# ~Panel()+ setPanelEnabled(bool): void+ getPanelEnabled(): bool+ setPanelSize(size: SbVec2f): void+ getPanelSize(): SbVec2f+ setPanelTranslation(SbVec2f): void+ getPanelTranslation(): SbVec2f+ initClass(): voidLabel+ Label()+ Label(label: String, translation: SbVec3f,justification: enum, spacing: float)# ~Label()+ setLabelEnabled(enabled: bool): void+ getLabelEnabled(): bool+ setLabelTranslation(center: SbVec2f): void+ getLabelTranslation(): SbVec2f+ setLabel(newLabel: String, justification: enum,spacing: float, adjustSize: bool): void+ getLabelBounds(): SbBox2f+ adjustPanelToLabel(minimumSize : SbVec2,borders: SbVec2f, shift: float): void+ initClass(): voidAbbildung 26: Die Klassen Panel und LabelPanels und Labels sind – trotz ihrer scheinbar passiven Rolle – Interaktionskomponenten.Dies resultiert aus der Tatsache, dass sie als Container fürandere Interaktionskomponenten dienen und GuiEvents empfangen und andie Unterkomponenten weiterleiten (siehe Abschnitt 7.9.5).Buttons, die im folgenden Abschnitt beschrieben werden, nutzen Label umihre visuelle Repräsentation zu implementieren.7.7 ButtonButton und die davon abgeleiteten Klassen Checkbox und RadioButtonstellen die wichtigsten von mare angebotenen Interaktionskomponenten dar.Buttons reagieren auf Handlungen des Benutzers, empfangen GuiEvents undgenerierenActionEvents 14 . Wenn der Benutzer den Gestencursor über einen14 Siehe Beschreibung der Ereignisbehandlung, Abschnitt 7.980

7 InteraktionskomponentenButton bewegt, reagiert dieser durch Ändern seiner Farbe, um dem Benutzerseine Fähigkeit zur Interaktion anzuzeigen. Sobald der Benutzer über demButton die mare-Geste zur Aktivierung ausführt, wechselt der Button erneutdie Farbe. Bei der Deaktivierung wird dann ein ActionEvent erzeugt und andie beim Button registrierten Listener gesendet.Die im experimentellen Prototyping entwickelte Farbcodierung unterstützt dieErkennbarkeit und Aussagekraft optimal (siehe Abbildung 27). Auch wurde diekonsistente Verwendung beachtet (siehe [Shneiderman02], Seite 461ff.).Status »Inactive«Cursor nicht vor ButtonStatus »Over«Cursor über Button,nicht aktiviertStatus »Active«Cursor über Button,aktiviertAbbildung 27: Die drei Zustände von Buttons7.7.1 ResponderDie Funktionalität zum Statuswechsel von Buttons ist in der Klasse Responderimplementiert (siehe Abbildung 28). Sie registriert das Überfahren des Szeneobjektesmit dem Gestencursor und die Aktivierung und ändert den Status entsprechend.Der Status wird in einem SoSwitch 15 -Objekt gespeichert, dessenwhichChild-Attribut zwischen den Werten 0 (inaktiv), 1 (over), und 2 (aktiv)wechselt.15 SoSwitch ist ein von OpenInventor zur Verfügung gestelltes Szeneobjekt, das wieSoGroup Unterobjekte verwaltet. Allerdings kann in einem SoSwitch-Objekt ausgewähltwerden, welches Unterobjekt angezeigt werden soll. Dies geschieht numerisch über das»whichChild«-Attribut.81

7 Interaktionskomponenten«Listener»GuiComponentContainerstateSwitchSoSwitch+ whichChild«EventProvider»Responder+ Responder()# ~Responder()+ getState(): State {values: INACTIVE, OVER, ACTIVE}– setState(newState: State): void+ addStateChangeListener(StateChangeListener): void+ removeStateChangeListener(StateChangeListener): void+ processEvent(event: GuiEvent): void+ initClass(): void3inactiveState,overState,activeStateSoNodeAbbildung 28: Die Klasse ResponderResponder-Objekte empfangen GuiEvents und generieren daraus State-ChangeEvents. Damit Responder GuiEvents empfängt, überschreibt dieKlasse die Methode processEvent. In dieser Methode wird je nach aktuellemStatus und Ereignis entschieden, ob der Status des Responders gewechseltwerden muss (siehe Abbildung 29). Wenn der Status wechselt, wird ein State-ChangeEvent erzeugt und an registrierte Listener verteilt. StateChange-Events enthalten den alten und den neuen Zustand des Responders.C, DINACTIVETransitionen:A Cursor verlässt SzeneobjektB Cursor überfährt SzeneobjektC Aktivierungsgeste ausgeführtD Aktivierungsgeste aufgehobenBAAOVERDCACTIVEAbbildung 29: Die Transitionen zwischen den drei Zuständen eines Responders82

7 Interaktionskomponenten7.7.2 Implementierung von ButtonDie von Responder erbende Klasse Button fügt in das SoSwitch-Objekt desResponders drei Labels ein, so dass das Szeneobjekt ein sichtbares Modellerhält (siehe Abbildung 30). Für jeden der drei Zustände (»inactive«, »over«,»active«) wird ein Label (mit unterschiedlichen Farben) instanziiert. Durch dasVerhalten der Klasse Responder – also das Setzen des Zustandes und Wahleines Unterobjektes aus ihrem SoSwitch-Objekt – erhält Button das eingangsbeschriebene Verhalten (Änderung der Farbe beim Überfahren und Aktivieren).ButtonstateSwitchvon Respondergeerbtes SoSwitch-Objekt(wählt je nach Zustandeines der drei enthaltenenLabel aus)inactiveLabeloverLabelactiveLabelAbbildung 30: Szenegraph von Button(vereinfachte Darstellung, vollständiges Szenegraphdiagramm in Anhang D)Button bietet Zugriffsmethoden um den Text der Labels zu setzen und derenGröße einzustellen, die an die drei enthaltenen Labels delegiert werden (sieheAbbildung 31).83

7 InteraktionskomponentenResponder«EventProvider»Button+ Button()+ Button(label: String, name: String, translation: SbVec3f)# ~Button()+ setLabel(newLabel: String): void+ setSize(size: SbVec2f): void+ getSize(): SbVec2f+ addActionListener(ActionEventListener): void+ removeActionListener(ActionEventListener): void+ processEvent(event: StateChangeEvent): void+ initClass(): voidstateSwitchSoSwitch3inactiveState,overState,activeStateLabelAbbildung 31: Die Klasse ButtonButtons erzeugen bei der Instanziierung drei Label, die in dem »stateSwitch« SoSwitch-Objektder Elternklasse Responder enthalten sind.7.7.3 Erzeugung eines ActionEventsDie Benachrichtigung über Auslöseereignisse wird wieder über das Observer-Pattern weitergeleitet. Dazu registriert sich Button als Empfänger für State-ChangeEvents bei sich selbst (beziehungsweise bei der geerbten Responder-Klasse) 16 . Sobald ein StateChangeEvent empfangen wird, das den Zustandswechselvon Active zu Over markiert (siehe Abbildung 29), wird ein Action-Event erzeugt.Buttons benachrichtigen registrierte Observer also in dem Moment, in dem derBenutzer die Geste zur Aktivierung über dem Button aufhebt. Das ähnelt demVerhalten von Buttons aus vielen 2D-Benutzerschnittstellen, die in dem Momentfeuern, in dem der Benutzer die Maustaste über dem Button loslässt.7.7.4 CheckBox und RadioButtonDie Spezialisierungen von der Klasse Button CheckBox und RadioButton entsprechenden aus 2D-Benutzerschnittstellen bekannten Interfaceelementen16 Die daraus resultierende Assoziation wird im UML-Diagramm ausgelassen. Die Software-Aspekte, die zur Ereignisbehandlung gehören, werden genauer in Abschnitt 7.9 beschrieben.84

7 Interaktionskomponenten(siehe Abbildung 32). Sie erweitern Buttons um einen Zustand (markiert odernicht markiert) und bieten Zugriffsmethoden dafür.Abbildung 32: CheckBox und RadioButtonRadioButton – als Erweiterung der CheckBox – bietet zusätzlich die Möglichkeit,RadioButtonszu Gruppen zusammmenzufassen, die sicher stellen, dassimmer nur ein Mitglied der Gruppe markiert sein kann. Dazu wird von Radio-Buttons, die eine Gruppe bilden, eine gemeinsam genutzte Liste verwaltet, diealle Gruppenmitglieder referenziert. Diese 1:n-Beziehung ermöglicht das Entfernender alten Markierung aus einem anderen RadioButton, sobald ein neuesMitglied der Gruppe aktiviert wird.Buttonstd::setRadioButtonbuttonGroup 0..1CheckBox+ CheckBox()+ CheckBox(label: String, name: String,translation: SbVec3f,initiallyChecked: bool)# ~ CheckBox()+ getChecked(): bool+ setChecked(checked: bool): void+ processEvent(ActionEvent): void+ initClass(): void2..* groupMemberRadioButton+ RadioButton()+ RadioButton(label: String, name: String,translation: SbVec3f,initiallyChecked: bool)# ~ RadioButton()+ joinGroup(memberOfGroup: RadioButton)+ leaveGroup(): void+ setChecked(checked: bool): void+ processEvent(ActionEvent): void+ initClass(): voidAbbildung 33: Schnittstellen von CheckBox und RadioButtonJederRadioButton kann Mitglied einer Gruppe sein, jede Gruppe referenziert mindestens zweiRadioButtons.85

7 Interaktionskomponenten7.8 RotorDie Entwicklung der Klasse Rotor resultierte aus der Überlegung, dass es Interaktionskomponentengeben muss, die die Auswahl eines Elementes aus einerListe von Elementen ermöglichen. Die entsprechenden 2D-Benutzerschnittstellenelementesind Menüs oder Tabellen mit Scrollbalken, deren Zeilen die auswählbarenElemente darstellen.Die Technik mit Scrollbalken ist aber für die Anwendung in der AugmentedReality zu komplex – sowohl grafisch als auch bezüglich der Bedienung. Außerdemdienen Scrollbalken in 2D-Schnittstellen dazu, die Begrenzung des Fenstersauf einen virtuellen, größeren Bereich abzubilden. Da diese Begrenzung im 3D-Raum nicht vorhanden ist, sollte eine intuitiver zu benutzende Interaktionskomponenteentwickelt werden. Dabei sollte bewusst die Tiefe als zusätzliche Dimensiongenutzt werden, um so auch den Raumeindruck als Orientierungswertnutzen zu können.Im experimentellen Prototyping hat sich der nachstehend beschriebene Rotorbewährt. Der Rotor ordnet seine Elemente so im Raum an, dass sie einen aufder Seite liegenden Zylinder ergeben (siehe Abbildung 34). Die nach vorne sichtbarenElemente können vom Benutzer ausgewählt werden. Um zu den Elementenauf der Rückseite des Zylinders zu gelangen, bewegt er den Gestencursorüber oder unter den Zylinder, der sich daraufhin in die jeweilige Richtung dreht.Je weiter der Benutzer den Gestencursor vom Zentrum des Zylinders entfernt,desto schneller dreht sich der Zylinder.Abbildung 34: Die Interaktionskomponente RotorDie Seitenansicht auf den Rotor dient nur der Verständlichkeit, der Benutzer sieht den Rotornormalerweise von vorne.86

7 InteraktionskomponentenImplementierungZur Implementierung verwendet Rotor die Klasse List, die die enthaltenen Elementeverwaltet. Als Basisklasse von Rotor erlaubt sie beliebige Interaktionskomponentenals Elemente. Dazu stellt sie ähnliche Zugriffsmethoden zur Verfügungwie Container – mit dem Unterschied, dass List-Objekte nur Interaktionskomponentenals Elemente annehmen.ContainerList+ List()# ~List()+ getNumElements(): int+ getElement(index: int): T+ getElement(name: String): T+ addElement(element:GuiComponent): void+ removeElement(element:GuiComponent): void+ removeAllElements(): void+ isElement(element:GuiComponent): bool+ setElementsEnabled(enabled:bool): void+ getElementsEnabled(): bool+ initClass(): void«Listener»Rotor+ Rotor()# ~Rotor()+ processEvent(MoveEvent): void– updateRotor(): void– updateControls(): void+ initClass(): voidSoTimerSensor2ResponsivePanelAbbildung 35: Die Klasse RotorDie Klasse Rotor (siehe Abbildung 35) erweitert die Funktionalität von List umdie geometrische Anordnung der Elemente zu einem Zylinder. Außerdem instanziiertsie zwei ResponsivePanels, die dazu dienen, den Gestencursor oberhalboder unterhalb des Zylinders zu erkennen. ResponsivePanel ist eine Interaktionskomponenteohne grafische Repräsentation, die GuiEvents empfängt, unddarausMoveEvents erzeugt – sofern sich der Cursor über einer (unsichtbaren)Fläche befindet.87

7 InteraktionskomponentenAbbildung 36: Interaktion mit dem RotorDie blauen Flächen in Abbildung 36 oberhalb und unterhalb des Rotors kennzeichnenResponsivePanel-Objekte,die bei Überfahren mit dem GestencursorMoveEventsgenerieren. Der Rotor empfängt diese Events und dreht sichentsprechend, so dass vorher nicht sichtbare Elemente nach vorne gelangen.Zur kontinuierlichen Drehung des Rotors während der Benutzer den Gestencursorüber einem der ResponsivePanels hält, benutzt Rotor ein SoTimer-Sensor-Objekt (siehe Fußnote 12). In dessen Callback wird der Rotor 20 Malpro Sekunde um einen Winkelbetrag gedreht, der sich danach richtet, wo derBenutzer den Gestencursor auf dem ResponsivePanel positioniert hat. Dadurchdreht sich der Rotor schneller, wenn sich der Cursor weiter weg vomZentrum des Rotors befindet.7.9 EreignisbehandlungIn den obigen Abschnitten der Beschreibung der Interaktionskomponenten wurdeschon mehrfach die Ereignisbehandlung erwähnt. In der Tat ist die Weiterleitungvon Ereignissen ein zentraler Mechanismus in mare, der an vielen Stelleneingesetzt wird. Daher wurde schon bei der Modellierung viel Wert auf die Auswahldes geeignetsten Verfahrens gelegt. Es wurden die folgenden Möglichkeitenuntersucht:88

7 Interaktionskomponenten– OpenInventor Globale Felder– OpenInventor Ereignisse– Observer PatternObwohl nach der Evaluation das Observer Pattern ausgewählt wurde, sollen hiernoch einmal die Vor- und Nachteile und die Entscheidungskriterien aufgeführtwerden.7.9.1 OpenInventor Globale FelderOpenInventor bietet die Möglichkeit, so genannte globale Felder anzulegen.Felder werden in OpenInventor die Datentypen genannt, die als grundlegendeAttribute der Szeneobjekte Verwendung finden. So gibt es zum Beispiel dieTypenSoSFInt32 (32-Bit-Integer Datentyp als Feld) und SoSFVec3f (dreidimensionalerVektor aus float).Globale Felder gehören nicht zu einem Szeneobjekt, sondern sind statisch durchString-Schlüssel zugreifbar und werden als Teil der Szene betrachtet (siehe[Wernecke94], Seite 337f.).Felder können über Feldverbindungen (siehe [Wernecke94], Seite 334) verbundenwerden, so dass Änderungen, die an einem Feld durchgeführt werden,automatisch in das verbundene kopiert werden. Diese Möglichkeit könnte manzum Beispiel nutzen, um direkt die Ausgabe eines CheckBox-Buttons (die einAttribut vom Typ SoSFBool wäre) an ein Szeneobjekt zu knüpfen (zum Beispielden Schalter einer Lichtquelle). Der Vorteil von solchen Verknüpfungen liegtdarin, dass zur Herstellung nur ein geringer Aufwand nötig ist. Außerdemwerden Feldverbindungen auch in OpenInventor-Dateien geschrieben, so dassganze Szenen mitsamt ihrer Verbindungs-Logik gespeichert werden könnten.Um auf Feldveränderungen individuell reagieren zu können, bietet OpenInventordieSoFieldSensor-Klasse, deren Objekte mit einem Feld verbunden werdenund die bei Änderung des Feldes eine Callback-Funktion aufrufen. Dadurchkönnen zum Beispiel nach Anklicken eines Buttons beliebige Aktionen ausgeführtwerden.Nachteilig an diesem Verfahren ist, dass es eigentlich nicht dazu gedacht ist,Ereignisse weiterzuleiten, sondern Zustände zu speichern und zu verteilen. Sowürde zum Beispiel ein betätigter Button seinen Boolean-Ausgang kurzzeitig von89

7 Interaktionskomponentenfalse auf true setzen, um kurz darauf wieder auf false zurückzuschalten. Dieswürde registrierte SoFieldSensor-Objekte zweimal (nach jeder Zustandsänderung)den Callback ausführen lassen – was aber nach einer einfachen Betätigungnicht gewünscht ist.Ein weiterer Nachteil ist die enge Bindung an die OpenInventor-Bibliothek, wasin Hinblick auf lose Kopplung und mögliche Erweiterung von mare auf andereSzenegraphbibliotheken nicht gewünscht ist.7.9.2 OpenInventor EventsOpenInventor bietet ein eigenes Verfahren, um Ereignisse an Szeneobjekte zuverteilen. Dazu wird ein von SoEvent abgeleitetes Objekt erzeugt und mittelseinerSoHandleEventAction im Szenegraph verteilt. Auf diese Art werdenzum Beispiel Maus- und Tastaturereignisse an interaktive Szeneobjekte derOpenInventor-Bibliothek weitergegeben.Das Verfahren eignet sich gut, um Low-Level-Ereignisse (zum Beispiel Tastendruckoder Mausbewegung, aber auch Trackerdaten) im Szenebaum zu verteilen.Um ein Ereignis zu empfangen, muss ein SoEventCallback-Szeneobjekt inden Szenegraph eingesetzt werden, das nach Empfang eines Ereignisses eineCallback-Funktion aufruft. Die Art der Verteilung richtet sich dabei nach demAufbau des Szenegraphen, der von der SoHandleEventAction traversiertwird. Sobald ein Szeneobjekt das Ereignis empfängt und ein »Wurde-Behandelt«-Flagzurückgibt, wird die weitere Traversion des Szenegraphen abgebrochen.Ebenso wie das oben beschriebene Verfahren mit Globalen Feldern sind natürlichauch die OpenInventor-Ereignisse an die OpenInventor-Bibliothek geknüpft.Ein weiterer Nachteil ist das starre Modell der Traversion über den Szenegraphen:Ereignisse werden in einer durch den Szenegraphen vorgegebenen Reihenfolgean Klienten verteilt – und möglicherweise wird diese Verteilung sogarabgebrochen, wenn einer der Klienten dies anzeigt. Diese Vorgehensweise ist fürHigh-Level-Events, wie Button-Betätigung oder CheckBox-Markierung-Setzennicht gut geeignet, da in solchen Fällen beliebige Klienten (nicht nur Szeneobjekte)benachrichtigt werden sollen.90

7 Interaktionskomponenten7.9.3 Observer PatternDas Observer Pattern (siehe [GHJV96], Seite 257ff.) stellt eine universelle Lösungzur Weiterleitung von Ereignissen an beliebig viele Klienten dar. Es ist weder aneine Bibliothek, noch an eine Datenstruktur gekoppelt. Beliebige Klienten könnensich einfach registrieren und werden daraufhin mit Ereignissen versorgt.In mare wird dieses Muster verwendet,– um Ereignisse von der Gestenerkennung an die Interaktionskomponentenweiterzuleiten,– um innerhalb der Interaktionskomponenten Ereignisse in andere Ereignisseumzuwandeln und schließlich,– um Ereignisse an mare-Anwendungscode zu schicken.Der besonders flexible und stark entkoppelnde Ansatz des Observer-Patternshat uns – gemeinsam mit der besonders effektiven Möglichkeit der Implementierung– dazu bewogen, dieses Verfahren für die Entwicklung von mare einzusetzen.:EventProvider:ListenerfireEvent()*[list of Listener]processEvent()Abbildung 37: Ereignisverteilung mit EventProvidern und ListenernImplementierung in C++Um das häufig benutzte Observer-Pattern nicht für jede Sorte von Ereignissenneu schreiben zu müssen, bietet mare Template-Klassen, die für diesen Zweckwiederverwendbaren, generischen Code enthalten.91

7 InteraktionskomponentenEventtypeListener*+ processEvent(EventTyp): voidEventProviderEventtype+ addListener(Listener): void+ removeListener(Listener): void# fireEvent(EventTyp): voidAbbildung 38: Implementierung des Observer-Pattern als Template-KlassenEinemEventProvider-Objekt (in [GHJV96] »Subject« genannt) werden beliebig vieleListener-Objekte (»Observer«) zugeordnet.Als Templateparameter verwenden die Klassen EventProvider undListener den Ereignistyp, den sie verarbeiten sollen. So kann durch Templateinstanziierungder jeweilig gebrauchte EventProvider- oder Listener-Typerzeugt und von einer konkreten EventProvider- oder Listener-Klasse beerbtwerden.Beispiel: StateChangeEvent bei Responder und ButtonZur Verdeutlichung soll hier als Beispiel die Interaktionskomponente Button(siehe Abschnitt 7.7) dienen: Buttons empfangen von Responder-ObjektenStateChangeEvents (Überfahren, Aktivieren, ...) und erzeugen ActionEvents(Button wurde aktiviert).EventProvider«bind» (StateChangeEvent)«bind» (ActionEvent)Listener«bind» (StateChangeEvent)StateChange-EventProvider*StateChangeListenerActionEvent-ProviderResponderButtonAbbildung 39: Implementierung der Ereignisbehandlung in der Klasse Button92

7 InteraktionskomponentenDamitButtons als Listener zu Responder-Objekten hinzugefügt werdenkönnen 17 , muss die Klasse Button die Templateinstanziierung StateChange-Listener beerben. Zum Empfang der Ereignisse überschreibt Button dieabstrakte Methode processEvent aus Listener. In dieser Methode entscheidetsich, ob das StateChangeEvent zu einer Aktivierung des Buttons führt;wenn ja, wird ein ActionEvent 18 erzeugt.Damit dieses Ereignis weitergeleitet werden kann, erbt Button von Action-EventProvider.EventProvider enthält die Methode fireEvent, die einEreignis an alle zuvor registrierten Listener schickt (indem sie ihre process-Event-Methoden aufruft).7.9.4 Ereignisweiterleitung am Beispiel eines ButtonsUm die Ereignisweiterleitung innerhalb von Interaktionskomponenten beispielhaftzu beschreiben, wird hier der vollständige Weg eines Gestenereignisses vonder Gestenerkennung bis zu einem registrierten ActionEventListener aufgezeigt(siehe Abbildung 40). Das mare-Modul zur Gestenerkennung (im Sequenzdiagrammals Klient dargestellt) erzeugt ein GestureEvent und schicktes an das registrierte GuiKit (siehe Abschnitt 10.4.5 und Kapitel 11). Dieseserzeugt daraus ein GuiEvent und sendet es an alle enthaltenen Interaktionskomponenten,wozu auch der hier betrachtete Button gehört. Der Responder-Teil von Button empfängt das GuiEvent und wechselt daraufhin (möglicherweise)seinen Zustand (zum Beispiel von inactive zu over) und erzeugt dabei einStateChangeEvent. Der Button-Teil des Button-Objektes empfängt dasStateChangeEvent und, falls es die richtige State-Konstellation enthält, erzeugtder Button daraufhin das ActionEvent.17 Die Tatsache, dass Button von Responder erbt, ist zur Beschreibung der Ereignisbehandlungnachrangig und wird hier der Klarheit wegen nicht beachtet. Eigentlich registrieren sichButton-Objekte bei sich selbst als StateChangeListener.18 AuchActionEvent ist in der Implementierung eine Template-Klasse, deren Parameter denTyp der EventQuelle festlegt. Wenn also im Text von einem ActionEvent gesprochen wird,ist an dieser Stelle eigentlich ein ActionEvent gemeint. In mare werden verschiedeneActionEventsverwendet, zum Beispiel auch von RadioButton und Check-Box.93

7 Interaktionskomponenten:GuiKit:ButtonActionEvent:ListenerprocessEvent(GestureEvent)fireEvent(GuiEvent)processEvent(GuiEvent)setState()fireEvent(StateChangeEvent)processEvent(StateChangeEvent)[oldState == ACTIVEand newState == OVER]fireEvent(ActionEvent)processEvent(ActionEvent)processEvent(GuiEvent)fireEvent(GuiEvent)ContainerResponderButtonAbbildung 40: Ereignisweiterleitung am Beispiel eines ButtonsDie Farben kennzeichnen, in welcher (Basis-) Klasse der Vererbungshierarchie eines Buttons eineaufgerufene Methode implementiert ist.94

7 Interaktionskomponenten7.9.5 Ereignisse in mareIm Folgenden werden die mare-Ereignistypen und die Klassen, die sie erzeugenoder empfangen aufgelistet. Die Position in der Tabelle bezeichnet (ungefähr)das Niveau des Ereignisses – also wie nah das Ereignis an der Erzeugung durchden Benutzer liegt. Je weiter unten ein Ereignis steht, desto abstrakter ist es.Ereignistyp Ereignisquelle Auslöser Empfänger 19 WeiterverarbeitungSoEvent 20 SoQtRenderArea 2 Mausbewegung,MausklicksGuiKitUmwandlung zuGuiEventGestureEventGestureRecogniti mare-Geste GuiKit Umwandlung zuon 21 GuiEventCursorKitDarstellung desCursorsGuiEventGuiKit,ContainerGestureEvent,SoEventContainerWeiterleitung anUnterobjekteResponderUmwandlung zuStateChangeEventResponsivePanelUmwandlung zuMoveEventStateChangeEventResponderCursorbewegung, AktivierungButtonUmwandlung zuActionEventActionEventButtonAktivierungeines ButtonCheckBoxUmwandlung zuActionEventActionEventCheckboxMarkierungwechseltRadioButtonUmwandlung zuActionEventActionEventRadioButtonMarkierungwechseltMoveEvent ResponsivePanel CursorbewegungRotorEinstellung derWinkelgeschwindigkeitTabelle 2: Ereignistypen in mare19 Alle Ereignisse können natürlich auch von beliebigem mare-Anwendungscode empfangenwerden, der sich als Listener registriert. Im Falle eines ActionEvents eines Buttons istdies zum Beispiel sehr üblich. Hier werden nur die in mare implementierten Empfängeraufgelistet.20 Nicht Teil von mare, sondern aus OpenInventor21 siehe Abschnitt 10.4.595

7 Interaktionskomponenten7.10 Konstruktion durch PrototypenDie geometrischen Modelle der Interaktionskomponenten bestehen zum Teilaus recht komplexen Szenegraphen mit großen Datenteilen für Koordinaten undPolygone. Zum Beispiel besteht ein Button (ohne Text) aus 108 Punkten und 53Polygonen. Um die Konstruktion dieser Objekte zu vereinfachen, werden sie ausPrototypen erzeugt.Die eigentlichen 3D-Modellbeschreibungen sind in einer Konfigurationsdateigespeichert, die bei der ersten Konstruktion einer Interaktionskomponente geladenwird. Die Konfigurationsdatei ist eine OpenInventor oder VRML-Szenedateiund enthält benamte Modelle aller Interaktionskomponenten.Die Singleton-Klasse Resource dient dazu, diese 3D-Modelle als Prototypen zuverwalten.Resource bietet eine Methode, die anhand eines Namens das gesuchteSzeneobjekt zurück liefert. Auf diese Art können die Konstruktoren derInteraktionskomponentenklassen die Szeneobjekte aus denen sie bestehen einfachvon Resource abfragen.Der Vorteil dieses Vorgehens liegt darin, dass das Erscheinungsbild der Interaktionskomponenteneinfach durch Ändern der Konfigurationsdatei angepasstwerden kann. Um zum Beispiel eine mare-Anwendung zu schreiben, die leuchtroteButtons verwendet, oder bei der die Checkboxen die Form von Kippschalternhaben, müsste ein mare-Anwendungsentwickler einfach die entsprechenden3D-Modelle in die Konfigurationsdatei schreiben.Resource– m_instance: Resource– Resource()+ ~Resource()+ get(name: String): T+ getCopy(name: String): T+ instance(): ResourceAbbildung 41: Schnittstelle der Klasse ResourceDie als Singleton implementierte Klasse hat einen privaten Konstruktor und kann somit nur aus sichselbst heraus instanziiert werden. Dies tut die statische Methode instance, wenn sie das ersteMal aufgerufen wird.96

7 Interaktionskomponenten7.11 ZusammenfassungZur Erzeugung von Benutzerschnittstellen wurden die mare-InteraktionskomponentenPanel,Label,Button,CheckBox,RadioButtonund Rotor entwickelt.Die erweiterbare und wiederverwendbare Implementierung der Interaktionskomponentenermöglicht mare-Anwendungsentwicklern aufgabenspezifischeModifikationen und Erweiterungen. Zur losen Kopplung der Interaktionskomponentenuntereinander und der Anbindung an die Gestenerkennung dientdie Ereignisbehandlung.97

Hauptteil IIIGestenerkennung

»Wahrnehmung ist immer die Folge eineserwartungsgesteuerten Suchprozesses.«,Wolf Singer, Neurowissenschaftler,Interview Spiegel Special 4/2003ÜberblickIm letzten Teil wurden die Interaktionskomponenten vorgestellt, mit denen sichInteraktionsschnittstellen für die Systemsteuerung von Augmented-Reality-Anwendungen erstellen lassen.Dieser Teil der Arbeit beschäftigt sich mit der Steuerung der Interaktionskomponentendurch die mare-Geste. Dafür muss die mare-Geste in den Videobilderndurch ein geeignetes Verfahren erkannt werden. Zuerst werden inKapitel 8 die Anforderungen an das Erkennungsverfahren festgelegt und anhanddieser zwei mögliche Erkennungsverfahren für weitere Untersuchungen ausgewählt.Das darauf folgende Kapitel 9 beschreibt das erste der Verfahren, dasShape Context Matching, und begründet, warum wir es nicht für die Erkennungder mare-Geste einsetzen. Kapitel 10 beschreibt das zweite und letztlich für dieErkennung der mare-Geste gewählte Verfahren, das Elastic Graph Matchingmit unseren Weiterentwicklungen.

8 Auswahl zu untersuchender Erkennungsverfahren8 Auswahl zu untersuchenderErkennungsverfahrenIm ersten Abschnitt dieses Kapitels werden die Anforderungen an das umzusetzendeErkennungsverfahren festgelegt. Im zweiten Abschnitt werden – auf dieAnforderungen Bezug nehmend – zwei mögliche Erkennungsverfahren ausgewählt.8.1 Anforderungen an das ErkennungsverfahrenUm die Anforderungen an das umzusetzende Erkennungsverfahren festzulegen,werden zuerst die Anforderungen an ein ideales Verfahren benannt, um diesedann auf die Anforderungen einzuschränken, die im Rahmen dieser Arbeit gelten.8.1.1 Anforderungen an ein ideales ErkennungsverfahrenFunktionale AnforderungenUm das Ziel, die Steuerung von Interaktionskomponenten durch die mare-Geste,zu erreichen, muss ein Erkennungsverfahren folgende funktionale Anforderungenerfüllen:1 Bestimmung des Vorhandenseins einer Hand, die die mare-Handhaltunghat:Das Erkennungsverfahren muss entscheiden können, ob eine Hand imVideobild zu sehen ist, die die mare-Handhaltung hat. Insbesonderemuss das Verfahren eine Hand, die eine beliebige andere Handhaltunghat, von einer, die die mare-Handhaltung hat, unterscheiden können.Dies ist notwendig, da die normale Tätigkeit eines Monteurs es erfordert,dass er seine Hände in gewohnter Weise verwenden kann, ohnedabei unbeabsichtigt Gestenereignisse auszulösen.2 Bestimmung der Abbildpositionen von Daumen- und Zeigefingerspitze:Wenn eine Hand im Videobild zu sehen ist, die die mare-Handhaltunghat, dann muss das Erkennungsverfahren die Positionen der Abbildervon Daumen- und Zeigefingerspitze bestimmen können. Denn diesesind die Voraussetzung für die korrekte Anzeige des Gestencursors.101

8 Auswahl zu untersuchender Erkennungsverfahren3 Erkennung der mare-Geste aus den Abbildpositionen von DaumenundZeigefingerspitze:Das Erkennungsverfahren muss aus den Abbildpositionen von DaumenundZeigefingerspitze ableiten können, ob die Handhaltung der zeigendenoder der aktivierenden Phase der mare-Geste entspricht.Nicht-funktionale AnforderungenNeben den genannten funktionalen Anforderungen muss das Erkennungsverfahreneinige nicht-funktionale Anforderungen erfüllen:4 Robust gegenüber der Position des Handabbilds:Die Hand kann sich bei Ausführung der mare-Geste durch das Bild bewegen.Das Erkennungsverfahren muss die Hand an jeder beliebigenPosition im Bild finden können. Insbesondere darf nicht Voraussetzungfür eine korrekte Erkennung der Geste sein, dass in einem bestimmtenBereich des Bildes mit der mare-Geste begonnen wird.5 Robust gegenüber der Größe des Handabbilds:Es muss davon ausgegangen werden, dass die Hand ihre Entfernung zurKamera ändert und sich dadurch die Größe ihres Abbilds ändert. Das Erkennungsverfahrenmuss robust gegenüber solchen Größenänderungensein.6 Robust gegenüber der Handform:Die Hand ist das universellste Werkzeug des Menschen, und sie kann inverschiedenster Weise verformt werden. Einem Menschen ist es nichtmöglich, seine Hand immer in exakt der gleichen Weise zu formen. Eskönnen beispielweise die Fingerkrümmung oder der Abstand der Fingerbei gleicher Krümmung variieren. Es ist notwendig, dass das Erkennungsverfahrenunabhängig von diesen Formfreiheitsgraden die mare-Handhaltung erkennen kann.7 Robust gegenüber der Handrotation:Einem Menschen ist es nicht möglich, seine Hand immer in derselbenRotationslage zu halten. Das Erkennungsverfahren muss unabhängigvon Rotationen um wenige Grad in allen Raumrichtungen sein.102

8 Auswahl zu untersuchender Erkennungsverfahren8 Unabhängig von der Hautfarbe:Das Erkennungsverfahren muss für Menschen beliebiger Hautfarbe einsetzbarsein.9 Unabhängig von der Handgeometrie:Das Erkennungsverfahren muss für Menschen mit unterschiedlicherHandgeometrie einsetzbar sein. Beispielsweise können sich die Händeverschiedener Menschen in den Knochenlängen unterscheiden.10 Unabhängig von der Händigkeit:Das Erkennungsverfahren muss sowohl für Links- wie auch Rechtshändereinsetzbar sein.11 Robust gegenüber der Beleuchtung:Da mare für den mobilen Einsatz geplant ist, kann sich die Beleuchtungssituationlaufend ändern. Das Erkennungsverfahren muss auch unterBedingungen wie zum Beispiel Gegenlicht oder Beleuchtung von untenzuverlässig funktionieren.12 Robust gegenüber dem Hintergrund:Da mare für den mobilen Einsatz geplant ist, muss das Erkennungsverfahrendie Hand vor verschiedensten Arten von Hintergründen findenkönnen; insbesondere muss davon ausgegangen werden, dass der Hintergrundnicht homogen ist. 2213 Unabhängig von bewegtem Hintergrund:Da mare für den mobilen Einsatz geplant ist, ist die Kameraposition variabelin Bezug auf den Hintergrund. Das Erkennungsverfahren muss dieHand also auch vor bewegtem Hintergrund finden können.14 Nicht wahrnehmbare Erkennungsungenauigkeit:Da die Hand zum Zwecke der Steuerung von Interaktionskomponentengefunden werden soll, muss das Erkennungsverfahren eine Erkennungsgenauigkeiterreichen, die es einem Monteur ermöglicht, die Interaktionskomponentenzu bedienen. Für ein ideales Verfahren ist die Erkennungsgenauigkeitso hoch, dass ein menschlicher Betrachter des Videobildeskeine Abweichung von der von ihm erwarteten Erkennung derAbbildpositionen von Daumen- und Zeigefingerspitze wahrnehmenkann.22 engl. »cluttered background«103

8 Auswahl zu untersuchender Erkennungsverfahren15 Nicht wahrnehmbare Erkennungsfrequenz:Die Frequenz der Erkennungen muss so hoch sein, dass der Benutzerdie Interaktionskomponenten komfortabel bedienen kann. Für ein idealesVerfahren ist die Erkennungsfrequenz so hoch, dass die Bewegungdes durch die Gestenerkennung gesteuerten Gestencursors als ruckelfreiwahrgenommen wird. 2316 Nicht wahrnehmbare Erkennungsverzögerung:Die Erkennungsverzögerung ist die Zeit, die zwischen der Aufnahme einesBildes durch die Videokamera und dem Abschluss der Analyse diesesBildes durch das Erkennungsverfahren vergeht. Sie muss so kleinsein, dass sie von einem menschlichen Betrachter nicht wahrgenommenwerden kann. 248.1.2 Anforderungen an das umzusetzende ErkennungsverfahrenDie im vorherigen Abschnitt benannten Anforderungen an ein Verfahren zur Erkennungder mare-Geste lassen sich im Rahmen dieser Arbeit nicht vollständigerfüllen. Dies liegt an der begrenzten Zeit in Verbindung mit der Tatsache, dassdie Gestenerkennung auf Basis von Videobildern noch immer ein Forschungsgegenstandist und bisher keine Standardlösung existiert, die alle Anforderungenfür alle möglichen Einsatzgebiete erfüllt.23 Leider lässt sich dafür keine allgemeine Bildwiederholungsrate angeben, da auch das Aussehendes bewegten Objekts und seine Geschwindigkeit für eine ruckelfreie Wahrnehmungeine Rolle spielen. Man könnte an dieser Stelle von der für Zeichentrickfilme üblichen Bildwiederholungsratevon zwölf Hertz ausgehen.24 Auch für die maximale Erkennungsverzögerung, die noch nicht von einem menschlichen Betrachterwahrgenommen wird, lässt sich keine allgemeine Aussage treffen. Man könnte vondem Kehrwert der Erkennungsfrequenz ausgehen, also einer zwölftel Sekunde.104

8 Auswahl zu untersuchender ErkennungsverfahrenFunktionale AnforderungenAlle funktionalen Anforderungen (Anforderungen 1 bis 3) müssen zwingenderfüllt sein, damit ein Erkennungsverfahren einsatzfähig ist:Nr Anforderung M 25 E 261 Bestimmung des Vorhandenseins einer Hand, die die mare-Handhaltung hat2 Bestimmung der Abbildpositionen von Daumen- und Zeigefingerspitze3 Erkennung der mare-Geste aus den Abbildpositionen vonDaumen- und ZeigefingerspitzeXXXTabelle 3: Funktionale Anforderungen an das umzusetzende ErkennungsverfahrenNicht-funktionale AnforderungenDas in dieser Arbeit umzusetzende Erkennungsverfahren kann einige nichtfunktionaleAnforderungen nur eingeschränkt erfüllen:Nr Anforderung M 26 E 274 Robust gegenüber der Position des Handabbilds X5 Robust gegenüber der Größe des Handabbilds X6 Robust gegenüber der Handform X7 Robust gegenüber der Handrotation X8 Unabhängig von der Hautfarbe X9 Unabhängig von der Handgeometrie X10 Unabhängig von der Händigkeit X11 Robust gegenüber der Beleuchtung X12 Robust gegenüber dem Hintergrund X13 Unabhängig von bewegtem Hintergrund X14 Nicht wahrnehmbare Erkennungsungenauigkeit X15 Nicht wahrnehmbare Erkennungsfrequenz X16 Nicht wahrnehmbare Erkennungsverzögerung XTabelle 4: Nicht-funktionale Anforderungen an das umzusetzende Erkennungsverfahren25 Muss vom umzusetzenden Verfahren erfüllt werden.26 Muss vom umzusetzende Verfahren eingeschränkt erfüllt werden.105

8 Auswahl zu untersuchender ErkennungsverfahrenZu den Anforderungen 4 bis 7:Die Robustheit gegenüber der Position und Größe des Handabbilds sowie gegenüberHandform und -größe sind notwendige Voraussetzungen für die Einsatzfähigkeitdes Erkennungsverfahrens.Zu Anforderung 5:Allerdings ist der Bereich, in dem das umzusetzende Erkennungsverfahrenrobust gegenüber der Größe des Handabbildes sein muss, gegenübereinem idealen Erkennungsverfahren einzuschränken: Es soll gelten,dass der Monteur die Hand immer in einem Abstandsbereich von zehnZentimetern um einen angenehmen Hand-Kamera-Abstand hält.Zu den Anforderungen 8 bis 10:Das Erkennungsverfahren muss in der umzusetzenden Form nicht bereits unabhängigvon Hautfarbe, Handgeometrie und Händigkeit sein. Es muss aber prinzipiellfür beliebige Menschen einsetzbar sein.Zu Anforderung 11:Das umzusetzende Erkennungsverfahren muss robust gegenüber leicht unterschiedlicherBeleuchtungen, wie unterschiedlicher Lichttemperatur (Tageslichtim Gegensatz zu Kunstlicht) und Beleuchtungsrichtung, sein. Es muss nicht robustgegenüber starkem Gegenlicht sein, da dies sehr große Unterschiede imObjektabbild verursachen kann.Zu Anforderung 12:Das umzusetzende Erkennungsverfahren muss die Hand vor hellem und dunklemHintergrund gleichermaßen finden können. Allerdings muss die Erkennungvor inhomogenem Hintergrund nicht gewährleistet sein.Zu Anforderung 13:Wenn der Hintergrund homogen ist (vgl. Anforderung 12), muss das Erkennungsverfahrenauch bei bewegter Kamera – und folglich auch bewegtem Hintergrund– funktionieren.Zu Anforderung 14:Die Erkennungsungenauigkeit des umzusetzenden Erkennungsverfahrens mussnicht so gering sein, dass sie nicht wahrnehmbar ist, sondern nur so gering, dassdamit eine effektive Steuerung der Interaktionskomponenten möglich ist.Zu den Anforderungen 15 und 16:Die Erkennungsfrequenz des umzusetzenden Erkennungsverfahrens muss auf106

8 Auswahl zu untersuchender Erkennungsverfahrender zur Verfügung stehenden Plattform (Pentium 4, 2,6 GHz) nur bei zwei Hertzliegen, die Erkennungsverzögerung entsprechend bei einer halben Sekunde.8.2 Verfahren zur GestenerkennungDieser Abschnitt gibt einen Überblick über die unterschiedlichen Verfahren,Handgesten in Videobildern zu erkennen.Dabei orientieren wir uns an den Unterscheidungskriterien aus [PSH97]. Dortwerden Verfahren zur Erkennung von Handgesten in folgende Hauptbestandteilezerlegt:1. Gestenmodellierung 272. Gestenanalyse 283. Gestenerkennung 29Für jeden dieser Schritte können unterschiedliche Erkennungsverfahren verschiedeneAnsätze verwenden. Im Folgenden werden die Schritte und ihre Funktiongenauer erläutert. Dabei werden mögliche Ansätze bezüglich ihrer Tauglichkeitzur Erfüllung der oben definierten Anforderungen untersucht.8.2.1 GestenmodellierungVoraussetzung für jedes Gestenerkennungsverfahren ist das Vorhandensein einesModells, mit dessen Modellparametern sich die Geste darstellen lässt. Wiedie Geste modelliert wird, hängt vor allem von deren Komplexität ab. Nach[PSH97] kann für eine bestimmte Anwendung ein einfaches Modell ausreichendsein; aber wenn natürliche Interaktion angestrebt wird, muss ein Modell verwendetwerden, das viele oder sogar alle natürlichen Gesten abbildet.Es muss sowohl der zeitliche wie auch der räumliche Aspekt einer Geste modelliertwerden. Da die mare-Geste nicht zeitabhängig ist, unterscheiden wir andieser Stelle ausschließlich zwischen den beiden Möglichkeiten, den räumlichenAspekt einer Geste zu modellieren:27 engl. »gesture modeling«28 engl. »gesture analysis«29 engl. »gesture recognition«107

8 Auswahl zu untersuchender ErkennungsverfahrenZum einen gibt es die Erkennungsverfahren, die ein dreidimensionales Modellder Hand für Analyse-durch-Synthese verwenden. Die Idee hinter diesem Ansatzist, das dreidimensionale Modell der Hand solange zu variieren, bis dessen Erscheinungsbildmit der Hand im Videobild übereinstimmt. Die Modellparameterkönnen zum Beispiel die Position des Handrückens und die Winkel der Fingergelenkesein.Zum anderen gibt es die erscheinungsbasierten Verfahren, die die Gesten direktmit dem Erscheinungsbild der Hand verbinden. Als Modell wird also nicht diedreidimensionale Form der Hand, sondern beispielsweise deren Kontur oder diePosition der Finger im Bild verwendet.Nach [PSH97] eignen sich erscheinungsbasierte Modelle für einen kleineren Teilmöglicher Gesten als die Verfahren, die ein dreidimensionales Modell der Handverwenden. Ihr Vorteil liegt aber in der geringeren Rechenkomplexität. Da dieErkennung der mare-Geste mit möglichst hoher Erkennungsfrequenz und möglichstgeringer Erkennungsverzögerung erfolgen soll (Anforderungen 15 und 16)und sie sich einer erscheinungsbasierten Modellierung erschließt, werden wir einerscheinungsbasiertes Verfahren verwenden. Die Modellparameter sind dabeidie Bildpositionen der gesamten Hand und die von Daumen- und Zeigefingerspitze.8.2.2 GestenanalyseErkennungsverfahren unterscheiden sich neben der Modellierung in der Art, wiedie Modellparameter des entsprechenden Modells aus dem Videobild ermitteltwerden. Dabei sind drei Schritte zu unterscheiden:1. Lokalisierung 302. Merkmalserkennung 313. Parameterbestimmung 3230 engl. »localization«31 engl. »feature detection«32 engl. »parameter estimation«108

8 Auswahl zu untersuchender ErkennungsverfahrenLokalisierungViele Erkennungsverfahren erfordern vor der eigentlichen Merkmalserkennungeine sogenannte Lokalisierung der Hand, beispielsweise die in [NHA03] oder[BLLLS01] beschriebenen Verfahren. Lokalisierung der Hand heißt, dass der Bildbereich,in dem das Abbild der Hand liegt, gefunden werden muss. Dafür wirdhäufig das Verfahren der Hintergrundsubtraktion 33 verwendet, oder es wird nachBildbereichen bestimmter Farbwerte (wie beispielsweise Hautfarbe) gesucht,oder es werden die Bildbereiche bestimmt, in denen sich zwischen zwei VideobildernVeränderungen ergeben haben. Dies widerspricht jedoch den Anforderungen,dass das Erkennungsverfahren robust gegenüber der Beleuchtung undrobust gegenüber unterschiedlichem Hintergrund sowie unabhängig von bewegtemHintergrund sein muss (Anforderungen 11 bis 13). Das Erkennungsverfahrendarf also keinen separaten Lokalisierungsschritt vor der Merkmalsextraktionerfordern.Um die Hand leichter zu finden, ist es auch üblich, dass Erkennungsverfahren dieBenutzung einfarbiger Handschuhe oder die Anbringung von Markern an derHand und den Fingern erfordern. Dies würde den Monteur einschränken, weswegenwir solche Ansätze vermeiden wollen. 34MerkmalserkennungBei der Merkmalserkennung wird das Bild auf einen bestimmten Merkmalstyphin untersucht und die Merkmale aus dem Bild extrahiert, die die Hand beschreiben.Als Merkmalstypen können zum Einsatz kommen:– Graustufen- oder Farbbilder der Hand und der Finger, beziehungsweisedes gesamten Bildes:Die Verwendung des Bildausschnitts, der die Hand und die Finger zeigt,als Merkmalstyp erfordert eine vorherige Lokalisierung dieses33 Dabei wird ein Bild, das nur den Hintergrund zeigt, pixelweise von den Bildern mit Handsubtrahiert, so dass die Pixel in den Hintergrundbereichen annähernd den Wert nullannehmen und so leicht der Bereich, in dem die Hand liegt, gefunden werden kann.34 Wir hatten noch folgende nicht ganz ernsthafte Idee: Aus praktischer Sicht wäre es für einenBenutzer durchaus keine Einschränkung, wenn man die farbige Lackierung von DaumenundZeigefingernagel in einer bestimmten ungewöhnlichen Farbe verlangte; aber auf Grundzu erwartender modischer Vorbehalte seitens der Benutzer haben wir diese Idee wiederverworfen.109

8 Auswahl zu untersuchender ErkennungsverfahrenAusschnitts, was wie oben beschrieben den Anforderungen widerspricht.Die Verwendung des gesamten Bildes als Merkmalstyp erlaubt es unterschiedlicheGesten zu klassifizieren, aber die Bestimmung der genauenModellparameter einer Geste ist nicht möglich (vgl. [PSH97]). Dies widersprichtalso der Anforderung, dass die Abbildpositionen von DaumenundZeigefingerspitze bestimmt werden müssen (Anforderung 2).– Silhouetten:Diese lassen sich vor homogenem Hintergrund durch Anwendung einesGraustufenschwellwertes oder Erkennung eines Farbbereiches bestimmen.Der Einsatz dieses Merkmalstyps widerspricht (wie ein separaterLokalisierungsschritt) den Anforderungen 11 bis 13.– Konturen:Diese werden durch Kantendetektion bestimmt 35 und können auf verschiedeneArten dargestellt werden; zum Beispiel als Polarkoordinatenoder im Freemancode (Kettencode). Ein Objekterkennungsverfahren,das auf Konturen basiert, ist das Shape Context Matching. Dieses wird inKapitel 9 hinsichtlich seiner Anwendbarkeit auf die Erkennung dermare-Geste untersucht.– Ortsfrequenzen:Diese können sich entweder auf das gesamte Bild beziehen oder aufeinzelne Bildbereiche. Erstere werden durch eine Fouriertransformationaus dem Bild extrahiert; sie können zwar für die Objektklassifikation eingesetztwerden, aber ähnlich wie bei der direkten Verwendung des Bildesals Merkmal, können die genauen Modellparameter der mare-Geste nicht bestimmt werden (Widerspruch zu Anforderung 2). Um dieBildfrequenzen einzelner Bildbereiche zu bestimmen, werden diese mitWavelets verschiedener Frequenzen und Orientierungen gefiltert 36 . Fürdas in Kapitel 10 untersuchte Elastic Graph Matching kommen GaborWavelets zum Einsatz.35 Es ist auch möglich, Konturen aus Silhouettenbildern zu gewinnen. In diesem Fall sind sieaber als äquivalent zu betrachten und es gelten die gleichen Gegenargumente.36 Das heißt, die Wavelets werden als Faltungskerne für Faltungen verwendet.110

8 Auswahl zu untersuchender ErkennungsverfahrenParameterbestimmungNach der Merkmalserkennung werden die Modellparameter aus den erkanntenBildmerkmalen bestimmt. Dies ist zwar von dem Merkmalstyp abhängig, aber injedem Fall für das Modell der mare-Geste problemlos zu realisieren. Wenn zumBeispiel die Kontur als Merkmalstyp verwendet wird, kann als Position der Daumen-oder Zeigefingerspitze der entsprechende Punkt der Kontur oder einDurchschnittswert eines Konturabschnittes verwendet werden.Die Bestimmung der Modellparameter für die mare-Geste stellt also keine weiterenBedingungen für die Auswahl des Erkennungsverfahrens.8.2.3 GestenerkennungAuch der letzte Schritt, die Erkennung der ausgeführten Geste, ist geradewegsumzusetzen, da für die mare-Geste kein zeitlicher Kontext beachtet werdenmuss, sondern sie eine ausschließlich zeigende Geste ist, und auch nur eine Gesteerkannt werden muss. Die üblicherweise für diesen Schritt eingesetzten HiddenMarkov Modelle (vgl. [FP03], Seite 550ff.) brauchen also nicht verwendetwerden. Stattdessen lässt sich aus den Positionen von Daumen- und Zeigefingerspitzeder Bereich auf den gezeigt wird als Mittelwert ableiten und die Aktivierungkann über einen zu unterschreitenden Abstandsschwellwert der Fingerspitzenermittelt werden.8.3 ZusammenfassungDie Untersuchung verschiedener Ansätze zur Erkennung der mare-Geste hatgezeigt, dass die Hauptaufgabe darin liegt, die Hand in mare-Handhaltung inden Videobildern zu finden. Die daran anschließenden Schritte Modellparameterbestimmungund Gestenerkennung lassen sich geradewegs umsetzen.Um die Hand in mare-Handhaltung zu finden, wurden zwei Objekterkennungsverfahrenzur weiteren Untersuchung ausgewählt. Dies sind: Shape Context Matchingund Elastic Graph Matching. Sie werden in den folgenden Kapiteln genaueruntersucht.111

9 Shape Context Matching9 Shape Context MatchingDas Shape Context Matching ist das erste der in dieser Arbeit untersuchten Objekterkennungsverfahren.Dieses Kapitel gibt zuerst eine kurze Einführung in dasVerfahren. Im Anschluss werden in der Literatur vorgeschlagene Verbesserungendargestellt und unsere Umsetzung einer dieser Verbesserungen mit deren Ergebnisvorgestellt. Schließlich werden die erzielten Ergebnisse ausgewertet undbegründet, warum wir das Shape Context Matching nicht als Erkennungsverfahrenfür mare ausgewählt haben.9.1 Einführung in das Shape Context MatchingDas Shape Context Matching wurde erstmals in [BMP02] vorgestellt. Es dientdazu, eine Formvorlage in einem Kantenbild zu finden. Dazu wird jedem Punktder Formvorlage und des Kantenbildes eine Beschreibung, der sogenannteFormkontext, zugeordnet.Der Formkontext (Shape Context) eines betimmten Punktes enthältdie Verteilung der restlichen Punkte zu ihm. Die Verteilung wirddurch ein Histogramm der relativen logarithmischen Polarkoordinatender restlichen Punkte beschrieben.Die Ähnlichkeit zweier Formkontexte kann durch eine Kostenfunktion bestimmtwerden. Als Kostenfunktion wird der 2 ­Test für die Histogramme verwendet.Um eine Formvorlage in einem Kantenbild zu finden, werden die Formkontextealler Punkte der Formvorlage mit den Formkontexten der Kantenpunkte des Bildesverglichen und es wird die Zuordnung gesucht, die die Summe aller Kostenminimal werden lässt.In [BMP02] sind gute Ergebnisse erzielt worden für die Erkennung von Markenzeichen,Handschriftzeichen und Haushaltsgegenständen, die vor homogenemHintergrund fotografiert wurden.112

9 Shape Context Matching9.2 VerbesserungsmöglichkeitenIn [TSTC03] wird das Shape Context Matching hinsichtlich seiner Tauglichkeit zurErkennung von Objekten vor inhomogenem Hintergrund untersucht. Das Ergebnisist, dass Objektpunkte und Hintergrundpunkte des Kantenbildes nur auf Basisdes Formkontextes schlecht unterschieden werden können und dass Punkte,die auf der zu findenden Formvorlage dicht beieinander liegen, häufig mit Bildpunktenkorreliert werden, die weit voneinander entfernt sind. Um diese Schwächenzu überwinden, werden zwei Verbesserungen vorgeschlagen:Die erste Verbesserungsmöglichkeit ist die Verwendung einer Kostenfunktion,die nicht nur den Formkontext beachtet sondern zusätzlich eine Kontinuitätsbedingungund einen Kostenterm für die Krümmung enhält. Die Kontinuitätsbedingungsoll sicherstellen, dass zwei Punkte, die in der Formvorlage dicht beieinanderliegen mit Bildpunkten korreliert werden, die dies auch tun. Der Kostentermfür die Krümmung ist dann niedrig, wenn die korrelierten Punkte eine ähnlicheKrümmung haben.In [TSTC03] werden mit dieser ersten Verbesserung sehr gute Ergebnisse auchvor inhomogenem Hintergrund erzielt. Das Problem ist, dass die Rechenkomplexitätdurch diese Verbesserung drastisch ansteigt und die Implementierung derAutoren auf einem Pentium 3 mit 1 GHz Taktfrequenz 20 Sekunden für das Findender Formvorlage in einem Bild benötigte. Dieser Ansatz wird also selbstdurch die eingeschränkte Anforderung 15 (Erkennungsfrequenz von 2 Hz) eindeutigausgeschlossen.Die zweite vorgeschlagene Verbesserungsmöglichkeit ist die Verwendung derKantenorientierung. In [TSTC03] wird nur kurz auf die dadurch erzielte Verbesserungeingegangen, weswegen wir diesen Ansatz selbst getestet haben.9.3 Verbesserung durch Verwendung der KantenorientierungUm die Kantenorientierung zweier Kantenpunkte vergleichen zu können, definierenwir den Kantenkontext.Der Kantenkontext eines betimmten Punktes beschreibt die Verteilungder Kantenpunkte um diesen herum in einem Bereich von fünfPixeln in jede Richtung.113

9 Shape Context MatchingDer Kantenkontext eines Pixels wird aus einem Kantenbild bestimmt und bestehtaus einem Histogramm mit 40 Einträgen. Um das Histogramm zu erstellen, werdendie umliegenden 120 Pixel betrachtet. Für jeden Pixel ist ein Index auf einenHistrogrammeintrag festgelegt wie in Abbildung 42 dargestellt.Abbildung 42: Histogrammindices für den Kantenkontext eines PunktesEin Histogrammeintrag enthält den Mittelwert der Grauwerte aller Pixel, die seinemIndex zugeordnet sind. Dem letzten Eintrag mit dem Index 39 sind beispielsweisefünf Pixel zugeordnet. Wenn der Kantenkontext für einen Punkt einerFormvorlage erstellt wird, die als Binärbild vorliegt, dann wird für die Formpunkteder maximale Grauwert und für alle anderen der minimale Grauwert verwendet.Um zwei Kantenkontexte zu vergleichen verwenden wir als Kostenfunktion –ebenso wie [BMP02] zum Vergleichen der Formkontexte – den 2 ­Test .114

9 Shape Context MatchingAbbildung 43 zeigt dieZuordnung von Punkteneiner Formvorlage zuPunkten eines Kantenbildesfür die die Summe allerKosten minimal ist. Man erkennt,dass bei diesem Bild mit sehr wenigenKantenpunkten die Zuordnungbis auf wenige Ausnahmen korrekt ist.Abbildung 44 zeigt das Ergebnis beiKombination von Formkontext undKantenkontext. Man erkennt, dass diePositionierung in dem Bild mit wenigenKanten sehr gut funktioniert. In demBild mit vielen Kantenpunkten sind diePunkzuordnungen allerdings so schlecht,dass eine Positionierung der Formvorlagezu einem falschen Ergebnis führt.Abbildung 43: KantenkontextZuordnung einer Form zu einem Kantenbildanhand des Kantenkontextes. Hinterden hellblauen Punkten des Kantenbildesist das Originalbild dargestellt.Die Punkte der Formvorlage sind indunkelblau dargestellt.Abbildung 44: Formkontext und Kantenkontext kombiniertÜberlagerung zweier Kantenbilder mit einer Formvorlage anhand des Form- und Kantenkontextes.Hinter den hellblauen Punkten der Kantenbilder sind die Originalbilder dargestellt. Die Punkte derFormvorlagen sind in gelb dargestellt.115

9 Shape Context Matching9.4 AuswertungDas Shape Context Matching erzielt für homogenen Hintergrund mit deutlichenKanten zwischen der Hand und dem Hintergrund gute Ergebnisse. An seineGrenzen stößt das Verfahren, wenn das Kantenbild sehr viele Kanten enthält.Dies ist dann der Fall, wenn der Hintergrund inhomogen ist oder wenn sich dieHand nur wenig vom Hintergrund abhebt, da dann der Schwellwert für die Kantendetektionentsprechend niedrig eingestellt werden muss. Die in [TSTC03]vorgeschlagenen Verbesserungsmöglichkeiten erhöhen die Rechenkomplexitätzu stark, so dass das Verfahren nicht mehr echtzeitfähig ist, beziehungsweise verbesserndas Ergebnis nicht so gut, dass das Verfahren auch vor inhomogenenHintergrund einsetzbar wäre.Wir haben zwar Anforderung 12 eingeschränkt, so dass das umzusetzende Verfahrendie Erkennung vor inhomogenem Hintergrund nicht gewährleisten muss,doch das im folgenden Kapitel beschriebene Elastic Graph Matching ist demShape Context Matching in dieser Hinsicht überlegen und nähert sich so stärkerdem idealen Verfahren an.Deswegen haben wir das Shape Context Matching nicht als Objekterkennungsverfahrenfür die Erkennung der mare-Handhaltung ausgewählt.116

10 Elastic Graph Matching10 Elastic Graph MatchingDas Elastic Graph Matching ist das zweite – und letztlich gewählte – der in dieserArbeit untersuchten Objekterkennungsverfahren. Es wurde am Institut für Neuroinformatikder Ruhr-Universität Bochum entwickelt und bereits erfolgreich fürverschiedene Aufgaben der Computer Vision eingesetzt, beispielsweise zur Klassifikationstatischer Handgesten und Gesichter ([TM96]). Es benötigt keine Initialisierungund keinen separaten Segmentierungschritt, bei dem das zu erkennendeObjekt vom Hintergrund getrennt wird. Dies macht es möglich, das Verfahrenauch für die Objekterkennung vor inhomogenem Hintergrund einzusetzen.Der Rest dieses Kapitels ist wie folgt strukturiert: Zuerst stellen wir die in der Literaturzu findende Beschreibung des Elastic Graph Matching in einem Exkurs dar.Dann werden Formalisierungen eingeführt, die die Grundlage für unsere darauffolgenden Weiterentwicklungen sind. Im Anschluss wird dargestellt, wie das ElasticGraph Matching mit unseren Weiterentwicklungen eingesetzt wird, um diemare-Geste in den Videobildern zu erkennenm, und es werden die erzielten Ergebnissepräsentiert. Das Kapitel schließt mit der Darstellung der objektorientiertenModellierung des Elastic Graph Matching samt Weiterentwicklungen.10.1 Exkurs Elastic Graph MatchingDie folgende Beschreibung des Elastic Graph Matching lehnt sich an [TM02] und[Pötzsch04] an.Graph und GraphtemplateEin zweidimensionaler Graph in derForm des zu erkennenden Objekts wirdüber ein Rasterbild gelegt und demAbbild des zu erkennenden Objektsangepasst. Nebenstehende Abbildungzeigt einen Graph, der erfolgreich anein Handabbild angepasst wurde.Abbildung 45: Hand mit erfolgreich angepasstemGraph(mit nummerierten Knoten)117

10 Elastic Graph MatchingEin Graph (im Sinne dieser Arbeit) besteht aus Knoten und ungerichtetenKanten.Ein Knoten eines Graphen hat eine Position in einem Bild und ihmwird eine Beschreibung der lokalen Bildeigenschaften zugeordnet.Eine Kante eines Graphen verbindet zwei unterschiedliche Knoten.Ihre Länge entspricht dem Abstand der verbundenen Knoten.Die lokalen Bildeigenschaften, die einem Knoten zugeordnet werden,beschreiben den Bildbereich, der die Knotenposition umgibt.Das EGM durchzuführen bedeutet nach Knotenpositionen zu suchen, so dassder Graph bestmöglich mit dem Abbild des zu erkennenden Objekts übereinstimmt.Wir legen folgende Kurzbezeichnung fest:Die Graphübereinstimmung ist die Übereinstimmung des Graphenmit dem Abbild des zu erkennenden Realobjekts.Um die Graphübereinstimmung zu bewerten verwenden wir ein Graphtemplate.Ein Graphtemplate ist ein Graph, dessen Knotenpositionen und lokalenBildeigenschaften sich auf ein Beispielbild beziehen.Die Graphübereinstimmung ist dann hoch, wenn die lokalen Bildeigenschaftender Graphknoten den jeweiligen lokalen Bildeigenschaften der Graphtemplateknotenmöglichst gut entsprechen und zum anderen der Graph im Verhältniszum Graphtemplate nicht zu stark verformt wird (s.u.). 37Gabor Wavelets zur Beschreibung der lokalen BildeigenschaftenAls Beschreibung der lokalen Bildeigenschaften eines Knotens verwenden wirdie Antworten, die eine diskrete zweidimensionale Faltung mit Gabor Waveletsals Faltungskernen ergibt. Die Verwendung von Gabor Wavelets ist motiviertdurch Erkenntnisse aus der Neurobiologie: sie haben eine ähnliche Form wie die37 Hier weichen wir (aus Implementierungsgründen) leicht von dem in [TM02] beschriebenenVerfahren ab: Dort wird ein einzelner Graph verwendet, der sowohl die Templateinformationenenthält als auch verändert wird, um ihn in Übereinstimmung mit dem Bild zu bringen.118

10 Elastic Graph Matchingrezeptiven Felder von Zellen im primären visuellen Kortex von Säugetieren 38 ; dieForm besteht aus einer ebenen Welle, die durch eine Gaußsche Hüllkurve begrenztwird. Die meisten der Zellen können zu Paaren zusammengefasst werden,wobei die eine jeweils ein symmetrisches und die andere ein asymmetrisches rezeptivesFeld hat. Diese können durch Verwendung einer Kosinus- und einerSinuswelle als Wellenfunktionen modelliert werden, die als komplexe Zahl dargestelltwerden können:e i kx = coskxi sinkxMit Hilfe dieser komplexwertigen Wellenfunktion lassen sich Gabor Wavelets beschreiben:k k x = ² ²e ­ k ²x ²2 ²Gaußsche Hüllkurve ei kxWelle­e ­ ²2 .mittelwertfreiEin Gabor Wavelet ist ein komplexwertiges Wavelet, das durch dieFunktion k beschrieben wird. Real- und Imaginärteil haben beidedie Form einer ebenen Welle, die durch eine Gaußsche Hülle begrenztwird. Die Wellen von Real- und Imaginärteil sind um 90° phasenverschoben.Abbildung 46 zeigt die Form des Real- und Imaginärteils eines Gabor Wavelets.Abbildung 46: Gabor WaveletLinks: Realteil, rechts: Imaginärteil. (Abbildung aus [TM96])38 Um das rezeptive Feld einer einzelnen Zelle zu bestimmen, wird ein Säugetier betäubt undfixiert und es wird ein einzelner Leuchtpunkt auf einem Bildschirm vor einem Auge des Tieresbewegt. Dabei wird durch eine in das Gehirn eingebrachte Elektrode für jede Leuchtpunktpositiondie Aktivität der Zelle gemessen.119

10 Elastic Graph Matching k ist eine komplexwertige Funktion, die von dem Ortsvektor x eines Punktesdes Faltungskerns abhängt 39 und mit dem Wellenvektor k parametrisiert ist.k legt Richtung und Frequenz der Welle fest und ergibt sich aus:k = k ⋅ cos sin mitk = k max/f , = D .Dabei bezeichnet der Index ∈{0,...,L­1} verschiedene Wellenfrequenzenund der Index ∈{0,...,D­1} verschiedene Wellenrichtungen, wobei L dieAnzahl der verschiedenen Frequenzen und D die der Richtungen angibt. f bestimmtden Frequenzabstand der Gabor Wavelets und k maxist die maximaleWellenzahl.Der Term k ² ²e ­ k ²x ²2 ²stellt die Gaußsche Hüllkurve dar, deren Weite von kderart abhängt, dass die Anzahl der Schwingungen unter ihr konstant ist. Durchdie Subtraktion von e ­ ²2von der Wellenfunktion wird k mittelwertfrei, sodass eine Faltung mit diesem Kern unabhängig von homogenen Änderungender Bildhelligkeit ist.Für diese Arbeit übernehmen wir die in [TM02] und anderen Arbeiten der gleichenAutoren verwendeten Parameterwerte, die auf eine maximale Abdeckungdes Frequenzraums hin optimiert sind:L = 3, D = 8, f = 1/2, k max= 1,7, = 2,5 .Dies ergibt die in Abbildung 47 dargestellten L⋅D = 24 Gabor Wavelets.Abbildung 47: Gabor KernelDie verwendeten Gabor Kernel jeweils in Paaren von Realteil (links) und Imaginärteil (rechts) dargestellt.Die drei Zeilen zeigen die unterschiedlichen Frequenzen und die acht Spalten die unterschiedlichenWellenrichtungen. Dunkle Bereiche entsprechen Werten kleiner Null und helle BereicheWerten größer Null.39 Der Ursprung des Faltungskerns liegt in seiner Mitte.120

10 Elastic Graph MatchingDie Faltungsantworten c jdieser Gabor Wavelets mit unterschiedlicher Wellenrichtungund -frequenz bilden einen Gabor Jet. c j setzt sich zusammen aus demBetrag a jund der Phase j: c j=a je i j.Ein Gabor Jet ist ein Tupel von komplexwertigen Faltungsantwortenfür einen Bildpunkt, das bei Faltung mit Gabor Wavelets unterschiedlicherWellenrichtung und -frequenz entsteht.Um zwei Jets miteinander zu vergleichen, gibt es zwei Ähnlichkeitsfunktionen S 40 :S absJ,J = ∑ jS phaJ,J = 1 21∑a ja jja j2∑ja j2 ,∑a ja jcos j­ jj ∑ ja j2∑ja j2.Eine Ähnlichkeitsfunktion (similarity function) ist eine Funktion zurBewertung der Ähnlichkeit von Jets oder gesamten Graphen (s.u.).S absnutzt nur die Beträge der Faltungsantworten und ändert sich langsam,wenn der Faltungskern über das Bild geschoben wird; S phanutzt zusätzlich diePhase und ändert sich schnell.Bunchjet und BunchgraphVerschiedene Bilder desselben Objekts können je nach Beleuchtung und Hintergrundunterschiedlich aussehen. Um mit diesen Unterschieden umzugehen,erzeugt man eine Menge von Beispielbildern, die die Variabilität in der Erscheinungwiderspiegeln. Die (topologisch identischen) Graphtemplates, die man ausdiesen Beispielbildern gewinnt, werden zu einem Bunchgraphtemplate zusammengefasst(siehe Abbildung 48 und Abbildung 49). Die Jets, die den Knotender konstituierenden Graphtemplates zugeordnet sind, werden knotenweise zuBunchjets zusammengefasst und dem jeweiligen Knoten des Bunchgraphtemplateszugeordnet.40 S wie »similarity«.121

10 Elastic Graph MatchingAbbildung 48: Bestandteile eines BunchjetsGabor Wavelets unterschiedlicher Frequenz und Richtung dienen als Faltungskerne; die Antwortender Faltungen für einen bestimmten Bildpunkt ergeben zusammen einen Jet; die Jets, die für einenbestimmten Knoten des Graphen mit verschiedenen Beispielbildern erstellt wurden, bildenden Bunchjet, der zu dem Knoten gehört. (Abbildung aus [LWWMH03])Abbildung 49: Aufbau eines BunchgraphtemplatesGraphtemplates für unterschiedliche Hintergründe und Beleuchtungenwerden zu einem Bunchgraphtemplate zusammengefasst.(Abbildung aus [TM02])122

10 Elastic Graph MatchingEin Bunchjet ist ein Tupel von Gabor Jets.Ein Bunchgraph ist die Zusammenfassung mehrerer, topologischidentischer Graphen.Ein Knoten eines Bunchgraphen hat keine Position in einem Bild,ihm wird »nur« ein Bunchjet zugeordnet, der aus den Gabor Jets derentsprechenden Knoten der zusammengefassten Graphen besteht.Eine Kante eines Bunchgraphen verbindet zwei Knoten. Ihre Längeist festgelegt als das arithmetische Mittel der Längen der entsprechendenKanten der zusammengefassten Graphen.Ein Bunchgraphtemplate ist ein Bunchgraph und beschreibt dieKantenlängen und die lokalen Bildeigenschaften, die aus mehrerenBeispielbildern gewonnen wurden.Um einen Graphen mit einem Bunchgraphtemplate zu vergleichen benötigt manÄhnlichkeitsfunktionen, die die Bunchjets berücksichtigen. Diese Funktionen basierenauf den oben genannten Ähnlichkeitsfunktionen S abs und S pha und ermittelnfür den Vergleich eines einzelnen Jets J mit einem Bunchjet B bestehendaus K Jets B kmit dem einzelnen Jet J : 41S BabsS Bphamit k ∈{0,...,K­1} die maximale Ähnlichkeit der Jets B kB ,J = maxS absB k ,J und analogkB ,J = maxS phaB k ,J .kDie Ähnlichkeit der lokalen Bildeigenschaften eines gesamten Graphen G mitdenen eines Bunchgraphtemplates T ergibt sich aus dem arithmetischen Mittelder Knotenähnlichkeiten:S TabsT ,G = 1 ∑ N nS B TphaB n,J n, S absanalog,wobei N die Anzahl der Knoten ist (die für den Graphen und das Bunchgraphtemplategleich sein muss) und J nder Jet des n-ten Graphknotens und B nderBunchjet des n-ten Bunchgraphtemplateknotens ist ( n ∈{0,...,N­1} ).41 Ab hier weichen wir von der Notation in [TM02] ab.123

10 Elastic Graph MatchingWährend des Anpassens des Graphens an das Bild kann der Graph verformtwerden, um Formunterschiede von Graph und Objektabbild auszugleichen. Umzu verhindern, dass der Graph zu stark von seiner originären Form abweicht,kann eine topologische Kostenfunktion definiert werden. Für eine einzelne KanteE mmit m ∈{0,...,M­1} seien die Verformungskosten C 42 :C E E m = l template ­ l distortedl template2,wobei l templatedie Länge der Kante des Bunchgraphtemplates und l distorteddieLänge der Kante des verformten Graphen ist.Die Verformungskosten für einen gesamten Graphen G mit M Kanten sind dasarithmetische Mittel aller Kantenverformungskosten:C G G = 1 M ∑ mC E E m .Auf Basis von C Ekann weiterhin eine Ähnlichkeitsfunktion definiert werden, diebei Verschiebung eines Knotens mit dem Index n ein Maß dafür liefert, wiestark die anliegenden M Kanten verformt sind. Die Ähnlichkeit soll die Ergänzungdes Mittelwerts der Verformungskosten (der anliegenden Kanten) zu Einssein und es soll verhindert werden, dass die Ähnlichkeitsfunktion Werte kleinerNull annehmen kann:nS topologicalG = 1­min 1, 1∑ M mC E E m.GraphanpassungMit den genannten Ähnlichkeitsfunktionen zur Bewertung der Graphübereinstimmungkann eine schrittweise Anpassung des Graphen an das Bild erfolgen.Jeder Schritt besteht darin, eine gegebene Transformation des Graphen mit verschiedenenParametern durchzuprobieren und den Parameter zu finden, für deneine gegebene Ähnlichkeitsfunktion maximal wird.Transformation eines Graphen bedeutet die Veränderung derKnotenpositionen.42 C wie »cost«124

10 Elastic Graph MatchingGraphanpassung ist die schrittweise Transformation eines Graphen,die durchgeführt wird, um eine möglichst gute Graphübereinstimmungzu erreichen.Ein Beispiel für einen Anpassungsschritt ist die Transformation »Verschieben desGraphen« und die verschiedenen Parameter wären »ein Pixel nach rechts«, »zweiTPixel nach rechts« und so weiter, als Ähnlichkeitsfunktion könnte S absdienen.10.2 Formalisierungen und Weiterentwicklungen in mareIm letzten Abschnitt wurde die in der Literatur zu findende Beschreibung desElastic Graph Matching vorgestellt. Wir haben das Verfahren weiterentwickelt.Für die Beschreibung der Weiterentwicklungen mussten wir die Graphtransformationstärker formalisieren und wir haben den Begriff des »Funktors« eingeführt.Dies wird in den folgenden beiden Unterabschnitten erläutert. In den darauffolgenden Unterabschnitten werden die einzelnen Weiterentwicklungen behandelt.10.2.1 Formalisierung der GraphtransformationDer Parameterraum einer TransformationsfunktionDie Anpassungsschritte einer Graphanpassung erfordern die Transformation desGraphen. Wir unterscheiden zwischen verschiedenen Transformationsarten, wiezum Beispiel der Verschiebung des Graphen und der Skalierung des Graphen.Bei der Verschiebung des Graphen werden die Positionen aller Knoten einheitlichverändert, beispielsweise werden alle Knoten einen Pixel nach rechts verschoben.Bei der Skalierung des Graphen werden die Knotenpositionen so verändert,dass der Graph danach eine andere Größe 43 hat.Um eine Transformation einer bestimmten Transformationsart durchzuführen,verwenden wir eine »Transformationsfunktion«. Um mit einer Transformationsfunktioneine Graphtransformation durchzuführen, werden Parameterwerte benötigt,die festlegen, wie die Transformation genau aussehen soll. Beispielsweisewird für die Transformationsfunktion »Verschiebung in x-Richtung« ein Parameterbenötigt, der festlegt, wie weit (und ob nach links oder rechts) die Knoten43 Als Maß für die Größe verwenden wir Höhe und Breite des kleinsten umschließenden Rechtecks.125

10 Elastic Graph Matchingdes Graphen verschoben werden. Ein möglicher Parameterwert wäre zumBeispiel »einen Pixel nach rechts«.Eine Transformationsfunktion führt eine Graphtransformation entsprechendder ihr übergebenen Transformationsparameter aus.Eine Transformationsfunktion kann n Parameter benötigen. Die Belegung der nParameter mit einem n-Tupel von Parameterwerten, einem Parametervektor,spezifiziert genau eine Transformation.Ein Parametervektor ist ein n-Tupel von Transformationsparameterwerten.Bei der Anwendung einer Transformationsfunktion trans auf einen Graphen werdender Graph G und der Parametervektor v übergeben; der Wert der Funktionist der transformierte Graph: G=transG , v .Die n-dimensionalen Parametervektoren einer Transformationsfunktion liegeninnerhalb eines n-dimensionalen Parameterraums.Der Parameterraum einer Transformationsfunktion ist n-dimensionalund wird aufgespannt durch die n Parameter der Transformationsfunktion.Eine Position im Parameterraum kann beschriebenwerden durch den Parametervektor, der den Ursprung in diese Positionverschiebt; der Parametervektor heißt dann Parameterortsvektor.Um zu bezeichnen, welche Transformationen auf einem Graph ausgeführtwurden, legen wir den Sprachgebrauch fest, dass ein Graph eine Position ineinem Parameterraum einer Transformationsfunktion einnehmen kann:Die Position eines Graphen in einem Parameterraum wird verändertdurch die Transformation des Graphen. Der untransformierteGraph liegt im Ursprung des Parameterraums. Durch Anwenden derTransformationsfunktion wird der Graph im Parameterraum entsprechenddem Parametervektor verschoben.126

10 Elastic Graph MatchingDurchsuchen eines ParameterraumsIm Sinne der vorangegangenen Definitionen bedeutet die Durchführung einesAnpassungsschritts die Verschiebung des Graphen in einem bestimmten Bereichdes Parameterraums (der den Ursprung einschließt), wobei nach einer möglichstguten Graphübereinstimmung gesucht wird.Wenn ein Bereich des Parameterraums von einen Computer durchsucht werdensoll, müssen die zu testenden Positionen festgelegt sein – der Bereich muss alsoin diskrete Schritte eingeteilt werden.Die Einschränkung des Parameterraums auf einen bestimmten Bereich und dessenDiskretisierung legen eine gewisse Anzahl P von möglichen Positionen fest,die wir durch deren Parameterortsvektoren v pmit p ∈{0,...,P­1} beschreiben.Der Parameterortsvektor des Ursprungs des Parameterraums habe den Indexp 0.10.2.2 Definition von FunktorUm die Transformationsart und die zu durchsuchenden Positionen leicht bezeichnenzu können, definieren wir:Ein Funktor (im Sinne dieser Arbeit) ist ein Tupel, das die Transformationsfunktion,den zu durchsuchenden Bereich des Parameterraumsder Transformationsfunktion und die Diskretisierung diesesBereiches festlegt.Wir schreiben: F=trans, v 0,...,v P, p 0 , wobei trans eine Transformationsfunktionist und v 0bis v P die Parameterortsvektoren der zu testenden Positionenim Parameterraum sind. p 0 ist der Index des Parameterortsvektors desUrsprungs.Ein Funktor kann auf einen Graphen angewandt werden, indem der Graph undzwei Parameterortsvektorindices übergeben werden: G = FG , p a, p b .Dann wird G=transG , v pb­v pa ; wenn G an der Parameterraumposition v paliegt, wird der Graph so im Parameterraum verschoben, dass G an der Positionv pbliegt.Die Erzeugung der Parameterortsvektoren v p(mit p ∈{0,...,P­1} ) ist abhängigvon der verwendeten Transformationsfunktion.127

10 Elastic Graph MatchingIm Folgenden werden beispielhaft einige Funktoren und die für diese zu erzeugendenParameterortsvektoren erläutert.Beispiel VerschiebungsfunktorAbbildung 50: Parameterraum eines VerschiebungsfunktorsDer Verschiebungsfunktor verschiebt nur in x-Richtung. Über derAchse sind die Parameterwerte der Transformationsfunktionmove xaufgetragen, unter der Achse ist derParametervektorindex p des Verschiebungsfunktors aufgetragen.Um einen Verschiebungsfunktor zu erzeugen, muss festgelegt werden, ob er aufder Transformationsfunktion move x(»Verschiebung in x-Richtung«) oder aufmove y (»Verschiebung in y-Richtung«) basieren soll und mit welcherSchrittweite und innerhalb welchen Bereichs die Verschiebung durchgeführtwerden soll.In Abbildung 50 ist der Parameterraum des Verschiebungsfunktors für eine Beispielkonfigurationdargestellt. Es wird die Transformationsfunktion move xundeine Schrittweite von stepSize=1 Pixel verwendet, die linke Verschiebungsgrenzeist minD=-4 Pixel und die rechte maxD=3 Pixel.Die Anzahl der Parameterortsvektoren ergibt sich alsP =maxD­minD/ stepSize1 , sie sind beginnend bei minD durchlaufend indiziertund der Ursprung hat den Index p 0=­minD / stepSize .Dieser Funktor lässt sich darstellen als:F =move x, ­4, ­3, ­2, ­1, 0, 1, 2, 3 , 4 .128

10 Elastic Graph MatchingBeispiel SkalierungsfunktorAbbildung 51: Parameterraum eines SkalierungsfunktorsÜber der Achse sind die Parameterwerte der Transformationsfunktion scale aufgetragen,unter der Achse ist der Parametervektorindex p des Skalierungsfunktorsaufgetragen.Beim Skalierungsfunktor wird im Gegensatz zum Verschiebungsfunktor nicht dieDiskretisierungsschrittweite, sondern die Anzahl der Diskretisierungsschritte festgelegt.Zudem müssen der minimale und der maximale Skalierungsfaktor festgelegtwerden.In Abbildung 51 ist der Parameterraum des Skalierungsfunktors für eine Beispielkonfigurationdargestellt. Die untere Skalierungsgrenze ist minScaling=0,6 unddie obere ist maxScaling=1,3. Im dazwischen liegenden kontinuierlichen Intervallwerden stepCount=8 diskrete Positionen festgelegt.Es gilt P = stepCountund p 0= floor1­minScaling⋅stepCount /maxScaling­minScaling .Dieser Funktor lässt sich darstellen als:F =scale, 0,6, 0,7, 0,8, 0,9, 1,0, 1,1, 1,2, 1,3 , 4 .129

10 Elastic Graph MatchingBeispiel CompositefunktorEine besonderer Funktor ist der Compositefunktor. Dieser kombiniert zwei andereFunktoren. Seien die P Parameterortsvektoren des einen Funktors v p , mitp ∈{0,...,P­1} , und analog die Q Parameterortsvektoren des anderen Funktorsw q , mit q ∈{0,...,Q­1} .Dann hat der Compositefunktor einen Parameterraum, dessen Dimensionalitätder aufsummierten Dimensionalität der zu Grunde liegenden Funktoren entspricht;die Anzahl der Parameterortsvektoren ergibt sich also als C = P⋅Q .Für deren Indizierung bedarf es einerAbbildung der zu Grunde liegendenParameterortsvektorenindices aufeinen einzelnen Index. Die verwendeteAbbildung ist :N×NN mitp ,q=q⋅Pp und ­1 c=mod Pc, floorc/P .Sie entspricht der üblichenDurchnummerierung der Pixel einesAbbildung 52: Rechtecknummerierungrechteckigen Bildbereichs; daher nennen wir sie Rechtecknummerierung.Abbildung 52 zeigt beispielhaft für P=5 und Q=3 .10.2.3 Modellierung von GraphverformungIn diesem Abschnitt werden die Freiheitsgrade, die ein zu erkennendes Objekthat, am Beispiel der mare-Geste untersucht. Dabei wird eine notwendige Erweiterungder in der Literatur beschriebenen Graphtransformationen motiviert.130

10 Elastic Graph MatchingAbbildung 53: Freiheitsgrade einer HandDie roten Pfeile in den Koordinatensystemen deuten den Freiheitsgrad der Handan. Ein grüner Graph stimmt mit dem Abbild der Hand überein, bevor sie entsprechenddem Freiheitsgrad verändert wurde. Der zugehörige rote Graph zeigt dienotwendige Graphtransformation, damit Graph und Abbild der veränderten Handwieder übereinstimmen. Der besseren Übersicht wegen sind nur die Graphumrissedargestellt.Ein zu erkennendes Objekt kann meist nicht nur parallel zur Bildebene verschobenwerden, sondern auch senkrecht zu dieser und es kann in verschiedenenRaumrichtungen gedreht werden. Außerdem kann das Objekt verformbar sein.Um mit diesen Freiheitsgraden umzugehen, sind Graphtransformationen nötig,die den Graphen wieder in Übereinstimmung mit dem Objektabbild bringen131

10 Elastic Graph Matchingkönnen. Abbildung 53 zeigt am Beispiel einer Hand in mare-Handhaltung dieverschiedenen Freiheitsgrade und die Transformationen, die sich aus ihnen füreinen Graphen ergeben müssten.Die Freiheitsgrade lassen sich wie folgt durch Graphtransformationenmodellieren:Die Verschiebung des Objekts in der Bildebene kann einfach durch Verschiebungdes Graphen modelliert werden.Eine Verschiebung senkrecht zur Bildebene resultiert in einer Verkleinerung bzw.Vergrößerung des Objektabbildes und kann durch Skalierung des Graphen modelliertwerden.Die Rotation des Objekts in der Bildebene lässt sich problemlos durch Rotationdes Graphen modellieren.Die Rotationen senkrecht zur Bildebene (also mit der Senkrechten oder derWaagerechten als Rotationsachse) führen dazu, dass eine Seite des Objekts indas Bild gedreht wird, die vorher nicht sichtbar war. Zudem ändert sich die Formdes Objektabbildes. Auch wenn sich die Form des Objektes selbst ändert, wiezum Beispiel bei der Ausführung der mare-Geste, verändert sich die Form desObjektabbildes.Um diese Veränderungen der Form des Objektabbildes zu modellieren, ist eineVerformung des Graphen notwendig. Zur Verformung eines Graphen ist in derLiteratur, beispielsweise [TM96], der Ansatz der sogenannten »Diffusion« zufinden:Die Diffusion ist eine Transformationsart, bei der sich die Knotendes Graphen jeweils in einem Bereich von wenigen Pixeln bewegenkönnen.Um eine zu starke Deformation des Graphen zu verhindern, müssen die Verformungskostenin die zur Beurteilung der Graphübereinstimmung verwendeteÄhnlichkeitsfunktion einfließen. Die Diffusion ist entwickelt worden, um dieGraphanpassung robust gegenüber leichten Formunterschieden zu machen, wiesie bei statischen Handgesten durch eine etwas andere Handhaltung oder durchunterschiedliche ausführende Menschen verursacht werden. Für so starke Veränderungenin der Form des Objektabbildes wie sie bei den Rotationen senk-132

10 Elastic Graph Matchingrecht zur Bildebene oder bei der Verformung des Objektes auftreten ist der Ansatznicht geeignet.Wir haben zwei alternative Ansätze entwickelt:Abbildung 54 zeigt in gelb und gründie Extremformen, die zum Beispielder Zeigefinger bei Ausführung dermare-Geste annehmen kann, und inrot eine Zwischenform.Der erste Ansatz ist, die Verformbarkeitdes Graphen durch Interpolationzwischen den Extremformen zu modellieren.Der zweite Ansatz basiert darauf, denGraphen in Teilgraphen zu strukturierenund gesonderte Transformationenauf diesen durchzuführen. Für die mare-Geste heißt das zum Beispiel,nur den Teilgraph, der die Knoten des Zeigefingers enthält, zu rotieren und ihnfür jeden Rotationsschritt in einem gewissen Bereich über das Bild zu bewegen,um die Rotations-Positions-Kombination mit der besten Teilgraphübereinstimmungzu finden. Danach könnte das Gleiche für die Fingerspitzegemacht werden.Im Vergleich der beiden Ansätze zeigt sich, dass der erste die möglichen Verformungenstärker einschränkt, wohingegen der zweite größere Flexibilität und damitauch Fehlanpassungen zulässt. Für die Erkennung der mare-Geste hat sichder erste Ansatz als zu unflexibel erwiesen, weswegen wir den zweiten verwenden.44 Dennoch scheint es vielversprechend, das Potenzial des ersten Ansatzes inweiteren Untersuchungen zu ergründen; zum Beispiel könnten mehrere Extremformenverwendet werden, um eine größere Menge von Formen dazwischen zuinterpolieren als es mit nur zwei Extremformen möglich ist.Abbildung 54: Extremformen einer HandDie Zeigefingerform (rot) liegt zwischen denExtremformen (gelb und grün).44 Wir haben die beiden Ansätze vor der objektorientierten Umsetzung des Elastic Graph Matchingin einem separaten Testprogramm untersucht. Da wir dabei mit dem zweiten Ansatzbessere Ergebnisse erzielt haben, steht für den ersten Ansatz zur Zeit keine objektorientierteUmsetzung zur Verfügung.133

10 Elastic Graph Matching10.2.4 Erhöhen der Ausführungsgeschwindigkeit durch Verwendung einerGaußschen PyramideDieser Abschnitt beschäftigt sich mit dem von uns entwickelten Verfahren zurGeschwindigkeitsverbesserung des Elastic Graph Matching. Wir vergleichen esmit dem in der Literatur üblichen Ansatz und stellen die neuen Transformationsartenvor, die für dessen Umsetzung notwendig sind.Graphanpassung in der LiteraturDer in der Literatur (zum Beispiel [TM01]) übliche Ansatz zur Graphanpassungbesteht aus folgenden oder ähnlichen Schritten:– Grobpositionierung des Graphen mit einer Schrittweite von fünf Pixelnin x- und y-Richtung,– Rotation des Graphen,– Skalierung des Graphen,– Diffusion einzelner Knoten in einem 9x9-Pixel-Fenster.Die dabei verwendeten Bilder haben eine Auflösung von 128x128 Pixeln. Für dieGrobpositionierung ergeben sich somit 25*25=625 zu testende Graphpositionenund bei der Diffusion einzelner Knoten müssen pro Knoten 9*9=81 Positionengetestet werden.Verwendung einer Gaußschen AuflösungspyramideUnser Ansatz ist, die Anzahl zu testender Positionen zu verringern, indem dieGraphanpassung auf einer Gaußschen Auflösungspyramide durchgeführt wird. 45Dabei wird auf der niedrigsten Auflösungsstufe begonnen, den Graphen grob zupositionieren, um dann mit jeder Auflösungsstufe die Position zu präzisieren.Nach einigen Experimenten sind wir zu folgenden Anpassungsschritten zur Positionierunggekommen (Rotation etc. sind in folgender Liste weggelassen):45 Die höchste Auflösungsstufe einer solchen Pyramide ist die Originalauflösung. Mit jederweiteren Stufe werden Höhe und Breite des Bildes halbiert, somit die Auflösung geviertelt.Dazu wird jede zweite Bildzeile (x*2) und -spalte (y*2) der vorherigen Stufe mit einem GaußschenFaltungskern der Größe 5x5 Pixel gefaltet und in die neue Auflösungsstufe übernommen(als Bildzeile x und -spalte y).134

10 Elastic Graph Matching– Grobpositionierung des Graphen mit einer Schrittweite von drei Pixelnin x- und y-Richtung bei einem 256tel der Auflösung,– Feinpositionierung des Graphen mit bis zu zwei Pixeln Verschiebungwieder bei einem 256tel der Auflösung,– ab dann für jede Auflösungsstufe: Feinpositionierung des Graphen mitbis zu zwei Pixeln Verschiebung.Bei welcher Auflösungsstufe anzufangen ist, hängt von der ursprünglichen Auflösungdes Bildes ab. Die von uns verwendeten Bilder haben eine Auflösung von640x480 Pixeln. Ein 256tel der Auflösung entspricht also einem Bild von 40x30 Pixeln.Somit ergeben sich für die Grobpositionierung 13*10=130 und für jedeFeinpositionierung 5*5=25 zu testende Graphpositionen. Um dies mit dem obengenannten Wert von 625 zu vergleichen, ist zu bedenken, dass die Auflösung derdort verwendeten Bilder bei nur 128x128 Pixeln liegt. Das ist etwa ein 16tel derAuflösung der von uns verwendeten Bilder. Nach einer Grob- und drei Feinpositionierungen,mithin 130+3*25=205 zu testenden Graphpositionen, ist der Graphauf dieser Auflösungsstufe positioniert. Wir haben somit nicht nur zwei Drittelweniger zu testende Graphpositionen, sondern auch ein genaueres Positionierungsrastervon einem anstatt fünf Pixeln. Die Rechenzeit, die benötigt wird, umdie Gaußsche Pyramide zu erstellen, ist vernachlässigbar klein gegenüber der,die durch die verringerte Anzahl zu testender Positionierungen eingespart wird.Die Verwendung von Bildern niedrigerer Auflösung bedeutet – bezogen auf dasBild in voller Auflösung und bei gleicher Konfiguration der Jets – die Betrachtungniedrigerer Ortsfrequenzen und eines größeren Bildausschnitts. Es scheintsich positiv auf die Robustheit der Graphanpassung auszuwirken, dass die Anpassungsschritteauf einer niedrigeren Auflösungsstufe auch auf niedrigerenOrtsfrequenzen basieren. Dies ist auch plausibel, denn würden diese Anpassungenauf dem Bild in voller Auflösung ausgeführt werden, dann würden dieKnoten des Graphen immer nur in größeren Pixelschritten bewegt werden. ZumBeispiel würde einer Bewegung um einen Pixel in einem Bild mit einem 256telder Auflösung eine Bewegung um 16 Pixel im Bild mit voller Auflösung entsprechen.Wenn ein Knoten nur in 16-Pixel-Schritten bewegt werden kann, dannmüssen, um seine Übereinstimmung zu bewerten, die lokalen Bildeigenschafteneines größeren Bildausschnittes betrachtet werden; und ein größerer Bildausschnittkann entsprechend niedrigere Ortsfrequenzen enthalten.135

10 Elastic Graph MatchingNotwendige neue TransformationsartenZwischen zwei Anpassungsschritten, die auf unterschiedlichen Auflösungsstufenarbeiten sollen, muss der Graph an die neue Auflösungsstufe angepasst werden.Dafür führen wir zwei neue Transformationsarten ein: Hochskalieren und Templateanpassung.Ihnen gemeinsam ist zum einen, dass sie den Graphen so transformieren, dass ervon einer Auflösungsstufe an die nächste angepasst wird; zum anderen, dass siesich von den sonstigen Transformationsarten dadurch unterscheiden, dass ihreTransformationsfunktionen immer die gleiche Transformation auf dem Graphenausführen. Sie benötigen also eigentlich keinen Parametervektor. Wegen derKonsistenz zu den anderen Transformationsfunktionen legen wir aber fest, dasssie durch einen leeren Parametervektor parametrisiert werden. Das bedeutet,dass der Parameterraum dieser Transformationsfunktionen nulldimensional ist.HochskalierenDas Hochskalieren ist eine Transformationsart, die den Graphen sovergrößert, dass er einer höheren Auflösungsstufe entspricht. Dieentsprechende Transformationsfunktion heißt upscale.Die Transformationsfunktion upscale factormultipliziert die Koordinaten jedesKnotens mit dem festen Faktor factor, so dass das Skalierungszentrum im Ursprungdes Bildes liegt. Beispielsweise wird bei factor=2 ein Knoten von der Position(x, y) nach (2x, 2y) verschoben. Diese Transformationsfunktion sollte nichtverwendet werden, wenn die Auflösung in der letzten Auflösungsstufe so niedrigwar, dass die Form des Graphen dadurch beeinträchtigt wurde. Dies ist zum Beispielder Fall, wenn zwei Knoten bei voller Auflösung einen Abstand von fünf Pixelnhaben und der Graph auf ein 256tel der Auflösung verkleinert wurde. Dannhätten die Knoten je nach Lage nach einer Rückvergrößerung entweder einenAbstand von Null oder von 16 Pixeln.136

10 Elastic Graph MatchingTemplateAnpassungIn einem solchen Fall sollte statt des Hochskalierens die TransformationsartTemplateAnpassung verwendet werden.Die TemplateAnpassung ist eine Transformationsart, die die Knotenpositioneines Graphtemplates verwendet, um für den anzupassendenGraphen die Knotenpositionen für eine höhere Auflösungsstufezu ermitteln. Die entsprechende Transformationsfunktion heißtadjustTemplate.Wenn die Transformationsfunktion adjustTemplate Gt ,factor,addend auf einenGraphen angewandt wird, dann passt sie diesen durch folgende Schritte an:1. Bestimmung des minimalen umschließenden Rechtecks R=(x, y, w, h)des Graphen,2. Anpassung dieses Rechtecks entsprechend factor und addend:R=factor⋅xaddend,factor⋅yaddend,factor⋅w,factor⋅h,3. Einpassung des Graphen in das angepasste Rechteck, wobei die Knotenpositionendenen entsprechen, die bei einer Einpassung des GraphtemplatesG tdurch Skalierung und Verschiebung in das Rechteck entständen.Ein Graph, der herunterskaliert wurde, um einem niedrig auflösenden Bild zuentsprechen, kann durch Verwendung eines Skalierungsfaktors von factor=2 andie nächst höhere Auflösungsstufe angepasst werden, so dass er die in dieserAuflösungsstufe maximale Genauigkeit hat. Der absolute Summand addendwird bei der Anpassung des Rechtecks auf dessen Position in beiden Koordinatenrichtungenaufgeschlagen. Dies hat den Zweck, Rundungsfehler auszugleichen,die sonst den Graphen nach links-oben wandern ließen. 46 Die TransformationsartTemplateAnpassung kann nicht verwendet werden, wenn ein Graph aneine höhere Auflösungsstufe angepasst werden soll, dessen Form bereitsverändert wurde, denn diese Veränderung würde wieder verloren gehen. Stattdessensollte dann die Transformationsart Hochskalieren verwendet werden.46 Bei Ganzzahldivision durch zwei mit anschließender Multiplikation mit zwei wird eine Koordinateim Mittel um Eins kleiner.137

10 Elastic Graph Matching10.2.5 TrackingDieser Abschnitt beschreibt unsere Erweiterung des Elastic Graph Matchings umTrackingfunktionalität. Im Folgenden wird die Notwendigkeit des Trackings motiviertund der Einsatz eines Kalman-Filters untersucht. In den nachfolgenden Unterabschnittenwird genauer auf die Umsetzung unseres Ansatzes eingegangen.10.2.5.1 Vorüberlegungen zum TrackingWie oben beschrieben wird zum Finden eines Objektabbildes in einem Bildbeim Elastic Graph Matching ein Graph durch mehrere Anpassungsschritte sotransformiert, dass er mit dem Objektabbild in Übereinstimmung gebracht wird.Entsprechend der von uns eingeführten Terminologie bedeutet dies das Findenderjenigen Positionen in den Parameterräumen der Transformationsfunktionen,an denen der Graph die Position, Größe etc. im Bild mit der größten Graphübereinstimmunghat. Man kann die Parameterräume der Transformationsfunktionenaller Anpassungsschritte als einen einzelnen, entsprechend hochdimensionalenGesamtparameterraum betrachten. 47Der Gesamtparameterraum einer Graphanpassung ist die Vereinigungder Parameterräume der Transformationsfunktionen aller Anpassungsschritte.Üblicherweise sind die Veränderungen des Objektabbildes zwischen zwei Bilderngering. Im Falle der Handerkennung könnte die Hand ein wenig verschobenoder die Öffnungsweite verändert sein. Dass die Hand so ruckartig bewegtwird, dass die Abbildposition sehr stark zwischen zwei aufeinanderfolgenden Videobildernvariiert, ist selten. Es liegt nahe, bei den Anpassungsschritten vonder letzten bekannten Position und Öffnungsweite auszugehen, also den Graphendem Objektabbild nachzuführen, das Objektabbild zu tracken.Tracking bedeutet (im Sinne dieser Arbeit), einen Graphen einemObjektabbild über eine Sequenz von Videobildern hinweg nachzuführen.Dafür beginnen wir die Suche an der letzten bekannten Position im Gesamtparameterraumund tasten uns von dort zu dessen Grenzen vor.47 Das schrittweise, immer in Richtung einer anderen Dimension optimierende, Vorgehen entsprichtdann dem Gauß-Seidel-Verfahren.138

10 Elastic Graph MatchingÜberlegungen zum Kalman-FilterDie Suche an der letzten bekannten Position im Parameterraum zu beginnen istim Allgemeinen nicht die optimale Lösung. Sinnvoller ist es, an der Position zubeginnen, die für das aktuelle Bild erwartet wird. Ein Trackingverfahren, das üblicherweisezur Lösung dieser Aufgabe eingesetzt wird, ist der Kalman-Filter (siehe[WB04]). Dieser benötigt jedoch, wie auch jedes andere Verfahren, das einePosition auf Basis der vorherigen vorhersagen soll, ein Modell für die Bewegungdes zu verfolgenden Objekts. Ein solches ist schwerlich zu finden, da die Handwillkürlich bewegt werden kann. In diesem Fall kann man sich damit helfen, die»Bewegung« als eigentlich konstante Position zu modellieren, die nur durch denProzessfehlerterm 48 des Kalman-Filters verändert wird. 49 Das hat allerdings zurFolge, dass der Kalman-Filter nur wenig bessere Ergebnisse erzielt als ein gleitenderDurchschnitt 50 und dass gerade bei starken Positionsveränderungenmehrfach von einer erwarteten Position aus gesucht wird, die der wahren Positionhinterherhängt. Die a priori vom Kalman-Filter vorhergesagten Positionenfür die Suche zu verwenden ergibt also keinen Vorteil.Davon unabhängig könnten die a posteriori Positionen für die Erkennung dermare-Handhaltung und somit auch für die Steuerung des Gestencursorsverwendet werden, um Erkennungsausreißer durch Glättung zu entfernen. Dashaben wir getestet und der Verzögerungseindruck, der sich durch die glättendeEigenschaft des Kalman-Filters bei skizzierter Modellierung ergibt, ist der Bedienungeher abträglich.Folglich setzen wir den Kalman-Filter nicht ein.48 engl. »process noise«49 Alternativ kann auch die Geschwindigkeit des Objektes mitmodelliert und die Position ausdieser integriert werden. Dann muss allerdings die Geschwindigkeitsveränderung durch denProzessfehlerterm dargestellt werden. Man kann diese Ableitung beliebig so weiter gehenund die Geschwindigkeit aus der Beschleunigung integrieren und so weiter, aber am Endekann die Willkürlichkeit der Handbewegung nur durch den Prozessfehlerterm modelliertwerden.50 Die Ergebnisse des Kalman-Filters sind insofern besser als die eines gleitenden Durchschnitts,als dass große Sprünge in der gemessenen Position stärker auf die vermutete Positioneinwirken als kleine Sprünge. Dadurch folgt der Kalman-Filter leichten Messfehlernkaum und wirklichen Positionsveränderungen stärker.139

10 Elastic Graph Matching10.2.5.2 Erforschende NummerierungMan kann sich die von der letzten bekannten Position im Parameterraum einesFunktors ausgehende Suche so vorstellen: Zuerst wird die Übereinstimmung ander Position selbst untersucht, dann werden alle Positionen, die an diese angrenzen,untersucht, dann die, die an diese Positionen angrenzen und so weiter.Das heißt, der Parameterraum wird schalenweise erforscht, beginnend mit derkleinsten Schale: der Ausgangsposition selbst 51 .Die Erforschung eines Parameterraums bedeutet dessen schalenweisesAbsuchen. Ausgangsposition ist dabei die für ein vorherigesVideobild bekannte Position im Parameterraum.Um die Erforschung durchzuführen, ist es notwendig, die P Parameterortsvektorenv pdes Funktors (mit p∈{0,...,P­1} ) schalenweise zu nummerieren. Dafürdefinieren wir eine Bijektion :{0,...,P­1}{0,...,P­1} derart, dass, wenn einErforschungsindex k von 0 bis P­1 läuft, k Parameterortsvektorindices zurschalenweisen Nummerierung erzeugt. Die Bijektion nennen wir erforschendeNummerierung.Der Erforschungsindex eines Funktors ist derart auf die Parameterortsvektorenindicesdes Funktors abgebildet, dass mit ihm eine Erforschungdes Parameterraums durchgeführt werden kann.Die erforschende Nummerierung eines Funktors ist die bijektiveAbbildung des Erforschungsindexes auf die Parameterortsvektorenindicesdes Funktors.Im Folgenden wird die Umsetzung eines Erforschungsindexes für einfacheFunktoren und für den Compositefunktor erläutert.51 Für Freunde der Fernsehserie »Star Trek« wird auch der Begriff »orbitales Suchmuster« einegewisse Intuition wecken.140

10 Elastic Graph MatchingEinfache FunktorenFür einen eindimensionalen Parameterraum wie bei den einfachen Verschiebungs-oder Rotationsfunktoren enthält jede Schale höchstens zwei Positionen:die erste Schale enthält nur die Ausgangsposition, die weiteren Schalen enthaltenjeweils die zwei Positionen auf beiden Seiten mit gleicher Entfernung zurAusgangsposition und sobald die Grenze des Parameterraums an einer Seite erreichtist, enthalten die Schalen nur noch jeweils eine Position. Diese alternierendeNummerierung a ist in Abbildung 55 dargestellt, dabei hat der Parametervektorder Ausgangsposition den Index p 1.Abbildung 55: Alternierende NummerierungDie erforschende Nummerierung eines eindimensionalen Parameterraums ist die alternierendeNummerierung; die Ovale deuten die schalenweise Erforschung des Parameterraums an.Die alternierende Nummerierung ist die erforschende Nummerierungfür Funktoren mit eindimensionalem Parameterraum. ak lässt sich wie folgt realisieren: Sei k der Offset eines alternierendenIndexes vom Ausgangsindex p 1, dann ist ak=p 1k . Zur Definition vonk müssen wir die Begrenzung des Parameterraums beachten: Dazu seid l=p 1 der Indexabstand des Ausgangsindexes zur linken Begrenzung des Pa-141

10 Elastic Graph Matchingrameterraums, d r=P­1­p 1der zur rechten Begrenzung und d=mind l,d rder kleinere der beiden. Weiterhin definieren wir k= floork1/2 .Für Werte von k, für die k≤d gilt, istk=k⋅ {­1, fallsk gerade1, sonst } .Für die anderen Werte von k muss unterschieden werden zwischen kd l,dann ist k=k­d , und kd r, dann ist k=d­k .CompositefunktorDer Compositefunktor wurde bereits in Abschnitt 10.2.2 vorgestellt. Dieser Abschnittbeschäftigt sich damit, wie die erforschende Nummerierung für denCompositefunktor definiert ist.Seien die P Parameterortsvektoren des einen zu Grunde liegenden Funktorsv p (mit p∈{0,...,P­1} ), analog seien die Q Parameterortsvektoren des anderenw q(mit q ∈{0,...,Q­1} ) und die zusammengesetzten C =P⋅Q Parametervektorendes Compositefunktors seien x c. Mit der Rechtecknummerierung:N×NN (siehe Abschnitt 10.2.2) liegt bereits eine Abbildung der zuGrunde liegenden Parameterortsvektorenindices auf einen einzelnen Index vorund für v pund w qseien die erforschenden Nummerierungen mit pund qgegeben 52 .Das heißt: für einen gegebenen Parameterortsvektorindex c 1, von dem aus erforschtwerden soll, lassen sich die Parameterortsvektorenindices der zu Grundeliegenden Funktoren als p 1,q 1= ­1 c 1 bestimmen und von dort aus kann jeweilserforscht werden.Die Idee für ein Composite- c ist, dessen Erforschungsindex k czu einem Metaindexder Erforschungsindices k pund k qzu machen, pund qauf dieseanzuwenden und die erhaltenen Parameterortsvektorenindices durch die Rechtecknummerierungwieder zusammenzufassen. Als Bijektion zwischen k c undk p , k q verwenden wir eine der Cantornummerierung ähnelnde, die wir dieBubblebijektion :N×NN nennen.52 Wenn die zu Grunde liegenden Funktoren einfache Funktoren, wie im letzten Abschnitt beschrieben,sind, dann sind pund qidentisch mit a.142

10 Elastic Graph MatchingDie Bubblebijektion funktioniert wiein Abbildung 56 dargestellt. Sie beginntbei (0, 0) und breitet sich dannwie eine Blase aus: sie erfasst Schalefür Schale 53 und wenn der Parameterraumeines Funktors komplett erforschtist, dann breitet sie sich nurnoch in Richtung des Erforschungsindexesdes anderen Funktors aus.Mit Hilfe der Bubblebijektion lässtsich eine erforschendeNummerierung für den Compositefunktor definieren. Diese nennen wirCompositenummerierung.Die Compositenummerierung ist die erforschende Nummerierungfür Compositefunktoren. Sie verwendet den Erforschungsindex alsMetaindex der Erforschungsindices der konstituierenden Funktoren.Es sei k p,k q= ­1 k c ; dann ist die Erforschungsnummerierung: ck c = pk p, qk q .Abbildung 56: BubblebijektionAbbildung zweier Erforschungsindices k p und k qmit P=5 und Q=3 auf den Metaindex k c durchdie Bubblebijektion.BeispielAbbildung 57 zeigt wie der Parameterraum eines Compositefunktors abgesuchtwird, der aus zwei Verschiebungsfunktoren besteht 54 : der eine ist für eine Verschiebungvon -2 bis 2 Pixeln in x-Richtung konfiguriert, der andere für eine Verschiebungvon -1 bis 1 Pixel in y-Richtung. Die Bildposition, an der der Graph imletzten Videobild die beste Graphübereinstimmung hatte, liegt bei (-1, 0) und istindiziert mit p 1=1 und q 1=1 . Die in grün dargestellten Zahlen zeigen den Erforschungsindexdes Compositefunktors; die Stellen, an denen sie in der Abbildungdargestellt sind, leiten sich aus den x- und y-Koordinaten-Werten der vonihnen indizierten Parameterortsvektoren ab. Man erkennt die schalenweise Erforschungder Bildpositionen, markiert durch die grauen Rechtecke.53 Die Schalen, die unsere metaphorische Blase erfasst, sind rechteckig.54 Zu beachten ist, dass in Abbildung 57 Pixelkoordinaten des Bildes auf die Koordinatenachsenaufgetragen sind – im Gegensatz zu Abbildung 56, in der die Erforschungsindicesder konstituierenden Funktoren aufgetragen sind.143

10 Elastic Graph MatchingAbbildung 57: CompositenummerierungDer Compositefunktor, dessen Parameterraum hier nummeriertwird, besteht aus zwei Move-Funktoren. Der Übersichtlichkeit wegensind die Koordinatenachsen separiert dargestellt.10.2.5.3 Abbruchbedingung und InitialbedingungMit der im letzten Abschnitt beschriebenen erforschenden Nummerierung ist dieGrundlage für das Tracking gelegt. Wenn von einer Position im Parameterraumaus gesucht wird, ist es zudem notwendig, entscheiden zu können, wann die Sucheabgebrochen werden kann. Also muss eine Abbruchbedingung für dasTracking definiert sein, die zutrifft, wenn die erreichte Graphübereinstimmungausreichend ist. Würde von der letzten Position ausgehend der komplette Gesamtparameterraumabgesucht werden, böte das Tracking keine Vorteile bezüglichder Ausführungsgeschwindigkeit.Die Abbruchbedingung legt fest, wann beim Tracking eine Graphübereinstimmunggefunden wurde, die so gut ist, dass von einer Anpassungan ein Abbild einer Hand in mare-Handhaltung ausgegangenwerden kann. Wenn die Abbruchbedingung zutrifft, wird dieErforschung des Parameterraums der Transformationsfunktion desaktuellen Anpassungsschrittes abgebrochen (um, falls vorhanden,mit dem nächsten Anpassungsschritt fortzufahren).Die Abbruchbedingung dient gleichzeitig der Erfüllung der Anforderung, dassdas Erkennungsverfahren entscheidet, ob es sich bei dem erkannten Objektabbildtatsächlich um die Hand in mare-Handhaltung handelt (Anforderung 1).144

10 Elastic Graph MatchingAllerdings kommt die Abbruchbedingung nur zum Einsatz, wenn im letzten Videobilddie mare-Handhaltung erkannt wurde.Es muss neben der Abbruchbedingung eine Initialbedingung definiert sein:Die Initialbedingung legt fest, ob eine Graphübereinstimmung gefundenwurde, die so gut ist, dass von einer Anpassung an ein Abbildeiner Hand in mare-Handhaltung ausgegangen werden kann.Die Initialbedingung kommt dann zum Einsatz, wenn im letzten Videobild keinemare-Handhaltung erkannt wurde und deswegen der komplette Gesamtparameterraumabgesucht wird.Der Grund für unterschiedliche Bedingungen für das Tracking und die initialeSuche ist die so geschaffene Möglichkeit, eine schärfere Bedingung für die initialeErkennung als für das Tracking festzulegen und dadurch eine einmal gefundeneHand nicht so leicht wieder zu verlieren und gleichzeitig die Anzahl initialerfalsch positiver Erkennungen zu minimieren.Analyse typischer Antworten einer ÄhnlichkeitsfunktionZur Definition von Abbruchbedingung und Initialbedingung analysieren wir dieAntworten der Ähnlichkeitsfunktionen, die während der Erforschung eines Paramterraumsgeneriert werden, anhand folgenden Beispieles.Abbildung 58: Bilder einer VideosequenzAbbildung 58 zeigt zwei aufeinander folgende Bilder einer Videosequenz. Wirbetrachten für diese Bilder den ersten Anpassungsschritt: die Verschiebung desGraphen über das gesamte Bild:145

10 Elastic Graph MatchingS0,940,930,920,910,900,890,880,870,860,850,840,830,820,810,800 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160kAbbildung 59: Ähnlichkeitsfunktionsantworten ITDie Antworten der Ähnlichkeitsfunktion S absbei Verschiebung des Graphen über das erste Bildaus Abbildung 58.Für das erste Bild ist noch keine letzte gefundene Bildposition bekannt. DerGraph wird über das gesamte Bild geschoben und es wird initial die Position derHand gefunden. Für das nächste Bild wird von der im ersten Bild gefundenenBildposition ausgegangen.TAbbildung 59 zeigt die Antworten der Ähnlichkeitsfunktion S absbei der Erforschungdes Parameterraums eines Compositefunktors, der aus zwei Verschiebungsfunktorenbesteht. Die Verschiebungsfunktoren sind so konfiguriert, dasssie die gesamte Fläche des ersten in Abbildung 58 dargestellten Bildes in drei-Pixel-Schritten bei einem 256tel der Auflösung absuchen. Für eine komplette Suchesind dafür 130 Graphpositionen zu testen. Für das erste Bild beginnt die Erforschungin dessen Ursprung. Es ist zu erkennen, dass sich die meisten der Antwortender Ähnlichkeitsfunktion in einem Bereich zwischen 0,82 und 0,89 bewegen.Die Spitzen, die nach oben aus diesem Bereich ausbrechen, entsprechenden Positionen im Bild, an denen der Graph sich über oder fast über der Handbefindet. Weiterhin sieht man, dass die Spitzen über den Suchbereich verteiltsind.146

10 Elastic Graph Matching0,950,940,930,920,910,900,89S0,880,870,860,850,840,830,820,810,800 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160kAbbildung 60: Ähnlichkeitsfunktionsantworten IIDas gleiche Vorgehen wie in Abbildung 59, nur mit dem zweiten anstatt dem ersten Bild ausTAbbildung 58, erzeugt die hier dargestellten Antworten der Ähnlichkeitsfunktion S abs.S0,950,940,930,920,910,900,890,880,870,860,850,840,830,820,810,800 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160kAbbildung 61: Ähnlichkeitsfunktionsantworten IIITDie Antworten der Ähnlichkeitsfunktion S abs für das zweite Bild, wenn eine Erforschung von derPosition des Parameterraums aus durchgeführt wird, an der der Graph im ersten Bild die besteÜbereinstimmung hatte.147

10 Elastic Graph MatchingAbbildung 60 zeigt das Ergebnis bei gleichem Vorgehen für das zweite Videobild.Wie man erkennt, sehen die Antworten der Ähnlichkeitsfunktion fast gleichaus.Die in Abbildung 61 dargestellte Reihenfolge der Antworten der Ähnlichkeitsfunktionergibt sich dadurch, dass eine erforschende Nummerierung (für daszweite Videobild) von der Position im Parameterraum aus durchgeführt wird, ander der Graph im ersten Bild die beste Graphübereinstimmung hatte. Es ist zusehen, dass die höchsten Spitzen, also die besten Graphübereinstimmungen,nicht mehr über den Suchbereich verteilt sind, sondern gleich am Anfang derSuche gefunden werden.Wie oben bereits gesagt, bewegen sich die meisten der Antworten der Ähnlichkeitsfunktionin einem bestimmten Bereich. Abbildung 62 zeigt, dass sich dieHäufigkeitsverteilung dieses Bereiches in guter Näherung durch eine Normalverteilungbeschreiben lässt.353025count(S)201510500,75 0,78 0,80 0,83 0,85 0,88 0,90 0,93 0,95SAbbildung 62: Häufigkeitsverteilung der ÄhnlichkeitsfunktionsantwortenII und IIIDie Antworten der Ähnlichkeitsfunktion sind auf zwei Nachkommastellengerundetet. Die gestrichelte Linie zeigt eine Normalverteilung,deren Erwartungswert und Standardabweichung aus den Antworten derÄhnlichkeitsfunktion abgeleitet wurden.148

10 Elastic Graph MatchingBestimmung von Abbruchbedingung und InitialbedingungDie Idee sowohl für die Abbruchbedingung wie auch für die Initialbedingung ist,einen Minimalwert S track min für das Tracking beziehungsweise einen initialenMinimalwert S init minzu definieren und eine Position im Parameterraum erst zuakzeptieren, wenn die Antwort der Ähnlichkeitsfunktion an dieser Position denMinimalwert überschreitet. Die Definitionen der Minimalwerte sehen wie folgtaus:S track min= ESr track min⋅ s undS init min= ESr init min⋅ s .Diese basieren auf dem arithmetischen Mittel ES und der Standardabweichung S typischer Antworten der Ähnlichkeitsfunktion. Mit dem Faktorr track min beziehungsweise r init min beeinflusst man die Wahrscheinlichkeit, dasseine zufällig ausgewählte Antwort der Ähnlichkeitsfunktion den Minimalwertüberschreitet. Die Wahrscheinlichkeit lässt sich dank der Normalverteilungabschätzen:Für r track min= 1 liegt sie bei etwa 16%, für r track min= 2 bei 2,3% und fürr track min= 3 bei nur noch 0,13%.Was das Tracking betrifft, so bestände, wenn nur der Minimalwert als Abbruchbedingungverwendet würde, die Gefahr, dass eine Position im Parameterraumakzeptiert und die Suche abgebrochen würde, obwohl eine später zu erforschendePosition eine bessere Graphübereinstimmung brächte. Um die Wahrscheinlichkeit,dass dies passiert, zu verringern, legen wir weiterhin fest, dass beimTracking eine Position im Parameterraum erst dann akzeptiert wird, wenn die ihrentsprechende Antwort der Ähnlichkeitsfunktion einen bestimmten HysteresewertS track hyst= r track hyst⋅ Soberhalb der Estimatorantwort einer später erforschtenPosition liegt oder bereits der gesamte Parameterraum abgesuchtwurde.Um ES und S zu ermitteln, wird eine statistische Untersuchung der Antwortender Ähnlichkeitsfunktionen für eine Menge von Beispielbildern durchgeführt.Diese sollten keine Hand enthalten, die die mare-Handhaltung hat, um den Bereich,in dem sich die Antworten der Ähnlichkeitsfunktionen typischerweise fürden Hintergrund bewegen, möglichst genau zu bestimmen.149

10 Elastic Graph Matching10.2.5.4 Trackingzustand der ErkennungIn den letzten beiden Abschnitten wurde beschrieben, wie die erforschendeNummerierung und die Abbruchbedingung funktionieren. Für ein erfolgreichesTracking ist es weiterhin notwendig, den Zustand der Erkennung bezüglich desTrackings zu modellieren. Dazu gehören die Informationen, welcher Anpassungsschrittgerade ausgeführt wird und ob die Anpassung auf dem letzten Bilderfolgreich durchgeführt werden konnte und somit eine letzte gefundene Positionim Parameterraum bekannt ist. Abbildung 63 zeigt, wie diese Informationendurch Erkennungszustände modelliert werden können.Nicht TrackingTrackingWartend auf neues BildWartend auf neues Bildneues Bildneues BildSchritt 1 ausführendSchritt 1 ausführendGraph passt nicht /nicht erkanntGraph passtGraph passt nicht /nicht erkanntGraph passtSchritt 2 ausführendSchritt 2 ausführendGraph passt nicht /nicht erkanntGraph passtGraph passt nichtGraph passtSchritt 3 ausführendSchritt 3 ausführendGraph passt nicht /nicht erkanntGraph passt /erkanntGraph passt nichtGraph passt /erkanntAbbildung 63: TrackingzuständeHauptzustände »Nicht Tracking« und »Tracking«Im Zustand »Nicht-Tracking« werden bei der Durchführung der Anpassungsschritteimmer alle Parametervektoren durchprobiert. Eine erfolgreiche Anpassungliegt vor, wenn die Initialbedingung bei allen Anpassungsschritten erfülltwurde.Im Zustand »Tracking« wird eine Erforschung des Parameterraums durchgeführt.Bei den einzelnen Anpassungsschritten wird die Erforschung abgebrochen,wenn die Abbruchbedingung zutrifft. Wenn die Abbruchbedingung bei einem150

10 Elastic Graph MatchingAnpassungsschritt für keine Position im Parameterraum zutrifft, wird davon ausgegangen,dass keine erfolgreiche Anpassung möglich war.Unterzustände von »Nicht Tracking«Vor der Erkennung des ersten Bildes eines Videostroms befindet sich die Erkennungim Hauptzustand »Nicht Tracking« und dort im Unterzustand »Wartend aufneues Bild«. Wenn ein neues Bild von der Videokamera zur Verfügung steht,wird begonnen, die Anpassungsschritte der Reihe nach auszuführen (im Beispielsind dies drei an der Zahl).Dies geschieht entweder so lange, bis ein Anpassungsschritt fehlschlägt und dieErkennung mit dem Ergebnis »nicht erkannt« für dieses Bild abgebrochen wird.Dann wird wieder in den Zustand »Wartend auf neues Bild« gewechselt.Oder es werden alle Anpassungsschritte erfolgreich durchlaufen. In diesem Fallwechselt die Erkennung mit dem Ergebnis »erkannt« in den Hauptzustand»Tracking« und dort in den Unterzustand »Wartend auf neues Bild«.Unterzustände von »Tracking«Befindet sich die Erkennung im Hauptzustand »Tracking«, Unterzustand »Wartendauf neues Bild« und es steht ein neues Bild von der Videokamera zur Verfügung,dann wird wieder begonnen, die Anpassungsschritte der Reihe nach auszuführen,wobei die Suche in den Parameterräumen der Anpassungsschritte abgebrochenwird, wenn die Abbruchbedingung zutrifft. Falls der gesamte Parameterraumeines Anpassungsschritts erfolglos erforscht worden sein sollte, alsokeine Übereinstimmung gefunden wurde, dann wird vom Hauptzustand »Tracking«in den Hauptzustand »Nicht Tracking« gewechselt.Wenn es der erste Anpassungsschritt war, der nicht erfolgreich durchgeführtwerden konnte, dann wird die Erkennung für das aktuelle Bild abgebrochen undmit dem Ergebnis »nicht erkannt« wieder in den Unterzustand »Wartend auf neuesBild« des Hauptzustandes »Nicht Tracking« gewechselt.Falls es einer der weiteren Anpassungsschritte war, der nicht erfolgreich durchgeführtwerden konnten, dann wird in den Unterzustand »Schritt 1 ausführend«des Hauptzustandes »Nicht Tracking« gewechselt, die Suche also ohne Trackingvon vorne begonnen. Dies hat den Grund, dass es sein könnte, dass ein späterer151

10 Elastic Graph MatchingAnpassungsschritt deswegen nicht erfolgreich durchgeführt werden kann, weilbei einem der vorherigen die Erforschung des Parameterraums zu früh abgebrochenund der Graph deswegen nicht optimal angepasst wurde.Wenn alle Anpassungsschritte erfolgreich durchgeführt werden konnten, dannwird mit dem Ergebnis »erkannt« in den Unterzustand »Wartend auf neues Bild«gewechselt.10.3 Erkennung der mare-GesteDieser Abschnitt beschreibt, wie das Elastic Graph Matching mit den beschriebenenFormalisierungen und Weiterentwicklungen zur Erkennung der mare-Geste eingesetzt wird.Die Erkennung der mare-Geste erfolgt in drei Schritten:1. Anpassung eines Graphen an das Abbild einer Hand in mare-Handhaltungin einem Videobild.2. Bestimmung der Bildpositionen von Daumen- und Zeigefingerspitze.3. Ermittlung der Gestenphase aus dem Abstand der Bildpositionen vonDaumen- und Zeigefingerspitze.Schritt 2 und 3 sind geradewegs umzusetzen: Wenn ein Graph an eine Hand inmare-Handhaltung angepasst wurde, dann können die Bildpositionen von Daumen-und Zeigefingerspitze jeweils aus den Positionen der Graphknoten vonDaumen- und Zeigefingerspitze bestimmt werden. Die Unterscheidung zwischenden Phasen Zeigen und Aktivieren wird durch einen Abstandsschwellwert realisiert.Wir haben diesen so gewählt, dass, wenn der Abstand zwischen DaumenundZeigefingerspitze kleiner als 40 Pixel ist, die Phase Aktivieren erkannt wird.Für Schritt 1 ist dagegen Voraussetzung, dass Graphtopologie und die zu verwendendenAnpassungsschritte festgelegt sind. Zur Beurteilung und zur Verbesserungder von uns gewählten Festlegungen haben wir eine Videosequenzmit 100 Bildern aufgenommen, von denen 98 eine Hand in mare-Handhaltungvor inhomogenem und bewegtem Hintergrund enthalten. Für diese Bilder habenwir manuell die korrekten Positionen für Zeigefinger- und Daumenspitzefestgelegt. Weitere 10 Einzelbilder enthalten keine Hand in mare-Handhaltung.152

10 Elastic Graph MatchingInsgesamt verwendeten wir also 110 Testbilder. Diese dienten der stetigen Qualitätskontrollebei unseren Experimenten.10.3.1 ErgebnisseFolgende Tabelle gibt einen Überblick über die Ergebnisse, die die beste vonuns gefundene Konfiguration von Graphanpassungsschritten erzielt hat:korrekt erkannt falsch erkannt nicht erkannt Summemit Hand 55 1 75 2 17 3 6 98ohne Hand 55 4 12--- 12Summe 8723 110Tabelle 5: ErkennungsergebnisseFür die Bilder mit Hand 55 (insgesamt98) wurde als eine korrekte Erkennunggewertet, wenn sowohl dieerkannte Position der Daumen- alsauch die der Zeigefingerspitze jeweilsin einem Bereich von 15 Pixelnum den manuell markierten Punktherum lagen (75 mal). War dies nichtder Fall, so wurde die Erkennung alsfalsch gewertet (17 mal). Abbildung64 zeigt die für eine korrekte Erkennungerlaubten Bereiche in einemder Bilder der Testsequenz.Abbildung 64: Bereiche für korrekte ErkennungDie Spalte »nicht erkannt« enthält die Anzahl der Bilder, für die die Erkennungfälschlicherweise das Ergebnis geliefert hat, dass keine Hand in mare-Handhaltungzu sehen ist (6 mal).Die Bilder ohne Hand in mare-Handhaltung (insgesamt 12) hat die Erkennungalle als solche klassifiziert.55 in mare-Handhaltung153

10 Elastic Graph MatchingAbbildung 65: Beispiele aus der Testsequenz5040N30201000-4 5-9 10-14 15-19 20-24 25-29 30-34 35-39 40-44 45-49d(Zeigefinger)Abbildung 66: Erkennungsgenauigkeit für die Zeigefingerspitze154

10 Elastic Graph MatchingAbbildung 65 zeigt jeweils ein Beispielbild für die Fälle 1 bis 4. Die manuellmarkierten Positionen für Daumen-und Zeigefingerspitze sind pink dargestellt,die durch die Graphanpassung ermittelten rot. Die grünen Punkte sind die Knotendes Graphen und die gelben Linien sind dessen Kanten.Abbildung 66 zeigt die Verteilung der Differenzen (euklidischer Abstand) zwischenden manuell markierten und den durch die Graphanpassung ermitteltenPositionen der Zeigefingerspitze. Im Mittel weicht die durch die Graphanpassungermittelte Position um 9,8 Pixel von der markierten ab.10.3.2 Konfiguration der AnpassungsschritteDie gezeigten Ergebnisse wurden mit der folgenden Konfiguration von Anpassungsschrittenerzielt:AuflösungTransformationsartGrenzen und Diskretisierungdes ParameterraumsS r init minr track min;r track hyst256telComposite vonTS abs1,2 1,2; 2Verschiebung in x-Richtungd=[0; 39]; stepSize=3Verschiebung in y-Richtungd=[0; 30]; stepSize=3256telComposite vonTS abs1,2Verschiebung in x-Richtungd=[-2; 2]; stepSize=1Verschiebung in y-Richtungd=[-2; 2]; stepSize=1TemplateAnpassung64tel Skalierung scale=[0,8; 1,2]; stepCount=7 0,9 0,9; 264telComposite vonTS abs1,2Verschiebung in x-Richtungd=[-2; 2]; stepSize=1Verschiebung in y-Richtungd=[-2; 2]; stepSize=1TemplateAnpassung16telComposite vonTS abs1,2 1,2; 2Rotationrotate=[-10°; 10°]; stepCount=5Composite vonVerschiebung in x-Richtungd=[-1; 1]; stepSize=1Verschiebung in y-Richtungd=[-1; 1]; stepSize=1T16tel Skalierung scale=[0,9; 1,1]; stepCount=7 S abs1,2 1,2; 1,2155

10 Elastic Graph MatchingAuflösungTransformationsartGrenzen und Diskretisierungdes ParameterraumsS r init minr track min;r track hystNur Zeigefinger:16telComposite vonTS abs1,2 1,2; 2Rotationrotate=[-5°; 20°]; stepCount=8Composite vonVerschiebung in x-Richtungd=[-3; 3]; stepSize=1Verschiebung in y-Richtungd=[-3; 3]; stepSize=1Nur Daumen:16telComposite vonTS abs1,2 1,2; 2Rotationrotate=[-3°; 3°]; stepCount=3Composite vonVerschiebung in x-Richtungd=[-3; 3]; stepSize=1Verschiebung in y-Richtungd=[-3; 3]; stepSize=1HochskalierenNur Zeigefingerspitze:4telComposite vonTS pha0Verschiebung in x-Richtungd=[-2; 2]; stepSize=1Verschiebung in y-Richtungd=[-2; 2]; stepSize=1Nur Daumenspitze:4telComposite vonTS pha0Verschiebung in x-Richtungd=[-2; 2]; stepSize=1Verschiebung in y-Richtungd=[-2; 2]; stepSize=1HochskalierenTabelle 6: Die besten gefundenen AnpassungsschritteBegonnen wird damit, den Graphen bei einem 256tel der Originalauflösung zupositionieren; bei einem 64tel der Auflösung wird die Größe angepasst und diePositionierung verfeinert. Dann wird bei einem 16tel der Auflösung rotiert,wobei der Graph gleichzeitig seine Position um einen Pixel in jeder Richtungändern kann, und schließlich wird die Größe noch einmal angepasst. Damit istdie Grobanpassung des gesamten Graphen abgeschlossen und es werden nurnoch Teile des Graphen modifiziert.156

10 Elastic Graph MatchingZuerst können Zeigefinger und Daumen rotieren und dabei ihre Position anpassen,womit die Öffnung und Schließung der Hand modelliert ist. Dann werdenbei einem 4tel der Originalauflösung die Positionierungen der Fingerspitzen verfeinert.TEs wird fast ausschließlich S abs als Ähnlichkeitsfunktion verwendet, da diese nurdie Beträge der komplexen Faltungsantworten berücksichtigt und somit robustergegenüber leichten Verschiebungen ist. Nur für die Anpassung der Finger-Tspitzen kommt S phazum Einsatz, weil diese Ähnlichkeitsfunktion auch die Phaseder Faltungsantworten berücksichtigt und damit eine höhere Genauigkeit erreichtwerden kann. Zudem lässt sich S abs wesentlich effizienter als S phaberechnen,was der Ausführungsgeschwindigkeit der Graphanpassung zu Gute kommt.Die in der Literatur (zum Beispiel in [TM02]) üblicherweise als letzter Anpassungsschrittverwendete Diffusion brachte in unserer Testsequenz keine Verbesserungder Erkennungsgenauigkeit mehr, weswegen wir sie nicht in die Liste derAnpassungsschritte aufgenommen haben.r track min und r track hyst legen das Trackingverhalten eines Anpassungsschrittesfest. Wenn keine Werte angegeben sind, dann wird für den entsprechenden Anpassungsschrittnicht getrackt. Dies ist immer dann der Fall, wenn sich ein Anpassungsschrittauf dieselben Dimensionen des Gesamtparameterraums beziehtwie ein vorheriger – so zum Beispiel für den ersten und zweiten Anpassungsschritt»Verschieben über das gesamte Bild in drei-Pixel-Schritten« und »Verschiebenum maximal zwei Pixel«. Deswegen wird von diesen beiden nur für denersten Anpassungsschritt getrackt. Weitere trackingfähige Anpassungsschrittesind: Skalierung, Rotation des gesamten Graphen und die Anpassung von Zeigefingerund Daumen bezüglich Rotation und Verschiebung.Es werden keine Anpassungsschritte für ein Bild der vollen Auflösung durchgeführt,weil dadurch keine Verbesserung der Erkennungsgenauigkeit erreichtwird. Dies liegt vermutlich an dem verrauschten und durch das Halbbildverfahrenvon der Videokamera aufgenommenen Kamerabild.157

10 Elastic Graph Matching10.4 Objektorientierte ModellierungDieser Abschnitt beschreibt die objektorientierte Umsetzung des in den letztenAbschnitten dargestellten mathematischen Modells. Das Ergebnis dieser Umsetzungist das mare-Modul »Gestenerkennung« (Übersicht in Anhang A).Das mare-Modul Gestenerkennung ist die objektorientierte Umsetzungdes weiterentwickelten Elastic Graph Matching. Es ist imNamespace mare::egm zu finden.Die mathematischen Konzepte »Graph«, »Knoten«, »Kante« und »Jet« erschließensich recht einfach einer objektorientierten Analyse. Darum soll dieser Teildes Modells als Einstieg dienen. Im Anschluss werden die Klassen Functor undEstimator eingeführt, die die Grundlage für die Ausführung eines Anpassungsschrittssind. Daraufhin werden die Klassen Matching, Optimizer undMatchingStep erklärt, die für die Durchführung der Graphanpassung zuständigsind. Schließlich wird die Klasse GestureRecognition eingeführt, die die bisdahin beschriebenen Klassen zur Erkennung der mare-Geste verwendet.10.4.1 Modellierung von Graphen und BunchgraphenDer bei der Durchführung des Elastic Graph Matching anzupassende Graph unddas Bunchgraphtemplate (siehe Kapitel 10) lassen sich geradewegs objektorientiertmodellieren. In Abbildung 67 sind die entsprechenden Klassen dargestellt.Ein Graph besteht aus einer beliebigen Zahl von Nodes (Knoten) und Edges(Kanten). Eine Node hat eine Bildposition (in x- und y-Richtung) und besitzt einenJet. Eine Edge verbindet genau zwei Nodes und bietet die Methode lengthan, die den Abstand der verbundenen Nodes zurückgibt.Die Klasse Jet repräsentiert einen Gabor Jet. Sie bietet die Methoden similarityAbsund similarityPha an, die die Ähnlichkeitsfunktionen S abs undS pha implementieren. Wenn die Bildposition einer Node verändert wurde, mussder Jet für die neue Position aktualisiert werden. Dafür stellt Jet die Methodeupdate zur Verfügung, die von updateJet der Klasse Node mit der neuen Bildpositionals Parameter aufgerufen wird.Die für ein Bunchgraphtemplate notwendige Datenstruktur des Bunchgraphwird analog der Modellierung eines Graph durch die Klassen BunchGraph,BunchEdge und BunchNode realisiert. Es gibt jedoch folgenden Unterschiede:158

10 Elastic Graph MatchingAbbildung 67: Klassendiagramm Graph und BunchGraphDie Klasse BunchGraph bietet zusätzlich die statische Fabrikmethode mergean, die aus einer Liste von Graph-Objekten einen BunchGraph erzeugt. 56 EineBunchNode enthält die Jets aller konstituierenden Nodes und sie hat im Gegensatzzur Node keine Position in einem Bild. Dem entsprechend hat eineBunchEdge, im Gegensatz zu einer Edge, eine feste Länge, die bei der Erzeugungdurch die Methode merge von BunchGraph festgelegt wird.10.4.2 Graphtransformation durch FunctorMit den bis hier vorgestellten Klassen lässt sich ein Graph und ein Bunchgraphtemplatemodellieren und vergleichen. Für die Durchführung eines Anpassungsschrittesfehlt noch die Möglichkeit, Transformationen eines Graphen durchzuführen.Dafür wurde in Abschnitt 10.2.2 der Begriff des Funktors eingeführt, dereine Transformationsfunktion, den zu durchsuchenden Bereich des Parameter-56 Entsprechend der Bunchgraphdefinition (Seite 123).159

10 Elastic Graph Matchingraums der Transformationsfunktion und die Diskretisierung dieses Bereichesfestlegt. Es wurden einige Funktoren, wie zum Beispiel der Verschiebungsfunktoroder der Rotationsfunktor, vorgestellt. Alle Funktoren lassen sich in gleicherWeise auf einen Graph anwenden: G=FG, p a, p b .Dies impliziert eine polymorphe Umsetzung, wie sie in Abbildung 68 dargestelltist.Abbildung 68: Klassendiagramm FunctorFunctor ist die gemeinsame Schnittstelle für alle Funktoren. Ein Functor lässtsich mit der Methode apply auf einen Graph anwenden. 57 Dafür wird der Graphund die Indices auf die Parameterortsvektoren der Ausgangs- und Zielpositionim Parameterraum übergeben.57 Um die Ausführungsgeschwindigkeit zu erhöhen, modifiziert die Methode den übergebenenGraph, anstatt eine modifizierte Kopie zurückzuliefern (wie die mathematische Definitionimplizieren würde).160

10 Elastic Graph MatchingDie Anzahl der Parameterortsvektoren lässt sich durch die Methode getParameterSpaceSizeabfragen und der Index p 0 des Ursprungsparameterortsvektors,also des Parameterortsvektors, der die Position eines unmodifizierten Graphenbeschreibt, wird von der Methode getNonModifyingParameterIndexzurückgegeben.Die erforschende Nummerierung eines Functors, also die bijektive Abbildungeines Erforschungsindexes auf die Parameterortsvektorenindices, wird durch dieMethode getExploringIteratorIndex realisiert.Mit Hilfe eines Functors kann ein Graph vom Ursprung v p0zu anderen Positionenv a und v b im Parameterraum verschoben werden. Dies kann dadurch geschehen,dass der Graph zuerst von v p0nach v a und dann von dort nach v bverschoben wird. Bei einigen Functoren allerdings würden sich auf diese Art,auf Grund der diskreten Bildpositionen, Rundungsfehler aufsummieren, beispielsweisebei der Functor-Implementierung Rescale; in diesem Fall darf derFunctor nur auf Kopien des Graph-Objekts angewandt werden, so dass vonv p0nach v a und dann von v p0nach v bverschoben werden kann. Functoren,für die dies notwendig ist, liefern true bei Aufruf der Methode isRounding-ErrorProne zurück.Implementierungen der Functor-SchnittstelleFür jede Transformationsart gibt es eine Implementierung der SchnittstelleFunctor, die die Transformationsfunktion umsetzt. Zudem sind die Implementierungendafür zuständig, die Diskretisierung und Begrenzung des Parameterraumsentsprechend der ihrem Konstruktor übergebenen Parameter vorzunehmen.Die Transformationsfunktion als Teil des Functors zu implementieren weichtvon unserer mathematischen Definition eines Funktors insofern ab, als dass beidieser ein Funktor mit einer Transformationsfunktion parametrisiert wird. Diedirekte Umsetzung wäre also, eine Klassenhierarchie für die Transformationsfunktionenaufzubauen und deren Instanzen für die Parametrisierung einesFunctors zu verwenden. Die Diskretisierung und Begrenzung des Parameterraumsist aber speziell für jede Transformationsfunktion. Somit müsste dennochfür jede Transformationsfunktion eine Functor-Implementierung existieren, wodurchdie Anzahl der Klassen steigen würde, ohne dass dies die Verständlichkeit161

10 Elastic Graph Matchingoder Wiederverwendbarkeit erhöhen würde. Deswegen haben wir dieser Variantedie einfachere Umsetzung vorgezogen.Beispielhaft sind in Abbildung 68 die Functor-Implementierungen Move undRescale aufgeführt. Deren Konstruktorparamter entsprechen den in Abschnitt10.2.2 dargestellten Parametern mit der Erweiterung, dass die umzusetzendeTransformationsfunktion angegeben werden kann. 58Weiterhin ist die Functor-Implementierung Composite dargestellt, die einKompositum von Functor-Objekten entsprechend des Kompositionsmustersaus [GHJV96] darstellt – mit der Besonderheit, dass Composite keine Verwaltungsoperationenfür Functor-Objekte anbietet und immer genau zweiFunctor-Objekte enthält, die im Konstruktor übergeben werden müssen.10.4.3 Bewertung der Graphübereinstimmung durch EstimatorDurch die im letzten Abschnitt beschriebenen Functoren lässt sich ein Graphauf vielfältige Weise transformieren. Um einen Anpassungssschritt durchzuführen,reicht das alleine aber noch nicht. Es ist zudem notwendig, die Graphübereinstimmungnach jeder Transformation bewerten zu können. In der mathematischenModellierung sind dafür die Ähnlichkeitsfunktionen vorgesehen. Je nachdem,auf welchem Kriterium eine Ähnlichkeitsfunktion basiert, benötigt sie unterschiedlicheParameter. Zwei Beispiele: Eine Ähnlichkeitsfunktion, die einenGraph mit einem Bunchgraphtemplate vergleicht, benötigt diese beiden als Parameter.Eine Ähnlichkeitsfunktion, die nur die Ähnlichkeit eines Knoten berücksichtigensoll, benötigt zusätzlich den Index dieses Knotens.Um für die Bewertung der Graphübereinstimmung verschiedene Ähnlichkeitsfunktionenpolymorph verwenden zu können, haben wir die SchnittstelleEstimator (Bewerter) eingeführt, die die Methode estimate deklariert, sieheAbbildung 69. Ein Aufruf von estimate liefert eine Bewertung zwischen Nullund Eins und nimmt nur einen Graph als Parameter – die für die Bewertungweiterhin notwendigen Parameter müssen als Attribute in den Implementierungenmodelliert werden. Für fast alle zur Zeit zur Verfügung stehendenEstimator-Implementierungen ist zur Bewertung ein BunchGraph-Templateals weiterer Parameter notwendig. Dieser Gemeinsamkeit entsprechend gibt es58 Für Move kann die Achse angegeben werden, entlang derer verschoben werden soll, undfür Rescale die Achse beziehungsweise die Achsen, entlang derer skaliert werden soll.162

10 Elastic Graph MatchingAbbildung 69: Klassendiagramm Estimatoreine abstrakte Basisimplementierung der Estimator-Schnittstelle, die einenBunchGraph als protected-Attribut enthält: AbstractEstimator. Direkte Extensionendieser Klasse sind JetAbsEstimator und JetPhaEstimator, dieTdie Ähnlichkeitsfunktionen S absTund S phaimplementieren, sowie die abstrakteZwischenklasse NodeEstimator, die als Basis für Estimatoren dient, die nureinen Node des Graphen zur Bewertung verwenden. Um zu bestimmen, auf welcheNode sich ein NodeEstimator bezieht, hat die Klasse das protected-AttributnodeIndex. Implementierungen von NodeEstimator sind Topology-NodeEstimator, der die Verformung der anliegenden Kanten eines Knoten bewertet,und JetAbsNodeEstimator sowie JetPhaNodeEstimator, die dieBÄhnlichkeitsfunktionen S absBsowie S phaimplementieren.Schließlich gibt es noch den CompositeEstimator, der zwei beliebige Estimatorengewichtet kombiniert. Werden dem Konstruktor zwei Estimatoren,die die Ähnlichkeitsfunktionen S 1 und S 2 implementieren und zwei Gewichtew 1und w 2übergeben, dann stellt der entstehende CompositeEstimator163

10 Elastic Graph Matchingdie Ähnlichkeitsfunktion S cG=w 1S 1Gw 2S 2G dar. CompositeEstimatorist ein Kompositum von Estimator-Objekten entsprechend des Kompositionsmustersaus [GHJV96] – mit der Besonderheit, dass CompositeEstimatorkeine Verwaltungsoperationen für Estimator-Objekte anbietet und immer genauzwei Estimator-Objekte enthält, die im Konstruktor übergeben werdenmüssen. 5910.4.4 Konfiguration und Durchführung der GraphanpassungMit den in den letzten beiden Abschnitten beschriebenen Schnittstellen Functorund Estimator und ihren Implementierungen kann ein Graph transformiertund seine Übereinstimmung mit einem Bild bewertet werden. Diese Funktionalitätist Voraussetzung für die Konfiguration und Durchführung eines Anpassungsschritts:10.4.4.1 MatchingStepDie Konfiguration eines Anpassungsschritts erfolgt durch ein MatchingStep-Objekt (siehe Abbildung 70). Ein solches hat Referenzen auf den zu verwendendenFunctor und Estimator und legt die für das Tracking (siehe Abschnitt10.2.5.3) notwendigen Faktoren r init min und r track min durch seine AttributetrackingMinimumFactor und initialMinimumFactor sowie den Faktorr track hyst durch trackingHysteresisFactor fest. Weiterhin legt es fest, obfür den Anpassungsschritt getrackt und welcher Bildindex verwendet werdensoll. 6010.4.4.2 OptimizerFür die Durchführung eines Anpassungsschritts ist die Klasse Optimizer verantwortlich.Ein Optimizer wird bei der Konstruktion mit einem MatchingStepkonfiguriert. Optimizer als Kontext und MatchingStep als Strategie implementierendas Strategiemuster aus [GHJV96] – allerdings wieder mit einer Besonderheit:MatchingStep implementiert nicht direkt einen Algorithmus,59 Trotz der starken strukturellen und Namensähnlichkeit zur Functor-ImplementierungComposite, sind beide völlig unabhängig voneinander zu verwenden. Es muss insbesonderenicht ein CompositeEstimator für einen Composite-Functor verwendet werden.60 Die Funktion des Bildindexes wird weiter unten bei der Matching-Klasse erklärt.164

10 Elastic Graph MatchingAbbildung 70: Klassendiagramm MatchingStep, Optimizer und MatchingDie Attribute der Klasse MatchingStep sind der Einfachheit wegen als öffentlich markiert. Tatsächlichgibt es für jedes Attribute einen »getter« und die Attribute werden im Konstruktor festgelegt(MatchingStep ist also eigentlich »immutable«)sondern stellt den indirekten Zugriff auf die Suchlogik (in Form eines Functors)und die Bewertungslogik (in Form eines Estimators) zur Verfügung.Die Durchführung eines Anpassungsschritts geschieht durch die MethodefindOptimum. Diese findet die optimale Graphübereinstimmung in dem Parameterraumdes Functors unter Verwendung des Estimators. Zur Implementierungdes Trackings hat findOptimum, neben dem anzupassenden Graph,einen Parameter zur Festlegung des Parameterortsvektorindexes bei dem dieSuche des Parameterraums begonnen werden soll und einen Parameter der festlegt,ob überhaupt getrackt werden soll 61 .61 Das heißt, ob das Absuchen des Parameterraums abgebrochen werden kann, wenn die Abbruchbedingungzutrifft (siehe Abschnitt 10.2.5.3).165

10 Elastic Graph MatchingSchließlich bietet Optimizer noch Methoden, um die statistische Analyse vonBeispielbildern für einen Anpassungsschritt durchzuführen und das Ergebnisabzufragen (accumulateEstimations, analyseEstimations, getInitialMinimum,getTrackingMinimum).10.4.4.3 MatchingFunctor, Estimator, MatchingStep und Optimizer erlauben es, einenGraphanpassungsschritt auszuführen. Da die Graphanpassung aus mehrerenSchritten besteht, ist noch ein Klient dieser Klassen notwendig, der die verschiedenenSchritte der Reihe nach ausführt und den Trackingzustand hält (siehe Abschnitt10.2.5.4). Das ist die Klasse Matching.Ihre Instanzen werden bei der Konstruktion mit einer Liste von MatchingStep-Objekten konfiguriert und im Konstruktor wird für jedes dieser Objekte einOptimizer instanziiert. Weiterhin wird dem Konstruktor ein Prototyp des anzupassendenGraphen übergeben.Zur Verwaltung des Trackingzustandes hat die Klasse Matching zwei Attribute:Das Attribut lastOptimalParameterIndices enthält die Parameterortsvektorindicesder Parameterraumpositionen, an denen der Graph für das letzte Videobilddie beste Graphübereinstimmung hatte. Das Attribut tracking enthältdie Information, in welchem Hauptzustand (»Tracking« oder »Nicht-Tracking«)sich die Erkennung gerade befindet.Die Methode match führt die Anpassungsschritte der Reihe nach aus und liefertzurück, ob der Graph erfolgreich angepasst werden konnte. Das Anpassungsergebniskann mit der Methode getGraph abgefragt werden.Da die Graphanpassung auf Bildern einer Gaußschen Auflösungspyramide erfolgensoll, muss der Methode match eine Liste mit allen Bildern der Auflösungspyramideübergeben werden. Das für einen Anpassungsschritt zu verwendendeBild wird durch den imageIndex der Klasse MatchingStep bestimmt.Um die statistische Analyse von Beispielbildern für alle Anpassungsschritte auszuführen,bietet Matching die Methoden accumulateEstimations undanalyseEstimations.166

10 Elastic Graph Matching10.4.4.4 InstanzbeispielAbschließend sei ein einfaches Beispiel gegeben, wie Objekte der in diesem Abschnittbeschriebenen Klassen zusammenarbeiten.Abbildung 71 ist ein Objektdiagramm, das ein Matching-Objekt zeigt, welchesbei der Konstruktion mit zwei MatchingSteps konfiguriert wurde. Entsprechendwurden durch den Konstruktor zwei Optimizer-Objekte instanziiert, diejeweils mit einer Referenz auf die konfigurierenden MatchingStep-Objekte versorgtwurden. Der eine MatchingStep referenziert als Functor ein Move-Objekt und als Estimator ein JetAbsEstimator-Objekt. Der andere MatchingStepreferenziert als Functor ein Rotate-Objekt und als Estimatorein JetPhaEstimator-Objekt. Neben den MatchingStep- und Optimizer-Objekten hat das Matching-Objekt eine Referenz auf den anzupassendenGraph.Abbildung 71: Objektdiagramm MatchingStep, Optimizer und MatchingAbbildung 72 zeigt vereinfacht das prinzipielle Zusammenspiel dieser Objektstruktur,wenn ein Klient die Methode match auf dem Matching-Objekt aufruft:Das Matching-Objekt ruft der Reihe nach auf jedem Optimizer die MethodefindOptimum auf. Für den ersten von diesen Aufrufen zeigt das Diagramm, wieder Optimizer den Aufruf behandelt. Er fragt zuerst den entsprechenden167

10 Elastic Graph MatchingAbbildung 72: Sequenzdiagramm MatchingFunctor 62 , in diesem Fall das Move-Objekt, wieviele Parameterortsvektoren erhat. Dann führt er folgende Schritte der Anzahl der Parameterortsvektoren entsprechendhäufig aus:62 Die Referenzen auf den Functor und den Estimator erlangt der Optimizer über denMatchingStep.168

10 Elastic Graph Matching– Er fragt den nächsten Parameterortsvektorindex der erforschendenNummerierung des Functor-Objekts über die Methode getExploringIteratorIndexab.– Er ruft die Methode apply auf dem Functor-Objekt derart parametrisiertauf, dass der Graph an die Position im Parameterraum verschobenwird, die durch den soeben abgefragten Parameterortsvektorindex gegebenist.– Er ruft die Methode estimate auf dem Estimator-Objekt (in diesemFall eine Instanz von JetAbsEstimator) auf, um die Graphübereinstimmungfür die Parameterraumpositionen zu bewerten.Abschließend wird der Graph an die Parameterraumposition mit der besten gefundenenGraphübereinstimmung verschoben.10.4.5 Erkennung der mare-Geste durch GestureRecognitionDie bis hier beschriebenen Klassen modellieren das weiterentwickelte ObjekterkennungsverfahrenElastic Graph Matching und erlauben es, eine Graphanpassungdurchzuführen. Um die Erkennung der mare-Geste umzusetzen, ist einKlient dieser Klassen notwendig, der– die zur Erkennung der mare-Handhaltung zu verwendenden Anpassungsschrittekonfiguriert,– Bildpositionen von Daumen- und Zeigefingerspitze bestimmt,– die Gestenphase aus dem Abstand der Bildpositionen von DaumenundZeigefingerspitze ermittelt und– Gestenereignisse erzeugt, die von den Interaktionskomponenten empfangenwerden können.Dieser Klient ist die Klasse GestureRecognition (Abbildung 73). Sie stellteine Fassade entsprechend des Fassadenmusters aus [GHJV96] dar und bieteteine einfache Schnittstelle auf das mare-Modul Gestenerkennung. Insbesonderebewahrt sie die Interaktionskomponenten davor, sich um die Details derGestenerkennung, wie zum Beispiel die Konfiguration der Anpassungsschritte,zu kümmern. GestureRecognition ist ein EventProvider für169

10 Elastic Graph MatchingGestureEvents, so dass sich die Interaktionskomponenten als Listener für dieGestenereignisse registrieren können.Abbildung 73: Klassendiagramm GestureRecognitionDem Konstruktor von GestureRecognition muss ein ImageSequence-Manager übergeben werden, der als Quelle für Videobilder dient. Ein Aufruf derMethode start erzeugt einen neuen Thread, in dem GestureRecognitionlaufend Bilder vom ImageSequenceManager abfragt und für diese die Erkennungausführt. Das Ergebnis der Erkennung sind Gestenereignisse, die an alleregistrierten Listener verteilt werden.10.5 ZusammenfassungDas mare-Modul Gestenerkennung stellt über die Fassade GestureRecognitioneine Quelle für Gestenereignisse zur Verfügung. Die Gestenereignissekönnen von den Interaktionskomponenten empfangen werden.Zur Erkennung der mare-Geste ist das Objekterkennungsverfahren ElasticGraph Matching stärker formalisiert und weiterentwickelt worden. Es wurde dieMöglichkeit geschaffen, Graphverformungen zu modellieren sowie zu trackenund die Ausführungsgeschwindigkeit wurde durch Verwendung einer Auflösungspyramidegesteigert.170

Hauptteil IVBeispielanwendung

11 Eine Beispielanwendung11 Eine BeispielanwendungIn diesem Kapitel wird die Benutzung von mare anhand der Erstellung einereinfachen Anwendung gezeigt. Die ausführlich beschriebene Implementierungder Anwendung soll mare-Anwendungsentwicklern helfen, die grundlegendenSchritte zu erlernen, die nötig sind, um mit mare AR-Anwendungen zu erstellen.Als Beispiel wird die Anwendung zur Waschmaschinendemontage aus der Einführungverwendet. Die Anwendung dient dazu, einem Monteur während derArbeit Demontagepfade anzuzeigen. Um den Arbeitsfortschritt zu steuern, solldie Anwendung einen Button zeigen, der per Gestensteuerung aktiviert werdenkann und daraufhin den Demontagepfad für den nächsten Arbeitsschritt zurAnzeige bringt.Die Anwendung soll:– das Videobild der Brille anzeigen,– die AR-Objekte, die die Ausbaupfade beschreiben, anzeigen,– einen Button darstellen,– bei Aktivierung des Buttons durch die mare-Geste den nächstenArbeitsschritt aufrufen.173

11 Eine BeispielanwendungUmsetzungDa dieses Beispiel dazu dient, die Benutzung von mare zur Entwicklung vonmare-Anwendungen im Allgemeinen zu beschreiben, werden die Logik und dieAR-Objekte der Anwendung zur Waschmaschinendemontage nicht weiter behandelt.Statt dessen wird eine Schnittstelle System definiert, die zur Zusammenarbeitmit den mare-Interaktionskomponenten verwendet wird.Die Schritte, die zur Erstellung dieser einfachen mare-Anwendung nötig sind,werden in der Klasse Demo umgesetzt. Der Quelltext der Demo-Klasse wird imfolgenden Abschnitt ausführlich beschrieben.Übersicht über die BeispielanwendungAbbildung 75: Klassendiagramm der BeispielapplikationDamit Objekte der Demo-Klasse Ereignisse von dem Button empfangen können,muss Demo die Schnittstelle Listener mit der MethodeprocessEvent(ActionEvent) implementieren. Dadurch können sich Demo-Objekte als Empfänger der Ereignisse bei Button registrieren.Nach Empfang eines Ereignisses des Buttons ruft Demo die Methode next-Step von System auf.174

11 Eine BeispielanwendungDie Klasse DemoUm eine funktionsfähige mare-Anwendung zu erstellen, werden die folgendenAnweisungen im Konstruktor von Demo ausgeführt:– Initialisieren der OpenInventor-Klassenbibliothek und Instanziieren einesViewers zur Anzeige der mare-Anwendung.– Initialisierung der mare-Interaktionsschnittstelle und der Gestenerkennung– Erzeugen eines Buttons.– Verknüpfen des Buttons mit einem Listener.– Verknüpfung der AR-Objekte der Anwendung mit der Darstellungskomponente.– Aufruf der OpenInventor Methode mainloop zum Starten derAnwendung.11.1.1 Quelltext von DemoDer Quelltext zeigt den C++ Code, der nötig ist, um eine mare-Anwendungmit der oben beschriebenen Funktionalität zu implementieren. Include-Anweisungenund Namespaces wurden weggelassen, wichtige Teile sind halbfett hervorgehoben.Kommentare werden zur besseren Übersicht rot dargestellt. Dieanwendungsspezifischen Teile des Sourcecodes sind blau markiert.175

11 Eine BeispielanwendungDie main-Funktionint main(){Demo demo;demo.execute();}Klassendefinition// Demo implementiert Button::ActionListener, damit Demo-Objekte// Ereignisse von einem Button empfangen koennen.class Demo : public Button::ActionListener{public:// Im Konstruktor wird die Beispielanwendung initialisiert.Demo();virtual ~Demo();// Ausführung der Beispielanwendung.void execute();// Diese Methode wird von Button nach der Aktivierung// des Buttons aufgerufen.void processEvent(ActionEvent& event);private:// Die Geschaeftslogik der Waschmaschinendemontageanwendung// ist in diesem 'System'-Objekt gekapselt.Systemm_system;SoQtExaminerViewer* m_viewer;QWidget* m_mainwin;ImageSequenceManagerPtr m_imageSequenceManager;GestureRecognitionPtr m_gestureRecognition;};176

11 Eine BeispielanwendungImplementierung der Methoden aus DemoDemo::Demo(){// Initialisierung von OpenInventor und Erzeugung// eines Viewers zur Anzeige der Anwendung.QWidget* mainwin = SoQt::init("");m_viewer = new SoQtExaminerViewer(mainwin);// Initialisierung der OpenInventor-Erweiterungen aus mare.util::init();// Erzeugung einer Videobildquelle.ImageProviderPtr imageProvider(new ARToolKitImageProvider(""));m_imageSequenceManager = ImageSequenceManagerPtr(new ImageSequenceManager(imageProvider));// Erzeugung und Initialisierung des Gestenerkennungsmoduls.m_gestureRecognition = GestureRecognitionPtr(new GestureRecognition(m_imageSequenceManager));// Erzeugung der grundlegenden Darstellungskomponente MareSceneKit.MareSceneKit* sceneKit = new MareSceneKit;sceneKit->setImageSequenceManager(m_imageSequenceManager);sceneKit->setSceneManager(m_viewer->getSceneManager());// Setzen des MareSceneKits als anzuzeigender Szenegraph.m_viewer->setSceneGraph(sceneKit);// Verknüpfung des GuiKits mit dem Modul zur Gestenerkennung// (Registrierung als GestureEventListener).m_gestureRecognition->addListener(sceneKit->getGuiKit());// Einsetzen der vom System bereitgestellten AR-Objekte zur// Anreicherung des Videobildes in das MareSceneKit.sceneKit->getVirtualityRoot()->addChild(m_system.getARObjects());// Instanziieren eines Buttons mit Label und Position.Button* button = new Button(">|", "", SbVec3f(-100, 100, 0));// Registrieren eines Listeners fuer ActionEvents des Buttons.button->addActionListener(this);}// Einsetzen des Buttons in das GuiKit.sceneKit->getGuiKit()->addChild(button);void Demo::execute(){// Starten der Videobildquelle und Starten der Gestenerkennungm_imageSequenceManager->start();m_gestureRecognition->start();}// Anzeige des Viewers und Start der Anwendungm_viewer->show();SoQt::show(m_mainwin);SoQt::mainLoop();void Demo::processEvent(const ActionEvent& event){m_system.nextStep();}177

Schluss

12 Diskussion12 DiskussionMit mare haben wir ein Environment für die Entwicklung von AR-Anwendungengeschaffen, das wiederkehrende und grundlegende Aufgaben aus Augmented-Reality-Anwendungen löst. Zur Systemsteuerung wurde eine Interaktionstechnikentwickelt, die ohne Interaktionsgeräte auskommt und so den Benutzer nichteinschränkt.12.1 InteraktionsschnittstelleDie mare-Interaktionsschnittstelle musste zwei Aufgabenbereiche lösen: Zumeinen sollte eine grundlegende Basis für die Darstellung der Computergrafik inAR-Anwendungen geschaffen werden, die die typischen Bestandteile von AR-Anwendungen zusammenführt und die dort anzutreffenden Probleme löst.Außerdem sollte eine prototypische Sammlung von Interaktionskomponentenentwickelt werden, die zur Steuerung einer solchen Anwendung dienen.DarstellungskomponentenDie funktionalen Anforderungen an die Darstellungskomponenten – Anzeigedes Videobildes und der AR-Objekte und Lösung des Verdeckte-Objekte-Problems– werden erfüllt. Auch eine Darstellungskomponente zur Anzeige desGestencursors wurde entwickelt. Damit sind die wichtigsten Voraussetzungen zurEntwicklung von AR-Anwendungen mit einem Video-See-Through-System geschaffen.Das MareSceneKit erlaubt dem mare-Anwendungsentwickler die einfacheZusammensetzung der verschiedenen visuellen Bestandteile der Anwendungund sorgt für die korrekte Darstellung. Neben den nicht interaktiven visuellenBestandteilen bietet es die Möglichkeit, Interaktionskomponenten einzufügen.InteraktionskomponentenZur Erstellung der Benutzerschnittstelle einer mare-Anwendung wurde eineAuswahl von Interaktionskomponenten entwickelt. Die Gestaltung der Interaktionskomponentenberücksichtigt die Steuerung durch Gesten und die Anzeigein Video-See-Through-Systemen. Sie verdecken die Sicht des Anwenders nicht181

12 Diskussionvollständig, sondern lassen ihn die im Videobild wiedergegebene Realität nochvisuell wahrnehmen. Die Interaktionskomponenten sind in ihrer Gestaltung soangelegt, dass sie vor jedem Hintergrund gut erkennbar und benutzbar sind. ZurAnpassung an andere gestalterische Anforderungen lassen sich alle Interaktionskomponentenin ihrer visuellen Darstellung verändern, einzeln oder in ihrerGesamtheit.Die objektorientierte Modellierung als Klassenhierarchie, die auf OpenInventor-Szeneobjekten aufbaut, ermöglicht eine einfache Verwendung der Interaktionskomponentenin mare-Anwendungen. Es können spezialisierte Interaktionskomponentenaus den bestehenden abgeleitet werden, wie zum BeispielCheckbox und RadioButton, die fast ihre gesamte Funktionalität von Buttonübernehmen. Auch können komplexe Interaktionskomponenten aus einfachenzusammengesetzt werden, wie im Fall von Rotor. Die bestehenden Klassenwurden so entworfen, dass Erweiterbarkeit und Wiederverwendbarkeit möglichstgroß sind.Alle Darstellungs- und Interaktionskomponenten wurden als Erweiterung derOpenInventor-Klassenbibliothek implementiert und können so auf einfache Weisein bestehenden OpenInventor-Anwendungen verwendet werden. Entwickler,die Erfahrung in der Programmierung mit OpenInventor haben, werden dieBenutzung der Darstellungs- und Interaktionskomponenten als einfach und intuitivempfinden, da bei dem Entwurf ihres APIs die Szeneobjekte aus OpenInventorauf weiten Strecken als Vorbild gedient haben.Nach den bisherigen Versuchen mit einfachen Beispielanwendungen sind dieentwickelten prototypischen Interaktionskomponenten für die Anwendung inAR-Systemen geeignet und erfüllen die Aufgabenstellung.12.2 GestenerkennungZur Umsetzung der Gestenerkennung wurde ein Verfahren entwickelt, das dieHand des Benutzers in Videobildern erkennt und verfolgt. Die mare-Geste wirdsicher von anderen Gesten unterschieden und kann damit zur Steuerung vonAR-Anwendungen verwendet werden, bei denen der Benutzer auch manuelleArbeiten im Gesichtsfeld durchführt.Die entwickelte Gestenerkennung basiert auf dem ObjekterkennungsverfahrenElastic Graph Matching. Die in dieser Arbeit gemachten Erweiterungen des zu182

12 DiskussionGrunde liegenden Verfahrens ermöglichen die Erfüllung der Anforderungen ausKapitel 8:Die funktionalen Anforderungen 1 bis 3 werden erfüllt. Die Hand des Benutzerswird im Videobild gefunden, es wird entschieden, ob die Handhaltung dermare-Handhaltung entspricht und die Öffnungsweite der Hand wird besimmt.Auch die nicht-funktionalen Anforderungen werden von dem entwickelten Verfahrenerfüllt: Es ist robust gegenüber Position, Form, Größe und Rotation derHand durch entsprechende Wahl der Anpassungsschritte. Die Ausführungsgeschwindigkeitliegt auf dem verwendeten System (Pentium 4, 2,6 GHz) bei etwafünf Bildern pro Sekunde. Als besonders vorteilhaft hat es sich erwiesen, dassdas Verfahren die Möglichkeit bietet, für die Bewertung der Übereinstimmungdes Graphen mit dem Bild die lokalen Bildeigenschaften nicht nur eines, sonderneiner Menge von Beispielbildern zu berücksichtigen. Wir verwendetenBeispielbilder, die bereits eine gewisse Robustheit gegenüber unterschiedlichenBeleuchtungssituationen und inhomogenem Hintergrund brachten.Insgesamt erzielt das Verfahren mit den ermittelten Anpassungsschritten bereitsvielversprechende Ergebnisse. Für die Person, deren Hand als Vorlage für dieBeispielbilder gedient hat, ist die Gestenerkennung vor homogenem Hintergrundeinsetzbar. Probleme bereitet noch inhomogener Hintergrund sowie gegenüberden Beispielbildern drastisch veränderte Beleuchtungsverhältnisse wiezum Beispiel Gegenlicht, bei dem auf dem Videobild nur noch eine schwarzeSilhouette der Hand zu erkennen ist. Auf dem bisherigen Entwicklungsstandkann das entwickelte Erkennungsverfahren also noch nicht in jeder AR-Anwendunguneingeschränkt verwendet werden.183

13 Ausblick13 AusblickObwohl die Augmented Reality ein junges Forschungsfeld ist, wird ihre konkreteAnwendung schon heute in verschiedenen Industriezweigen getestet – ihr Potenzialist aber bei weitem noch nicht ausgeschöpft. Die wachsende Zahl derAnwendungen wird einen steigenden Bedarf an intuitiven Interaktionsformenauslösen, die den Benutzer nicht einschränken.13.1 InteraktionsschnittstelleDie prototypische Entwicklung der Interaktionskomponenten in mare zeigt,dass das Konzept von gestengesteuerten Benutzerschnittstellen in der AugmentedReality anwendbar ist. Wichtigste Aufgabe ist nun, in realen Anwendungendie Verwendbarkeit der entwickelten Komponenten zu untersuchen und herauszufinden,welche Steuerungsaufgaben in Bezug auf konkrete Praxisanwendungenzu optimieren beziehungsweise neu zu entwickeln sind.Durch Untersuchung konkreter Szenarien und Aufstellen weiterer Use-Cases fürverschiedene Anwendungen können Interaktionsaufgaben erkannt werden, diezur Zeit noch nicht mit mare-Interaktionskomponenten erfüllt werden können.Aus diesen Informationen können dann neue Interaktionskomponenten abgeleitetwerden.Vorstellbar ist die Entwicklung von Möglichkeiten zur Texteingabe (zum Beispielfür Dateinamen oder kurze Notizen). Dafür könnte eine gestengesteuerte virtuelleTastatur verwendet werden.Auch ist vorstellbar, dass baumartig angeordnete Daten in einer Interaktionskomponenteauswählbar gemacht werden sollen, um zum Beispiel hierarchischeMenüs oder Dateisysteme darzustellen. Dafür könnte die InteraktionskomponenteRotor zu einem komplexeren Multirotor zusammengesetzt werden, derdurch nebeneinander angeordnete Zylinder den Selektionsweg durch eineHierarchie zeigt.184

13 AusblickEine kritische Beurteilung der Usability ist eine wichtige Voraussetzung für diebestehenden und noch zu entwickelnden Interaktionskomponenten, um sie inwirklich einsatzfähigen Benutzerschnittstellen von AR-Anwendungen zu verwenden.Die Entwicklung von Usability-Tests in realen Anwendungen ist eine aufwändigeaber notwendige Aufgabe, um den Nutzen der Interaktionsschnittstellevon mare zu maximieren.Anpassung an Optical-See-ThroughWährend der Entwicklung von mare haben wir uns auf die optimale Unterstützungvon Video-See-Through-Systemem konzentriert. Die Gestaltung der Interaktionskomponentenist für die Verwendung auf Video-Bildern optimiert. DieAnpassung der Interaktionskomponenten an Optical-See-Through-Systeme würdeden Anwendungsbereich von mare erweitern.Abkopplung von OpenInventorDie Zielsetzung der Diplomarbeit beinhaltete die Entwicklung der Interaktionsschnittstelleals Erweiterung der OpenInventor-Klassenbibliothek. Dies hat zurFolge, dass die Modelle, die den Interaktionskomponenten zu Grunde liegen, inder Implementierung nicht von ihrer grafischen Darstellung getrennt sind. Umdiese Kopplung zu lösen, könnte ein neues Design der mare-Interaktionsschnittstelleeine eigene Klassenhierarchie beinhalten, die die Interaktionskomponentenals Modelle beschreibt und eine losere Verbindung zu ihrer grafischenDarstellung erlaubt. Dadurch könnten verschiedene Szenegraphbibliothekeneingesetzt werden.Verdeckte-Objekte-ProblemIn unseren Versuchen mit einfachen mare-Anwendungen hat sich herausgestellt,dass es in bestimmten Situationen verwirrend sein kann, wenn VR-ObjekteGegenstände aus der realen Welt verdecken, die aber eigentlich vor den VR-Objekten liegen (siehe Abschnitt 6.2). Besonders irritierend ist dies, wenn derBetrachter ein virtuelles Objekt mit der Hand greifen will und die eigentlich vordem Objekt befindliche Hand von dem Objekt verdeckt wird. Um diesem Problemzu begegnen, muss eine Möglichkeit geschaffen werden, die Entfernung185

13 Ausblickder realen Gegenstände zu messen und bei der Darstellung der VR-Objekte zuberücksichtigen. Dies wäre durch die Verwendung einer Stereokamera möglich,deren Tiefeninformation in die Darstellung einfließen könnte (vgl. auch[KOYTK95]).13.2 GestenerkennungObwohl das Verfahren zur Gestenerkennung im derzeitigen Entwicklungsstandnoch nicht in jeder Umgebung einsetzbar ist, glauben wir, dass das Verfahrendas Potenzial hat, so ausgebaut zu werden, dass eine voll funktionsfähige Interaktionsmethodefür AR-Anwendugen entsteht.Dies erfordert zum einen die systematische Optimierung der bereits vorhandenenKonfigurationsmöglichkeiten des Verfahrens. Zum Beispiel würde ihn esdurch höhere Zahl passender Beispielbilder in noch größerem Maße robustgegenüber Beleuchtungsveränderungen sowie inhomogenem Hintergrund undunabhängig von der ausführenden Person (insbesondere auch ihrer Hautfarbe).Außerdem bietet sich die Möglichkeit, die von uns festgelegte Graphtopologiehinsichtlich Optimierungen zu untersuchen.Zum anderen können bereits in der Literatur zu findende Verbesserungen umgesetztwerden, wie zum Beispiel die in [TM01] beschriebene Verwendung zusätzlicherBildmerkmale (beispielsweise Hautfarbenähnlichkeit) neben den Gabor-Wavelet-Faltungsantwortenoder die in [Loy02] dargestellten Möglichkeiten zur Verringerungder Rechenkomplexität bei der Erzeugung dieser Antworten.Desweiteren sind während der Entwicklung folgende Ideen für Verbesserungenund zusätzliche Weiterentwicklungen des Elastic Graph Matching entstanden:Variabilität der GraphformUm Unabhängigkeit von Handgeometrie und Links- oder Rechtshändigkeit zu erreichen,könnte das Konzept des Bunchgraphs so erweitert werden, dass ein solcherneben mehreren Jets an den Knotenpunkten auch unterschiedliche Knotenpositionenenthalten kann, so dass innerhalb der durch ein Bunchgraphtemplatebeschriebenen Klasse von Objekten auch deren Geometrie variieren kann.Wie bereits in Abschnitt 10.2.3 erläutert, könnte die Verformbarkeit des Graphendurch Interpolation zwischen Extremformen modelliert werden.186

13 AusblickDie Kombination beider Ansätze (Erweiterung des Bunchgraphkonzepts und Interpolationzwischen Extremformen) könnte zur Erkennung komplexerer Gestenals der mare-Geste verwendet werden.Automatisierung der KonfigurationDie Auswahl und Konfiguration der Anpassungsschritte sowie die Festlegungder Graphtopologie müssen zur Zeit manuell erfolgen. Dies zu automatisierenwürde es auch fachfremden Softwareentwicklern erlauben, das Elastic GraphMatching als Objekterkennungsverfahren einzusetzen. Unsere Vision ist, dass nureine Menge von Beispielbildern zur Verfügung gestellt und über diese ein »Minimalgraph«gelegt werden muss, der die Kontur des zu trainierenden Objektsund die Punkte von Interesse 63 beschreibt. Die beste Graphtopologie und diebesten Anpassungsschritte würden automatisch ermittelt durch einen evolutionärenAnsatz, der die Erkennungsgenauigkeit zur Bewertung verwendet unddiese so schrittweise verbessert.Erweiterung des TrackingverfahrensWeiterhin interessant wäre es zu untersuchen, inwieweit das Trackingverfahren»Condensation« ([IB96]) eine Ergänzung oder ein Ersatz für das von uns entwickelteTracking sein könnte. Denkbar ist zum Beispiel, dass unser Trackingverfahrenzur Begrenzung des abzusuchenden Parameterraums verwendet wird unddurch Condensation die genaue Parameterbestimmung durchgeführt wird.Flexiblere KonfigurationSoftwaretechnische Verbesserungsmöglichkeiten sehen wir bei der Definitionder Graphtopologie und der Anpassungsschritte, was zur Zeit noch durchSchreiben von Code erfolgt. Hier wäre es wünschenswert, ein XML-Schema zudefinieren. Dies hätte den Vorteil, dass die manuelle Festlegung von Graphtopologieund Anpassungsschritten ohne Neukompilieren geändert und eine etwaigautomatisch erzeugte persistent gemacht werden könnte.63 Bei uns wären das die Daumen- und Zeigefingerspitze.187

14 Resümee14 ResümeeDas mare Augmented Reality Environment für die Entwicklung von AR-Anwendungenzeichnet sich durch seine innovative Interaktionsschnittstelle und die dafüreingesetzte Gestenerkennung aus.Wir sind der Überzeugung, dass mit dieser Arbeit eine solide Basis für die skizziertenzukünftigen Entwicklungen gelegt und somit das Potenzial zur Anwendungin Bereichen geschaffen wurde, die weit über die ursprüngliche Aufgabenstellunghinausgehen.188

Anhänge

Anhang AÜbersicht über das mare-Modul InteraktionsschnittstelleSoNodeSoBaseKitImageBackgroundBufferClearCursorNodeKitSoSceneKit«Listener»GuiComponentCursorKitMareSceneKit«EventProvider»ContainerList«EventProvider»ResponderPanel«Listener»GuiKit«Listener»Rotor«Listener»«EventProvider»ButtonLabel«EventProvider»ResponsivePanel«EventProvider»CheckBoxOpenInventor Basisklassenmare Darstellungskomponenten«EventProvider»RadioButtonmare InteraktionskomponentenDie verwendeten Stereotypen bezeichnen die EventProviderbeziehungsweise Listener, von denen die jeweilige Klasse erbt

Anhang AÜbersicht über das mare-Modul Gestenerkennung«EventProvider»GestureRecognitionFassade zur Erkennung der mare-GesteGraph und BunchgraphGraphtransformationMatching{m = n >= 1}Bewertung der GraphübereinstimmungGraphanpassungmn1..*OptimizerMatchingStep*«interface»Estimator2*CompositeEstimatorAbstractEstimator*«interface»Functor2JetAbsEstimatorNodeEstimatorJetPhaEstimator*RescaleMoveCompositeTopologyNodeEstimatorJetAbsNodeEstimatorJetPhaNodeEstimatorJet1..****Graph*Edge*2Node2 **BunchNode BunchEdge BunchGraph

Anhang BAnhang BOpenInventorOpenInventor gehört zu den ältesten und meist verwendeten 3D-Bibliothekenund stellt einen großen Funktionsumfang bereit. Die Bibliothek liegt als objektorientierteC++ Implementierung im Source-Code vor und wird kontinuierlichweiter entwickelt. Sie wird in vielen wissenschaftlichen und industriellen Anwendungeneingesetzt.OpenInventor wurde ursprünglich von SGI entwickelt. Neben der Originalimplementierung,die bei Version 2.1 stehen geblieben ist, gibt es zwei weitere, dieden Funktionsumfang noch erweitern: Eine kommerzielle Version von TGS unddie Coin-Bibliothek mit dualem Lizenzmodell von Systems in Motion, die in ihrerfreien Variante in mare verwendet wird.OpenInventor bietet eine große Auswahl vordefinierter Szeneobjekte, die alsgemeinsame Schnittstelle SoNode beerben: Geometrische Grundkörper, Transformationen(wie Translation, Rotation, Skalierung), NURBS-Flächen, 2D- und3D-Text, Materialeigenschaften, Darstellungseigenschaften, Texturen und Texturmapping,Gruppierungsobjekte, Animationsobjekte, interaktive Manipulationsobjekte.Um neue VR-Objekte zu erstellen, die sich nicht aus vorhandenenSzeneobjekten zusammensetzen lassen, können durch Erweitern der eingebautenKlassen weitere Szeneobjekte mit eigenem Verhalten erzeugt werden.Szenegraph in OpenInventorDie Implementierung der Gruppierungsobjekte in OpenInventor entspricht demKompositionsmuster (vergleiche [GHJV96], Seite 213ff.): Die Container-KlasseSoGroup beerbt dieselbe abstrakte Basisklasse, die alle Szeneobjekte beerben.Anders als beim üblichen Kompositionsmuster können hier allerdings Kindobjektein beliebig vielen Elternobjekten enthalten sein. Um trotz dieser unüblichenMöglichkeit durch die Elternobjekte die Lebenszeit der Kindobjekte kontrollierenzu können, wird in SoNode ein Referenzzähler verwendet.195

Anhang BSoNode+ ref(): void+ unref(): void*SoGroup*+ addChild(child: SoNode): void+ getChild(childnum: int): SoNode+ removeChild(child: SoNode): voidKompositionsmuster in OpenInventorNodeKitDa häufig VR-Objekte erstellt werden, die sich aus vielen grundlegenden Szeneobjektenzusammensetzen, bietet OpenInventor einen Mechanismus, solchekomplexen VR-Objekte zusammenzusetzen: NodeKits erzeugen Szenesubgraphennach einem für sie eigenen Muster. Dazu erben solche Objekte vonSoBaseKit und haben dadurch die Möglichkeit, intern auf ihre Bestandteile zuzugreifen(mit den Methoden getPart und setPart) – von außen erscheinen sieaber als ein Szeneobjekt. In mare nutzen viele Klassen der Darstellungskomponentendiese Technik.DateiformatFür alle Szeneobjekte und die daraus erstellten Szenegraphen bietet OpenInventorein Dateiformat (mit der Extension ».iv«). Darüber lassen sich einzelne Szeneobjekteoder ganze Szenegraphen in ihrem aktuellen Zustand persistent speichernund wieder laden. Auch Szeneobjekte von abgeleiteten Klassen werdendurch das eingebaute Laufzeittypsystem korrekt erkannt und können so ebenfallsmit ihrem Zustand in Dateien abgelegt werden.196

Anhang BBetriebssystemanbindungZu OpenInventor gehört auch eine Sammlung von GUI-Klassen in einer eigenenBibliothek, die eine einfache Verwendung von OpenInventor in einem grafischenBetriebssystem ermöglicht. Diese Sammlung wurde auf verschiedene Plattformenportiert, so dass nur sehr wenig Aufwand entsteht, wenn eine OpenInventor-Anwendungauf eine andere Plattform übertragen wird. In mare verwendenwir die »SoQt«-Variante (GUI-Bindung an das freie GUI-Framework Qt von Trolltech),da diese unter Linux, Macintosh und Windows gleichermaßen benutzbarist.DerSoQtExaminerViewer ist eine Klasse aus dem SoQt-Paket, die als komfortablerSzenenbetrachter dient. Er stellt ein Fenster mit Werkzeugen zum Navigierendurch eine Szene dar und konvertiert Betriebssystemevents zu Inventor-Events, so dass interaktive Szeneobjekte funktionieren.SoQtExaminerViewer auf Mac OS X197

Anhang CAnhang CSzenegraphdiagrammeFolgende Symbole werden in [Wernecke94] für Szenegraphdiagramme definiertund unserer Diplomarbeit verwendet:beliebigeEigenschaftTransformationErscheinungseigenschaftTopologieBeleuchtungKameraFormSubgraphGruppeSeparatorgruppeSwitchgruppeNode KitSymbole für Szeneobjekte in SzenegraphdiagrammenSzenegraphdiagramme entstehen durch die Verbindung der obigen Symbolemit Linien, die die »Ist-Enthalten-In«-Beziehung beschreibt. Dabei sind weiteroben stehenden Symbole die Gruppenobjekte, weiter unten stehende Szeneobjektesind die enthaltenen Unterobjekte. Szeneobjekte können in Szenegraphdiagrammenmit Namen oder Typen versehen werden.Zusätzlich zu diesen aus der Literatur übernommenen Regeln für Szenegraphdiagrammegelten in dieser Arbeit folgende besonderen Regeln:– Typen von Szeneobjekten werden kursiv dargestellt.– Für Kommentare wird die in der UML verwendete Notation benutzt.– Wenn in einem Diagramm zur Vereinfachung Szeneobjekte weggelassenwerden, so ist dies durch gestrichelt gezeichnete Kanten kenntlich gemacht.198

Anhang CSzeneobjekttyp(kursiv)SoCameraSoLightSoSeparatorSzeneobjekteSzeneobjektname(nicht kursiv)PositionFarbeKoordinatenTetraederVereinfachteDarstellungdes selbenSzenegraphenSoCameraSoLightTetraederBeispielhaftes Szenegraphendiagramm (mit vereinfachter Darstellung)199

Anhang DAnhang DSzenegraphen von InteraktionskomponentenMareSceneKitblaue Darstellung:geerbte Szeneobjekteaus SoSceneKitthisschwarze Darstellung:neue Szeneobjekteaus MareSceneKitcallbackListtopSeparatorguiKitSwitchguiKitcameraListbackgroundSwitchlightListvirtualitySwitchchildListbackgroundSeparatorvirtualityrealitySwitchbackgroundrealityOverlaySwitchrealitySeparatorrealityOverlaySeparatorrealityLightModelrealityrealityOverlayDrawStylerealityOverlayBaseColorrealityOverlay200

Anhang DGuiKitGuiKitcallbackListenableSwitchtopSeparatorcameraSwitchlightsSwitchtransformcursorSwitchcameralightschildrenSwitchcursorclearBufferClearpickStylechildrenCursorKit201

Anhang DLabelLabelcallbackListenableSwitchtopSeparatortransformpanelSwitchlabelSwitchchildrenSwitchpaneldecorationlabelchildren202

Anhang DButtonButtoncallbackListtopSeparatortransformstateSwitchchildrenSwitchinactiveState overState activeStatechildren203