Medizinische Visualisierung

Vorlesung 6

05.12.2012, Universität Koblenz-Landau

Dr. Matthias Raspe SOVAmed GmbH

Medizinische Visualisierung

Agenda

• Grundlagen GPU-Programmierung

• Evolution

• Moderne OpenGL-Programmierung

• Shaderprogrammierung (GLSL)

• Visualisierung 1

• Volumenrendering-Verfahren im Überblick

• Visualisierungspipeline im Detail

• Indirektes Volumenrendering

• Transferfunktionen

Wiederholung/Grundlagen

GPU-Programmierung (Dank an Niklas Henrich)

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

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.)

Shadersprachen

• Damals...

• reine Maschinensprache

• fehlende Modularisierung

• Heute:

• zahlreiche Hochsprachen zur Programmierung

• Compiler übersetzt in Maschinensprache

• Übliche Sprachen:

• Cg (Nvidia)

• GLSL (OpenGL)

• HLSL (DirectX)

• für GPGPU-Anwendungen:

CUDA, Brook, Sh, OpenCL

Architektur-Unterschiede Cg/GLSL

Cg Translator

Application

Cg source code

Cg Translator

OpenGL or DirectX Driver

Assembler assembly

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

Application Application

Shader source code

OpenGL Driver

Linker Program

Object

OpenGL API

Shader source code

Graphics hardware

executable code

Provided by application developer

Provided by graphics hardware vendor

Compiler Shader

Object compiled code

• Cg

• kompatibel zu OpenGL und DirectX

• externer Compiler → manuelle Optimierung

• GLSL

• OpenGL/OpenCL-kompatibel

• Compiler in OpenGL-Treiber integriert

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.)

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

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

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

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

shader = glCreateShader(TYPE);

glShaderSource(shader,&sourcePtr,0);

glCompileShader(shader);

program = glCreateProgram();

glAttachShader(program, vertexShader);

glLinkProgram(program);

glUseProgram(program);

renderObjects();

glUseProgram(0);

Minimal GLSL-Shader

• Vertexprogramm

• Fragmentprogramm

void main() {

gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;

// alternativ: gl_Position = ftransform();

gl_FrontColor = gl_Color;

}

void main()

{ gl_FragColor = gl_Color;

}

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

• Texturen

• verschiedene Typen und Dimensionen

• üblich für sehr große Datenmengen

Volumenvisualisierung 1

Einführung, Indirektes Volumenrendering

Volumenvisualisierung

• Kategorien von Volumenrendering-Verfahren

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

®

Visualisierungspipeline

Transferfunktion

Compositing

Integration zu Endbild

Darstellung Akquisition

der Daten

Bildgebende Verfahren (z.B. CT, MR), Simulationen

Applikation/Hardware Externe Systeme

Sampling

Anzahl/Abstand der Slices oder Samples

entlang Sehstrahl

Filterung

Interpolation der vorhandenen Daten für Samples

Klassifikation

Zuweisung von Farbe und Opazität/

Transparenz

Shading

Auswertung von Beleuchtungs-

modellen

®

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…

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 proportional to 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 limited to shading equations per se, but can also include the derivation of additional information that is only needed for visible pixels and may be required as input for shading, such as differential surface properties.

In this section, we describe deferred shading computations for rendering isosurfaces of volumetric data. The computations that are deferred to image space are not limited to actual shading, but also include the derivation of differential implicit surface properties such as the gradient (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, and figure 5.6 shows example images corresponding to the output of specific image space rendering passes. 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 slicing the volume, or first hit ray casting, as outlined above and illustrated in figure 5.4.

From this intersection position image, differential isosurface properties such as the gradient and 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. Surface properties such as (a) the gradient (here color-coded in RGB), (b) principal curvature magni- tudes (here: ), and (c) principal curvature directions can be reconstructed. These properties

®

• 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

(

) f ( _x , y , z )

( _f ) = ( _f

, f

, f

) = ^f

x , f

y , f z

⇥

|| ⇥ ( f ) || = f

+ f

+ f

f

( _{x, y, z} ) = _f ( _x + _{1, y, z} ) _f ( _{x 1, y, z} ) _{mit x, y, z} ⇥ ^N

®

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

®

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

®

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 4 6

6

4

4 6

6 4

4 3

5 6 5 2

4

6

4 2

4 4

4 5 2 2 1 2

: ≤ C („innerhalb“) : > C („außerhalb“)

®

Marching Squares

• Betrachtet man sich eine Gitterzelle genauer, gibt es nur eine begrenzte Zahl von Kombinationen, wie die Linie grundsätzlich verlaufen kann

• Insgesamt 2⁴ = 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…

®

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)

®

Marching Cubes

• Die Anzahl der möglichen Kombinationen beträgt in einer Voxelzelle insgesamt 2⁸

= 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 teilweise nicht 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

®

• 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

®

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öhter Datenmenge und Laufzeit

• Ideal: adaptive Verfahren

Volumenvisualisierung 1

Transferfunktionen

®

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

9.789.65 9.228.79 8.68…

…… 3.012.32 1.92

11.23 10.11 9.78 9.65 9.22 8.79 8.68

…

…

… 3.01 2.32 1.92 1.01 0.78

Werte werden „geclamped“

Werte werden „geclamped“

®

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

f : R → R

f : R → R

f : R

→ R

®

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

Helligkeit

Diskrete, abschnittsweise

definierte TF Kontinuierliche TF

für RGB-Kanäle Keine gültige TF,

da Relation

®

• 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

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

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.

®

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