Experiment 2 angefangen

Paperung/Experimente/Experiment 1 - Renderzeit.md

@@ -0,0 +1,85 @@
+Während der Implementierung der ViewLayers ist aufgefallen, dass die Zeit, die es dauert ein Bild und die Segmentierungsmasken zu rendern, gesunken ist im Vergleich zur Ausgangslage des Projekts. Um dieses Beobachtung zu validieren und deren Ursache zu finden wurde das folgende Experiment durchgeführt.
+
+Ein Durchlauf des Scripts erzeugt eine definierte Anzahl an Bildern und den dazugehörigen Segmentierungsmasken.
+
+Listing ... zeigt als Pseudo-Code den Groben Ablauf des Scripts. Anfangs wird einmalig die Konfiguration sowie geladen. Diese definiert einerseits die Wertebereiche für die später zufällig gewählten Parameter wie z. B. die möglichen Grauwerte für Haut, Sclera, Iris usw. Dort wird auch definiert, wie viele Bilder generiert werden sollen. Darauf folgt eine Schleife, die so viele Iterationen hat, wie Bilder generiert werden sollen (X). Für jede dieser Iterationen wird dann die zufällige Konfiguration bestimmt, also die Blickrichtung des Auges, die Grauwerte der Objekte in der Szene, wie weit das Augenlid geöffnet ist. Mit diesen Werten werden dann die Objekte in den Szenen modifiziert. Es werden auch Node-Trees für die Materialen und das Compositing neu erzeugt. Nachdem die Konfiguration abgeschlossen ist, wird das Bild und dessen Segmentierungsmasken gerendert.
+
+```
+1. Initialiserung
+2. Wiederhole x mal
+3.    Modifiziere Blender-Szene mit zufälliger Konfiguration
+4.    Rendere ein Bild und Segmentierungsmasken
+```
+Daraus ergeben sich mehrere Punkte, an denen die Laufzeit verbessert worden sein kann:
+
+Da in der im Rahmen dieser Arbeit erweiterten Implementierung nur eine Szene existiert und in der Initialisierung für alle Szenen Logik ausgeführt wird, kann die Initialisierungszeit verkürzt sein. Da diese allerdings nur einmalig ausgeführt wird, kann sie höchstens Einfluss auf die Gesamtlaufzeit haben. Allerdings wurden Verbesserungen in der Render-Zeit einzelner Bilder beobachtet, somit müssen diese signifikanten Verbesserungen in der Schleife auftreten.
+
+Der nächste mögliche Aspekt ist die Zeit, die für die Konfiguration der Szene nötig ist. In diesem Teil des Scripts wurden große Änderungen vorgenommen, da durch den Umstieg auf ViewLayer Objekte nur noch einmalig und nicht in mehreren Szenen angepasst werden müssen. Allerdings sind nun auch deutlich mehr zufällig gewählte Variablen vorhanden, was die Laufzeit dieses Schritts verlängern könnte.
+
+Zuletzt müssen die Bilder gerendert werden. Das ist mit Abstand der aufwendigste Teil dieses Prozesses, der demensprechend die meiste Laufzeit in Anspruch nimmt. Daher ist auch zu erwarten, dass die Laufzeitverbesserungen in diesen Schritt entstehen. Sie können entweder durch den Wechsel von mehreren Szenen auf die ViewLayer entstanden sein, oder durch den Wechsel von Blender-Version 4.x auf die zum Zeitpunkt dieser Arbeit neueste Version 5.0.
+
+Unter diesen Gesichtspunkten ergeben sich folgende Laufzeiten die direkt gemessen werden können:
+- Initialisierungszeit ($t_{init}$):
+  Wie lange dauert der Initialisierungsschritt. Aufgrund der geringen Arbeit, die in diesem Schritt passiert ist besten Falls eine minimale Verringerung der Laufzeit zu erwarten.
+- Zeit für die zufällige Konfiguration der Szene ($t_{config}$):
+  Die Zeit, die es dauert die Szene mit zufälligen Parametern für ein einzelnes Bild zu modifizieren. Es ist eine moderate Verbesserung der Laufzeit zu erwarten, da das Verändern der Iris-Geometrie nur noch einmal durchgeführt wird, statt wie vorher dreimal. Generell entfallen Szenen-Wechsel. Es wird kaum mehr Laufzeit erwartet durch das setzen der zufälligen Gewichte für die Blend-Shapes wie die Schließung des Augenlids und der anderen Veränderungen an der Periorbital-Geometrie, sodass insgesamt eine Verbesserung zu beobachten sein dürfte.
+- Zeit für das Rendern der Szene ($t_{render}$):
+  Die Zeit, die es dauert vom Befehl das Bild und die Masken zu rendern, bis dieses Fertig gerendert ist. Da dies der aufwändigste Schritt ist, wird hier die meiste Verbesserung erwartet.
+- Gesamtlaufzeit eines Bildes ($t_{frame}$):
+  Dies ist die Laufzeit einer Iteration der Schleife, also die zufällige Konfiguration der Szene plus die Render-Zeit. Mathematisch ist also $t_{frame} = t_{config} + t_{render}$ zu erwarten
+- Gesamtlaufzeit des Scripts ($t_{script}$):
+  Die Gesamtlaufzeit innerhalb des Scripts. Hier spielen also die einmalige Laufzeiten wie z. B. die Initialisierung eine Rolle, aber insbesondere die Laufzeit der $x$ Iterationen in denen die Bilder generiert werden. Mathematisch ist also $t_{script} = t_{init} + \sum_{i = 0}^{x}t_{image,i}$ oder wenn man berücksichtigt, dass die Laufzeit $t_{image}$ pro Bild nach einer Aufwärmphase innerhalb einer Standardabweichung konstant sein sollte $t_{script} \approx t_{init} + x \cdot t_{image}$ zu erwarten.
+- Gesamtlaufzeit des Befehls ($t_{total}$)
+  Zu Ausführen des Scripts wird per Kommandozeile Blender als Head-Less Instanz, also ohne sichtbares Fenster, gestartet. Dabei bekommt es sowohl den Pfad zur zu ladende Szene sowie zum auszuführenden Script übergeben. Diese ist für unsere Betrachtung keine sonderlich relevanten Informationen, da lediglich die einmalige Startzeit (und Stoppzeit) von Blender zusätzlich gemessen wird. Da dies allerdings einfach zu messen ist wird es der wissenschaftlichen Vollständigkeit zusätzlich erfasst. Mathematisch kann folgende Laufzeit erwartet werden: $t_{total} = t_{startup} + t_{script} + t_{shutdown}$.
+
+
+Es ist zu erwarten, dass die Laufzeiten der Iterationen einer Aufwärmphase unterliegen, in der anfangs Iterationen relativ lange dauern und kürzer werden, bevor sie sich relativ zuverlässig um eine Asymptote sammeln. Daher müssen ausreichend viele Iterationen durchgeführt werden um einerseits die Aufwärmphase zu überwinden und dann ausreichend Datenpunkte für die Bestimmung von Mittelwert und Standardabweichung zu sammeln.
+In vorläufigen Tests wurde festgestellt, dass die Aufwärmphase nach etwa 10 Iterationen zuverlässig überwunden ist und die Laufzeit der Iterationen dann relativ stabil ist. Es wurde 120 als Anzahl der Iterationen, also der zu generierenden Bilder, gewählt. Das sollten genügend Iterationen sein, um zuverlässige Mittelwerte und Standardabweichungen unter Ausschluss der Aufwärmphase zu liefern.
+
+Es wurden fünf Durchläufe durchgeführt, um einerseits mehrere Messwerte für die einmaligen Messwerte wie Initialisierungszeit und Gesamtlaufzeit zu sammeln. Außerdem erlaubt dies unerwartete Auswirkungen die Generierungszeit auszuschließen.
+
+# Testdurchläufe:
+Es werden grundsätzlich zwei Versionen von HEyes mit einander verglichen: Die original Implementierung von HEyes, auf der die vorliegende Arbeit aufbaut, und die fertige Implementierung dieser Arbeit mit allen zusätzlichen Funktionalitäten. Dabei ist anzumerken, dass die original Implementierung so angepasst wurde, dass die Messung alle nötigen Laufzeiten möglich ist. 
+
+1. Og Implementierung + Blender 4.5:
+   Die praktisch unveränderte Implementierung wird mit der alten Blender Version getestet. Einzig um sicherzustellen, dass die Ergebnisse reproduzierbar sind, wurde wie in Abschnitt ... beschrieben die Möglichkeit implementiert, die Zufallsgeneratoren mit einem festen Seed-Wert zu initialisieren. Die hierdurch gewonnenen Messwerte stellen die Baseline-Laufzeit dar, anhand welcher Verbesserungen in nachfolgenden Experimenten erkannt werden können. 
+2. Og Implementierung + Blender 5.0:
+   Die Implementierung aus Test 1 wurde minimal angepasst, um mit der API der von Blender 5.0 kompatibel zu sein. Alle anderen Aspekte bleiben Unverändert. Dadurch werden die Performance-Veränderungen, die durch die Blender Version verursacht werden sichtbar gemacht.
+3. Neue Implementierung + Blender 4.5:
+   Die neue Implementierung wurde wieder mit Blender 4.5 kompatibel gemacht und getestet. Das erlaubt zusätzlich den Vergleich, ob die Änderungen in der Implementierung in verschiedenen Blender-Versionen ggf. effizienter wurden.
+4. Neue Implementierung + Blender 5.0:
+   Dies stellt die endgültige Version der neuen Implementierung und somit die endgültige Performance dar.
+
+Um die zusätzlichen Messwerte erfassen zu können, musste das Script angepasst werden. Um sicherzustellen, dass die Messung minimalen Einfluss auf die Laufzeiten hatte, wurde zusätzlich der Test ... auch ohne Instrumentalisierung durchgeführt und nur die Gesamtlaufzeit erfasst. Wenn die Ergebnisse zeigen, dass die Gesamtlaufzeiten innerhalb der Standardabweichung praktisch gleich sind, kann davon ausgegangen werden, dass die Instrumentalisierung des Codes keinen Einfluss auf die Gesamtlaufzeit sowie die Teillaufzeiten hatte.
+
+> [!question]- TODO, falls ich Bock habe
+> Zusätzlich wurde die Konfiguration aus Test 4 mit unterschiedlichen Blender-Einstellungen getestet:
+>
+>
+>
+> | Parameter   |                       |
+> | ----------- | --------------------- |
+> | Compositing | 1. CPU<br>2. GPU      |
+> | Rendering   | 1. CPU<br>2. GPU      |
+> | Renderer    | 1. Eevee<br>2. Cycles |
+>Das wären 35 weitere Tests (eigentlich 36, aber die Standard-Config ist CPU Comp, GPU Eevee Render)
+
+Bereits im Laufe der Vorbereitung dieses Experiments fiel auf, dass die Vorbereitung der Szene für das Generieren eines Bildes deutlich mehr Zeit in Anspruch nimmt, als zunächst angenommen wurde. Daher wurde dieser zunächst vernachlässigte Schritt genauer untersucht.
+
+Variablen:
+Blender: 4.5 vs 5.0
+Code: Alt vs Neu
+Cache Luminance (lum): Yes vs No
+Optimized Texture Generation (optitex): Yes vs No
+
+
+Tests:
+1. Alt mit 4.5
+2. Alt mit 5.0
+3. Neu mit 4.5, lum und Optitex aus
+4. Neu mit 5.0, lum und Optitex aus
+	-> betrachtet isoliert Performanceverbesserungen  durch Blender 5
+5. Neu mit 5.0, lum und Optitex an
+	-> blender 5, lum und optitex sind orthogonal zueinander, daher gleichzeitig messbar und tortzdem individuell vergleichbar. Betrachtet isoliert die Optimierung, auch auf alt Anwendbar
+
+-> Wenn ich für _Experiment 2_ Bilder erzeuge, dann kann ich das ggf. mit Blender 5, lum und optitex machen

Paperung/Experimente/Experiment 2 - NN performance.md

@@ -0,0 +1,53 @@
+Hypothese: (besser formulieren, kommt irgendwo an den Anfang der Arbeit, mal Gucken, wo Meiko das hingepackt hatte...)
+LightEyes stellt Augen nur sehr grundlegende Formen dar, im Grunde graue Kreise und erzielt dabei verhältnismäßig gute Performance beim Training von Neuronalen Netzen. Daher ist davon auszugehen, dass das detailliertere Modellieren der Periorbitalregion keinen nennenswerten Einfluss auf die Leistung von Neuronalen Netzen hat.
+
+## Einleitung
+In der vorliegenden Arbeit wurde die bestehende Implementierung von HEyes erweitert, sodass nun die Form der Periorbitalregion zufällig verändert werden kann. In Experiment 1 wird untersucht, wie sich die Änderungen auf die Laufzeit der Generierungspipeline auswirken. In diesem Experiment soll untersucht werden, ob diese Erweiterung einen Einfluss auf die Erkennungsleistung von KI-basierten Segmentierungsmodellen hat. Dazu wird ein Vergleich
+
+
+
+Von Timms Arbeit:
+Über alle Experimente hinweg wurden die gleichen, in der medizinischen Bildsegmentierung etablierten Metriken erfasst [71]. Im Mittelpunkt stehen der Dice Score (auch F1  Score) und die IoU (auch Jaccard Index genannt) als Flächenüberlappungsmaße sowie  Precision und Recall als Fehlerratenmaße. Besonders der Dice-Score fand in verwandten Arbeiten, wie etwa bei M. Calisto et al. (2021) [10] und Z. Fan et al. (2020) [19],  Verwendung.
+
+Meiko hat auch Dice und IoU überprüft. Nach jeder Epoche berehcnet.
+
+
+Sachen, die ich mache:
+- Modell: Yolo26-seg small
+- Zwei Modelle trainieren:
+	1. Alte Implementierung
+	2. Neue Implementierung
+	- 80 - 20 Split? Meiko hat 85 - 15?! für Training und Validierung
+- Test-Set mit ???
+	- entweder 500k oder Daten aus TEyeD?
+		- Vom Testset hängt auch die zu generierende Auflösung der synthetischen Bilder ab
+	- Störfaktoren sind nicht wirklich Teil meiner Arbeit, daher möchte ich am besten einen kontrollierten Datensatz, aber mit verschiedenen Ethnien
+- Synthetische Daten generieren
+	- Es werden explizit Bilder mit verdeckter Pupille erzeugt
+	- TODO: Müssen wir die Helligkeitswerte aus den Test-Set extrahieren?
+	- Um Überrepräsentation von verdeckten Pupillen zu vermeiden wird der Exponentielle-Faktor für den Lidschluss verwendet, damit mehr Bilder ein offenes Auge haben
+
+# Sachen, die ich am Ende sehen möchte:
+Graphen:
+Plotten über alle Epochen:
+- Train Loss
+- Validation Loss (Meiko hat das auch irgendwie für jede Epoche berechnet)
+- Precision und Recall
+- Okay für Yolo hat er Mask Precision und Recall, was auch immer das sein soll
+Meiko hatte auch:
+- Validation mAP50
+- Validation mAP50-95
+
+Für das Finale Modell:
+- IoU und Dice für die Test-Set-Bilder berechnen
+- Tabelle: Mean + SD für IoU und Dice für beide Modelle
+- Ich möchte auch einen Boxplot zeigen können für IoU und Dice und einzelne Bilder und ihre Masken (Ground Truth und predicted) + Scores zeigen können
+# Todo!!!!!!!!!!
+- Meiko und Jan haben aus den Daten die Helligkeitswerte extrahiert
+
+
+# Genutzte Hardware:
+Beide Experimente wurden auf einem Computer mit folgender Hardware ausgeführt:
+- CPU: AMD Ryzen 7 2700x mit 8 Kernen (16 Threads)
+- GPU: NVIDIA RTX 3080 mit 10 GB VRAM
+- RAM: 32 GB DDR4