ProjektpraktikumMedizinische Visualisierung

Einführung

Projektleitung: Matthias Biedermann

Projektassistenz: Andreas Langs

Projektteilnehmer: Marcus Berlage

Martina Brümmer

Johannes Hamecher

Jan Hermes

Thomas Höllt

Christian Isleib

Sören Kewenig

Carsten Meffert

Das Team

• Visualisierung von medizinischen Volumendaten, die zum Beispiel von CT oder MRI

geliefert werden• im Gegensatz zum Oberflächen Rendering werden hierbei mehrschichtige oder

transparente Informationen dargestellt, zum Beispiel das Innere eines Körpers

EinführungDie Thematik

• bislang nur 8 bit Datensätze unterstützt• hauptsächlich CPU-Rendering • maximal interaktive Performance

EinführungEigenschaften von bekannten Systemen

EinführungZiele des Projektpraktikums

• Einarbeitung in den Bereich der medizinischen Visualisierung • Schwerpunkt: Visualisierung• Entwicklung eines Programmes zur Visualisierung von Volumendaten• Entwicklung einer Benutzeroberfläche • für möglichsten großen Lerneffekt: wurde auf keine bestehende Software zurückgegriffen [Ausnahme DICOM-Reader]

EinführungZiele des Projektpraktikums

• Verarbeitung von Volumendaten: DICOM, PGM• Rendern auf CPU und GPU• Ein- und Ausgabegeräte (Maus, (Spacemaus, Phantom))• Stereodisplay

EinführungOrganisation des Praktikums

• Zeitraum des Praktikums: 1.Oktober 2005 bis 31.März 2006• Organisation

– Vorbereitungsphase: Vorträge– Übungsphase: Übungsaufgabe– 1. Programmierphase: CPU-Raycasting– 2. Programmierphase: GPU-Raycasting– Audit

VorbereitungsphaseVorträge und Entscheidungen

Raycasting

Studienarbeit

Selbstentwicklung

CG, GLSL

wxWidgets, QT

• Grundlagen der Volumenvisualisierung• Renderingverfahren• Transferfunktion• Optimierungsmöglichkeiten• existierende API's• GPU-Programmierung• GUI-Programmierung• Haptik

VorbereitungsphaseSystemanforderungen

• Windows-PC (entwickelt und getestet unter Windows XP) • aktuelle Grafikhardware mit Unterstützung für Shader-Model 3.0 (empfohlen: Nvidia, ab NV4x) • je nach Datensatz ausreichend Arbeitsspeicher (mind. 512 MB) • Bibliotheken:

•Boost(version),•wxWidgets(), •cg 1.4, •glew(),•Opengl•DICOM Parser

Datenverarbeitung

Programmierphase 1Teamaufteilung

Projektleiter

GUI-WorkflowCPU-Rendering

-CPU Raycasting -Raw/PGM lesen/schreiben-Filter (Mean /Gauss/Median)

-Basisoberfläche

Programmierphase 1Module und Daten

GUI DatenhaltungDateien

CPUVolumen

Kamera und Transferfunktion fest

Programmierphase 1Probleme und Lösungen

• Integration der einzelnen Komponenten nur anhand des Klassendiagramms– zu kurze Planungsphase --> direktes Implementieren warf Probleme auf – Schnittstellen waren nicht genau genug spezifiziert– Änderungen wurden bis zur Integrationspahse nicht an andere weitergegeben– Dokumentation aktuell halten und mehr Wissensaufbau (?)

• Entwicklung des Raycasters in Kommandobox, ohne GUI– besser direkt integrieren

Programmierphase 1Ergebnisse

• CPU rendert erste Bilder (ein Bild ca. 45 Sek.)• Filter implementiert• Lesen und schreiben von Dateien möglich• GUI besteht aus Grundgerüst (keine Interaktion)

Programmierphase 1Ergebnisse

CPU – Raycaster Maximum Intensity

Programmierphase 1Ergebnisse

CPU – Raycaster Mean Value

GlueCode

Programmierphase 2Teamaufteilung

Projektleiter

GUI-DesignGPU-Shader

-Echtzeitfähiges Raycasting(dual NV40) -Verschiedene Shader-12 bit

-Shader und GUI verbinden-Kamerasteuerung

-Code komplett integrieren-Transferfunktion-Dicom-Spacemouse

Programmierphase 2Module und Daten

GUI

Datenhaltung

Gluecode GPU

Dateien

Kamera, Shader,Transferfunktion

Shader,Texturuniformvariablen

Volumen

CPUVolumen

Kamera, Transferfunktion

Programmierphase 2Probleme und Lösungen

• Struktur des GlueCodes• Laden der Shader und zur Verfügungstellen der Parameter• Integration der Komponeten stellte sich als schwierig heraus

– unbekannte Nebeneffekte Texturen– Kapselung problematisch: keiner wusste genau was wo anders gemacht wurde

Programmierphase 2Probleme und Lösungen

• fehlende Testumgebung für die Shader– GlueCode-Erstellung dauerte länger als Shaderprogrammierung

• einfache Optimierungverfahren führten nicht zu Performancesteigerung • mehr als 256 steps führen zu Bildfehlern• Cg reagierte nicht vorhersehbar• Instabilitäten in der GUI• unerwartete Auswirkungen von einem Programmteil auf einen Anderen

Programmierphase 2Ergebnisse

• Verschiedene Shader implementiert • 12 bit fähig• Transferfunktion für CPU und GPU• Kamerasteuerung per Mouse (Maya)• Funktionalitäten über GUI ansteuerbar• Outputfenster für Statusausgaben• DICOM lesen

Programmierphase 2Ergebnisse

GPU - Torso mit linearer Transferfunktion

Programmierphase 2Ergebnisse

GPU - Torso mit veränderter Transferfunktion

Programmierphase 2Ergebnisse

Emission - Absorbtion Slice Viewer

Programmierphase 2Ergebnisse

Mean Value Maximum Intensity

Programmierphase 2Ergebnisse

CPU - Raycaster

FazitEindrücke und Ausblicke

• Das Projekt wurde als Erfolg gewertet• Die Hauptziele wurden erreicht (bis auf Spacemouse)• Mehr Softwaretechnische Planung wäre sinnvoll gewesen• Unbekanntes Problemfeld macht planen schwierig• GLSL statt CG vielleicht besser• Boost war im Nachhinein überflüssig• Audit war hilfreich (vielleicht früher)• Mögliche Erweiterungen: Haptik, Stereodisplay, Shader(Optimierung)