Interaktive Visualisierung zeitabhängiger Volumendaten

Interaktive Visualisierung zeitabhängiger Volumendaten Diplomarbeit im Fach Informatik vorgelegt von Dario Kardas geb. am 4. Juni 1976 in Nürnberg angefertigt am Institut für Informatik 9 Lehrstuhl für Graphische Datenverarbeitung Friedrich-Alexander-Universität Erlangen-Nürnberg Betreuer: Peter Kipfer Verantwortlicher Hochschullehrer: Prof. Dr. G. Greiner Beginn der Arbeit: 24. März 2003 Abgabe der Arbeit: 23. September 2003

ii

Inhaltsverzeichnis 1 Grundlagen 3 1.1 Statische Daten.................................... 4 1.2 Zeitabhängige Daten................................. 4 1.2.1 Lattice-Boltzmann Verfahren........................ 5 1.2.2 Navier-Stokes Gleichungen......................... 6 1.3 Skalarfelder, Vektorfelder.............................. 7 1.4 Indirekte Verfahren.................................. 9 1.5 Direkte Verfahren................................... 11 1.5.1 Lichttransport................................. 11 1.5.2 Ray-Casting.................................. 12 1.5.3 Texturbasierte Verfahren........................... 14 2 Interaktion 19 2.1 Zielsetzung....................................... 20 2.2 Hochladen der Texturen............................... 20 3 Kompression 25 3.1 Graphikhardware................................... 26 3.1.1 Cg....................................... 26 3.1.2 GPU-Charakteristiken............................ 28 3.2 Herkömmliche Verfahren.............................. 28 3.2.1 Wavelets.................................... 28 3.2.2 Singulärwertzerlegung............................ 31 3.3 VQ-Verfahren..................................... 32 3.3.1 Das L3VQ-Format.............................. 32 3.3.2 Das BIP-Verfahren.............................. 40 3.3.3 Das Delta-Verfahren............................. 42 3.3.4 Das 4D-Verfahren............................... 53 3.3.5 Vergleich der Verfahren........................... 56 4 Zusammenfassung und Ausblick 59 iii

INHALTSVERZEICHNIS INHALTSVERZEICHNIS A Vektorquantisierung 61 A.1 PCA-Split....................................... 61 A.2 Verfeinerung...................................... 62 B VQPlayer-Applikation 64 Literaturverzeichnis 69 iv

Einleitung Ein wichtiger Bereich der wissenschaftlichen Visualisierung ist die Volumenvisualisierung. Dabei werden dreidimensionale Datensätze (meistens Schichtbildaufnahmen eines CT- oder MR-Scanners) durch ein Graphiksystem auf dem Bildschirm dargestellt. Die bisherige Geschichte der Volumenvisualisierung ist von einem anhaltenden Mangel an Hardwareresourcen gezeichnet; die Möglichkeiten, große Datensätze zu beschaffen, waren schon immer größer als die Möglichkeiten, sie zu verarbeiten. Immerhin hat in den letzten Jahren die rasante Entwicklung der Graphikhardware dafür gesorgt, dass statische Volumendatensätze durchschnittlicher Größe (z.b. 512 512 256 Voxel) schon auf Mainstream- PCs interaktiv dargestellt werden können. Mit den neuen Möglichkeiten moderner Mainstream-Graphikhardware kommen natürlich neue Ideen, wie man diese ausgiebig auszureizen könnte. Eine davon ist die Darstellung zeitabhängiger Volumendatensätze, d.h. es wird nicht nur ein statisches Volumen auf dem Bildschirm angezeigt sondern eine Folge von 3D-Datensätzen abgespielt. Natürlich besteht eine Realisierungsmöglichkeit darin, eine beliebige Anzahl von Volumendatensätzen einfach mit herkömmlichen Mitteln hintereinander auf dem Bildschirm darzustellen. Es liegt aber auf der Hand, dass damit keine großartigen Frameraten erzielt werden können, denn die durchschnittliche Größe eines Zeitschrittes liegt bei etwa 64 Megabytes; mit einer maximalen Busbandbreite von derzeit ca. einem Gigabyte pro Sekunde und dem üblichen Overhead für das Rendern liegt die zu erwartende Framerate bei höchstens 15 Bildern pro Sekunde, wenn man unterstellt, dass die Festplatte die Daten mit diesem Tempo liefern kann. Um die Interaktivität der Darstellung zu steigern ist es also unumgänglich, die Datenmenge mit Hilfe eines geeigneten Kompressionsverfahrens zu verringern. Meine Diplomarbeit besteht im Wesentlichen aus zwei Hauptaufgaben. Zum einen geht es darum, herauszufinden, welche Strategie für das Hochladen der Volumendatensätze in den Texturspeicher der Graphikkarte optimal für die Interaktivität der Darstellung ist. Zum anderen werde ich einige Kompressionsverfahren für zeitabhängige Volumendatensätze vorstellen, die in der Vorverarbeitung angewendet werden, um die Daten zu komprimieren, wobei die Dekompression auf der Graphikkarte während des Renderns stattfindet. Im ersten Kapitel meiner Diplomarbeit werde ich kurz einige Grundlagen der Volumenvisualisierung erläutern. Dazu gehören einige populäre Darstellungsverfahren für statische Volumendatensätze wie z.b. das Ray-Casting oder texturbasierte Verfahren wie Shear- Warp oder 3D-Texturen. Außerdem werde ich kurz zwei numerische Methoden zur Simulation von Strömungsfeldern behandeln ( Navier-Stokes und Lattice-Boltzmann ). 1

INHALTSVERZEICHNIS INHALTSVERZEICHNIS Das zweite Kapitel handelt von der Interaktivität der Visualisierung. Dort werden Möglichkeiten untersucht, wie man das Volume-Streaming derart optimieren kann, dass die Darstellung flüssig läuft und die Bandbreite der Systemkomponenten möglichst gut ausgenutzt wird. Die Kompressionsverfahren für Volumendatensätze sind Gegenstand des dritten Kapitels. Dort werde ich zunächst auf die Beschaffenheit der Graphikhardware eingehen, da sich daraus gewisse Einschränkungen für die Implementierung eines Dekompressionsverfahrens ergeben. Danach werde ich die Eignung zweier herkömmlicher Kompressionsverfahren zur Implementierung in GPU-Code diskutieren. Schließlich folgen die im Rahmen dieser Diplomarbeit entstandenen Ansätze: das Delta- und das 4D-Verfahren. Diese basieren auf dem Prinzip der Vektorquantisierung. 2

Kapitel 1 Grundlagen der Volumenvisualisierung 3

1.1. STATISCHE DATEN KAPITEL 1. GRUNDLAGEN 1.1 Statische Daten Statische Daten zeichnen sich dadurch aus, dass sie nicht zeitabhängig sind; es besteht lediglich eine Auflösung im Ortsraum. Meistens werden statische Daten im Rahmen einer MRT 1 oder CT 2 erhoben. Dabei wird ein Körper schichtweise eingescannt, die Schichtbilder enthalten an jedem Punkt die magnetische Dichte (MRT) oder die Massedichte (CT) des gescannten Volumens. Menschlicher Fuß Menschlicher Schädel Abbildung 1.1: Schichtbilder und deren Visualisierung Die Schichtbilder ergeben, wenn man sie in der richtigen Reihenfolge übereinander legt, ein Abbild des ursprünglich gescannten Körpers (s. Abb. 1.1). 1.2 Zeitabhängige Daten Scannt man mittels MRT oder CT einen beweglichen Körper, so erhält man mehrere Volumendatensätze, die zeitlich voneinander getrennt sind. Ein beliebtes Beispiel aus der Medizin ist der Herzschlag (Abb. 1.2). 1 Magnet-Resonanz-Tomographie 2 Computer-Tomographie 4

KAPITEL 1. GRUNDLAGEN 1.2. ZEITABHÄNGIGE DATEN Abbildung 1.2: Herzschlag Die meisten Volumendatensätze (mehr statische als zeitabhängige) wurden bis vor kurzem von der Medizin geliefert. Mit dem rapiden Anstieg der Rechenleistung moderner Computersysteme wurde dieses Prädikat auf den Bereich der Simulation übertragen. Hier werden mathematische Modelle für verschiedene dynamiche Prozesse aus der Natur formuliert und mit numerischen Methoden gelöst. Zwei beliebte Beispiele aus dem Bereich der CFD 3 sind die Boltzmann- [OSY95] und die Navier-Stokes-Gleichung [GR86]. 1.2.1 Lattice-Boltzmann Verfahren Die Boltzmann-Gleichung (1.1) basiert auf der Dichtefunktion n( r, v, t), die beschreibt, wie wahrscheinlich es ist, einen Flüssigkeitspartikel am Ort r mit Geschwindigkeit v zum Zeitpunkt t zu finden. n t + v n + F vn = n neq r Die linke Seite der Gleichung beinhaltet die zeitliche Veränderung der Partikelverteilung auf Grund ihrer Bewegung und einwirkender Kräfte F, während die rechte Seite die Interaktion der Teilchen untereinander berücksichtigt. n eq ist dabei die Verteilung im Gleichgewichtszustand und r ist ein Relaxationsparameter, der die Schrittweite beim Übergang ins Gleichgewicht steuert. 3 Computational Fluid Dynamics (Strömungsmechanik) (1.1) 5

1.2. ZEITABHÄNGIGE DATEN KAPITEL 1. GRUNDLAGEN c 14 c 6 c 5 c 1 c4 c 2 c 3 c 7 c 16 c 15 c 13 c 8 c 17 c 11 c 18 c 12 c 9 c 10 Abbildung 1.3: Lattice-Boltzmann Diskretisierung L3B19 Die numerische Lösung der Boltzmann-Gleichung erfolgt durch die Diskretisierung des Raumes in einem uniformen Gitter (engl. lattice). Die Geschwindigkeitskomponente der Verteilung wird ebenfalls diskretisiert, aber nicht in einem eigenen Gitter sondern als Zerlegung in einige plausible Komponenten, die eine sinnvolle Partikelbewegung im Raum ermöglichen. Demnach sind in jedem Gitterpunkt zum Zeitpunkt t i die entsprechenden Geschwindigkeitskomponenten n j, j = 1... b gegeben. Abbildung (1.3) zeigt eine mögliche Diskretisierung in 3D mit b = 19. Hier sind alle Permutationen c j von (±1, 0, 0) (1 j 6) und (±1, ±1, 0) (7 j 18) und (0, 0, 0) (j = 19) als mögliche Richtungen vorgesehen. Die Zeitschritte werden wie folgt entwickelt: { n j ( r, t) System ist im Gleichgewicht n j ( r + δt c j, t + δt) = n j ( r, t) n i n eq i r sonst Dies entspricht der Akkumulation der Partikeldichte aus den Dichten und Geschwindigkeiten der benachbarten Gitterelemente im vorherigen Zeitschritt. 1.2.2 Navier-Stokes Gleichungen Ein etwas allgemeinerer Ansatz zur Modellierung des dynamischen Verhaltens von Flüssigkeiten ist die Navier-Stokes Gleichung. Man setzt voraus, dass die Flüssigkeit aus derart vielen infinitesimal kleinen Teilchen besteht, dass die Geschwindigkeit v( r, t), der Druck P( r, t) und die Dichte ρ( r, t) kontinuierliche Größen sind. Basierend auf den Prinzipien von Massen-, Impuls- und Energieerhaltung lässt sich die Navier-Stokes Gleichung wie folgt formulieren: ρ v t + ρ v v = P ρ g + η 2 v + (η + λ) ( v) (1.2) Die linke Seite der Gleichung beschreibt die Bewegung des Teilchens durch das sich ändernde Geschwindigkeitsfeld. Auf der rechten Seite werden die verschiedenen Kräfte berücksichtigt, die auf die Partikel wirken. g steht dabei für das Gravitationsfeld, η und λ sind die dynamische Viskosität bzw. die Volumenviskosität der Flüssikgeit. Eine häufig angewandte Vereinfachung der Navier-Stokes Gleichung geht von einer inkompressiblen Flüssigkeit aus, d.h. die Dichte ρ ist konstant. Diese Annahme ist physikalisch 6

KAPITEL 1. GRUNDLAGEN 1.3. SKALARFELDER, VEKTORFELDER durchaus vertretbar, wenn die Geschwindigkeit der Teilchen wesentlich langsamer als die Ausbreitung von Schall in der Flüssigkeit ist. In diesem Fall vereinfacht sich die Navier- Stokes Gleichung wie folgt: v t + v v = P + 1 Re 2 v r r L, v v U, t tu L, P P ρu 2 Durch das Ersetzen von v, r, P und t durch die entsprechenden dimensionslosen Größen v, r, P und t ist die Gleichung ebenfalls dimensionsfrei. Dabei ist L eine typische Länge und U eine typische Geschwindigkeit im betrachteten Problembereich. Die Reynoldszahl beschreibt das Verhältnis zwischen der durch Druck (innere Reibung) und der durch Viskosität verursachten Kräfte in der Flüssigkeit. Für sehr kleine Werte von Re ( 1) ist die Strömung laminar, für sehr große Werte ( Re kritisch ) eher turbulent. Für die Lösung der Navier-Stokes Gleichungen gibt es verschiedene Ansätze (z.b. Finite- Elemente Methoden, s. [GR86]). Fast alle benutzen zur Diskretisierung für die numerische Lösung ein unstrukturiertes 4 Gitter. Um die Ergebnisse mit Mitteln der Volumenvisualisierung darzustellen, müssen diese entlang eines uniformen Gitters neu abgetastet werden (resampling). Die Ergebnisse von Simulationen sind fast ausnahmslos sehr große zeitabhängige Volumendatensätze, die man natürlich interaktiv visualisieren möchte. Die Herausforderung in diesem Zusammenhang ist die Bewältigung der immensen Datenmenge. Bevor ich jedoch mögliche Lösungen für dieses Problem präsentiere, möchte ich auf einige grundlegende Themen der Volumenvisualisierung etwas näher eingehen. Re LρU η 1.3 Skalarfelder, Vektorfelder Neben der Klassifikation der Volumendatensätze in statische und zeitabhängige gibt es eine Reihe weiterer Charakteristiken, anhand deren man eine Unterteilung vornehmen kann. Eine davon ist die Dimensionalität der Datenwerte. Die bisher gezeigten Beispiele (Abb. 1.1, 1.2) sind allesamt Skalarfelder, d.h. jedem Punkt im Volumen ist genau ein Wert zugeordnet. Gleichung (1.3) enthält eine formale Definition für skalare Volumendaten: f (i, j, k, t) = s l i, j, k {0... 2 N 1} l {0... 2 M 1} t {0... T} (1.3) Der Parameter t in (Gl. 1.3) steht für den Zeitschritt und kann bei statischen Datensätzen weggelassen werden. Nach dieser Definition ist das Skalarfeld nur an diskreten Gitterpunkten (Voxel 5 -Mittelpunkten) definiert. Das liegt daran, dass der Computer nur begrenzten Speicherplatz zur Verfügung hat (kontinuierliche Daten sind unendlich groß). Das ist aber 4 unstrukturiert ist das Gegenteil von uniform; die Gitterpunkte sind beliebig im Raum verteilt 5 Ein Voxel ist die dreidimensionale Entsprechung eines Pixels 7

1.3. SKALARFELDER, VEKTORFELDER KAPITEL 1. GRUNDLAGEN nicht sonderlich schlimm, da zum einen die Auflösung von CT- oder MRT-Scans beschränkt ist, sodass bei der Digitalisierung und der damit verbundenen Diskretisierung der kontinuierlichen Daten nicht viel Information verloren geht. Zum anderen sind die im Rahmen einer numerischen Simulation erzeugten Daten von Natur aus diskret. Um Werte zwischen den Gitterpunkten zu erhalten, muss man interpolieren. Einfache Methoden hierzu sind die Nearest-Neighbour- und die lineare Interpolation [FvDFH90], zu den anspruchsvolleren Techniken gehören beispielsweise die Spline- und die Newton-Interpolation [Sch97]. Eine weitere Gattung der Volumendaten sind Vektorfelder. Die Datenwerte an den Gitterpunkten sind hier keine Skalare sondern Vektoren (z.b. Geschwindigkeiten, Gradienten,...). Die im Rahmen meiner Diplomarbeit entstandenen Verfahren konzentrieren sich allerdings ausschließlich auf das Darstellen von Skalarfeldern, was nicht bedeutet, dass man mit ihnen keine Vektorfelder visualisieren kann. Die Idee besteht darin, einen Vorverarbeitungsschritt auf dem Vektorfeld durchzuführen, bei dem ein repräsentatives Skalarfeld erzeugt wird, das letztendlich dargestellt wird. Ein beliebtes Verfahren hierzu ist die Line Integral Convolution (LIC) [CL93]. Als Basis für das LIC-Verfahren dient ein mit weißem Rauschen gefülltes Volumen. Die Rauschinformation wird entlang der Vektoren des gegebenen Vektorfeldes mit einem geeigneten Filterkern K (z.b. Dreiecksfilter, Sinc-Filter) gefaltet (Abb. 1.4). Abbildung 1.4: 3D-LICs [RSHTE99] Gegeben sind der Input-Datensatz T : R 3 R mit zufällig generiertem Inhalt (weißes Rauschen) und das Vektorfeld V : R 3 R 3. Der Wert des Output-Datensatzes O : R 3 R an der Stelle x (i) wird wie folgt berechnet: O( x (i) ) = 1 si +L K(s s i )T(σ(s))ds = K (T σ) (1.4) 2L s i L Dabei ist σ : R R 3 eine parametrisierte Partikelbahn durch das Vektorfeld mit σ(s i ) = x (i), entlang der die Input-Daten I mit dem Filterkern K gefaltet werden. L ist die Länge der 8

KAPITEL 1. GRUNDLAGEN 1.4. INDIREKTE VERFAHREN Partikelbahn in beiden Richtungen um x (i). Anschaulich kann die Faltung als Verschmieren des Rauschens entlang der Partikelbahnen durch das Vektorfeld interpretiert werden. Dabei steuert der Paremeter L die Länge der Schmierer. Das auf diese Weise entstandene Output-Feld O kann nun mit Mitteln der 3D-Skalarfeld-Visualisierung dargestellt werden. Es gibt eine Reihe weiterer Verfahren, die die Visualisierung von Vektorfeldern auf die Darstellung von skalaren Volumendaten zurückführen (z.b. Level-Sets [WJE00]). Aus besagten Gründen seien ab hier immer Skalarfelder im Sinne von (Gl. 1.3) gemeint, wenn von Volumendaten gesprochen wird. In den nächsten Abschnitten werde ich einige grundlegende Techniken zur Visualisierung von Skalarfeldern vorstellen, wobei deren Reihenfolge so gewählt wurde, dass die Relevanz für meine Diplomarbeit ansteigt. 1.4 Indirekte Verfahren Indirekte Verfahren zur Darstellung von Volumendaten transformieren das Skalarfeld f in eine andere Struktur und stellen diese dar. So kann man beispielsweise mit dem Marching Cubes Algorithmus [LC87] eine Isofläche des Skalarfeldes triangulieren und das dabei entstandene Dreiecksnetz mit Standardverfahren und lokaler Beleuchtung rendern (s. Abb. 1.5). Abbildung 1.5: Marching-Cubes Triangulierung Im MC-Algorithmus werden die Datenwerte im Volumen als Eckpunkte von Würfeln betrachtet; der Datensatz besteht demnach aus einer dreidimensionalen Anordnung von Würfeln, die an den Kanten und Seitenflächen aneinander grenzen. Jeder Würfel wird zunächst entsprechend der Relation seiner acht Vertices zur Isofläche klassifiziert. Ist der Datenwert an einem Vertex größer als der Isowert, wird dieser als außerhalb, ansonsten als innerhalb angesehen (Abb. 1.6). 9

1.4. INDIREKTE VERFAHREN KAPITEL 1. GRUNDLAGEN 1 1 1 0 1 1 0 0 v 8 = 10 v 7 = 10 Iso = 9 v 5 = 5 v 6 = 5 v 4 = 10 v 3 = 8 v 1 = 8 v 2 = 8 Iso = 7 0 0 0 0 1 1 0 0 innerhalb (1) außerhalb (0) v 1 v 2 v 3 v 4 v 5 v 6 v 7 v 8 Abbildung 1.6: Klassifikation eines Würfels Aus der Belegung der acht Vertices ergeben sich insgesamt 256 Situationen für den Würfel. Durch Ausschluss von Isometrie werden diese auf lediglich 15 verschiedene Fälle reduziert (Abb. 1.7). Nachdem der Würfel klassifiziert worden ist, können dementsprechend Polygone durch das Innere gelegt werden. Die Positionen der Polygonvertices werden durch lineare Interpolation der Datenwerte entlang der Würfelkanten gewonnen. Abbildung 1.7: Verschiedene Fälle für den Verlauf der Isofläche durch den Würfel Auf diese Weise entsteht durch das Abarbeiten sämtlicher Würfel im Volumen das triangulierte Modell der gewünschten Isofläche. Dieses kann mit Standardverfahren der Computergraphik [FvDFH90] gerendert werden. 10

KAPITEL 1. GRUNDLAGEN 1.5. DIREKTE VERFAHREN 1.5 Direkte Verfahren Bei den direkten Verfahren wird das Volumen, wie der Name schon sagt, direkt aus den Daten f visualisiert, ohne dass diese vorher transformiert werden müssen. Zentral für diese Verfahren ist die Interaktion des Volumens mit dem Licht in der Szene. 1.5.1 Lichttransport n ds I( x + d x, n, f ) dω da I( x, n, f ) Abbildung 1.8: Modell für den Lichttransport Abbildung (1.8) zeigt das zugrundeliegende Modell für den Lichttransport. Dessen Bestandteile bedeuten folgendes: f : Frequenz des Lichts (Farbe) dω : Raumwinkel I( x, n, f ) : Strahlungsenergie im Punkt x in Richtung n mit Frequenz f χ( x, n, f ) : Absorption im Punkt x in Richtung n mit Frequenz f η( x, n, f ) : Emission im Punkt x in Richtung n mit Frequenz f da, ds : Grundfläche und Höhe eines infinitesimal kleinen zylindrischen Volumenelements Die durch das Volumen definierten Größen im Modell sind die Emission η und die Absorption χ, d.h. das Volumen kann sowohl aus eigener Kraft leuchten als auch Licht verbrauchen (z.b. durch Umwandlung in Wärmeenergie). Durch die Abhängigkeit dieser Größen von der Richtung n und der Frequenz f werden Effekte wie Streuung und Spektralzerlegung des Lichts ermöglicht. Die im Sinne dieses Modells korrekte Darstellung eines Volumendatensatzes ergibt sich aus der Lösung der sog. Lichttransportgleichung [Kaj86]: 11

1.5. DIREKTE VERFAHREN KAPITEL 1. GRUNDLAGEN {I( x, n, f ) I( x + d x, n, f )}da dω df dt = { χ( x, n, f )I( x, n, f ) + η( x, n, f )}ds da dω df dt (1.5) Die Lichttransportgleichung lässt sich wie folgt in Worte fassen: Die Differenz zwischen der Menge der ausgestrahlten Lichtenergie im Punkt x + d x und der Menge der einfallenden Lichtenergie im Punkt x entspricht der Differenz zwischen der durch Emission erzeugten Energie und der durch Absorption verbrauchten Energie. Wie man sich leicht vorstellen kann, ist das Lösen der Lichttransportgleichung sehr rechenintensiv und daher für die meisten Anwendungen inpraktikabel. Einige vereinfachende Annahmen reduzieren die Komplexität erheblich, ohne die Qualität der Ergebnisse zu sehr zu vermindern, und führen damit zum sog. Ray-Casting Verfahren. 1.5.2 Ray-Casting Beim Ray-Casting [Lev88] wird das Volumen an Sichtstrahlen 6 entlang äquidistant abgetastet (s. Abb. 1.9). Betrachter Bildschirm (r i, g i, b i, a i ) } {{ } c i Schnittbilder c i a i : Farbwert (r/g/b) des i-ten Samples auf dem Sichtstrahl : Opazität ( [0... 1]) des i-ten Samples auf dem Sichtstrahl Abbildung 1.9: Ray-Casting Jeder Abtastwert enthält einen Farb- und einen Opazitätswert. Der resultierende Farbwert des Fragments 7, durch das der Sichtstrahl verläuft, wird ermittelt, indem die Samples entweder von vorne nach hinten (front-to-back) oder von hinten nach vorne (back-to-front) miteinander kombiniert werden (Abb. 1.10). Eine naheliegende Optimierung im Fall des front-to-back Blending ist die sog. early ray termination. Wie man im Algorithmus (Abb. 1.10) sieht, enthält die Variable A die aktuelle Opazität des Fragments und steigt monoton, da der Term (1 A)a i stets positiv ist. Falls A 6 Sichtstrahlen (Rays) gehen vom Auge des Betrachters aus durch den Bildschirm in die Szene und traversieren das Volumen 7 Bereich des Bildschirms (meist ein Pixel), dessen Farbe aus den Abtastwerten entlang des entsprechenden Sichtstrahls ermittelt wird 12

KAPITEL 1. GRUNDLAGEN 1.5. DIREKTE VERFAHREN C := C background ; for i = I last to 0 ; { C := (1 a i )C + a i c i ; } return C ; (back-to-front) A := 0 ; C := 0 ; for i = 0 to I last { C := C + (1 A)c i ; A := A + (1 A)a i ; } C := C + (1 A)C background ; return C ; (front-to-back) c i a i : Farbwert (r/g/b) des i-ten Samples auf dem Sichtstrahl : Opazität ( [0... 1]) des i-ten Samples auf dem Sichtstrahl C : laufend aktualisierter Farbwert (r/g/b) des Fragments A : laufend aktualisierte Opazität des Fragments Abbildung 1.10: Blending der Abtastwerte entlang eines Sichtstrahls einen hinreichend hohen Wert erreicht hat, wird sich im nachfolgenden Verlauf der Rechnung kaum mehr etwas an der Farbe C ändern, sodass man hier die Schleife vorzeitig abbrechen kann. Abbildung (1.11) zeigt den optimierten Algorithmus. Eine erhebliche Zeitersparnis ist bei Volumina zu erwarten, die im vorderen Bereich opak sind. A := 0 ; C := 0 ; i := 0 ; while i < I last and A < A max { C := C + (1 A)c i ; A := A + (1 A)a i ; } C := C + (1 A)C background ; return C ; Abbildung 1.11: front-to-back Blending mit early ray termination Eine weitere Optimierung des Ray-Casting ist das space-leaping. Dabei wird das Volumen 13

1.5. DIREKTE VERFAHREN KAPITEL 1. GRUNDLAGEN in Teilvolumina partitioniert, wobei homogene Bereiche zusammengefasst werden (Abb. 1.12). Diese können dann als Ganzes in die Rechnung aufgenommen werden, womit die Anzahl der benötigten Rechenschritte reduziert wird. Abbildung 1.12: Space-leaping Das Ray-Casting ist ein reines Software-Verfahren. Mit der Verfügbarkeit leistungsstarker Graphikhardware entstanden texturbasierte Abwandlungen, die deren Vorzüge ausnutzen. 1.5.3 Texturbasierte Verfahren Die grundlegenden graphischen Primitive beim Rendern mit OpenGL 8 [ope] sind Polygone. Diese werden durch die Spezifikation ihrer Eckpunkte (Vertices) definiert. Einem Vertex können neben verschiedenen Materialeigenschaften (Farbe, Beleuchtungsparameter, usw.) und geometrischen Attributen (z.b. Oberflächennormale) insbesondere Texturkoordinaten zugewiesen werden. Eine Textur ist ein 2D- oder 3D-Bild im Texturspeicher der Graphikkarte, das den Texturkoordinaten entsprechend auf das Polygon abgebildet wird. Dies geschieht im Rasterisierungsschritt, in dem die Polygone der Szene Zeile für Zeile und Fragment für Fragment gefüllt werden. Für die aktuelle Position jedes Fragments werden baryzentrische Koordinaten [ukas96] bezüglich der Vertices des Dreiecks, in dem es sich befindet, berechnet. Diese werden auf die Texturkoordinaten derselben Vertices angewendet und liefern somit die Position des Fragments in der Textur. Insbesondere ist dieser Vorgang sowohl für 2D- als auch für 3D-Texturen anwendbar; in beiden Fällen entstehen drei baryzentrische Koordinaten und sind von der Dimensionalität der Texturkoordinaten unabhängig. Abbildung (1.13) illustriert den 2D-Fall. 8 API zum rasterisierten Rendern 14

KAPITEL 1. GRUNDLAGEN 1.5. DIREKTE VERFAHREN Polygon in der Szene t 0 Textur t 1 t 2 t 0, t 1, t 2 : Texturkoordinaten der Vertices Abbildung 1.13: 2D-Texture-Mapping Die Essenz der hardwarebasierten Volumenvisualisierung ist die Definition des Volumendatensatzes als Textur. Eine Schwierigkeit ergibt sich aus der Tatsache, dass die graphischen Primitive keine Volumina sondern planare Polygone sind. Wie man dennoch zur Darstellung eines Volumens kommt, werde ich im folgenden anhand zweier weit verbreiteter Verfahren erklären. Shear-Warp Die Projektion des Volumens auf die Bildschirmebene beim Ray-Casting lässt sich in eine Scherung der Slices des Volumendatensatzes (Shear) und eine anschließende 2D-Korrektur (Warp) zerlegen [LL] (Abb. 1.14). Die texturbasierte Entsprechung dieses Ansatzes definiert die Schichtbilder des Volumens als 2D-Texturen und rendert diese ihrer Ausrichtung entsprechend auf den achsenparallelen Schnitten (object-aligned slices) durch den Standardwürfel (Abb. 1.15). Ein Problem dieses Ansatzes ist der Blickwinkel auf das Volumen. Prinzipiell lässt es sich derart im Raum drehen, dass die Slices senkrecht zur Bildschirmebene stehen. Der Betrachter würde in diesem Fall zwischen den Schichtbildern hindurchsehen. Um dies zu vermeiden, wird der komplette Datensatz dreifach im Texturspeicher gehalten; einmal für jede mögliche Orientierung der Slices. Während des Renderings wird gemäß der Blickrichtung zwischen den Kopien umgeschaltet. Ein weiteres Problem dieses Verfahrens ist die Schrittweite bei der Abtastung. Während diese beim Ray-Casting konstant gewählt werden kann, da die Werte im Inneren der Voxel trilinear interpoliert werden, wird bei Shear-Warp immer nur innerhalb eines Schichtbildes abgetastet und bilinear interpoliert. Abbildung (1.16) zeigt die Auswirkung der fehlenden trilinearen Interpolation auf die visuelle Qualität der Bilder. 15

1.5. DIREKTE VERFAHREN KAPITEL 1. GRUNDLAGEN Ray-Casting Shear & Scale Project Warp (2D) Viewplane Viewplane Abbildung 1.14: Shear-Warp Faktorisierung der Viewing-Transformation Betrachter Bildschirm gerenderte Slices Modell Schnittbilder Schnittflächen Abbildung 1.15: Volume-Rendering mit 2D-Texturen 3D-Texturen Im Gegensatz zum eben beschriebenen Shear-Warp-Ansatz kann das Volumen, wenn es die Graphikkardware unterstützt, als 3D-Textur in den Speicher der Graphikkarte geladen werden. Die Darstellung des Volumens erfolgt nun, indem die zur Bildschirmebene parallelen Schnittflächen (view aligned slices) des Standardwürfels nacheinander gerendert und in geeigneter Weise übergeblendet werden [CCF94] (Abb. 1.17). Der Inhalt dieser Flächenstücke wird dabei aus der 3D-Textur der Volumendaten erzeugt. Die an der Bildschirmebene ausgerichteten Slices werden aus der Model-View Transformation T MV gewonnen. Diese transformiert Modellkoordinaten in das Koordinatensystem der Kamera, aus deren Perspektive die Szene dargestellt wird. Zunächst wird die gemeinsame Normale aller Slices berechnet. Dazu ist es nötig, die Model-View Transformation zu invertieren. Die Normale n ergibt sich dann aus folgender Gleichung ( ˆm i, j seien die Einträge 16

KAPITEL 1. GRUNDLAGEN 1.5. DIREKTE VERFAHREN Shear Warp Ray Casting Bilinear Trilinear Abbildung 1.16: Fehlende trilineare Interpolation bei Shear-Warp Betrachter Bildschirm gerenderte Slices Modell Schnittbilder Schnittflächen Abbildung 1.17: Volume-Rendering mit 3D-Texturen von M 1 MV ): n H = M 1 MV 0 0 1 1 M 1 MV 0 0 0 1 n temp = 1 n = 1 n temp n temp ˆm 4,3 ˆm 1,3 ˆm 2,3 ˆm 3,3 1 ˆm 4,4 ˆm 1,4 ˆm 2,4 ˆm 3,4 Die Normale n definiert eine zur Bildschirmfläche parallele Ebene durch den Ursprung in Modellkoordinaten. Diese wird mit sämtlichen Kanten des Standardwürfels geschnitten, womit der erste Slice entsteht. Die übrigen Slices lassen sich aus dem ersten berechnen, 17

1.5. DIREKTE VERFAHREN KAPITEL 1. GRUNDLAGEN indem die bereits vorhandenen Schnittpunkte dem Sliceabstand entsprechend entlang der Würfelkante verschoben werden (Abb. 1.18). d 1 d 3 d 2 d 1 d 2 d 3 d 1 Ursprungs-Slice Abbildung 1.18: Berechnung der view-aligned slices Die Inkremente d zur Verschiebung der bereits vorhandenen Schnittpunkte ergeben sich aus dem gewünschten Sliceabstand D: d = D n 2 /n 1 D n 2 /n 2 D n 2 /n 3 Es werden so lange Slices produziert, bis erstmals alle berechneten Koordinaten entlang der Würfelkanten im Betrag größer sind als 1, womit man die Kanten des Standardwürfels verlassen hat. Dieses Vorgehen muss man nur in einer Richtung vom zentralen Slice ausgehend durchmachen; die Schnittflächen in die andere Richtung ergeben sich aus der Punktsymmetrie zum Ursprung. Die Vorteile dieses auf 3D-Texturen basierenden Verfahrens gegenüber Shear-Warp sind zum einen die nicht vorhandene Notwendigkeit, den Datensatz dreifach im Texturspeicher zu halten. Zum anderen wird die trilineare Interpolation für 3D-Texturen hardwareseitig unterstützt, sodass hier keine Qualitätsverluste (vgl. Abb. 1.16) zu beobachten sind. Auf einigen Graphikkarten werden jedoch keine 3D-Texturen angeboten oder sind wesentlich langsamer als 2D-Texturen. In diesen Fällen bleibt nichts anderes übrig, als mit Shear-Warp zu arbeiten. 18

Kapitel 2 Interaktion 19

2.1. ZIELSETZUNG KAPITEL 2. INTERAKTION 2.1 Zielsetzung Ein Schwerpunkt meiner Diplomatbeit ist die Interaktivität der Darstellung zeitabhängiger Volumendaten. Ob ein Volume-Playback als interaktiv angesehen werden kann ist mehr eine subjektive Entscheidung als ein formal definierbares Kriterium. Deshalb will ich, meinen persönlichen Anforderungen entsprechend, eine Darstellung als interaktiv klassifizieren, wenn sie mindestens zehn Bilder pro Sekunde liefert; damit sollte sicher gestellt sein, dass das System auf Benutzereingaben verzögerungsfrei reagiert. Die zentralen Begebenheiten, die sich auf die Interaktivität auswirken, sind a priori die Datensatzgröße und die Leistungsfähigkeit der Hardware, auf der die Visualisierung durchgeführt wird. Aus Gründen, die im nächsten Kapitel ausführlich diskutiert werden, wurden handelsübliche Mainstream-PCs 1 mit Graphik-Hardware, die Fragment-Programme 2 ab Version 2.0 unterstützt, als Zielplattform für meine Diplomarbeit festgelegt (s. Abschnitt 3.1). Die Implementierung des Volume-Playbacks soll auf solchen Systemem interaktive Frameraten für Datensätze der momentan geläufigen Größe von 512 3 Voxeln realisieren. 2.2 Hochladen der Texturen Die Wahl des Renderingverfahrens zur Darstellung der Volumendatensätze fällt auf den in Abschnitt (1.5.3) vorgestellten auf 3D-Texturen basierten Ansatz. Dieser profitiert von der Graphikhardware, da diese insbesondere das Texture-Mapping unterstützt. Das interessante Problem im Bezug auf die Interaktivität ist das kontinuierliche Versorgen des Texturspeichers mit Volumendaten. Die optimale Strategie hierfür hängt von einigen Faktoren ab: Busbandbreite zwischen Hauptspeicher des PCs und Texturspeicher der Graphikkarte Asynchronität des Hochladens Interne Bandbreite der Graphikhardware Texturgröße Das Verhalten der Hardware bezüglich der oben genannten Punkte wird nicht offiziell von den Herstellern dokumentiert, sodass eine sinnvolle Strategie nur durch geeignete Experimente bestimmt werden kann. Abbildung (2.1) zeigt hierfür den grundlegenden Algorithmus. Die Strategien für das Hochladen ergeben sich aus den verschiedenen Belegungen der Variablen m und n: m : Anzahl der Volumina (Zeitschritte), die in einer Textur abgelegt sind n : Anzahl der Texturen 1 Intel Pentium IV oder Athlon Prozessor ab 2 Gigahertz, 1 GB Hauptspeicher 2 Derzeit unterstützt von der Geforce FX-Reihe von nvidia und ab Radeon 9700 von ATI 20

KAPITEL 2. INTERAKTION 2.2. HOCHLADEN DER TEXTUREN Erzeuge n Texturen der Größe m for (i := 0 ; i < n ; i++) initialisiere Textur T i mit Volumendaten i := 0 j := 0 while (Messung) rendere alle m Frames in Textur T imodn i++ bis (i mod n/2 == 0) lade m neue Datensätze in Textur T jmodn j++ bis (j == i) Abbildung 2.1: Algorithmus für das Experiment Es wird also zum einen das Verhältnis zwischen der Anzahl der Texturen und deren Größe untersucht (n = 2, m variabel). Zum anderen ist interessant zu erfahren, ob es günstiger ist, wenn mehrere Texturen direkt hintereinander hochgeladen werden oder wenn zwischendurch gerendert wird (m konstant, n > 2). Im ersten Experiment soll der Datendurchsatz zwischen dem Hauptspeicher des PCs und dem Texturspeicher der Graphikkarte untersucht werden. Tabelle (2.1) zeigt eine Messreihe, die auf einem Pentium IV-System mit 2.4 GHz, 1 GB Hauptspeicher und einer NVidia Quadro FX 1000-Graphikkarte durchgeführt wurde. Die Volumina hatten eine Auflösung von 64 3 und drei Farbkanäle (RGB). Die Größe der Datensätze (jeweils 768 Kilobyte) wurde deshalb so gering gewählt, damit genügend Freiraum für die Parameter m und n im Algorithmus bleibt (die Graphikkarte hatte 128 Megabyte RAM). Leider wird eine Textur nicht unbedingt in den Texturspeicher der Graphikhardware übertragen, wenn nicht daraus gerendert wird. Dieser Umstand ist ärgerlich, da das Rendering seinerseits Rechenzeit verbraucht und damit die Messung des Durchsatzes am AGP-Bus verfälscht. Aus diesem Grund wurde im Experiment immer nur ein Slice pro Zeitschritt gerendert und das Volumen selbst aus großer Distanz dargestellt, um eine unendlich große Füllrate zu simulieren. Außerdem wurden immer wieder dieselben Daten hochgeladen, da ansonsten die Ladezeit von der Festplatte bzw. die Generierung der Textur ebenfalls die Messergebnisse verfälscht hätte. Die gemessenen Werte (Tab. 2.1) zeigen, dass sich verschiedene Strategien durchaus auf den Datendurchsatz auswirken. Dem Experiment zufolge ist die einfache Strategie mit m = 1 und n = 2 die Vielversprechendste. Auch aus Speicherplatzgründen ist diese Strategie die günstigste, da sie am wenigsten verbraucht, was sehr großen Datensätzen zugute kommt. Trotz allem liegt die höchste in diesem Experiment gemessene Transferrate bei 163 Frames/s 768 Kilobytes 122 Megabytes pro Sekunde. Das ist nur ein kleiner Bruchteil von den 2 21

2.2. HOCHLADEN DER TEXTUREN KAPITEL 2. INTERAKTION n fps 2 163 4 162 8 160 16 156 32 155 64 153 164 162 160 158 156 154 152 150 10 20 30 40 50 60 n fps 2 160 4 157 8 155 16 154 32 153 m = 1 m = 2 164 162 160 158 156 154 152 150 5 10 15 20 25 30 n fps 2 159 4 156 8 155 16 153 164 162 160 158 156 154 152 n fps 2 156 4 155 8 154 164 162 160 158 156 154 152 150 150 2 4 6 8 10 12 14 16 2 3 4 5 6 7 8 m = 4 m = 8 n fps 2 154 4 152 164 162 160 158 n fps 2 154 164 162 160 158 156 156 154 154 152 152 150 2 2.5 3 3.5 4 150 m = 16 m = 32 2 Tabelle 2.1: Gemessene Bildraten für verschiedene n und m Gigabyte pro Sekunde am AGP 8x Bus, die von den Herstellern propagiert werden. Das zweite Experiment soll über die Asynchronität des Hochladens Aufschluss geben. Dazu wird der Algorithmus aus dem ersten Experiment herangezogen und mit dem Wert n = 2 fest belegt, m ist variabel. Die Strategie verfügt also über zwei Textur-Slots, aus denen gerendert wird. In der Initialisierung werden beide Slots hochgeladen, in der Hauptschleife werden die Slots abwechselnd gerendert und gleich wieder hochgeladen. Theoretisch sollte es also möglich sein, eine Textur zu übertragen, währenddessen aus der anderen gerendert wird. Abbildung (2.2) zeigt die gemessene Dauer, wie lange das System im Befehl für das Hochladen von Texturen 3 verschiedener Größen verweilt. Die Anzahl der Slices sowie die Größe der Darstellung wurden abermals klein gehalten, damit sich die interne Bandbreite der Graphikkarte nicht störend auf die Messung auswirkt. Die lineare Abhängigkeit gibt Anlass zur Annahme, dass der Upload synchron stattfindet. Diese Beobachtung allein reicht jedoch nicht aus, um Asynchronität auszuschließen, denn diese muss ja nicht unbedingt am Upload-Befehl festgemacht sein. 3 gltexsubimage3d() 22

KAPITEL 2. INTERAKTION 2.2. HOCHLADEN DER TEXTUREN 180 160 140 120 msec 100 80 60 40 20 0 5 10 15 20 25 30 m Abbildung 2.2: Verweilzeit des Hochladebefehls für verschiedene m Um die Asynchronität letztendlich nachzuweisen, wird in der nächsten Messung die Anzahl der gerenderten Slices variiert, die Datensatzgröße bleibt konstant. Die obere linke Kurve in Tabelle (2.2) zeigt die verstrichene Zeit zwischen Aufruf und Rückkehr des Ladebefehls an. Die verblüffende Tatsache, dass diese proportional zur Slice-Zahl ist, führt zu der Vermutung, dass das Rendering der Szene im Hintergrund stattfindet, während die andere Textur hochgeladen wird. Die obere rechte Kurve in Tabelle (2.2) unterstützt diese Schlussfolgerung, denn die Zeit für das Absetzten der Zeichenbefehle ist konstant gering; für 257 Slices wurden gerade mal 0.14 Millisekunden benötigt, was auf eine Framerate von 7142 bei synchronen Zeichenbefehlen schließen ließe. Tatsächlich waren es aber nur 8.5 Frames pro Sekunde (s. untere linke Kurve in Tabelle (2.2)). Der Nachweis der Asynchronität wird wie folgt erbracht. Die unteren beiden Kurven in Tabelle (2.2) zeigen, dass sich die Framerate bei geringer Slicezahl kaum ändert. In diesem Bereich ist der Durchsatz offenbar durch die Bandbreite am AGP-Bus beschränkt. Da wir wissen, dass der Ladebefehl gemäß Messung (tab. 2.2) synchron arbeitet, dauert das Hochladen eines Datensatzes mindestens 5.8 Millisekunden. Da die Ladeanweisung bei 257 Slices 116.3 Millisekunden bis zur Rückkehr braucht, ergibt das eine reine Renderingzeit von 116.3-5.8 = 110.5 Millisekunden für 257 Slices, wenn man voraussetzt, dass alle Vorgänge sequentiell ablaufen. Demnach ist eine Framerate von über 9 Bildern pro Sekunde bei 257 Slices zu erwarten, wenn das Hochladen abgeschaltet wird. Wie man in Abbildung (2.3) sieht, ist dies nicht der Fall. Die Framerate bei großer Slicezahl ist unabhängig vom Upload, was zwangsläufig bedeutet, dass Hochladen und Rendering simultan laufen. Die gefundene Strategie für das Hochladen der Texturen dient lediglich der Optimierung der Kontinuität des Volume-Playbacks. Eine weitere Steigerung der Interaktivität ist durch eine geeignete Texturkompression möglich, da dadurch weniger Daten durch den Flaschenhals am AGP-Bus übertragen werden müssen. 23

2.2. HOCHLADEN DER TEXTUREN KAPITEL 2. INTERAKTION 120 # msec 100 1 5.8 3 5.9 80 5 6.7 60 9 8.5 40 17 12.0 20 33 18.9 0 65 32.7 Slices 129 60.5 257 116.3 Verweildauer des Ladebefehls msec 50 100 150 200 250 0.2 # msec 1 0.08 0.15 3 0.08 5 0.08 0.1 9 0.08 17 0.08 0.05 33 0.08 0 65 0.1 Slices 129 0.11 257 0.14 Zeitaufwand für Zeichenbefehle msec 50 100 150 200 250 # msec 1 150 3 148 5 131 9 107 17 78 33 50.6 65 29.8 129 16.2 257 8.5 msec 160 140 120 100 80 60 40 20 0 50 100 150 200 250 Slices Framerate # MByte 1 112.5 3 108.8 5 98.3 9 80.3 17 58.5 33 38.0 65 22.3 129 12.2 257 6.4 KByte/s 120000 100000 80000 60000 40000 20000 0 1 2 4 8 16 32 64 128 256 Übertragungsrate Slices Tabelle 2.2: Timings mit variierender Anzahl gerenderter Slices # msec 1 440 3 399 5 354 9 210 17 125.5 33 64.4 65 32.4 129 16.3 257 8.5 msec 450 400 350 300 250 200 150 100 50 0 1 2 4 8 16 32 64 128 256 Slices Abbildung 2.3: Abhängigkeit zwischen Framerate und Anzahl Slices ohne Hochladen 24

Kapitel 3 Kompression 25

3.1. GRAPHIKHARDWARE KAPITEL 3. KOMPRESSION 3.1 Graphikhardware Zeitabhängige Volumendatensätze (s. Abschnitt 1.2) sind von Natur aus sehr groß. Um diese interaktiv mit einem Slice-basierten Ansatz (s. Abschnitt 1.5.3) zu visualisieren, muss der Zugriff auf die Texturen entsprechend effizient sein. Auf einigen Highend-Workstations teilen sich zu diesem Zweck CPU und GPU den gemeinsamen Hauptspeicher des Rechners. Im Bereich der Mainstream-PCs setzt sich diese Architektur nur schleppend durch 1, sodass sich standardmäßig die Graphikhardware samt Texturspeicher auf einer Erweiterungskarte befindet, die über den AGP-Bus mit dem Rest des Systems verbunden ist. Während die Graphikkarten in den letzten Jahren enorm an Leistung zugenommen haben, wurde im Vergleich dazu die Transferrate des AGP-Bus nur schwach verbessert (s. Messungen in Tab. 2.1). Dieser unglückliche Umstand scheint der Aussicht auf Interaktivität bei der Visualisierung zeitabhängiger Volumendaten erheblich im Wege zu stehen. Ein Grund, weshalb die Wahl der Hardware für die Belange meiner Diplomarbeit trotzdem auf Mainstream-PCs gefallen ist, liegt in dem Bestreben jedes vernünftigen Entwicklers, so wenig Hardwareresourcen zu fordern wie möglich. Immerhin kostet ein derzeit handelsüblicher Standard-PC mit 2-Gigahertz-CPU, 1 Gigabyte Arbeitsspeicher und Fragment- Shader 2.0 fähiger Graphikkarte ca. 1500 Euro, während Highend-Graphik-Workstations locker in den fünf- bis sechsstelligen Bereich kommen. Desweiteren gibt es vielversprechende Aspekte aktueller PC-Graphikkarten, die die Misere mit dem AGP-Bus kompensieren könnten. Diese sind eher historisch motiviert. In den Anfangsjahren der Graphikhardware für den breiten Markt wollte die Spieleindustrie immer komplexere Szenen in Echtzeit darstellen. Dafür war es nötig, die Polygon- und die Füllrate explosionsartig zu steigern. Nach einiger Zeit wurden diese Bedürfnisse gesättigt; aktuelle Spiele liefen mit über 300 Bildern pro Sekunde. Es gab also keinen Grund mehr, die interne Bandbreite der Graphikkarten derart massiv zu verbessern. Stattdessen setzten die Spielemacher verstärkt auf die Qualität der Darstellung und auf Spezialeffekte, sodass sich der Trend in die Weiterentwicklung der GPU-Programmierbarkeit gewandelt hat. Aus dieser Trendwende ergibt sich die Idee, anstelle von rohen Datensätzen komprimierte Volumina in den Texturspeicher zu laden, womit sich die benötigte Bandbreite am AGP-Bus verringert. Ein entsprechendes GPU-Programm dekomprimiert die Daten intern auf der Graphikkarte und stellt diese dar. Im Verlauf dieses Kapitels werden einige Verfahren hierzu vorgestellt. Im nächsten Abschnitt werde ich näher auf die Programmierung der Graphikhardware eingehen und erläutern, mit welchen Möglichkeiten und Einschränkungen diese verbunden ist. 3.1.1 Cg Abbildung 3.1 zeigt das Modell einer programmierbaren GPU. Die beiden programmierbaren Einheiten sind der Vertex Processor und der Fragment Processor. Die darin ausgeführten 1 Einziges Beispiel für eine PC-Architektur mit gemeinsamen Speicher für CPU und GPU ist derzeit der nforce2 Chipsatz von nvidia in der Variante, in der die GPU in der Northbridge integriert ist 26

KAPITEL 3. KOMPRESSION 3.1. GRAPHIKHARDWARE Abbildung 3.1: Modell einer programmierbaren GPU (aus [NVI03]) Programme werden dementsprechend Vertex-Shader und Fragment-Shader genannt. In der 3D-API (OpenGL oder Direct3D) werden Polygone durch ihre Eckpunkte (Vertices) spezifiziert. Dazu gehören neben der Position weitere Eigenschaften wie Oberflächennormalen, Texturkoordinaten und ähnliches. Der Vertex-Shader erzeugt daraus Outputs, die an den Rasterizer geschickt werden (z.b. transformierte Texturkoordinaten, Farben,...). Dieser generiert daraus Fragmente. Dabei werden die Outputs des Vertex-Shaders interpoliert und dem Fragment-Shader als Inputs zur Verfügung gestellt. Weitere, vom Vertex-Shader unabhängige Inputs für den Fragment-Shader sind beispielsweise Texturen oder frei wählbare uniforme Parameter 2. Eine typische Aufgabe für den Vertex-Shader ist die Model-View-Transformation [FvDFH90]. Dafür werden zwei Inputs benötigt: die Position in Modellkoordinaten (z.b. mittels glvertex3f() in OpenGL) und die momentane Model-View Matrix. Einziger Output ist die neue Position der Vertices in normalisierten View-Koordinaten. Ein weit verbreiteter Fragment-Shader ist die Implementierung des Phongschen Beleuchtungsmodells [FvDFH90]. Da die komprimierten Volumendaten als 3D-Texturen in den Texturspeicher der Graphikkarte geladen werden und da das Texture-Mapping durch den Fragment-Processor erfolgt, wird ein Fragment-Shader für die Dekompression der Volumendaten verantwortlich sein. Es gibt zwei Möglichkeiten, einen Vertex- oder Fragment-Shader zu programmieren: entweder direkt in GPU-Code oder in der Sprache Cg 3. Während der GPU-Code stark dem Assembler-Code für CPU-s ähnelt und dessen Programmierung sehr mühsam ist, bekommt man mit Cg eine an C angelehnte Sprache, die wesentlich einfacher zu beherrschen und dennoch sehr flexibel ist. Aus diesem Grund wurden die Verfahren, die in dieser Diplomarbeit entstanden sind, in Cg implementiert. 2 Uniforme Parameter sind Werte, die für alle Fragmente eines Polygons gleich sind (z.b. phongscher Beleuchtungskoeffizient) 3 C for Graphics, eine von NVidia entwickelte High-Level Sprache für das Programmieren von Vertex- und Fragment-Shadern. Cg-Programme werden vorab oder während der Laufzeit zu GPU-Code compilliert. 27

3.2. HERKÖMMLICHE VERFAHREN KAPITEL 3. KOMPRESSION Zu den Vorzügen der GPU-Programmierung zählen die zahlreichen Matrix- und Vektoroperationen. Skalare Operationen werden, wenn einer der Operanden ein Vektor ist, parallel auf jede einzelne Komponente des Vektors angewendet. Dazu kommen viele mathematische Operationen sowie Zugriffsfunktionen für Texturen usw. (eine komplette Übersicht über Cg findet man in [NVI03]). 3.1.2 GPU-Charakteristiken Trotz allem darf die Programmierbarkeit einer GPU nicht mit der Programmierbarkeit einer CPU verglichen werden, da es einige Einschränkungen gibt, die zu beachten sind. Ein Fragment-Shader wird für jedes Fragment des gezeichneten Polygons komplett ausgewertet. Deshalb verfügen moderne Graphikkarten gleich über mehrere Fragment-Shader- Units, die parallel arbeiten und damit den Fragmentdurchsatz erheblich erhöhen. Diese Art von Parallelität bringt aber auch einige Nachteile mit sich: Die Reihenfolge, in der die Fragmente ausgewertet werden, ist nicht bekannt Die Auswertung eines Fragments darf nicht von der Auswertung eines anderen abhängig sein Innerhalb eines Fragment-Shaders kann nur das eine Fragment verändert werden, für das der Shader gerade ausgeführt wird Bei den meisten momentan aktuellen Graphikchips kommen weitere Einschränkungen hinzu. Dort müssen alle aktiven Shader absolut synchron laufen. Das bedeutet, dass bei alternativen Sprüngen im Code in jedem Fall die übersprungenen Regionen ihrer Länge entsprechend Taktzyklen verbrauchen. Schleifen werden stets aufgerollt und können bei variabler Wiederholungszahl ebenfalls zu Einbußen in der Performance führen. Außerdem ist die Länge von GPU-Programmen sehr beschränkt (Programm- und Texturspeicher sind voneinander getrennt). All diese Eigenarten der GPU-Programmierung müssen bei der Entwicklung eines Verfahrens zur Dekompression von Volumendaten berücksichtigt werden. Eine Lauflängencodierung beispielsweise ist unter diesen Bedingungen nicht effizient implementierbar. 3.2 Herkömmliche Verfahren In diesem Abschnitt werde ich einige herkömmliche Verfahren zur Kompression von Volumendaten behandeln. Dabei werde ich besonders auf die Implementierbarkeit der Dekompression als Fragment-Shader eingehen. 3.2.1 Wavelets Die Wavelet-Transformation beruht auf der Darstellung eines Signals bezüglich einer bestimmten Menge von Basisfunktionen. In unserem Fall ist das Signal der diskrete Volumen- 28

KAPITEL 3. KOMPRESSION 3.2. HERKÖMMLICHE VERFAHREN datensatz. Ich werde das Prinzip zunächst in 1D erklären, als Basisfunktionen bieten sich die einfachen Haar-Wavelets an. Sei eine beliebige Zahlenfolge der Länge 2 n gegeben, z.b. (9, 7, 6, 2) für n=2. Das ursprüngliche Signal lässt sich trivial bzgl. der Level n Haar-Basis darstellen: 9 7 6 2 9 7 6 2 Level 2 Nun wird das Signal in Zweiergruppen aufgeteilt. Für jede Gruppe wird der Mittelwert und die Differenz zum Mittelwert berechnet: Gruppe 1 Gruppe 2 Ausgangssignal 9 7 6 2 Mittelwerte 8 4 Differenzen 1 2 Die Mittelwerte können als grobe Repräsentation der Originaldaten mit halber Auflösung aufgefasst werden, während die Differenzen die fehlende Detailinformation enthalten. Die zugehörige Basis (Level 1) zur Rekonstruktion des ursprünglichen Signals sieht wie folgt aus: 8 1 4 2 Level 1 Die entstandenen Mittelwerte werden als neues Signal aufgefasst und rekursiv durch Mittelwert- und Differenzbildung weiterentwickelt, bis nur noch ein Mittelwert übrig ist (Level 0). Im Beispiel: Mittelwert = 1 2 (8 + 4) = 6, Differenz = 8 6 = 6 4 = 2, Level 1 bleibt wie gehabt. 6 2 1 2 Level 0 Am Ende des Vorgangs bleiben ein Mittelwert und 2 n 1 Detailwerte übrig. In den homogenen Bereichen des Ausgangssignals sind die Differenzen entweder sehr klein oder sogar gleich Null, sodass sie nicht gespeichert werden müssen (darin besteht letztendlich die Kompression). Bei der Rekonstruktion werden an deren Stelle Nullen eingesetzt. 29

3.2. HERKÖMMLICHE VERFAHREN KAPITEL 3. KOMPRESSION Im Falle eines Volumendatensatzes müssen Differenz- und Mittelwertbildung in jedem Schritt entlang der drei Achsen separat durchgeführt werden (s. Abb. 3.2). Originaldaten Mittelwerte Differenzen Abbildung 3.2: Haar-Transformation in 3D Der Vorteil der Wavelet-Transformation liegt darin, dass sowohl im Orts- als auch im Frequenzraum eine Auflösung besteht, während bei anderen Transformationen (z.b. Fourier, DCT) nur der Frequenzraum aufgelöst ist. Das Verfahren kann durch das Heranziehen anderer Basen oder durch verschiedene Strategien für das Weglassen von Details variiert werden [PCW96]. In der Praxis wurden im Vergleich zu DCT-basierten Verfahren höhere Kompressionsraten bei besserer Bildqualität erzielt. Die Originaldaten lassen sich aus der transformierten Form effizient zurückgewinnen, wenn ein Level nach dem anderen komplett rekonstruiert wird. Auf der Graphikhardware besteht diese Möglichkeit nicht, da die Zwischenergebnisse bei der Auswertung eines Fragments nicht für die Auswertung eines anderen zur Verfügung stehen. Ein als Shader implementierter Wavelet-Decoder müsste also für jedes einzelne Fragment die komplette Level-Hierarchie immier wieder aufs Neue durchrechnen; das ist sicherlich inpraktikabel. Ein anderes Problem besteht in der adaptiven Datenreduktion. Es wird kaum ein ganzer Detail-Level aus dem Datensatz herausgenommen, denn das entspräche einem einfachen Downsampling. Vielmehr sind die homogenen Bereiche eher unregelmäßig geformt, sodass man reduzierte Regionen mit komplexen Datenstrukturen beschreiben muss. Diese müssen mit Schleifen oder gar Rekursion ausgewertet werden; leider sind beide Konzepte in Cg nicht effizient und einheitlich verfügbar. Schleifen werden noch von den meisten GPUs aufgerollt, Rekursion ist bislang in Cg verboten. 30