Masterarbeit-Obsidian-Vault/Prewrite/Kontext Periorbitale Formvariation.md

Kontext: Periorbitale Formvariation

Zusammenfassung aller relevanten Infos zur Planung und zum Schreiben der Abschnitte 4.2 (Methodik) und 5.4 (Implementierung) zur periorbitalen Formvariation.

---

Was bereits geschrieben ist (Stand: 2026-04-03)

Methodik 4.2 (fertig geschrieben)

Datei: 04_Methodik/2_KonzeptFormvariation.tex

Deckt ab:

• Motivation: Bestehende Pipelines nutzen feste Modelle oder PCA (semantisch opak)
• Wisetchats TFM als konzeptuelle Referenz
• Warum Shape-Keys (vs. diskrete Modellsammlungen, PCA, Skelett-Rigs, prozedural)
• Zentrale Eigenschaft: lineare Superposition, einzeln parametrierbar
• Kurze Erwahnung von Konsequenzen (Wimpern/Brauen, Augenlid, Korrekturmechanismen)
• Verweis auf \fref{sec:impl_periorbital} fur Details
• Formulierung: "nicht populationsstatistisch validiert, sondern anatomisch motiviert, visuell plausibel"

Implementierung 5.6 Parametrisierung (fertig geschrieben)

Datei: 05_Implementierung/6_Parametrisierung.tex

Deckt ab:

• Ubersichtstabelle aller randomisierten Parameter (Shape-Keys als einziger neuer Eintrag)
• JSON-Config-Schema mit allen 9 Shape-Keys und ihren Bereichen (als Listing)
• Erklarung ECF_weight negativer Bereich (-0.3): Basismodell hat bereits leichte Falte
• Config-Parsing und Validierung
• Sampling: uniform pro Bild, unabhangige Ziehungen
• Verweis auf Korrektur-Shape-Keys in 5.4
• Seed/Reproduzierbarkeit
• Laufzeit: vernachlassigbar (t_shape_keys)

Implementierung 5.3 Augenlidmodell (fertig geschrieben)

Datei: 05_Implementierung/3_Augenlidmodell.tex

Deckt ab:

• Probleme des alten Modells (separate Geometrie, Rotation statt Shape-Key)
• Neues Augenlid als Teil des Gesichts-Meshes mit Shape-Keys
• Catmull-Clark-Subdivision, Crease an Lidkante
• Clipping-Problem und Shrinkwrap-Modifier als Losung
• Bilder sind vorhanden

---

Was in 5.4 rein muss (noch zu schreiben)

Datei: 05_Implementierung/4_PeriorbitaleFormvariation.tex

5.4 behandelt ausschliesslich die 3D-Modellierungsseite: Was stellen die Shape-Keys anatomisch dar, wie wurden sie im Mesh modelliert, und wie funktionieren die Korrektur-Driver. Keine Uberschneidung mit Config/Randomisierung (das steht in 5.6) oder konzeptuelle Begrundung (das steht in 4.2).

Geplante Struktur

5.4.1 Modellierte Formmerkmale

• Tabelle aller 9 Shape-Keys mit anatomischer Bedeutung und Abbildung (min vs. max)
• Kategorisierung:
  • Positionale Merkmale: ENC_x, ENC_y, EXC_x, EXC_y (verschieben die Kanthi)
  • Winkelmerkmale: ENC_angle (Lidspaltenneigung am medialen Kanthus)
  • Formmerkmale: ECF_weight (Epikantusfalte), SPC_weight (Oberlidfalte/Suprapalpebral Crease), STF_weight (Supratarsalfalte), LPF_depth (Unterlidfurche)
• Bezug zu Wisetchats 17 Features: welche umgesetzt, welche nicht und warum
  • PLATZHALTER: Grunde fur das Weglassen der restlichen 8 Features mussen noch recherchiert werden
  • Bekannt: mindestens ein Unteraugen-Parameter kollidiert mit dem Shrinkwrap-Modifier (2mm Mindestabstand)

5.4.2 Modellierung und Grenzen

• Heuristische Modellierung in Blender anhand visueller Plausibilitat
• Mesh-Topologie: Balanceakt zwischen Detail fur Furchen/Falten und Regularitat fur saubere Subdivision
• Herausforderung oberes Augenlid: Tarsus-Falten (ECF, STF) auf dunner Haut vs. umliegende Fettgewebe-Strukturen (SPS, STC, SPC, PNS, PTF)
• Technische Einschrankung Shrinkwrap: Kollision mit Unteraugen-Parametern (PLATZHALTER fur Details)

5.4.3 Korrektur-Shape-Keys mit Drivern

• Problem: Unabhangiges Sampling (beschrieben in 5.6) kann bei bestimmten Kombinationen Artefakte erzeugen
• Losung: Korrektive Shape-Keys im Blender-Modell, gesteuert uber Blender-interne Driver
• Mechanismus: Driver berechnet Gewicht = Produkt der auslosenden Shape-Keys
  • Korrektur greift nur, wenn beide stark
  • Pipeline-Code muss nichts uber Korrekturen wissen, da Blender die Driver automatisch auswertet
• Konkretes Beispiel: Augenlid-Schliessung x ENC_y -> Korrektur am Endokanthion bei geschlossenem Auge mit stark verschobenem Endokanthion
• Weitere Korrektur-Paare (PLATZHALTER)

5.4.4 Randomisierung zur Laufzeit

• ENTFALLT: Wird komplett in 5.6 behandelt. Nur kurzer Verweis auf 5.6 notig.

---

Die 9 implementierten Shape-Keys (aus config.json)

Shape-Key	Bereich	Anatomische Bedeutung
ECF_weight	[-0.3, 1.0]	Epikantusfalte (mediale Kanthusbedeckung). Negativ, da Basismodell bereits leichte Falte hat.
ENC_angle	[0.0, 1.0]	Kanthalwinkel am Endokanthion (Neigung der Lidspalte am medialen Kanthus)
ENC_x	[0.0, 1.0]	Horizontalposition des Endokanthion (medial-lateral)
ENC_y	[0.0, 1.0]	Vertikalposition des Endokanthion (superior-inferior)
EXC_x	[0.0, 1.0]	Horizontalposition des Exokanthion (medial-lateral)
EXC_y	[0.0, 1.0]	Vertikalposition des Exokanthion (superior-inferior)
SPC_weight	[0.0, 1.0]	Tiefe der Oberlidfalte (Suprapalpebral Crease / Double Eyelid vs. Monolid)
LPF_depth	[0.0, 1.0]	Tiefe der Unterlidfurche (Lower Palpebral Fossa)
STF_weight	[0.0, 1.0]	Supratarsalfalte (Auspraegung der Lidfalte oberhalb des Tarsus)

Wisetchats 17 Augenattribute (davon 9 umgesetzt)

Wisetchat definiert 17 Eye Attributes: 10 unsigned (0-1) und 7 signed (-1 bis 1). Davon wurden 9 fur HEyes implementiert. Die restlichen 8 wurden nicht umgesetzt.

Nicht umgesetzt (PLATZHALTER - Grunde mussen noch recherchiert werden):

• Vermutlich: Features ausserhalb des sichtbaren Bereichs in NIR-Eye-Tracking-Bildern
• Vermutlich: Features, die mit der vorhandenen Mesh-Topologie nicht umsetzbar waren
• Bekannt: Mindestens ein Unteraugen-Parameter kollidiert mit Shrinkwrap-Modifier

Quasi-Orthogonalitat (aus Wisetchat)

Wisetchat definiert quasi-orthogonale Merkmale:

• Orthogonal: Features modifizieren verschiedene Vertex-Regionen, oder gleiche Region aber orthogonale Achsen (z.B. Breite vs. Hohe)
• Nicht orthogonal: Features uberlappen und modifizieren gleiche Vertices in ahnlicher Weise
• In extremen Kombinationen konnen Ergebnisse unplausibel sein, aber die meisten Kombinationen sind plausibel
• Fur problematische Kombinationen: Korrektur-Shape-Keys

Korrektur-Shape-Keys (aus Gesprach mit User)

• Existieren als Blender-interne Mechanismen (nicht im Python-Code)
• Gesteuert uber Blender-Driver: Gewicht = Produkt der auslosenden Shape-Keys
• Beispiel: Korrektur-Shape-Key fur Augenlid x ENC_y
  • Driver multipliziert Gewichte beider Shape-Keys
  • Korrektur wird nur vollstandig angewendet, wenn Augenlid zu IST UND ENC_y maximal verschoben
• Vorteil: Pipeline-Code (gaze_controller.py) setzt nur die Shape-Key-Werte, Blender wertet Driver automatisch aus

Technische Details aus dem Code

• Zielobjekt: "Skin" (das Periorbital-Geometrie-Mesh in Blender)
• Anwendung: gaze_controller.py, Methode random_skin_model_modification()
  • Holt Skin-Objekt und dessen shape_keys
  • Iteriert uber alle konfigurierten Shape-Keys
  • Zieht uniform aus [min, max]
  • Setzt Wert direkt auf den Blender Shape-Key
• Aufruf in Pipeline: nach random_eyeball_rotation(), vor Compositing
• Timing: RenderTimes.set_shape_keys (< 0.2ms, vernachlassigbar)

Offene Punkte / Platzhalter

1. Welche der 17 Wisetchat-Features wurden bewusst weggelassen und warum? User erinnert sich nicht genau. Bekannt: Shrinkwrap-Kollision bei mind. einem Unteraugen-Parameter. Wird ggf. nochmal uberarbeitet.
2. Weitere Korrektur-Shape-Key-Paare: Nur das Beispiel Augenlid x ENC_y ist bekannt. Weitere mussen in Blender recherchiert werden.
3. Min/Max-Bilder der Shape-Keys: User wird diese noch rendern. Pro Shape-Key: Minimum-Auspraegung vs. Maximum-Auspraegung.

Modellierungsherausforderungen (aus Augenfeatures.md)

• Oberes Augenlid besonders schwierig: dunne Falten des Tarsus (ECF, STF) auf dunner Haut, wahrend umliegende Furchen und Konvexitaten (SPS, STC, SPC, PNS, PTF) Eigenschaften des Fettgewebes darstellen
• Mesh-Topologie: Je simpler das Basis-Mesh, desto glatter die Subdivision-Oberflache. Aber genug Detail noetig fur Furchen und Falten.
• Basismodell stellt keinen Ethnotypen dar und entspricht keinem Durchschnitt
• Blender-Vorteil gegenuber Maya (Wisetchat): Shape-Keys sind Eigenschaften eines einzelnen Meshes, keine separaten Kopien. Topologie-Anderungen nach Shape-Key-Erstellung moeglich.