Projektpraktikum Medizinische Visualisierung

Einführung Das Team 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

Einführung Die Thematik 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ührung Eigenschaften von bekannten Systemen bislang nur 8 bit Datensätze unterstützt hauptsächlich CPU-Rendering maximal interaktive Performance Ein GPU Renderer in Wien entstanden,

Einführung Ziele 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] Ziele siehe Wiki!

Einführung Ziele des Projektpraktikums Verarbeitung von Volumendaten: DICOM, PGM Rendern auf CPU und GPU Ein- und Ausgabegeräte (Maus, (Spacemaus, Phantom)) Stereodisplay Ziele siehe Wiki!

Einführung Organisation 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

Vorbereitungsphase Vorträge und Entscheidungen Grundlagen der Volumenvisualisierung Renderingverfahren Transferfunktion Optimierungsmöglichkeiten existierende API's GPU-Programmierung GUI-Programmierung Haptik Raycasting Studienarbeit Selbstentwicklung CG, GLSL wxWidgets, QT Renderingverfahren-> direktes Rendering Wxwidgets-> plattformunabhängig und OpenSource Boost -> GLSL oder CG --> keine allgemeine Treiberunterstützung für GLSL (?) Namenssuche -> Galenus

Vorbereitungsphase Systemanforderungen 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

Programmierphase 1 Teamaufteilung Projektleiter CPU-Rendering Datenverarbeitung GUI-Workflow Ziele der ersten Projektphase erwähnen Vielleicht Gruppenstärke -CPU Raycasting -Raw/PGM lesen/schreiben -Filter (Mean /Gauss/Median) -Basisoberfläche

Programmierphase 1 Module und Daten GUI Datenhaltung CPU Dateien Volumen GUI Datenhaltung CPU Moduldiagramm vielleicht besser!!!! Ablauf des Programmes erklären Kamera und Transferfunktion fest

Programmierphase 1 Probleme 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 Problme bei der Schnittstellenabsprache

Programmierphase 1 Ergebnisse 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) Soweit alle Ziele der Projektphase erreicht. GUI renderte ununterbrochen (ein Bild 45 Sek.) Noch keine Camerasteuerung Transferfunktion war Hardgecodet für CPU Dicom in arbeit Kurz vor Weihnachten erst fertig Pgm lesen/schreiben und Raw schreiben aus Übung 3 übernommen

Programmierphase 1 Ergebnisse CPU – Raycaster Maximum Intensity Soweit alle Ziele der Projektphase erreicht. GUI renderte ununterbrochen (ein Bild 45 Sek.) Noch keine Camerasteuerung Transferfunktion war Hardgecodet für CPU Dicom in arbeit Kurz vor Weihnachten erst fertig Pgm lesen/schreiben und Raw schreiben aus Übung 3 übernommen CPU – Raycaster Maximum Intensity

Programmierphase 1 Ergebnisse CPU – Raycaster Mean Value Soweit alle Ziele der Projektphase erreicht. GUI renderte ununterbrochen (ein Bild 45 Sek.) Noch keine Camerasteuerung Transferfunktion war Hardgecodet für CPU Dicom in arbeit Kurz vor Weihnachten erst fertig Pgm lesen/schreiben und Raw schreiben aus Übung 3 übernommen CPU – Raycaster Mean Value

Programmierphase 2 Teamaufteilung Projektleiter GPU-Shader GlueCode GUI-Design GleuCode: Daten an Shader geben, opengl code, shader verwalten(laden, binden) Die verschieden shader (emabs, Mean, firstlokalmax, Mip) -Echtzeitfähiges Raycasting (dual NV40) -Verschiedene Shader -12 bit -Shader und GUI verbinden -Kamerasteuerung -Code komplett integrieren -Transferfunktion -Dicom -Spacemouse

Programmierphase 2 Module und Daten GUI CPU Datenhaltung Gluecode GPU Kamera, Transferfunktion CPU Dateien Datenhaltung Volumen Volumen Kamera, Shader, Transferfunktion Die Generalisierung in Shader war im Nachhinnein sinnlos ( Vererbung war nicht einsetzbar , beide mussten komplett separat gehalten werden ) Nur Vererbung der Klassensignatur Gluecode Shader,Textur uniformvariablen GPU

Programmierphase 2 Probleme 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 Hinweis: übernehmen der Funktionen wie sie im Dummy geschrieben waren, war nicht ohne weiteres möglich GUI warf auch Probleme auf --> Texturen Kapselung: Bsp. GUI, Nebeneffekte wurden erst viel später klar, nach Einarbeitung so wusste Johannes nicht wie es beim GlueCode funktioniert wird und andersrum --> bessere Dokumentation, Planung, Ablaufdiagramme, usw. GlueCode wurde zweimal geplant (Klassenstruktur) und trotzdem nicht perfekt.

Programmierphase 2 Probleme 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 Hinweis: übernehmen der Funktionen wie sie im Dummy geschrieben waren, war nicht ohne weiteres möglich GUI warf auch Probleme auf --> Texturen, klicken in Transferfunktion vor laden der Volumen führte zum Absturtz Kapselung: Bsp. GUI, Nebeneffekte wurden erst viel später klar, nach Einarbeitung so wusste Johannes nicht wie es beim GlueCode funktioniert wird und andersrum --> bessere Dokumentation, Planung, Ablaufdiagramme, usw. Neues opengl Fenster in der GUI führte zu falschen Zuweisungen der Texturen cg: unterschiedliche Anordnung von Methoden führte zu unterschiedlichen Ergebnissen, uniforms wurden teilweise nicht korrekt übergeben,

Programmierphase 2 Ergebnisse 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 mehfaches laden, verschiedene shader, GPU/CPU wechsel, Steps, opacity Mouse dreht sich auch über den Kopf

Programmierphase 2 Ergebnisse mehfaches laden, verschiedene shader, GPU/CPU wechsel, Steps, opacity Mouse dreht sich auch über den Kopf GPU - Torso mit linearer Transferfunktion

Programmierphase 2 Ergebnisse mehfaches laden, verschiedene shader, GPU/CPU wechsel, Steps, opacity Mouse dreht sich auch über den Kopf GPU - Torso mit veränderter Transferfunktion

Programmierphase 2 Ergebnisse Emission - Absorbtion Slice Viewer mehfaches laden, verschiedene shader, GPU/CPU wechsel, Steps, opacity Mouse dreht sich auch über den Kopf Emission - Absorbtion Slice Viewer

Programmierphase 2 Ergebnisse Mean Value Maximum Intensity mehfaches laden, verschiedene shader, GPU/CPU wechsel, Steps, opacity Mouse dreht sich auch über den Kopf Mean Value Maximum Intensity

Programmierphase 2 Ergebnisse CPU - Raycaster mehfaches laden, verschiedene shader, GPU/CPU wechsel, Steps, opacity Mouse dreht sich auch über den Kopf CPU - Raycaster

Fazit Eindrü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) Zusammenfassung des Projekts, Team, Stimmung Vorteil kleine Gruppe, gute Zusammenarbeit, homogene Gruppe… Boost: bei Dateihaltung hinderlich, Multithreading wäre mit wxsWidgets gelaufen Klassendiagramme nicht aktuell, hätten einmal festgelegt werden müssen Viele Ergänzungen im Nachhinein