Berührungslose Mensch-Computer-Interaktion (HCI) im Operationssaal

Transkript

1 Berührungslose Mensch-Computer-Interaktion (HCI) im Operationssaal Microsofts Kinect im intraoperativen Einsatz Bachelorarbeit von Tolan Druckmiller und Tobias Poel Universität Bremen Internationaler hochschulübergreifender Studiengang Digitale Medien Erstprüfer: Prof. David Oswald, Hochschule Bremen Zweitprüfer: Prof. Dr. Rainer Malaka, Universität Bremen Betrieblicher Betreuer: Dr. Felix Ritter, Fraunhofer MEVIS

2 Danksagung Wir danken unserem Betreuer Dr. Felix Ritter (Fraunhofer MEVIS) herzlich für seine Unterstützung und Hilfe über den gesamten Zeitraum, in dem diese Arbeit entstand. Des Weiteren danken wir in alphabetischer Reihenfolge: Dr. Marcello Donati (Asklepios Klinik Barmbek), Christian Hansen (Fraunhofer MEVIS), Prof. Dr. Rainer Malaka (Universität Bremen), Prof. David Oswald (Hochschule Bremen). Abschließend danken wir weiteren Angestellten des Fraunhofer-MEVIS-Instituts und der Me- Vis Medical Solutions AG sowie unseren Familien und Freunden, die uns dabei unterstützt haben, diese Arbeit zu verfassen. Erklärung Wir versichern hiermit, dass wir die vorliegende Arbeit selbständig und nur unter Benutzung der angegebenen Literatur und Hilfsmittel angefertigt haben. Wörtlich übernommene Sätze oder Satzteile sind als Zitat belegt, andere Anlehnungen hinsichtlich Aussage und Umfang unter Quellenangabe kenntlich gemacht. Die Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen und ist nicht veröffentlicht. Ort, Datum Unterschrift Ort, Datum Unterschrift

3 Aufteilung der Kapitel Die Abschnitte dieser Bachelorarbeit wurden von uns einzeln bearbeitet und gemeinsam aufeinander abgestimmt. Das Einleitungskapitel 1 sowie das abschließende Kapitel 7 wurden gemeinsam verfasst. Die Aufteilung der Abschnitte haben wir wie folgt vorgenommen: Kapitel 2 Computerunterstützung in der Leberchirurgie: Bisherige Situation und State of the Art Tobias Poel Kapitel 3 Funktionale Anforderungen Tolan Druckmiller Kapitel 4 Berührungslose Gestensteuerung: Technischer und algorithmischer Hintergrund Abschnitt 4.1 Hardware: Analyse der Kamera-Aufnahmetechniken Tolan Druckmiller Abschnitt 4.2 Software: Algorithmen zur Gestenerkennung Tobias Poel Kapitel 5 Entwurf eines berührungslosen Interfaces Abschnitt 5.1 Aspekte der Gebrauchstauglichkeit Tobias Poel Abschnitt 5.2 Interface-Konzept Tolan Druckmiller Kapitel 6 Prototypische Beispielimplementierung Abschnitt 6.1 Verwendete Technologien, Frameworks, Bibliotheken Tolan Druckmiller Abschnitt 6.2 Überblick über Programmaufbau und Algorithmen Tobias Poel

4 Kurzzusammenfassung In der bildbasierten Medizin erlauben es heutzutage Softwareprogramme, Diagnosen zu stellen und in einem weiteren Schritt Interventionen vorzubereiten. Bei komplizierten Leberresektionen werden sie zum Beispiel genutzt, um Schnitte an einem 3D-Modell der Leber zu planen und den genauen Anteil der Restleber zu berechnen. Trotz fortschreitender Technologie ist es bisher nicht gelungen, dem Chirurgen eine zufriedenstellende Lösung zu bieten, mit der er die digitalen Daten im Operationssaal nutzen kann. Diese Arbeit beschäftigt sich mit der Konzeption eines Systems, das ihm die Planungsdaten zur Verfügung stellt und die speziellen Anforderungen an den Operationssaal als Anwendungskontext für HCI erfüllt. Darüber hinaus wird eine Erweiterung des Systems vorgeschlagen, die dazu dienlich ist, dem operierenden Arzt die Möglichkeit zu bieten, bei zusätzlich vorgefundenem erkranktem Gewebe, eine Änderung der Planungsdaten vorzunehmen. Die Anwendung, dessen Bedienschnittstelle eine Gestensteuerung darstellt, wird hinsichtlich funktionaler, technischer und algorithmischer Aspekte analysiert. Des Weiteren wird eine geeignete grafische Benutzerschnittstelle entworfen und die entsprechende Gesteninteraktion konzipiert. Auf dieser Grundlage erfolgt eine Beschreibung eines möglichen Einstiegspunkts, wie eine Umsetzung des Systems realisiert werden kann. Abstract Nowadays, physicians are supported by software products for vision-based medicine which simplify diagnosis and help to plan interventions. For instance for complicated hepatic operations, resection lines can be drawn and the volume of the remnant can be calculated through a virtual resection of the liver. Despite the proceedings in technology, there is no satisfactory solution yet for using the digital data in the operating room. This thesis presents a concept of an application that provides access to this planning data while complying with the special requirements during surgeries. In addition, a suggestion for an extension of the application will be made. With this extension, the surgeon can change the resection plan, if he detected additionally diseased tissue. The program is designed for the navigation via gestures and with this in mind, we will analyze it in terms of functionality, techniques and algorithms. Next to that, this thesis includes several drafts of the graphical user interface and concepts of hand gestures for human-computer interaction. Based on this, a description of how to implement the application will be given.

5 Inhaltsverzeichnis 1 Einleitung Problemstellung Inhalt und Abgrenzung Computerunterstützung in der Leberchirurgie: Bisherige Situation und State of the Art Der Operationssaal als Anwendungskontext für HCI: Formale Anforderungen an intraoperativ zu bedienende Interfaces Verschiedene Ansätze für geeignete Interfaces Funktionale Anforderungen Aufgaben aus Anwendungsbereich Visualisierung Der 2D-Inspektor Der 3D-Inspektor Legende Aufgaben aus Anwendungsbereich Aktualisierung Zusätzliche Läsionen markieren Resektionsplan anpassen Berührungslose Gestensteuerung: Technischer und algorithmischer Hintergrund Hardware: Analyse der Kamera-Aufnahmetechniken Fazit Software: Algorithmen zur Gestenerkennung Handgestenerkennung: Problemstellung und Überblick Schritt I Komplexität verringern: Erstellung von Hintergrundmasken zur Ausklammerung unwichtiger Bildbereiche

6 Inhaltsverzeichnis Schritt II Hand finden: Erkennung und Lokalisierung des Objekts Schritt IIIa Hand verfolgen und Handpositur erkennen: Tracking des gefundenen Objekts Schritt IIIb: Handmodellerstellung Schritt IV Gesten erkennen: Interpretation der festgestellten Handposituren und -bewegungen Entwurf eines berührungslosen Interfaces Aspekte der Gebrauchstauglichkeit Definition des Gestenvokabulars Empfangsbereitschaft des Systems Interface-Konzept Anwendungsszenario Konzeption der grafischen Benutzeroberfläche Konzeption der Gestensteuerung Modell Prototypische Beispielimplementierung Verwendete Technologien, Frameworks, Bibliotheken Überblick über Programmaufbau und Algorithmen Konklusion 88 A Lichttest mit der Kinect im Operationssaal 90 B Umfrage zu assoziierten Gesten 92 Literaturverzeichnis 94 6

7 1 Einleitung Bei der Planung chirurgischer Eingriffe zum Beispiel Leberresektionen werden bereits vielerorts computerunterstützte Verfahren angewandt, die es dem Chirurgen ermöglichen, an dreidimensionalen Computermodellen, die aus MRT- oder CT-Daten der Patienten erstellt wurden, präzise Operationsplanungen durchzuführen, zum Beispiel sehr genau Schnitte zu setzen. Für die computerassistierte Planung von Leberoperationen gibt es beispielsweise die Software MeVis LiverAnalyzer vom Fraunhofer MEVIS-Institut in Zusammenarbeit mit der Bremer Firma MeVis Medical Solutions AG. Mit dieser Software lässt sich bei der präoperativen Schnittplanung millilitergenau ausrechnen, wie groß der nach einer durchgeführten Resektion verbleibende Leberanteil wäre und welche Überlebenschancen sich daraus für den Patienten ergeben Problemstellung So gewonnene Erkenntnisse sind für den Chirurgen von großem Nutzen. Bei der intraoperativen Nutzung dieser Daten offenbaren sich jedoch im Wesentlichen zwei große Problemfelder. Das erste Problemfeld betrifft die Übertragung der Planungsdaten in den Operationssaal, da bisher in vielen Operationssälen noch nicht die nötige Technik zur Verfügung steht: Schlimmstenfalls verbleiben hier von den hochdetaillierten dreidimensionalen Computermodellen nur einige DIN-A4-Ausdrucke mit vorher festgelegten Ansichten. Bei dieser Art der Darstellung gehen aus zwei offensichtlichen Gründen Informationen verloren: a) Bei den Ausdrucken handelt es sich um eine festgelegte Darstellungsgröße und b) die Festlegung auf eine bestimmte Anzahl von Ansichten kann dazu führen, dass einige Bereiche überhaupt nicht einsehbar sind. Anders formuliert: Man kann in die Ausdrucke nicht hineinzoomen und die Modelle nicht rotieren. Einschränkung a) führt zu Problemen, wenn anatomische Strukturen zu klein sind, um in der ausgedruckten Form sichtbar zu sein. Die Einschränkung b) ist vor allem dann problematisch, wenn relevante Strukturen in allen verfügbaren Ansichten von anderen Strukturen überlagert werden. Das zweite Problemfeld ergibt sich, wenn sich die präoperativ akquirierten Bilddaten von den intraoperativ vorgefundenen Begebenheiten so gravierend unterscheiden, dass die Planung angepasst werden muss. Dies kann beispielsweise an der nicht unerheblichen Zeitspanne zwi- 7

8 1. Einleitung schen Planung und Durchführung einer Operation liegen oder auch daran, dass während der Operation Strukturen gefunden werden, die für die Erfassung durch die präoperativ eingesetzten bildgebenden Verfahren zu klein waren. In beiden Fällen muss sich der Chirurg zwischen den Alternativen entscheiden, die Schnittplanung ohne Computerunterstützung anzupassen was zu eventuell vermeidbaren Ungenauigkeiten führen kann oder die Operation komplett abzubrechen Inhalt und Abgrenzung Aus der beschriebenen Problemsituation ergibt sich der Bedarf, dem Chirurgen auch direkt im Operationssaal Zugriff auf die detaillierten dreidimensionalen Computermodelle zu ermöglichen. Es gibt bereits seit Längerem Ansätze, die sich mit der Umsetzung dieses Ziels befassen [72, 27]. Die besondere Schwierigkeit der Thematik ist hierbei der speziellen Einsatzumgebung des Systems geschuldet, die ganz bestimmte Anforderungen an die Bedienbarkeit vorgibt: Da der Chirurg bereits diverse Operationsinstrumente verwendet, ist es sinnvoll, ihm eine Schnittstelle zur Verfügung zu stellen, die kein weiteres Bedieninstrument verlangt. Die Tätigkeit des Chirurgen erfordert seine gesamte Aufmerksamkeit, die Bedienung der Schnittstelle muss daher nachvollziehbar und intuitiv beziehungsweise mit möglichst natürlichen, leicht zu merkenden Bewegungen erfolgen. Die Schnittstelle muss Fehlbedienung so weit wie möglich ausschließen und eine zuverlässige direkte Bedienung auch in zeitkritischen Situationen ermöglichen. Die Benutzung der Schnittstelle muss effizient sein und darf den Chirurgen niemals bei seiner primären Tätigkeit behindern. Kapitel 2 stellt ausführlich die bisherige Situation und eine Analyse des Operationssaales als Anwendungskontext für HCI sowie eine Abwägung der Eignung verschiedener Interaktionsparadigmen für diesen Kontext zusammen. Aus der Analyse leiten wir ab, dass sich eine berührungslose Bedienschnittstelle mit einer Gestensteuerung für dieses Problem anbietet. Wir schlagen den Einsatz eines 3D-Kamera-Systems vor, mit dessen Hilfe zusätzlich zum RGB-Bild ein Tiefenbild ermittelt werden kann. Kapitel 3 definiert die funktionalen Anforderungen für eine Anwendung, die eine Lösung für das oben genannte Problem darstellt. Dabei stellen wir zwei Anforderungsbereiche vor, in die die Anwendung geteilt wird. Kapitel 4 beschäftigt sich mit der Gestensteuerung in technischer und algorithmischer Hinsicht. Im ersten Teil geben wir einen Überblick über verschiedene denkbare Kameratechniken und schlagen den Einsatz eines Streifenprojektions-Scanners vor, wie beispielsweise die Ende 2010 auf den Markt gebrachte Microsoft Kinect. Im zweiten Teil des Kapitels stellen wir 8

9 1. Einleitung verschiedene für unseren Fall geeignete Ansätze zur algorithmischen Lösung des Handgestenerkennungsproblems vor und diskutieren deren Stärken und Schwächen sowie die Zukunftsperspektiven dieser Ansätze. Kapitel 5 stellt die Anforderungen an ein geeignetes User Interface zusammen sowohl im Sinne der grafischen und funktionellen Repräsentation als auch in Bezug auf verwendete Gesten. Unterschiedliche Ansätze werden analysiert und bewertet. Kapitel 6 gibt einen Einblick in Treiber-Bibliotheken und Entwicklungsumgebungen, die genutzt werden können, um eine entsprechende Applikation umzusetzen. Wir beschreiben beispielhaft für einen Teil der Anwendung eine mögliche Umsetzung. Kapitel 7 zieht ein Fazit aus der Arbeit und gibt einen Ausblick auf mögliche weitere Entwicklungen, sowie weitere Ideen für die Zukunft. 9

10 Computerunterstützung in der Leberchirurgie: Bisherige Situation und State of the Art 2 Der Erfolg von Leberresektionen hängt maßgeblich vom Volumen des nach der Operation im Körper verbleibenden funktionalen Gewebes (auch Parenchymgewebe genannt) ab. Ausgehend vom Volumen dieses Restgewebes lassen sich relativ gute Prognosen über die Überlebenschancen des Patienten treffen. Schon bei gut 20 30% erhaltenem funktionellen Lebervolumen (ca. 0,5% des Körpergewichts) kann sich die Leber, sofern sie nicht bereits vorgeschädigt ist, selbständig und vollständig regenerieren. Bei Vorbelastung durch Hepatitis, Fettleber oder auch durchlaufener Chemotherapie erhöht sich dieser Wert jedoch auf 30 60%, bei Vorbelastung durch eine Leberzirrhose gar auf 40 70% 1. Wichtig ist hierbei, dass eine ausreichende Drainage des Restparenchyms gewährleistet wird, da mindervaskularisiertes Parenchymgewebe zum einen nur eingeschränkt zur Regeneration der Leber beiträgt, zum anderen aber auch einen potenziellen Infektionsherd darstellt. Grundlage einer effektiven Schnittplanung ist also die Visualisierung sowohl des Parenchymgewebes mit etwaigen malignen Strukturen (Tumore, Metastasen, Zysten) wie auch der Gefäßsysteme, also Gallengänge und die hepatischen Arterien (HA) und Venen (HV) sowie die Portalvene (Vena portae) [39, 55]. Software wie beispielsweise MeVis LiverAnalyzer oder HepaView bieten das Erstellen einer solchen Visualisierung an. Der Chirurg erhält seine Operationsplanung an vorgefertigten dreidimensionalen virtuellen Modellen der individuellen Patientenleber, in denen die unterschiedlichen Gewebearten bereits korrekt segmentiert sind und Vorschläge für den Schnitt eingefügt wurden 2. Noch nicht in der aktuellen Version, aber zukünftig geplant ist hier beispielsweise auch eine nach bestimmten Kriterien berechnete Bewertung des Schnitts. Hierzu gehören neben dem angesprochenen Volumen des Restparenchymgewebes auch einen Sicherheitsabstand zu den Tumoren, damit dieser auch vollständig und ohne Rezidive entfernt werden kann, sowie ein Sicherheitsabstand zu wichtigen Gefäßen wie Venen, Arterien oder Gallengängen (Vermeidung von Gallengangsleckagen. Auch wird die mögliche Drainage nach dem Eingriff simuliert, 1 Angaben variieren je nach Quelle [39, 55, 57]. 2 Diese Aufgaben werden beispielsweise von Mitarbeitern der Firma MeVis Medical Solutions [46] übernommen. 10

11 2. Computerunterstützung in der Leberchirurgie: Bisherige Situation und State of the Art indem das Parenchymgewebe den entsprechenden nächstliegenden Gefäßen zugeordnet wird. Durch diese Zuordnung kann berechnet werden, wie viel Gewebe bei einem Schnitt verloren ginge. Der Chirurg sieht sich die Ergebnisse in einer abgespeckten Version des LiverAnalyzers an (LiverViewer) oder als interaktive PDF-Datei [34]. Die zu Grunde liegenden Daten stammen in der Regel aus Magnetresonanztomographie- oder Computertomographieaufnahmen (abgekürzt MRT beziehungsweise CT). Durch mehrere zeitlich aufeinander folgende MRT-Aufnahmen nach Zugabe unterschiedlicher Kontrastmittel, die jeweils andere Gewebearten hervorheben, oder entsprechend durch CT-Aufnahmen mit unterschiedlichen Strahlenstärken (Multi-Energy-CT), kann die Segmentierung der einzelnen relevanten Gewebearten erleichtert werden. Eine vollautomatische Segmentierung ist jedoch mit heutigen Methoden noch nicht möglich, sodass die CT-Daten durch Experten aufbereitet werden müssen, bevor sie vom Chirurgen in Form der fertig segmentierten 3D-Modelle für die Planung verwendet werden können. Auf lange Sicht gelangen Zachow et al. [73] zu Folge nur solche Systeme in den tatsächlichen klinischen Gebrauch, die einen tatsächlichen Bedarf des Chirurgen adressieren und einen entsprechenden Nutzen/Mehrwert gegenüber der herkömmlichen Vorgehensweise darstellen. Diese Voraussetzung gelte insbesondere, wenn mit Einsatz des Systems nicht nur eine Paradigmenerweiterung, sondern ein Paradigmenwechsel einhergehe, wovon wegen der durch das Aufbereiten der Daten zu dreidimensionalen Computermodellen auftretenden Verzögerung gegenüber der früher üblichen direkten Betrachtung am Röntgenschaukasten [11] durchaus die Rede sein kann. Bei Resektionsplanungen ergibt sich der rechtfertigende Mehrwert der Computerunterstützung aus der höheren Präzision bei der Schnittplanung und der direkten Berechnung des funktionellen Restgewebes. Da bei gewöhnlichen Leberresektionen wie oben beschrieben lediglich 20 30% des Parenchymgewebes erhalten bleiben müssen, ist dieser Aufwand jedoch nicht immer der Aufgabe angemessen: die erreichbare Präzision wird in vielen Fällen gar nicht unbedingt benötigt. Die volle Palette der oben beschriebenen Maßnahmen findet daher nur in einem Bruchteil der Fälle Anwendung, wenn der Chirurg dem kritisch zu erhaltenden Mindestvolumen gefährlich nahe kommen muss. Zu diesen Fällen gehören tendenziell eher erweiterte Links- als Rechtsresektionen. Dieses Phänomen ist nicht unmittelbar einleuchtend, da bei Linksresektionen in der Regel mehr Restgewebe übrig bleibt als bei Rechtsresektionen. Dennoch sind Linksresektionen aus diversen Gründen problematischer, beispielsweise da es hier weniger sichtbare Landmarken auf der Organoberfläche gibt. Entsprechend kommen Povoski et al. [58] in ihrer Studie zu höheren Morbiditäts- sowie Mortalitätsraten bei Linksresektionen (53% und 8%) als bei Resektionen anderer Art (40% und 4%) und auch in der Studie von Hasegawa et al. [29] sind entsprechende Tendenzen verzeichnet. Weitere Anwendungsfelder sind auf Grund ihrer Komplexität und der daraus folgenden Präzisionsanforderung Leberlebendspenden, Rezidiveingriffe (Eingriffe, bei denen nach einem bereits durchgeführten vorherigen Eingriff übrig gebliebenes malignes Gewebe entfernt werden muss) und Fälle, in denen durch eine bereits vorliegende Schwächung des Lebergewebes das benötigte Restvolumen höher ist, wie etwa bei Vorhandensein einer Zirrhose (vergleiche oben) [39]. Das für diese Arbeit hauptsächlich relevante Themenfeld ist die Übertragung der Planungsdaten auf den Operationssitus: Eine Aufgabe, die dem Operateur eine unnötig große kognitive Leistung abfordern kann, wenn er dabei nicht in irgendeiner Form technisch unterstützt wird. Da die Durchführung der Operation ohnehin schon ein hohes Maß an Aufmerksamkeit erfor- 11

12 2. Computerunterstützung in der Leberchirurgie: Bisherige Situation und State of the Art dert, ist es sinnvoll, dem Operateur durch Technikeinsatz die Belastung der Übertragung der Planungsdaten abzunehmen, was letztendlich auch zu einer erhöhten Patientensicherheit führt. Eine solche Entlastung ist zum einen durch einen komfortablen, d.h. intuitiven und robust zu bedienenden Zugriff auf die Planungsdaten innerhalb des Operationssaals und zum anderen durch aktive Computerunterstützung beim Operationsvorgang selbst möglich sowie natürlich auch durch die Kombination beider Ansätze. Eine aktive Unterstützung, also der Einsatz von klinischen Navigationssystemen, wird bereits in prototypischer Form in der Praxis angewandt [57], soll aber nicht Gegenstand dieser Arbeit sein. Wir befassen uns stattdessen mit den Möglichkeiten, dem Operateur die Planungsdaten unter Berücksichtigung der speziellen Anforderungen des Operationssaals möglichst effizient zur Verfügung zu stellen. Hier ist zwischen zwei Aufgabenfeldern zu unterscheiden: a) die Planungsdaten in einer interaktiven, d.h. explorierbaren Ansicht zur Verfügung zu stellen (im Folgenden nur als Anwendungsbereich Visualisierung bezeichnet) und b) die Planungsdaten intraoperativ zu aktualisieren (im Folgenden als Anwendungsbereich Aktualisierung bezeichnet). Aufgabenfeld b) ist in Fällen wichtig, in denen sich die intraoperativ vorgefundene Situation so stark von der der präoperativen Planung zu Grund liegenden Situation unterscheidet, dass die Planungsdaten nicht mehr ohne weitere Anpassung brauchbar sind. Das kann zum einen an dem zwischen Planung und Durchführung der Operation liegenden Zeitraum liegen und zum anderen daran, dass manche pathologische Strukturen so klein sind, dass sie mit den bildgebenden Methoden von außen nicht erkennbar waren, bei offenem Körper aber gefunden werden können (insbesondere, da intraoperativ zusätzlich die Ultraschalltechnologie angewandt wird, die zusätzliche Tumore auffindbar macht - vergleiche [62]). Nach Zachow et al. [73] ist die Vollständigkeit dieser intraoperativen Aktualisierung umso wichtiger, je näher der Operateur sich an eine kritisch zu erhaltende Mindestgröße oder -funktion des Organs heranwagen muss. Im folgenden Abschnitt sollen nun zunächst die formalen Anforderungen beleuchtet werden, die der Operationssaal als Anwendungskontext für HCI mit sich bringt, bevor dann einige verschiedene konkretere Ansätze diskutiert werden, wie die Mensch-Computer-Interaktion eines Systems für die intraoperative Bereitstellung von Operationsdaten realisiert werden kann oder werden könnte Der Operationssaal als Anwendungskontext für HCI: Formale Anforderungen an intraoperativ zu bedienende Interfaces Der Operationssaal ist ein Einsatzgebiet, das durch einige Besonderheiten sehr spezielle Anforderungen an ein gutes Mensch-Computer-Interaktionskonzept stellt. Diese ergeben sich aus räumlichen Gegebenheiten und aus der speziellen Arbeitssituation. In diesem Abschnitt werden in loser Auflistung wichtige Aspekte erläutert, die Einfluss auf das HCI-Design haben. Sterilität. Sowohl der Operateur als auch anderes Personal, das während der Operation mit dem Patienten in Kontakt kommt, müssen nach jeder Berührung mit potenziell kontaminierten Oberflächen die Handschuhe wechseln. Technische Geräte, die zur Interaktion eine Berührung der Oberfläche erfordern, müssen deswegen entweder von einem nicht direkt am invasiven Ein- 12

13 2. Computerunterstützung in der Leberchirurgie: Bisherige Situation und State of the Art griff beteiligten Assistenten bedient werden oder durch eine geeignete sterile Schutzhülle abgedeckt sein. Eine unmittelbare Desinfektion der Geräte ist wegen ihrer Beschaffenheit kaum möglich (Wischdesinfektion wegen kleiner Ecken und Kanten nicht möglich; Sprühdesinfektion verbietet sich wegen der Elektronik). Bei Benutzerschnittstellen, die keine direkte Berührung erfordern, ist auf einen Sicherheitsabstand zu sterilen Bereichen des Operationssaals zu achten (in der Praxis reicht hier meist eine Armlänge als Entfernung). Zu den sterilen Bereichen gehören der Operationstisch, alle direkt mit dem Patienten in Kontakt kommenden Operationsinstrumente und deren Lagerflächen sowie das direkt am invasiven Eingriff beteiligte OP-Personal. Zeitkritische Vorgänge. Je nach Erfahrung des verantwortlichen Chirurgen können unvorhergesehene Komplikationen den Stresspegel stark erhöhen. Dennoch ist oft gerade in diesen Situationen schnelles Handeln gefordert. Während der Operation genutzte technische Geräte müssen auch (und besonders) in solchen Situationen eine Unterstützung für den Operateur darstellen und dürfen keinesfalls als weiteres Hindernis auftreten. Der Operateur braucht seine gesamte Aufmerksamkeit für schnelle Sachentscheidungen über das weitere Vorgehen. Kompliziert zu bedienende, fehlerhafte oder zu langsam reagierende technische Geräte dürfen ihn nicht von dieser Hauptaufgabe ablenken. Dieser Grundsatz bedeutet im Konkreten, dass entsprechende Interaktionsgeräte möglichst direkt bedienbar sein sollten. Wenn der Operateur die Anweisungen, die eigentlich dem technischen Gerät gelten, erst mit einem Assistenten kommunizieren muss, der diese dann umsetzt, ist die Bedienung langsam und fehleranfällig, da zum Beispiel Anweisungen über Grad und Richtung der Rotation eines 3D-Modells schwer verbal zu kommunizieren sind. Außerdem verbieten sich aus merkbare Ladezeiten während des Einsatzes der Software, um den Arbeitsfluss nicht zu gefähreden. Aus gleichem Grund ist ein Höchstmaß an Robustheit beziehungsweise Fehlertoleranz gefordert. Mentale, psychische, kognitive, körperliche Belastung des Personals. Die Anforderung, dass der Einsatz technischer Geräte im Operationssaal, sofern sich dadurch Zeit nicht sogar einsparen lässt, nur mit einem minimalen zusätzlichen Zeitaufwand verbunden sein darf, ergibt sich nicht nur aus der geforderten Funktionstüchtigkeit in zeitkritischen Situationen, sondern auch aus der mentalen, psychischen, kognitiven sowie körperlichen Gesamtbelastung des OP- Personals. Eine umständliche Bedienung (scheinbar) simpler Funktionen führt unweigerlich dazu, dass über kurz oder lang auf den Einsatz des betreffenden technischen Geräts trotz eines theoretischen Mehrwerts verzichtet wird. Während diese Aussage allgemein auch für andere Einsatzgebiete von Benutzerschnittstellen gilt, ist dies im Operationssaal besonders gegeben, da die Arbeit im Operationsaal ein hohes Stresspotenzial aufweist: Die Arbeit ist geprägt von engen Zeitplänen, dem Umgang mit (anderen) komplexen medizinischen Geräten, hoher Aufgabenvariabilität, starken Verantwortlichkeiten und anderen Stressfaktoren [10]. Erweiterte Leberlinksresektionen wie oben beschrieben ein Haupteinsatzgebiet für die in dieser Arbeit behandelte Software dauern über mehrere Stunden (bei Povoski findet sich beispielsweise als Median der Operationsdauer ein Wert von über viereinhalb Stunden [58]). Aus dieser langen Operationsdauer ergibt sich neben der angesprochenen Belastung für das OP-Personal auch ein starke körperliche Belastung für den narkotisierten Patienten. Aber nicht nur eine Schnelligkeitsanforderung leitet sich aus dieser Situation ab, sondern auch Anforderungen an ein sehr intuitives 13

14 2. Computerunterstützung in der Leberchirurgie: Bisherige Situation und State of the Art Interaktionsmodell 3, das möglichst schnell erlernt werden kann. Der Chirurg muss sich auf sein eigentliches Ziel konzentrieren können, statt darüber nachdenken zu müssen, wie er dieses Ziel erreicht. Dies gilt insbesondere, da für die technische Schulung des OP-Personals schon jetzt vielerorts die Zeit sehr knapp bemessen ist [10, 44]. Lichtverhältnisse. Operationssäle sind in der Regel konstant elektrisch beleuchtet und nicht den Helligkeitsschwankungen des Tageslichts ausgesetzt. Besonders für Gestenerkennungsalgorithmen ist eine konstante Beleuchtung eine sehr gute Ausgangssituation. Mit nur wenigen Ausnahmen wird bei invasiven Eingriffen auf eine höchstmögliche Ausleuchtung des Raumes und besonders des Operationstisches geachtet. Dazu gibt es neben dem normalen Raumlicht meistens zwei bis drei justierbare OP-Leuchtkörper, die direkt auf die offene Körperstelle gerichtet sind und diese von einer oder mehreren Seiten ausleuchten. Dieser Umstand muss sowohl bei schwachen oder spiegelnden Computerdisplays (zum Beispiel Apple ipad), wie auch bei ToF-Kameras und Streifenprojektions-3D-Scannern (zum Beispiel Microsoft Kinect) beachtet werden. 4 Eingespielte, bereits vorhandene Paradigmen oder Verhaltensweisen. Die Bedienung von Computersystemen ist nicht das eigentliche Interesse eines Chirurgen und der vertiefte Umgang mit Computeranwendungen nicht direkt Teil der medizinischen Ausbildung [73]. Daher ist solchen Systemen der Vorzug zu geben, die sich den bereits eingespielten Praktiken von Chirurgen anpassen und ihn in diesen unterstützen. Eine ausführlichere Diskussion zu diesem Kriterium findet sich in der Einleitung zu Abschnitt 2.2. Eine Hand am Patienten. Bei einer Analyse von Leberresektionsvideos fiel auf, dass Chirurgen bei ihrer Arbeit selten beide Hände vom Patienten nehmen, die meiste Zeit über befindet sich mindestens eine Hand am Patienten, um die mobilisierte Leber zu stützen und zu fixieren. Es ergibt sich daraus, dass geeignete Interaktionsmodelle keine zweihändige Bedienung voraussetzen dürfen. Zusammenspiel mit (anderen) Operationsinstrumenten. Während die eine Hand des Chirurgen überwiegend am Patienten ist und das mobilisierte Organ stützt, führt er mit der anderen Hand OP-Instrumente. Diese sind vielfältig und zahlreich. Für den Operateur ist es deshalb wünschenswert, nicht noch ein weiteres haptisches OP-Instrument verwalten zu müssen. Dies spricht zum Beispiel für Fußpedale, Sprachsteuerung oder Gestensteuerung. Systeme, die mit Infrarotlicht arbeiten, könnten überdies zum Beispiel Wechselwirkungen untereinander haben, das betrifft unter anderem auch klinische Navigationssysteme oder 3D-Kameras, die auf Streifenprojektion basieren (siehe Abschnitt 4.1). Alle etwaigen möglichen ungewollten Wechsel- 3 Die Definition von intuitiven Benutzerschnittstellen ist nicht trivial und umfasst eine Vielzahl an Themenfeldern. Bei Hurtienne et al. [32] findet sich ein Definitionsversuch, der zu einem gemeinsamen kleinsten Nenner führen soll. Vergleiche auch den Abschnitt dieser Arbeit. 4 Die technischen Grundlagen der verschiedenen Kameratechniken werden in Abschnitt 4.1 besprochen, es kann jedoch bereits vorweggenommen werden, dass ein von uns durchgeführter Lichttest in einem Operationssaal der Asklepios-Klinik Barmbek in Hamburg zeigen konnte, dass zumindest mit Microsofts Xbox Kinect selbst bei maximaler Ausleuchtungsstufe keine Probleme zu erwarten sind. Vergleiche Appendix A. 14

15 2. Computerunterstützung in der Leberchirurgie: Bisherige Situation und State of the Art Instrumentierschwester/-pfleger Assistenzarzt Chefchirurg Springerschwester/-pfleger OP-Tisch Tisch mit Geräten, Monitoren und Zugangsschläuchen für die Anästhesie Anästhesist Instrumententisch Anästhesieschwester/-pfleger Assistenzarzt Vorhang Position 2 Position 1 Abbildung 2.1.: Skizze einer typischen Anordnung von Geräten und Personen um den Operationstisch wirkungen müssen vor dem Einsatz einer Bedienschnittstelle ausgeschlossen werden können. Eine entsprechende Studie von Høgetveit et al. [31] konnte zeigen, dass Probleme mit Interferenzen von Funksignalen (WLAN, Bluetooth, GSM/TEMS) weitgehend ausgeschlossen werden können. Platzknappheit, Positionierung des Systems. In Abbildung 2.1 ist eine typische Anordnung der Personen und Geräte während einer Leberresektion zu sehen, wie sie uns von Mitarbeitern aus der Asklepios-Klinik geschildert wurde und wie sie in von uns analysierten Leberresektionsvideos zu sehen ist. Die tatsächliche Situation ist sogar noch gedrängter als die Skizze vermuten lässt, da wichtige kleinere Geräte wie Saugmaschinen und Infusionsständer nicht berücksichtigt wurden. Es zeigt sich, dass sich für die Positionierung zusätzlicher Geräte, insbesondere im Falle zusätzlicher Monitore oder Kameras, zu denen der Chefchirurg direkten Sichtkontakt haben muss, nur wenige Möglichkeiten bieten. Eine Möglichkeit, die uns in der Asklepios-Klinik vorgeschlagen wurde und die auch Peterhans et al. [57] als optimale Position für ihr Navigationsgerät vorschlagen, befindet sich hinter dem Vorhang neben dem Anästhesisten (dies entspricht in der Skizze der eingezeichneten Position 2). Hier ist relativ viel Platz und der Bereich muss nicht steril gehalten werden (der Vorhang trennt den sterilen vom unsterilen Bereich des Operationstisches). Da bei einigen Eingriffen jedoch zusätzlich eine Anästhesieschwester oder ein Anästhesiepfleger vor Ort ist, kann auch hier der Platz begrenzt sein. Matern et al. [44] zeigen überdies, dass diese Position aus ergonomischer Sicht für einen Monitor ungeeignet ist. Ihrer Studie zu Folge ist die optimale Position direkt in Augenhöhe vor dem Chirurgen. Da dieser Bereich steril sein muss, sollten elektronische Geräte hier einen gewissen Abstand vom Operationstisch einhalten (in der Skizze entspricht dies der eingezeichneten Position 1). Jedoch könnte sich auch diese Position als problematisch erweisen, wenn Monitor und Kamera vom dem Chirurgen gegenüber stehenden Assistenzarzt verdeckt werden. Insgesamt lässt sich festhalten, dass 15

16 2. Computerunterstützung in der Leberchirurgie: Bisherige Situation und State of the Art das dichte Gedränge um den Operationstisch zu der Schlussfolgerung führt, dass die eingesetzten Empfangsgeräte der entsprechenden Benutzerschnittstellen so klein wie möglich gehalten werden müssen. Beispielsweise für raumgreifende Stereokamerasysteme wäre also unter Umständen zu wenig Platz. Verschmutzungen durch Blut, Sekrete oder ähnlichem. Leberresektionen kommen nicht ohne Verschmutzungen (mindestens der Hände des Chirurgen) mit Blut und anderen Körpersekreten aus. Bei mit Klarsichtfolie steril verpackten Touchscreens oder sonstigen Bediengeräten führt das zu einem schmieriger Flüssigkeitsfilm, der die Bedienfähigkeit beeinflussen kann. Anerkennung als medizinisches Gerät. Die Anerkennung als medizinisches Gerät muss nach der Norm EN [23] geschehen, die beispielsweise mit Ergänzungsnorm EN auch Anforderungen an die Gebrauchstauglichkeit des Systems stellt. Die einzelnen Bestimmungen sollen hier nicht durchgesprochen werden, es ist aber wichtig festzuhalten, dass vor dem tatsächlichen Einsatz im Operationssaal eine Prüfung der hier festgelegten Kriterien eingeplant werden muss. Kostenfaktoren. Auch wenn es in der Forschung sinnvoll ist, alle Alternativen durchzuprobieren, darf man nicht komplett aus dem Blick verlieren, dass die entwickelten Geräte, wenn sie tatsächlich auch kurzfristig in den klinischen Gebrauch kommen sollen, nicht die (immer geringer werdenden [10, 44]) finanziellen Möglichkeiten der Kliniken übersteigen. Kostenfaktoren sind nicht das oberste Kriterium, aber es ist durchaus sinnvoll, sich bei einer Methode Gedanken darüber zu machen, wie diese möglichst kostengünstig umgesetzt werden kann Verschiedene Ansätze für geeignete Interfaces Im präoperativen Umgang mit den Planungsdaten orientiert sich die MeVis LiverAnalyzer- Software durchgehend am sogenannten WIMP-Paradigma. Die Abkürzung WIMP steht dabei für Windows, Icons, Menus, Pointers/Pointing Devices, zu deutsch also Fenster, Symbole, Menüs, Zeiger/Zeigeinstrumente. Benutzeroberflächen, die diesem Paradigma folgen bekannte Beispiele sind die klassischen Ansichten sowohl der Apple-OSX- als auch der Microsoft- Windows-Betriebssysteme benutzen im Allgemeinen diese vier Elemente, um dem Benutzer Zugriff auf Programmfunktionen zu ermöglichen. Selbst wenn mittlerweile argumentiert wird, dass sogenannte Post-WIMP User Interfaces [19] den Arbeitsfluss stark verbessern können, ist alleine die bereits etablierte Vertrautheit, die von der momentanen Allgegenwärtigkeit der WIMP-Benutzeroberflächen herrührt, ein starkes Argument, in der präoperativen Planung auf das Erzwingen eines Paradigmenwechsels zu verzichten. Zwar sollten durchaus in Zukunft neuartige, den Arbeitsfluss verbessernde Paradigmen sinnvoll in die Benutzeroberflächen der präoperativen Planung einbezogen werden, es gibt aber Gründe, damit zu warten, bis diese der Mehrheit der Benutzer durch den Einsatz in Mainstreamprodukten bekannt geworden sind: Anwendungen zur präoperativen Leberresektionsplanung müssen und können allein auf Grund 16

17 2. Computerunterstützung in der Leberchirurgie: Bisherige Situation und State of the Art der relativen Seltenheit ihrer Nutzung und geringen Verbreitung in dieser Hinsicht keine Vorreiter sein, da mit unbekannten neuartigen Eingabemethoden auch eine Einarbeitungszeit einhergeht, die man einem Chirurgen nur mit Bedacht zumuten sollte 5. Im intraoperativen Anwendungsbereich hingegen gibt es durchaus gute Argumente, auch ungewöhnliche Interaktionsparadigmen einzuführen, da die entstehenden Vorteile in diesem Fall die angesprochenen potenziellen Nachteile der erhöhten Einarbeitungszeit oder Umgewöhnung weit übertreffen können. Eine Abwägung der individuellen Vor- und Nachteile einzelner Ansätze soll in diesem Abschnitt erfolgen. Tastatur/Maus-Bedienung mit Assistenten auf Zuruf. Selbstverständlich ist es denkbar, die präoperativ eingesetzte Benutzeroberfläche unverändert auch intraoperativ zu nutzen. Diese Nutzung könnte mit Hilfe eines Assistenten durchgeführt werden, der die Kommandos des Operateurs am Computer sitzend ausführt. Die Vorteile wären ganz klar, dass sich keiner der beteiligten Personen auf eine neue Benutzeroberfläche einstellen müsste. Alles sieht aus und verhält sich wie gewohnt. Eine solche indirekte Nutzung verlangsamt den Prozess jedoch zwangsläufig erheblich, da der Operateur alle Aktionen, die auf dem Bildschirm geschehen sollen, zunächst klar formulieren und verbal kommunizieren muss, bevor der Assistent diese interpretieren und ausführen kann. Besonders bei genauen Längen- oder Richtungsangaben (und hier insbesondere bei räumlichen Angaben der Drehrichtung) fällt es dem Menschen allgemein sehr schwer, diese präzise und eindeutig verbal auszudrücken. Missverständnisse zwischen Operateur und Assistenten sind vorprogrammiert. Darüber hinaus ist ein zusätzlicher Assistent auch ein erheblicher Kostenfaktor (vergleiche auch den Diskussionsteil in [6]). Touchscreens, Touchpads, Tablet-Computer. Eine Alternative wären steril verpackte Touchscreens, freistehende Touchpads (Beispiel: Apples Magic Trackpad, das über Bluetooth verbunden wird) oder Tablet-Computer (Beispiele: Android-Tablets oder Apples ipad), die als Eingabegerät dienen. Hier ließen sich sowohl Benutzeroberflächen, die nach reinem WIMP-Prinzip aufgebaut sind, als auch multitouchoptimierte GUIs (englisch: Graphical User Interface), die unter anderem Fingergesten unterstützen können, realisieren. Touchscreens werden bereits zur intraoperativen Bedienung klinischer Navigationsgeräte eingesetzt [57]. Der Touchscreen kann zwar mit Hilfe von Plastiktüten sehr leicht steril verpackt werden, der auf der Plastikfolie entstehende Flüssigkeitsfilm (Blut und andere Sekrete), hindert jedoch ebenso wie bei Tablet-Computern die Sicht und führt zu einer unpräziseren, fehleranfälligeren Bedienung. Letzteres gilt auch für Touchpads wie die über Bluetooth verbundenen batteriebetriebenen Magic Trackpads von Apple: Ein kurzer Test mit einem solchen Gerät zeigte zwar, dass die Plastikfolie die Bedienung nicht besonders störend beeinflusste, Flüssig- 5 Momentan machen beispielsweise viele Menschen Erfahrung mit der Verwendung von Fingergesten, da diese immer häufiger in technischen Alltagsgeräten eingesetzt werden (wie zum Beispiel in Mobiltelefonen und Tablets, die Betriebssysteme wie Android, Windows Phone 7 oder ios einsetzen, sowie auf immer mehr Laptops mit Trackpad -Eingabeflächen). Das kann dazu führen, dass diese in Zukunft als bekannt vorausgesetzt und damit auch im Bereich der präoperativen Planung Verwendung finden können. Solange dies aber noch nicht mit Sicherheit gesagt werden kann, ist es vermutlich besser, dem Benutzer im präoperativen Planungsbereich nur bekannte Interaktionsparadigmen zuzumuten. 17

18 2. Computerunterstützung in der Leberchirurgie: Bisherige Situation und State of the Art keiten auf der Folie führten jedoch zu ungewollten sehr störenden Effekten. Ähnliche Ergebnisse ergaben Tests mit Ipod Touchs, iphones und ipads. Sonstige Funk/Bluetooth-Bediengeräte. Ritter et al. [62] sowie Wilkens [72] stellen ein (und dasselbe) Interface zur Anzeige von Planungsdaten von Leberresektionen vor, das mit Hilfe der WiiMote von Nintendo funktioniert. Die WiiMote wird dabei ebenfalls aus Sterilitätsgründen in einer Plastiktüte untergebracht, wodurch Einbußen bestimmter WiiMote-Funktionen auftreten. Beispielsweise konnte der Knopf an der Rückseite des Eingabegeräts nicht bedient werden und durfte deshalb nicht belegt werden. Darüber hinaus handelt es sich bei der WiiMote um ein weiteres Instrument, das der Chirurg zur Bedienung in die Hand nehmen muss, was wir wie vorher besprochen vermeiden wollen. Fußpedale. Bei Allaf et al. [6] findet sich ein Vergleich zweier Interfacevarianten zur Bedienung eines intraoperativ eingesetzten Robotersystems. Die eine Variante arbeitet mit einer Sprachsteuerung (siehe folgenden Absatz), die andere, weiter verbreitete, basiert auf Fußpedalen. Das Fußpedalsystem, das von den Chirurgen grundsätzlich gut angenommen wurde, bietet den Vorteil, dass der Chrirurg beide Hände für seine eigentliche Tätigkeit zur Verfügung hat, jedoch ist eine Fußsteuerung für komplexe Bedienungen tendenziell ungeeignet, da viele unterschiedliche Funktionen entweder zu viele verschiedene Fußpedale oder zu komplizierte Befehlskombinationen nach sich ziehen [62]. Allaf et al. kommen in ihrer Evaluation des Systems außerdem zu dem Ergebnis, dass Operateure während der Operation häufig unter den Tisch blicken mussten, um ihre Füße neu in Position zu bringen. Dies lenkt den Chirurgen unnötig ab, was wie im vorherigen Abschnitt beschrieben unbedingt vermieden werden soll. Nichtsdestotrotz kann eine Fußpedalbedienungsschnittstelle sehr effektiv und schnell sein, ist jedoch nicht für Präzisionsaufgaben geeignet. Sprachsteuerung. Die Sprachsteuerung, die in der Studie von Allaf et al. untersucht wurde, erlaubte den Probanden zwar eine präzise Bedienung, war jedoch sehr langsam, da für jede Aktion ein Sprachbefehl ausgesprochen und interpretiert werden musste. Für einige Aktionen musste ein und derselbe Befehl mehrmals hintereinander ausgesprochen werden. Außerdem kam es vermehrt zu Fehlinterpretationen der ausgesprochenen Sprachbefehle. Solche Fehlbedienungen führen nicht nur zu einer sehr langsamen Bedienbarkeit, sondern können auch ein Sicherheitsrisiko darstellen. Ein weiterer Nachteil ergibt sich aus einer erhöhten Einarbeitungszeit in das System, da zumindest das von Allaf et al. eingesetzte Interface eine relativ lange Trainingsphase voraussetzte, in der die Probanden bestimmte Wörter einsprechen mussten, damit das System sich an die Stimme gewöhnen kann. Auch wenn Spracherkennungsalgorithmen heute auf einem besseren Stand als noch vor dreizehn Jahren sind, bleibt die zuverlässige Erkennung von Sprachbefehlen besonders in einer lauten Umgebung wie dem Operationssaal ein nicht triviales Problem. Berührungslose Handgestensteuerung. Interfacevarianten, die auf berührungsloser Gestensteuerung basieren, arbeiten mit Hilfe von 2D- oder 3D-Gestenerkennung. Zu unterscheiden ist, ob die Systeme nur die gezeigten Gesten interpretieren oder auch die Position der Hand im 18

19 2. Computerunterstützung in der Leberchirurgie: Bisherige Situation und State of the Art Raum berechnen. Letzteres geschieht beispielsweise in den beiden Systemen, die von Chojecki et al. [18] und von Penne und Leiner [56] beschrieben werden. Beide Systeme simulieren einen Touchscreen ohne tatsächliche Berührung des Bildschirms. Bei diesen Interfaces handelt es sich um WIMP-basierte Interfaces, bei denen lediglich das Pointing Device beziehungsweise Zeigeinstrument durch eine aktive Erkennung von Handgesten substituiert wird. Der vermeintliche Vorteil, bei einer solchen Steuerung das auch in der präoperativen Planung eingesetzte bekannte Interface beibehalten zu können, greift jedoch nicht, da diese Interfaces meist nicht aus größerer Entfernung funktionieren, auf die sie nicht ausgelegt sind. Schrift- und Schaltflächengrößen sind auf eine Bedienung per Maus von einer Person, die direkt vor dem Monitor sitzt, ausgerichtet. Wie von Penne und Leiner gezeigt wird, sind kleine Schaltflächen mit der Gestensteuerung jedoch sehr schwer zu treffen. Daraus ergibt sich, dass auch bei Einsatz solcher Interfacekonzepte die GUI angepasst werden müsste, wenn auch das Interfaceparadigma zumindest gleich bliebe. Neben einer Anpassung der GUI innerhalb des WIMP-Paradigmas wäre jedoch auch der Einsatz eines komplett anderen Paradigmas denkbar, sofern dieses deutliche Vorteile bietet (siehe die Diskussion in der Einleitung dieses Abschnitts). Ein entsprechender Ansatz kann darauf basieren, Gesten unabhängig von der Position der Hand im Raum beziehungsweise der Position der Hand in Bezug auf Monitor oder Kamera interpretieren zu lassen. Dieser Ansatz wird von der Beobachtung gestützt, dass beim Einsatz von WIMP-Interfaces mit Bedienung durch einen Assistenten (siehe oben), die Kommandos des Operateurs an den Assistenten häufig ohnehin schon unwillkürlich durch Gesten unterstützt werden, beispielsweise Rotationsgesten, um die Rotationsrichtung zu verdeutlichen. Es erscheint also nur folgerichtig, diese Gesten direkt von einem Computersystem interpretieren zu lassen. Technisch ist diese Aufgabe sowohl mit 2D-Kameras, als auch mit 3D-Kameras lösbar, wobei wir unter Vorgabe, ein möglichst robustes System zu entwickeln, die Nutzung der zusätzlichen Tiefenbildinformationen eines 3D-Kamerasystems vorschlagen. Es sollte außerdem darauf geachtet werden, dass die dafür eingesetzten Kameras möglichst klein und kostengünstig ausfallen. Dieser Thematik widmen wir uns in einem späteren Teil der Arbeit ausführlicher (siehe Abschnitt 4.1). Die Algorithmen zur Handgestenerkennung an sich sind ein großes Feld, dem wir uns in dieser Arbeit ebenfalls noch ausführlicher widmen werden (Abschnitt 4.2). Allgemein lässt sich jedoch bereits festhalten, dass Algorithmen, die beispielsweise die farbliche Kennzeichnung der Finger mittels Klebestreifen oder bunten Fingerhüten erfordern, auf Grund der Inkompatibilität mit der primären Aufgabe des Chirurgen im intraoperativen Bereich ungeeignet sind. Aus demselben Grund kommen Systeme, für die spezielle Sensorik-Handschuhe oder ähnliche Hilfsmittel benötigt werden, in unserem Fall nicht in Frage. Als bestes berührungsloses Gestensteuerungssystem schlagen wir also eines auf reiner Computer-Vision-Basis vor, das Gesten einer unpräparierten Hand (beziehungsweise einer Hand in Operationshandschuhen) allein mit Hilfe der aufgenommenen Kamerabilder erkennen und interpretieren kann. Nach Abwägung der Vor- und Nachteile der einzelnen Interaktionsparadigmen kommen wir also, wie sich im letzten Absatz bereits deutlich angekündigt hat, zu dem Ergebnis, dass für die intraoperative Visualisierung und Aktualisierung von Leberresektionsplanungsdaten ein auf berührungsloser Handgestensteuerung basierendes System am besten geeignet erscheint, das 19

20 2. Computerunterstützung in der Leberchirurgie: Bisherige Situation und State of the Art sich nicht auf das WIMP-Paradigma beschränkt, sondern unter anderem auch Gebrauch von der Erkennung von ohnehin schon unbewusst oder unwillkürlich verwendeten Gesten macht. Bevor wir uns jedoch in Kapitel 4 konkreter und ausführlicher mit dieser Thematik beschäftigen, ist es im Sinne einer optimal zugeschnittenen Lösung angebracht, zunächst die funktionalen Anforderungen einer entsprechenden Anwendung zu definieren. Dies soll im nun folgenden Kapitel 3 geschehen. 20

21 3 Funktionale Anforderungen an eine Software zur intraoperativen Nutzung und Manipulation von Operationsplanungsdaten Wie in Kapitel 2 beschrieben, wird die computerunterstützte Planung eines chirurgischen Eingriffs bereits für komplexe Leberresektionen angewendet. Ein Softwaresystem zur Visualisierung tomographischer Bilder und zur präoperativen Planung von Leberresektionen ist beispielsweise der MeVis LiverAnalyzer. Viele Informationen aus diesem Kapitel sind der Dokumentation des MeVis LiverAnalyzers entnommen. Sie ist öffentlich nicht zugänglich, jedoch die einzige Quelle, auf die wir uns hier beziehen können [48]. Der MeVis LiverAnalyzer erlaubt zunächst die Segmentierung zusammengehöriger Äste des Lebergefäßsystems, der Läsion (gegebenenfalls auch mehrerer Läsionen) und der Leber. In einem weiteren Schritt wird daraus ein dreidimensionales Modell der Leber berechnet, in dem abhängig vom Gefäßsystem verschiedene Territorieneinteilungen kalkuliert werden. Nebst den Territorien wird auch eine Risikoanalyse erstellt. Sie markiert abhängig von der Position das Läsionen diejenigen Bereiche der Leber, die je nachdem, welcher Abstand bei einem Resektionsschnitt eingehalten wird, nicht mehr genügend versorgt werden. Da die Gefäße in der Leber und die Form der Leber bei jedem Menschen stark variieren, muss dies individuell für jeden Patienten geschehen. In das dreidimensionale Modell der Leber können Resektionsebenen eingezeichnet werden, die die Leber in Restleber und Resektat teilen. Dadurch ist es möglich, genaue Volumina der eingeteilten Bereiche zu erhalten und des weiteren, eine ausreichende Drainage nach der Operation einzuplanen. [48] Die Herausforderung ist es nun, die Planungsdaten, die mit Hilfe des MeVis LiverAnalyzers gewonnen wurden, dem operierenden Arzt zur Verfügung zu stellen. Hier ist es zunächst wichtig, dass er sich die 2D- und 3D-Bilddaten ein weiteres Mal ansehen und sich den geplanten Schnitt in Erinnerung rufen kann. Zur Erweiterung der Anwendung soll er bei intraoperativ zusätzlich vorgefundenem erkrankten Gewebe eine Aktualisierung seiner Planungsdaten vornehmen können. Hauptteil dieser Arbeit soll zunächst der Visualisierungsbereich sein, der gleichzeitig die 21

22 3. Funktionale Anforderungen Grundlage für die Anwendung darstellt. Er kann in einem weiteren Schritt um den Aktualisierungsbereich erweitert werden. Die Inhalte beider Bereiche sowie die darin nutzbaren Werkzeuge sollen im Folgenden erklärt werden Aufgaben aus Anwendungsbereich Visualisierung Der Visualisierungsbereich soll dem operierenden Arzt die Möglichkeit bieten, die Planungsdaten während der Operation ein weiteres Mal zu betrachten. Dabei sollen zum einen die mit Hilfe tomographischer Geräte aufgenommene Schnittbilder visualisiert werden. Zum anderen soll das im MeVis LiverAnalyzer berechnete 3D-Modell dem Arzt zur Verfügung gestellt werden. Die Darstellung der einzelnen Schnittbilder sollen in der Anwendung im sogenannten 2D-Inspektor wiedergegeben werden. Entsprechend soll es für das 3D-Modell den 3D-Inspektor geben. Das 3D-Modell kann je nachdem, was für den Chirurgen zur Durchführung der Operation wichtig ist, in seiner Darstellung variieren. Die Variation resultiert daraus, dass es für den Arzt von großem Nutzen ist, Gefäße und deren Territorien auszuwählen, sodass sie im 3D-Modell angezeigt werden, beziehungsweise die für ihn unwichtigen oder sichtverdeckenden Gefäße auszublenden. Dies soll über eine Auswahl geschehen, die es ermöglichen soll die Anzeige im 3D-Inspektor zu verändern. Die Auswahl der Anzeige soll des Weiteren auch die 3D-Darstellung des geplanten Resektionsschnitts und die Risikoanalyse der gefährdeten Bereiche einblenden können. Um die Leber, die Lebergefäßsysteme, die Territorien und die Läsionen voneinander zu unterscheiden ist es notwendig, sie durch verschiedene Farben zu kennzeichnen. Eine Legende soll dem Benutzer helfen, die farblich markierten Territorien zu identifizieren und sich einen Überblick über die jeweiligen Volumina zu verschaffen Der 2D-Inspektor Der 2D-Inspektor gibt die Schnittbilder der vorwiegend durch Computertomographie oder Magnetresonanztomographie gewonnen Bilddaten wieder. Er ist für den Chirurgen von hoher Bedeutung, da kleinste Details durch die unterschiedliche Graustufen sichtbar werden. Des Weiteren visualisiert er auch umliegende Strukturen, die der operierende Arzt am offenen Körper im besten Fall wiedererkennen kann [30]. In der 2D-Visualisierung lässt sich im Gegensatz zur 3D-Visualisierung die genaue Position eines Objektes, das von Interesse ist, bestimmen. Die folgenden Funktionen soll der 2D-Inspektor erfüllen: Ansicht. Eine Folge von Schnittbildern gibt den Bilddaten einen 3D-artigen Charakter, sodass Bildebenen mit beliebiger Orientierung berechnet werden können. Meist genügt es schon, dem Benutzer die drei orthogonal zueinander stehenden Ebenen zur Verfügung zu stellen. [34] Axialebene: horizontaler Schnitt, der den Körper in oberen und unteren Teil trennt. Sagittalebene: vertikaler Schnitt, der den Körper in linken und rechten Teil trennt. Coronarebene: vertikaler Schnitt, der den Körper in vorderen und hinteren Teil trennt. 22

23 3. Funktionale Anforderungen Durchblättern. In allen drei soeben beschriebenen Ansichten soll es möglich sein, durch die Schichten hindurchzublättern (englisch: to slice), sofern es sich um Schnittbildfolgen von mindestens drei Tiefendimensionen handelt. Zu beachten ist, dass auch vierdimensionale Datensätze vorkommen können, wobei es sich bei der vierten Dimension um die Zeit handelt. Vorstellbar wäre also auch ein Blättern durch unterschiedliche Zeitpunkte. Bei solchen Datensätzen handelt es sich um 4D-MRT-Aufnahmen, die meist nur Verwendung in der Kardiologie finden. Bei der Diagnose von Lebererkrankungen werden sie nur selten eingesetzt, sodass die 4D-MRT- Aufnahmen für unsere Arbeit nicht relevant sind. Transformationen. Zu den Transformationsfunktionen zählen das Vergrößern beziehungsweise das Verkleinern (zoom) des Schnittbildes sowie das Verschieben (move). Eine weitere Eigenschaft zur Navigation ist das Zurücksetzen (reset), was bewirkt, dass die Schnittbilder wieder in ihrer Ausgangsposition dargestellt werden. Dies entspricht bei tomografischen Leberaufnahmen häufig einer axialen Darstellung in einer vordefinierten Schicht. Das Bild ist dann so arrangiert, dass es mittig positioniert ist und komplett wiedergegeben wird. Fensterungstechnik. Die Fensterungstechnik wird häufig bei Bildern mit einem hohen Informationsgehalt angewendet, so auch typischerweise bei CT- oder MRT-Schnittbildern [40]. Diese verfügen über bis zu Signalwerte (12 Bit-Darstellung), die in Graustufen dargestellt werden. Diese Anzahl an Graustufen kann weder vom menschlichen Auge erfasst noch von Monitoren dargestellt werden. Deshalb ist es sinnvoll die Signalwerte, die zur Veranschaulichung auf einem linearen Graphen abgebildet sind, auf einen bestimmten Bereich zu beschränken. Dieser Bereich wird Fenster genannt und wird durch die gegebene Position und Breite definiert [30]. Alle Signale, die unterhalb dieses Fensters liegen, bekommen den Wert 0 also schwarz und alle, die oberhalb des Fensters liegen, den Wert 255 also weiß [40]. Das bedeutet, dass in Kauf genommen werden muss, dass Gewebearten mit Signalwerten oberhalb und unterhalb des Fensters nicht mehr erkennbar dargestellt werden. Dafür ist jedoch der ausgewählte Bereich detaillierter. Daraus ergibt sich: Je größer das Fenster, desto größer der Bereich abgedeckter Werte, aber auch desto weniger Details und umgekehrt. Die Abbildungen 3.1 und 3.2 veranschaulichen unterschiedliche Einstellungen der Fensterung. Ein größeres Fenster bewirkt, dass die Aufnahme weniger kontrastreich ist und mehr Bereiche des MRT-Bildes abdeckt, ein kleineres Fenster sorgt für mehr Kontraste in der Aufnahme und somit werden beispielsweise Gefäßverläufe sichtbarer. Weitere Werkzeuge. Eine Reihe an Werkzeugen sind noch zusätzlich im 2D-Inspektor des MeVis LiverAnalyzers [48] umgesetzt. Wir wollen diese zwar vorstellen, jedoch halten wir sie nicht für unabdingbar im intraoperativen Gebrauch. Ihre Funktionen und die Begründung, warum wir sie in der Anwendung nicht benutzen wollen, sollen hier aber trotzdem erläutert werden. Die farblich markierten Strukturen, die sich aus der Berechnung des 3D-Modells ergeben, sind im 2D-Inspektor analog dargestellt. Sie sind hilfreich um eine Orientierung zwischen 23

24 3. Funktionale Anforderungen Abbildung 3.1.: MRT-Aufnahme mit Postion c=500 und Breite w=1000; Die 255 Graustufen des Bildschirms sind auf 1000 Signalwerte verteilt, wodurch Details verloren gehen. (Abbildung erstellt in Me- VisLab nach Hastreiter et al. [30]) Abbildung 3.2.: Gleiche Aufnahme mit c=250 und w=500; Die Graustufen sind nun auf 500 Werte verteilt. Kontraste sind dadurch höher und Details werden deutlicher, jedoch v.a. in den hellen Bereichen gehen Informationen verloren. (Abbildung erstellt in MeVisLab nach Hastreiter et al. [30]) 24

25 3. Funktionale Anforderungen dem 2D- und dem 3D-Inspektor zu gewinnen. Die verschiedenen Bereiche der Leber werden im 2D-Inspektor durch transparente Überlagerungen auf dem tomographischen Bild dargestellt und können nach Belieben wieder ausgeblendet werden, um den Originaldatensatz in Graustufen anzuzeigen. Wir halten diese Funktion zwar für sehr wichtig, gehen jedoch davon aus, dass der Chirurg bereits genügend Vorwissen hat, um sich an den Landmarken zu orientieren. Annotationen erlauben es, unter anderem Längen und Winkel abzumessen. Auch Textannotationen können für den Arzt eine wichtige Hilfe sein, damit der Arzt sich Notizen machen kann. Intraoperativ werden diese Annotationen aber kaum notwendig sein, da der Arzt beispielsweise die Größe des Tumors schon im Vorfeld abgemessen haben wird und nun bei offenem Körper die reale Ausdehnung des Tumors vorliegt. Die Punktselektion ermöglicht es einen Punkt in den 2D-Schichten zu markieren, der dann entsprechend im 3D-Modell wiedergefunden werden kann. Dies ist eine wichtige Orientierungshilfe, die aber inmitten einer Operation auch weniger eingesetzt wird, da es hier mehr um die bildliche Darstellung der gesamten Leber geht als um einen bestimmten Punkt auf der Leber Der 3D-Inspektor Das generierte 3D-Modell wird im 3D-Inspektor dargestellt. Die segmentierten Strukturen, also die Leber, die Läsion(en), die Gefäße und die daraus resultierenden Territorien sind farblich voneinander getrennt und werden durch unterschiedliche Transparenzen abgebildet, damit sie sich nicht gegenseitig verdecken. In diesem Bereich der Visualisierung soll der Arzt im ersten Schritt auswählen können, was im 3D-Modell angezeigt wird und es jederzeit ändern können, falls er eine andere Ansicht benötigt. Die Auswahl erfolgt üblicherweise (nach Kjen Wilkens Analyse [72]) unter zwölf vorgegebenen Modellen, die die Risikoanalyse, den Resektionsschnitt und verschiedene Kombinationen der Gefäße, die Anzeige der jeweiligen Territorien und des Tumors beinhalten. Die dreidimensionale Visualisierung hat besonders bei Resektionen von Tumoren eine wichtige Bedeutung, da sie zum Beispiel Gefäßverläufe und die Ausdehnung der pathologischen Struktur räumlich genau darstellen kann [38]. Einige nützliche Werkzeuge im 3D-Inspektor überschneiden sich teilweise mit denen des 2D-Inspektors. Andere sind für das generierte 3D- Modell unbrauchbar, wie beispielsweise die Fensterung. Dafür müssen an anderer Stelle wieder Werkzeuge hinzugefügt werden. Ansicht. Die in Abschnitt beschriebenen vordefinierten Ansichten (Axial-, Sagittal- und Coronarebene) sollen auch im 3D-Inspektor zur Verfügung stehen. Transformationen. Im 3D-Inspektor zählen wie im 2D-Inspektor das Skalieren, das Verschieben und das Zurücksetzen zu den Navigationsmöglichkeiten. Zusätzlich soll eine interaktive Rotation als weiteres Werkzeug geschaffen werden, bei der der Benutzer nach Belieben das 3D-Modell der Leber drehen und von allen Seiten betrachten kann. 25

26 3. Funktionale Anforderungen Auswahl der Anzeige. Die Auswahl der Anzeige hilft bei der Selektion, was im 3D-Inspektor dargestellt wird. Da das Lebergefäßsystem in unterschiedliche Gefäßarten geteilt ist, kann die dreidimensionale Darstellung schnell unübersichtlich werden. Es empfiehlt sich also, einige Gefäße auszublenden, wenn sie zu einem bestimmten Zeitpunkt von geringerer Bedeutung sind. Über die Auswahl der Anzeige soll es auch möglich sein, die Resektionsplanung ein- und auszublenden. Da sich der Arzt an bestimmten Landmarken auf der Leber orientiert, vereinfacht eine Rekapitulation des geplanten Schnittes durch die digitale Visualisierung das Wiedererkennen dieser Landmarken auf der echten Leber. Die Planung einer Leberresektion erlaubt es, die arterielle und portalvenöse Versorgung, wenn nötig, schon im Vorfeld zu kalkulieren [48]. Diese Kalkulation nennt sich Risikoanalyse und kann auch im dreidimensionalen Modell visualisiert werden. Dies ist wichtig, wenn das Einlegen von Drainagen nach der Operation von Nöten ist. Al Issawi bedachte in ihrer Arbeit, dass es mehr als 30 verschiedene Modelle geben könne, zwischen denen der Benutzer wählen muss [34]. Während Wilkens sich in seiner Arbeit auf 23 verschiedene Ansichten beschränkte. In seiner Evaluation jedoch beschrieb er, dass eine Auswahl zwischen zwölf verschiedenen Modellen genügen würde [72]. Wir möchten uns in dieser Arbeit nicht darauf konzentrieren, welche Modelle für den Chirurgen in einer intraoperativ genutzten Anwendung wichtig beziehungsweise unwichtig sind und übernehmen die Schlussfolgerung, die Wilkens in seiner Arbeit ableiten konnte. Weitere Werkzeuge. Wie im 2D-Inspektor gibt es auch hier weitere Werkzeuge im MeVis LiverAnalyzer [48], um die sich unsere Anwendung erweitern lässt, die wir aber zu diesem Zeitpunkt nicht für notwendig halten. Wie im 2D-Inspektor kann man auch im 3D-Modell einzelne Punkte selektieren, was aus den angeführten Gründen für unsere Anwendung keine Verwendung findet. Im 3D- Inspektor kommt zudem die Schwierigkeit hinzu, dass ein Punkt auf einem 3D-Modell nur sehr ungenau auf einem Bildschirm selektiert werden kann. Die Objektselektion erlaubt es, die verschiedenfarbigen Bereiche auf der Leber auszuwählen und in der Legende wiederzufinden. Es ist vor allem dann notwendig, wenn sich die Bereiche farblich nicht genug voneinander unterscheiden. Da aber die Darstellung nur auf bestimmte Farben reduziert ist, die so ausgewählt sind, dass sie unterscheidbar sind, kann dieses Werkzeug für unsere Applikation vernachlässigt werden. Räder für Rotation in x- und y-richtung sind im LiverAnalyzer eine wichtige Funktion um das 3D-Modell der Leber in horizontaler oder vertikaler Richtung zu kippen. Wir werden sie allerdings in unserer Anwendung nicht nutzen, da sie zusätzlichen Aufwand darstellen und durch das interaktive Rotieren ersetzt werden können Legende Die Legende enthält neben den Farberklärungen für die farblich unterschiedlich markierten Territorien weitere Informationen, wie den jeweiligen Namen und die absolute sowie die relative 26

27 3. Funktionale Anforderungen Volumenangabe. Die Namen bestimmen sich nach der Anatomie beziehungsweise der Funktionalität [48]. Die absolute Volumenangabe wird in Millilitern angegeben und die relative prozentual berechnet in Relation zur gesamten Leber. Somit können auch Informationen über die Ausdehnung der Restleber und des Resektats gewonnen werden Aufgaben aus Anwendungsbereich Aktualisierung Schnitt bearbeiten Ebenen verschieben Resektionsplan erstellen zusätzlich gefundene Läsion Läsion einzeichnen Anzeige auswählen OR Schnitt löschen Resektionsebenen berechnen OR AND Ebenen verformen Volumina berechnen Schnitt setzen Abbildung 3.3.: Schritte zur Anpassung des Resektionsplans Der Aktualisierungsbereich ist vor allem dann notwendig, wenn die intraoperativ vorgefundene Situation stark von der präoperativen abweicht. Dies ist meist dann der Fall, wenn sich die Läsion unverkennbar verändert hat, was in dem Zeitraum, der zwischen den Aufnahmen und der Operation vergangen ist, durchaus geschehen kann. Ein weiterer Grund für eine Anpassung der Operationsplanung können zusätzlich vorgefundene pathologische Strukturen sein, die bei den Planungsdaten nicht gefunden werden konnten, da sie zu klein oder von anderen Strukturen verdeckt waren, sodass sie vom Computertomographen oder Magnetresonanztomographen nicht erfasst wurden. Zusätzliche Läsionen können bei Leberresektionen zum einen durch Tasten und Sehen gefunden werden, zum anderen wird bei der Leber auch häufig die Sonographie (Ultraschall) genutzt 1, um Gefäße und eingesetzte Instrumente zu erfassen. Die Sonographie ermöglicht zusätzlich das Auffinden kleinster pathologischer Strukturen und somit auch weiterer Läsionen [11]. In diesen Fällen muss sich der Arzt bisher entscheiden, ob er die Operation abbricht und nach weiteren Untersuchungen fortführt oder ob er ohne vorige Planung weiteroperiert. Beides kann zu zusätzlichen unnötigen Belastungen und Risiken sowohl für den Patienten als auch für den Arzt führen. Deshalb wäre es sinnvoll die Anwendung um den Aktualisierungsbereich zu erweitern, sodass der Arzt die Planung der Resektion intraoperativ verändern, seine Schnitte neu wählen und somit einen weniger risikobehafteten Eingriff planen kann. Abbildung 3.3 verdeutlicht die Schritte, die zu einer Anpassung des Resektionsschnittes führen. Hierfür muss die zusätzlich gefundene Läsion zunächst lokalisiert werden, um daraufhin den geplanten Resektionsschnitt zu verändern oder neu zu definieren. Die einzelnen Schritte sollen im Folgenden erläutert werden und somit die Aufgaben des Anwendungsbereichs Aktualisierung aufdecken. 1 Auch optische oder elektromagnetische Lokalisierungssysteme wie CT, MRT oder Fluoroskopie werden genutzt, sind aber sehr kostspielig und daher selten. 27

28 3. Funktionale Anforderungen Zusätzliche Läsionen markieren Die navigationsunterstützte Leberresektion ermöglicht es, Zeigeinstrumente durch die Technik der Sonographie zu orten und zu registrieren. Dies erleichtert die Navigation und Orientierung auf der Leber, da so das vorgefundene Gefäßsystem mit der präoperativen Bildgebung abgeglichen werden kann. Somit kann die Lage einer zusätzlich gefundenen pathologischen Struktur ermittelt werden und mit den Planungsdaten abgeglichen werden, selbst wenn die Leber womöglich mobilisiert oder gelagert wurde [11]. Möchte der Arzt nun seine Planungsdaten anpassen, soll er zunächst die gefundene Läsion in das 3D-Modell einzeichnen dürfen. Dies soll durch eine Kugel dargestellt werden, die in ihrer Größe variiert, sodass sie ungefähr mit der Größe der gefundenen Läsion übereinstimmt. Das Einzeichnen dieser Kugel soll sowohl im 2D-Inpektor als auch im 3D-Inspektor möglich sein. Für den 2D-Inspektor muss man bis zu der ermittelten Schicht blättern und an die gewünschte Stelle die Kugel setzen. Sie wird daraufhin direkt in dem 3D-Inspektor übernommen und im 3D-Modell angezeigt. Dieses Prinzip soll auch anders herum gelten: Alles, was im 3D-Inspektor eingezeichnet wird, wird im 2D-Inspektor übernommen. Das Hinzufügen der Kugel im 3D-Inspektor gestaltet sich etwas schwieriger, da das Auswählen eines bestimmten Punktes im 3D-Modell auf einem Bildschirm oft dadurch behindert wird, dass andere Pixel optisch davor liegen. Deshalb wäre es sinnvoll zunächst erst einmal die Kugel in den 3D-Raum zu setzen und sie daraufhin in x-, y- und z-richtung zu verschieben. Das Verschieben der Kugel soll horizontal und vertikal auch im 2D-Inspektor möglich sein. Möchte man eine Verschiebung nach vorne oder hinten bewirken, muss die Ansicht in eine der zwei anderen orthogonalen Ebenen gewechselt werden Resektionsplan anpassen Der Arzt muss sich als erstes entscheiden, ob er den präoperativen Resektionsplan anpassen oder einen komplett neuen erstellen möchte. Je nachdem, welche Option er wählt, muss Entsprechendes im 3D-Inspektor angezeigt werden. Über die Auswahl der Anzeige kann er den geplanten Schnitt ein- beziehungsweise ausblenden. Ist er eingeblendet, so stehen ihm das Resektat und die Restleber getrennt durch Resektionsebenen zur Verfügung. Diese Resektionsebenen kann er dann bearbeiten oder löschen oder ggf. weitere hinzufügen. Für das Verändern des alten Resektionsplans oder das Erstellen eines neuen sind mehrere Schritte zu absolvieren: Resektionslinien anpassen und setzen. Das Setzen beziehungsweise das Anpassen von Resektionslinien ist am einfachsten im 3D-Inspektor realisierbar, da die optisch vordersten Pixel auf dem 3D-Modell gleichzeitig die Oberfläche der Leber darstellen. Hierfür soll zunächst die gewünschte Ansicht im 3D-Inspektor ausgewählt werden. Schnitte werden oft anhand der Territorienbegrenzung gesetzt, sodass es zusätzlich nützlich sein kann, diese einzublenden. Daraufhin soll das 3D-Modell der Leber in die gewünschte Position rotiert werden, alte Schnitte sollen selektiert und gelöscht werden und neue Resektionslinien auf der Oberfläche der Leber sollen definiert werden können. Resektionsebenen definieren. Die Resektionsebenen kalkulieren sich automatisch aus den Resektionslinien. Die zuvor gesetzten Resektionslinien bilden eine Linie um die Leber herum. 28

29 3. Funktionale Anforderungen Bei der Berechnung der Resektionsebene wird eine glatte Ebene in das 3D-Modell eingezeichnet, die die Punkte auf der Resektionslinie am besten approximiert. Sie soll daraufhin noch verformt und verschoben werden können, um einen genügenden Abstand zur Läsion zu gewährleisten. Abstand zwischen Läsion und Resektionsebene. Während des Bearbeitens der Resektionsebenen soll es möglich sein, den kleinsten Abstand zwischen den Resektionsebenen und der Läsion zu berechnen. Es gibt unterschiedliche Auffassungen eines tumorfreien Sicherheitsabstandes, der eingehalten werden muss, um den Tumor vollständig zu entfernen. Laut Hamady et al. [28] wird diesem Sicherheitsabstand zu große Bedeutung beigemessen, sodass eher zu einer parenchymsparenden Resektion geraten wird. Kalkulation und Darstellung des Volumens der Restleber und des Resektats. Die Volumina der Restleber und des Resektats sollen auf Grundlage der neu gesetzten Resektionsebenen neu kalkuliert und dargestellt werden. Für die Darstellung muss also die Auswahl der Anzeige aktualisiert werden, um die Anzeige der Restleber und des Resektats auszuwählen. Die relativen und absoluten Volumina in der Legende müssen neu berechnet und geladen werden. Es sind jedoch nicht nur die Volumina entscheidend für den Erfolg einer vollständigen Tumorentfernung. Zusätzlich braucht der Arzt Informationen über die Versorgung der Lebergefäße, damit sichergestellt werden kann, dass betreffende Bereiche der Leber ausreichend durchblutet oder drainiert werden [39]. 29

30 4 Berührungslose Gestensteuerung: Technischer und algorithmischer Hintergrund Nachdem in Kapitel 3 nun die funktionalen Anforderungen an ein gestengesteuertes Interface beschrieben wurden, soll hier auf den technischen und algorithmischen Hintergrund eingegangen werden. Kapitel 4.1 beschäftigt sich mit verschiedenen Aufnahmetechniken. Wie in Abschnitt 2.2 bereits beschrieben, bietet sich die Verwendung einer 3D-Kamera besonders an. Daher sollen hier verschiedene Kamerasysteme vorgestellt werden, die die Gewinnung von Tiefeninformationen ermöglichen. Hieraus wird eine Schlussfolgerung gezogen, die basierend auf den erörterten Technologien diejenige wählt, die für den Anwendungskontext im Operationssaal die verhältnismäßig besten Resultate liefert. Kapitel 4.2 geht auf die algorithmische Erschließung der Gestenerkennung ein. Hier werden Methoden diskutiert, die für unseren Anwendungsbereich relevant sind und berücksichtigt insbesondere die Gestenerkennung in 3D-Bildern Hardware: Analyse der Kamera-Aufnahmetechniken Die meisten digitalen RGB-Videokameras arbeiten heutzutage mit CCD- (englisch: charge coupled device) oder mit CMOS-Chips (englisch: complementary metal oxide semiconductor) [42]. Die Sensortechnologie von 2D-Kameras soll jedoch nicht Gegenstand unserer Arbeit sein. Stattdessen wollen wir uns mit den 3D-Aufnahmesystemen beschäftigen, die nach Abschnitt 2.2 die für unsere Anwendung benötigte Technik darstellen. Für die 3D-Aufnahmetechnik hat sich bisher noch keine allgemein verwendete Technik etabliert [12]. Je nach Weiterverarbeitung und Darstellung unterscheiden sich die Anforderungen an die 3D-Aufnahme. Für unsere Zwecke sind zum einem das 2D-Bild mit Farbinformationen und zum anderen die Tiefeninformationen für jeden Bildpunkt wichtig. Diese Informationen können durch unterschiedliche Methoden gewonnen werden. Wir werden hier einige Techniken genauer betrachten und ihre Vor- und Nachteile in der Gewinnung der Tiefeninformation kurz zusammenfassen. Im Anschluss erörtern wir die für uns wichtigen Funktionen und entscheiden uns für eine der folgenden Aufnahmetechniken: 30

31 4. Berührungslose Gestensteuerung: Technischer und algorithmischer Hintergrund Stereokameras/Multi-Kamera-Array: Mehrere Kameras, jedoch mindestens zwei, nehmen die gleiche Szene auf und ermöglichen somit eine dreidimensionale Bildfolge [63]. Streifenprojektionsverfahren: Ein Muster wird auf die Szene projiziert. Aus dem Wiedererkennen des Musters können Rückschlüsse über die Tiefeninformationen der Szene gezogen werden [25]. Time-of-Flight (ToF) Kameras: Die Zeit, die ein Lichtimpuls benötigt, um von der Lichtquelle ausgesendet, von einem Objekt reflektiert und von der Kamera wieder eingefangen zu werden, wird gemessen und daraus die Distanz berechnet [12]. Interferometrie: Hier bedient man sich der Technik der Phasenverschiebung und berechnet so Tiefeninformationen der Szene [16]. Plenoptic: Mit Hilfe von Mikrolinsen-Arrays können Aufnahmen aus mehreren Blickwinkeln auf einem Sensor gewonnen werden [12]. Multi-Kamera-Array Eine unterschiedliche Anzahl an Stereokameras wird auf verschiedene Art und Weise angeordnet, um eine Szene aus mehreren Blickwinkeln zu betrachten. Mit Hilfe des Prinzips der Triangulation können Abstände in der Szene bestimmt werden. Zur Vereinfachung werden wir auf ein stereoskopisches System mit zwei Kameras eingehen. Hier lässt sich zwischen dem kovergenten und den achsenparallelen Kamerasystem unterscheiden. Konvergenzpunkt a optisches Zentrum a Abbildung 4.1.: Konvergentes Kamerasystem (links) und achsenparalleles (rechts) (Abbildung nach Schreer [63]) Ersteres wird in Abbildung 4.1 links gezeigt, in dem die optischen Zentren der Kameras auf einen Konvergenzpunkt ausgerichtet sind. Bei einem achsenparallelen Stereosystem (Abbildung 4.1, rechts) sind die Kameras parallel zueinandern ausgerichtet [63]. Häufig sind die Kameras in einem Abstand von ca. 65 mm ausgerichtet. Dies entspricht in etwa dem Abstand 31

32 4. Berührungslose Gestensteuerung: Technischer und algorithmischer Hintergrund der menschlichen Augen. Die zwei Kanäle können somit als Ansicht für das linke und das rechte Auge übernommen werden. Bei der Rekonstruktion der Distanzen aus der Szene stellt man sich zunächst dem Problem der Korrespondenz. Das bedeutet, dass in beiden Kanälen die jeweilig übereinstimmenden Pixel gefunden und einer bestimmten Weltkoordinate zugeordnet werden müssen. Ist dies geschehen, lässt sich mit dem Strahlensatz die Entfernung jedes Punktes berechnen (vergleiche Abbildung 4.2). P d B1 f c1 x1 p1 a p2 x2 c2 B2 B1, B2 a x1, x2 - Bildebenen - Abstand zw. optischen Zentren - kürzeste Abstände zw. Bildmittelachsen und p1/p2 p1, p2 P f d - korrespondierendes Punktepaar - gemeinsamer Bildpunkt - Brennweite - gesuchter Tiefenwert Abbildung 4.2.: Rekonstruktion von Tiefenwerten eines achsenparallelen Systems mit bekanntem korrespondierendem Punktepaar (Abbildung nach Schreer [63]) Bei bekanntem, korrespondierendem Punktepaar p 1, p 2 in den Bildebenen B 1, B 2, sowie dem festgelegten Abstand a zwischen den Kameras lässt sich der Tiefenwert d bestimmen mit d = a x 1 + x 2 f (4.1) wobei x 1, x 2 der horizontale Abstand zwischen den optischen Zentren und den korrespondierenden Pixeln und f die Brennweite der Kameras sind. Die mathematischen Zusammenhänge bei der Stereoskpie sind zwar einfach, jedoch können erhebliche Probleme bei der Erkennung des korrespondierenden Punktepaares entstehen. Dies geschieht nämlich auf Grundlage der Farbwerte in den beiden aufgenommenen Bildern. Wird also eine einfarbige Fläche aufgenommen, so kann die Tiefenstruktur kann nicht vollständig erfasst werden. Zusätzlich muss ein Multi-Kamera-Array aufwendig kalibriert werden, damit die Tiefeninformationen genau berechnet werden können. Die Kameras müssen klein in ihrer Bauweise sein und auch die Linsenverzerrung muss beachtet werden, da sie die Berechnung der Distanz verfälschen kann. Die Stereoskopie findet vor allem Verwendung in der 3D- 32

33 4. Berührungslose Gestensteuerung: Technischer und algorithmischer Hintergrund Filmproduktion. Die Problematik in der Berechnung der Distanzen besteht zwar auch mit sehr hochauflösenden Kamerasystemen, jedoch wird in diesem Fall viel Arbeit in die Postproduktion verschoben, sodass ein sehr genaues 3D-Bild geschaffen werden kann. Eine Verarbeitung in Echtzeit ist allerdings nur schwer realisierbar [12]. Streifenprojektionsverfahren Beim Streifenprojektionsverfahren wird ein Streifenmuster auf die Szene projiziert. Diese wird dann von einer Kamera, deren Sensor im kurzwelligen Bereich empfindlich ist (beispielsweise CMOS-Sensor), aus einem festgelegten Winkel aufgenommen [25]. Abbildung 4.3 zeigt das Prinzip des Streifenprojektionsverfahrens. Durch die optische Projektor Kamera Streifenprojektion auf die Szene α Abbildung 4.3.: Prinzip der Streifenprojektion. (Abbildung nach Frankowski [25]) Verformung der Streifen auf den Objekten in der Szene lassen sich Distanzen mit Hilfe des Triangulationsverfahren berechnen [25]. Abbildung 4.4 verdeutlicht, wie aus der Verformung der Streifen der Tiefenwert gewonnen wird. Aus der Position p des Punktes im Bild, dem Abstand f der Kameramatrix zum Scheitelpunkt und festem Winkel γ (Winkel zwischen dem optischen Zentrum der Kamera und der Positionierung vom Projektor zur Kamera) lässt sich der Winkel β mit β = γ + arctan( p f ) (4.2) berechnen. Die Kamera und der Projektor sind in einem bestimmten Abstand a aufgestellt und ihre Projektions- beziehungsweise Aufnahmeflächen bilden einen festgelegten Winkel α, der bei jedem Punkt im Bild gleich ist. Mit dem berechneten Winkel β, dem Abstand a zwischen Projektor und Kamera und dem Winkel α, der sich aus der Projektionsrichtung und dem Winkel, 33

34 4. Berührungslose Gestensteuerung: Technischer und algorithmischer Hintergrund in dem die Szene von der Kamera aufgenommen wird, ergibt, kann die Tiefeninformation d für jeden Pixel im Bild generiert werden [71]. Aus dem Sinussatz ergibt sich: c sin(180 α β) = a sinα c = a sin(180 α β) sinα (4.3) Somit lässt sich die Tiefeninformation d gewinnen mit: Das Streifenprojektionsverfahren hat nicht die Korrespondenzprobleme wie beim Multi-Kamera-Array, da die Tiefenstruktur nun nicht anhand der Farbinformationen ermittelt wird. Der Nachteil, der sich aus der Berechnung der Distanzen mittels der Streifenprojektion ergibt, ist, dass transparente oder spiegelnde Strukturen nicht erfasst werden können. Der Sensor kann das reflektierte infrarote Licht bei solchen Gegenständen nicht lokalisieren und so können keine Tiefeninformationen in diesen Bereichen erstellt werden. Ein großer Vorteil des Streifenprojektionsverfahrens ist die kostengünstige Herstellung und das Berechnen der Tiefeninformationen in Echtzeit. Microsofts Kinect für die Xbox 360 Spielekonsole ist ein System, das eine RGB-Kamera mit einem Tiefensensor und einem Multiarray-Mikrofon verbindet. Es ist das erste System, das all diese Eigenschaften in einem Gerät vereint d = c sinβ (4.4) Projektor a α d β γ f Kamera Abbildung 4.4.: Rekonstruktion von Tiefenwerten bei Streifenprojektionsverfahren (Abbildung nach Wilke [71]) und kommerziell erworben werden kann. Nach einiger Recherche mussten wir feststellen, dass Microsoft nicht viele technische Details zur Kinect preisgibt. Der Tiefensensor basiert auf der Technik der Streifenprojektion. Er besteht aus dem Projektor, der infrarotes Licht in einem bestimmten Muster aussendet und mit einer CMOS-Kamera wieder aufnimmt. Dies ermöglicht die Gewinnung von Tiefeninformationen unter nahezu allen Lichtverhältnissen [?]. Time-of-Flight Kameras Ein Lichtimpuls außerhalb des sichtbaren Bereichs wird in bestimmten Zeitabständen auf die Szene projiziert. Die Objekte in der Szene reflektieren das Licht, sodass es von einem Sensor wieder aufgenommen werden kann [12]. Aus der vergangene Zeit vom Aussenden bis zum Einfangen des Lichtes lassen sich Rückschlüsse über die Distanzen der p 34

35 4. Berührungslose Gestensteuerung: Technischer und algorithmischer Hintergrund Objekte ziehen: i = c t (4.5) 2 Die Tiefeninformation i ergibt sich aus der Multiplikation der Hälfte der gemessenen Zeit t mit der Lichtgeschwindigkeit c km sec [16]. Probleme ergeben sich bei transparenten oder spiegelnden Oberflächen, da hier aus den gleichen Gründen, die bei dem Prinzip der Streifenprojektion genannt sind, das Licht nicht mehr akkurat eingefangen werden kann. Ebenso gilt das Reflexionsgesetz: Die Photonen werden abhängig vom Einfallswinkel abgelenkt und eingefangen. Sehr helle Lichtquellen, wie die Sonne oder Halogenlampen beeinflussen die Lichtwellen, sodass dies zu Messfehlern führen kann [12]. Weniger problematisch ist die Mehrfachdeutung von Distanzen. Das Einfangen des Lichtstrahls bei einer pulsierenden Lichtquelle ist zwar nicht immer eindeutig dem Aussenden zuzuordnen, jedoch ist dies nur bei großen Distanzen und einer hohen Bildrate der Fall. Dieses Verfahren zur Gewinnung von 3D-Informationen ist einerseits zuverlässig und einfach in der Kalkulation der Distanzen, andererseits aber auch sehr kostspielig. Interferometrie Das Prinzip der Interferometrie (englisch: Continuous Wave Modulation) ist dem Time-of-Flight unterzuordnen, da auch hier Distanzen durch den Abgleich von ausgesendetem und eingefangenen Licht stattfindet. Wie bei den ToF- Kamerasystemen handelt es sich bei der Interferometrie um Licht außerhalb des sichtbaren Bereichs, das von den Objekten in der Szene reflektiert und von einem Sensor wieder eingefangen wird. Im Gegensatz zu ToF-Kameras handelt es sich um einen ununterbrochenen Lichtstrahl, welcher vor allem durch das Auftreffen auf einen Gegenstand in seiner Amplitude verringert wird. Die Wellenlänge allerdings verändert sich nicht. Die Wellen des aufgenommenen Strahls werden mit denen des ausgesendeten verglichen. Diese Vergleichsmethode wird in der Physik Phasenverschiebung genannt und wird in Abbildung 4.5 veranschaulicht. Aus der Phasenverschiebung lässt sich die Zeit ermitteln, die die A φ k t gesendetes Signal Sg empfangenes Signal Se A k A φ t - Amplitude des gesendeten Signals - Phasenverschiebung - Koeffizient, um den sich die Amplitude von Se verringert - Zeit Abbildung 4.5.: Phasenverschiebung, ein Vergleich des gesendeten und empfangenen Signals (Abbildung nach Büttgen et al. [16]) Photonen des Lichtes vom Aussenden bis zum Einfangen benötigen (siehe Time-of-Flight), und somit auch die Distanzen zu jedem Punkt in der Szene. Nachteile ergeben sich bei transparenten oder spiegelnden Oberflächen und bei zu steilen Winkeln, sowie bei heller Beleuchtung vergleichbar mit dem Prinzip der ToF-Kameras. Zudem ist auf die interne und äußere Temperatur der Kamera zu achten, da dies die Geschwindigkeit der Photonen beeinflussen kann. Die Messung der Zeit mittels der Interferometrie ist zwar nach heutiger Technik sehr genau, jedoch ebenso wie ToF-Kameras noch immer teuer [16]. 35

36 4. Berührungslose Gestensteuerung: Technischer und algorithmischer Hintergrund Plenoptic Das Plenoptic-System bedient sich dem Prinzip des parallaktischen Winkels. Dabei handelt es sich um die gleichzeitige Erzeugung von Aufnahmen einer Szene aus mehreren Blickpunkten auf einem Sensor. Jeder Punkt in der Szene wird also von einer festen Anzahl an Blickwinkeln betrachtet. Hierfür wird eine Folge an Mikrolinsen vor die Kamera gesetzt, sodass für jeden Punkt im Bild ein winkelabhängiger Pixel auf dem Bildsensor abgebildet werden kann. Fasst man alle Pixel mit der gleichen Parallaxe zusammen, so entsteht eine Bildsequenz aus einem festgelegten Blickwinkel. Abbildung 4.6 veranschaulicht das Prinzip des Plenoptic- Systems, bei dem 15 Mikrolinsen benutzt werden. Diese erzeugen für jeden Objektpunkt 15 Blickpunkte und somit ergeben sich 15 Abbildungen mit unterschiedlicher Parallaxe [12]. Aus den unterschiedlichen Abbildungen lässt sich die Tiefeninformation für jeden Pixel wieder mittels Triangulation berechnen [12]. Hauptlinse Zusammenfassung der Ansichten ergibt 15 Bildsequenzen Mikrolinsenfolge (für jeden Punkt 15 Ansichten) Abbildung 4.6.: Prinzip des plenoptischen Systems. (Abbildung nach Bloß et al. [12]) Je mehr Bildsequenzen für unterschiedliche Parallaxen existieren, desto genauer und zuverlässiger lassen sich die Distanzen berechnen. Adelson et al. [5] stellten bereits 1992 eine der ersten Kameras vor, die das Prinzip der Plenoptic nutzt. Ein großer Vorteil ist dabei, dass keine umständliche Kalibrierung notwendig ist, da die gesamte Technik in einer Kamera verbaut werden kann. Zudem ist es nicht nötig auf bestimmte Lichtverhältnisse zu achten, da die Kamera ohne ausgesendete Lichtwellen arbeitet. Einschränkungen ergeben sich in der Auflösung, da diese von der Anzahl der Mikrolinsen abhängig ist. Des Weiteren ist diese Art zur Gewinnung von Tiefeninformationen noch immer in der Entwicklung und sehr kostspielig [12] Fazit Die unterschiedlichen Aufnahmetechniken haben jeweils ihre Vor- und Nachteile. Die für unsere Zwecke wichtigen Kriterien werden in der Tabelle aus Abbildung 4.7 zusammengefasst. Das Kamerasystem basierend auf der Interferometrie haben wir dem Time-of-Flight-System zugeordnet, da die ähnliche Funktionsweise zu nahezu gleichen qualitativen Ergebnissen führt. Neben dem Preis ist auf die Verarbeitung der Tiefeninformationen in Echtzeit zu achten. Eine 36

37 4. Berührungslose Gestensteuerung: Technischer und algorithmischer Hintergrund Stereokameras Streifenprojektion ToF-Prinzip Plenoptic Preis Echtzeit Handhabung Lichtverhältnisse Zuverlässigkeit Abbildung 4.7.: Bewertung der Aufnahmetechniken leichte Handhabung ist natürlich auch eine Grundvoraussetzung, die nicht außer Acht gelassen werden darf. Umständliche Kalibrierungen, wie das Ausrichten der Kameras oder das Anpassen von Lichtverhältnissen, sollen im Operationssaal nicht geschehen. Der spezielle Situationskontext im Operationssaal gibt bestimmte Lichtverhältnisse vor. Wie in Kapitel 2.1 bereits erörtert, ist der Raum und insbesondere der Operationstisch während eines chirurgischen Eingriffs sehr stark ausgeleuchtet. Somit können Aufnahmetechniken, die mit Licht außerhalb des sichtbaren Bereichs arbeiten, qualitativ in ihrer Gewinnung des Tiefenbildes beeinflusst werden. Dies gilt insbesondere für ToF- und Interferometrie-Kamerasysteme, da diese Distanzen aus der Zeit berechnen, die das infrarote Licht vom Aussenden bist zum Einfangen benötigt. Zu guter Letzt müssen die Kameras zuverlässig Tiefeninformationen berechnen können. Unter bestimmten Bedingungen, man stelle sich beispielsweise ein Szenario vor, bei dem eine gleichflächig weiße Wand aufgenommen wird, können manche Kamerasysteme die Tiefeninformationen nicht beziehungsweise nur ungenau erfassen. Dies ist dann der Fall, wenn anhand der Farbwerte aus verschiedenen Bildern Distanzen berechnet werden wie bei Multi-Kamera-Arrays und plenoptischen Kameras. Dieses Problem liegt bei den ToF-Kamerasystemen und dem Streifenprojektionsverfahren nicht vor. Im Normalfall allerdings ist die Genauigkeit der Tiefenberechnung für alle Aufnahmetechniken genügend erfüllt. Eine lückenlos genaue Kalkulation für jedes einzelne Pixel im Bild kann zwar von allen Systemen nicht in Echtzeit erfolgen, jedoch ist dies für die Gestenerkennung auch nicht notwendig. Aus der Tabelle ist ersichtlich, dass Stereosysteme unter anderem schwierig in der Handhabung sind, da hier mindestens zwei Kameras entweder in einem bestimmten Winkel oder achsenparallel ausgerichtet werden müssen und zusätzlich ist darauf zu achten, dass alle Kameras die gleichen Einstellung bezüglich der Helligkeit, Kontraste, Tiefenschärfe usw. haben. Die Kamerasysteme, die auf dem ToF-Prinzip basieren, können, wie bereits erwähnt, stark von den sehr hellen Lichtverhältnissen im Operationssaal beeinflusst werden. Die Planeoptic ist ein Verfahren, das vor allem dann Einsatz findet, wenn es darum geht, Videos aufzunehmen, die auf autostereoskopischen Displays dargestellt werden sollen. Für die Verarbeitung in Echtzeit und die Gestenerkennung ist dieses Verfahren weniger geeignet. Zudem ist dieses Kamerasystem zu diesem Zeitpunkt noch nicht relevant für unsere Arbeit, da es bisher noch keine Kamera gibt, die kommerziell vertrieben wird. Kamerasysteme auf Basis vom Streifenprojektionsverfahren 37

38 4. Berührungslose Gestensteuerung: Technischer und algorithmischer Hintergrund bieten vor allem seit dem Vertrieb der Microsoft Kinect (für Deutschland seit November 2010) ein vergleichbar kostengünstiges Instrument zum gleichzeitigen Erwerb von RGB- und Tiefenbildern. Die Kinect wurde eigentlich für Microsofts Spielekonsole Xbox 360 entwickelt, wurde aber schon bald nach der Veröffentlichung für den Einsatz an Computersystemen mit Mac OS X, Microsoft Windows oder Linux-Betriebssystemen erschlossen. Der Einsatz auf diesen Systemen ist von Microsoft zwar nicht intendiert, wird aber mittlerweile ausdrücklich gebilligt. Somit kommen wir zu dem Schluss, dass die Kinect für unsere Zwecke am besten geeignet ist Software: Algorithmen zur Gestenerkennung Dieser Abschnitt soll einen Überblick über die algorithmische Lösung des Handgestenerkennungsproblems geben. Dabei sollen gängige Methoden angesprochen und diskutiert werden. Wir beschränken uns hierbei auf unser spezielles Anwendungsgebiet, sodass wir Lösungsansätze für typische Probleme der Handgestenerkennung, die in unserem Szenario nicht relevant sind, zwar ansprechen, aber nicht ausführlich behandeln werden. So können 2D-Hintergrundsegmentierungsalgorithmen bei starker Farb- oder Helligkeitsänderung des aufgenommenen Bereiches unbrauchbar werden. Dies tritt bei Tageslichtbeleuchtung auf oder wenn in Innenräumen das Licht ein- beziehungsweise ausgeschaltet wird. Wir gehen zum einen wie in Abschnitt 2.1 beschrieben von einer weitgehend konstanten Beleuchtungssituation aus und können zum anderen das uns zur Verfügung stehende Tiefenbild zur Hintergrundsegmentierung verwenden, sodass dieses nicht triviale Problem in unserem Fall nur bedingt auftritt. Ebenso müssen wir uns mit der Hand-Arm-Segmentation, die für einige Algorithmen ein Problem darstellt, nicht ausführlich beschäftigen, da diese Trennung durch die bei invasiven Eingriffen getragenen Handschuhe in unserem Fall sehr leicht umzusetzen ist. Ein weiterer großer Bereich, der zur Komplexität vieler Algorithmen entscheidend beiträgt, ist die Erkennung von mehr als einer Hand gleichzeitig. Da wir zumindest für den Visualisierungsbereich ein einhändig bedienbares System vorschlagen (vergleiche Abschnitt 2.1), das nicht gleichzeitig von mehreren Personen bedient wird, ist auch dieses Themenfeld für uns nicht relevant. Wie bereits vorher in dieser Arbeit diskutiert, schließen wir auch Ansätze aus, die spezielle Markierungen der Hände beziehungsweise Finger oder gar spezielle Sensorenhandschuhe beim Bedienenden voraussetzen. Eine ausführlichere Zusammenstellung, die auch die von uns ausgelassenen Fälle berücksichtigt, jedoch nicht so stark auf die Nutzung von 3D-Features eingeht, ist bei Erol et al. [22] zu finden, deren Einordnung und Taxonomie verschiedener Techniken zur Handgestenerkennung diesem Abschnitt in abgewandelter Form zu Grunde liegt. Wir definieren für diese Arbeit den Begriff statische Geste für Handgesten, die sich durch eine bestimmte Handpositur auszeichnen, und dynamische Geste für Handgesten, deren Bedeutung aus einer zugehörigen Handbewegung erschlossen werden muss. Selbstverständlich existieren auch Mischformen. Diese Begriffsdefinition ist auch die gängigste Wahl in vergleichbaren anderen Arbeiten 1. Außerdem benutzen wir den Begriff Handpositur (englisch: hand posture), mit dem wir die Stellung der Hand in Bezug auf Fingerstellung sowie allgemeiner Rotationsausrichtung der gesamten Hand im Raum bezeichnen. 1 beispielsweise in Mitra und Acharya [50] oder Just und Marcel [35]. 38

39 4. Berührungslose Gestensteuerung: Technischer und algorithmischer Hintergrund Der zuerst folgende Unterpunkt soll das Handgestenerkennungsproblem kurz in seiner Gesamtheit skizzieren, bevor dann für unseren Fall geeignete Lösungsansätze für die entsprechenden Teilaufgaben der Handgestenerkennung angesprochen werden: Schritt I Hintergrundsegmentation (Abschnitt 4.2.2), Schritt II Finden der Hand (Abschnitt 4.2.3), Schritt III Tracking der Hand, aufgeteilt in Schritt IIIa verschiedene Trackingmöglichkeiten (Abschnitt 4.2.4) und Schritt IIIb Erstellung eines Handmodells (Abschnitt 4.2.5), Schritt IV Interpretation der erkannten Posituren (Abschnitt 4.2.6) Handgestenerkennung: Problemstellung und Überblick Die Erläuterungen in diesem Abschnitt dienen nur der Einordnung und Abgrenzung unterschiedlicher Ansätze voneinander sowie dem Aufzeigen gegenseitiger Wechselbeziehungen und sollen dem Leser als Orientierung dienen. Sie sind daher an manchen Stellen zunächst vereinfacht dargestellt. Präzisere und umfangreichere Erläuterungen zu den Ansätzen finden sich dann in den entsprechenden Abschnitten zu den Schritten II und III der Gestenerkennung. Eine Hand sowie ihre Positur zu erkennen ist abhängig von den Umgebungsbedingungen kein triviales Problem. Dies liegt hauptsächlich daran, dass die Hand in sich sehr beweglich ist, also sehr viele Freiheitsgrade aufweist: Die Hand hat mindestens 26 Freiheitsgrade und mindestens sechs davon werden für eine robuste Gestenerkennung benötigt [22]. Insbesondere ist festzustellen, dass die Silhouette einer Hand für eine zuverlässige unabhängige Erkennung rein über dieses Merkmal zu viele Formen annehmen kann. Erschwert wird das Unterfangen besonders durch das hohe Selbstverdeckungspotenzial der Hand. Folgendes Problem gilt es zu lösen: Wir haben ein Objekt die Hand, das in verschiedenen Zuständen Posituren vorliegen kann. Diese Zustände bilden in ihrer Gesamtheit den so genannten Zustandsraum. Neben der Frage, ob überhaupt ein den Kriterien entsprechendes Objekt im beobachteten Bereich vorzufinden ist, wollen wir auch die Frage nach dem momentanen Zustand des Objekts klären. Dieser Zustand ist für uns jedoch nicht direkt greifbar, sondern nur über Beobachtungen zu erschließen. Man sagt, der tatsächliche Zustand sei versteckt. Um aus Merkmalsbeobachtungen auf den Zustand schließen zu können, müssen wir wissen, welche Zustände das Objekt überhaupt einnehmen kann. Das Wissen um die möglichen Zustände kann man vorgeben oder während einer Trainingsphase oder sogar auch noch während der Laufzeit vom System lernen lassen. Die Schwierigkeit, die dieses Problemfeld ausmacht, ergibt sich aus der Ungenauigkeit, die grundsätzlich jedes erdenkliche Messverfahren mit sich bringt mal stärker, mal weniger stark. Beobachtete Merkmale können auf Grund dieser Ungenauigkeit häufig nicht eindeutig einem Zustand zugeordnet werden. Während mit Sensorenhandschuhen auf relativ genaue Beobachtungen der Handpositur zugegriffen werden kann, ist bei Computer- Vision-Ansätzen allein das Kamerabild vorhanden, aus dem Rückschlüsse auf die Handpositur gezogen werden müssen mit all seinen Schwächen: Rauschen, Selbstverdeckungsprobleme, 39

40 4. Berührungslose Gestensteuerung: Technischer und algorithmischer Hintergrund Ansätze zur Handgestenerkennung einzelbildbasiert verfolgungsbasiert volle Positurenanzahl eingeschränkte Positurenanzahl können Initialisierungsdaten liefern Abbildung 4.8.: Kategorisierung der Ansätze zur Handgestenerkennung Verzerrungen usw. 2 Dieses Aufgabenfeld i.e. trotz Messungenauigkeiten robuste Aussagen über das beobachtete Objekt treffen zu können gehört zur so genannten Signalverarbeitung. Wegen der hohen Dimensionalität des Zustandsraumes (verursacht durch die vielen Freiheitsgrade der Hand), handelt es sich bei der Handgestenerkennung um ein besonders komplexes Signalverarbeitungsproblem, für dessen Lösung in Echtzeit noch kein optimaler Algorithmus existiert. Um dieser optimalen Abschätzung 3 jedoch zumindest nahe zu kommen, gibt es viele unterschiedliche Ansätze. Allgemein lassen sich diese Ansätze grob in einzelbildbasierte und verfolgungsbasierte Algorithmen unterteilen (letztere sind auch als modellbasierte Ansätze bekannt, s.u.). Diese Kategorisierung wird in Abbildung 4.8 veranschaulicht. Einzelbildbasierte Algorithmen zu denen auch die im Absatz beschriebenen Methoden zum initialen Auffinden der Hand gehören sind zum Großteil auch erscheinungsbasierte Algorithmen, die über Vergleiche der aufgenommenen Handabbildungen mit typischen Referenzaufnahmen der zu interpretierenden Gesten arbeiten. Diese Referenzaufnahmen sind im Regelfall nicht durch hinterlegte Pixelbilder repräsentiert, sondern in anderer, leichter auswertbarer und platzsparender Form in Datenbanken gespeichert. Dabei werden häufig bestimmte Bildinformationen extrahiert, die sich in Form von Histogrammen darstellen lassen. Kantendetektoren und Farbhistogramme sind Beispiele für Methoden, die in diesen Ansätzen gebraucht werden können. Zu unterscheiden ist, ob die Algorithmen hier nur bestimmte Posituren zu erkennen versuchen oder eine Erkennung aller möglichen Posituren angestrebt wird. Algorithmen, die alle möglichen Posituren nur mit Hilfe der Informationen aus dem aktuellen Bild (Frame) zu erkennen versuchen, sind leider noch sehr unzuverlässig und rechenintensiv, insbesondere wenn die Hand Teile von sich selbst verdeckt. Der große Vorteil im Vergleich zu den im Fol- 2 Selbstverständlich ist das Problem der Messungenauigkeit mit Sensorenhandschuhen nur verringert, nicht jedoch aus der Welt geschaffen. Dasselbe gilt für den Einsatz von 3D-Kameras: Zwar erlauben diese genauere beziehungsweise zusätzliche Merkmalsbeobachtungen, aber das grundsätzliche Problem bleibt bestehen. 3 Eine solche Abschätzung, die mit a-priori-wahrscheinlichkeiten arbeitet, um den wahrscheinlichsten aktuellen Zustand aus Beobachtungen zu ermitteln, basiert auf dem Bayestheorem und wird deshalb auch häufig als Bayes sche Abschätzung bezeichnet. 40

41 4. Berührungslose Gestensteuerung: Technischer und algorithmischer Hintergrund genden erläuterten modellbasierten/verfolgungsbasierten Ansätzen ist jedoch die Tatsache, dass diese ohne Vorwissen aus vorherigen Bildern zu einem Ergebnis kommen können. Würde diese allgemeine Einzelbild-Erkennung in Echtzeit gelingen, wäre sie in jedem Fall die erste Wahl und würde die ungleich komplizierteren Verfahren, die auf Handverfolgung setzen, obsolet machen, zumal diese eine Reihe weiterer Probleme aufwerfen. Wir wollen in Schritt II kurz auf erste Umsetzungsversuche, dieser einzelbildbasierten Algorithmen ohne Beschränkung der Positurenanzahl eingehen, wenn auch klar gesagt werden muss, dass wir nicht über die nötigen Ressourcen verfügen, entsprechende Ansätze tatsächlich zu implementieren. In der Praxis wurden unseres Wissens entsprechende Systeme auch andernorts noch nicht erfolgreich umgesetzt. Ist das Ziel jedoch nur die Erkennung eines sehr eingeschränkten Vokabulars ikonischer Gesten, ist das Problem nicht mehr ganz so schwer lösbar. Es wird sich zeigen, dass entsprechende eingeschränkte Einzelbildalgorithmen auch zum Initialisieren von Handverfolgungsalgorithmen gebraucht werden, sodass sie eine weite Verbreitung aufweisen. Handverfolgungsalgorithmen (englisch: Hand-Tracking) werden im Abschnitt ausführlich beschrieben. Sie setzen voraus, dass relevante Eigenschaften des zu verfolgenden Objekts zusammengetragen und daraus ein Modell gebildet wird, weshalb sie auch als modellbasierte Ansätze bezeichnet werden 4 : Es wird also das Wissen um die Ausprägung des Zustandsraumes verfeinert und modelliert. Der Realitätsgrad dieser Modelle kann stark variieren, da sehr realistische Modelle zwar zu genaueren Ergebnissen führen, aber aufwändiger und damit langsamer zu berechnen sind. Außerdem können zu detaillierte Modelle auch Schwierigkeiten bei der Abstraktion relevanter Tracking-Features bereiten 5. Ein Modell bildet die möglichen Erscheinungsformen des zu erkennenden Objekts ab. Mit diesen möglichen Erscheinungsformen wird jeweils die im Kamerabild vorgefundene Situation verglichen und eine Hypothese aufgestellt, in welchem Zustand sich das beobachtete Objekt gerade befindet. Hierbei ist eine falsche Annahme in nur einem Bild grundsätzlich noch nicht besonders tragisch, aber da diese Hypothese Grundlage der Hypothese des nächsten Bildes ist, ist es sehr wahrscheinlich, dass die Hypothese sich über kurz oder lang sehr weit vom tatsächlichen Zustand entfernt. In diesem Moment reißt der Verfolgungsalgorithmus ab und muss neu gestartet werden. Dieser Fehlerkumulation kann teilweise Einhalt geboten werden, indem man nicht nur die wahrscheinlichste, sondern jederzeit gleich mehrere Hypothesen weiterreicht. Es wird für den Zustandsraum eine entsprechende Wahrscheinlichkeitsverteilung gebildet, die wie beim Ein-Hypothesen-Ansatz auf dem vorherigen Zustand und den vorgenommenen Beobachtungen beziehungsweise Messungen basiert. Hat sich der Algorithmus verlaufen, wird angenommen, dass die wahrscheinlichste Hypothese nicht richtig war und der Erkennungsprozess wird erneut versucht, diesmal unter der Annahme, der im vorherigen Bild zweitwahrscheinlichste Zustand sei der richtige gewesen. Auf diese Weise fallen Fehler nicht mehr so stark ins Gewicht, der Trackingalgorithmus wird stabiler und robuster. Diese Strategie wird bei Partikelfiltern angewandt, die im Schritt III weiter erläutert werden. Da es zu Beginn eines modellbasierten Algorithmus keinen vorherigen Frame gibt, dessen Hypothese oder Wahrscheinlichkeitsdichte über die mögliche Handpositur genutzt werden 4 Im Falle der Handgestenerkennung wären diese Modelle in der Regel (3D-)Modelle der Hand, es wären grundsätzlich aber auch andere Modelle möglich, zum Beispiel ein Geschwindigkeitsmodell, falls nur die Geschwindigkeit der Hand relevant ist o.ä. 5 Weitere Details zum Thema Handmodellgestaltung finden sich in Abschnitt

42 4. Berührungslose Gestensteuerung: Technischer und algorithmischer Hintergrund kann, muss dieser Anfangszustand auf anderem Wege erstellt werden. Wie bereits angedeutet, wird hierfür dann ein positureneingeschränkter einzelbildbasierter Alogrithmus verwendet Schritt I Komplexität verringern: Erstellung von Hintergrundmasken zur Ausklammerung unwichtiger Bildbereiche Das erste Problem, das sich im Allgemeinen stellt, ist die Segmentierung in Vordergrund (Hand) und Hintergrund (alles andere): Es soll eine Maske erstellt werden, die Hintergrundpixel ausblendet, um die Komplexität des Lokalisierungsproblems zu verringern. Diese Segmentierung wird in klassischen 2D-Ansätzen häufig rein über ein Verfahren gelöst, das Optischer Fluss (englisch: Optical Flow) genannt wird, das auf Positionsvergleichen korrespondierender Pixelbereiche unterschiedlicher aufeinander folgender Einzelbilder basiert: Alles, was sich im Vergleich zum anfangs gelernten statischen Hintergrund verändert hat, hat sich folglich bewegt und gehört damit zum Vordergrund, der Rest ist Hintergrund. Vordergrundpixel, die sich nicht mehr verändern, werden im Laufe der Zeit zur neuen aktualisierten Hintergrundreferenzmatrix hinzugefügt. Dieser Schritt ist wichtig, da sonst nachträglich in die Szenerie platzierte Gegenstände dauerhaft als Vordergrund betrachtet würden. Ein verwandtes Problem tritt auf, wenn ein zum Hintergrund gehörender Gegenstand bewegt wird. In diesem Fall würde sowohl an der alten, wie auch an der neuen Position eine Pixeländerung erfasst. Es ist also wichtig, dass Vordergrundobjekte, wenn sie sich nicht mehr ändern, irgendwann zum Hintergrund hinzugezählt werden. Mit sogenannten Codebook-Algorithmen können zudem auch kleinere wiederkehrende Bewegungen des Hintergrundes toleriert werden, ohne dass diese Stellen sofort als Vordergrund interpretiert werden [13]. Gerade diese Vordergrund-Hintergrund-Segmentierung kann enorm vereinfacht werden, wenn wie in unserem Fall von der Szenerie auch ein zuverlässiges Tiefenbild vorliegt. So kann in einem ersten Schritt bereits ein bestimmter Interaktionsbereich im 3D-Raum definiert werden, außerhalb dessen gar nicht erst nach einer zur Interaktion bereiten Hand gesucht zu werden braucht 6. Nur innerhalb dieses Bereiches muss nun wie oben beschrieben mit bewegungssensitiven Algorithmen in Vordergrund und Hintergrund getrennt werden. Nach diesen Schritten gehören zur Ausschlussmaske nun bereits alle Bereiche, die außerhalb dieses 3D-Raums sind und alle Bereiche, die in diesem Bereich als statischer Hintergrund erkannt werden. In den noch verbleibenden möglichen Pixeln wird nach Anzeichen für die Anwesenheit einer Hand gesucht (s. folg. Abschnitt 4.2.3). Wird eine Hand gefunden, kann für die nachfolgenden Frames die Ausschlussmaske noch weiter verschärft werden, sodass nur noch der minimal benötigte dreidimensionale Bereich um die gefundene Hand herum von den Algorithmen interpretiert werden muss. Natürlich muss dieser Bereich so groß gewählt sein, dass der Operateur beim Gestikulieren den überwachten Bereich nicht unbeabsichtigt verlässt. Mit diesen Werten sollte experimentiert werden, bis sich eine zufriedenstellende Kombination herauskristallisiert hat. 6 Die Definition einer sog. interaction zone findet sich beispielsweise bei Graetzel et al. [27]. 42

43 4. Berührungslose Gestensteuerung: Technischer und algorithmischer Hintergrund Schritt II Hand finden: Erkennung und Lokalisierung des Objekts In vielen Algorithmen zur Handerkennung wird, um von der variablen Form unabhängig zu sein, zum Auffinden der Hand ein vergleichsweise simpler Farbabgleich durchgeführt. Dieses Vorgehen ist möglich, da die Hautfarben verschiedener Ethnien sich lediglich im Helligkeits-, nicht aber im Sättigungs- und Farbwert unterscheiden 7 [50]. In unserem Fall werden bei der Benutzung jedoch Handschuhe getragen. Sind diese weiß, sind sie schwer von anderen weißen Gegenständen im Operationssaal zu unterscheiden, aber auch wenn sie farbig sind, bekommen wir spätestens dann ein Problem, wenn der Chirurg Blut an den Händen hat, was eine starke Änderung aller drei Farbparameter (Farbton, Helligkeit, Sättigung) zur Folge hat. Solche Ansätze sind also in unserem Fall unbrauchbar, auch wenn beispielsweise Wachs et al. in einer frühen Version ihres Gestix genannten gestenbasierten Krankenhaussystems eine Kalibrierung auf die Handschuhfarbe erprobt haben [69]. Ein alternativer, für unser Vorhaben sinnvollerer Ansatz, der das Auffinden der Hand stark erleichtert, ist die Festlegung der zu findenden Form, d.h. der gezeigten Handpositur und der Handausrichtung. Diese Festlegung kann durch die Definition so genannter Aktivierungsgesten geschehen, beispielsweise die zur Kamera ausgerichtete Handfläche mit gespreizten Fingern. Wenn nur nach bestimmten Aktivierungsgesten gesucht werden muss, ist nicht mehr jede mögliche Silhouettenform der Hand für den Suchalgorithmus relevant. Dies entspräche einer einzelbildbasierten Lösung des Problems mit Einschränkung auf nur eine Positur (vergleiche Einordnung in Abschnitt 4.2.1). Während Erol et al. zu Bedenken geben, dass eine Aktivierungsgeste für den Benutzer eine unerwünschte Einschränkung darstellt 8, argumentieren Graetzel et al. [27], dass im speziellen Fall der intraoperativen Gestensteuerung besonders wenn der Interaktionsbereich knapp oberhalb des Patienten definiert wird eine Aktivierungsgeste nicht nur wegen des Robusterwerdens der initialen Handfindungsalgorithmen, sondern auch durch die einhergehende Verringerung der Fallzahl von Falsch-Positiv-Interpretationen nicht als Interaktiongesten gemeinter Handbewegungen sehr wünschenswerte Effekte hat. Da der Chirurg seine Hände auch bei seiner Primäraufgabe ständig bewegen muss, könnte die entsprechende Fehlerzahl ohne eine Aktivierung sehr hoch ausfallen. Dieses Thema wird später in Abschnitt zur Empfangsbereitschaft des Systems diskutiert, zur Einschränkung der algorithmischen Ansätze soll hier jedoch bereits vorweggenommen werden, dass wir uns für den Einsatz einer Aktivierungsgeste aussprechen. Da uns wie bereits mehrfach angesprochen ein Tiefenbild zur Verfügung steht, wird das Auffinden der Hand zusätzlich erleichtert. Tiefeninformationen geben uns nicht nur verbesserte Möglichkeiten, die Hand von der Umgebung abzugrenzen (Abschnitt 4.2.2), sie ermöglichen uns zusätzlich zur Bewertung der gefundenen Form die Kontrollmöglichkeit des Größenabgleichs: Wir wissen, wie weit der (vielleicht fälschlicherweise) als Hand erkannte Gegenstand von der Kamera entfernt ist, und können ausgehend von typischen Handgrößen berechnen, wie groß 7 Bei dieser Methode wird davon ausgegangen, dass die zu findende Hand der einzige hautfarbene Bereich im Bild ist. Das ist selbstverständlich nicht automatisch der Fall, sondern vielmehr eine Vorgabe, deren Einhaltung der Nutzer des Systems sicherzustellen hat. 8 Dies gelte insbesondere, wenn die Geste während der Interaktion wiederholt werden müsse, da sie zur Initialisierung eines Tracking-Algorithmus verwendet wird, der nicht robust genug ist und zu häufigem Verlieren der Hand neigt. 43

44 4. Berührungslose Gestensteuerung: Technischer und algorithmischer Hintergrund eine Handabbildung in diesem Fall sein müsste. Andere handähnliche, aber zu große oder zu kleine Gegenstände können so ausgeschlossen werden, was zu einer erhöhten Robustheit und Geschwindigkeit des Algorithmus beiträgt. Die beschriebenen Einschränkungen und Bedingungen führen zu einer vergleichsweise günstigen Ausgangssituation der Objekterkennung, die mit Hilfe der bekannten Algorithmen aus diesem Anwendungsbereich durchgeführt werden kann. Dazu gehören beispielsweise Kantendetektoren wie der sogenannte Canny edge detector mit einer anschließenden Formendetektion mit Hilfe der sogenannten Houghtransformation. Andere Methoden sind der Einsatz sogenannter Minimum Energy Contours (auch als Snakes bekannt) oder das Berechnen der sogenannten Chamfer distance. Es handelt sich hierbei um sehr bekannte, weit verbreitete und sehr allgemeine Methoden, die mehrfach an anderen Stellen beschrieben sind und deshalb hier nicht im Detail erläutert werden sollen. Abbildung 4.9.: Repräsentation nach Tarabella (basierend auf einer ähnlichen Abb. in [66]): Die grünen gestrichelten Linien stellen die Halbgeraden dar, die roten die zu messenden Strecken. Stattdessen wollen wir stellvertretend und beispielhaft eine von Tarabella [66] auf die Handgestenerkennung angepasste Methode vorstellen, die ursprünglich zum automatischen Erkennen von Werkzeugen auf einem Fließband entwickelt wurde: Das kleinste, die gesamte Hand beinhaltende Rechteck wird ermittelt. In diesem wird mit einer bestimmten Abtastrate für jede Richtung vom Rechteckmittelpunkt aus der am weitesten entfernte, zur Hand gehörende Punkt ermittelt und in einem Histogramm notiert. Bei Einsatz einer binären Maske, die aus einer Segmentierung von Hand und Umgebung entstanden ist, wäre das für jede Richtung jeweils die Entfernung zwischen Mittelpunkt und dem am weitesten entfernten weißen Pixel auf der zugehörigen vom Mittelpunkt ausgehenden Halbgerade innerhalb des Rechtecks (vergleiche Abb. 4.9). In dieser Repräsentation wäre eine Rotation der Hand nur eine Phasenverschiebung innerhalb des entstandenen Histogramms, sodass Posituren rotationsunabhängig verglichen werden können. Die störende Varianz in der Größe der Entfernungswerte verursacht sowohl durch unterschiedlichen Handgrößen, als auch durch unterschiedliche Entfernungen von der Kamera lässt sich durch eine Standardisierung der Werte verringern. Eine solche Repräsentation erlaubt nach Durchführung einer Fast-Fourier-Transformation einen sehr schnellen und robusten Abgleich mit Referenzaufnahmen, sodass eine beschränkte Anzahl an Posituren eindeutig erkannt werden kann. Geeignete Toleranzwerte für diesen Abgleich müssten dann experimentell bestimmt werden. Grundlage für eine solche Gestenerkennung ist eine Datenbank mit einer möglichst großen Datenmenge. Bei eingeschränkter Positurenanzahl, ist diese noch per Hand befüllbar, soll aber eine große Anzahl an Posituren erkannt werden, wird diese Datenbank extrem groß, sodass zumindest eine semi-automatische Befüllung mit teilweise synthetischen Daten angedacht werden sollte. So benutzen Athitsos et al. [8] beispielsweise verschiedene Bilder in ihrer Datenbank, von denen ein großer Anteil synthetisch erstellt wurde. 44

45 4. Berührungslose Gestensteuerung: Technischer und algorithmischer Hintergrund Es ist zu erwarten, dass in Zukunft Algorithmen entwickelt werden, die eine Positions- und Positurenerkennung der Hand nur mit Hilfe von Einzelbildern ohne Einschränkung der akzeptierten Posituren in Echtzeit realisieren. Dafür spricht beispielsweise der erst kürzlich 9 veröffentlichte Algorithmus von Shotton et al. [64], der auch im Microsoft-Xbox-Kinect-System Verwendung findet und genau diese Einzelbilderkennung mit Hilfe eines Structured-Light-Tiefenbilds (s. Paragraph über Streifenprojektionsverfahren in Abschnitt 4.1) für die Ganzkörperpositurerkennung umsetzt. Hier wird eine Datenbank von ca Frames verwendet, die Aufnahmen von Personen in verschiedenen Körperposituren zeigen 10. Eine entsprechende Lösung für die Handerkennung ist uns nicht bekannt, aber insbesondere nach der erfolgreichen Implementierung des entsprechenden Ganzkörpererkennungsalgorithmus in naher Zukunft zu erwarten. Dass zunächst Lösungen für die Ganzkörpererkennung publik werden, liegt eventuell daran, dass diese auf das Erkennen einzelner Körperteile abzielen und dies bei der Handerkennung insofern komplizierter ist, als dass die einzelnen Teile der Hand (es käme lediglich eine Einteilung in Finger, Daumen und die Handfläche in Frage) sich weniger stark von einander unterscheiden als Körperteile. Ein solider Algorithmus dieser Art würde jedoch nicht mehr nur als Initialisierungshilfe für die Trackingalgorithmen aus Schritt III fungieren, sondern diese gänzlich obsolet machen. Momentan ist dieser Stand jedoch noch nicht erreicht, wie beispielsweise auch Athitsos et al. in ihrem erst 2010 erschienenen Artikel feststellen: We need to specify [...] that, in a real-world system, reliable recognition of handshapes of arbitrary 3D orientation from a single image is beyond the current state of the art. 11 [8] Beim Einsatz ihres Systems schlagen sie daher vor, für eine genaue Positurenerkennung zum Beispiel ein zusätzliches Hand-Tracking-System einzusetzen. Bei so großen Datenbanken, die in so kurzer Zeit durchforstet werden müssen, ist es offensichtlich, dass die Optimierung der Datenbanken und der eingesetzten Suchalgorithmen ein entscheidender Punkt in der Gestaltung solcher Systeme ist. Diese zu erläutern würde jedoch den Rahmen dieser Arbeit sprengen Schritt IIIa Hand verfolgen und Handpositur erkennen: Tracking des gefundenen Objekts Da der Einsatz von Echtzeit-Einzelbildalgorithmen wie angesprochen noch sehr schwierig ist, ist der nächste Schritt, nachdem die Hand in der Positur der statischen Aktivierungsgeste vorgefunden wurde, die gefundene Hand zu verfolgen (englisch: tracking). Die folgenden Absätze sollen 9 Vorveröffentlichung des Artikels am unter pubs/default.aspx?id= Hier wurde beim Lernprozess darauf geachtet, dass die Personen in ihrem Körperbau stark variieren, um ein sogenanntes Overfitting zu vermeiden, was zur Folge hätte, dass der Algorithmus auch beim späteren Erkennungsprozess nicht mit der Varianz im Körperbau unterschiedlicher Benutzer umgehen könnte. 11 zu deutsch: Wir müssen [...] angeben, dass unter realen Bedingungen eine zuverlässige Erkennung von Handformen in willkürlicher Orientierung im Raum nur mit Hilfe eines einzelnen Bildes den momentanen Stand der Technik übersteigt. 45

46 4. Berührungslose Gestensteuerung: Technischer und algorithmischer Hintergrund dazu wichtige Algorithmen, Konzepte und einige modellbasierte Lösungsansätze vorstellen, deren Anwendung in unserem Fall denkbar wäre. Einige davon lassen sich auch kombinieren oder bauen aufeinander auf. Die zunächst behandelten Kalman-Filter sind zwar in ihrer Grundform nur für lineare dynamische Systeme brauchbar, haben aber in ihrer erweiterten Form, dem erweiterten Kalman-Filter (EKF), sehr große Verbreitung gefunden. Darüber hinaus lässt sich das grundsätzliche Problem und der grundsätzliche Lösungsansatz hier sehr anschaulich erklären, was zum erleichterten Verständnis der treffenderen, aber komplexeren Ansätze beiträgt, die im Anschluss besprochen werden. Ein solcher treffenderer Ansatz ist beispielsweise das Konzept des Versteckten Markow- Modells (Hidden Markov Model, HMM) 12 und die darauf basierenden Algorithmen ein HMM ähnelt einem linearen dynamischen System, passt aber auf Grund des Wegfalls einiger Einschränkungen besser auf das Gestenerkennungsproblem. Zum Schluss dieses Abschnitts soll auf Partikelfilter eingegangen werden, auch als sequentielle Monte-Carlo-Methoden bezeichnet, die zur Zeit die beste Approximation an die optimale Abschätzung ermöglichen. Lineare dynamische Systeme: Kalman-Filter. Eine Möglichkeit, trotz des in Abschnitt besprochenen Messproblems den versteckten tatsächlichen Zustand eines Objektes zu erkennen, ist der Einsatz eines sogenannten Kalman-Filters 13 (KF). Das grundsätzliche Prinzip sieht vor, zu jeder Messung, die vom Objekt vorgenommen wird, die bereits angesprochene Unsicherheit abzuschätzen, mit der diese Messung belastet ist. Mit jeder neuen Messung kann die Aussage über den Zustand verfeinert werden, wobei die zugehörige Messungenauigkeit die Gewichtung jeder Messung bestimmt: Messungen mit hoher Unsicherheit haben weniger Auswirkung auf das Gesamtergebnis als Messungen mit niedriger Unsicherheit. Aus den beiden Teil- Unsicherheiten wird außerdem eine neue Gesamtunsicherheit für das Gesamtergebnis ermittelt, sodass diese Kombination aus zwei Messungen für weitere Messwertvereinigungen wie eine einzige behandelt werden kann. Dadurch wird erreicht, dass von der Vergangenheit des Systems lediglich ein Schritt zurück bekannt sein muss. Ausgehend von diesem Grundprinzip können nun außerdem vorhersagbare Zustandsabweichungen von einer Messung zur nächsten einberechnet werden, indem die vorherige Messung k-1 zunächst interpoliert wird, bevor sie im Verfeinerungsschritt mit der aktuellen Messung k gewichtet verrechnet wird. Ein solcher Faktor wäre bei Positionsmessungen eines Objektes beispielsweise eine bekannte Geschwindigkeit. Das Prinzip dahinter ist also: Wenn ich bereits weiß, dass die Messung k-1 zum Zeitpunkt der aktuellen Messung k veraltet ist, und wenn ich ebenfalls sowohl weiß, in welcher Art und Weise, als auch in welchem Ausmaß sie veraltet ist, dann ist es nur logisch und folgerichtig, zunächst die zu erwartenden Zustandsabweichungen mit einzuberechnen, bevor ich sie mit Messung k vereinige. Diese beiden Phasen werden auch als Vorhersage- und Aktualisierungsschritt bezeichnet. Zu den berücksichtigbaren Abweichungen gehören: 1. Dynamische Abweichungen (zum Beispiel bekannte Geschwindigkeiten, oder konstante Beschleunigungen englisch: dynamical motion), 12 Die eingedeutschte Variante findet sich in der Literatur nur sehr selten, sodass wir im Folgenden die sehr viel weiter verbreitete englische Bezeichnung verwenden wollen. 13 Der Kalman-Filter stellt eine Form so genannter Bayes scher Netze dar. Da die zu ermittelnden Zustände über die Zeit veränderlich sind, spricht man von einem dynamischen Bayes schen Netz. 46

47 4. Berührungslose Gestensteuerung: Technischer und algorithmischer Hintergrund 2. kontrollierte Abweichungen (von außen induzierte Bewegungen, deren Art und Ausmaß wir kennen, zum Beispiel Bewegung der Kamera nach bestimmten Parametern englisch: control motion) und 3. zufällige Abweichungen (weder berechenbare noch kontrollierte Zustandsänderungen von aufgenommenen Objekten englisch: random motion). Während die ersten beiden Arten von Abweichungen mit in die Interpolation der Messung k-1 einbezogen werden können, wird der dritten Kategorie Tribut gezollt, indem die erwartete Zustandsvarianz erhöht wird. Problematisch ist, dass bei einfachen Kalman-Filtern davon ausgegangen werden muss, dass diese unkontrollierbaren Abweichungen im Gauß schen Sinne normalverteilt sind eine solche Annahme ist entweder möglich, wenn es sich tatsächlich so verhält, oder, wenn die Annahme einer Normalverteiltheit, obwohl die Verteilung nicht tatsächlich bekannt ist, keine gravierenden negativen Auswirkungen hat [13]. Theoretisch disqualifiziert diese Einschränkung Kalman-Filter für unser Problem, da die Zustandsabweichungen, die wir behandeln wollen, selbst für die letzte Kategorie zu chaotisch sind: Es handelt sich bei Handbewegungen um selbst-induzierte, nicht kontrollierte Zustandsabweichungen, deren Auftreten eben nicht folgenlos mit einer Gauß schen Normalverteilung beschrieben werden kann. Selbst wenn man diese Tatsache, dass die möglichen Handposituren keiner normalverteilten Varianz unterliegen, ignoriert, sodass diese in die dritte Kategorie passen würden, ist es grundsätzlich problematisch, wenn diese Art der Abweichung zu stark auftritt, da sich das Gegenmittel Erhöhen der tolerierten Zustandsvarianz selbstverständlich auf die Genauigkeit der Zustandserkennung auswirkt. Anders formuliert: Kalman-Filter eignen sich (nur) für Situationen, die als lineare dynamische Systeme beschrieben werden können. Das sind sehr grob zusammengefasst die Systeme, in denen wir zum einen von einer Gauß sche Wahrscheinlichkeitsverteilung beim ersten gemessenen Zustand und zum anderen von linearer Abhängigkeit aller weiteren (versteckten) Zustände ausgehen können. Für diesen sehr speziellen Fall stellen sie die optimale Lösung dar. Auf die Situation, die uns bei der Handgestenerkennung vorliegt, trifft diese Annahme jedoch eben gerade nicht zu. Um Kalman-Filter trotzdem auf nicht-linearen Systemen anzuwenden, werden sogenannte erweiterte Kalman-Filter (englisch: Extended Kalman Filter, EKF) eingesetzt, die zwar das Grundproblem nicht lösen, aber praktisch die Unzulänglichkeiten umgehen, indem die nicht-lineare Verteilung jeweils lokal linearisiert wird [70]. Bei Kalman-Filtern handelt es sich um eine Methode, bei der nur eine Hypothese weitergereicht wird 14. Die Nachteile solcher Verfahren wurden in Abschnitt bereits angesprochen. Hidden Markov Modelle: Viterbi- und Baum-Welch-Algorithmus. Wie bereits mehrfach angedeutet, lässt sich die Handerkennungssituation sehr treffend mit einem Hidden Markov Model (HMM) 15 beschreiben. Dieses ist vergleichbar mit dem erwähnten linearen dynamischen 14 Da eine Gauß sche Wahrscheinlichkeitsverteilung angenommen wird, wären zusätzliche Hypothesen auch gar nicht sinnvoll, da es unter dieser Voraussetzung ohnehin nur ein einziges Wahrscheinlichkeitsmaximum geben kann. Dies wird anschaulich, wenn man sich beispielsweise die Gauß sche Glockenkurve vor Augen führt, die für dreidimensionalene Zustandsräume die Verteilung repräsentieren kann und eben nur eine Spitze hat. 15 In unserem Fall handelt es sich um HMMs erster Ordnung, da die Zustandswahrscheinlichkeitsverteilung von nur einem Schritt in die Vergangenheit benötigt wird, um Wahrscheinlichkeitsprognosen für den nächsten Zustand 47

48 4. Berührungslose Gestensteuerung: Technischer und algorithmischer Hintergrund System, das den Kalman-Filtern zu Grunde liegt, unterliegt aber nicht den angesprochenen Einschränkungen (Gauß sche Grundverteilung, zeitlich lineare Abhängigkeit der Zustände) 16. Der kontinuierliche Zustandsraum muss hierzu in diskrete Zellen [7] unterteilt werden (möglichst dicht, um sich von der eigentlichen Kontinuität des Zustandsraumes nicht zu weit zu entfernen) und wird dann in Form einer Markow-Kette modelliert. Markow-Ketten erlauben unter Berücksichtigung der unmittelbaren vorherigen Zustände eine Wahrscheinlichkeitenberechnung zukünftiger Zustände, d.h. eine Zustandsvorhersage. Zu diesem Zweck müssen die Übergangswahrscheinlichkeiten von einem Zustand auf die möglichen folgenden Zustände bekannt sein 17. Da auch hier nicht direkt auf die tatsächlichen Zustände, d.h. die Markow-Ketten zugegriffen werden kann (s. weiter oben besprochene Messproblematik), wird auch hier von versteckten Markow-Ketten seien versteckt (englisch: hidden). Diese Verstecktheit bedingt, dass wir eine zweite Wahrscheinlichkeitenebene einführen müssen, die zunächst die Beobachtungen mit den dahinter steckenden Zuständen verknüpft (ähnlich wie der Kalman-Filter). Wir reden also von zwei miteinander verwobenen Wahrscheinlichkeitsprozessen. Eine sehr anschauliche Beschreibung von HMMs findet sich in einer häufig zitierten Anleitung zum praktischen Einsatz von HMMs von Rabiner [61]. Rabiner zeigt folgende drei Problemstellungen im Umgang mit HMMs auf: 1. Evaluation der Wahrscheinlichkeit, dass eine Beobachtungssequenz von einem spezifischen HMM generiert werden kann (lösbar mit dem sogenannten Vorwärts-Algorithmus), 2. Optimale Annäherung der Zustandssequenz, die einer Beobachtungssequenz zu Grunde liegt (lösbar mit Vorwärts-Rückwärts-Algorithmus oder noch effizienter mit dem Viterbi- Algorithmus) und 3. Bestimmung der optimalen Parameter eines HMMs unter Vorgabe einer Beobachtungssequenz (lösbar mit dem Baum-Welch-Algorithmus). Das erste Problemfeld behandelt das Problem, das wir eigentlich und hauptsächlich gelöst haben wollen: Wir haben eine Beobachtungssequenz (das sind mehrere Bilder eines Kamerastreams, auf dem eine Hand in über der Zeit variierenden Posituren und Positionen zu sehen ist) und können mit dem Viterbi-Algorithmus aus dieser den eigentlichen Zustand zum jeweils aktuellen Zeitpunkt herausfinden. Der Baum-Welch-Algorithmus aus 3. ist für die Vorbereitung unverzichtbar, dies ist die Lern- oder Trainingsphase, die für gewöhnlich off-line geschieht. Die verschiedenen Parameter des Modells insbesondere die Zustandswahrscheinlichkeiten und Übergangswahrscheinlichkeiten zwischen den Zuständen können hiermit gesetzt und angepasst werden, wenn dem Algorithmus typische Ausgabesequenzen gegeben werden, aus denen diese Parameter abgeleitet werden können, also Aufnahmen typischer Handbewegungsabläufe. Auch das erste Problemfeld ist für uns interessant: Mit dem Vorwärts-Algorithmus könnten wir aufzustellen. Je mehr Schritte in die Vergangenheit bekannt sein müssen, desto höher ist die Ordnung. HMM erster Ordnung sind der Normalfall. 16 Eine genauere Abgrenzung der beiden Systeme findet sich bei Minka [49]. 17 Posituren, die nah an der Positur im vorherigen Frame liegen, sind selbstverständlich zu bevorzugen: Anzunehmen, die jetzige Positur sei ähnlich zur vorherigen, ist erfolgsversprechender, als eine komplett andere Positur zu erwarten, also sind die Übergangswahrscheinlichkeiten zu nahe liegenden Posituren oder gar zur selben Positur höher. Wie diese Übergangswahrscheinlichkeiten tatsächlich ermittelt werden, wird in Kürze angesprochen. 48

49 4. Berührungslose Gestensteuerung: Technischer und algorithmischer Hintergrund zum Beispiel verschiedene 3D-Modelle auf ihre Tauglichkeit als geeignetes Markow-Modell testen. Wenn wir zum Beispiel zwei verschiedene Varianten des 3D-Modells haben, können wir mit Hilfe einer Beobachtungssequenz und dem Vorwärts-Algorithmus testen, welches Modell mit höherer Wahrscheinlichkeit die gegebene Beobachtungssequenz generieren kann, also der Wirklichkeit näher kommt. Es ist offensichtlich, dass es sich durch die vorherige Einteilung eines kontinuierlichen Raumes in diskrete Zellen bei dieser Methode nicht um eine optimale bayes sche Annäherung handeln kann, dennoch ist sie in der Handgestenerkennung weit verbreitet. Bei Just und Marcel [35] findet sich ein auf Handgestenerkennung bezogener Vergleich von normalen HMM mit einer weiterentwickelten Form, den Input/Output HMM (IOHMM), bei der mehrere HMM miteinander verkettet werden. Gesten werden in Gestenklassen zusammengefasst und für jede dieser Klassen ist ein eigenes HMM zuständig. Das eigentliche IOHMM hat als Zustände nur diese Klassen und leitet den Input-Stream weiter an das zuständige Unter-HMM. Übergangswahrscheinlichkeiten sind nun nicht mehr komplett zeitunabhängig, da sie in den einzelnen Unter-HMM variieren können. Auch wird ein weiteres Problem gelöst, das Problem des Zwangs zur Homogenität des Zustandsraumes. Bei normalen HMM ist es nicht möglich, salopp gesagt, bei bestimmten Gesten genauer hinzuschauen, weil sie vielleicht mehr Informationen beinhalten. Mit IOHMM kann, da die Unter-HMM unabhängig voneinander sind, eine solcher inhomogener Zustandsraum realisiert werden. Trotz dieser viel versprechenden Theorie schneiden IOHMM jedoch im Praxistest von Just und Marcel bei der Handgestenerkennung schlechter ab als normale HMM. Es ist abzuwarten, ob die Probleme mit dieser eigentlich vielversprechenden Weiterentwicklung in Zukunft gelöst werden können. Partikelfilter. Als Partikelfilter werden sequentielle Monte-Carlo-Methoden (SMC) bezeichnet. Monte-Carlo-Methoden eignen sich allgemein für Vorhersageprobleme, die nicht direkt gelöst werden können, deren Lösung aber angenähert werden kann, wenn man nur genügend Testläufe (oder Simulationen) durchführt. Sie sind damit eine praktische Anwendung des so genannten Gesetzes der großen Zahl. Der Zusatz sequentiell soll ausdrücken, dass die Methoden on-line, d.h. auf Live-Aufnahmen (in unserem Fall der zu trackenden Hand) angesetzt werden können konkret bedeutet das zum einen, dass die Anzahl der Messungen nicht im Voraus festgelegt sein muss, und zum anderen, dass diese Methoden für den Echtzeit-Einsatz schnell genug sind 18. Entsprechende Filter arbeiten nach einem rekursiven Muster, sie brauchen also nur einen Schritt in die Vergangenheit als Vorwissen. Auch hier werden entsprechend dem Bayestheorem für jeden neuen Zeitpunkt (sprich: jeden neuen Frame oder auch: jede neue Messung) zunächst der Vorhersage- und dann der Aktualisierungsschritt (in dem die Vorhersage mit Hilfe der neuen Messung korrigiert wird) durchgeführt. Die Wahrscheinlichkeitsdichteverteilung, die beim linearen dynamischen System und der Kalman-Filter-Lösung auf eine Gauß sche Normalverteilung festgesetzt wurde, wird bei Partikelfiltern, um auch nicht-normalverteilte Wahrscheinlichkeitsdichten abbilden zu können, als Zusammenstellung vieler einzelner zufällig ausgewählter Zustands-Wahrscheinlichkeits-Paare modelliert, die als Samples oder eben als Partikel bezeichnet werden. Die Auswahl geschieht nach einem gewichteten Zufallsprinzip, das dafür sorgt, dass 18 Nicht-Sequentielle Verfahren sind zum Beispiel die Markow-Ketten-Monte-Carlo-Verfahren (Markov chain Monte Carlo methods, MCMC). 49

50 4. Berührungslose Gestensteuerung: Technischer und algorithmischer Hintergrund das Sample-Set bevorzugt aus den Bereichen zusammengestellt wird, die eine hohe Wahrscheinlichkeit haben, den richtigen Zustand zu beinhalten. Dieses Auswahlverfahren ist allgemein als Importance Sampling und die bisher beschriebene Art von Partikelfiltern daher auch als Sequential Importance Sampling (SIS) bekannt. Sequentiell sind sie zum einen wie angesprochen wegen der rekursiven Arbeitsweise und zum anderen, da die Größe des Sample-Sets an die zur Verfügung stehende Rechenleistung angepasst und damit die Bearbeitung in Echtzeit gewährleistet werden kann. Wird eine ausreichend hohe Anzahl dieser Partikel verarbeitet, stellen Partikelfilter eine Annäherung an die optimale Bayes sche Abschätzung des Zustands dar. Partikelfilter können daher als generalisierte Version von Kalman-Filtern angesehen werden, die ja wie erläutert unter ganz bestimmten Einschränkungen ebenfalls eine optimale Abschätzung liefern [7]. Jedes dieser Paare ist eine weitergereichte Hypothese, wodurch klar wird, dass es sich bei Partikelfiltern im Gegensatz zum Kalman-Filter um Mehr-Hypothesen-Tracking-Ansätze (englisch: multiple hypotheses tracking, MHT) handelt. Es ist wichtig anzumerken, dass SIS-Partikelfilter trotz der soeben vorgestellten vielversprechenden Theorie als praxisuntauglich gelten [21], da sich das Sample-Set, wenn sich die Zustände von Frame zu Frame zu wenig ändern, nach wenigen Iterationen festgefahren hat. Das bedeutet, dass einige wenige dieser Samples eine immer höhere Wichtigkeit erlangen, während der Großteil der Samples eine Wichtigkeit nahe Null besitzt. Es wird also sehr viel Rechenleistung verschwendet, um Partikel zu berechnen, die ziemlich sicher nicht viel über den tatsächlichen Zustand des beobachteten Objekts auszusagen haben. Deshalb ist es wichtig, das Sample-Set nach jedem Schritt neu zu wählen, indem unwichtige Samples aus dem Set entfernt werden und durch Samples ersetzt werden, die sich in der Nähe der wichtigen Samples befinden. Dieses Verfahren wird als Resampling bezeichnet und bewirkt, dass bestimmte Partikel, die eine größere Aussagekraft haben, häufig in der Stichprobe auftauchen, während unwichtigere Partikel im Extremfall vielleicht gar nicht berücksichtigt werden. Diese Abwandlung der SIS-Partikelfilter wird als Sequential Imporance Resampling (SIR) bezeichnet und ist sehr weit verbreitet, zum Beispiel in Form des weit verbreiteten CONDENSATION-Algorithmus [33] Schritt IIIb: Handmodellerstellung Beim Erstellen eines Handmodells für den Fall der Gestenerkennung sind nicht alle Eigenschaften der Hand gleichwichtig. Einige können (und sollten aus Effizienzgründen) weggelassen werden. Wichtig ist zunächst einmal das Skelett der Hand, das vereinfacht gesprochen aus verschiedenen unbiegsamen Elementen, d.h. den Knochen besteht, und den Punkten, an denen diese Elemente miteinander verknüpft sind, d.h. den Gelenken. Wir beginnen daher mit einer präziseren Begriffsklärung dieser für uns wichtigen Handelemente (vergleiche ergänzend da- DIP PIP MCP Handgelenk Fingerendglied Fingermittelglied Fingergrundglied Mittelhand IP MCP Abbildung 4.10.: Stark vereinfachte Darstellung der Knochen und Gelenke der Hand (basierend auf ähnlicher Abb. in [41]). 50

51 4. Berührungslose Gestensteuerung: Technischer und algorithmischer Hintergrund zu Abb. 4.10): Die Fingergliedknochen (lat.: Phalanx, Phalangis, f.) sind grundsätzlich in Fingerendglieder (Phalanx distalis), Fingermittelglieder (Phalanx media) und Fingergrundglieder (Phalanx proximalis) unterschieden. Bei den Daumen fehlt das Fingermittelglied. Die Finger sind verbunden mit den Mittelhandknochen (Metacarpus, -i), die jeweils mit den Handwurzelknochen verbunden sind. Letztere werden jedoch in den meisten Fällen nicht modelliert. Die Gelenke zwischen Fingern beziehungsweise Daumen und Mittelhand werden als Fingergrundgelenke oder Metacarpophalangealgelenke (MCP-Gelenke) bezeichnet. Die Fingergelenke zwischen den einzelnen Fingergliedknochen werden auch Interphalangealgelenke (IP) genannt. Während der Daumen nur eines dieser Gelenke hat, wird bei den Fingern zusätzlich in Fingermittelgelenke (proximale IP-Gelenke, PIP) und Fingerendgelenke (distale IP-Gelenke, DIP) unterteilt. Gelenke verfügen über eine unterschiedlich hohe, aber bestimmte Anzahl an Freiheitsgraden 19. In der tatsächlichen Bewegungsfreiheit innerhalb der von den Freiheitsgraden vorgegeben Richtungen gibt es ebenfalls Beschränkungen: Finger können beispielsweise an den einzelnen Mittelgelenken und Endgelenken zwar abgeknickt werden, aber nur in Richtung Handfläche. Eine Berücksichtigung dieser Einschränkungen der Bewegungsfreiheit ist sehr hilfreich, da sie die erwartete Anzahl möglicher Posituren, also die erwartete Zustandsvarianz minimiert. Lin et al. [41] haben zur genauen Ermittlung der Bewegungseinschränkungen Daten mit einem Datenhandschuh aufgenommen und analysiert. Sie teilen die vorhandenen Beschränkungen in drei Kategorien ein: 1. Statische Einschränkungen diese Einschränkungen resultieren aus den anatomischen Gegebenheiten der Hand. DIP- und PIP-Gelenke sind beispielsweise nur in eine Richtung beweglich und können ohne äußere Kraftzufuhr nicht zum Handrücken hin abgeknickt werden. 2. Dynamische Einschränkungen hier handelt es sich um Einschränkungen, die verschiedene Gelenke im Zusammenspiel miteinander verursachen. Diese können innerhalb eines Fingers bestehen (DIP-Gelenke lassen sich nicht abknicken, ohne dass auch das zugehörige PIP-Gelenk abgeknickt wird) oder auch zwischen mehreren Fingern (wird der Zeigefinger am MCP-Gelenk abgeknickt, wird für gewöhnlich auch das MCP-Gelenk des Mittelfingers leicht mit abgeknickt). 3. Natürliche Bewegungen Einschränkungen dieser Art ergeben sich aus natürlichen Bewegungen, ein Beispiel ist zu beobachten, wenn man ausgehend von einer offenen Hand eine Faust machen soll: Die meisten Menschen beugen dazu natürlicherweise alle Finger gleichzeitig, obwohl es theoretisch auch möglich wäre, die Finger einzeln oder unterschiedlich schnell in die Endposition zu bewegen. Dabei ist festzuhalten, dass es nicht nur darum geht, die Wirklichkeit besonders realistisch darzustellen, sondern auch darum, wie dieses bei gleichzeitiger Minimierung der Komplexität des Modells zu erreichen ist. So argumentieren beispielsweise McDonald et al. [45], dass die Mittel- 19 Alle IP haben jeweils einen, der MCP des Daumen ebenfalls, die MCP der Finger haben drei, das Gelenk zwischen Daumen und Handgelenk hat zwei und das Handgelenk selbst hat sechs [14]. 51

52 4. Berührungslose Gestensteuerung: Technischer und algorithmischer Hintergrund handknochen ohne große Probleme als komplett statisch modelliert werden können 20, obwohl die zum kleinen und zum Ringfinger gehörenden Mittelhandknochen in der Realität durchaus in geringem Maße beweglich sind. Die MCP-Gelenke müssen dafür so gestaltet werden, dass der Effekt der gegenseitigen Fingerannäherung beim Abknicken der Finger am MCP-Gelenk gewährleistet bleibt, der eigentlich durch die Beweglichkeit der Mittelhandknochen entsteht. Das Ziel solcher Maßnahmen ist es, so wenig Freiheitsgrade und bewegliche Elemente einzusetzen wie für ein brauchbares Modell nötig. Im konkreten Einsatz kann das Modell, wie bei Delamarre und Faugeras [20] beschrieben, mit Hilfe simulierter Kräfte in die verschiedenen Posituren gedrückt werden, die am besten die aus dem Tiefenbild rekonstruierte Wirklichkeit wiedergeben, also in die als Hypothesen genutzten Zustände. Dazu muss selbstverständlich auch die Haut zwischen den Elementen des Skeletts berücksichtigt werden. Die Umsetzung dieser Anforderung variiert stark vom Einsatz simpler primitiver Körper um die Knochenelemente herum [43] bis zu realitätsnaher Modellierung mit Hilfe von B-Splines und Polygonen [14, 15]. Werden nur 2D-Kameratechniken eingesetzt, sodass im Endeffekt ohnehin nur die Silhouette das Vergleichskriterium ist, sind hochdetaillierte volumetrische Modelle eindeutig über das Ziel hinausgeschossen, bei einem Abgleich mit einem Tiefenbild kann ein komplexeres 3D-Modell jedoch trotz erhöhten Rechenaufwands seine Berechtigung haben. Es ist allgemein wichtig, hier ein gutes Mittelmaß zwischen benötigter Rechenleistung und Genauigkeit zu finden. Ein Problem, das bei vielen modellbasierten Algorithmen auftritt, ist die Kalibrierung des Handmodells auf die Hand des aktuellen Nutzers. Hände variieren so stark in der Größe, dass die einfache Nutzung einer durchschnittlichen Hand nicht möglich ist. Auch wenn wir keine entsprechenden Umsetzungen in der Literatur finden konnten, erscheint es uns in unserem Fall als gangbarer und als bester Weg, mit Hilfe des Tiefenbilds bei der ersten Nutzung des Systems (oder je nach Performanz des Systems auch bei jeder erkannten Aktivierungsgeste) eine Messung der Handgröße durchzuführen und das Modell automatisch anzupassen Schritt IV Gesten erkennen: Interpretation der festgestellten Handposituren und -bewegungen Es ist zwar ein hehres Ziel, alle möglichen, vielleicht auch halbverdeckten oder gar auch unbewusst getätigten Gesten des Menschen erkennen und interpretieren zu wollen. Zumindest in unserem Fall genügt es jedoch, nur ein bestimmtes Repertoire an bedeutungsvollen Gesten, die direkt an das System gerichtet sind, zu erkennen zu versuchen. Diese Einschränkung lässt sich leicht durchsetzen, da der Benutzer ohnehin nur gezielt und nur in einem klar definierten Anwendungsfeld mit dem System kommunizieren soll. Es gibt in unserem System zum einen statische Gesten, bei denen einfach nur gemeldet werden muss, dass sie momentan vorzufinden sind (größtenteils so genannte ikonische Gesten), und dynamische Gesten, bei denen darüber hinaus genaue Positionsänderungen der Hand wichtig sind. Die Position der Hand im Raum beziehungsweise im Bild ist also nur in Relation zur vorherigen Position interessant, jedoch nicht als 20 Eine Ausnahme bildet der zum Daumen führenden Mittelhandknochens, der nicht so vereinfacht repräsentiert werden kann. 52

53 4. Berührungslose Gestensteuerung: Technischer und algorithmischer Hintergrund absoluter Wert 21. Wie von Just und Marcel [35] ausgeführt, ist das Problem aufgeteilt in die Teilprobleme der Gestenfindung und der Gestenklassifikation (englisch: spotting und classification). Ersteres ist das Problem des Erkennens von Anfang und Ende einer bestimmten Geste innerhalb eines Datenstroms verschiedener gezeigter Posituren. Das Problem der Klassifikation hingegen ist das nachgeordnete Problem, eine bereits abgegrenzte Positur oder Positurenfolge einer Geste zuzuordnen. Ist eine definierte statische oder dynamische Geste erkannt, muss anschließend analysiert werden, welche Funktionalität damit im Interface ausgelöst wird. Dieser letzte Schritt ist Teil des eigentlichen Interfaces. Es ist verbreitet, Systeme in zwei Ebenen aufzuteilen, bei denen die eine Ebene für die Gestenerkennung zuständig ist und die obere Ebene die Interpretation und Umsetzung der zugehörigen Befehle übernimmt. Eine genauere Beschreibung geeigneter Interfaces sowie eine Übersicht benötigter Gesten ist Teil von Kapitel Würden wir Zeigegesten implementieren wollen, sähe die Situation ganz anders aus. Neben der Berechnung der Zeigerichtung ist auch eine Berechnung der genauen Position der erkannten Hand im Raum oder zumindest in Relation zum Monitor von Nöten. Eine entsprechende Umsetzung ist zum Beispiel bei Graetzel et al. zu finden. 53

54 5 Entwurf eines berührungslosen Interfaces Dieses Kapitel stellt den Entwurf des Interfaces und den Weg dahin vor. Da bei all diesen Ausführungen die Gebrauchstauglichkeit eine entscheidende Rolle spielt, soll Abschnitt 5.1 zunächst auf die Gebrauchstauglichkeit in Bezug auf unser System eingehen, bevor in Abschnitt 5.2 ein Interface-Konzept für das System entwickelt wird. Die in Kapitel 3 erörterten funktionalen Anforderungen sollen Grundlage für die Entwicklung von den Entwürfen unserer Anwendung sein. Dieser Abschnitt beschäftigt sich zunächst mit der Konzeption einer grafischen Benutzeroberfläche und setzt sich des Weiteren mit unterschiedlichen Möglichkeiten zur Interaktion mittels Handgesten auseinander. Die allgemeinen Konsequenzen aus Kapitel 5.1, die aus den Erkenntnissen zur Gebrauchstauglichkeit in Bezug auf unser System gezogen werden, fließen jeweils in die Diskussion und Analyse der grafischen Benutzeroberfläche und der Konzeption der Gestensteuerung ein. Im Abschluss dieses Kapitels soll in Abschnitt ein Modell entstehen, das unsere Anforderungen an eine Software zur Visualisierung und Bearbeitung von Planungsdaten während einer Leberresektion erfüllt Aspekte der Gebrauchstauglichkeit Unter dem Oberbegriff Gebrauchstauglichkeit oder Benutzerfreundlichkeit 1 werden ganz allgemein Aspekte zusammengefasst, die die Leichtigkeit der Bedienung (englisch: ease of use) eines System bestimmen. Die Europäische Norm ISO ( Grundsätze der Dialoggestaltung [24]) gibt allgemein folgende sieben Grundsätze vor, die zu erfüllen sind: 1. Aufgabenangemessenheit, 2. Selbstbeschreibungsfähigkeit, 3. Erwartungskonformität, 1 Der Begriff Gebrauchstauglichkeit (englisch: usability) wird trotz leichter Bedeutungsverschiebungen in dieser Arbeit synonym zum Begriff der Benutzerfreundlichkeit (englisch: user-friendliness) genutzt. Ersterer wird von Normungsbehörden auf Grund der Zweideutigkeit des Begriffes Benutzerfreundlichkeit (freundliche Benutzer oder freundlich für den Benutzer?) bevorzugt. 54

55 5. Entwurf eines berührungslosen Interfaces 4. Fehlertoleranz, 5. Steuerbarkeit, 6. Individualisierbarkeit und 7. Lernförderlichkeit. Die Gewichtung dieser Grundsätze kann von System zu System variieren. Da wegen der hohen sonstigen Arbeitsbelastung der potenziellen Benutzer eine lange Einarbeitungsphase vermieden werden soll, muss besonders auf Selbstbeschreibungsfähigkeit geachtet werden, was bei einer noch nicht sehr weit verbreiteten und damit noch relativ ungewohnten Interaktionsform wie der Gestensteuerung eine große Herausforderung darstellen kann. Ebenfalls ergibt sich aus diesem Umstand die Forderung nach einer schnell ansteigenden Lernkurve während der Benutzung. Auch sollte viel Wert auf Fehlertoleranz gelegt werden, da bei der eher geringen Nutzungshäufigkeit, die bei unserem System zu erwarten ist, Fehlbedienungen vermehrt zu erwarten sind. Aufgabenangemessenheit, Steuerbarkeit und Erwartungskonformität sind unserer Auffassung nach allgemein wichtige Faktoren, die aber in unserem Fall weder überdurchschnittlich hohe Aufmerksamkeit verlangen, noch mit Einschränkungen versehen werden sollten, wohingegen der Stellenwert der Individualisierbarkeit ebenfalls auf Grund der geringen Nutzungshäufigkeit vermutlich am ehesten herabgestuft werden dürfte. In einem ähnlichen Ansatz gibt Usability-Experte Jakob Nielsen 2 folgende etwas konkreter formulierten Grundsätze zur Benutzerschnittstellengestaltung an (Übersetzungen und Anmerkungen in Klammern von uns): 1. Use simple and natural dialogue ( Benutze eine einfache und natürliche Dialogform ; eine Forderung, deren Umsetzung um in den Kategorien der ISO-Norm zu sprechen zur Aufgabenangemessenheit sowie zur Lernförderlichkeit des Systems beiträgt), 2. Speak the user s language ( Sprich die Sprache des Nutzers ; diese Forderung fällt in den Bereich Erwartungskonformität der ISO-Norm, wir interpretieren diese Vorgabe nicht nur bezogen auf gesprochene/geschriebene Sprache, d.h. fachbezogen die richtigen Begrifflichkeiten zu verwenden, sondern auch auf die Gestenauswahl), 3. Minimize user memory load ( Minimiere das zu Merkende ; ergibt sich aus guter Selbstbeschreibungsfähigkeit des Systems), 4. Be consistent ( Sei konsistent ; dies fällt ebenfalls in den Bereich des ISO-Grundsatzes der Erwartungskonformität, zielt aber eher auf die vom System selbst aufgebauten Erwartungen ab und nicht wie Punkt 2 auf die bereits vor Nutzung des Systems vorhandenen Erwartungen), 5. Provide feedback ( Gib Rückmeldung ; fällt in den Bereich der Steuerbarkeit), 6. Provide clearly marked exits ( Stelle klar erkennbare Ausstiegspunkte zur Verfügung ; ebenfalls Steuerbarkeit), 2 zitiert nach (Michael) Nielsen et al. [53], ursprünglich veröffentlicht von (Jakob) Nielsen [52]. 55

56 5. Entwurf eines berührungslosen Interfaces 7. Provide shortcuts ( Stelle Abkürzungen/Shortcuts zur Verfügung ; ist hauptsächlich der Aufgabenangemessenheit zuträglich), 8. Provide good error messages ( Gib gute Fehlermeldungen aus ; Teil der Selbstbeschreibungsfähigkeit) und 9. Prevent errors ( Beuge Fehlern vor ; ist verwandt, aber nicht gleichzusetzen mit der in der ISO-Norm geforderten Fehlertoleranz). Nielsen et al. behaupten, dass die Benutzerfreundlichkeit der Gestensteuerung an sich im Vergleich mit anderen Eingabeformen als sehr hoch bewertet werden könne, insbesondere da der Benutzer kein Eingabegerät aufgezwungen bekomme und dadurch keine äußeren Kräfte wie etwa bei der Mausbenutzung zu ertragen habe. Unserer Einschätzung nach kann diese These nicht so allgemein und anwendungsunbezogen stehen bleiben, da insbesondere bei Präzisionsarbeiten zu diskutieren wäre, ob nicht andere Eingabemöglichkeiten zu besseren Ergebnissen führen können und ob diese leicht zu erreichenden besseren Ergebnisse nicht eher für eine hohe Benutzerfreundlichkeit sprächen als das Freisein von äußeren Kräften, die man sonst zu ertragen hätte. Die Abwägung verschiedener Eingabemethoden wurde bereits ausführlich in Abschnitt 2.2 diskutiert, sodass wir uns in diesem Abschnitt stattdessen darauf konzentrieren wollen, wie man unter der schon gegebenen Entscheidung für die Nutzung einer Gestensteuerung diese eben besonders gut gestalten kann. Wir wollen in diesem Abschnitt sowohl auf die ISO-Norm, als auch auf Jakob Nielsens Empfehlungen Bezug nehmen. Der Unterpunkt befasst sich mit der Definition eines optimalen Gestenvokabulars, Unterpunkt behandelt Ansätze zur Aktivierung der Gestensteuerung. Während der Bearbeitung dieser Bachelorarbeit wurden auf Grund der Aktualität 3 des Themas sehr viele gestensteuerungsbasierte Ansätze im Internet (häufig über Videovorführungen) vorgestellt, zu denen (noch) keine wissenschaftlichen Ausarbeitungen vorliegen. Wir werden in diesem Abschnitt auch auf diese Ansätze eingehen, können jedoch nur auf die Informationen zugreifen, die den Präsentationen zu entnehmen sind Definition des Gestenvokabulars Nach Stern et al. [65] ist bei der Gestaltung eines optimalen Gestenvokabulars sowohl auf menschliche wie auch auf technische Aspekte zu achten. Zu erster Kategorie gehören dabei Dinge wie Natürlichkeit, Lern- und Merkförderlichkeit der Gesten, sowie zu erwartende Ermüdungserscheinungen (vergleiche dazu auch das sogenannte Gorillaarm-Syndrom bei vertikalen Touchscreens 4, das selbstverständlich bei Gestensteuerungen auch vielleicht sogar in noch 3 Microsoft bringt mit der Kinect im November 2010 das erste erschwingliche Consumer-Produkt dieser Klasse auf den Markt, das bald darauf mit OpenKinect und OpenNI (vergleiche: Abschnitt??: OpenKinect vs. OpenNI) auch für andere Systeme als die Xbox 360 erschlossen wird. 4 Das Phänomen des Gorilla-Arms wird beispielsweise bei Wachs et al. [68] angesprochen, eine viel schöner formulierte Zusammenfassung findet sich jedoch im englischen Wikipedia-Artikel über Gesture Recognition: Designers of touch-menu systems failed to notice that humans aren t designed to hold their arms in front of their faces making small motions. After more than a very few selections, the arm begins to feel sore, cramped, and oversized the operator looks like a gorilla while using the touch screen and feels like one afterwards. [...] Gorilla arm is 56

57 5. Entwurf eines berührungslosen Interfaces größerem Maße eine Rolle spielen kann), zu den technischen Aspekten gehört hauptsächlich die Erkennungsrate durch den eingesetzten Gestenerkennungsalgorithmus (vergleiche: Abschnitt 4.2). Den Ermüdungsfaktor der Gesten beachten Stern et al. in ihrer Methode zur Gestaltung eines optimalen Gestenvokabulars mit dem Aspekt Gestenkomfort, während sie die anderen drei menschlichen Aspekte unter dem Aspekt Gestenintuitivität zusammenfassen. Komfort und Intuitivität des gesamten Vokabulars ergeben sich jeweils aus der Summe der Einzelwerte jeder verwendeten Geste in diesen beiden Kategorien, die jedoch gewichtet summiert werden: Häufig verwendete Gesten geben einen höheren Ausschlag als selten verwendete. Es wird versucht, das Gestenvokabular zu finden, das in diesen menschlichen Aspekten am besten abschneidet unter der Bedingung, dass sich die Erkennungsrate durch den Gestenerkennungsalgorithmus über einem bestimmten Schwellwert befindet. Wird dieser unterschritten, muss eine der Gesten, die am häufigsten mit einander verwechselt werden, ersetzt werden. Die Intuitivität einer Geste kann nur in Bezug auf das zugeordnete Kommando, das damit bewirkt werden soll, bestimmt werden und muss empirisch ermittelt werden, indem man eine Umfrage durchführt, in der für mit Gesten zu belegende Kommandos des Systems nach der intuitiv dazu erwarteten Geste gefragt wird. Daran lässt sich auch klar erkennen, dass ein optimales Gestenvokabular nicht objektiv und allgemein bestimmt werden kann, sondern nur auf das jeweilige System bezogen. Auch wenn Stern et al. dies nicht direkt adressiert, ist gemäß des Grundsatzes Speak the user s language, d.h. der Erwartungskonformität davon auszugehen, dass die Gruppe befragter Personen möglichst deckungsgleich mit der Gruppe potenzieller Benutzer ist. In unserem Fall wäre es also am sinnvollsten, Leute zu befragen, die sich beruflich mit Leberresektionen oder 3D-Modellierung auskennen. Damit kann zum Beispiel sichergestellt werden, dass, wenn von Mitgliedern dieser Gruppe mit bestimmten Kommandos bereits relativ einheitlich bestimmte Gesten assoziiert werden, auch genau diese Gesten verwendet werden entsprechend stellen Nielsen et al. [53] fest, dass die benötigte Gruppengröße sowohl von der Spannbreite der Nutzergruppe abhängt, als auch von der Spannbreite der ersten Ergebnisse. Eine Sonderrolle spielen Kommandopaare (wie links rechts), die mit korrespondierenden Gestenpaaren belegt werden sollten. Gesten, die schwierig auszuführen sind (Stern et al. bezeichnen diese als Gesten, die nur Klavierspieler ausführen können 5 ), sollten selbstverständlich von Anfang an bereits ausgeschlossen worden sein. Auch Nielsen et al. führen aus, dass bestimmte Gesten zwar besonders gut algorithmisch verarbeitet und damit erkannt werden können, diese Tatsache aber nur die zweitrangige Rolle spielen sollte (in Jakob Nielsens Grundsätzen entspricht dies der Forderung nach einer natürlichen Dialogform). Wichtig ist der bereits angesprochene Gestenkomfort, der experimentell empirisch ermittelt werden muss. Während Stern et al. von einer 1:1-Beziehung zwischen Geste und zugehörigem Kommando ausgehen, geben Nielsen et al. zu bedenken, dass es ein wichtiges Ziel ist, die Anzahl zu lernender und zu merkender Gesten gering zu halten. Die Verringerung der Gestenanzahl sei beispielsweise durch kontextabhängige oder zonenabhängige Gesten-Kommando-Zuordnungen möglich. Varianten der erstgenannten Methode wäre beispielsweise in unserem Fall die Festlenot a problem for specialist short-term-use uses, since they only involve brief interactions which do not last long enough to cause gorilla arm. abgerufen am Original: gestures that only piano players can perform 57

58 5. Entwurf eines berührungslosen Interfaces gung, dass ein und dieselbe Geste im 2D-Inspektor eine etwas andere Funktionalität hat als im 3D-Inspektor oder dass die Funktionalität einer Geste vom ausgewählten Werkzeug abhängig ist. Diese Varianten werden in Abschnitt ausführlicher diskutiert. Zonenabhängigkeit wäre beispielsweise gegeben, wenn die gleiche Geste links unten ausgeführt ein anderes Kommando darstellt als rechts unten. Diese Methode setzt unserer Meinung nach voraus, dass der Benutzer gut einschätzen kann, wo die Begrenzungen des aufgenommenen Bildes sind. Den Nachteil der Erfordernis einer entsprechenden Rückmeldung auf dem ohnehin schon knapp bemessenen Bildschirm sehen wir in unserem Fall als gravierender an als die entstehenden Vorteile der Gestenanzahlverringerung. Wie in Abschnitt 4.2 genauer besprochen, schlagen wir eine Zoneneinteilung vor, die den Raum beschränkt, in dem nach Gesten gesucht, beziehungsweise Gesten als solche erkannt werden sollen. Eine weitere Einteilung wäre unnötig kompliziert. Ein wichtiges Fazit ist, dass es kein allgemein als optimal zu bezeichnendes Gestenvokabular gibt, sondern immer nur systembezogen, sodass dieses erst erstellt werden kann, wenn alle benötigten Kommandos feststehen. Ein von uns vorgeschlagenes Gestenvokabular findet sich in Abschnitt Empfangsbereitschaft des Systems Bei Computer-Vision-basierten Computerinteraktionssystemen kann die Bedienung des Geräts häufig aus dem Grund problematisch sein, dass theoretisch jede Handbewegung eine Geste sein könnte, die für das System bestimmt ist. Der Benutzer muss also genau aufpassen, nicht auf das System bezogene Handbewegungen zu vermeiden. Während bei der Mausbedienung dazu kurz die Maus losgelassen wird, ist das bei der Handgestensteuerung nicht so einfach möglich. Dieses Problem wird in der englischsprachigen Literatur oft als Midas Touch problem bezeichnet [36]. Den Namen erhält es vom griechischen König Midas, der sich dem Mythos zu Folge gewünscht hatte, dass alles, was er berührt, zu Gold werde, womit er sich selbst zum Hungertode verurteilte, da auch jegliche Nahrung, die er berührte, unmittelbar zu Gold wurde. Es ist also wichtig, dass für das System eindeutig zu erkennen ist, ob Handbewegungen mit der Intention zum Interagieren mit dem System oder aus anderen Gründen getätigt wurden. Vor dem Hintergrund dieser Problemstellung ist es sinnvoll, zunächst grundsätzlich zu entscheiden, ob das System durchgängig aktiv sein soll oder in einer Art Standby-Modus bleibt, bis es aktiviert wird. Letzteres verringert die Gefahr einer ungewollten Fehlbedienung des Systems, ersteres sorgt für eine schnellere Nutzbarkeit. Da die Bedienung unseres Systems nicht die primäre Aufgabe der Operateure ist, sondern andere Tätigkeiten im Vordergrund stehen, die ebenfalls diverse Handbewegungen erfordern, halten wir es für unabdingbar, das Gerät während dieser Zeit in einen Standby-Modus fallen zu lassen. Es ist zu erwarten, dass der Chirurg die Ansicht nicht nach jedem Handgriff am Patienten neu verstellen möchte, und Aufgaben wie Änderungen der Schnittplanung werden erst recht nicht nebenbei, sondern nur in bestimmten abgrenzbaren Zeiträumen der Systembedienung durchgeführt. Wir halten eine irgendwie gestaltete Form der Aktivierung des Systems daher grundsätzlich für sinnvoll. Während in einem kürzlich vorgestellten Video zum Virtopsy-Projekt der Forensic Research Group der Universitäten Zürich und Bern [67], das eine unserem Ansatz sehr ähnliche Gestensteuerung für Visualisierungssysteme bei Autopsien vorstellt, Sprachkommandos zur Aktivierung des Systems benutzt werden, finden sich in anderen Systemen vorwiegend spezielle Gesten 58

59 5. Entwurf eines berührungslosen Interfaces zur Aktivierung des Systems [27]. Grundsätzlich wären auch andere multimodale Ansätze denkbar, wie beispielsweise ein Aktivierung per Fußpedal. Die in Abschnitt 2.2 besprochenen Vorund Nachteile würden dann grundsätzlich auch für diese Aktivierungsmethoden greifen. Wir schlagen der Einfachheit halber ein unimodales System mit einer klar definierten Aktivierungsgeste vor. Diese Entscheidung hat, wie in Abschnitt 4.2 gezeigt, den zusätzlichen Vorteil, dass sie die Komplexität der Algorithmen zum Auffinden der Hand verringern. Entsprechend dem Grundsatz Gib Rückmeldung muss der Benutzer selbstverständlich darüber informiert sein, ob das System gerade aktiviert ist oder nicht. Beim Virtopsy-Projekt geschieht dies über einen Signalton. Da im Operationssaal jedoch bereits genügend andere Signaltöne verschiedenster Geräte zu hören sind, schlagen wir eine visuelle Rückmeldung vor, etwa durch eine farbige Umrahmung des gesamten Bildschirms. Bei Einsatz des Kinect-Kamera- Sytems, den wir in dieser Arbeit vorschlagen (s. Abschnitt 4.1), wäre zusätzlich die Farbänderung der LED-Leuchte am Gerät denkbar Interface-Konzept In Kapitel 3 haben wir die Funktionen der Software in zwei Bereiche geteilt: den Visualisierungs- und dem Aktualisierungsbereich. Während der Visualisierungsbereich eine Stütze für den operierenden Arzt bei der Resektion sein soll, damit er sich die Planungsdaten nicht nur kognitiv ins Gedächtnis rufen muss, sondern auch visuell dargestellt bekommt, indem er die tomografischen Bilder und auch das Modell der Leber in gewünschter Ansicht und Position erneut digital betrachten kann, sollen im Aktualisierungsbereich die Resektionsschnitte bearbeitet oder neu gesetzt werden. Wir gehen davon aus, dass der Chirurg während der Operation immer mindestens eine Hand am Patienten hat. Es wäre umständlich für ihn, beide Hände von ihrer primären Tätigkeit zu befreien, nur um die Ansicht des digitalen Modells zu verändern. Aufgrund dieser Annahme soll der Visualisierungsbereich, der schließlich auch als parallele Tätigkeit zu der Operation geschehen können soll, nur mit einer Hand bedienbar sein. Weiterhin nehmen wir an, dass die Anpassung und Änderung der Resektionsschnitte nicht geschieht, während gleichzeitig chirurgische Tätigkeiten ausgeübt werden. Es ist kaum vorstellbar, dass der Chirurg beispielsweise einen Resektionsschnitt setzt und derweil eben diesen im digitalen 3D-Modell verändert. Daher kommen wir zu der Schlussfolgerung, dass der Arzt, wenn er die Resektionsschnitte anpassen möchte, beide Hände zur Verfügung hat. Dies bringt uns viele Vorteile auch in Hinsicht darauf, dass im Aktualisierungsbereich weitere funktionale Anforderungen hinzukommen nebst denen, die im Visualisierungsbereich schon vorzufinden sind. Dies macht diesen Bereich wesentlich komplexer und erfordert somit eine Interaktion mit beiden Händen. Aufgrund der Komplexität des Aktualisierungsbereichs und vor allem aufgrund der Tatsache, dass im ersten Schritt die visuelle Unterstützung der Leberresektion im Vordergrund steht, werden wir im Folgenden hauptsächlich auf den Visualisierungsbereich eingehen. Festzustellen ist, dass die GUI des Aktualisierungsbereichs nicht stark von der des Visualisierungsbereichs abweichen sollte, da der Aktualisierungsbereich prinzipiell nur den Visualisierungsbereich um einige Funktionen ergänzt. Sollte das System also erweitert werden, so sollen die GUI und die Ausführung der Grundfunktionen (Transformation, Ändern der Ansicht sowie Fenstern und Durchblättern) gleich bleiben und weitere Funktionen wie das Einzeichnen zusätzlich 59

60 5. Entwurf eines berührungslosen Interfaces gefundener Läsionen und das Setzen des neuen Resektionsschnitts hinzugefügt werden. Eine detaillierte Beschreibung der Interaktion im Aktualisierungsbereich würde den Rahmen unserer Arbeit sprengen, sodass wir uns in diesem Abschnitt nur noch auf die GUI des Systems und die Interaktion im Visualisierungsbereich konzentrieren und nur kurz darauf eingehen, was bei einer Erweiterung des Systems durch den Aktualisierungsbereich hinzukäme. Da die funktionalen Anforderungen unserer Software stark an denen des MeVis LiverAnalyzers angelehnt sind, ist es zunächst sinnvoll, die grafische Benutzeroberfläche dieser Software zu betrachten und daraus Schlüsse für unsere Anwendung zu ziehen. Die beiden Systeme sind zwar grundsätzlich verschieden zu bedienen, dennoch halten wir es für sehr hilfreich, uns zunächst an der GUI des MeVis LiverAnalyzers zu orientieren. Diese Vorgehensweise ist vor allem aufgrund dessen besonders sinnvoll, da diese Software dem Chirurgen im Vorfeld schon bekannt ist. Eine Orientierung am MeVis LiverAnalyzer trägt so maßgeblich zu der Selbstbeschreibungsfähigkeit und der Erwartungskonformität des Systems bei. Abbildung 5.1 zeigt die grafische Benutzeroberfläche des MeVis LiverAnalzers, der in vier Bereiche geteilt ist. Die»1«markiert darin die sogenannte Kollektion, die dem Benutzer viele Abbildung 5.1.: Grafische Benutzeroberfläche des MeVis LiverAnalyzers zur Visualisierung und Bearbeitung von Planungsdaten. (Quelle: Ritter et al. [62]) vordefinierte Modelle der Leber vorschlägt, sodass die Gefäßsysteme, das Leberparenchymgewebe, die Läsionen, die Risikoanalyse und der geplante Schnitt in unterschiedlicher Kombination dargestellt werden. Dieser Bereich entspricht in unserer Anwendung der Auswahl der Anzeige (vergleiche Abschnitt 3.1.2), der hier unter dem 3D-Inspektor aufgelistet ist, da er die Möglichkeit bietet, auszuwählen, was im 3D-Inspektor dargestellt wird. Das Fenster, das mit der»2«gekennzeichnet ist, fungiert im MeVis LiverAnalyzer als der von uns vorgestellte 3D-Inspektor. Das geladene Modell kann hier unter anderem frei gedreht und vergrößert werden. Dementsprechend gibt Bereich»4«die tomografischen Schnittbilder wieder. Diesen Bereich haben wir bisher als 2D-Inspektor betitelt (vergleiche Abschnitt 3.1.1). Im Fenster mit der»3«finden sich die Tabellen mit den Volumeninformationen zu der Anzeige im 2D- und 3D-Inspektor wieder, die wir Legende genannt haben. 60

61 5. Entwurf eines berührungslosen Interfaces Im Folgenden soll zunächst ein Anwendungsszenario für den Bereich der Visualisierung entwickelt werden. Daraufhin folgt die Konzeption der grafischen Benutzeroberfläche. Mithilfe des Anwendungsszenarios werden wir die Entwürfe beurteilen und anhand dessen einen unserer Meinung nach optimalen GUI-Entwurf schaffen. Im Abschluss dieses Abschnitts sollen zu dem gefundenen GUI-Entwurf verschiedene Interaktionsmöglichkeiten untersucht und somit die Grundlage für das Modell in Abschnitt geschaffen werden Anwendungsszenario Grundlage für ein Anwendungsszenario im Visualisierungsbereich sind die von Kjen Wilkens entwickelten Szenarien, die auf Videoaufzeichnungen von Leberresektionen basieren. Wilkens System beinhaltet im Gegensatz zu unserem nur die Kollektion und den 3D-Inspektor, sodass unser Anwendungsszenario dementsprechend angepasst werden muss, damit auch der 2D- Inspektor und die Legende Beachtung finden [72]. Im Anwendungsbereich Visualisierung geht es zunächst nur um das Betrachten der Planungsdaten. In Abbildung 5.2 sind die Aufgaben des Visualisierungsbereichs aufgelistet. Dabei haben wir uns am MeVis LiverAnalyzer orientiert, dessen GUI wie oben beschrieben in vier Bereiche geteilt ist (in der Abbildung links wiederzufinden). Die Bereiche und jeweiligen Interaktionen, die in unserem speziellen Anwendungsszenario relevant sind, sind rot markiert. Aufgaben des Visualisierungsbereichs vergrößern verkleinern Kollektion 3D-Inspektor Auswahl der Gefäßsysteme transformieren skalieren rotieren (nur 3D) verschieben zurücksetzen links rechts oben unten 2D-Inspektor Legende Ansicht ändern weitere axial sagittal coronar Position nach links Position nach rechts weiten fenstern schmälern durchblättern vorwärts rückwärts Abbildung 5.2.: Interaktion im Anwendungsbereich Visualisierung. 61

62 5. Entwurf eines berührungslosen Interfaces Für dieses Anwendungsszenario, das dabei behilflich sein soll, eine GUI für unsere Anwendung zu entwerfen, ist es zunächst unerheblich, alle Werkzeuge in beiden Inspektoren zu bedienen wie es bei Wilkens der Fall ist. Vielmehr soll ein und dieselbe Tätigkeit in beiden Inspektoren durchgeführt werden und daran die Gebrauchstauglichkeit der GUI gemessen werden. Zur Betrachtung der Planungsdaten muss als erstes ausgewählt werden, welche Strukturen der Leber angezeigt oder ausgeblendet werden 6. Nach der Auswahl wird das entsprechende 3D-Modell in den 3D-Inspektor geladen und die tomgrafischen Aufnahmen sind im 2D-Inspektor wieder zu finden. Daraufhin will der Arzt das 3D-Modell vergrößern, um beispielsweise den Tumor genauer zu betrachten. Nun ist es hilfreich zur Orientierung die umliegenden Gewebestrukturen zu betrachten, sodass es notwendig ist, die Ansicht des Schnittbildes im 2D-Inspektor zu verkleinern. Zuletzt soll der Arzt Informationen über die Größe des Tumors einsehen wollen. Tabelle 5.1 gibt die Interaktionsschritte noch einmal im Einzelnen wieder. Aufgabe Vorbedingung Aktion des Benutzers Anzeige auswählen Tumor im 3D- Inspektor betrachten umliegende Strukturen im 2D-Inspektor betrachten Größe des Tumors beurteilen Die Anwendung ist gestartet und der Datensatz des Patienten ist geladen. Das 3D-Modell ist im 3D-Inspektor dargestellt. Die Schnittbilder sind im 2D- Inspektor dargestellt und die gewünschte Schicht ist bereits angezeigt. Der Tumor ist im 3D-Modell durch eine bestimmte Farbe markiert. Der Arzt selektiert eines der Bilder in der Kollektion. Der Arzt vergrößert das 3D-Modell. Der Arzt verkleinert die Ansicht des Schnittbildes. Der Arzt betrachtet die Legende und findet den Eintrag für die Volumenangabe des Tumors. Reaktion der Anwendung Die entsprechende Auswahl wird im 3D-Inspektor geladen und die verschiedenen Bereiche werden farbig wiedergegeben. Das Organ ist vergrößert angezeigt. Das Schnittbild ist verkleinert angezeigt. Tabelle 5.1.: Anwendungsszenario zum Betrachten der Planungsdaten 6 An dieser Stelle ist es noch irrelevant, um welche Strukturen es sich im Genauen handelt, die angezeigt werden. 62

63 5. Entwurf eines berührungslosen Interfaces Konzeption der grafischen Benutzeroberfläche Den oben beschriebenen vier Bereichen der GUI ist ein weiterer Bereich hinzuzufügen. Dieser Bereich ist dafür zuständig, das Kamerabild wiederzugeben. Bei unserer Implementierung stellten wir fest, dass dieser Teil der GUI nicht trivial ist. So war es eine wichtige Erkenntnis, dass es ohne visuelle Unterstützung schwierig ist, mit der Hand im Sichtbereich der Kamera zu bleiben. Dies bemerkten wir erst in Tests, bei denen der Proband nicht die Möglichkeit hatte sich selbst auf dem Monitor zu sehen. Er konnte mit seinen Handbewegungen nur innerhalb des sichtbaren Bereichs der Kinect bleiben, wenn ihm klare Anweisungen gegeben wurden. Zu beachten ist, dass das Bild nicht nur nach links und rechts und oben und unten begrenzt ist, es gibt auch Einschränkungen in der Tiefe. So ergab sich in unseren Tests, dass die gewonnenen Tiefen zwischen einem und dreieinhalb Metern am genauesten wieder gegeben werden. Eine Interaktion ohne das Kamerabild im Blickfeld zu haben ist also beinah unmöglich oder nur mit sehr viel Übung durchführbar. Daraus resultierend ist es sinnvoll, dass der Benutzer sich selbst beziehungsweise seine Hand sobald sie erkannt wurde auf dem Bildschirm sehen kann. Dieser fünfte Bereich in unserer GUI soll aufgrund seiner Bedeutsamkeit permanent angezeigt werden. Die Anzeige des Kamerabildes fällt in den Bereich des ISO-Grundsatzes der Steuerbarkeit: Sie hilft zum einen bei der Orientierung und soll außerdem eine Stütze sein, sodass der Benutzer nachvollziehen kann, wann seine Hand erkannt wurde und wo sich der Trackpunkt befindet. Wir möchten vorschlagen, dass sich dieser Bereich immer im rechten unteren Drittel des Bildschirms befindet. Für die Anordung aller weiteren Bereiche in der GUI sollen nun mehrere Entwürfe entwickelt werden. Sie werden zum einen anhand des Anwendungsszenarios aus Abschnitt und zum anderen mithilfe der Europäischen Norm ISO und Nielsens Grundsätzen aus Abschnitt 5.1 diskutiert und beurteilt werden. GUI-Entwurf I Orientierung am MeVis LiverAnalyzer. Ein Entwurf, der sich an dem Me- Vis LiverAnalyzer orientiert ist in Abbildung 5.3 dargestellt. Hier befinden sich 2D- und 3D- Inspektor und die Kollektion und die Legende an gleicher Position wie bei dem MeVis LiverAnalyzer und das Kamerabild ist im rechten unteren Drittel hinzugefügt. Die Trennlinie zwischen dem 2D- und dem 3D-Inspektor soll vertikal verschoben werden können und es soll außerdem noch möglich sein, die beiden Ansichten zu vertauschen, sodass das 3D-Modell im unteren Inspektor und die Schnittbilder im oberen dargestellt werden. Bei einer solchen GUI ist die Interaktion via WIMP oder Touch offensichtlich. Je nach dem, in welchen Bereich geklickt wird erfolgt die Interaktion und die Reaktion des Systems. Für die Gestensteuerung gestaltet sich dies jedoch schwieriger. Wir haben bereits ausgeschlossen die Kamera zu nutzen, um die Position des Fingers oder der Hand im Verhältnis zum Monitor zu betrachten (vergleiche Abschnitt 2.2). Das Verfolgen der Hand in Bezug zum Kamerabild ist vorstellbar, wobei mit einem 3D-Kamerasystem auch ein Klicken oder Doppelklicken erkannt und verwirklicht werden kann. Diese Art der Interaktion ist für unsere Anwendung jedoch nicht sinnvoll, da es schließlich unser Leitbild ist, intuitive Gesten aus der Kommunikation zu nutzen, die die Funktionen wie beispielsweise die Rotation zusätzlich unterstützen. Eine weitere Möglichkeit zur Interaktion ist es, für jede Funktion in den jeweiligen Fenstern unterschiedliche Gesten zu finden, sodass die Skalierung, die Verschiebung, das Zurücksetzen 63

64 5. Entwurf eines berührungslosen Interfaces Abbildung 5.3.: GUI-Entwurf I und das Ändern der Ansichtsebene im 2D-Inspektor durch eine andere Geste durchgeführt werden müssen als im 3D-Inspektor. Nachteil bei diesem Verfahren ist die Vielzahl an unterschiedlichen Gesten, die sich der Benutzer merken muss. Dies verstößt gegen den dritten Grundsatz, der von Nielsen definiert wurde: Minimiere das zu Merkende [53]. Es müsste also in unserem Anwendungsszenario von Abschnitt für die Skalierung im 3D-Inspektor eine andere Geste gefunden werden als im 2D-Inspektor. Die verschiedenen Gesten können schnell miteinander verwechselt werden. Eine solche Komplexität wollen wir dem Nutzer unserer Anwendung nicht aufzwingen. Letztendlich kommen wir zu dem Schluss, dass die einzig sinnvolle Art der Interaktion bei dieser GUI durch eine Aktivierung der einzelnen Fenster zu realisieren ist. Es müssen also Gesten gefunden werden, die die Kollektion, den 2D- und den 3D-Inspektor aktivieren 7, sodass die Funktionen, die sowohl im 2D- als auch im 3D-Inspektor übereinstimmen, mit der gleichen Geste zu bedienen sind. In unserem Anwendungsszenario muss der Benutzer also zunächst das Fenster für die Kollektion aktivieren, um auszuwählen, was im 3D-Modell angezeigt wird. Daraufhin muss er den 3D-Inspektor aktivieren und das 3D-Modell vergrößern und im Folgenden den 2D-Inspektor auswählen, um hier das Schnittbild mit der entgegengesetzten Geste zu verkleinern. Für die Informationen über das Volumen des Tumors genügt ein Blick auf die Legende. Eine Aktivierung der Fenster bedeutet gleichzeitig, dass der Benutzer immer wissen muss, in welchem Fenster er sich gerade befindet. Ein farbiger Rahmen um das aktive Fenster kann den Benutzer dabei unterstützen sich zu orientieren. Hierbei ist fraglich, wie hilfreich eine solche Markierung ist und ob dies nicht leicht zu Verwirrungen führt, da man schnell das fokussierte Fenster für das aktive hält. Um diesem Fehler vorzubeugen (Nielsens neunter Grundsatz aus Abschnitt??), haben wir uns dafür entschieden in einem zweiten Entwurf alle Bereiche außerhalb des Bildschirms auszulagern, sodass nur der Bereich für den Benutzer sichtbar ist, der ihn je nach Bedarf interessiert. 7 Bei der Legende ist keine Interaktion notwendig, sodass dieses Fenster nicht aktiviert werden muss. 64

65 5. Entwurf eines berührungslosen Interfaces GUI-Entwurf II Bereiche auslagern. Dieser Entwurf befasst sich damit, die Probleme des vorigen Entwurfs bezüglich der Fehler, die bei der Identifikation des aktiven Fensters geschehen, zu umgehen. Wir beschließen die unterschiedlichen Bereiche 2D-Inspektor, 3D-Inspektor, Kollektion und Legende außerhalb des Bildschirms auszulagern. Eine Skizze des Entwurfs ist in Abbildung 5.4 dargestellt. Abbildung 5.4.: GUI-Entwurf II Hier soll es möglich sein, sich entweder den 2D- oder den 3D-Inspektor auf dem gesamten Bildschirm anzeigen zu lassen. Bei Bedarf kann die Kollektion und die Legende auf den Bildschirm gezogen werden. Dies hat zum einen den Vorteil, dass nur im derzeitig angezeigten Fenster interagiert werden kann. Dem Benutzer ist also immer klar, in welchem Fenster er arbeitet. Zum anderen werden die Inhalte der Kollektion und der Legende seltener benötigt, sodass der Platz, den sie im ersten Entwurf einnehmen, anderweitig genutzt werden kann. In diesem Entwurf soll erörtert werden, was die Vor- und Nachteile einer GUI sind, bei dem die zwei Inspektoren im Vollbildmodus dargestellt werden. Im Anwendungsszenario aus Abschnitt soll im ersten Schritt ausgewählt werden, was im 3D-Modell zu sehen ist. Es muss also zunächst die Kollektion von oben auf den Bildschirm gezogen werden wie in Abbildung 5.4 [2] (unten links) skizziert, damit die gewünschte Repräsentation des 3D-Modells selektiert werden kann. Daraufhin kann das Kollektion-Fenster wieder vom Bildschirm weggeschoben werden. Da es im weiteren Verlauf unseres Szenarios nicht mehr benötigt wird, ist es praktisch, dass es außerhalb des Bildschirm verlagert werden 65

66 5. Entwurf eines berührungslosen Interfaces kann. Auch im Operationssaal wird es wahrscheinlich nur selten vorkommen, dass die Anzeige des 3D-Modells verändert wird. Hier wird im ersten Schritt das entsprechende Modell ausgewählt und nur dann verändert, wenn beispielsweise ein weiteres Gefäßsystem betrachtet werden muss. Nachdem das Kollektion-Fenster aus dem sichtbaren Bereich des Bildschirms weggeschoben wurde, ist der 3D-Inspektor auf dem gesamten Bildschirm zu sehen (Ausgangssituation aus Abbildung 5.4 [1] (oben links)). Hier kann nun mit einer Geste das 3D-Modell vergrößert werden. Das Verschieben des Inspektors nach links soll den 2D-Inspektor in den sichtbaren Bereich rücken (vergleiche Abbildung 5.4 [3] (oben rechts)). Hier soll die gleiche Geste zum Verkleinern des Schnittbilds angewendet werden, die zuvor im 3D-Inspektor genutzt wurde, dieses Mal allerdings in entgegengesetzter Richtung. Um das Volumen des Tumors einzusehen, muss entsprechend die Legende von links auf den Bildschirm gezogen werden. Dieser Zustand ist in Abbildung 5.4 [4] unten rechts dargestellt. Das Verlagern der Bereiche außerhalb des Sichtbereichs des Bildschirms hat den Vorteil, dass zu jedem Zeitpunkt offensichtlich ist, welcher Bereich aktiv ist. Die Legende und die Kollektion können, je nachdem, wann es erwünscht ist, auf den Bildschirm gezogen werden, unabhängig davon, welcher Inspektor gerade angezeigt wird. Dies schafft mehr Platz auf dem Bildschirm, sodass die Vollbilddarstellung der beiden Inspektoren ermöglicht wird. Nachteilig ist allerdings, dass die beiden Inspektoren nicht direkt miteinander verglichen werden können, was in den Bereich der Aufgabenangemessenheit der oben vorgestellten ISO-Norm fällt. So ist es beispielsweise wünschenswert, den Resektionsschnitt im 3D-Modell gleichzeitig mit den umliegenden Gewebestrukturen in den Schnittbildern zu betrachten, um einen risikofreien Schnitt sicherzustellen. Mit diesen Feststellungen kommen wir zu unserem dritten GUI-Entwurf, der eine Lösung dieses Problems erörtert, indem eine Kombination aus Entwurf I und II geschaffen wird. GUI-Entwurf III Kombination aus den vorhergehenden Entwürfen. Wie im Entwurf von Abschnitt bereits erörtert, ist das Ein- und Ausblenden der Kollektion und der Legende äußerst hilfreich, um einerseits die Inspektoren möglichst großflächig darzustellen und andererseits auch, um das aktive Fenster eindeutig identifizieren zu können. Dieses Konzept zur Auslagerung auf den nicht sichtbaren Bereich des Bildschirms soll in diesem Entwurf beibehalten werden. Im Gegensatz zu Entwurf II sollen hier aber der 2D- und 3D-Inspektor nebeneinander auf dem Monitor dargestellt sein, sodass ein Abgleich zwischen den Daten, die von ihnen wiedergegeben werden, stattfinden kann. Abbildung 5.5 skizziert die GUI dieses Entwurfs, bei dem wie in Entwurf II die Kollektion von oben und die Legende von rechts auf den sichtbaren Bereich des Bildschirms gezogen werden kann. Dabei sind vergleichbar mit Entwurf I die zwei Inspektoren gleichzeitig auf dem Bildschirm dargestellt. Sie sollen durch eine Trennlinie in zwei Bereiche geteilt sein, die man horizontal verschieben kann, sodass die Größe der jeweiligen Fenster variabel ist. Dieses Prinzip haben wir bereits im GUI-Entwurf I vorgestellt und ist auch im MeVis LiverAnalyzer vorzufinden, wodurch es dem Benutzer bereits bekannt ist. Beim Verschieben der Trennlinie soll es auch möglich sein, dass eines der Fenster in den Vollbildmodus übergeht, sobald der Splitter vollständig zur Seite geschoben wird. Auch hier stellt sich das Problem des Erkennens des aktiven Fensters. Ist die Kollektion auf dem Monitor sichtbar, so ist es eindeutig, dass dieses Fenster aktiv ist. Befindet sich einer der beiden Inspektoren im Vollbildmodus, so ist dieser aktiv. Wenn 66

67 5. Entwurf eines berührungslosen Interfaces Abbildung 5.5.: GUI-Entwurf III nun jedoch beide gleichzeitig auf dem Bildschirm zu sehen sind, muss eine Regel für die Aktivierung gefunden werden. Wir erwarten, dass der Inspektor, in dem gearbeitet wird, derjenige ist, der größer dargestellt wird. Somit kommen wir zu dem Schluss, dass der jeweilig größer dargestellte Inspektor der aktive ist. Des Weiteren bietet es sich an, dass die Trennlinie schrittweise verschoben werden kann. Somit können die beiden Inspektoren vier verschiedene Größen einnehmen: nicht sichtbar, ein Drittel der Bildschirmfläche, zwei Drittel der Bildschirmfläche und Vollbild. Es kann also nicht vorkommen, dass beide Inspektoren gleich groß dargestellt werden und es damit nicht mehr eindeutig ist, welcher der aktive ist. Führen wir das Anwendungsszenario in diesem GUI-Entwurf durch, ergibt sich zur Auswahl der Anzeige und zum Beurteilen der Größe des Tumor die gleiche Interaktion wie bereits im GUI-Entwurf II beschrieben: Die Kollektion muss von oben auf den Bilschirm gezogen werden, um die gewünschte Anzeige auszuwählen und die Legende von rechts, um das Volumen des Tumors in Erfahrung zu bringen. Wenn der Benutzer den Tumor im 3D-Modell genauer betrachten möchte, so muss der 3D-Inspektor auf dem Bildschirm größer dargestellt sein als der 2D-Inspektor, so wie es in Abbildung 5.3 der Fall ist. Dadurch ist der 3D-Inspektor aktiviert und alle Gesten bewirken eine Reaktion in ebendiesem. So kann das Vergrößern des 3D-Modells bewirkt werden. Zur Interaktion im 2D-Inspektor muss dann die Trennlinie nach links geschoben werden, sodass der 2D-Inspektor entweder zwei Drittel der Bildschirmfläche einnimmt oder als Vollbild dargestellt wird also größer ist als der 3D-Inspektor. Dies bewirkt die Aktivierung des 2D-Inspektors, sodass nun das Schnittbild verkleinert werden kann, um umliegende Strukturen zu betrachten. 67

68 5. Entwurf eines berührungslosen Interfaces Konklusion Wir betrachten den GUI-Entwurf III als den optimalen Entwurf für unsere Anwendung und werden ihn nun hinsichtlich der Europäischen Norm ISO und den Grundsätzen zur Benutzerschnittstellengestaltung von Jakob Nielsen beurteilen (beide in der Einleitung von Kapitel 5 beschrieben). Natürlich ist es zu diesem Zeitpunkt nicht möglich, alle Stärken und Schwächen der GUI zu identifizieren. Dies kann erst nach einer umfassenden Evaluation mit einem Prototypen geschehen. Jedoch möchten wir an dieser Stelle festhalten, welche Punkte schon jetzt in der von uns entwickelten GUI beachtet werden. Die konzipierte grafische Benutzeroberfläche ist an die des MeVis LiverAnalyzers angelehnt. Trotz vieler Änderungen bestehen noch immer die vier Bereiche: Kollektion, 3D-Inspektor, 2D- Inspektor und Legende. Da der Chirurg den LiverAnalyzer benutzt, um sich auf die bevorstehende Operation vorzubereiten, ist ihm diese Applikation bereits bekannt. Mit diesem Vorgehen erfüllen wir bereits zwei von Nielsens Punkten, und zwar das Sprechen der Sprache des Nutzers und die Konsistenz. Beides ist der Erwartungskonformität unterzuordnen. Ein Chirurg, dem eine Anwendung zum intraoperativen Gebrauch gestellt wird, erwartet, dass sie sich ähnlich verhält, wie die, die er bereits präoperativ genutzt hat. Die Änderungen in der GUI, die wir vorgenommen haben, benötigen zwar eine kurze Eingewöhnungszeit, sollten den Benutzer aber nicht bedeutend irritieren, da er den grundsätzlichen Aufbau in unserem Konzept schnell wiedererkennen kann. Das Wiedererkennen der unterschiedlichen Bereiche in der GUI trägt gleichzeitig zu der von der ISO-Norm geforderten Lernförderlichkeit und der Selbstbeschreibungsfähigkeit bei. Weiterhin möchten wir dem Fehler vorbeugen, der häufig vorzufinden ist, wenn mehrere Fenster gleichzeitig auf dem Bildschirm dargestellt sind. So ist die Mensch-Computer-Interaktion gekennzeichnet durch die Handlung des Benutzers mit dem Computer, der daraufhin eine bestimmte Reaktion des Computers oder in unserem Fall der Software erwartet. Nach Niegemann et al. [51] erfolgt die menschliche Wahrnehmung nur selektiv. So ist es vorstellbar, dass der Nutzer unserer Anwendung einen bestimmten Bereich in der GUI fokussiert und in diesem interagieren möchte. Bei der Gestensteuerung ist durch den fehlenden Zeiger nicht klar, welcher der von dem Benutzer fukussierte Bereich ist. Deshalb haben wir eine Regel für die Aktivierung der einzelnen Bereiche festgelegt. Bei der gleichzeitigen Darstellung all unserer Bereiche kann es zu einem Informationsüberfluss kommen, sodass der Benutzer jedes Mal, wenn er auf den Monitor schaut, als erstes den aktiven Bereich ausmachen muss und diesen gegebenenfalls wechseln muss, um seine Handlung durchzuführen. Aufgrund dessen entschieden wir uns für eine Minimierung der dargestellten Bereiche, sodass der Benutzer nur die Informationen erhält, die ihn zum jeweiligen Zeitpunkt interessieren. Das Auslagern einiger Bereiche trägt entscheidend zu der Steuerbarkeit des Systems bei und es kommt seltener zu Fehlbedienungen (siehe Fehlertoleranz). Dabei mussten wir zusätzlich die Möglichkeit berücksichtigen, dass der Arzt die tomografischen Bilder und das 3D-Modell vergleichend betrachten möchte, sodass eine gleichzeitige Anzeige des 2D- und 3D-Inspektors in die Benutzeroberfläche einfließen muss. Würden die Inspektoren nur einzeln auf dem Monitor angezeigt werden, so wären alle Gesten des Benutzers eindeutig auf den dargestellten Inspektor bezogen. Dies würde die Steuerbarkeit des Systems im Wesentlichen vereinfachen, muss jedoch der Aufgabenangemessenheit weichen, sodass wir letztendlich uns dafür entscheiden, dass beide Inspektoren gleichzeitig angezeigt werden und der jeweilig größer dargestellte, der aktive ist. Des Weiteren haben wir bei der Konzeption der grafischen Oberfläche versucht, darauf zu 68

69 5. Entwurf eines berührungslosen Interfaces achten, dass die Anzahl der benötigten Gesten so klein wie möglich gehalten wird. Es wäre zum Beispiel nicht sinnvoll, für die Interaktion im 2D-Inspektor andere Gesten zu benutzen als im 3D-Inspektor, wenn es sich um die gleiche Funktion handelt 8. Diese Feststellung minimiert das zu Merkende und fällt in den Bereich der Selbsbeschreibungsfähikeit. Eine Erörterung der verschiedenen Gesten und wie sie in unserem GUI-Entwurf eingesetzt werden ist im folgenden Abschnitt zu finden Konzeption der Gestensteuerung Zu der konzipierten grafischen Benutzeroberfläche soll nun die entsprechende Interaktion mittels Handgesten gefunden werden. Wie in Abschnitt bereits geschildert, eignet sich eine Umfrage am besten bei der Entwicklung eines optimalen Gestenvokabulars. So führten wir eine Umfrage innerhalb des Fraunhofer-MEVIS-Instituts und der MeVis Medical Solutions AG durch, bei der wir Mitarbeiter befragt haben, die sich bereits mit dem MeVis LiverAnalyzer oder ähnlichen Produkten zur Visualisierung von medizinischen Bilddaten auskennen. Die Frage, wie sich der Benutzer die Kollektion und die Legende auf den Bildschirm holt und wie er die Trennlinie zwischen dem 2D- und 3D-Inspektor verschiebt, haben wir in unserer Umfrage nicht gestellt. Dazu hätten wir den Befragten erst unser Konzept vorstellen müssen. Dies würde die Befragungszeit gravierend verlängern, sodass wir beschlossen haben, für diese Interaktionen selbst Gesten zu definieren. Für das Ziehen der Kollektion auf den Bildschirm beschließen wir, dass der Benutzer mit zwei gestreckten Fingern, dem Zeige- und dem Mittelfinger, die Hand von oben nach unten bewegen muss. Zum Wegschieben des Kollektion-Fensters soll er die gleiche Geste von unten nach oben benutzen. Für das Ein- und Ausblenden der Legende können wir diese Geste auch verwenden. Allerdings muss hier die Hand von links nach rechts bewegt werden, um die Legende anzuzeigen und von rechts nach links, um sie wieder verschwinden zu lassen. Für das Verschieben der Trennlinie soll der Benutzer mit dem Zeigefinger und Daumen ein Greifen nachahmen. Also Zeigefinger und Daumen zusammenführen und diese Positur dann beibehalten. Bei der Bewegung der Hand nach links und rechts wird die Trennlinie entsprechend verschoben. An dieser Stelle möchten wir den Prototypen zur Auswahl der Anzeige aus Kjen Wilkens Arbeit vorstellen [72]. Dessen Interface und die Interaktion darin werden wir mit einigen Änderungen von ihm übernehmen. Er stellte in seiner Arbeit ein Ringmenü vor, das es ermöglicht, zwischen mehreren Darstellungen des 3D-Modells zu wählen und eine davon auszuwählen. Ein Screenshot seines Prototypen ist in Abbildung 5.6 zu finden. Sein System wird mithilfe der Wii Remote der Spielekonsole Nintendo Wii gesteuert und wurde in Processing realisiert. Zeigt der Benutzer mit der Wii Remote auf den rechten beziehungsweise linken Bildschirmrand, so findet eine Rotation des Ringmenüs in entsprechender Richtung statt. Die Auswahl soll durch eine Bewegung nach oben geschehen. [72]. Das Ringmenü werden wir zur Auswahl der Ansicht beibehalten. Die Rotation des Menüs geschieht bei ihm durch das Verweilen auf der linken oder rechten Seite, bei uns soll sie, da wir auf einen Pointer verzichten, durch die dynamische Geste nach links und rechts geschehen. Dabei soll der Benutzer die Hand zu einer Faust geformt ha- 8 Das Skalieren, Verschieben, Zurücksetzen und die drei verschiedenen Ansichtsebenen sind sowohl im 2D- Inspektor als auch im 3D-Inspektor vorhanden. 69

70 5. Entwurf eines berührungslosen Interfaces Abbildung 5.6.: Screenshot von Kjen Wilkens Prototyp zur Auswahl der Ansicht im Kollektion- Bereich (Quelle: Wilkens [72]) ben. Die Auswahl soll bei uns aber durch das Führen der Faust in Richtung Kamera erfolgen, was ein Klicken mit der Maustaste anmutet. Im Folgenden möchten wir zunächst zwei Möglichkeiten vorstellen, wie sich die Interaktion in unserer Applikation gestalten kann: Paradigma (a), dessen Interaktion an die WIMP- oder Touchscreen-Methodik anlehnt, bei dem jedes Werkzeug ausgewählt werden muss um angewendet werden zu können und Paradigma (b), das für jedes Werkzeug eine individuelle Geste fordert. Letzteres bildet die Grundlage für unsere Umfrage, da hier alle Werkzeuge in den Inspektoren mit verschiedenen Gesten belegt werden müssen. Des Weiteren soll die Interaktion im Aktualisierungsbereich hier kurz erfasst werden, um im Anschluss eine Schlussfolgerung zu ziehen. Paradigma (a) beschreibt eine Interaktion auf der Benutzeroberfläche, wie sie im GUI-Entwurf III (vergleiche Abschnitt 5.2.2) konzepiert wurde, bei dem die in den Inspektoren genutzten unterschiedlichen Werkzeuge ausgewählt werden müssen, um dann mittels Positionserkennung der Hand gesteuert zu werden. Da die Hand nicht in Bezug auf den Monitor verfolgt wird und wir ebenso das Arbeiten mit einem Mauszeiger ausschließen, bietet es sich an, die vielen verschiedenen Werkzeuge ähnlich wie in Abbildung 5.2 zu kategorisieren, um die Auswahl des Werkzeugs zu vereinfachen und somit die Komplexität zu verringern. Kategorisieren bedeutet in unserem Fall die Einteilung der Werkzeuge in drei Gruppen: Transformation: darunter fällt das Skalieren, das Verschieben und das Zurücksetzen sowie 70

71 5. Entwurf eines berührungslosen Interfaces das Rotieren des 3D-Modells im 3D-Inspektor Ändern der Ansicht: darunter fällt das Wechseln zwischen den drei Darstellungsebenen Axial-, Sagittal- und Coronarebene weitere Werkzeuge: darunter das Durchblättern und das Fenstern (beides wird nur im 2D- Inspektor eingesetzt) Abbildung 5.7 beschreibt die Benutzeroberfläche zur Auswahl des Werkzeugs. In der Vertikalen lässt sich die Kategorie bestimmen (zum Beispiel Ansicht ändern), sodass in der Horizontalen das gewünschte Werkzeug selektiert werden kann (zum Beispiel die Coronarebene). Wie oben bereits verdeutlicht, sind viele Werkzeuge im 2D-Inspektor ebenso wie im 3D-Inspektor vorzufinden. Dagegen ist das Fenstern und das Durchblättern nur im 2D-Inspektor möglich und das Rotieren nur im 3D-Inspektor. Das bedeutet, dass es entweder zwei Leisten zur Auswahl der Werkzeuge geben muss, die den Inspektoren zugeordnet sind oder je nachdem, welches der beiden Fenster aktiv ist müssen jeweilige Werkzeuge eingeblendet oder aktiviert werden. Wir entscheiden uns dabei für letztere Variante, da wir zum einen zwei Werkzeugleisten für überflüssig halten und zum anderen erwarten, dass sie den Benutzer eher verunsichern, als dass sie die Steuerbarkeit des Systems verbessern. Abbildung 5.7.: GUI-Entwurf III mit Werkzeugleiste (Paradigma (a)). Bei diesem Konzept zur Gestensteuerung muss eine Geste gefunden werden, die die Werkzeugleiste bedient und eine andere, die das ausgewälte Werkzeug anwendet. So kann man sich zum Beispiel vorstellen, dass Werkzeuge mit gestrecktem Zeigefinger ausgewählt werden können. Bewegt sich die Hand dabei nach oben und unten, wählt der Benutzer zwischen den Kategorien, bewegt sie sich nach links und rechts, wählt der Benutzer zwischen den einzelnen Werkzeugen innerhalb der ausgewählten Kategorie. Hat der Benutzer das gewünschte Werkzeug ausgewählt, kann er es im jeweilig aktiven Inspektor anwenden, indem er beispielsweise mit seiner Hand eine Faust bildet. Durch die Verwendung der 3D-Kamera kann der gesamte 3D-Raum genutzt werden, der von der Kamera erfasst wird. So sind Bewegungen in der Frontalebene und zudem auch 71

72 5. Entwurf eines berührungslosen Interfaces in der Transversalebene möglich. Die Frontalebene befindet sich vor dem Körper des Benutzers und beinhaltet die Bewegungen, die von oben nach unten und von links nach rechts gehen. Die Transversalebene ist die Ebene, die sich horizontal zum Körper befindet, also Bewegungen nach vorne und hinten beinhaltet. Skalieren lässt sich durch Bewegungen in der Transversalebene verwirklichen. So kann sich der Benutzer vorstellen, dass er das Bild näher ran holt oder weiter weg schiebt. Zum Rotieren soll der Benutzer die Hand in der Frontalebene bewegen. Dadurch wird das 3D-Modell in die Richtung gedreht in die die Hand bewegt wird. Gleiches gilt für das Verschieben. Ebenso wie das Skalieren, kann auch das Durchblättern im 2D-Inspektor durch eine Bewegung der Hand in der Transversalebene realisiert werden. Bei der Fensterung im 2D- Inspektor nehmen wir uns aus Konsistenzgründen ein Beispiel an der Interaktion mit der Maus. Hier wird die Maus nach rechts bewegt, um das Fenster zu vergrößern und nach links um es zu verkleinern. Um die Position des Fensters in den Bereich kleinerer Werte zu bringen wird die Maus nach oben bewegt und um sie in den Bereich größerer Werte zu bringen nach unten. Dies sollte in unserer Anwendung beibehalten werden: Für die Änderung der Weite muss die Hand also nach links und rechts bewegt werden und für die Änderung der Position nach oben und unten. Um das Zurücksetzen und das Wechseln in der Ansichtsebene durchzuführen, muss vom Benutzer keine Richtung vorgegeben werden. Sie können ausgeführt werden, sobald der Benutzer sie in der Werkzeugleiste auswählt. Ärgerlich wäre es dann aber, wenn der Benutzer allein durch die Auswahl eines Werkzeugs in der Kategorie Transformation versehentlich das Zurücksetzen aktiviert und dadurch all seine Einstellungen verliert. Daraus resultierend wäre es angemessen, dass diese Werkzeuge erst dann vom System umgesetzt werden, wenn der Benutzer sie aktiviert. Er könnte also wieder die Hand zu einer Faust formen, sodass das System registriert, dass diese Aktion auch vom Benutzer erwünscht ist. Dieses Paradigma ermöglicht es, dass jedes Werkzeug mit der gleichen Geste allein durch Positionserkennung bedient werden kann, sodass technisch nur wenige verschiedene Handposituren erkannt werden müssen. Gleichzeitig muss sich der Benutzer auch weniger Gesten merken, was einer Fehlbedienung vorbeugen kann. Sollten noch mehr Funktionen hinzukommen, bleibt die Anzahl der unterschiedlichen Gesten dennoch gleich und es kommen lediglich weitere Kategorien und Werkzeuge hinzu. Das ist zum Beispiel dann der Fall, wenn der Bereich der Aktualisierung hinzugezogen wird. Dies bedeutet, je komplexer die Anwendung ist, desto mehr bietet sich eine Interaktion nach diesem Paradigma an. Negativ wirkt sich ein schneller Wechsel zwischen den Werkzeugen aus. Möchte der Benutzer beispielsweise drei verschiedene Transformationen hintereinander ausführen, wie rotieren, vergrößern, verschieben, muss er immer wieder die Werkzeugleiste bedienen, um das Werkzeug zu wechseln. Noch komplizierter wird es dann, wenn er die Kategorie zusätzlich ändern muss. Paradigma (b) bietet eine Lösung für die Schwierigkeit bezüglich des schnellen Wechsels zwischen den Werkzeugen. In dieser Lösung schlagen wir eine Interaktion vor, bei der für jede Funktion in den Inspektoren unterschiedliche Gesten gefordert sind. Für dieses Paradigma ist eine Werkzeugleiste nicht mehr notwendig. Stattdessen sollte es aber eine Übersicht geben, die die Gesten den jeweiligen Funktionen zuordnet (vergleiche Abildung 5.8). Dies entspricht zum einen einer Rückmeldung, ob das System auch die richtige Geste erkannt hat, zum anderen kann der Benutzer kontrollieren, ob die Geste, die er macht auch das Werkzeug bedient, das er 72

73 5. Entwurf eines berührungslosen Interfaces Abbildung 5.8.: GUI-Entwurf III mit einer Übersicht, die den Funktionen Gesten zuordnet (Paradigma (b)). benutzen möchte. Die Werkzeuge in den Inspektoren addieren sich zu sieben Grundfunktionen, darunter das Ändern der Ansichtsebene, die vier Transformationsfunktionen sowie das Fenstern und Durchblättern im 2D-Inspektor. Um für alle sieben Werkzeuge intuitive Gesten zu finden, haben wir eine Umfrage unter den Mitarbeitern des Fraunhofer-MEVIS-Instituts und der MeVis Medical Solutions AG durchgeführt. Alle Befragten sind in dem Gebiet der Medizintechnik bewandert. Wir haben den Befragten keine Gesten vorgelegt, um sie in ihren Antworten nicht zu beeinflussen. Die detaillierten Ergebnisse unserer Befragung finden sich im Anhang B. Abbildung 5.9.: Gesten zum Einstellen der Ansichtsebene (von links nach rechts: Axialebene, Sagittalebene, Coronarebene). Das Ändern der Ansichtsebene besteht in beiden Inspektoren aus der Axial-, der Sagittal- und der Coronarebene. Die Ansichtseneben wurden von allen Befragten durch die flache Hand dargestellt, die sich jeweils in der entsprechenden Ebene befand. Die meisten darunter benutzten die Geste statisch. Die Finger waren bei fast allen gestreckt und geschlossen. Die Axialebene 73

74 5. Entwurf eines berührungslosen Interfaces soll also eingestellt werden, wenn die Handfläche nach unten zeigt, die Sagittalebene, wenn sie zur Seite zeigt, und die Coronarebene, wenn sie nach vorne zeigt (vergleiche Abbildung 5.9). Wir betrachten die Geste als sehr sinnvoll, da sie von allen Befragten genannt wurde. Die Ansichtsebene soll erst dann gewechselt werden, wenn die Hand einen bestimmten Zeitraum in der Position verweilt. Dieser Zeitraum darf nicht zu lang sein, da zu lange Wartezeiten häufig zu der Frustration des Benutzers führen, er darf aber auch nicht zu kurz sein, sodass die Ansicht nicht versehentlich gewechselt wird. Die Rotation wurde von den meisten der Befragten durch eine geöffnete Hand mit entspannten Fingern, das bedeutet leicht gebeugt und mit kleinen Abständen zwischen den Fingern, durch eine Drehbewegung wiedergegeben (vergleiche Abbildung 5.10). Diese Geste empfanden wir selbst auch schon als die passendste, da wir sie häufig in Gesprächen beobachtet haben, wenn vermittelt werden wollte, dass ein Gegenstand gedreht werden soll. Technisch muss hierfür jeder Finger erkannt werden, sodass an allen fünf Richtungen, in die Finger von der Startposition bis zur Endposition zeigen, die Rotationsrichtung erkannt werden kann. Dies kann nur sehr schwer erkannt werden, da einzelne Finger aus Sicht der Kamera verdeckt sein können. Abbildung 5.10.: Geste zur Zudem können auf die Weise Rotationen nur bis zu einem be- Rotation des 3D-Modells. stimmten Grad durchgeführt werden, da die Drehung der Hand auf bestimmte Winkel beschränkt ist. So müsste der Benutzer, wenn er das Modell weiter drehen möchte, als es ihm physisch möglich ist, seine Hand wieder zurück drehen. Hier kommt es mit großer Wahrscheinlichkeit wieder zu dem Midas-TouchProblem (vergleiche Abschnitt 5.1.2), da die Hand die Positur beibehält und das System nicht weiß welche der Drehungen eine Rotation bewirkt. Nichtsdestotrotz, werden wir diese Geste zunächst als die optimale Geste für die Rotation betrachten. Das Skalieren assoziierten die meisten der Befragten mit der Pinch-Geste (vergleiche Abbildung 5.11). Das ist das Führen der Fingerspitzen von Daumen und Zeigefinger zueinander beim Verkleinern und voneinander weg beim Vergrößern. Dies ist die Geste, die auch häufig bei Touchscreens verwendet wird. Etabliert hat sich die Geste durch Apples ipad, iphone und Touchpad. Auch hier wird diese Geste zum Skalieren benutzt. Bei der Pinch-Geste kommt wieder das Midas-Touch-Problem auf, da die Finger nur in begrenztem Ausmaß gespreizt oder zusammengeführt werden können. Spontan nannten fast alle der Befragten ein häufiges auseinander Bewegen und Zusammenführen der Finger. Das System würde in dem Fall aber ständig hinaus- und Abbildung 5.11.: Geste zum hineinzoomen. Dem schaffen wir Abhilfe, indem wir beschlie- Skalieren. ßen dass die Geste ein Mal ausgeführt wird und dann so lange in ihrer Positur verweilt, bis die gewünschte Größe eingestellt ist. Das bedeutet, dass für das Vergrößern der Zeigefinger und der Daumen auseinander gezo- 74

75 5. Entwurf eines berührungslosen Interfaces gen werden und für das Verkleinern zusammengeführt werden und dann in ihrer jeweiligen der Positur verweilen bis der gewünschte Skalierungsfaktor erreicht ist. Aufgrund der kurzen Distanz zwischen Daumen und Zeigefinger ist es bei der Geste auch nur schwierig möglich, die Geschwindigkeit der Bewegung zu messen und die Skaliergeschwindigkeit daran festzumachen. Deshalb sollte das System die Skalierung in einer standardisierten Geschwindigkeit durchführen, die wiederum nicht zu schnell sein darf, um den Moment an dem die gewünschte Größe angezeigt wird nicht zu verpassen, aber auch nicht zu langsam, sodass zu lange Wartezeiten entstehen. Das Verschieben des 3D-Modells beziehungsweise des tomografischen Bildes soll nach Meinung der meisten Befragten mit dem gestreckten Ziegefinger realisiert werden (vergleiche Abbildung 5.12). Alle anderen Finger waren dabei gebeugt, die Haltung des Daumens war dabei eher zufällig entweder abstehend oder angelehnt. Zudem fand die Bewegung bei fast allen der Befragten in der Frontalebene statt. Einige konnten sich auch eine Bewegung in der Horizontalen vorstellen. Dies waren jedoch sehr wenige. Ebenso wurde die geöffnete Hand von einigen Befragten mit dem Verschieben verbunden. Da wir die geöffnete Hand bereits als die Geste festgelegt haben, in der das System zwar aktiv sein soll und nach Gesten suchen soll, aber keine Än- Abbildung 5.12.: Geste zum derungen bewirken soll, entscheiden wir uns dafür, die Geste mit Verschieben. dem gestreckten Zeigefinger zu wählen. Diese Geste kann zudem auch gut erkannt werden. Das Zurücksetzen wurde von vielen mit einer Wischgeste verbunden. Dabei war die Hand geöffnet und bewegte sich schnell nach links und rechts. Fast genauso viele hielten die Fingerspitzen von Daumen und Zeigefinger zusammen. Dies sollte eine Null anmuten, die die Befragte mit der Ausgangsstellung oder Nullstellung verbanden. Das Wischen, das einem Winken ähnelt, benutzen wir bereits als Aktivierungsgeste. Es wäre aber nicht schlimm und, unserer Meinung nach, auch nicht verwirrend für den Benutzer, wenn diese Geste noch eine zweite Bedeutung bekäme. Möchte der Benutzer das Zurücksetzen initialisieren, wurde im Vorfeld seine Hand bereits vom System erkannt, sodass beim zweiten Wischen klar ist, dass er das Werkzeug bedienen möchte. Wir haben zwar soeben die offene Hand als eine Geste ausgeschlossen, jedoch in diesem Fall ist sie mit einer Bewegung verbunden, die einige Male wiederholt werden muss, sodass das System sie erkennen kann. Die Null, die mit Daumen und Zeigefinger geformt wird, erinnert sehr stark an die OK -Geste beim Tauchen. Grundsätzlich spricht aber nichts dagegen, diese Geste für das Zurücksetzen zu benutzen. Funktionen, die mit statischen Gesten ausgeführt werden, sollen in Abbildung 5.13.: Geste zum Zurücksetzen. 75

76 5. Entwurf eines berührungslosen Interfaces unserem System nur dann ausgelöst werden wenn der Benutzer die Handpositur einen bestimmten Zeitraum beibehält. Dies soll auch hier der Fall sein. Da ungefähr gleich viele das Wischen und die Null mit dem Zurücksetzen verbanden, entscheiden wir uns dafür, dass das System bei beiden Gesten dieses Werkzeug ausführen soll. Beide Gesten sind in Abbildung 5.13 dargestellt. Bei den beiden Werkzeugen, die nur im 2D-Inspektor zu bedienen sind, das Fenstern und das Durchblättern, konnten wir werder eine einheitliche Meinung noch eine Tendenz ausmachen. Festzustellen war, dass das Fenstern von fast allen Befragten mit Bewegungen analog zur Maus verbunden wurde. Hier stellt man, wie in Paradigma (a) beschrieben, die Weite durch Bewegungen nach links und rechts ein und die Position durch Bewegungen nach oben und unten. Da die Befragung keine eindeutigen Ergebnisse für die Handpositur lieferte, entscheiden wir uns nun für eine Faust (vergleiche Abbildung 5.14). Die Faust soll für das Symbol stehen, das häufig zum Einstellen der Helligkeit von Monitoren benutzt wird und so auch im MeVis LiverAnalyzer für die Fensterung übernommen wurde. Die Faust kann zudem auch gut anderen Gesten unterschieden werden. Das Durchblättern wurde von den Befragten sowohl durch Handbewegungen nach vorne und hinten als auch nach oben und unten durchgeführt. Auch hier gab es keine Tendenz in der Handpositur. Einige hielten jedoch einen Finger (manche den Daumen, manche den Zeigefinger) zur Seite. So entscheiden wir uns nun dafür den ausgestreckten Daumen zur Seite zu halten (vergleiche Abbildung 5.14) und die Hand vor und zurück zu schieben, um das Durchblättern zu initialisieren. Es kann vorkommen, dass der Benutzer die Hand nicht mehr weiter nach vorne oder schieben kann, sodass die Hand wieder zurück muss. Auch hier schlagen wir vor, dass die Hand in der Positur verweilt, bis die gewünschte Schicht erreicht ist. Abbildung 5.14.: Geste zum Fenstern (oben) und zum Durchblättern (unten). Dieses Konzept umfasst die Gestensteuerung unseres Systems, indem es Gesten vorschlägt, die losgelöst vom WIMP- und Touch-Paradigmen entwickelt wurden. Dazu benutzten wir eine Umfrage, in der sich gezeigt hat, dass einige Werkzeuge, wie das Skalieren oder das Fenstern, von den Befragten unmittelbar intuitiv mit einem der beiden Paradigmen verbunden wurden. Das Skalieren mit der Pinch-Geste ist ein gutes Beispiel dafür, dass eine solche Geste, die eigentlich für Touch-Interfaces bestimmt war, sich etabliert hat. Selbst die Befragten, die sich nur wenig mit Touch-Interfaces auskennen, nannten diese Geste, sodass wir daraus schließen, dass sie durch ihre Verbreitung inzwischen zu den intuitiven Handbewegungen gehört. In diesem Paradigma ist es möglich, schnell zwischen den Tools zu wechseln, ohne ständig ein Werkzeug auswählen zu müssen. In den Inspektoren mussten für sieben Werkzeuge Gesten gefunden werden. Hinzu kommt die Geste zum Ein- und Ausblenden der Kollektion und der Legende 76

77 5. Entwurf eines berührungslosen Interfaces und die zum Verschieben der Trennlinie zwischen den Inspektoren sowie die zur Interaktion im Kollektion-Fenster, sodass wir insgesamt auf zehn Gesten kommen. Wir sind der Meinung, dass der Benutzer sich alle Gesten merken kann, zum einen weil er die Gesten, die er verwenden muss, in einer Übersicht dargestellt bekommt und zum anderen, weil die Ergebnisse in unserer Befragung größtenteils sehr eindeutig waren. So ist zu erwarten, dass alle Gesten erlernbar und zu merken sind. Sobald jedoch mehr Werkzeuge in den Inspektoren erwünscht sind bedeutet dies als Schlussfolgerung, dass weitere Gesten für sie gefunden werden müssen. Diese Gesten müssen sich dann von denen, die wir bereits festgelegt haben unterscheiden, und zwar so sehr, dass sie technisch auch gut zu erfassen sind. Unserer Ansicht nach genügen allerdings die Werkzeuge, die wir in unseren funktionalen Anforderungen erörtert haben, sodass dieser Nachteil kein unmittelbares Ausschlusskriterium für dieses Konzept darstellt. Interaktion im Aktualisierungsbereich Abbildung 3.3 verdeutlicht bereits die Schritte, die nötig sind um einen Resektionsschnitt zu setzen beziehungsweise zu ändern. Diese sind: 1. Läsion im 2D-Inspektor einzeichnen 2. Resektionslinien im 3D-Inspektor ändern 3. Berechnen der Resektionsebenen initialisieren 4. Resektionsebene im 3D-Inspektor verschieben 5. Resektionsebene im 3D-Inspektor verformen 6. Erstellen des Resektionsplans initialisieren Beim Aktualisieren des Resektionsplans tun sich zwei Problemfelder auf: Ein Zeiger, entsprechend dem Mauszeiger, muss eingesetzt werden um die nötige Präzision zu gewährleisten und ein schneller Wechsel zwischen den Werkzeugen des Visualisierungsbereichs und denen des Aktualisierungsbereichs muss ermöglicht werden. Für Punkt 1, 2, 4 und 5 ist ein Zeiger, vergleichbar mit dem Mauszeiger, in jedem Fall nötig. Um diesen zu steuern, muss die Hand sehr präzise verfolgt werden. Eine Klickgeste, dies entspricht der Bewegung der Hand zum Sensor hin und wieder weg, kann einem Mausklick entsprechen. Dabei kann nicht ausgeschlossen werden, dass während der Ausführung die Position des Punktes versehentlich verändert wird. Das Drag-and-Drop, das beim Zeichnen der Resektionslinien und beim Verformen und Verschieben der Resektionsebenen eingesetzt wird, kann simuliert werden, indem die Hand eine definierte Positur einnimmt, bewegt wird und dann wieder geöffnet wird. Beim Ausführen der Schritte zur Aktualisierung des Resektionsplans muss häufig die Ansicht geändert werden. Schritt 2 geschieht zum Beispiel durch abwechselndes Zeichnen der Resektionslinie und Rotieren des 3D- Modells, sodass die Linie die gesamte Leber umfasst. Diese beiden Problemfelder machen den Aktualisierungsbereich so komplex, dass wir ihn im Rahmen dieser Arbeit nicht bis ins Detail erörtern werden. In Paradigma (a) soll das Anpassen des Resektionsplans eine weitere Kategorie in der Werkzeugleiste darstellen. In dieser Kategorie können die sechs Punkte wieder gefunden werden. Sie können nur hintereinander ausgeführt werden. Geht der Benutzer einen Schritt zurück, werden 77

78 5. Entwurf eines berührungslosen Interfaces seine letzten Aktionen rückgängig gemacht. Beim ersten Schritt, dem Einzeichnen der Läsion, muss die entsprechende Schicht, in der sich die zusätzlich gefundene Läsion befindet, im 2D- Inspektor ausgewählt werden. Der Benutzer muss also die Kategorie wechseln und das Werkzeug Durchblättern auswählen. Beim Setzen der Resektionslinie muss das 3D-Modell mehrmals rotiert werden und die Linie eingezeichnet werden. Es müsste also sehr häufig die Kategorie gewechselt werden, um das Rotieren und das Einzeichnen abwechselnd auszuführen. Im nächsten Schritt sollen die Resektionsebenen anhand der gezeichneten Linien berechnet werden. Dies soll durch eine Geste initialisiert werden. Wählt der Benutzer das Verschieben oder das Verformen der Resektionsebene aus, muss das Drag-and-Drop durch Gesten erfolgen. Hier wird das 3D-Modell sehr häufig rotiert, skaliert und verschoben, um die Resektionsebenen so zu verändern, dass der Tumor restlos entfernt werden kann. Das häufige Wechseln in den Kategoien verlangsamt die Durchführung und führt letztendendes zur Frustration des Benutzers. In Paradigma (b) kann das Winken mit der zweiten Hand das Aktualisieren initialisieren. In dem Fall soll eine Leiste auf dem Bildschirm erscheinen, in der die einzelnen Schritte abgearbeitet werden können. Im ersten Schritt muss im 2D-Inspektor zur gewünschten Schicht geblättert werden, in der sich die zusätzlich gefundene Läsion befindet. Die Geste für das Durchblättern ist, wie oben definiert, die Hand zu einer Faust zu formen, wobei der Daumen ausgestreckt ist und zur Seite zeigt, und nach vorne oder hinten bewegen. Daraufhin kann der Punkt, an dem sich die Läsion befindet, ausgewählt werden und durch eine Klickgeste signalisiert werden, dass der gesuchte Punkt gefunden ist. Im zweiten Schritt kann mit einer Hand das 3D-Modell rotiert werden (durch das Drehen der geöffneten Hand) und die andere Hand zeichnet die Linie währenddessen ein. Nachdem die Resektionsebenen berechnet wurden, sollen sie verändert werden. Auch hier ist es hilfreich, dass mit einer Hand schnell die Ansicht transformiert werden kann, um einen optimalen Blick den Tumor zu erhalten. Vorraussetzung ist dabei, dass der Benutzer alle Gesten kennt und schnell anwenden kann, um den häufigen Wechsel und teilweise auch gleichzeitigen Nutzen der Werkzeuge effektiv ausführen zu können. Nebst der Problematik die beiden Gesten und Handbewegungen zu koordinieren, muss auch das System in der Lage sein, gleichzeitig beides zu erkennen. Konklusion Während Paradigma (a) sich mehr an die Steuerung mit Maus beziehungsweise Touchscreen anlehnt, stellt Paradigma (b) eine Steuerung dar, die völlig losgelassen von den bekannten Computereingabemöglichkeiten interagiert. Eine Entscheidung, welche der beiden Paradigmen intuitiver oder komfortabler ist, lässt sich objektiv nicht entscheiden. Eine Bewertung der Paradigmen nach den von Stern et al. aufgestellten menschlichen Aspekten [65] soll nun geschehen, um das für unser System optimale Gestenvokabular zu finden. Stern fordert, wie oben bereits beschrieben, dass Gesten, die ein System steuern, vier Faktoren besonders beachtet werden müssen: Natürlichkeit, Lern- und Merkförderlichkeit sowie Ermüdungserscheinungen. Wir bezeichnen Gesten als natürlich, wenn sie in Dialogen spontan und ungeplant erfolgen. Cassell stellt dazu die sogenannten ausdruckskräftigen Gesten (englisch: propostional gestures) vor. Dies sind Gesten, die zwar nicht unbewusst gemacht werden, aber dennoch spontan. Darunter zählen die Gesten, die gemacht werden, um zum Beispiel Größen zu verdeutlichen oder Richtungen anzuzeigen. Cassell bezeichnet diese Art Gesten als besonders wichtig in aufgabenorientierten Gesprächen [17]. So lässt sich unsere Interaktion mit der Anwendung ver- 78

79 5. Entwurf eines berührungslosen Interfaces gleichbar als aufgabenorientierten Dialog mit dem Computer bezeichnen. Wir haben versucht mit der Umfrage spontane Gesten für die Interaktion zu finden. Die Antworten waren zwar teilweise von WIMP- oder Touchparadigmen abgeleitet, jedoch wurden sie in den Fällen so eindeutig genannt, dass man sie wieder als intuitiv bezeichnen kann. Aus unserem Vorgehen lässt sich ableiten, dass die Gestensteuerung in Paradigma (a) weniger natürlich ist als die in Paradigma (b), da sie an die Interaktion mit einer Maus anlehnt, während die Gesten in Paradigma (b) empirisch ermittelt wurden. Die Lern- und Merkförderlichkeit lässt sich am besten beurteilen, indem man einige Testpersonen die Applikation bedienen lässt und dabei festmacht, wie viele Fehler sie in der Durchführung einer Aufgabe machen. Dies ist zu diesem Zeitpunkt noch nicht möglich. Im Allgemeinen aber fordert Paradigma (a) nur zwei Gesten eine zur Auswahl des Werkzeugs und eine zum Anwenden des ausgewählen Werkzeugs. Paradigma (b) dagegen erwartet sieben verschiedene Gesten, eine für jedes Werkzeug. In beiden Paradigmen kommen noch die Gesten für das Einund Ausblenden der Kollektion und der Legende, für das Verschieben der Trennlinie zwischen den Inspektoren und für die Interaktion im Kollektion-Bereich hinzu. Insgesamt erfordert Paradigma (b) einen höheren Aufwand, um sich alle Gesten zu merken und sie den Werkzeugen zuordnen zu können. Dennoch erwarten wir, dass sie alle erlernbar und unterscheidbar sind. Ermüdungserscheinungen treten dann auf, wenn die Anwendung ständig benutzt wird. Dies soll allerdings im Visualisierungsbereich nicht der Fall sein. Hier soll der Chirurg nur die Ansicht kurz nebenbei ändern, wenn es nötig ist, zum Beispiel wenn bestimmte Gefäße die Sicht auf den Tumor verhindern. Im Aktualisierungsbereich verhält es sich jedoch anders. Paradigma (b) trägt dazu bei, dass zwischen den Werkzeugen schnell gewechselt werden kann. Bei einer Erweiterung des Systems um den Aktualisierungsbereich kann es zum Beispiel ein großer Vorteil sein, dass beim Setzen der Schnittlinie mit einer Hand die Linie eingezeichnet werden kann und gleichzeitig mit der anderen das 3D-Modell rotiert werden kann. Dies wäre bei Paradigma (a) nicht möglich, da hier ständig zwischen den beiden Tools gewechselt werden müsste. Zusammenfassend erwarten wir für Paradigma (a) einen kleineren Merkaufwand, sodass mit dieser Art der Interaktion einer Fehlbedienung vorgebeugt werden kann. Dennoch glauben wir, dass die sieben geforderten Gesten für das Paradigma (b) vom Benutzer durchaus gelernt und auch unterschieden werden können. Wenn wir die Erweiterung des Systems berücksichtigen, müssen wir uns für Paradigma (b) entscheiden. Im nächsten Abschnitt dieses Kapitels soll ein Modell unseres Entwurfs gezeigt werden, das mittels Paradigma (b) bedient werden kann Modell Im Folgenden stellen wir das Modell vor, das sich an der obigen Diskussion orienteiert. Hier ist die grafische Benutzeroberfläche aus Entwurf III wiederzufinden zusammen mit der konzipierten Interaktionsmöglichkeit aus Paradigma (b). Abbildung 5.15 zeigt das Mock-up, bei dem der 3D-Modell zu zwei Drittel und der 2D-Inspektor zu einem Drittel dargestellt sind. Hier ist der 3D-Inspektor aktiv, sodass in der Übersicht der Gesten (im unteren Bereich des Modells) die Gesten dargestellt sind, die den 3D-Inspektor steuern. Die Pfeile am oberen und am linken Rand stehen für die Legende und die Kollektion, die bei Bedarf auf den Bildschirm gezogen werden können. In Abbildung 5.16 ist der 3D-Inspektor als Vollbild dargestellt. Um zu dieser Ansicht zu gelangen, muss der Benutzer die Trennlinie nach rechts geschoben haben. 79

80 5. Entwurf eines berührungslosen Interfaces Abbildung 5.15.: Modell I: Der 3D-Inspektor ist aktiv, der 2D-Inspektor ist zum Vergleich der Daten auch sichtbar. Die Übersicht zeigt die Gesten zum Steuern des 3D-Inspektors. Abbildung 5.16.: Modell II: Der 3D-Inspektor ist als Vollbild dargestellt. Die Übersicht zeigt die Gesten zum Steuern des 3D-Inspektors. 80

81 5. Entwurf eines berührungslosen Interfaces Die Interaktionen im 2D-Inspektor sind dann möglich, wenn der 2D-Inspektor zu mindestens zwei Dritteln wiedergegeben wird, wie es in Abbildung 5.17 der Fall ist. Hier sind in der Übersicht der Gesten die Gesten zur Steuerung des 2D-Inspektors dargestellt, die größtenteils mit denen des 3D-Inspektors übereinstimmen. Abbildung 5.18 zeigt die Anwendung, in der die Trennlinie zwischen 3D- und 2D-Inspektor ganz nach links geschoben wurde. Hier ist der 2D- Inspektor als Vollbild dargestellt. Abbildung 5.17.: Modell III: Der 2D-Inspektor ist aktiv, der 3D-Inspektor ist zum Vergleich der Daten auch sichtbar. Die Übersicht zeigt die Gesten zum Steuern des 2D-Inspektors. 81

82 5. Entwurf eines berührungslosen Interfaces Abbildung 5.18.: Modell IV: Der 2D-Inspektor ist als Vollbild dargestellt. Die Übersicht zeigt die Gesten zum Steuern des 2D-Inspektors. Abbildung 5.19 und 5.20 zeigen die Anwendung, wenn die Kollektion beziehungsweise die Legende in den sichtbaren Bereich des Bildschirm gezogen wurde. Ist die Kollektion sichtbar, sind in der Übersicht die beiden Gesten zu finden, mit der man das Ringmenü drehen kann und eines der Repräsentationen des 3D-Modells auswählen kann. Ist die Legende sichtbar verlangt es nach keiner weiteren Interaktion, sodass in der Übersicht nur die Geste zum Ausblenden der Legende dargestellt ist. 82

83 5. Entwurf eines berührungslosen Interfaces Abbildung 5.19.: Modell V: Die Kollektion ist sichtbar. Die Übersicht der Gesten passt sich demnach an. Abbildung 5.20.: Modell VI: Die Legende ist sichtbar. Die Übersicht der Gesten passt sich demnach an. 83

84 Prototypische Beispielimplementierung 6 Um die technische Seite der Problematik auch im Detail zu betrachten, haben wir uns mit den Möglichkeiten der tatsächlichen Umsetzung des Konzept befasst. Da die komplette Umsetzung unseres Konzepts den Rahmen einer Bachelorarbeit sprengen würde, haben wir uns als Ziel gesetzt, mit der Kinect zumindest die Steuerung der Fensterung im 2D-Inspektor umzusetzen (siehe Abschnitt 3.1.1). Dazu gehört das Erkennen der Hand und die kontrollierte Manipulation der Fensterungsparameter. Kontrolliert bedeutet in diesem Fall, dass die Handposition nicht direkt nach Erkennen der Hand Einfluss auf die Fensterungsparameter hat, sondern nur dann, wenn es vom Benutzer gewollt ist (vergleiche Midas-Touch-Problem in Abschnitt 5.1.2). Da die Aktivierungsgeste von der von uns eingesetzten OpenNI-Middleware NITE (Winken oder Klicken) am einfachsten mit offener Hand ausgeführt werden kann, legen wir fest, dass die tatsächliche Manipulation der Parameter bei geschlossener Hand geschehen soll. Bewegungen nach links und rechts bewirken Änderungen in der Fensterbreite und Bewegungen nach oben und unten verschieben die Fensterposition. Dieses Kapitel stellt keine komplette Umsetzung unseres Konzepts dar, sondern soll als Einstiegspunkt für eine eventuelle zukünftige Umsetzung dienlich sein. Im folgenden Abschnitt 6.1 sollen zunächst die verwendeten Bibliotheken, Frameworks und Technologien vorgestellt werden, bevor dann in Abschnitt 6.2 deren Einsatz und der allgemeine Programmaufbau beschrieben wird Verwendete Technologien, Frameworks, Bibliotheken Wir haben uns dafür entschieden die Entwicklungsumgebung MeVisLab [47] zu nutzen, um die Umsetzung zu realisieren. Zu Beginn unserer Arbeit war die Erschließung der Microsoft Kinect noch nicht sehr weit fortgeschritten. Zu der Zeit taten sich zwei Projekte hervor, die Treiber stellten, die es ermöglichen, die Kinect mit Computern zu nutzen: OpenKinect [54] und die PrimeSense-/OpenNI-Initiative [60, 1]. Letzteres nutzten wir für unsere Implementierung. Dennoch sollen beide Projekte in diesem Abschnitt kurz vorgestellt werden. Nebst der Überlegung, welches Framework und welchen Treiber wir nutzen, entschieden wir uns des Weiteren für die Verwendung der OpenCV-Bibliothek [2]. Eine kurze Zusammenfassung über die verschiedenen 84

85 6. Prototypische Beispielimplementierung Technologien, Framworks und Bibliotheken findet im Folgenden statt. MeVisLab ist eine Entwicklungsumgebung mit Hauptaugenmerk auf die Visualisierung medizinischer Bilddaten von der MeVis Research GmbH. Die Programmierung geschieht über Netzwerke, die aus Modulen und Konnektoren zwischen den Modulen bestehen. Module beinhalten Algorithmen in der Programmiersprache C++. MeVisLab stellt viele Module bereit, die Aufgaben erfüllen, die häufig im Zusammenhang mit medizinischen Bilddaten genutzt werden. So kann zum Beispiel sehr schnell definiert werden, dass das Durchblättern im 2D-Inspektor abhängig von der Position der Maus durchgeführt wird. In unserem Fall müssen wir auf die Parameter zugreifen, die die Fensterung im 2D-Inspektor festlegen, und zwar so, dass sie sich abhängig von der Handposition verändern. Das Modul, das die Fensterung steuert, ist in MeVisLab bereits vorhanden, sodass es unsere Aufgabe ist, ein Modul zu schreiben, das erkennt, dass der Benutzer die Fensterung initialisieren möchte und daraufhin seine Hand verfolgt [47]. Vergleich OpenKinect vs. PrimeSense/OpenNI mit NITE OpenKinect [54] ist eine Gemeinschaft, mit dem Ziel ein Open-Source-Bibliotheken zur Verfügung zu stellen, mit denen es möglich ist, die Kinect auf unterschiedlichen Systemen zu verwenden. Sie benutzt dazu den Treiber und die Bibliotheken der libfreenect-software, mit der unter anderem auf das RGB- und das Tiefenbild und den Motor der Kinect zugegriffen werden kann. So kann auf den Systemen Windows, Linux und Mac OS X mittels sogenannten Wrappern in verschiedenen Programmiersprachen Software entwickelt werden, die die Funktionen der Kinect nutzt. Kurz nachdem sich die OpenKinect Communtiy bildete gab PrimeSense [60] bekannt, dass sie in Zusammenarbeit mit OpenNI [1], einen eigenen Treiber veröffentlichen werde. Prime- Sense entwickelt 3D-Technologien und lieferte ebenso die Sensortechnologie für das Projekt Natal, das später als die Kinect für die Xbox 360 von Microsoft vorgestellt wurde. OpenNI ist eine Organisation, die Geräte, Applikationen und sogenannte Middlewareprodukte für Natural Interaction (deutsch: natürlichliche Interaktion, im Folgenden NI genannt) fördert. Sie bietet ein Framework mit entsprechender API (Application Programming Interface). Mit dem OpenNI- Framework lassen sich Anwendungen für NI entwickeln, wobei OpenNI die Kommunikation zwischen Middleware und dem Sensor regelt. Dabei liefert PrimeSense den Treiber für die Kinect und nannte ihn PrimeSensor. Ein Beispiel für eine Middleware ist NITE [59] von Prime- Sense. Ein Teil von NITE besteht in der Skelett-Erkennung und -Verfolgung. Ein weiterer, und das ist der für uns wichtigere, hilft bei dem Erkennen von Handbewegungen und bei der Interpretation von einfachen Handgesten, wie das Winken, die Bewegung der Hand Richtung Sensor und das Verbleiben der Hand an einer Stelle. Während die OpenKinect-Gemeinschaft sich nach eigenen Angaben, mehr darauf konzentriert, eine Schnittstelle in der Programmiersprache C zu entwickeln, bietet OpenNI ein Framework in C++. Dies war der Hauptgrund, weshalb wir uns dafür entschieden haben, OpenNI und NITE zu nutzen, da die Module in MeVisLab auf C++ basieren. Bei den ersten Versuchen ergab sich eine Inkompatibiltät des PrimeSensors auf Mac OS X Systemen. Eine Lösung lieferte SensorKinect 1, eine veränderte Version des PrimeSensors. Ein weiterer Unterschied zwischen 1 Die einzigen Informationen über SensorKinect sind unter verfügbar. 85

86 6. Prototypische Beispielimplementierung den beiden Projekten sind die Linzenzen. Libfreenect untersteht der General Public License (im Folgenden GPL genannt) und OpenNI der Lesser General Public License (im Folgenden LGPL genannt) [26]. Der wesentliche Unterschied zwischen den zwei Lizenzen liegt darin, dass Programme, die LGPL-lizenzierte Software einbinden, unter bestimmten Umständen nicht gleich lizenziert werden müssen. Das ist zum Beispiel dann der Fall, wenn die Bibliotheken der Software dynamisch vom Programm geladen werden. Dieser Aspekt fällt aber erst ann ins Gewicht, wenn die geschriebene Anwendung kommerziell genutzt werden soll. Ein weiterer Punkt, der hier nicht unerwähnt bleiben soll, ist die Entwicklungsumgebung Kinect for Windows SDK beta 2. Diese Entwicklungsumgebung kann bisher nur auf Windows7 Betriebssystemen installiert werden und umfasst unter anderem eine Skelett- und Spracherkennung. Eine Handerkennung wird noch nicht unterstützt. Dennoch ist abzusehen, dass in naher Zukunft das Kinect for Windows SDK eine sinnvollere Lösung für eine Entwicklung einer Software ist, die die Funktionen der Kinect nutzt. OpenCV ist eine Open-Source-Bibliothek für die Bildverarbeitung (englisch: Computer Vision). Die Bildverarbeitung bezeichnet die Interpretation sowie die neue Repräsentation von Daten einer Kamera. Zudem beinhaltet die OpenCV-Bibliothek Algorithmen, die ein sogenanntes Machine-Learning ermöglichen. Das Machine-Learning ist für unsere Zwecke besonders wichtig, da das System so bestimmte Gesten erlernen kann. Die OpenCV-Bibliothek ist in den Programmiersprachen C und C++ geschrieben und läuft unter Linux, Windows und Mac OS X. OpenCV setzt den Fokus auf die Echtzeitverarbeitung. So können Anwendungen geschrieben werden, die mit den Daten einer Kamera arbeiten und mittels OpenCV interpretiert werden. Die OpenCV-Lizenz erlaubt die Produktion von kommerzieller Software [2] Überblick über Programmaufbau und Algorithmen Wir bauen in unserer Implementierung auf das VideoBackend-Modul aus MeVisLab auf, das allgemein für die Video-Wiedergabe geschrieben wurde und von uns entsprechend der nötigen Gestenerkennung (das heißt: Anbindung an NITE und eigene darauf aufbauende Algorithmen) angepasst wurde. Durch die direkte Einbindung als MeVisLab-Modul haben wir die Möglichkeit, leichter eine Verbindung zu anderen MeVisLab-Modulen beispielsweise einem 2D-Inspektor herzustellen und diese zu steuern. Wir haben die NITE-Anbindung und die aufbauenden Algorithmen jedoch auch als Standalone-Version ohne MeVisLab umsetzen können. Obwohl OpenCV in den neuesten Revisionen mittlerweile die Kinect als Eingabegerät unterstützt, konnten wir die Implementierung in dieser Bibliothek nicht direkt nutzen, wenn wir gleichzeitig die NITE-Middleware verwenden wollten. Der Grund dafür ist kurz zusammengefasst, dass die Kinect-Treiber-Bibliothek OpenNI ein Kontext-Objekt verwendet, das auch an die NITE-Middleware übergeben werden muss, von OpenCV aber in der momentanen Version versteckt wird, sodass nicht darauf zugegriffen werden kann 3. Wir mussten daher die Kinect- 2 Kinect for Windows SDK beta kann seit dem 16. Juni 2011 unter en-us/um/redmond/projects/kinectsdk/default.aspx herunter geladen werden. 3 Um es genauer und ausführlicher zu formulieren: Video-Quellen werden in OpenCV mit der cv::videocapture()-funktion abgerufen, die lediglich Matrizen (cv::mat-objekte) mit Bilddaten 86

87 6. Prototypische Beispielimplementierung Unterstützung von OpenCV an unsere Bedürfnisse anpassen. Die NITE-Middleware ist nicht quelloffen und die Methoden zur Handerkennung werden nicht beschrieben. Zum Aktivieren der Handverfolgung muss eine dynamische Geste erfolgen. Das kann ein Winken sein, bei der die Hand mehrfach von links nach rechts und zurück bewegt wird, oder eine Klickgeste, bei der die Hand zur Kamera hin und wieder zurück bewegt wird. Ein Farb- oder Formenabgleich findet offensichtlich nicht statt, da beim richtigen Bewegungsmuster auch andere Gegenstände als Hand erkannt werden. NITE bietet auch keine Möglichkeiten zur Positurenbestimmung an. Zur grundsätzlichen Lokalisierung einer möglichen Hand ist das System jedoch durchaus hilfreich. In unserer Implementation gehen wir von dem von NITE als zu einer Hand gehörig erkannten Punkt aus und erstellen eine binäre Maske, die lediglich alle Punkte enthält, die einen ähnlichen Tiefenwert haben. Dieses Vorgehen stellt eine sehr effektive und simple Form der Hintergrundsegmentierung dar. Zu beachten ist, dass der NITE-Algorithmus manchmal ungenau arbeitet, der Handpunkt ist dann beispielsweise zwischen den Fingern, wodurch zwar in diesen Momenten die ungefähre Position der Hand korrekt wiedergegeben wird, jedoch der Tiefenwert unbrauchbar wird. Es muss also überprüft werden, ob der Tiefenwert unrealistisch stark schwankt, um diese Ausreißer herauszufiltern. Außerdem ist es wichtig, Gegenstände, die in der gleichen Tiefenebene liegen, aber nicht zur Hand gehören, herauszufiltern. Dazu eignet sich eine Maske, die nur den Bereich um den Trackingpunkt der Hand berücksichtigt, der einer realistischen Handgröße entspricht (wir verwenden hier eine relativ großzügige runde Maske, deren Radius von den Tiefeninformationen abhängt, also kleiner wird, je weiter die Hand von der Kamera entfernt ist) und in dieser Maske alles wegzuschneiden, was zur Hauptfläche gehört. Dazu eignet sich die Methode floodfill() von OpenCV, die ausgehend von einem sogenannten Seed Point all die Pixel als zur Fläche zugehörig erkennt, die durch gleiche Farbwerte miteinander verbunden sind 4. Vor diesem Schritt ist ein Closing 5 der Flächen sinnvoll. Diese binäre Maske, die nun nur noch die Hand enthält, eignet sich, um mit dem Tarabella- Algorithmus, wie er in Abschnitt beschrieben ist, einen simplen Positurenabgleich durchzuführen. Der Klassifikator muss in unserem Fall nur erkennen, ob die Hand offen oder geschlossen ist, wobei offen als Standardwert gelten kann, sodass nur der geschlossene Zustand erkannt werden muss. Mit diesen Informationen kann nun die von uns gewünschte Funktionalität umgesetzt werden: Nur wenn eine geschlossene Hand erkannt wird, werden die Positionsänderungen an das 2D-Inspektor-Modul weitergeleitet und die Fensterungsparameter entsprechend geändert. des momentan aufgenommenen Frames der Kinect zurück gibt. Der komplette auf OpenNI basierende Unterbau wird somit vor dem Anwender versteckt, was für uns problematisch war, da wir mit NITE eine sogenannte OpenNI-Middleware einsetzen wollten, für deren Einsatz Zugriff auf den OpenNI-Unterbau nötig ist. 4 Man kennt einen ähnlichen Effekt beispielsweise auch aus Bildbearbeitungsprogrammen, die Werkzeuge anbieten, mit denen man zusammengehörende Flächen mit einer Farbe füllt. 5 Closing wird das aufeinanderfolgende Ausführen einer Erweiterung und anschließend einer Verringerung der hellen Bereiche der Maske genannt und bewirkt, dass kleinere Flächen, die z.b. durch Rauschen entstanden sind und keinen Aussagewert haben, verschwinden. 87

88 7 Konklusion Wir haben die Aspekte, die bei der Konzeption einer brauchbaren Software zur Unterstützung des Chirurgen und weiteren Personals während Leberresektionen nötig sind, erörtert und jeweils gezeigt, welche Probleme sich ergeben und welche Ansätze sich zur Lösung dieser Probleme eignen. Unsere Analyse des Operationssaals als Anwendungsbereich für HCI ergab, dass sich eine Handgestensteuerung gut für diese Aufgabe eignen kann, wenn die dazu benötigte Technik klein genug und leicht im Aufbau beziehungsweise in Hinsicht auf Kalibrierung und ähnliche Maßnahmen leicht zu handhaben ist. Eine Gegenüberstellung einiger 3D-Kamera-Systeme konnte zeigen, dass sich unter diesen Bedingungen besonders die Kinect von Microsoft für die Aufgabe empfiehlt, insbesondere, wenn auch die finanzielle Komponente eine Rolle spielt, was bei der prekären finanziellen Situation vieler Krankenhäuser durchaus der Fall sein sollte. Eine Zusammenstellung momentan eingesetzter Handgestenerkennungsalgorithmen konnte zeigen, dass die Algorithmenwahl, sofern es sich nicht um nur sehr wenige zu erkennende Posituren handelt, im Moment noch auf trackingbasierte Algorithmen fallen müsste, wenn auch die Zukunft bei einzelbildbasierten Echtzeit-Posituren-Erkennungsalgorithmen ohne Positureneinschränkungen liegt, wie sie für die Kanzkörperpositurenerkennung seit kurzem bereits erfolgreich im Spielebereich etabliert wurde. Eine ähnliche Technologie für die Handgestenerkennung ist in nicht all zu ferner Zukunft zu erwarten. Wir haben die nötigen und sinnvollen funktionalen Anforderungen für eine entsprechende Software aufgezeigt. Diese teilen sich in den Visualisierungsbereich und den Aktualisierungsbereich. Mit einer Analyse möglicher GUI-Varianten konnten wir zeigen, dass zumindest der einhändig bedienbare Visualisierungsbereich in zufriedenstellender Weise umsetzbar ist. Nach einer Abwägung unterschiedlicher Möglichkeiten haben wir einen begründeten Vorschlag für ein GUI-Konzept geliefert und darauf hingewiesen, was bei der tatsächlichen Umsetzung beachtet werden muss. Der Aktualisierungsbereich hingegen ist wenn nur sehr schwerfällig mit einer einhändigen Bedienung zu realisieren und selbst ein praktikables Interface für ein zweihändige Bedienungsschnittstelle stellt durchaus eine ernstzunehmende Herausforderung dar, die jedoch eventuell durch den hohen Nutzen einer solchen Funktion gerechtfertigt werden könnte, da die Möglichkeit der intraoperativen Aktualisierung der Planung eine starke Entlastung für den Patienten darstellt, der keinen zweiten Operationstermin über sich ergehen lassen muss. 88

89 7. Konklusion Wenn auch die Umsetzung der vollständigen Applikation den Rahmen dieser konzeptionellen Arbeit sprengen würde, haben wir zumindest als praktischen Einstieg in die Thematik die mögliche Implementierung einer einfachen Gestensteuerung für die Fensterungsfunktion des Visualisierungsbereichs beschrieben. Durch diesen praktischen Teil unserer Arbeit konnten wir zeigen, dass eine Umsetzung in C++ mit Hilfe der Open-Source-Bibliotheken OpenNI (mit der proprietären Middleware NITE) und OpenCV und der Entwicklungsumgebung MeVisLab möglich ist. Nach anfänglichen Konfigurationsschwierigkeiten erwies sich dieser Ansatz als praktikable Lösung, wenn auch noch zu untersuchen ist, ob die erst kürzlich von Microsoft offiziell veröffentlichte Entwicklungsumgebung für Windows-Betriebssysteme einen einfacheren Weg zur Umsetzung unserer Applikation unter Einsatz der Kinect darstellt. Für eine entsprechende Untersuchung war der Zeitraum zwischen Veröffentlichungstermin der Entwicklungsumgebung und Abgabetermin der Arbeit zu kurz. Wir halten jedoch auch mit unserem Ansatz die komplette Applikation für umsetzungsfähig, wenn auch für eine so dezidierte Gestensteuerung ein mächtigerer Erkennungsalgorithmus als der von uns verwendete erscheinungsbasierte Algorithmus von Tarabella. Ein nächster Schritt wäre dann, das von entwickelte System hinsichtlich der umgesetzten Mensch-Computer- Interaktion einem standardisierten Test zu unterziehen. Ein sinnvoller Weg wäre, diesen Test in Form einer standardisierten Studie nach dem von Korb und Jannin [37] vorgestellten Rahmenkonzept durchzuführen. Alternativ oder ergänzend kann die Gebrauchstauglichkeit nach einer von Backhaus [9] vorgestellten Methodik beurteilt werden. 89

90 A Lichttest mit der Kinect im Operationssaal Streifenprojektions-Scanner können bei zu starker Beleuchtung unbrauchbar werden, was sich vor allem beim Einsatz im Freien bemerkbar macht. Um die Tauglichkeit der Kinect für unser Vorhaben zu testen, haben wir daher einen Lichttest bei voller Beleuchtung (das heißt Umgebungslicht auf höchster Stufe und alle Leuchtstrahler eingeschaltet) in der Asklepios Klinik Barmbek durchgeführt. Die Abbildung A.1 auf der folgenden Seite zeigt drei Fotos, die mit der Kinect aufgenommen wurden, jeweils ein RGB-Bild und ein Tiefenbild. Die Darstellung der Tiefenbilder zeigt deutlich, dass selbst direkt unter den Leuchtstrahlern die Tiefeninformationen der Hand korrekt wiedergegeben werden: Wäre der Bereich zu hell, würden die zu hellen Bereiche der Hand schwarz angezeigt 1. Der Einsatz der Kinect im Operationssaal wird also nicht durch die starke Ausleuchtung behindert. 1 Dass dennoch einige Bereiche schwarz angezeigt werden, liegt am sogenannten 3D-Schatten, der daraus resultiert, dass der Sender des Lichtmusters räumlich nicht an derselben Position sein kann wie der Empfänger. 90

91 A. Lichttest mit der Kinect im Operationssaal Abbildung A.1.: Drei Aufnahmen aus dem Operationssaal. Rechts jeweils das RGB-Bild, links das zugehörige Tiefenbild, bei dem die verschiedenen Graustufen zur besseren Sichtbarkeit der Tiefenverhältnisse eingefärbt wurden. 91