Medizinische Visualisierung - userpages.uni-koblenz.decg/ws1213/medvis/vorlesung/... · • erweiterte Programmierbarkeit für VS+FS (Flusskontrolle usw.) • Einführung von Hochsprachen

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)


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


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


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


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


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


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


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


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

http://www.khronos.org/files/opengl-quick-reference-card.pdf

http://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

12

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

13

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

14

• Texturen

• verschiedene Typen und Dimensionen

• üblich für sehr große Datenmengen

Volumenvisualisierung 1

Einführung, Indirektes Volumenrendering


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


®

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


®

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


®

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.


®

• 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


®

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


®

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


®

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


®

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


®

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


®

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


®

• 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


®

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


®

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“


®

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


®

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


®

• 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


®

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


®

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

Documents

Medizinische Visualisierung - userpages.uni-koblenz.decg/ws1213/medvis/vorlesung/... · • erweiterte Programmierbarkeit für VS+FS (Flusskontrolle usw.) • Einführung von Hochsprachen