Sehr viele Sachen

Prewrite/3. Stand der Forschung (Related Work).md

@@ -0,0 +1,99 @@
+Ziel: ca. 12 Seiten
+## 1. Synthetische Datengenerierung für Eyetracking
+**Ziel: ca. 4 Seiten**
+
+Der Kernblock. Vorgestellt werden die bekannten Generatoren und Pipelines: SynthesEyes, UnityEyes, RIT-Eyes, LEyes, und bei Bedarf UnityEyes 2 als neuerer Ausblick. Der Fokus liegt auf der Pipeline-/Generator-Perspektive: Was wird jeweils randomisiert, welche Labels entstehen, wie realistisch bzw. kontrollierbar ist die Synthese, und wo liegen die Grenzen? Dabei die Unterschiede herausarbeiten – photorealistisch vs. vereinfachte Generierung, welche Downstream-Aufgaben adressiert werden. SynthesEyes betont photorealistische, kontrollierbare Variation von Kopfpose, Blickrichtung und Beleuchtung; UnityEyes zielt auf schnelle Synthese großer Mengen variabler Augenregionen; RIT-Eyes ergänzt deformierbare Iris, gaze-koordinierte Lidbewegung und Blinzeln; LEyes geht bewusst weg vom Photorealismus und modelliert nur die für Video-Eye-Tracking nötigen Schlüsselmerkmale. Bei jedem Generator kurz mitdiskutieren, für welche Aufgabe die Daten gedacht waren – aber noch nicht ausführlich in Sim-to-Real oder Segmentierungsmodelle abrutschen, das kommt in Kapitel 2 und 3.
+
+Das bleibt dein **Kernblock**. Hier geht es um bestehende Generatoren und Pipelines wie **SynthesEyes, UnityEyes, RIT-Eyes, LEyes** und ggf. neuere Weiterentwicklungen. Der Fokus liegt auf der **Erzeugungsseite**: Welche Arten synthetischer Augenbilder werden erzeugt, welche Parameter werden variiert, welche Annotationen entstehen, wie realistisch oder abstrahiert ist die Darstellung, und welche Grenzen haben die jeweiligen Ansätze?
+
+Wichtig ist, dass du dieses Kapitel konsequent aus der **Pipeline-/Generator-Perspektive** schreibst. Also nicht ausführlich: „Wie gut funktioniert das für Segmentierung?“ oder „Welche Architektur wurde danach verwendet?“, sondern:  
+Welche Form von Variation wird überhaupt modelliert? Blickrichtung, Pose, Beleuchtung, Lidbewegung, Irisform, Bildrauschen, Hardwareeffekte, Augenregionsform usw.
+
+Hier kannst du am Ende schon vorsichtig die Brücke schlagen: Einige Arbeiten variieren durchaus Merkmale der Augenregion, aber die **gezielte Modellierung stabiler interindividueller Augenformmerkmale** ist dort nicht der zentrale Untersuchungsgegenstand.
+
+**Kurzform des Kapitels:**  
+Bestehende Eye-Tracking-Synthesepipelines, ihre Variationsachsen, ihre Annotationen und ihre methodischen Grenzen.
+
+
+## 2. Synthetische Daten für gaze estimation, Feature-Lokalisierung und Pupillensegmentierung
+**Ziel: 1 bis 2 Seiten**
+
+Dieses Kapitel verortet die Arbeit in den nachgelagerten Lernaufgaben. Die Leitfrage ist nicht "welche Modelle gibt es", sondern: Wie wurden synthetische Daten in Downstream-Aufgaben verwendet? Dafür eine kurze Einordnung der drei Hauptstränge – Gaze Estimation, Eye-Shape/Landmark Localization, semantische Segmentierung (Pupil/Iris Parsing) – und dann der Fokus auf die Segmentierungsseite. RITnet und EllSeg gehören hier hinein, aber rein datenbezogen: Welche Datensätze wurden genutzt, wie wichtig waren synthetische Labels? RITnet ist stark an OpenEDS gekoppelt; EllSeg evaluiert auf mehreren synthetischen Segmentierungsdatensätzen. Um Redundanz mit Kapitel 1 zu vermeiden: Die Generatoren werden in Kapitel 1 vorgestellt, hier geht es nur darum, wie ihre Outputs in der Segmentierungsforschung aufgegriffen wurden.
+
+Dieses Kapitel solltest du **schmaler und schärfer** halten, damit es sich nicht mit Kapitel 1 doppelt. Es ist **keine allgemeine Modellübersicht**, sondern beantwortet eine andere Frage:  
+**Wie wurden synthetische Augendaten in nachgelagerten Lernaufgaben verwendet?**
+
+Damit verschiebt sich die Perspektive weg vom Generator und hin zur **Verwendung der Daten**. Du kannst hier knapp zeigen, dass synthetische Augendaten bereits für verschiedene Aufgaben eingesetzt wurden, etwa für:
+
+- Gaze Estimation,
+- Landmarken- bzw. Augenform-Lokalisierung,
+- Pupillen-/Iris-Erkennung bzw. Segmentierung.
+
+Der entscheidende Punkt ist dabei:  
+Nicht die Architekturen selbst stehen im Vordergrund, sondern **welche Rolle synthetische Daten für diese Aufgaben gespielt haben**. Also zum Beispiel:  
+Wurden synthetische Daten zum Vortraining genutzt? Zur Ergänzung kleiner realer Datensätze? Für bestimmte Labelarten, die real nur schwer zu annotieren sind?
+
+Damit wird Kapitel 2 zu einer Art **Anwendungsbrücke**: Es zeigt, dass synthetische Daten im Eye-Tracking-Feld etabliert sind, aber je nach Zielaufgabe unterschiedlich eingesetzt werden — und dass gerade für die Pupillensegmentierung die Zusammensetzung des Trainingsdatensatzes besonders relevant ist.
+
+**Kurzform des Kapitels:**  
+Nicht: „Welche Modelle gibt es?“  
+Sondern: „Wie und wofür wurden synthetische Augendaten bereits eingesetzt?“
+
+## 3. Sim-to-Real-Transfer, Generalisierung und Domain Adaptation / Domain Randomization
+**Ziel: ca. 2 Seiten**
+
+Die zentrale Frage der Arbeit ist nicht nur "Kann ich Augenformen modellieren?", sondern "Hilft diese zusätzliche Variation beim Training auf reale Daten – oder schadet sie?" Dafür braucht es den Forschungsstrang zu Domain Gap und Übertragbarkeit. Innerer Aufbau als Dreischnitt: Zuerst das Problem (Sim-to-Real Gap), dann Strategie 1 (mehr Variation / Domain Randomization, Tobin et al. als allgemeiner Rahmen), dann Strategie 2 (Verfeinerung / Adaptation, z.B. SimGAN für synthetische UnityEyes-Bilder, Seg2Eye als stilkonsistente personenspezifische Generierung). Wichtig ist weniger Breite als die Argumentation: Formvariation als eine Art von Domain Randomization einzuordnen. Spezifischer Bezug zum Eyetracking über SynthesEyes (Bedeutung realistischer Beleuchtung und Formvariation) und LEyes (Hardwareunterschiede und biologische Unterschiede als Generalisierungshürden).
+
+Dieses Kapitel ist logisch sehr wichtig und in sich schon recht sauber. Hier geht es nicht mehr primär um konkrete Generatoren, sondern um den **übergeordneten methodischen Rahmen**, in den deine Arbeit gehört.
+
+Die Leitfrage lautet hier:  
+Warum sollte zusätzliche Variation in synthetischen Daten überhaupt helfen — und unter welchen Bedingungen hilft sie vielleicht nicht?
+
+Inhaltlich würde ich das Kapitel intern in drei gedankliche Teile gliedern:
+
+1. **Das Problem:** synthetische und reale Daten unterscheiden sich, wodurch ein Sim-to-Real-Gap entsteht.
+2. **Eine Strategie:** mehr Variation durch Domain Randomization, um robustere Modelle zu trainieren.
+3. **Weitere Strategien:** Domain Adaptation, Verfeinerung synthetischer Bilder oder stilistische Angleichung an reale Daten.
+
+Für deine Arbeit ist dabei der wichtigste argumentative Punkt:  
+**Augenformvariation kann als eine spezielle Form von Domain Randomization verstanden werden.**  
+Du testest also nicht einfach „noch einen Parameter“, sondern konkret, ob zusätzliche morphologische Variation die Generalisierung verbessert oder verschlechtert.
+
+**Kurzform des Kapitels:**  
+Der theoretische Rahmen dafür, warum zusätzliche Variation in synthetischen Daten für reale Anwendungen relevant sein kann.
+
+## 4. Modellierung interindividueller anatomischer Variation der Periorbitalregion
+**Ziel: 2 bis 3 Seiten**
+Das ist das Kapitel, das die Arbeit am stärksten von klassischer Syntheseliteratur abhebt 👁️✨
+Hier sollte klar werden, warum Augenformmerkmale wie Lidform, Lidfalte, Kanthusform oder Epikanthus **keine bloßen Details** sind, sondern eine eigenständige, biologisch plausible Variationsachse. Dafür passt eine Zweiteilung sehr gut:
+### 4.1 Periorbitale Morphologie als relevante Variationsachse
+Anthropometrische Literatur, die zeigt, dass sich die periorbitale Morphologie zwischen Personen systematisch unterscheidet (Ethnie, Geschlecht, Alter, natürliche Asymmetrien). Damit begründen, warum Merkmale wie Lidform, Lidfalte, Kanthusform oder Epikanthus nicht bloß kosmetische Details sind, sondern eine relevante Variationsachse für Trainingsdaten. Dieses Teilkapitel liefert die **inhaltliche Rechtfertigung**, warum die Variation überhaupt sinnvoll ist.
+### 4.2 Parametrische Modellierung morphologischer Variation
+
+Hier ordnest du angrenzende Arbeiten ein, die Gesichtsvariation parametrisch modellieren, etwa über Morphable Models oder ähnliche 3D-Ansätze. Wichtig ist die Einordnung: Das sind **angrenzende Arbeiten**, aber keine direkten Eye-Tracking-Synthesepipelines mit Fokus auf die Periorbitalregion. Genau dadurch kannst du zeigen, dass parametrisierte Formvariation grundsätzlich ein etablierter Gedanke ist, aber in deinem spezifischen Anwendungskontext noch nicht in dieser Form ausformuliert wurde.
+
+**Holistische 3D Morphable Models** wie FLAME, das Basel Face Mode, eventuell weitere 3DMMs. Diese Modelle sind Nachbarliteratur, keine direkten Eye-Tracking-Generatoren. FLAME als artikuliertes Ganzkopfmodell, BFM als klassisches Morphable-Face-Model. Das zeigt, dass parametrisierte Gesichtsvariation grundsätzlich etabliert ist – aber die Dimensionen dieser Modelle sind typischerweise holistisch und nicht in Bezug auf lokale Gesichtsmerkmale interpretierbar.
+
+**Wisetchat 2018 ("Description-based visualisation of ethnic facial types")** nimmt hier eine Sonderstellung ein und ist das methodisch engste Vorbild für die eigene Arbeit. Im Gegensatz zu klassischen 3DMMs definiert Wisetchat explizite, semantisch interpretierbare und quasi-orthogonale Formparameter für einzelne Gesichtsregionen – darunter die Augenregion. Lokale Merkmale wie Falten, Wölbungen, Neigungen etc. werden als kontinuierliche Attribute modelliert, die ein morphbares Modell steuern und ethnische Formvariation sichtbar machen. Der entscheidende Punkt: Wisetchat zeigt, dass lokale, beschreibbare Formparameter ethnische Variation oft besser erfassen als reine Landmark-Abstände. Die Arbeit zielt dabei auf die menschliche Wahrnehmung und Visualisierung ethnischer Gesichtsvariation ("human visual appreciation"), **nicht** auf die Erzeugung synthetischer Trainingsdaten.
+
+Genau hier liegt die Abgrenzung: Die eigene Arbeit übernimmt dieselbe Grundidee – explizite, semantische Formparameter für die Periorbitalregion – setzt sie aber in einer Blender-Synthesepipeline ein, um damit Trainingsdaten für ein Segmentierungsmodell zu erzeugen. Gleicher Modellierungsansatz, anderer Zweck. Das baut direkt die Brücke zu Kapitel 5, weil sich zeigen lässt: Die Idee parametrischer, semantischer Formvariation existiert und ist tragfähig, wurde aber im Kontext synthetischer Eye-Tracking-Daten noch nicht in dieser Form eingesetzt und als eigenständiger Faktor untersucht.
+
+Das ist thematisch deutlich besser hier aufgehoben als in Kapitel 1, weil es direkt auf die **Forschungslücke** vorbereitet.
+## 5. Forschungslücke und Positionierung der eigenen Arbeit
+
+**Ziel: ca. 1 Seite**
+
+Die rote Linie: Es gibt starke Arbeiten zur synthetischen Erzeugung von Augenbildern, die erfolgreich Blickrichtung, Pose, Beleuchtung und teils dynamische Lidbewegungen variieren. Vorsicht bei der Formulierung der Lücke – UnityEyes wird ausdrücklich mit Variation der Eye Region Shape beschrieben. Die Lücke ist also nicht "niemand hat Augenform variiert", sondern: Die explizite, parametrisierbare und als eigener Faktor untersuchte Modellierung stabiler periorbitaler Augenformmerkmale steht nicht im Zentrum der bisherigen Arbeiten. Die Arbeit erweitert eine bestehende Blender-Pipeline um diese Formvariation und prüft experimentell, ob das für ein Segmentierungsmodell Nutzen oder Nachteil hat.
+
+Dieses Kapitel ist dann die **saubere Synthese** aus 1 bis 4.
+
+Die Argumentation sollte ungefähr so verlaufen:
+
+Bestehende Arbeiten zur synthetischen Erzeugung von Augenbildern zeigen, dass kontrollierte Variation für Eye-Tracking-Aufgaben grundsätzlich sehr wertvoll ist. Dabei werden bereits verschiedene Einflussfaktoren wie Blickrichtung, Kopfpose, Beleuchtung, Lidbewegung oder bildgebende Effekte berücksichtigt. Auch der Einsatz synthetischer Daten für nachgelagerte Lernaufgaben ist etabliert, und im weiteren Sinn lässt sich zusätzliche Variation als Beitrag zur Verbesserung der Generalisierung verstehen.
+
+Was jedoch nicht im Zentrum der bisherigen Arbeiten steht, ist die **explizite, parametrisierbare und gezielt untersuchte Modellierung stabiler interindividueller Augenformmerkmale der Periorbitalregion** als eigener Faktor für die Generalisierung segmentierungsbasierter Eye-Tracking-Modelle.
+
+Genau dort setzt deine Arbeit an:  
+Du erweiterst eine bestehende Blender-basierte Synthesepipeline um diese Formvariation und untersuchst experimentell, welchen Einfluss sie auf die Leistung eines Segmentierungsmodells hat.
+
+Das ist die präziseste und zugleich vorsichtige Formulierung deiner Lücke.

Prewrite/Gliederung Kapitel 4-7.md

@@ -0,0 +1,223 @@
+# Gliederung Kapitel 4-7 (Methodik, Implementierung, Versuchsaufbau, Ergebnisse)
+
+## Leitprinzip
+
+| Kapitel | Funktion |
+|---------|----------|
+| 4 Methodik | WAS und WARUM (Konzept, Designentscheidungen) |
+| 5 Implementierung | WIE (technische Umsetzung, Blender-Details, Code) |
+| 6 Versuchsaufbau | Womit und wie getestet (Parameter, Datensatze, Metriken) |
+| 7 Ergebnisse | Was rauskam (Daten, unmittelbare Schlussfolgerungen) |
+
+## Entscheidungen
+
+- Augenlid-Inhalt (Problemanalyse + Losung) bleibt komplett in Implementierung, da zu technisch fur Methodik
+- Methodik beschreibt nur das Gesamtkonzept auf hoherer Ebene, keine Blender-spezifischen Details
+- Szenenarchitektur (ViewLayer-Umbau) und Augenbrauen/Wimpern sind technische Entscheidungen, gehoren in Implementierung, nicht Methodik
+- Methodik bekommt einen kurzen Abschnitt "Evaluationslogik" (max 0,5-1 Seite)
+- Konfigurationskonzept in Methodik abstrakt halten (keine JSON-Details), konkretes Schema nach Implementierung
+- 5.3 (Augenlid + Periorbital) aufteilen in zwei Abschnitte: Augenlid und Periorbitalregion sind eigenstandige Beitrage
+- Versuchsaufbau bekommt einen Abschnitt "Gemeinsame Auswertungsprinzipien" (allgemein), experiment-spezifische Inferenzstatistik in den jeweiligen Experiment-Abschnitten
+- Exp 1.1 explizit als faktorielles Design (Pipeline x Blender-Version) rahmen, aber vorsichtig formulieren (keine perfekte kausale Trennung behaupten)
+- Exp 2 (6.5) intern untergliedern: Datensatzquellen, Trainings-/Validierungssplit, Vorverarbeitung, Metriken (mit Primarmetrik)
+- 5.10 Experimentwerkzeuge: hart priorisieren, UI-Komfortfeatures nur kurz
+- `0X_PerformanceVerbesserung.tex` wird aufgelost in drei Ziele (siehe Kap. 5.9, 6.4, 7.2)
+- Reihenfolge: Methodik -> Implementierung -> Versuchsaufbau -> Ergebnisse
+
+---
+
+## Kapitel 4: Methodik -- Konzeption der parametrisierbaren Augenmodell-Pipeline
+
+Dieses Kapitel beschreibt auf konzeptueller Ebene, WAS gemacht wird und WARUM. Keine Blender-spezifischen Details, keine Code-Details. Bewusst knapp halten: ca. 4-8 Seiten. Bei zu viel Umfang droht Wiederholung von Einleitung (4.1) und Versuchsaufbau (4.4).
+
+### 4.1 Gesamtkonzept und Anforderungen
+- Was soll die erweiterte Pipeline leisten: parametrische periorbital Formvariation in HEyes
+- Anforderungen (abgeleitet aus Forschungsfrage): plausible Augenformen, kompatibel mit bestehender Pipeline, konfigurierbar, randomisierbar, keine inakzeptable Laufzeitverschlechterung
+- Architekturubersicht: Figur, die den Weg von Config -> zufallige Parameter -> Rendering zeigt, mit Markierung wo die Formvariation eingreift
+
+### 4.2 Konzept der periorbitalen Formvariation
+- Warum Shape-Keys als Mechanismus gewahlt wurden (vs. Alternativen: separate Meshes, Skelett-Rigs, prozedurale Generierung)
+- Grundidee: lineare Kombination von Shape-Keys fur Augenlid-Schliessung + periorbital Formvariation
+- Kurze Erwahnung: Augenbrauen und Wimpern mussen deformierbar angebunden sein (feste Geometrie ungeeignet), daher haarbasierter Ansatz. Kein eigener Abschnitt, nur kurze Erwahnung im Kontext der Formvariation
+- Kurze Erwahnung der Herausforderungen (Clipping, Korrektur-Shape-Keys), die in der Implementierung gelost werden
+- NICHT: die detaillierte technische Problemanalyse (Krummungsruck, Normalen etc.) -- das bleibt in Kap. 5
+
+### 4.3 Konzept der Parametrisierung und Randomisierung
+- Abstrakt: Welche Parameter kontrollierbar sind, wie sie randomisiert werden, Rolle der Reproduzierbarkeit
+- Formulierung auf Methodenebene, z.B.: "Die Formvariation wird uber parametrisierbare Bereiche gesteuert, aus denen pro Bild Zufallswerte gezogen werden. Zur Reproduzierbarkeit konnen identische Zufallsinitialisierungen verwendet werden."
+- NICHT: JSON-Schema, konkrete Datenstrukturen, Config-Datei-Aufbau (das kommt in 5.7)
+
+### 4.4 Ubergeordnete Evaluationslogik
+- Sehr kurz (max 0,5-1 Seite)
+- Welche ubergeordneten Fragen beantwortet werden sollen
+- Warum dafur drei Experimente notig sind:
+  - Exp 1.1: Hat die Erweiterung die Laufzeit verschlechtert?
+  - Exp 1.2: Wo liegen Bottlenecks, und was bringen gezielte Optimierungen?
+  - Exp 2: Verbessert die Formvariation die Segmentierung auf echten Daten?
+- NICHT: konkrete Begrundungen pro Experiment (die stehen in Kap. 6)
+
+---
+
+## Kapitel 5: Implementierung
+
+Technische Umsetzung. Zeigt konkrete Probleme und Losungen. Hier stehen die Blender-Details, Modifier-Einstellungen, Code-Architektur. Ca. 15-20 Seiten.
+
+### 5.1 Projektstruktur
+- Kurzer Uberblick (max 0,5-1 Seite): Code-Organisation, Modul-Verantwortlichkeiten
+- Nur Module, die fur das Verstandnis notig sind. Keine Repository-Fuhrung
+
+### 5.2 Allgemeine technische Anpassungen
+- Blender 5 Upgrade (API-Anderungen, Compositing-Graph: eine Output-Node pro Textur) -- wichtigster Punkt
+- Seed-Konfiguration fur Reproduzierbarkeit -- sinnvoll
+- Debug-Szenen-Speicherung -- sinnvoll
+- Type-Annotations -- nur kurz erwahnen als Nebenaspekt
+
+### 5.3 Umsetzung des Augenlidmodells
+- **Probleme des bisherigen Modells** (der bestehende Text aus `3_AugenlidUndHaut.tex`): Krummungsruck, Texturkoordinaten-Sprunge, unvollstandige Schliessung, Clipping
+- **Shape-Key-basiertes Augenlid**: Zusammenfuhrung in ein Mesh, Catmull-Clark-Subdivision, Shape-Key-Animation
+- **Shrinkwrap Modifier**: Lösung des Clipping-Problems, Aufliegen auf dem Auge
+
+### 5.4 Umsetzung der periorbitalen Formvariation
+- Modellierte Shape-Keys, Deformationsbereiche
+- Grenzen der heuristischen Modellierung (sachlich formulieren, siehe Schreibhinweise)
+- Korrektur-Shape-Keys mit Drivern: welche Kombinationen kollidieren, wie Driver das losen
+
+### 5.5 Anpassung der Segmentierungsausgabe
+- Problem: Cryptomatte funktioniert nicht mehr fur Augenlid nach Mesh-Zusammenfuhrung
+- Erster Versuch: Geometry Nodes -> Vertex-Group-Gewichte -> Shader-Output (umstandlich, unprazise)
+- Losung: Zweite Haut-Textur (weiss fur Augenlid, schwarz fur Rest), direkt uber Texturkoordinate im Shader
+
+### 5.6 Augenbrauen und Wimpern
+- Warum feste Geometrie nicht funktioniert (kurz, Verweis auf Erwahnung in 4.2)
+- Gescheiterter Versuch mit Hair-Particles
+- Funktionierender Hair-Modifier-Ansatz: konkrete Umsetzung
+- Verbleibende Limitierungen und Verbesserungsmoglichkeiten
+
+### 5.7 Technische Umsetzung der Parametrisierung und Randomisierung
+- JSON-Schema-Eintrage fur Shape-Keys (das konkrete Schema, das in 4.3 nur abstrakt beschrieben wurde)
+- min/max-Range-Implementierung
+- Automatisches Sampling und Anwendung auf die Szene
+
+### 5.8 Szenenumbau und View-Layer-Architektur
+- Warum der Umbau notig war (kurze Motivierung)
+- Technische Schritte: 3 Szenen -> 1 Szene mit 3 ViewLayern
+- Konkrete Anderungen am Compositing-Graph, Material-Zuweisungen, Render-Einstellungen
+
+### 5.9 Performance-Optimierungen
+- **Hierhin kommt der Implementierungsteil aus `0X_PerformanceVerbesserung.tex`**
+- Luminanz-Caching fur Haut-Textur: was im Code geandert wurde
+- Compositing-Graph-Wiederverwendung
+- Anpassung an Sklera-Generierung
+- NUR die Code-Anderungen, nicht die Profiling-Analyse (die ist in 7.2)
+
+### 5.10 Implementierung der Experimentwerkzeuge
+- Benchmark-Runner (Worktree-Setup, Commit-basierte Benchmarks, CSV-Logging) -- wichtig fur Reproduzierbarkeit
+- Detail-Logging fur Experiment 1.2
+- Datenextraktions- und Vorbereitungstools -- wichtig fur Datensatzqualitat
+- Erweiterungen am Parameter-Picker -- nur kurz erwahnen, UI-Komfortfeatures nicht breittreten. Nur Features, die echten Einfluss auf die Luminanz-Kalibrierung hatten, ausfuhrlicher
+
+---
+
+## Kapitel 6: Versuchsaufbau
+
+Beschreibt die konkreten Experimente: warum, womit, wie ausgewertet. Ca. 8-12 Seiten. In Kap. 6 keine Skriptnamen oder Tool-Details (die stehen in 5.10), sondern methodische Beschreibungen (was wurde gefiltert, nach welchen Kriterien).
+
+### 6.1 Hardware und Testumgebung
+- Hardware-Specs, Software-Versionen
+- Gilt fur alle Experimente
+
+### 6.2 Gemeinsame Auswertungsprinzipien
+- Wiederholungen / Seeds
+- Deskriptive Statistik (Lage- und Streuungsmasse)
+- Reproduzierbarkeit
+- Allgemeine Prinzipien der statistischen Auswertung
+- Experiment-spezifische Inferenzstatistik (BCa Bootstrap, Wilcoxon etc.) jeweils in den Experiment-Abschnitten, NICHT hier
+
+### 6.3 Experiment 1.1: Globaler Laufzeitvergleich
+- Ziel und Begrundung
+- **Explizit als faktorielles 2x2-Design rahmen:**
+  - Faktor A: Implementierungsstand (Baseline vs. Current)
+  - Faktor B: Blender-Version (4.5 vs. 5.0)
+  - Vorsichtig formulieren: "Damit konnen Effekte des Implementierungsstands und der Blender-Version systematisch gegenubergestellt und potenzielle Interaktionen sichtbar gemacht werden." (Keine perfekte kausale Trennung behaupten, da Codepfade nicht perfekt orthogonal.)
+- Gemessene Timing-Metriken und warum diese
+- Anzahl Durchlaufe, Bilder pro Durchlauf, Auflosung
+- Erwartete Ergebnisse / Hypothesen
+
+### 6.4 Experiment 1.2: Detaillierte Laufzeitanalyse und Optimierungsevaluation
+- **6.4.1 Instrumentierung und gemessene Phasen**
+  - Hierhin kommt die Phasenbeschreibung aus `0X_PerformanceVerbesserung.tex` (t_camera, t_tex_init, t_skin_lum, t_sclera etc.)
+- **6.4.2 Auswahl der Optimierungsziele**
+  - Nach welchen Kriterien wurde entschieden, was optimiert wird
+- **6.4.3 Versuchsaufbau des Vorher-Nachher-Vergleichs**
+  - Zwei Konfigurationen: unoptimiert vs. optimiert (beide Blender 5)
+  - Durchlauf-Parameter
+
+### 6.5 Experiment 2: YOLO-Training
+- Ziel und Begrundung: Verbessert periorbital Formvariation die Segmentierung auf echten Daten?
+- Hypothese
+- **6.5.1 Datensatzquellen**
+  - Synthetische Trainingsdaten: Baseline vs. Current, je 5000 Bilder, Generierungsparameter
+  - Externer Testdatensatz: 500k-Dataset, Reduktionsverfahren (SSIM + Diversity-Ranking)
+  - Glasklar machen: Testdatensatz ist komplett separat von den Trainingsdaten
+- **6.5.2 Trainings-/Validierungsaufteilung**
+  - 80/20-Split auf synthetischen Daten, 15 Seeds pro Bedingung
+  - YOLO-Modell und Trainingsparameter
+- **6.5.3 Vorverarbeitung und Filterung**
+  - Luminanz-Kalibrierung: Workflow, Quantil-basierte Grenzen
+  - Okklusionsschwelle und Filterungskriterien
+- **6.5.4 Metriken**
+  - Primarmetrik festlegen (z.B. Dice oder IoU) -- methodisch starker als alle Metriken gleichwertig zu berichten
+  - Sekundarmetriken: geometrische Fehlermasse (Centroid-Error, Ellipsen-Fit-Error)
+  - Experiment-spezifische Inferenzstatistik (Wilcoxon, BCa Bootstrap CI) hier statt in 6.2
+
+---
+
+## Kapitel 7: Ergebnisse (weitgehend unverandert)
+
+Faustregel: Kap. 7 zeigt, was die Daten zeigen und welche unmittelbaren Schlusse sich ergeben. Kap. 8 (Diskussion) bewertet das wissenschaftlich und zeigt Grenzen auf.
+
+### 7.1 Experiment 1.1: Untersuchung der Laufzeit
+(bereits gut geschrieben)
+
+### 7.2 Experiment 1.2: Detaillierte Konfigurationszeit-Analyse
+- **Hierhin kommt die Profiling-Analyse aus `0X_PerformanceVerbesserung.tex`**: Bottleneck-Identifikation, Beurteilung des Optimierungspotenzials
+- Vorher/Nachher-Vergleich der Optimierungen
+- Story: Exp 1.1 zeigte hohe Config-Zeit -> detailliertes Profiling -> Bottlenecks identifiziert -> Optimierungen implementiert (Verweis auf 5.9) -> Exp 1.2 misst den Effekt
+
+### 7.3 Experiment 2: YOLO-Training
+(bereits gut geschrieben)
+
+---
+
+## Auflosung von `0X_PerformanceVerbesserung.tex`
+
+Der Inhalt verteilt sich auf drei Stellen:
+
+| Inhalt | Ziel |
+|--------|------|
+| Phasenbeschreibungen (was jede Timing-Phase misst) | -> **6.4.1** Versuchsaufbau Exp 1.2 |
+| Profiling-Analyse, Bottleneck-Identifikation | -> **7.2** Ergebnisse Exp 1.2 |
+| Code-Anderungen (Luminanz-Caching, Sklera etc.) | -> **5.9** Implementierung |
+
+---
+
+## Zusammenfassung
+
+| Nr. | Kapitel | Status | Geschatzter Umfang |
+|-----|---------|--------|--------------------|
+| 4 | Methodik | **NEU zu schreiben** | 4-8 Seiten |
+| 5 | Implementierung | Teilweise geschrieben, umstrukturieren | 15-20 Seiten |
+| 6 | Versuchsaufbau | Teilweise geschrieben, erweitern | 8-12 Seiten |
+| 7 | Ergebnisse | Gut geschrieben, kaum Anderungen | ~30 Seiten |
+
+---
+
+## Schreibhinweise
+
+1. **Exp 1.2 als iterative Folgeanalyse einordnen:** Im Fliesstext explizit machen, dass Exp 1.2 aus den Befunden von Exp 1.1 hervorgegangen ist. Sonst fragt sich der Leser, warum es zwei Performance-Experimente gibt.
+
+2. **"Keine medizinische Grundlage" in 5.4 sachlich formulieren:** Statt "keine medizinische Grundlage" besser: "Die modellierten periorbitalen Formvariationen wurden heuristisch und anhand visueller Plausibilitat entwickelt. Sie beanspruchen keine anthropometrisch oder medizinisch validierte Abbildung realer Populationen."
+
+3. **Kap. 7 Titel:** Ob "Ergebnisse" oder "Ergebnisse und Analyse" ist Geschmackssache. Bei separatem Diskussionskapitel (Kap. 8) ist "Ergebnisse" allein etwas sauberer, da "Analyse" schnell zur Interpretation einladt, die eigentlich in die Diskussion gehort.
+
+4. **Kap. 7 vs. Kap. 8 Grenze:** Kap. 7 zeigt, was die Daten zeigen und welche unmittelbaren Schlusse sich ergeben. Kap. 8 (Diskussion) bewertet das wissenschaftlich, ordnet es in den Forschungskontext ein und zeigt Grenzen auf.

Prewrite/Implementierung.md

@@ -0,0 +1,84 @@
+1. Projektstruktur
+	1. (Wie ist das Repository aufgebaut)
+2. Ablauf der bestehenden Pipeline?
+3. Allgemeine Änderungen an den bestehenden Scripts:
+	1. Upgrade auf Blender 5
+		- Eigentlich nur eine Änderung nötig: im Blender Compositing-Graph ist pro Output-Textur eine Output-Node nötig (statt vorher einer Node für alle)
+	2. unwichtige Änderung: konsequente Type-Annotations im gesamten Projekt
+	3. Möglichkeit einen bestimmten Seed in Config-Datei einzutragen
+	4. Möglichkeit, dass die modifizierte Szene abgespeichert wird (für Debugging)
+4. Umbau der Pipeline
+	1. Augenlid mit Shape-Key implementieren
+		1. Probleme mit dem alten Ansatz
+			- Hat ein getrennten Modell für Augenlid
+				- -> Kann nicht vollständig geschlossen werden
+				- -> passt sich nicht an Auge / periorbitale Haut an
+		2. Lösung: Modell weg -> mit Shape-Key umsetzen
+			- Script muss angepasst werden um statt objekt-Rotation festzulegen den Shape-Key zu steuern
+			- Vorteile:
+				- Erlaubt es das Auge vollständig zu schließen
+				- Mit Wrap-Modifier an das Auge angeschmiegt
+	2. Problem: Augenlid-Segmentierungsmaske funktioniert jetzt nicht mehr mit Cryptomattes
+		1. erster Versuch: Kompliziert Gewichte für Augenlid-Vertex-Group mit GEometry Nodes an Haut-Shader reichen und mit extra Shader-Output ausgeben
+			- Umständlich und unpräzise (sind an Geometrie-Detail gebunden)
+		2. bessere Lösung: Verwenden eine zweite Haut-Textur, in der Pixel des Augenlids weiß und der Rest schwarz ist
+			- Vorteil: Viel einfacher, kann direkt mit Texturkoordinate im Haut-Shader ausgelesen und direkt an den extra Shader-Output übergeben werden
+	3. Wimpern und Augenbrauen
+		1. Probleme mit dem alten Ansatz
+			- War vorher feste Geometrie -> kann nicht an Shapekeys angepasst werden
+		2. erster Versuch mit Hair-Particles
+			- funktioniert nicht gut -> Die Wimpern gehen kaputt, wenn man das Augenlid bewegt
+		3. zweiter Versuch mit Hair-Modifier (gut)
+			- funktioniert deutlich besser
+			- aber nicht perfekt
+			- Ansätze für zukünftige Verbesserung anreißen (z. B. Variation in Länge/Dicke und Winkel durch Geometrie Nodes möglich)
+	4. Periorbitalregion
+		1. Umsetzung mit Shape-Keys
+			- TODO: Es so klingen lassen, als hätte ich das nicht in zwei Stunden hingeklatscht
+			- TODO: Irgendwie klar machen, dass die absolut keiner medizinischen Grundlage folgen, sondern einfach nach Gefühl gebastelt sind 😅
+		2. Problem: Bestimmte Kombinationen von Shape-Keys kollidieren, weil sie doch nicht quasi-Orthogonal sind (z. B. kollidieren einige mit dem geschlossenen Augenlid)
+			- Lösung: Korrektur-Shape-Keys mit Driver ansteuern
+		3. Änderung an Script:
+			- Konfiguration: In Json-Config kann einfach für jeden Shape-Key den man steuern möchte der Name des Keys mit min- und max-Wert eingetragen werden
+			- Anwendung: Für alle in der Json eingetragenen Shape-Keys wird automatisch ein zufälliger Wert innerhalb der konfigurierten Range gezogen und für den Shapekey angewendet.
+5. Implementierung für die Tests:
+	1. Experiment 1.1: Performance Benchmarks
+		1. (wahrscheinlich nicht so interessant): Zeit wird mit time.perf_counter_ns() gemessen und als CSV-Datei gespeichert
+		2. Benchmark-Runner-Script:
+			1. In Config-Json kann eingetragen werden:
+				- Welche Benchmarks laufen. Für jeden Benchmark:
+					- Name,
+					- Git-Commit im Repo
+					- Ob mit Blender 4 oder 5 ausgeführt werden muss
+				- Wie viele (X) Bilder pro Durchlauf
+				- Wie viele (Y) Durchläufe
+				- Output-Verzeichnis
+			2. Benchmark Runner macht dann für jeden konfigurierten Benchmark:
+				1.  in einem Git-Worktree das Repo mit dem jeweiligen Commit auschecken
+				2. Passt config im Worktree an, sodass X viele Bilder generiert werden und diese als Unterordner im konfigurierten Benchmark-Output landen
+				3. Führt Y Durchläufe durch
+		3. Auswertung mit Jupyter Notebook
+	2. Experiment 1.2: Detaillierte Performance Auswertung
+		- ??? wie viel hiervon in der Methodik?
+		- zusätzlich erfasste Werte
+		- ggf. für das eine Ding Mikrobenchmarks
+		- konkrete Änderungen
+			- Haut-Luminanzwerte und Compositing-Graph cachen
+			- Anpassung an Sklera-Generierung nach den Mikrobenchmarks
+				- Das ist sehr technisch und der Effekt am Ende praktisch irrelevant
+	3. Experiment 2: Yolo Training
+		1. 500k-Datenextraktor? Oder reicht es, dass in Methodik beschrieben ist, wie die Daten extrahiert wurden
+		2. Verbesserungen/Änderungen an LEyes Parameter Picker (nur ein bisschen, nicht zu sehr ins Detail gehen)
+			1. Output Median percentiles 5, 10, 90 and 95
+			2. Fixed metrics changing when switching to different image
+			3. Add mask overlay controls for alpha transparency and bounding box display
+			4. Add dirty-state and ask for confirmation on image change
+			5. Don't continuously Refresh stats while drawing, only on release
+			6. Add deadzone functionality with adjustable borders
+
+
+Was mir gerade noch zur Implementierung eingefallen ist: Es gab einen Umbau der Blender-Datei von drei Szenen auf eine Szene mit drei Viewlayers.
+
+Ich habe noch etwas, das irgendwie in der Arbeit einsortiert werden muss: Der erste Performance benchmark hat veranlasst, dass die versuchete die Performance weiter zu verbessern. Dementsprechend wurde der zweite detailliertere Benchmark gemacht, dann Optimiert, dann nochmal Benchmark für vorher nacher vergleich der optimierung. Wie soll ich das einordnen. Die Finalen Ergebnisse sind klar, die gehören ins Auswertungskapitel, aber der vorherige Detaillierte benchmark um zu entscheiden, was optimiert werden soll. Ist das ein eigener Abschnitt/Kapitel oder so? Ich habe jetzt gerade eine Rohschrift (unfertig) in "@MasterLatex/content/0X_PerformanceVerbesserung.tex". Das muss irgendwie einsortiert werden.
+
+Ich Grunde möchte ich eine gute Struktur haben, was kommt in Methodik, was kommt in Versuchsplanung (und Versuchsauswertungsplanung), was ist Implementierung. Wie soll ich diese Kapitel strukturieren.

Prewrite/Änderungen an Szene und Code/Compositor Rewrite.md

@@ -203,4 +203,7 @@ Abbildung CYC demonstriert die Effekte von Kantenglättung und verschiedenen Tex
 
 Der Code für das Generieren des Compositing Graphen (`nodetree.py`) wurde so angepasst, dass diese Schwellwert-Berechnung angewandt wird. Außerdem wurden alle Verbindungen mit der alten Cryptomatte-Maske des Augenlid-Objekts durch die Schwellwert-Node binärisierte "Eyelid Mask" ersetzt. (TODO: vielleicht ei
 
-![[final_compositing_tree.png]]
+![[final_compositing_tree.png]]
+
+# Pupille verkürzen
+Da nur noch ein Modell für alle Ansichten verwendet wird, und dieses einen langen Zylinder am Ende hat, kam es manchmal vor, dass eine Maske generiert wurde, bei der hinten dieser Pimmel sichtbar ist. In der alten Implementierung war er nur in der Hauptszene lang und die anderen hatten ein kurzen. Er wurde in der neuen verkürzt. Es ist nicht wichtig für uns, dass er lang ist.

Prewrite/Änderungen an Szene und Code/Random Änderungen.md

@@ -10,6 +10,3 @@ Um die Sclera-Textur zu erzeugen wird in der alten Implementierung zunächst ein
 
 Die ersten beiden Schritte lassen sich zusammenfassen. Statt erst eine weiße Textur zu erzeugen (`np.ones`) und die Pixel dann grau (`tex[::3] = grau`) zu machen, kann in einem einzigen Schritt ein Array mit den korrekten Grauwerten erzeugt werden (`np.full(size, [grau,grau,grau,1])`). Tatsächlich kommt der meiste Performance-Vorteil durch das ersetzen von `tex[::3]`
 
-
-# Pupille verkürzen
-Da nur noch ein Modell für alle Ansichten verwendet wird, und dieses einen langen Zylinder am Ende hat, kam es manchmal vor, dass eine Maske generiert wurde, bei der hinten dieser Pimmel sichtbar ist. In der alten Implementierung war er nur in der Hauptszene lang und die anderen hatten ein kurzen. Er wurde in der neuen verkürzt. Es ist nicht wichtig für uns, dass er lang ist.