3D-Rekonstruktion extraokulärer Augenmuskeln aus MR ... - SEE-KID

Fachhochschul-Studiengang
SOFTWARE ENGINEERING
A-4232 Hagenberg, Austria
3D-Rekonstruktion extraokulärer
Augenmuskeln aus MR-Bilddaten
Diplomarbeit
zur Erlangung des akademischen Grades
Diplom-Ingenieur (Fachhochschule)
Eingereicht von
Franz Anton Pirklbauer
September 2001
Betreuer: Dipl.-Ing. (FH) Michael Buchberger
Begutachter: FH-Prof. Dipl-Ing. Dr. Herwig Mayr

Eidesstattliche Erklärung
Ich erkläre, dass ich die Diplomarbeit selbstständig verfasst, andere als die angegebenen
Quellen und Hilfsmittel nicht verwendet und mich auch sonst keiner unerlaubten Hilfe bedient
habe.
Hagenberg, im September 2001 Franz Pirklbauer

KURZFASSUNG v
Kurzfassung
In der Medizin produzieren tomographische Messverfahren immer genauere Abbildungen von
menschlichen Körperteilen. Verschiedenste Bilderzeugungsverfahren, wie Magnetresonanztomographie
oder Computertomographie, liefern dabei Bilder, die bereits einen hohen Detaillierungsgrad
aufweisen. Derartige Bilder werden nicht nur zur Unterstützung von Diagnose
und Therapie eingesetzt, sie können auch Grundlage für Modelle sein, die Abläufe im menschlichen
Körpers simulieren.
Das Forschungsprojekt SEE-KID am Fachhochschulstudiengang Software-Engineering für
Medizin in Hagenberg hat sich zum Ziel gesetzt, eine Simulation des menschlichen Auges am
Computer zu verwirklichen. Im Rahmen dieses Projektes ist unter anderem eine möglichst
realistische Darstellung der extraokulären Augenmuskeln gefordert und in der vorliegenden
Arbeit beschrieben.
Für die Umsetzung dieser Anforderungen kommen Verfahren der medizinischen Bildverarbeitung
zum Einsatz, die größtenteils ihren Ursprung in der digitalen Bildverarbeitung haben.
Spezielle Magnetresonanzbilder, die wenige Millimenter hinter dem Augapfel aufgenommen
werden, bilden dabei die Grundlage. Darauf aufbauend werden mit verschiedenen Segmentationsverfahren,
wie der Schwellwertanalyse oder dem Scan-Line Verfahren, die Bilder vorbereitet
und schließlich mit dem sogenannten Marching-Cube-Algorithmus analysiert. Das
Ergebnis dieser Verarbeitungsschritte ist ein dreidimensionales Polyedermodell, welches einen
Augenmuskel repräsentiert. Durch die Abspeicherung in einer DXF-Datei kann das so erstellte
Modell von einem beliebigen, 3D-fähigen Grafikprogramm dargestellt werden.

ABSTRACT vii
Abstract
Tomographical measuring systems are producing increasingly exact images from the human
body. Different techniques, like magnetic resonance tomography or computer tomography,
provide high level of details in the images. Primarily such images are used to support the
medicians in diagnoses and therapeutics. Furthermore these images can supply the basics
for models which simulate processes in the human body.
The reasearch project SEE-KID at the Upper Austrian Polytechnic University in Hagenberg,
Department of Software Engineering for Medicine, wants to build a simulation of the human
eye. To simulate the extraocular eye muscles as realisticly as possible, a visualization of these
muscles is necessary.
To visualize the eyemuscles we need methods from medical image processing which are mainly
derived from digital image processing. The basis for our work are special magnetic resonance
images, which were taken with an offset of only a few millimeters behind the eyeball of
a human eye. To prepare these images several methods of segmentation, like threshold
analysis and the scan-line-method, are used. Finally the marching-cube-algorithm analyses
the images, builds a model of polyhedrons from the muscle surface and stores it in a DXF
file. This file can be visualized by any standard 3D graphic program.

viii

Vorwort
Das Gebiet der medizinischen Bildverarbeitung findet in dieser Arbeit eine sehr spezialisierte
Anwendung. Die Verarbeitung von medizinischen Bildern nimmt einen immer höheren
Stellenwert ein. Die Menge von Bildern, die zur Unterstützung von Medizinern im Bereich
der Diagnostik und Therapie wesentliche Erleichterung bringen, wird immer größer. Der
Grund ist wohl darin zu suchen, dass das menschliche Auge visuelle Informationen leichter
verarbeiten kann als Informationen in Textform.
Eine der wichtigsten Anforderungen an bildverarbeitende Systeme ist die dreidimensionale
Darstellung von menschlichen Organen. Das Ergebnis dieser Arbeit ist ein System, das extraokuläre
Augenmuskeln aus Magnetresonanzbildern segmentiert, die Oberfläche analysiert
und schließlich dreidimensional darstellt. Dabei kommen Algorithmen aus der digitalen Bildverarbeitung
zum Einsatz, die in Kap. 2 genauer beschrieben werden. Weiters wird in diesem
Kapitel eine Einführung in das medizinische Umfeld gegeben.
Entstanden ist diese Arbeit aus einer Initiative des Forschungsprojektes SEE-KID am Fachhochschulstudiengang
Software-Engineering für Medizin, das sich schon seit einiger Zeit mit
der Erstellung eines Augenmodells beschäftigt. Kap. 3 beschreibt nicht nur den Zusammenhang
dieser Arbeit mit dem Projekt SEE-KID, sondern definiert auch die genauen Anforderungen
an das System.
Die eigentliche Verarbeitung der Bilder, die von der Beschaffung der Bilder über die Bildaufbereitung
bis hin zum Analysieren und Generieren einer Objektoberfläche reicht, ist in
Kap. 4 beschrieben. Dabei wird besonders auf die verwendeten Verfahren und Algorithmen
eingegangen, die zentraler Bestandteil der Arbeit sind. In Kap. 5 ist die detailierte Umsetzung
der Algorithmen erklärt, wobei kurze Quellcodeausschnitte im Anhang und zahlreiche
Bilder ein leichteres Verständnis bringen sollen.
Die theoretische Beschreibung des entstandenen Systems, wird in Kap. 6 anhand eines einfachen
Beispiels in die Praxis umgesetzt. Dabei wurde vor allem Anwendung und die Praxisrelevanz
dargestellt. Darüber hinaus wurde ein Vergleich mit einem kommerziellen Softwaresystem
angestellt.
In Kap. 7 und Kap. 8 werden persönliche Erfahrungen und Verbesserungsmöglichkeiten angegeben.
Diese Arbeit dient als Grundlage bzw. als Vorarbeit für weitere Projekte. Daher steht
am Abschluss ein kurzer Ausblick auf noch geplante Arbeitsschritte, die schließlich wieder in
das Projekt SEE-KID einfließen sollen.
ix

x DANK
Dank
Diese Arbeit entstand als Diplomarbeit am Fachhochschulstudiengang Software Engineering
in Hagenberg. Mein Dank gilt allen Mitarbeitern dieses Instituts, denn die fundierte
Ausbildung, die ich durch deren Engagement genießen konnte, war ein wesentlicher Motivationsfaktor
für mich. Mein spezieller Dank gilt Herrn FH-Prof. Dipl.-Ing. Dr. Herwig Mayr
und Herrn Dipl.-Ing. (FH) Michael Buchberger für die Betreuung dieser Arbeit und allen
Mitarbeitern der Forschungsabteilung der FH-Hagenberg für die gute Zusammenarbeit und
die Hinweise zu meiner Arbeit.
Franz Pirklbauer

Inhaltsverzeichnis
Vorwort ix
1 Einführung 1
1.1 Modellierung in der virtuellen Chirurgie . . . . . . . . . . . . . . . . . . . . . 1
1.2 Generierung von 3D-Augenmuskelmodellen aus MR-Bildern . . . . . . . . . . 2
2 Grundlagen 5
2.1 Medizintechnische Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Anatomie des menschlichen Auges . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Magnetresonanztomographie . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Softwaretechnische Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1 Scan-Line-Verfahren für Polygone . . . . . . . . . . . . . . . . . . . . . 10
2.2.2 Marching-Cube-Algorithmus . . . . . . . . . . . . . . . . . . . . . . . 12
3 Problemstellung 17
3.1 Das Forschungsprojekt SEE-KID . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.1 Projektziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.2 Projektgeschichte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.3 Bisherige Projektergebnisse . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.4 Projektpartner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Notwendigkeit einer Muskelvisualisierung . . . . . . . . . . . . . . . . . . . . 21
3.3 Segmentierung und Visualisierung von Augenmuskeln . . . . . . . . . . . . . 22
4 Systemmodell und Ablauf 25
4.1 Beschaffung von Bildern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Bildaufbereitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.1 Sortieren der Farbpalette . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.2 Definition von Polygonbereichen . . . . . . . . . . . . . . . . . . . . . 27
4.2.3 Definition von Schwellwerten . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 Generieren eines Polyedermodells . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.1 Erstellen des Datenvolumens . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.2 Schwellwertanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3.3 Zurückführen auf Grundkonfigurationen . . . . . . . . . . . . . . . . . 32
4.3.4 Definition der Polyeder . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4 Plattformunabhängige Abspeicherung . . . . . . . . . . . . . . . . . . . . . . 38
xi

xii INHALTSVERZEICHNIS
5 Implementierung 41
5.1 Beschreibung des statischen Klassenmodells . . . . . . . . . . . . . . . . . . . 41
5.2 Bildbearbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2.1 Ausgangspunkt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2.2 Veränderungen an den Bildern . . . . . . . . . . . . . . . . . . . . . . 44
5.2.2.1 Farbpalette . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2.2.2 Polygon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2.2.3 Schwellwertbereich . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2.3 Abspeichern der Zwischenergebnisse . . . . . . . . . . . . . . . . . . . 47
5.3 Generierung eines Polyedermodells . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3.1 Erstellung eines Volumensmodells . . . . . . . . . . . . . . . . . . . . 48
5.3.2 Polygongenerierung mithilfe des Marching-Cube-Algorithmus . . . . . 49
5.3.3 Abspeicherung der Resultate . . . . . . . . . . . . . . . . . . . . . . . 53
6 Anwendung und Ergebnisse 55
6.1 Beispiel: Rekonstruktion des m. rect. med. aus Coronalschnitten . . . . . . . . 55
6.2 Vergleich der Ergebnisse mit anderen Anwendungen . . . . . . . . . . . . . . 59
7 Vorgehen aus der Sicht des Software-Ingenieurs 63
8 Schlussbemerkungen 65
8.1 Ergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.2 Verbesserungsmöglichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.3 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
A Quellcodebeispiele 69
A.1 Farbpalette setzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
A.2 Polygonaktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
A.3 Datenvolumen generieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
A.4 Kantenschwellwert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
B Screenshots 75
C Glossar 79
Literatur 83

Abbildungsverzeichnis
1.1 Bildanalyse, Mustererkennung und Visualisierung . . . . . . . . . . . . . . . . 1
2.1 Blick von oben auf das rechte Auge . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Schematische Darstellung eines geraden Augenmuskels mit Ursprung, Tangentialund
Insertionspunkt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Blicklinie, Vertikal- und Horizontalachse; Rotationen zu anderen Blickpositionen 7
2.4 MR-Bilder des menschlichen Auges mit axialer (A), sagittaler (B) und coronaler
(C) Schichtführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 a) Polygon um den m. rect. sup. b) Polygon mit Scan-Linie c) gefülltes Polygon 11
2.6 Sonderfälle des Scan-Line-Verfahrens beim Auftreffen der Scan-Linie auf einen
Eckpunkt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.7 Definition eines Würfels im Marching-Cube-Algorithmus . . . . . . . . . . . . 13
2.8 Standardkonfigurationen beim Marching-Cube-Algorithmus . . . . . . . . . . 14
3.1 Screenshot vom Programm SEE++ . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Augenvisualisierung nach Miller . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1 Vereinfachtes Beispiel zum Sortieren der Farbpalette . . . . . . . . . . . . . . 27
4.2 Polygonbeispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 Definition eines Schwellwertbereiches . . . . . . . . . . . . . . . . . . . . . . . 29
4.4 Segmentierung der Bilddaten . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5 Invertierung der Würfelkonfiguration . . . . . . . . . . . . . . . . . . . . . . . 32
4.6 Zurückführung auf eine Standardkonfiguration . . . . . . . . . . . . . . . . . 34
4.7 Beschriftung der Würfeleckpunkte und Kanten . . . . . . . . . . . . . . . . . 35
4.8 Zurückrotieren der Dreiecke . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.1 Statisches Klassenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2 Feld zur Verwaltung der Paletteneinträge . . . . . . . . . . . . . . . . . . . . 44
5.3 Screenshot vom Programm zur Bildbearbeitung . . . . . . . . . . . . . . . . . 45
5.4 Aufbau eines Würfels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.1 Sortieren der Farbpalette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2 Öffnen der Bilddateien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.3 Mögliche Schwellwert- und Polygondefinition . . . . . . . . . . . . . . . . . . 57
6.4 Ausschnitte der manipulierten Bilder . . . . . . . . . . . . . . . . . . . . . . . 58
6.5 3D-Rekonstruktion des m. rect. med. . . . . . . . . . . . . . . . . . . . . . . . 59
6.6 Blick durch den m. rect. med. . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.7 Ausschnitt aus dem Voxel-Man 3D-Navigator . . . . . . . . . . . . . . . . . . 61
xiii

xiv ABBILDUNGSVERZEICHNIS
6.8 3D-Rekonstruktion von Sehnerv und Bulbus . . . . . . . . . . . . . . . . . . . 62
B.1 Unterer Schwellwert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
B.2 Unterer und oberer Schwellwert . . . . . . . . . . . . . . . . . . . . . . . . . . 76
B.3 Oberer Schwellwert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Tabellenverzeichnis
4.1 Übersicht über die verwendeten MR-Bildfolgen . . . . . . . . . . . . . . . . . 25
4.2 Vorkommen der Grundkonfigurationen . . . . . . . . . . . . . . . . . . . . . . 34
4.3 Zuweisung der Dreieckseckpunkte auf die Würfelkanten . . . . . . . . . . . . 37
5.1 Beispiel für die Dateibenennung . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2 Definition der Würfel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.1 Schwellwertbereiche der Bildserie . . . . . . . . . . . . . . . . . . . . . . . . . 58
xv

xvi TABELLENVERZEICHNIS

Kapitel 1
Einführung
1.1 Modellierung in der virtuellen Chirurgie
In der modernen Medizin nehmen Bildverarbeitungssysteme einen immer höheren Stellenwert
ein. Dies liegt vor allem daran, dass das menschliche Auge wesentlich mehr Informationen
in Bildform verarbeiten kann als in Tabellen- oder Textform. Verschiedenste Techniken
und Verfahren der Bildgewinnung, wie etwa die Röntgentechnik, die Computertomographie
(CT) oder die Magnetresonanztomographie (MRT), bieten dem Arzt Unterstützung bei Diagnostik
und Therapie. Zahlreiche Krankheiten können nur mit derartigen Visualisierungen
festgestellt werden. Sämtliche Verfahren liefern ein oder mehrere zweidimensionale Bilder
von spezifischen Körperregion. Die Aufgabe der medizinischen Bildverarbeitung ist es, diese
Bildfolgen so aufzubereiten, dass sie dreidimensional am Bildschirm sichtbar werden.
Eine der wichtigsten Anforderungen an diagnoseunterstützende Bildanalysesysteme ist die
Darstellung von medizinischen Bildobjekten wie Gewebe, Tumore, Knochen, Muskeln oder
ganzer Organe. Die technische Umsetzung basiert auf Verfahren und Techniken aus den
Bereichen der Bildanalyse, Mustererkennung und Visualisierung (Abb. 1.1), wobei diese Bereiche
eng miteinander verbunden und voneinander abhängig sind.
Mustererkennung
Bildanalyse Visualisierung
Abbildung 1.1: Bildanalyse, Mustererkennung und Visualisierung
1

2 KAPITEL 1. EINFÜHRUNG
Dieser Zusammenhang wird in [Handels, 2000] wie folgt beschrieben:
• Die Bildanalyse hat die Extraktion von Objekten und ihre quantitative Beschreibung
zum Ziel. Einen wichtigen Teilschritt bildet hier die Segmentierung, d.h. die algorithmische
Abgrenzung medizinischer Bildobjekte in Bildern und Bildfolgen. Sie ist
grundlegend für die weitergehende Analyse von Bildobjekten sowie ihre dreidimensionale
Visualisierung.
• Die Mustererkennung beschäftigt sich mit der automatischen Verarbeitung, Analyse
und Erkennung von Mustern. Eine Vielzahl von Fragestellungen der medizinischen
Diagnostik kann als Mustererkennungsproblem modelliert werden. Medizinische Bilder
werden in diesem Kontext als komplexe Untersuchungsergebnisse aufgefasst, wobei die
Mustererkennung speziell auf die Erkennung von Bildstrukturen (Gewebe, Gefäße, etc.)
gerichtet ist.
• Bei der Visualisierung werden Techniken aus dem Beriech der Computergraphik zur
Darstellung medizinischer bilder und Bildfolgen sowie der durch Bildanalyse- und Mustererkennungsverfahren
erhaltenen Ergebnisse eingesetzt. Sie erleichtern das Verständnis
und die Interpretation der vielfältigen Informationen, die aus medizinischen Bilddaten
extrahiert werden können.
Auf Basis dieser Dreiecksbeziehung soll ein System erstellt werden, dass ausgehend von medizinischen
Bildfolgen die Bereiche der Augenmuskeln segmentiert, die Oberfläche selbständig
abtastet und eine Visualisierung des gesuchten Augenmuskels liefert.
1.2 Generierung von 3D-Augenmuskelmodellen aus MR-Bildern
Die derzeit vorhandenen Systeme aus dem Bereich der medizinischen Bildverarbeitung bieten
zum Teil eine gute Verwaltung von Schnittbildern bis hin zu einer guten Visualisierung von
Körperteilen. Allerdings ist es bei keinem System möglich, die gewünschten Visualisierungsbereiche
selbst auszuwählen bzw. die Ergebnisse vernünftig abzuspeichern. Diese Tatsache
war der Grund dafür, eine eigene Realisierung eines medizinischen Bildverarbeitungssystems
anzugehen.
Die Anforderungen an eine spezielle Rekonstruktion der extraokulären Augenmuskeln lassen
sich wie folgt auflisten:
• Der Ausgangspunkt für die Arbeiten sind Magnetresonanzbilder des menschlichen Auges.
• Mithilfe von entsprechenden Verfahren und Algorithmen aus der digitalen Bildverarbeitung
ist die gesuchte Objektoberfläche zu segmentieren und zu analysieren.
• Die dreidimensionale Visualisierung muss die Oberfläche möglichst originalgetreu nachstellen
und von allen Seiten betrachten lassen können.

1.2. GENERIERUNG VON 3D-AUGENMUSKELMODELLEN AUS MR-BILDERN 3
• Die Ergebnisse müssen in einem verbreitet verwendeten Format abgespeichert und so
anderen Programmen zur Verfügung gestellt werden.
• Die Interaktion des Benutzers ist auf einige wenige Eingriffe zu reduzieren.
Die Arbeitsschritte, die zur Erreichung dieses Ziels notwendig sind, lassen sich zunächst grob
in drei Bereiche aufteilen:
1. Beschaffung der Bilder,
2. Bearbeiten der Bilder,
3. Analyse und Generierung der Objektoberfläche.
Zur Beschaffung der Bilder wurde eng mit spezialisten aus dem Bereich der Erstellung von
Magnetresonanzbildern zusammengearbeitet. Diese Bilder werden in das Bitmap-Format
umgewandelt und dann weiter bearbeitet.
Die Manipulation der Bilder umfasst
• das Sortieren der Farbpalette,
• die Definition von Polygonbereichen und
• die Definition von Schwellwertbereichen.
Durch das Sortieren der Farbpalette wird der Vergleich der Farben vereinfacht, womit die
späteren Arbeiten wesentlich erleichtert werden. Um die Auswahl von speziellen Körperregionen
zu ermöglichen, werden Polygone definiert, die z. B. einen Augenmuskel umschließen
und somit für die Verarbeitung markieren. Ein spezieller Farbbereich kann durch die
Definition von einem Schwellwertbereich definiert werden. Die Farbpunkte, die nicht den
Augenmuskel darstellen, werden so eliminiert.
Um eine Oberfläche des Muskels zu rekonstruieren, ist
• ein spezielles Datenvolumen zu erstellen,
• eine Schwellwertanalyse durchzuführen,
• die Folge der Bilder mit einem geeigneten Algorithmus zu analysieren,
• eine Oberfläche zu generieren und
• diese Oberfläche abzuspeichern.
Bei all diesen Arbeiten wird unter anderem auf bereits bekannte Algorithmen und Vorgehensweisen
zurückgegriffen. Neben der Vorstellung dieser wird im nächsten Kapitel eine kurze
Einführung in das medizinische Umfeld gegeben.

4 KAPITEL 1. EINFÜHRUNG

Kapitel 2
Grundlagen
2.1 Medizintechnische Grundlagen
2.1.1 Anatomie des menschlichen Auges
Die Augen zählen zu den wichtigsten Sinnesorganen des menschlichen Organismus. Sie liefern
uns ein ständig aktualisiertes Bild der Welt um uns. Eine Beschreibung von Aufbau und
Funktionsweise der Augen ist für das Verständnis des Umfeldes dieser Arbeit von grundlegender
Bedeutung. Die folgenden Erläuterungen beziehen sich auf das rechte Auge.
Der Augapfel (lat. bulbus oculi, kurz bulbus, ø ca. 2.4 cm, annähernd kugelförmig lt. [Pschyrembel,
1994]) liegt geschützt in der Augenhöhle (Orbita), welche eine Vertiefung in den
Schädelknochen ist. Der Bulbus ist zwiebelschalenartig aus drei Schichten aufgebaut [Schäffler
und Schmidt, 1998]:
• sklera (Lederhaut): äußere Augenhaut,
• choroidea (Aderhaut): mittlere Augenhaut,
• retina (Netzhaut): innere Augenhaut.
Für die Bewegung des Bulbus sind die sechs extraokulären Augenmuskeln verantwortlich. Die
vier geraden Augenmuskeln (musculi recti) und die beiden schrägen Augenmuskeln (musculi
obliqui) entspringen in der Augenhöhle und setzen an der Lederhaut des Augapfels an.
Abb. 2.1 zeigt den Ursprung der Muskeln in der Orbita und den Ansatz (Insertion) auf dem
Bulbus. Die hauptsächliche Wirkungsrichtung jedes Muskels lässt sich aus der Bezeichnung
ableiten [Brugger, 2000]:
• musculus rectus superior (oberer gerader Augenmuskel): nach oben,
• musculus rectus inferior (unterer gerader Augenmuskel): nach unten,
• musculus rectus lateralis (äußerer gerader Augenmuskel): seitwärts nach außen,
5

6 KAPITEL 2. GRUNDLAGEN
• musculus rectus medialis (innerer gerader Augenmuskel): seitwärts nach innen,
• musculus obliquus superior (oberer schräger Augenmuskel): nach unten und außen,
• musculus obliquus inferior (unterer schräger Augenmuskel): nach oben und innen.
Abbildung 2.1: Blick von oben auf das rechte Auge
Die rechtwinkelig zueinander angeordneten musculi recti entspringen in der Spitze der Orbita.
Ihre Endsehnen vereinigen sich zu einer ringformigen Sehnenplatte (Zinn’scher Ring)
und ihre Insertionen liegen vor der Äquatorialebene des Bulbus (vgl. [Günther, 1986]). Im
Gegensatz dazu setzen die musculi obliqui hinter dem Bulbusäquator an und ziehen schräg
nach vorne. Dadurch ist auch zu erklären, dass sich die Wirkungsrichtung umkehrt. Der
m. obl. sup. ist der längste aller Augenmuskeln. Ausgehend von der Insertion läuft er oberhalb
des Bulbus in Richtung des nasalen Stirnbeins, durchzieht eine knorpelige Rolle (die
Trochlea) und verläuft von hier aus direkt zu seinem Ursprung nahe am Zinn’schen Ring.
Der m. obl. inf. entspringt am nasalen Rand des knöchernen Orbitabodens, läuft unterhalb
des Bulbus um den m. rect. inf. herum und setzt im hinteren Bereich des Augapfels an. Im
Bereich der Überkreuzung von m. obl. inf. und m. rect. inf. existiert eine sehnige Verbindung
zwischen den beiden Muskeln, die ligamentum lockwood genannt wird [Günther, 1986].
Jeder Augenmuskel besteht neben dem rein muskulären Anteil auch aus einem sehnigen
Anteil. Die Sehnen stellen die Verbindung des Muskels zum Ursprung auf der einen Seite,
bzw. zum Insertionspunkt auf der anderen Seite her. Die Gesamtlänge (Muskel und Sehne)
der Augenmuskeln ist sehr unterschiedlich. Die größten Unterschiede weisen dabei die Längen
der Sehnen auf (vgl. [Kaufmann, 1995]). Der m. obl. inf. weist mit 0 bis 2 mm die kürzeste
und der m.obl.sup. mit 25 bis 30 mm die längste Sehne auf. Die eigentliche Muskellänge
liegt zwischen 30 mm (bei den mm. obliqui) bis 39 mm (beim m. rect. inf.).
Durch die Lage des Insertionspunktes vor bzw. hinter dem Bulbusäquator verläuft jeder
Muskel zum Teil auf der Bulbusoberfläche. Erst beim Tangentialpunkt endet der Kontakt
zum Bulbus und der Muskel zieht in Richtung seines Ursprungs (vgl. Abb. 2.2). Bei jeder
Bewegung des Bulbus ändert sich auch die Lage der Insertionspunkte relativ zur Orbita.

2.1. MEDIZINTECHNISCHE GRUNDLAGEN 7
Könnten sich die einzelnen Muskeln zwischen Insertionspunkt und Ursprung bei einer Augenbewegung
frei bewegen, hätte dies eine Verschiebung der Muskeln auf der Bulbusoberfläche
zur Folge. Dadurch würde sich der Muskelpfad und somit die Wirkungsrichtung verändern.
Um dies zu verhindern, umgibt eine bindegewebsartige Hülle den Bulbus und stabilisiert die
Muskeln im Bereich des Tangentialpunktes. Diese Stabilisatoren werden Pulleys genannt
(vgl. [Buchberger und Mayr, 2000], [Miller und Demer, 1996]).
Ursprung
Tangentialpunkt
Bulbusmittelpunkt =
Rotationspunkt
Insertionspunkt
Abbildung 2.2: Schematische Darstellung eines geraden Augenmuskels mit Ursprung,
Tangential- und Insertionspunkt
Abbildung 2.3: Blicklinie, Vertikal- und Horizontalachse; Rotationen zu anderen Blickpositionen
Die Bewegung des Bulbus entspricht annähernd einer Rotation eines Objektes im dreidimensionalen
Raum um eine bestimmte Achse. Der Bulbusmittelpunkt kann dabei als Rotationszentrum
gesehen werden. Die Blicklinie ist ein Vektor vom Bulbusmittelpunkt durch
die Mitte der Pupille. Normal dazu liegen die Vertikal- und die Horizontalachse, wobei der
Schnittpunkt dieser drei Achsen im Bulbusmittelpunkt liegt (vgl. Abb. 2.3a). Die Medizin
unterscheidet grundsätzlich drei Augenpositionen (vgl. [Kaufmann, 1995]):
• Primärposition: Das Auge blickt bei fixiertem Kopf geradeaus ins “Unendliche“. Es
wird angenommen, dass in dieser Position alle Muskeln am wenigsten gespannt sind.
Aus dieser Lage sind alle anderen Blickpositionen mit möglichst geringem Energieaufwand
erreichbar.
• Sekundärposition: Ausgehend von der Primärposition erfolgt eine Rotation um die
horizontale oder vertikale Achse (Abb. 2.3b). Das Auge blickt nach links oder rechts
bzw. nach oben oder unten.

8 KAPITEL 2. GRUNDLAGEN
• Tertiärposition: Ausgehend von der Primärposition erfolgt eine Rotation um die horizontale
und vertikale Achse (Abb. 2.3c). Das Auge blickt z. B. nach links oben oder
nach rechts unten. Die Kombination um zwei Achsen kann auch durch eine Rotationsachse
dargestellt werden, die in der durch horizontale und vertikale Achse aufgespannten
Ebene liegt (Abb. 2.3d).
Beide Augen können nur in binokularer Gemeinschaft miteinander bewegt werden, d.h. die
Bewegung nur eines Auges ist in der Regel nicht möglich (vgl. [Günther, 1986]). Die Augenmuskeln
sind in der Lage, das Auge sehr schnell und punktgenau zu positionieren. Darüber
hinaus kann das Auge ohne Ermüdung in einer bestimmten Stellung gehalten werden.
2.1.2 Magnetresonanztomographie
Die medizinische Bildverarbeitung ist geprägt durch eine große Vielfalt verschiedener Bildarten,
die zur Unterstützung der medizinischen Diagnostik und Therapie generiert werden.
Die bekanntesten Techniken sind lt. [Handels, 2000]:
• die Ultraschalltechnik (Sonographie),
• die Röntgentechnik,
• die Computertomographie (CT) als Weiterentwicklung der Röntgentechnik und
• die Magnetresonanztomographie (MRT, oder MR), auch als Kernspintomographie
bekannt.
Die Grundlage dieser Arbeit stellen MR-Schnittbildfolgen des menschlichen Auges dar, weshalb
hier nur diese Technik genauer beschrieben wird.
Die physikalische Grundlage der Magnetresonanztomographie bildet das Phänomen der kernmagnetischen
Resonanz, das 1946 von Felix Bloch und Edward M. Purcell entdeckt wurde
(vgl. [Brockhaus, 1989]). Die kernmagnetische Resonanz beruht auf der Wechselwirkung
zwischen Atomkernen mit bestimmten Eigenschaften und einem äußeren Magnetfeld. In
der medizinischen MR-Bildgebung spielt das Wasserstoffatom eine wesentliche Rolle, da der
menschliche Körper zu 70 % aus Wasser besteht.
Wasserstoff ist ein schwach positiver Magnet. Das Zufallsprinzip bewirkt, dass diese “Magnete“
im menschlichen Körper keine geordnete Richtung haben (Prinzip: Chaos). Ein von außen
einwirkendes Magnetfeld großer Stärke ordnet diese Felder in eine Richtung (vgl. [Kauffmann
et al., 1996]). Nach dieser Anregung bewegen sich die angeregten Wasserstoffatome auf ihren
Gleichgewichtszustand zurück und strahlen dabei Energie in Form elektromagnetischer
Wellen ab. Je nach dem, wieviele Wasserstoffatome in einem bestimmten Bereich vorhanden
sind, verändert sich die abgestrahlte Energie. Diese Veränderungen sind messbar und im
MR-Tomographen kann ein Bild des gesuchten Organs rekonstruiert werden. Eine genauere
Beschreibung dieses Vorgangs ist in [Dössel, 2000] und [Morneburg, 1995] zu finden.

2.1. MEDIZINTECHNISCHE GRUNDLAGEN 9
MR-Bilder weisen einen sehr hohen Weichteilkontrast auf. Muskeln und Nerven heben sich
beispielsweise klar vom umgebenden Fettgewebe ab. Gewebsveränderungen, wie z.B. Tumore,
lassen sich deutlich erkennen und millimetergenau lokalisieren. Demgegenüber ist eine
Darstellung von Knochenstrukturen in MR-Bildern nur eingeschränkt möglich, da hier
lediglich vom fetthaltigen Knochenmark MR-Signale empfangen werden. In diesem Fall
kommt vorrangig die Computertomographie zum Einsatz, die auf der Abschwächung von
Röntgenstrahlen, die durch den Körper geleitet werden, basiert.
Im Gegensatz zu CT-Aufnahmen können MR-Bilder für verschiedene Körperschichten in beliebiger
Orientierung erzeugt werden, ohne dass eine Umlagerung des Patienten durchgeführt
werden muss. Grundsätzlich wird zwischen drei Schichtführungen unterschieden. Die Beschreibungen
stammen aus [Roche, 1999] und Abb. 2.4 zeigt Beispiele von MR-Aufnahmen
eines menschlichen Auges:
• axial: in Richtung einer Achse; In diesem speziellen Fall handelt es sich um Aufnahmen
entlang der Augenachse, welche die Verbindungslinie zwischen vorderem und hinterem
Augapfelpol darstellt. Axiale Bilder entsprechen dem Blick von oben oder unten auf
das Auge (Abb. 2.4A).
• sagittal: parallel zur Sagittalebene; Die Sagittalebene ist eine Ebene in der Körperlängsachse
streng von hinten nach vorn bzw. umgekehrt. Sagittale Bilder entsprechen
dem Blick von links bzw. rechts auf das Auge (Abb. 2.4B).
• coronal: parallel zur Frontalebene; Die Frontalebene ist die in Richtung der Körperlängsachse
auf der Sagittalebene senkrecht stehende Körperebene. Sie verläuft in etwa
parallel zur Stirn. Coronale Bilder entsprechen dem Blick von vorne auf das Auge
(Abb. 2.4C).
Digitale, medizinische Bilder werden zumeist in einer zweidimensionalen Matrix repräsentiert.
Die Bildpunkte werden hierbei kurz als Pixel (engl.: picture element) bezeichnet. Die Anzahl
der Bildpunkte ist eine Maßzahl für die Auflösung des Bildes. Eine weitere, wichtige Kenngröße
digitaler medizinischer Bilder ist die Grauwerttiefe, die angibt, wie fein diskretisiert
die gemessenen Signale in der Bildmatrix repräsentiert werden können (vgl. [Handels, 2000]).
Ein 2D-Bild, bei dem jedes Pixel mit einem Byte (= 8 Bit) abgespeichert wird, ergibt ein
Grauwertbild mit 256 verschiedenen Graustufen.
Aus den Schichtbildern kann ein Volumendatensatz erzeugt werden, indem alle Einzelbilder in
der topologischen Reihenfolge in einem Datensatz zusammengefügt werden. Eine derartige
3D-Bildfolge ist eine Sequenz von 2D-Bildern gleicher Schnittführung, die hintereinander
gelegt eine bestimmte Körperregion repräsentieren. Ein Pixel eines Schichtbildes wird auf
diese Weise als Volumenelement (Voxel) interpretiert (vgl. [Kaiser, 1999]).

10 KAPITEL 2. GRUNDLAGEN
Abbildung 2.4: MR-Bilder des menschlichen Auges mit axialer (A), sagittaler (B) und coronaler
(C) Schichtführung
2.2 Softwaretechnische Grundlagen
2.2.1 Scan-Line-Verfahren für Polygone
Die MR-Bilder, die als Grundlage dieser Arbeit dienen, enthalten naturgemäß mehr Informationen
als nur eine einfache Abbildung der Augenmuskeln. Um bei einem Segmentierungsvorgang
nicht das gesamte Bild durchlaufen zu müssen, wird der Betrachtungsbereich durch ein
Polygon eingegrenzt, das aus genau einer Fläche besteht und das zu untersuchende Objekt
einschließt (vgl. Abb. 2.5a). Beim späteren Generieren einer Objektoberfläche ist es notwendig,
die gewünschten Bereiche aller Bilder zeilenweise bzw. Pixel für Pixel durchzulaufen, um
jeden Bildpunkt analysieren zu können. Das Scan-Line-Verfahren für Polygone stellt genau
diese Funktionalität zur Verfügung.
Ein Polygon (Vieleck), ist eine Figur, die entsteht, wenn eine feste Anzahl von Punkten
P1, P2, ..., Pn der Reihe nach durch ein Geradenstück verbunden wird: P1 mit P2, P2 mit
P3 ... Pn mit P1 (vgl. [Brockhaus, 1989]). Die Koordinaten dieser Eckpunkte dienen als
Eingabewerte für den Scan-Line-Algorithmus. [Vornberger et al., 1997] beschreibt die Idee
dieses Verfahrens so:
Bewege eine wagrechte Scan-Linie schrittweise von oben nach unten über das Objekt (Polygon),
und berechne die Schnittpunkte der Scan-Linie mit dem Objekt.
1. Sortiere alle Kanten nach ihrem größten y-Wert.
2. Bewege die Scan-Linie vom größten y-Wert bis zum kleinsten y-Wert.

2.2. SOFTWARETECHNISCHE GRUNDLAGEN 11
3. Für jede Position der Scan-Linie
• wird die Liste der aktiven Polygonkanten ermittelt,
• werden Schnittpunkte berechnet und nach x-Werten sortiert,
• werden jene Segmente der Scan-Linie angezeigt, die im Inneren des Polygons liegen.
Für jede Seite (Kante) des Polygons sind die Koordinaten xi, yi der Ecke mit dem Maximum
y, sowie die Differenzen ∆x, ∆y bekannt, aus denen sich die Koordinaten der anderen Ecke
berechnen lassen. Zunächst werden alle Kanten nach den größten y-Werten sortiert. Bei
Übereinstimmung werden die x-Werte bzw. ∆x und ∆y als Sortierkriterium herangezogen.
Die Sortierung der Kanten nach ihrem größten y-Werten ermöglicht den einfachen Aufbau
und die effiziente Aktualisierung einer Liste von aktiven Kanten. Eine Kante wird in diese
Liste aufgenommen, wenn der Endpunkt mit dem größerem y-Wert von der Scan-Linie
überstrichen wird, und wird wieder entfernt, wenn die Scan-Linie den anderen Endpunkt
überstreicht. Beim Beispiel in Abb. 2.5b stehen am Beginn die Kanten BA und BC in der
aktiven Liste. Erreicht die Scan-Linie den Punkt D werden auch die Kanten DC und DE in
die aktive Kantenliste aufgenommen.
Abbildung 2.5: a) Polygon um den m. rect. sup. b) Polygon mit Scan-Linie c) gefülltes Polygon
Jede Position der Scan-Linie teilt das Polygon in Schnitte mit den Eigenschaften, dass jeder
Schnitt eine geradzahlige Anzahl von Kanten enthält und dass das Innere eines Gebietes
zwischen den Kanten mit ungerader und mit gerader Kantennummer liegt (vgl. [Pavladis,
1990]). Im oben erwähnten Beispiel liegt demnach das Gebiet zwischen den Punkten A ′ und
B ′ . Das Ausfüllen vollzieht sich dadurch, dass für jede Position der Scan-Linie zwischen den
entsprechenden Schnittpunkten mit den Kanten eine Linie gezeichnet wird. Abb. 2.5c zeigt
ein Polygon, dass mit dem Scan-Line-Verfahren gefüllt wurde.
Damit der Algorithmus für ein beliebiges Polygon funktioniert, sind einige Sonderfälle zu
berücksichtigen (lt. [Vornberger et al., 1997]):
• Horizontale Kanten werden nicht in die Kantenliste aufgenommen. Für sie wird eine
Linie gezeichnet.

12 KAPITEL 2. GRUNDLAGEN
• Trifft die Scan-Linie auf einen Polygoneckpunkt, dessen Kanten beide oberhalb oder
beide unterhalb liegen, so zählt der Schnittpunkt doppelt (vgl. Abb. 2.6a und b).
• Trifft die Scan-Linie auf einen Polygoneckpunkt, dessen Kanten oberhalb und unterhalb
liegen, so zählt der Schnittpunkt nur einfach (vgl. Abb. 2.6c).
doppelt
doppelt
einfach
a) b) c)
Scan-Linie
Abbildung 2.6: Sonderfälle des Scan-Line-Verfahrens beim Auftreffen der Scan-Linie auf
einen Eckpunkt
2.2.2 Marching-Cube-Algorithmus
Um bestimmte Köprerregionen ausgehend von zweidimensionalen MR-Schnittbildfolgen dreidimensional
visualisieren zu können, ist es notwendig, die Oberflächen der anatomischen Objekte
aus dem Grauwert-Volumendatensatz zu extrahieren. Ein Algorithmus, der speziell für
diese Anforderung entwickelt wurde, ist der Marching-Cube-Algorithmus, der 1987 erstmals
von William E. Lorensen und Harvey E. Cline vorgestellt wurde (vgl. [Lorensen und Cline,
1987]). Es wird dabei ein Dreiecksmodell erstellt, das die Oberfläche des gesuchten Objektes
darstellt.
Für die Repräsentation von rekonstruierten Oberflächen aus Volumendaten hat sich mit
dem Dreieck die einfachste Polygonstruktur durchgesetzt. Die Vorteile gegenüber anderen
Polygonstrukturen sind (lt. [Kaiser, 1999]):
• Alle Punkte innerhalb eines Dreiecks liegen auf einer Ebene.
• Jedes ebene Objekt mit mehr als drei Ecken lässt sich in mehrere Dreiecke zerlegen.
• Die 3D-Visualisierung von Dreiecken kann leicht in Hardware durchgeführt werden.
Beim Marching-Cube-Algorithmus wird ein Voxel durch einen Punkt repräsentiert, dem ein
Signal-, Parameter- oder Grauwert f(x, y, z) zugeordnet wird. Der gesamte 3D-Bilddatensatz
wird somit als Punktgitter aufgefasst. Weiters wird ein Schwellwert t ∈ R definiert. Dieser
Schwellwert gibt jenen Farbwert an, der die gesuchte Oberfläche beschreibt. Jedes Voxel im
3D-Bilddatensatz kann so in eine binäre Form gebracht werden (vgl. [Handels, 2000]):
B(x, y, z) =
� 0, falls f(x, y, z) > t
1, falls f(x, y, z) ≤ t
(2.1)

2.2. SOFTWARETECHNISCHE GRUNDLAGEN 13
In dieser Arbeit wird der Algorithmus dahingehend erweitert, dass ein unterer (t1) und ein
oberer (t2) Schwellwert definiert werden. Die Formel 2.1 wird dementsprechend abgeändert:
B ′ �
0, falls f(x, y, z) < t1 ∨ f(x, y, z) > t2
(x, y, z) =
1, falls t1 ≤ f(x, y, z) ≤ t2
(2.2)
Diese Schwellwertanalyse ergibt ein Binärmuster des 3D-Bilddatensatzes, wobei ein Wert 1
bedeutet, dass das Voxel innerhalb des gesuchten Objektes liegt und ein Wert 0, dass sich
der Bildpunkt außerhalb des gesuchten Bereichs befindet.
Bei der Oberflächenrekonstruktion werden aus zwei benachbarten Schichten die lokalen Voxelkonfigurationen
bestehend aus 8 benachbarten Voxeln betrachtet, wobei jeweils 4 der Voxel
aus einer der beiden Schichten stammen. Die einzelnen Voxel werden somit als Eckpunkte
eines Würfels (bzw. eines Quaders) gesehen (vgl. Abb. 2.7). Wenn die Binärkonfigurationen
zweier benachbarter Eckpunkte des Würfels unterschiedlich sind, so heißt das, dass die gesuchte
Objektoberfläche zwischen diesen beiden Punkten liegen muss. Ein Punkt der gesuchten
Dreiecksoberfläche liegt also auf der Kante des Würfels, die durch die beiden Punkte
definiert ist.
Abbildung 2.7: Definition eines Würfels im Marching-Cube-Algorithmus
In jedem Würfel sind 2 8 = 256 binäre Konfigurationen möglich. Die Komplexität wird entscheidend
vereinfacht, indem sich der Algorithmus auf die Betrachtung von 15 Grundkonfigurationen
beschränkt (vgl. Abb. 2.8). Durch die Anwendung von einer Kombination der unten
aufgelisteten Aktionen, können alle 256 Konfigurationen auf diese Standardkonfigurationen
zurückgeführt werden (vgl. [Kaiser, 1999]):
• Drehungen um die drei Hauptachsen
• Spiegelungen an den drei Hauptachsen
• Invertierung der Eckenklassifizierung
Für jede Grundkonfiguration ist eine entsprechende Anordnung von Dreiecken vorgeschrieben,
die die Objektoberfläche wiedergibt (vgl. Abb. 2.8). Der einfachste Fall (0) besagt,

14 KAPITEL 2. GRUNDLAGEN
Abbildung 2.8: Standardkonfigurationen beim Marching-Cube-Algorithmus

2.2. SOFTWARETECHNISCHE GRUNDLAGEN 15
dass alle Punkte des Würfels innerhalb oder außerhalb des gesuchten Objektes liegen. Folglich
beinhaltet ein derartiger Würfel keine Oberflächendreiecke. Der nächsten Fall (1) tritt
genau dann auf, wenn sich ein Eckpunkt von den anderen sieben unterscheidet. Daraus resultiert
ein Oberflächendreieck, dessen Eckpunkte sich auf den entsprechenden Kanten des
Würfels befinden [Lorensen und Cline, 1987]. Alle anderen Fälle produzieren auf die selbe
Weise Dreiecke, wobei die genaue Position eines Dreieckspunktes auf einer Kante durch eine
Interpolation der Grauwerte der beteiligten Voxel bestimmt wird.
Mit dem Durchwandern (marching) dieser Würfel (cubes) durch das Datenvolumen wird der
gesamte 3D-Bilddatensatz analysiert und eine Oberfläche des gesuchten Objektes erstellt.
Der große Vorteil bei der Triangulation mit dem Marching-Cube-Algorithmus besteht darin,
dass die Reihenfolge der Abarbeitung keine Rolle spielt.
Abgesehen vom trivialen Fall 0 werden in jedem Würfel zwischen 1 und 4 Dreiecke erzeugt,
wodurch eine große Anzahl an Dreiecken entsteht und glatte Flächen unnötig oft unterteilt
werden. Trotz dieser Tatsache hat sich der Algorithmus vor allem wegen seiner hohen Detailtreue
gegenüber anderen Triangulationsalgorithmen durchgesetzt (vgl. [Kaiser, 1999], [Tiede,
1999b]). Die voxelige Struktur wird durch den Algorithmus vollständig aufgelöst. Die dabei
entstehende sehr glatte Oberflächenbeschreibung eignet sich sehr gut für eine anschließende
Reduktion der Dreiecke. Darüber hinaus liefert der Algorithmus immer eine eindeutige
Lösung und der Rechenaufwand ist verhältnismäßig gering.

16 KAPITEL 2. GRUNDLAGEN

Kapitel 3
Problemstellung
3.1 Das Forschungsprojekt SEE-KID
Das Erkennen der Ursachen und das Korrigieren pathologischer Fälle verlangt vom Experten,
gerade in der Augenmedizin, ein hohes Maß an geometrischer Vorstellungsgabe und Fähigkeit
zur Modellbildung. Hier bietet die computerunterstützte Modellbildung und Simulation der
Vorbereitung von Augenoperationen exzellente Hilfe.
Die Sehschule des Konventhospitals der Barmherzigen Brüder Linz hat sich darauf spezialisiert,
angeborene und erworbene Fehlstellungen der Augen (Motilitätsstörungen, Schielen,
Nystagmus) bei Kleinkindern z. B. durch Verkürzung oder Verlagerung eines oder mehrerer
Augenmuskeln operativ zu beheben.
Bereits im Vorfeld derartiger Operationen müssen detaillierte Planungen erfolgen bzw. geeignete
Schritte ausgewählt werden. Der Ablauf der Operation kann bislang nur direkt am
Patienten erlernt und perfektioniert werden. Bei besonders komplizierten Fehlstellungen ist
selbst der erfahrene Experte auf dokumentierte Erfahrungswerte, sowie sein unmittelbares
Geschick angewiesen. Operationen an den Augenmuskeln führen in manchen Fällen erst bei
wiederholtem Eingriff zum Erfolg (vgl. [Brüder, 2001]). Um die Arbeit der Augenärzte zu
unterstützen, wurde an den Fachhochschulstudiengängen Software Engineering und Software
Engineering für Medizin in Hagenberg gemeinsam mit der Sehschule des Konventhospitals
der Barmherzigen Brüder in Linz das Projekt SEE-KID (Software Engineering Environment
for Knowledge-based Interactive Eye Motility Diagnostics) ins Leben gerufen.
3.1.1 Projektziel
Das Ergebnis des Projekts, das Softwaresystem SEE-KID, wird es erstmals ermöglichen,
meist kongenitale Fehlstellungen bei Augen von Kleinkindern, aber auch von Erwachsenen
am Computer nachzumodellieren, graphisch dreidimensional zu visualisieren, sowie die Auswirkungen
von chriurgischen Eingriffen zu berechnen und interaktiv darzustellen. Auf diese
Weise kann der Chirurg bereits am Computer den für den jeweiligen Patienten optimalen
17

18 KAPITEL 3. PROBLEMSTELLUNG
Eingriff bestimmen (also welche Muskeln er auf welche Weise verkürzen oder verlagern muss)
und so mehrfache Operationen durch das Erfassen der Motilitätsstörungen bzw. das Verstehen
der zu Grunde liegenden Mechanismen vermeiden.
Dieses System wird speziell als Lehr- und Lernsystem zur Aus- und Weiterbildung von
Fachärzten an der Sehschule des Konventhospitals der Barmherzigen Brüder eingesetzt werden
und auch Krankenhäusern in Österreich sowie - über Partner - im deutschsprachigen und
später auch englischsprachigen Raum angeboten.
3.1.2 Projektgeschichte
Die Idee, das menschliche Auge am Computer zu simulieren bzw. Augenoperationen nachzustellen
wurde am Fachhochschulstudiengang Software Engineering in Hagenberg erstmals
im Jahr 1995 aufgegriffen. Eine Studentengruppe erarbeitete im Rahmen des Studienprojektes
” Computerunterstützte Vorbereitung von Augenoperationen” einen ersten Prototyp, der
eine einfache Visualisierung des Auges beinhaltete und grundsätzliche Funktionen für den
Chirurgen anbot.
Aufbauend auf diese Ergebnisse wurde ab dem Jahr 1999 das Forschungsprojekt SEE-KID
in Angriff genommen. Gefördert durch Mittel aus dem Forschungsförderungsfonds für die
gewerbliche Wirtschaft (FFF) wurde intensiv an der Einbettung diverser medizinischer und
mathematischer Modelle in das vorhandene System gearbeitet. Die Umsetzung der Forschungsergebnisse,
die Verbesserung der Visualisierung und der Einbau diverser Masken und
Auswertungstabellen in das Programm geschah im Zuge des Studienprojektes SEE++. Das
Ergebnis dieser Arbeiten, das Programm SEE++ (Simulation Expert for Eyes +Diagnoses
+Transposition Surgery), bietet umfassende Möglichkeiten, die über die einfache Visualisierung
des Auges hinaus gehen. Durch den versuchsweisen Einsatz bei den Projektpartnern
werden neben der Überprüfung der Praxisrelevanz auch Verbesserungsvorschläge eingebracht.
3.1.3 Bisherige Projektergebnisse
Die Erkenntnisse des Projektes SEE-KID flossen direkt in das System SEE++ ein. Um den
Überblick über die komplexen Bereiche des Projektes zu bewahren, erfolgte eine Aufteilung
des Gesamtsystems in vier Modelle:
• Grafisches Modell: In diesem Modell wird die Visualisierung des Auges geregelt. Es
ermöglich darüber hinaus eine grafische Interaktion.
• Geometrisches Modell: Hier werden besondere Eigenschaften des Auges in der Bewegung
berücksichtigt.
• Dynamisches Modell: Es wird beschrieben, wie sich ein Muskel auf Grund einer
Innervation kontrahiert.
• Biomechanisches Modell: Dieses Modell kann als Verbindung zwischen geometrischem
und dynamischem Modell gesehen werden. Weiters wird beschrieben, wie sich
die Dynamik des Muskels auf den Bulbus auswirkt.

3.1. DAS FORSCHUNGSPROJEKT SEE-KID 19
Das Programm SEE++ bietet die Möglichkeit, auf Grund vorliegender Daten einen pathologischen
Fall nachzubilden. Für einen Patient oder ein Szenario werden die vorhandenen
Daten eingegeben. Mit diesen Daten ist es möglich, mit Hilfe verschiedener Diagramme und
Ansichten (sowohl 3-dimensional als auch 2-dimensional), virtuelle Änderungen am Auge des
Patienten vorzunehmen. Die Auswirkungen dieser Änderungen können sofort überprüft und
auch als Grundlage für weitere Arbeiten in einer Datei gespeichert werden. Damit deckt
SEE++ die grundsätzlichen Funktionen des grafischen und des geometrischen Modells ab.
Die Eingabeparmeter werden aufgrund von Messungen am Patienten bestimmt. An dieser
Stelle wird nur ein Überblick über die wichtigsten Messmethoden gegeben. Eine genaue
Beschreibung ist in [Reisinger, 2001] zu finden:
• Sehschärfentest,
• Prismen- und Hornhautreflextest,
• Abdeck-Aufdeck-Test,
• Maddox-Wing-Test,
• Hess-Test,
• Less-Schirm.
In Abb. 3.1 ist ein Screenshot vom Programm SEE++ zu sehen. Die dreidimensionale Darstellung
des Auges ermöglicht es dem Benutzer, das Auge von allen Seiten zu betrachten
bzw. die Muskelpfade zu verfolgen. Darüber hinaus sind andere Darstellungsmöglichkeiten
vorgesehen, wie etwa die ” quadratische Plattkarte”, die den dreidimensionalen Bulbus auf eine
zweidimensionale Ebene projiziert. Interaktive Veränderungen an den Muskeln, wie z. B.
die Versetzung eines Insertionspunktes, können direkt am Hess-Diagramm oder am Muskelwirkungsverteilungsdiagramm
abgelesen werden. Das System untersützt auch mehrere
medizinische Modelle zur Beschreibung der Augenmuskelwirkung (vgl. dazu [Lehner, 2001]).
Um die Visualisierung zu verbessern, wurde nach einer Möglichkeit gesucht, die Augenmuskeln
so darzustellen, wie sie tatsächlich aussehen. Ein erster Ansatzpunkt dazu ist die
vorliegende Arbeit. Das Ergebnis wird in [Lacher, 2001] aufgegriffen und erweitert, sodass
eine Simulation der Muskeln und ein Einbau in das vorhandene System möglich wird.
3.1.4 Projektpartner
Der primäre Projektpartner ist die Sehschule des Konventhospitals der Barmherzigen Brüder
mit ihrem Leiter Prim. Prof. Dr. Siegfried Priglinger. Er ist nicht nur der Initiator des
Projektes, sondern auch wichtigster Ansprechpartner in medizinischen Belangen.
Um immer am neuesten Stand der Augenforschung zu sein, unterstützen zwei internationale
Partner das Projekt mit ihren neuesten Forschungsergebnissen. Es sind dies Dr. Joel M.
Miller vom Smith-Kettlewell Eye Research Institute in San Francisco/USA und Dr. Thomas
Haslwanter vom Universitätsspital der ETH Zürich in der Schweiz.

20 KAPITEL 3. PROBLEMSTELLUNG
Abbildung 3.1: Screenshot vom Programm SEE++

3.2. NOTWENDIGKEIT EINER MUSKELVISUALISIERUNG 21
Einen wichtigen Teil der Projektarbeit stellte die Beschaffung von geeigneten MR-Bildern
des menschlichen Auges dar. Auch dazu konnten Spezialisten gefunden werden, die ihre
Erfahrungen auf diesem Gebiet einbrachten. Erste Versuchsreihen wurden mit Univ.-Doz.
Dipl.-Ing. Mag. DDr. Josef Kramer vom CT & MRT Institut am Schillerplatz in Linz durchgeführt.
Am Allgemeinen Krankenhaus in St. Pölten wurden unter der Leitung von Prim.
Univ.-Doz. DDr. Armin Ettl weitere Bildserien erstellt, die ebenfalls Grundlage diverser Arbeiten
darstellten.
Allen Projektpartnern sei an dieser Stelle ein herzlicher Dank für die geleistete Arbeit und
die hervorragende Unterstützung ausgesprochen.
3.2 Notwendigkeit einer Muskelvisualisierung
Das Programm SEE++ bietet bereits eine gute Visualisierung des menschlichen Auges. Allerdings
gibt es einen Schönheitsfehler: Die Muskeln werden nur als Linien dargestellt (vgl.
Abb. 3.1). Daher wird eine Möglichkeit gesucht, die Augenmuskeln so darzustellen, wie sie
tatsächlich aussehen.
Eine Möglichkeit zur Visualisierung von Augenmuskeln wird in [Miller, 1999] dargestellt.
Dabei wird ein Drahtgittermodell angezeigt, welches die Muskeln repräsentieren soll (vgl.
Abb. 3.2 und [Miller, 2001]). Der Schwachpunkt dieser Visualisierung ist, dass die Veränderung
des Aussehens bei der Kontraktion eines Muskels willkürlich erfolgt. Damit ist gemeint,
dass ein Muskel zwar die Form ändert, diese Veränderung aber nicht anatomisch nachvollziehbar
ist.
Abbildung 3.2: Augenvisualisierung nach Miller
Zur Darstellung der Augenmuskeln wurde ein Weg gesucht, die betreffenden Muskeln aus
geeigneten MR-Bildern zu segmentieren und zu visualisieren. Die grundsätzliche Idee war

22 KAPITEL 3. PROBLEMSTELLUNG
es, zunächst einen Muskel in einer Primärposition darzustellen (d.h. der Muskel ist nicht
angespannt) und als zweiten Schritt eine Visualisierung des Muskels in einer Sekundär- oder
Tertiärposition vorzunehmen (d.h. der untersuchte Muskel ist kontrahiert). Dadurch kann
das Aussehen eines entspannten und eines kontrahierten Muskels veranschaulicht werden.
Die Suche nach Programmen, die eine Bearbeitung von MR-Daten ermöglichen, ergab durchaus
interessante Ergebnisse. So ermöglicht beispielsweise die auf MATLAB basierende MRI
Toolbox (vgl. [Tiede, 1999a]) die Generierung eines Datenvolumens aus MR-Schnittbildfolgen
durch das Hintereinanderlegen von einzelnen MR-Bildern. Eine genaue Segmentierung bestimmter
Bereiche bzw. eine dreidimensionale Darstellung ist allerdings nicht möglich. Eine
gute dreidimensionale Visualisierung von menschlichen Organen bietet das Projekt ” Virtual
Human Body” bzw. dessen Ergebnis, der ” VOXEL-MAN 3D-NAVIGATOR”, von der Abteilung
für Informatik und Datenverarbeitung in der Medizin der Universitätsklinik Hamburg-
Eppendorf (vgl. [Höhne, 2001]). Wenngleich hier viele schöne 3D-Modelle von diversen
Körperteilen zu sehen sind, ist es nicht möglich, eigene Eingabedaten zu verwenden.
Diese Erkenntnisse machten eine eigene Implementierung einer Muskelvisualisierung notwendig.
Benötigt wird ein Programm, in dem aus beliebigen MR-Bildern ein bestimmtes Objekt,
in diesem speziellen Fall ein Augenmuskel, segmentiert und anschließend visualisiert wird.
Ein weiterer wichtiger Punkt war die Abspeicherung der Ergebnisse in einem standardisierten
Format, um eine weitere Verarbeitung bzw. einen einfachen Datentransfer in andere Systeme
zu ermöglichen. Neben der Abdeckung dieser Funktionalitäten wird durch diese Arbeit ein
erster Schritt im Bereich der medizinischen Bildverarbeitung an den FH-Studiengängen Software
Engineering und Software Engineering für Medizin in Hagenberg gesetzt, der Grundlage
für spätere Arbeiten sein wird.
3.3 Segmentierung und Visualisierung von Augenmuskeln
Wie bereits mehrfach erwähnt ist es Ziel dieser Arbeit, eine Methode anzugeben, die aus zweidimensionalen
MR-Bildfolgen die Augenmuskeln segmentiert und die Oberfläche der Muskeln
als dreidimensionale Objekte am Bildschirm darstellt.
Die MR-Bilder sind zunächst so aufzubereiten, dass die Farbeinträge in der Farbpalette aufsteigend
sortiert sind. Dadurch wird eine leichtere Vergleichbarkeit der Farbwerte ermöglicht.
Durch ein Hintereinanderlegen der einzelnen Schnittbilder entsteht ein Datenvolumen, das
alle notwendigen Bildinformationen enthält.
Die Augenmuskeln setzen sich durch einen charakteristischen Grauwertbereich gegenüber
der Nachbarschaft ab. Vereinfacht gesagt: Die Bildpunkte des gesuchten Augenmuskels sind
deutlich dunkler als die Bildpunkte in der Umgebung des Augenmuskels. Dieser Umstand
wird benutzt, um den Muskel zu isolieren. Durch das Setzen eines Schwellwertes werden die
helleren Bildpunkte in der Umgebung des Muskels entfernt. Diese Schwellwertanalyse wird
hier dahingehend erweitert, dass zwei Schwellwerte (ein oberer und ein unterer Schwellwert)
definiert werden. Liegt ein Farbpunkt außerhalb dieses Schwellwertbereiches, wird er entfernt
(vgl. Kap. 4.3.2).

3.3. SEGMENTIERUNG UND VISUALISIERUNG VON AUGENMUSKELN 23
Auf einem MR-Bild nehmen diejenigen Bildpunkte, die den tatsächlich gesuchten Muskel
repräsentieren, nur einen relativ kleinen Teil der Pixelmenge ein. Damit nicht jedes Mal das
gesamte Datenvolumen analysiert werden muss, wird dem Benutzer die Möglichkeit gegeben,
die gewünschten Bereiche mit Polygonen einzugrenzen. Mithilfe des Scan-Line-Verfahrens für
Polygone (siehe Kap. 2.2.1) wird ein neues Datenvolumen, welches nur mehr die gewünschten
Flächen beinhaltet, erstellt.
Erst mit diesem Datenvolumen wird die eigentliche Generierung der Objektoberfläche in
Angriff genommen. Der Marching-Cube-Algorithmus (siehe Kap. 2.2.2) durchläuft das Datenvolumen
und berechnet die Oberfläche des Augenmuskels. Dabei wird ein Dreiecksmodell
erstellt, das die gesuchte Oberfläche repräsentiert. Die genauen Positionen der einzelnen
Eckpunkte der Dreiecke wird mittels linearer Interpolation der Farbwerte des Datenvolumens
berechnet.
Die Ergebnisse des Marching-Cube-Algorithmus sollten nicht nur am Bildschirm angezeigt,
sondern auch für eine weitere Verarbeitung abgespeichert werden. Bereits während des
Durchlaufens werden die Koordinaten der Dreicke in das standardisierte Grafikformat DXF
(Drawing Interchange File Format) gespeichert und für jedes 3D-fähige Grafikprogramm
lesbar gemacht.
Die vorliegende Arbeit beschreibt in den folgenden Kapiteln ein System, das zur Umsetzung
dieser Anforderungen implementiert wurde.

24 KAPITEL 3. PROBLEMSTELLUNG

Kapitel 4
Systemmodell und Ablauf
4.1 Beschaffung von Bildern
Als Ausgangspunkt für die Arbeiten wurden Magnetresonanzbilder gewählt, weil diese einen
relativ hohen Weichteilkontrast aufweisen. Dadurch heben sich die Muskeln deutlich vom
umliegenden Gewebe ab. Die deutlichen Kontraste sind wichtig für einen guten Erfolg der
Analysealgorithmen.
Die Beschaffung geeigneter Bildfolgen gestaltete sich anfangs schwierig. Erste Versuchsreihen
erbrachten nicht die gewünschten Ergebnisse, da erst die richtigen Einstellungen für den
MR-Tomographen gefunden werden mussten. Jener Bereich des Auges, der für die Untersuchungen
interessant ist, ist relativ klein. Dementsprechend schwierig war das Finden der
richtigen Auflösung bzw. der optimalen Schrittweite der Bildfolgen. Ein weiters Problem
stellte der Proband selbst dar. Nach einer gewissen Zeitspanne, bei den Versuchen etwa nach
45 Minuten, war es nicht mehr möglich, die Augen in der selben Position zu behalten. Trotz
der Anwendung diverser Mittel führte das Auge unwillkürliche Bewegungen durch, die nicht
zu unterbinden waren. Die Versuche mussten abgebrochen und auf eine späteren Zeitpunkt
verschoben werden.
Mit den ersten brauchbaren Bildern konnten Tests durchgeführt werden, bei denen die Bilder
mit coronaler Schichtführung die besten Ergebnisse brachten. Der Grund ist darin zu finden,
dass es bei coronalen Bildern mehr Schnitte gibt, auf denen ein Muskel zu sehen ist. Je mehr
Eingabeinformationen vorhanden sind, desto besser wird auch das Ergebnis.
Nr. Ort Proband Blickposition Vorh./Verw.
1 CT & MRT Inst. am Schillerplatz Franz Pirklbauer primär 18/14
2 AKH St. Pölten Dr. Hildebrandt primär 12/7
3 AKH St. Pölten Dr. Hildebrandt sekundär 12/7
Tabelle 4.1: Übersicht über die verwendeten MR-Bildfolgen
25

26 KAPITEL 4. SYSTEMMODELL UND ABLAUF
In Tab. 4.1 sind diejenigen Bildserien aufgelistet, mit denen hier gearbeitet wurde. Alle Bilder
dieser Serien haben eine Auflösung von 512x512 Pixel und besitzen 256 Graustufen. Nicht
auf allen Bildern der Serien ist auch tatsächlich ein Augenmuskel zu erkennen. Darum wurde
bei den Zahlenangaben zunächst die Anzahl aller vorhandenen Bilder in der Serie angegeben
und daneben die Anzahl der tatsächlich verwendeten.
Die einzelnen Bilder müssen im Bitmap-Format (*.bmp) vorliegen und die Namen der Dateien
müssen aufsteigend sortiert sein (z. B. liegt die Datei xxx09.bmp in der Reihenfolge vor
xxx10.bmp).
4.2 Bildaufbereitung
4.2.1 Sortieren der Farbpalette
Die Farbpalette einer Bitmapdatei dient zur Verwaltung der Farbwerte, wobei die einzelnen
Pixel im Bild nur mehr durch Indexwerte auf die entsprechenden Paletteneinträge verweisen.
Die Paletteneinträge liegen im sogenannten RGB-Farbschema (Rot-Grün-Blau Farbwerte)
vor. Da es sich bei MR-Bildern um Grauwertbilder handelt, sind die jeweiligen RGB-Einträge
immer gleich. Bei einer Farbe, dessen Grauwert 50 ist, sind demnach die Farbwerte Rot =
Grün = Blau = 50.
Von den 256 möglichen Farbwerten werden in MR-Bildern nicht alle benutzt. Als erster
Schritt ist also eine Untersuchung des Bildes auf die verwendeten Farben notwendig. Die nicht
benutzten Farben werden für den Sortiervorgang markiert und an das Ende der Farbpalette
verschoben. Diese nicht benutzten Werte werden nach dem Sortiervorgang der Einfachheit
halber auf den Farbwert von Schwarz (Rot = Grün = Blau = 0) gesetzt. Die Sortierung
selbst erfolgt nur über die verwendeten Farbwerte.
Die veränderte Farbpalette wird wieder in die Bitmapdatei zurückgeschrieben. Das Aussehen
des Bildes wird durch diese Aktion nicht beeinflusst. Die in späterer Folge durchzuführenden
Vergleichsoperationen werden aber wesentlich vereinfacht. Wie bereits erwähnt besteht die
Farbinformation in den Bildpunkten nur aus einem Indexverweis auf einen Farbpaletteneintrag.
Durch die Sortierung der Farbpalette entspricht ein kleinerer Indexwert auch tatsächlich
einem kleineren Farbwert.
Ein einfaches Beispiel zur Sortierung der Farbpalette ist in Abb. 4.1 dargestellt. Die acht
Farbwerte sind beliebig in der Palette verteilt. Der Farbwert mit dem Index 2 wird im Bild
nicht verwendet, weil es kein Grauwert ist (die RGB-Werte sind verschieden). Nach der
Sortierung stehen die Farbwerte in aufsteigender Reihenfolge, wobei die nicht verwendete
Farbe auf Schwarz gesetzt wurde und am Ende der Palette steht. Der Index 1 verweist nun
auf eine Farbe, die tatsächlich heller ist als die Farbe, auf die der Index 0 verweist.

4.2. BILDAUFBEREITUNG 27
0
1
2
3
4
5
6
7
Farbpalette vor der
Sortierung
2/2/2
1/1/1
132/231/132
0/0/0
3/3/3
10/10/10
8/8/8
255/255/255
4 5 3 7 7
0 1
3
6
6
5
5
3
4
3
Indexverweise
der Pixel
Farbpalette nach der
Sortierung
0
1
2
3
4
5
6
7
0/0/0
1/1/1
2/2/2
3/3/3
8/8/8
10/10/10
255/255/255
0/0/0
3 5 0 6 6
2 1
0
4
4
5
5
0
3
0
Indexverweise
der Pixel
Abbildung 4.1: Vereinfachtes Beispiel zum Sortieren der Farbpalette
4.2.2 Definition von Polygonbereichen
In den vorhandenen MR-Bildern sind die Flächen, die den Augenmuskel darstellen, verglichen
mit der gesamten Bildinformation relativ klein. Ein Algorithmus, der das gesamte
Datenvolumen analysiert, wäre extrem ineffizient, weil
• der Zeitaufwand zum Durchlaufen aller Bildpunkte zu groß ist bzw. überdimensionale
Anforderungen an die Hardware gestellt werden,
• neben den Augenmuskeln auch noch andere Körperteile dargestellt werden, die nicht
relevant sind,
• große Datenmengen erzeugt werden, die wiederum eine effiziente Weiterverarbeitung
unmöglich machen.
Um diesem Problemen auszuweichen, wird eine Abgrenzung der zu untersuchenden Flächen
vorgenommen. Diese Abgrenzung erfolgt interaktiv durch den Anwender, in dem auf jedem
verwendeten MR-Bild ein Polygonbereich definiert wird. Bei der Analyse werden nur mehr
diejenigen Bildpunkte betrachtet, die innerhalb des Polygons liegen. Dem Anwender wird
damit ein Werkzeug gegeben, das ihm ermöglicht
• selbst Schnitte durch Organe vorzunehmen,
• bestimmte Organe vom umliegenden Gewebe zu trennen.
Letzteres kann z. B. dann vorkommen, wenn ein Augenmuskel die Orbitawand fast berührt.
Die Farbwerte von Muskel und Orbitawand sind im MR-Bild annähernd gleich. Das geschulte
Auge eines Anwenders kann jedoch die Grenzen des Muskels erkennen und mit dem Polygon
nachzeichnen. Optimale Ergebnisse werden dann erzielt, wenn neben den Polygonen auch
die Schwellwerte laufend verändert werden. Oftmals sind mehrere Versuche notwendig, bis
ein gesuchter Muskel tatsächlich isoliert werden kann.

28 KAPITEL 4. SYSTEMMODELL UND ABLAUF
Polygone sind durch die Koordinaten ihrer Eckpunkte genau definiert. Das verwendete Koordinatensystem
ist mit dem Bildraster der Pixel ident. Abb. 4.2a zeigt ein Polygon, das in
ein Pixelraster eingebettet ist. Die Koordinaten der einzelnen Eckpunkte definieren genau
die Lage und das Aussehen des Polygons.
Abbildung 4.2: Polygonbeispiele
Für die Verarbeitung ist es wichtig, dass Polygone definiert werden, die aus genau einer
Fläche bestehen. Andernfalls würden zwei Bereiche auf dem Bild definiert, und der Analysealgorithmus
würde einen Fehler liefern. Ein Polygon mit einer Fläche ist genau dann
gegeben, wenn es bei den Polygonkanten zu keinen Überschneidungen kommt. Beim Polygon
in Abb. 4.2b ist eine Überschneidung zu erkennen. Dadurch wird die Fläche in zwei Teile
zerteilt, die sich zwar berühren, aber dennoch kein sinnvolles Ergebnis liefern.
Eine Anforderung an das System ist die Abspeicherung der Polygone, damit einmal getätigte
Eingaben auch für spätere Analysevorgänge zur Verfügung stehen. Die Koordinaten der Polygoneckpunkte
definieren das Vieleck vollständig, daher ist es ausreichend, nur diese Punkte
zu speichern. Aus der Reihenfolge der einzelnen Koordinatenwerte lassen sich die Seiten des
Polygons rekonstruieren. Dabei ist es unerheblich, welche Koordinaten als erstes abgespeichert
werden, da der letzte Punkt der Liste wieder mit dem ersten verbunden wird, um so
das Polygon zu schließen.
4.2.3 Definition von Schwellwerten
Neben der Definition von Polygonen ist eine Möglichkeit vorgesehen, die bestimmte Bildpunkte
aus einem MR-Bild herausfiltern kann. Dazu wird ein Schwellwertbereich definiert,
der nur mehr die gewünschten Farbwerte zulässt.

4.3. GENERIEREN EINES POLYEDERMODELLS 29
Zur Durchführung eines Schwellwertverfahrens muss vom Anwender ein Schwellwert t (engl.:
threshold) definiert werden. Diese Eingabe erfolgt direkt interaktiv am Bild, d.h. jede
Veränderung des Schwellwertes ist direkt am Bild zu beobachten. Eine zusätzliche Verbesserung
bietet die Möglichkeit, einen Schwellwertbereich festzulegen. Damit ist gemeint,
dass zwei Werte (tunten und toben) definiert werden, die eine Abgrenzung nach beiden Seiten
ermöglichen.
Das Beispiel in Abb. 4.3 soll dies veranschaulichen. Das Grauwertspektrum besteht aus
256 möglichen Grauwerten, die zwischen den Farben Schwarz und Weiß liegen (vgl. dazu
den unteren Balken in Abb. 4.3). Der untere Schwellwert 8 und der obere Schwellwert 134
stellen die Grenzen des Schwellwertbereiches dar. Diejenigen Grauwerte, die außerhalb dieses
Bereiches liegen, werden einfach durch die Farbe Weiß ersetzt und damit nicht mehr angezeigt.
In einer Schwellwertanalyse (Kap. 4.3.2) werden diese Eingabedaten weiter verarbeitet.
Abbildung 4.3: Definition eines Schwellwertbereiches
Genau wie die Polygone werden auch die Schwellwerte für eine spätere Verwendung abgespeichert.
Dazu reicht es, die beiden Werte tunten und toben in einer Datei zu archivieren.
Abschließend ist noch zu erwähnen, dass sämtliche Bildmanipulationen in allen verwendeten
MR-Bildern einer Serie zu machen sind. Die Schwellwerte und Polygone müssen nicht gleich
sein, jedoch empfielt es sich, keine zu großen Unterschiede in den Werten zu haben, da
damit die Ergebnisse der Oberflächengenerierung verbessert werden. Im Protoyp, den diese
Arbeit beschreibt, sind keine Automatisierungen vorgesehen. Der Benutzer soll selbst durch
mehrmaliges Probieren die optimalen Einstellungen herausfinden und damit ein Gefühl für
die richtigen Werte bekommen.
4.3 Generieren eines Polyedermodells
Nach dem ersten Schritt, der Vorbereitung der MR-Bilder, ist der zweite Schritt das Generieren
eines Polyedemodells. Dabei wird mit Hilfe des Scan-Line Verfahrens (vgl. Kap. 2.2.1)
für Polygone ein Datenvolumen erstellt, das dann mit dem Marching-Cube-Algorithmus (vgl.
Kap. 2.2.2) analysiert wird. Wenngleich diese beiden Verfahren aus der Literatur bekannt
sind, wird hier auf einige Besonderheiten für die spezielle Aufgabe der Generierung von Muskeloberflächen
eingegangen.

30 KAPITEL 4. SYSTEMMODELL UND ABLAUF
4.3.1 Erstellen des Datenvolumens
Für diesen Arbeitsschritt wird als gegeben betrachtet, dass eine Serie von MR-Bildern vorliegt,
wobei jedes Bild über einen definierten Schwellwertbereich sowie über ein Polygon
verfügt. Anhand der Polygondaten wird ein Datenvolumen erstellt, das die Basis für die
weitere Verarbeitung darstellt.
Das geforderte Datenvolumen hat folgenden Anforderungen zu entsprechen:
• Das Datenvolumen ist vergleichbar mit einem Quader aus Voxeln, der alle Polygonpunkte
in den Bildern einschließt.
• Für jede Schnittebene sind nur mehr diejenigen Bildpunkte aktiv, die innerhalb eines
Polygons liegen.
• Diejenigen Bildpunkte, die außerhalb der Polygone liegen, erhalten einen Farbwert, der
sicher außerhalb der Schwellwertbereiche liegt. Damit sind zwar Bildpunkte vorhanden,
sie sind aber für den Analysevorgang unerheblich.
• Die Farbwerte der einzelnen Voxel innerhalb der Polygone werden unverändert in das
Datenvolumen übernommen.
x x x x x x x x x x x x x x x x
x x x x x x x x x x x x x x x x
x x x x x x x x x x x x x x x x
x x x x x x x x x x x x x x x x
x x x x x x x x x x x x x x x x
x x x x x x x x x x x x x x x x
x x x x x x x x x x x x x x x x
x x x x x x x x x x x x x x x x
x x x x x x x x x x x x x x x x
x x x x x x x x x x x x x x x x
x x x x x x x x x x x x x x x x
x x x x x x x x x x x x x x x x
x x x x x x x x x x x x x x x x
x x x x x x x x x x x x x x x x
x x x x x x x x x x x x x x x x
x x x x x x x x x x x x x x x x
Abbildung 4.4: Segmentierung der Bilddaten
x
x x x x
x x x x x
x x x x x
x x x x x x
x x x x x x x x
x x x x x x
x x x x x x
x x x x x x
x x x x x x
Um den Vorgang der Erstellung des Datenvolumens verständlich zu machen, wird zunächst
nur ein Schichtbild betrachtet. Abb. 4.4 zeigt ein Feld mit 16x16 Bildpunkten. Darauf wurde
ein 7-eckiges Polygon gezeichnet, welches die gewünschten Bildpunkte einschließt. Das
Rechteck, das rund um das Polygon entsteht, orientiert sich an den maximalen bzw. minimalen
x- und y-Werten des Polygons. Durch dieses Rechteck ist die Größe des zu erstellenden
Rasters bereits vorgegeben und kann gleich initialisiert werden. Durch diese Initialisierung
werden alle Bildpunkte mit einem Farbwert belegt, der sicher außerhalb des Schwellwertbereiches
liegt (z. B. -1). Mithilfe des Scan-Line Verfahrens (Kap. 2.2.1) werden jetzt diejenigen
x
x
x
x

4.3. GENERIEREN EINES POLYEDERMODELLS 31
Bildpunkte in das neue Datenvolumen geschrieben, die innerhalb des Polygons liegen. Das
Ergebnis in Abb. 4.4 zeigt einen Raster aus Bildpunkten, der so groß ist wie das Rechteck, das
das Polygon einschließt und in dem nur mehr die Bildpunkte innerhalb der Polygongrenzen
markiert sind.
Beim Generieren eines Datenvolumens aus mehreren Schichtbildern verändert sich lediglich
das Finden eines geeigneten Rechtecks. Dazu werden am Beginn der Verarbeitung alle Polygone
analysiert und die minimalen bzw. maximalen x- und y-Werte über alle Polygone zur
Definition der Rechtecksdimension herangezogen. Danach werden alle Schichtbilder durchlaufen
und mit dem Scan-Line Verfahren analysiert. Das Ergebnis ist ein Datenvolumen, das
so breit bzw. lang ist wie das größte Rechteck aus den Polygoneckpunkten. Die Höhe des
Datenvolumens entspricht der Anzahl der verwendeten Schichten.
Durch diese Vorgangsweise werden natürlich viele leere Bildpunkte produziert, da die Polygone
auf den einzelnen Schichtbildern versetzt sein können. Dennoch wird dadurch eine
leichtere Weiterverarbeitung gewährleistet:
• Es entsteht ein Datenvolumen, das in jeder Schicht die gleichen Dimensionen aufweist.
Das Volumen kann also mit einfachen Schleifen durchlaufen werden.
• Das gesamte Datenvolumen wird deutlich verringert. Die Anzahl der Bildpunkte ist
nur mehr ein Bruchteil im Vergleich zu der Menge in den Ausgangsbildern.
• Die Bildpunkte außerhalb der Polygone fallen automatisch weg. Diese müssen nicht
mehr näher berücksichtigt werden.
Das so erstellte Datenvolumen wird nun Punkt für Punkt durchlaufen. In jedem Schritt
wird dabei ein Würfel definiert, dessen Eckpunkte einzelnen Voxeln entsprechen (vgl. dazu
Abb. 2.7 auf Seite 13). Es werden jeweils vier benachbarte Punkte aus zwei übereinander
liegenden Schichten hergenommen. Den so definierten Würfeln werden in einer Schwellwertanalyse
bestimmte Konfigurationen zugewiesen, die als Eingabewerte für den Marching-
Cube-Algorithmus dienen.
4.3.2 Schwellwertanalyse
Bei der schwellwertbasierten Segmentierung medizinischer Bildobjekte werden die zu einem
Bildobjekt gehörenden Pixel anhand zweier Schwellwerte (engl.: thresholds) tunten und toben
in dem Bild bzw. der 3D-Bildfolge separiert und in einem Binärbild bzw. einer Binärbildfolge
markiert. [Handels, 2000]
Vereinfacht gesagt bedeutet dies, dass jedem Bildpunkt eine Wahr-Falsch-Entität zugewiesen
wird. Die mathematische Berechnung erfolgt nach der Formel 2.2 (Seite 13). Ein Bildpunkt,
dessen Farbwert innerhalb des Schwellwertbereiches liegt, erhält somit den Wert Wahr. Damit
wird festgehalten, dass sich dieser Bildpunkt innerhalb des gesuchten Objektes befindet.
Da diejenigen Bildpunkte, bei denen die Schwellwertanalyse Falsch ergibt, außerhalb des Objektes
liegen, ist die Oberfläche des darzustellenden Objektes beim Übergang zwischen den
Bildpunkten mit wahren und falschen Entitäten zu suchen.

32 KAPITEL 4. SYSTEMMODELL UND ABLAUF
Diese Erkenntnis verwendet letztendlich auch der Marching-Cube-Algorithmus. So ist es
jetzt notwendig, den Eckpunkten der vorher definierten Würfeln genau diese Entitäten zuzuordnen.
Jeder Eckpunkt entspricht einem Voxel und kann somit einer Schwellwertanalyse
unterzogen werden. Das Ergebnis ist eine sogenannte Würfelkonfiguration, bei der allen
acht Ecken entweder ein Wert Wahr oder Falsch zugeordnet wird. Dabei können 2 8 = 256
mögliche Würfelkonfigurationen entstehen, die relativ einfach auf einige wenige Grundkonfigurationen
zurückgeführt werden können.
4.3.3 Zurückführen auf Grundkonfigurationen
Der Marching-Cube-Algorithmus gibt an, wie eine Dreiecksanordnung in einem Würfel auszusehen
hat, damit die gesuchte Objektoberfläche dargestellt wird. Dabei ist es nicht zielführend,
alle 256 Möglichkeiten zu betrachten. [Lorensen und Cline, 1987] geben einen Weg
an, diese 256 Würfelkonfigurationen auf 15 Grundkonfigurationen zurückzuführen. Dies geschieht
im Wesentlichen durch
• Invertieren der Würfelkonfigurationen, wenn mehr als die Hälfte der Punkte den Wert
Wahr besitzen,
• Spiegelungen um die drei Hauptachsen,
• Rotationen um die drei Hauptachsen.
Der einfachste Schritt ist die Umkehrung der Würfelkonfigurationen. Dieser ist nur dann
notwendig, wenn mehr als die Hälfte der Eckpunkte einen Wert Wahr besitzen. Ist dies der
Fall, werden einfach alle Wahr- und Falschwerte vertauscht. In Abb. 4.5 besitzen die schwarz
markierten Ecken einen Wert Wahr. Bei der Invertierung werden diese sechs Ecken in einen
Wert Falsch umgewandelt, sodass nur mehr zwei Eckpunkte den Wert Wahr enthalten. Durch
diese Vorgehensweise lassen sich die 256 Würfelkonfigurationen bereits auf 128 reduzieren.
Abbildung 4.5: Invertierung der Würfelkonfiguration
Etwas schwieriger sind die Spiegelungen bzw. Rotationen um die drei Hauptachsen. Versuche
haben gezeigt, dass alle Fälle auf eine der 15 Grundkonfigurationen zurückgeführt
werden können, wenn eine Kombination von Rotationen um alle drei Koordinatenachsen

4.3. GENERIEREN EINES POLYEDERMODELLS 33
durchgeführt wird. Unter den Grund- bzw. Standardkonfigurationen sind die in Abb. 2.8 abgebildeten
Würfeldefinitionen gemeint. Die Winkel, um die die Würfel dabei gedreht werden
können sind
• -90 ◦ ,
• 0 ◦ ,
• +90 ◦ und
• +180 ◦ .
Alle Kombinationen dieser vier Winkel um die drei Koordinatenachsen ergeben maximal 64
Möglichkeiten, wie ein Würfel rotiert werden kann. Dadurch werden mit Sicherheit alle denkbaren
Konfigurationen auf eine der 15 Grundkonfigurationen zurückgeführt. Eine zusätzliche
Betrachtung der Spiegelungen ist nicht mehr notwendig.
Der große Vorteil dieser Vorgehensweise zeigt sich erst später, wenn die Dreiecke, die in die
Würfel gezeichnet werden, wieder zurückrotiert werden. Dieser Schritt ist notwendig, um die
Ausgangsposition der Würfel wieder herzustellen. Die Dreiecke werden dadurch in diejenige
Position gebracht, die sie laut der ursprünglichen Würfelkonfiguration einnehmen müssen.
Diese Rückrotation kann wesentlich vereinfacht werden, wenn nur mit Rotationsachsen gerechnet
wird (vgl. Kap. 5.3.2).
Im Normalfall werden nicht alle 64 Möglichkeiten der Würfelrotationen benötigt. Der Algorithmus
bricht ab, sobald der rotierte Würfel mit einer Standardkonfiguration übereinstimmt.
Das Beispiel in Abb. 4.6 soll den Vorgang der Findung einer Grundkonfiguration nochmals
verdeutlichen. Ausgegangen wird von einer Würfelkonfiguration, bei der fünf Eckpunkte
den Wert Wahr haben. Im ersten Schritt wird eine Invertierung der Eckenklassifizierung
vorgenommen. Dadurch entsteht ein Würfel mit drei Wahrwerten. Dieser Würfel wird
jetzt um 180 ◦ um die z-Achse und um 90 ◦ um die x-Achse rotiert. Die jetzt entstandene
Würfelkonfiguration ist mit der Standardkonfiguration 5 (Abb. 2.8) ident.
Die Häufigkeit des Auftretens der Standardkonfigurationen in der Menge aller 256 verschiednen
Möglichkeiten ist höchst unterschiedlich (vgl. Tab. 4.2). Die Grundkonfiguration mit
dem Index 0 kommt beispielsweise nur zwei mal vor, nämlich genau dann, wenn entweder
alle Eckpunkte einen Wert Wahr oder Falsch besitzen. Im Datenvolumen selbst wird dieser
Fall allerdings am häufigsten vorkommen, weil die meisten Voxel außerhalb des gesuchten
Objektes liegen, und somit den Wert Falsch aufweisen.

34 KAPITEL 4. SYSTEMMODELL UND ABLAUF
z
y
180˚ um die
z-Achse
x
Invertierung
der Ecken
90˚ um die
x-Achse
Das Ergebnis entspricht der
Standardkonfiguration 5
Abbildung 4.6: Zurückführung auf eine Standardkonfiguration
Index der Standardkonfiguration Häufigkeit
0 2
1 16
2 24
3 24
4 8
5 48
6 48
7 16
8 6
9 8
10 6
11 12
12 24
13 2
14 12
Summe: 256
Tabelle 4.2: Vorkommen der Grundkonfigurationen

4.3. GENERIEREN EINES POLYEDERMODELLS 35
4.3.4 Definition der Polyeder
Nach all diesen Vorarbeiten können nun die Dreiecke der gesuchten Objektoberfläche generiert
werden, und zwar genau so, wie es der Marching-Cube-Algorithmus vorgibt. Dazu
ist zunächst eine Indizierung der Würfeleckpunkte und der Würfelkanten notwendig. Die
Eckpunkte des Würfels werden mit den Ziffern von 0 bis 7 indiziert. Die zwölf Kanten zwischen
den Eckpunkten werden mit Buchstaben von a bis l benannt (vgl. Abb. 4.7). Diese
Indizierung hilft entscheidend beim Verständnis der folgenden Erklärungen.
7 g 6
l
h
d
4
i
5
0 1
3 2
c
a
k
e
f
b
j
a: 0 1
b: 1 2
c: 2 3
d: 3 0
e: 4 5
f: 5 6
g: 6 7
h: 4 7
i: 0 4
j: 1 5
k: 2 6
l: 3 7
Abbildung 4.7: Beschriftung der Würfeleckpunkte und Kanten
Die Aufgabe des ersten Teilschrittes ist es, in die definierten Würfel Dreiecke zu legen, sodass
die Objektoberfläche möglichst gut repräsentiert wird. Dabei ist zu beachten, dass
• die Eckpunkte der Dreiecke auf den Kanten des Würfels liegen,
• die Zuordnung der Dreieckseckpunkte auf die Würfelkanten fix durch den Marching-
Cube-Algorithmus vorgegeben wird,
• die genaue Lage der Dreieckspunkte auf den Kanten durch lineare Interpolation der
Farbwerte in den Bildpunkten berechnet wird,
• die endgültigen Koordinaten der Dreieckspunkte erst nach dem Zurückrotieren und
nach dem Setzen des richtigen Offsets (damit ist die Position des Würfels im Datenvolumen
gemeint) feststehen.
Die Kanten der Würfel im Datenvolumen berühren einander naturgemäß. Damit durch die
Dreiecke eine Oberfläche ohne Löcher entsteht, müssen auch sie sich berühren. Dies kann nur
geschehen, wenn die Koordinaten der Eckpunkte der Dreiecke ebenso auf den Kanten liegen.
Die zentrale Frage ist nun, wie die einzelnen Dreiecke je nach Standardkonfiguration in den
Würfel gelegt werden. Die Antwort auf diese Frage gibt der Marching-Cube-Algorithmus. Die

36 KAPITEL 4. SYSTEMMODELL UND ABLAUF
Dreieckseckpunkte werden genau auf jene Kanten gelegt, deren Eckpunkte eine verschiedene
Wahr-Falsch-Konstellation aufweisen.
Dazu ein kleines Beispiel: Es wird angenommen, dass die Punkte 0 und 1 einen Wert Wahr
haben und der Punkt 2 einen Wert Falsch. Auf der Kante a wird mit Sicherheit kein Eckpunkt
eines Dreieckes zu finden sein, hingegen wird das Dreieck irgendwo auf der Kante b eine Ecke
haben.
Die graphische Darstellung aller möglichen Dreieckszuordnungen in den Würfeln ist in
Abb. 2.8 dokumentiert. In Tab. 4.3 wird genau dieser Sachverhalt in Tabellenform dargestellt,
wobei die Indizierung aus Abb. 4.7 verwendet wird. Für alle Grundkonfigurationen
wird angegeben, welche Eckpunkte den Wert Wahr haben müssen und auf welchen Kanten
Dreieckspunkte liegen. Dabei definieren immer drei nebeneinander liegende Kanten ein
Dreieck.
Jede Kante des Würfels ist definiert durch zwei Eckpunkte A und B, für die neben den Wahr-
Falsch-Entitäten auch die Farbwerte CA und CB bekannt sind. Weiters ist für jede Kante
der zugehörige Schwellwert T bekannt. Dieser Schwellwert liegt im Normalfall zwischen den
beiden Farbwerten CA und CB. Wenn die beiden Eckpunkte der Kante von ein und dem
selben Bild kommen, wird entweder der obere oder untere Schwellwert des zugehörigen Bildes
genommen, der zwischen den beiden Farbwerten liegt. Aufwändiger wird die Berechnung des
Kantenschwellwertes, wenn die Eckpunkte der Kanten aus zwei verschiedenen Schichtbildern
kommen. Es werden dabei die Durchschnitte des oberen und unteren Schwellwertes mit den
Farbwerten verglichen. Die Lage der Dreieckspunkte ist einerseits durch die Kante vorgegeben.
Der Abstand zu den Würfeleckpunkten d muss aber extra berechnet werden. Die
Berechnung des relativen Abstandes d zum Punkt A erfolgt nach der Formel:
⎧
1 −
⎪⎨
d =
⎪⎩
T −CB
CA−CB , falls CA > CB
T −CA
CB−CA , falls CA < CB
0.5, falls CA = CB
(4.1)
Die Farbwerte CA und CB sind grundsätzlich verschieden, weil damit normalerweise die Unterschiede
in den Wahr-Falsch-Entitäten verbunden sind. Allerdings kann es vorkommen,
dass Voxel aus zwei verschiedenen Bildern zwar die gleichen Farbwerten besitzen, aber unterschiedliche
Wahr-Falsch-Zustände aufweisen, da die Schwellwertbereiche unterschiedlich
definiert wurden. Dieser Sonderfall ist speziell zu berücksichtigen. Der Eckpunkt des Dreiecks
wird dann einfach in die Mitte zwischen Punkt A und B gelegt. d erhält also den Wert
0.5.
Abb. 4.8 zeigt die Fortsetzung des Beispiels aus Abb. 4.6. Die Dreiecke wurden wie im
Marching-Cube-Algorithmus vorgeschrieben in den Würfel gelegt. Danach wurde die Ausgangsposition
wieder hergestellt und die Dreiecke zurückrotiert.
Die Dreiecke besitzen jetzt die richtige Orientierung im Würfel. Damit sie aber an der
richtigen Stelle im dreidimensionalen Raum liegen, muss noch ein Offset dazuaddiert werden,

4.3. GENERIEREN EINES POLYEDERMODELLS 37
Index Eckpunkte mit Wahrwerten Betroffene Würfelkanten Anzahl der Dreiecke
0 - - 0
1 3 d, c, l 1
2 2, 3 d, k, l 2
d, b, k
3 3, 6 c, d, l 2
f, k, g
4 3, 5 c, d, l 2
f, e, j
5 0, 1, 2 c, d, k 3
k, d, i
k, i, j
6 2, 3, 5 d, k, l 3
d, b, k
f, e, j
7 2, 5, 7 f, e, j 3
b, c, k
h, g, l
8 0, 1, 2, 3 k, l, i 2
i, j, k
9 0, 1, 3, 4 l, h, e 4
l, e, c
c, e, j
j, b, c
10 1, 3, 5, 7 d, h, g 4
c, d, g
a, b, f
a, f, e
11 0, 1, 3, 5 c, i, l 4
c, i, f
c, f, b
i, f, e
12 0, 1, 2, 7 c, d, k 4
k, d, i
k, i, j
l, h, g
13 1, 3, 4, 6 c, d, l 4
a, b, j
f, g, k
e, i, h
14 0, 1, 2, 4 d, c, h 4
c, h, j
j, c, k
j, h, e
Tabelle 4.3: Zuweisung der Dreieckseckpunkte auf die Würfelkanten

38 KAPITEL 4. SYSTEMMODELL UND ABLAUF
zurück
rotieren
Abbildung 4.8: Zurückrotieren der Dreiecke
der den Koordinaten des Würfels im Datenvolumen entspricht. Das heißt, die Dreiecke
werden an diejenige Stelle geschoben, an der auch der Würfel liegt, von dem die Berechnung
ausgegangen ist.
Auf diese Art und Weise werden alle Bildpunkte des Datenvolumens durchlaufen und liefern
die Koordinaten einer Polyederoberfläche. Diese kann nun entweder direkt mithilfe von
z. B. OpenGL angezeigt werden, oder, wie im nächsten Kapitel beschrieben, für eine spätere
Verwendung abgespeichert werden.
4.4 Plattformunabhängige Abspeicherung
Zur Abspeicherung der Dreiecksoberfläche wird ein Grafikformat benötigt, das
• eine standardisierte Abspeicherung von dreidimensionalen Bildinformationen ermöglicht,
• selbst programmierbar und veränderbar ist,
• eine Portierung auf beliebige Systeme erlaubt.
Ein Grafikformat, das diese Anforderungen erfüllt, ist das Drawing Interchange Fileformat
(DXF) von der Firma Autodesk. Es wurde in erster Linie dafür entwickelt, verschiedenste
Grafiken in CAD-Systeme einlesen zu können. Die Art und Weise, wie die Daten abgespeichert
werden müssen, ist fix vorgegeben. Es handelt sich dabei um ein ASCII-Format, das
nicht nur mit jedem beliebigen Editor erstellt bzw. verändert werden kann, es ist auch einfach
selbst zu programmieren. DXF ist weit verbreitet. Beinahe jedes 3D-fähige Grafikprogramm
kann mit diesem Format umgehen.
Die Struktur einer DXF-Datei erinnert entfernt an strukturierte Programmiersprachen wie
etwa COBOL. Der gesamte Inhalt einer Grafik ist in vier sogenannte Sections unterteilt (vgl.
[Pohl und Eriksdottar, 1991]):

4.4. PLATTFORMUNABHÄNGIGE ABSPEICHERUNG 39
1. Die Header Section; Sie enthält die generellen Einstellungen, die für jede Zeichnung gemacht
werden müssen, wie aktuelle Farben, aktueller Bildschirmausschnitt, usw. Dafür
stehen eine Reihe von Variablen zur Verfügung.
2. Die Tables Section; Hier werden die Definitionen der zeichenabhängig definierten Einträge
in Tabellen abgelegt.
3. Die Blocks Section; Sie beschreibt die Blockdefinitionseinträge, die jeden Block der
Grafik umfassen.
4. Die Entities Section; Sie enthält schließlich die eigentlichen Zeichenelemente.
Für die Abspeicherung der Dreiecke wird eine DXF-Datei mit standardisierter Header- und
Tables-Section erstellt. Die Blocks-Section ist nicht unbedingt erforderlich und wird daher
in unserem Fall weggelassen. In der Entities-Section werden die Koordinaten der Dreiecke
der Reihe nach eingetragen. Dies geschieht bereits während des Durchlaufens des Marching-
Cube-Algorithmus. Dadurch können Rechnerressourcen eingespart werden. Beim Erstellen
der DXF-Datei entstehen große Datenmengen, da jede Dreieckskoordinate abgespeichert
wird. Allerdings werden die Werte im ASCII-Format abgespeichert, dadurch relativiert sich
der Platzbedarf. Das Ende einer DXF-Datei stellt ein ” END OF FILE” Eintrag dar.
Durch die Abspeicherung der Dreiecksoberfläche im DXF-Format können die Ergebnisse der
Oberflächenanalyse mit jedem beliebigen, DXF-fähigen 3D-Grafikprogramm betrachtet werden.
Weiters besteht die Möglichkeit, die Daten einfach in ein anderes System zu importieren,
was eine leichte Weiterverwendung der Daten gewährleistet.

40 KAPITEL 4. SYSTEMMODELL UND ABLAUF

Kapitel 5
Implementierung
Die Umsetzung des in Kap. 4 beschriebenen Modells erfolgte in der Programmiersprache
C++. Als Werkzeug wurde der Borland C++ Builder gewählt, da dieser eine relativ einfache
Erzeugung einer Benutzeroberfläche erlaubt.
Das gesamte Programm wurde in zwei Teilprogramme aufgeteilt. Im ersten Programmteil
wird die Funktionalität der Bildbearbeitung implementiert. Dieser Teil beschränkt sich auf
die Manipulation der Bilder und speichert die Zwischenergebnisse ab. Dadurch werden einmal
getroffene Einstellungen für später abgelegt. Im zweiten Teil wird die Funktionalität der
Generierung einer Polygonoberfläche zur Verfügung gestellt. Die Ergebnisse des ersten Teils
werden verarbeitet und eine Objektoberfläche wird abgespeichert. Durch die beiden Programmteile
können diese Arbeitsschritte unabhängig voneinander durchgeführt, wiederholt
oder abgeändert werden.
Bevor nun die technische Umsetzung des Systemmodells beschrieben wird, erfolgt eine Beschreibung
des statischen Klassenmodells, das die Grundlage der Implementierung darstellt.
5.1 Beschreibung des statischen Klassenmodells
Es wurde versucht, alle geforderten Funktionalitäten möglichst objektorientiert in Klassen
aufzuteilen und den notwendigen Daten die richtigen Methoden zuzuordnen. Diese Aufteilung
und die Beziehungen zwischen den einzelnen Klassen sind in Abb. 5.1 dargestellt.
Ausgangspunkt für alle hier beschriebenen Programme ist eine Klasse MyTForm, die von der
Borland C++ Klasse TForm abgeleitet wird. Dadurch sind die grundlegenden Programmfunktionen
eingebunden und es kann leicht ein Programmfenster erstellt werden, in dem die
notwendigen Benutzereingaben erfolgen.
Der linke Ast des statischen Klassenmodells ist in erster Linie für die Bildbearbeitung interessant.
Die Klasse VolumeData dient dabei zur Verwaltung der Daten. Sie enthält im
Wesentlichen eine Liste aller verwendeten Bilder. Die Bilder selbst werden in der Klasse
Picture verwaltet. Die Bestandteile der Bilder sind die Farbpalette (Palette), das Polygon
41

42 KAPITEL 5. IMPLEMENTIERUNG
«struct»
tab
Palette
Picture
MyPolygon
PolygonFill
VolumeData
edge
«struct»
voxel
Threshold
Cube
MyTForm
MarchingCube
3dmath
Abbildung 5.1: Statisches Klassenmodell
TForm
Triangle
helpDxf

5.2. BILDBEARBEITUNG 43
(MyPolygon), das ebenso wie der Schwellwertbereich (Threshold) vom Benutzer interaktiv
definiert wird. Die Struktur tab, die zur Palette gehört, dient zur Verwaltung der Platteneinträge
und hat zusätzlich einen Boolean-Wert, der angibt, ob eine Farbe im Bild vorkommt
oder nicht.
In der Klasse VolumeData wird auch die Funktionalität zum Erstellen des Datenvolumens
zur Verfügung gestellt. Zentraler Bestandteil dabei ist die Implementierung des Scan-Line
Algorithmus, welche in der Klasse PolygonFill durchgeführt wird. Die Klasse edge stellt
dabei eine Hilfsklasse dar, die der Scan-Line Algorithmus benötigt.
Die zentrale Klasse im rechten Ast des Klassenmodells ist MarchingCube, welche den Marching-
Cube-Algorithmus implementiert. Die wichtigsten Methoden dieser Klasse sind Check, die
eine bestimmte Würfelkonfiguration auf eine Standardkonfiguration zurückführt, und GenerateTriangles,
die für das Erstellen der Dreiecke und das Zurückrotieren sorgt. Die Klassen
Cube und Triangle sind diejenigen Klassen, in denen die Würfel und Dreiecke verwaltet
werden. Ein Würfel besteht aus acht Voxel, wobei jeder Voxel den Farbwert, den Wahr-
Falsch-Wert und die dazugehörenden Koordinaten verwaltet. Ein Dreieck besteht nur aus
den Koordinaten der Eckpunkte und einem Farbwert.
Eine wesentliche Funktion von Würfel und Dreieck ist das Rotieren. Die Rotationen erfolgen
mit sogenannten Quaternionen. Der Einfachheit halber werden deswegen auch die Koordinaten
mithilfe von Quaternionen abgespeichert. Die Klasse 3dmath stellt die zugehörige
Funktionalität zur Verfügung.
Zum Abspeichern der Dreiecke ist die Hilfsklasse helpDxf vorgesehen. In diese Klasse sind
Funktionen zur Dateiverwaltung und zur einfachen Erstellung der DXF-Sections zu finden.
5.2 Bildbearbeitung
5.2.1 Ausgangspunkt
Die Beschaffung der benötigten MR-Bilder wurde bereits in Kap. 4.1 ausführlich beschrieben.
Einige Anmerkungen aus technischer Sicht sind dennoch notwendig.
Um die Bilder bearbeiten zu können, müssen sie im Bitmap-Format (*.bmp) vorliegen. Die
meisten medizinischen Bilder werden aber in einem speziellen Datenformat, dem DICOM -
Format, gespeichert. DICOM steht für Digital Imaging and Communications in Medicine
(vgl. [Lehmann et al., 1997]) und verwaltet nicht nur einzelne Bilder, sondern bietet die
Möglichkeit, ganze Bildarchive abzuspeichern, die zusammenhängende Abbildungen von Untersuchungen
beinhalten. Liegen die Bilder im DICOM-Format vor, ist eine Umwandlung in
entsprechende BMP-Files notwendig. Diese Umwandlung erfolgte mit der frei verfügbaren
Software dicom2 von Sébastien Barré (vgl. [Barré, 2001]). Es handelt sich dabei um ein einfaches
Kommandozeilen-Programm, das DICOM-Bilder problemlos in ein beliebiges Format
umwandelt.
Eine Bildserie besteht nach der Konvertierung aus einer bestimmten Anzahl von BMP-
Dateien, bei denen sich der Name nur durch eine laufende Nummer unterscheidet (xxx01.bmp,

44 KAPITEL 5. IMPLEMENTIERUNG
xxx02.bmp, usw.). Dabei wird vorausgesetzt, dass die Dateinamen aufsteigend sortiert sind.
Damit ist gemeint, dass z. B. die Datei xxx09.bmp räumlich vor der Datei xxx10.bmp liegt.
Ist dies gewährleistet, können die Veränderungen an den Bildern vorgenommen werden.
5.2.2 Veränderungen an den Bildern
5.2.2.1 Farbpalette
Zum Sortieren der Farbpalette muss jedes Bild einer Serie einzeln geladen werden. Die
Farbpalette wird dann mithilfe der Funktion GetPaletteEntries() in ein Objekt der Klasse
Palette eingelesen. Ein derartiges Objekt besteht im Wesentlichen aus einem Feld mit 256
Einträgen, wobei jeder Eintrag einen Farbwert (=Paletteneintrag) und einen Wahr-Falsch-
Markierer enthält (vgl. Abb. 5.2). Jeder Farbwert wird jetzt untersucht, ob er im Bild
vorkommt. Dazu wird für jeden Paletteneintrag eine Vertretung im Bild gesucht. Wird ein
Farbindex im Bild gefunden, erhält der zugehörige Markierer den Wert Wahr, andernfalls den
Wert Falsch. Die gefundenen Farbindizes werden dabei in einer Zählvariable (AnzahlFarben)
mitgezählt.
data
0 1 2 3 4 5 6 ... 255
entry: PALETTEENTRY
marker: BOOLEAN
Abbildung 5.2: Feld zur Verwaltung der Paletteneinträge
Die Farbpalette wird jetzt entsprechend sortiert:
1. Diejenigen Farbwerte, dessen Markierer den Wert Wahr haben, kommen an den Anfang
der Liste.
2. Die ” wahren” Farbwerte werden der Reihe nach aufsteigend sortiert.
Am Ende der Sortierung werden noch diejenigen Farbwerte, die nicht im Bild vorkommen
(also deren Markierer den Wert Falsch besitzen) auf die Farbe Schwarz gesetzt, in dem die
Rot-Grün-Blauwerte jener Paletteneinträge, die hinter dem Index AnzahlFarben liegen, auf
0 gesetzt werden.
Zum Abspeichern der Farbpalette wird die Funktion CreatePalette() hergenommen, die als
Parameter eine Variable vom Typ TLogPalette benötigt. Dieser Typ besitzt neben den
Paletteneinträgen und der Anzahl der Paletteneinträge eine Versionsnummer. Die einzelnen
Farbwerte werden also in der sortierten Reihenfolge in eine TLogPalette geschrieben und mit
CreatePalette dem Bild zugeordnet (vgl. Anhang A).
Diese Vorgehensweise verändert das Bild selbst nicht. Es wird lediglich die Palette verändert,
was später eine bessere Vergleichbarkeit der Farbwerte erlaubt.

5.2. BILDBEARBEITUNG 45
5.2.2.2 Polygon
Um die Bilder weiter bearbeiten zu können, müssen jetzt die Bilder der Serie geladen werden.
Die einzelnen Dateinamen der Bilder werden in einer Liste angezeigt (vgl. Abb. 5.3). Bei der
Auswahl eines Bildes, wird dieses angezeigt. Falls zu den Bildern bereits ein Polygon oder
ein Schwellwertbereich definiert wurde, wird hier bereits das veränderte Bild angezeigt.
Abbildung 5.3: Screenshot vom Programm zur Bildbearbeitung
Auf einem Bild kann jetzt mithilfe von Maus und Tastatur ein beliebiges Polygon gezeichnet
werden. Folgende Aktionen sind dabei möglich:
• Hinzufügen eines Polygonpunktes: Ein Klick mit der linken Maustaste während die
Shift-Taste gedrückt wird fügt an der aktuellen Mausposition einen Punkt ein.
• Verschieben eines Punktes: Durch einen Klick auf einen Punkt wird dieser markiert
und dann mit gedrückter Maustaste an die neue Position gezogen.
• Löschen eines Punktes: Ein Punkt wird gelöscht, wenn dieser bei gedrückter Ctrl-Taste
mit der Maus angeklickt wird.
Der Programmausschnitt, der diese Funktionalität realisiert, ist in Anhang A zu finden. Im
Wesentlichen werden dabei die Funktionen AddPoint(), ChangePoint() und DeletePoint()
aus der Klasse MyPolygon() aufgerufen. Bevor eine Veränderung tatsächlich wirksam wird,
wird untersucht, ob das veränderte Polygon noch aus einer Fläche besteht. Dazu wird bei
jeder Kante des Polygons überprüft, ob es eine Überschneidung mit irgendeiner anderen
Kante gibt. Diese Überprüfung geschieht mit dem Algorithmus zum Schneiden von Strecken
aus [Sedgewick, 1997]. Für die einzelnen Fälle gilt dabei:
• AddPoint: Bei AddPoint entstehen zwei neue Kanten. Es muss lediglich überprüft
werden, ob diese beiden Kanten eine bereits vorhandene Polygonkante schneiden.

46 KAPITEL 5. IMPLEMENTIERUNG
• ChangePoint: Verändert sich ein Punkt im Polygon, verändern sich damit zwei Polygonkanten.
Diese beiden Kanten werden mit allen anderen Kanten im Polygon geschnitten.
• DeletePoint: Es wird ein Hilfspolygon angelegt, bei dem der zu löschende Punkt ausgelassen
wird. In diesem Polygon wird jede Kante mit jeder geschnitten.
Kommt es dabei zu keinen Überschneidungen von Kanten, kann die gewünschte Aktion durchgeführt
werden. Weiters ist eine Überschneidung unmöglich, wenn die Gesamtanzahl der
Polygoneckpunkte kleiner oder gleich 3 ist. Damit ist gemeint, dass z. B. bei AddPoint im
bisherigen Polygon maximal zwei Eckpunkte vorhanden sind oder dass bei ChangePoint maximal
drei Polygoneckpunkte existieren. Tritt dieser Fall auf, kann die Aktion auf jeden Fall
durchgeführt werden.
Die grafische Visualisierung des Polygons ist von der tatsächlichen Veränderung im gespeicherten
Polygon getrennt. Wird z. B. ein Eckpunkt verschoben, wird das ” neue” Polygon nur
gezeichnet, solange die Maustaste gedrückt wird. Dies geschieht mit einer eigenen Funktion
Draw(). Die Veränderungen werden erst dann wirksam, wenn die Maustaste wieder ausgelassen
wird. Der Benutzer kann so ein beliebiges Polygon am Bildschirm zeichnen, wobei die
einzige Einschränkung die ist, dass das Polygon aus einer Fläche bestehen muss.
5.2.2.3 Schwellwertbereich
Der Schwellwertbereich wird im Programm dadurch gesetzt, dass der obere und untere
Schwellwert durch einen Schieberegler eingestellt wird (vgl. dazu Abb. 5.3 links unten). Im
angezeigten Bild umfasst der Schwellwertbereich alle Grauwertstufen (unterer Schwellwert 0
und oberer Schwellwert 255). Darum ist das Bild im Original zu sehen.
Der Benutzer kann jetzt mithilfe der Schieberegler einen beliebigen Schwellwertbereich einstellen.
Der untere bzw. der obere Schwellwert können unabhängig voneinander verändert
werden. Die Auswirkungen sind direkt am Bildschirm erkennbar. In Anhang B sind einige
Beispiele von verschiedenen Schwellwerteinstellungen zu sehen. Wird z. B. der untere Schwellwert
nach oben gesetzt, verschwinden die dunkleren Bildpunkte. Wird der obere Schwellwert
nach unten gesetzt, verschwinden die helleren Bildpunkte.
Bei jeder Veränderung einer Schwellwertgrenze wird die zugehörige Variable lowerBound
oder upperBound aus der Klasse Threshold gesetzt und die Funktion Draw() aus der Klasse
Picture aufgerufen. Diese Funktion zeichnet das Bild Pixel für Pixel auf den Bildschirm.
Dabei wird für jedes Pixel der Farbwert überprüft. Befindet sich der Farbwert innerhalb des
Schwellwertbereiches, wird dieser Farbwert auf dem Bildschirm angezeigt. Ansonsten wird
ein weißer Punkt gezeichnet.
Dadurch kann der Benutzer die optimale Einstellung für einen Schwellwertbereich finden.
Wurden jetzt sowohl Schwellwertbereich als auch Polygon definiert, können diese Dinge abgespeichert
werden, um die Einstellungen für später zu archivieren.

5.2. BILDBEARBEITUNG 47
Bilddatei Polygondatei Thresholddatei
20001123 coronal512 05.bmp 20001123 coronal512 05.pol 20001123 coronal512 05.thr
20001123 coronal512 06.bmp 20001123 coronal512 06.pol 20001123 coronal512 06.thr
20001123 coronal512 07.bmp 20001123 coronal512 07.pol 20001123 coronal512 07.thr
20001123 coronal512 08.bmp 20001123 coronal512 08.pol 20001123 coronal512 08.thr
20001123 coronal512 09.bmp 20001123 coronal512 09.pol 20001123 coronal512 09.thr
20001123 coronal512 10.bmp 20001123 coronal512 10.pol 20001123 coronal512 10.thr
20001123 coronal512 11.bmp 20001123 coronal512 11.pol 20001123 coronal512 11.thr
... ... ...
Tabelle 5.1: Beispiel für die Dateibenennung
5.2.3 Abspeichern der Zwischenergebnisse
Sowohl in der Klasse MyPolygon als auch in der Klasse Threshold gibt es eine Methode
Save(), die zum Abspeichern der jeweiligen Informationen dient.
Die Gemeinsamkeit dabei ist, dass beide Methoden als Parameter den Namen der zugehörigen
Bilddatei erhalten. Der Name der Bilddatei ist gleichzeitig der Name der Polygon- bzw.
Threshold-Datei. Es wird lediglich die Dateiendung abgeändert. So erhalten Polygondateien
die Endung ” *.pol” und Thresholddateien die Endung ” *.thr”. Tab. 5.1 zeigt einen Ausschnitt
derjenigen Dateien, die für die erste Bildserie erstellt wurden. Die Beibehaltung der
Dateinamen wurde deswegen gewählt, weil dadurch eine relativ einfache Implementierung des
Speichervorgangs möglich ist. Werden zu einem bestimmten Bild die gespeicherten Polygonoder
Thresholdwerte benötigt, reicht es, den Namen der Bilddatei zu kennen.
Wenn die gewünschte Datei noch nicht existiert, wird sie mit CreateFile(FileName) erstellt.
Ist die Datei bereits vorhanden, wird sie mit OpenFile(FileName, Mode) geöffnet, wobei
alle bisherigen Inhalte gelöscht werden (Mithilfe des Parameters Mode wird die Datei für
Schreibzugriff geöffnet). Der Rückgabewert beider Funktionen ist ein iFileHandle, mit dem
die folgenden Funktionen auf die Datei zugreifen.
Zum Speichern eines Polygons wird jetzt die Liste, die die Koordinaten verwaltet, durchlaufen.
Jeder Polygonpunkt wird einzeln in die Datei gespeichert, wobei die Funktion File-
Write(...) verwendet wird. Ein Schwellwertbereich wird abgespeichert, in dem die beiden
Integer-Werte lowerBound und upperBound mithilfe von FileWrite(...) in die entsprechende
Datei geschrieben werden. Am Ende wird die Datei mit FileClose(...) geschlossen.
Weiters ist eine Methode Load() zum Laden der Dateien vorgesehen. Dabei wird eine Datei
für den Lesezugriff geöffnet und die Inhalte mit FileRead(...) aus der Datei gelesen. Wird
ein Polygon geladen, wird die Liste der Punkte mit den Werten aus der Datei neu aufgebaut.
Die geladenen Schwellwerte werden den Variablen in der Klasse Threshold zugewiesen.
Obwohl durch diese Vorgangsweise viele kleine Dateien entstehen (die Thresholddatein sind
beispielsweise nur acht Bytes groß), wurde ihr der Vorzug gegeben. Sie ist relativ einfach zu
implementieren, da keine zusätzlichen Suchalgorithmen oder Datenbankfunktionen notwen-

48 KAPITEL 5. IMPLEMENTIERUNG
dig sind.
5.3 Generierung eines Polyedermodells
Die vorbereiteten Bilder werden jetzt im zweiten Programmteil analysiert und ein Polyedermodell
der gesuchten Oberfläche wird erstellt. Dazu ist zunächst ein Datenvolumen aufzubauen,
das nur mehr die relevanten Bildpunkte beinhaltet. Erst danach wird dieses Datenvolumen
durchlaufen und ein Polyedermodell bestehend aus Dreiecken erstellt. Dieses Dreiecksmodell
wird schließlich abgespeichert und damit anderen Anwendungen zur Verfügung
gestellt.
5.3.1 Erstellung eines Volumensmodells
Um ein Datenvolumen erstellen zu können, müssen die zuvor manipulierten Bilder geladen
werden. Dabei kann der Benutzer selbst auswählen, welche Bilder zur Verwendung kommen.
Es müssen allerdings für alle verwendeten Bilder auch die zugehörigen Polygon- und
Threshold-Dateien vorhanden sein.
Ein Objekt der Klasse VolumeData öffnet zunächst einen Dialog, indem der Benutzer die
gewünschten Dateien auswählen kann. Für jeden Eintrag dieser Dateiliste wird jetzt
• die zugehörige Bilddatei in den Hauptspeicher geladen,
• die richtige Einfügeposition ermittelt (ist der Eintrag bereits vorhanden, wird der
nächste Eintrag bearbeitet),
• ein Objekt der Klasse Picture angelegt, das mit den gespeicherten Werten initialisiert
wird,
• dieses Picture-Objekt an die ermittelte Position in der Liste eingefügt.
Das Laden der Bilddatei erfolgt mit der Funktion LoadFromFile(FileName). Ist die Datei mit
dem angegebenen Dateinamen nicht vorhanden, wird eine Ausnahme (Exception) geworfen
und die Verarbeitung für diese Datei abgebrochen.
Zum Ermitteln der richtigen Einfügeposition werden die Dateinamen miteinander verglichen.
Die Bilder werden in einer TList abgespeichert, die im Grunde nur ein Feld von Zeigern
verwaltet. Die Dateinamen jedes Eintrages werden nun mit dem neuen Eintrag verglichen.
Ist noch kein Eintrag vorhanden, kann direkt mit der Verarbeitung fortgefahren werden.
Ansonsten stoppt die Suche nach der richtigen Position, sobald der Eintrag aus der Liste
größer oder gleich ist, als der Dateiname des neuen Eintrags. Bei gleichen Dateinamen darf
dieser nicht in die bestehende Liste eingefügt werden. Eine Fehlermeldung wird angezeigt
und die Verarbeitung mit der nächsten Datei fortgesetzt.
Jetzt wird ein neues Objekt der Klasse Picture erstellt. Dem Konstruktor wird dabei das
geladene Bitmap und der Dateiname übergeben. Dort werden Objekte der Klassen Palette,
MyPolygon und Threshold erstellt und initialisiert:

5.3. GENERIERUNG EINES POLYEDERMODELLS 49
• Die Paletteneinträge werden aus dem Bitmap in die Palette geschrieben.
• Die Indizes der Bildpunkte werden aus dem Bitmap in ein zweidimensionales Feld aus
Integer-Werten geschrieben.
• Das Polygon wird aufgebaut, indem mit der Methode Load die gespeicherten Einträge
geladen werden.
• Dem Threshold-Objekt werden mit der Methode Load die gespeicherten Werte zugewiesen.
Das so erstellte Picture-Objekt wird in die Liste der Bilder eingefügt. Der Datentyp TList
stellt dazu die Methode Insert(index, pointer) zur Verfügung. Diese fügt an der Stelle index
den Zeiger auf das Objekt ein und verwaltet selbständig den Speicher.
Mithilfe der Methode GenerateSubVolume() aus der Klasse VolumeData wird jetzt das neue
Datenvolumen erstellt. Dabei werden zunächst die maximalen bzw. minimalen Koordinaten
der Polygone aller beteiligter Bilder ermittelt. Sämtliche Punkte aller Polygone werden
betrachtet. Die kleinsten Koordinaten werden in einer Variable min gespeichert und die
größten Koordinaten in einer Variable max (vgl. dazu das Programmbeispiel aus Anhang A).
Um sicher zu gehen, dass alle Polygoneckpunkte im neuen Datenvolumen Platz finden, wird
ein Sicherheitsrand von einem Pixel an allen Seiten angebracht. Die min-Werte werden um
1 verringert, die max-Werte um 1 erhöht.
Das neue Datenvolumen (das SubVolume) wird erstellt, indem neue Objekte der Klasse
Picture angelegt werden. Die Ausdehnung dieser Bilder in x-Richtung entspricht xlength =
xmax − xmin und die Ausdehung in y-Richtung ist ylength = ymax − ymin. Beim Erstellen
dieser Bilder werden zunächst alle Farbwerte auf einen sicher falschen Wert (-1) gesetzt.
Die Implementierung des Scan-Line Verfahrens befindet sich in der Klasse PolygonFill. Nach
einer entsprechenden Initialisierung liefert die Methode GetNextPoint() solange den nächsten
Punkt im Polygon, bis der zurückgelieferte y-Wert gleich -1 ist. Jedes Pixel, das sich innerhalb
des Polygons befindet, wird nun in das neue Datenvolumen kopiert, indem die Methode
SetIndexForPixel(...) vom neu erstellten Picture-Objekt aufgerufen wird. Als Parameter
erhält diese Methode den Wert, der durch GetIndexFromPixel(...) vom ursprünglichen Bild
geliefert wird (vgl. Anhang A). Das neue Picture-Objekt wird schließlich in das SubVolume
eingefügt.
Das so entstandene neue Datenvolumen beinhaltet nicht nur alle Bildpunkte, die innerhalb
der Polygone liegen. Es sind auch viele Bildpunkte außerhalb der Polygone enthalten. Diese
besitzen allerdings durch die Initialisierung am Beginn einen sicher falschen Farbwert und
werden somit beim Generieren der Polygonoberfläche nicht berücksichtigt.
5.3.2 Polygongenerierung mithilfe des Marching-Cube-Algorithmus
Beim Durchlaufen des Datenvolumens wird bei jedem Schritt ein Würfel definiert. Diese
Aufgabe wird von der Methode GetNextCube(...) aus der Klasse VolumeData übernommen.

50 KAPITEL 5. IMPLEMENTIERUNG
Eckenindex x-Ausdehnung y-Ausdehnung z-Ausdehnung
0 col index line index + 1 pic index
1 col index + 1 line index + 1 pic index
2 col index + 1 line index + 1 pic index + 1
3 col index line index + 1 pic index + 1
4 col index line index pic index
5 col index + 1 line index pic index
6 col index + 1 line index pic index + 1
7 col index line index pic index + 1
Tabelle 5.2: Definition der Würfel
Dabei ist der Rückgabewert wahr, solange sich ein Würfel im Datenvolumen generieren lässt.
Die Methode verwendet drei Laufvariablen, die zu Beginn der Verarbeitung auf 0 gesetzt
werden und die Voxelstruktur durchlaufen:
• col index: Durchläuft das Datenvolumen in x-Richtung. Sie wird bei jedem Aufruf von
GetNextCube(...) erhöht, solange bis sie die Anzahl der Voxel in der Spalte -1 erreicht
hat (col index = xlength − 1). Dann wird col index auf 0 gesetzt und line index erhöht.
• line index: Durchläuft das Datenvolumen in y-Richtung. Ein Zeilenvorschub geschieht
immer dann, wenn alle Punkte einer Zeile analysiert worden sind. Wenn line index =
ylength − 1 ist, wird line index auf 0 gesetzt und der pic index erhöht.
• pic index: Durchläuft alle Bilder im Datenvolumen. Wurden alle Bildpunkte im Bild
analysiert, wird auf das nächste Bild weitergeschaltet. Auch dieser Index läuft nur bis
zu der um eins verminderten Anzahl der Bilder.
Die jeweiligen Indizes laufen immer bis zur maximalen Anzahl -1. Der Grund liegt darin,
dass beim Aufbau eines Würfels die ” nächsten” Punkte auch benötigt werden. Die Zuweisung
der Laufvariablen zu den Würfeleckpunkten ist in Tab. 5.2 angegeben. Die x-y-Ebene
spannt dabei ein Bild auf und die z-Richtung entspricht dem Index der Schnittbilder. Diese
Zuordnung ist in Abb. 5.4 grafisch dargestellt.
Ein Würfel wird im Programm mit einem Objekt der Klasse Cube repräsentiert. Die Komponenten
von Cubes sind
• ein Feld von acht Voxel (ein Voxel besteht aus dem Farbwert, einem Wahr-Falsch-
Markierer und den Koordinaten) und
• ein Feld von zwölf Werten vom Typ unsigned char, die zur Verwaltung der Schwellwerte
für die Würfelkanten dienen.
Bevor mit dem Füllen der einzelnen Voxel begonnen werden kann, ist die Schwellwertanalyse
durchzuführen. Die Methode Analyze(ColorIndex) aus der Klasse Threshold überprüft, ob
ein Index auf eine Farbe innerhalb der Schwellwertgrenze liegt und gibt einen Wahr- oder

5.3. GENERIERUNG EINES POLYEDERMODELLS 51
pic_index+1
line_index
z
line_index+1
pic_index
7
3
y
Abbildung 5.4: Aufbau eines Würfels
0
4
2
6
col_index col_index+1
Falschwert zurück. Dabei ist natürlich darauf zu achten, dass der richtige Schwellwertbereich
hergenommen wird, da für die Bilder unterschiedliche Definitionen vorhanden sind. Zum
Befüllen der einzelnen Voxel stellt die Klasse Cube drei Methoden zur Verfügung:
1. SetIncludedOfVoxel(index, marker) setzt für einen bestimmten Eckenindex den Wahr-
Falsch-Wert, den die Schwellwertanalyse ergibt.
2. SetCoordOfVoxel(index, coords) setzt die Koordinaten für den Eckpunkt.
3. SetColorOfVoxel(index, color) setzt denjenigen Farbwert, der auf dem Originalbild an
dieser Stelle vorhanden ist.
Die Berechnung des Kantenschwellwertes erfolgt mithilfe der Funktion GetEdgeThreshold(...)
(die Implementierung ist in Anhang A zu finden). Als Eingabe werden dabei die Farbwerte
der beiden Eckpunkte einer Kante benötigt und ein Schwellwertbereich. Befinden sich die
Kanten des Würfels auf einem Bild, wird jeweils das zugehörige Threshold-Objekt übergeben.
Wenn nicht, wird jeweils aus den oberen und unteren Schwellwerten der beiden Bereiche der
Durchschnitt ausgerechnet und der somit neu entstandene Schwellwertbereich übergeben.
Die so definierten Würfel werden jetzt mit der Methode Check(...) aus der Klasse MarchingCube
auf eine Standardkonfiguration zurückgeführt. Der Rückgabewert dieser Methode
entspricht dem Index der Standardkonfiguration.
Bei der Verarbeitung in der Methode Check(...) werden zunächst in einer Schleife die Wahr-
Falsch-Entitäten der acht Eckpunkte untersucht. Gibt es mehr als vier Eckpunkte mit einem
Wert Wahr, werden diese Entitäten einfach vertauscht.
5
1
x

52 KAPITEL 5. IMPLEMENTIERUNG
In einer weiteren Schleife werden jetzt diejenigen Rotationen, die bereits in Kap. 4.3.3 beschrieben
wurden, auf den Würfel angewendet. Eine Methode Rotate(...) aus der Klasse
Cube sorgt für die Rotationen. Dabei werden sogenannte Quaternionen verwendet.
Quaternionen bestehen grundsätzlich aus einem skalaren Anteil s und einem einem vektoriellen
Anteil �v. Der große Nutzen für die Berechnung von Rotationen besteht darin, dass mit
dem vektoriellen Teil eine (beliebige) Rotationsachse aufgestellt werden kann und im skalaren
Teil wird dann der Rotationswinkel angegeben. Eine genaue Beschreibung der Quaternionen
in Verbindung mit Rotationen ist in [Kaltofen, 2001] zu finden.
Alle Koordinaten im Würfel werden mit Quaternionen gespeichert. Dazu wird der Skalaranteil
auf 0 gesetzt und im vektoriellen Anteil die Koordinaten eingetragen. Um jetzt einen
beliebigen Punkt P um einen Quaternion Q zu rotieren, genügt es die Formel
PRot = Q ◦ P ◦ Q −1
(5.1)
anzuwenden. Dabei ist anzumerken, dass das Rotationsquaternion Q ein Einheitsquaternion
sein muss.
Nun wird untersucht, ob der rotierte Würfel schon mit einer Standardkonfiguration übereinstimmt.
Dazu wird der Würfel in einer Schleife mit allen 15 Grundkonfigurationen verglichen.
Dies geschieht mit einer Methode Compare(...) aus der Klasse Cube, die für alle acht Eckpunkte
die Wahr-Falsch-Entitäten beider Würfel vergleicht.
Sobald eine Übereinstimmung gegeben ist, wird der Vorgang abgebrochen und die Methode
Check() beendet. Wichtig ist, dass die Nummer der Standardkonfiguration sowie das
Rotatationsquaternion und der rotierte Würfel zurückgegeben werden.
Mit diesen Informationen wird die Methode GenerateTriangles(...) aus der Klasse MarchingCube
aufgerufen. Mit dem Index der Standardkonfiguration wird die entsprechende
Dreieckskonfiguration laut Tab. 4.3 zugewiesen. Die genaue Berechnung der Dreieckspunkte
geschieht mit der Funktion CalculatePoint(...), der neben den beiden Farbwerten der Kanteneckpunkte
auch der Kantenschwellwert als Parameter übergeben wird.
Die jetzt entstandenen Dreiecke können relativ einfach zurückrotiert werden. Dies geschieht
in einer Methode Rotate(...) aus der Klasse Triangle, indem der Rotationsquaternion invertiert
wird:
PRot = Q −1 ◦ P ◦ Q (5.2)
Wenn die Würfelkonfiguration am Beginn der Verarbeitung invertiert wurde, muss jetzt noch
die Orientierung der Dreiecke geändert werden. Dies ist notwendig, damit die späteren
Visualisierungsprogramme die Normalen auf die Dreiecke richtig zeichnen. In einer Methode
Flip() aus der Klasse Triangle werden einfach zwei Eckpunkte vertauscht und somit die
Orientierung geändert.
Um die Dreiecke in die richtige Lage im Objekt zu bringen, werden die Ausgangskoordinaten,
die durch den Würfel bekannt sind, zu den Dreieckskoordinaten dazuaddiert. Die Dreiecke

5.3. GENERIERUNG EINES POLYEDERMODELLS 53
besitzen jetzt die richtige Orientierung und Lage im Objekt und können im folgenden Schritt
abgespeichert werden.
5.3.3 Abspeicherung der Resultate
Der Vorgang des Abspeicherns beginnt schon vor der Deklaration des ersten Würfels. Durch
das Anlegen eines neuen Objekts der Klasse helpDxf wird eine DXF-Datei angelegt. Die
Klasse helpDxf stellt einige Methoden zur Verfügung, die das Schreiben in die DXF-Datei
unterstützen:
• Write(...): Schreibt einen DXF-Eintrag.
• WriteHeaderSection(): Schreibt eine fix vorgegebene Header-Section in die DXF-Datei.
• WriteTablesSection(): Schreibt eine fix vorgegebene Tables-Section in die DXF-Datei.
• WriteTriangle(...): Die Eckpunkte eines Dreiecks werden übergeben und in die DXF-
Datei geschrieben.
Nach jedem Aufruf von GenerateTriangles(...) werden die erstellten Dreiecke sofort mithilfe
der Methode WriteTriangle(...) abgespeichert. Dies geschieht, indem alle drei Punkte des
Dreiecks mit ihren Koordinaten in das DXF-Format gebracht werden und dann mittels der
Funktion Write(...) zeichenweise in die Datei geschrieben werden.
Zusätzlich zur DXF-Datei wird noch eine Metadatei im Textformt gespeichert. Die darin
enthalten Informationen sind die Größe der verwendeten Bilder bzw. die Ausdehnungen des
erstellten Datenvolumens und eine Liste aller verwendeten Bilddateien. Diese Informationen
werden für spätere Arbeiten mit den Ergebnissen benötigt.

54 KAPITEL 5. IMPLEMENTIERUNG

Kapitel 6
Anwendung und Ergebnisse
6.1 Beispiel: Rekonstruktion des m. rect. med. aus Coronalschnitten
Dieses Beispiel soll den Ablauf der bisher beschriebenen Tätigkeiten veranschaulichen. Die
Aufgabe besteht darin, ausgehend von den Bildern der Serie 1, es handelt sich dabei um
Coronalschnitte, die wenige Millimeter hinter dem Augapfel aufgenommen wurden, den
m. rect. med. zu segmentieren und schließlich dreidimensional darzustellen.
Die Bilder liegen bereits im BMP-Format vor und die Namen der Dateien sind aufsteigend
sortiert. Der erste Schritt ist also das Sortieren der Farbpaletten. Dazu wird ein Bild in das
Programm Farbpalette geladen. Der Menüpunkt Aktion bietet zwei Möglichkeiten:
1. Anzeigen der Farbpalette,
2. Sortieren der Farbpalette.
Bei Auswahl der ersten Aktion wird die Farbpalette im Textfeld angezeigt. Bei Auswahl
der zweiten Aktion wird zunächst die Farbpalette vor der Sortierung angezeigt, dann wird
die Sortierung durchgeführt und schließlich die neue, veränderte Farbpalette in das Textfeld
geschrieben (vgl. Abb. 6.1). Beim angezeigten Bild sind 244 Graustufen in Verwendung. Der
Rest wurde auf Schwarz gesetzt. Vor dem Verlassen des Programms kann das Bild mit der
veränderten Farbpalette abgespeichert werden.
Um jetzt die Bilder zu bearbeiten, werden sie in das Programm ” Bilder segmentieren” geladen
(vgl. Abb. 6.2). Dazu werden alle 18 Bilder der Serie markiert und geöffnet. Die Dateinamen
werden im Listenfeld auf der rechten Seite des Programmfensters aufgelistet. Bei der Auswahl
eines Dateinamens wird das zugehörige Bild angezeigt. Existiert bereits eine Polygon- bzw.
eine Threshold-Datei, wird sofort das Polygon auf das Bild gezeichnet bzw. werden diejenigen
Bildpunkte, die außerhalb des Schwellwertbereiches liegen, nicht mehr angezeigt.
Der Benutzer kann jetzt die Einstellungen für Polygone und Schwellwerte treffen. Abb. 6.3
55

56 KAPITEL 6. ANWENDUNG UND ERGEBNISSE
Abbildung 6.1: Sortieren der Farbpalette
Abbildung 6.2: Öffnen der Bilddateien

6.1. BEISPIEL: REKONSTRUKTION DES M. RECT. MED. AUS CORONALSCHNITTEN57
zeigt eine selbstverständlich unsinnige, aber mögliche Einstellung der Werte. Der Schwellwertbereich
wurde so gewählt, dass die dunkleren Bildpunkte verschwinden. Dadurch werden
die Farbinformationen beim Muskel gelöscht. Das Polygon ist willkürlich im Zeichenbereich
angeordnet. Das ist möglich, solange das Polygon aus einer Fläche besteht, und das ist hier
der Fall. Es liegt also in der Verantwortung des Benutzers, wie er die Einstellungen trifft.
Abbildung 6.3: Mögliche Schwellwert- und Polygondefinition
Jedes einzelne Bild muss jetzt also für sich betrachtet und manipuliert werden. Die getroffenen
Schwellwerteinstellungen für dieses Beispiel sind in Tab. 6.1 zu sehen und Ausschnitte
von den manipulierten Bildern sind in Abb. 6.4 abgebildet. Auf den Bildern 01 bis 04 ist kein
Muskel zu erkennen. Diese Bilder haben daher auch keine Relevanz für die späteren Arbeiten.
Es wurde weder ein Schwellwertbereich noch ein Polygon definiert. Bei den Schwellwertbereichen
in der Tabelle fällt auf, dass nur obere Schwellwerte definiert wurden. Auf allen
Bildern wird also der gewünschte Bereich, nämlich der des m. rect. med., allein durch die
Herausfilterung der hellen Bildpunkte ausreichend gut isoliert.
All diese Manipulationen werden jetzt abgespeichert. Das Programm ” DXF erstellen” benutzt
diese Daten als Eingabe und führt das Scan-Line Verfahren und den Marching-Cube-
Algorithmus aus. Die einzige Benutzereingabe, die dabei notwendig ist, geschieht beim Laden
der Dateien. In einem Öffnen-Dialog werden diejenigen Dateien ausgewählt, die in das Ergebnis
einfließen sollen. Im Beispielfall sind das die Bilder 05 bis 18.
Es werden jetzt alle Bilder durchlaufen und eine DXF-Datei erstellt. Diese DXF-Datei kann
mit einem beliebigen 3D-fähigen Grafikprogramm visualisiert werden. In diesem Fall wurde
die Datei mit dem Program ” Micrografx Instant 3D” geöffnet. Das gespeicherte Objekt wird
dreidimensional visualisiert und kann von allen Seiten betrachtet werden (vgl. Abb. 6.5).
Die Dreiecke bilden im Wesentlichen eine geschlossene Oberfläche. Die kleinen Gebilde am
rechten Rand des Muskels stammen von ” Pixelüberresten” aus den Bildern. Es sind dies
jene Pixel, die weder durch die Schwellwertanalyse noch durch die Polygongrenzen eliminiert

58 KAPITEL 6. ANWENDUNG UND ERGEBNISSE
Bildindex unterer Schwellwert oberer Schwellwert
01 kein Schwellwert kein Schwellwert
02 kein Schwellwert kein Schwellwert
03 kein Schwellwert kein Schwellwert
04 kein Schwellwert kein Schwellwert
05 0 119
06 0 107
07 0 138
08 0 131
09 0 150
10 0 146
11 0 136
12 0 112
13 0 139
14 0 135
15 0 121
16 0 115
17 0 129
18 0 139
Tabelle 6.1: Schwellwertbereiche der Bildserie
Abbildung 6.4: Ausschnitte der manipulierten Bilder

6.2. VERGLEICH DER ERGEBNISSE MIT ANDEREN ANWENDUNGEN 59
werden konnten. In Abb. 6.6 wurde der selbe Muskel so gedreht, dass ein Blick durch den
Muskel hindurch möglich ist. Auch hier ist die geschlossene Oberfläche wieder zu erkennen.
Abbildung 6.5: 3D-Rekonstruktion des m. rect. med.
6.2 Vergleich der Ergebnisse mit anderen Anwendungen
Gerade in einer Zeit, in der die technische Entwicklung von Computern immer rasanter
fortschreitet, wird auch auf dem Gebiet der Visualisierung von menschlichen Organen eine
intensive Forschungstätigkeit betrieben. Ein interessanter und gleichzeitig bemerkenswerter
Meilenstein ist dabei der Abteilung für Informatik und Datenverarbeitung in der Medizin
der Universitätsklinik Hamburg-Eppendorf [Höhne, 2001] gelungen: Der Voxel-Man
3D-Navigator Gehirn und Schädel.
In diesem Programm wurden zahlreiche MR- und CT-Bilddatensätze verarbeitet und verschiedenste
Modelle des menschlichen Schädels erstellt. Eine detaillierte Visualisierung der
Schädelknochen ist dabei genauso zu finden, wie eine Darstellung des Gehirns oder der Blutbahnen.
In Abb. 6.7 ist eine Szene zu sehen, in der das Kleinhirn, der Rückenmarkansatz
sowie Sehnerv und Bulbus dargestellt sind.
Um nun eine Vorstellung darüber zu bekommen, inwieweit die vorliegende Arbeit mit derartigen
Visualisierungen mithalten kann, wurde aus einem Bilddatensatz der Sehnerv und
der Bulbus rekonstruiert. Das Ergebnis in Abb. 6.8 zeigt natürlich gravierende Unterschiede
zum Voxel-Man, aber, es ist doch schon eine Oberfläche des Nerves bzw. die Krümmung des
Bulbus zu erkennen.
Die deutlichen Unterschiede ergeben sich schon alleine aus der Tatsache, dass für diesen Ver-

60 KAPITEL 6. ANWENDUNG UND ERGEBNISSE
Abbildung 6.6: Blick durch den m. rect. med.
such nur eine kleine Anzahl von MR-Bildern zur Verfügung gestanden sind. Weiters wurden
Rekonstruktionsalgorithmus und Darstellungstechniken beim Voxel-Man durch jahrelange
Forschung verfeinert und optimiert. Dieser Vergleich zeigt aber, dass bei den Entscheidungen
für bestimmte Vorgehensweisen der richtige Weg eingeschlagen wurde.
Ein weiterer positiver Effekt dieses Vergleiches ist die Erkenntnis, dass das erstellte Programm
beliebige Körperteile nachbilden kann. Mit relativ geringem Aufwand konnte die
Visualisierung des Sehnervs und des Bulbus durchgeführt werden. Es ist also leicht vorstellbar,
dieses Programm auch für andere Körperregionen einzusetzen. Einzige Voraussetzung
ist, dass die Eingabeparameter, also die medizinischen Bildfolgen, von ausreichender Qualität
sind. Je besser die Bilder, um so besser das Ergebnis!

6.2. VERGLEICH DER ERGEBNISSE MIT ANDEREN ANWENDUNGEN 61
Abbildung 6.7: Ausschnitt aus dem Voxel-Man 3D-Navigator

62 KAPITEL 6. ANWENDUNG UND ERGEBNISSE
Abbildung 6.8: 3D-Rekonstruktion von Sehnerv und Bulbus

Kapitel 7
Vorgehen aus der Sicht des
Software-Ingenieurs
Bei der Erstellung von Software für eine medizinische Anwendung wird vom Software-Ingenieur
ein gewisses Maß an medizinischem Detailwissen verlangt. Der klassische Software-
Ingenieur hat in der Regel nicht die Möglichkeit, derartiges Wissen bereits in der Ausbildung
aufzubauen. Am Beginn eines Softwareprojektes für die Medizin ist also ein Einlesen in
anatomische und diagnostische Grundlagen des menschlichen Körpers notwendig. Für die
vorliegende Arbeit war speziell das menschliche Auge und die Art und Weise der Augenbewegungen
interessant. Die medizinischen Fachausdrücke sind anfangs doch sehr verwirrend,
allerdings wird mit einiger Übung eine gewisse Routine aufgebaut und so die Sprache der
Mediziner erlernt.
Genau um dieses gegenseitige Verständnis geht es bei jeder Art von Softwareerstellung. Die
Meinungen und das Wissen eines Arztes ist für ein gutes Programm unbedingt notwendig.
Die Aufgabe des Programmierers ist es dabei, die Vorgänge zu analysieren, zu verstehen
und schließlich umzusetzen. Die Wissensgrundlagen für diese Arbeit lassen sich wie folgt
konkretisieren:
• Anatomie des menschlichen Auges,
• medizinische Bezeichnungen der beteiligten Körperteile,
• Wirkung der einzelnen Muskeln auf den Bulbus,
• Entstehung von MR-Bildern,
• Erkennung von Organen auf MR-Bildern.
In dieser Aufzählung wurden nur die medizinischen Grundlagen erwähnt. Natürlich waren
auch im softwaretechnischen Bereich einige Algorithmen und Verfahren zu erlernen bzw.
zu perfektionieren. Die gesamte Einlesearbeit nahm einen nicht unbeträchtlichen Teil der
Arbeitszeit in Anspruch, ist aber für ein gutes Ergebnis unbeding notwendig.
63

64 KAPITEL 7. VORGEHEN AUS DER SICHT DES SOFTWARE-INGENIEURS
Das Projekt SEE-KID ist ein Forschungsprojekt. Der Vorteil eines Forschungsprojektes ist
gleichzeitig auch der Nachtel: Das Arbeiten in einem Forschungsumfeld ermöglicht es bzw.
erfordert es, sich in völlig neue und bislang unbekannte Algorithmen und Abläufe einzuarbeiten.
Das gute Arbeitsumfeld und die ständige Beschäftigung mit Neuem fördern die
Motivation und laden ein, die eigenen Grenzen auszuloten und den Horizont zu erweitern.
Allerdings sind die Vorgaben bezüglich einer Projektplanung eher rar. Es besteht leicht die
Gefahr, den Roten Faden zu verlieren und sich auf die falschen und unwichtigen Dinge zu
sehr zu konzentrieren. Man ist teilweise völlig auf sich allein gestellt, was einerseits zwar die
Kreativität fördert, aber andererseits eine hohe Selbstdisziplin erfordert.
Zur Sicherung der Qualität der erstellten Software wurden laufend Überprüfungen der Zwischen-
und Endergebnisse durchgeführt. Plausibilität und Verwendbarkeit waren dabei die
obersten Kriterien. So wurde z. B. beim Sortieren der Farbpalette das Ergebnis des erstellten
Programms in einem handelsüblichen Grafikprogramm kontrolliert, indem dort die Farbpalette
angezeigt wurde. Die Veränderung der Farbanordnung vor und nach der Sortierung
waren gut zu erkennen.
Im Vordergrund der Arbeit stand immer eine möglichst genaue Implementierung der Algorithmen.
Das Erhalten von richtigen Ergebnisse war wichtiger als eine besonders bedienerfreundliche
Benutzeroberfläche, da das System für die Benutzung von Expertern ausgelegt ist. Die
Erfahrung zeigte allerdings, dass gewisse Grundelemente, wie Statuszeile oder Menüführung,
dennoch vorhanden sein müssen.
Weiters ist die Verwendung einer Versionsverwaltung unbeding empfehlenswert. Gerade in
einer Forschungsumgebung, in der viel ausprobiert, verändert und wieder verworfen wird,
kann leicht der Überblick verloren werden. Eine gute Dokumentation hilft dabei wesentlich,
ist aber nicht das einzige Allheilmittel.
Abschließend sei mir noch eine persönliche Anmerkung erlaubt: Das Arbeiten im medizinischen
Umfeld ist höchst faszinierend. Allein die Tatsache, dass das oberste Ziel des Projektes
eine Verbesserung der Situation des Patienten ist, motiviert zu Höchstleistungen. Eine umfassende
Forschung ist die Grundlage für viele Arbeiten - und das nicht nur in der Medizin.
Es werden aber auch die entsprechenden Praktiker benötigt, die die Ergebnisse der Forschung
umsetzen. Diese Praktiker liefern ihrerseits wieder neue Ideen, die in die Forschung einfließen.
Forscher sind wichtig für Praktiker - Praktiker sind wichtig für Forscher.

Kapitel 8
Schlussbemerkungen
8.1 Ergebnis
Im Rahmen dieser Arbeit wurde ein System entwickelt, mit dem es möglich ist, ausgehend
von MR-Bildern des menschlichen Auges die extraokulären Augenmuskeln zu segmentieren,
die Oberfläche zu analysieren und dreidimensional darzustellen. Das Programm wurde so
ausgelegt, dass die Auswahl des gewünschten Darstellungsbereiches vom Benutzer selbst getroffen
wird. Dadurch ist nicht nur eine Visualisierung der Augenmuskeln möglich, es kann
jeder beliebige Körperteil analysiert werden.
Eine wesentliche Anforderung war das Finden und Implementieren geeigneter Bildverarbeitungsalgorithmen.
Mit dem Scan-Line Verfahren (Kap. 2.2.1) und dem Marching-Cube-
Algorithmus (Kap. 2.2.2) wurden zwei weit verbreitete Vorgehensweisen umgesetzt und in
das Programm eingebaut.
Durch die Aufteilung des Ergebnisses in drei Programmteile wurde eine Verteilung der Aufgaben
erreicht, womit jeder Arbeitsschritt unabhängig von den anderen durchgeführt werden
kann. Die Bezeichnungen der Programmteile lauten:
• Farbpalette sortieren,
• Bilder segmentieren und
• DXF erstellen.
Jeder Arbeitsschritt liefert ein Zwischenergebnis, das zur weiteren Verarbeitung abgespeichert
wird. Die Veränderungen an der Farbpalette werden direkt in das Bild gespeichert.
Die Manipulationen an den Bildern, also die Schwellwerte und die Polygone, werden in eigenen
Dateien gespeichert, damit das Ausgangsbild nicht verändert wird. Die DXF-Dateien
gelten als Ergebnis der vorliegenden Arbeit und sind mit jedem 3D-fähigen Grafikprogramm
darstellbar.
65

66 KAPITEL 8. SCHLUSSBEMERKUNGEN
8.2 Verbesserungsmöglichkeiten
Das hier beschriebene Ergebnis kann nur ein erster Schritt in Richtung einer optimalen Visualisierung
von medizinischen Daten sein. Die Einarbeitung aller Feinheiten und wissenschaftlichen
Erkenntnissen würde wohl den Umfang dieser Arbeit sprengen. Vor allem ist
der Zeitaufwand für eine genaue Implementierung der Algorithmen und die Beachtung aller
möglichen Fälle nicht abzuschätzen. Die folgende Liste soll nur einen kurzen Überblick
darüber geben, wie das Ergebnis noch verbessert werden kann:
• Die Geräte zur Erzeugung von MR-Bildern unterliegen einer ständigen Verbesserung.
Neue und bessere Bilder bringen bessere Eingabewerte und ermöglichen eine genauere
Segmentierung der Augenmuskeln.
• Einige Teile der Implementierung der Algorithmen sind durchaus verbesserungswürdig.
So kann beispielsweise durch eine Optimierung der Würfelrotationen oder der Definition
der Dreiecke im Würfel eine Steigerung der Effizienz erreicht werden.
• Die Oberfläche des generierten Objektes besteht aus vielen Dreiecken, die oftmals in
der selben Ebene liegen. Eine Reduktion dieser Dreiecke bzw. eine Umwandlung in
andere geometrische Figuren, wie sie bereits in diversen Arbeiten ansatzweise beschrieben
wurde (z. B. in [Handels, 2000] oder in [Kaiser, 1999]), kann das Datenvolumen der
DXF-Datei erheblich vermindern.
Diese Arbeit stellt nicht den Anspruch auf eine perfekte Rekonstruktion von Augenmuskeln.
Die gestellten Anforderungen wurden allerdings erreicht. Die Darstellung erfolgt im dreidimensionalen
Raum und die Ergebnisse können in anderen Programmen weiterverarbeitet
werden.
8.3 Ausblick
Ein Programm, das auf den Ergebnissen dieser Arbeit aufbaut, ist in [Lacher, 2001] beschrieben.
Die DXF-Dateien werden von diesem Programm eingelesen und analysiert. Die spezielle
Aufgabe liegt nun darin, die Muskelpfade herauszufinden und anzuzeigen. Dies geschieht
mit verschiedensten mathematischen Analysevorgängen, die aus der erstellten Oberfläche die
Schwerpunkte ausrechnen und so auf einen Muskelpfad schließen lassen.
Weiters ist es möglich, zwei DXF-Dateien aus Bildfolgen zu generieren, in denen verschiedene
Blickpositionen dargestellt sind, damit die Veränderung des Muskels untersucht werden
kann. So wird das Zusammenziehen und die anschließende Entspannung von Muskeln am
Computer zu simuliert. Diese Erkenntnise wiederum sollen in weiterer Folge in das dynamische
Muskelmodell einfließen und eine originalgetreue Visualisierung der Muskelbewegung
ermöglichen.
Noch ist ein weiter Weg zurückzulegen, bis die Vision der vollständigen Darstellung aller
Augenmuskeln im System SEE++ Wirklichkeit wird. Die Erstellung des dynamischen Mo-

8.3. AUSBLICK 67
dells gestaltet sich als sehr schwierig, da jeder der sechs Augenmuskeln seine eigene Gesetzmäßigkeit
hat und diese nur schwer in Modellform zu bringen sind.
Bei Betrachtung der vielfältigen Möglichkeiten, die bildgebende Verfahren in der Medizin bieten,
kann die Idee geboren werden, pathologische Fälle auf Grund von MR-Untersuchungen
nachzustellen und so dem Arzt eine Grundlage für die Diagnose zu liefern bzw. eine genauere
Vorbereitung der Operation zu ermöglichen. Diese Vorgehensweise wird allerdings aus heutiger
Sicht eine Vision bleiben, weil die Generierung der Bilder zu aufwändig und kostenintensiv
ist. Die persönliche Erfahrung des Mediziners wird auch in Zukunft unbedingt notwendig
sein. Ein medizinisches Softwaresystem kann und darf nur eine Hilfestellung bieten.

68 KAPITEL 8. SCHLUSSBEMERKUNGEN

Anhang A
Quellcodebeispiele
A.1 Farbpalette setzen
Die veränderte Farbpalette steht im Datenfeld data[]. Diese wird nun Eintrag für Eintrag in
eine TLogPalette geschrieben und dann mittels CreatePalette() dem Bild zugeordnet.
Graphics::TBitmap * Palette::SetPalette()
{
typedef struct {
TLogPalette lPal;
TPaletteEntry dummy[PALETTE_MAX];
} LogPal;
}
LogPal SysPal;
SysPal.lPal.palVersion = 0x300;
SysPal.lPal.palNumEntries = PALETTE_MAX;
for (int i = 0; i < PALETTE_MAX; i++)
{
SysPal.lPal.palPalEntry[i] = data[i].entry;
}
pBitmap->Palette = CreatePalette(&SysPal.lPal);
return pBitmap;
69

70 ANHANG A. QUELLCODEBEISPIELE
A.2 Polygonaktionen
Die Interaktionen, die die Veränderung von Polygonpunkten bewirken, werden mit drei
” Mouse-Events” implementiert:
1. MouseDown, wenn eine Maustaste gedrückt wird,
2. MouseMove, wenn sich die Position des Mauszeigers ändert,
3. MouseUp, wenn eine Maustaste losgelassen wird.
Im folgenden Programmausschnitt muss ein aktuelles Polygon (actPol; Instanz der Klasse
MyPolygon) und ein aktuelles Bild (actPic; Instanz der Klasse Picture) definiert sein. Die
Methode Draw() aus der Klasse MyPolygon dient zum Zeichnen des gesamten Polygons auf
ein Canvas. Sie kann auch mit zwei neuen Koordinaten aufgerufen werden, dann wird das
bisherige Polygon mit einem neuen Punkt gezeichnet.
void TForm1::FormMouseDown(TObject *Sender, TMouseButton Button,
TShiftState Shift, int X, int Y)
{
// Wenn noch kein Polygon definiert, Abbruch
if(!actPol) return;
}
// Wenn -Taste gedrückt ist, neuen Punkt hinzugefügen
if (Shift.Contains(ssShift))
{
actPol->AddPoint(X, Y);
if(actPic) CopyCanvas(hideBmp);
if(actPol) actPol->Draw(paintBox->Canvas);
}
// Überprüfung, ob die aktuelle Mausposition mit einem Polygonpunkt
// übereinstimmt
// Falls ja, wird changeIndex ein Wert ungleich -1 zugewiesen
if (actPol) changeIndex=actPol->FindPoint(X, Y);
// Wenn die -Taste drückt ist, wird ein Punkt gelöscht
if (Shift.Contains(ssCtrl) && changeIndex != -1)
{
actPol->DeletePoint(changeIndex);
if(actPic) CopyCanvas(hideBmp);
if(actPol) actPol->Draw(paintBox->Canvas);
}

A.2. POLYGONAKTIONEN 71
//-------------------------------------------------------------------
void TForm1::FormMouseMove(TObject *Sender, TShiftState Shift,
int X, int Y)
{
// Wenn noch kein Polygon definiert, Abbruch
if(!actPol) return;
if (Shift.Contains(ssCtrl)) return;
// Wenn die -Taste gedrückt ist und die Maus bewegt wird,
// heißt das, dass gerade ein neuer Punkt gezeichnet wird.
// Der neue Punkt wird auf Plausibilität geprüft und gezeichnet.
if(Shift.Contains(ssShift))
{
pressed = true;
if(actPol->CheckPoint(X,Y))
{
if(actPic) CopyCanvas(hideBmp);
if(actPol) actPol->Draw(paintBox->Canvas, X,Y);
}
}
else
{
if (pressed)
{
pressed = false;
}
}
if(actPic) CopyCanvas(hideBmp);
if(actPol) actPol->Draw(paintBox->Canvas);
// Wird die Maus bewegt und die linke Maustaste gedrückt,
// wird möglicherweise ein Punkt verschoben.
// Dies ist dann der Fall, wenn changeIndex != -1 ist.
if(Shift.Contains(ssLeft))
{
if (changeIndex != -1)
{
actPol->ChangePoint(changeIndex, X, Y);
}
if(actPic) CopyCanvas(hideBmp);
if(actPol) actPol->Draw(paintBox->Canvas);

72 ANHANG A. QUELLCODEBEISPIELE
}
}
//-------------------------------------------------------------------
void TForm1::FormMouseUp(TObject *Sender, TMouseButton Button,
TShiftState Shift, int X, int Y)
{
// Wenn noch kein Polygon definiert, Abbruch
if(!actPol) return;
}
// Wird die Maustaste ausgelassen und der changeIndex
// ist ungleich -1, wird der veränderte Punkt gespeichert
if(Shift.Contains(ssLeft))
{
if (changeIndex != -1)
{
actPol->ChangePoint(changeIndex, X, Y);
changeIndex = -1;
}
}
if(actPic) CopyCanvas(hideBmp);
if(actPol) actPol->Draw(paintBox->Canvas);
A.3 Datenvolumen generieren
Zunächst werden die minimalen und maximalen Ausdehungen der Polygone ermittelt und
in den Variablen min und max (beides Variablen vom Typ POINT) abgespeichert. Danach
werden neue Pictures angelegt, deren Größe dem Bereich zwischen min und max entspricht.
Die Bildpunkte werden zunächst mit einem sicher falschen Wert (-1) initialisiert. Mithilfe
des Scan-Line Verfahrens werden jetzt die noch vorhandenen Bildpunkte in das neue Datenvolumen
kopiert, wobei GetNextPoint() solange den nächsten Punkt im Polygon liefert, bis
der y-Wert gleich -1 ist.
bool VolumeData::GenerateSubVolume()
{
POINT min,max;
MyPolygon *polygon;
Picture *pic, *sub_pic;
bool first=true;
POINT *p;

A.3. DATENVOLUMEN GENERIEREN 73
for (int i = 0; i < pics->Count; i++)
{
pic = (Picture*)pics->Items[i];
polygon = pic->GetPolygon();
}
for (int j = 0; jGetNumOfPoints(); j++)
{
p = (POINT*)polygon->GetPointList()->Items[j];
if (first)
{
min=max=*p;
first = false;
}
else
{
// Ist der Punkt p größer oder kleiner als min oder max,
// wird der entsprechende min- oder max-Wert berichtigt
if (p->x < min.x) min.x = p->x;
if (p->y < min.y) min.y = p->y;
if (p->x > max.x) max.x = p->x;
if (p->y > max.y) max.y = p->y;
}
}
// Die max-Werte werden um 1 erhöht und die min-Werte
// um 1 vermindert, damit auch die äußersten Polygone
// sicher in das neue Datenvolumen übernommen werden.
max.x++;
max.y++;
min.x--;
min.y--;
for (int i = 0; i < pics->Count; i++)
{
POINT point, helpPoint;
pic = (Picture*)pics->Items[i];
// Neues Bild erstellen; Bildpunkte mit -1 initialisieren;
// Threshold und Palette zuweisen
sub_pic = new Picture(max.x-min.x, max.y-min.y, -1);
sub_pic->SetThreshold(pic->GetThreshold());
sub_pic->SetPalette(pic->GetPalette());

74 ANHANG A. QUELLCODEBEISPIELE
}
// Scan-Line Verfahren initialisieren
PolygonFill *polFill = new PolygonFill(pic);
polFill->Init();
// Das Polygon mit dem Scan-Line Verfahren durchlaufen
// und die Bildpunkte in das neue Bild schreiben
polFill->GetNextPoint(point);
while (point.y != -1)
{
helpPoint.x = point.x - min.x;
helpPoint.y = point.y - min.y;
sub_pic->SetIndexForPixel(pic->GetIndexFromPixel(point), helpPoint);
polFill->GetNextPoint(point);
}
// neues Bild dem neuen Datenvolumen zuweisen
subVolume->Add(sub_pic);
}
return true;
A.4 Kantenschwellwert
Der Kantenschellwert wird für die Berechnung der genauen Punktposition benötigt. Dazu
werden die beiden Farbwerte der Eckpunkte der Kanten benötigt und ein Schwellwertbereich.
unsigned char VolumeData::GetEdgeThreshold(unsigned char color1,
unsigned char color2,
Threshold * thr)
{
if (color1 > thr->GetLowerBound())
{
if (color2 > thr->GetLowerBound()) return thr->GetUpperBound();
else return thr->GetLowerBound();
}
else return thr->GetLowerBound();
}

Anhang B
Screenshots
Abbildung B.1: Unterer Schwellwert
75

76 ANHANG B. SCREENSHOTS
Abbildung B.2: Unterer und oberer Schwellwert

Abbildung B.3: Oberer Schwellwert
77

78 ANHANG B. SCREENSHOTS

Anhang C
Glossar
A
Aequatorialebene: Ebene durch den Bulbusäquator
axial: In Richtung einer Achse; In dieser Arbeit beteutet axial immer entlang der Augenachse,
welche die Verbindungslinie zwischen vorderem und hinterem Augapfelpol
darstellt.
B
Bulbus: (Augapfel) Er ist annähernd kugelförmig und liegt geschützt in der Orbita. Er
besteht aus sklera (Lederhaut), choroidea (Aderhaut) und retina (Netzhaut).
Bulbusäquator: Der größte gedachte, senkrecht auf der Augenachse stehende Umfangskreis
des Augapfels in der Frontalebene
C
coronal: Parallel zur Frontalebene (Ebene entlang der Körperlängsachse senkrecht zur Sagittalebene).
D
DICOM: Digital Imaging and Communications in Medicine; Im DICOM-Format werden
neben den digitalen Bildern auch eine Fülle von bildbeschreibenden Daten (wie z. B.
Informationen zum Patienten, zur Untersuchung etc.) abgespeichert und es ist somit
das optimale Bildformat für medizinische Anwendungen.
DXF: Das ASCII Drawing Interchange Files-Format (DXF) wurde von der Firma Autodesk
entwickelt, um in das wohl verbreitetste PC-CAD-Programm, Auto-CAD, die Grafiken
anderer Programme einlesen zu können. DXF ist ein reines ASCII-Text-Format und
lässt sich mit jedem Editor herstellen und auch verändern.
79

80 ANHANG C. GLOSSAR
E
extraokuläre Augenmuskeln: (Äußere Augenmuskeln) Sie sind für die Bewegung des
Augapfels verantwortlich. Die vier geraden Augenmuskeln (musculi recti) und die zwei
schrägen Augenmuskeln (musculi obliqui) entspringen in der Augenhöhle und setzen
an der Lederhaut des Augapfels an.
K
kongenital: lat.: angeboren, d.h. bei der Geburt bereits vorhanden und erkennbar
Kontraktion: Die Muskelkontraktion (Zusammenziehung) ist eine durch direkte oder indirekte
Reizung des Muskels ausgelöste Verkürzung des Muskels.
M
Magnetresonanztomographie: Abk: MRT, MR-Tomographie, MR; Auch als Kernspintomographie
bekannt; Verfahren zur Erzeugung medizinischer Bilder mithilfe von Magnetfeldern.
Es entstehen Schnittbilder bestimmter Körperregionen, die sich durch
einen besonders hohen Weichteilkontrast auszeichnen.
MATLAB: MATLAB ist ein interaktives Programm für numerische Berechnungen und
für Datenvisualisierung. Zahlreiche Toolboxes erweitern die grundlegenden Funktionen
von MATLAB und bieten verschiedenste Applikationen an.
Motilitätsstörungen: Störung der Beweglichkeit der Augenmuskeln
musculi obliqui: Schräge Augenmuskeln
musculi recti: Gerade Augenmuskeln
musculus obliquus inferior: (m. obl. inf.) unterer schräger Augenmuskel; Wirkungsrichtung:
nach oben und innen
musculus obliquus superior: (m. obl. sup.) oberer schräger Augenmuskel; Wirkungsrichtung:
nach unten und außen
musculus rectus inferior: (m. rect. inf.) unterer gerader Augenmuskel; Wirkungsrichtung:
nach unten
musculus rectus lateralis: (m. rect. lat.) äußerer gerader Augenmuskel; Wirkungsrichtung:
seitwärts nach außen
musculus rectus medialis: (m. rect. med.) innerer gerader Augenmuskel; Wirkungsrichtung:
seitwärts nach innen
musculus rectus superior: (m. rect. sup.) oberer gerader Augenmuskel; Wirkungsrichtung:
nach oben

N
Nystagmus: (Augenzittern) Unwillkürliche, rhythmische Bewegungen des Auges
O
Orbita: (Augenhöhle) Vertiefung in den Schädelknochen. Beinhaltet den Augapfel und
seine Anhangsgebilde (Muskeln, Nerven, Gefäße, Tränenapparat, usw.)
P
Proband: Versuchsperosn, zu Untersuchender
R
Relaxation: Die Muskelrelaxation (Muskelerschlaffung) ist das im Anschluss an die Muskelkontraktion
erfolgende Nachlassen der Muskelverkürzung bis hin zur Ruhelänge.
S
sagittal: Parallel zur Sagittalebene (Ebene entlang der Körperlängsachse streng von hinten
nach vorn)
Schielen: (Strabismus) Eine Störung der Sensomotorik des Sehorgans mit der Unfähigkeit,
die Blicklinien beider Augen auf den gleichen Punkt zu richten
T
Trochlea: Am Stirnbein verankerter Knorpelring, durch den die Sehne des m. obl. sup.
verläuft
81

82 ANHANG C. GLOSSAR

Literatur
[Barré, 2001] S. Barré. Dicom2, A Free Medical Image and DICOM converter (in Englisch). [Website,
http://www.barre.nom.fr/medical/dicom2, zugegriffen am 23. August 2001], 2001.
[Brüder, 2001] Barmherzige Brüder. Konventhospital Barmherzige Brüder Linz, Sehschule. [Website,
http://www.barmherzige-brueder.at/bblinz/abt/seh.htm, zugegriffen am 31. Juli 2001], 2001.
[Brockhaus, 1989] Brockhaus. Naturwissenschaften und Technik. Brockhaus, Mannheim, Sonderausgabe,
1989.
[Brugger, 2000] P.C. Brugger. Der 3D Anatomie Atlas. Weltbild Verlag GmbH, Augsburg, Deutsche Erstausgabe,
2000.
[Buchberger und Mayr, 2000] M. Buchberger und H. Mayr. SEE-KID: Software Engineering Environment
for Knowledge-based Interactive Eye Motility Diagnostics (in Englisch). In Proceedings of International
Symposium on Telemedicine, Gothenburg, Sweden, 2000.
[Dössel, 2000] O. Dössel. Bildgebende Verfahren in der Medizin: Von der Technik zur medizinischen Anwendung.
Springer-Verlag Berlin Heidelberg, 2000.
[Günther, 1986] S. Günther. Die modellmäßige Beschreibung der Augenmuskelwirkung. Diplomarbeit, Universität
Hamburg, Universitätskrankenhaus-Eppendorf, Abteilung für medizinische Optik, 1986.
[Handels, 2000] H. Handels. Medizinische Bildverarbeitung. B.G. Teubner Stuttgart, Leipzig, 2000.
[Höhne, 2001] K. H. Höhne. Abteilung Informatik und Datenverarbeitung in der Medizin. [Website,
http://www.uke.uni-hamburg.de/idv, zugegriffen am 6. August 2001], 2001.
[Kaiser, 1999] K. Kaiser. Hardwareorientierte Schnittflächendarstellung und interaktive Objektmanipulation
mit OpenGL. Diplomarbeit, Fachbereich Informatik der Universität Hamburg, Juni 1999.
[Kaltofen, 2001] T. Kaltofen. Die Listing’sche Ebene aus mathematischer Sicht. Paper, FH-Studiengang
Software Engineering, Hagenberg, 2001.
[Kauffmann et al., 1996] G. Kauffmann, E. Moser, und R. Sauer. Radiologie, Grundlagen der Radiodiagnostik,
Radiotherapie und Nuklearmedizin. Urban und Schwarzenberg Verlag, München, 1996.
[Kaufmann, 1995] H. Kaufmann. Strabismus. Ferdinand Enke Verlag, Stuttgart, zweite, neu bearbeitete und
erweiterte Auflage, 1995.
[Lacher, 2001] M. Lacher. A Volume-Preserving Model for Biomechaically-Based Muscle Volume Deformation
(in Englisch). Diplomarbeit, FH-Studiengang Software Engineering, Hagenberg, 2001.
[Lehmann et al., 1997] T. Lehmann, W. Oberschelp, E. Pelikan, und R. Repges. Bildverarbeitung für die
Medizin. Springer-Verlag, Berlin, Heidelberg, 1997.
[Lehner, 2001] G. Lehner. Augenmuskelwirkung - Ein allgemeiner Abriss. Paper, FH-Studiengang Software
Engineering, Hagenberg, 2001.
[Lorensen und Cline, 1987] W. E. Lorensen und H. E. Cline. Marching Cubes: A High Resolution 3D Surface
Construction Algorithm (in Englisch). Computer Graphics, 21(4):163–169, 1987.
[Miller und Demer, 1996] J.M. Miller und J.L. Demer. Uses of Biomechanical Modeling (in Englisch). In
Proceedings of CLADE, Buenos Aires, 1996.
[Miller, 1999] J. M. Miller. Gaze Mechanics Simulation (in Englisch). User Manual, Eidactics Visual Biosimulation,
San Francisco, USA, 1999.
83

84 LITERATUR
[Miller, 2001] J. M. Miller. Eidactics Visual Biosimulation (in Englisch). [Website, http://www.eidactics.com,
zugegriffen am 3. August 2001], 2001.
[Morneburg, 1995] H. Morneburg. Bildgebende Systeme für die medizinische Diagnostik. Publicis-MCD-
Verlag, München, 3., wesentlich überarb. und erw. Auflage, 1995.
[Pavladis, 1990] T. Pavladis. Algorithmen zur Grafik und Bildverarbeitung. Verlag Heinz Heise GmbH & Co.
KG, Hannover, 1990.
[Pohl und Eriksdottar, 1991] M. Pohl und H. Eriksdottar. Die wunderbare Welt der Grafikformate. Wolfram’s
Fachverlag, München, 1991.
[Pschyrembel, 1994] Pschyrembel. Klinisches Wörterbuch. Nikol Verlagsgesellschaft mbH, Hamburg, 257.
Auflage, 1994.
[Reisinger, 2001] R. Reisinger. Messmethoden bei Strabismus - am Beispiel des Hess-Diagramms. Paper,
FH-Studiengang Software Engineering, Hagenberg, 2001.
[Roche, 1999] Roche. Lexikon Medizin. Urban und Schwarzenberg Verlag, München, 4., neubearb. und erw.
Auflage, 1999.
[Schäffler und Schmidt, 1998] A. Schäffler und S. Schmidt. Biologie, Anatomie und Physiologie. Urban und
Fischer Verlag, München, 3., erweiterte Auflage, 1998.
[Sedgewick, 1997] R. Sedgewick. Algorithmen in C. Verlag Addison-Wesley, Bonn, 2., unveränderter Nachdruck
Auflage, 1997.
[Tiede, 1999a] M. K. Tiede. MRI Tooblox - A MATLAB-based system for manipulation of MRI data (in
Englisch). Technical Report, ATR Human Information Processing Laboratories, Kyoto, Japan, 1999.
[Tiede, 1999b] U. Tiede. Realistische 3D-Visualisierung multiattributierter und multiparametrischer Volumendaten.
Dissertation, Fachbereich Informatik der Universität Hamburg, 1999.
[Vornberger et al., 1997] O. Vornberger, F. M. Thiesing, und F. Lohmeyer. Computergrafik. Vorlesungsunterlagen,
Fachbereich Mathematik/Informatik, Universität Osnabrück, 1997.