Kapitel 4 — Aux-Fenster

Neben dem Hauptfenster (3D-Viewport plus Inspector) verwaltet RadianceKit sieben weitere Fenster, die alle über das Help-Menü geöffnet werden. Die Liste ist von oben nach unten: User Guide (⌘?), Keyboard Shortcuts (⌘/), Open Training Logs… (öffnet keinen App-Fenster, sondern den Finder; deshalb hier nicht weiter behandelt), Manage Storage…, Pareto Dashboard… (⇧⌘D), Holdout Analysis… (⇧⌘H), BayesOpt Console… (⇧⌘B). Drei davon — Dashboard, Holdout, BayesOpt — sind eigenständige Analyse-Werkzeuge. Sie haben jeweils einen eigenen View-Model-Stack, lesen oder schreiben JSON-Dateien auf der Platte, und es gibt für jedes ein CLI-Argument, mit dem du das Fenster gleich beim App-Start auf eine bestimmte Datei zeigen lassen kannst (–dashboard-dir, –holdout-file, –bayesopt-autorun).

Die vier einfachen Fenster (User Guide, Keyboard Shortcuts, Manage Storage, plus die Untermenüpunkte Open Training Logs / Open Exports Folder) bekommen pro Steuerelement einen kurzen Eintrag. Die drei Analyse-Fenster sind ausführlicher dokumentiert — jeweils mit einer Einleitung, die erklärt was du im Fenster siehst, wann du es öffnen solltest und wie du das angezeigte Bild interpretierst.

Am Ende des Kapitels gibt es einen Querverweis-Abschnitt zum Inspector des Hauptfensters: was du im Live-Loss-Chart und in der Gaussian-Count-Anzeige während eines laufenden Trainings sinnvoll ablesen kannst.

User Guide (W1–W4)

Was es ist: Ein eingebautes Hilfefenster, das die bei der App mitgelieferte guide_<sprache>.md rendert. Die Sprache wird aus den Settings (Tab General → Language) oder, wenn dort „System" steht, aus den macOS-Sprachpräferenzen abgeleitet. Layout ist klassisch: links Sidebar mit allen Überschriften, rechts der Fließtext.

Wenn du eine schnelle Erinnerung an einen einzelnen Punkt brauchst — also als Stichwort-Ersatz. Die ausführliche Referenz ist dieses Manual; das eingebaute Hilfefenster ist eher das, was eine –help auf der Kommandozeile wäre. Es wird bei jedem App-Release mit aktualisiert, aber inhaltlich oberflächlicher gehalten.

W1NavigationSplitView (Sidebar + Detail)

WO

Help → User Guide (⌘?)..

TECHNISCH

Zweispalt-Layout mit schmaler Sidebar (mindestens 180 pt breit) für den Inhaltsbaum und einem scrollbaren Detail-Bereich für den eigentlichen Markdown-Inhalt. Das Fenster hat eine Mindestgröße von 700 × 500 pt. Beim ersten Öffnen lädt das Fenster die passende guide_<lang>.md aus dem App-Bundle (Fallback guide_en.md), parst sie in Block-Records (Überschriften H1–H4, Absätze, Listen, Tabellen, Trennlinien) und extrahiert separat die Überschriften-Struktur für die Sidebar. Inline-Formatierung (Bold, Italic, Code-Span) wird über die eingebaute Markdown-Engine gerendert. Die Sprache wird aus den App-Einstellungen gelesen, mit dem Spezialfall Chinesisch (zh-Hans) und Brasilianisches Portugiesisch (pt-BR), die als volle Locale-Tags behalten werden, weil sich diese Varianten von zh bzw. pt unterscheiden.

W2List (Heading-Sidebar)

WO

Linke Spalte im User-Guide-Fenster..

TECHNISCH

Liste über alle H2- und H3-Überschriften des aktuellen Markdown-Dokuments. H2-Einträge erscheinen ohne Einrückung mit Medium-Schriftgewicht, H3-Einträge mit 16 pt Einrückung links und reduziertem Foreground-Style. H4 und tiefer werden ignoriert, weil die Tiefe sonst die Sidebar unübersichtlich macht. Anker-IDs werden aus dem Heading-Text per Slugifizierung erzeugt (lowercase + Spaces zu Dashes + Filterung auf Letters/Numbers/Dashes — derselbe Algorithmus, den GitHub für seine Markdown-Anker verwendet, sodass auch externe URLs zur Doku potenziell auf denselben Anker landen würden). Die Liste verwendet den nativen macOS-Stil.

W3Button (Heading → Anchor-Sprung)

WO

Pro Sidebar-Zeile ein Button..

TECHNISCH

Jeder Sidebar-Eintrag ist ein Button, der den aktuellen Anker setzt, optisch aber wie ein Listeneintrag aussieht. Eine Beobachter-Variable triggert dann den Scroll-Sprung zum entsprechenden Anker mit einer weichen Animation über 0,3 s. Nach dem Sprung wird der Anker-Wert zurückgesetzt, damit der nächste Klick auf denselben Anker wieder feuert (sonst würde der Beobachter nicht erneut auslösen, weil sich der Wert nicht geändert hat).

W4ScrollView (Detail-Inhalt)

WO

Rechte Spalte..

TECHNISCH

Scrollbarer, vertikal-stapelnder Inhaltsbereich mit Lazy-Rendering, weil längere Guides leicht über 200 Markdown-Blöcke haben können — eine nicht-lazy Variante würde alle gleichzeitig instanziieren. Jeder Block bekommt eine eigene ID, entweder den Heading-Anker (für sprungbare H1–H3) oder einen Index-Platzhalter. Maximalbreite ist 720 pt, Padding 32 horizontal / 24 vertikal, sodass lange Zeilen ein gut lesbares Layout behalten. Tabellen werden zellenweise mit horizontalen Stacks und Trennlinien gerendert; Inline- Code durch die eingebaute Markdown-Engine. Echte Codeblöcke werden aktuell als Paragraph behandelt — eine bekannte Einschränkung des Help-Fensters.

Keyboard Shortcuts (W5–W6)

Statische Referenz-Liste in fünf Sektionen. Navigation: Mouse Drag (Orbit/Fly), Shift+Drag/Right-Drag (Pan), Scroll (Zoom), WASD (Fly-Through-Bewegung), Q/E (Up/Down), F (Toggle Orbit/Fly), Double-click (Re-center), Cmd+Scroll (FoV-Adjust). Views: R (Reset Camera), T (Auto-Rotation), P (Camera Playback), B (Background-Cycle), 0–9 (Springe zu Training-Cam 1=10%/5=50%/0=last), Left/Right Arrow (Prev/Next Cam). Capture: S (Screenshot to Desktop), V (Turntable-Video), C (Copy Camera Info). Editor: Tab (Edit-Modus), Click/Drag (Paint-Select), Option+Click (Deselect), X / Delete (Selektion löschen), Cmd-Z (Letzte Löschung rückgängig), [ / ] (Pinselgröße kleiner/größer), Esc (Selektion aufheben). Training: Start, Pause/Resume, Cancel, Continue +5K/+10K/+20K über die Menü-Shortcuts in M9–M14.

Was es ist: Eine simple statische Übersicht aller Tastenkürzel — Navigation, Views, Capture, Editor, Training. Inhalt ist hartkodiert in, kein Markdown-Loading.

Wenn du nach dem schnellsten Weg suchst, etwas im Viewport zu tun. WASD-Fly-Through, R für Camera-Reset, B fürs Background-Cycling — alle stehen hier.

W5ScrollView (Inhaltsbereich)

WO

Help → Keyboard Shortcuts (⌘/)..

TECHNISCH

Ein einfacher Scroll-Bereich mit einer vertikalen Liste drin. Padding 20 rundherum, kein Sidebar-Navigations-Tree (die Liste ist kurz genug). Inhalte sind in fünf Sektionen gruppiert (Navigation, Views, Capture, Editor, Training). Pro Tastenkombination eine Zeile mit übersetzbarem Text in beiden Spalten. Linke Spalte (Tastencode) fixiert auf 180 pt Breite, sodass die Beschreibungen rechts vertikal aligned bleiben. Keine Interaktion außer Scrollen — Klicken auf eine Zeile löst nichts aus, die Tastenkürzel sind echte Tastatur-Modifier im Menü und auf dem Viewport.

W6VStack (Shortcut-Sektionen)

WO

Innerhalb des ScrollView..

TECHNISCH

Linksbündig gestapelte Sektionen mit 16 pt Abstand. Innerhalb der fünf Sektionen jeweils Heading + Zeilen-Folge. Headings nutzen einen sekundären Subheadline-Stil — bewusst kein Title-Format, weil die Sektionen nicht navigierbar sein müssen. Inhalt ist bewusst flach (kein Disclosure, kein Search, kein Filter), damit die Komponente auf jeder macOS-Version unverändert läuft und die Datei lesbar bleibt.

Manage Storage (W7–W12)

Tabellen-Ansicht aller von RadianceKit verwalteten Files. Header zählt 693 Items, 16.74 GB Gesamtgröße. Toolbar oben: „Show in Finder" + „Refresh". Jede Zeile: PLY-Icon, Dateiname (z.B. training_20260527T211321Z.ply), Export-Datum, Größe (variiert 7 KB bis 218 MB), Lupen-Icon (Reveal) und Papierkorb-Icon (Move to Trash). Files sind nach Datum sortiert, neueste oben. In dieser Demo-Aufnahme dominieren PLY-Exports, weil viel mit –benchmark gearbeitet wurde.

Was es ist: Eine Disk-Usage-Übersicht für alles, was RadianceKit unter ~/Documents/RadianceKit/ ablegt — Logs, Exports, Scenes, Capture-Bundles (vom iOS-Begleiter), Imports (Staging-Kopien der Eingabe-Bilder). Pro Eintrag eine Größe in Bytes und zwei Buttons: „im Finder anzeigen" und „in den Papierkorb verschieben". Ist KEIN automatisches Aufräumen — die App löscht selbst nichts; du entscheidest pro Eintrag.

Wenn die Platte voll wird. Vor allem die Logs sammeln sich (eine JSONL pro Trainingsversuch, plus die _qualityMetrics.json); die Exports natürlich auch (PLY 100% rohe Daten, einer pro Export). Auch nützlich nach einem Crash, wenn das Imports-Staging-Verzeichnis noch alte Kopien der Eingangsbilder herumliegen hat (siehe „Disk-pressure incident" in dev_v549f-needle-reduction.md).

W7Button „Show in Finder"

WO

Header oben rechts im Storage-Browser-Fenster..

TECHNISCH

Öffnet das gesamte RadianceKit-Verzeichnis (~/Documents/RadianceKit/) im Finder, sodass du die Ordnerstruktur direkt sehen und auch mit dem Finder selbst manipulieren kannst. Die Aktion öffnet ein neues Finder-Fenster und wechselt nicht in den App-Sandbox-Container — ~/Documents/RadianceKit/ ist die regulär für Apps zugängliche Documents-Domain, kein Sandboxed-Container-Pfad.

W8Button „Refresh"

WO

Header, neben dem Finder-Button..

TECHNISCH

Triggert einen Hintergrund-Scan, der auf einem nutzer-initiierten asynchronen Task läuft, damit das Scannen großer Verzeichnisbäume die UI nicht blockiert. Das eigentliche Walken geht jeden bekannten Unterordner (Logs, Exports, Scenes, Captures, Imports) durch und erzeugt pro direktem Kind einen Storage-Eintrag. Pro Eintrag wird die rekursive Größe ermittelt — bevorzugt der tatsächliche Plattenverbrauch (inklusive APFS-Hardlinks-Sharing) mit Fallback auf die logische Dateigröße.

W9List (Storage-Einträge)

WO

Hauptinhalt unter dem Header..

TECHNISCH

Liste mit pro Zeile diesem Layout: kategorie- spezifisches SF-Symbol-Icon (Dokument für Logs, Upload-Pfeil für Exports, Würfel für Scenes, Tray für Imports), Name + Untertitel (Kind-Label + formatiertes Modifications-Datum), Bytes-Counter rechts (rechtsbündig, monospaced), Reveal-Button (Lupe-Symbol), Trash-Button (Papierkorb). Sortierung: primär nach Kind (Scenes zuerst, dann Exports, Logs, Captures, Imports, Other), sekundär nach Modifikationsdatum absteigend (neueste oben). Wenn der Scan noch läuft, zeigt die Stelle stattdessen einen „Scanning…"-Fortschritt. Wenn nichts gefunden wurde, eine Empty-State-Anzeige mit Tray-Icon.

W10Row-Button „Reveal in Finder"

WO

Pro Zeile, Lupe-Symbol rechts..

TECHNISCH

Öffnet den Finder und selektiert das spezifische Item (Datei oder Ordner). Unterschied zu W7: W7 öffnet das Root-Verzeichnis; W10 markiert genau diesen einen Eintrag. Praktischer Workflow: identifiziere einen großen Eintrag, klick auf die Lupe, kopiere ihn dann zum Beispiel auf ein externes Volume.

W11Row-Button „Move to Trash"

WO

Pro Zeile, Papierkorb-Symbol rechts neben der Lupe..

TECHNISCH

Löst die Bestätigungs-Dialog-Box (W12) aus. Erst nach Bestätigung läuft die macOS-Standard-Operation „in den Papierkorb verschieben" (also reversibel, kein direktes Löschen). Nach erfolgreichem Trash wird der Eintrag aus der Liste entfernt und der Gesamtbyte-Counter aktualisiert. Bei Fehlern wird ein modaler Fehler-Dialog eingeblendet.

W12ConfirmationDialog (Lösch-Bestätigung)

WO

Wird durch W11 ausgelöst, dargestellt als macOS-Sheet..

TECHNISCH

Standard-Bestätigungsdialog mit dynamischem Titel „Delete <name>?" und einer Message-Zeile, die explizit darauf hinweist, dass der Eintrag im Papierkorb landet und von dort wiederherstellbar ist (bis der Papierkorb geleert wird). Zwei Buttons: „Move to Trash" als destruktive Aktion (rot dargestellt) und „Cancel" mit automatischer Esc-Bindung. Der Dialog ist non-modal in dem Sinne, dass er nur dieses Fenster blockiert, nicht die ganze App — das ist macOS-Standard für reversible Löschungen.

Pareto Dashboard (W13–W22)

Leerer Zustand (nach erstem Öffnen) — Empty-State mit Call-to-Action „Open Reports Folder…". Die Datenpunkte erscheinen, sobald Trainings-Reports geladen sind, siehe nächster Shot.

Header-Toolbar zeigt „129 reports of 129" (alle Reports im gewählten Ordner erfolgreich geparst — 21 zusätzliche Files konnten wegen älterem Format nicht geparst werden, siehe Hinweis-Liste rechts). Achsen: X-Axis-Picker auf Gaussians, Y-Axis-Picker auf PSNR (dB). Scatter-Plot: grüne Punkte = Classic-Strategy, blaue Punkte = MCMC. Die gestrichelte Pareto-Front-Linie verläuft entlang der best-erreichten PSNR-Werte und plateaut um PSNR≈30 dB ab ca. 500K Gaussians. Filter-Chips rechts: 7 Scenes (bicycle, bonsai, family, flowers, kitchen, stump, truck), 2 Strategies (classic, mcmc), 3 Mip-Splatting-Optionen (All, On, Off). Aktuell sind alle Filter offen, deshalb der dichte Punkte-Cluster.

Was es ist: Ein Multi-Run-Vergleichs-Werkzeug. Trainiert hast du in der Vergangenheit mehrere Szenen oder dieselbe Szene mit unterschiedlichen Presets — jeder dieser Trainingsläufe produziert (wenn du –benchmark mitgegeben oder über die Benchmark-Funktion aufgerufen hast) eine JSON-Report-Datei, die unter anderem Final-PSNR, SSIM, LPIPS, Gaussian-Count und Wallclock-Zeit enthält. Das Dashboard liest einen ganzen Ordner solcher Reports gleichzeitig ein und plottet sie als 2D-Scatter mit selektierbaren Achsen. Zusätzlich wird die Pareto-Front (die Menge der nicht-dominierten Punkte) als gestrichelte Linie eingezeichnet.

Nachdem du mindestens drei oder vier Trainings-Reports angelegt hast. Mit weniger Punkten ist die Frontier-Linie nicht aussagekräftig. Typischer Use-Case: du hast versucht, eine Outdoor-Szene zu rekonstruieren, und hast nacheinander P3 Balanced (Classic), P4 Quality (Classic), P7 MCMC Quality und P9 Outdoor (tuned) durchgespielt — jetzt willst du wissen, welche Konfiguration die beste PSNR pro Sekunde Trainingszeit liefert oder welche die wenigsten Gaussians braucht für gegebene PSNR.

Beide Achsen sind frei wählbar (X-Achse:,, psnr, ssim, lpips, …; Y-Achse genauso). Die Pareto-Front-Logik in ParetoFront2D.indices weiß für jede Metrik, ob „kleiner = besser" (z.B. LPIPS, Loss, Time) oder „größer = besser" (PSNR, SSIM) — die Linie verläuft also je nach Achsen-Wahl von links unten nach rechts oben oder von links oben nach rechts unten, immer entlang der besten erreichten Kombination. Ein Punkt ist Pareto-optimal, wenn KEIN anderer Punkt in BEIDEN Dimensionen mindestens gleich gut ist (also kein anderer dominiert ihn). Pareto-optimale Punkte liegen auf der Linie, andere Punkte rechts/oberhalb (je nach Achsenorientierung) davon. Punkte AUF der Linie sind die echten Kandidaten für „bestes Preset"; Punkte WEIT von der Linie sind verschwendete Trainingszeit.

Du kannst die Auswahl auf eine bestimmte Szene einschränken (wenn du z.B. nur Outdoor-Runs vergleichen willst), auf eine bestimmte Strategie (Classic oder MCMC), oder auf Mip-Splatting an/aus (relevant nach Phase Q1.5, wo Mip als opt-in Advanced Flag bleibt).

Du hast drei Reports für „truck"-Szene unter ~/Documents/RadianceKit/Reports/: Run A (P4 Quality, 40K iter, 524K Gs, 105 s, PSNR 23.4), Run B (P7 MCMC, 200K iter, 150K Gs, 693 s, PSNR 24.6), Run C (P9 Outdoor, 100K iter, 1.25M Gs, 312 s, PSNR 25.8). Setze X-Achse auf trainingTime, Y-Achse auf PSNR. Run B liegt rechts oben, Run C noch weiter rechts oben, Run A links unten. Die Pareto-Front verbindet A und C — beide nicht-dominiert. Run B ist „lost" (C ist besser in Time UND PSNR). Erkenntnis: für „truck" lohnt sich der MCMC-Default nicht; entweder schnell+ok (A) oder lang+sehr gut (C). Konfiguration aus C als eigenes Preset speichern (Inspector → I1 Save Preset).

Nächste Aktion: Beste Konfiguration als Preset abspeichern. Konkret: schau dir die Pareto-Punkte an (Hover zeigt PSNR/SSIM/LPIPS/Gs/Time im Tooltip), entscheide welcher dir vom Time-vs-Quality-Trade-off am besten passt, öffne den zugehörigen Report (Dateiname enthält Run-Timestamp), kopiere dessen Trainingskonfiguration in einem neuen Run oder speichere sie nach der nächsten Trainings-Session als Preset über den Inspector.

W13Button „Open Reports Folder…"

WO

Toolbar oben links..

TECHNISCH

Öffnet einen Ordner-Auswahldialog mit der Aufforderung „Select a folder containing benchmark .json reports". Nach Bestätigung läuft ein Hintergrund-Task, der alle .json-Dateien im Ordner sequentiell parst. Fehlerhafte Reports (kaputtes JSON, falsches Schema) werden gesammelt und unten in der Sidebar als „N file failed to parse" angezeigt — kein Crash. Wenn ein zweiter Klick erfolgt, während ein erster Load noch läuft, wird der vorherige Task abgebrochen, sodass nicht zwei Ergebnisse gleichzeitig in den State schreiben.

Auch über CLI: –dashboard-dir /pfad/zu/reports lädt den Ordner gleich beim App-Start.

W14Picker „X-Axis"

WO

Über dem Chart, links..

TECHNISCH

Menü-Picker mit allen verfügbaren Metrik-Achsen des Dashboard-Moduls (PSNR, SSIM, LPIPS, Gaussian-Count, Trainingszeit und so weiter). Default ist Gaussian-Count. Beim Wechsel wird der gehoverte Punkt zurückgesetzt, weil eine bisher gehighlightete Position im alten Achsen-Koordinatensystem nach Achsenwechsel keinen Sinn mehr macht. Picker ist auf Inhaltsbreite begrenzt, damit er nicht über die ganze Breite zieht.

W15Picker „Y-Axis"

WO

Über dem Chart, neben X-Axis..

TECHNISCH

Identisch zu W14, nur dass das Default PSNR ist. Die Achsenwahl wird unabhängig gespeichert, also kann der Nutzer auch Unsinns-Kombinationen wählen (X=PSNR, Y=PSNR — würde alle Punkte auf eine Diagonale werfen). Solche Kombinationen werden aber nicht abgefangen; bewusste Entscheidung, weil ein Vergleich „SSIM vs PSNR" durchaus interessant ist, um zu sehen wie konsistent die Metriken sich verhalten.

W16Toggle „Show Pareto Front"

WO

Rechts neben den Achsen-Pickern..

TECHNISCH

Standard-macOS-Toggle. Wenn aktiv, wird im Pareto-Chart zusätzlich zur Punktwolke eine Linie mit der errechneten 2D-Pareto-Front gezeichnet. Stil: gestrichelt (Strichmuster 4–4), grau halbtransparent, Linienstärke 1,5 pt. Die Pareto-Berechnung läuft auf dem Hauptthread — bei der typischen Anzahl Reports (≤ ~50) ist das problemlos schnell. Wenn der Toggle aus ist, wird die Linie weggelassen, sodass nur die nackten Punkte stehen.

W17Chips „Scene"-Filter

WO

Rechte Sidebar im Dashboard-Fenster..

TECHNISCH

Filter-Chips für jede in den geladenen Reports vorkommende Szene. Eigenes Flow-Layout, das Chips in mehrere Zeilen automatisch umpackt, sobald die Breite ausgereizt ist. Aktive Chips bekommen den Akzent-Hintergrund, inaktive einen neutralen Standard-Material-Hintergrund. Mehrfach-Auswahl ist möglich (Set-Semantik); wenn keine Chip selektiert ist, gelten alle Szenen als „durchgelassen" — d.h. die Set-Logik ist „leere Selektion = alles", nicht „leere Selektion = nichts".

W18Chips „Strategy"-Filter

WO

Unter Scene-Filter in der Sidebar..

TECHNISCH

Genau wie W17, aber für Trainings-Strategien — typischerweise die zwei Werte „classic" und „mcmc", abgeleitet aus dem Strategy-Feld der Benchmark-Report-JSONs. Hilfreich, wenn du Reports beider Strategien gemischt hast und nur eine Sorte sehen willst (z.B. „nur MCMC-Runs zeigen, weil ich Classic schon ausgeschlossen habe").

W19Chips „Mip-Splatting"-Filter

WO

Unter Strategy-Filter in der Sidebar..

TECHNISCH

Dreiwertiger Filter (statt Set wie W17/W18): „All" / „On" / „Off". Hintergrund: Mip-Splatting wurde in Phase Q1.5 als experimentelle Multi-Skalen-Verbesserung evaluiert und der finale Verdict war „kein netter Win durchgehend; behalten als opt-in Flag". Wenn du Mip-on/off-Vergleiche machst, willst du oft sehr scharf trennen können. Daher der dedizierte ternäre Filter mit den Zuständen „alles durchlassen", „nur Mip an", „nur Mip aus". Die Sidebar-Section wird nur eingeblendet, wenn mindestens ein Mip-Report UND mindestens ein Nicht-Mip-Report in der Daten-Menge ist (sonst macht die Filterung keinen Sinn).

W20ChipButton (Filter-Toggle, all/on/off)

WO

Helper-Component, wird in W17/W18/W19 verwendet..

TECHNISCH

Minimalistischer Button-Wrapper. Inhalt: Label- Text mit Caption-Schriftgrad und Padding 10 horizontal / 5 vertikal. Hintergrund konditional: wenn aktiv → App-Akzentfarbe mit weißem Text; sonst neutraler Standard-Material-Hintergrund mit schwarzem Text. Form ist eine Capsule (pillenartig). Plain-Buttonstyle, damit das Capsule- Material nicht von einem System-Border überlagert wird.

W21Chart (Pareto-Scatter)

WO

Mittelfläche des Dashboards..

TECHNISCH

Swift-Charts-Diagramm mit zwei Layern: 1. ein Punkt pro Report — Position aus den gewählten X- und Y-Metriken, Farbe nach Strategy, Symbol nach Mip-Status. Symbol-Größe normal 80, gehighlighted 200 (wenn die ID dem aktuell gehoverten Report entspricht). 2. eine Linie für die Pareto-Front, nur wenn der Toggle an ist.

Chart-Overlay: ein transparentes Rechteck registriert Maus-Bewegung; pro Frame wird die euklidisch nächste Punktposition im Plot-Frame ermittelt und der gehoverte Report aktualisiert, falls die Distanz unter 24 px liegt (sonst zurückgesetzt). So bekommst du den Tooltip ohne Klicken — Hovern reicht.

W22Tooltip (Hover-Detail)

WO

Unter dem Chart, eingeblendet bei Hover..

TECHNISCH

Horizontaler Stack: Szene-Name (Headline), Strategy-Tag (Caption), Trennlinie, dann PSNR/SSIM/LPIPS/Gs/Time-Metriken in jeweils einer kleinen vertikalen Gruppe (Label + monospaced Wert). Falls Mip aktiviert war, zusätzlich ein „Mip"-Capsule-Tag in Akzentfarbe. Hintergrund halbtransparenter Blur, abgerundetes Rechteck mit 8 pt Radius. Wird nur eingeblendet, wenn die Maus tatsächlich über einem Punkt ist. Verschwindet automatisch beim Verlassen.

Holdout Analysis (W23–W29)

Leerer Zustand mit Empty-State und Call-to-Action „Open transforms.json…". Akzeptiert NeRF-Studio- und Instant-NGP-Format.

Leerer Zustand (nach erstem Öffnen) — die Kamera-Marker erscheinen, sobald eine transforms.json geladen ist, siehe nächster Shot.

Header zeigt geladene Datei (transforms_train.json) und Cam-Count („100 cameras"). Linke Sidebar: Strategy-Picker mit zwei Optionen — Angular (longitudinal) aktiv (richtet Folds nach Längen-/Breiten-Sektoren auf der Sphäre aus, sodass jeder Test-Fold geometrisch dicht ist) vs Linear (round-robin) (Reihenfolge-basiert, alle k-ten Frames als Test-Set). k-Folds-Slider steht auf 5, Test-Fold-Picker auf Fold 1. Export-Button erzeugt eine fold-assignment.json für Nerfstudio/Instant-NGP. Mittel-Panel: 3D-Globe-Projektion aller 100 Kameras — grüne Punkte = Train, rote Punkte = aktueller Test-Fold (Fold 1 mit 20 Kameras). Rechte Sidebar (Angular Correlation): pro Fold 20 Cams + Mean Nearest Angle (Fold 1: 7.9°, Fold 2: 7.8°, Fold 3: 7.7°, Fold 4: 7.0°, Fold 5: 6.3°) — kleinerer Wert bedeutet, dass die Kameras innerhalb dieses Folds eng beieinander liegen, also der Holdout-Split räumlich kohärent ist.

Was es ist: Ein 3D-Visualisierer für deine Kamera-Anordnung mit Cross-Validation-Logik. Du lädst eine transforms.json (das Standardformat von Nerfstudio / Instant-NGP für Kamera-Posen), die App liest alle Kameras, projiziert ihre Blickrichtungen auf eine Einheitskugel und zeigt sie als kleine Kugel-Marker auf einem virtuellen Globus. Dann teilt sie die Kameras in k Folds auf (per gewählter Strategie: angular oder linear), markiert grün den Trainings-Anteil und rot den Test-Anteil (Holdout), und berechnet pro Fold einen Angular-Correlation-Score, der dir sagt wie weit der Test-Fold im Blickwinkel-Raum vom Trainings-Fold entfernt liegt.

Wenn du Holdout-Evaluation machen willst — also: wie gut generalisiert dein Modell auf ungesehene Blickwinkel? Standard im Training ist „every-8th view als Holdout" (Mip-NeRF360-Konvention), aber das ist eine sehr lineare Aufteilung. Wenn deine Bilder zum Beispiel zeitlich geclustert sind (erst eine Seite des Objekts, dann die andere), dann ist „every-8th" nicht repräsentativ — eine zufällige Sequenz-Position landet im Test, aber alle ihre Nachbarn sind im Training, das ist zu einfach. Mit „angular" stratifiziert man stattdessen über den Blickwinkel-Raum: jeder Fold enthält Kameras aus allen Bereichen des Orbits, sodass der Test wirklich Generalisierungs-Lücken testet.

Angular vs Linear: - Angular (Standard): teilt die Kameras nach Longitudinalwinkel (φ-Koordinate um die Y-Achse) in k gleiche Sektoren. Fold 0 sind Kameras mit φ ∈ [0°, 360/k°), Fold 1 die nächsten, und so weiter. Vorteil: jeder Fold deckt einen Teilausschnitt des Orbits ab; der Test-Fold ist räumlich kompakt aber breit über den Welt-Datensatz verteilt. Gut für klassische Orbit-Aufnahmen. - Linear (Round-Robin): Fold-Index = (image_index modulo k). Das ist die simple „every-k-th"-Aufteilung. Funktioniert, wenn die Bildreihenfolge KEINEN spatialen Bias hat (z.B. zufällig sortierte Drohnenaufnahmen). Funktioniert schlecht, wenn die Bilder zeitlich clustern.

Im 3D-Globus siehst du sofort: grüne Punkte (Training) und rote Punkte (Test). Wenn die roten Punkte alle in einer Ecke clustern, ist der Holdout schlecht (kein guter Generalisierungs-Test). Wenn sie gleichmäßig zwischen den grünen liegen, ist er gut. Der Angular-Correlation-Score pro Fold (rechte Sidebar, in Grad) sagt zusätzlich: kleinerer Wert = der Test ist nah am Training (jede Test-Kamera hat eine nahe Trainings-Kamera, leichter Test); größerer Wert = der Test ist weit weg vom Training (härtere Generalisierung).

Du hast deine Truck-Szene mit 251 Bildern aufgenommen, exportierst per Menü-Item M33 (Export SfM transforms.json) ein nerfstudio-File. Öffne das Holdout-Window (⇧⌘H), lade die JSON via „Open transforms.json…", schau dir den Globus an. k=5 (Default) gibt dir 5 Folds. Klick auf „Fold 3" — siehe ob die roten Marker einigermaßen gleichmäßig sind. Falls ja: „Export fold-assignment.json", lege die exportierte Datei in den Reports-Ordner, und beim nächsten Training-Run mit –benchmark (oder den entsprechenden Inspector-Einstellungen) wird genau diese Fold-Aufteilung als Test-Holdout verwendet — anstelle des Standards „every-8th".

W23Button „Open transforms.json…"

WO

Toolbar oben links..

TECHNISCH

Öffnet einen Datei-Auswahldialog, der auf JSON- Dateien beschränkt ist. Nach Bestätigung lädt das Holdout-Modul die Datei. Der Loader parst sowohl das nerfstudio-Format (Kamera-Intrinsics plus Liste von Frames mit Bildpfad und Transform-Matrix) als auch das instant-ngp-Format (gleicher Aufbau). Pro Frame wird die Blickrichtung aus der Transform-Matrix extrahiert (z-Achse der Kamera-Lokalbasis) und gespeichert. Wenn das Parsen fehlschlägt, wird eine Fehlermeldung im Status-Bereich angezeigt.

Auch via CLI: –holdout-file /pfad/zu/transforms.json startet das Fenster direkt mit geladener Datei.

W24Picker „Strategy" (angular/linear)

WO

Linke Sidebar, oben..

TECHNISCH

Radio-Picker mit zwei Optionen: Angular und Linear. Strategy-Wechsel triggert automatisch eine Neuberechnung der Folds. Die Blickrichtungen sind eine Liste von 3D-Einheitsvektoren auf der Sphäre; die Angular-Strategie projiziert sie auf den Longitudinalwinkel φ und sortiert, die Linear-Strategie macht einfach eine Modulo-Aufteilung über den Frame-Index.

W25Slider „k Folds"

WO

Linke Sidebar, mittig..

TECHNISCH

Slider von 3 bis 10, Schrittweite 1. Bei Änderung wird die Fold-Berechnung automatisch neu angestoßen, sodass die Folds-Liste, die Trainings/Test-Indices und der pro-Fold-Score sofort neu berechnet werden. Der gewählte Wert wird als monospaced-Digit-Text rechts neben dem Label angezeigt.

Faustregel: k=5 ist Standard (gibt dir 20% Test pro Fold, das ist üblich für Cross-Validation). k=10 wenn du sehr viel Daten hast und mehr Folds für statistische Aussagekraft brauchst. k=3 wenn du wenig Daten hast.

W26Picker „Test Fold"

WO

Linke Sidebar, unter dem k-Slider..

TECHNISCH

Menü-Picker. Optionen sind dynamisch 0..<k, Label „Fold 1" bis „Fold N" (also 1-indexed in der UI, 0-indexed intern). Wenn der vorher gewählte Index ≥ k ist (z.B. weil du k von 10 auf 5 reduziert hast), wird er automatisch auf 0 zurückgesetzt. Der gewählte Test-Fold wird im Globus rot dargestellt, alle anderen grün.

W27Button „Export fold-assignment.json"

WO

Linke Sidebar, unten..

TECHNISCH

Öffnet einen Speichern-Dialog mit Default- Dateiname fold-assignment.json. Nach Bestätigung kodiert das Holdout- Modul die aktuelle Aufteilung in ein JSON-Schema (per-Frame Fold- Zuordnung plus Strategy-Meta-Block). Diese Datei kann dann beim nächsten Training mit –benchmark mit übergeben werden, sodass derselbe Holdout für die finale Metrik-Auswertung verwendet wird. Schreib-Fehler werden als Fehlertext angezeigt; Erfolg in grünem Text als „Saved to (filename)".

W28SCNView (3D Camera Globe)

WO

Mittelpanel im Holdout-Fenster..

TECHNISCH

SceneKit-Globus-View. Die Szene besteht aus: einer Wireframe-Kugel (Radius 1.0, 36 Segmente, dunkelgrau), drei farbigen Achsenstummeln (rot/grün/blau für X/Y/Z, je 1.2 lang), und pro Kamera einer kleinen Markerkugel (Radius 0.03) an der entsprechenden Blickrichtungs-Position auf der Einheitskugel (leicht außerhalb, damit sie nicht IN der Wireframe-Kugel verschwindet). Die Marker werden bei jeder Fold-Änderung NICHT neu gebaut — Rebuild ist nur dann nötig, wenn sich die Frame-Liste ändert (also eine neue JSON geladen wird). Stattdessen läuft pro Update eine in-place-Aktualisierung der Material- Farben: rot für Test-Indices, grün für Training, hellgrau wenn weder noch. So bleiben Slider-Ticks performant auch bei N > 1000 Kameras.

Die Kamera-Kontrolle ist aktiviert — du kannst mit der Maus den Globus drehen, zoomen, pannen. Beleuchtung sorgt dafür, dass die Marker nicht flach aussehen. Hintergrund ist dunkelgrau.

W29FoldCard (Tap to Select Fold)

WO

Rechte Sidebar, „Angular Correlation"-Sektion..

TECHNISCH

Pro Fold eine Karten-View — abgerundetes Rechteck mit 6 pt Radius, Padding 10, vertikales Layout mit zwei Zeilen (oben „Fold N" + Kamera-Anzahl, unten „Mean nearest angle:" + Wert in Grad). Hintergrundfarbe konditional: aktiver Fold = Akzentfarbe halbtransparent, inaktive = neutrales Standard-Material. Tippen wählt den Fold, und der Globus färbt sich live um.

Der „Mean nearest angle"-Score ist der mittlere kleinste Winkel pro Test-Kamera zur nächsten Trainings-Kamera (in Radiant intern berechnet, in Grad in der UI angezeigt).

BayesOpt Console (W30–W39)

Leerer Zustand mit Search-Space-Picker (RadianceKit defaults (6-dim)), Trial-Budget-Slider (default 40), Random-Seed (42) und drei Empty-Panels für Convergence-Chart, Trial Log und Search-Space-Parameter-Liste.

Leerer Zustand (nach erstem Öffnen) — Convergence-Chart und Trial-Tabelle füllen sich, sobald ein Run gestartet wurde, siehe nächster Shot.

Status oben rechts „Finished — best 0.9943 after 40 trials". Linke Sidebar: Search-Space-Picker auf RadianceKit defaults (6-dim), Trial-Budget 40, Random Seed 42. Parameter-Liste zeigt die sechs zu tunenden Hyperparameter mit ihren Wertebereichen: mipSmoothing3DScale [0.05, 0.5], mipFilter2DVariance [0.1, 0.6], densifyGradThreshold [5e-07, 5e-06], ssimWeight [0.05, 0.5], mcmcNoiseScale [1e-05, 0.0001], mcmcRelocationInterval [50, 200]. Mitte: Convergence-Chart (X = Trial-Index 1–40, Y = Objective Value 0–1) — graue Punkte = Initial-Samples (LHS), blaue Punkte = BayesOpt-Acquisition, orange Punkte = Restart-Trials (#22 und #31). Beste-Wert-Linie steigt steil bis Trial ~7, dann nur noch marginale Verbesserung bis Trial 15, ab dort flacher Plateau bei 0.99+. Rechte Sidebar: Trial-Log #1–#34 mit Score + Tag (init/bo/restart). Save-Best-Config-Button oben rechts schreibt bayesopt-best.json.

Was es ist: Eine Bayes-Optimierungs-Konsole für Hyperparameter-Suche. Bayes-Opt ist ein automatisches Verfahren, das versucht, mit möglichst wenig Experimenten den optimalen Punkt einer unbekannten Funktion zu finden — typischerweise: „welche Kombination aus mcmcMaxGaussians, capMultiplier, ssimWeight und gradThreshold liefert die beste PSNR für meine Szenenklasse?" Statt eines Grids von 6^4 = 1296 Trials probiert Bayes-Opt etwa 40–100 informierte Trials und kommt damit nahe ans Optimum.

Wichtig: Die aktuelle in der App ausgelieferte Version führt die Optimierung nicht gegen echte Trainings-Runs aus (das würde Tage dauern), sondern gegen eine synthetische Demo-Objektive — eine multi-modale Landschaft mit Hill-Climbing-Charakter plus leichtem Noise. Das ist mit Absicht so: das Fenster soll dir das Verhalten des Optimierers zeigen (Konvergenz-Verlauf, Sample-Punkte, Best-So-Far) und dich die Search-Space-Definitionen verstehen lassen. Für echte Trainings-getriebene BayesOpt-Läufe (wie in Phase Q7 für die Scene-Class-Presets durchgeführt) wird ein separater offline CLI-Workflow benutzt; das Fenster ist die Live-UI-Variante.

Drei Anwendungsfälle: 1. Du willst verstehen, wie BayesOpt arbeitet — dann starte einen Demo-Run und beobachte den Convergence-Chart. 2. Du planst eine neue Szenenklasse (etwa „Aquarien" oder „Antike Möbel"), für die die eingebauten 10 Presets nicht perfekt passen. Definiere mental einen Suchraum, prüfe ihn hier mit dem „Bowl demo" oder „Densify"-Preset, exportiere dann die Best-Config als JSON und nutze sie als Startpunkt für einen echten Trainings-Run. 3. Du willst die im RKBayesOpt-Package definierten Default-Search-Spaces (Mip-Subset, RadianceKit Defaults) inspizieren — die werden im Parameter-Panel der linken Sidebar aufgelistet.

- Convergence-Chart (mittlere Spalte): Y = beste bisher erreichte Objective-Funktion-Wert. X = Trial-Index. Anfangs steil ansteigend (BayesOpt probiert die Initial-Samples zufällig, einige davon sind glücklich), dann zunehmend flach, weil die nahen-Optimum-Region ausgeschöpft ist. Wenn die Linie für 20+ Trials flach bleibt, kannst du den Run stoppen — weitere Trials bringen nichts mehr. Die einzelnen Punkte im Chart sind die individuellen Trial-Werte (also nicht „best so far"), gefärbt nach Phase: grau = initial sample, blau = bayesopt acquisition, orange = restart. - Trial-Tabelle (rechte Spalte): #1, #2, #3, … mit jeweils Wert und Phase-Tag. Der bisher beste Trial ist mit einem gelben Stern markiert. Aus der Tabelle kannst du den Best-Trial identifizieren und seine Parameter-Werte später beim Export anschauen. - Search-Space-Inspektor (linke Sidebar): zeigt für das gewählte Preset alle Parameter-Namen und ihre Suchbereiche [lo, hi]. Wenn du beim Preset „RadianceKit defaults (6-dim)" stehst, siehst du z.B. „densifyGradThreshold [5e-7, 5e-6]" — also log-uniform zwischen diesen beiden Werten.

Wähle Preset „RadianceKit defaults (6-dim)", Trial-Budget 40, Seed 42. Klick „Start". Beobachte: die ersten 8 Trials sind grau (initial samples, LHS-Latin-Hypercube), die folgenden blau (BayesOpt-akquiriert). Der Convergence-Chart wird steil bis Trial ~15, danach flacht er ab. Bei Trial ~30–40 stabilisiert sich der beste Wert. Klick „Save Best Config" — eine bayesopt-best.json wird gespeichert mit dem Preset-Namen, Trial-Index, Wert und den dekodierten Parameter-Werten. Diese JSON kannst du dann manuell in deine Preset-Definition übernehmen.

W30Button „Start"

WO

Toolbar links, im Idle/Finished-State..

TECHNISCH

Setzt die Trial-Liste zurück, wechselt in den Running-State, generiert eine neue Run-ID (für Stale-Detection bei mehrfachen Start-Clicks) und erzeugt ein frisches Pause-Gate. Dann startet ein Hintergrund-Task, der den Optimierer als asynchronen Stream ausführt. Initial-Samples-Größe ergibt sich aus min(8, budget / 4 + 1) — also typisch 8 Latin-Hypercube-Samples bei Budget ≥ 28, weniger bei kleinem Budget. Trial-Updates werden inkrementell empfangen und in die Liste angehängt. Stale-Run-Protection: wenn währenddessen ein zweiter Start-Klick die Run-ID neu setzt, werden Updates aus dem alten Run verworfen.

Primary-Action-Style für den prominenten Knopf-Look.

W31Button „Pause"

WO

Toolbar links, im Running-State..

TECHNISCH

Setzt das Pause-Gate aktiv und wechselt in den Paused-State. Der eigentliche Effekt: der Runner wartet in einem 50-ms-Polling-Loop bevor er die nächste Objective-Funktion auswertet. Das bedeutet, ein gerade laufendes Trial wird zu Ende geführt (es ist ja synthetisch und dauert nur Mikrosekunden), aber kein weiteres Trial wird angestoßen. Sobald Resume läuft, geht es weiter wo aufgehört wurde.

W32Button „Stop"

WO

Toolbar links, im Running- und Paused-State..

TECHNISCH

Bricht den Runner-Task ab, nullt die Referenz, löst das Pause-Gate (falls noch paused war), und wechselt in den Finished-State (wenn Trials existieren) oder Idle-State (wenn keine). Die bereits berechneten Trials bleiben in der Liste sichtbar — Stop löscht sie nicht. Destruktive Button-Rolle zeigt den Knopf in Rot, weil er den Run abbricht.

W33Button „Resume"

WO

Toolbar links, im Paused-State..

TECHNISCH

Löst das Pause-Gate und wechselt in den Running-State zurück. Der Runner-Task läuft schon (er wartet ja im Polling-Loop); sobald der Loop merkt, dass die Pause aufgehoben ist, läuft er weiter und startet das nächste Trial.

W34Button „Save Best Config"

WO

Toolbar rechts, immer sichtbar (aber disabled wenn kein bestTrial vorhanden)..

TECHNISCH

Öffnet einen Speichern-Dialog mit Default- Dateiname bayesopt-best.json, auf JSON beschränkt. Nach Bestätigung wird ein Payload-Dictionary gebaut: Preset-Name, Trial-Index, Wert (Objective-Score), Parameter (Dictionary der dekodierten Parameter- Namen → Werte). Die Decodierung projiziert die normalisierten Suchraum-Koordinaten in [0,1]^d zurück in den Original-Wertebereich (mit log-uniform/linear/integer-Skalen entsprechend). JSON-Output ist pretty-printed und mit sortierten Keys. Bei Schreib-Fehler wird (in der aktuellen Demo-Version) still ignoriert — keine Error-UI, weil das ein Demo-Path ist.

Der Button bleibt grau, solange kein Trial gelaufen ist.

W35Picker „Search Space"-Preset

WO

Linke Sidebar, oben..

TECHNISCH

Menü-Picker mit vier Preset-Optionen: - „RadianceKit defaults (6-dim)" — der vollständige Standard-Suchraum mit allen Q7-Hyperparametern. - „Mip subset (2-dim)" — nur mipSmoothing3DScale [0.05, 0.5] log-uniform und mipFilter2DVariance [0.1, 0.6] linear. Nützlich wenn du Mip-Splatting für eine Szenenklasse tunen willst. - „densify-until + ssim-weight + grad-thresh" — drei Densify-relevante Parameter (densifyGradThreshold log-uniform, ssimWeight linear, densifyUntilIter integer). - „Bowl demo (1-dim)" — pädagogischer Single-Parameter-Suchraum für „so funktioniert BayesOpt"-Demos.

Während ein Lauf aktiv ist, kann der Suchraum nicht gewechselt werden (würde den Optimizer verwirren).

W36Slider „Trial Budget"

WO

Linke Sidebar, unter dem Search-Space-Picker..

TECHNISCH

Slider von 10 bis 200, Schrittweite 5. Default 40. Das bedeutet: BayesOpt darf maximal N Trials machen. Davon sind die ersten paar initiale Samples (Latin-Hypercube), der Rest sind echte BayesOpt-Trials. Faustregeln für die Praxis: ein Suchraum mit d Dimensionen braucht etwa 10d bis 20d Trials für ein gutes Optimum. Bei 6-dim Defaults also 60–120, bei 2-dim Mip-Subset 20–40, bei 1-dim Bowl-Demo 10–20.

Während des Laufs ist der Slider deaktiviert.

W37Slider „Random Seed"

WO

Linke Sidebar, unter dem Budget-Slider..

TECHNISCH

Slider von 1 bis 100, Schrittweite 1. Default 42. Der Seed wird sowohl an die initialen Latin-Hypercube-Samples als auch an die Noise-Komponente der Demo-Objective weitergereicht. Reproduzierbarkeit: gleicher Seed + gleicher Suchraum + gleiches Budget ergibt exakt identische Trial-Sequenz. Nützlich für „bekommen alle deine Kollegen denselben Lauf wenn sie das Demo nachbauen?". Während des Laufs deaktiviert.

W38Chart (Convergence)

WO

Mittlere Spalte des Fensters..

TECHNISCH

Swift-Charts-Diagramm mit zwei Layern: 1. eine Linie für „best-value-so-far" pro Trial — eine monoton steigende oder gleichbleibende Kurve in Akzentfarbe. 2. ein Punkt pro Trial mit dem individuellen Objective-Wert, gefärbt nach Phase. Symbol-Größe 40. Drei Phase-Labels: „init" (grau), „bo" (blau), „restart" (orange).

Eine kleine Legende zeigt die Phase-Farben oben links. Wenn die Trial- Liste leer ist (vor dem ersten Start), wird stattdessen eine Empty- State-Anzeige mit Chart-Icon und Hinweis „Press Start to begin a BayesOpt run." eingeblendet.

W39Table (Trial Log)

WO

Rechte Spalte des Fensters..

TECHNISCH

Scroll-Bereich mit lazy gestapelten Trial- Zeilen. Pro Zeile ein horizontaler Stack: Trial-Nummer (3-stellig monospaced, links), Wert (monospaced, rechtsbündig, 70 pt breit), Phase- Tag (Capsule, gefüllt mit Phase-Farbe bei 25% Opacity), optional ein gelber Stern wenn dieser Trial der aktuell beste ist. Ein Auto-Scroll-Mechanismus springt automatisch ans Ende, sobald ein neuer Trial dazukommt — sodass du den Live-Verlauf am Bildschirm-Boden mitlesen kannst, ohne selbst zu scrollen.

Hauptfenster: Verlustverlauf und Gaussian-Count (I39–I41, Querverweis)

Drei der Inspector-Anzeigen im Hauptfenster verdienen eine eigene Erklärung, weil sie während eines laufenden Trainings ständig zu sehen sind und es wichtige Faustregeln gibt, wann der Verlauf gesund aussieht. Die Anzeigen sind im Inspector unter der „Loss Chart"-Sektion (siehe Kapitel 2 — Inspector) und ergänzen die Holdout-Analyse aus dem Aux-Fenster oben.

Wann ist die Loss-Kurve gesund? Eine gesunde Loss-Kurve zeigt drei Phasen: (1) Warmup — die ersten 200–500 Iterationen fällt der Loss steil von hoch (typisch 0.15–0.25 für L1+SSIM-kombiniert je nach Szene) auf etwa die Hälfte. Wenn der Loss in dieser Phase NICHT fällt, ist meist die Eingabe falsch (Bilder kaputt, SfM-Posen schlecht, Anzahl Initial-Gaussians zu klein). (2) Densification — zwischen ~500 und densifyUntilIteration (klassisch 15K, MCMC bis 20K oder 25K) fällt der Loss weiter, oft mit kleinen Sprüngen nach unten wenn Densify-Operationen neue Gaussians einfügen und der Optimizer sie ausnutzt. Der Gaussian-Count steigt in dieser Phase. (3) Refinement — danach läuft der Loss in einen flacher werdenden Tail. Typische End-Werte: Tanks-&-Temples Truck mit P4 Quality landet bei L1 ≈ 0.023, Horse mit Full Classic V546 bei L1 ≈ 0.0230, Outdoor-Mip-NeRF360-Szenen oft schlechter (0.04–0.07).

Was bedeutet ein Plateau? Ein Plateau (Loss-Kurve verläuft horizontal über mehrere Tausend Iterationen) hat zwei Interpretationen: (a) das Modell hat konvergiert, weiteres Training bringt nichts mehr — das ist der gute Fall. (b) das Modell ist stuck (lokales Minimum, schlechte Gradient-Information, ein Cap am Buffer-Limit) — der schlechte Fall. Beide sehen im Chart identisch aus. Unterscheidung: schau dir den Gaussian-Count an. Wenn er auch flach ist UND dem MCMC-Cap nahe (z.B. 150K von 150K bei .fullMCMC), bist du am Limit — entweder Cap erhöhen oder Plateau akzeptieren. Wenn der Gaussian-Count noch wächst, aber der Loss nicht fällt, ist das stuck.

Wann abbrechen vs weitertrainieren? Faustregel: 10K Iterationen lang keine Verbesserung des Min-Loss → abbrechen, weitere Iterationen sind verschwendet. Davor: kannst du via Cmd+T (Training-Menü → Continue Training → +5K iterations) noch eine Verlängerung anhängen, falls du grenzwertige Verbesserung siehst. Achtung: bei MCMC ist das Plateau oft echt — das Cap ist die natürliche Grenze.

Gaussian-Count-Plateau ist KEIN „fertig"-Signal. Es bedeutet nur, dass MCMC das Cap erreicht hat oder dass Classic Densification ausgereizt ist. Die echte „fertig"-Frage stellt erst die Holdout-Analyse — PSNR/SSIM/LPIPS auf einem unabhängigen Test-Set, ausgewertet im Holdout-Window (W23–W29) oder via –benchmark-Flag.

PSNR/Holdout ist die Wahrheit, Loss nur Proxy. Der Loss ist eine relative Metrik: er fällt während dein Modell sich an die Trainings-Views anpasst. Ein niedriger Loss heißt aber nicht automatisch gutes Modell — wenn das Modell die Trainings-Bilder auswendig gelernt hat (Overfitting), wäre der Loss klein, aber die PSNR auf ungesehenen Views (Holdout) wäre schlecht. Deshalb: für die finale Qualitätsbewertung immer auf Holdout-Metriken schauen, nicht auf End-Loss allein.

Faustregel-Box

- User Guide und Keyboard Shortcuts sind statische Hilfe — bei Stichwort-Fragen schnell, für Tiefe das hier vorliegende Manual nutzen. - Manage Storage öffnen, sobald die Platte unter 10% freien Speicher fällt. Logs und Imports-Staging sind die üblichen Sünder. - Pareto Dashboard erst nach mindestens drei oder vier Trainings-Reports sinnvoll. X-Achse = Kosten (Time / Gs), Y-Achse = Qualität (PSNR / SSIM). Pareto-Front zeigt die effizienten Kombinationen. - Holdout Analysis nutzen, bevor du PSNR-Benchmarks mit anderen veröffentlichst — sichert dir, dass dein Test-Set wirklich repräsentativ ist. - BayesOpt Console ist primär ein Lern- und Inspektions-Werkzeug für Suchraum-Definitionen. Für echte Trainings-getriebene Hyperparameter-Tuning den offline CLI-Workflow nutzen. - Loss-Plateau und Gaussian-Count-Plateau sind getrennt zu interpretieren. Cap-Limit ist kein „fertig"-Signal. Echte Qualität misst nur Holdout-PSNR. - 10K Iterationen ohne Min-Loss-Verbesserung → Training stoppen.