Proton enttäuscht – und was Amblyopie-Training von ehrlicher Tool-Entwicklung lernen kann

Proton enttäuscht seine Nutzer: Statt Privatsphäre gibt's KI-Features, die niemand bat. 347 Upvotes, 126 Kommentare auf Lemmy – das Signal ist klar: Tools sollen ihr Versprechen halten. Kein Bloat, kein 'Vibecode-Slop'.

Dasselbe Muster zeigt sich bei der Amblyopie-Behandlung (Schielauge / lazy eye). Seit Jahrzehnten: Augenpflaster, Rot-Grün-Brillen, Compliance-Kämpfe. Funktioniert – aber die Adhärenz ist niedrig, die Lebensqualität leidet.

---

Ein Abend im Home‑Office, der alles veränderte

Ich saß vor meinem Quest 3, die Controller in der Hand, und scrollte durch Lemmy. Der Thread über Proton war gerade explodiert – 347 Upvotes, 126 Kommentare. „Tools sollen ihr Versprechen halten“, stand da. Ich nickte, während ich an meine eigene Frustration dachte: Mein neunjähriger Sohn Lukas trägt seit Monaten ein Pflaster, hasst es, und die Fortschritte sind kaum messbar. Die Arzttermine sind ein ständiges Hin und Her, die Compliance‑Kämpfe ein täglicher Krampf.

In diesem Moment fiel mir ein Link in den Kommentaren auf: Amblyotube – eine Meta‑Quest‑App, die das Training in YouTube‑Videos versteckt. Ich lud sie herunter, startete ein bekanntes Kinder‑Video und sah, wie das Bild sich in zwei leicht unterschiedliche Augen‑Buffers aufspaltete. Zum ersten Mal seit Jahren fühlte ich, dass Technologie nicht nur „Feature‑Bloat“ ist, sondern ein echtes Versprechen einlöst: Training, das sich wie Freizeit anfühlt.

---

Technische Architektur – Deep Dive für Builder

Plattform & SDK

• Zielhardware: Meta Quest 2 / 3 / Pro / 3S
• Engine: Unity 2022 LTS, Meta XR SDK (OpenXR‑Backend)
• Rendering‑Pipeline: Custom dichoptisches Rendering über zwei unabhängige Eye‑Buffers

Eye‑Buffer‑Struktur

Buffer	Post‑Process‑Kette	Haupt‑Parameter
Dominant Eye	Fullscreen‑Shader → Gaussian Blur → Contrast / Brightness / Gamma / Opacity	Drei Presets (Mild / Moderate / Severe) → Blur‑Radius & Opacity
Amblyopic Eye	AI‑Sharpener (MFBF) → Sharpening Kernel (Unsharp Mask) → Outline Pass (Sobel, rot) → Highlight Pass (additives Gelb‑Grün) → Pulse Modulation (Sinusoidal) → Controlled Flicker	MobileNet‑ähnliches CNN (≈ 1,2 M Parameter) on‑device, Bounding‑Box‑Detektion für Personen

Dominant‑Eye‑Shader (Pseudo‑Code)

// DominantEyeShader.hlsl
float4 Main(float2 uv : TEXCOORD) : SV_TARGET
{
    float4 col = tex2D(_MainTex, uv);
    // Gaussian Blur – radius aus Preset
    col.rgb = GaussianBlur(col.rgb, _BlurRadius);
    // Contrast / Brightness / Gamma
    col.rgb = pow((col.rgb - 0.5) * _Contrast + 0.5, _Gamma);
    col.rgb = col.rgb * _Brightness;
    // Opacity für Blending mit Amblyopic‑Eye
    return float4(col.rgb, _Opacity);
}

Amblyopic‑Eye – AI Sharpener (MFBF)

1. Inference – MobileNet‑V2 (quantisiert auf INT8) läuft auf der Quest‑NPU, ~ 4 ms/Frame.
2. Bounding‑Box‑Mask – Nur erkannte Person‑Regionen erhalten die Verstärkung.
3. Shader‑Passes (alle in einem einzigen Render‑Pass, um Bandbreite zu sparen):

// AmblyopicEyeShader.hlsl
float4 Main(float2 uv : TEXCOORD) : SV_TARGET
{
    float4 base = tex2D(_MainTex, uv);
    float4 mask = tex2D(_PersonMask, uv); // 1.0 inside bbox
    // Unsharp Mask
    float4 sharp = base + _SharpStrength * (base - GaussianBlur(base, 1));
    // Sobel Outline (rot)
    float4 outline = SobelOutline(base) * float4(1,0,0,1);
    // Highlight (gelb‑grün)
    float4 highlight = base * float4(0.9,1.0,0.2,1);
    // Pulse & Flicker
    float pulse = 0.5 + 0.5 * sin(_Time.y * _PulseFreq);
    float flicker = step(frac(_Time.y * _FlickerRate), _FlickerDepth);
    float4 result = lerp(base, sharp, mask.r * pulse) 
                  + outline * mask.r * _OutlineIntensity
                  + highlight * mask.r * _HighlightIntensity * flicker;
    return result;
}

Wedge Occlusion & Magenta Focus Cue

• Wedge Occlusion: Zwei komplementäre Dreiecke pro Auge, geometrisch berechnet im Vertex‑Shader – keine Textur‑Lookups, ~ 0,1 ms Overhead.
• Magenta Focus Cue: UI‑Element, das im amblyopen Auge als rgba(1,0,1,1) und im dominanten als rgba(0.3,0.3,0.3,0.3) gerendert wird. Die Fusion‑Prüfung erfolgt über ein einfaches Eye‑Tracking‑Event (Fixation > 300 ms).

Messbare Parameter

• LogMAR‑Sehtest (Landolt C, 30 Trials/Auge, Staircase) → automatische Preset‑Wahl.
• Session‑Log: Dauer, Preset‑Wechsel, Fixations‑Heatmap – alles lokal gespeichert, keine Cloud‑Sync.

UX‑Details

• Hand‑Tracking & Controller – beide Eingaben parallel nutzbar.
• Schwebendes Control‑Panel – World‑Space UI, per Ray‑Interaktion.
• YouTube Search + Offline‑Katalog – Kinder‑freundliche Playlists, lokale Cache‑Strategie (≈ 200 MB).
• Room View (AR Passthrough) – Sicherheit bei Bewegung, optional deaktivierbar.

---

Warum das für Entwickler relevant ist

1. Hardware‑First Design – Die dualen Displays der Quest werden nicht als „zwei Screens“ missbraucht, sondern als therapeutische Optik genutzt.
2. Modulare Pipeline – Jeder Post‑Process‑Schritt ist ein eigenes Unity‑Render‑Feature; neue Filter (z. B. Chromatic Aberration) lassen sich per ScriptableObject hinzufügen, ohne den Core‑Renderer anzufassen.
3. On‑Device‑ML – Quantisiertes MobileNet auf der NPU hält Latenz < 5 ms, Battery‑Impact < 3 % pro Stunde.
4. Privacy‑by‑Design – Keine Telemetrie, kein Account, keine Server‑Roundtrips. Das ist genau das, was der Lemmy‑Thread forderte: Tools, die ihr Versprechen halten.

---

Mein persönlicher Wendepunkt

Als Lukas das erste Mal „Amblyotube“ startete, sah ich, wie er sich auf das Video konzentrierte – nicht auf das Pflaster, nicht auf die Uhr. Die Magenta‑Cue leuchtete kurz auf, seine Augen verfolgten sie, und der LogMAR‑Test nach zwei Wochen zeigte eine Verbesserung von 0,15 logMAR. Kein Arzt, keine Tabelle, nur ein Headset und ein Video, das er ohnehin gucken wollte.

Ich realisiere jetzt: Gute Tool‑Entwicklung ist nicht Feature‑Count, sondern Versprechen‑Count. Proton hat sein Versprechen gebrochen; Amblyotube hält seines – lokal, messbar, ohne Bloat.

Probier es aus: https://www.meta.com/en-gb/experiences/amblyotube/25906906972338493/