Download - Benjamin Granzow Portfolio

Bachelorarbeit
GPU-basierte Volumendarstellung
Verfasser
Benjamin Granzow
Studiengang
Medieninformatik
Fachbereich
FB VI - Informatik und Medien
Mat.Nr. 764663
Bearbeitungszeit 01. Nov 2012 - 21. Feb 2013
Betreuer
Prof. Dr.-Ing. Hartmut Schirmacher
Gutachter
Prof. Dr. rer. nat. Rüdiger Weis
Beuth Hochschule für Technik Berlin
Beuth Hochschule für Technik Berlin

Inhaltsverzeichnis
Abbildungsverzeichnis
Listings
Vorwort
v
vi
vii
1 Einleitung 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Abgrenzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Fachliches Umfeld 4
2.1 Theoretischer Hintergrund . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Lichttransportmodell . . . . . . . . . . . . . . . . . . . 4
2.1.2 Volumen Rendering Integral . . . . . . . . . . . . . . . 6
2.1.3 Volumen Rendering Verfahren . . . . . . . . . . . . . 7
2.1.4 Volumen Rendering Pipeline . . . . . . . . . . . . . . 9
2.2 Datensätze . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Verwendete Technologien . . . . . . . . . . . . . . . . . . . . 11
2.3.1 C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.2 Qt-Framework . . . . . . . . . . . . . . . . . . . . . . 12
2.3.3 OpenGL ES . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.4 Shader . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 OpenGL ES 2.0 Grafikpipeline . . . . . . . . . . . . . . . . . 13
2.4.1 Vertex Processing . . . . . . . . . . . . . . . . . . . . 14
2.4.2 Fragment Processing . . . . . . . . . . . . . . . . . . . 14
2.4.3 Compositing . . . . . . . . . . . . . . . . . . . . . . . 14
2.5 GPU Programmierung . . . . . . . . . . . . . . . . . . . . . . 16
2.5.1 Vertexshader . . . . . . . . . . . . . . . . . . . . . . . 17
2.5.2 Fragmentshader . . . . . . . . . . . . . . . . . . . . . 18
3 Konzeption 19
3.1 Auswahl des Rendering Verfahrens . . . . . . . . . . . . . . . 19
3.2 Prototypischer Software-Entwurf . . . . . . . . . . . . . . . . 20

INHALTSVERZEICHNIS
iii
4 Umsetzung 23
4.1 2D Texture-Sliced Volumen Rendering . . . . . . . . . . . . . 23
4.1.1 Texturen Anordnung . . . . . . . . . . . . . . . . . . . 23
4.1.2 Einzelne Textur . . . . . . . . . . . . . . . . . . . . . . 24
4.1.3 Mehrfach Texturen . . . . . . . . . . . . . . . . . . . . 26
4.1.4 Zusammensetzung im Framebuffer . . . . . . . . . . . 29
4.2 Klassifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.1 Transferfunktion . . . . . . . . . . . . . . . . . . . . . 30
4.2.2 Pre- vs. Post-Klassifizierung . . . . . . . . . . . . . . . 30
4.2.3 Post-Klassifizierung . . . . . . . . . . . . . . . . . . . 31
4.3 Beleuchtung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.1 Blinn-Phong . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.2 Gradient Berechnung . . . . . . . . . . . . . . . . . . . 35
4.3.3 Integration . . . . . . . . . . . . . . . . . . . . . . . . 39
5 Ergebnisse & Auswertung 42
5.1 Datenqualität und Datengröße . . . . . . . . . . . . . . . . . 43
5.2 Erstellung einer Transferfunktion . . . . . . . . . . . . . . . . 44
5.3 Vergleich der eigenen Umsetzung mit Visage7 . . . . . . . . . 46
6 Zusammenfassung & Ausblick 49
6.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . 49
6.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Danksagung 53
A CD-Inhalt 54
Literatur- und Quellenverzeichnis 55

Abbildungsverzeichnis
1.1 Verschiedene Volumengrafiken: Sparschwein, Orange, Brustkorb,
Metall . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1 Materialmodelle (a) Emission (b) in-scattering (c) out-scattering
(d) Absorption . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Schematische Darstellung der Shear-Warp Volumen Rendering
Variante. Umsetzung für orthografische und perspektivische
Projektion . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Verschiedene Schnitte erstellt von einem CT, aus den Beispieldatensätzen
der Visage7 Demo . . . . . . . . . . . . . . . 11
2.4 Programmierbare OpenGL ES pipeline . . . . . . . . . . . . . 14
3.1 Prinzip der Texture slicing Volumendarstellung: a) Textur
Anordnung b) 2D-Texturen c) Optische Interpretation; Entnommen
Real-Time Volume Graphics [3] Seite 49, Figure 3.1. 20
3.2 Programmablauf mit Benutzerinteraktion und Rendering Schritten
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 Komponenten und ihre angedachte Interaktion untereinander 22
4.1 Darstellung des Rotationsproblems von Ebenen a) ohne Ebenenwechsel
b) mit Ebenenwechsel . . . . . . . . . . . . . . . . 23
4.2 Einfache Volumendarstellung mit konstanter Transparenz . . 25
4.3 Mittels Transferfunktion dargestellte Ebenen Links: Einzelne
Texturen (20 Ebenen) Rechts: Mehrfach Texturen (200 Ebenen) 29
4.4 Schematische Darstellung von a) Pre-Klassifizierung: zuerst
Klassifizierung dann Interpolation b) Post-Klassifizierung: zuerst
Interpolation dann Klassifizierung . . . . . . . . . . . . . 30
4.5 Vergleich von Pre-(Links) und Post-Klassifizierung(Rechts)
eines CT-Datensatzes mit der selben Transferfunktion. Entnommen
Real-Time Volume Graphics [3] Seite 90, Figure 4.2. 31
4.6 Visualisierung von mikro- und makroskopischer Normalen . . 33
4.7 Darstellung der Winkel des Blinn-Phong Modells . . . . . . . 34
4.8 Berechnung des Gradienten (Steigung) an der Stelle x i . . . . 36

ABBILDUNGSVERZEICHNIS
v
4.9 Links: Berechnete Gradienten (Steigung), Rechts: Berichtigte
Orientierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1 Ansicht der resultierenden Umsetzung . . . . . . . . . . . . . 42
5.2 Histogramm eines Datensatzes a) Luft b) Haut c) Muskeln d)
Knochen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3 Beispiele für Transferfunktion mit Resultat . . . . . . . . . . 45
5.4 Gegenüberstellung von Visage7 (links) und der eigenen Umsetzung
(rechts). Dabei wurden die selben Volumendaten und
Transferfunktion verwendet. . . . . . . . . . . . . . . . . . . . 48

Listings
2.1 Minimum Vertexshader in GLSL . . . . . . . . . . . . . . . . 17
2.2 Minimum Fragment Shader in GLSL . . . . . . . . . . . . . . 18
4.1 Berechnung der Ebenenrichtung der negativen Z-Achse . . . . 24
4.2 Fragmentshader für eine Textur mit konstanter Transparenz . 25
4.3 Berechnung einer Ebene aus den Texturen auf der Z-Achse . 26
4.4 Textureinstellung zum begrenzen des Wertebereichen . . . . . 27
4.5 Fragmentshader für mehrere Texturen mit konstanter Transparenz
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.6 Fragment Shader mit Transferfunktion . . . . . . . . . . . . . 32
4.7 Blinn-Phong Methode im Fragmentshader . . . . . . . . . . . 35
4.8 Vorbrauserechnung des Gradienten auf dem Datensatz . . . . 38
4.9 Fragmentshader mit Transferfunktion und Blinn-Phong Beleuchtung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Vorwort
Zum Abschluss des Studiums ist es vorgesehen, dass eine Abschlussprüfung
abgehalten wird. Die Regelungen, denen diese Prüfung unterliegt, sind in
der Rahmenprüfungsordnung (RPO IV) festgelegt. Die Abschlussprüfung
besteht nach §13 Abs. 2 aus einer Abschlussarbeit und einer mündlichen
Abschlussprüfung. Für den Studiengang Medieninformatik ist in der Studienordnung
Medieninformatik Bachelor §5 Abs. 7 festgelegt, dass für die
schriftliche Ausarbeitung 12 Wochen Bearbeitungszeit zur Verfügung stehen.
Während der gesamten Abschlussphase wird dem Prüfling eine betreuende
Lehrkraft zugewiesen, welche diesem mit Anleitung und Beratung zur
Verfügung steht. Die Bewertung der Abschlussprüfung wird vom Betreuer
und einem zusätzlichen Gutachter vorgenommen.
Die tatsächliche Bearbeitungszeit dieser Arbeit weicht um vier Wochen von
den festgelegten 12 Wochen ab. Diese Verlängerung ist vom Prüfungsausschuss
genehmigt. Das ist begründet aus einer zweiwöchigen krankheitsbedingten
Prüfungsunfähigkeit und einem zweiwöchigen Zeitbonus, aufgrund
eines Nachteilsausgleiches nach §12 (RPO IV) hinsichtlich einer amtlich anerkannten
Legasthenie.

Kapitel 1
Einleitung
Die Computergrafik befasst sich mit der Generierung, Bearbeitung und Verarbeitung
von Bildern. Am Anfang bezog sich die Computergrafik nur auf
2D Raster- oder Vektorgrafiken, welche seit den 60er Jahren um die dritte
Dimension ergänzt wurde 1 . Seitdem unterliegt die Computergrafik einer
schnellen Entwicklung und bietet immer mehr Möglichkeiten. Da die Qualität
immer fotorealistischer wird, hat die Computergrafik in vielen visuellen
Medienbereichen Einzug gehalten. Dabei wird meistens der Bereich
der Unterhaltungsindustrie wahrgenommen. Seien es Computergrafiken in
Computerspielen, digitale Ergänzungen in der Filmtechnik oder komplett
im Computer entstandene Animationsfilme. Sie wird auch immer häufiger
verwendet, um die verschiedensten Informationen besser für ein Zielpublikum
aufzubereiten.
In der Wirtschaft und Forschung wird Computergrafik besonders zur Visualisierung
von Daten verwendet. So werden zum Beispiel Messdaten aus dem
CERN LHC-Teilchenbeschleuniger grafisch aufbereitet, um diese medienwirksam
präsentieren zu können 2 . Eine alltägliche Anwendung dieser Visualisierung
durch die Computergrafik geschieht in der Medizintechnik, wo für
bildgebende Verfahren zB. Computertomographie (CT) oder Magnetresonanztomographie
(MRT) mittels Computergrafik möglichst aussagekräftige
Darstellungen erstellt werden. Diese Verfahren erstellen eine sehr große Anzahl
von Bildschnitten, welche einzeln ausgewertet werden können. Um aber
einen Überblick zu erhalten, kann man durch Volumengrafik ein Gesamtbild
erzeugen. Volumengrafiken eignen sich besonders um Objekte darzustellen,
die keine direkte Abgrenzung zu ihrer Umgebung besitzen, wie Wolken oder
Nebel. Diese Methode erreicht durch Nachbildung des Lichttransportes eine
hohe optische Wirklichkeitsnähe. In Abbildung 1.1 sind verschiedene Volumengrafiken
aufgezeigt.
1 http://de.wikipedia.org/wiki/Geschichte der Computergrafik [24.01.13]
2 ALICE scrutinizes proton-lead run for quark-gluon plasma,
http://home.web.cern.ch/about/updates/2013/01/alice-scrutinizes-proton-lead-run-

1.1. MOTIVATION 2
Abbildung 1.1: Verschiedene Volumengrafiken: Sparschwein, Orange, Brustkorb,
Metall
Im Laufe dieser Arbeit wird eine Möglichkeit erläutert, wie Volumendarstellung
mit Hilfe der Grafikkarte (GPU) umgesetzt werden kann. Dabei wird
ein zusätzlicher Schwerpunkt auf Portabilität gesetzt, sodass die Implementierung
auf so vielen Plattformen wie möglich funktioniert.
1.1 Motivation
Da die Thematik der Volumengrafik im Rahmen des Studiums nicht behandelt
worden ist, ging es darum diese selbständig zu erarbeiten. Besonders
interessant ist dieses Thema, da es eine vollkommen andere Sichtweise aufzeigt,
als in der Computergrafik üblich ist. Bei den gängigen Techniken ist
der Schwerpunkt auf die Beschreibung von Oberflächen gelegt, sodass das
Objekt als ein geschlossener und hohler oder fester Körper modelliert wird.
Dieses oberflächenbasierte Rendering (Surface Rendering) ist vor allem für
geschlossene Objekte mit klar abzugrenzenden Oberfläche geeignet. Um mit
dieser Technik transparente Objekte zu realisieren gibt es nur zwei Varianten.
Die Erste ist das ganze Objekt mit einer Transparenz zu versehen. Die
Zweite besteht darin mit Texturen zu arbeiten, wodurch auch einzelne Bereiche
transparent gesetzt werden können. Dennoch kann bei beiden Varianten
die klare Abgrenzung nicht wirklich aufgehoben werden. Mit Volumentechquark-gluon-plasma
[24.01.13]

1.2. ZIELSETZUNG 3
niken wird diese Begrenzung aufgehoben, des Weiteren kann das Innenleben
eines Objektes miteinbezogen werden.
Die Thematik der Volumendarstellung ist nicht neuartig. Doch in den letzten
Jahren haben sich einige technische Entwicklungen ergeben, durch welche
sich für die Volumendarstellung interessante neue Möglichkeiten ergeben.
Die Erstellung eigener Shaderprogramme ermöglicht nun schnelle interaktive
Manipulationen der anzuzeigenen Daten. Durch die Auslagerung einiger
Berechnungen entstehen andere Anforderungen an die Hardware.
1.2 Zielsetzung
In der vorliegenden Arbeit geht es darum, die grundlegenden Techniken der
Volumendarstellung aufzuzeigen und dabei einen praktisch verwendbaren
Prototypen zu erstellen. Dieser soll medizinische Daten als Volumengrafik
darstellen. Durch eine einfache grafische Oberfläche sollen die Daten manipuliert
werden können. Zusätzlich soll ein Schwerpunkt auf Portabilität
gesetzt werden, sodass die Implementierung mit wenig Aufwand auf möglichst
vielen Plattformen realisiert werden kann. Für diese Arbeit werden
die gängigsten Plattformen (Windows, Linux, Mac OS) berücksichtigt. Für
eine bessere Performance soll die Hardwarebeschleunigung der Grafikkarte,
in Form von Shadern, mit einbezogen werden. Dadurch ergibt sich die zuvor
erwähnte Interaktivität mit den Daten.
1.3 Abgrenzung
Die Thematik der Volumendarstellung ist sehr umfangreich, wodurch nicht
alle Aspekte des Themas bearbeitet werden können, da dieses den Rahmen
der Bearbeitungszeit übersteigen würden. Aus diesem Grund schneidet diese
Arbeit nur die Grundlagen der Thematik an.
Bei der Implementierung beschränken sich die importierten Datensätze auf
CT-Daten. Andere bildgebende Verfahren, wie MRT oder Sonographie, werden
nicht umgesetzt. Die Datensätze liegen in Form von allgemein üblichen
Bilddateien (JPEG, TIFF, etc.) vor. DICOM, dass Standardformat für radiologische
Bilddaten, wird im Rahmen der Arbeit nicht unterstützt.
Um die vorgestellten Techniken nachvollziehbar zu halten, wird nicht vertieft
auf Speicheroptimierungen eingegangen, da der Code dadurch nur unnötig
komplex und schwerer nachvollziehbar wird. Auch auf die neusten Entwicklungen
im Bereich der Deformation und Animation wird in dieser Abhandlung
nicht weiter eingegangen.

Kapitel 2
Fachliches Umfeld
2.1 Theoretischer Hintergrund
2.1.1 Lichttransportmodell
Die physikalische Grundlage des Volumen Renderings liegt in der geometrischen
Optik. Diese nimmt an, dass Licht sich immer entlang eines geraden
Strahles bewegt, außer es erfolgt ein Zusammentreffen mit anderen Materialien.
Genau diese Interaktion zwischen Licht und anderen Materialien ist bei
der Volumendarstellung von Interesse. In der optischen Geometrie werden
drei Verschiedene Materialmodelle beschrieben.
Für die nachfolgende Beschreibung wird von einem gasförmigen Material
ausgegangen.
Abbildung 2.1: Materialmodelle (a) Emission (b) in-scattering (c) outscattering
(d) Absorption
Emission
Emission beschreibt, das ein aktives Material selbst Licht aussendet. In der
Realität wandelt stark erhitztes Gas seine Wärmeenergie in Strahlung um,
dabei wird die Strahlungsenergie erhöht.

2.1. THEORETISCHER HINTERGRUND 5
Absorption
Das Material kann Licht absorbieren. Physikalisch wird dabei Strahlung in
Wärmeenergie umgewandelt. Hierbei ist zu beachten, dass ein Material nicht
unbedingt die gesamte Strahlungsenergie umwandelt, diese jedoch reduziert.
Scattering
Scattering beschreibt, das Licht gestreut wird. Dieses kann man aber eher
mit einer Richtungsänderung vergleichen. Es sind dabei noch zwei Verhalten
zu unterscheiden. Ein Material kann aus anderen Richtungen einfallendes
Licht sammeln und dieses selber in Strahlenrichtung aussenden, was als
in-scattering bezeichnet wird. Oder es kann Licht absorbieren und in alle
Richtungen aussenden, dies wird als out-scattering bezeichnet. Dadurch
ist es durch Scattering möglich, die Strahlungsenergie zu erhöhen oder zu
reduzieren.
Es gibt verschiedenste Modelle, die unterschiedlich viele dieser Materialmodelle
verwenden. Wobei die Königsdisziplin darin besteht, alle drei Modelle
zu berücksichtigen. Dennoch ist das Emissions-Absorptions-Modell die am
meisten verbreitetste Umsetzung. Aus diesem Grunde wird dieses Model in
dieser Arbeit genauer dargestellt und für die Implementation auch verwendet.
Um dieses Modell mathematisch umzusetzen, ist es nötig, sich vor Augen
zu führen, was Licht überhaupt ist. Licht kann an seiner Bestrahlungsstärke
(Irradiance) I beschrieben werden. Diese wird durch die Strahlenenergie Q,
Fläche A und Raumwinkel Ω pro Zeiteinheit t berechnet.
I =
dQ
dA ⊥ dΩdt
Dabei steht ⊥ dafür, dass der Strahl parallel zur Fläche verläuft. A ⊥ =
A cos θ, wobei θ für den Winkel zwischen Lichtrichtung und Normale der
Fläche A steht. Ausführliche Spezifikationen und Grundlagen zum Thema
Licht in der Bildsynthese können einem Buch von Glassner [1] entnommen
werden.
Die nachfolgende Formel beinhaltet alle vorher erwähnten Modelle:
ω · ∇ x I(x, ω) = −χI(x, ω) + η
Dabei steht der Term ω · ∇ x I für das Skalarprodukt zwischen Lichtrichtung
ω und Strahlung I abhänig von der Position x. Der Nabla-Operator ∇ ist
ein Vektor, welcher als Komponenten die partiellen Ableitungsoperatoren
besitzt (∇ = ( ∂ ∂
∂x 1
. . .
∂x n
)). Dieser wird als Kurzschreibweise für den Gradientvektor
verwendet. Der Term χ bezeichnet die absolute Absorption und η
die absolute Emission.

2.1. THEORETISCHER HINTERGRUND 6
Diese Darstellung des Lichttransportes ist so nicht ganz genau. Mit der
Schreibweise von H.C.Hege [2] wird die Emission und Absorption noch weiter
aufgespalten, sodass die Scattering-Varianten mit berücksichtigt werden.
χ = κ + σ
Dadurch wird ausgedrückt, dass die absolute Absorption aus dem Absorptions-
Koeffizienten κ und dem out-scattering-Koeffizienten σ besteht.
η = q + j
Analog dazu, ist die absolute Emission aufgeteilt in Emission q und inscattering
j. Zu beachten ist, dass die Koeffizienten alle von der Position x
und der Strahlenrichtung ω abhängen. Mit diesen Schreibweisen erhält man
nun:
ω · ∇ x I(x, ω) = −κ(x, ω) + σ(x, ω)I(x, ω) + q(x, ω) + j(x, ω)
Da, wie oben schon erwähnt, das Scattering außer acht gelassen werden soll,
können die dazugehörigen Terme aus der Formel entfernt werden. Die resultierende
Formel wird meistens als Volumen Rendering Formel bezeichnet.
ω · ∇ x I(x, ω) = −κ(x, ω)I(x, ω) + q(x, ω) (2.1)
Genaugenommen beschreibt die Formel den Lichttransport bei differenziellen
Änderungen im Lichtstrahl. Wird nur ein einziger Strahl ausgewertet, so
kann ω · ∇ x I auch als Ableitung ( dI
ds
) geschrieben werden.
dI(s)
ds
= −κ(s)I(s) + q(s) (2.2)
Dort wird die Position durch den Längenfaktor s angegeben.
2.1.2 Volumen Rendering Integral
Ausgehend von der Differenzialform der Volumen Rendering Formel 2.2,
welche für einen Strahl gültig ist, kann mittels Änderungen der Variablen s
dieser Strahl entlanggewandert werden. Mittels Integration der Formel kann
dieses ausgedrückt werden. Dabei wird mit s = S 0 der Startpunkt und mit
s = D der Endpunkt beschrieben. Daraus ergibt sich:
I(D) = I 0 e
D∫
− k(t)dt
∫ D
s 0 +
s 0
D∫
q(s)e − k(t)dt
s ds (2.3)

2.1. THEORETISCHER HINTERGRUND 7
In dieser Formel wird durch I 0 als die Bestrahlungsstärke des Hintergrundes
an der Anfangsposition s 0 angenommen. Dabei ist I(D) die Bestrahlungsstärke,
welche das Volumen an der Stelle s = D verlässt. Also repräsentiert
der erste Term die Bestrahlungsstärke des Hintergrundes abgeschwächt
durch das Volumen. Der zweite Term steht für die Bestrahlungsstärke, welche
durch das Durchqueren der verschiedenen Materialien abgeschwächt
wird. Das hochgestellte Integral
r(s 1 , s 2 ) =
∫ s 2
s1
k(t)dt
definiert die Optische Tiefe im Bereich s 1 bis s 2 . Dieses beschreibt die Länge,
die ein Lichtstrahl benötigt bis dieser vollständig zerstreut wird. Niedrigere
Werte stehen also für ein transparenteres Material, Hohe analog dazu für undurchlässigere.
Äquivalent dazu kann Transparenz auch anders ausgedrückt
werden.
s ∫2
T (s 1 , s 2 ) ⇔ e −r(s 1,s 2 ) ⇔ e − k(t)dt
s1
Mit dieser kann das Volumen Rendering Integral 2.3 weiter vereinfacht werden.
∫ D
I(D) = I 0 T (s 0 , D) +
s 0
q(s)T (s, D)ds (2.4)
Diese Volumen Rendering Integral Formel ist die am meisten verwendete
Darstellung.
2.1.3 Volumen Rendering Verfahren
Die zugrundeliegende Idee hinter der Umsetzung von Volumendarstellung
unterscheidet sich signifikant von der üblichen Vorgehensweise bei der oberflächenbasierten
Darstellung. Volumengrafiken anzuzeigen, wird von den Grafikbibliotheken
nativ nicht unterstützt, da diese darauf spezialisiert sind, mit
Gitternetzen (Meshes) zu arbeiten. Um Volumendarstellungen realisieren zu
können, muss daher auf übliche Mittel zurückgegriffen werden, diese werden
ihrem eigentlichen Zweck entfremdet, um ein Volumen darzustellen. Für die
Umsetzung existieren unterschiedlichste Herangehensweisen, welche unter
andem im Buch Real-Time Volumen Graphics [3] erwähnt werden.
Raytracing
Diese Technik ist in der Computergrafik weit verbreitet um 3D-Szenen abzubilden.
Dabei wird für jeden Pixel der zu erstellenden Ansicht ein Strahl in

2.1. THEORETISCHER HINTERGRUND 8
die Szene gesendet. Das Volumen wird entlang jeden Strahls von vorne nach
hinten (front-to-back) oder von hinten nach vorne (back-to-front) durchlaufen,
und die Emission und Absorption ausgewertet und aufsummiert. Dieses
geschieht solange, bis bewertet werden kann, dass die dahinter liegenden
Teile des Strahl nicht mehr sichtbar sind.
Texture slicing
Bei dieser Variante handelt es sich um die, welche in die Volumendarstellung
die häufigste Verwendung findet. Die Grundidee davon ist es, hintereinander
liegende Ebenen sog. Slices, abzubilden. Dabei werden diese Ebenen mit
Transparenzen dargestellt, was bei frontaler Betrachtung die Texturen auf
den einzelnen Ebenen addiert. Dabei entsteht für den Betrachter der Anschein,
dass es sich um ein einziges Objekt handelt.
Shear-Warp
Die Mechanik dieser Variante ist eng mit dem Konzept des Texture slicing
verbunden. Hierbei wird das Volumen auch auf transparenten Ebenen
dargestellt. Abhängig von der verwendeten Kameratransformation wird das
Volumen geschert und skaliert. Bei der orthografischen Projektion wird das
Volumen nur so geschert, dass die Entfernung der Abtastung auf den Ebenen,
bezogen auf eine bestimmte Ebene, immer gleich ist. Bei der perspektivischen
Projektion ist zusätzlich noch eine Skalierung notwendig. Beide
Variationen sind in Abbildung 2.2 dargestellt.
Abbildung 2.2: Schematische Darstellung der Shear-Warp Volumen Rendering
Variante. Umsetzung für orthografische und perspektivische Projektion
Da dieses für CPU-Berechnung vorgesehen ist, werden die einzelnen Ebenen
in eine Ergebnisebene addiert. Diese Variante ist die performanteste Variante
bei CPU Umsetzungen. Sie wurde das erste Mal von Lacroute und Levoy[4]
beschrieben.

2.1. THEORETISCHER HINTERGRUND 9
Splatting
Das Splatting basiert auf der Annahme, dass jeder diskrete Punkt des Volumens
das Resultat beeinflusst. Dafür wird das Volumen von hinten nach
vorne durchlaufen und jeder abgetastete Punkt auf die Bildebene projiziert.
Dabei geht der Punkt mit seiner Emission geschwächt um die Absorption
in den Bildpunkt ein. Die verschiedenen Projektionen werden anschließend
durch unterschiedliche Overlay-Operations kombiniert. Der Name des Verfahrens
wurde durch Lee Westover geprägt, welcher den Ablauf mit einem
Schneeball verglich, der auf eine Bildebene geworfen wird und zerplatzt. Eine
genaue Beschreibung kann im Visualization Handbook[5] nachgeschlagen
werden.
Durch diese Konzepte muss man sich von der Vorstellung lösen, dass ein
Volumen im Programm als wirkliches Objekt existiert. Erst im Auge des
Betrachters wird dieses zu einer Volumendarstellung.
2.1.4 Volumen Rendering Pipeline
Auch wenn die verschiedenen Rendering Verfahren unterschiedliche Herangehensweisen
haben, folgt die Erstellung von Volumengrafiken immer einem
festen Ablauf. Ein typischer Ablauf einer Volumen Rendering Pipeline ist:
Datensätze vorbereiten
Die Datensätze werden so positioniert, dass die Abtastpunkte passend für
das Verfahren liegen. Dazu gehören auch Transformationen, wie Translation,
Rotation und Scherung. Dabei wird die Ausrichtung hergestellt, um die
Verwendung des Volumen Rendering Integrals zu ermöglichen.
Interpolation
Dabei geht es darum, entlang der Datenwerte zu interpolieren, um die Zwischenwerte
der abgetasteten Punkte zu erhalten. Am häufigsten findet hier
die triliniare Interpolation Verwendung.
Klassifizierung
Transformiert die Werte des Datensatzes anhand einer Transferfunktion,
um ihre optischen Eigenschaften zu ermitteln. Hier werden die optischen
Eigenschaften (Absorption, Emission), welche für das Volumen Rendering
Integral benötigt werden, zugewiesen.

2.2. DATENSÄTZE 10
Beleuchtung
Bei Volumendarstellung ist es Möglich, auch Beleuchtung in das Volumen
Rendering Integral einzubringen. Dafür kann eine beliebige Beleuchtungsberechnung
aufgerechnet werden.
Zusammensetzen
Zusammensetzten der einzelnen Daten zu einem Gesamtbild. Dieses repräsentiert
die Aufsummierung und Iteration des Volumen Rendering Integrals.
Dabei steht back-to-front oder front-to-back zur Auswahl.
Auch die im Verlauf dieser Ausarbeitung dargestellte Umsetzung verwendet
diesen Aufbau der Volumen Rendering Pipeline. Daher werden die einzelnen
Schritte im weiteren Verlauf noch näher erläutert.
2.2 Datensätze
Es gibt verschiedenste bildgebende Verfahren, die bekanntesten darunter
sind CT, MRT und Sonografie (Ultraschall). Diese Verfahren messen durch
unterschiedliche Methoden die Dichte bzw. Materialbeschaffenheit eines Objektes.
Durch eine Vielzahl von Schnitten entlang des Objektes wird damit
Einblick in das Innenleben dieses ermöglicht. Dabei kann der Schichtabstand
der Schnitte gezielt eingestellt werden, um die Abtastung passend
zum Untersuchungszweck anzupassen. Solche Datensätze werden meistens
im offenen DICOM-Format gespeichert, können aber auch in allgemein üblichen
Bilddateien abgespeichert werden. Diese Bilddaten sind bei CT-Scans
meistens 512x512 Pixel groß und beinhalten die Messdaten als Graufarbenbild.
Die Messdaten werden dafür in einen Farbwert umgewandelt, wobei der
Wert 0 keiner messbaren Dichte entspricht. Mit zunehmender Dichte steigt
auch der Farbwert an. Abhängig vom Verfahren können Dichtewerte unterschiedlich
präzise abgestuft werden. Daher gibt es Datensätze in 8, 12 und
16 Bit Farbtiefe, welche eine unterschiedlich Anzahl an Abstufungen speichern
können. Auf die Auswirkungen von Datengrößen wird im Abschnitt
Datenqualität und Datengröße 5.1 eingegangen. In Abbildung 2.3 sind verschiedene
CT Schnitte dargestellt.

2.3. VERWENDETE TECHNOLOGIEN 11
Abbildung 2.3: Verschiedene Schnitte erstellt von einem CT, aus den Beispieldatensätzen
der Visage7 Demo
2.3 Verwendete Technologien
Durch die zusätzliche Zielsetzung der Kompatibilität entstehen bestimmte
Anforderungen an die Implementierung. Damit diese auf möglichst vielen
Systemen funktioniert, wurde auf einheitliche Standards bzw. Schnittstellen
zurückgegriffen.
2.3.1 C++
Typischerweise werden für die Kernfunktionalität von Computergrafik-Anwendungen
die Programmiersprache C++ verwendet. Es ist oft nötig viele

2.3. VERWENDETE TECHNOLOGIEN 12
Daten in der Computergrafik zu verwalten und durch die Eingenschaft von
C++ ist es möglich, die Speicherverwaltung selbst zu kontrollieren. Deswegen
kann eine sehr gute Performance für Anwendungen erzielt werden, da
eine direkte Anbindung an die Hardware entsteht. Als Programmiersprache,
welche direkt in Maschinencode kompiliert wird, entfällt der Laufzeit-
Overhead, welchen interpretierte Sprachen durch ihre Laufzeitumgebung erzeugen.
2.3.2 Qt-Framework
Das Qt-Framework stellt dem Anwender Klassen zur Verfügung, um grafische
Benutzeroberflächen zu erstellen. Dieses Framework funktioniert nicht
nur für verschiedene Desktop-Betriebssysteme und eingebettete Systemen,
sondern es ist auch für mobile Plattformen geeignet. Dabei werden zum jetzigen
Zeitpunkt Windows Mobile, ältere Nokia-Systeme (Symbian, MeeGo,
Maemo) und Blackberry unterstützt, dennoch sind Umsetzungen für Android
und iOS mit dem im Herbst 2013 erscheinenden Qt 5.2 angekündigt.
Des Weiteren wird zur Steuerung der Anwendung ein einfaches und effektives
Eventsystem geboten. Durch die Nutzung dieses Frameworks, wird eine
breite Kompatibilität der Anwendung zu verschiedensten Systemen garantiert.
2.3.3 OpenGL ES
Die Open Graphics Library (OpenGL) ist ein offener Standard im Multimediabereich,
um plattformübergreifend die Darstellung von 2D und 3D
Computergrafiken zu ermöglichen. OpenGL wird von der Khronos Group
entwickelt, welche viele namenhafte Firmen zu ihren Mitgliedern zählt. Dabei
sind AMD/ATI, Apple Inc., id Software, Google, Intel Coorporation,
Mozilla und Oracle/Sun Microsystems, um nur einige zu nennen. OpenGL
wird von allen handelsüblichen Grafikkarten nativ unterstützt, und ist nicht
wie andere Bibliotheken, zB. DirectX nur auf Windows Systeme, beschränkt.
Für die Implementierung wurde gezielt OpenGL ES 2.0 verwendet, da der
genutzte Befehlssatz auch auf mobilen Plattformen und eingebetteten Systemen
sicher zur Verfügung steht.
OpenGL ES 2.0 umfasst 179 Befehle und bildet eine bereinigte Untermenge
der 297 Standardbefehle, welche in OpenGL 4 verfügbar sind, um eine möglichst
große Kompatibilität zu ermöglichen. Die Funktionsweise von OpenGL
ES 2.0 und ihrer Grafik-Pipeline wird im Abschnitt 2.4 OpenGL ES 2.0 Grafikpipeline
näher erläutert.
2.3.4 Shader
Shader sind Mini-Programme, die auf die Grafikkarte geladen werden können
und auf die Szenendaten dann beliebige Effekte rauf rechnen. Zum Erstel-

2.4. OPENGL ES 2.0 GRAFIKPIPELINE 13
len von Shaderprogrammen können verschiedene Sprachen gewählt werden.
Anfangs wurden die Programme mittels einer Assemblersprache geschrieben.
Da diese aber nicht intuitiv zu verwenden ist, wurden einige Alternativen
entwickelt, welche sich an der Programmiersprache C orientieren. Die
Verbreitetsten sind C for Graphics (Cg) von NVIDIA, High Level Shading
Language (HLSL), die für DirextX entwickelt wurde oder die OpenGL Shading
Language (GLSL) für OpenGL Anwendungen. An diese Shader können
beliebige zusätzliche Informationen übertragen werden, was eine erhöhte Interaktivität
mit der Darstellung ermöglicht. Da für die Implementierung die
Wahl auf OpenGL ES gefallen ist wird auch GLSL im nachfolgenden verwendet.
Im Abschnitt 2.4 OpenGL ES 2.0 Grafikpipeline wird im Detail auf
die zur Verfügung stehenden Shader von OpenGL ES eingegangen.
2.4 OpenGL ES 2.0 Grafikpipeline
Eine Grafikpipeline ist ein Modell, dass die einzelnen Schritte beschreibt,
welche beim Grafikrendern durchlaufen werden, um eine Grafik auf den Bildschirm
darzustellen. Dabei sind einige Schritte dieser Pipeline auf der Hardware
implementiert, um eine bessere Performance zu erhalten. Die Schritte
der OpenGL ES 2.0 Pipeline sind in Abbildung 2.4 mit ihren drei Phasen
dargestellt. Um die Grafikpipeline zu betrachten, werden einige Begriffe benötigt:
ˆ Vertex Buffer Object (VBO)
Ein VBO ermöglicht eine schnelle und performante Speicherung und
Übertragung von Daten, zB. Vertices und Normalen, zur Grafikkarte.
Dabei wird dennoch ein einfacher Zugriff ermöglicht, um die Daten zu
aktualisieren.
ˆ Vertex(Vertices)
Vertices sind Knotenpunkte aus welchen eine geometrische Form zusammengesetzt
werden.
ˆ Primitive
Sind eine einfache geometrische Form, welche durch die Verbindung
von Vertices repräsentiert werden. Üblich sind Punkte, Linien, Dreiecke
und Vierecke.
ˆ Fragment
Fragments repräsentieren eine Farbe auf einer Rasterposition und beinhalten
alle Informationen, um die betreffende Pixel darstellen zu können.

2.4. OPENGL ES 2.0 GRAFIKPIPELINE 14
Abbildung 2.4: Programmierbare OpenGL ES pipeline
Wie in Abbildung 2.4 dargestellt, ist die OpenGL ES Pipeline in drei Phasen
aufgeteilt: Das Vertex Processing, das Fragment Processing und das Compositing.
2.4.1 Vertex Processing
Während dem Vertex Assambly Schritt werden die Daten aus der Anwendung
in den Grafikkartenspeicher geladen. Dies geschieht zB. über ein VBO,
welches die Vertices von Primitiven mit ihren zugehörigen Attributen enthält.
Diese Daten werden als Attribute an den Vertexshader weitergegeben.
Im Vertexshader werden verschiedene Vertex-Attribute transformiert. Meistens
wird dieses auf die Position angewendet, aber potentiell können alle
Attribute wie die Normale oder andere Anwendungsspezifische Per-Vertex-
Daten transformiert werden. Nachdem die Vertex-Attribute transformiert
wurden, können weitere beliebige Werte über sogenannte Varyings an den
Fragmentshader weitergegeben werden. Nähere Beschreibung zum Vertexshader
folgt im Abschnitt 2.5.1 Vertexshader. Darauf folgt der Primitiv Assembly
Schritt, welcher die einzelnen Vertices zu Primitiven zusammensetzt.
Danach werden beim Clipping die Bereiche der Objekte abgeschnitten, welche
nicht im sichtbaren Ausschnitt liegen. Dies reduziert die weiterzuverarbeitenden
Daten und entlastet dadurch die nachfolgenden Schritte.
2.4.2 Fragment Processing
Der erste Schritt in dieser Phase ist die Rasterization. Dabei wird für jeden
Pixel, der ein Teil des Primitiven abdeckt, ein Fragment erzeugt. Jeder
dieser Fragments gehört dabei zu einer Rasterposition auf dem Bildschirm,
repräsentiert diesen aber nicht, da üblicherweise mehrere Fragments von unterschiedlichen
Objekten auf einer Rasterposition liegen. Diese Fragments,
welche aus den interpolierten Werten der Vertices bestehen, durchlaufen anschließend
den Fragmentshader, der den endgültige Farbwert des Fragments
berechnet. Dies kann durch Texturzugriffe oder Funktionen geschehen. Nähere
Beschreibung folgt im Abschnitt 2.5.2 Fragmentshader.
2.4.3 Compositing
Die Compositing Phase ist der letzte Verarbeitungsschritt bevor der Farbwert
in den Framebuffer gespeichert wird. Der Framebuffer ist ein 2D-Array
von Pixeln und ihren Attributen (Farbe, Transparenz, Tiefe), welches das

2.4. OPENGL ES 2.0 GRAFIKPIPELINE 15
endgültige Bild enthält. Bevor ein Fragment in den Framebuffer übertragen
wird, können verschiedene Tests auf diesen angewendet werden, um herauszufinden
ob es ggf. verworfen oder angezeigt wird. Dafür sind folgende Tests
verfügbar, welche nach Bedarf verwendet werden können:
Alpha-Test
Der Alpha-Test wertet das Alpha-Attribut a der Fragmentfarbe aus. Anhand
einer vorher definierten Funktion wird bewertet, ob das Fragment als
komplett transparent gilt. Wenn dies der Fall ist, werden die restlichen Tests
und das Speichern in den Framebuffer übersprungen. Die Funktion wird mit
glAlphaFunc(func,value) festgelegt. Dabei muss value im Bereich [0,1] liegen
und bezeichnet den Referenzwert. Für func kann aus einem Aufzählungstyp
(Enumeration) verschiedene Vergleichsoperationen gewählt werden. Diese
Operation legt fest, wie value und das Alpha-Attribut a der Fragmentfarbe
verglichen werden.
Es ist zu beachten, dass der Befehl glAlphaFunc in OpenGL ES 2.0 nicht
zu Verfügung steht, dieser Test ist nur zu Vollständigkeit mit aufgeführt.
Ist diese Funktionalität dennoch gewünscht kann diese im Fragmentshader
selbstständig umgesetzt werden.
Stencil-Test
Dieser Test besteht daraus, dass die im Stancilbuffer erstellte Maske auf
das Fragment angewendet wird. Im Stancilbuffer können durch diese Maske
Bereiche festgelegt werden, welche herausgefiltert werden oder welche sichtbar
sind. Dies wird zB. dazu verwendet, wenn nur bestimmte Bereiche neu
gerendet werden sollen. Durch die Möglichkeit die gespeicherten Werte des
Buffers zu inkrementieren oder zu dekrementieren, wird dieser auch für die
Berechnung von Shadow-Volumes benötigt. Mehr Informationen zu diesem
Thema können dem von NVIDIA veröffentlichen GPUGems[6] entnommen
werden.
Depth-Test
Der Tiefen-Test ist dafür da, um herauszufinden, welche Fragments der Kamera
am Nächsten und dadurch sichtbar sind. Dabei existiert, ähnlich dem
Stancilbuffer, ein Depthbuffer, welcher die Tiefenwert des sich momentan im
Framebuffer befindlichen Fragments an dieser Stelle speichert. Zur Bewertung
wird die Tiefe des neuen Fragments mit der des Alten verglichen. Ist das
Neue näher an der Kamera, also der Wert kleiner, wird das neue Fragment
in den Framebuffer übernommen und der neue Tiefenwert im Depthbuffer
gespeichert. Ist dieses nicht der Fall, befindet sich das neue Fragment hinter
dem alten und wird im endgültigen Bild nicht sichtbar sein, das Fragment

2.5. GPU PROGRAMMIERUNG 16
wird daher verworfen.
Nachdem ein Fragment alle Test durchlaufen hat, wird dieser in den Framebuffer
übertragen. Bei komplett sichtbaren Objekten wird der neue Wert
direkt in den Framebuffer übertragen. Wenn aber transparente Objekte verwendet
werden, müssen diese noch durch den Alpha-Blending Schritt verarbeitet
werden.
Alpha-Blending
Mittels Alpha-Blending wird genau festgelegt, wie ein neuer Fragment mit
dem alten Wert im Framebuffer kombiniert wird, um den neuen Wert festzulegen.
Dafür muss eine Blendfunktion festgelegt werden. Dies geschieht
über glBlendFunc(srcFactor,fbFactor), wobei für die Faktoren Enumeration verwendet
werden. Die möglichen Werte können der OpenGL ES 2.0 Referenz
[7] entnommen werden. Diese Funktion beschriebt, mit welchen Anteilen
welche Farbwerte eingehen. srcFactor wird dabei auf die neuen Fragment
angewendet und fbFactor auf den alten Wert im Framebuffer.
2.5 GPU Programmierung
Heutzutage sind die meisten Computer mit leistungsfähiger Grafikhardware
ausgestattet. Diese Hardware besitzt einen eigenen Rechenkern, der auf die
Berechnung von Grafiken optimiert ist. Dieser wurde historisch dafür verwendet,
Projektionen für die Darstellung zu berechnen und Objekte nachträglich
zu transformieren und mit Lichteffekten zu versehen. Dabei wurden
Bereiche einer Textur heller oder dunkler eingefärbt, um Schatten und Licht
darzustellen. Diese Beleuchtungsfunktionen waren fest auf der Hardware
verankert und konnten nur leicht konfiguriert werden. Aus diesem Grund
wurde diese auch als Fixed-Function-Pipeline bezeichnet. Durch den Nachfolger
dieser Architektur, die Programmable-Graphics-Pipeline, wurden die
Grafikprozessoren immer leistungsfähiger. Diese neuen Graphic Processing
Units (GPUs) können mit beliebigen Mini-Programmen, den sogenannten
Shadern, ausgestattet werden, um beliebige Berechnungen auszuführen.
Die OpenGL ES Pipeline unterstützt zwei Typen von Shadern, welche an
unterschiedlichen Stellen der Pipeline durchlaufen werden. Jeder übernimmt
davon eine bestimmte Aufgabe. Im Folgenden werden die angedachten Aufgaben
kurz erwähnt. Da die Shader aber frei programmierbar sind, ist es
dennoch möglich, diese für andere Zwecke zu verwenden.
Bei Shadern gibt es eine Besonderheit für Variablen, welche Werte von außerhalb
erhalten oder welche herausgeben. Diese müssen zusätzlich mit einem
Typenqualifizerer versehen werden. Er ist der Typendeklaration vorangestellt
und kommt am Anfang des Shaders.

2.5. GPU PROGRAMMIERUNG 17
Es folgt eine Auflistung der wichtigsten Typenqualifizierer und ihre Bedeutung:
ˆ attribute
Attribute bezeichnen nur lesbare Werte, welche aus den Vertex Buffer
Objekten kommen und beinhalten die fertig interpolierten Werte des
speziellen Vertexes.
ˆ uniform
Typen, welche damit qualifiziert sind, können gezielt in der Anwendung
gesetzt werden, um einen Shader zu steuern bzw. zu manipulieren.
Hiermit wird eine Interaktivität gewährleistet.
ˆ varying
Damit werde Werte bezeichnet, welche vom Vertexshader an den Fragmentshader
übergeben werden.
2.5.1 Vertexshader
Dieser Shader arbeitet strikt auf den Attributen des aktuellen Vertices. Es
kann nicht auf andere zugreifen oder neue hinzufügen. Seine Aufgabe ist
es, die Vertices zu transformieren. Dabei wird klassisch zwischen zwei unterschiedlichen
Bedeutungen unterschieden. Zuerst betrifft es denn Vertex
direkt, dabei kann auf dem Vertex Rotation, Translation und Skalierung angewendet
werde. Zuletzt geht es um die Interpretation des Vertex.
a t t r i b u t e vec3 textureCoord ;
a t t r i b u t e vec3 vertexPos ;
uniform mat4 modelViewMatrix ;
uniform mat4 p r o j e c t i o n M a t r i x ;
varying vec3 textCoord ;
void main ( void )
{
// W e i t e r l e i t e n von Texturkoordinaten zum Fragment Shader
textCoord = textureCoord ;
// Transformieren der V e r t e x p o s i t i o n i n Bildschirm
Koordinatensystem
g l P o s i t i o n = p r o j e c t i o n M a t r i x * modelViewMatrix * vec4 ( vertexPos
, 1 . 0 ) ;
}
Listing 2.1: Minimum Vertexshader in GLSL
Durch verschiedene Matrix-Operationen kann das Koordinatensystem umgerechnet
werden. Klassisch werden Lokalekoordinaten erst in Weltkoordinaten
(Modelmatrix) danach in die Kamerakoordinaten (Viewingmatrix) und

2.5. GPU PROGRAMMIERUNG 18
anschließend in Bildschirmkoordinaten (Projectionmatrix) umgerechnet. Im
Verlauf des Shaders muss dabei gl Position mit den neuen transformierten
Vertex-Attributen gefüllt werden. Das Vertexshader-Programm wird für jeden
Vertex einzeln aufgerufen. Im Listing 2.1 ist ein simples Beispiel für ein
Vertexshader Programm aufgeführt.
2.5.2 Fragmentshader
Der Fragmentshader wird von jedem Fragment einzeln durchlaufen. Dieser
bekommt das Fragment, mit den interpolierten Vertex-Attributen, und
weitere beliebige Werte durch die Varyings. Durch diese Informationen wird
der endgültige Farbwert jedes Fragmentes berechnet. Dafür können beliebige
Berechnungen angewendet oder Texturen ausgelesen und weiterverarbeitet
werden. Auch Post-Processing-Effects wie Bloom, Blur oder Beleuchtung
werden hier errechnet. Auch ist es möglich, gezielt Fragments zu verwerfen
um Löcher in Objekten zu realisieren. Im Verlauf des Shaders muss dabei
gl FragColor die endgültige Fragmentfarbe zugewiesen werden.
Ein simples Beispiel für einen Fragment Shader ist in Listing 2.2 aufgeführt.
varying vec2 textCoord ;
uniform sampler2D t e x t u r e ;
void main ( void )
{
// Lesen der Fragmentfarbe an der P o s i t i o n der Texturkoordinate
g l F r a g C o l o r = texture2D ( texture , textCoord ) ;
}
Listing 2.2: Minimum Fragment Shader in GLSL
Die OpenGL ES Pipeline ist auf den Vertex- und Fragmentshader beschränkt
und diese Shadertypen sind auch zwingend erforderlich. Wenn diese nicht
implementiert werden, ist es nicht möglich das Shaderprogramm zu kompilieren
und auf die Grafikkarte zu übertragen. So etwas wie Standardimplementationen,
welche bei nicht vorhanden sein verwendet werden, sind nicht
vorhanden. Auf der Standard OpenGL Pipeline stehen noch zwei weitere
Shader zu Verfügung. Dabei handelt es sich um den Tesselationshader und
den Geometryshader und diese dienen dazu, die geometrischen Primitiven
zu manipulieren und zu verfeinern. Diese Shadertypen sind dort optional
und können weggelassen werden. Detailliertere Informationen zum Thema
OpenGL ES können dem Buch OpenGL ES 2.0 Programming Guide[8] entnommen
werden.

Kapitel 3
Konzeption
3.1 Auswahl des Rendering Verfahrens
Wie in Abschnitt 2.1.3 Volume Rendering Verfahren dargestellt, gibt es unterschiedliche
Verfahren eine Volumendarstellung zu erzeugen.
Da bei der Umsetzung wegen möglichst großer Portierbarkeit auf OpenGL
ES 2.0 zurückgegriffen wird, ergeben sich einige technische Einschränkungen.
Die Ausschlaggebendste ist, dass dort keine 3D-Texturen zur Verfügung
stehen. Des Weiteren ist ein gewichtiger Grund, dass die Verwendung von
3D-Texturen auch sehr grafikspeicherfüllend ist. Gerade bei mobilen oder
eingebetteten Systemen kann nicht davon ausgegangen werden, dass ein Grafikspeicher
in solch einer Größe vorhanden ist. Mehr zu Datengrößen können
dem Abschnitt 5.1 Datenqualität und Größe entnommen werden. Um Raytracing
mit einer akzeptabler Leistung durchzuführen, wird eine Hardware
der aktuellen Grafikkartengeneration benötigt. Denn erste diese schaffen es,
Schleifen im Shadern mit einer annehmbaren Laufzeit zu verarbeiten. Es
kann davon ausgegangen werden, das die meisten Systeme nicht über eine
solche Hardware verfügen, besonders im Hinblick auf eingebettete Systeme.
Daher würde diese Variante, welche mehrere Schleifen benötigt, eine
sehr schlechte Laufzeit erreichen. Das Shear-Warp und Splatting sind für
die CPU-Umsetzungen erstellt worden, und daher nicht sonderlich geeignet
für die Umsetzung mittels Hardwarebeschleunigung (GPU) und damit wegen
der Aufgabenstellung nicht verwendbar. Aus diesen Gründen wurde für
das weitere Vorgehen die Texture slicing Variante gewählt. Diese eignet sich
hervorragend um mittels Hardwarebeschleunigung auf der GPU umgesetzt
zu werden. Dabei wird sehr speicherschonend gearbeitet, da es mit wenigen
2D-Texturen auskommt.
Die Grundidee des Texture slicing ist in Abbildung 3.1 abgebildet. Dafür
werden mehrere Ebenen hintereinander aufgereiht, sodass diese frontal
vom Benutzer betrachtet werden können. Auf diese werden anschließend die

3.2. PROTOTYPISCHER SOFTWARE-ENTWURF 20
einzelnen Schnitte des Datensatze abgebildet. Durch die Verwendung von
Transparenzen und das Aufaddieren der einzelnen Schnitte entsteht für den
Betrachter eine Volumendarstellung.
Abbildung 3.1: Prinzip der Texture slicing Volumendarstellung: a) Textur
Anordnung b) 2D-Texturen c) Optische Interpretation; Entnommen Real-
Time Volume Graphics [3] Seite 49, Figure 3.1.
3.2 Prototypischer Software-Entwurf
Neben der schriftlichen Ausarbeitung soll ein praktisch verwendbarer Prototyp
erstellt werden. Dieser soll Datensätze, welche aus üblichen Bilddaten
bestehen, laden und diese als Volumengrafik darstellen können. Diese Darstellung
soll vom Benutzer durch eine einfache Oberfläche manipuliert werden
können. Durch das Laden einer Transferfunktion soll der Benutzer die
Möglichkeit haben, die von ihm gewünschten Informationen hervorzuheben
und unerwünschte auszublenden.
Für das Volumen Rendering müssen die Daten vorverarbeitet werden. Dieses
umfasst die Berechnung der Gradienten, welche für die Beleuchtung benötigt
werden, und die Erstellung der verschiedenen Textur-Datensätze für die
verschiedenen Ansichten auf das Volumen. Nachdem diese Vorbereitungen
getroffen wurden, kann eine Darstellung erstellt werden. Dafür müssen zuerst
die Shader in die Grafikkarte übertragen werden, wobei auch die Darstellungsoptionen
des Benutzers auf die Grafikkarte transferiert werden. Daraufhin
werden die einzelnen Ebenen, welche nach dem Texture slicing Verfahren
verwendet werden um das Volumen aufzubauen, einzeln der Grafikkarte
übergeben. Die liest in ihrem Shader die Dichtewerte aus den übergebenen
Texturen aus und klassifiziert diese durch die Transferfunktion, wobei der
endgültige Farbwert ermittelt wird. Abhängig von der folgenden Beleuchtungsberechnung
wird dieser Farbwert schwächer oder intensiver dargestellt.

3.2. PROTOTYPISCHER SOFTWARE-ENTWURF 21
Die Farbwerte alle Ebenen werden miteinander überlagert, um das endgültige
Bild zu erhalten, das auf dem Bildschirm angezeigt wird. Eine Darstellung
der Interaktion des Benutzers und des Volumen Renderings ist in Abbildung
3.2 dargestellt.
Abbildung 3.2: Programmablauf mit Benutzerinteraktion und Rendering
Schritten
Um dieses Konzept zu realisieren, sind nur wenige Komponenten erforderlich.
Die Benutzeroberfläche sollte verständlich gestaltet werden, um dem
Benutzer eine einfache Manipulation der Darstellung zu ermöglichen. Alle
Einstellungen vom Benutzer und die geladenen Daten, sollten performant in
einem DataStore gespeichert werden. Dieses ist soweit wichtig, weil auf die
Daten oft zugegriffen wird. Für die Darstellung wird ein OpenGL fähiges
Widget benötigt, welches die Shader in die Grafikkarte lädt und die benötigten
Daten überspielt. Auch die Anzeige läuft über diese Komponente.
Dieser Grundaufbau ist in Abbildung 3.3 verdeutliche, und stellt die Interaktion
zwischen den Komponenten dar.

3.2. PROTOTYPISCHER SOFTWARE-ENTWURF 22
Abbildung 3.3: Komponenten und ihre angedachte Interaktion untereinander
Bei der Umsetzung ist darauf geachtet worden, strukturiert an die einzelnen
Funktionen heranzugehen. Um die Funktionen übersichtlich zu implementieren,
wurden diese in einzelne Schritte unterteilt und objektorientiert in C++
in Klassen und Methoden umgesetzt. Am Ende jeder einzelnen Funktion war
dadurch eine komplett lauffähige Version verfügbar. So wurden nacheinander
die verschiedenen Funktionen umgesetzt. Im nachfolgenden Abschnitt
4 Umsetzung werden diese Funktionen und Schritte hintereinander präsentiert.

Kapitel 4
Umsetzung
4.1 2D Texture-Sliced Volumen Rendering
4.1.1 Texturen Anordnung
Mit der Darstellung durch mehrere Ebenen ist ein höherer Aufwand verbunden,
als wenn man Volumen mit 3D-Texturen darstellt. Als Bedingung,
damit bei dem Betrachter ein Eindruck eines Volumens entsteht, ist es nötig,
dass die Blickrichtung dessen frontal auf die Ebenen gerichtet ist. Wenn die
Bedingung nicht erfüllt ist, entsteht die Problematik, dass der untersuchte
Strahl auf keine Ebene mehr trifft und der Betrachter nichts mehr vom darzustellenden
Objekt sehen kann. Dieses ist das selbe Phänomen, als wenn
ein Betrachter seitlich auf ein perfekt gerades Stück Papier blickt. So würde
er nur die Stirnseite wahrnehmen, da das Papier eine Dicke besitzt, dennoch
aber nichts von der Vorder- oder Rückseite sehen. Da in der Computergrafik
Ebenen keine Dicke besitzen, wäre für den Betrachter nicht einmal die
Stirnseiten zu erkennen. Dies ist im a) Zweig der Abbildung 4.1 dargestellt.
Abbildung 4.1: Darstellung des Rotationsproblems von Ebenen a) ohne Ebenenwechsel
b) mit Ebenenwechsel

4.1. 2D TEXTURE-SLICED VOLUMEN RENDERING 24
Damit dies nicht passiert, müssen die Ebenen abhängig der Blickrichtung
des Benutzers angepasst werden. Ab einer Blickrichtungsänderung von 45 ◦
muss die Ebenenausrichtung so verändert werden, dass diese wieder frontal
zum Betrachter steht. Wird das auf allen Achsen beachtet, wird bei einer
beliebigen Rotation immer eine konsistente Darstellung entstehen. Dieses ist
im b) Zweig der Abbildung 4.1 dargestellt.
Da abhängig von der Blickrichtung nun verschiedene Ansichten der Daten
benötigt werden, ist es notwendig, diese anfänglich zur Verfügung zu stellen.
Dafür wird für jede der drei Achsen ein eigener Datensatz benötigt, zwischen
welchen bei Bedarf gewechselt werden kann.
4.1.2 Einzelne Textur
Um das Volumen Rendering Integral 2.3 hardwarebeschleunigt nachzubilden,
wird auf die Arbeitsweise des Framebuffers der Grafikkarten-Pipeline
zurückgegriffen. Damit dieses aber funktioniert, ist es notwendig, die Ebenen
von Hinten nach Vorne (back-to-front) zu zeichnen, damit diese aufsummiert
werden können. Die nähere Beschreibung dieses Verfahrens wird unter 4.1.4
Zusammensetzung im Framebuffer erläutert.
Im nachfolgenden Listing 4.1, wird eine Möglichkeit dargestellt, dieses umzusetzen.
Dabei werden die Daten in einem Einheitswürfel [-1,1] und mit
ZCOUNT Ebenen dargestellt.
void GLFrame : : drawSlices NegativZ ( )
{
// Rahmenwerte f ü r d i e Ebenen im Einheitsw ü r f e l
double dZPos = −1.0;
double dZStep = 2 . 0 / f l o a t (ZCOUNT−1) ;
f o r ( i n t s l i c e = 0 ; s l i c e < ZCOUNT; s l i c e ++){
// P o s i t i o n e n der V e r t i c e s
QVector3D v e r t i c e s [ 6 ] = {
. . .
} ;
// Texturekoordinaten der V e r t i c e s
QVector2D textCoord [ 6 ] = {
. . .
} ;
}
}
// Zeichnet d i e V e r t i c e s mit den angegebenen
Texturkoordinaten
drawTexturedQuad ( v e r t i c e s , textCoord ,
bindTexture ( textureStackZ [ s l i c e ] )
) ;
dZPos += dZStep ;
Listing 4.1: Berechnung der Ebenenrichtung der negativen Z-Achse

4.1. 2D TEXTURE-SLICED VOLUMEN RENDERING 25
Um alle Blickrichtungen abzudecken, müssen analog dazu weitere Methoden
für jede der Achsen in positiver und negativer Richtung erstellt werden. Um
die Ebenen in umgekehrter Reihenfolge zu zeichnen, muss nur dZPos = 1.0
initialisiert werden und dann in den negativen Bereich laufen. Der Texturzugriff
erfolgt an der Stelle textureStackZ[ slice −1]. Diese Umsetzung erlaubt
es, abhängig von der Betrachtungsrichtung, die passende Zeichenmethode
aufzurufen.
varying vec2 textCoord ;
uniform f l o a t textAlpha ;
uniform sampler2D t e x t u r e ;
void main ( void )
{
// Konstante Transparenz
f l o a t alpha = 0 . 0 1 ;
g l F r a g C o l o r = vec4 ( texture2D ( texture , textCoord . xy ) . rgb , alpha ) ;
}
Listing 4.2: Fragmentshader für eine Textur mit konstanter Transparenz
Mittels des Fragmentshaders wird dann, wie im Volumen Rendering Integral
2.4 beschrieben, der Farbwert für die aktuelle Ebene berechnet.Dabei
ist die Darstellung der Emission und Absorption direkt auf vorhandene Mittel
übertragbar. Die Emission eines Fragments entspricht dabei genau dem
Farbwert der Textur und die Absorption kann durch den Alpha-Wert der
Farbe umgesetzt werden. Um eine einfache Volumendarstellung zu erzeugen,
wird im Fragmentshader für die Transparenz eine konstanter Wert verwendet.
Im Listing 4.2 wird dieser konstante Wert verwendet.
Abbildung 4.2: Einfache Volumendarstellung mit konstanter Transparenz

4.1. 2D TEXTURE-SLICED VOLUMEN RENDERING 26
Die daraus resultierende Volumendarstellung ist sehr von der Anzahl der
Ebenen abhängig, denn der Farbwert jede Ebene geht mit 1% seines Farbwertes
in das endgültige Bild ein. Dadurch kann es passieren, dass bestimmte
Informationen nicht mehr vom Betrachter erkennbar sind, weil diese von vielen
Ebenen verdeckt werden, die höheren Dichtwerte besitzen.
4.1.3 Mehrfach Texturen
Durch die einfache Texturierung kann zwar ein Volumen erstellt werden,
dennoch ist die Bildqualität sehr von der Anzahl der Ebenen aus dem Datenensatz
abhängig. Durch die 2D-Textur Umsetzung wird die Darstellung
void GLFrame : : drawSlices NegativZ ( i n t r e n d S l i c e s )
{
f l o a t dZPos = −1.0;
f l o a t dZStep = 2 . 0 / f l o a t ( r e n d S l i c e s −1) ;
f o r ( i n t s l i c e = 0 ; s l i c e < r e n d S l i c e s − 1 ; s l i c e ++){
}
}
// Berechnet den Index der benö t i g t e n Texturen
f l o a t dZPosTex = (ZCOUNT*( dZPos +1.0) / 2 . 0 ) ;
i n t texIndex = ( i n t ) dZPosTex ;
// I n t e r p o l a t i o n s w e r t f ü r d i e P o s i t i o n der Ebene zwischen
den Texturen
f l o a t alpha = dZPosTex−f l o a t ( texIndex ) ;
// P o s i t i o n e n der V e r t i c e s mit Verschiebung e ntlang der Z−
Achse
QVector3D v e r t i c e s [ 6 ] = {
QVector3D ( −1.0 , 1 . 0 , dZPos ) ,
. . .
} ;
// Texturekoordinaten der V e r t i c e s mit O f f s e t f ü r P o s i t i o n
zwischen den Ebenen
QVector3D textCoord [ 6 ] = {
QVector3D ( 0 . 0 , 1 . 0 , alpha ) ,
. . .
} ;
// Zeichnet d i e V e r t i c e s mit den angegebenen
Texturkoordinaten
drawTexturedQuad ( v e r t i c e s , textCoord ,
bindTexture ( textureStackZ [ texIndex ] ) ,
bindTexture ( textureStackZ [ min ( texIndex +1,ZCOUNT) ] )
) ;
dZPos += dZStep ;
Listing 4.3: Berechnung einer Ebene aus den Texturen auf der Z-Achse

4.1. 2D TEXTURE-SLICED VOLUMEN RENDERING 27
nur bilinear interpoliert, also entlang der Achsen zwischen denen die Ebene
aufgespannt wird. Optisch wirkt sich dies in der Art aus, dass beim Volumen
Stufenartefakte sichtbar sind. Um diese Beschränkung aufzuheben, kann auf
zwei Texturen zurückgegriffen und aus diesen dann eine dazwischenliegende
Ebene interpoliert werden.
Die Problematik bei der Umsetzung besteht darin, die benachbarten Texturen
zu finden, zwischen welchen die neue Ebene erstellt werden soll. Dafür
muss die Position innerhalb des Einheitswürfels dZPos auf die Texture-Indizes
abgebildet werden, was mittels float dZPosTex = (ZCOUNT * (dZPos + 1.0)/ 2.0)
; geschieht. Dabei bildet (dZPos + 1.0)/ 2.0) die Position auf den Bereich [0.0,
1.0] ab und durch Multiplikation mit der Gesamtanzahl der vorhandenen
Ebenen erhält man eine Fließkommazahl, welche die Position der zu errechnenden
Ebene entspricht. Um den unteren Textur-Index zu erhalten, wird
davon der Ganzzahlteil verwendet. Die zweite Textur ist der nächst höhere
Index bzw. der nächst tiefere darauf. Die Nachkommastellen der Zahl
symbolisieren die Position zwischen den beiden Texturen.
Da die Interpolation erst im Fragmendshader erfolgt, muss der Offset zwischen
den Texturen dem Shader übergeben werden. Um keine zusätzlichen
uniform Variablen verwenden zu müssen, bietet es sich an, die Texturkoordinaten
um eine Dimension zu erweitern und dort den Offset zu speichern.
Bei der Verwendung von Texturen im Zusammenhang mit dem Errechnen
von Texturkoordinaten, kann es durch Rechenungenauigkeiten zu Darstellungsfehler
kommen. Dadurch das die Rechengenauigkeit limitiert ist, kann
es vorkommen, dass die Koordinaten, welche für den Texturzugriff verwendet
werden, den Wertebereich von [0.0,1.0] weit in den Nachkommastellen
verlassen. Dies kann damit behoben werden, dass beim Laden der Textur in
die Grafikkarte (glBindTexture) das Verhalten für das Verlassen des Wertebereiches
angegeben wird. In Listing 4.4 wird aufgeführt, wie die Texturparameter
s und t beim Überschreiten auf den Grenzwert beschränkt werden.
Diese Parameter beschreiben einen Punkt auf der Textur mit s als Breite
und t als Höhe. Weitere Beschreibungen von Texturparametern können in
der OpenGL SuperBible[9] nachgeschlagen werden.
glTexParameteri (GL TEXTURE 2D,GL TEXTURE WRAP S,GL CLAMP TO EDGE
) ;
glTexParameteri (GL TEXTURE 2D,GL TEXTURE WRAP T,GL CLAMP TO EDGE
) ;
Listing 4.4: Textureinstellung zum begrenzen des Wertebereichen
Durch ein paar Änderungen im Fragmentshader kann eine Interpolation
zwischen die beiden Texturen vorgenommen werden. Dafür werden die beiden
Texturen einzeln ausgewertet und zwischen den Ergebnissen, durch den
Textur-Offset, welcher sich nun in den Texturkoordinaten befindet, linear
interpoliert.

4.1. 2D TEXTURE-SLICED VOLUMEN RENDERING 28
varying vec3 textCoord ;
uniform sampler2D t e x t u r e 0 ;
uniform sampler2D t e x t u r e 1 ;
void main ( void )
{
f l o a t mixColor , c o l o r 0 , c o l o r 1 , alpha ;
// Konstante Transparenz
alpha = 0 . 0 1 ;
c o l o r 0 = texture2D ( texture0 , textCoord . xy ) . r ;
c o l o r 1 = texture2D ( texture1 , textCoord . xy ) . r ;
// Lineare I n t e r p o l a t i o n zwischen den Texturen
mixColor = mix ( c o l o r 0 , c o l o r 1 , textCoord . z ) ;
g l F r a g C o l o r = vec4 ( mixColor , mixColor , mixColor , alpha ) ;
}
Listing 4.5: Fragmentshader für mehrere Texturen mit konstanter
Transparenz
Nachdem nun auch in Richtung der letzten Achse interpoliert wurde, ist
die gesamte Volumengrafik nun trilinear interpoliert. Dieser Effekt muss,
wenn im Shader mit 2D-Texturen gearbeitet wird, selbstständig umgesetzt
werden. Bei 3D-Texturen wäre dieses automatisch enthalten, denn bei den
Texturzugriffen würde gleich trilinear interpoliert werden. Bei diese Umsetzung
ist durch etwas mehr Aufwand, die selbe Funktionalität entstanden,
welche bei 3D-Texturen vorhanden wäre. Nur das diese Variante mit weniger
Grafikkartenspeicher auskommt.
Da die Anzahl der Ebenen nun gezielt geändert werden kann, ist es zB. möglich,
bei schlechterer Hardware eine geringere Ebenenanzahl zu verwenden,
um die Anzeige zu beschleunigen. Darunter leidet jedoch die Bildqualität.
Analog kann durch zusätzlichen Ebenen eine bessere Approximation des Volumens
erhalten werden, um die Bildqualität zu erhöhen. Durch die Verwendung
einer Transferfunktion, beschrieben in 4.2.1 Transferfunktion, werden
die auftretenden Stufenartefakte der Volumendarstellung sichtbar reduziert.
Diese Auswirkung ist auf der Abbildung 4.3 gut zu erkennen.
Diese Umsetzung hat jedoch einen großen Nachteil. Für jede Ebene müssen
individuell die passenden Texturen in den Texturspeicher der Grafikkarte
übertragen werden, was einiges an Zeit beansprucht. Alle Ebenentexturen
in den Grafikkartenspeicher zu übertragen, wäre bei kleineren Datensätzen
möglich. In der Realität aber unrealistisch, da gängige Datensätze meistens
den Grafikkartenspeicher übersteigen.

4.1. 2D TEXTURE-SLICED VOLUMEN RENDERING 29
Abbildung 4.3: Mittels Transferfunktion dargestellte Ebenen Links: Einzelne
Texturen (20 Ebenen) Rechts: Mehrfach Texturen (200 Ebenen)
4.1.4 Zusammensetzung im Framebuffer
Damit das Volumen Rendering Integral 2.4 vollständig umgesetzt wird, fehlt
noch die Aufsummierung der einzelnen Farbwerte der Ebenen. Diese Aufgabe
wird hardwarebeschleunigt vom Framebuffer ausgeführt. Damit diese so
ausgeführt werden kann, müssen die Farbwerte der Ebenen, vom Betrachter
aus gesehen, von Hinten nach Vorne verarbeitet werden. Dafür kann das
unter Compositing beschriebene 2.4.3 Alpha-Blending verwendet werden.
Damit das Alpha-Blending die Werte einfach aufsummiert, kann folgende
Funktion verwendet werden.
glAlphaFunc (GL SRC ALPHA, GL ONE MINUS SRC ALPHA)
Dieses bedeutet, dass von dem neuen Fragment, nur in Höhe seines Alpha-
Wertes eingeht und das im Framebuffer schon vorhandene mit der Differenz
dazu. Wenn C ∈ R, G, B die Farbe darstellt und A für die Alphawert steht,
dann entspricht das Mathematisch:
C dest = C src A src + C fb (1 − A src )
Die Aufsummierung von Hinten nach Vorne hat aber auch einen Nachteil.
Ausgegangen vom Raytracingansatz wird hierbei der Strahl rückwärts ausgewertet.
Daher ist es bei diesem Ansatz nicht möglich, die Berechnung
vorzeitig abzubrechen, wenn der Farbwert sich optisch nicht mehr ändern
würde (early ray termination).

4.2. KLASSIFIZIERUNG 30
4.2 Klassifizierung
4.2.1 Transferfunktion
Die simple Volumendarstellung, durch eine Standardtransparenz, ist nicht
sonderlich ansehnlich und zu Auswertungszwecken nicht geeignet. Durch die
Technik der Klassifizierung kann die Darstellung angepasst werden. Dabei
geht es um das Separieren von unterschiedlichen Strukturen, innerhalb des
Volumens, anhand ihrer Dichtewerte. Dafür wird jedem Dichtewert durch
die Transferfunktion ein Farbwert zugewiesen. Durch dieses Abbilden ist es
möglich, einem Dichtewert gezielt eine Absorption und Emission zuzuweisen.
Abhängig von der Transferfunktion ist es nun möglich, bestimmte Informationen
einzufärben oder auszublenden, was die praktische Nutzbarkeit
fördert. Die Herangehensweise zur Erstellung von Transferfunktionen wird
im späteren Abschnitt 5.2 Erstellung einer Transferfunktion beschrieben. In
der dort zu findenden Abbildung 5.3 können Beispiele und ihre Auswirkungen
betrachtet werden.
Es gibt unterschiedliche Verfahren Daten zu klassifizieren, am Häufigsten
findet Pre- bzw. Post-Classification Anwendung. Weiterführende Informationen
können einem Text von Duda, Hart und Stork [10] entnommen werden.
4.2.2 Pre- vs. Post-Klassifizierung
Die beiden Varianten unterscheiden sich darin, zu welchem Zeitpunkt die
Transferfunktionen angewendet wird. Geschieht dieses als Vorverarbeitungsschritt
vor der Interpolation der Dichtewerte, so wird dieses als pre-classification
bezeichnet, geschieht es danach als post-classification. Historisch
gesehen sind die beiden Varianten nacheinander eingeführt worden, denn bei
Abbildung 4.4: Schematische Darstellung von a) Pre-Klassifizierung: zuerst
Klassifizierung dann Interpolation b) Post-Klassifizierung: zuerst Interpolation
dann Klassifizierung

4.2. KLASSIFIZIERUNG 31
der Fixed-Function-Pipeline war es nicht möglich Post-Klassifizierung vorzunehmen,
aus diesem Grund musste dieses vorher geschehen. Erst durch
eine Erweiterung war es möglich weitere Texturzugriffe umzusetzen, sodass
Post-Klassifizierung realisiert werden konnte. Durch die Einführung der programmierbaren
Pipeline wurde die Realisierung noch weiter vereinfacht, da
dieser Standard überall verfügbar war.
Die optische Qualität der beiden Klassifizierungsvarianten ist sehr unterschiedlich.
Da bei der Pre-Klassifizierung die Daten zuerst klassifiziert werden
und anschließend auf den Farbwerten interpoliert wird, treten starke
Blockartefakte auf, sodass das Ergebnis recht grob und körnig wirkt. Bei
der Post-Klassifizierung werden die Dichtewerte zuerst interpoliert, was eine
höhere Auflösung der Werte erreicht. Anschließend können diese Werte gezielt
klassifiziert werden, was zu einem feineren und detaillierteren Resultat
führt. Der Unterschied ist schematische in Abbildung 4.4 dargestellt. Eine
Gegenüberstellung beider Varianten ist im Abbildung 4.5 zu finden.
Abbildung 4.5: Vergleich von Pre-(Links) und Post-Klassifizierung(Rechts)
eines CT-Datensatzes mit der selben Transferfunktion. Entnommen Real-
Time Volume Graphics [3] Seite 90, Figure 4.2.
4.2.3 Post-Klassifizierung
Um die Post-Klassifizierung in die Implementierung zu integrieren, sind nur
ein paar zusätzlicher Codezeilen erforderlich. Dennoch ist dieser Schritt nicht
zu unterschätzen, da er eine große optische Wirkung erzielt.
Es gibt zwei Möglichkeiten Transferfunktionen umzusetzen. Entweder können
diese als Funktion umgesetzt werden oder als Textur. Dabei hat die
Textur-Variante einen Vorteil, diese ist im Gegensatz zu der Funktion aus-

4.2. KLASSIFIZIERUNG 32
tauschbar und ist nicht fest im Code verankert. Dieses ist soweit relevant,
dass die Interaktion mit der Darstellung ermöglicht wird, abhängig von
den gewünschten Informationen können unterschiedliche Transferfunktionen
(Texturen) geladen werden, um die Visualisierung anzupassen.
Um eine Transferfunktion im Fragmentshader zu verwenden, wird diese einfach
als zusätzliche Textur übergeben. Für die sinnvolle Nutzung dieser, ist
noch ein Anwendungsbereich (fromIndex, toIndex) zu verwenden. Auf diesen
Bereich wird die Transferfunktion skaliert und angewendet. Ist ein Dichtewert
unter- oder oberhalb des Bereiches, wird der Minimal- bzw. Maximalwert
verwendet.
In Wirklichkeit ist die Funktion nur eine 1D-Funktion, aber technisch muss
diese in unserem Fall als 2D-Textur umgesetzt werden, da OpenGL ES nur
2D-Texturen unterstützt. Aus diesem Grund wird die Transferfunktionstextur
mit der Höhe 1 umgesetzt und im Fragment Shader dann auf dem
Höhenwert 0.5 ausgelesen, um sicher einen gültigen Farbwert zu erhalten.
varying vec3 textCoord ;
uniform sampler2D t e x t u r e 0 ;
uniform sampler2D t e x t u r e 1 ;
// K l a s s i f i z i e r u n g
uniform sampler2D t r a n s f e r F u n c t i o n ;
uniform f l o a t fromIndex ;
uniform f l o a t toIndex ;
void main ( void )
{
f l o a t mixSample , sample0 , sample1 ;
sample0 = texture2D ( texture0 , textCoord . xy ) . r ;
sample1 = texture2D ( texture1 , textCoord . xy ) . r ;
mixSample = mix ( sample0 , sample1 , textCoord . z ) ;
// Ab den Randwerten bekommt a l l e s den oberen oder unteren Wert
zugewiesen , dazwischen wird d i e Funktion auf den Bereich
s k a l i e r t
i f ( mixSample < fromIndex ) {
mixSample = 0 . 0 ;
} e l s e i f ( mixSample > toIndex ) {
mixSample = 1 . 0 ;
} e l s e {
mixSample = ( mixSample−fromIndex ) /
( toIndex−fromIndex ) ;
}
g l F r a g C o l o r = texture2D ( t r a n s f e r F u n c t i o n , vec2 ( mixSample , 0 . 5 ) ) ;
}
Listing 4.6: Fragment Shader mit Transferfunktion

4.3. BELEUCHTUNG 33
Post-Klassifizierung hat einen gewichtigen Nachteil. Diese kann nur auf neuerer
Hardware umgesetzt werden, denn es wird ein Fragmentshader benötigt.
Dafür ist eine Grafikkarte mit programmierbarer Pipeline notwendig.
4.3 Beleuchtung
4.3.1 Blinn-Phong
Um die Volumendarstellung mit Beleuchtung zu erweitern, wird ein Beleuchtungsmodell
benötigt, dass möglichst unaufwändig zu berechnen ist, sodass
die Laufzeit nicht unnötig belastet wird.
Eines der bekanntesten Beleuchtungsmodelle ist das Phong Shading, welches
nach seinem Entwickler Bui Tuong Phong benannt wurde. In diesem Modell
wird die Beleuchtung aus einem ambient, diffuse und specular Anteil errechnet.
Dieses Modell ist in Formel 4.1 aufgeführt. Eine nähere Beschreibung
der Terme kann dem Artikel [11] von Bui Tuong Phong entnommen werden.
I(p, v) = k a L A
} {{ }
ambient
∑
∑
+ k d L j (n · s j ) + k s L j (v · r j ) a
j
} {{ }
diffuse
j
} {{ }
specular
(4.1)
Ausgehend vom Phong Shading wurde von James F. Blinn 1977[12] ein
erweitertes Modell (Blinn-Phong) vorgestellt, welches die Berechnung des
spekularen Anteils modifiziert. Hier wird davon ausgegangen, dass ein Körper
keine einheitliche gerade und perfekt spiegelnde Oberfläche besitzt, wie
es im Phong-Modell angenommen wird. Diese von Blinn als makroskopische
Normale bezeichnete Vereinfachung entspricht keiner realistischen Oberfläche.
Im Blinn-Phong-Modell besteht eine Oberfläche aus sehr vielen kleinen
spiegelnden Facetten, welche unterschiedlich orientiert sind. Jede dieser Facetten
besitzt eine eigene mikroskopische Normale, dies wird in Abbildung
4.6 schematisiert.
Abbildung 4.6: Visualisierung von mikro- und makroskopischer Normalen

4.3. BELEUCHTUNG 34
Damit nicht jede Facette einzeln Berechnet werden muss, kann eine Vereinfachung
verwendet werden. Dieser Halfway Vectors beschreibt die Normale,
welche eine perfekt spiegelnde Oberfläche haben müsste, um vom Betrachter
v zur Lichtquelle s zu reflektieren. Dabei weicht der Halfway-Vektor h um
den Winkel α h von der makroskopischen Normalen ab. Dies bedeutet, dass
die mikroskopischen Normalen um cos α (α h ) um die makroskopische Normale
verteilt sind.
Abbildung 4.7: Darstellung der Winkel des Blinn-Phong Modells
Durch die Auswertung des Winkels α h wird der spekulare Anteil berechnet.
Der Halfway-Vektor wird wie in Formel 4.2 beschreiben errechnet.
h = v + s
|v + s|
(4.2)
Der spekulare Anteil wird beim Blinn-Phong-Modell mit h ∗ n berechnet.
Wird diese Variante für den spekularen Anteil in der Phong Shading Formel
verwendet, so erhält man die in 4.3 aufgelistete Formel.
I(p, v) = k a L A
} {{ }
ambient
∑
∑
+ k d L j (n · s j ) + k s L j (n · h j ) a
j
} {{ }
diffuse
j
} {{ }
specular(Phong)
(4.3)
Um Blinn-Phong im Fragmentshader umzusetzen, bietet es sich an, dieses in
einer eigene Methode zu strukturieren. In Listing 4.7 ist eine mögliche Umsetzung
dargestellt. Diese Methode bekommt als Parameter die Normale der
Oberfläche n, die Betrachtungsrichtung v und die Richtung zur Lichtquelle
l.

4.3. BELEUCHTUNG 35
vec3 blinnPhong ( vec3 n , vec3 v , vec3 l )
{
// M a t e r i a l i e n
vec3 kAmbient = vec3 ( 0 . 1 ) ; // Ambient
vec3 k D i f f u s e = vec3 ( 0 . 6 ) ; // Defuse
vec3 kSpecular = vec3 ( 0 . 2 ) ; // Spekular
f l o a t s h i n i n e s s = 1 0 0 . 0 ; // R e f l e x i o n s f a k t o r
// Licht
vec3 ambientLight = vec3 ( 0 . 3 ) ;
vec3 l i g h t C o l o r = vec3 ( 1 . 0 ) ;
// Ambienter T e i l
vec3 ambient = kAmbient* ambientLight ;
// Halfway−Vektor zwischen Licht− und Betrachtungsrichtung
vec3 h = normalize ( l+v ) ;
// Defuser T e i l
f l o a t d i f f u s e L i g h t = max( dot ( l , n ) , 0 ) ;
vec3 d i f f u s e = k D i f f u s e * l i g h t C o l o r * d i f f u s e L i g h t ;
// S p e k u l a r e r T e i l
f l o a t s p e c u l a r L i g h t = pow(max( dot (h , n ) , 0 ) , s h i n i n e s s ) ;
vec3 s p e c u l a r = kSpecular * l i g h t C o l o r * vec3 ( s p e c u l a r L i g h t ) ;
// Aufsummieren der E i n z e l t e i l e
r e t u r n ambient+d i f f u s e+s p e c u l a r ;
}
Listing 4.7: Blinn-Phong Methode im Fragmentshader
4.3.2 Gradient Berechnung
Bei der Beleuchtung von Volumengrafiken kommt ein großes Problem auf.
Anders als bei oberflächenbasierten Objekten ist es bei Volumendaten nicht
einfach möglich eine Normale anzugeben. Da keine Flächen oder Abhängigkeiten
zu den benachbarten Daten vorhanden sind, kann ausgehend vom
betrachteten Punkt keine eindeutige Orientierung angegeben werden. Für
die Beleuchtungsberechnung ist eine Oberflächenorientierung aber unerlässlich,
da an dieser der zusätzliche Lichtanteil der Lichtquelle bemessen wird.
Um so etwas wie eine Orientierung zu erhalten, kann die Steigung (Gradient)
der Dichtewerte an der betroffenen Position auswerten werden. Damit
der Gradient dem Wert an der gesuchten Position entspricht, ist es nötig,
diesen aus den umliegenden Daten zu bilden. Dafür wird in jeder Dimension
einfach die Differenz zwischen den umliegenden Daten gebildet. Wenn der
Wert an der Position x i + 1 mit dem Wert bei x i − 1 subtrahiert wird, ergibt
sich daraufhin eine diskrete Approximation für den gesuchten Gradienten

4.3. BELEUCHTUNG 36
an der Position x i . Dieses ist in Abbildung 4.8 symbolisch dargestellt, die
grüne Linie bezeichnet die errechnete Steigung, die rote Linie die Tatsächliche.
Abhängig von der Schrittweite kann eine unterschiedliche Differenz zur
tatsächlichen Steigung auftreten.
Abbildung 4.8: Berechnung des Gradienten (Steigung) an der Stelle x i
Bedingt durch die Berechnung ist der Gradienten-Vektor in Richtung des zunehmenden
Dichtewertes orientiert, also in Richtung der gedachten Fläche.
Für das Beleuchtungsmodell wird aber ein fortgerichteter Vektor benötigt.
Dieser kann durch die einfache Umkehr der einzelnen Komponenten erreicht
werden. Diese Korrektur der Orientierung ist unbedingt notwendig, da sonst
die falsche Seite für die Berechnung der Beleuchtung verwendet werden würde.
In der Abbildung 4.9 ist eine Gegenüberstellung der beiden Ergebnisse,
die Gradienten sind durch Pfeile dargestellt worden.
Abbildung 4.9: Links: Berechnete Gradienten (Steigung), Rechts: Berichtigte
Orientierung

4.3. BELEUCHTUNG 37
Anhand der Länge des Gradienten-Vektors kann die Dichteänderung an der
betrachteten Stelle bewertet werden. Dies kann dafür verwendet werden,
dass nur Gradienten ab einer bestimmten Länge weiter verwendet werden.
Dadurch kann die Wirkung der Beleuchtungsberechnung angepasst werden.
Wenn zB. nur größere Änderungen berücksichtigt werden sollen, führt es
dazu, dass die Konturen der Darstellung mehr betont würden.
Es gibt zwei grundlegende Verfahren den Gradienten zu berechnen. Die erste
Variante besteht darin, die Gradienten vorauszuberechnen (precomputed),
die Zweite wäre es, den Gradienten individuell zu berechnen, wenn dieser
benötigt wird(on the fly). Die zweite Variante würde direkt im Fragmentshader
durchgeführt werden, und da damit auf Nachbarwerte zugegriffen werden
müsste, würden 3D-Texturen benötigt werden. Diese sind in OpenGL
ES nicht verfügbar, daher wurde für die Umsetzung die erste Variante gewählt.
Dies hat noch einen weiteren Vorteil. Da die Daten schon vorhanden
sind, fällt die benötigte Berechnungszeit während der Laufzeit weg. Diese
Berechnungen müssen dennoch der Darstellung vorangehen, dies bietet sich
beim Laden des Datensatzes an.
Die in Listing 4.8 dargestellte Methode berechnet die Gradienten und speichert
diese wieder in einer Textur. Bis jetzt wurde von den Texturwerten
nur eine Komponente verwendet, da alle drei Farbwerte gleich sind (Graufarbenbild).
Wenn der errechnete Gradienten-Vektor in den RGB-Werten
der Textur und der alte Dichtewert in dem Alpha-Wert gespeichert wird,
können alle Informationen in einer Textur untergebracht werden. Das hat
den Vorteil, dass alle Informationen später mit einem Texturzugriff ausgelesen
werden. Dabei ersetzt die Methode die ursprünglichen Daten mit den
Neuen. Wenn die Datensätze für die anderen Ansichten aus dem Original
zusammengesetzt werden, sind dadurch alle Datensätze mit den Gradienten
versehen.
Da sich Volumendaten in alle drei Dimensionen erstrecken, ist es auch nötig
den Gradienten über diese zu bilden. Um dies zu tun, wird ein min-/
und maxSample erstellt und die Differenz dieser ergibt den Gradienten. Die
Sample werden jeweils um eine Einheit davor und danach gewählt.
Da es auch möglich ist, dass der Gradient negative Werte annimmt, muss
dieser zuerst in den positiven Wertebereich skaliert werden, damit er in einer
Textur gespeichert werden kann. Dies geschieht mittels (gradientVec.x()+1)*125
. Dadurch wird der normierte Vektor auf den Wertebereich [0,250] skaliert.
Beim Auslesen der Werte in der Textur ist zu beachten, dass dieser auf
den Wertebereich [-1,1] zurückskaliert wird. Der Wertebereich von 255 wird
gezielt nicht komplett verwendet, da es bei Rechenungenauigkeiten dazu
kommen könnte, dass der Grenzwert von 255 überschritten wird. Dadurch
ist es sichergestellt, dass der Gradient in die Textur gespeichert werden kann.
Um ein besseres optisches Resultat zu erhalten, ist zu empfehlen, nur größere
Dichteänderungen in der Beleuchtung zu berücksichtigen. Das führt
dazu, dass nur die Übergänge betont werden und sich die verschiedenen

4.3. BELEUCHTUNG 38
Materialien stärker voneinander abgrenzen. Dieses kann einfach durch die
Überprüfung der Länge eines Vektors geschehen.
void DataStore : : b u i l d G r a d i e n t S l i c e s ( void )
{
QImageList g r a d i e n t L i s t ;
QVector3D sampleMin = QVector3D ( ) ;
QVector3D sampleMax = QVector3D ( ) ;
const QImage* b e f o r e S l i c e , * c u r r S l i c e , * a f t e r S l i c e ;
// Z u s a t z b i l d f ü r d i e Randuntersuchungen ( Dichtewert 0)
QImage blackImage = QImage ( t e x t u r e S t a c k [ 0 ] . width ( ) ,
t e x t u r e S t a c k O r g i n a l [ 0 ] . h e i g h t ( ) ,
QImage : : Format ARGB32
) ;
blackImage . f i l l ( QColor ( 0 , 0 , 0 ) ) ;
f o r ( i n t sliceNumber = 0 ; sliceNumberwidth ( ) ; x++){
f o r ( i n t y = 0 ; y < c u r r S l i c e −>h e i g h t ( ) ; y++){
// Setzen der min−/max Samples , f ü r Rä nder wird 0
bzw . blackImage verwendet
i f ( x == 0) {
sampleMin . setX ( 0 ) ;
sampleMax . setX ( qRed ( c u r r S l i c e −>p i x e l ( x+1,y ) ) ) ;
} e l s e i f ( x == c u r r S l i c e −>width ( ) −1){
sampleMin . setX ( qRed ( c u r r S l i c e −>p i x e l ( x−1,y ) ) ) ;
sampleMax . setX ( 0 ) ;
} e l s e {
sampleMin . setX ( qRed ( c u r r S l i c e −>p i x e l ( x−1,y ) ) ) ;
sampleMax . setX ( qRed ( c u r r S l i c e −>p i x e l ( x+1,y ) ) ) ;
}
i f ( y == 0) {
sampleMin . setZ ( 0 ) ;
sampleMax . setZ ( qRed ( c u r r S l i c e −>p i x e l ( x , y+1) ) ) ;
} e l s e i f ( y == c u r r S l i c e −>h e i g h t ( ) −1){
sampleMin . setZ ( qRed ( c u r r S l i c e −>p i x e l ( x , y−1) ) ) ;

4.3. BELEUCHTUNG 39
sampleMax . setZ ( 0 ) ;
} e l s e {
sampleMin . setZ ( qRed ( c u r r S l i c e −>p i x e l ( x , y−1) ) ) ;
sampleMax . setZ ( qRed ( c u r r S l i c e −>p i x e l ( x , y+1) ) ) ;
}
sampleMin . setY ( qRed ( b e f o r e S l i c e −>p i x e l ( x , y ) ) ) ;
sampleMax . setY ( qRed ( a f t e r S l i c e −>p i x e l ( x , y ) ) ) ;
QVector3D gradientVec = sampleMax−sampleMin ;
// I n v e r t i e r e n der O r i e n t i e r u n g
gradientVec *= −1.0;
gradientVec . normalize ( ) ;
}
}
// Speichern des Gradienten und Dichtewertes in e i n
neues Image und s k a l i e r t den Wert in den
p o s i t i v e n Bereich
gradientImage . s e t P i x e l ( x , y ,
qRgba ( ( gradientVec . x ( ) +1) *125 ,
( gradientVec . y ( ) +1) *125 ,
( gradientVec . z ( ) +1) *125 ,
qRed ( c u r r S l i c e −>p i x e l ( x , y ) ) )
) ;
}
}
g r a d i e n t L i s t . append ( gradientImage ) ;
// Ersetzen der O r i g i n a l d a t e n mit der Gradient−Variante
t e x t u r e S t a c k . c l e a r ( ) ;
t e x t u r e S t a c k . append ( g r a d i e n t L i s t ) ;
Listing 4.8: Vorbrauserechnung des Gradienten auf dem Datensatz
4.3.3 Integration
Um die Beleuchtung im Fragmentshader zu verwenden, wird nach der Klassifizierung
der Gradient aus der Textur gelesen. Dabei ist zu beachten, dass
die Werte immer noch in ihren alten Wertebereich zurück gerechnet werden
müssen. Dies geschieht mit 2.0*mixSample.rgb−vec3(1.0). Da die Orientierung
des Gradienten beim Speichern schon korrigiert wurde, kann dieser als die
angenommene Normale und die benötigten Betrachtungsrichtung und Lichtrichtung
zur Berechnung der Beleuchtung verwendet werden. Das einfallende
Licht der Beleuchtung wird anschließend auf den Emissionswert aufgerechnet.
In Listing 4.9 ist eine einfache Umsetzung mit fester Lichtposition aufgeführt.

4.3. BELEUCHTUNG 40
varying vec3 textCoord ;
uniform sampler2D t e x t u r e 0 ;
uniform sampler2D t e x t u r e 1 ;
uniform mat3 normalMatrix ;
uniform sampler2D t r a n s f e r F u n c t i o n ;
uniform f l o a t fromIndex ;
uniform f l o a t toIndex ;
void main ( void )
{
f l o a t mixSample , sample0 , sample1 ;
vec4 r e s u l t ;
sample0 = texture2D ( texture0 , textCoord . xy ) . r ;
sample1 = texture2D ( texture1 , textCoord . xy ) . r ;
mixSample = mix ( sample0 , sample1 , textCoord . z ) ;
i f ( mixSample . a < fromIndex ) {
mixSample . a = 0 . 0 ;
} e l s e i f ( mixSample . a > toIndex ) {
mixSample . a = 1 . 0 ;
} e l s e {
mixSample . a −= ( mixSample . a−fromIndex ) /
( toIndex−fromIndex ) ;
}
r e s u l t = texture2D ( t r a n s f e r F u n c t i o n , vec2 ( mixSample , 0 . 5 ) ) ;
// Feste Licht− und Kameraposition
vec3 l i g h t P o s = vec3 ( 0 . 0 , 1 0 . 0 , 0 . 0 ) ;
vec3 eyePos = vec3 ( 0 . 0 , 0 . 0 , 0 . 0 ) ;
// Erweitern und n o r m a l i s i e r e n des Normalen−Vektors
vec3 normal = 2 . 0 * mixSample . rgb−vec3 ( 1 . 0 ) ;
// Korrektur der O r t hogonalit ä t
normal = normalize ( normalMatrix * normal ) ;
// Berechnung der Licht− und B l i c k r i c h t u n g
vec3 viewDir = normalize ( eyePos−p o s i t i o n ) ;
vec3 l i g h t D i r = normalize ( l ightPos −p o s i t i o n ) ;
// Addieren des Beleuchtungswertes zur Emision
r e s u l t . rgb += blinnPhong ( normal , viewDir , l i g h t D i r ) ;
g l F r a g C o l o r = r e s u l t ;
}
\ c l e a r p a g e
Listing 4.9: Fragmentshader mit Transferfunktion und Blinn-Phong
Beleuchtung

4.3. BELEUCHTUNG 41
Diese Beleuchtung führt dazu, das Stellen, welche von der Lichtquelle erreicht
werden, einfach heller dargestellt werden. Eine realistischere Darstellung
kann erreicht werden, wenn als Material für den ambienten und diffusen
Teil die Emission der Klassifizierung verwendet wird. Das führt dazu, dass
die originale Darstellung weniger verfälscht wird und nur stärker oder schwächer
in das Gesamtresultat eingeht.

Kapitel 5
Ergebnisse & Auswertung
Im Rahmen dieser Arbeit wurde ein Softwareprototyp entwickelt, der es ermöglicht,
beliebige 3D-Bildstapel mittels direktem Volumen Rendering und
beliebiger Transferfunktionen interaktiv darzustellen. Abbildung 5.1 zeigt
einen Screenshot der Benutzeroberfläche. Es sind zwei unterschiedliche Darstellungen
nutzbar. Zum Einen die Volumendarstellung, zum Anderen die
Slices des Datensatzes. Diese Darstellungen können zusammen verwendet
werden. Die Volumendarstellung kann rotiert werden, um diese von beliebigen
Ansichten zu betrachten. Durch das Interface ist es möglich, den Anwendungsbereich
der Transferfunktion einzustellen und die Lichtquelle für
die Beleuchtung zu positionieren.
Abbildung 5.1: Ansicht der resultierenden Umsetzung

5.1. DATENQUALITÄT UND DATENGRÖSSE 43
5.1 Datenqualität und Datengröße
Die Eigenschaften des Ausgangsdatensatzes sind maßgeblich am optischen
Resultat der Volumendarstellung beteiligt. Ein Schnitt eines bildgebenden
Verfahrens hat üblicherweise eine Bildgröße von 512 x 512 Pixel, aber auch
kleinere Bildgrößen sind möglich. Bedingt durch die Art des bildgebenden
Verfahrens besitzen die Datensätze eine Farbtiefe von 8, 12 bzw. 16 Bit. Die
Farbtiefe beeinflusst die mögliche Menge der darstellbaren Farbabstufungen.
Diese Abstufungen sind insoweit wichtig, da diese die möglichen Dichtewerte
darstellen. Bei einer Farbtiefe von 8 Bit sind 2 8 = 256 Abstufungen möglich,
es können daher 256 Dichtewerte unterscheiden werden. Dagegen können
bei 16 Bit Farbtiefe bereits 2 16 = 65536 Abstufungen unterschieden werden.
Durch die Verwendung von mehr Abstufungen kann das original Objekt
besser abgebildet werden. Für die Bildqualität bedeuten mehr Abstufungen
weichere Übergänge und die Möglichkeit die Klassifizierung genauer vornehmen
zu können.
Um so höher die Farbtiefe eines Bildes ist, um so mehr Speicherplatz wird benötigt.
Bei der aktuellen Entwicklungsgeschwindigkeit von Hardware wird
dies oft als nicht relevant angesehen, da Festplatten- und Arbeitsspeicher
immer größer werden. Doch für die Nutzung von Bildern als Texturen in
der GPU ist die Speicherkapazität eingeschränkter. Ein Standarddatensatz
mit 512 x 512 Pixel und einer Farbtiefe von 8 Bit, welcher aus 600 Ebenen
besteht, würde wie in Rechnung 5.1 beschrieben 150 MB Speicherplatz benötigen.
Da bei dieser Volumendarstellung für jede Achse ein eigener Datensatz
vorrätig gehalten werden muss, werden somit schon 450 MB nötig. Bei einer
16 Bit Farbtiefe würde der selbe Datensatz schon 900 MB benötigen.
(512 ∗ 512)pix ∗ 8 bit = 2097152 bit pro pix
2097152 bit /8 bit = 262144 Bytes
262144 Bytes /1024 = 256 kB
(5.1)
600 Ebenen ∗ 256 kB = 153600 kB /1024 = 150 MB
150 MB ∗ 3 Texturstacks = 450 MB
Für die Umsetzung wurde zusätzlich noch ein Alpha-Kanal verwendet, da
für die Beleuchtung in den Farbkanälen der Gradient mit gespeichert wurde.
Daher wurde ein Bildformat mit 32 Bit Farbtiefe verwendet. 24 Bit für die
Farbkanäle + 8 Bit für den Alpha-Kanal, mit solch einem Format kommt
der selbe Datensatz auf 1,76 GB Speicherbedarf. Eine hohe Anzahl von Abstufungen
verbessert die Volumendarstellung, benötigt aber einen höheren
Aufwand bei der Speicherverwaltung.

5.2. ERSTELLUNG EINER TRANSFERFUNKTION 44
5.2 Erstellung einer Transferfunktion
Die Erstellung von Transferfunktionen ist eine Wissenschaft für sich. Es existieren
eigene Publikationen zu dieser Thematik, wie Optimal generation of
transfer functions for direct volume rendering von G.M. Nicoletti [13]. Es
gibt keine allgemeingültige gute Transferfunktion, diese müssen speziell für
die zu betrachtende Information erstellt werden. Dies ist eine Arbeit die manuell
erfolgen muss, da jeder Datensatz leicht unterschiedlich ist. Eine gute
Transferfunktion erreicht eine scharfe Abgrenzung zwischen den verschiedenen
Strukturen und besitzt dennoch weiche Übergänge innerhalb der selben
Struktur.
Eine Transferfunktion wird meistens auf einen Bereich angewendet, welcher
sich innerhalb des Wertebereiches von vorhandenen Dichtewerten befinden.
Die Transferfunktion wird dann auf diesen Bereich skaliert, sodass das Verhältnis
der erstellten Funktion gleich bleibt. Für Dichtewerte, welche sich
außerhalb dieses Bereiches befinden, werden die nächstliegenden definierten
Werte verwendet. Also für darunter liegende Werte der Niedrigste und für
darüber liegende der Höchste. Durch die Verwendung von Transparenzen
können gezielt Objekte ausgeblendet werden.
Die nachfolgende Betrachtung wurde mit der Software Visage7 1 der in Berlin
ansässigen Firma Visage Imaging durchgeführt. Da dieses Programm einen
ausgereiften und intuitiven Editor für Transferfunktionen beinhaltet, eignet
es sich sehr gut um die Funktionsweise darzustellen.
Um eine Transferfunktion zu erstellen, ist es vorteilhaft, zuerst ein Histogramm
des Datensatzes zu betrachten. In diesem ist die Verteilung der Dichtewerte
aufgezeigt und lässt es zu, grob die verschiedenen Strukturen zu unterscheiden.
In Abbildung 5.2 ist dieses verdeutlicht: Im mit a) bezeichneten
Bereich befinden sich Luft und andere gasartige Stoffe. In b) befindet sich
Haut und c) schließt Muskeln, Sehnen und Adern ein. Im Bereich d) sind
Knochen und härteren Materialien wie Zahnschmelz anzusiedeln. Um nun
Abbildung 5.2: Histogramm eines Datensatzes a) Luft b) Haut c) Muskeln
d) Knochen
1 http://www.visageimaging.com/visage7-overview.html [24.01.13]

5.2. ERSTELLUNG EINER TRANSFERFUNKTION 45
Knochen darzustellen, muss am Anfang des Dichtebereiches, wo die Knochen
beginnen, zB. die Farbe Weiß zugewiesen werden. Um sanfte Übergänge in
den Knochen zu erhalten, wird die Farbe mit fallender Transparenz umgesetzt.
Auf die selbe Art können dann beliebige Bereiche hervorgehoben
werden, zB. Muskelansätze oder die Haut. In Abbildung 5.3 ist das Resultat
zusammen mit den Transferfunktionen dargestellt. Bei der Abbildung der
Transferfunktion, ist an dem Slider-Element die Länge der Funktion zu erkennen.
Abbildung 5.3: Beispiele für Transferfunktion mit Resultat
Um ein optisch ansprechendes Resultat zu erhalten, ist darauf zu achten,
dass durch passende Transparenzen weiche Übergänge entstehen. Das sorgt
dafür, dass zB. ein Knochen eine konsistente Darstellung über seine Dichtewerte
bekommt. Dabei ist zu beachten, nicht unnötig großzügig im Dichtebereich
zu sein, denn nur wenn diese Bereiche den einzelnen Strukturen
passend zugeordnet sind, wird zwischen ihnen eine scharfe Abgrenzung erreicht.
Ist erst einmal eine Transferfunktion erstellt worden, ist diese, zumindest für
CT-Daten, für ähnliche Körperteile wiederverwendbar. Dieses kommt daher,
dass dank der Hounsfield-Skala 2 die Dichtewerte normiert sind. Bei dieser
hat Luft einen Wert von -1000, Gewebe ca. -100, Wasser 0 und Knochen
Werte von 500 bis 1500. Bei anderen bildgebenden Verfahren, wie MRT, ist
solch ein Standard nicht vorhanden.
Der Aufwand zur Erstellung einer Transferfunktion ist abhängig von der darzustellenden
Information. Besonders die Feineinstellung, um die passenden
Abgrenzungen zu erhalten, kann einiges an Zeit beanspruchen. Wenn in der
2 http://www.mta-r.de/allgemein/2011/10/die-hounsfield-skala-im-ct/ [15.02.13]

5.3. VERGLEICH DER EIGENEN UMSETZUNG MIT VISAGE7 46
Darstellung Beleuchtung verwendet werden soll, ist es nötig, eine Funktion
auch darauf anzupassen. Eine nicht darauf angepasste Funktion wird in den
meisten Fällen ein schlechteres Resultat erbringen.
5.3 Vergleich der eigenen Umsetzung mit Visage7
Auch wenn die eigene Umsetzung im Rahmen einer Bachelorarbeit nicht
mit einer hochspezialisierten kommerziellen Lösung vergleichbar ist, muss
sich eine Anwendung immer mit den existierenden Umsetzungen messen.
Zum Vergleich wurde die kommerzielle Anwendung Visage7 verwendet. Verglichen
wurde anhand der Bildqualität der resultierenden Volumendarstellung,
die Bedienung und Funktionen wurden nicht mit berücksichtigt. Für
die Darstellung wurden die selben Volumendaten verwendet und durch eine
identische Transferfunktion interpretiert, bei beiden Anwendungen wird
Beleuchtung verwendet.
Um eine vergleichbare Qualität zu erhalten, wurde eine in Visage eingebaute
Funktion für die eigene Umsetzung außerhalb der Anwendung vorbereitet.
Visage filtert die verwendeten Datensätze automatisch beim Importieren,
was dazu führt, dass die Oberflächen weicher und Gleichmäßiger dargestellt
werden. Für die eigene Umsetzung wurde der Datensatz vorher mittels eines
Bildverarbeitungsprogrammes mit einem Filter vorbearbeitet. Das Ausgangsmaterial
ist für beide Anwendungen jedoch identisch. Die Gegenüberstellung
ist in Abbildung 5.4 zu finden.
Beobachtung
ˆ Oben:
Bei beiden Bildern sind die verschiedenen Bereiche gut zu unterscheiden,
zB. erkennt man auf beiden Bildern gut den Kehlkopf und die
Muskeln am Hals. Durch die Klassifizierung heben sich auch Haut und
Knochen von einander ab. Die Schlüsselbeine sind sehr deutlich zu erkennen
und auch das Stirnbein ist zu sehen, bei dem eigenen Bild um
die Augen aber nur noch schwach angedeutet. Durch die Klassifizierung
wirkt bei dem Bild von Visage die Oberfläche wie Haut, bei dem
eigenen Bild wie Fleisch.
ˆ Mitte:
Beide Bilder haben eine Andeutung des Fleisches (rot), da diese nicht
komplett transparent ist. Bei dem eigenen Bild wirkt dies zusammen
mit der Farbe des Schädels wie eine Maske. Der Schädel und auch die
Zähne sind bei dem Bild von Visage deutlicher erkennbar.

5.3. VERGLEICH DER EIGENEN UMSETZUNG MIT VISAGE7 47
ˆ Unten:
Die Zähne sind auf dem eigenen Bild so gut wie gar nicht mehr zu
erkennen. Wieder verfälscht die Andeutung des Fleisches(rot) das Bild
etwas. Im Vergleich zu dem Bild von Visage, bei dem noch Gewebeähnliches
im Schädel angedeutet wird, ist bei dem eigenen Bild direkt die
Schädelrückwand zu sehen. Auch treten bei dem eigenen Bild Fehler
in Form von Ringen auf der Oberfläche auf.
Analyse
Der auffälligste Unterschied liegt darin, dass die eigene Umsetzung vertikal
gestaucht ist. Dies kommt daher, dass in der Umsetzung die Proportionen
nicht mit berücksichtigt werden, da der Datensatz immer in einem Einheitswürfel
[-1,1] erstellt wird. Bei Visage wird der Schichtabstand der Datensätze
mitverwendet, um die Proportionen zu erhalten. Die Farben bei Visage werden
viel feiner abgestuft als bei der eigenen Umsetzung, daher können bei
Visage die einzelnen Strukturen besser dargestellt werden. Dies kommt daher,
dass Visage wahrscheinlich eine viel höhere Abstufungsanzahl, 12 bzw.
16 Bit für jeden Farbkanal, verwendet, als die Eigene Umsetzung, die nur
8 Bit für jeden Farbkanal verwendet und daher die Transferfunktion frei
darauf verteilen kann. Daher sind die Übergänge in und zwischen den unterschiedlichen
Strukturen viel weicher.
Die Beleuchtung erfüllt bei beiden ihren Zweck, die Abgrenzung zwischen
den Strukturen hervorzuheben. Nur treten bei der eigenen Umsetzung gelegentlich
Beleuchtungsartefakte auf. Diese sind dann als helle Streifen sichtbar,
ähnlich der Stufenartefakte nur nicht so weitläufig, und treten im diffusen
Anteil der Beleuchtung auf.
Da Visage serverbasiert arbeitet und die fertige Darstellung zu den Clienten
überträgt, ist davon auszugehen, dass dieser Server mit einer sehr leistungsfähigen
Grafikkarte mit hohem Grafikspeicher ausgestattet ist. Dort werden
für die Berechnung der Darstellung vermutlich 3D-Texturen und eine weitaus
größere Anzahl an Ebenen verwendet. Auch sind weitere Filterungstechniken
denkbar, welche unterschiedlichste Artefakte kaschieren.

5.3. VERGLEICH DER EIGENEN UMSETZUNG MIT VISAGE7 48
Abbildung 5.4: Gegenüberstellung von Visage7 (links) und der eigenen Umsetzung
(rechts). Dabei wurden die selben Volumendaten und Transferfunktion
verwendet.

Kapitel 6
Zusammenfassung &
Ausblick
6.1 Zusammenfassung
Das Ziel dieser Arbeit war, die Konzeption und Umsetzung eines Softwareprototypen,
der die 3D-Visualisierung medizinischer Bilddaten mittels direktem
Volumen Rendering ermöglicht. Dazu wurden alle grundlegenden
Techniken betrachtet und umgesetzt. Die Anwendung ist in der Lage, beliebige
Datensätze, welche aus Bilddateien bestehen, zu laden und anzuzeigen.
Diese Volumendarstellung kann anschließend mittels einer Transferfunktion
klassifiziert werden, um die Darstellung für den Betrachter anzupassen. Um
die Klassifizierung noch weiter hervorzuheben, kann durch die Beleuchtung
der Kontrast zwischen den einzelnen Strukturen verstärkt werden.
Bei der Realisierung, wurde auf die Portabilität der Anwendung geachtet,
sodass diese auch auf Geräten zu nutzen ist, welchen nur eingeschränkte grafische
Ressourcen zur Verfügung stehen. Um das zu erreichen, wurden daher
nur 2D-Texturen verwendet, da diese nur wenig Grafikspeicher benötigen.
Um dennoch die relativ großen Volumendaten anzuzeigen, werden nur die
aktuell benötigten Daten in den Grafikspeicher geladen. Dies führt dazu,
dass oft neue Texturdaten zur Grafikkarte übertragen werden müssen, der
Speicherverbrauch aber gering bleibt. Durch die Klassifizierung mittels einer
Transferfunktion werden die Dichtewerte in beliebige Strukturen eingeteilt
und dargestellt, dabei handelt es sich um ein Zuordnung von Farbwerten.
Für die Beleuchtung wird das Blinn-Phong Modell verwendet. Damit dieses
anwendbar ist, werden aus den Dichtewerten Gradienten errechnet, welche
die Approximation der Normale für die Oberfläche darstellen.
Besonders zu erwähnen ist, dass die Erarbeitung und Umsetzung der Beleuchtung
nicht trivial ist. Die Problematik der nicht vorhandenen Normalen
in Volumengrafiken, die durch Gradienten ersetzt werden, macht die Erstellung
weitaus komplexer. Da für den Datentransfer in die GPU hauptsächlich

6.2. AUSBLICK 50
auf Texturen zurückgegriffen wurde, ergaben sich öfters Rechenungenauigkeiten,
welche zu störenden Darstellungsfehlern führten. Diese treten meistens
auf, wenn der Wertebereich nicht passend gewählt oder überschritten
wurde. Daher muss bei solch einer Umsetzung sehr genau auf Grenzwerte
geachtet werden.
Auch wenn die Herangehensweise über 2D-Texturen mehr Aufwand bedeutet,
wird diese mit einer nützlichen Eigenschaft honoriert. Es muss zwar die
dreifache Menge an Texturen an die Grafikkarte übergeben werden, ermöglicht
aber, nur die momentan benötigten Texturen nacheinander hochzuladen.
Dies hat den Vorteil, dass nicht das gesamte Volumen im Grafikspeicher
vorhanden sein muss und dadurch wenig Speicher benötigt wird. Diese Eigenschaft
geht bedauerlicherweise auf die Laufzeit des Programmes, da oft
neue Texturen in den Grafikspeicher geladen werden müssen.
Zusammenfassend kann das gesetzte Ziel als gelöst angesehen werden, trotz
des sehr komplexen Themas wurde ein durchaus verwendbarer Prototyp
entwickelt. Dieser läuft auf allen OpenGL ES 2.0-fähigen Plattformen und
bietet alle Basisfunktionen zur Volumendarstellung.
6.2 Ausblick
Obwohl im Rahmen der vorliegenden Arbeit ein funktionierender Prototyp
erstellt wurde, bietet sich eine Vielzahl von Möglichkeiten, um die Performanz
und die Darstellungsqualität der 3D-Visualisierung zu verbessern. Im
Nachfolgenden werden einige weiterführende Thematiken erörtert.
Die momentane Ausarbeitung ist nur auf Funktionalität bedacht und beinhaltet
keine Optimierungen. Besonders im Bereich der Performance ist dies
dringend zu empfehlen, da diese vom Benutzer sehr dominant wahrgenommen
wird. Eine Anwendung die ruckelt oder unnötig hohe Ladezeiten aufweist,
wird es sehr schwer haben sich zu etablieren. Im Normalfall wird
bei der Betrachtung einer Information der größte Teil des Datensatzes ausgeblendet,
wobei sehr viele transparente Daten verrechnet werden. Durch
Empty-Space Leaping [14] könnten transparente Bereiche im Vorfeld identifiziert
und anschließend bei der Berechnung ausgelassen werden. Die Grundidee
dabei ist es, den Datensatz in Blöcke zu zerlegen und für diese den
minimalen und maximalen Dichtewert zu speichern. An diesen kann dann
eine Bewertung stattfinden, welche entscheidet, ob der Block überhaupt berechnet
werden muss. Eine andere Möglichkeit wäre das Bricking. Dieses
Verfahren wird meist im Zusammenhang mit 3D-Texturen erwähnt, ist aber
auch bei 2D-Texturen denkbar. Dabei geht es darum, das Volumen in mehrere
Blöcke zu unterteilen und dann möglichst viele Blöcke im Grafikspeicher
zu lassen, sodass so wenig Texturen wie möglich neu in den Grafikspeicher
geladen werden müssen. Dadurch soll der Flaschenhals beim Übertragen der
Daten in den Grafikspeicher reduziert werden. Eine weitere Optimierung

6.2. AUSBLICK 51
wäre die Early Ray Termination, welche das Aufsummieren der Ebenen beschleunigt
bzw. entlastet. Bei diesem Verfahren geht es darum, nur solange
Ebenen zu berechnen, bis neue Ebenen keinen erkennbaren optischen Unterschied
mehr ausmachen, also das Alpha-Blending im Framebuffer frühzeitig
abzubrechen. Da die vorderen Ebenen dadurch aber immer eingehen werden,
ist es nötig die Ebenen front-to-back durchzugehen und dann ggf. frühzeitig
zu enden. Dieses Verfahren benötigt aber einiges an Aufwand, da die aktuelle
Umsetzung mittelt dem back-to-front Verfahren arbeitet, um mittels
Framebuffer die Fragments aufzusummieren.
Ein anderer Optimierungsbereich wäre die Darstellungsqualität. Um ein einheitlicheres
Bild zu erhalten, sollten die Originalbilder des Datensatzes vor
der Verwendung noch gefiltert werden. Dies würde dafür sorgen, dass die
Oberflächen und Übergänge weicher werden. Besonders für die Beleuchtung
ist es von Vorteil, da die Fluktuation der Gradienten geringer wird. Da dies
beim Laden des Datensatzes erfolgen müsste, hat es nur längere Ladezeiten
der Datensätze zufolge. Die Berechnung der Volumendarstellung wird
dabei nicht weiter beeinträchtigt. Abhängig davon, was für ein Datensatz
verwendet wird, können Stufenartefakte auftreten. Es gibt verschiedenste
Möglichkeiten wodurch diese hervorkommen zB. blending artifacts, shading
artifacts, den größten Einfluss haben aber die sampling artifacts. Diese treten
auf, wenn die Anzahl der Ebenen zu gering ist, also das sampling Theorem
verletzt wurde. Dieses Theorem sag aus, dass die Abtastung > 2 * maximale
Frequenz sein muss. Ein Weg dieses Problem zu behandeln läge darin, die
Volumendarstellung in homogene und inhomogene Bereiche einzuteilen und
die inhomogenen mit einer höheren Anzahl von Ebenen abzudecken.
Um die praktische Nutzbarkeit zu steigern, wäre es von Vorteil gewisse neue
Funktionen umzusetzen. Besonders die Möglichkeit Bereiche aus der Darstellung
zu entfernen sollte umgesetzt werden. Ohne diese Funktion ist es
nur möglich Dichtewerte gänzlich zu entfernen. Dennoch haben verschiedene
Strukturen den selben Dichtewert und verdecken ggf. die gewünschte
Information. Eine einfache Lösung dieses Problems sind virtuelle Schnittebenen(clipping
planes). Diese blenden ab ihrer Position alles Weitere des
Volumens aus, sodass es möglich ist an einer Stelle einen Querschnitt zu
betrachten. Eine andere Realisierung, die mehr Aufwand erfordert, wäre die
Möglichkeit, ein virtuelles Skalpell zu implementieren, sodass der Benutzer
Elemente im Volumen herausschneidet und dadurch Bereich von Interesse
freigelegt werden können. Da dies nur partiell geschieht, würde der Zusammenhang
im Gesamtvolumen erhalten bleibt.
Mit diesen Thematiken würde eine erhebliche Steigerung der praktischen
Nutzbarkeit einhergehen. Dennoch sollte für weiteres Vorgehen der Aufwand
der Erarbeitung dem Nutzen des Resultates entgegengestellt werden. Der
größte Nutzen würde durch die Optimierung der Bildqualität einhergehen,
denn dies wird vom Benutzer aktiv wahrgenommen und eine hochwertige
Darstellung ist die Hauptaufgabe einer Volumendarstellungs-Anwendung.

6.2. AUSBLICK 52
Anschließend sollte die Performance betrachtet werden. Dabei ist zu beachten,
dass Performance-Verbesserungen aufwändig sind, vom Nutzer im
sichtbaren Bereich aber direkt wahrgenommen werden. Neue Funktionen zu
behandeln hat in der Weiterführung nicht unbedingt hohe Priorität. Besser
wenige Funktionen, welche gut umgesetzt sind, als viele Möglichkeiten ohne
passende Qualität.
Während der Erarbeitung dieses Themas haben sich einige technische Neuerungen
ergeben. Am 10. Januar 2013 ist die neue OpenGL ES 3.0 Spezifikation
1 erschienen. Durch diese neue Spezifikation sind einige in dieser
Ausarbeitung getroffene Entscheidungen neu zu bewerten, da mit ES 3.0 die
Verwendung von 3D-Texturen möglich ist. Dennoch wird es noch weiter Zeit
benötigen, bis die Grafikkarten die neue Version unterstützen. Auch wenn
dadurch die technische Möglichkeit gegeben ist, wird von den meisten Geräten
der Grafikspeicher nicht ausreichen, um ausreichend große 3D-Texturen
bereitzustellen.
1 http://www.khronos.org/registry/gles/

Danksagung
An dieser Stelle möchte ich mich bei allen Personen bedanken, die mich bei
der Erstellung dieser Arbeit unterstützt haben.
Ein besonderer Dank gilt meinem Betreuer Herrn Prof. Dr.-Ing. Hartmut
Schirmacher, der mit sehr viel Engagement, guten Anregungen, kritisches
Hinterfragen und unermüdlichem Einsatz meine Bachelorarbeit betreut hat.
Besonders zu den Zeiten, an denen mich die Motivation und der Wille weiterzumachen
fehlte, hat er die Nerven behalten und an mich geglaubt. Vielen
Dank für Zeit und Mühen, die Sie in meine Arbeit investiert haben.
Daneben gilt mein Dank meiner Freundin Sandra Krohn, die in zahlreichen
Stunden Korrektur gelesen hat. Und eine große Hilfe dabei war Schwächen
aufzuweisen, wo noch Erklärungsbedarf bestand.
Vielen Dank an die Berliner Firma Visage Imaging, welche mir Zugang zu einem
Demo Account ihrer kommerziellen Anwendung Visage7 ermöglichten.
Die Erfahrungen und Beobachtungen mit diesem Programm hat maßgeblich
dazu beigetragen, dass diese Arbeit nun in der Form vorliegt.
Nicht zuletzt gebührt meinen Eltern Dank, da Sie während des Studiums
nicht nur finanziell, sondern vor allem auch emotional immer für mich da
waren. Und als Fachfremde die Verständlichkeit der Arbeit begutachteten
und Korrektur lasen.

Anhang A
CD-Inhalt
Datei
CT-Data (Ordner)
references (Ordner)
voxelViewerSrc (Ordner)
pre-compiled (Ordner)
index.htm
Readme.txt
Bachelorarbeit.pdf
Inhalt
Datensätze und Transferfunktionen
Offline Webreferenzen und Artikel
Sourcecode der Umsetzung, VoxelViewer
Vorkompilierte Versionen der Umsetzung
Index der Webreferenzen
Installations-/Verwendungsanleitung
Digitale Version der Bachelorarbeit

Literaturverzeichnis
[1] Andrew S. Glassner. Principles of Digital Image Synthesis. Morgan
Kaufmann, 2nd edition, Mar. 1995.
[2] H. C. Hege, T. Hollerer, and D. Stalling. Volume rendering
mathematical models and algorithmic aspects.
http://www.cs.ucsb.edu/∼holl/pubs/hege-1993-vrm.pdf, 1993. Report
TR 93-7, Last checked 2013.01.10 19:34.
[3] Klaus Engel, Markus Hadwiger, Joe Kniss, Christof Rezk-Salama, and
Daniel Weiskopf. Real-Time Volume Graphics. A K Peters, Ltd., 1st
edition, Aug. 2006.
[4] Philippe Lacroute and Marc Levoy. Fast Volume Rendering Using a
Shear-Warp Factorization of the Viewing Transformation. Proc. SIG-
GRAPH ’94, pages 451–458, 1994.
[5] Charles D. Hansen and Chris R. Johnson. Visualization Handbook.
Academic Press, 1st edition, Dez. 2004.
[6] Randima Fernando (Series Editor). GPU Gems: Programming Techniques,
Tips and Tricks for Real-Time Graphics. Addison-Wesley Professional,
Apr. 2004.
[7] Khronos Group. OpenGL ES 2.0 Dokumentation.
http://www.khronos.org/opengles/sdk/docs/man/. Last checked
2013.01.13 15:10.
[8] Aaftab Munshi, Dan Ginsburg, and Dave Shreiner. OpenGL ES 2.0 Programming
Guide. Addison-Wesley Professional, 1 edition, Aug. 2008.
[9] Richard S. Wright, Nicholas Haemel, Graham Sellers, and Benjamin
Lipchak. OpenGL SuperBible: Comprehensive Tutorial and Reference
(5th Edition). Addison-Wesley Professional, 5th edition, Aug. 2010.
[10] Richard O. Duda. Pattern Classification 2nd Edition with Computer
Manual 2nd Edition Set. Wiley-Interscience, 2nd edition, June 2004.

LITERATURVERZEICHNIS 56
[11] Bui Tuong Phong. Illumination for computer generated pictures. Commun.
ACM, 18:311–317, June 1975.
[12] James F. Blinn. Models of light reflection for computer synthesized
pictures. SIGGRAPH Comput. Graph., 11(2):192–198, July 1977.
[13] G.M. Nicoletti. Optimal generation of transfer functions for direct volume
rendering. System Theory, 2003. Proceedings of the 35th Southeastern
Symposium on, pages 367–371, March 2003.
[14] Wei Li, Klaus Mueller, and Arie Kaufman. Empty space skipping and
occlusion clipping for texture-based volume rendering. IEEE Visualization
2003, pages 317–324, Dec. 2003.
[15] Jason Gregory. Game Engine Architecture. A K Peters, Ltd., July 2009.
[16] Randi J. Rost, Bill M. Licea-Kane, Dan Ginsburg, John M. Kessenich,
Barthold Lichtenbelt, Hugh Malan, and Mike Weiblen. OpenGL Shading
Language. Addison-Wesley Professional, 3rd edition, July 2009.
[17] Willi A. Kalender. Computed Tomography. Publicis, 3rd edition, Aug.
2011.
[18] Joe M. Kniss, Klaus Engel, and Christof Rezk-Salama. High-quality volume
graphics on consumer pc hardware. Course Note 42, SIGGRAPH,
page 122, 2002.
[19] Qt Project. Qt 4.7 Dokumentation.
http://doc.qt.digia.com/4.7/index.html. Last checked 2013.01.13
16:00.