Vorlesung 605.12.2012, Universität Koblenz-Landau
Dr. Matthias RaspeSOVAmed GmbH
Medizinische Visualisierung
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
Agenda
• Grundlagen GPU-Programmierung• Evolution • Moderne OpenGL-Programmierung• Shaderprogrammierung (GLSL)
• Visualisierung 1• Volumenrendering-Verfahren im Überblick• Visualisierungspipeline im Detail• Indirektes Volumenrendering• Transferfunktionen
2
Wiederholung/Grundlagen
GPU-Programmierung (Dank an Niklas Henrich)
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
Wiederholung OpenGL
• Open Graphics Library
• Low-Level Bibliothek zur Darstellung von 3D Objekten
• Herstellerunabhängiges System
• Konsequentes „state-machine“-Konzept
• Aktuelle Version: OpenGL 4.3
• Bisher: fixed-function pipeline• fest definierte Einheiten• zum Teil parametrisierbar• Parallelisierung durch fehlende
Abhängigkeiten möglich
4
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
Moderne OpenGL Pipeline
• zunehmende Flexibilität und Effekte durch Programmierbarkeit
• nicht nur parametrisierbar, sondern programmierbar• Mini-Programme (“Shader”) laufen auf Prozessoreinheiten der Grafikhardware• je nach Typ und Sprache/Sprachversion unterschiedliche Befehle und Möglichkeiten
• zahlreiche Erweiterungen, wesentlich für MedVis sind
• Fragmentshader: z.T. historisch bedingt, viel Texturoperationen• Vertex- und Geometryshader: je nach Anwendung (Glyphen, Geometrien etc.)
5
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
Shadersprachen
• Damals...
• reine Maschinensprache• fehlende Modularisierung
• Heute:
• zahlreiche Hochsprachenzur Programmierung
• Compiler übersetzt in Maschinensprache
• Übliche Sprachen:• Cg (Nvidia)• GLSL (OpenGL)• HLSL (DirectX)
• für GPGPU-Anwendungen: CUDA, Brook, Sh, OpenCL
6
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
Architektur-Unterschiede Cg/GLSL
7
Cg Translator
Application
Cg source code
Cg Translator
OpenGL or
DirectX Driver
Assemblerassembly
program
OpenGL or DirectX API
Assembly source code
(source or binary)
Graphics hardware
executable code
Provided by application
developer
Provided by Nvidia
Provided by graphics
hardware vendor
ApplicationApplication
Shader source code
OpenGL Driver
LinkerProgram
Object
OpenGL API
Shader source code
Graphics hardware
executable code
Provided by application
developer
Provided by graphics
hardware vendor
CompilerShader
Object
compiled code
• Cg• kompatibel zu OpenGL und DirectX • externer Compiler → manuelle Optimierung
• GLSL• OpenGL/OpenCL-kompatibel• Compiler in OpenGL-Treiber integriert
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
Historische Entwicklung
• Erste Generation (ca. 2001, DX 8.0/SM 1.1)• programmierbare Vertexshader (VS)• sehr eingeschränkte Fragmentshader (FS)
• Zweite Generation (ca. 2002, DX 9.0/SM 2.x)• erweiterte Programmierbarkeit für VS+FS (Flusskontrolle usw.)• Einführung von Hochsprachen (Cg, HLSL, später GLSL)
• Dritte Generation (ca. 2004, DX 9.0c/SM 3.0)• mehr Erweiterungen (z.B. Vertex-Texturen, höhere Grenzen)
• Vierte Generation (ca. 2007, DX 10.0/SM 4.0)• Einführung der Geometry-Shader, Konzept der Unified Shader• Erweiterungen (Integertexturen, bitweise Operationen usw.)
8
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
Vertexprogramm
• Arbeitet nur auf einem Eckpunkt• keine Information über Topologie (andere Eckpunkte)• keine Punkte erzeugen oder löschen• wahlfreier Zugriff auf Texturspeicher
• Typische Aufgaben:• Eckpunkttransformationen
(Welt- in Kamerakoordinaten,kanon. Volumen)
• Normalentransformation• Beleuchtung (in Kamera-
Koordinaten)
• Nicht in Vertexprogramm:• Clipping, persp. Division
9
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
Fragmentprogramm
• Arbeitet am Ende der Pipeline• für jedes zu zeichnende Fragment
ausgeführt• arbeitet nur auf aktuellem Fragment
im Framebuffer• wahlfreier Zugriff auf Texturspeicher
• Typische Aufgaben:• Farbe des Pixels berechnen• Texturzugriffe und -operationen• Effekte wie Nebel integrieren
• Nicht in Fragmentprogramm:• Tiefen-/Stenciltest• Alpha-Blending
10
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
OpenGL Shading Language (GLSL)
• Teil des OpenGL 2.0 Standards
• Syntax orientiert sich an C / C++
• Funktionen• Einfache Datentypen (float, int, bool) • Strukturen• Arrays• Bedingungen• Schleifen• Aber: keine Zeiger
• Beliebige Länge der Shader-Programme
• detaillierte Informationen:
• “Orange Book”• www.khronos.org/files/opengl-quick-reference-card.pdf
11
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
Grundlegender Ablauf
(1) Shader Objekt erzeugen
(2) Sourcecode laden
(3) Shader compilieren
(4) Shader Program Objekt erzeugen
(5) Shader Program mit Shadern belegen
(6) Program linken
(7) Program benutzen
(8) Programm(e) ausführen
(9) Zurück zur OpenGL Fixed-Function Pipeline
12
shader = glCreateShader(TYPE);
glShaderSource(shader,&sourcePtr,0);
glCompileShader(shader);
program = glCreateProgram();
glAttachShader(program,vertexShader);
glLinkProgram(program);
glUseProgram(program);
renderObjects();
glUseProgram(0);
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
Minimal GLSL-Shader
• Vertexprogramm
• Fragmentprogramm
13
void main() {gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;// alternativ: gl_Position = ftransform();gl_FrontColor = gl_Color;
}
void main() {gl_FragColor = gl_Color;
}
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
Kommunikation mit Shadern
• Verschiedene Arten des Datenaustauschs möglich:
• uniform-Variablen:
• innerhalb von Shadern nur Lesezugriff• Wert konstant für Grafikprimitiv• viele vordefiniert (z.B. gl_ModelViewMatrix, gl_LightSource[0])
• attribute-Variablen:
• benutzerdefinierte Attribute pro Vertex• vordefiniert (z.B. Farbe, Normale usw.)
• varying-Variablen:
• Kommunikation zwischen den Shadern• automatische Interpolation von VS -> FS
14
• Texturen
• verschiedene Typen und Dimensionen
• üblich für sehr große Datenmengen
Volumenvisualisierung 1
Einführung, Indirektes Volumenrendering
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
Volumenvisualisierung
• Kategorien von Volumenrendering-Verfahren
16
Volume Rendering
Indirect Direct
Software Hardware
Image-space Object-space Other
Fourier
Shear-Warp
Image-space Object-space
Ray casting Texture-based
view-parallel volume-parallel
Ray casting Splatting
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
®
Visualisierungspipeline
17
Transferfunktion
CompositingIntegration zu
Endbild
Darstellung
Akquisitionder Daten
Bildgebende Verfahren (z.B. CT, MR), Simulationen
Applikation/Hardware
Externe Systeme
Sampling
Anzahl/Abstand der Slices oder Samplesentlang Sehstrahl
FilterungInterpolation der
vorhandenen Daten für Samples
KlassifikationZuweisung von
Farbe und Opazität/Transparenz
ShadingAuswertung von Beleuchtungs-
modellen
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
®
Darstellung von Volumendaten
• Eine Form der Visualisierung ist die Hervorhebung gleicher Werte mit geometrischen Primitiven• Isolinien (auch „Höhenlinien“,
Konturlinien)• Isoflächen (Konturflächen)
• In dieser Form gehören sie zu den indirekten Visualisierungsmethoden
• direkte Methoden → später…
18
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
®
Darstellung von Volumendaten
• Diese können mit weiteren Attributen erweitert dargestellt werden, z.B.• Isolinien für bestimmte Höhen eines Geländes• Farbe/Sättigung für
Vorzeichen/Betrag des Gradienten• Steile Anstiege → intensives Rot• Flache Gefälle → leichtes Blau
• Isolinien und vor allem Iso-flächen spielen in vielen Anwendungsgebieten eine sehr große Rolle
19
106 CHAPTER 5. NON-PHOTOREALISTIC VOLUME RENDERING
concept of deferred computations is that it reduces their complexity from being proportionalto object space, e.g., the number of voxels in a volume, to the complexity of image space, i.e.,the number of pixels in the final output image. Naturally, these computations are not limitedto shading equations per se, but can also include the derivation of additional information thatis only needed for visible pixels and may be required as input for shading, such as di�erentialsurface properties.
In this section, we describe deferred shading computations for rendering isosurfaces ofvolumetric data. The computations that are deferred to image space are not limited to actualshading, but also include the derivation of di�erential implicit surface properties such as thegradient (first order partial derivatives), the Hessian matrix (second order partial derivatives),and principal curvature information.
Figure 5.5 illustrates a pipeline for deferred shading of isosurfaces of volume data, andfigure 5.6 shows example images corresponding to the output of specific image space renderingpasses. The input to the pipeline is a single floating point image storing ray-surface intersec-tion positions of the viewing rays and the isosurface. This image is obtained via either slicingthe volume, or first hit ray casting, as outlined above and illustrated in figure 5.4.
From this intersection position image, di�erential isosurface properties such as the gradientand additional partial derivatives such as the Hessian matrix can be computed first. This
Figure 5.6: Example image space rendering passes of deferred isosurface shading. Surfaceproperties such as (a) the gradient (here color-coded in RGB), (b) principal curvature magni-tudes (here: �1), and (c) principal curvature directions can be reconstructed. These propertiescan be used in shading passes, e.g., (d) Blinn-Phong shading, (e) color coding of curvaturemeasures (here:
��2
1 + �22 [70]), and (f) advection of flow along principal curvature directions.
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
®
• Beim bisherigen (Oberflächen-)Rendering waren die Normalen gegeben oder konnten berechnet werden
• Für Volumendaten (genauer: 3D-Skalarfelder) gibt es jedoch keine Normalen im eigentlichen Sinn...
• Guter Ersatz: der Gradientenvektor
• entspricht der Normale auf Isofläche• analog zu Gradient in Bildverarbeitung (vgl. Kantendetektion)
• Der Gradientenvektor ist die erste Ableitung eines 3D-Skalarfeldes , d.h
• Wird oft durch Zentraldifferenzen berechnet, z.B. in x-Richtung:
Exkurs: Gradient
20
�( f ) f (x, y, z)
�( f ) = ( fx, fy, fz) =�
� f�x
,� f�y
,� f�z
⇥||⇥( f )|| =
�fx
2 + fy2 + fz
2
fx(x, y, z) = f (x + 1, y, z)� f (x� 1, y, z) mit x, y, z ⇥ N
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
®
Marching Cubes
• Wie können Isoflächen automatisch aus Volumendaten generiert werden?
• Marching Cubes (Lorensen et al., 1987)• Übliches Verfahren zur Konstruktion von Isoflächen aus 3D-Skalarfeldern
(d.h. Volumen)• Auch allgemein definiert auf anderen Daten• Bei höherdimensionalen Daten (Vektorfelder etc.) wird eine entsprechende
Ordnungsrelation benötigt, z.B. • Betrag des Vektors• Gradient (auch bei Skalaren)
• Zunächst im 2D: Marching Squares
21
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
®
Marching Squares
• Ausgangsdaten: Skalare an Gitterpunkten
• Annahmen:• Isowert wird höchstens einmal zwischen zwei Gitterpunkten angenommen →
ausreichend hohe Auflösung• Werte (und damit die Konturen) verlaufen linear
• Vorgehen:• Bestimme für jeden Gitterpunkt, ob er innerhalb/außerhalb liegt → Bitcode• Ermittle beteiligte Kante aus unterschiedlichen Bitcodes• Bestimme Punkt auf dieser Kante durch lineare Interpolation• Verbindung dieser Punkte zu Linien
22
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
®
Marching Squares
• Beispiel Graustufenbild, Isolinie für C = 3• Skalarfeld der Dimension 2• Gitterpunkte = Pixelmitte
• Ergebnis ähnlich zu Kanten-detektion, aber: Kante ≠ Isolinie
0
2
2
1
2
1
2 1
2
4
46
6
4
46
6 4
4 3
5
6
52
4
6
42
4 4
4
5
2
2
1
2
: ≤ C („innerhalb“) : > C („außerhalb“)
23
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
®
Marching Squares
• Betrachtet man sich eine Gitterzelle genauer, gibt es nur eine begrenzte Zahl von Kombinationen, wie die Linie grundsätzlich verlaufen kann
• Insgesamt 24 = 16 Möglichkeiten:
• Anzahl läßt sich deutlich reduzieren:
• Durch Komplementbildung → 8 Möglichkeiten• Durch Rotation und Symmetrie → 4 Möglichkeiten
• Es gibt aber dennoch eine Mehrdeutigkeit…
24
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
®
Marching Cubes
• Die Erweiterung des Marching Squares Ansatzes führt zu Marching Cubes• Prinzipiell gleicher Ablauf• Statt (Iso-)Linien werden Isoflächen erzeugt
• Ausgangsdaten sind hier wieder Skalare in einer regulären Gitterstruktur (Voxelzelle)
25
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
®
Marching Cubes
• Die Anzahl der möglichen Kombinationen beträgt in einer Voxelzelle insgesamt 28 = 256
• Durch Anwendung der gleichen Prinzipien (Komplement, Symmetrie) lassen sich die Fälle auf die folgenden 15 Kombinationen reduzieren:
• Auch hier gibt es Mehrdeutig-keiten, die sich jedoch teilweisenicht auflösen lassen→ Löcher in Isofläche…
• Mögliche Lösungen• Zusätzliche Komplemente• Gradienten berücksichtigen• Alternative Verfahren (z.B. Marching Tetraeder, Shirley et al, 1990)
Loch in Isofläche
26
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
®
• Allgemeines Vorgehen bei Marching Cubes:• Betrachtung von Würfeln aus je 4 Voxeln der Schicht k und k+1• Bestimmung der Codes für Eckpunkte (innerhalb/außerhalb)• Ermittlung der beteiligten Kanten• Ermittlung von Punkten auf diesen Kanten durch lineare Interpolation• Verbindung der Punkte zu Dreiecken
• Zusätzlich:• Zusammenfassung der Dreiecke/Dreiecksnetze zu möglichst
effizienten Meshes (Triangle Strips usw.)• Bestimmung von Gradienten, z.B. für Shading
• Speicherung der Vektoren in Textur (RGB+A)• exakter, aber teurer: on-the-fly Berechnung
Marching Cubes
27
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
®
Zusammenfassung MC
• Marching Cubes als Methode zur Generierung von Isoflächen aus einem Voxelgitter
• Mehrdeutigkeiten, begrenzte Anzahl von Kombinationen→ Optimierung möglich:
• Bitcodes • Lookup-Tabelle
• Benötigt jedoch hohe Auflösung des Gitternetzes für ausreichende Qualität
• Problematisch wegen erhöhterDatenmenge und Laufzeit
• Ideal: adaptive Verfahren
28
Volumenvisualisierung 1
Transferfunktionen
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
®
Darstellung der Daten
• Darstellung der skalaren Werte in Farben üblicherweise mit Hilfe von Farbtabellen („color maps“)• Realisierung als einfache Lookup-Tabelle
• Direkt in Hardware verfügbar:• glColorTableEXT → als Palette in fixed-function-pipeline
• glTexImage1D → als Textur, z.B. für eigene Shader
30
9.789.659.228.798.68………
3.012.321.92
11.2310.119.789.659.228.798.68………
3.012.321.921.010.78
Werte werden „geclamped“
Werte werden „geclamped“
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
®
Transferfunktionen
• Transferfunktionen sind eine Abbildung von der Menge der Attribute in die Menge der visuellen Eigenschaften
• Farbtabelle = diskretisierte Form der allgemeineren Transferfunktion
• Bei der Abbildung muss einem Eingabedatum eindeutig ein Wert zugeordnet werden können…
• Typische Abbildungen sind:• Skalare in Grauwerte• Skalare in RGB-Farben• Richtungsvektoren in RGB-Farben
31
f : R ! R
f : R ! R3
f : R3! R
3
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
®
Transferfunktionen
• Genauer:• Die Transferfunktion (TF) ist aus mathematischer Sicht eine Funktion
und keine Relation• Je nach Dimension der Wertemenge können aber mehrere
Ausgabewerte einem Eingabewert zugeordnet sein
• Beispiele:
Kontinuierliche TF
Skalar
Hel
ligke
it
Diskrete, abschnittsweisedefinierte TF
Kontinuierliche TFfür RGB-Kanäle
Keine gültige TF,da Relation
32
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
®
• In der Praxis ist die Bestimmung einer “guten” Transferfunktion aufwendig
• eindimensionale TFs ermöglichen nur einfache Abbildungen
• Idee: zusätzliche Informationen wie Gradienten, Abstände etc. mit einbeziehen
• Abgrenzung sonst gleicher Strukturen möglich
• aber: TF wird dadurch mehrdimensional • große Datenmengen
• Kontrolle/User-Interface?
Transferfunktionen
Cascada: 1D-TF
Cascada: 2D-TF33
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
®
• Es existieren sehr viele unterschiedliche Ansätze, jedoch keine universelle Lösung• „High-Level User Interfaces for Transfer Function Design with Semantics“, Rezk-
Salama et al., 2006• „The Transfer Function Bake-Off“, Pfister et al., 2001
• Med. Workstations bieten oft Kombination aus TF-Bibliothek und manueller Steuerung (1D-TF) an
Transferfunktionen
34
Transfer Functions
3D Visualization and Image Processing 30
Each transfer function has been designed for a specific purpose, e.g. to
enhance vessels or to reveal the kidneys. Accordingly, the transfer functions
might have a lesser effect on a different dataset.
Figure 3.9: Transfer
Functions in syngo
Siemens Medical Inc.
MedVis - Vorlesung 6 05.12.2012 Dr. Matthias Raspe, SOVAmed GmbH
®
Zusammenfassung TF
• Transferfunktionen weisen Volumendaten optische Eigenschaften zu, zum Beispiel:• Dichtewert → Opazität• Windrichtung → RGB-Wert
• verschiedene Dimensionen möglich, jedoch zunehmend komplexer
• kein universelles Verfahren• Unterscheidung nach Automatisierung• stark abhängig von Modalität (CT: einfach, MR: schwierig)
• aktives Forschungsgebiet
35
Top Related