Diplomarbeit. Schnelle Volumenvisualisierung großer dreidimensionaler Bilddaten unter Verwendung von OpenGL

Transkript

1 Diplomarbeit Schnelle Volumenvisualisierung großer dreidimensionaler Bilddaten unter Verwendung von OpenGL Falco Hirschenberger Mat.Nr.: Neugasse Orbis 22. Dezember 2004

2 I E R K L Ä R U N G [ ] Die Diplomarbeit entstand in Zusammenarbeit mit einer Institution / Firma / Person außerhalb der Fachhochschule Oldenburg / Ostfriesland / Wilhelmshaven. [ ] Die Diplomarbeit enthält vertrauliche / kommerziell nutzbare Informationen, deren Rechte außerhalb der Fachhochschule Oldenburg / Ostfriesland / Wilhelmshaven liegen. Sie darf nur den am Prüfungsverfahren beteiligten Personen zugänglich gemacht werden, die hiermit auf ihre Pflicht zur Vertraulichkeit hingewiesen werden. [ ] Soweit meine Rechte berührt sind, erkläre ich mich einverstanden, dass die Diplomarbeit Angehörigen der Fachhochschule Oldenburg / Ostfriesland / Wilhelmshaven für Studium / Lehre / Forschung uneingeschränkt zugänglich gemacht werden kann. Zutreffendes ist in die Ausarbeitung aufzunehmen. Nichtzutreffendes kann entfallen. E I D E S S T A T T L I C H E E R K L Ä R U N G Hiermit erkläre ich an Eides statt, dass ich die vorliegende Diplomarbeit bis auf die offizielle Betreuung selbst und ohne fremde Hilfe angefertigt habe und die benutzten Quellen und Hilfsmittel vollständig angegeben sind. Datum, Unterschrift 25. Fachbereichsratsitzung vom Beschluss: 87/ XXV - 10 : 0 : 0 (Die Eidesstattliche Erklärung muss in die Diplomarbeit übernommen werden und von der Erklärung nur die Teile, die jeweils zutreffen.)

3 II Diplomarbeit im Studiengang Informatik der Fachhochschule Oldenburg Ostfriesland Wilhelmshaven von: erstellt am: Betreuung Fachhochschule: Betreuung Diplomarbeitsstelle: Falco Hirschenberger Neugasse Orbis Telefon: 0179/ Fraunhofer Institut Technound Wirtschaftsmathematik Gottlieb-Daimler-Straße, Geb Kaiserslautern Prof. Dr.-Ing. Dietrich Ertelt Dipl.-Inform. Markus Rauhut Dr. Katja Schladitz

4 Inhaltsverzeichnis Erklärung I 1 Einleitung Der visuell orientierte Mensch Dreidimensionale Darstellungen Grundlagen der Visualisierung Ziele der Visualisierung d-Bilddaten Volumendaten Vektordaten Verfahren Indirekte Visualisierung Direkte Visualisierung Lichtquellen Materialeigenschaften Beleuchtung und Schattierung Die Diffus-Komponente Die Glanzlicht-Komponente Die Umgebungs-Komponente Die Beleuchtungsgleichung Schattierung Filterung und Rekonstruktion Physikalischer Hintergrund Visualisierungstechniken OpenGL Die OpenGL Rendering-Pipeline Die Visualisierungs-Pipeline Volumenvisualisierung Klassifikation III

5 INHALTSVERZEICHNIS IV d-Texturen, bilinear interpoliert d-Texturen, trilinear interpoliert d-Texturen Weitere Verfahren Oberflächenvisualisierung Das Marching-Cubes-Verfahren Vergleich Implementierung Die Anwendung MAVI und das Voxel-Sculpture Modul Die Blend-Modi Die Klassenstruktur Die Renderklassen Die Texturklassen Ergebnisse Messungen d-Textur-Verfahren (bilinear interpoliert) d-Textur-Verfahren (trilinear interpoliert) d-Textur-Verfahren Bewertung Ausblick A Beispiele 73 A.1 Feuerbeton A.2 Faserfilz A.3 Offenporiger Nickelschaum A.4 Menschlicher Schädel B Beigefügte Programme 83 Abbildungsverzeichnis 84 Quelltextverzeichnis 86 Literaturverzeichnis 87

6 Kapitel 1 Einleitung 1.1 Der visuell orientierte Mensch What You See, Is What You Get. unbekannte Marketingabteilung Dieses Zitat, welches auf den ersten Blick wie ein vollmundiges Versprechen der Werbeindustrie wirkt, beinhaltet doch mehr Wahrheit als man am Anfang glauben möchte. Zuerst denkt man: So wie ich es sehe, so wird dann auch das Resultat sein. Das heißt auf Software bezogen, daß die Vorschau, zum Beispiel eines Textes in einer Textverarbeitung oder eines Bildes in einem Bildverarbeitungsprogramm, genau so ausgedruckt oder gespeichert, wie sie momentan dargestellt, wird. Wenn man aber das englische get nicht als bekommen, sondern als verstehen interpretiert, bekommt der Satz eine ganz andere Bedeutung: Was ich sehe, ist was ich verstehe. Tatsächlich fällt es den meisten Menschen leichter symbolische Informationen zu verarbeiten als quantitative oder textuelle. Texte und Zahlen benötigen eine Analyse, um verstanden zu werden, da sie nach festen Regeln codiert sind. Sie müssen zuerst decodiert und dann interpretiert werden. Symbolische Darstellungen dagegen, ermöglichen eine intuitive Art des Verstehens. 1 1 Wenn es sich um einfach interpretierbare Darstellungen handelt. Falls hinter dem Symbol ein tieferer Sinn steht, handelt es sich hingegen wieder um eine Art der codierten Information. 1

7 KAPITEL 1. EINLEITUNG 2 Dabei ist die symbolische Verarbeitung von Informationen oftmals weniger präzise als die quantitative, da dem Betrachter ein größerer Interpretationsspielraum bleibt. So werden gleiche Bilder von verschiedenen Personen häufig unterschiedlich bewertet. Außerdem lassen sich nicht von allen Dingen symbolische Darstellungen bilden. 1 Beispiel: quantitativ Das Objekt: 0b b0b a0a 090b a09 0a09 0c0a a0b 0c0c 090b 0b08 0b0b 0a0a 080c 0c08 0b0a 0f0b 080e 0a09 0b0c 0a0c 0a0c 0c0c 0c0a 090c 0c0c 0c0c 0a0b 0a0b 0c0e 0a0b 0b0a 100b 0b0a 0b0c... beschreibend Das Objekt ist ein regelmäßiger Oktaeder mit der Kantenlänge: 10cm, der Farbe: #3357C5, einem Volumen: 471.4cm 3 und einer Oberfläche von 282.8cm 2. Er hat eine filigrane Struktur aus Stegen und Öffnungen auf seiner Oberfläche, ansonsten ist er im Inneren hohl. Die Struktur lässt sich mit der mathematischen Funktion f(x, y) =... beschreiben. symbolisch Das Objekt: 1 Wie ist zum Beispiel die Darstellung von abstrakten Dingen wie: Zuversicht,Vertrauen, Möglichkeit...? So etwas lässt sich mit Worten wesentlich besser beschreiben.

8 KAPITEL 1. EINLEITUNG 3 Die erste Beschreibung ist wohl die detaillierteste, es werden die Pixelkoordinaten zusammen mit den Farbwerten codiert. Diese Art der Codierung ist aber für Menschen völlig unbrauchbar. Er kann die Informationen nicht in ein Abbild des Objektes decodieren. Auch die zweite Beschreibung kann ein Mensch nur sehr schwer decodieren. Er muss wissen wie ein Oktaeder im Allgemeinen aussieht, nach welchem Schema die Farbe #3357C5 codiert ist und wie sie aussieht. Außerdem muss er sich vorstellen können wie die Funktion aussieht, die die Struktur der Oberfläche beschreibt. Die meisten Menschen werden sich wohl kein exaktes Bild jenes Objektes erzeugen können. Einem Betrachter wird die Form, Struktur und Farbe sofort klar, wenn er das Bild sieht. Er kann sich den Oktaeder noch einmal vorstellen, wenn er auch das Bild nicht mehr vor Augen hat. Das spiegelt die Stärke und Wichtigkeit der visuellen Wahrnehmung wieder. Die Augen gelten als unser wichtigstes Sinnesorgan. Der Mensch ist visuell-anschaulich orientiert, was sich vor allem bemerkbar macht, wenn ein Mensch die Fähigkeit zu Sehen verliert. Wie hilflos ist doch ein Mensch im Dunkeln, der nur auf seine haptischen Sinne beschränkt ist. Die Art wie ein Mensch visuelle Informationen aufnimmt hat einen ganzheitlichen Aspekt, eine Gestalt ist für den Menschen mehr als die Summe der Pixel.[SP97] Informationen können viel leichter aufgenommen und verarbeitet werden, wenn sie visuell aufbereitet sind, so zum Beispiel: Balkendiagamme in Präsentationen anstatt Zahlenreihen, oder eine Software mit einem GUI 1 anstatt einer Textausgabe. Aus diesem Grund wird auch die grafische Darstellung von wissenschaftlichen Daten zunehmend wichtiger. Es wird nicht nur mit den Daten gerechnet, komplexe Sachverhalte sollen besser verständlich gemacht werden, indem sie grafisch aufbereitet werden. Dabei werden nicht nur naturgetreue Darstellungen verwendet, sondern auch Techniken wie Falschfarben-, Gradienten-, Vektorfeld- und Raum-Zeit-Darstellungen, um einen Aspekt wissenschaftlicher Ergebnisse zu verdeutlichen. Sie ersetzt aber nie die eigentliche Analyse der Daten, aus denen die Darstellung generiert ist, sie hilft nur, die Ergebnisse leichter zu verstehen. Die visuelle Wahrnehmung hat aber auch entscheidende Nachteile: Welche Dimensionen hat der Oktaeder? Beschreiben sie die Farbe. Welche Struktur 1 Graphical User Interface grafische Bedienoberfläche

9 KAPITEL 1. EINLEITUNG 4 hat die Oberfläche? Diese Fragen exakt zu beantworten ist nahezu unmöglich, da wir dadurch das Bild das wir im Kopf haben, wieder quantisieren müssen. Dies ist nahezu unmöglich. Durch unsere Interpretation kann vieles verfälscht sein, oder Informationen, die wir als unwichtig erachtet haben, können gar nicht erst aufgenommen worden sein. Es folgt der Schluss, daß nur die Kombination aus quantitativ-beschreibender und symbolischer Darstellung es dem Betrachter ermöglicht, sich exakte Vorstellungen von Objekten zu machen. 1.2 Dreidimensionale Darstellungen Die Darstellung von Tiefeninformationen in Bildern entwickelte sich erst im Laufe der Menschheitsgeschichte, so sind zum Beispiel in den Wandmalereien der alten Ägypter nur sehr eingeschränkte Tiefeninformation enthalten. Oft wurden Tiefeneffekte durch einfache Überdeckung, ohne Zuhilfenahme von perspektivischen Mitteln, angedeutet. Erst in der Frührenaissance (um 1425) wurde die geometrisch konstruierte Zentralperspektive, später auch die Luftperspektive 1, eingeführt [Kai80]. Erstaunlich präzise und sogar mit der Perspektive spielend sind die Zeichnungen und Stiche des Niederländers M.C. Escher 2, der mit seinen Darstellungen von unmöglichen Konstruktionen berühmt wurde (siehe Abbildung 1.1). In der Abbildung erkennt man, das sich die Szene in der Entfernung verjüngt. Wenn man von den Ecken des Raumes Hilfslinien zeichnet, schneiden sich diese im Zentrum des Bildes, dem so genannten Fluchtpunkt. Das Besondere an diesem Bild ist, dass der Fluchtpunkt gleichzeitig auch ein Zenit (Fluchtpunkt senkrecht über dem Betrachter) und ein Nadir (Fluchtpunkt senkrecht unter dem Betrachter) ist [Ern78]. Die exakte Darstellung von perspektivischen Eigenschaften und Effekten, wie zum Beispiel das Zusammenlaufen eigentlich paralleler Bahnschienen am Horizont, also die perspektivische Verkleinerung entfernter Objekte, benötigt fundierte Kenntnisse in linearer Algebra, da die dreidimensionale Darstellung durch eine perspektivische Projektion in eine zweidimensionale Darstellung überführt werden muss, die dann auf der Leinwand beziehungsweise dem Bildschirm, dargestellt werden kann. 1 Das atmosphärisch bedingte Verblassen der Farben in der Entfernung 2 Maurits Cornelis Escher, ( )

10 KAPITEL 1. EINLEITUNG 5 Abbildung 1.1: Holzstich Other World, M.C. Escher 1947 Gerade durch diese mathematische Abhängigkeit bietet sich der Rechner als unterstützendes Medium an. Zum Beispiel mit Hilfe der Grafikbibliothek OpenGL [GL] lassen sich Szenen 1 durch Angabe von Koordinaten in einem dreidimensionalen Raum beschreiben. Dann gibt man das Sichtfenster (viewport) an, durch das man die Szene beobachten will. OpenGL berechnet dann die korrekte Projektion der 3d-Szene in die 2d-Bildebene (rendern). Da solche 3d-Szenen aus vielen Millionen Koordinaten bestehen können, hat man diese Berechnungen in die Hardware der Grafikkarte integriert, um die CPU des Rechners zu entlasten, man spricht dann von hardwarebeschleunigtem 3d-Rendering. Diese, in die Grafikkarte integrierte, Recheneinheit (GPU), wurde in den letzten Jahren sehr leistungsfähig, wobei gerade die Computerspiele-Industrie die stetige Weiterentwicklung forcierte. Sie forder- 1 eine Sammlung von Objekten, Beleuchtung und Animation

11 KAPITEL 1. EINLEITUNG 6 te immer leistungsfähigere Grafikchips, und immer mehr Funktionalität wurde in die Hardware integriert. In Medizin und Forschung fallen große Datenmengen an, zum Beispiel von Kernspintomographen (MRI, Magnetic Resonance Imaging 1 ), Computertomographen (CT, Computed Tomography) oder aus Prozesssimulationen. Um diese dreidimensional zu visualisieren, benötigte man früher noch teure Spezialhardware und Großrechner oder man begnügte sich mit der scheibenweisen Darstellung von Schnitten durch die 3d-Daten. Da aber heute die Möglichkeit besteht, große 3d-Datenmengen in Echtzeit auch auf handelsüblichen PC-Grafikkarten darzustellen, geht die Visualisierung weg vom Großrechner und hin zur Workstation am Arbeitsplatz. Da die Datenmengen, die zum Beispiel bei CT-Aufnahmen anfallen, oft sehr groß 2 sind, muß eine effiziente und speichersparende Möglichkeit gefunden werden, um diese Daten darzustellen. Diese Arbeit behandelt die Visualisierung von Daten aus CT-Aufnahmen. Es werden verschiedene Methoden entwickelt, um diese unter OpenGL zu rendern, wobei die verschiedenen Verfahren Vor- und Nachteile im Bezug auf Speichernutzung, Leistung und Genauigkeit haben. Zunächst werden im nächsten Kapitel die Grundlagen von dreidimensionalen Bilddaten und die physikalischen Hintergründe von Beleuchtungsmodellen erläutert. 1 Früher Nuclear MRI, da das Wort nuclear aber zu negativen Assoziationen führte, wurde es später weggelassen 2 Die Größe von Bit = 1GB stellt bei handelüblichen Grafikkarten mit einem Speicher von 128MB ein großes Problem dar.

12 Kapitel 2 Grundlagen der Visualisierung 2.1 Ziele der Visualisierung Das Ziel der Visualisierung ist es, dem Betrachter einen Aspekt der zu visualisierenden Daten näher zu bringen. Das bedeutet, daß die Daten so aufbereitet werden, daß der Betrachter den Aspekt intuitiv erfassen kann. Aspekte können Teilbereiche der Daten, Zusammenhänge zwischen Teilbereichen, Oberflächen oder Maße innerhalb des Datensatzes sein. Dabei steht die Verdeutlichung des Aspektes im Vordergrund, nicht die möglichst realistische Darstellung der Daten. Man kann zum Beispiel einen Datensatz in Falschfarben darstellen, um Abweichungen von Normmaßen zu verdeutlichen. Dabei gibt es zwei Anforderungen, die eine Visualisierung erfüllen sollte: Interaktivität: Die Darstellung der Daten sollte interaktiv veränderbar sein. Sowohl die Geometrie (Rotation, Skalierung, Translation), als auch die Transformation (Einfärbung, Schnitte, Merkmalsextraktion) sollten wenn möglich in Echtzeit 1 erfolgen. Oft lässt sich dies aber nicht verwirklichen, da die Algorithmen zu aufwendig, die Hardware zu langsam oder die Daten zu groß sind. In diesem Fall sind auch noch Bildwiederholraten von 1Hz ausreichend. Bildqualität: Die Bildqualität steht immer im direkten Zusammenhang mit der Interaktivität. Erhöht man die Datenmenge, sinkt die Interaktivität, da die Algorithmen länger rechnen, allerdings steigt die Bildqualität. Es gibt Methoden die Interaktivität zu gewährleisten, indem man zunächst eine sehr grobe Darstellung wählt. Nach und nach wird dann das Bild verfeinert, wenn keine Interaktion mehr stattfindet (progressiver Bildaufbau). Damit ist die Interaktivität auf Kosten der Bildqua- 1 Man spricht von Echtzeit wenn die Bildwiederholrate >30Hz ist 7

13 KAPITEL 2. GRUNDLAGEN DER VISUALISIERUNG 8 lität gewährleistet. Weitere Einflüsse auf die Bildqualität hat die Wahl der verwendeten Algorithmen. Algorithmen, die eine bessere Bildqualität liefern, haben oftmals längere Rechenzeiten oder größere Speicheranforderungen, was wiederum auf Kosten der Interaktivität geht. Dem Anwender sollte es gestattet weden, den Kompromiss zwischen der Interaktivität der Darstellung und der Bildqualität selbst zu wählen, damit er eine für sich optimale Darstellung erhält d-Bilddaten Volumendaten Unter Volumendaten versteht man die dreidimensionalen diskreten Werte eines Volumendatensatzes V der Form: V = {v i (x, y, z) i = 1, 2,, n} wobei v(x, y, z) einen Bildpunkt im dreidimensionalen euklidischen Raum darstellt, also v R 3. Diese Elemente im R 3 nennt man auch Voxel (volume element) in Anlehnung an das Pixel (picture element) in 2-d Bildern. Volumendaten bestehen aus Zellen, welche in einem gleichmäßigen (regular grid) oder ungleichmäßigen (irregular grid) Raster angeordnet sein können. Gleichmäßig bedeutet in diesem Fall, daß jedes Element die gleiche Form und das gleiche Volumen hat (siehe Abbildung 2.1 a-c). Tomographen erzeugen gleichmäßige Raster, wobei jedes Volumenelement entweder ein perfekter Kubus oder zumindest ein Quader ist. Ungleichmäßige Raster erzeugen zum Beispiel Radargeräte oder Algorithmen wie finite- Elemente Simulationen, welche häufig auch Tetraeder- oder Prismenraster verwenden [Joo99]. Die einzelnen Voxel beschreiben also ein Volumenelement, dabei gibt es verschiedene Formen und Größen, in denen die Daten codiert sein können. Es folgen einige Beispiele gängiger Bildformate: Bezeichnung Beschreibung Wertebereich Mono Binärbild {0, 1} {0, 255} Luminanz8 8-bit Graustufen [0, 255] Luminanz16 16-bit Graustufen [0, 65535] Luminanz32 32-bit Graustufen [0, 2 32 ] LuminanzF 32-bit Floating-Point Graustufen [ 10 38, ] RGB 3-Kanal RGB-Farben 3 x [0, 255] Complex 2-Kanal Komplex 2 x [ , ]

14 KAPITEL 2. GRUNDLAGEN DER VISUALISIERUNG 9 a) b) c) Abbildung 2.1: Beispiele für gleichmäßige und ungleichmäßige Voxelgitter. In a) handelt es sich um ein Gitter mit kubusförmigen Elementen. In b) sind die Elemente quaderförmig und in c) sind es Pyramidenstümpfe unterschiedlicher Größe. Bilddaten, die aus mehreren Farbkanälen bestehen (RGB 1, Complex), können kanal- 2 oder pixelweise 3 (interleaved) gruppiert gespeichert sein. Bilddaten aus CT-Aufnahmen enthalten normalerweise keine Opazitätsinformationen der aufgenommenen Objekte, die verschiedenen Graustufen sind Dichteintensitäten bezüglich der verwendeten Strahlung. Um ein Volumenobjekt dreidimensional darzustellen, muß man aber Opazitätswerte bestimmen, um nur das Objekt und nicht den Hintergrund darzustellen. So kann die CT-Aufnahme einer Glasscheibe im mittleren Graustufenbereich liegen, obwohl Glas im optischen Wellenspektrum eine hohe Transparenz 4 aufweist. So würde eine Glasscheibe eine hohe Opazität (dank ihrer hohen Dichte) zugewiesen bekommen, was aber zu einer unerwarteten Visualisierung führen würde. Ein Ziel der CT-Volumenvisualisierung ist es, eine möglichst gute Zuordnung von Graustufen- zu Opazitätswerten zu finden. Dies geschieht über eine Pixeltransferfunktion, welche jedem Graustufenwert aller Kanäle, einen eindeutigen Farb- und Opazitätswert zuweist. Diese Transferfunktion wandelt die verschiedenen oben genannten Darstellungen in eine vierkanal Farb- Opazitätsdarstellung (RGBA) um, die sich dann mit Hilfe von OpenGL am Rechner visualisieren lässt. Das A steht hierbei für den Alphakanal, welcher die Transparenz des Voxels bestimmt. 1 Aus den drei Grundfarben (rot,grün,blau), zusammengesetzter Farbwert 2 Die Farbkanäle sind kanalweise gruppiert. (RRR...GGG...BBB...) 3 Die Farbkanäle sind pixelweise gruppiert. (RGB RGB RGB...) 4 Die Transparenz ist das Gegenteil der Opazität (Trübung)

15 KAPITEL 2. GRUNDLAGEN DER VISUALISIERUNG Vektordaten Vektordaten sind, in einem Vorverarbeitungsschritt auf die CT-Daten, generierte Vektoren, die zu OpenGL-Primitiven zusammengefasst und dann gerendert werden. OpenGL-Primitive sind die kleinsten geometrischen Formen, die OpenGL direkt darstellen kann. Üblicherweise handelt es sich dabei um Dreiecke oder aus Dreiecken zusammengesetzte Strukturen, da drei Punkte im Raum immer in einer Ebene liegen und es somit keine Probleme mit Sattelpunkten geben kann. Außerdem ist ein Dreieck immer eine konvexe Fläche, was die algorithmische Generierung einer geschlossenen Oberfläche erleichtert. 2.3 Verfahren Bei der 3d-Visualisierung unterscheidet man grundsätzlich zwischen zwei verschiedenen Verfahren, der direkten- und indirekten Visualisierung, welche sich grundlegend voneinander unterscheiden. In dieser Arbeit wird nur mit direkten Verfahren gearbeitet, trotzdem wird später der Unterschied zu indirekten Verfahren erläutert, um einen umfassenden Überblick über die gebräuchlichsten Methoden zu geben Indirekte Visualisierung Bei der indirekten Visualisierung werden nicht die Voxeldaten direkt dargestellt, sondern in einem Vorverarbeitungsschritt zu OpenGL-Primitiven umgewandelt (Triangulierung der Oberfläche). Dieser Vorverarbeitungsschritt extrahiert Oberflächen gleicher Graustufen, so genannte iso-surfaces, deshalb bezeichnet man diese Art der Visualisierung auch oft als Oberflächenvisualisierung. Die entstehenden Bilder haben oft ein etwas schwammiges Aussehen und wirken künstlich, da die Graustufeninformationen des ursprünglichen Bildes verloren gegangen sind und nur noch beleuchtete, zusammenhängende Dreiecke dargestellt werden, welche eine Approximation der eigentlichen Oberfläche sind. Zudem ist es nicht möglich in das Volumen hineinzusehen, ohne neue Oberflächen zu erstellen. Außerdem leidet diese Art der Visualisierung unter einem Leistungsverlust im Vergleich zu direkten Verfahren (bei gleicher Detailtreue). Am Beispiel des Marching-Cubes-Algorithmus wird in Kapitel ein indirektes Verfahren erläutert und auf die Vor- und Nachteile eingegangen.

16 KAPITEL 2. GRUNDLAGEN DER VISUALISIERUNG Direkte Visualisierung Bei direkten Visualisierungsverfahren werden die Voxeldaten nicht in OpenGL- Primitive umgewandelt. Statt dessen werden aus ihnen Texturen generiert, die dann von der Grafikkarte hardwarebeschleunigt dargestellt werden. Texturen sind Pixeldaten, die auf OpenGL-Primitive projiziert und dann beliebig im Raum bewegt werden können. Es gibt ein-, zwei- und dreidimensionale Texturen, die in verschiedenen Formaten vorliegen und zur Reduzierung des Speicherbedarfs auch komprimiert gespeichert werden können. Direkte Visualisierungen erzeugen durch die Verwendung der Voxeldaten bildartige Darstellungen, denen aber etwas an Plastizität fehlt, da die korrekte Beleuchtung von Texturen unter OpenGL nur eingeschränkt möglich ist oder nur mit hardwarespezifischen OpenGL-Erweiterungen ermöglicht werden kann (siehe Kapitel 3.1). Nachteile von direkten Verfahren sind der große Speicherbedarf für die Texturen und der langsame Transfer der Texturdaten vom Hauptspeicher über den AGP-Port 1 in die Grafikkarte, falls die Größe der Texturdaten die des Grafikkartenspeichers übersteigen. Ein Vergleich der beiden Varianten wird, nach näheren Erläuterungen zu speziellen Verfahren, im Kapitel 3.5 dargestellt. 2.4 Lichtquellen Um ein Objekt sehen zu können, müssen Photonen auf es treffen, wieder von ihm abgestrahlt 2 werden und dann das Auge des Betrachters erreichen. Diese Photonen können ebenfalls von anderen Objekten emittiert worden sein oder von Lichtquellen kommen. In diesem Zusammenhang unterscheiden wir zwischen drei verschiedenen Arten von Lichtquellen die in der Computergrafik üblich sind (siehe Abbildung 2.2): Gerichtete Lichtquellen sind unendlich weit von dem Objekt entfernt das sie beleuchten. Die Lichtstrahlen sind parallel zueinander. Ein Beispiel für gerichtetes Licht ist das der Sonne. Punktförmige Lichtquellen haben einen Ursprung im Raum und werden als positionsbehaftete Lichtquellen bezeichnet. Sie können als Punkt beschrieben werden, der Photonen emittiert. Im Gegensatz zu realen haben punktförmige Lichtquellen keine räumliche Ausdehnung und werfen 1 Acclerated Graphics Port - Schnittstelle zwischen Mainboard und Grafikkarte. 2 emittiert (siehe Kapitel 2.8)

17 KAPITEL 2. GRUNDLAGEN DER VISUALISIERUNG 12 deswegen harte Schatten. Es lassen sich aber weiche Schatten erzeugen, indem an der Schattengrenze eine Überblendung von dunkel nach hell erzeugt wird. Kegelförmige Lichtquellen sind auch positionsbehaftet, haben aber außerdem noch einen eingeschränkten Strahlungskegel, der das Licht bündelt. n s dir s dir s pos s cut a) φ b) c) s pos Abbildung 2.2: Gängige Lichtquellen in der Computergrafik. Bei a) handelt es sich um eine gerichtete, b) ist eine punktförmige und c) eine kegelförmige Lichtquelle. Lichtquellen werden mit unterschiedlichen Parametern beschrieben. Zwei Parameter haben alle gemeinsam: die Intensität und die Farbe. Die Farbe wird normalerweise über die drei Grundfarben rot, grün und blau (RGB) erzeugt. Dies ist nur eine approximative Farbdarstellung, die aber in der Computergrafik weit verbreitet ist. Außerdem kann man Lichtquellen noch nach ihrem Diffus-, Glanzlicht- und Ambientanteil (siehe Kapitel 2.6) beschreiben. Scheinwerfer haben zusätzlich noch einen Öffnungswinkel (cut-off angle), eine Leuchtrichtung (spot direction) und eine Abschwächung (spot exponent) zum Rand des Strahlungskegels hin. Weitere Parameter sind möglich, wie zum Beispiel ein Weichzeichnen des Randes des Strahlungskegels, um realistischere Lichtquellen zu simulieren. Lichtquellen werden üblicherweise folgendermaßen parametrisiert: Symbol s amb s diff s spec s pos s dir s cut Beschreibung Ambienter Farbanteil Diffuser Farbanteil Glanzlicht Farbanteil Position der Lichtquelle Richtung in die die Lichtquelle zeigt (nur bei kegelförmigen Lichtquellen) Öffnungswinkel des Strahlungskegels (nur bei kegelförmigen Lichtquellen)

18 KAPITEL 2. GRUNDLAGEN DER VISUALISIERUNG 13 In der Realität fällt die Intensität einer Lichtquelle mit dem Quadrat seiner Entfernung ab. Im Bereich der Echtzeit-Computergrafik bleibt die Intensität mit der Entfernung konstant. Diese Vereinfachung wird aus Effizienz- und Komplexitätsgründen angewandt. 2.5 Materialeigenschaften Materialeigenschaften werden in der Echtzeit-Computergrafik durch folgende Parameter beschreiben: Symbol m amb m diff m spec m shi m emi Beschreibung Ambiente Materialfarbe (ambient) Diffuse Materialfarbe (diffuse) Glanzlicht Materialfarbe (specular) Glanzfaktor (shininess) Materialeigenleuchtenfarbe (emissive) Die Farbe eines Materials wird durch diese Parameter, die der Beleuchtung 1 und des Beleuchtungsmodells berechnet. 2.6 Beleuchtung und Schattierung Die Variation von Beleuchtung, Materialeigenschaften und Positionierung der Objekte im Raum verändert ihr Aussehen im gerenderten Bild. Man spricht dann von Schattierung (shading) des Objekts. Die Schattierung verleiht dem Objekt eine realitätsnahe Plastizität Die Diffus-Komponente Die Diffus-Komponente des Beleuchtungsmodells ist die am nächsten an der physikalischen Realität befindliche. Sie modelliert die physikalische Eigenschaft, daß Lichtstrahlen, die von einer komplett matten Oberfläche reflektiert werden, mit der Intensität des Kosinus zwischen dem Normalenvektor n der Oberfläche und dem Lichtvektor 2 l reflektiert werden (siehe Abbildung 2.2a). 1 d.h. alle Lichtquellen deren Licht das Material erreicht 2 Der Vektor der vom Oberflächenpunkt p zur Lichtquelle zeigt

19 KAPITEL 2. GRUNDLAGEN DER VISUALISIERUNG 14 Der Diffus-Anteil des Lichts lässt sich dann folgendermaßen berechnen: i diff = n l = cos φ (2.1) Wobei n und l normierte Vektoren sind. Außerdem ist der diffuse Lichtanteil null, wenn der Winkel φ > π/2 ist. Das heißt, daß die Oberfläche vom Betrachter weggerichtet ist. Lichtquelle l n φ p Wenn nun ein Photon eine diffuse Oberfläche erreicht, wird es augenblicklich absorbiert und dann abhängig von der Farbe des Lichts und des Materials entweder total absorbiert oder im entsprechenden Winkel reflektiert. Die Wahrscheinlichkeit der Reflektion in eine bestimmte Richtung ist gleich für alle Richtungen φ > π/2. Das bedeutet die diffuse Komponente ist unabhängig von der Position der Kamera. Die Beleuchtung der Oberfläche sieht von allen Richtungen gleich aus. Wenn man den diffusen Farbanteil der Lichtquelle s diff und den des Materials m diff in die Betrachtung mit einschließt, ergibt sich aus Gleichung 2.1 der diffuse Farbvektor i diff : i diff = ( n l) m diff s diff (2.2) Der Operator ist hier eine komponentenweise Multiplikation. Um auszudrücken, daß der diffuse Anteil der Beleuchtung null ist, wenn der Winkel zwischen n und l größer als π/2 ist, ergibt sich aus Gleichung 2.2 folgendes: i diff = max(( n l), 0) m diff s diff (2.3) Die Glanzlicht-Komponente Die Glanzlicht-Komponente erzeugt Glanzlichter (highlights) auf Oberflächen, was dem Betrachter hilft, die Form der Oberfläche und die Position von Lichtquellen zu erfassen. Das Material wirkt glänzend und glatt.

20 KAPITEL 2. GRUNDLAGEN DER VISUALISIERUNG 15 Es gibt verschiedene Ansätze die Glanzlicht-Komponente zu errechnen. Die hier vorgestellten sind die Beleuchtungsgleichung von Phong 1 [Pho75]und die von Blinn [Bli77], welche beispielsweise in OpenGL Verwendung findet. Eine andere Methode ist die von Schlick [Sch94], die eine Approximation der Phonggleichung darstellt, dafür aber effizienter zu berechnen ist. Die Beleuchtungsgleichung von Phong Bei der Methode von Phong berechnet sich die Intensität i spec aus dem Vektor v, der vom Oberflächenpunkt p zur Kamera zeigt. Der Paramter m shi gibt den Glanz des Materials an. Der Vektor r ist der Reflektionsvektor vom Lichtvektor l um die Oberflächennormale n; ρ ist der Winkel zwischen r und v. Das bedeutet, die Glanzlicht-Komponente ist im Gegensatz zur Diffus- Komponente, blickwinkelabhängig. r n l Lichtquelle Kamera v ρ p i spec = ( r v) m shi = (cos ρ) m shi (2.4) Der Reflektionsvektor r errechnet sich aus dem Lichtvektor l und der Oberflächennormalen n wie folgt: r = 2( n l) n l (2.5) Wobei n und l normiert sind und deshalb r ebenso normiert ist. Falls n l < 0 dann ist die Oberfläche von der Lichtquelle weggerichtet und die Glanzlicht- Komponente wird nicht berechnet. Die Intensität der Glanzlicht- Komponente ist maximal, wenn r = v und fällt mit größerwerdendem ρ ab. Die Beleuchtungsgleichung von Blinn Blinn verwendet anstatt des Reflektionsvektors r einen normierten Halbvektor h der die Normale auf eine Ebene durch den Punkt p darstellt, die das Licht von l kommend, direkt in die Kamera reflektiert. 1 Nicht zu verwechseln mit dem Phong-Schattierungsmodell, siehe Kapitel 2.6.4

21 KAPITEL 2. GRUNDLAGEN DER VISUALISIERUNG 16 h n l Lichtquelle Kamera v θ p h = l + v l + v (2.6) Blinn verwendet einen Winkel θ zwischen h und n. Das ergibt folgende Gleichung: i spec = ( n h) m shi = (cos θ) m shi (2.7) Wenn man die Material- und Lichtkomponente mit einbezieht, ergibt sich nach Blinn der Term für die Glanzlicht-Komponente: i spec = ( n h) m shi m spec s spec (2.8) Zwischen Phong s und Blinn s Beleuchtungsgleichungen lässt sich näherungsweise folgende Beziehung herleiten: Die Umgebungs-Komponente ( r v) m shi ( n h) 4m shi (2.9) Die Umgebungs-Komponente i amb beschreibt die Eigenschaft, daß in der realen Welt Licht nicht nur direkt von Lichtquellen auf Oberflächen fällt, sondern auch von anderen Oberflächen reflektiertes Licht. Man spricht dann von indirekter Beleuchtung. Das hat den Effekt, daß Oberflächen, die von Lichtquellen abgewandt sind, nicht völlig dunkel erscheinen, sondern eine Grundhelligkeit haben. Sie ist die Kombination aus Material- und Lichtkomponente. i amb = m amb s amb (2.10) Die Beleuchtungsgleichung Nun werden die bereits bestimmten Parameter zu einer Beleuchtungsgleichung zusammengefügt, mit der sich dann die Interaktion der Lichtquellen

22 KAPITEL 2. GRUNDLAGEN DER VISUALISIERUNG 17 mit den Materialeigenschaften der Objekte berechnen lassen, was letzten Endes die Farbe der Bildpunkte auf dem Bildschirm ergibt. Das in der Echtzeit-Computergrafik verwendete Beleuchtungsmodell bezeichnet man als lokales Beleuchtungsmodell, da nur Licht, das von Lichtquellen emittiert wird, in die Berechnung einfließt. Licht, das von anderen Objekten reflektiert wird, wird außer Acht gelassen. Die totale Intensität i tot ergibt sich dann aus der Summe der Einzelintensitäten. i tot = i amb + i diff + i spec (2.11) Wie ein Pixel aber dann am Ende am Bildschirm dargestellt wird, hängt neben der Beleuchtungsgleichung auch noch vom Schattierungsmodell (shading) ab Schattierung Unter Schattierung versteht man die Art, wie die Beleuchtungsgleichung auf die einzelnen Polygone des Objekts angewandt wird und damit die Farbwerte der einzelnen Pixel des Polygons bestimmt werden. Es gibt drei Arten von Schattierungsmodellen, die in der Echtzeit-Computergrafik Verwendung finden: Flache Schattierung (flat-shading): Jedes Polygon wird einfarbig, abhängig vom Beleuchtungswinkel zum Normalenvektor n auf das Polygon, eingefärbt. n v 1 v 2 Gouraud-Schattierung (Gouraud-shading): Hier wird für jeden Eckpunkt v n des Polygons ein durchschnittlicher Normalenvektor n n aus dem Normalenvektoren der angrenzenden Polygone berechnet und dann die Farbwerte i über die Polygonfläche interpoliert. n 1 n 2 i v 1 v 2

23 KAPITEL 2. GRUNDLAGEN DER VISUALISIERUNG 18 Phong-Schattierung (Phong-shading): Bei der Phong-Schattierung werden die Normalenvektoren n über die Polygonfläche interpoliert und dann die Farbe pixelweise aus den interpolierten Normalenvektioren berechnet. n 1 n 2 n v 1 v 2 Flache Schattierung ist effizient zu berechnen und einfach zu implementieren, erzeugt aber kantige Oberflächen auf kurvigen Objekten. Gouraud- Schattierung ist auch schnell zu berechnen und erzeugt wesentlich bessere Oberflächen. OpenGL beherrscht flache und Gouraud-Schattierung. Phong- Schattierung wird in der Nicht-Echtzeit-Computergrafik 1 verwendet, weil es sehr rechenintensiv ist, da für jedes Pixel ein Normalenvektor berechnet werden muß, an dem dann die Intensität des Pixels bestimmt wird. Ein Problem bei der Gouraud-Schattierung ist, daß die Qualität der erzeugten Oberfläche stark vom Detaillierungsgrad des Modells abhängt. Das heißt, wenn ein Glanzlicht auf eine Oberfläche fällt, die sehr grob gerastert ist, kann es sein, daß mit Gouraud-Schattierung das Glanzlicht eckig, beziehungsweise gar nicht dargestellt wird, wenn es komplett innerhalb eines Polygons liegt und keine Polygonecke berührt. Mit detaillierten Modellen kann man mit Gouraud-Schattierung nahezu Phong-Qualität erreichen. 2.7 Filterung und Rekonstruktion Um aus der dreidimensionalen Szene ein zweidimensionales Bild zu erhalten, muß die Szene aus der Richtung der Kamera durch die Blende (viewport) aufgenommen werden. Diesen Vorgang nennt man auch Rasterisierung oder scan-conversion. Dabei handelt es sich um einen Abtastvorgang (sampling), der mit einer Abtastfrequenz (sample-rate) r dem Abtasttheorem von Nyquist genügen muß. Das Nyquist-Theorem kommt ursprünglich aus der Nachrichtentechnik und besagt, das die Abtastfrequenz eines Signals größer als die doppelte Bandbreite f g des Signals sein muß, um eine Abtastung ohne Informationsverlust zu gewährleisten. 1 Zum Beispiel beim Raytracing r > 2f g (2.12)

24 KAPITEL 2. GRUNDLAGEN DER VISUALISIERUNG 19 Eine Bedingung hierbei ist, daß das Signal bandbegrenzt ist, das heißt, daß kein Anteil oberhalb einer bestimmten Frequenz liegt. Eine durch Pixel abgetastete Szene ist normalerweise nicht bandbegrenzt. Kanten von Polygonen oder Schattengrenzen erzeugen sehr hohe Frequenzen, die auch bei Erhöhung der Abtastfrequenz nicht optimal abgetastet werden können. Diese Eigenschaft führt zu so genannten Aliasing-Effekten, die sichtbare Störungen im Bild erzeugen. Um das diskrete Ausgangssignal möglichst gut aus den abgetasteten Daten zu rekonstruieren, benutzt man einen Rekonstruktionsfilter. Theoretisch ist es möglich, ein bandbegrenztes Signal mit Hilfe des optimalen Sinc-Filters, vollständig zu rekonstruieren (siehe Abbildung 2.3). In der y 1 f(x) = sin(πx) πx x Abbildung 2.3: Der Sinc-Filter Praxis wird der Sinc-Filter aber nicht verwendet, da er eine unendliche Ausdehnung hat, und so jedes Pixel des abgetasteten Bildes für die Berechnung eines Pixels einbezogen werden müsste. Wesentlich effizienter zu berechnen ist die Rekonstruktion mittels Box-Filter, auch bekannt als nearest-neighbor (siehe Abbildung 2.4). Er zieht nur seine nächsten vier Nachbarpixel in die Berechnung mit ein und übernimmt den Wert des Pixels mit dem geringsten Abstand zu ihm. Die rekonstruierten Bilder wirken bei niedriger Abtastfrequenz pixelig. Bessere Ergebnisse erzielt man mit dem Tent-Filter, der auch als lineare Interpolation bekannt ist (siehe Abbildung 2.5). Er erzeugt weiche Bilder, da er zwischen den Abtastpunkten linear interpoliert. Der Unterschied zwischen Box- und Tent-Filter ist in Abbildung 2.6 dargestellt.

25 KAPITEL 2. GRUNDLAGEN DER VISUALISIERUNG 20 y 1 0 x 0.5 f(x) = 1 für 0.5 x x x Abbildung 2.4: Der Box-Filter y 1 0 x 1 x 1 x 0 f(x) = für x 0 x x x Abbildung 2.5: Der Tent-Filter Abbildung 2.6: Vergleich zwischen nearest-neighbor (li.) und linearer Interpolation (re.)

26 KAPITEL 2. GRUNDLAGEN DER VISUALISIERUNG 21 Man erkennt, daß auch beim Tent-Filter an den scharfen Kanten deutliche Aliasing-Effekte auftreten, denn an diesen Stellen hat man einen Frequenzsprung im Ausgangssignal, was einen unendlichen Wert im Frequenzspektrum bewirkt. Somit ist das Signal an diesen Stellen nicht mehr bandbegrenzt und die Rekonstruktion mit Filtern, die nur ihre Nachbarpixel beachten, führt zu Aliasing-Effekten an diesen Stellen. 2.8 Physikalischer Hintergrund In der folgenden Darstellung physikalischer Eigenschaften wird davon ausgegangen, daß die Szene mit einer Art Kamera aufgenommen wird. Alle psychologischen und physiologischen Effekte der menschlichen Wahrnehmung werden hier ignoriert, um eine wohldefinierte Beschreibung zu erreichen. Die Art, wie ein Bild in einer Fotokamera erzeugt wird, lässt sich mit bekannten optischen Gesetzen beschreiben. Um die dabei stattfindenden Prozesse zu simulieren, müsste man das gesamte Strahlungsfeld einer Lichtquelle und wie es sich in der Szene ausbreitet, in Betracht ziehen. Dies würde komplizierte Rechnungen nach sich ziehen und kann vereinfacht werden, indem man den Wellencharakter und die Polarisierung des Lichts außer acht lässt. Dafür vernachlässigt man Effekte wie Interferenz und Beugung. Wir behandeln also nur die geometrische Optik, nicht die physikalische. Mit dieser Annäherung können wir die Reaktion von Licht mit Oberflächen verschiedener Materialien mit Hilfe der Ausbreitungstheorie des Lichts beschreiben, welche auf der Strahlentheorie basiert. Sie beinhaltet die Komponenten emission (Abstrahlung), absorption (Aufnahme) und scattering (Streuung) des Lichts [HHS93]. Die zentrale Komponente in der Strahlentheorie ist die spezifische Intensität I( x, n, ν). Sie beschreibt das Strahlungsfeld im Punkt x komplett über den Abstrahlwinkel und die Frequenz. Die Menge an Strahlungsenergie δe in der Zeit dt mit einem Frequenzintervall [ dν, +dν] um ν durch ein Oberflächenelement da in einen Raumwinkel dω in Richtung n ist gegeben durch: δe = I( x, n, ν) cos ϑ da dω dν dt (2.13) Hierbei ist ϑ der Raumwinkel zwischen n und der Normalen der Ebene da. Dabei kann man bei der spezifischen Intensität I auch von der Leuchtstärke sprechen.

27 KAPITEL 2. GRUNDLAGEN DER VISUALISIERUNG 22 n dω ϑ dt x da Um nun ein Bild einer Szene zu erzeugen, müssen wir I( x, n, ν) für jeden Punkt im Raum berechnen, der vom Bildausschnitt fokussiert wird und dessen n in Richtung Kamera zeigt. Die spezifische Intensität steht im direkten Zusammenhang mit der Helligkeit eines Bildpunktes in der Bildebene der Kamera. Wenn Strahlung Material durchquert, verliert sie Energie. Wir quantisieren diesen Verlust mit dem totalen Absorptionskoeffizienten χ( x, n, ν). Der Anteil der absorbierten Energie einer spezifischen Intensität I( x, n, ν) beim durchqueren eines zylindrischen Volumenelements der Länge ds und Oberfläche da ist gegeben durch: δe (ab) = χ( x, n, ν) I( x, n, ν) ds da dω dν dt (2.14) Die Abstrahlung an diesem Punkt quantisieren wir mit dem Emissionskoeffizienten η( x, n, ν). δe (em) = η( x, n, ν) ds da dω dν dt (2.15) Hierbei ist es wichtig zwischen tatsächlicher- und Wärmeabsorption bzw. Emission zu unterscheiden und auch die Eigenschaft der Streuung (scattering) zu beachten. Im vorherigen Fall führte die absorbierte Energie zur Erwärmung des Materials und die Emission von Energie führte zur Abkühlung. Im Gegensatz dazu müssen wir noch den Anteil der gestreuten Strahlung beachten, die in verschiedene Richtungen ( n) mit unterschiedlicher Frequenz (ν) sofort reflektiert wird. Wir definieren einen wahren Absorptionskoeffizienten κ( x, n, ν) und einen Streuungskoeffizienten σ( x, n, ν). Der totale Absorptionskoeffizient ergibt sich dann aus: χ = κ + σ (2.16)

28 KAPITEL 2. GRUNDLAGEN DER VISUALISIERUNG 23 Ebenso teilen wir den Emissionskoeffizienten in einen Quell- q( x, n, ν) und einen Streuungsteil j( x, n, ν) auf. η = q + j (2.17) Um nun den Energieerhaltungssatz einzuhalten, muss die Energiedifferenz an zwei Punkten entlang eines Strahls durch ein Volumenelement gleich der Differenz der absorbierten zur emittierten Energie an dem Volumen sein. Diese Gesetzmäßigkeit wird durch die Strahlentransfergleichung beschrieben: I( x, n, ν) = χ( x, n, ν) I( x, n, ν) + η( x, n, ν) (2.18) s Da es sich bei der Streuung des Lichts um einen sehr komplexen Vorgang handelt, der die Frequenz (ν) und die Richtung ( n) der abgestrahlten Energie ändert, ist die Integration der Strahlungsmenge nur möglich, wenn die Eigenschaft der Streuung außer acht gelassen wird. Dadurch kann die frequenzabhängige Variable ν in Formel (2.18) wegfallen. Deshalb wird in der Volumenvisualisierung im Allgemeinen ein Emissions- Absorptions-Modell 1 (emission-absorption model) verwendet, in dem der Effekt der Streuung vernachlässigt wird. Auch aus Leistungsaspekten ist die Vernachlässigung der Streuung sinnvoll, um die Berechung zu beschleunigen und damit die Interaktivität zu gewährleisten. Die Reduktion auf das Emissions-Absorptions-Modell bildet dann zwar nicht mehr die realen physikalischen Vorgänge ab, liefert aber immer noch eine sehr gute Annäherung. Die analytische Form von (2.18) sieht dann wie folgt aus: I(s) = I(s 0 ) e τ(s 0,s) + s s 0 q( s) e τ( s,s) d s (2.19) Wobei von einem Lichtstrahl ausgegangen wird, der in Richung n durch eine Variable s parametrisiert wird. Der Strahl tritt am Punkt s 0 in ein Volumen ein. Die Richtung n wird hier außer Acht gelassen und n durch die Integrationsgrenzen s 0 s ersetzt. Der Term τ(s 1, s 2 ) ist die optische Tiefe, sie ist definiert als: τ(s 1, s 2 ) = s2 s 1 κ(s) ds (2.20) Um diese Gleichung numerisch lösen zu können, müssen wir entlang des Strahls diskretisieren, indem wir den Strahl in n Teilinveralle zerlegen (siehe 1 oft auch: Dichte- Emissionsmodell (density-emitter model) genannt

29 KAPITEL 2. GRUNDLAGEN DER VISUALISIERUNG 24 Kamera I(s) s n-1 n s 0 s 0 s 1 s 2 s 3 s 4 s n 2 s n 1 s n s Abbildung 2.7: Veranschaulichung der Integration entlang des Lichtstrahls durch ein Volumenelement. Abbildung 2.7). Dann ist die spezifische Intensität an der Position s k definiert durch die Intensität an der diskreten Position s k 1 durch: Wir definieren den Term: I(s k ) = I(s k 1 ) e τ(s k 1,s k ) + als Transparenz des Mediums und b k = sk θ k = e τ(s k 1,s k ) sk s k 1 q(s) e τ(s,s k) ds (2.21) (2.22) s k 1 q(s) e τ(s,s k) ds (2.23) als Emissionsterm, der den Anstieg der abgestrahlten Energie im Intervall [s k 1, s k ] entlang des Strahls beschreibt. Wir nehmen nun an, das ein Medium ein Volumen mit Licht emittierenden Partikeln ist, das durch die Dichtefunktion ρ(s) beschrieben ist. Der Quellanteil q und die wahre Absorption κ sind dann proportional zur Partikeldichte: κ(s) = κ 0 ρ(s) und q(s) = q 0 ρ(s) Wenn man nun annimmt, daß κ 0 und q 0 konstant sind, ergibt sich aus Term (2.23): b k = = q 0 (1 e τ(s k 1,s k ) ) = q 0 (1 θ k ) (2.24) κ 0 κ 0 Die Terme (2.22) (2.24) werden nun in die Transferfunktion (2.21) eingesetzt und man erhält eine iterative Lösung des Emissions-Absorptions- Modells:

30 KAPITEL 2. GRUNDLAGEN DER VISUALISIERUNG 25 I(s k ) = I(s k 1 ) θ k + b k = I(s k 1 ) θ k + q 0 κ 0 (1 θ k ) (2.25) Dies ist eine fundamentale Gleichung, auf der alle Visualisierungsverfahren beruhen, die im folgenden Kapitel erläutert werden.

31 Kapitel 3 Visualisierungstechniken In diesem Kapitel werden verschiedene Techniken erläutert, mit denen Volumendaten dreidimensional dargestellt werden können. Die einzelnen Verfahren bieten Vor- und Nachteile, die am Ende des Kapitels diskutiert werden. Als Basis benutzen die Verfahren die 3d-Grafikbibliothek OpenGL [GL], sie sind aber nicht zwangsläufig an sie gebunden. Auch eine Implementierung mit anderen Bibliotheken wie zum Beispiel Direct3D [MDX] ist möglich, bleibt dann aber auf die Microsoft Windows Plattform beschränkt. 3.1 OpenGL OpenGL wurde ursprünglich von Silicon Graphics [SGI] entwickelt, um eine Programmierschnittstelle (API 1 ) für interaktive 2d/3d-Computergrafik zu erstellen. OpenGL ist eine Spezifikation, die eine Schnittstelle beschreibt, welche durch die Implementierungen der verschiedenen Hersteller eingehalten werden muß. Seit 1992 wird sie durch ein Konsortium 2, bestehend aus Hard- und Softwareherstellern, definiert und zertifiziert. Jede OpenGL-Implementierung muß einen festgelegten Teil an Grundfunktionalität bieten, kann aber noch eigene und fremde Erweiterungen unterstützen. Die OpenGL-Grafikoperationen müssen nicht durch die Hardware der Grafikkarte beschleunigt sein, die meisten Implementierungen sind es aber. Das heißt, sie arbeiten direkt mit dem Grafikkartentreiber des Betriebssystems zusammen. Die Schichtstruktur, die OpenGL im Gesamtsystem bildet, ist in Abbildung 3.1 dargestellt. OpenGL-Implementierungen sind für die meisten Hardware- und Betriebssystemplattformen erhältlich und fast alle modernen Grafikkarten bieten beschleunigte OpenGL-Operationen. 1 Application Programming Interface 2 Das OpenGL Architecture Review Board (ARB) 26

32 KAPITEL 3. VISUALISIERUNGSTECHNIKEN 27 Abbildung 3.1: Die OpenGL Schichtstruktur Obwohl die Programmiersprachen C und C ++ im OpenGL-Bereich dominant sind, gibt es für fast jede andere Sprache eigene Bindungen, die die Spezifikation erfüllen. Das macht OpenGL zu einer portablen und flexiblen Grafikumgebung und ist auch ein Grund für ihre weite Verbreitung. Intern agiert OpenGL als Zustandsmaschine (state-machine). Das heißt, daß sich der interne Zustand von OpenGL nicht ändert, solange man ihn nicht durch einen expliziten Befehl ändert. Das kann die Programmierung erschweren, da eine Anwendung zu jedem Zeitpunkt des Programmablaufs für das Setzen der entsprechenden OpenGL-Zustände verantwortlich ist und nach Ausführen einer Operation die Maschine wieder in einen Zustand bringen muß, der nicht mit der folgenden Operation kollidiert. Auch die Fehlerfindung ist mühsam, da OpenGL keine Fehlermeldungen ausgibt, wenn eine Anweisung fehlschlägt. Es ist möglich abzufragen, ob ein Fehler aufgetreten ist; dieser bezieht sich aber immer nur auf die zuerst fehlgeschlagene OpenGL-Anweisung. Weitere Fehler werden nicht registriert, bevor der Fehler nicht abgefragt und der Fehlerstatus zurückgesetzt wurde Die OpenGL Rendering-Pipeline Die meisten OpenGL-Implementierungen führen ihre Verarbeitungsoperationen in mehreren Stufen aus. Man spricht von der Rendering-Pipeline, da die Daten von Stufe zu Stufe weitergeleitet und verarbeitet werden. Die Struktur der OpenGL Rendering-Pipeline ist in Abbildung 3.2 dargestellt. Die zu verarbeitenden Daten sind Pixeldaten (Texturen 1, Bitmaps,... ) und Vektordaten (Punkte, Linien, Polygone,... ). Diese Daten können in Displaylisten vorverarbeitet werden. Sie werden in ein Zwischenformat überführt, 1 Bilddaten, die an Polygone gebunden sind und beliebig im Raum bewegt werden können

33 KAPITEL 3. VISUALISIERUNGSTECHNIKEN 28 Abbildung 3.2: Die OpenGL Rendering-Pipeline

34 KAPITEL 3. VISUALISIERUNGSTECHNIKEN 29 das OpenGL effizient verarbeiten kann. Die Vektordaten werden dann durch die Vektor-Operationen (Translation, Rotation, Skalierung,... ) von der 3d- Szene in die 2d-Bildebene transformiert. Diese Operationen sind meistens einfache Matrixmultiplikationen, die schnell in der Grafikkarte berechnet werden können. Die Pixeldaten werden durch die Pixel-Operationen zunächst in ein einheitliches, internes Format gebracht. Danach können sie noch skaliert (scaled), verschoben (biased) und indiziert 1 (indexed/mapped) werden. Am Ende werden die Pixelwerte auf den Wertebereich [0.0, 1.0] transformiert. Falls es sich bei den Pixeldaten um Texturen handelt, können diese in Texturobjekten gebunden werden, um sie wiederzuverwenden und nicht bei jeder Bildaktualisierung neu generieren zu müssen. Dies geschieht in der Textur-Generierung. Da die OpenGL-Pixeloperationen nur eingeschränkte Möglichkeiten bieten Pixeldaten gezielt zu verändern, wurden die Pixelshader eingeführt, die kleine assemblerartige Programme in die Grafikkarte laden, die dann die volle Kontrolle über die Pixelpipeline haben. Als erstes entwickelte die Firma NVidia [NV] eine eigene Shadersprache Cg (C for graphics). In der kommenden Version 2.0 von OpenGL wird aber eine offizielle Shadersprache glslang (OpenGL Shading Language) zur OpenGL-Grundfunktionalität hinzugefügt, die Cg dann ersetzt und von allen neueren Grafikkarten unterstützt wird. Die vorverarbeiteten Pixel und Vektordaten werden an die Rasterisierungseinheit gegeben, die aus den Vektoren, Pixeldaten (fragments) generiert und die Texturen in ihre zugeordneten Polygone zeichnet. Hier werden auch das gewählte Schattierungsmodell, die Beleuchtung und die Materialeigenschaften ausgewertet (siehe Kapitel 2.5 und 2.6). In der letzten Verarbeitungseinheit der Rendering-Pipeline werden pixelweise- Operationen, wie die Auswertung von Alphawerten der Pixel, um Transparenz zu erzeugen und die Anwendung von logischen Operationen auf Pixeldaten, durchgeführt. Am Ende entsteht ein zweidimensionales Bild in der Größe des OpenGL-Anzeigefensters, welches der Treiber im Framebuffer speichert und von der Grafikkarte auf dem Bildschirm dargestellt wird. Der Framebuffer besitzt einen Rückkanal (in Abbildung 3.2 gestrichelt dargestellt), über den es möglich ist, Pixelwerte auszulesen und für weitere Verarbeitungsschritte wiederzuverwenden. Man spricht von multi-pass-rendering, wenn der Framebuffer nach dem ersten Durchlauf der Rendering-Pipeline nicht dargestellt wird, sondern zwei- oder mehrmals die Pipeline durchläuft, bevor er auf dem Bildschirm erscheint. Moderne OpenGL-basierte Spiele benutzen bis zu sieben Durchläufe, um spezielle grafische Effekte zu erzeugen. 1 Eine Farbtabelle wird benutzt, um die eigentlichen Werte durch die Werte der Tabelle auszutauschen

35 KAPITEL 3. VISUALISIERUNGSTECHNIKEN Die Visualisierungs-Pipeline Auch die Visualisierung von Volumendaten lässt sich mit einem Pipeline- Konzept realisieren (siehe Abbildung 3.3). Als Eingabe in die Visualisierungs- Pipeline dienen die Rohdaten. Üblicherweise enthalten sie mehr als die eigentlich relevanten Daten. Diese werden durch einen Filterungsprozess aus den Rohdaten extrahiert. Das können Schnitte durch das Volumen sein oder Schwellwerte für Opazitäten. Auch eine Überabtastung 1 (oversampling) ist möglich, mit einer Einschränkung in der Bildqualität. Indem man das Datenvolumen auf seinen relevanten Anteil reduziert, werden Ressourcen geschont. Der nächste Schritt (die Transformation) ist der eigentliche Kern der Volumenvisualisierung. Die Struktur der Daten wird analysiert und modifiziert, um die gewünschten Informationen hervorzuheben. Dies kann über eine normale Farbtabelle geschehen, die Voxel verschieden einfärbt; aber auch komplexere Operationen wie die Extraktion von Oberflächen und Umwandlung in Polygone sind möglich. Im letzten Schritt (Rendering) wird das 3d-Volumen in ein 2d-Bild überführt. Dazu gehört die Rasterisierung (scan-conversion) und das Zuschneiden des Bildes in das gewünschte Ausgabeformat 2. Der hier schematisch vorgestellte Ansatz beschreibt allgemein den Prozess der Volumenvisualisierung. Die verschiedenen Visualisierungstechniken implementieren für jeden Schritt eigene Algorithmen, der dreistufige Ablauf bleibt jedoch erhalten. 3.3 Volumenvisualisierung Bei der Volumenvisualisierung spricht man auch von direkten Verfahren, weil die Voxeldaten selbst dargestellt werden und nicht in einem aufwendigen Vorverarbeitungsschritt in ein anderes Format überführt werden müssen. Erst die hardwarebeschleunigte Bearbeitung erlaubt eine interaktive Volumenvisualisierung, da reine Softwarelösungen auf Standard-Hardware oftmals zu langsam sind, um die Daten zu filtern und zu transformieren. Das hat den Vorteil, daß die meisten Bearbeitungsschritte hardwarebeschleunigt auf der Grafikkarte ausgeführt werden können. Nachteilig sind die begrenzte Funktionalität und die unflexible Architektur der OpenGL Textur- und Pixelpipeline. Diese Funktionalität wurde von verschiedenen Herstellern erweitert, die so genannte OpenGL-extensions mit ihrer Grafikkarte eingeführt haben. Diese Erweiterungen sind aber oft her- 1 Nur jedes n-te Voxel wird benutzt 2 Zum Beispiel die Größe des OpenGL-Anzeigefensters

36 KAPITEL 3. VISUALISIERUNGSTECHNIKEN 31 Rohdaten Filterung aufbereitete Daten Transformation transformierte Daten Rendering Rasterbild Abbildung 3.3: Die Visualisierungs-Pipeline

37 KAPITEL 3. VISUALISIERUNGSTECHNIKEN 32 stellerspezifisch und somit wenig portabel. Das OpenGL-ARB nimmt diese Erweiterungen aber auf und fügt einige davon zu neuen OpenGL-Versionen hinzu. Dann sind sie ein Teil der OpenGL-Spezifikation und müssen von jeder Implementierung unterstützt werden. Da es aber Jahre dauert, bis eine neue Version von OpenGL veröffentlicht wird, ist dies ein sehr langsamer Entwicklungsprozess, der gerade im schnellebigen Bereich der Grafikhardware zu einer Vielzahl herstellerspezifischer Erweiterungen geführt hat. Um trotzdem ein breites Spektrum an Hardware abzudecken, ist es möglich zur Laufzeit abfragen, welche Erweiterungen die jeweilige Grafikkarte unterstützt und dann den jeweiligen Algorithmus mit dem unterstützten Satz an Erweiterungen ausführen. Dies hat den Nachteil, daß Algorithmen mehrmals mit den jeweiligen Erweiterungen implementiert werden müssen. Oder man beschränkt sich auf die offiziellen ARB-Erweiterungen, die von den meisten Herstellern in den neueren Grafikkarten hardwarebeschleunigt unterstützt werden Klassifikation Um die physikalischen Eigenschaften des Emissions-Absorptions-Modells, das in Kapitel 2.8 erläutert wurde, in der Visualisierung zu benutzen, muß man den Emissions- und Absorptionskoeffizienten für jeden Abtastwert v festlegen. Diesen Vorgang nennt man Klassifikation (classification) und wird mittels einer geeigneten Transferfunktion T bestimmt. I(s k ) = T emission (v) und θ k = T absorption (v) Es gibt verschiedene Ansätze Transferfunktionen automatisiert zu bestimmen, indem man den Volumendatensatz analysiert. Diese sind aber oft nicht allgemein genug, um sie auf alle Arten von Volumendaten anzuwenden. Deshalb ist die Bestimmung einer geeigneten Transferfunktion meistens ein aufwendiger, manueller Prozess, der viel Erfahrung erfordert. Besonders wichtig ist es, daß der Anwender eine Veränderung der Transferfunktion sofort in der Visualisierung sieht, um den iterativen Prozess des Ausprobierens zu beschleunigen. Außerdem sollte es die Möglichkeit geben, Transferfunktionen zu speichern und zu laden, um schnell verschiedene Klassifikationen auf ein Bild anzuwenden. Transferfunktionen werden oft über vierkanalige RGBA-Farbtabellen realisiert, wobei der Emissionskoeffizient I(s k ) dem RGB-Tripel und der Absorptionskoeffizient θ k dem Alphakanal A entspricht. Wie im Kapitel beschrieben, bestehen Volumendaten aus diskreten Abtastwerten, die in einem dreidimensionalen Raster angeordnet sind. Im Kapitel 2.7 wurde erklärt, daß sich durch die Abtastung diskreter Punkte mit

38 KAPITEL 3. VISUALISIERUNGSTECHNIKEN 33 einer geeigneten Abtastfrequenz, das kontinuierliche Ausgangssignal rekonstruieren lässt, indem man einen geeigneten Filter anwendet. Wenn man nun die Transferfunktion auf die Volumendaten anwenden will, kann man dies tun, bevor die Daten gefiltert wurden (pre-classification) oder danach (postclassification). Die Ergebnisbilder unterscheiden sich deutlich voneinander. Am einfachsten lässt sich eine pre-classification implementieren, da OpenGL ab Version 1.4 palettierte Texturen (GL_EXT_paletted_texture) direkt unterstützt. Das heißt, daß die Texturen nicht als Luminanzwerte, sondern als Indizes auf eine externe Farbpalette interpretiert werden. Vor der Texturgeneriertung werden dann die Indexwerte durch die entsprechenden Werte der Farbtabelle ausgetauscht. Das hat den Vorteil, daß anstatt vier RGBA-Werte nur ein Indexwert pro Pixel gespeichert werden muß, was den Speicherbedarf auf ein Viertel reduziert. Eine zweite OpenGL-Erweiterung GL_EXT_shared_texture_palette ermöglicht es, eine Farbpalette zwischen mehreren Texturen zu teilen und somit den Speicherbedarf weiter zu reduzieren, wenn die Daten in mehrere zwei- oder dreidimensionale Texturen aufgeteilt sind. Eine post-classification muss hingegen komplett in der Grafikpipeline stattfinden, da die Farbpalette nach der Interpolation der Texturen angewendet wird. Auch hierfür kann man eine OpenGL-Erweiterung benutzen (GL_ NV_texture_shader). Es handelt sich um eine Erweiterung, die das so genannte pixelshading, also die direkte Manipulation von Pixelwerten nach der Texturgenerierung, unterstützt. Man verwendet dazu eine Technik, die eine Textur, in Abhängigkeit von einer zweiten, generiert (dependent texures). Dabei werden in der ersten Textur die normalen Luminanzwerte gespeichert und interpoliert. In der zweiten Textur wird die Farbtabelle generiert. Die interpolierten Luminanzwerte der Texturen dienen dann als Indizes der Fabtabelle, aus der sich dann der resultierende RGBA-Wert bestimmen lässt. Dies lässt sich aber auch mit der herstellerunabhängigen OpenGL Shadersprache glslang erreichen, welche in der kommenden Version 2.0 in OpenGL Einzug halten wird. Es wird allerdings noch einige Zeit dauern, bis die Hersteller den kompletten Satz von OpenGL-2.0 in ihre Grafikkartentreiber integriert haben und man muß natürlich auch eine moderne Grafikkarte besitzen, die OpenGL-2.0 unterstützt. Es gibt es im Moment leider keine Möglichkeit, Transferfunktionen ohne einen erhöhten Speicherbedarf und Performanceverluste herstellerunabhängig zu implementieren. Im Folgenden sollen drei Verfahren zur direkten Volumenvisualisierung vorgestellt werden.

39 KAPITEL 3. VISUALISIERUNGSTECHNIKEN d-Texturen, bilinear interpoliert Bei diesem Verfahren werden die Volumendaten in zweidimensionale Scheiben (slices) zerschnitten, hintereinander angeordnet und dann gerendert. Die Scheiben sind an den Hauptachsen des Volumens ausgerichtet und besitzen seine Abmessungen. Man zeichnet die Scheiben von hinten nach vorne (backto-front order), um die korrekten Tiefeninformationen zu erhalten. Die Scheiben sind dabei normale zweidimensionale Texturen, die in Rechteckpolygone gerendert werden (siehe Abbildung 3.4). Reihenfolge Sichtvektor Abbildung 3.4: Hintereinander angeordnete Scheiben des Volumens Wenn das Volumen rotiert wird, ergibt sich ein Problem, wenn der Sichtvektor seitlich oder von oben auf den Scheibenstapel zeigt. Es entstehen grobe Artefakte, da die zweidimensionalen Texturen zwar in zwei Richtungen (bilinear) interpoliert werden, aber zwischen den einzelnen Scheiben keine Interpolation stattfindet. So blickt man zwischen den Scheiben hindurch, da der Abstand zwischen den Scheiben größer als die minimale Abtastrate ist und dadurch das Nyquist-Theorem verletzt wird (siehe Abbildung 3.5 und Kapitel 2.7). Man umgeht dieses Problem, indem man drei Scheibenstapel mit in den Hauptebenen ausgerichteten Scheiben generiert und bei der Rotation den Stapel anzeigt, dessen Normalenvektor am nächsten zum Sichtvektor liegt (siehe Abbildung 3.6). Das hat aber auch Nachteile, denn zum einen müssen die Volumendaten dreimal im Speicher gehalten werden und zum anderen kann eine Art Ruckeleffekt auftreten, wenn bei einer Drehung der Scheibenstapel ausgetauscht

40 KAPITEL 3. VISUALISIERUNGSTECHNIKEN 35 Abbildung 3.5: Artefakte beim Blick auf die Seite eines Scheibenstapels Sichtvektor Reihenfolge Reihenfolge Sichtvektor Abbildung 3.6: Man verwendet drei Scheibenstapel, um Artefakte an den Seiten zu vermeiden

41 KAPITEL 3. VISUALISIERUNGSTECHNIKEN 36 werden muss, da die Texturen vom Hauptspeicher in den Grafikspeicher geladen werden. Trotzdem kommt es bei einer Vergrößerung der Szene immer noch zu Artefakten, da der Abstand zweier benachbarter Abtastpunkte zwischen zwei Scheiben vom Sichtwinkel abhängt. So wird er an den Rändern des Volumens unter Umständen größer als die minimale Abtastrate, wenn man stark vergrößert, was wiederum die bekannten Störungen verursacht (siehe Abbildung 3.7). Abbildung 3.7: Artefakte an den Rändern durch starke Vergrößerung Ein weiterer Effekt ist das Springen der Voxel, da sich nach dem Austauschen der Stapel die Positionen der Voxel geringfügig geändert hat. Dies hat ein leichtes Flackern des Bildes zum Ergebnis. Das hier beschriebene Verfahren ist auch mit älteren Grafikkarten realisierbar, da zweidimensionale Texturen von jeder OpenGL-Implementierung hardwarebeschleunigt unterstützt werden. Unter der Annahme, daß genügend Speicher vorhanden ist, liefert diese Methode sehr schnelle Bildwiederholraten mit den oben erwähnten Problemen bei der Bildqualität d-Texturen, trilinear interpoliert Um die Bildqualität des oben beschriebenen Verfahrens zu verbessern, haben Rezk-Salama, Engel et al. [RSEB + ] statt einer bilinearen, eine trilineare Interpolation vorgeschlagen, die auch zwischen den einzelnen Scheiben interpoliert. Die Berechung der trilinearen Interpolation lässt sich in

42 KAPITEL 3. VISUALISIERUNGSTECHNIKEN 37 eine Folge von drei linearen Interpolationen in die entsprechenden Richtungen zerlegen. So werden die Texturen zunächst von der normalen OpenGL- Textureinheit bilinear interpoliert. Mit Hilfe der OpenGL-Erweiterung GL_ NV_register_combiners, welche von NVIDIA mit der Grafikkarte GeForce256 eingeführt wurde, werden die Pixel der benachbarten Scheiben linear interpoliert, um dann die gewünschte trilineare Interpolation zu erhalten. Die Register-Combiner erlauben es die OpenGL-Textureinheit komplett zu umgehen und stattdessen eine Reihe hintereinandergeschalteter Registeroperationen (combiner stages) zu durchlaufen und parallel mehrere verschiedene Berechnungen auszuführen. Dabei dient die Ausgabe einer Stufe als Eingabe der nächsten Stufe. Die Verarbeitung einer kompletten Textur dauert in der Regel nur einen Takt der Grafikkarte. Da heutige Spitzenprodukte von NVI- DIA bei Taktfrequenzen von über 500Mhz bis zu acht Stufen unterstützen, lassen sich sehr schnell komplexe Texturoperationen durchführen. Eine Stufe ist dabei in RGB- und Alpha-Anteil aufgeteilt. Nachdem alle Stufen durchlaufen sind, wird die endgültige Textur in einer Endstufe (final stage) erzeugt. Der schematische Aufbau des Register-Combiner-Mechanismus ist in Abbildung 3.8 dargestellt. In Abbildung 3.9 ist der interne Aufbau einer Register- Eingangsregister Stufe 1 RGB-Anteil Alpha-Anteil AB+CD, AB, CD AB+CD, AB, CD Stufe 2 AB+CD, AB, CD AB+CD, AB, CD Endstufe AB+(1-A)C+D, EF, G RGBA Textur Abbildung 3.8: Schematischer Aufbau des Register-Combiner Mechanismus

43 KAPITEL 3. VISUALISIERUNGSTECHNIKEN 38 Combiner-Sufe dargestellt. Auf der linken Seite befinden sich eine Reihe von Eingangsregister RGB A Ausgangsregister RGB A Primärfarbe Sekundärfarbe Textur 0 Textur 1 Undef. 0 Undef. 1 Vorverarbeitung Vorverarbeitung Vorverarbeitung Vorverarbeitung A B C D AB + CD AB mux CD Primärfarbe Sekundärfarbe Textur 0 Textur 1 Undef. 0 Undef. 1 Nebel Konstante Farbe 1 AB A B Skalierung und Verschiebung Nebel Konstante Farbe 1 Konstante Farbe 2 Konstante Farbe 2 Null CD C D Null nicht lesbar nicht schreibbar Abbildung 3.9: Interner Aufbau einer normalen Register-Combiner Stufe Eingangsregistern, die RGBA-Vektoren speichern können. Danach wird bestimmt, welche Register nach einem Vorverarbeitungsschritt in welche der vier Eingangsvariablen (A, B, C, D) geladen werden. Der Vorverarbeitungsschritt kann ebenfalls aus einer Menge von Operationen 1 gewählt werden, die dann auf den Pixeldaten ausgeführt werden. Nun erfolgt die eigentliche Verarbeitung der Daten: Parallel werden drei wählbare Operationen durchgeführt, entweder eine Multiplikation (AB bzw. CD) oder die Berechnung des Skalarprodukts (A B bzw. C D). Zusätzlich noch eine komponentenweise gewichtete Summe (AB+CD) oder eine mux-operation, die folgendermaßen definiert ist: { CD : falls Undef0Alpha 0, 5 ABmuxCD = AB : sonst (3.1) Dabei ist Undef0 Alpha der Alphawert des Eingangsregisters Undef0. Anschließend lassen sich die Ergebnisse noch skalieren und verschieben, bevor sie in die Ausgaberegister geschrieben werden. Die Ausgaberegister dienen dann entweder der nächsten Combiner-Stufe oder der Endstufe als Eingaberegister. Die Combiner-Stufen lassen sich für den RGB- und Alpha-Anteil vollständig getrennt voneinander konfigurieren (siehe Abbildung 3.8). Sie sind an fünf Stellen individuell anpassbar: Eingabere- 1 Operationen wie Inversion, Normalisierung oder Negation

44 KAPITEL 3. VISUALISIERUNGSTECHNIKEN 39 gister, Vorverarbeitung, Operationen, Skalierung und Verschiebung, Ausgaberegister. Am Ende der Combiner-Pipeline liegt noch eine spezielle Endstufe, die einen anderen Aufbau als die normalen Combiner-Stufen hat (siehe Abbildung 3.10). Die Endstufe ist für die Berechnung von Farben und Nebel geeignet, Eingangsregister RGB A Vorverarbeitung Vorverarbeitung Primärfarbe E F Sekundärfarbe EF Textur 0 Textur 1 Undef. 0 Vorverarbeitung Vorverarbeitung Vorverarbeitung Vorverarbeitung Undef 0 + Sekundärfarbe Vorverarbeitung Undef. 1 Nebel A B C D G Konstante Farbe 1 Konstante Farbe 2 AB+(1-A)C+D RGB Ausgabe Null G Alpha Ausgabe Abbildung 3.10: Interner Aufbau der Register-Combiner-Endstufe da sie im Gegensatz zu normalen Stufen auf alle Eingangsregister Zugriff hat. Sie kann aber auch für andere Operationen genutzt werden, da in ihren Vorverarbeitungsschritten die gleichen Berechnungen möglich sind wie in normalen Stufen. Als Ergebnis liefert diese Stufe einen RGBA-Vektor, der dann normal in der OpenGL-Rendering-Pipeline weiterverarbeitet 1 wird. Um eine trilineare Interpolation zu erzielen, werden mit Hilfe geeigneter Register-Combiner-Einstellungen Zwischenscheiben mittels linearer Interpolation der Pixel benachbarter Scheiben generiert (siehe Abbildung 3.11). Da die Scheiben selbst schon bilinear interpoliert sind, erhält man damit die gewünschte trilineare Interpolation. Dazu werden zwei benachbarte Scheiben (S i und S i+1 ) in die Eingangsregister Textur0 und Textur1 der ersten Stufe geladen. Ziel ist die Interpolation durch die Operation AB+CD, wobei B und D die Gewichtungsfaktoren und A und C die Pixelwerte sind. Dazu schaltet die Vorverarbeitung für die Werte A und C ab und lädt die Textur0 in A und Textur1 in C. Die Variablen B und D beinhalten die zur Interpolation notwendigen Gewichtungsfaktoren (1 α) und α, die aus einem der beiden 1 Der nächste Schritt sind die pixelweisen Operationen (siehe Abbildung 3.2)

45 KAPITEL 3. VISUALISIERUNGSTECHNIKEN 40 Eingaberegister Combiner-Stufe0 Null Endstufe Ausgaberegister Scheibe i Scheibe i+1 Alpha Textur0 Textur1 KonstanteFarbe0 Invertierung A B C D AB+CD RGB A B C D AB+ (1-A)C+ D RGB A Alpha G Abbildung 3.11: Register-Combiner-Konfiguration zur Interpolation beliebiger Zwischenscheiben KonstanteFarbe-Register gelesen werden. So ergibt sich für die Berechnung einer beliebigen Scheibe S α zwischen den Schichten S i und S i+1 : S α = (1 α) S i + α S i+1 α [0, 1] (3.2) Den Gewichtungsfaktor α lädt man einmal in die Variable D und einmal mit einer Invertierung 1 als Vorverarbeitungsschritt in die Variable B. Nach der Operation AB+CD erhält man dann das Ergebnis: AB+CD = Textur0 (1 KonstanteFarbe0) + Textur1 KonstanteFarbe0, was der Berechnung aus Gleichung (3.2) entspricht. Da die Interpolation innerhalb einer Combiner- Stufe durchgeführt werden kann, werden die folgenden Stufen deaktiviert. Das Ergebnis der Interpolation wird im Ausgaberegister Undef0 gespeichert. Die Endstufe holt sich den RGBA-Vektor und legt den Alphawert Undef0 Alpha in der Variablen G ab, wo er direkt als Alpha-Komponente des Ausgangsvektors dient. Der RGB-Anteil wird in D gespeichert. Die Variablen A, B und C werden durch das Register Null mit null initialisiert. Durch die Operation AB + (1 A)C + D enthält der RGB-Anteil des Ausgangsvektors nur noch den Wert von D. Nach der Endstufe werden die interpolierten Daten durch die oben beschriebene Farbpalette eingefärbt und dann gerendert. Da die Interpolation mittels Register-Combiner die normale OpenGL-Texturgenerierung umgeht und innerhalb eines Taktzyklus durchgeführt wird, ist das Rendern einer interpolierten Zwischenschicht nicht langsamer als das Rendern einer normalen Textur. Dies hat den Vorteil, daß kein Speicher innerhalb des Grafikkartenspeichers belegt wird, weil die Rasterisierungsstufe die Textur generiert. Ein Vergleich der bilinearen mit der trilinearen Interpolation durch Register- Combiner ist in Abbildung 3.12 dargetellt. 1 Entspricht der Operation: 1 min(max(x, 0, 1))

46 KAPITEL 3. VISUALISIERUNGSTECHNIKEN 41 Abbildung 3.12: Vergleich zwischen bilinearer und trilinearer Interpolation d-Texturen Eine weitere Möglichkeit eine trilineare Interpolation hardwarebeschleunigt durchzuführen, sind dreidimensionale Texturen, die OpenGL seit Version 1.2 standardmäßig unterstützt. Dabei müssen die Volumendaten auch in Scheiben zerlegt werden, da OpenGL keine Volumenprimitive unterstützt. Die Scheiben sind aber im Gegensatz zu den vorherigen Ansätzen nicht am Objekt, sondern zum Betrachter hin ausgerichtet (viewport aligned). Das bedeutet, daß der Sichtvektor mit dem Normalenvektor der Scheiben kolinear ist. Das hat den Vorteil, daß die Artefakte, die bei objeketausgerichteten Scheiben entstehen, vermieden werden können, indem die Schnittpunkte des Volumens mit den Scheiben nach jeder Änderung des Sichtwinkels neu berechnet werden. Wobei es auch hier bei einer starken Vergrößerung zu Artefakten kommen kann, da die Abtastrate zu den Rändern der Scheiben hin stark abnimmt. Im Gegensatz zu objektausgerichteten Scheiben hat die Bestimmung der Schnittpunkte der Scheiben mit dem Volumen einen viel höherem Rechenaufwand. Weiterhin müssen diese Schnittpunkte nach jeder Änderung des Sichtwinkels neu bestimmt werden, was diese Berechnung zu einer der Kernroutinen dieses Algorithmus macht. Eine oft genutzte Vorgehensweise wird im folgenden erläutert. Sie besteht aus drei Schritten: 1. Berechnung der Schnittpunkte der Ebene und den Strecken, die die Kanten des Volumens bilden. 2. Elimination doppelter und ungültiger Schnittpunkte.

47 KAPITEL 3. VISUALISIERUNGSTECHNIKEN Sortierung der Punkte um ein geschlossenes Polygon zu bilden. Der Schnittpunkt r s der Scheibe E : n ( r r 0 ) = 0 mit der Kante des Volumens g : r = r 1 + λ a lässt sich leicht mit folgender Formel bestimmen: r s = r 1 + n ( r 0 r 1 ) n a a (3.3) Da diese Berechnung mit Geraden anstelle von Strecken durchgeführt wird, muß sichergestellt sein, daß der Punkt wirklich auf der Kante des Volumens liegt. Deshalb wird im zweiten Schritt ein Bounding-Sphere-Test durchgeführt. Dabei testet man, ob der Schnittpunkt innerhalb einer Kugel liegt, die das Volumen enthält 1. Punkte, die außerhalb liegen, werden verworfen. Punkte die innerhalb eines kleinen Intervalls ɛ liegen, werden zu einem Punkt zusammengefasst. Im dritten Schritt werden die Schnittpunkte sortiert, um geschlossene Polygone zu erhalten. Dazu wird für jede Kante des Volumens ein Satz von sechs Bitflags gespeichert, wobei jedes Flag eine Seite des Volumens repräsentiert. Die Bits werden gesetzt, wenn eine Kante an die entsprechende Seite des Volumens angrenzt. Die Reihenfolge der Schnittpunkte, die ein geschlossenes Polygon bilden, ist gegeben, wenn zwei benachbarte Schnittpunkte ein gleiches Bit gesetzt haben (siehe Abbildung 3.13). Seiten, die eine Kante teilen, lassen sich durch eine bitweise ODER-Operation der Kantenflags bestimmen. Ist das Ergebnis ungleich Null, besitzen die Kanten eine gemeinsame Seite und die Reihenfolge ist richtig. L D H C I G B K A F E J oben unten links rechts vorne hinten A X X B X X C X X D X X E X X F X X G X X. Abbildung 3.13: Sortierung der Schnittpunkte der Scheiben mit dem Volumen unter Zuhilfenahme von Bitflags. 1 Das heißt, die Eckpunkte des Volumens liegen auf der Oberfläche der Kugel

48 KAPITEL 3. VISUALISIERUNGSTECHNIKEN Weitere Verfahren Es existieren noch eine Reihe weiterer Verfahren, die zur Volumenvisualisierung verwendet werden. Dies sind Verfahren, die ohne Hardwarebeschleunigung implementiert werden und deshalb den Ansprüchen an die Performance nicht genügen 1. Diese werden im folgenden kurz erläutert, sind aber nicht Bestandteil dieser Arbeit. Raycasting Die Raycasting-Methode wurde zuerst von Kajiya [KH84] beschrieben und später von Levoy [Lev90] erweitert. Beim Raycasting handelt es sich um eine vereinfachte Version des Raytracing 2, indem man die Reflexion, Brechung und Beugung der Lichtstrahlen außer Acht lässt. Der Lichtstrahl wird entweder vom Betrachter durch das Volumen geworfen (front-to-back) oder vom Volumen zur Kamera hin (back-to-front). Dabei werden die Farb- und Opazitätswerte aufsummiert. Sie bilden später die Farbe und Transparenz der Pixel. Diese Addition entspricht der iterativen Integration entlang des Lichtstrahls, die in Gleichung (2.25) hergeleitet wurde. Die Berechnung wird im Transformationsschritt der Visualisierungs-Pipeline durchgeführt (siehe Abbildung 3.3). Dabei wird häufig die Integration zum Objekt hin bevorzugt, da die Integration abgebrochen werden kann, wenn der Wert die Opazität 1 erreicht (early-ray termination). Dadurch lässt sich der Integrationsprozess, abhängig vom dargestellten Datensatz 3 beschleunigen. Da dieses Verfahren die physikalischen Modelle, die im Kapitel 2.8 diskutiert wurden, direkt abbilden, setzt es in Sachen Bildqualität die Referenz, mit der sich andere Methoden messen lassen müssen. Leider lässt sich dieses Verfahren mit den heutigen Grafikkarten nicht hardwarebeschleunigt implementieren. Durch den hohen Rechenaufwand der Integration entlang der Strahlen ist eine interaktive Implementierung nicht möglich. Shear-Warp Die Shear-Warp Methode wurde von Lacroute und Levroy in [LL94] beschrieben. Sie ist vergleichbar mit der Methode, die in Kapitel dargestellt 1 Es gibt Ansätze, die Berechungen auf mehrere vernetzte Rechner zu verteilen, um die Leistung zu steigern 2 Man verfolgt den Verlauf eines Lichtstrahls von der Lichtquelle durch die Szene. Dabei kann er mehrmals reflektiert, gegebrochen oder gebeugt werden. 3 Wenn der Datensatz eine geringe Opazität besitzt, läuft die Integration länger bis sie den Wert 1 erreicht und terminiert

49 KAPITEL 3. VISUALISIERUNGSTECHNIKEN 44 wurde. Auch hier müssen die Daten dreifach im Speicher gehalten und bei Bedarf ausgetauscht werden, um Artefakte an den Seiten der Scheibenstapel zu vermeiden. Man umgeht aber das Problem der variablen Abtastrate und der daraus resultierenden Artefakte, indem man die Scheiben nicht direkt hintereinander, sondern seitlich verschoben (shear) anordnet. Der Verschiebungsgrad ergibt sich aus dem Sichtwinkel auf das Volumen. Indem man die Strahlen auf das Volumen abknickt (warp) und danach parallel sowie senkrecht durch die Scheiben führt, ergibt sich eine konstante Abtastrate. Somit können Artefakte komplett vermieden werden. Diese Methode lässt sich nicht mit normaler Grafikhardware beschleunigen, es handelt sich aber um die schnellste Softwarelösung zur Volumenvisualisierung. Zur Beschleunigung lassen sich noch eine Lauflängenkodierung und optimierte Bilddatenstrukturen verwenden. Trotzdem ist die Leistungsfähigkeit dieser Methode um ein Vielfaches langsamer als die vorgestellten hardwarebeschleunigten Verfahren. 3.4 Oberflächenvisualisierung Bei der Oberflächenvisualisierung wird im Gegensatz zur Volumenvisualisierung eine zusammenhängende Oberfläche, die gleiche oder ähnliche Werte im Datensatz besitzen, extrahiert und dargestellt. Dafür werden die Daten in einem Vorverarbeitungsschritt in eine Oberflächenrepresentation überführt. Dies können Voxel- oder Polygonoberflächen sein. Falls es sich um Polygonoberflächen handelt, spricht man von indirekter Volumenvisualisierung, weil nicht die Voxeldaten selbst, sondern nur angenährte Polygondaten dargestellt werden. Diese Verfahren unterscheiden sich hauptsächlich darin, wie die Polygonoberflächen generiert werden Das Marching-Cubes-Verfahren Die bekannteste indirekte Methode ist der Marching-Cubes Algorithmus, der von Lorensen et al. [LC87] entwickelt wurde. Er extrahiert eine Iso-Oberfläche (iso-surface), also eine Ebene gleicher Intensitäten, durch Auswertung von Nachbarschaftsbeziehungen der acht benachbarten Voxel. Ein kubusförmiges, strukturierendes Element wird durch das Volumen geschoben und beim Schneiden der Iso-Oberfläche wird einer von 2 8 = 256 möglichen Schnitten durch den Kubus gewählt. Dieser Schnitt durch den Kubus stellt dann ein Polygon der späteren Oberfläche dar (siehe Abbildung 3.14). Diese 256 Konfigurationen werden in einer Look-Up-Tabelle gespeichert um, effizient auf die verschiedenen Konfigurationen zugreifen zu können. Die exakte Position der Schnittpunkte mit den Kanten des Kubus wird durch eine lineare Inter-

50 KAPITEL 3. VISUALISIERUNGSTECHNIKEN Abbildung 3.14: Vier der 256 möglichen Schnitte durch den Kubus.

51 KAPITEL 3. VISUALISIERUNGSTECHNIKEN 46 polation der betreffenden Voxelwerte bestimmt. Durch den reinen Marching-Cubes-Algorithmus erhält man ebensoviele Polygone wie man Voxel hat. Das macht das Verfahren sehr ineffizient, da die Polygone zwar als hardwarebeschleunigte OpenGL-Primitive gerendert werden können, ihre Anzahl die Leistungsfähigkeit der Grafikkarte aber schnell übersteigt. Man reduziert die Menge der Polygone durch einen weiteren Verarbeitungsschritt, der benachbarte Polygone, die fast in einer Ebene liegen, zusammenfasst. Dadurch lässt sich die Anzahl je nach Datensatz um bis zu 40 Prozent, reduzieren. Ein Nachteil dieses Verfahrens ist die aufwendige Vorverarbeitung der Daten, wobei man bei diesem Schritt auch nützliche Analysen auf den Bilddaten durchführen kann 1. Auch ist es, je nach Datensatz, schwierig einen Iso-Wert für die Oberflächenextraktion zu bestimmen, so zum Beispiel wenn die Daten sehr diffus sind. Dann müssen aufwendige Segmentierungsalgorithmen im Vorverarbeitungsschritt angewandt werden, um klare Iso-Oberflächen zu generieren. So hat Seibert in [Sei01] die verschiedenen Nachbarschaftskonfigurationen untersucht, um topologisch definierte Oberflächen zu segmentieren. Die vom Marching-Cubes-Verfahren generierten Oberflächen wirken durch ihre indirekte Darstellung künstlich, da die Oberflächenpolygone eingefärbt werden und nicht mehr die ursprünglichen Luminanzwerte erhalten bleiben. Vorteilhaft ist die Möglichkeit eine Glanzlicht-Beleuchtung mit den normalen OpenGL Beleuchtungsfunktionen zu implementieren Vergleich Jedes der vorgestellten Verfahren hat Nachteile, die je nach den gestellten Anforderungen das Verfahren als geeignet oder ungeeignet qualifizieren. Dabei spielen verschiedene Parameter eine Rolle, die es zu gewichten gilt. Die Hardwareausstattung 3 und Unterstützung der verwendeten OpenGL- Erweiterungen spielen eine sehr große Rolle. Die Anforderungen an die Realitätsnähe der dargestellten Daten kann bei der Entscheidung zwischen di- rekten und indirekten Verfahren beitragen, ebenso wie die gewünschte Beachtung topologischer Eigenschaften. In dieser Arbeit wurden nur direkte Verfahren betrachtet, da sie in Leistungsfähigkeit und Bildqualität den indirekten Verfahren überlegen sind und die Daten ohne Vorverarbeitung direkt von modernen Grafikkarten verarbei- 1 Wie zum Beispiel eine Histogrammgenerierung oder die Berechnung von Kenngrößen 2 Die Glanzlicht-Beleuchtung von Texturen ist nur mit OpenGL-Erweiterungen möglich. 3 Die Leistungsfähigkeit der Grafikkarte, Geschwindigkeit der CPU oder die Menge an verfügbarem Hauptspeicher

52 KAPITEL 3. VISUALISIERUNGSTECHNIKEN 47 tet werden können. In der folgenden Tabelle ist ein Vergleich der Verfahren nach pro und contra dargestellt: PRO CONTRA 2d-Texturen, bilinear interpoliert sehr schnell gute Verfügbarkeit hoher Speicherbedarf nur bilineare Interpolation Artefakte bei Vergrößerung Ruckeln beim Wechsel des Scheibenstapels Springen bei Wechsel des Scheibenstapels 2d-Texturen, trilinear interpoliert sehr schnell hohe Bildqualität (trilineare Interpolation) hoher Speicherbedarf Artefakte bei Vergrößerung eingeschränkte Verfügbarkeit Ruckeln beim Wechsel des Scheibenstapels Springen bei Wechsel des Scheibenstapels 3d-Texturen schnell hohe Bildqualität (trilineare Interpolation) Artefakte bei Vergrößerung eingeschränkte Verfügbarkeit aufwendige Geometrieberechnung in der CPU Marching-Cubes gute Verfügbarkeit direkter Bezug zur Topologie hoher Speicherbedarf aufwändige Vorverarbeitung künstliches Erscheinungsbild langsam Im folgenden Kapitel wird auf Details der im Rahmen dieser Arbeit implementierten Anwendung Voxel-Sculpture eingegangen. Dabei wird die Struk-

53 KAPITEL 3. VISUALISIERUNGSTECHNIKEN 48 tur der Anwendung anhand der Klassenhierarchie und die Kernalgorithmen mit kleinen Codebeispielen erläutert.

54 Kapitel 4 Implementierung Bevor auf die Details der Implementierung eingegangen wird, soll zunächst die Anwendung MAVI und das darin eingebettete Modul Voxel-Sculpture vorgestellt werden, in das die Algorithmen integriert wurden. 4.1 Die Anwendung MAVI und das Voxel- Sculpture Modul Im Rahmen dieser Arbeit entstand das Modul Voxel-Sculpture, im Weiteren kurz VS, das einige der Verfahren aus Kapitel 3 implementiert. VS wurde in C ++ mit Hilfe von OpenGL entwickelt. Als GUI 1 -Bibliothek wurde Qt [Qt] verwendet, welche auch das OpenGL-Fenster, das zur Anzeige benutzt wird, bereitstellt. VS wurde unter Linux entwickelt, aber ohne großen Aufwand auf die Windows-Plattform portiert. Ursprünglich war VS als eigenständige Anwendung unter Beachtung einer zukünftigen Integration in das 3d-Bildverarbeitungs- Framework MAVI [MAV] entwickelt worden, welches mit Hilfe eines Plugin- Mechanismus, Anzeige- und Algorithmenmodule hinzuladen kann. (siehe Abbildung 4.1). Das im OpenGL-Fenster dargestellte Bild lässt sich mit Hilfe der drei Scroll-Räder am Rand des Fensters oder der Maus in allen Raumrichtungen rotieren und vergrößern. Links unten im Bild sieht man den Transferfunktions-Dialog, mit dem sich die Transferfunktion der RGBA-Kanäle verändern lässt. Indem man einen Kontrollpunkt zur voreingestellten Identitätsfunktion hinzufügt und diesen dann verschiebt, kann man die Zuordnung der Graustufen zu den Farb- und Opazitätswerten steuern. Die so erstellten Transferfunktionen lassen sich in einem XML-Format speichern 1 graphical user interface grafische Bedienoberfläche 49

55 KAPITEL 4. IMPLEMENTIERUNG 50 Abbildung 4.1: Die 3d-Bildverarbeitungssoftware MAVI mit geladenem Voxel-Sculpture Modul zeigt die gegeschnittete CT-Aufnahme eines menschlichen Kopfes.

56 KAPITEL 4. IMPLEMENTIERUNG 51 und laden, um sie später wieder herstellen zu können. Desweiteren gibt es einen Dialog, um eine Schnittebene (clipping plane) auf das Bild anzuwenden und auszurichten. Damit lässt sich das Bild in allen Richtungen aufschneiden. Beim Start von VS werden die unterstützten OpenGL-Erweiterungen der Grafikkarte abgefragt und je nach deren Fähigkeiten ein Renderverfahren automatisch ausgewählt (siehe Kapitel 4.3.1). Eine wichtige Rolle für das Erscheinungsbild des gerenderten Objekts spielt die Methode, wie hintereinander liegende Voxel miteinander kombiniert werden. Man spricht von blending wenn die resultierende Farbinformation von anderen (benachbarten) Voxeln abhängt. 4.2 Die Blend-Modi Unter blending versteht man die Art, wie die Opazitätswerte der Voxel berechnet werden, um die Intensität der Rasterpixel zu erhalten. Dabei werden durch die OpenGL-Funktion glblendfunc(quellfaktor, Zielfaktor) die Quell- und Zielfaktoren in der Form (S r, S g, S b, S a ) und (D r, D g, D b, D a ) angegeben. Die RGBA-Werte des resultierenden Voxels ergeben sich aus: (R s S r + R d D r, G s S g + G d D g, B s S b + B d D b, A s S a + A d D a ) VS unterstützt drei verschiedene Blending-Methoden (siehe Abbildung 4.2): Normal-Blending: Standard Blending-Modus in welchem die Voxel entsprechend ihrer Alphawerte transparent sind. Code: glblendfunc(gl_src_alpha, GL_ONE_MINUS_SRC_ALPHA) Quellfaktoren: (A s, A s, A s, A s ) Zielfaktoren: (1, 1, 1, 1) (A s, A s, A s, A s ) MIP-Blending: Die Maximale Intensitätsprojektion (maximum-intensity projection) bei der die Farbe und Intensität des Zielvoxel, das Maximum aller berechneten Voxel ist. Dieses Verfahren wird oft in medizinischen Visualisierungen verwendet, um zum Beispiel Knochen mit hoher Intensität innerhalb von Gewebe mit niedriger Intensität sichtbar zu machen. Code: glblendfunc(gl_src_color, GL_DST_COLOR) Quellfaktoren: (R s, G s, B s, A s ) Zielfaktoren: (R d, G d, B d, A d )

57 KAPITEL 4. IMPLEMENTIERUNG 52 XRay-Blending: Die Farben und Intensitäten der Voxel werden aufaddiert. Das entstehende Bild ähnelt einem zweidimensionalen Röntgenbild. Die Werte müssen noch manuell normiert werden, um ein Übersteuern des Bildes zu vermeiden. Dazu lässt sich die Funktion glcolortableparameterfv() mit dem Parameter GL_COLOR_TABLE_SCALE verwenden. Code: glblendfunc(gl_one, GL_ONE) Quellfaktoren: (1, 1, 1, 1) Zielfaktoren: (1, 1, 1, 1) Abbildung 4.2: Vergleich zwischen Normal-, MIP- und XRay-Blending Da MIP- und XRay-Blending projektionsbasierte Verfahren sind, geht die räumliche Tiefe verloren, die beim normalen Blending erhalten bleibt. Außerdem sind diese Verfahren langsamer, da mehr Voxel in das Blending einbezogen werden. 4.3 Die Klassenstruktur Die Anwendung Voxel-Sculpture wurde streng objektorientiert entwickelt. Die gesamte Funktionalität ist in Klassen gekapselt, die miteinander per Aggregation und Polymorphie interagieren. Vererbung wurde nur verwendet, wenn durch die Ableitung von einer gemeinsammen Basisklasse doppelter Quellcode vermieden oder Wert auf eine einheitliche Schnittstelle gelegt wurde, durch die neue Funktionaliät hinzugefügt werden kann. Alle Klassen wurden im Namensbereich VS definiert. Auf die Verwendung von using namespace für externe Klassen wurde verzichtet, um Namenskollisionen zu vermeiden. Eine externe Bibliothek im Namensraum ITWM stellt die Bildklasse CImage und die Geometrieklasse CBox zur Verfügung, auf die hier aber nicht weiter eingegangen wird. Die Kernklassen von VS sind in Abbildung 4.3 als

58 KAPITEL 4. IMPLEMENTIERUNG 53 1 VS::CVoxelSculpture 1 QGLWidget 1 ITWM::CImage 1 VS::CRenderWidget 1 VS::CRenderEngine 1 VS::C2d3tsRenderEngine VS::CTexture VS::C3dtRenderEngine 1 1 n VS::CTexture2d VS::CTexture3d n 1 ITWM::CBox VS::CMultiTexture2d n VS::CBrick StIntersectionPoint Abbildung 4.3: Statisches UML-Klassendiagramm der Kernklassen der Anwendung Voxel- Sculpture

59 KAPITEL 4. IMPLEMENTIERUNG 54 statisches UML-Klassendiagramm dargestellt. Die oberste Klasse von VS, von der der gesamte Vererbungs- und Aggregationsbaum aufgebaut wird, ist CVoxelSculpture. Diese Klasse hält einen Zeiger auf ein CImage-Objekt, das darzustellende dreidimensionale Bild. Außerdem erzeugt CVoxelSculpture ein Objekt vom Typ CRenderWidget, welches von der Qt-Klasse QGLWidget abgeleitet ist und das eigentliche Anzeigefenster bereitstellt. CRenderWidget wiederum aggregiert einen Zeiger auf ein von CRenderEngine abgeleitetes Objekt (C2d3tsRenderEngine oder C3dtRenderEngine), welches den eigentlichen Algorithmus kapselt. Dies ist eine Anwendung des Strategiemusters (Strategy pattern) aus [GHJV94] zur Kapselung und dem Austausch von Funktionalität. Da CRenderEngine eine pur-virtuelle abstrakte Basisklasse ist, die ein Interface definiert, lassen sich weitere Algorithmen hinzufügen, indem man von CRenderEngine ableitet und das Interface implementiert (siehe Abbildung 4.4). Außerdem lässt sich so der Algorithmus zur Laufzeit austauschen, indem man ein neues von CRenderEngine abgeleitetes Objekt erzeugt und dem Renderfenster den Basisklassenzeiger übergibt. Für das Renderfenster ist der Zugriff auf die Algorithmen durch das Interface CRenderEngine transparent. Ähnlich ist es mit der Klasse CTexture und den abgeleiteten Klassen CTex- CRenderEngine #Render(): void... CRenderEngineImpA #Render(): void CRenderEngineImpB #Render(): void... Abbildung 4.4: Schematische Darstellung des CRenderEngine-Interface ture2d und CTexture3d, die von den jeweiligen Render-Engine-Klassen aggregiert werden; mit dem Unterschied, daß dies kein Basisklassenzeiger ist, da die jeweiligen Render-Engines nur mit ihren abgeleiteten Klassen umgehen können. So lässt sich vermeiden, daß zum Beispiel die Renderklasse, die den Algorithmus für die dreidimensionalen Texturen implementiert, einen Zeiger auf zweidimensionale Texturen aggregiert, was ein undefiniertes Verhalten zur Folge hätte. Eine Ausnahme stellt die Klasse C2d3tsRenderEngine dar, denn sie kann mit Objekten vom Typ CTexture2d und CMultiTexture2d umgehen und hält deswegen einen Basisklassenzeiger auf CTexture2d.

60 KAPITEL 4. IMPLEMENTIERUNG 55 Die Klasse CTexture3d benutzt noch weitere Hilfsklassen, auf die in Kapitel näher eingegangen wird Die Renderklassen In Voxel-Sculpture existieren zur Zeit zwei Implementierungen vom Interface CRenderEngine. Zum einen die Klasse C2d3tsRenderEngine, welche zweidimensionale Texturen bi- und trilinear rendern kann. Zum anderen die Klasse C3dtRenderEngine, welche dreidimensionale Texturen trilinear interpoliert darstellen kann. Diese beiden Klassen überladen die pur-virtuellen Methoden: Render(), GenerateTextures() und Update() von CRenderEngine. Dabei wird mit Render(CImage*) das darzustellende Bild übergeben, Generate- Textures() generiert die Texturen für die spätere Verwendung und Update() wird bei jedem Neuzeichnen der gesamten Szene aufgerufen. Dabei wird Update() von der überladenen Methode paintgl() der Klasse CRender- Widget aufgerufen. Dies ist die Callback-Methode des Render-Fensters und wird bei jedem Neuzeichnen ausgeführt (siehe Abbildung 4.5 und 4.6). Die Klasse C2d3tsRenderEngine Die Renderklasse C2d3tsRenderEngine implementiert die Methode der drei zweidimensionalen Texturstapel, die je nach Blickrichtung ausgetauscht werden (siehe Kapitel 3.3.2). Dafür werden in GenerateTextures() drei Texturstapel generiert, die an den Hauptachsen ausgerichtet sind. Die Texturreferenzen werden in den drei Vektoren m axytextures, m axztextures und m ayztextures gespeichert. Um den jeweils korrekten Texturstapel zu bestimmen, wird der Sichtvektor aus der Modellmatrix der Szene extrahiert. Dabei entspricht der aktuelle Sichtvektor der dritte Zeile der Modellmatrix 1 (siehe Quelltext 4.1). Quelltext 4.1 Bestimmung des Sichtvektors 1 GLfloat amatrix[16]; 2 3 // get the modelview matrix 4 glgetfloatv(gl_modelview_matrix, &amatrix); 5 6 // extract the view-vector 7 GLfloat aviewvec[] = { amatrix[2], amatrix[6], amatrix[10], 0.0 }; 1 Im Beispiel werden die Indizes 2, 6 und 10 verwendet, da OpenGL eine transponierte Matrix benutzt (column-major-form)

61 n n n 1 KAPITEL 4. IMPLEMENTIERUNG 56 VS::CVoxelSculpture QGLWidget ITWM::CImage VS::CRenderWidget VS::CRenderEngine VS::C2d3tsRenderEngine VS::CTexture VS::C3dtRenderEngine VS::CTexture2d VS::CTexture3d ITWM::CBox VS::CMultiTexture2d VS::CBrick StIntersectionPoint ITWM::CImage QGLWidget VS::CVoxelSculpture -m_pimage: CImage* -m_prenderwidget: CRenderWidget* +DrawImage(pImage:CImage*): void #initializegl(): void #resizegl(nwidth:int,nheight:int): void #paintgl(): void m_prenderwidget->render(m_pimage); m_prenderwidget->update(); VS::CRenderWidget -m_prenderengine: CRenderEngine* #initializegl(): void #resizegl(nwidth:int,nheight:int): void #paintgl(): void +Render(pImage:CImage*): void VS::CRenderEngine +Render(pImage:CImage): void +GenerateTextures(): void +Update(): void m_prenderengine->render(pimage); m_prenderengine->generatetextures(); VS::C2d3tsRenderEngine -m_axytextures: vector<ctexture2d*> -m_axztextures: vector<ctexture2d*> -m_ayztextures: vector<ctexture2d*> -m_btrilininterpolation: bool +Render(pImage:CImage*): void +GenerateTextures(): void +Update(): void VS::C3dtRenderEngine -m_ptexture: VS::CTexture3d* +Render(pImage:CImage*): void +GenerateTextures(): void +Update(): void m_ptexture->draw(apoints); switch(viewdirection){... case XY_BACK_TO_FRONT: for(int i in m_axytextures) m_axytextures[i]->draw(apoints);... } if(m_btrilininterpolation){ m_axytextures.push_back(new CMultiTexture2d());... } else{ m_axytextures.push_back(new CTexture2d());... } Abbildung 4.5: Statisches UML-Klassendiagramm der Renderklassen der Anwendung Voxel-Sculpture. Oben-links ist der dargestellte Ausschnitt aus der gesammten Klassenhirarchie eingezeichnet.

62 KAPITEL 4. IMPLEMENTIERUNG 57 VoxelSculpture RenderWidget RenderEngineImpl TextureImpl <<create>> initializegl <<create>> DrawImage Render GenerateTextures <<create>> paintgl Update paintgl Update Draw Draw OpenGL Funktionen OpenGL Funktionen Abbildung 4.6: Interaktionsdiagramm der Voxel-Sculpture Renderklassen Da die Scheiben immer von hinten nach vorne gezeichnet werden müssen, um die Tiefeninformationen zu erhalten, ist zu entscheiden, in welcher Reihenfolge die Texturen zu zeichnen sind. Dies geschieht in der Methode GetStack(), die einen Schlüssel entsprechend der Richtung und Reihenfolge liefert. Um den richtigen Scheibenstapel auszuwählen, wird die Vektorkomponente bestimmt, die betraglich am größten ist. Die Reihenfolge wird dann durch das Vorzeichen bestimmt (siehe Quelltext 4.2). VS::X, VS::Y und VS::Z sind dabei Enumerationen, die den Werten 0, 1 und 2 entsprechen und deshalb als Indexargumente von Arrays verwendet werden können. Entsprechend dem bestimmten Sichtvektor und der Reihenfolge zeichnet man dann die Scheiben (siehe Quelltext 4.3). Das weitere Zeichnen der Texturen übernehmen dann die Texturobjekte, auf die im Kapitel näher eingegangen wird. Die Klasse C2d3tsRenderEngine bietet alternativ die Möglichkeit, anstatt einer bilinearen Interpolation innerhalb einer 2d-Textur eine trilineare Interpolation zwischen den Scheiben durchzuführen (siehe Kapitel 3.3.3). Dazu werden in GenerateTextures() anstatt CTexture2d, CMultiTexture2d Instanzen erzeugt. Die Klassenvariable m btrilininterpolation dient dazu zwischen den beiden Modi zu wechseln.

63 KAPITEL 4. IMPLEMENTIERUNG 58 Quelltext 4.2 Bestimmung des richtigen Scheibenstapels und der Zeichenreihenfolge anhand des Sichtvektors 1 EnStack C2d3tsRenderEngine::GetStack(const GLfloat* aviewvec) const 2 { 3 switch(cglutilities::getmaxveccomponent(aviewvec)){ 4 case VS::X: 5 if(aviewvec[vs::x] < 0) 6 return VS::YZ_FRONT_TO_BACK; 7 else 8 return VS::YZ_BACK_TO_FRONT; 9 case VS::Y: 10 if(aviewvec[vs::y] < 0) 11 return VS::XZ_FRONT_TO_BACK; 12 else 13 return VS::XZ_BACK_TO_FRONT; 14 case VS::Z: 15 if(aviewvec[vs::z] < 0) 16 return VS::XY_FRONT_TO_BACK; 17 else 18 return VS::XY_BACK_TO_FRONT; 19 } 20 } Quelltext 4.3 Zeichnen der Scheibenstapel 1 switch(getstack(aviewvec)){ 2 case VS::XY_BACK_TO_FRONT: 3 for(int i=0; i < img->size().z; i++){ 4 m_axytextures[i]->draw(...); 5 } 6 break; 7 8 case VS::XY_FRONT_TO_BACK: 9 for(int i=img->size().z-1; i>=0; i++){ 10 m_axytextures[i]->draw(...); 11 } 12 break; case VS::XZ_BACK_TO_FRONT: }

64 KAPITEL 4. IMPLEMENTIERUNG 59 Die Klasse C3dtRenderEngine Die Renderklasse C3dtRenderEngine implementiert die Methode der trilinearen Interpolation durch 3d-Texturen (siehe Kapitel 3.3.4). Da dieses Verfahren nicht auf Scheibenstapeln, sondern auf volumetrischen Texturdaten beruht, aggregiert diese Klasse nur ein Objekt vom Typ CTexture3d, in dem das gesamte dreidimensionale Bild gespeichert ist. In der Methode Update() wird dann lediglich die Methode Draw() der Textur aufgerufen. Das weitere Rendering und die Geometriebehandlung findet dann in der Texturklasse statt. Ansonsten implementiert C3dtRenderEngine ebenfalls die CRenderEngine- Schnittstelle Die Texturklassen Die Basisklasse für alle Texturklassen ist CTexture, die ähnlich wie CRender- Engine eine Schnittstelle zur Verfügung stellt, die von den abgeleiteten Klassen implementiert werden muss (siehe Abbildung 4.8). In OpenGL haben Texturen die Einschränkung, daß ihre einzelnen Dimensionen die Größe von Zweierpotenzen haben müssen (POT Power-of-Two Textures). Würde nun die Texturgröße entsprechend der nächst-größeren Zweierpotenz gewählt, hätte man unter Umständen einen sehr großen Speicherverbrauch, von dem ein großer Teil ungenutzt bliebe 1. Um dieses Problem zu umgehen, werden in Voxel-Sculpture die Texturen in Objekten gekapselt, die eine Textur beliebiger Größe aus POT-Texturen zusammensetzen (siehe Abbildungen 4.7 und 4.9). Die Klasse CTexture2d Objekte der Klasse CTexture2d repräsentieren eine zweidimensionale Textur beliebiger Größe. Dafür werden zwei Vektoren mit den Koordinaten der Teiltexturen bei ihrer Erzeugung erstellt. Die Klasse überschreibt die Methode Draw(const double*) der Basisklasse CTexture. Der Parameter der Funktion ist ein Array mit den Koordinaten dreier Punkte (P 1, P 2, P 3 ) in der Ebene, in der die Textur liegt. Aus diesen drei Punkten werden die beiden orthogonalen Vektoren: a = P 2 P 1 und b = P 3 P 1 bestimmt. Aus den Größen der Textur und der Teiltexturen werden die beiden Faktoren λ und µ bestimmt. Über die Formel r(λ, µ) = P 1 + λ a + µ b können dann die Vektoren der Koordinaten der Teiltexturen ermittelt werden. 1 Bei einer Bildgröße von , 3MB müsste man = 128MB Texturspeicher belegen.

65 KAPITEL 4. IMPLEMENTIERUNG Abbildung 4.7: Ein Textur der Größe 150x110 wird aus 20 Einzeltexturen zusammengesetzt. Die Teilgrößen in X-Richtung sind: 128, 16, 4, 2. Die Teilgrößen in Y-Richtung sind: 64, 32, 8, 4, 2. Die Klasse CMultiTexture2d Die Klasse CMultiTexture2d ist von CTexture2d abgeleitet, weil sie prinzipiell genauso funktioniert wie die Klasse CTexture2d. Die Koordinatengenerierung der Teiltexturen findet in der Basisklasse statt. Der Unterschied besteht darin, daß CMultiTexture2d die trilineare Interpolation zwischen den Scheiben mit Hilfe der NVidia Register-Combiner implementiert (siehe Kapitel 3.3.3). Um zwischen zwei Scheiben interpolieren zu können, müssen die benachbarten Texturen an verschiedene Textureinheiten gebunden werden. Die Klasse CMultiTexture2d besitzt die Methode BindTexture(), die das entsprechende Texturobjekt an die zweite Textureinheit GL TEXTURE1 ARB bindet. Damit die Texturen ihre Nachbartexturen (Nachbarscheiben) kennen, aggregiert jede einen Zeiger auf ihren Vorgänger und ihren Nachfolger. So entsteht eine doppelt verkettete Liste von Texturobjekten. Vor dem Rendern bindet sich die Textur selbst an die Textureinheit GL TEXTURE0 ARB und abhängig vom übergebenen Parameter BACK TO FRONT oder FRONT TO BACK wird entschieden, ob der Vorgänger oder der Nachfolger an die zweite Textureinheit gebunden werden soll (siehe Quelltext 4.4). Ein Parameter innerhalb der Klasse CMultiTexture2d bestimmt, wieviele Zwischenscheiben generiert werden sollen. Die Texturen werden dann wie in der Klasse CTexture2d gerendert.

66 n n 1 KAPITEL 4. IMPLEMENTIERUNG 61 VS::CVoxelSculpture QGLWidget ITWM::CImage VS::CRenderWidget VS::CRenderEngine VS::C2d3tsRenderEngine VS::CTexture VS::C3dtRenderEngine VS::CTexture2d VS::CTexture3d VS::CMultiTexture2d ITWM::CBox VS::CBrick StIntersectionPoint VS::CTexture #m_atexturenames: vector<int> #Draw(aPoints:const double*): void VS::CTexture2d #m_axcoords: vector<unsigned int> #m_aycoords: vector<unsigned int> #Draw(aPoints:const double*): void VS::CTexture3d #m_axcoords: vector<unsigned int> #m_aycoords: vector<unsigned int> #m_azcoords: vector<unsigned int> -m_abricks: vector<cbrick> #Draw(aPoints:const double*): void -m_pnexttexture: CMultiTexture2d* -m_pprevtexture: CMultiTexture2d* -m_direction: EnDir VS::CMultiTexture2d #Draw(aPoints:const double*): void +SetNextTexture(pNextTexture:CMultiTexture2d*,direction:EnDir): void +SetPrevTexture(pPrevTexture:CMultiTexture2d*,direction:EnDir): void +Bind(): void ITWM::CBox +Width(): long +Height(): long +Depth(): long +left(): long +right(): long +top(): long +bottom(): long +front(): long +back(): long switch(m_direction){... case XY_BACK_TO_FRONT: m_pprevtexture->bind();... case XY_FRONT_TO_BACK: m_pnexttexture->bind(); } +StIntersectionPoint VS::CBrick +CutPlaneBrick(fP1:double*,fPlaneN:double*, out aintpoints:vector<stintersectionpoint>&): void struct StIntersectionPoint +nedgecode: int +acoords[3]: double +bused: bool Abbildung 4.8: Statisches UML-Klassendiagramm der Texturklassen der Anwendung Voxel-Sculpture. Oben-links ist der dargestellte Ausschnitt aus der gesammten Klassenhirarchie eingezeichnet.

67 KAPITEL 4. IMPLEMENTIERUNG 62 Quelltext 4.4 Binden der benachbarten Texturen an die Textureinheiten 1 // bind texture in this slice 2 glactivetexturearb(gl_texture0_arb); 3 glbindtexture(gl_texture_2d, m_atexturenames[k]); 4 5 // bind texture in the next or previous slice 6 if(m_enorder == VS::BACK_TO_FRONT && m_pnexttexture){ 7 m_pnexttexture->bindtexture(k); 8 } 9 else if(m_enorder == VS::FRONT_TO_BACK && m_pprevtexture){ 10 m_pprevtexture->bindtexture(k); 11 } Die Klasse CTexture3d Die Klasse CTexture3d ist eine Kapselung der dreidimensionalen Texturen, die OpenGL unterstützt (GL EXT texture3d). Die Einschränkung, die für zweidimensionale Texturen bezüglich ihren Dimensionen gilt, gibt es in OpenGL auch für dreidimensionale Texturen. Deshalb muß auch in diesem Fall die Textur aus Stücken zusammengesetzt werden. Die Klasse CTexture3d bedient sich dazu der Hilfsklasse CBrick. Objekte dieser Klasse repräsentieren einen Volumen innerhalb des Raums. CBrick ist von der externen Geometrieklasse ITWM::CBox abgeleitet, die die Geometrieberechnungen implementiert. Genauso wie in den 2d-Texturklassen werden auch in CTexture3d die Koordinaten der einzelnen Teiltexturen in drei Dimensionen bestimmt und gespeichert. Außerdem wird noch ein Vektor mit CBrick-Objekten erzeugt, die den einzelnen Teiltexturen entsprechen. Auch CTexture3d überschreibt die Methode Draw(double*) von CTexture, allerdings wird nur ein Vektor als Array übergeben, der dem Sichtvektor der Szene auf das Objekt entspricht. Der Algorithmus der dreidimensionalen Texturen arbeitet mit Scheiben durch das Volumen, die zum Sichtvektor ausgerichtet sind (siehe Kapitel 3.3.4). Der Sichtvektor wird also als Normalenvektor auf die Scheiben interpretiert. Die Klasse CBrick besitzt eine Methode CutPlaneBrick(...), die die Struktur StIntersectionPoint zurückgibt, die einen Schnittpunkt zwischen einer Kante des CBrick-Objekts und einer Scheibe repräsentiert. Das Verfahren lässt sich dabei grob in vier Schritte unterteilen, die bei jedem Renderzyklus durchgeführt werden müssen: Schnittpunkte zwischen der Schnittebene und dem Brick berechnen. Punkte die nahe beieinander liegen zusammenfassen. Punkte umsortieren damit sie ein konvexes Polygon bilden.

68 KAPITEL 4. IMPLEMENTIERUNG 63 Poygon mit Hilfe von OpenGL-Funktionen zeichnen. Der Algorithmus geht dabei wie in Quelltext 4.5 angedeutet vor. Er iteriert Quelltext 4.5 Pseudocode des Algorithmus zum Rendern von 3d-Texturen 1 foreach(brick in m_abricks){ 2 feffrad = CalculateBrickEffRad(); 3 4 foreach(slice in -feffrad to feffrad){ 5 aintersectionpoints = brick.cutplanebrick(slice); 6 7 aintersectionpoints.eliminatedoublepoints(); aintersectionpoints.sorttoconvexpolygon(); 11 GlStartPolygon(); 12 foreach(point in aintersectionpoints){ 13 glvertex(point); 14 } 15 GlEndPolygon(); 16 } 17 } dabei über alle CBrick-Objekte und berechnet den effektiven Radius des CBrick-Volumens bezüglich des Sichtvektors (Zeile 2). Dann wird das Volumen schrittweise vom negativen zum positiven effektiven Radius durchlaufen (Zeile 4). Dies sind die Abtastpunkte der Scheiben durch das Volumen. Danach werden die Schnittpunkte der Kanten des jeweiligen CBrick-Objekts mit der aktuellen Scheibe berechnet (Zeile 5). Punkte die zusammenfallen werden entfernt (Zeile 7). Die verbliebenen Punkte werden so umsortiert, daß sie ein geschlossenes, konvexes Polygon bilden (Zeile 9). Dann werden die Punkte durch OpenGL-Funktionen zu einem Polygon zusammengefasst und gezeichnet (Zeilen 11 15). Die Textur des Polygons wird dabei automatisch von OpenGL erzeugt und interpoliert. Viele der zur integration in das MAVI -Framework notwendigen Implementierungsarbeiten wurden hier nicht vorgestellt, da sie nicht zum Kernthema dieser Arbeit gehören. So entstanden zum Beispiel verschiedene Dialoge zum Bearbeiten von Transferfunktionen und zum Ausrichten von Clippingebenen (siehe Abbildung 4.1). Außerdem wurde noch ein Rot-grün-Rendermodus implementiert, der es erlaubt mit Hilfe einer Rot-grün-Brille einen Tiefeneffekt zu erzeugen [Bou99] (siehe Abbildung 4.10). Im nächsten Kapitel werden die Ergebnisse der Performancemessungen tabellarisch dargestellt und analysiert. Außerdem wird ein Ausblick und weitere Anregungen für die zukünftige Entwicklung von Voxel-Sculpture gegeben.

69 KAPITEL 4. IMPLEMENTIERUNG 64 Abbildung 4.9: Darstellung der Geometrie von 2d- (links) und 3d-Texturen (rechts) mit abgeschalteter Textureinheit. Um die Übersichtlichkeit zu verbessern wurde nur jede 20. Scheibe gezeichnet. Abbildung 4.10: Darstellung im Rot-grün-Rendermodus. Bei Benutzung einer speziellen Rot-grün-Brille eintsteht ein Tiefeneffekt.

70 Kapitel 5 Ergebnisse Um die in dieser Arbeit implementierten Verfahren qualitativ und quantitativ zu vergleichen, wurden eine Reihe von Messungen durchgeführt, die eine Aussage über die Leisungsfähigkeit im Bezug auf Speicherverbrauch und Geschwindigkeit zulassen sollen. Da es kein objektives Verfahren zur Messung der Bildqualität gibt, wird diese nicht berücksichtigt. Trotzdem gibt es natürlich Unterschiede in der Bildqualität, die aber schon in der vorherigen Kapiteln diskutiert wurden und hier nicht weiter beachtet werden sollen (siehe Kapitel 3). 5.1 Messungen Zur Messung der Leistung der entwickelten Renderverfahren wurde ein Zähler in Voxel-Sculpture integriert, der die Zeit zum Rendern von 30 Frames misst und so die Anzahl der Frames pro Sekunde (FPS frames per second) errechnet. Für die Messungen kamen folgende Hardwarekonfigurationen zum Einsatz: 65

71 KAPITEL 5. ERGEBNISSE 66 Rechner A 1 CPU Dual Intel Xeon 2,8GHz RAM 2,0GB Grafikkarte NVidia GeForce4 Ti 4200 Betriebssystem SuSE Linux 9.0 Rechner A 2 CPU Dual Intel Xeon 2,8GHz RAM 2,0GB Grafikkarte NVidia FX 5200 Betriebssystem SuSE Linux 9.0 Rechner A 3 CPU Dual Intel Xeon 2,8GHz RAM 2,0GB Grafikkarte NVidia Quadro 4750 XGL Betriebssystem SuSE Linux 9.0 Rechner B CPU AMD Duron 1,5GHz RAM 512MB Grafikkarte NVidia FX 5200 Betriebssystem Windows 2000 Bei den Rechnern A 1 A 3 handelt es sich um den gleichen Rechner mit unterschiedlichen Grafikkarten. Bei A 2 und B wurde die gleiche Grafikkarte in verschiedenen Rechnern unter Windows und Linux getestet. Die Messungen wurden mit den folgenden drei Bildern durchgeführt: Nickelschaum Ersteller S.Gondrom, IzfP Saarbrücken Abbildung A.5, Seite 80 Datenerfassung Computertomographie (XCT) Dimensionen (Pixel) 220 x 115 x 510 Dimensionen (mm) 22 x 11,5 x 51 Größe 12,1MB Skull Ersteller Siemens Medical Systems, Abbildung A.7, Seite 82 Forchheim Datenerfassung Rotations-Röntgenscan Dimensionen (Pixel) 256 x 256 x 256 Dimensionen (mm) unbekannt Größe 16MB Feuerbeton Ersteller S. Gondrom, IzfP Saarbrücken Abbildung A.1, Seite 74 Prof. Schlegel, TU Freiburg Datenerfassung Computertomographie (XCT) Dimensionen (Pixel) 340 x 360 x 350 Dimensionen (mm) 158,8 x 168,1 x 163,5 Größe 40,9MB Um eine Abschätzung für den Aufwand der Geometrieberechnung zu erhalten, wurde die Framerate mit an- und abgeschalteter Textureinheit durch-

72 KAPITEL 5. ERGEBNISSE 67 geführt d-Textur-Verfahren (bilinear interpoliert) Die folgende Tabelle vergleicht der Bildgröße mit der Größe der zu generierenden Texturen. Ebenso ist die Anzahl der OpenGL-Texturen angegeben, die für die einzelnen Bilder erzeugt werden müssen. Dies lässt Schlüsse auf die Geschwindigkeit der Texturgenerierung zu, die jedoch unabhängig von der eigentlichen Zeichengeschwindigkeit ist und nicht einzeln gemessen wurde. Bild Bildgröße in MB Texturgröße in MB Anzahl Texturen Nickelschaum 12, Skull Feuerbeton 40, Bild FPS mit Textur FPS ohne Textur Rechner A 1 Nickelschaum 8,5 122,2 Skull 7,4 204,9 Feuerbeton <0,1 2,0 Rechner A 2 Nickelschaum 4,1 77,1 Skull 3,2 150 Feuerbeton <0,1 2,0 Rechner A 3 Nickelschaum 17,3 310,2 Skull 16,9 833 Feuerbeton 6,0 333,4 Rechner B Nickelschaum 4,0 87,0 Skull 3,2 160 Feuerbeton 1,2 71, d-Textur-Verfahren (trilinear interpoliert) Die folgende Tabelle vergleicht der Bildgröße mit der Größe der zu generierenden Texturen. Ebenso ist die Anzahl der OpenGL-Texturen angegeben, die für die einzelnen Bilder erzeugt werden müssen. Dies lässt Schlüsse auf die Geschwindigkeit der Texturgenerierung zu, die jedoch unabhängig von der eigentlichen Zeichengeschwindigkeit ist und nicht einzeln gemessen wurde. Hier wurden pro Scheibe durch eine Register-Combiner Konfiguration zwei Zwischenscheiben interpoliert. Dies entspricht einer Verdreifachung der einzelnen Bilddimensionen, ohne jedoch mehr Texturspeicher zu beanspruchen.

73 KAPITEL 5. ERGEBNISSE 68 Bild Bildgröße in MB Texturgröße in MB Anzahl Texturen Nickelschaum 12, Skull Feuerbeton 40, Bild FPS mit Textur FPS ohne Textur Rechner A 1 Nickelschaum 2,8 47,5 Skull 2,4 160,1 Feuerbeton <0,1 0,8 Rechner A 2 Nickelschaum 1,2 34,8 Skull 1,2 107,1 Feuerbeton <0,1 1,1 Rechner A 3 Nickelschaum 5,9 136,4 Skull 5,4 600 Feuerbeton 1,9 153,2 Rechner B Nickelschaum 1,1 32,1 Skull 1,4 112,7 Feuerbeton 0,3 24, d-Textur-Verfahren Die folgende Tabelle vergleicht der Bildgröße mit der Größe der zu generierenden Texturen. Ebenso ist die Anzahl der OpenGL-Texturen angegeben, die für die einzelnen Bilder erzeugt werden müssen. Dies lässt Schlüsse auf die Geschwindigkeit der Texturgenerierung zu, die jedoch unabhängig von der eigentlichen Zeichengeschwindigkeit ist und nicht einzeln gemessen wurde. Bild Bildgröße in MB Texturgröße in MB Anzahl Texturen Nickelschaum 12,1 12,1 200 Skull Feuerbeton 40,9 40,9 96

74 KAPITEL 5. ERGEBNISSE 69 Bild FPS mit Textur FPS ohne Textur Rechner A 1 Nickelschaum 6,3 141,2 Skull 4,3 216,7 Feuerbeton 1,8 132,3 Rechner A 2 Nickelschaum 4,7 88,2 Skull 3,3 166,7 Feuerbeton 1,5 76,9 Rechner A 3 Nickelschaum 7,3 157,8 Skull 5,9 750 Feuerbeton 2,3 214 Rechner B Nickelschaum 4,7 106,7 Skull 3,2 174,0 Feuerbeton 1,8 83,6 5.2 Bewertung Beim Vergleich der verschiedenen Renderverfahren fällt die hohe Anzahl der zu generierenden Texturen bei den 2d-Textur basierten Verfahren auf. So müssen zum Beispiel für die Visualisierung des Nickelschaums über Texturen generiert werden. Das hängt mit den Ausmaßen des Bildes und der damit verbundenen Unterteilung innerhalb der CTexture-Objekte zusammen. Im Vergleich dazu müssen, um Abbildung A.7 zu visualisieren nur 768 Texturen 1 generiert werden. Weiterhin ist die Größe des Speichers der durch die Texturen belegt wird dreimal größer, als der, der für das 3d-Textur-Verfahren benötigt wird. Bei den 3d-Texturen entspricht die Größe des Bildes genau den eigentlichen Bilddaten. Auch die Anzahl der zu erstellenden Teiltexturen ist bei 3d-Textur basierten Verfahren bedeutend kleiner. So müssen beim Feuerbeton nur 96 im Gegensatz zu Texturen generiert werden. Vergleicht man die Leistung des bilinear mit der des trilinear interpolierenden Verfahrens auf 2d-Texturen, lässt sich auf jedem getesteten Rechner ein Absinken der gemessenen FPS beim Rendern beobachten. Dies lässt sich durch den zusätzlichen Aufwand für die Interpolation von Zwischenscheiben erklären. Die beiden Werte die kleiner als 0,1 FPS sind (Rechner A 1 und A 2 ) sind fehlerhafte Messungen, die wahrscheinlich von einem Problem beim Öffnen neuer Fenstern im MAVI -Framework unter Linux stammen. Unter Windows (Rechner B) tritt kein so großer Leistungseinbruch auf. Auch unter Linux mit einer starken Grafikkarte (Rechner A 3 ) lässt sich ein solcher 1 Es muß pro Scheibe nur eine Textur generiert werden. 3 Stapel 256 Scheiben = 768 Texturen.

75 KAPITEL 5. ERGEBNISSE 70 Einbruch nicht beobachten. Indiz dafür ist eine ähnlich niedrige FPS-Rate, wenn die Texturdarstellung abgeschaltet ist. Unter Windows stieg in diesem Fall die Framerate wieder auf normale Werte. Ansonsten ist die Leistung bei gleicher Grafikkarte unter Windows fast identisch mit der unter Linux (Rechner A 2 und B). Hier lässt sich auch beobachten, daß sich bei abgeschalteter Texturdarstellung die Framerate nicht signifikant ändert, obwohl Rechner A 2 einen schnelleren Prozessor und mehr Speicher besitzt als Rechner B. Sogar bei Verwendung von 3d-Texturen mit vielen Teiltexturen (Bild: Nickelschaum), wo eine aufwendige Geometrieberechnung notwendig ist, ist kein großer Unterschied erkennbar. Daraus lässt sich folgern, daß die Geometrieberechnung nur eine untergeordnete Rolle im Leistungsvermögen der getesteten Verfahren spielt. Der wichtigste Faktor ist die Grafikkarte, wobei die Unterschiede im 3d- Textur-Verfahren weniger groß sind als bei den 2d-Textur-Verfahren. So beträgt der Unterschied zwischen schlechtester (Rechner: A 2 ) und bester Grafikkarte (Rechner: A 3 ) im 3d-Textur-Verfahren 55% (7.3 FPS zu 4,7 FPS) und im 2d-Textur-Verfahren mit bilinearer Interpolation 390% (5,9 FPS zu 1,2 FPS). Die Leistungsfähigkeit der Verfahren hängt also essentiell von der Leistungsfähigkeit der Grafikkarte ab. Prozessor, Speicherausstattung und Betriebssystem spielen nur eine untergeordnete Rolle. Nur die Dauer der Texturgenerierung aus den Rohdaten, also die Extraktion der Scheiben und das Kopieren der Daten werden davon beeinflusst. Diese Funktionen wurden aber nicht gemessen, da sie nicht direkt mit der Laufzeit der Visualisierungsverfahren zusammenhängen. 5.3 Ausblick In zukünftigen Versionen von Voxel-Sculpture könnten weitere Renderverfahren integriert werden, ohne am Design grundlegende Änderungen vornehmen zu müssen. Es ist denkbar, anstatt einer volumen- eine polygonbasierte Oberflächenvisualisierung (siehe Kapitel 3.4.1) hinzuzufügen, indem man eine neue Renderklasse implementiert. Die bestehenden Verfahren könnten durch verschiedene OpenGL-Erweiterungen, wie zum Beispiel Pixel- und Vertex-Shader, verbessert werden. Pixel- Shader finden Verwendung, um die Glanzlicht-Beleuchtung auf Texturen zu ermöglichen, Vertex-Shader verbessern die Leistung der Geometrieberechnungen. Um die Geschwindigkeit und die Handhabung von großen Bildern zu verbes-

76 KAPITEL 5. ERGEBNISSE 71 sern, ist es möglich, bei Interaktionen von seiten des Anwenders (drehen des Bildes, Zoom), das eigentliche, hochauflösende Bild durch ein kleineres Bild mit schlechterer Qualität auszutauschen. Wenn der Anwender seine Interaktion beendet hat, wird das Bild in guter Qualität wieder angezeigt. Da sich das reduzierte Bild schneller rendern lässt, steigt die Leistung bei Interaktivität zu lasten der Bildqualität (siehe auch Kapitel 2.1). Ein ähnlicher Ansatz für Verbesserungen ist das Rendern in einen Hintergrundpuffer. Man spricht dann vom so genanntem off-screen rendering. Dies hat mehrere Vorteile: Zum einen sind OpenGL-Fenster anfällig für Clipping- Probleme. Das heißt, wenn ein anderes Fenster das OpenGL-Fenster überlagert, bricht die Leistung ein. Mit dem off-screen rendering tritt dieser Effekt nicht mehr auf. Zum anderen lässt sich so ein progressiver Bildaufbau einfach realisieren: Das komplette Framebuffer-Bild wird zunächst in schlechter Qualität vom Hintergrundpuffer in den Framebuffer kopiert und progressiv verbessert. Dadurch verbessert sich auch die Interaktivität, ohne weiteren Speicher zu verbrauchen, wie es bei dem erstgenannten Verfahren notwendig ist. Die Realisierung einer voxelbasierten Oberflächenvisualisierung mit Hilfe des OpenGL stencil-buffer ist eine Alternative zum Marching-Cubes-Verfahren. Dabei wird jede zu rendernde Scheibe einzeln gerendert. Dann werden Bildverarbeitungsoperationen auf das Bild angewendet, um eine Maske zu erstellen. Diese Maske hat die Form der Oberfläche, die dargestellt werden soll. Die Maske wird wieder eingelesen und für den stencil-test verwendet. Dieser bestimmt, ob ein Voxel gezeichnet werden soll. Dieses Verfahren wird Multipass-Rendering genannt, da der gerenderte Framebuffer wieder eingelesen wird und als Grundlage eines zweiten Durchlaufs dient. Eine interessante Möglichkeit Voxel-Sculpture weiter zu entwickeln ist die Kombination von Volumen- mit Oberflächenvisualisierung (semi-transparent isosurface rendering). Dazu wird das eigentliche Objekt mit einer geeigneten Transferfunktion, im ersten Renderdurchlauf, opak gerendert. Im zweiten Renderdurchlauf wird dann die Umgebung des Objekts halbtransparent hinzugefügt. Damit lassen sich sehr reizvolle Effekte erzielen. So lässt sich durch dieses Verfahren ein Objekt, wie zum Beispiel eine Pore oder ein Knochen in seinem Gesamtkontext im Bild darstellen. Es gibt noch viele Ansätze, Voxel-Sculpture zu verbessern. Interessant hierbei sind die neuen Techniken, wie der OpenGL shading-lanuage und die Unterstützung von nicht-pot-texturen, die in die im Herbst 2004 verabschiedete OpenGL2.0 -Spezifikation eingeflossen sind. Es wird allerdings noch einige Monate dauern, bis die Hersteller den neuen Standard vollständig in ihre Treiber integriert haben.

77 KAPITEL 5. ERGEBNISSE 72 Diese Arbeit hat gezeigt, daß eine schnelle Volumenvisualisierung auf normaler Grafikhardware möglich ist. Selbst Datensätze deren Größe die des Grafikkartenspeichers um ein Vielfaches übersteigen, lassen sich noch effizient visualisieren. Trotzdem bleibt der Speicherverbrauch problematisch, da die normalen Grafikkarten nicht für solche Datenmengen entwickelt wurden. Dieses Problem wird sich aber in Zukunft eher relativieren, da der AGP-Port schnellen Bussystemen wie zum Beispiel PCI-Express weicht und sich so der Transfer der Texturdaten zur Grafikkarte beschleunigen wird. NVidia bietet seit der neusten Grafikkartengeneration ein System an, um mehrere Grafikkarten in einem Rechner parallel zu nutzen, was im Falle der Volumenvisualisierung großer Datenmengen zu einer erheblichen Beschleunigung führen könnte. Mit Sicherheit ist die Tendenz zu immer schnelleren Grafikkarten gerechtfertigt, da direkte Volumenvisualisierungsverfahren stark von der Leistungsfähigkeit der Grafikhardware abhängen.

78 Anhang A Beispiele A.1 Feuerbeton Die Korundeinschlüsse im Feuerbeton können durch einfache Schwellwertbildung segmentiert werden. Anschließende Trennung mit Hilfe morphologischer Transformationen und eine Objektvermessung erlaubt die Bestimmung verschiedenster Charakteristika der Einschlüsse [ONS02, ONS03]. Um die Erstellung einer Transferfunktion zu erleichtern, wurden die Einschlüsse in Größenklassen eingeteilt und entsprechend gelabelt. Nach einer Grauwertspreizung sieht das Histogramm wie in Abbildung A.2(re.) aus. Die Visualisierungen zu diesen Transferfunktionen sind in Abbildung A.1 dargestellt. 73

79 ANHANG A. BEISPIELE 74 Abbildung A.1: Feuerbeton. Rekonstruierte tomographische Aufnahme. Größe: 340x360x350. Auflösung: 46,7 µm. Oben: Orginalaufnahme. Unten: Korundeinschlüsse in fünf Größenklassen unterteilt (rot < grün < blau < braun < gelb) im Bereich bis 0,70mm 3

80 ANHANG A. BEISPIELE 75 Abbildung A.2: Transferfunktion für das Orginalbild (oben) und für die Einfärbung in Größenklassen (unten). Die verschiedenen Farben stehen jeweils für den entsprechenden Farbkanal, die gelbe Funktion beschreibt den Alphakanal. Im Hintergrund sieht man die fünf Spitzen des Histogramms.

81 ANHANG A. BEISPIELE 76 A.2 Faserfilz Durch eine Tophat-Transformation können die dünnen von den dicken Fasern getrennt werden. So können zum Beispiel Faserlängendichte oder Richtungsverteilung für beide Phasen getrennt bestimmt werden. Nachdem die Phasen gelabelt und ihre Grauwerte gespreizt wurden, werden die verschieden großen Fasern durch die in Abbildung A.4(re.) dargestellten Transferfunktionen visualisiert (siehe Abbildung A.3).

82 ANHANG A. BEISPIELE 77 Abbildung A.3: Faserfilz, rekonstruierte tomographische Aufnahme (Phasenkontrastmethode) Größe: 256x256x256. Auflösung: 6,65µm. Oben: Orginalaufnahme. Unten: dünne Fasern blau und dicke Fasern rot eingefärbt.

83 ANHANG A. BEISPIELE 78 Abbildung A.4: Faserfilz. Transferfunktionen für das Orginalbild (oben) und für die Einfärbung der Größenklassen (unten). Die verschiedenen Farben stehen jeweils für den entsprechenden Farbkanal, die gelbe Funktion beschreibt den Alphakanal. Im Hintergrund sieht man die beiden Spitzen des Histogramms.

84 ANHANG A. BEISPIELE 79 A.3 Offenporiger Nickelschaum Durch eine Wasserscheidentransformation lassen sich die einzelnen Zellen des offenporigen Nickelschaums rekonstruieren. Danach wurden die Zellen in fünf Größenklassen eingeteilt und gelabelt. Nach einer Grauwertspreizung lässt sich leicht die in Abbildung A.6(unten) dargestellte Transferfunktion erstellen. Dies führt zu der in Abbildung A.5 dargestellten Visualisierung.

85 ANHANG A. BEISPIELE 80 Abbildung A.5: Offenporiger Nickelschaum. Rekonstruierte tomographische Aufnahme. Größe: 220x115x510. Auflösung: 10µm. Oben: Orginalaufnahme. Unten: Rekonstruierte Zellen in 5 Größenklassen im Bereich bis 0,11mm 3.

86 ANHANG A. BEISPIELE 81 Abbildung A.6: Transferfunktionen für das Orginalbild (oben) und für die Einfärbung der Größenklassen (unten). Die verschiedenen Farben stehen jeweils für den entsprechenden Farbkanal, die gelbe Funktion beschreibt den Alphakanal. Im Hintergrund sieht man die fünf Spitzen des Histogramms.

87 ANHANG A. BEISPIELE 82 A.4 Menschlicher Schädel Abbildung A.7: Rotations-Computertomographie-Aufnahme eines menschlichen Schädels im 3d-Textur Rendermodus.