Technical Report 153 / 2004 Entwicklung eines 3D ... - Dkfz

mbi
Technical Report
153/2004
Entwicklung eines 3D-Visualisierungstools für medizinische Bilddaten
-Redesign, Funktionserweiterung und Integration in das
Teleradiologiesystem CHILI-
Deutsches Krebsforschungszentrum Heidelberg
Abteilung Medizinische und Biologische Informatik
Christian Sonek
28.01.2004

Inhaltsverzeichnis
1 Einleitung 1
1.1 Aufbau der Arbeit.................................................2
2 Problembeschreibung 5
2.1 Beschreibung des Workflows der Operationsplanung ................. 6
2.1.1 Akteure der Leberoperationsplanung. .................................6
2.1.2 Stationen der Leberoperationsplanung . ............................... 7
3 Grundlagen 9
3.1 Medizinische Grundlagen .......................................... 9
3.1.1 Die Leber . .......................................................... 9
3.1.2 Leberkrebs . ........................................................10
3.1.3 Bildgebende Verfahren in der Medizin ............................... 11
3.1.4 Medizinische Bildformate ........................................... 15
3.1.5 PIC-Format ........................................................ 18
3.1.6 Segmentierung ..................................................... 19
3.2 Medizinische Bildverarbeitung. ....................................20
3.2.1 Bildverarbeitungsoperationen........................................20
3.3 Visualisierungstechniken . ......................................... 22
3.3.1 Graphikprogrammierung ............................................ 22
3.3.2 Volumendarstellung.................................................28
3.3.3 Beschreibung der OpenGL Visualisierungs-Schnittstelle ............... 30
3.3.4 Visualization Toolkit (VTK) ........................................ 32
3.3.5 Die VTK Visualisierungs-Pipeline....................................33
3.3.6 VRML.............................................................36
3.4 Grundlagen der Informatik ........................................ 37
3.4.1 Software-Engineering ............................................... 37
i

Inhaltsverzeichnis
3.4.2 Die Klassenbibliothek Qt............................................42
4 Stand der Technik 45
4.1 Der Organicer Prototyp .......................................... 45
4.1.1 Die SceneHandler-Bibliothek ........................................ 45
4.1.2 Einteilung eines Gefäßbaumes ....................................... 47
4.1.3 Workflow Leberoperationsplanung . .................................. 49
4.2 Andere Systeme. .................................................50
4.3 Das Teleradiologiesystem CHILI...................................52
4.3.1 Aufbau des Teleradiologisystems CHILI . ............................. 52
5 Praktische Realisierung 55
ii
5.1 Ist-Analyse ...................................................... 55
5.1.1 Datentransfer ...................................................... 55
5.1.2 Bildverarbeitung....................................................56
5.1.3 Programmstruktur..................................................56
5.2 Soll-Konzept. ....................................................57
5.2.1 Datentransfer ...................................................... 57
5.2.2 Bildverarbeitung....................................................57
5.2.3 Programmstruktur..................................................57
5.2.4 Funktionserweiterung ............................................... 58
5.3 Einsatz der Entwurfsmuster.......................................58
5.3.1 Model-View-Controller..............................................58
5.3.2 Strategiemuster .................................................... 59
5.4 Datenhaltung .................................................... 60
5.4.1 Die Datenelemente der Visualisierung................................60
5.4.2 Zentrale Verwaltung der Daten......................................62
5.4.3 Kapselung der I/O-Funktionalität in Klassen ......................... 63
5.4.4 Das Dateiformat der Szenenbeschreibung . ........................... 65
5.5 Aufbau der graphischen Benutzeroberfläche. .......................69
5.6 Neugestaltung der Materialverwaltung.............................70
5.6.1 Viewproperty Klasse................................................ 70
5.6.2 DataListView ...................................................... 70

Inhaltsverzeichnis
5.7 Berechnung der Distanz zwischen Tumor und Gefäßen ............. 73
5.8 Exportieren von VRML-Szenen....................................75
5.9 Entwicklung PlugIn-Adapterklasse.................................77
5.9.1 Die Adapterklasse OrganicerPluginFrame ............................ 78
5.9.2 Datenbankabfragen der Adapterklasse ............................... 81
5.9.3 Die Imageklassen. ..................................................82
5.9.4 Informationen über Schichtbilder .................................... 82
6 Zusammenfassung der Diplomarbeit 89
7 Ausblick 93
7.1 Ablösung des Altsystems ......................................... 93
7.1.1 Ausbau der Visualisierungsplattform CHILI. ..........................93
7.2 Das Visualisierungsframework MITK .............................. 94
7.3 Neue Einsatzgebiete des Organicers . .............................. 95
7.4 Schlusswort......................................................95
Tabellenverzeichnis 97
A Listings 99
A.1 Listing zum Aufbau eines VTK-Datasets...........................99
A.2 Listing Mediator - Datenhaltung ................................. 100
A.3 Update Mechanismus der Datenansicht .......................... 103
A.4 Oberflächemodell erzeugen . ..................................... 104
A.5 Datenbankabfrage der Adapterklasse . ............................ 106
Literaturverzeichnis 109
Abbildungsverzeichnis 111
1.6 Glossar ......................................................... 114
Index 117
iii

Inhaltsverzeichnis
iv

1 Einleitung
Die fortschreitende technische Entwicklung und das Ziel, die interdisziplinäre Zusammenar-
beit in der Medizin zu verbessern, stellt hohe Anforderungen an die verschiedenen medizi-
nischen Berufsgruppen. Dies liegt auch an der steigenden Komplexität und Vielfalt medizi-
nischen Wissens, durch den der Austausch von Informationen immer wichtiger wird. Dazu
müssen Systeme entwickelt werden, die diesen Kommunikationsprozess ermöglichen und
mit den informationserzeugenden Produkten zusammenarbeiten. Neben der Bereitstellung
geeigneter Produkte in der apparativen Medizin, müssen aber auch die Arbeitsabläufe der
beteiligten Gruppen optimiert werden. Die medizinische Bildverarbeitung hat dabei die Auf-
gabe die Auswertung der medizinischen Bilddaten und ihre Verfügbarkeit zu verbessern.
Bilder dienen in weiten Bereichen der Medizin als primäre Informationsquelle und daher
sind viele Untersuchungsmethoden bildgebende Verfahren. Menschliche Organe und Ge-
webe variieren in ihrem Erscheinungsbild und besitzen bei pathologischen Veränderungen
unterschiedliche Ausprägungen. Deshalb ist es wichtig über Bilddaten Informationen zu er-
halten, die der Diagnosefindung dienen und zur Planung und Durchführung medizinischer
Maßnahmen beitragen.
Mit Methoden der medizinischen Bildverarbeitung wird die Interpretation der Bilder un-
terstützt bzw. verbessert. Medizinische Schichtbilder, wie sie bei der Computertomogra-
phie (CT) oder der Magnetresonanztomographie (MR) erzeugt werden, bieten eine zweidi-
mensionale Ansicht eines dreidimensionalen Objektes. Um aus diesen Daten Informationen
(z.b. Lage, Volumen, Form) zu erhalten benötigt ein Arzt ein gut ausgeprägtes räumli-
ches Vorstellungsvermögen. Rechnergestützte Verfahren erleichtern die Auswertung dieser
Bilddaten durch die Bereitstellung geeigneter Visualisierungsmethoden, die als Ergebnisse
3D-Rekonstuktionen bieten.
Im Mittelpunkt dieser Diplomarbeit steht ein Prototyp eines 3D-Visualisierungstools, der
Organicer, mit dem Operationsplanungen durchgeführt werden. Diese Operationsplanungen
sollen nach einem Redesign und einer Funktionserweiterung innerhalb eines Teleradiologie-
1

KAPITEL 1. EINLEITUNG
systems durchgeführt werden. Dabei soll ein Softwareprodukt einstehen, dass sich durch
eine modulare, erweiterbare und flexible Struktur auszeichnet.
1.1 Aufbau der Arbeit
Diese Diplomarbeit ist in verschiedene Kapitel unterteilt. Die einzelnen Kapitel bauen aufein-
ander auf und geben nach der Problembeschreibung, einen Überblick über die zum weiteren
Verständnis benötigten Grundlagen, bevor die Realisierungsmaßnahmen vorgestellt werden.
◮ Die Problembeschreibung in Kapitel 2 gibt einen Überblick über das Einsatzgebiet
des Organicers und den, an einer Operationsplanung, beteiligten medizinischen Fach-
gruppen.
◮ Zum Verständnis der Realisierungsmaßnahmen dienen die, in Kapitel 3 in Abschnitte
aufgeteilten, Grundlagen. Aus den medizinischen Grundlagen ergibt sich die spezielle
Funktionalität des Organicers. Danach werden Verfahren vorgestellt, mit denen me-
dizinische Bilder erzeugt, verarbeitet und gespeichert werden können. Der Visualisie-
rungsabschnitt zeigt wie diese Bilder mit verschiedenen Methoden dargestellt werden
können. Der nächste Abschnitt stellt allgemeine Prinzipien des Softwareengineering
vor, die durch den Einsatz von Entwurfsmustern zu flexiblen, modularen und erweiter-
baren Programmstrukturen umgesetzt werden können. Am Ende dieses Kapitels wird
die Klassenbibliothek Qt beschrieben, die die Implementierung des Organicers als
plattformunabhängiges Programm ermöglicht.
◮ Die beiden Programme Organicer und das Teleradiologiesystem CHILI bilden die Grund-
lage der Realisierungsmaßnahmen. Deshalb werden diese beiden eigenständigen Pro-
gramme im Kapitel 4 vorgestellt. Darüber hinaus wird der Workflow, der Operati-
onsplanungen beschrieben und in einem weiteren Abschnitt mit anderen Systemen
verglichen.
◮ Das Kapitel 5 listet in einer Ist-Analyse zuerst die Mängel des Organicers auf, bevor
2
es im Soll-Konzept die Realisierungsmaßnahmen beschreibt. In einzelnen Abschnit-
ten werden die entwickelten Konzepte der Datenhaltung und Materialverwaltung, die
Funktionserweiterungen der Distanzmessung und die Konvertierung von Szenen in
das internetfähige VRML-Format beschrieben. Der letzte Abschnitt zeigt, wie mit der

1.1. AUFBAU DER ARBEIT
Entwicklung einer PlugIn-Schnittstelle, die Funktionalität des Organicers im Telera-
diologiesystem zur Verfügung gestellt wird.
◮ In Kapitel 6 werden in einer Zusammenfassung die Ergebnisse diskutiert, bevor ein
Ausblick in Kapitel 7 mit der Beschreibung der geplanten bzw. möglichen Entwick-
lungen, diese Arbeit abschließt.
3

KAPITEL 1. EINLEITUNG
4

2 Problembeschreibung
In der Abteilung Medizinische und Biologische Informatik (MBI) des Deutschen Krebsfor-
schungszentrum (DKFZ) in Heidelberg wurde der Prototyp eines 3D-Visualisierungstools
für Segmentierungsergenisse, der OrganNicer, entwickelt. Dieses Tool wurde für den Ein-
satz in der Planung von Leberoperationen konzipiert, kann aber auch in anderen Bereichen
wie Nieren-, Herz- und Lungenchirurgie eingesetzt werden.
Die ständige Weiterentwicklung in der medizinischen Bildverarbeitung und der kliniknahe
Einsatz stellen an ein Softwareprodukt hohe Anforderungen. Um diese zu Erfüllen muß das
Softwaredesign insbesondere den Qualitätskriterien Benutzerfreundlichkeit, Erweiterbarkeit
und Wiederverwendbarkeit genügen. Dies erfordert eine systematische und ingenieursmäßige
Software-Entwicklung. Eine objektorientierte Programmmierung stellt dazu die geeigneten
Methoden und Werkzeuge zur Verfügung und kann durch den Einsatz von Entwurfsmustern
(Kapitel 3.4.1), aus den Erfahrungen in der Softwareentwicklung profitieren.
Zur Optimierung des Workflows einer Operationsplanung muß das Zusammenspiel der zur
Bildverarbeitung eingesetzten Tools (Abschnitt 2.4) und der Austausch der gewonnenen
Bilddaten 2.1.2 verbessert werden.
Das Teleradiologiesystem CHILI (siehe )bietet hier eine geeignete Plattform, da es
einen sicheren Datentransfer und durch seine Datenbankanbindung die Verwaltung der Bild-
daten ermöglicht. Darüberhinaus verfügt es über ein ein PlugIn-Konzept, dass die Integration
eines Segmentierungsprogrammes erlaubt und damit die zur Visualisierung benötigten Seg-
mentierungsergebnisse anbieten kann. Um diese allerdings effektiv nutzen zu können, muss
auch das Visualisierungstool als PlugIn integriert werden.
Das Internet, ist die am weitesten verbreitete Kommunikationsplattform. Deshalb arbeitet
die Abteilung MBI des DKFZ an einem webbasierten System zum Austausch von Infor-
mationen, mit dem auch die Kommunikation zwischen der Radiologie und Chirurgie der
Universitätsklinik Heidelberg und der MBI-Abteilung verbessert werden soll.
5

KAPITEL 2. PROBLEMBESCHREIBUNG
2.1 Beschreibung des Workflows der Operationsplanung
2.1.1 Akteure der Leberoperationsplanung
Die Patienten werden in der Chirurgie angemeldet und nach einer Aufnahmeuntersuchung,
zur Bilderzeugung in die Radiologie geschickt. Der Radiologe schickt die gewonnenen Bildda-
ten mit dem Teleradiologiesystem CHILI zur Bearbeitung ins DKFZ. Nach der Aufbereitung
der Bilder durch einen Mitarbeiter des DKFZ, werden die Ergebnisse durch den Radiologen
begutachtet und bei einer positiven Validierung freigegeben.
6
Chirurg
DKFZ-
Mitarbeiter
Patient aufnehmen
Bilder erzeugen
Bilder versenden
Bilder verarbeiten
3D-Rekonstrukionen
validieren
3D-Rekonstruktionen
präsentieren
3D-Rekonstruktionen
interpretieren
Abbildung 2.1: Anwendungsfälle
Operationsplanung
Radiologe
Der DKFZ-Mitarbeiter präsentiert die
3D-Rekonstruktionen bei einer Bespre-
chung dem Radiologen und Chirurgen,
welche diese 3D-Modelle interpretieren
und als Unterstützung der Diagnosefin-
dung und Therapieplanung nutzen. Bei
dieser Besprechung wird auch entschie-
den, ob der DKFZ-Mitarbeiter die 3D-
Visualisierungen während der Operation
zur Unterstützung des chirurgischen Ein-
griffs präsentieren soll.

2.1. BESCHREIBUNG DES WORKFLOWS DER OPERATIONSPLANUNG
Die Abbildung 2.2 zeigt den Zeitverlauf in den die beschriebenen Anwendungsfälle einge-
ordnet sind. Durch die Anhäufung der Anwendungsfälle am 1. Tag wird deutlich, wie wichtig
ein kurzer Zeitaufwand bei der Durchführung einer 3D-Rekonstruktion, für die Integration
des Organicers in den klinischen Alltag ist.
Patientenanmeldung
Bilderzeugung
Bildtransfer
Bildsegmentierung
Segmentierungsergenisse
validieren
Volumen auswerten
validieren
3D-Rekonstruktion
erstellen
Operation
1. Tag 2. Tag
Abbildung 2.2: Zeitplan der Leberoperationsplanung
2.1.2 Stationen der Leberoperationsplanung
Mini
Pacs
Radiologie MBI-Abteilung
CHILI
Firewall
Firewall
CHILI
CHILI
DB
Abbildung 2.3: Datenaustausch
Operationsplaung
Lokaler
Fileserver
Die Abbildung 2.3 zeigt den Weg der Bilddaten bei einer Operationsplanung. Ausgangs-
punkt ist ein bilderzeugendes Gerät in der Radiologie, das die gewonnenen Bilder in einem
Mini-Pacs speichert. Die Radiologie verfügt über ein CHILI-Teleradiologiesystem, mit dem
die Daten zum CHILI-Server der MBI-Abteilung transferiert werden und in der dortigen
CHILI-Datenbank gespeichert werden.
Laptop
7

KAPITEL 2. PROBLEMBESCHREIBUNG
8
Daten empfangen und speichern
Daten segmentieren
Gefäßbäume segmentieren
Gefäßbäume bearbeiten
Lebersegmente berechnen
Oberflächenmodelle erstellen
3D-Szene darstellen
Abbildung 2.4: Aktivitäten der
Operationsplanung
Der Workflow der Operationsplanung beginnt mit
dem Laden eines Segmentierungs-PlugIns, im Te-
leradiologiesystem CHILI. Nach der Auswahl ei-
ner Serie, wird eine zweite Serie angelegt, in der
die Segmentierungsergebnisse, nach der Bearbei-
tung gespeichert werden. Um die Daten weiter
bearbeiten zu können, müssen diese auf einen lo-
kalen Fileserver exportiert werden. Zur Segmen-
tierung der Gefäßbäume wird mit einem spezi-
ellen Tool durchgeführt und bildet die Grundla-
ge für die nachfolgenden Aktivitäten. Nach dem
Abspeichern, der erhaltenen Ergebnisse in einem,
für diese Zwecke bestimmten Dateiformat, kann
der Organicer diese Datei laden. Nach dem Laden
eines neuen Gefäßbaumes wird dieser einheitlich
dargestellt und muss in verschiedene Gefäßberei-
che (portal,venös,arteriell) eingeteilt werden. Bei
der weiteren Einteilung werden die Gefäßberei-
che in Äste aufgeteilt, die jeweils autonome Ver-
sorgungsgebiete repräsentieren. Nach der Eintei-
lung in autonome Versorgungsgebiete, kann mit
einem speziellen Tool eine Einteilung der Leber in
Segmente durchgeführt werden. Diese Segmen-
te werden durch ein PIC-Volumen repräsentiert
(siehe Kapitel 3.1.5) und können jetzt in STL-
Oberflächenmodelle umgewandelt werden. Erst
jetzt sind alle Elemente, die zur Darstellung einer
Szene im Organicer benötigt werden, vorhanden
und können geladen und visualisiert werden.

3.1 Medizinische Grundlagen
3.1.1 Die Leber
Anatomie der Leber
3 Grundlagen
Da der Anatomische Aufbau der Leber und insbesondere der Verlauf der Gefäße, für eine
Leberoperation von zentraler Bedeutung sind, gibt dieser Abschnitt einen Überblick über
die für eine Operationsplanung wichtigen Strukturen.
Die Leber ist das zentrale Stoffwechselorgan und mit etwa 1,5 kg, die größte Drüse des
menschlichen Körpers. Sie liegt größtenteils im rechten Oberbauch und ihre konvexe Ober-
fläche ist mit dem Zwerchfell verwachsen.
Funktionen der Leber
Die wichtigsten Aufgaben der Leber sind nach :
• Die Produktion von Galle zur Fettverdauung
• Die Ausscheidung von Bilirubin und Toxinen
• Ihre zentrale Rolle im Kohlehydrat-, Lipid-, Eiweiß- und Hormonstoffwechsel
Die Leber wird in in einen größeren rechten (Lobus dexter) und einen kleineren
linken (Lobus sinister) Lappen unterteilt, deren Trennungslinie nicht durch das Verzwei-
gungsmuster der Lebergefäße bestimmt wird.
Die Pfortader führt der Leber nicht nur das venöse Blut mit aus dem Darm resorbierten
Substanzen zu, sondern bestimmt auch die in Abschnitt 3.1.1 beschriebene Einteilung der
Leber. Durch die Leberaterie wird der Leber sauerstoffreiches Blut zugeführt. Diese beiden
Gefäße zweigen sich solange auf, bis sie auf mikroskopischer Ebene, den Leberläppchen
Blut zuführen. Dabei verläuft im Normalfall die Arterie über weite Strecken entlang der
Pfortader. In den Leberläppchen wird nach der Durchführung der Leberfunktionen, das Blut
9

KAPITEL 3. GRUNDLAGEN
gesammelt und über die drei großen Lebervenen (Vv. hepaticae), in die untere Hohlvene
(Vena cava inferior) abgeleitet.
Segmenteineilung der Leber
Lebervenen
Gallenblase
Gallengang
Pfortader
Hohlvene
Leberarterie
Abbildung 3.1: Segmenteinteilung der Leber nach Couinaud (aus )
Die Abbildung 3.1 zeigt die sich durch die Verzweigungsstruktur der Pfortader ergebende,
Segmenteinteilung der Leber. Jedes dieser Segmente besitzt eine eigene Blutversorgung und
bildet eine autonome Einheit. Auch die Venen teilen die Leber in unabhängige Gebiete auf.
3.1.2 Leberkrebs
Lebertumore kann man in verschiedene Arten aufteilen (nach ):
◮ Benigne Tumore sind gutartige Blutgefäßtumore
◮ Primäre maligne Lebertumore sind bösartige Tumore die ohne Einfluss anderer Tumore
10
innerhalb der Leber entstehen. Das Leberzellkarzinom (HCC) ist mit einem Anteil von
90% der wichtigste Vertreter dieser Art. Am Häufigsten tritt diese Art in afrikanischen
Ländern südlich der Sahara (bei etwa 150 von 100.000 Menschen) auf, während sie in
Europa und Nordamerika deutlich seltener (1 bis 4 von 100.000 Menschen) vorkommt.

3.1. MEDIZINISCHE GRUNDLAGEN
◮ Sekundäre maligne Lebertumore enstehen als Metastasen primärer Karzinome anderer
Körperteile. Die Primären Tumore sind dabei häufig im Darm, der Gallenblase oder
in der Bauchspeicheldrüse angesiedelt.
3.1.3 Bildgebende Verfahren in der Medizin
In diesem Abschnitt werden die wichtigsten Verfahren der medizinischen Bildgewinnung vor-
gestellt. Ein Bildaufnahmegerät mit seinen Komponenten wird in der Radiologie als Modali-
tät bezeichnet. Diese nutzen zur Bildgewinnung die Wechselwirkung der Körpersubstanzen
mit ionisierenden Strahlen, Magnetfeldern oder Ultraschallwellen aus. Die in diesem Ab-
schnitt vorgestellten Modalitäten stellen die erzeugten Bilddaten zur Diagnostik und digita-
len Weiterverarbeitung zur Verfügung. Dabei unterscheiden sich die von den verschiedenen
Bildaufnahmegeräte erzeugten Bilder in Auflösung, Farbtiefe und Interpretation.
Computertomographie
Die Computertomographie ist eine computergestützte Röntgenuntersuchung, die den
menschlichen Körper in Querschnittbildern dargestellt. Dazu werden Röntgenstrahlen er-
zeugt, die sich beim Durchdringen des Körpers, proportional zur Dichte des Gewebes, ab-
schwächen.
Abbildung 3.2: Dichteskala nach Hounsfield
11

KAPITEL 3. GRUNDLAGEN
Zur Gewinnung eines Bildes wird der Körper in kleine Volumenelemente aufgeteilt, für die
ein Computer Abschwächungswerte berechnet und anschließend aus den Ergebnissen ein
Schichtbild aufbaut.
Die in Abbildung 3.2 dargestellte Skala zeigt die Zuordnung der Dichtewerte, zu den einzel-
nen Organen, nach Hounsfield. Für jedes Volumenelement (Voxel) wird ein Intensitätswert
errechnet, der den Schwächungskoeffizienten des Volumenelementes gegenüber der ver-
wendeten Röntgenstrahlung charakterisiert (siehe ). Die erhaltenen Ergebnisse
werden relativ zur Dichte von destilliertem Wasser angegeben. Zur Bilderzeugung werden
den Schwächungskoeffizienten Graustufenwerte zugeordnet.
Röntgenröhre
Patient
Detektoren
Abbildung 3.3: Schema Computertomographie
(Quelle: )
Die Abbildung 3.3 zeigt schematisch die
Funktionsweise eine CT-Gerätes. Dabei
rotiert eine Röntgenröhre um den Körper
des Patienten und erzeugt viele Einzelauf-
nahmen, aus denen ein zweidimensiona-
len Einzelbild berechnet werden kann. Der
Tisch auf dem der Patient liegt wird wäh-
rend der Aufnahme in Längsrichtung ver-
schoben , wodurch der Reihe nach Quer-
schnittbilder der untersuchten Region an-
gefertigt werden.
Die CT-Untesuchung im Rahmen einer
Leberoperationsplanung kann man in drei
Phasen unterteilen:
1. In der nativen Phase wird eine Aufnahme der Anatomie der Leber ohne Kontrastmittel
gemacht.
2. Das Kontrastmittel gelangt mit dem Blut über die Venen zu den Arterien und verstärkt
in der arteriellen Phase dort den Kontrast.
3. Nach einer intravenösen Injektion von Kontrastmittel reichert sich das Kontrastmittel
in stark mit Blut versorgten Bereichen, wie Gefäßen und Tumoren, an. In der venösen
Phase sind dabei die Lebervenen gut zu erkennen.
Die Bilder haben meist eine Auflösung von 512x512 Pixel mit 12 Bit Graustufen, so dass
sich eine Größe von 512 KB ergibt. Die Anzahl der Einzelbilder einer CT-Serie richtet sich
12

3.1. MEDIZINISCHE GRUNDLAGEN
nach Größe des untersuchten Organs und dem gewählten Schichtabstand der Bilder.
Magnetresonanztomographie (MRT)
Die Magnetresonanztomographie ist ein indirektes Verfahren der Bilderzeugung, bei dem
Atome, durch ein starkes Magnetfeld und Hochfrequenzimpulse (Radiowellen), abgelenkt
werden und der Rückkehrimpuls zur Bilderzeugung genutzt. Dabei handelt es sich um Atom-
kerne mit einen Eigendrehimpuls, womit sie ein magnetisches Dipolmoment besitzen. Für die
medizinische Bildgebung interessant ist vor allem das Wasserstoffatom, da dieses sehr häufig
in gebundener Form im Gewebe vorkommt. Beim Anlegen eines starken Magnetfeldes rich-
ten sich Atome mit einem magnetischen Dipolmoment entlang der Hauptmagnetfeldachse
aus und begeben sich auf eine Kreisbahn um diese Achse. Dabei können die Atome in einem
energiearmen (parallelen) oder in einem energiereichen (antiparallelen) Zustand vorliegen.
Nach dem Anlegen starker Hochfrequenzimpulse kann man zwei Phänome beobachten:
◮ Durch die Überführung einiger Atome vom energieärmeren in den energiereichen Zu-
stand wird die Magnetisierung längs der Haupmagnetfeldachse reduziert.
◮ Alle Atome auf ihrer Kreisbahn um die Hauptmagnetachse werden synchronisiert. Dabei
ensteht ein quer zur Haupmagnetfeldachse liegendes Magnetfeld.
Nach dem Aufheben des Hochfrequenzsignals wird mit zwei Zeitkonstanten die Rückkehr
zum Ausgangszustand beschrieben. Die T1-Konstante beschreibt dabei die Geschwindigkeit
der Wiederzunahme der Längsmagnetisierung, während die T2-Konstante die Abnahme der
Quermagnetisierung festhält. Diese Relaxationszeiten sind unveränderliche Naturkonstan-
ten und können mit Empfangsspulen gemessen und zur Differenzierung der verschiedenen
Gewebearten genutzt werden.
Zur Bilderzeugung müssen diese Phänomene durch Anlegen ortsabhängiger Magnetfelder
einzelnen Bildpunkten durch Graustufen zugeordnet werden. Durch die MRT kann man
den medizinisch relevanten Gewebearten charakteristische Wertebereiche zuordnen, die sich
hauptsächlich aus der chemischen Zusammensetzung des Gewebes ergeben. Damit können
gegenüber der CT oder dem Ultraschall auch Gewebe mit gleicher Dichte unterschieden
werden.
Eine ausführliche Beschreibung der physikalischen Eigenschaften der MRT findet sich bei-
spielsweise in oder .
13

KAPITEL 3. GRUNDLAGEN
Axial
Sagital
Abbildung 3.4: Schichteinstellung MRT
Coronar
Radiologische Untersuchung von Gefäßen
Ein weiterer Vorteil der MRT ist in der Ab-
bildung 3.4 abgebildet. Durch die Mög-
lichkeit Schnittebenen in frei wählbarer
Richtung anfertigen zu können, ist es so-
gar möglich das Rückenmark in seiner
Längsausdehnung darzustellen.
Die Bildgröße eines mit der MRT er-
zeugten Graustufenbildes beträgt meist
512x512 Pixel mit 12 Bit Graustufentie-
Es gibt in der Medizin viele Bereiche, in denen die Untersuchung der Blutversorgung von
Organen oder Körperteilen eine zentrale Bedeutung besitzt. Den Kardiologen interessiert
z.B. die Durchblutung der Herzkranzgefäße und der Neurologe möchte nach einem Schlag-
anfall wissen, welche Teile des Gehirns nicht mehr mit Blut versorgt werden. Dabei können
die benötigten Bilddaten mit unterschiedlichen Verfahren aufgenommen werden.
14
• Bei der konventionellen Angiographie wird dem Patienten ein strahlensabsorbierendes
Kontrastmittel verabreicht, wodurch die Gefäße bei einer Röntgenuntersuchung durch
einen erhöhten Kontrast sichtbar werden.
• Mit der computertomographischen Angiographie (CTA) kann man Gefäße dreidimen-
sional darstellen. Dabei ist es schwierig, den richtigen Zeitpunkt zum Start einer
solchen Untersuchung zu bestimmen, da der Zeitpunkt, in dem das Kontrastmittel
die interessanten Gewebe passiert, nicht exakt vorhersehbar ist.
• Durch die Magnetresonanzangiographie (MRA) ist es möglich physiologische Bewe-
gungen innerhalb der Gefäße aufzunehmen. Die MRA nutzt den Blutfluss, um sowohl
fe.

Ultraschall
3.1. MEDIZINISCHE GRUNDLAGEN
morphologische als auch quantitative Darstellungen der vaskulären Anatomie aufzu-
nehmen ().
Schallkopf Bauchhaut
Leber
Signal/Echo
Abbildung 3.5: Schema Ultraschall
Die Ultraschalldiagnose ist das bildgeben-
de Verfahren mit der geringsten Belastung
für den Patienten und gilt als Basisuntersu-
chung für Erkrankungen der abdominalen
Organe. Sie ermöglicht bei einer Untersu-
chung der Leber keine sichere Identifizie-
rung der gefundenen Strukturen. Bei der
Sonographie sendet ein Schallkopf Schall-
wellen aus, die durch das Anlegen eines
Stromes erzeugt werden und gewebespezifisch absorbiert, gebrochen, gestreut oder reflek-
tiert werden. Aus den Reflektionen ergibt sich ein Diese Schallwellen werden durch Anlegen
eines Stromes an Kristalle erzeugt. Daraus ergibt sich ein Schwächungsbild mit sehr weichen
verschwommenen Konturen. Nach der Überlagerung mehrerer solcher, in gleicher Ausrich-
tung erfasster Bilder, erhält man ein Schnittbild mit schärferen Konturen. Ultraschallbilder
besitzen üblicherweise eine Farbtiefe von 8 Bit bei unterschiedlicher Grösse.
3.1.4 Medizinische Bildformate
Das DICOM Informationsmodell
Das DICOM Informationsmodell definiert die Struktur und Organisation der Kommunikation
mit medizinischen Bilddaten. Dabei werden Dienstleistungen festgelegt, die den Umgang mit
den verschiedenen Informationsobjekten (siehe Abschnitt 3.1.1) organisieren.
Entwicklungsgeschichte
Der Austausch von medizinischen Bilddaten ist nur möglich, wenn diese auch einem allge-
meinen Standard genügen, sonst sind aufwendige Konvertierungsverfahren notwendig, um
sie an das jeweilige Umfeld anzupassen. Das American College of Radiology (ACR) und
die National Electrical Manufactures Association (NEMA) arbeiteten seit 1983 an einem
ACR-NEMA-Standard, der dieses Problem lösen sollte. Darauf aufbauend wurde 1993 der
15

KAPITEL 3. GRUNDLAGEN
DICOM-Standard als eine herstellerunabhängige Kommunikationsplattform für medizinische
Bildinformationen vorgestellt (siehe ).
Das DICOM Objektmodell
Die DICOM-Datenstrukturen basieren auf einem objektorientierten Informationsmodell, mit
dem die Objekte der realen Welt mit ihren spezifischen Eigenschaften und Funktionen mo-
delliert werden.
Patient
Instance UID
Name
1
1-n
Studie
Instance UID
Modalität
1
1-n
Serie
Instance UID
Beschreibung
1
1-n
CT-Bild
Instance UID
Pixeldaten
Abb. 3.6: Objektdiagramm Dicom
Aufbau der Informationsobjekte
� Attribute und Attributwerte
16
Attribut Attributwert
Name Mustermann
Geburtsdatum 1965-23-03
Gechlecht männlich
Tabelle 3.1: Patientenobjekt
Der objektorientierte Aufbau ermöglicht es, den
Standard durch Veränderungen und Erweiterungen
an neue Anforderungen anzupassen. Das Diagramm
3.1.1 zeigt die aus 4 Ebenen bestehende DICOM-
Struktur : Patient - Studie - Serie - Bild
Eine Studie repräsentiert eine Untersuchung, die in
einzelne Serien unterteilt ist. Bei der Leberopera-
tionsplanung entspricht eine Studie einer Sitzung
beim Radiologen, bei der verschiedene Serien auf-
genommen werden können ( siehe Abschnitt 3.1.3).
Eine Serie beschreibt mit ihren CT-Bildern eine be-
stimmte Aufnahmephase innerhalb einer Untersu-
chung.
Attribute dienen zur Beschreibung von Infor-
mationsobjekten und werden in Gruppen mit
einer gemeinsamen Gruppennummer zusam-
mengefasst. In der Tabelle 3.1 sind beispiel-
haft einige Attribute des Objektes Patient mit
Attributwerten aufgelistet.

� Tags
3.1. MEDIZINISCHE GRUNDLAGEN
Attribut Value Representation Gruppen-Tag Element-Tag
Name PN 0010 0030
Geburtsdatum DA 0010 0040
Modalität CS 0008 0060
Pixeldaten OW 7FE0 0010
Tabelle 3.7: Beispieltags
Zur eindeutigen Identifikation eines Attributes wird ein Tag, der aus zwei 16-Bit-Zahlen
besteht, benutzt. Dabei legt die erste Zahl die Zugehörigkeit zu einer bestimmten Gruppe
fest und die zweite Zahl identifiziert das Element innerhalb dieser Gruppe. Zusammen sind
diese Werte mit ihrem Darstellungsformat (Value Representation) in einem DataDictionary
definiert.
� Arten von Informationsobjekten
• Normalized Objekte beinhalten nur Attribute aus einer einzigen Gruppe.
Beispiel : Patienteninformation
• Composite Objekte enthalten Attribute aus verschiedenen Objektklassen.
Beispiel : CT-Bild (“Computed Tomography Information Object Class”) enthält Infor-
mationen aus den Gruppen Studie, Serie und Patient.
� Unique Identifier
Beschreibung UID
CT Image Storage 1.2.840.5.1.4.1.1.4
Studieninformationen 1.2.840.5.1.4.1.2.5
Tabelle 3.2: Instance UID
DICOM ordnet jeder Objektinstanz
einen eindeutigen Indetifier zu. So
ist es zum Beispiel möglich, von
einem CT-Bild auf den Herstel-
ler des Aufnahmegerätes zu schlie-
ßen.
17

KAPITEL 3. GRUNDLAGEN
3.1.5 PIC-Format
Das PIC-Format ist ein in der Abteilung MBI-Abteilung des Deutschen Krebsforschungszen-
trum (DKFZ) entwickeltes Bildformat. Es dient als herstellerunabhängiges Format zum Spei-
chern und Versenden von medizinischen Bilddaten. Dabei kann dieses Format als Container
für andere Bildformate dienen. Durch die Möglichkeit Einzelschichten zusammenzusetzen,
ist es mit dem PIC-Format möglich auch Bildvolumen darzustellen.
Aufbau des Datenformates
Das Pic-Format besteht aus drei Teilen:
• Der Header enthält veschiedene Informationen über die Pixeldaten ( Datentyp, Di-
mension, Auflösung etc. )
• Tag Fields ermöglichen das Speichern von Zusatzinformationen die eine Benennung
und einen Wert besitzen. Bei der Arbeit mit DICOM-Bildern findet sich hier ein Ver-
weis auf den DICOM-Header. Ein Tag eines Segmentierungsergebnisses ist der Image
Type, dem der Wert“Image ,Segmentation”zugeordnet wird und der zur Indetifizie-
rung dient.
• Die Bilddaten.
Die interne Repräsentation wird mit einem ipPicDescriptor deklariert:
typedef struct
{
void *data; / ∗ p o i n t e r t o ’ i m a g e ’ d a t a ∗/
_ipPicInfo_t *info; / ∗ p o i n t e r t o t h e P i c I n f o s t r u c t u r e ∗/
ipPicType_t type; / ∗ d a t a t y p e o f t h e d a t a ∗/
ipUInt4_t bpe; / ∗ b i t s p e r e l e m e n t ∗/
ipUInt4_t dim; / ∗ n u m b e r o f d i m e n s i o n s ∗/
ipUInt4_t n[_ipPicNDIM]; / ∗ s i z e o f d i m e n s i o n n [ i ] ∗/
} ipPicDescriptor;
18
Listing 3.1: Deklaration eines ipPicDescriptors in der ipPic.h

3.1. MEDIZINISCHE GRUNDLAGEN
Auf diesem Format aufbauend wurde eine Bibliothek entwickelt, die die grundlegenden
Funktionen, wie das Laden ( ipPicGet ) und Speichern ( ipPicPut) eines PIC-Bildes zur
Verfügung stellt. Die ipFunc-Bibliothek bietet dagegen Funktionen zur Vearbeitung der
PIC-Bilder an. In Kapitel 5.9.4 wird diese Bibliothek genutzt, um aus PIC-Schichtbildern
ein Oberflächenmodell zu erzeugen.
3.1.6 Segmentierung
Da ein Computer auf Bildern keine Objekte erkennen kann, wird durch die ein Bild in
Bereiche gleicher Zusammengehörigkeit (z.B. funktionale, anatomische) aufgeteilt. Ziel ist
es das Objekt vom Rest des Bildes , dem Hintergrund, zu trennen. Dies gestaltet sich je
nach Dichtewert des Objektes unterschiedlich schwierig. So kann Knochen aufgrund seiner
hohen Dichte sehr gut von benachbarten Organen und Gewebe getrennt werden. Im Falle
der Leber gestaltet sich diese Trennung bei weitem schwieriger, da die Dichteunterschie-
de zwischen der Leber und benachbarten Organen klein sind. Aus dem als Grauwertbild
vorliegenden Originalbild wird ein Binärbild gleicher Größe erzeugt, indem Bildpunkte, die
zu einem bestimmten Objekt gehören, der gleiche Wert zugeordnet werden. Falls sie au-
ßerhalb des gesuchten Objektes liegen, erhalten sie den Wert 0. Diese segmentierten Ein-
zelschichtbilder dienen als Grundlage für die Erzeugung der in Kapitel 5.9.4 vorgestellten
Oberflächenerzeugung. Bei der Leberoperationsplanung werden automatische und manuelle
Segmentierungsverfahren eingesetzt, allerdings existiert zur Zeit noch kein automatisches
Verfahren, das ohne manuelle Nachbearbeitung bzw. Kontrolle funktioniert.
(a) Originalbild (b) Segmentierungsergebnis
Abbildung 3.8: Bildaufbereitung durch Segmentierung
Zur Zeit wird dabei meist mit den folgenden Segmetierungswerkzeugen gearbeitet:
◮ Beim Freihandzeichnen wird mit einem Eingabegerät wie z.B. der Maus eine Linie
19

KAPITEL 3. GRUNDLAGEN
entlang des Objektrandes gezogen und anschließend die eingeschlossene Fläche als
Objekt markiert.
◮ Ein Schwellwertverfahren kann bei Objekten eingesetzt werden, die sich stark von ih-
rem Hintergrund abheben. Ein angegebener Schwellwert definiert dabei die Grenze
zwischen Objekt und Hintergrund, indem z.B. alle Bildpunkte, deren Grauwert größer
als der Schwellwert ist, dem Objekt zugeordnet werden. Bei CT-Bilder kann dieser
Schwellwert aus der Hounsfield-Skala (Abbildung 3.2) abgeleitet werden.
◮ Regionenwachstumsverfahren versuchen ein Bild anhand der Homogenität der zu ei-
nem Objekt gehörenden, Bildbereiche zu segmentieren. Eine Möglichkeit ist, in das
Objekt einen Saatpunkt zu setzen, der sich ausbreitet, solange ein vorgegebenes Ho-
mogenitätskriterium erfüllt ist und im günstigsten Fall auf diese Weise die gesamte
Objektfläche ausfüllt. Zur Gefäßsegmentierung wird ein Volume-Growing-Verfahren
eingesetzt, mit dem die Gefäßbäume in einem dreidimensionalen Volumen segmen-
tiert werden können.
3.2 Medizinische Bildverarbeitung
Die Medizinische Bildverarbeitung hat in den letzten Jahren aufgrund der Entwicklung neu-
er bildgebender Verfahren, der Leistungssteigerung der Computer und Graphikarten und
der Verbesserung der Bilddatenkommunikation an Bedeutung gewonnen. Die Aussagekraft
von digitalen Bildern kann durch Hervorhebung der relevanten Bildinformationen erhöht
werden, womit auch die Interpretation der Bildinformationen erleichtert wird. Beim Aufbe-
reiten der Bilddaten können wie im Abschnitt 3.1.6 neue Bilder erzeugt oder im Falle der
3D-Rekonstruktion in anderer Form (siehe Kapitel 5.9.4) dargestellt werden. Neben der
visuellen Erhöhung der Aussagekraft der Bilder, kann auch durch die Bestimmung quanti-
tativer Größen der Informationsgehalt eines Bildes erhöht werden (siehe Kapitel 5.7).
3.2.1 Bildverarbeitungsoperationen
Von den als Schichtbildern vorliegenden Bilddaten ausgehend gibt die Abbildung 3.9 einen
Überblick über die in dieser Diplomarbeit verwendeten Bildverabeitungsoperationen.
20

Bilddaten
Interpretation
Filterung
Segmentierung
Geometrische
Operationen
3D-Rekonstruktion
Segmentierung
Segmentierung
Datenreduktion
Distanzmessungen
Bildarchivierung Bildauswertung
Abbildung 3.9: Bildverarbeitungsoperationen
3.2. MEDIZINISCHE BILDVERARBEITUNG
Die im Kapitel 5.9.4 zur Oberflächengene-
rierung eingesetzten Filteroperationen, er-
zeugen wie die Segmentierung ein neues
Bild und verbessern dadurch die Interpre-
tationsmöglichkeiten. Die in Kapitel 3.3.1
beschriebenen geometrischen Operationen
werden beispielsweise können zum Bewe-
gen der Szene eingesetzt werden. Eine 3D-
Rekonstruktion bildet die Grundlage einer
3D-Visualisierung, kann aber durch eine Re-
duzierung der Daten optimiert werden (sie-
he Kapitel 5.9.4). Mit Distanzmessungen
wird der in Kapitel ein Sicherheitsabstand
bestimmt. Die angesprochene Maßnahmen
dienen der Bildauswertung, während die
Bildarchivierung in Verbindung mit einem
Teleradiologiesystem eine Datenkommuni-
kation ermöglicht.
21

KAPITEL 3. GRUNDLAGEN
3.3 Visualisierungstechniken
Dieser Abschnitt gibt eine Einführung in die 3D-Programmierung und ermöglicht dadurch
das Verständniss der aufwendigeren 3D-Rekonstruktion einer Leberoperationsplanung. Die-
ses Thema wird in , und ausführlicher beschrieben. Die
Darstellungen der Abbildungen 3.10 und 3.14 wurde zur Demonstration der Visualisie-
rungstechniken programmiert und das Listing zu Abbildung 3.10 befindet sich teilweise im
Anhang.
3.3.1 Graphikprogrammierung
In der Computergraphik bezeichnet man die Ausgabeelemente Punkte, Linien, Dreiecke und
Polygone als Primitive und baut mit ihnen komplexere Objekte zusammen.
Punkte und Vektoren
Punkte stellen die Basis für alle Graphikoperationen und graphischen Elemente dar. Als Be-
standteile von Graphikobjekten werden sie auch als Vertex (Scheitelpunkt) bezeichnet. Die
Punkte werden dabei durch die Angabe von Koordinaten definiert und bezeichnen dadurch
eine feste Position im Raum. Dazu wird ihnen eine Liste von Zahlen, auch Tupel genannt,
zugeordnet. Im zweidimensionalen Raum enthält diese Liste zwei und im dreidimensionalen
Raum drei Einträge. In Abbildung 3.10 sind als Beispiele 4 Punkte mit Koordinatenangabe
beschriftet. Neben der Zuordnung von Koordinaten kann man den Punkten aber noch mit
andere Eigenschaften wie Farbe, Transparenz oder skalare Werte zuweisen. Ein Vektor wird
wie ein Punkt durch die Zuordnung eines Tupels definiert, legt allerdings keine Ortsangabe
fest, sondern repräsentiert eine Verschiebung mit festgelegter Länge und Richtung.
Polygone
Polygone sind die Bauelemente graphischer 3D-Objekte und werden durch einzelne Punkte
definiert. Da die Graphikhardware das Zeichnen von Dreiecken unterstützt, besitzen diese
in der 3D-Graphik eine besondere Rolle. Sie werden auch zur Darstellung anderer Polygone
genutzt, indem mehrere Dreicke so angeordnet werden, dass mit ihnen die Polygonfläche
dargestellt werden kann. Dreiecke werden im 3D-Raum durch drei Punkte definiert, die mit
Linien verbunden und bei Bedarf noch ausgefüllt werden. Die Abbildung 3.10 zeigt vier mit
Koordinaten beschriftete Punkte, welche mit Linien verbunden, zwei Dreiecke ergeben und
22

zusammengesetzt die Vorderseite des Würfels bilden.
Aufbau von Objekten
3.3. VISUALISIERUNGSTECHNIKEN
Zum Aufbau von Objekten werden Polygone verbunden und diesen Oberflächen- und Ma-
terialeigenschaften zugeordnet. Die Vertices werden dabei meist von mehreren Polygonen
geteilt. So teilen sich die 12 Dreiecke in Abbildung 3.10 die 8 Vertices des Würfels. Zur
Speicherung der Informationen zu einem Objekt werden in vielen 3D-Anwendungen zwei
getrennte Listen verwendet. Dabei speichert die erste Liste die Informationen der Vertices,
während in der zweiten Liste die Informationen zu den Dreiecken, über Verweise auf die erste
Liste enthält. Auf diese Weise müssen die Koordinaten von Punkten, welche von verschie-
denen Dreiecken benutzt werden, nur einmal gespeichert werden. Eine solche Verwaltung
der Punktdaten wird vom Visualization Toolkit (VTK) (siehe Abschnitt 3.3.4) verwendet
und wird in der Abbildung 3.10 demonstriert.
Indexliste der vorderen Dreicke:
{{0,1,2},{0,2,3}}
3:(-1,1,-1)
0:(-1,-1,-1)
+y
2:(1,1,-1)
1:(1,-1,-1)
Punkteliste der vorderen Dreicke:
{{-1,-1,-1},{1,-1,-1}, {1,1,-1}, {-1,1,-1}}
+z
+x
Abbildung 3.10: Beispielobjekt Würfel
23

KAPITEL 3. GRUNDLAGEN
Koordinatensysteme
Mit Koordinatensystemen ist es möglich Punkte eindeutig über Koordinaten zu definieren.
Zur Positionsangabe von Punkten im 3D-Raum wird ein Koordinatensystem mit 3 Achsen
(x,y,z) benötigt, in dem der Punkt mit den Koordinaten (0,0,0) der Schnittpunkt dieser
Achsen und Koordinatenursprung ist. Den Punkt (x,y,z) erreicht man indem man sich x
Einheiten auf der x-Achse, y Einheiten auf der y-Achse und z Einheiten auf der z-Achse
bewegt.
3D-Koordinatensysteme können aufgrund der Orientierung der z-Achse hinsichtlich der Ori-
entierung von x- und y-Achse in linkshändige und rechtshändige Systeme unterteilt werden.
Die Abbildung 3.10 zeigt ein linkshändiges Koordinatensystem bei der die positive z-Achse,
bei der Ausrichtung positive x-Achse weg vom Betrachter in die Szene hinein zeigt.
5
2
2
C
A
0
B
2
E
D
0
2 5
Abb 3.11: Welt-Objektkoordinatensystem
2
F
G
2
Punkt Weltkoordinaten Objektkoordinaten
A (2,3) (0,0)
B (3,3) (2,0)
C (1,6) (0,2)
D (5,1) (0,0)
E (5,3) (0,2)
F (7,3) (2,2)
G (7,1) (2,0)
Tabelle 3.12: Punkte im
Welt-Objektkoordinatensystem
Ein Weltkoordinatensystem ist ein der gesamten Szene zugrundeliegendes Koordinatensys-
tem, in dem die verschiedenen Objekte einer Szene platziert werden. Die Abbildung 3.11
und die Tabelle 3.12 zeigen wie zwei Objekte, in ihrem Objektkoordinatensystem definierte
Objekte, im gemeinsamen Weltkoordinatensystem platziert werden.
24

(1,6)
(1,4)
(2,6)
(2,4)
(4,4)
(5,1)
(5,3)
(a) Translation
(1,4)
(5,3)
(5,1)
(7,1)
(7,1)
(c) Translation mit Skalierung
Transformationen einer Szene
3.3. VISUALISIERUNGSTECHNIKEN
(1.5,5)
(3,3.5)
(4.5,5)
(5,3)
(5,1) (7,1)
(b) Translation mit Rotation
(5,3)
(5,1)
(7,-1)
(5,-3)
(7,1)
(d) Spiegelung an x-Achse
Abbildung 3.13: 2D-Transformationen eines Dreiecks
Eine Transformation ist in der Computergraphik als eine Positionsänderung eines oder meh-
rerer Punkte in dem, der Szene zugrundeliegenden, Koordinatensystem definiert. Die Ab-
bildung 3.13 stellt einige in der Computergraphik verwendete Transformationen vor, dabei
verdeutlicht der Pfeil neben den Objekten die Richtung der Transformation.
(7,-1)
25

KAPITEL 3. GRUNDLAGEN
◮ Bei einer Modelltransformation, erfolgt die Bewegung über eine Positionsveränderung
der Punkte, in dem, der Szene zugrundeliegenden, Koordinatensystem. Im folgenden
werden kurz die wichtigsten Transformationen vorgestellt.
• Bei einer Translation können Punkte, in alle möglichen Richtungen des Koordi-
natensystems, verschoben werden( siehe Abbildung 3.13(a)).
• Eine Rotation ist eine kreisförmige Bewegung eines Punktes um ein Rotations-
zentrum. Die Abbildung 3.13(b) zeigt die Rotation eines Dreiecks nach einer
Translation.
• Mit einer Skalierung kann man die Größe eines Objektes in allen drei Achsen-
richtungen manipulieren. In Abbildung 3.13(c) wurde das Dreieck nach der
Translation um den Faktor 0.5 in x-Richtung skaliert.
• Eine Spiegelung eines Objektes ist an jeder beliebigen Linie möglich. In der
Abbildung 3.13(d) als Beispiel ein Dreieck an der x-Achse gespiegelt.
◮ Bei einer Ansichtstransformation (siehe Abbildung 3.14) werden nicht die Objekte
der Szene, sondern die Kameraeinstellung verändert. Die Kameraeinstellung ist, durch
eine Kameraposition, eine Kameraorientierung und einen Brennpunkt, definiert und
bei einer Änderung dieser Einstellung, wird das zugrundeliegende Koordinatensystem
manipuliert.
Mathematische Darstellung der Transformationen
Für affine geometrische Transformation kann eine Transformationsmatrix aufgestellt wer-
den, die bei einer mathematischen Operation mit einem als Vektor dargestellten Punkt die
gewünschte Positionsveränderung des Punktes bewirkt.
Um den Punkt (5,1) in Abbildung 3.13(a) in den Punkt (2,4) zu transformieren ist folgende
Rechnung notwendig:
⎛ ⎞
1 0 −3
⎜ ⎟
⎜
⎝ 0 1 3 ⎟
⎠
0 0 1
∗
⎛ ⎞
5
⎜ ⎟
⎜
⎝ 1 ⎟
⎠
1
=
⎛
⎜
⎝
Um aufeinanderfolgende Transformationen auszuführen, werden die verschiedenen Matrizen
miteinander multipliziert. So wird die in 3.13(c) gezeigte Skalierung nach einer Translation
folgendermaßen durchgeführt :
26
2
4
1
⎞
⎟
⎠

⎛ ⎞
0.5 0 0
⎜ ⎟
⎜
⎝ 0 1 0 ⎟
⎠
0 0 1
∗
⎛ ⎞
1 0 −3
⎜ ⎟
⎜
⎝ 0 1 3 ⎟
⎠
0 0 1
∗
⎛ ⎞
5
⎜ ⎟
⎜
⎝ 1 ⎟
⎠
1
=
⎛
⎜
⎝
3.3. VISUALISIERUNGSTECHNIKEN
Neben den zwei Koordinaten zur Ortsangabe besitzen die Vektoren und Matrizen noch eine
dritte homogene Koordinate, die eine konsistente Matrixscheibweise von Rotation, Skalie-
rung und Translation und die Durchführung von perspektivischen Transformationen ermög-
licht.
Eine möglichst realistische Darstellung von Objekten kann über die Beleuchtung und Zuord-
nung von Materialeigenschaften erreicht werden. In unserer Umwelt sehen wir Objekte, weil
sie Licht reflektieren oder als Lichtquellen Licht aussenden. Die durch Rot-,Grün-, Blau-
und Transparenzwerte angegebe Farbe und die Wechselwirkung der Materialien mit dem
Licht bestimmen dabei das Aussehen der Objekte. Eine Anpassung dieser Darstellung kann
durch die Änderung der Reflexionseigenschaften der Objektmaterialien oder der Einstellung
der Lichtquellen erreicht werden.
Kameraeinstellung und Beleuchtung
Brennpunkt
Azimuth
Projektionsrichtung
Elevation
Roll
Abbildung 3.14: Kamera- und
Lichteinstellungen
1
4
1
⎞
⎟
⎠
Zur Veränderung der Ansicht auf eine Sze-
ne, erbringen die beiden angesprochenen
Transformationen die gleichen Ergebnis-
se. Für die Navigation durch eine Sze-
ne im Darstellungsfenster des Organicers
(siehe Kapitel 4.1.1) werden aber Modell-
transformationen benutzt. Die Kamerapo-
sition ist dabei in einem bestimmten Ab-
stand von der Szene entfernt positioniert
und der Brennpunkt liegt im Ursprung des
Koordinatensystems. Die Kameraorientie-
rung kann horizontal (Azimuth), vertikal
(Elevation) und durch eine Drehung um
Projektionsachse verändert werden.
27

KAPITEL 3. GRUNDLAGEN
3.3.2 Volumendarstellung
Zur Visualisierung eines Volumens können zwei unterschiedliche Verfahren verwendet wer-
den: das Oberflächenrendering und das Volumenrendering (siehe Abschnitt 3.3.4). Diese
Verfahren unterscheiden sich u.a. in der Repräsentation der Volumendaten, in der Qualität
der berechneten dreidimensionalen Ansichten sowie in der dazu benötigten Rechenzeit.
Oberflächenrendering
Bei der Oberflächenvisualisierung werden die Außenflächen der Objekte durch grafischen
Primitive (meist Dreiecke) dargestellt. Die Objektgrenzen werden mit einem Schwellwertver-
fahren bestimmt und durch Dreiecke angenähert. Durch diese Annäherung und die fehlenden
Informationen innerhalb des Objektes, gehen bei diesem Verfahren allerdings Bildinforma-
tionen verloren.
Sie werden aber bevorzugt in interaktiven Anwendungen verwendet, da das Rendern der auf-
gebauten Gittermodelle durch die Graphikhardware- und OpenGL-Unterstützung schneller
als die direkte Volumendarstellung ist.
4
0
5
2
Voxel
Abbildung 3.15:
6
1
Aufbau eines Würfels
7
3
Der Marching-Cubes Algorithmus
Zur Durchführung dieser Oberflächenkonstruktion kann der
Marching-Cubes-Algorithmus verwendet werden, der ein
Bildvolumen in Würfel aufteilt. Ein Würfel wird aus zwei
Schichten des Volumendatensatzes gebildet und wird von 8
benachbarten Voxeln gebildet. Das weitere Vorgehen ent-
spricht einem in Kapitel 3.1.6 beschriebenen Schwellwert-
verfahren, bei dem für jeden Eckpunkt des Würfels ent-
schieden wird, ob er innerhalb oder außerhalb des Objek-
tes liegt. Falls eine Kante des Würfels einen innerhalb des
Würfels liegenden Eckpunkt mit einem außerhalb liegenden
Punkt verbindet, wird diese Kante von der Objektoberflä-
che geschnitten. Der exakte Schnittpunkt wird durch Interpolation über die Pixelwerte der
Eckpunkte der Kante bestimmt und mit den anderen Kantenschnittpunkten zu Polygonen
verbunden.
28

3.3. VISUALISIERUNGSTECHNIKEN
Abbildung 3.16: Entscheidungsfälle beim Marching-Cubes-Algorithmus
Dabei ergeben sich 256 Möglichkeiten die Oberfläche durch eine Würfel zu legen, von denen
allerdings nur 15 berücksichtigt werden müssen. Alle anderen Fälle können durch Spiegelung,
Rotation oder Komplementärbildung in diese Fälle überführt werden. In Abbildung 3.16
sind zum besseren Verständniss drei dieser Fälle dargestellt.
Da bei der Erstellung einer Oberfläche mit dem Marching-Cubes Algorithmus die Anzahl der
Dreiecke des Objektmodells eine Interaktion nur bedingt zulassen, ist es notwendig diese An-
zahl in Nachbearbeitungsschritten zu reduzieren. In Kapitel 5.9.4 wird neben der Erzeugung
von STL-Oberflächenmodellen auch auf die Reduktion der Polygone eingegangen.
Direkte Volumendarstellung
Zur direkten Volumendarstellung wird meist ein Raytracing-Verfahren eingesetzt, bei dem
von der aktuellen Kameraposition ausgehend Strahlen in die Szene geworfen werden. Diese
werden für jedes Pixel verfolgt und beim Auftreffen auf ein Objekt ein Strahl zu der Licht-
quelle ausgesandt, um ein lokales Beleuchtungsmodell zu berechnen (Abbildung 3.17). Ein
solches Verfahren ist sehr rechenaufwendig, da auch reflektierte Strahlen berücksichtigt und
Schattenberechnungen durchgeführt werden müssen. Bei einer interaktiven Anwendung muß
das Bild bei jeder Aktion neu berechnet werden, dies führt bei der direkten Volumendar-
stellung zu einem hohen Rechenaufwand. Der Vorteil dieses Verfahrens liegt aber im hohen
Informationsgehalt und der Realitätstreue der berechneten Bilder.
29

KAPITEL 3. GRUNDLAGEN
Abbildung 3.17: Vereinfachte Darstellung des Raytracing-Prinzips
3.3.3 Beschreibung der OpenGL Visualisierungs-Schnittstelle
Historischer Hintergrund
Die Firma Silicon Graphics Incorporation entwickelte 1982 eine Schnittstelle zur Graphik-
programmierung ihrer Workstations. Diese Befehls-Bibliothek (IRIS GL) war sehr hardwa-
renah programmiert und konnte deshalb nicht auf andere Systeme portiert werden. Zur
Realisierung einer Portabilität von OpenGL wurde 1991 ein Konsortium aus Vertretern der
Computerindustrie (z.B. Microsoft,IBM, Intel, DEC, SGI, Sun etc.) mit dem Namen Ar-
chitectur Review Board (ARB) gebildet, deren Aufgabe es ist, offizielle Dokumente bzgl.
Definition und Weiterentwicklung herauszugeben und Implementierungen von OpenGL zu
kontrollieren. Bereits 1992 veröffentlichten die Firmen DEC und SGI die ersten Versionen
von OpenGL. Eine Microsoft-Version für Windows NT folgte 1994. Brian Paul veröffentliche
1995 die Mesa-Bibliothek, eine Opensourceversion von OpenGL.
Kennzeichen von OpenGL
30
• Strenge Normierung : Die ARB stellt sicher, dass jede Erweiterung von OpenGL
herstellerneutral ist und zertifiziert wird.
• Systemunabhängigkeit : Anwendungen mit reinen OpenGL-Anweisungen laufen auf
verschieden Betriebssystemen. Da OpenGL keine Fensterverwaltung oder die Verar-
beitung von Maus- bzw. Tastaturereignissen unterstützt, muß diese Funktionalität
von systemspezifischen Zusatzbibliotheken wie GLUT, GLX und WGL oder Qt über-
nommen werden.

3.3. VISUALISIERUNGSTECHNIKEN
• Client-Server Prinzip : Die Berechnung und die Darstellung von Szenen kann auf
verschiedenen Rechnern erfolgen. Große Rechenmaschinen können virtuelle Welten
erzeugen, welche an PC’s geschickt und dort angezeigt werden können.
• Zustandsautomat : OpenGL verfügt über Zustandsvariablen, welche abgefragt wer-
den können und deren Änderung sich auf alle nachfolgend definierten Objekte unmit-
telbar auswirkt.
• Kleiner Sprachumfang : OpenGL besitzt mit ca. 300 Funktionen eine überschaubare
Anzahl von Befehlen, die zur Farb- bzw. Materialzuweisung und Transformation der
Vertices dienen. Diese werden prozedural abgearbeitet, so dass bei Statusabfragen,
unabhängig von der Komplexität der Befehle, der tatsächliche Status von OpenGL
zurückgegeben werden kann.
Die OpenGL-Renderingpipeline
OpenGL-Primitive
Vertex-Daten
Displaylisten
Trabsformationen,
Beleuchtung,
Clipping
Rasterisierung
Fragmentoperationen
Bildspeicher
Abbildung 3.18:
OpenGL Pipeline
Die in der Abbildung 3.18 dargestellte vereinfachte Dar-
stellung der OpenGL Graphikpipeline ist aus über-
nommen. Am Anfang der Pipeline werden durch OpenGL-
Ausgabeanweisungen aus grafischen Primitiven Objekte mo-
delliert. Die zur Erstellung von Objekten benötigten OpenGL-
Befehle können in Displaylisten zusammengefasst werden, was
das Rendern dieser Objekte bei einer Animation beschleunigt.
Durch die Transformation der Vertex-Koordinaten werden die
Objekte in der Szene ausgerichtet und über Beleuchtungsrech-
nungen werden den Vertices Farbwerte zugewiesen. Als Ras-
terung bezeichnet man die Abbildung der grafischen Primiti-
ve auf ein Gitter abgebildet, dessen Ausmaße der Größe des
Bildschirmfensters entspricht. Die einzelnen Quadrate dieses
Gitters nennt man Fragmente und ordnet ihnen in verschie-
denen Operationen einen Tiefenwert, Texturkoordinaten und
Farbwerte zu. Nach einer Verdeckungsrechnung werden die
Fragmente als Pixel in den Bildspeicher eingetragen.
31

KAPITEL 3. GRUNDLAGEN
Hardwareunterstützung
Graphics Device
Interface
Display System
Application Program
OpenGL
Software
Rasterizer
(a) Softwareunterstützung
Graphics Device
Interface
Display System
Application Program
OpenGL
Hardware
Driver
(b) Hardwareunterstützung
Abbildung 3.19: Beschreibung der OpenGL Unterstützung
Durch die strengen Konformitätstests der ARB ist sichergestellt, dass einem Entwickler im-
mer sämtliche Möglichkeiten, welche ihm die OpenGL-API bietet, zur Verfügung stehen.
Falls diese nicht die Hardware realisiert, werden diese softwaremäßig emuliert. Bei einer
OpenGL-Softwareunterstützung muß die CPU die in Abschnitt 3.3.3 beschriebene Durch-
führung der OpenGL-Pipeline übernehmen und die Pixel in den Bildspeicher schreiben. Da
diese Aktionen einige Zeit benötigen ist durch die reine Softwareunterstützung keine fort-
geschrittene 3D-Graphikprogrammierung möglich.
Durch eine verbesserte OpenGL-Unterstützung durch Graphikkarten wachsen auch die Mög-
lichkeiten der 3D-Programmierung. In Abbildung 3.19(b) ist zu erkennen, dass die Gra-
phikhardware direkt mit den Ausgabegeräten zusammenarbeitet und die in der Graphikkar-
te ausgeführte OpenGL-Pipeline kann direkt weitergegeben werden. Neuere Graphikkarten
unterstützen dabei neben 3D-Transformationen auch aufwendige Operationen wie Schat-
tenberechnungen, so dass diese zur Verbesserung der räumlichen Darstellung in der 3D-
Visualisierung eingesetzt werden kann.
3.3.4 Visualization Toolkit (VTK)
Das Visualization Toolkit (VTK) ist ein frei verfügbares (Open Source), objektorientiert
aufgebautes Softwaresystem für 3D-Computergraphik, Bildverarbeitung und Visualisierung
32

3.3. VISUALISIERUNGSTECHNIKEN
(siehe ). VTK unterstützt die Graphikprogrammiersprache OpenGL und die Ent-
wicklung plattformunabhängiger Anwendungen. Die Abbildungen 3.10 und 3.14 zeigen
Aufnahmen von Programmen, die zur Veranschaulichung der beschriebenen Themen, für
diese Arbeit programmmiert wurden und deren Listings sich auszugsweise im Anhang be-
finden.
Hauptklassen von VTK
vtkActor
(Objekt)
1
1
1
vtkRenderer
(Szene)
1 n
1
vtkCamera vtkLight vtkMapper
1
Abbildung 3.20: Klassendiagramm VTK
1
n
1
vtkRenderWindow
(Ausgabefenster)
• Ein vtkRenderWindow bietet einen Fensterbereich, in dem die verschiedenen Objekte
dargestellt werden und Interaktionen durchgeführt werden könnnen.
• Die vtkRenderer koordinieren das Rendern unter Berücksichtigung der Lichtquellen,
Kameraeinstellung und Objekte.
• Die Kameraeinstellungen werden durch eine Instanz der Klasse vtkCamera definiert.
• vtkActor repräsentiert ein in der Szene darzustellendes Objekt.
• Ein vtkMapper erzeugt die grafischen Objekte.
• Objekte besitzen eine vtkProperty-Instanz, über die ihr Erscheinungsbild (Farbe,
Transparenz, Lichteigenschaften) verändert werden kann.
3.3.5 Die VTK Visualisierungs-Pipeline
Innerhalb der Visualisierungs-Pipeline werden Datenobjekte in graphische Primitive umge-
wandelt und können anschließend auf einem Ausgabegerät dargestellt werden.
33

KAPITEL 3. GRUNDLAGEN
Die Objekte der Pipeline
Am Visualisierungsprozess von VTK sind zwei Arten von Objekten beteiligt:
◮ Datenobjekte repräsentieren Informationen und bieten Methoden zur Abfrage ver-
schiedener Eigenschaften der Daten an. Der Abschnitt 3.3.5 stellt die verschiedenen
Strukturen vor, mit denen die Datenobjekte die Daten verwalten könnnen.
◮ Zur Bearbeitung der Daten dienen Prozessobjekte, die als Eingabe Daten erhalten
und diese verändert ausgeben.
• Source Objekte, die ihre Daten aus externen Quellen (z.B. Dateien) auslesen,
werden als Reader-Objekt (z.B. vtkSTLReader) bezeichnet. Manche Source Ob-
jekte könnnen ihre Daten aber auch direkt erzeugen (z.B. vtkConeSource).
• Filter Objekte könnnen Daten mit spezifischen Funktionen verarbeiten und die
veränderten Daten in neue Datenobjekte schreiben. Je nach Art erhalten sie
mehrere Datenobjekte als Eingabe und produzieren mehrere Ausgabeobjekte.
• Mapper Objekte bilden das Ende der Visualisierungs-Pipeline und konvertieren
die Daten in Grafische Primitive oder schreiben die Daten als Writer-Objekt in
eine Datei.
Aufbau der Pipeline
PolyData Datei PolyData Reader Daten Objekt PolyData Mapper Display
Abbildung 3.21: VTK Pipeline
Zum Aufbau einer Visualisierungspipeline werden verschiedene Daten- und Prozessobjekte
miteinander verbunden. Das in der Abbildung 3.21 dargestellte Diagramm zeigt einen
typischen Aufbau einer Pipeline, wie sie auch zur Darstellung des Objektes in 3.14 verwendet
wird. Die Daten sind in einer Datei als Polydata strukturiert abgelegt und werden mit einem
dafür geeigneten Reader ausgelesen. Dieses Prozessobjekt liefert einen Output, der entweder
in ein Datenobjekt geschrieben werden kann oder direkt dem Mapper zur Erzeugung der
graphischen Primitive und der Beendigung der Pipeline übergeben werden kann. Im Anhang
zeigt ein Listing, den Einsatz einer VTK-PipeLine zur Visualisierung eines Würfels.
34

Daten Repräsentation
Eigenschaften der Daten
3.3. VISUALISIERUNGSTECHNIKEN
Zur Visualisierung von Daten ist es wichtig, diese in geeigneter Form zur Verfügung zu
stellen und dadurch eine effiziente Verarbeitung der Daten zu ermöglichen. Die Auswahl der
Form wird durch drei Eigenschaften festgelegt:
• Da die digitalen Daten in diskreter Form vorliegen, besitzen sie keine Informationen
über die Bereiche zwischen den Messpunkten. Die bei einer Visualisierung an beliebiger
Stelle benötigten Werte, müssen deshalb durch eine Interpolation berechnet werden
können.
• Die Struktur der Daten kann regelmäßig oder unregelmäßig sein. So kann bei einer
regelmäßigen Anordnung der Daten auf die Aufnahme jeder einzelnen Punktpositi-
on verzichtet werden, da diese sich aus dem Ursprungsort, dem Abstand zwischen
den Punkten und der Anzahl der Punkte ergeben. Bei einer unregelmäßigen Struktur
der Daten können Stellen ihrem Informationsgehalt entsprechend stärker oder weni-
ger stark repräsentiert werden. Dadurch lässt sich durch die Wahl einer angepaßten
Repräsentationsform der benötigte Speicherplatz reduzieren.
• Die topologische Dimension der Daten wird durch die dargestellten Strukturen wie
Punkte (0-dimensional), Linien (1-dimensional), Flächen (2-dimensional) oder Körper
(3-dimensional) bestimmt.
Datenobjekte und Attributwerte
Die Datenobjekte der Visualisierungs-Pipeline werden als Dataset bezeichnet und setzen sich
aus einer Organisationsstruktur und zusätzlichen Datenattributen zusammen. Die Struktur
ergibt sich dabei aus geometrischen und topologischen Eigenschaften. Die topologischen Ei-
genschaften werden durch, als Zellen bezeichnete, Linien, Dreiecke oder Polygone bestimmt
und bleiben bei geometrischen Transformationen unverändert. Zur Beschreibung der geome-
trischen Struktur dienen die Punktkoordinaten. Durch Organisation der Bilddaten können
mit VTK effiziente Operationen durchgeführt werden.
Die Datenattribute werden mit der Struktur eines Dataset verbunden und bieten ergänzende
Informationen zu den Daten. Dazu werden die Attribute den Punkten des Datasets zuge-
ordnet und können über diese abgefragt werden. Die Punkte eines Datasets zur Darstellung
35

KAPITEL 3. GRUNDLAGEN
eines Gefäßbaumes erhalten über Datenattribute Informationen über Farbe, Durchmesser
und Gefäßtyp (Kapitel 4.1.2).
In der Visualisierung werden insbesondere zwei Arten von Datasets verwendet:
◮ Die von graphischen Bibliotheken erzeugten Primitive werden Polygonal Data genannt
und ihre Repräsentionsform im VTK ist das Polydata Dataset. Die Topologie und
die Geometrie von Polydata ist unstrukturiert, da die beteiligten Zellen verschiedene
Dimensionen und eine beliebige geometrische Lage haben können. Ein Listing im
Anhang zeigt den Aufbau eines vtkPolyData-Datasets zur Visualisierung eines Würfels.
◮ Das Structured Points Dataset besteht aus Punkten und Zellen, die auf einem recht-
eckigen, regelmäßigen Gitter angeordnet sind. Durch die regelmäßige Topologie und
Geometrie wird die Struktur dieses Datasets durch die Angabe der Dimension (Punkte
in x-,y- und z-Richtung), den Abstand der Daten und einen Ursprungspunkt eindeutig
definiert. Als zweidimensionale Datenobjekte wird das Dataset als Pixmap oder Image
bezeichnet. Die dreidimensionale Variante, ein Volume, wird in der Medizin oft zum
Darstellen der Untersuchungsergebnisse der CT oder MRT eingesetzt.
Auch bei der Berechnung des Sicherheitsabstandes in Kapitel 5.7 werden die Bilddaten in
einer topologisch und geometrischen Struktur organisiert.
3.3.6 VRML
Die Virtual Reality Modelling Language (VRML) stellt ein Dateiformat dar, um interaktive
3D-Welten und Objekte zu beschreiben (siehe ). Mit dieser Beschrei-
bungssprache ist es möglich 3D-Welten im Internet anzubieten.
Um auf einem System VRML nutzen zu können, benötigt man einen VRML-Browser, der
entweder als Standalone-Anwendung genutzt oder als Plugin innerhalb eines Web-Browsers
eingefügt werden kann.
Eine VRML-Datei liegt im Textformat vor und beschreibt einen Szenengraph. Die Objekte
dieses Graphen werden als Knoten abgebildet. Knoten können alle Elemente einer Szene wie
z.b. graphische Primitive, Transformationen oder Materialeigenschaften repräsentieren.
VTK bietet die Möglichkeit alle Elemente einer, in einem vtkRenderWindow dargestellten,
Szene mit einer Exporterklasse auf der Festplatte zu speichern. Diese Klasse wird auch
zum Konvertieren der 3D-Szenen des Organicers, in das VRML-Format (siehe Kapitel 5.8)
benutzt.
36

3.4 Grundlagen der Informatik
3.4.1 Software-Engineering
Redesign
perfektionierend
adaptierend
korrigierend
Abbildung 3.22: Anteile der
Wartbarkeit
3.4. GRUNDLAGEN DER INFORMATIK
Für den Neuentwurf eines Softwaresystems existieren ei-
ne Reihe von Konzepten, dagegen spielt die Software-
Wartung nur eine bescheidene Rolle in der Literatur und
Forschung und dies obwohl Studien und Statistiken bele-
gen, dass die Wartung den größten Anteil innerhalb der
Gesamtkosten eines Softwareproduktes einnehmen ( nach
, ). In wird der Begriff
Wartung als ein Prozess zur Veränderung von Software-
Systemen verwendet. Diese wird auch wegen rasant fort-
schreitenden technologischen Entwicklung und der damit
verbundenen raschen Veralterung bestehender Systeme
immer wichtiger.
Der Begriff Software-Wartung kann in drei Bereiche unterteilt werden ,die verschiedene
Anteile am Gesamtwartungsaufwand (nach ) haben:
◮ Unter korrektiver Wartung vesteht man die Beseitigung von Fehlern.
◮ Eine adaptierende Wartung wird zur Anpassung der Software an sich ändernte Sys-
temumgebungen vorgenommen. Hierzu stellt das Kapitel 5.9 die Integration des
Visualisierungstools Organicer in das Teleradiologiesystem CHILI vor.
◮ In den Bereich der perfektionierenden Wartung fallen Änderungen, die zur Erfüllung
neuer oder geänderter fachlicher Anforderungen durchgeführt werden. Die im Rahmen
dieser Diplomarbeit durchgeführten perfektionierenden Wartungsarbeiten werden im
Kapitel 5 beschrieben.
37

KAPITEL 3. GRUNDLAGEN
Zeit
Anforderungen Analyse
Design
Implementierung Tests Produktion
Abbildung 3.23: Änderungskostenkurve
Kosten
Eine der allgemeinen Annahmen der Softwaretwicklung lautet, dass die Kosten für die Än-
derung eines Programmes mit der Zeit expotentiell ansteigen (siehe ). Diese
Aussage wird auch durch die Änderungskostenkurve in Abbildung 3.4.1 verdeutlicht, die
es nahelegt in der Anforderungsanalyse von Software-Produkten eine maximale Flexibilität
zu berücksichtigen, um so möglichst wenig kostenintensive Änderungen in späteren Pha-
sen durchführen zu müssen. Durch die Berücksichtigung einer maximalen Flexibilität, steigt
allerdings auch die Komplexität der Programme.
Deshalb versuchen neuere Ansätze in der Softwareentwicklung die Änderungen von Softwa-
reprodukten zu erleichtern. Die Extreme Programming Methode (siehe ) vesucht
mit ihren Technologien einfache, verständliche und redundanzarme Systeme zu entwickeln
und die Implementierungen auf die aktuellen Anforderungen zu begrenzen. Die Flexibilität
für neue Anforderungen soll dabei durch die Verwendung von Lösungen, wie Entwurfsmus-
tern, die sich in anderen Entwürfen in ihrer Erweiterbarkeit bewährt haben und durch den
Einsatz objektorientierter Programmierung, gewährleistet werden.
Die Abbildung 3.24 zeigt den Ablauf eines Reengineering-Prozesses in der Wartungsphase.
Von einem Altsystem ausgehend wird die Softwarearchitekur durch ein Redesign verbessert.
Diese Aktivität entspricht dem Reverse Engineering bei dem ein Software-System in einer
neuen Form oder auf einem höheren Abstraktionsniveau repräsentiert wird. Zur Anpassung
der alten Strukturen an die neuen Bedürfnisse muss eine Restrukturierung durchgeführt
werden, aus der sich Module ableiten, die die gewünschte Funktionalität anbieten.
An die Implementierungsphase schließt sich ein Migrationsprozess an, der den sicheren Über-
gang vom alten zum funktionierenden neuen System als Ziel hat und damit den Forward
Engineering Abschnitt durch eine Transformation in ein niedigeres Abstraktionsniveau ab-
38

3.4. GRUNDLAGEN DER INFORMATIK
schließt. Das Ziel dieses Software Reengineering Prozesses ist die Erneuerung des Altsystems
unter Beibehaltung der grunsätzlichen Funktionalität.
Abstraktionsniveau
Reverse Engineering Forward Engineering
Altsystem Redesign Restrukturierung Komponentenentwurf Migration
Abbildung 3.24: Der Reengineering-Prozess
Neusystem
Bei Forschungsprojekten in der Medizinischen Informatik enstehen oft Anwendungssoft-
wareprodukte, die zur praktischen Umsetzung von Modellen dienen. Diese prototypischen
Entwicklungen gelangen oft nicht zum Routineeinsatz, obwohl die Funktionalität dieser Sys-
teme durchaus benötigt wird.
Entwurfsmuster
Die Entwicklung objektorientierter Software, die spezifischen Anforderungen genügt, aber
auch flexibel genug ist, um zukünftigen Anforderungen zu begegnen, setzt Erfahrung im
Bereich der objektorientierten Softwareentwicklung voraus. Dann ist es möglich, erfolgreiche
Lösungen für Entwurfsprobleme zu finden, die sich durch eine einfache, flexible und leicht
verständliche Architektur auszeichnet. Erfahrene Softwareentwickler vermeiden es, jedes
Problem von Grund auf neu anzugehen und verwenden Lösungen, die sie zuvor erfolgreich
eingesetzt haben.
In Entwurfsmustern werden diese bewährten Problemlösungen in einer Form festgehalten,
die auch anderen Entwicklern den erfolgreichen Einsatz dieser Entwurfserfahrung ermöglicht.
Die Entwurfsmuster beschreiben dabei die Programmstruktur, indem sie die beteiligten
Objekte und Klassen identifiziert und ihre Zusammenarbeit erläutert. Die in dieser Arbeit
verwendeten Entwurfsmuster sind in den Büchern und ausführlich
beschrieben.
39

KAPITEL 3. GRUNDLAGEN
Singleton
Mit einem Singleton-Pattern ist es möglich eine Klasse zu modellieren, die nur einmal
instanziert werden kann und auf die ein globaler Zugriff möglich ist. Eingesetzt wird die-
ses Muster in Kapitel 5.3.1 zur Realisierung der Mediator-Klasse (siehe auch Abschnitt
Mediator). Diese Klasse verwaltet ihr einziges Exemplar selbst und bietet anderen keine
Möglichkeit, weitere Instanzen zu erzeugen. Da eine Singleton-Klasse durch Bildung von
Unterklassen erweiterbar sein soll, benötigt sie einen als protected deklarierten Konstruktor.
Der Zugriff auf das einzige Exemplar wird in einer Operation geregelt, welche beim ersten
Aufruf ein Exemplar erstellt und dieses bei allen weiteren Aufrufen den Klienten zurückgibt.
Singleton
singletonDaten
protected: Singleton()
static Singleton* getInstance()
{ return myOneAndOnlyInstance() ; }
Abbildung 3.25: Singleton-Muster
Beobachter
Dieses Muster beschreibt die Beziehung zwischen einer Gruppe von Klassen, die Beobachter,
welche vom Zustand einer einzigen Klasse, das Subjekt, abhängig sind. Bei einer Änderung
des Subjektes sollen alle abhängigen Objekte benachrichtigt werden, damit sich diese mit
dem Zustand des Subjektes synchronisieren.
Das Beobachtermuster zeigt, wie man diese Beziehung etabliert, ohne die beteiligten Klassen
eng miteinander zu koppeln. Dazu müssen die Objekte über eine definierte Schnittstelle
verfügen, damit sie angesprochen werden können, ohne als konkrete Klasse bekannt zu
sein. Die verschiedenen Objekte beziehen sich zwar auf das gleiche Subjekt, können aber
unabhängig voneinander verändert und wiederverwendet werden.
Das Sequenzdiagramm 3.26 zeigt die Interaktion zwischen zwei Beobachtern und einem
Subjekt. Die Klasse DataListView ist im Abschnitt 5.6.2 als typischer Beobachter beschrie-
ben, ändert das Subjekt , aktualisiert sich aber nicht selbst, sondern wartet wie der andere
Beobachter, auf die Benachrichtigung durch das Subjekt. Dieser Update-Aufruf kann aber
40

Subjekt
verändereSubjekt()
zustandAbfragen()
zustandAbfragen()
aktualisiere()
3.4. GRUNDLAGEN DER INFORMATIK
Beobachter Mediator
Beobachter
aktualisiere()
benachrichtige()
aktualisiere()
Abbildung 3.26: Beobachter-Muster
auch von einem der Beobachter ausgehen. Diese Variante wird in Abbildung 3.26 dargestellt
und im Organicer verwendet, bei der ein Mediator die Nachricht an die anderen Beobachter
weiterleitet.
Mediator - Vermittler
Ein Vermittler ist ein Objekt, welches die Kommunikation anderer Objekte organisiert, indem
er Nachrichten weiterleitet. Da die beteiligten Objekte sich nicht kennen müssen, fördert
dieses Muster die lose Kopplung der Objekte. Im Organicer wird diese Kommunikation mit
dem in Abschnitt 3.4.2 vorgsetellten Signal-Slot-Konzept umgesetzt, so dass auch der Me-
diator seine Beobachter nicht kennen muss. Um die Einzigartigkeit des Mediators zu sichern
wird dieser als Singleton implementiert. Die im Organicer verwendete Mediatorklasse, der
OpMediator, ist eine Ableitung der Mediator-Klasse, die Teil der SceneHandler-Bibliothek
(siehe Kapitel 4.1.1) ist und besitzt neben den Möglichkeiten der Oberklasse, anwendungs-
spezifischen Erweiterungen.
Das Diagramm 3.26 zeigt, wie eine Update-Nachricht eines Beobachters vom Mediator
weitergeleitet wird .
Model-View-Controller
Mit dem MVC-Prinzip kann eine interaktive Anwendung in drei Komponenten (siehe
) aufgeteilt werden. Das Model enthält die Kerndaten der Anwendung und ist un-
abhängig von speziellen Ausgabeformaten oder Eingabemöglichkeiten. Deshalb ist es mög-
lich, eine andere Ansicht der Daten zu entwickeln ohne Veränderungen am Model vornehmen
41

KAPITEL 3. GRUNDLAGEN
zu müssen. In einem Programm zur 3D-Visualisierung verwaltet das Model Bilddaten, mit
den zugehörigen Materialeigenschaften und Spezifikationen (siehe Kapitel 5.4). Diese Da-
ten sollen auf verschiedene Arten dargestellt werden können. Die Ansichten (engl. views)
präsentieren diese Informationen und bilden mit den Steuerungskomponenten (Controller)
die Benutzerschnittstelle.
Kompositum
Die Klassenbibliothek Qt (Abschnitt 3.4.2) benutzt wie die meisten Klassenbibliotheken
zur Erstellung von Benutzerschnittstellen das Kompositum-Muster. Dabei wird die Graphi-
sche Benutzerschnittstelle aus Komponenten zusammengefügt, die entweder aus einfachen
oder zusammengesetzten Fenstern bestehen. Da alle diese Komponenten von einer gemein-
samen Oberklasse abgeleitet sind, verfügen sie über gemeinsame geerbte Methoden, die
den Umgang mit den verschiedenen Widgets erleichtern. Deshalb lassen sich beispielswei-
se einfache und zusammengesetzte Widgets beim Erstellen eines Layouts mit demselben
SetPosition-Aufruf positionieren.
Einfache Fenster sind beispielsweise Buttons oder Listviews, während die selbst definierten
Customwidgets auch Container für verschiedene Fenster sein können. Eine für das Kom-
positionsmuster typische Objektstruktur könnte wie in Abbildung 3.27 aussehen und auf
ähnliche Weise ist auch die Oberfläche des Organicers gestaltet (siehe Kapitel 5.5). Dabei
nehmen das Mainframe und die Customwidgets als Container andere Objekte, wie Buttons
und ein Listview auf.
3.4.2 Die Klassenbibliothek Qt
Qt ist eine C++-Klassenbibliothek, mit der plattformunabhängige Programme entwickelt
werden können. Dabei bietet Qt zum Aufbau einer Benutzerschnittstelle verschiedene Fens-
ter wie Frames, Buttons, Dialoge und Listviews an. Diese sind alle von der Oberklasse
QWidget abgeleitet und können als Container andere Widgets aufnehmen. Mit der OpenGL-
Extension bietet Qt die Möglichkeit an, Anwendungen in der Bildverarbeitung zu entwickeln
und stellt ein QGLWidget mit einem gültigen OpenGL-Kontext zur Verfügung.
Das Qt-Objektmodell
Eine modulare, objektorientierte Programmierung wird dabei insbesondere durch den Signal-
Slot-Mechanismus und der Möglichkeit, Customwidgets zu entwickeln und diese für ver-
42

1
CustomWidget
n
1
Button
1
MainWidget
Button
Listview
1 1
n
1
CustomWidget
3.4. GRUNDLAGEN DER INFORMATIK
WidgetStack
1
1
Button
1
1
Widget
1 1 1
n n n
Button
Abbildung 3.27: Benutzerschnittstelle als Kompositum-Muster
schiedene Anwendungen nutzen zu können, unterstützt. Der Signal-Slot-Mechanismus dient
Objekten zur Kommunikation innerhalb eines Qt-Programms. Dabei werden die Ereignisse
(Signals) beispielsweise von Steuerelementen ausgelöst und ein Empfänger (Slot) reagiert
auf dieses Signal. Der Sender des Signals muss seinen Empfänger nicht kennen. Mit diesem
Nachrichtenkonzept wird eine Kommunikation der Komponenten, aber auch eine modula-
re Programmentwicklung ermöglicht. Mit dem Qt-Designer steht ein Tool zur Erstellung
von Benutzeroberflächen zur Verfügung. Die Formulare und Bilder eines Projektes werden
in Projektdateien (.pro) gespeichert und können dazu genutzt werden, plattformspezifi-
sche Makefiles zu erzeugen. Die Informationen zu den Formularen werden in Dateien im
XML-Format gespeichert, aus denen die Header- und Source-Dateien des Formulars gene-
riert werden. Zusätzliche Informationen der Formulare werden in speziellen Header-Dateien
(ui.h) abgelegt und welche zum Source-Code eingebunden.
Mit der Möglichkeit Customwidgets enzwickeln zu können, erleichtert Qt die Entwicklung
von Komponenten, welche in verschiedenen Anwendungen in die Benutzerschnittstelle ein-
gebaut werden können.
43

KAPITEL 3. GRUNDLAGEN
44

4.1 Der Organicer Prototyp
4 Stand der Technik
Der Organicer wurde zur Unterstützung von Leberoperationsplanungen entwickelt und wird
auf diesem Gebiet seit 2002, in Zusammenarbeit mit der Chirurgischen Universitätsklinik
Heidelberg eingesetzt. Dabei zeichnet sich dieses Visualisierungstool insbesondere durch
seine Funktionalität aus. Deshalb werden im Anschluss die SceneHandler-Bibliothek, die
Transparenzdarstellung und das Einteilen eines Gefäßbaumes dargestellt.
4.1.1 Die SceneHandler-Bibliothek
Die SceneHandler-Bibliothek stellt das Darstellungsfenster der Anwendung zur Verfügung,
in der Oberflächenmodelle visualisiert und interaktiv verändert werden. Dieses Fenster ist
von der Klasse QGLWidget (siehe Kapitel 3.4.2) abgeleitet und eignet sich deshalb zur
Darstellung von Visualisierungen mit OpenGL. Um dem Benutzer die Möglichkeit zu bieten,
die Szene aus verschiedenen Blickrichtungen zu betrachten ist es möglich, diese Szene zu
rotieren oder transformieren (siehe Abschnitt 3.3.1). Durch diese Navigationsmöglichkeit,
kann ein Gefäßbaum bei der Einteilung in Segmente (Abschnitt 4.1.2), in verschiedene
Richtungen bewegt und markiert werden.
Auf welche Art, Oberflächenmodelle dargestellt werden, ist in den verschiedenen
Visualisierer-Klassen festgelegt. Diese Visualisierer werden einem Datenelement (Kapitel
5.4.1) zugeordnet und können dieses auf verschiedene Arten darstellen (Kapitel 5.3.2).
Darstellung transparenter Objekte
Bei einer 3D-Rekonstruktion der Leber mit Oberflächenmodellen ist es notwendig Tumore
innerhalb der Gefäßhülle sehen zu können. Deshalb muss die Darstellung der Leberhülle mit
transparenten Eigenschaften möglich sein. Die Abbildung 3.10 zeigt an einem einfachen
Beispiel, die Visualisierung eines Objektes mit transparenten Oberflächeneigenschaften. Bei
der Darstellung von transparenten Objekten verändert die Reihenfolge der Visualisierung das
Visualisierungsergebnis. Für eine korrekte Darstellung müssen die Elemente in Blickrichtung
45

KAPITEL 4. STAND DER TECHNIK
sortiert und die näher zum Betrachter liegenden Dreiecke über die entfernteren gezeichnet
werden.
Blickrichtung
(a) Raumunterteilung
1
2
Blickrichtung
Abbildung 4.1: Verfahren der Transparenzdarstellung
(b) Sortierung aller Dreiecke
Die Zahlen kennzeichnen die Reihenfolge der Darstellung
Im Organicer sind zwei Verfahren zur Sortierung der Dreiecke von Oberflächenmodellen
realisiert, die in der Abbildung 4.1 veranschaulicht werden. Die Qualität der Transparenz-
darstellung richtet sich dabei nach der Auswahl der, zur Sortierung verwendeten, Elemente.
Abbildung 4.1(a) zeigt ein Verfahren, bei dem die Dreiecke nicht einzeln sortiert, sondern
die Szene nach einem Oktreeverfahren (siehe Kapitel 5.16(a)) in Raumteile bzw. Würfel
zerlegt wird. Eine weitere Möglichkeit, ist die Sortierung der einzelnen Dreiecke (Abbil-
dung 4.1(b)). Beide Verfahren verwenden die Schwerpunktkoordinaten der Elemente als
Sortierkriterium.
In der Abbildung 4.1(a) ist ein Problem des Raumunterteilungsverfahrens, auf zwei Di-
mensionen übertragen, dargestellt. Die Dreiecke innerhalb eines Würfels bleiben unsortiert.
Deshalb kann es passieren, dass entferntere Dreiecke (rotes Dreieck), über näher liegende
Dreiecke (blaues Dreieck) gezeichnet werden und es dadurch in den Bereichen der Überla-
gerung, zu einer fehlerhaften Darstellung kommt.
Die Abbildungen 4.1 zeigen, dass bei bestimmten Konstellationen nur die Sortierung über
46
2
1

die einzelnen Dreiecke eine korrekte Darstellung ermöglicht.
+z
Abbildung 4.2: Transparenzdarstellung
y
x
-z
4.1. DER ORGANICER PROTOTYP
Dies alleine reicht aber nicht aus, da
sich bei einer interaktiven Anwendung die
Blickrichtung durch Ansichts- oder Mo-
delltransformationen (siehe 3.3.1) ändern
kann, müssen die Sortierungen in verschie-
denen Richtungen möglich sein. Dazu ver-
fügt die Klasse ElementOrganizer über drei
Listen, in denen die x-,y- und z-Werte der
Schwerpunktskoordinaten gespeichert wer-
den. Da die Listen eine aufsteigende und
absteigende Sortierung anbieten, können
auf diese Weise 6 verschiedene Richtungen
repräsentiert werden. Damit ist es möglich
eine Sortierung entlang der drei Achsen des Koordinatensystems der Szene in positiver oder
negativer Richtung durchzuführen.
Um während der Visualisierung die Blickrichtung angeben zu können, wird die Szene in 6
Pyramiden aufgeteilt. In Abbildung 4.2 soll der rote, transparente Würfel die gesamte Szene
darstellen. Verläuft der, vom Beobachter zum Ursprungspunkt gerichtete, Sehstrahl durch
den Bereich der beiden grünen Pyramiden, werden die Elemente in z-Richtung sortiert.
4.1.2 Einteilung eines Gefäßbaumes
Die, bei einer Leberoperationsplanung verwendeten, Gefäßbäume können durch eine Baum-
oder Graphstruktur symbolisch beschrieben und in einem speziellen Format (.ves) gespei-
chert werden.
Diese Beschreibung enthält die Informationen über die Lage der Verzweigungs- und End-
punkte und den Durchmesser der Gefäße. Um diese Informationen zu erhalten, werden in
den Bilddaten die Gefäße segmentiert, mit einer Skelettierung auf eine eindimensionale Li-
nie reduziert, der Durchmesser bestimmt und das Ergebnis als Graph oder Baum abgelegt
(siehe ).
Der zwischen zwei Verzweigungspunkten liegende Gefäßabschnitt, ist ein VesselElement.
Ein VesselElement verläuft durch eine bestimmte Anzahl von Voxeln, die in der Abbildung
4.3(a) rot markiert sind und ist die kleinste Einheit, die einem bestimmten Gefäß- oder
47

KAPITEL 4. STAND DER TECHNIK
(a) Darstellung Gefäßbaum
Abbildung 4.3: Einteilung eines Gefäßbaumes
Segment 1 Segment 2
1
1
1
2
2
(b) Eingeteilter Gefäßbaum
Segmenttyp (siehe Kapitel 3.1.1), durch eine Identifikationsnummer zugeordnet werden
kann. Für diese Zuordnung muss der Gefäßbaum interaktiv bearbeitet werden.
Zur Visualisierung werden die Informationen über den Gefäßbaum aus einer Datei (.ves)
gelesen und die Punkte des Gefäßbaumes mit Linien oder Zylindern verbunden. Mit dem
Picking-Mechanismus von OpenGL können in der Szene vorhandene Objekte mit der Maus
selektiert werden. Nach dem Einstellen eines speziellen Rendermodus zur Selektion wird die
Szene nach dem Rendern nicht in den Bildspeicher eingetragen, sondern die Identifikations-
nummern der VesselElemente in einen speziellen Puffer geschrieben. Nach einem Mausklick
kann in diesem Puffer nach Objekten gesucht werden, die im Bereich der Mausposition
liegen und deren Indentifikationsnummer abgefragt werden.
Die auf diese Weise selektierten VesselElemente können auf drei verschiedene Arten markiert
werden:
48
Markierung des Bereiches zwischen zwei Verzweigungspunkten.
2

Markierung vom Gefäßelement zur Wurzel des Gefäßbaumes.
Markierung vom Gefäßelement zu den Endpunkten.
4.1.3 Workflow Leberoperationsplanung
1.
2.
3.
4.
5.
6.
7.
8.
9.
Segmentierte Bilddaten auf
Festplatte exportieren
Pic-Volumen erstellen
Pic-Volumen skalieren
Oberflächen erzeugen
Gefäßbaum segmentieren
Gefäßbaum einteilen
Segmente berechnen
Resektionsvorschlag
bestimmen
Restvolumen bestimmen
Diagramm 4.4:
Workflow
4.1. DER ORGANICER PROTOTYP
Eine spezifische Planung von Leberoperationen ist, wegen der
individuell stark variierenden Ausprägung der Leber, Grundlage
eines Therapieerfolgs. Eine wichtige Aufgabe ist es, den Gefäß-
baum zu analysieren und in Segmente einzuteilen (vergl. Kapitel
3.1.1). Nach der Bestimmung der Lage der Gefäße relativ zu den
Tumoren wird ein Resektionsvorschlag erstellt, der diejenigen
Segmente berücksichtigt, die zu einem Versorgungsbereich der
tumornahen Gefäße gehören. Im allgemeinen wird davon ausge-
gangen, dass der Resektionsvorschlag einen Sicherheitsabstand,
von mindestens 0.5 cm berücksichtigen muss.
Das verbleibende Restvolumen entscheidet über die Durchführ-
barkeit einer Leberoperation, da dieses die postoperative Leber-
leistung bestimmt. Dabei reichen ca. 50% Restleberparenchym
zur Regeneration der Leber aus. In den 4-5 Wochen nach einer
solchen Operation, wächst die Leber wieder zu ihrer ursprüngli-
chen Größe heran.
Das Diagramm 4.4 zeigt den Workflow einer Operationspla-
nung, der mit dem Exportieren der Bilddaten aus dem Te-
leradiologiesystem CHILI beginnt. Für die Erzeugung des PIC-
Volumens, der Skalierung und der Oberflächenerzeugung muss
jeweils ein neues Tool verwendet werden.
Aus den Segmentierungsergebnissen werden die Oberfläche des
Tumors und die Leberhülle generiert. Die Gefäßbäume werden
aus dem Pic-Volumen über ein Volume-Growing-Verfahren (Ka-
pitel 3.1.6) bestimmt. Zur Einteilung wird der Gefäßbaum im Organicer visualisiert und
interaktiv bearbeitet (Abschnitt 4.1.2). Nach der Speicherung dieser Einteilung dient der
Gefäßbaum, zusammen mit der Leberhülle, als Grundlage zur Bestimmung der Leberseg-
mente.
49

KAPITEL 4. STAND DER TECHNIK
4.2 Andere Systeme
Der Organicer profitiert vor allem von der engen Zusammenarbeit mit der Radiologie und
Chirurgie der Universitätsklinik Heidelberg (siehe Abbildung 2.1). So wird jede Leberope-
rationsplanung von Experten aller drei Fachrichtungen (Chirurgie, Radiologie, Informatik)
besprochen, um die Diagnose und Durchführung der Operationen zu optimieren. Dieser
routinemäßige Einsatz der Software, hat zu einer fortschreitenden Verbesserung der Funk-
tionalität und Benutzbarkeit geführt. Darüber hinaus wird das Softwaresystem durch bereits
veröffentlichte und derzeit laufende Studien evaluiert.
Operationsplanungen im Bereich der Leberchirurgie werden derzeit von zwei weiteren Grup-
pen angeboten. Die Arbeitsgruppe des Instituts MeVis in Bremen wendet zur Durchführung
ihrer Planungen vergleichbare Methoden wie der Organicer an. MeVis verfolgt zur Zeit einige
Ziele (siehe ), wie die systematische Evaluierung und die Verfeinerung der
3D-Interaktion zur Spezifikation von Resektionsgebieten, bei denen das Softwaresystem Or-
ganicer einen Vorsprung aufweist. Dies könnte darauf zurückzuführen sein, dass MeVis der
routinemäßige Einsatz im klinischen Betrieb fehlt, ohne den eine Evaluierung und Weiterent-
wicklung eines Operationsplanungstools nicht möglich ist. Nur durch diesen Praxiseinsatz
können die Operationsvorschläge des Organicers innerhalb einer Bearbeitungszeit von einer
Stunde angeboten werden. Dies ist für die klinische Akzeptanz von erheblicher Bedeutung.
Eine vergleichbare abgesicherte Maßzahl liegt für das MeVis-System nicht vor. Während
MeVis in unterschiedlichen Bereichen (z.B. Segmentierung, Gefäßbaumtrennung) auf auto-
matische Verfahren setzt, benutzt die Operationsplanung der MBI-Abteilung des DKFZ in
diesen Bereichen interaktive Mechanismen. Ein Vorteil der interaktiven Methode ist darin
zu sehen, dass automatische Verfahren niemals eine 100%-tige Fehlerfreiheit garantieren
und somit eine interaktive Nachbearbeitung notwendig ist. MeVis und die MBI-Abteilung
arbeiten zur Zeit an der Bemaßung einer 3D-Visualisierung und der Farbcodierung von
Abständen wichtiger Strukturen (siehe Kapitel 5.7).
Die zweite Gruppe, die sich mit Visualisierungen der Leber beschäftigt, ist die von Luc Soler
geleitete IRCAD Gruppe in Strassburg. Dort werden allerdings keine Operationsvorschläge
berechnet, sondern lediglich Segmentanatomien erstellt. Auch hier werden wie bei MeVis
automatische Verfahren zur Extraktion der acht Lebersegmente eingesetzt, die die oben
genannten Nachteile vorweisen.
50

4.2. ANDERE SYSTEME
Durch die Entwicklung des Teleradiologiesystems CHILI zu einer Visualisierungsplattform,
ensteht ein weiterer Vorteil der Operationsplanungen in Heidelberg, da hiermit die Seg-
mentierungen, die Gefäßbaumanalyse und die Visualisierung der Ergebnisse innerhalb einer
Programmumgebung möglich ist. Ein solches System steht MeVis und IRCAD für ihre Pla-
nungen nicht zur Verfügung.
51

KAPITEL 4. STAND DER TECHNIK
4.3 Das Teleradiologiesystem CHILI
Das Teleradiologiesystem CHILI wurde vom Steinbeis-Transferzentrum Medizinische Infor-
matik (STZ-MI) in Heidelberg entwickelt und ist seit 1998 im Einsatz. Zur Erklärung des
Begriffes Teleradiologie dient die Definition von Engelmann et al. in :
” Die Aufgabe der Teleradiologie ist die Übertragung von radiologischen Bildern
von einem Ort zu einem anderen zwecks Interpretation und Konsultation. Die
digital übertragenen Bilder können anschließend an verschiedenen Orten gleich-
zeitig dargestellt, bearbeitet und besprochen werden.“
4.3.1 Aufbau des Teleradiologisystems CHILI
Das Teleradiologiesystem verfügt über eine DICOM-Schnittstelle über die Bilddaten zur
Verfügung gestellt werden können. Radiologische Bilder können aus verschiedenen bildge-
benden Geräten (Modalitäten) in CHILI integriert und dort in einer PostgreSQL Datenbank
gespeichert werden. Der Datentransfer basiert idealerweise auf dem radialogischen Kommu-
nikationsstandard DICOM, darüber hinaus können aber auch andere Datenformate impor-
tiert oder exportiert werden. Intern arbeitet CHILI mit dem, in Kapitel 3.1.5 vorgestellten
PIC-Format und stellt in der PlugIn-Schnittstelle die Daten auch in diesem Format zur
Verfügung-
CHILI PlugIn Konzept
CHILI bietet durch ein PlugIn Konzept die Möglichkeit, die Software den individuellen Anfor-
derungen der Kunden anzupassen. Die Schnittstelle der Zusatzmodule ist in einem PlugIn
Software Developer Kit offengelegt. Die Zusatzmodule, mit der die Funktion von CHILI
erweitert werden kann, werden beim Start von CHILI dynamisch geladen.
PACS
Ein PACS (Picture Archiving and Comminacation System) dient zur Speicherung, Verwal-
tung, Übermittlung und Darstellung digitaler medizinischer Bilddaten. Das digitale Archiv
besteht dabei aus einer Datenbank, in der Daten über Bilder und Patienteninformationen
eingetragen werden. Zu einem Pacs gehört weiterhin ein Massenspeicher auf dem die Bild-
daten abgelegt sind. Dieser Speicher ist so aufgebaut, dass auf aktuelle Daten möglichst
52

4.3. DAS TELERADIOLOGIESYSTEM CHILI
schnell zugegriffen werden kann. Darüberhinaus steuert ein PACS die automatische Über-
tragung der, durch bildgebende Geräte erzeugten, digitalen Bilddaten. Das CHILI-System
kann als regulärer PACS-Arbeitsplatz zur Diagnose und Bildbetrachtung eingesetzt werden
( siehe ) und damit die Möglichkeit der einfachen und sicheren Bildübertragung
an andere Stellen, sowie die Möglichkeit interner und externer Telekonferenzen bieten.
Datenbankanbindung
Der Aufbau der PostgreSQL Datenbank ist auf das, im Kapitel 3.1.1 bechriebene, DICOM-
Datenmodell ausgerichtet. Für die DICOM-Objekte Patient, Studie, Serie und CT-Bild
werden durch die Datenbankobjekte patient t, study t, series t und image t die DICOM-
Informationen und weitere interne Daten repräsentieren und als Tabellen darstellen. Die
eigentlichen Bilddaten werden aber nicht in der Datenbank gespeichert, sondern das Da-
tenbankobjekt image t erhält jediglich den Pfad, an dem die Bilddaten auf der Festplatte
liegen. Mit dem Datenbankobjekt text t ist das Eintragen von Textinformationen in die
Datenbank möglich.
Zugriff auf die Datenbankinformationen
Abbildung 4.5:
Lichtkasten
Die graphische Oberfläche von Chili bietet drei verschiedene Datenbank-
ansichten bzw. Auswahlmöglichkeiten an (Abbildung 5.19). In den Aus-
wahlfenstern für Studie und Serie sind die aktuell ausgewählten Einträge
grau unterlegt. Im Lichtkasten von CHILI ist der Zugriff auf die Bild- und
Texteinträge der aktuellen Serie möglich. In der Abbildung 4.3.1 zeigt der
Lichtkasten Bilder einer Originalserie an, während in Abbildung 5.19 die
Szeneninformationen des Organicer-PlugIns durch Icons repräsentiert wer-
den.
53

KAPITEL 4. STAND DER TECHNIK
54

5 Praktische Realisierung
Innerhalb dieses Kapitels werden zuerst die zu behebenden Mängel des Organicer Prototypen
aufgelistet, bevor ein Soll-Konzept die Lösung dieser Probleme beschreibt. Die weiteren
Abschnitte beschreiben die praktische Umsetzung dieser Lösungen.
Zur Beschreibung und Dokumentation der Designmaßnahmen wird die Unified Modeling
Language (UML) verwendet, die u.a. in den Büchern und beschrieben
ist. Die Notation der Aktivitätsdiagramme ist aus übernommen. Zur Beschrei-
bung der Synchronisation von Aktivitäten können Folgeaktivitäten nicht nur beim Vorliegen
aller Eingangsaktivitäten starten (UND-Synchronisation), sondern schon beim Vorliegen ei-
ner (XOR-Synchronisation) bzw. mindestens einer eingehenden Aktivität (OR). Außerdem
ermöglicht diese Notation das wiederholte Ausführen von Aktivitäten, die innerhalb eines
schwarzen Balkens mit der Bezeichnung“* for each ...”und eines Synchronisationsbalkens
liegen. In den Aktivitätsdiagrammen 5.25 und 5.10 wird diese Notation benutzt, um Akti-
vitäten zu beschreiben, die nacheinander für alle Elemente der Datenliste (siehe Abschnitt
5.4) ausgeführt werden.
Dabei sind in den Klassen- und Objektdiagrammen nur diejenigen Methoden und Attribute
berücksichtigt, die für das Verständnis der Dokumentation notwendig sind und auf die in der
begleitenden Beschreibung eingegangen wird. Die Implementierung benutzt dabei C++ als
objektorientierte Programmiersprache und verwendet die in Abschnitt 3.4.1 aufgeführten
Entwurfsmuster zur Verbesserung der Programmstruktur.
5.1 Ist-Analyse
Der Organicer ist als Prototyp eines Visualisierungstools vorhanden und kann in der Lebe-
roperationsplanung eingesetzt werden. Allerdings bestehen bei dem jetzigen Ablauf einige
Mängel:
5.1.1 Datentransfer
• Durch die fehlende Integration des Organicer und der verschiedenen zur Bildaufbe-
reitung benötigten Tools in das Teleradiologiesystem, müssen die Bilddaten auf den
55

KAPITEL 5. PRAKTISCHE REALISIERUNG
lokalen Fileserver exportiert werden.
• Die Ergebnisse der Operationsplanung müssen zur Validierung beim Radiologen, zur
Präsentation bei der chirurgischen Besprechung und zu einer Visualisierung, während
einer Operation, auf ein Laptop übertragen werden. Für diese drei Anlässe muss ein
DKFZ-Mitarbeiter Termine mit den betreffenden Personen ausmachen und sich mit
dem Laptop in die Klinik begegeben.
• Zur Präsentation der Ergebnisse wird ein DKFZ-Mitarbeiter benötigt, der die 3D-
Rekonstruktionen im Organicer vorstellt.
Diese Mängel beschränken den Einsatz der computergestützten Operationsplanung, in der
klinischen Routine, da die ersten beiden Punkte zu einer redundanten und inkonsistenten
Datenhaltung führen. Außerdem müssen für die verschiedenen Präsentationen Termine mit
den jeweiligen Teilnehmern vereinbart werden, die im klinischen Alltag nicht immer zu finden
sind. Des weiteren muss der DKFZ-Mitarbeiter für diese Termine Zeit einplanen, wodurch
Personalkosten entstehen, die einem Einsatz dieser Operationsplanungen, als Dienstleis-
tungsangebot, entgegenstehen.
5.1.2 Bildverarbeitung
Zur Weiterverarbeitung der Segmentierungsergebnisse werden neben dem Organicer, drei
weitere Tools eingesetzt. Mit einem dieser Programme werden die segmentierten Einzel-
schichten zu einem Pic-Bildvolumen 3.1.5 zusammengesetzt und auf der Festplatte abge-
speichert. Falls nach einer Verbesserung der Segmentierung kein Export der Daten erfolgt
und das PIC-Volumen neu erstellt wird, führt dies zu einer fehlerhaften Darstellung.
5.1.3 Programmstruktur
56
• Die Programmstruktur ist nur mit einer automatisch generierten Dokumentation be-
schrieben, die eine eingeschränkte Perspektive auf das Softwaremodell bietet und keine
dynamischen Aspekte der Anwendung berücksichtigt.
• Die Anwendungsdaten werden in verschiedenen Listen gehalten, die alle seperat ak-
tualisiert werden müssen. Durch diese dezentrale, redundante Datenhaltung, wird die
Fehleranfälligkeit und Komplexität des Programmes erhöht. Auch der Datenaustausch

5.2. SOLL-KONZEPT
ist nicht einheitlich organisiert, sondern verwendet neben einer Datei mit der Szenen-
beschreibung im XML-Format, eine Binärdatei pro vorhandenem Datenelement zum
Abspeichern der Materialeigenschaften.
5.2 Soll-Konzept
Die in der Ist-Analyse beschriebenen Mängel sollen beseitigt und die Durchführung von
Operationsplanungen im Teleradiologiesystem CHILI möglich sein.
5.2.1 Datentransfer
• Die PlugIn-Version des OrganNicers soll aus den, in der CHILI-Datenbank abgeleg-
ten, Segmentierungsergebnissen Oberflächenmodelle erzeugen, damit keine Bilddaten
exportiert werden müssen.
• Die Ergebnisse der Operationsplanung sollen mit dem webbasierten Informationssys-
tem über ein Netzwerk für die verschiedenen Präsentationen angeboten werden. Dazu
sollen die 3D-Rekonstruktionen in das internetgeeignete VRML-Format ( siehe 3.3.6)
umgewandelt werden. Da die VRML-Szenen in einem einfach zu bedienenden Plu-
gIn eines Webbrowsers darzustellen sind, wird für diese Art der Präsentation kein
DKFZ-Mitarbeiter mehr benötigt.
• Integration aller zu einer Operationsplanung benötigten Tools in das Teleradiologie-
system CHILI.
5.2.2 Bildverarbeitung
Die PlugIn-Version soll, die zu einer Segmentierungsserie gehörenden Einzelbilder, mit einer
Anfrage an die CHILI-Datenbank selektieren und aus diesen, ohne Abspeichern des Pic-
Volumens, ein Oberflächenmodell erzeugen. Vor der Visualisierung der Oberflächenmodelle
soll überprüft werden, ob die zugrundeliegenden Segmentierungsergenisse verbessert wurden,
um das Darstellen inkonsistenter Daten zu verhindern.
5.2.3 Programmstruktur
57

KAPITEL 5. PRAKTISCHE REALISIERUNG
• Die Dokumentation soll durch eine detaillierte Beschreibung der Programmentwurfs
das Verständis des Softwaresystems verbessern. Dabei sollen die dynamischen Aspek-
te der Anwendung durch Aktivitätsdiagramme und Sequenzdiagramme beschrieben
werden.
• Die Daten sollen in einer zentralen Datenliste gehalten werden, wodurch eine modula-
re Programmstruktur unter Verwendung des Model-View-Controller Entwurfsmusters
(Abschnitt 5.3.1) möglich ist. Zur Vereinfachung des Datenaustausches soll ein ein-
heitliches Dateiformat zur Szenenbeschreibung entwickelt (siehe Abschnitt 5.4.4)
werden und die zum Datenaustausch entwickelten Strukturen in seperate Klassen
gekapselt werden.
5.2.4 Funktionserweiterung
• Durch die Entwicklung einer PlugIn-Adapterklasse soll der Zugriff auf die Datenbank
des Teleradiologiesystems möglich sein. Daneben sollen weitere neue Klassen den
Umgang mit den im Pic-Format vorliegenden Bilddaten ermöglichen.
• Zur Verbesserung der Qualität der Leberoperationsplanung sollen der Abstand der
Gefäße zum berechnet und ein Sicherheitsbereich um den Tumor farblich markiert
werden können.
• Die Entwicklung einer Materialklasse soll eine einheitliche Materialverwaltung bei der
Verwendung von OpenGL- und VTK-Visualisierungen ermöglichen. Diese Klasse soll
in Verbindung mit einem Fenster der Benutzeroberfläche die Materialzuweisung an
die Szenenobjekte vereinfachen.
5.3 Einsatz der Entwurfsmuster
5.3.1 Model-View-Controller
Das Klassendiagramm 5.1 zeigt vereinfacht die Umsetzung des Model-View-Controller Prin-
zips im Organicer, indem es sich auf die wichtigsten Klassen konzentriert und die Dialoge,
Toolbars und Popupmenus nicht berücksichtigt. Der in Abschnitt ?? vorgestellte Media-
tor enthält als Model des MVC-Entwurfsmusters, die Kernfunktionalität und die Daten der
58

View Modell View + Controller
SceneHandler
Mediator
paintGL()
mousePressEvent()
mouseMoveEvent()
Mediator
Elementorganizer
Datenliste
updateMVC()
getElementOrganizer()
getDataNode()
Controller
PropertyWidget InteractionWidget
5.3. EINSATZ DER ENTWURFSMUSTER
Mediator
Datenansicht
slotUpdateListView()
editProperty(ViewProperty*)()
updateMVC()
Abbildung 5.1: Model-View-Controller Prinzip
Anwendung. Aufgrund seiner Einzigartigkeit eignet er sich dazu, die anderen einzigartigen
Objekte der Anwendung, wie Elementorganizer (siehe 4.1.1) und Datenliste (Abschnitt
5.4.2), zu verwalten und anderen Objekten über geeignete Methoden den Zugriff zu ermög-
lichen.
Der Mediator erfüllt dabei die im Sequenzdiagramm 3.26 dargestellte Aufgabe, die Beob-
achter (Views und Controller) zu benachrichtigen und organisiert gleichzeitig den Zugriff auf
die Datenliste. Die in Abschnitt 5.6.2 beschriebene Datenansicht kann den Steuerelemen-
ten und den Ansichten zugeordnet werden, da sie die Datenliste in einer bestimmten Form
anzeigt, aber auch als Steuerelement die Möglichkeit bietet, diese zu verändern. Mit dem
Propertywidget sind Veränderungen an den Materialeigenschaften der Datenelemente mög-
lich (siehe 5.6.1). Das Interactionwidget wird bei der Einteilung der Gefäßbäume verwendet
(siehe 4.1.2). Der SceneHandler ( siehe 4.1.1) ist dagegen ein reines Ansichtenobjekt, mit
einer Funktion die auf die Aktualisierungsnachricht des Mediators reagiert.
5.3.2 Strategiemuster
Die Darstellung bestimmter Visualisierungsdaten kann nicht nur in verschiedenen Ansich-
ten, sondern auch mit unterschiedlichen Algorithmen erfolgen. Die Äste der Gefäßbäume
(siehe Kapitel 4.1.2) können mit Linien oder Zylindern dargestellt werden oder die Oberfä-
chenmodelle, je nach gewünschter Qualität der Transparenzeigenschaften, unterschiedlich
aufwendig sortiert werden. Durch Kapselung dieser Algorithmen in Klassen, mit einer ge-
meinsamen Schnittstelle, werden sie von den Datenobjekten entkoppelt und können separat
geändert oder ausgetauscht werden.
Die Auswahl, welcher Algorithmus zum Darstellen der Datenelemente verwendet wird, er-
folgt im Organicer in einem eigenen Modul, dem ElementOrganizer. Das Sequenzdiagramm
59

KAPITEL 5. PRAKTISCHE REALISIERUNG
ElementOrganizer DataNode STLVisualizer
setStrategie(Transparence)
STLVisualizer*
drawElement(int id)
Abbildung 5.2: Strategie Transparenzdarstellung
5.2 zeigt die Auswahl eines Visualisierers für STL-Oberflächenmodelle, für die der Elemen-
tOrganizer eine Strategie vorschlägt und dem erhaltenen STLVisualizer die Identifizierungs-
nummer eines zu visualisierenden Oberflächenelementes übergibt.
5.4 Datenhaltung
Das in Abschnitt 5.3.1 besprochene MVC-Muster zeigt die zentrale Rolle der Daten in
einer interaktiven Anwendung. Deshalb muss dem Design der Datenhaltung auch besondere
Aufmerksamkeit geschenkt werden.
5.4.1 Die Datenelemente der Visualisierung
Die Abbildung 5.3 zeigt die Vererbungshierachie der Klassen zur Darstellung der Daten-
elemente. Der Name DataNode wurde von der Darstellungmöglichkeit in einem Szenegraph
abgeleitet, dabei enthält ein Datenelement in der Visualisierung, neben den eigentlichen
Bilddaten, Informationen über Materialeigenschaften und zusätzliche Spezifikationen, wie
z.B Name oder Typ. Der Aufbau dieser Klassen wurde größtenteils übernommen, deshalb
gibt die Darstellung der Klassenstruktur nur einen Einblick in den Aufbau der Klassen, der
aber zum weiteren Verständniss ausreicht.
Um die in die in den Abschnitten 5.6.1 und 5.7 beschriebenen Funktionserweite-
rungen durchführen zu können wurden Erweiterungen der Klassen vorgenommen, wie
z.B. das Hinzufügen der ViewProperty-Klasse, mit der die zur Visualisierung benötigten
Materialzuweisungen vorgenommen werden. Diese Materialgebung erfolgt bei den STL-
Oberflächenmodellen einheitlich, während bei den Gefäßbaumklassen jedem Gefäßabschnitt,
60

virtual Visualizer* setStrategie(DataNode::Strategie);
virtual void setName(QString);
virtual void setType(QString);
virtual vtkPolyData* getPolyData();
virtual ViewProperty* getProperty(QString);
virtual addProperty(QString);
virtual bool save(const char* filename);
virtual bool load(const char* filename);
QString myType;
QString myName;
enum Strategie{Line,Cylinder,Transparence,HighQuality};
QPtrList PropertyList;
vtkPolyData* polyData;
Mediator* mediator;
SurfaceNode
STLTriangleData* getTriangle(int);
void setVisualizer(Visualizer*);
void setHQVisualizer(Visualizer*);
STLVisualizer* mySTLVisualizer;
STLHQVisualizer* hqSTLVisualizer;
STLTriangleList* triangle;
DataNode
VesselTreeNode
void initScalars(ViewProperty*);
int getLookupTableIdx(ArTreeIterator);
int getLookupTableIdx(int);
LineTreeVisualizer* myLineTreeVisualizer;
CylinderTreeVisualizer* myCylinderTreeVisualizer;
vtkPointLocator* locator;
5.4. DATENHALTUNG
Abbildung 5.3: Die Klassen der Gefäßbäume und Oberflächenmodelle
der eine Anzahl von Punkten repräsentiert (siehe Kapitel 4.1.2), ein skalarer Wert zuge-
wiesen wird (siehe Abbildung 5.13), über den die Materialeigenschaften bestimmt werden
können.
61

KAPITEL 5. PRAKTISCHE REALISIERUNG
Color
Data-
Node
DataList
Materialproperties
Scene
Version
Data-
Node
Color
Titel
Materialproperties
Abbildung 5.4: Organicer Scenegraph
5.4.2 Zentrale Verwaltung der Daten
void dataListAppend(DataNode* );
void dataListRemove(int);
int dataListCount();
DataNode* getDataNode(int);
QPtrListIterator getDataListIterator();
1
1
62
1
Mediator
DataList
DataNode
ViewProperty
1
1
1
Material
Properties
n
n
Color
Abbildung 5.5: Datenmanagement
1
1
Der in Abbildung 5.4 dargestellte Graph
zeigt die in einer Organicer-Szene vorhan-
denen Elemente. Diese Darstellung soll die
dreidimensionale Szene in einem Diagramm
darstellen, entspricht aber nicht dem klas-
sischen Szenegraph-Konzept. Die Szene er-
hält einen Titel und eine Information über
die verwendete Organicer-Version. Die ei-
gentlichen Bilddaten werden mit den Farb-
und Materialeigenschaften einem Datenk-
noten zugeordnet. Alle in der Szene vorhan-
denen Datenknoten werden in einer gemein-
samen Datenliste gespeichert.
Für die Verwaltung der zentralen
Datenhaltung bietet sich die Me-
diatorklasse an, da er von allen
Objekten der Anwendung ange-
sprochen werden kann. Er verwal-
tet die Datenelemente der Anwen-
dung in einer Datenliste, die eine
von Qt implementierte Template-
Pointerklasse verwendet. Der Me-
diator verfügt zum Datenmanage-
ment über eine Reihe von Funk-
tionen, mit denen die elementaren
Operationen wie das Einfügen und
Löschen von Datenelementen, die
Abfrage der Anzahl von Datenele-
menten, der Zugriff auf Datenele-
mente über einen Iterator und das

Abfragen eines Datenelementes über einen Index möglich sind.
5.4.3 Kapselung der I/O-Funktionalität in Klassen
DataReader
DataNode* loadNode(QString fileName)
ViewProperty* loadProperty(DataNode*,QDomDovument&)
SceneReader
void slotReadOCN(QString fileName)
OrganicerWidget
1 1
1 1
5.4. DATENHALTUNG
DataWriter
void saveDataNode(DataNode*,QString)
void saveProperty(ViewProperty*,QString)
SceneWriter
void slotSaveOCN(QString fileName)
Abbildung 5.6: An der Datenspeicherung beteiligte Klassen
Zur persistenten Speicherung von Szenen oder verwendeten Materialeigenschaften auf der
Festplatte und zum Laden dieser gespeicherten Daten, wurden mehrere Klassen entwickelt,
die spezielle Funktionen bzw. Strategien kapseln. Dadurch wird die Übersichtlichkeit und
Verständlichkeit der Programmstruktur erhöht und Veränderungen können lokal an den
beteiligten Klassen vorgenommen werden.
Diese Klassen werden als Reader- und Writerklassen bezeichnet und verwenden zur Daten-
speicherung das XML-Format (siehe ), das als Sprache zur Beschreibung von
strukturierten Daten und Dokumenten die Möglichkeit bietet, die Elemente des Organicer-
Scenegraphs in Textform aufzuführen. Qt bietet zum Umgang mit XML-Dokumenten eine
Schnittstelle an, die u.a. die Konvertierung eines XML-Dokumentes in einen String und die
Schreib- und Leseoperationen auf die Festplatte unterstützt.
Die Abbildung 5.6 zeigt die Beziehungen der IO-Klassen untereinander und ihre Zuord-
nung zum OrganicerWidget (siehe Abbildung 5.11), so dass sie in der Standalone- und in
der PlugIn-Version verfügbar sind. In den Oberklassen DataReader und DataWriter werden
diejenigen Funktionen implementiert, die von unterschiedlichen Teilen der Anwendung ge-
nutzt werden. Die Abbildungen 5.4.3 und 5.4.3 zeigen das Zusammenspiel verschiedener
Objekte bei den Aktivitäten Laden und Speichern von Materialeigenschaften, die beide von
der Datenansicht (siehe Abschnitt 5.6.2) ausgelöst werden. Im Abschnitt 5.8 wird die
63

KAPITEL 5. PRAKTISCHE REALISIERUNG
Konvertierung und persistente Speicherung im VRML-Format beschrieben.
DataListView
loadProperty(DataNode* Message2() node)
OpMediator
Nachricht
weiterleiten
()
loadProperty(DataNode* node)
loadProperty(DataNode* node,
QDomNode& doc)
Nachricht
weiterleiten
OrganNicerFrame \
OrganNicerPluginFrame
Materialdatei
auswählen
XML-Dokument
erzeugen
DataReader
loadProperty(DataNode* node,QDomNode& doc) XML-Dokument
parsen
Abbildung 5.7: Sequenzdiagramm ViewProperty laden
Das in der Datenansicht ausgewählte Element wird, durch die Vermittlung des Mediators,
mit der Aufforderung zum Laden neuer Materialien der Rahmenklasse der Anwendung über-
geben. In der Standalone-Version wird mit einem Dateidialog eine Materialdatei im Datei-
system ausgewählt, während die Materialdateien der PlugIn-Version über den Lichtkasten
(siehe Kapitel 4.3) ausgewählt werden können. In der Frameklasse wird das XML-Dokument
aufgebaut und mit dem Datenelement zusammen, durch Vermittlung des Mediators, dem
DataReader übergeben. Die loadProperty-Funktion des DataReaders parst das Dokument
mit den Materialeigenschaften und weist diese dem Datenelement zu. Beim Lesen einer
Szene durch den SceneReader wird dieselbe loadProperty-Funktion benutzt, so dass keine
Redundanz von Code ensteht.
Beim Speichern von Materialeigenschaften übernimmt der DataWriter die Aufgabe, die
Eigenschaften des ViewProperty-Objekts in ein XML-Dokument zu schreiben. Dieses Do-
kument wird in der Standalone-Version als Textdatei gespeichert und in der PlugIn-Version
als Texteintrag in die CHILI-Datenbank eingetragen.
64

DataListView \
SceneWriter
saveProperty(ViewProperty* vp,
QString filename)
OpMediator
Nachricht
weiterleiten
()
saveProperty(ViewProperty* vp,
QString filename)
saveProperty(QString vp,
QString filename)
Nachricht
weiterleiten
DataWriter
XML-Dokument
erzeugen
saveProperty(QString vp,
QString filename)
5.4. DATENHALTUNG
OrganNicerFrame \
OrganNicerPluginFrame
Abbildung 5.8: Sequenzdiagramm ViewProperty speichern
5.4.4 Das Dateiformat der Szenenbeschreibung
Organicer 1.9.2 RELEASE CANDIDATE
Unknown patient
STL
XML-Dokument
speichern
..\pacs\db\patientUID\studyUID\seriesUID\Tumor.stl
two tumor
true
1
10
0
0.8
0.4
0.2
65

KAPITEL 5. PRAKTISCHE REALISIERUNG
1
Listing 5.1:Organicer Dateiformat
Das Listing 5.1 zeigt als Beispiel den Inhalt eines XML-Dokumentes, welches eine Szene
mit einem STL-Oberflächenmodell enthält. Dieses Model ist aus der Segmentierung zweier
Tumore entstanden und besitzt aus Datenschutzgründen den Titel“Unknown Patient”. Da
die Oberfläche von STL-Modellen einheitlich visualisiert wird, besitzt die Lookuptabelle der
ViewProperty-Eigenschaft nur einen Eintrag, über den die Farbe zugeordnet wird.
Aktivitätsdiagramm Datei oder Szene laden
Das Aktivitätsdiagramm 5.25 zeigt die verschiedenen Möglichkeiten, Datenelemente zu
einer Szene hinzuzufügen. Da diese sich zwischen der Standalone- und PlugIn-Version un-
terscheiden, gibt es im Diagramm zwei verschiedene Startpunkte. Die Standalone-Version
bietet die Möglichkeit Dateien oder Szenen durch Kommandozeilenargumente zu übergeben
oder über Dateidialoge auszuwählen. In der PlugIn-Version gibt es zur Auswahl von Dateien
und Szenen unterschiedliche Vorgehensweisen. Die zu einer Serie gehörenden Szenen werden
in einer eigenen Serie, der OrganicerSerie, welche im Lichtkasten von CHILI angezeigt wird
und die Selektion der Szene ermöglicht ( siehe Kapitel 4.3).
66

{XOR}
Kommandozeilenargumente
übergeben
{XOR}
*for all
DataNode
{ AND }
XML-Dokument
parsen
Standalone
Materialeigenschaften
einlesen
{ XOR }
Dateidialog öffnen
[.ocn ]
[.stl oder .ves ]
{ XOR }
Datei auswählen
OrganNicerSerie
suchen
[existiert]
Dateiendung überprüfen
for one
DataNode
Daten laden
DatenListe aktualisierien
{ AND }
{ AND }
al l
DataNode
{ AND }
Studie auswählen
OrganNicerSerie in
LightBox anzeigen
[.pic && ! plugin ]
[.pic && plugin]
[ ok ]
PlugIn
Serie auswählen
Derivate in DataList
-View anzeigen
Existenz und
Aktualität überprüfen
[ ! ok ]
PIV-Volumen skalieren
STL-Volume erzeugen
Standarderte für Materialien setzen
{ XOR }
Abbildung 5.9: Aktivität Laden von Daten
5.4. DATENHALTUNG
Nach der Auswahl einer Serie mit
Originalbildern werden die Segmentie-
rungsergebnisse dieser Serie in der Da-
tenansicht (siehe Abschnitt 5.6.2)
angezeigt und können dort ausge-
wählt werden. Die Endung der aus-
gewählten Datei entscheidet über das
weitere Vorgehen. Bei einer Szene-
Datei (.ocn) werden die einzelnen
gespeicherten Datenelemente geladen
und mit den in der Datei aufge-
führten Materialeigenschaften visuali-
siert. Dateien, die Informationen zu
einzelnen Datenelementen enthalten,
werden geladen und mit Standard-
materialwerten dargestellt. Bei der
Auswahl eines Pic-Volumens über-
prüft die PlugIn-Version, ob ein STL-
Oberflächenmodell zu diesem Volumen
vorhanden ist und die einzelnen seg-
mentierten Schichten des Volumens
nach der Erstellung dieses Oberflä-
chenmodells verbessert wurden. Falls
das Oberflächenmodell aktuell ist und
existiert wird es geladen, ansonsten
muss es mit dem in Abschnitt 5.9.4
vorgestellten Ablauf erzeugt werden.
Nach dem erfolgreichen Laden eines
Datenelementes wird die Datenliste
aktualisiert.
67

KAPITEL 5. PRAKTISCHE REALISIERUNG
Plugin
DataList-Popupmenu
benutzen
for one
DataNode
Toolbar benutzen
Speichermodus wählen
* for all
DataNode
Datenliste iterieren
Aktivitätsdiagramm Datei oder Szene speichern
[ Scene speichern ]
Daten auf Platte speichern
[ einzelne Datei
speichern ]
Neue Serie in Chili-
Datenbank eintragen
{ XOR }
Dateidialog öffnen
Spezifikationen in
XML-Dokument eintragen
Materialeigenschaften in
XML-Dokument eintragen
[ Scene speichern ] [ Standalone ]
[ existiert nicht ]
Scene als Text in
OrganNicer-Series speichern
{ XOR }
all
DataNode
{ XOR }
{ XOR }
{ XOR }
OrganNicer
-Serie suchen
[ existiert ]
Standalone
Scenedatei auf
Platte speichen
Abbildung: 5.10: Aktivität Speichern von Daten
68
Da in der PlugIn-Version zusätzliche
Dialoge unerwünscht sind, verfügt nur
die Standalone-Version über einen Da-
teidialog zum Speichern. Das Schrei-
ben einzelner Datenelemente auf die
Festplatte ist mit einem Popupme-
nu der Datenansicht (siehe Abbildung
5.6.2 ) möglich. Soll die gesamte Sze-
ne gespeichert werden, schreibt der
SceneWriter (siehe Abschnitt 5.4.3)
die Elemente der Datenliste mit ih-
ren Spezifikationen und Materialeigen-
schaften im Organicer-Dateiformat in
ein XML-Dokument. Nach dem Spei-
chern der Datenelemente auf der Fest-
platte ist bei einer einzelnen Datei
der Ablauf beendet, während beim
Speichern einer Szene noch die XML-
Szenenbeschreibung gespeichert wer-
den muss. Im Standalonebetrieb wird
die Szene in eine Datei geschrie-
ben, während die PlugIn-Version erst
überprüft, ob zu der aktuellen Se-
rie mit Originalbildern eine Organicer-
Serie existiert und diese bei negati-
ver Prüfung angelegt. Zu dieser Se-
rie wird ein Texteintrag in die CHILI-
Datenbank eingetragen, in den die
XML-Szenenbeschreibung geschrieben
wird.

5.5. AUFBAU DER GRAPHISCHEN BENUTZEROBERFLÄCHE
Die beiden Buttons zum Abspeichern der Bilddaten befinden sich in einer Toolbar des
OrganicerWidgets und bieten folgende Funktionalität an :
Alle Datenelemente der Szene auf die Festplatte schreiben.
Nach dem Abspeichern der gesamten Datenelemente wird eine Szenedatei erzeugt und
abgespeichert.
5.5 Aufbau der graphischen Benutzeroberfläche
Für die Benutzerschnittstelle gibt es besonders häufig Änderungsanforderungen, da sie bei
jeder Funktionserweiterung angepasst werden muss. Damit diese Änderungen leicht durch-
zuführen sind, ist die Oberfläche des Organicers durch die Umsetzung des MVC-Musters
(siehe Kapitel 5.3.1) von den Daten entkoppelt. Der Aufbau der Benutzeroberfläche wur-
de größtenteils übernommen. Für die, in den Abschnitten 5.6.2 und 5.9 beschriebenen
Erweiterungen, wurde die Komponente PropertyWidget entwickelt und die Komponente
DataListView in ihrer Funktion erweitert. Diese Maßnahmen wurden mit dem GUI-Designer
von Qt umgesetzt (siehe Kapitel 3.4.2).
InteractorControls
OrganicerFrame /
OrganicerPluginFrame
OrganicerWidget
SceneHandler
Property-
Widget
DataListView
Abbildung 5.11: Aufbau der GUI
Bei der Gestaltung der Oberfläche wurde
auch berücksichtigt, dass die Anwendung
als Standalone- und als PlugIn-Version ge-
nutzt werden kann. Aus diesem Grund
sind diejenigen Teile, die in beiden Nut-
zungsarten benötigt werden, im Organi-
cerWidget (in Abbildung 5.11 rot unter-
legt) zusammengefasst. Dieses Organicer-
Widget wird je nach Anwendungsart in
verschiedene Rahmenfenster eingebunden
(in Abbildung 5.11 rot unterlegt). Das Framefenster der Standalone-Version (Organicer-
Frame) besitzt zusätzliche Toolbars und Menudialoge, die das Rahmenfenster der PlugIn-
Version (OrganicerPluginFrame) nicht benötigt.
Qt bietet die Möglichkeit eigene Widgets als Customwidgets zu definieren und diese in ver-
schiedenen Anwendungen einzusetzen. In Abbildung 5.11 sind die verschiedenen Custom-
widgets der Organicer-Oberfläche zu sehen, die nach dem Kompositum-Muster (Kapitel
3.4.1) zusammengesetzt sind.
69

KAPITEL 5. PRAKTISCHE REALISIERUNG
5.6 Neugestaltung der Materialverwaltung
5.6.1 Viewproperty Klasse
In der entwickelten Version des Organicers werden veschiedene Visualisierungstechniken ver-
wendet. Die Visualisierung der Szene im SceneHandler mit OpenGL wurde übernommen.
Darüberhinaus wird mittlerweile aber auch das Visualization Toolkit (siehe Kapitel 3.3.4)
zur Materialverwaltung, zum Exportieren einer VRML-Szene und zur Berechnung des Sicher-
heitsabstandes eingesetzt. Die Viewproperty-Klasse wurde mit dem Ziel entwickelt, beide
Visualiserungstechniken mit einer einheitlichen Datenhaltung, in einer Anwendung nutzen
zu könnnen. Jedem Datenelement wird wie im Diagramm 5.5 dargestellt, eine Instanz dieser
Klasse zugeordnet, mit der die Materialeigenschaften des Elementes festgelegt werden.
ViewProperty
void setDiffuseColor(int lut,float*);
float* getDiffuseColor(int lut);
vtkFloatArray* getScalars();
vtkPolyData* getPolyData();
vtkFloatArray* scalars;
vtkLookupTable* lut;
vtkPolyData* polyData;
vtkFloatArray* shininess;
vtkFloatArray* emission;
bool visibility;
Abb. 5.12: ViewProperty-Klasse
Die Klassenbeschreibung 5.12 zeigt einige Elemente
und Methoden der ViewProperty-Klasse. Eine wich-
tige Funktion erfüllt dabei die vtkLookupTable, die
die Farben des Datenelementes führt. Die Größe der
Lookuptabelle hängt von der Art des Datenelementes
ab und variiert von einer Farbe für Oberflächenmo-
delle bis zu 30 für Gefäßbaummodelle, bei denen allen
Segmenten und Sektoren eigene Farben zugeordnet
werden können. Die verschiedenen Funktionen zum
Verändern der Eigenschaften eines Datenelementes
arbeiten wie die Funktion zum Setzen oder Abfragen von Farbeigenschaften, der ein In-
dex der Lookuptabelle und die neuen Farbwerte übergeben. Auf die gleiche Weise arbeiten
auch die Funktionen zur Änderung der Materialeigenschaften (Brightness, Shininess und
Emission).
Das Setzen von Farbeigenschaften ist ein gutes Beispiel, wie in der Visualisierung den Punkt-
daten eines Objektes, skalare Werte zugeordnet werden und wird mit der Abbildung 5.13
und der folgenden Beschreibung verdeutlicht. Den sieben Punkten des Polydata-Datasets
wird in einem Array ein Skalarwert zugeordnet, der als Index für eine Lookuptabelle dient.
5.6.2 DataListView
In der Datenansicht ist eine visuelle Darstellung der Szenen-Objekte mit einer baumartigen
Struktur, die über mehrere Spalten aufgebaut werden kann, möglich. Diese Komponente
70

Polydata
7
5
2 3
1
4
0
6
5.6. NEUGESTALTUNG DER MATERIALVERWALTUNG
Skalararray
Punkt ID
0 1 2 3 4 5 6
3 2 2 0 3 2 0
Skalarwert
Abbildung 5.13: Farbwertzuordnung über Skalare
7
1
id
0
1
2
3
Lookuptable
r g
b
0.80.3
0.8
0.10.3
0.1
0.3 0.10.8
0.10.8
0.9
wurde in das MVC-Konzept integriert (siehe Abschnitt 5.3.1) und wird bei einer Änderung
der Szenenobjekte benachrichtigt, um sich anschließend zu aktualisieren.
Um verschiedene Arten von Daten im DataListView darstellen zu können wurden neue
Klassen von Listvieweinträgen gebildet:
• Ein DataCheckListItem repräsentiert ein Datenelement der Datenliste. Aktive Gefäß-
bäume werden mit grüner Farbe hervorgehoben.
• Die PlugIn-Version verwendet blau gezeichnete SeriesCheckListItems um segmentierte
Serien darzustellen (Abschnitt 5.9.4).
• Zur Darstellung der Gefäßbaum-Datenelemente werden SegmentListItems verwendet.
Dabei sind die aufgeführten Gefäßabschnitte mit derselben Farbe gezeichnet, mit der
sie im SceneHandler (Kapitel 4.1.1) visualisiert sind.
71

KAPITEL 5. PRAKTISCHE REALISIERUNG
Abbildung 5.14: Datenansicht
Das PropertyWidget
Durch die Selektion eines Dateneintrages wird
seine Sichtbarkeit im SceneHandler geändert
werden. Zur Veränderung der Materialeigen-
schaften von Datenelementen musste im Pro-
totyp des Organicers ein modaler Dialog geöff-
net werden. Zur Erleichterung dieser Einstellun-
gen wurde ein neues Customwidget, das Pro-
pertyWidget, das in die Oberfläche des Organi-
cers (Abschnitt 5.6.2) integriert ist, entwickelt.
Nach der Auswahl eines Eintrages in der Daten-
ansicht wird dieses Element im PropertyWidget
aktiv und kann in seinen Materialeigenschaften
verändert werden.
Mit einem Popup-Menu, das sich beim Ankli-
cken mit der rechten Maustaste öffnet, können
weitere Interaktionen vorgenommmen werden.
Dazu gehören das Speichern und Löschen von
Datenlementen, Speichern und Laden von Ma-
terialeigenschaften und das Spezifizieren eines
Datenelementes durch eine Beschreibung.
Das in der Abbildung 5.15 dargestellte PropertyWidget besitzt zwei Funktionen:
◮ Die Veränderung von Materialeigenschaften ist in Zusammenarbeit mit der Datenan-
sicht möglich. Dazu wird in der Datenansicht ein Oberflächenmodell oder ein Ab-
schnitt eines Gefäßbaumes ausgewählt und diesem, durch Veränderung der Sliderein-
stellungen, neue Materialwerte zugordnet.
◮ Berechnung eines Sicherheitsabstandes (siehe Abschnitt 5.7)
72

5.7. BERECHNUNG DER DISTANZ ZWISCHEN TUMOR UND GEFÄSSEN
Das Modul wurde mit dem Ziel entwickelt, die enthaltenen Steuerelemente (ColorSlider und
SliderWidget) für die beiden genannten Funktionen benutzen zu können.
� Farbauswahl: Das SliderWidget zeigt eine Regenbogenskala an (Abschnitt 5.19) und
der ColorSlider dient zur Farbauswahl.
� Sicherheitsabstand: Mit dem ColorSlider wird die Größe des Sicherheitsabstandes einge-
stellt, der im SliderWidget mit einer Rot-Blau-Skala veranschaulicht wird und oberhalb
des STL-ListView als Wert [mm] angezeigt wird.
5.7 Berechnung der Distanz zwischen Tumor und Gefäßen
Für den Erfolg einer Operation zur Entfernung von Lebertumoren ist die räumliche Bezie-
hung der Tumore zum Gefäßverlauf von entscheidender Bedeutung. Bei der Resektion des
Tumors muss das Lebergewebe, das innerhalb eines Sicherheitsabstandes von 0.5 cm liegt,
mitentfernt werden. Die Abbildung 5.19 zeigt eine Szene mit Gefäßbaum, zwei Tumoren und
den für die Operation vorgeschlagenen Resektionsvolumina. Falls in dem Sicherheitsbreich
Gefäße verlaufen, werden die von ihnen versorgten Lebersegmente bei der Resektion mitent-
fernt. Bis jetzt wurde dieser Abstand empirisch bestimmt, so dass keine exakte Beurteilung
über die Entfernung der Strukturen möglich war.
SceneHandler
SliderWidget
STL-ListView
ColorSlider
Abbildung 5.15: Einsatz des PropertyWidget zur Berechnung des Sicherheitsabstandes
73

KAPITEL 5. PRAKTISCHE REALISIERUNG
Dieser Abschnitt beschreibt den Weg zur exakten Bestimmung eines Sicherheitsabstandes,
durch den die Qualität eines Resektionsvorschlages erhöht wird. Die Gefäßbaum- und Ober-
flächenmodelle werden aus einzelnen Punkten aufgebaut, die unstrukturiert im Raum verteilt
sind.
root
(1.Stufe)
(2.Stufe)
(a) Oktree Raumunterteilung
root
1.Stufe
2.Stufe
Abbildung 5.16: Aufteilung des 3D-Raumes
1.Punkteliste
2. Punkteliste
3. Punkteliste
4. Punkteliste
5. Punkteliste
6. Punkteliste
7. Punkteliste
8. Punkteliste
9. Punkteliste
10. Punkteliste
…
64. Punkteliste
(b) Locator Punkteliste
Eltern
Oktanten
Abschluss
Oktanten
Die Datenelemente der Gefäßbaummodelle verfügen über einen vtkPointLocator, der mit
einem Octree-Raumunterteilungsverfahren, die Szene in Würfel aufteilt (siehe Abbildung
5.16(a)). Dieses Verfahren kann in mehreren Stufen durchgeführt werden, wodurch der 3D-
Raum in gleichgroße Würfel und einer gleichmäßigen Struktur aufgeteilt wird. Dadurch kann
jeder Punkt der Szene über seine Koordinaten eindeutig einem Würfel zugordnet werden. Der
vtkLocator vergibt für jeden Würfel eine Punkteliste, in der die Punkte des Gefäßbaumes,
die sich innerhalb des Würfels befinden, gespeichert werden (siehe Abbildung 5.16(b)).
Unter Verwendung dieser Strukturen ist es möglich, effektive Suchoperationen innerhalb
eines Bildvolumens durchzuführen.
Das PropertyWidget verfügt über eine Listenansicht, in der die Namen der Tumore angezeigt
werden und eine Auswahl möglich ist. Nach der Auswahl der Tumore und der Einstellung
des Sicherheitsabstandes mit dem ColorSlider, können alle Punkte des Gefäßbaumes, die
74

5.8. EXPORTIEREN VON VRML-SZENEN
sich innerhalb des Sicherheitsabstandes befinden, bestimmt werden. Hierzu wird für jeden
Punkt eines Tumor-Oberflächenmodells untersucht, in welchem Würfel er sich befindet und
der Abstand zu den Gefäßbaumpunkten des Würfels bestimmt. Da auch Gefäßbaumpunkte
der Nachbarwürfel innerhalb des Sicherheitsabstandes liegen könnnen, muss auch für alle
Punkte dieser Würfel der Abstand berechnet werden. Alle untersuchten Punkte des Gefäß-
baumes deren Abstand zu mindestens einem Punkt des Tumors, kleiner als der vorgegebene
Sicherheitsabstand ist, werden jetzt rot markiert werden (Abbildung 5.15).
5.8 Exportieren von VRML-Szenen
Zur Zeit ist es ein wichtiges Ziel im Bereich der Operationsplanung, die 3D-Rekonstruktionen
über das Internet verschiedenen Partnern anbieten zu können (siehe ). Dieser Ab-
schnitt zeigt, wie eine Organicer-Szene in das VRML-Format (siehe Kapitel 3.3.6) umge-
wandelt wird und dadurch mit einem Webbrowser dargestellt werden kann.
Diese Umwandlung erfolgt in der entwickelten Klasse VRMLExporter unter Verwendung
des Visualization Toolkits (VTK). Die Grundlage hierzu bietet aber die besprochene
ViewProperty-Klasse, die die Materialeigenschaften der Datenelemente mit Strukturen des
Visualization Toolkits ( vtkLookupTable, vtkFloatArray ) organisiert und damit eine Visua-
liserung mit VTK ermöglicht. Zum Export einer Szene mit VTK werden die verschiedenen
Objekte in einem vtkRenderWindow visualisiert und anschließend mit einem vtkVRMLEx-
porter in Textformat in eine Datei geschrieben.
Zur Visualisierung der Objekte mit VTK, müssen die Objekte der Organicer-Szene im
vtkPolyData-Format vorliegen oder in dieses Format umgewandelt werden. Die STL-Dateien
können mit einem vtkSTLReader vom Dateisystem gelesen werden, der das gewünschte
vtkPolyData-Dataset liefert.
Die Gefäßbaumobjekte müssen allerdings erst in eine polygonale Datenstruktur konvertiert
werden. Dazu werden die vorhandenen Punkten des Gefäßbaumes (siehe Kapitel 4.1.2) mit
Zylindern verbunden.
4
3
2
9
Gefäßbaumpunkte
0
1
5
6
Abb. 5.17 Gefäßbaumrepräsentation
8
7
Diese Aufgabe erledigt der vtkTubeFilter, der die
Verbindungszylinder durch Pyramidenstümpfe, mit
einer bestimmbaren Anzahl von Ecken, annähert
und als Ausgabe ein polygonales Dataset liefert. Die
Abbildung 5.17 zeigt wie aus zwei Punkten des Ge-
fäßbaumes, eine Pyramide mit fünf Ecken entsteht.
75

KAPITEL 5. PRAKTISCHE REALISIERUNG
Die Materialeigenschaften der Gefäßbaummodelle werden über die Einteilung der VesselEle-
mente zu bestimmten Gefäßtypen bestimmt und müssen den Punkten der PolyData-Objekte
über skalare Werte, die den Identifikaktionsnummern der Gefäßtypen entsprechen, zugeord-
net werden.
Segment 1 Segment 2
1
2
1
1
2
2
Skalararray
0 1 2 3 4 5 6 7
1 1 1 1 1 1 1 1
8 9
...
...
Skalarwert = Identifikationsnummer
Punkt ID
51 52 53 54 55
1 1 2 2 2 2 2
Abbildung 5.18: Farbzuordnung bei Gefäßbäumen
id
0
1
2
3
Lookuptable
r g
b
0.80.3
0.8
0.10.3
0.1
0.3 0.10.8
0.10.8
0.9
Die Anzahl der Punkte die im PolyData-Dataset ein VesselElement repräsentieren, ist von
der Anzahl der Punkte des VesselElementes abhängig. Diese liegen im Mittelpunkt der
Grundfläche bzw. Deckfläche der Pyramidenstümpfe, die zur Verbindung der Punkte dienen.
Die Abbildung 5.18 geht davon aus, dass die Pyramidenstümpfe fünf Ecken besitzen. Ein
VesselElement mit zwei Punkten wird dann nach der Verbindung mit Pyramidenstümpfen,
durch 10 Eckpunkte repräsentiert, die über die Identifikationsnummer als skalarer Wert
die Information des Gefäßtyps erhalten und mit einer dem Gefäßtyp zugeordneten Farbe
dargestellt werden.
76

5.9 Entwicklung PlugIn-Adapterklasse
5.9. ENTWICKLUNG PLUGIN-ADAPTERKLASSE
Die Abbildung 5.19 zeigt den Einsatz des Organicers als PlugIn, dabei befindet sich der
Arbeitsbereich des Organicers innerhalb der roten Umrandung.
Studienauswahl Serienauswahl
Lichtkasten
SceneHandler
Resektionsvorschlag
Tumor
Abbildung 5.19: CHILI-Teleradiologiesystem
PropertyWidget
( Darstellung der Resektionsvolumina in beiger Farbe )
DataListView
Das Teleradiologiesystem CHILI bietet mit einem PlugIn-Mechanismus und einer offengeleg-
ten Schnittstelle (siehe ), die Möglichkeit Zusatzmodule zur Funktionserweiterung
zu entwickeln. Da das CHILI Softwaresystem zur Zeit aber, von einer UNIX-Implementierung
auf eine plattformunabhängige Qt-Version umgestellt wird und sich dadurch auch die PlugIn-
Schnittstelle ändern wird, wurde bei der Entwicklung des Organicer-PlugIns weitgehend auf
die Nutzung der Schnittstelle verzichtet, um spätere Änderungen zu minimieren. Des wei-
teren hat sich im Verlauf der Enwicklung des Organicer-PlugIns gezeigt, dass die Anforde-
rungen des Organicer-PlugIn’s durch die angebotene CHILI-Schnittstelle nicht ausreichend
77

KAPITEL 5. PRAKTISCHE REALISIERUNG
erfüllt werden.
Deshalb wurde zur Integration des Organicers eine eigene PlugIn-Schnittstelle entwickelt.
Die Kommunikation zwischen dem Teleradiologiesystem CHILI und dem Organicer über-
nimmt dabei eine Adapterklasse. Diese Klasse arbeitet mit den entwickelten Serien- und
Imageklassen zusammen, um Informationen über Serien und Bilder zu erhalten.
5.9.1 Die Adapterklasse OrganicerPluginFrame
ChiliPluginFrame
QString getAbsSeriesPath();
QString getRelSeriesPath();
bool insertTextToLB(QString,QString);
void insertPixmapToLB(char** pm,int pos);
// CHILI callbacks
void selectSeries(int ,void* user_data,void*);
void selectImage(int, void* user_data,void*);
char* getImageTypeFromSeries(char* seriesOID);
bool findSegmentationFromOrig(char* seriesOID);
void selectAllSeriesFromStudy(char* studyOID);
void selectSegmentationsFromOrig(char*):
void newOrganNicerSeries();
void initSegmentationSeries(SegmentationSeries*);
void findSTLFromSeries(SegmentationSeries*);
void findOrganNicerText();
void insertTextToSeries(char* seriesOID,QString text,QString mime,char* oid);
void getSeriesInformationFromOriginal();
void selectSeries();
void selectStudy():
void selectImage(int position);
void seriesListAppend(SegmentationSeries* );
SegmentationSeries* getSegmentationSeries(int id);
void serieListCount();
void slotLoadVolume(int id);
QPtrListIterator getSeriesListIterator();
void slotLoadProperty(DataNode*);
void slotSaveProperty(QString);
void slotExportVRML();
void slotSaveOCN(QString);
OrganNicerPluginFrame
OpMediator* mediator;
SliceInfo* sliceinfo;
ChiliSeries* originalSeries;
OrganNicerSeries* organNicerSeries;
QPtrList SeriesList;
Abbildung 5.20: Adapterklasse OrganicerPluginFrame
78

5.9. ENTWICKLUNG PLUGIN-ADAPTERKLASSE
Die Oberklasse ChiliPluginFrame wurde entwickelt um verschiedene spezielle PlugIns ent-
wickeln zu können. Dazu besitzt sie wie jede Oberklasse Methoden, die für alle speziellen
abgeleiteten PlugIn-Klassen interresant sind. Eine wichtige Funktion ist das Weiterleiten von
Nachrichten des CHILI-Programms, bei einer Änderung der aktuellen Patienten-, Studien-,
Serien-, Bild- oder Textauswahl.
Die OrganicerPluginFrame-Klasse ist eine spezielle PlugIn-Klasse, mit der die Organicer-
Applikation und das CHILI-Programm zusammenarbeiten, können.
Sie speichert verschiedene Informationen in ihren Attributen :
• Falls in der aktuellen Studie von CHILI eine OrganicerSerie (Abschnitt 5.9.4) vor-
handen ist, werden die Informationen in der Variablen organNicerSeries gehalten.
• Die Informationen über die aktuell ausgewählte Serie mit Originalbildern, enthält die
Variable originalSeries.
• In die SeriesList werden alle segmentierten Serien, der ausgewählten Serie mit Origi-
nalbildern, eingetragen.
Neben diesen Attributen besitzt die Adapterklasse verschiedene Methoden die zum Daten-
austausch benötigt werden und bei der Beschreibung der im Abschnitt 5.4.3 aufgeführten
Aktivitäten erwähnt wurden. Die Kommunikation zwischen CHILI und dem Organicer wird
durch die folgenden Methoden ermöglicht:
◮ Die Bestimmung des Typs (Original oder Segmentierung) einer Serie, mit der Funktion
getImageTypeFromSeries(), ist nur über die enthaltenen Bilder möglich. Deshalb muss
zuerst über eine Datenbankabfrage ein Bild dieser Serie selektiert werden, bevor mit
der getImageType-Funktion der SliceInfo-Klasse (Abschnitt 5.9.4), der Typ bestimmt
werden kann.
◮ Um alle segmentierten Serien einer Originalserie zu erhalten, können diese mit einer
Datenbankselektion in der Funktion findAllSeriesFromStudy() abgefragt und in die
SeriesList eingetragen werden.
◮ Beim Einsatz des Organicers in CHILI soll die Serienansicht, nur Serien mit Originalbil-
dern anzeigen, da die Segmenentierungsergebnisse in der Datenansicht des Organicers
angezeigt werden. Die Funktion selectAllSeriesFromStudy() implementiert eine Da-
tenbankabfrage, die die Originalserien zu diesem Zweck selektiert.
79

KAPITEL 5. PRAKTISCHE REALISIERUNG
◮ Zum Speichern einer Szene oder von Materialeigenschaften wird eine OrganicerSzene
benötigt, die mit der Funktion newOrganicerSeries() angelegt werden kann.
◮ Bei der Auswahl einer Studie wird mit der Funktion selectAllSeriesFromOrig(), nach
einer OrganicerSerie in der Studie gesucht. Falls eine OrganicerSerie gefunden wird,
werden ihre Informationen im Attribut organNicerSeries gespeichert und ihre Textein-
träge im Lichtkasten von CHILI angezeigt.
◮ In jeder segmentierten Serie wird mit der Funktion findSTLFromSeries() nach einem
Texteintrag, der das Oberflächenmodell des Segmentierungsergebnisses repräsentiert,
gesucht.
◮ Mit der Funktion insertTextToSeries() kann ein Text, der Oberflächenmodelle oder
Szenen repräsentiert, in die Datenbank zur aktuellen Studie eingetragen werden.
◮ Die Funktion getSeriesInformationFromOriginal() trägt den Spacing-Wert einer Serie
in eine Instanz der Klasse SegmentationSeries ein.
◮ Die Funktionen selectSeries(), selectStudy() und selectImage(int) werden durch die
Eventbehandlung in der ChiliPluginFrame-Klasse, nach einer Änderung in der Daten-
bankschnittstelle aufgerufen.
◮ Mit der Funktion serieListAppend() werden Serien mit Segmentierungsergebnissen in
die SeriesList eingetragen. Die Funktion getSeriesListIterator() ermöglicht den Zugriff
auf die SeriesList über einen Iterator.
◮ Nach der Auswahl eines SeriesCheckListItems in der Datenansicht des Organicers (Ab-
80
schnitt 5.6.2), wird das Volumen des Segmentierungsergenisses geladen (slotLoadVo-
lume(int)). Dabei wird die Existenz und Aktualität des Oberflächenmodells überprüft
und bei Bedarf, aus dem ImageVolume des Segmentierungsergebnisses, ein neues
Oberflächenmodell erzeugt.

5.9.2 Datenbankabfragen der Adapterklasse
patient_t
char* oid;
char* name;
study_t
char* oid;
char* instanceUID;
char* modality;
char* description;
1
n
series_t
char* oid;
char* instanceUID;
char* description;
1
text_t
1
n
char* oid;
char* chiliText;
char* mime_type;
n
1
n
image_t
char* oid;
char* instanceUID;
char* imageType;
char* path;
char* date;
char* time;
Abbildung 5.21: Datenbankobjekte
5.9. ENTWICKLUNG PLUGIN-ADAPTERKLASSE
Das in der Abbildung 5.21 dargestellte Klas-
sendiagramm zeigt die Beziehung zwischen den
Datenbankobjekten der CHILI-Datenbank und
ähnelt dabei dem DICOM-Objektdiagramm
aus Kapitel 3.6. Diese Objekte enthalten
neben einer eindeutigen Datenbank Objekt-Id
(oid), auch die in der Tabelle 3.2 aufgeführten
eindeutigen Instance UID des DICOM-Headers
zur Identifikation. Das Datenbankobjekt text t
wird vom PlugIn zur Speicherung der Szenen
und Materialeigenschaften verwendet. Eine
Organicer-Szene im XML-Format wird als
String im Attribut chiliText gespeichert und
erhält den mime type “OCN”. Dagegen wird
eine VRMLSzene vom VRMLExporter auf die
Festplatte geschrieben und die Pfadangabe
als chiliText angegeben, sowie der mime type
als “WRL” festgelegt. Bei den Imageobjekten
ist insbesondere die Pfadangabe wichtig, da sie zum Laden eines PIC-Bildes mit der
ipPicGet-Funktion der PIC-Bibliothek benötigt wird (siehe Kapitel 3.1.5).
Zur Umsetzung der Datenbankabfragen werden Routinen die auch das CHILI-System be-
nutzt, abgewandelt und in die Adapterklasse eingebaut. Diese Abfragen liefern als Ergebnis
(dbResult t), eine Liste aus Zeigern, auf die verschiedenen Datenbankobjekte der Selektion.
Diese Datenbankobjekte sind aber keine Objekte im objektorientierten Sinne, da sie über kei-
ne Methoden verfügen, die den Zugriff auf ihre Attribute ermöglicht, sondern als Strukturen
implementiert sind. Das weiteren sind, wie am Beispiel des Datenbankobjektes image t viele
benötigte Informationen nicht vorhanden. Bei der Bildklasse sind einige Informationen, die
für die Arbeit mit dem PlugIn benötigt werden, nicht direkt über das Bild-Datenbankobjekt
zu abzufragen, sondern erst nach dem Laden eines PIC-Bildes, im PIC- oder DICOM-Header
verfügbar.
Deshalb wurde die Klasse SliceInfo (Abschnitt 5.23) entwickelt, mit der es möglich ist,
Informationen über Schichtbilder zu erhalten.
81

KAPITEL 5. PRAKTISCHE REALISIERUNG
5.9.3 Die Imageklassen
ImageVolume
int getSize();
void addSlice();
void sortVolume();
Volume::iterator getSliceIterator();
vtkPolyData* getPolyData();
std::deque Volume;
Volume::iterator it;
Volume volume;
ImageSlice
void setPath(QString path);
void setZ(QString z);
void setNumber(int n);
int n,z;
QString path;
Abbildung 5.22: PlugIn-Imageklassen
Das in Kapitel 3.1.5 vorgestellte PIC-Format stellt zwar gegenüber dem DICOM-Format
mehr Informationen zur Verfügung, bei der Entwicklung der Adapterklasse hat sich aber her-
ausgestellt, dass diese nicht ausreicht. Deshalb wurden die in Abbildung 5.22 dargestellten
Imageklassen entwickelt, die den Umgang mit den Bilddaten vereinfachen. Die wichtigste
Funktion dieser Klassen ist das, in Abschnitt 5.9.4 beschriebene, Bereitstellen eines Oberflä-
chenmodells. Dazu werden die, durch die Klasse ImageData repräsentierten Einzelschichten,
in einer Containerklasse sequentiell angeordnet. Dieser Container bietet gegenüber einer An-
ordnung in einem PIC-Volumen einige Vorteile. Die enthaltenen ImageSlices können nach
bestimmten Kriterien sortiert werden, über einen Iterator ist ein einfacher Zugriff möglich
und die Klasse kann neuen Anforderungen angepasst werden.
5.9.4 Informationen über Schichtbilder
SliceInfo
char* getImageType(ipPicDescriptor*);
float getZValueFromPic(ipPicDescriptor*);
float getImageNumber(int);
char* getSeriesSourceUID(ipPicDescriptor*);
Vector3 getSpacingFromSlices(ipPicDescriptor* pic[2]);
Abbildung 5.23: Die Klasse SliceInfo
Im folgenden werden die verschiedenen Funktionen der Klasse SliceInfo, die die benötig-
82

5.9. ENTWICKLUNG PLUGIN-ADAPTERKLASSE
ten Schichtbild-Informationen über einen ipPicDescriptor aus dem PIC-Header abfragen,
vorgestellt:
◮ Die Methode getImageType() liefert den ImageType eines PIC-Bildes, der das Bild
z.B. als Originalbild oder Segmentierungsergebiss kennzeichnet. Diese Information
muss abgefragt werden, wenn eine Serie als Originalserie oder Segmentierungsergebnis
identifiziert werden soll.
◮ Um von einer Segmentierungsserie die Originalserie zu erhalten, muss die instan-
ceUID der Originalserie mit der Funktion getSeriesSourceUID(), über den Header
eines Schichtbildes der segmentierten Serie abgefragt werden.
◮ Die Anfangs- und Endposition des Patienten bei einer radiologischen Untersuchung,
bestimmen die Größe der Ausdehnung eines Bildvolumens in z-Richtung. Für jedes
einzelne Schichbild kann mit der Funktion getZValueFromPic() die Position innerhalb
dieses Volumens abgefragt werden.
◮ Die einzelnen Schichtbilder einer Serie sind in z-Richtung aufsteigend sortiert und mit
der ImageNumber nummeriert. Die Datenbank-Selektion aller Bilder einer Serie liefert
ein nicht sortiertes Volumen, dass mit der ImageNumber sortiert werden kann.
◮ Der Spacing-Wert beschreibt die Ausrichtung eines Volumens in x-y-z-Richtung. Dieser
Wert läßt sich durch die, in den PIC-Header eingetragene, Pixelgröße und durch den
Abstand zweier Schichten mit der Funktion getSpacingFromSlices() bestimmen.
83

KAPITEL 5. PRAKTISCHE REALISIERUNG
Die Serieninformations-Klassen
ChiliSeries
QString type;
double spacing[3];
QString description;
QString absolutPath;
QString relativPath;
QString chiliOID;
QString instanceUID;
SegmentationSeries
void setDateTime(char* date,char* time);
bool stlActual();
ImageVolume* getVolume();
QString stlPath;
QDateTime dateTime;
QDateTime stlDateTime;
bool stlFound;
OrganNicerSeries
QString vrmlOID;
QString sceneOID;
Abbildung 5.24: Serieninformations-Klassen
Das Organicer-PlugIn mehr Informationen
benötigt, als das Serienobjekt von CHILI
anbietet, wurden die, in der Abbildung 5.24
abgebildeten Klassen entwickelt, die zusätz-
lich die notwendige Funktionalität anbietet,
um mit diesen Klassen arbeiten zu können.
Zu den einzelnen Attributen der verschiede-
nen Klassen gibt es Set- und GetMethoden,
zum Abfragen bzw. Setzen der Werte. Mit
der SegmentationSeries-Klasse sin die In-
formationen über segmentierte Serien ver-
bunden. Bei der Initialiserung dieser Klasse
wird untersucht, ob zur Serie ein Oberflä-
chenmodell vorhanden ist und falls es exis-
tiert der Pfad und der Zeitpunkt der letzten
Modifikation gespeichert. Um die Aktualität eines Obeflächenmodells überprüfen zu können,
müssen in den Image-Datenbankobjekten einer segmentierten Serie, die Zeiten des Daten-
bankeintrages abgefragt werden und die jüngste Änderungszeit, mit der Modifikationszeit
der STL-Oberflächendatei verglichen werden.
84

PlugIn Workflow
PlugIn aktivieren
Studie auswählen
Serien selektieren
[ Originalserie ] [ OrganNicer-Serie ]
Anzeigen in
Chili-Serienansicht
Anzeigen in
Chili-Lichtkasten
Originalserie auswählen Szenendatei auswählen
Segmentierte Serien
selektieren
for each
Pfadangaben der Einzelbilder speichern
Erstellungsdatum abfragen
Existenz und Datum STL-Datei abfragen
for all
Szene laden
Anzeigen in DataListView
Segmentierte Serie auswählen
Aktualität STL-Datei überprüfen
[ aktuell ] [ nicht aktuell ]
STL-Daten laden
Abbildung 5.25:
STL-Daten erzeugen
Aktivätsdiagramm PlugIn-Workflow
5.9. ENTWICKLUNG PLUGIN-ADAPTERKLASSE
Das Diagramm auf dieser Seite beschreibt
den Arbeitsablauf nach dem Aktivieren des
Organicer-PlugIns. Durch die Farbunter-
legung der Symbole können die, an einer
Aktivität beteiligten Akteure, unterschie-
den werden. Den verschiedenen Akteuren
werden folgende Farben zugeordnet:
� Anfragen des PlugIns an die Chili-
Datenbank
� Auslesen von Header-Informationen
durch das PlugIn
� Eingaben des Benutzers
� CHILI-Aktionen
Symbole ohne Farbunterlegung repräsen-
tieren Aktionen des PlugIns. Nachdem
der Benutzer eine Studie ausgewählt hat,
werden in der Serienansicht von CHILI,
die zu dieser Studie gehörenden Serien
mit Originalbildern angezeigt. Falls eine
Organicer-Serie existiert, werden die vor-
handenen Organicer-Szenen als Einträge
im Lichtkasten angezeigt und können gela-
den werden (siehe Abbildung 5.25). Nach
der Auswahl einer Originalserie werden die,
von ihr abgeleiteten Serien, gesucht. Für
jede dieser Serien müssen die Einzelbilder
selektiert werden. Von den Schichtbildern
werden die Pfadangaben gespeichert und
in den Pic-Headern das Erstellungsdatum
abgefragt und das jüngste Datum als Seri-
endatum gespeichert. In der Datenansicht
kann der Benutzer eine segmentierte Serie
85

KAPITEL 5. PRAKTISCHE REALISIERUNG
zur Visualisierung auswählen. Wenn zu dieser Serie eine STL-Datei existiert und diese
aktuell ist, wird sie geladen. Andernfalls muss aus den Segmentierungsergenissen erst ein
Oberflächenmodell erzeugt werden.
Erzeugen von Oberflächen
Speicherplatz für Bildvolumen allokieren
für jede
Einzelschicht
Bilddaten von Platte lesen
Zum Bildvolumen kopieren
alle
Schichten
Bildvolumen skalieren
In vtkImage konvertieren
Binärvolumen erzeugen
Auflösung reduzieren
Binärvolumen glatten
Konturfläche erzeugen
Reduzierung der Dreiecke
vtkPolyData-Oberfläche glätten
STL-Daten laden
Abb. 5.26: Aktivitäten
STL-Erzeugung
86
Zur Erzeugung der Oberflächenmodelle wurde ein Ablauf erar-
beitet, der aus den, von CHILI angebotenen Schichtbildern,
STL-Daten erzeugt. Ziel ist es eine glatte Oberfläche, mit
möglichst wenig Polygonen herzustellen. Nachdem in der Da-
tenansicht des Organicers eine segmentierte Serie ausgewählt
ist, wird in der PlugIn-Adapterklasse geprüft, ob eine Neuer-
stellung eines Oberflächenmodells notwendig ist. Der in der
Abbildung 5.26 dargstellte Ablauf, findet in der getPolyDa-
ta-Funktion der ImageVolume-Klasse statt. Nach dem Laden,
der im PIC-Format auf der Festplatte abgelegten Schichtbilder,
mit der ipPicGet-Funktion, werden diese im Arbeitsspeicher zu
einer Bildsequenz zusammengefügt. Die im PIC-Format auf der
Festplatte gespeicherten Schichtbilder werden im Arbeitsspei-
cher zu einer Bildsequenz zusammengefügt. Mit der ipFuncS-
cale-Funktion wird das Bildvolumen isotrop, auf die Pixelgröße
(1,1,1) , skaliert. Um zur weiteren Verarbeitung, die Funk-
tionen des Visualization Toolkits (Kapitel 3.3.4) nutzen zu
können, wird dieses Bildvolumen in eine topologisch und geo-
metrisch regelmäßige Struktur, ein vtkImageData, konvertiert.
Eine Glättung des Volumens wird durch die Bearbeitung mit
einem Gaußfilter erreicht, bei dem einem Bildpunkt, unter Be-
rücksichtigung seiner Nachbarpixel, ein Mittelwert zugeordnet
wird. Mit dem in Kapitel 3.3.2 vorgestellten Marching-Cubes-
Algorithmus, wird ein aus Polygonen bestehendes Oberflächen-
modell erzeugt. Da dieses Modell überflüssige Polygone ent-
hält, werden diese mit einem Dezimierer reduziert. Zur weiteren
Glättung wird ein Filter benutzt, der durch die Lagebeziehung
einzelner Punkte zu ihren Nachbarpunkten einen Mittelwert

5.9. ENTWICKLUNG PLUGIN-ADAPTERKLASSE
bestimmt und diesen als Grundlage zur Glättung der Oberfläche benutzt. Das bearbeitete
Oberflächenmodell wird durch die Adapterklasse, an den DataReader weitergegeben und
dort geladen.
Durch den hier vorgstellten Workflow vereinfacht und beschleunigt sich auch der Ablauf
einer Operationsplanung, da keine Bilddaten exportiert werden müssen und die Schritte 1-4
in der Abbildung 4.4 entfallen.
PlugIn Klassenstruktur
Dieser letzte Abschnitt gibt einen Überblick über die Klassenstruktur der entwickelten
PlugIn-Schnittstelle. Dazu zeigt das Klassendiagramm 5.27 die Verbindungen zwischen
den einzelnen Klassen und die abschließende kurze Beschreibung einiger Klasse.
1
STL-Texteintrag
Instance UID
Eintrag
1
1-n
SegmentationSerie
Instance UID
Description
1
ImageVolume
ImageSliceArray
1
ImageSlice
Nummer
Pfad
1
1
1-n
1
CT-Bild
Instance UID
Pixeldaten
1-n
1
OrganNicerPluginFrame
OrganNicerApp* organNicerApp;
1 1 1
1
OriginalSeries
Instance UID
Description
SliceInfo
char* getImageType()
float getZValueFromPic()
1
1
1
OrganNicerSerie
Instance UID
Description
Abbildung 5.27: PlugIn Klassenstruktur
1
1
1-n
Instance UID
Eintrag
VRML-Szene
Instance UID
Eintrag
OrganNicerSzene
1-n
87

KAPITEL 5. PRAKTISCHE REALISIERUNG
◮ In der OrganicerSerie werden die zu einer Studie gehörenden Organicer- und VRML-
Szenen abgelegt.
◮ Eine Organicer-Szene wird als XML-Szenenbeschreibung der OrganicerSerie zugeord-
net und erhält den Mime-Type OCN.
◮ Der Texteintrag einer VRML-Szene enthält eine Pfadangabe der VRML-Datei auf der
Festplatte und den Mime-Type WRL.
◮ Die Klasse ImageSlice enthält den Pfad zu einem PIC-Schichtbild und eine Nummer,
welche die Position innerhalb des PIC-Volumens beschrieben.
◮ In der ImageVolume werden die einzelnen Schichtbilder in einem Array gespeichert.
◮ In der Klasse SegmentationSeries werden die Segmentierungsergebnisse als ImageVo-
lume gespeichert und können als vtkPolyData abgefragt werden.
◮ Die Klasse SliceInfo verfügt über verschiedene Funktionen zur Abfrage von Informa-
88
tionen über Schichtbilder.

6 Zusammenfassung der Diplomarbeit
In der Abteilung Medizinische und Biologische Informatik des Deutschen Krebsforschungs-
zentrums ist ein Prototyp zur Visualisierung medizinischer Bilddaten, der OrgaNicer, ent-
wickelt worden. Dieses Tool wird überwiegend zur Planung von Lebertumoroperationen
eingesetzt. Dabei werden die Leberhülle, die Gefäßbäume und berechnete Segmente als
Oberflächenmodelle visualisiert.
Durch eine enge Zusammenarbeit mit der Radiologie und Chirurgie der Universitätsklinik
Heidelberg ist es möglich, die gewonnenen 3D-Rekonstruktionen zur Verbesserung der Dia-
gnosestellung und Operationsdurchführung in den klinischen Alltag zu integrieren. Hierzu
wird weiterhin an der Optimierung der Arbeitsabläufe und der Datenkommunikation gearbei-
tet. In der medizinischen Bildverarbeitung ist dabei nicht nur das Übertragen der Bilddaten
von einem Ort zu einem anderen zu betrachten, sondern auch der Weg der Daten innerhalb
eines Programms.
Im Mittelpunkt dieser Diplomarbeit stand die Weiterentwicklung des 3D-Visualisierungstools
OrgaNicer und die Integration in das Teleradiologiesystem CHILI. Mit dem Redesign dieses
Softwareproduktes wurde das Ziel erreicht, seine Funktionalität als Standalone- und PlugIn-
Version zur Verfügung zu stellen. Die vorgenommenen Änderungen lassen sich in adaptieren-
de und perfektionierende Wartungsmaßnahmen unterteilen. Zur Umsetzung dieser Arbeiten
wurde die Programmiersprache C++ und die C++-Klassenbibliothek Qt verwendet.
Bei den perfektionierenden Wartungsmaßnahmen standen die Neugestaltung der Datenhal-
tung und die Entwicklung einer, für interaktive Anwendungen geeigneten, Programmstruktur
im Vordergrund. Durch die Verwendung von Entwurfsmustern ist ein modular aufgebautes
Programm entstanden, in dem die verschiedenen Funktionalitäten in eigenen Klassen gekap-
selt sind. Eine Vermittlerklasse organisiert dabei den Nachrichtenmechanismus mit den am
Datenaustausch beteiligten Programmteilen. Mit einem neugestaltenen Datenformat kön-
nen die Daten auf die Festplatte oder in die Datenbank des Teleradiologiesystems CHILI
geschrieben bzw. von dort gelesen werden.
Zur Darstellung des Sicherheitsabstands zwischen den Tumoren und dem Gefäßbaum wurde
ein Verfahren implementiert, mit dem tumornahe Gefäße farblich markiert werden können.
Des Weiteren wurde ein Ablauf zur Konvertierung von 3D-Szenen in das internetfähige
89

KAPITEL 6. ZUSAMMENFASSUNG DER DIPLOMARBEIT
VRML-Format implementiert. Beide Maßnahmen wurden mit dem Visualization Toolkit
(VTK) umgesetzt.
Mit einem eigenen Konzept wurde die Verwendung von VTK und das reine OpenGL-
Rendering des OrgaNicer’s kombiniert. In diesem Konzept verwaltet die ViewProperty-
Klasse die Materialeigenschaften und ermöglicht, neben der qualitativ hochwertigen Tranz-
parenzdarstellung der Oberflächenmodelle, die Verwaltung der Materialdefinitionen in Da-
tenstrukturen von VTK.
Durch die Integration eines Tool’s zur Segmentberechnung ist die Erstellung und Visua-
lisierung von Resektionsvorschlägen möglich. Hierzu werden die Gefäßteile innerhalb des
Sicherheitsabstandes markiert und das von ihnen versorgte Gewebe berechnet.
Im Verlauf der Entwicklung des OrgaNicer-PlugIn’s hat sich gezeigt, dass die CHILI-PlugIn-
Schnittstelle den Anforderungen nicht genügt:
• Die Datenbank von CHILI ist inkonsistent. Wichtige Bildinformationen werden nicht
in die vorgesehenen Datenbankstrukturen eingetragen.
• Die Bilddaten sind mit einem Steuerelement (Lichtkasten) verknüpft, welches vom
OrgaNicer-PlugIn nicht benutzt wird.
• Benötigte Bildinformationen sind im Datenbankkonzept von CHILI nicht vorgesehen
und mussten über die Header der Bilder abgefragt werden.
• Aus den Datenbankobjekten der Serien kann keine Information gewonnen werden, ob
es sich um eine Serie mit Originalbildern oder Segmentierungsergebnissen handelt. Es
gibt auch keine Zuordnungsmöglichkeit zwischen Originalserie und ihren Segmentie-
rungsergebnissen.
• Die mit C-Strukturen implementierten Datenbankobjekte bieten keine Funktionalität
zum Zugriff auf die Daten an.
• Das Eintragen mehrerer Texteinträge zu einer ausgewählten Serie war nicht möglich.
Änderungswünsche wurden von den Entwicklern des Teleradiologiesystems CHILI nicht be-
rücksichtigt. Deshalb wurde die Integration des OrgaNicer’s nicht mit der vorhandenen
Schnittstelle vollzogen, sondern mit der Neuentwicklung einer eigenen Schnittstelle gelöst.
Diese neue Schnittstelle verfügt über eine Adapterklasse, welche die Kommunikation mit
90

dem Teleradiologiesystem organisiert. Weitere Klassen erlauben den Zugriff auf die DICOM-
Informationen der Serien und Bilder und bieten Informationen an, welche von den Daten-
bankobjekten des Teleradiologiesystems nicht zur Verfügung gestellt werden. Durch adap-
tierende Änderungen an der Programmstruktur des OrgaNicer’s ist es möglich, weite Teile
des Quellcodes in der Standalone und in der PlugIn-Version zu nutzen. Auch die Elemen-
te der graphischen Benutzerschnittstelle können, durch die Verwendung eines Tool’s zur
Gestaltung von graphischen Benutzerschnittstellen, in beiden Anwendungsarten verwendet
werden.
Die Funktionalität des OrgaNicer’s steht mit der PlugIn-Version im Teleradiologiesystem
CHILI zur Verfügung, so dass Operationsplanungen innerhalb dieses Teleradiologiesystems
möglich sind. Somit ist es nicht mehr notwendig die Bilddaten zu exportieren, wodurch
sich die Bearbeitungszeit einer Operationsplanung verkürzt. Auch wird durch einen neuen
Workflow die Erzeugung der Oberflächenmodelle aus den Einzelschichten optimiert.
Mit der allgemeinen Schnittstellenklasse ChiliPluginFrame arbeitet mittlerweile ein Pro-
gramm zur Analyse von Gefäßstrukturen am Herzen. Die erzeugten VRML-Szenen können
mit dem OrgaNicer-PlugIn in die Datenbank von CHILI importiert und so einem webbasier-
ten Informationssystem zur Verfügung gestellt werden.
Mit der vorliegenden Diplomarbeit steht darüber hinaus eine Dokumentation zur Verfügung,
die mit der modular gestalteten Programmstruktur die Verständlichkeit der Programmstruk-
tur erhöht und zur Qualitätsverbesserung des OrgaNicer’s beiträgt.
91

KAPITEL 6. ZUSAMMENFASSUNG DER DIPLOMARBEIT
92

Altsystem Aktueller Stand
CHILI
Unix
OpenGL OpenGL + VTK
7.1 Ablösung des Altsystems
7 Ausblick
CHILI
Qt
Ausblick
Abbildung 7.1: Entwicklung eines Visualisierungstools
MITK (VTK)
Die Migrationstrategie erfolgt stufenweise und soll schon frühzeitig nutzbare Ergebnisse
bringen. Allerdings ensteht durch diese Vorgehensweise auch der Aufwand, dass beide Sys-
teme in dieser Zeit koexistieren und gepflegt werden müssen. Durch intensive Tests müssen
Fehler in der Neuentwicklung gefunden und beseitigt werden. Der Einsatz des Neusystems
in der Operationsplanung ist erst mit einer stabilen Version möglich, da aufgrund des engen
Zeitplans einer solchen Planung, nur mit einer stabilen Version gearbeitet werden kann.
7.1.1 Ausbau der Visualisierungsplattform CHILI
Nach der vollzogenen Ablösung des Altsystems, soll die Integration in das Teleradiologiesys-
tem CHILI vorangetrieben werden. Hierzu muss allerdings ein Programm entwickelt werden,
dass die Gefäßbäume innerhalb des Teleradiologiesystems segmentiert und über die CHILI-
Datenbank dem Organicer zur Verfügung stellt. Die Funktionalität des Organicers steht mit
VTK
93

KAPITEL 7. AUSBLICK
der PlugIn-Version im Teleradiologiesystem zur Verfügung. Allerdings muss diese Version
noch intensiv getestet werden, da das zugrundeliegende CHILI-Softwaresystem sensibel auf
Fehler reagiert. Ziel dieser Migrationphase ist die Durchführung des kompletten Workflows
einer Operationsplanung im Teleradiologiesystem CHILI.
Die Erfahrungen der PlugIn-Entwicklung können auch für andere Projekte genutzt werden.
• Diese Diplomarbeit könnte helfen eine neue CHILI-PlugIn-Schnittstelle für die Qt-
Version zu entwickeln. Da das Organicer-PlugIn größtenteils mit der Datenbank von
CHILI zusammenarbeitet, ist die Umstellung auf die Qt-Version von CHILI unproble-
matisch.
• Teile der Funktionalität der Organicer-Adapterklasse könnten in die Oberklasse (Chi-
liPluginFrame) ausgelagert werden und damit auch den anderen Entwicklungen in-
nerhalb der MBI-Abteilung zur Verfügung gestellt werden.
Eine Verlagerung der Funktionalität der Organicer-Adapterklasse in andere Bereiche, würde
die Wiederverwendung der gefundenen Lösungen ermöglichen und andererseits die Komple-
xität der Organicer-Adapterklasse reduzieren.
7.2 Das Visualisierungsframework MITK
Das Hauptziel der MBI-Abteilung ist es, alle Neuentwicklungen innerhalb eines Visuali-
sierungsframeworks umzusetzen. Dazu gehören neben der Leberoperationsplanung, For-
schungsprojekte im Bereich Lunge und Herz, ein kommerzielles Projekt zur Verfolgung von
Instrumenten bei Herzoperationen, die Navigation von Instrumenten in der Leberchirurgie
und die Verbesserung der Segmentierungsalgorithmen. Dieses Framework bildet den Rah-
men in dem Klassen und Entwürfe entwickelt werden, die in möglichst vielen Bereichen der
MBI-Abteilung genutzt werden können. Dies soll in Zukunft die schnellere Entwicklung von
Anwendungen mit ähnlichen Strukturen ermöglichen und die Wartbarkeit und Wiederver-
wendbarkeit der Komponenten erhöhen.
Die Entwicklung dieses Frameworks ist allerdings noch nicht so weit fortgeschritten, dass es
sich zur Realisierung eines Operationsplanungstools eignet. Deswegen ist es auch noch nicht
abzusehen, ob mit diesem Framework auch die qualitativ hochwertigen Visualisierungen des
Organicers umgesetzt werden können und die Entwicklung eines flexiblen, erweiterbaren
Softwareproduktes möglich ist. Allerdings sind in diesem Framework Funktionalitäten rea-
lisiert, die auch für den Organicer interessant sind. Die Möglichkeit Schnittbilder innerhalb
94

7.3. NEUE EINSATZGEBIETE DES ORGANICERS
einer 3D-Rekonstruktion (Multiplanare Rekonstruktion) darstellen zu können, kann u.a. dazu
genutzt werden Visualisierungsergebnisse mit den Originalbildern zu vergleichen. Nach einer
kompletten Umstellung der Visualisierung des Organicers auf VTK, könnte eine Anbindung
an das Framework stattfinden. Da im Framework auch VTK-Darstellungsfenster verwendet
werden, müsste im Organicer der SceneHandler durch ein solches Fenster ersetzt werden.
Diese Anbindung wurde während dieser Diplomarbeit getestet, setzt aber die vollständige
Umstellung des Organicers auf VTK voraus.
7.3 Neue Einsatzgebiete des Organicers
Das Softwareprodukt Organicer wurde speziell für die Operationsplanung in der Leberchirur-
gie konzipiert, aber auch schon im Bereich der Nieren-, Pankreas-, Herz- und Lungenchirur-
gie in Heidelberg eingesetzt. Dieses Visualisierungstool könnte aber auch in anderen Berei-
chen, in denen zur Beurteilung der anatomischen Strukturen Bilder aufgenommen werden,
zum Einsatz kommen. Natürlich kann der Organicer auch für spezielle Aufgaben angepasst
werden. Denkbar wäre ein verstärkter Einsatz bei orthopädischen oder neurochirurgischen
Problemstellungen.
Mit der Entwicklung des webbasierten Informationssystems können die VRML-Szenen über
das Internet anderen Kliniken angeboten werden. Bis jetzt konnten Ergebnisse der Operati-
onsplanungen nur mittels FTP-Server übertragen werden. Durch die Präsentation über das
Internet ist auch ein Ausbau der Zusammenarbeit mit den Kliniken John Hopkins Washing-
ton, Presbyterian Hospital Pittsburgh und der Universitätsklinik Lausanne möglich. Zur Zeit
werden auch Wege gesucht Visualisierungsergebnisse, als Dienstleistung, anderen Kliniken in
Deutschland anzubieten. Dazu muss allerdings geklärt werden, wer die Kosten einer solchen
Leistung trägt.
7.4 Schlusswort
Die Verbesserung der Aufnahmegeräte für medizinische Bilder und die Fortschritte in der
medizinischen Bildverarbeitung führen zu immer besseren Visualisierungsergebnissen. Mit
verschiedenen Messungen und Methoden kann dieses objektive Wissen noch erweitert wer-
den. Dies führt aber weder zu einer allwissenden Erkenntnis, noch kann ein Erfolg einer
Therapie vorrausgesagt werden, denn dieser hängt auch von der individuellen Verfassung
des Menschen ab. Deswegen wird bei Leberlebendspenden in Heidelberg nicht nur die Spen-
95

KAPITEL 7. AUSBLICK
derleber auf ihre Tauglichkeit untersucht, sondern auch die psychische Eignung des Spenders
beurteilt. So wurden bereits Operationen abgesagt obwohl die Spenderleber, nach der ob-
jektiven Beurteilung, für eine Leberlebendspende geeignet war.
Dieses Beispiel zeigt, dass nur durch eine Zusammenarbeit der medizinischen Berufsgruppen
und dem Austausch der gewonnenen Informationen, eine bestmögliche individuelle Therapie
für den Patienten gefunden werden kann.
96

Tabellenverzeichnis
3.1 Patientenobjekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Instance UID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
97

Tabellenverzeichnis
98

A Listings
Die in diesem Anhang vorgestellten Listings sind keine lauffähigen Programme. Sie sollen
einen Einblick in die Implementierungen dieser Diplomarbeit geben und verwenden dazu
Ausschnitte aus verschiedenen Teilen des Quellcodes.
A.1 Listing zum Aufbau eines VTK-Datasets
Das folgende Listing zeigt am Beispiel des Würfels aus Abbildung 3.10 den Aufbau eines
Polydata-Datasets innerhalb einer VTK-Pipeline:
/ ∗ A r r a y d e r P u n k t e , D r e i e c k e und S k a l a r e i n s t a n z i i e r e n ∗/
vtkCellArray* polys = vtkCellArray::New();
vtkPoints* points = vtkPoints::New();
vtkFloatArray* scalars = vtkFloatArray::New();
/ ∗ E c k p u n k t e f e s t l e g e n ∗/
static float x[8][3]= {{-1,-1,-1},{1,-1,-1},{1,1,-1},{-1,1,-1},
{-1,-1,1},{1,-1,1},{1,1,1},{-1,1,1}};
/ ∗ P u n k t d a t e n , D r e i e c k e und S k a l a r w e r t e z u o r d n e n ∗/
for(int p=0;pInsertPoint(p,x[p]);
for(int i=0;iInsertNextCell(3,pts[i]);
for(int s=0;sInsertTuple1(s,s);
/ ∗ F a r b w e r t e f e s t l e g e n u nd d e n S k a l a r e n z u o r d n e n ∗/
vtkLookupTable* lut = vtkLookupTable::New();
for(int l=0;lSetTableValue(l,1,0,0,0.85);
for(int l=4;lSetTableValue(l,0,0,1,0.85);
scalars->SetLookupTable(lut);
/ ∗ P u n k t e und D r e i c k e dem D a t a s e t z u o r d n e n ∗/
vtkPolyData* polydata = vtkPolyData::New();
99

ANHANG A. LISTINGS
polydata->SetPoints(points);
polydata->SetPolys(polys);
polydata->GetPointData()->SetScalars(scalars);
/ ∗ M a p p e r dem A c t o r z u o r d n e n ∗/
vtkPolyDataMapper* cubeMapper = vtkPolyDataMapper::New();
cubeMapper->SetInput(polydata); // d a s D a t e n o b j e k t dem M a p p e r
vtkActor* cubeActor = vtkActor::New();
cubeActor->SetMapper(cubeMapper);
/ ∗ R e n d e r e r dem F e n s t e r z u o r d n e n ∗/
vtkRenderer *renderer = vtkRenderer::New();
vtkRenderWindow *window = vtkRenderWindow::New();
window->AddRenderer(renderer);
window->Render()
A.2 Listing Mediator - Datenhaltung
Listing A.1: Aufbau eines Polydata Datasets
Der Mediator implementiert den Nachrichtenmechanismus der Anwendung und organisiert
die Datenhaltung (aus mediator.h und mediator.cpp).
// a u s m e d i a t o r . h
class Mediator : public QObject{
Q_OBJECT
public slots:
// u p d a t e Model −View − C o n t r o l l e r
signals:
void slotUpdateMVC();
void updateMVC();
public:
// g i b t E l e m e n t o r g a n i s a t o r zum E i n t r a g e n d e r D a r s t e l l u n g s e l e m e n t e
ElementOrganizer* getElementOrganizer();
// l o e s c h t d i e D a t e n l i s t e und d i r E l e m e n t l i s t e n
100

void clearLists();
// ü f g t D a t e n e l e m e n t i n D a t e n l i s t e
void dataListAppend(DataNode* dn);
// l o e s c h t D a t e n e l e m e n t a u s D a t e n l i s t e
void dataListRemove(int n);
A.2. LISTING MEDIATOR - DATENHALTUNG
// l i e f e r t d i e A n z a h l d e r E l e m e n t e i n d e r D a t e n l i s t e
int dataListCount(){ return dataCounter;}
// l i e f e r t e i n D a t e n e l e m e n t u e b e r e i n e n I n d e x
DataNode* getDataNode(int i);
// I t e r a t o r zum Z u g r i f f a u f a l l e E l e m e n t e d e r D a t e n l i s t e
QPtrListIterator getDataListIterator();
// g i b t I n s t a n z d e s M e d i a t o r s
static Mediator* getInstance();
// z u r P r u e f u n g ob M e d i a t o r b e r e i t s i n s t a n z i i e r t i s t
friend class std::auto_ptr;
// g i b t I d e n t i f i k a t i o n s n u m m e r f u e r n e u e s D a t e n e l e m e n t
int getId(){ return idCounter; }
protected:
// Z a e h l e r d e r I d e n t i f i k a t i o n s n u m m e r n
static int idCounter;
// ä Z h l e r d e r D a t e n l i s t e
static int dataCounter;
// c o n s t r u c t o r NOT p u b l i c ! ( s i n g l e t o n p a t t e r n )
Mediator();
virtual ~Mediator();
// Z e i g e r a u f d i e I n s t a n z d e s M e d i a t o r s
static std::auto_ptr oneAndOnlyInstance;
// d i e D a t e n l i s t e d e r A n w e n d u n g
typedef QPtrList DataNodeList;
DataNodeList DataList;
private:
};
// s p e i c h e r t d i e I d e n t i f i k a t i o n s n u m m e r n d e r D a t e n e l e m e n t e
typedef QValueList IDList;
IDList idList;
// o r g a n i s i e r t d i e D a r s t e l l u n g s e l e m e n t e
ElementOrganizer* elementOrganizer;
// a u s m e d i a t o r . c p p
101

ANHANG A. LISTINGS
Mediator* Mediator::getInstance(){
if (oneAndOnlyInstance.get() == 0) {
oneAndOnlyInstance.reset(new Mediator());
}
return oneAndOnlyInstance.get();
}
void Mediator::dataListRemove(int dnId){
}
IDList::iterator it;
it = idList.at(dnId);
int dlIdx = *it; // g e t t h e d a t a l i s t i n d e x
DataNode* dn = DataList.at(dlIdx);
elementOrganizer->removeDataNode(dnId);
DataList.remove(dlIdx);
dataCounter-=1;
if(dataCounter == 0 )clearLists();
emit updateMVC();
bool Mediator::dataListIsEmpty(){
}
return DataList.isEmpty();
ElementOrganizer* Mediator::getElementOrganizer(){
}
return elementOrganizer;
void Mediator::dataListAppend(DataNode* dn){
}
int idx = idList.count();
dn->setId(dataCounter);
idList.append(idCounter);
DataList.append(dn);
++dataCounter;
++idCounter;
DataNode* Mediator::getDataNode(int dnId){
IDList::iterator it;
it = idList.at(dnId);
int id = *it;
DataNode* dn = DataList.at(id);
return dn;
}
102

A.3. UPDATE MECHANISMUS DER DATENANSICHT
QPtrListIterator Mediator::getDataListIterator() {
}
QPtrListIterator iterator(DataList);
return iterator;
void Mediator::clearLists(){
}
dataCounter=0;
idCounter = 0;
idList.clear();
DataList.clear();
elementOrganizer->clearLists();
emit clearSeriesList();
void Mediator::slotUpdateMVC(){
}
emit updateMVC( );
Listing A.2: Implementierung Mediator
A.3 Update Mechanismus der Datenansicht
Diese Funktion übernimmt die Aktualisierung der Datenansicht nach einer Veränderung des
Models (aus datalistview.cpp).
void DataListView::updateListView(){
if(!isBlocked()){
DataCheckListItem* dcli;
clear();
typedef std::map::const_iterator it;
it s; // ä E i n t r g e d e r S e r i e n
for ( s = SeriesList.begin(); s != SeriesList.end(); ++s){
}
dcli = new DataCheckListItem(this,s->se,s->fi,CheckBox);
dcli->setSelectable(true);
// h o l t s i c h d e n D a t a L i s t − I t e r a t o r
103

ANHANG A. LISTINGS
}
QPtrListIterator dit=mediator->getDataListIterator();
DataNode* dn;
ViewProperty* vp;
QCheckListItem* cli;
if(mediator->dataListCount() > 0){
while((dn = dit.current()) != 0){ // D a t e n e l e m e n t e e i n t r a g e n
dcli = new DataCheckListItem(this,dn->getName(),dn,CheckBox);
QListViewItem* qc =new QListViewItem(dcli, "P:"+dn->getPath());
if(dn->getType()==QString("VES"))
qc = new QListViewItem(dcli, "D:"+ dn->getDescription());
if(dn->getType()==QString("STL"))
if(dn->getType()=="VES"){ // S e g m e n t e i n t r a e g e
for(int i=0; i< vp->getNumberOfColors(); ++i){
QString text;
text = *(SegmentTypes.at(i));
SegmentListViewItem*type=new SegmentListViewItem(prop,text,vp,i);
type->setSelectable(true);
}
}
repaint(qc);
}
++dit;
}
}
setBlocked(false);
A.4 Oberflächemodell erzeugen
Listing A.3: Update Datalistview
Das Erzeugen von Oberfächenmodellen ist in der Klasse ImageData implementiert (aus
ImageData.cpp).
vtkPolyData* ImageVolume::getPolyData(){
104
ipPicDescriptor* picVolume = ipPicNew();

}
ipPicClear( picVolume );
ipPicDescriptor* pic,first;
vtkPolyData* polyData; void* importPointer;
vtkPolyDataNormals* data3d;
Volume::iterator it = volume.begin();
for(int i = 0; i < volume.size() ;++i,++it){
path = (char*)it->getPath().latin1();
pic = ipPicGet(path,NULL);
if(i==0){
first = pic;
ipPicCopyHeader(first,picVolume);
type = first->type;
bpe = first->bpe;
picsize = _ipPicSize(pic);
}
picsize*=size;
picVolume->data = (char*)malloc(picsize);
importPointer = picVolume->data;
id = _ipPicSize(first)*i ;
A.4. OBERFLÄCHEMODELL ERZEUGEN
memcpy(&((char *)picVolume->data)[id],pic->data,ipPicSize(pic));
if(i == (volume.size() -1)){
picVolume->dim = 3;
ipFloat8_t scale[3] = { 0.58,0.58,3.0 };
picVolume = ipFuncScale(picVolume,scale,ipFuncScaleNN);
vtkImageData* imageData= Pic2vtk::convert(picVolume);
vtkImageThreshold *iselect = vtkImageThreshold::New();
vtkImageGaussianSmooth *gaussian = vtkImageGaussianSmooth::New();
vtkImageShrink3D *shrinker = vtkImageShrink3D::New();
vtkMarchingCubes* mc = vtkMarchingCubes::New();
vtkDecimate* decimate = vtkDecimate::New();
vtkSmoothPolyDataFilter*smoother=vtkSmoothPolyDataFilter::New();
if(picVolume){ipPicFree(picVolume);}
}
return polyData; }}
Listing A.4: Oberflächenmodell erzeugen
105

ANHANG A. LISTINGS
A.5 Datenbankabfrage der Adapterklasse
Nach der Auswahl einer Studie im Teleradiologiesystem CHILI überprüft diese Funktion, ob
eine Organicer-Serie in dieser Studie vorhanden ist und trägt alle Segmentierungsergebnisse
in eine Liste ein (aus organicerPluginFrame.cpp).
void OrganNicerPluginFrame::selectAllSeriesFromStudy
QStringList oidList;;
dbBrowser_t *browser;
QString abspath;
QString relpath;
if(pCurrentStudy()){
(char *studyOID ){
abspath=QString((char*)pGetValues(this->myInstance,"db_path"));
abspath.append("/");
relpath.append(pCurrentStudy()->modality);relpath.append("/");
relpath.append(pCurrentStudy()->instanceUID);
relpath.append("/");
abspath += relpath;
}
series_t *series;
int result = 0;
browser = globals.browser[1];
if( browser->db_type == dbTypePostgres ) {
dbObject_t *study_object;
study_object=dbObjectNewOID(browser->studyIOD,studyOID);
if( study_object ) {
dbResult_t *result_text;
result_text=dbObjectList(study_object,browser->sIOD);
if( result_text ){
106
dbObject_t *tmpObj = NULL;
for( tmpObj = dbResultFirst(result_text,NULL);
tmpObj != NULL;
tmpObj = dbResultNext(result_text, NULL)){
if( dbObjectNull(tmpObj))continue;
if( !dbObjectAllowed(tmpObj, dbRIGHT_R)){

}
printf("not_allowed_to_read\n");}
else{
A.5. DATENBANKABFRAGE DER ADAPTERKLASSE
series = (series_t*)malloc( sizeof( image_t ) );
initSeriesStruct(series_t);
if(!dbObjectGetData(tmpObj,series)){
coutinstanceUID;}
organicerSeries->setAbsolutPath(abspath);}
if(ipStrCmp("Image,Segmentation",
}
getImageTypeFromSeries(series->oid))==0){
oidList.append(series->oid);}}}
Listing A.5: Beispiel einer Datenbankabfrage
107

ANHANG A. LISTINGS
108

Literaturverzeichnis
[Bus96] Pattern-orientierte Softwareentwicklung Frank Buschmann, Addison-Wesley, 1996
[Chi02] Steinbeis-Transferzentrum Medizinische Informatik,Heidelbeg, CHILI-
Produktbeschreibung Stand Januar 2002, Eigenverlag, 2002
[Cla97] Claussen Ute, Programmieren mit OpenGL, Springer-Verlag Berlin,Heidelberg,New
York, 1997
[Eng95] U. Engelmann, A. Schröter, DKFZ, Abt. MBI , Technical Report PIC-Format,
Eigenverlag ,1995
[Eng00] U.Engelmann, M.Scheab, U.Eisenmann, M.Vetter,Radiologiesystem CHI-
LI,Telemedizinführer Deutschland,2000
[Eng02] U.Engelmann,M.Schwab,A.Schröter,H.-P.Meinzer,Evaluation des CHILI-
Teleradiologienetzwerks nach 4 Jahren im klinischen Einsatz,Springer-Verlag,2002
[Fow00] Martin Fowler, Refactoring,Object Technology International,Inc., 0000
[Gam96] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides Entwurfsmuster,
Addison-Wesley,1996
[Mei03] H.P.Meinzer, Vorlesungsskript Medizinische Bildverarbeitung, Universität Heidel-
berg, 2003
[Mue97] Bernd Mueller, Reengineering -Eine Einführung-, Teubner Verlag, 1997
[Oes98] B.Oestereich, Objektorientierte Softwareentwicklung - Analyse und
Design,Addison-Wesley, 1998
[OGL99] Richard S. Wright,Michael Sweet, OpenGL SuperBible, Waite Group Press, 1999
[Plu99] Steinbeis-Transferzentrum Medizinische Informatik,Plugin Software Developer Kit
Version 1.8,Eigenverlag,1999
109

Literaturverzeichnis
[Psy89] Psyschrembel Klinisches Wörterbuch, de Gruyter Verlag,, 1989
[QtD03] Trolltech,Trolltech Qt-Dokumentation,Copyright Trolltech,2003
[Rad01] Kauffmann,Moser,Sauer, Radiologie, Urban & Fischer, 2001
[Sch02] Max Schöbinger, Analyse von Gefäßstrukturen und vesorgtem Gewebe, Technical
Report, DKFZ, 2002
[Sil79] S.Silbernagl,A.Despopoulus, Taschenbuch der Physiologie, Thieme-Verlag, 1997
[Som92] Sommerville, Software Engineering,Addison Wesley, 1992
[uml01] Dr.Thomas Ehrler, Das Einsteigerseminar UML, bhv-Verlag, 2001
[Vtk99] Lorenzen, The Visualization Toolkit, Verlag, 1999
[Wil99] Marco Wiltgen, Digitale Bildverarbeitung in der Medizin, Shaker-Verlag, 1999
[Xpp00] Kent Beck,Extreme Programming,Addison Wesley,0000
[Yal03] Baris Yalcin,Entwicklung eines webbasierten Informationssystems für die computer-
gestützte Leberoperationsplanung,DKFZ Technical Report,2003
[3Ds00] Adrian Perez,Dan Royer, 3-D Spieleprogrammierung, Software & Support Verlag,
2000
[3Dl00] Norman Lin, Linux 3D-Grafik, Software & Support Verlag, 2001
[www.lebertransplantation.de] http://www.lebertransplantation.de
[www.w3.org] http://www..w3.org/XML
[www.mevis.de] http://www.mevis.de
[www.ircad.com] http://www.ircad.com
[www.web3d.org] http://www.web3d.org
[www.medical.nema.org] http://www.medical.nema.org
110

Abbildungsverzeichnis
2.1 Anwendungsfälle Operationsplanung . . . . . . . . . . . . . . . . . . . . . 6
2.2 Zeitplan der Leberoperationsplanung . . . . . . . . . . . . . . . . . . . . . 7
2.3 Datenaustausch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Aktivitäten Operationsplanung . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 Segmenteinteilung der Leber nach Couinaud (aus ) . . . . . . . . 10
3.2 Dichteskala nach Hounsfield . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Schematische Darstellung Computertomographie . . . . . . . . . . . . . . 12
3.4 Schichteinstellung Magnetresonanztherapie . . . . . . . . . . . . . . . . . 14
3.5 Schema Ultraschall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.6 Objektdiagramm Dicom . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.7 Beispieltags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.8 Bildaufbereitung durch Segmentierung . . . . . . . . . . . . . . . . . . . . 19
3.9 Bildverarbeitungsoperationen . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.10 Beispielobjekt Würfel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.11 Darstellung Welt-Objektkoordinatensystem . . . . . . . . . . . . . . . . . 24
3.12 Punkte im Welt-Objektkoordinatensystem . . . . . . . . . . . . . . . . . 24
3.13 2D-Transformationen eines Dreiecks . . . . . . . . . . . . . . . . . . . . . 25
3.14 Kamera- und Lichteinstellungen . . . . . . . . . . . . . . . . . . . . . . . 27
3.15 Marching Cubes - Aufbau eines Würfels . . . . . . . . . . . . . . . . . . . 28
3.16 Entscheidungsfälle beim Marching-Cubes-Algorithmus . . . . . . . . . . . 29
3.17 Vereinfachte Darstellung des Raytracing-Prinzips . . . . . . . . . . . . . . 30
3.18 OpenGL-Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.19 Beschreibung der OpenGL Unterstützung . . . . . . . . . . . . . . . . . . 32
3.20 Klassendiagramm VTK . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.21 VTK Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.22 Darstellung Welt-Objektkoordinatensystem . . . . . . . . . . . . . . . . . 37
3.23 Änderungskostenkurve . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
111

Abbildungsverzeichnis
112
3.24 Der Reengineering-Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.25 Singleton-Muster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.26 Beobachter-Muster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.27 Benutzerschnittstelle als Kompositum-Muster . . . . . . . . . . . . . . . . 43
4.1 Verfahren der Transparenzdarstellung
Die Zahlen kennzeichnen die Reihenfolge der Darstellung . . . . . . . . . . 46
4.2 Transparenzdarstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3 Einteilung eines Gefäßbaumes . . . . . . . . . . . . . . . . . . . . . . . . 48
4.4 Workflow
Leberoperationsplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.5 Lichtkasten des Teleradiologiesystems CHILI . . . . . . . . . . . . . . . . . 53
5.1 Model-View-Controller Prinzip . . . . . . . . . . . . . . . . . . . . . . . . 59
5.2 Strategie Transparenzdarstellung . . . . . . . . . . . . . . . . . . . . . . . 60
5.3 Die Klassen der Gefäßbäume und Oberflächenmodelle . . . . . . . . . . . 61
5.4 Organicer Scenegraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.5 Zentrale Verwaltung der Daten . . . . . . . . . . . . . . . . . . . . . . . . 62
5.6 An der Datenspeicherung beteiligte Klassen . . . . . . . . . . . . . . . . . 63
5.7 Sequenzdiagramm ViewProperty laden . . . . . . . . . . . . . . . . . . . . 64
5.8 Sequenzdiagramm ViewProperty speichern . . . . . . . . . . . . . . . . . . 65
5.9 Aktivität Daten laden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.10 Aktivität Daten speichern . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.11 GUI Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.12 ViewProperty Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.13 Farbwertzuordnung über Skalare . . . . . . . . . . . . . . . . . . . . . . . 71
5.14 Datenansicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.15 Einsatz des PropertyWidget zur Berechnung des Sicherheitsabstandes . . . 73
5.16 Aufteilung des 3D-Raumes . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.17 Gefäßbaumrepräsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.18 Farbzuordnung bei Gefäßbäumen . . . . . . . . . . . . . . . . . . . . . . . 76
5.19 CHILI-Teleradiologiesystem
( Darstellung der Resektionsvolumina in beiger Farbe ) . . . . . . . . . . . 77
5.20 Adapterklasse OrganicerPluginFrame . . . . . . . . . . . . . . . . . . . . . 78

Abbildungsverzeichnis
5.21 CHILI Datenbankobjekte . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.22 PlugIn-Imageklassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.23 Die Klasse SliceInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.24 Serieninformations-Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.25 Aktivätsdiagramm PlugIn-Workflow . . . . . . . . . . . . . . . . . . . . . 85
5.26 Aktivität STL-Modell erzeugen . . . . . . . . . . . . . . . . . . . . . . . . 86
5.27 PlugIn Klassenstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.1 Entwicklung eines Visualisierungstools . . . . . . . . . . . . . . . . . . . . 93
113

Abbildungsverzeichnis
1.6 Glossar
D
DICOM-Standard Bildformat und Übertragungsprotokoll für medizische Bilddaten
DKFZ Deutsches Krebsforschungszentrum Heidelberg
E
Entwurfsmuster Entwurfsmuster beschreiben wiederkehrende Probleme und verwenden Lö-
F
sungen, die zuvor erfolgreich eingesetzt wurden
Framework Ein Framework besteht aus einer Menge kooperierender Klassen, welche die Ele-
G
mente eines wiederverwendbaren Entwurfs für eine bestimmte Art von Software dar-
stellen (siehe ).
Gefäßtyp Autonome Versorgungsgebiete der Gefäße werden mit einem Typ gekennzeichnet.
Grauwertbild Bilder deren Bildpunkte mit Grautönen dargestellt sind.
H
Hounsfield Englischer Physiker der 1979 für die Entwicklung der Computertomographie mit
I
dem Nobelpreis ausgezeichnet wurde
ipFunc-Bibliothek Die ipFunc-Bibliothek stellt eine grosse Anzahl von Funktionen zur Bear-
beitung von Pic-Bildern bereit
ipPic-Bibliothek Stellt grundlegende Funktionen für den Umgang mit PIC-Dateien zur Ver-
fügung.
Isotrope Skalierung Durch eine isotrope Skalierung wird die Ausdehnung, der im Bildvolumen
114
enthaltenen Voxel, auf eine in x-y-z-Richtung einheitliche Größe, skaliert.

K
1.6. GLOSSAR
Komponente Ein gekapselter Teil eines Softwaresystems mit einer Schnittstelle, die den Zu-
gang zu ihren Diensten ermöglicht
Kopplung Ausmaß der Abhängigkeit von Softwarekomponenten.
M
MBI Abteilung für medizinische und biologische Informatik des Deutschen Krebsforschungs-
zentrums
Modul Eine syntaktische und konzeptionelle Einheit eines Softwaresystems.
Multiplanare Rekonstruktion Eine multiplanare Rekonstruktion bietet die Möglichkeit belie-
N
bige Schnitte durch ein Visualisierungsergebniss legen zu können auf denen die Struk-
turen, welche sich in diesem Bereich befinden, dargestellt werden.
Navigation Die Möglichkeit des Benutzers seinen Standort und seine Blickrichtung innerhalb
P
der dargestellzen Szene frei zu wählen.
Picking OpenGL bietet einen Picking-Mechanismus an, mit dem ein Benutzer Objekte einer
Szene selektieren kann.
Pixel Ein Pixel ist die kleinste, einzeln ansprechbare sichtbare Element eines Rasterbildschir-
mes
Polygon Ein Objekt mit vielen Ecken. In der Computergraphik werden 3D-Objekte aus Po-
lygonen aufgebaut
Punkt Ein Punkt bezeichnet eine feste Koordinate
R
Redesign Redesign verbessert das Design bzw. die Softwarearchitektur bestehender Softwa-
resysteme
115

Abbildungsverzeichnis
Rendering Beim Rendering werden Computermodelle in Darstellungen auf dem Bildschirm
umgewandelt.
Restrukturierung Restruktuerierung verbessert die Implementierung bestehender Software
Reverse-Engineering Reverse-Engineering bezeichnet den Vorgang bei dem aus einem Aus-
gangssystem (Altsystem) ein Modell gewonnnen wird.
Rolle Die Verantwortlichkeit einer Komponente im Kontext mehrerer Komponenten
S
Spacing Im Spacing-Wert werden die Pixelgröße und der Abstand der Einzelschichten ge-
speichert, aus denen sich die Größe eines Voxels im Bildvolumen ergeben.
SSL-Protokoll Das Secure Sockets Layer Protokoll emöglicht die Verschlüsselung und Au-
thentifikation einer Client-Server-Kommunikation mittels verschiedener Algorithmen
STL-Datei Eine STL-Datei beschreibt in einer Liste die Dreicke aus denen ein Oberflächen-
T
modell besteht.
Tupel Liste von Zahlen
V
Vektor Verchiebung im Raum
Vertex Verbindungspunkte von Polygonen
VesselElement Gefäßabschnitt zwischen zwei Verzweigungspunkten eines Gefäßbaumes
Voxel Die den Pixeln entsprechenten Volumenelemente in 3D-Bildern
VRML Dateiformat zur Beschreibung virtueller Welten zur Darstellung im Internet
VTK Open-Source Klassenbibliothek für Visualisierungen
X
XML-Format XML ist eine Sprache zur Beschreibung von strukturierten Daten und Doku-
116
menten und ist ein universelles Format zum Datenaustausch.

Index
DICOM-Standard....................15
DKFZ ............................ 6, 18
Entwurfsmuster .................. 39, 96
Framework .......................... 94
Gefäßtyp ........................ 10, 75
Hounsfield...........................11
Interpolation.....................28, 34
ipFunc-Bibliothek....................19
ipPic-Bibliothek ..................... 19
Isotrope Skalierung .................. 86
Komponente ........................ 39
Kopplung ........................... 39
Leber
” Anatomie........................9
” Segmente ...................... 10
Leberkrebs
” HCC . .......................... 10
” Metastase ...................... 10
MBI..............................5, 18
Modalität ........................... 52
Modul...........................39, 72
Multiplanare Rekonstruktion. .........94
Navigation .......................... 45
Oberflächenerendering ............... 28
Picking. .............................45
Pixel ................................31
Punkt...............................22
Redesign ............................ 37
Rendering ........................... 28
Restrukturierung.....................37
Reverse-Engineering. .................37
Rolle................................60
117

Index
Segmentierung ...................... 19
Spacing ............................. 79
SSl-Protokoll ......................... 7
STL-Datei...........................86
Tupel . .............................. 22
Vertex .............................. 22
VesselElement ................... 47, 75
Volumenrendering ................... 28
Voxel ............................... 28
VRML ....................... 36, 57, 75
VTK ............................ 33, 94
XML-Format ........................ 63
118

Erklärung
Index
Diese Diplomarbeit wurde im Rahmen des Studiums zum Diplom-Informatiker (FH) im
Fachbereich Informatik -Studiengang Informatik- der Fachhochschule Worms verfasst.
Hiermit erkläre ich eidesstattlich, dass die vorliegende Diplomarbeit von mir selbstständig
und ohne unerlaubte Hilfe erstellt worden ist.
Ort, Datum Christian Sonek - M.Nr. 657424
119

Index
120