Projektpraktikum Medizinische Visualisierung. Einführung Projektleitung:Matthias Biedermann...
-
Upload
christiane-weisel -
Category
Documents
-
view
108 -
download
4
Transcript of Projektpraktikum Medizinische Visualisierung. Einführung Projektleitung:Matthias Biedermann...
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)