Kapitel 4 — Aux-Fenster

Neben dem Hauptfenster (3D-Viewport plus Inspector) verwaltet RadianceKit sechs weitere Fenster, die alle über das Help-Menü geöffnet werden. Das Menü hat acht Einträge, von oben nach unten: User Guide (⌘?), Keyboard Shortcuts (⌘/), Open Training Logs… (⇧⌘L), Open Exports Folder…, Manage Storage…, Pareto Dashboard… (⇧⌘D), Holdout Analysis… (⇧⌘H), BayesOpt Console… (⇧⌘B). Die beiden „Open …"-Einträge öffnen kein App-Fenster, sondern den Finder; deshalb sind sie hier nicht weiter behandelt. Drei der Fenster — Dashboard, Holdout, BayesOpt — sind eigenständige Analyse-Werkzeuge: sie arbeiten unabhängig vom Hauptfenster und lesen oder schreiben JSON-Dateien auf der Platte. Jedes dieser drei Fenster öffnest du über das Hilfe-Menü und wählst darin anschließend selbst die Datei oder den Ordner aus, den du auswerten willst — über „Open Reports Folder…", „Open transforms.json…" bzw. den „Start"-Knopf. Diese drei Fenster sind als einzige nicht übersetzt: ihre Knöpfe, Regler und Spaltentitel stehen in jeder Sprachfassung auf Englisch. Die hier genannten Beschriftungen findest du also genau so auf dem Bildschirm wieder.

Die drei einfachen Fenster (User Guide, Keyboard Shortcuts, Manage Storage) und die beiden Ordner-Menü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 die Kurzfassung zum schnellen Nachschlagen. 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. Alle anderen Ebenen — H1 ebenso wie H4 und tiefer — erscheinen nicht in der Sidebar, weil sie sie sonst unübersichtlich machen würden. 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 (den bekommt jede Überschrift, unabhängig von der Ebene) 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: Option+Space (Training pausieren/fortsetzen), Cmd+E (Szene exportieren). Mehr steht hier nicht — Start, Cancel und die Verlängerungen erreichst du über das Training-Menü (Kapitel 1).

Was es ist: Eine simple statische Übersicht aller Tastenkürzel — Navigation, Views, Capture, Editor, Training. Der Inhalt ist fest eingebaut und wird nicht aus einer Datei nachgeladen.

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 1.356 Items, 55,1 GB Gesamtgröße. Toolbar oben: „Show in Finder" + „Refresh". Jede Zeile: Export-Icon, Dateiname (z.B. training_20260718T194416Z.ply), Export-Datum, Größe (variiert hier von 7,8 MB bis 2,24 GB), Lupen-Icon (Reveal) und Papierkorb-Icon (Move to Trash). Sortiert wird zuerst nach Kategorie und innerhalb einer Kategorie nach Datum, neueste oben. In dieser Aufnahme dominieren PLY-Exports, weil in dieser Ablage vor allem Trainings-Ergebnisse gesichert wurden.

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. Dieses Fenster ist übersetzt: auf Deutsch heißt es „Speicher verwalten", die beiden Kopfzeilen-Knöpfe heißen „Im Finder anzeigen" und „Aktualisieren", die Zeilen-Knöpfe „Im Finder anzeigen" und „In den Papierkorb legen". Die englischen Namen in den Einträgen unten sind die Bezeichnungen aus der englischen Fassung.

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 Absturz, wenn das Imports-Staging-Verzeichnis noch alte Kopien der Eingangsbilder herumliegen hat.

W7Button „Show in Finder"

WO

Header oben rechts im Storage-Browser-Fenster.

TECHNISCH

Öffnet den RadianceKit-Datenordner im Finder — genau das Verzeichnis, dessen Inhalt dieses Fenster auflistet. Damit siehst du die Ordnerstruktur (Logs, Exports, Scenes, Captures, Imports) direkt und kannst die Dateien auch mit dem Finder selbst verschieben oder kopieren. Die Aktion öffnet ein neues Finder-Fenster; die Liste im Fenster ändert sich dadurch nicht mit — dafür ist „Refresh" da (W8).

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, iPhone für Capture-Bundles, 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 rechts „384 reports of 384" (alle Reports im gewählten Ordner erfolgreich geparst); links neben dem Knopf „Open Reports Folder…" steht der Name des geladenen Ordners, hier „Benchmarks". Achsen: X-Axis-Picker auf Gaussians, Y-Axis-Picker auf PSNR (dB), daneben das aktive Häkchen „Show Pareto Front". Legende oben links: blau = mcmc, grün = classic, orange = hybrid, dazu die Symbolform für Mip-Splatting On/Off. Die gestrichelte Pareto-Front-Linie verläuft entlang der best-erreichten PSNR-Werte und plateaut um PSNR≈30 dB ab ca. 300K Gaussians; die Punktwolke reicht bis über 1,5 Mio. Gaussians. Filter-Chips rechts: über 30 Scenes (u.a. bicycle, bonsai, family, flowers, garden, kitchen, stump, truck sowie die durchnummerierten 360-, drone- und photo-Testreihen), 3 Strategies (classic, hybrid, mcmc), 3 Mip-Splatting-Optionen (All, On, Off) mit „All" aktiv. Aktuell ist kein Scene- oder Strategy-Filter gesetzt, 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 — aus einer Benchmark-Auswertung entsteht pro Trainingslauf eine JSON-Report-Datei, die unter anderem Final-PSNR, SSIM, LPIPS, Gaussian-Count und Wallclock-Zeit enthält. Einen Schalter für diese Auswertung gibt es in der Oberfläche nicht; das Dashboard wertet aus, was bereits als Report im gewählten Ordner liegt. Es 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), P8 Quality (MCMC) und P9 Drone / Aerial 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: Gaussians, Trainingszeit, PSNR, SSIM, LPIPS, …; Y-Achse genauso). Die Pareto-Front-Berechnung weiß für jede Metrik, ob „kleiner = besser" (LPIPS, Gaussians, Training Time, BRISQUE) oder „größer = besser" (PSNR, SSIM, FSIM, MS-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, hybrid oder mcmc), oder auf Mip-Splatting an/aus (Mip-Splatting ist eine optionale Einstellung für Fortgeschrittene, deshalb lohnt der direkte Vergleich).

Du hast drei Reports für die „truck"-Szene in einem Reports-Ordner: Run A (P4 Quality (Classic), 524K Gs, 105 s, PSNR 23.4), Run B (P8 Quality (MCMC), 150K Gs, 693 s, PSNR 24.6), Run C (P5 Ultra Detail, 1.25M Gs, 312 s, PSNR 25.8). Setze X-Achse auf Training Time, 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-Weg 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.

Der gewählte Ordner wird nicht dauerhaft gemerkt: nach dem Öffnen des Fensters über Hilfe → Pareto Dashboard… (⇧⌘D) wählst du ihn hier erneut aus. Der Name des geladenen Ordners erscheint danach rechts neben dem Knopf.

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

Ein Ankreuzfeld, standardmäßig gesetzt. Die Pareto-Front wird zusätzlich zur Punktwolke als Linie über den Chart gelegt — gestrichelt (Strichmuster 4–4), grau halbtransparent, Linienstärke 1,5 pt. Achtung: In der ausgelieferten Fassung wirkt sich das Häkchen nicht auf den Chart aus — die Front-Linie wird immer gezeichnet, ob angekreuzt oder nicht. Die Front wird bei jedem Achsenwechsel und nach jeder Filteränderung neu bestimmt.

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 drei Werte „classic", „hybrid" und „mcmc", abgeleitet aus dem Strategy-Feld der Benchmark-Report-JSONs. Hilfreich, wenn du Reports mehrerer 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 ist eine Multi-Skalen-Erweiterung, die je nach Szene hilft oder nicht — deshalb bleibt sie eine bewusst zuschaltbare Einstellung und kein Standard. 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 erscheint, sobald die geladene Menge überhaupt Reports enthält — also praktisch immer; sie verschwindet nur, wenn gar nichts geladen ist.

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 der normalen Textfarbe (passt sich hellem und dunklem Erscheinungsbild an). 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 (siehe W16 — sie wird immer gezeichnet). Zusätzlich blendet der gerade gehoverte Punkt den Szenennamen als kleine Kapsel über sich ein.

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. Die Kamera-Marker erscheinen, sobald eine transforms.json geladen ist — siehe nächste Abbildung.

Header zeigt geladene Datei (transforms.json) und Cam-Count („86 cameras"). Linke Sidebar: Strategy-Picker mit zwei Optionen — Angular (longitudinal) aktiv (sortiert die Kameras nach ihrem Längenwinkel um den Orbit und verteilt sie dann reihum auf die Folds) vs Linear (round-robin) (dieselbe Reihum-Verteilung, aber nach Bildreihenfolge statt nach Blickwinkel). k-Folds-Slider steht auf 5, Test-Fold-Picker auf Fold 1. Export-Button erzeugt eine fold-assignment.json zur Weiterverwendung in externen Auswertungs-Werkzeugen. Mittel-Panel: 3D-Globe-Projektion aller 86 Kameras, über die ganze Kugel verteilt — grüne Punkte = Train, rote Punkte = aktueller Test-Fold (Fold 1 mit 18 Kameras). Rechte Sidebar (Angular Correlation): pro Fold die Kamera-Zahl + Mean Nearest Angle (Fold 1: 18 Cams / 8.5°, Fold 2: 17 / 6.1°, Fold 3: 17 / 6.2°, Fold 4: 17 / 6.7°, Fold 5: 17 / 6.4°) — kleinerer Wert bedeutet, dass jede Test-Kamera eine nahe Trainings-Kamera hat, der Test also leichter 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): sortiert alle Kameras nach ihrem Longitudinalwinkel (φ-Koordinate um die Y-Achse) und teilt sie dann reihum auf die k Folds aus — die erste Kamera des Rings kommt in Fold 1, die zweite in Fold 2, und nach k Kameras beginnt der Umlauf von vorn. Vorteil: jeder Fold enthält Kameras aus allen Richtungen des Orbits, gleichmäßig über den Ring verteilt. Gut für klassische Orbit-Aufnahmen, weil die Aufteilung dann nicht mehr von der Aufnahme-Reihenfolge abhängt. - Linear (Round-Robin): dieselbe Reihum-Verteilung, aber über die Bild-Position statt über den Winkel (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 — dann liegen benachbarte Frames in verschiedenen Folds und der Test wird zu leicht.

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". Die exportierte Datei ist für externe Auswertungs-Werkzeuge gedacht (Nerfstudio, Instant-NGP); RadianceKit selbst liest sie nicht wieder ein und trainiert weiterhin gegen seinen eigenen Holdout-Standard „every-8th". Das Fenster dient hier also der Beurteilung, ob dein Kamera-Satz überhaupt einen fairen Test zulässt.

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, erscheint eine Meldung in der linken Sidebar — allerdings nur, wenn dort schon eine Szene geladen war; beim allerersten Versuch bleibt das Fenster im Leerzustand ohne sichtbare Meldung.

Die geladene Datei wird nicht dauerhaft gemerkt: nach dem Öffnen des Fensters über Hilfe → Holdout Analysis… (⇧⌘H) wählst du sie hier erneut aus. Ihr Name erscheint danach rechts neben dem Knopf.

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 sortiert sie nach ihrem Longitudinalwinkel φ und weist sie dann reihum den Folds zu, die Linear-Strategie macht dieselbe Reihum-Zuweisung über den Frame-Index und ignoriert die Geometrie ganz. Beide Strategien erzeugen daher gleich große Folds; sie unterscheiden sich nur darin, wonach vorher sortiert wird.

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. Er listet genau so viele Einträge, wie Folds eingestellt sind, beschriftet mit „Fold 1" bis „Fold N". 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). Die Datei ist für externe Auswertungs-Werkzeuge gedacht — RadianceKit liest sie nicht wieder ein. Der Knopf ist ausgegraut, solange keine Kamera-Datei geladen ist. Erfolg meldet sich als „Saved to (filename)", ein Schreib-Fehler als „Export failed: …" — beide erscheinen an derselben Stelle unter dem Knopf und beide in grüner Schrift, die Farbe unterscheidet die Fälle also nicht.

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. Convergence-Chart und Trial-Tabelle füllen sich, sobald ein Run gestartet wurde — siehe nächste Abbildung.

Status oben rechts „Finished — best 0.9943 after 40 trials", daneben der Knopf „Save Best Config"; oben links der Knopf „Start". 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 „Convergence (best value so far)" (X = Trial-Index 0–40, Y = Objective Value 0–1) — blaue Punkte = Initial-Samples, grüne Punkte = BayesOpt-Acquisition, orange Punkte = Restart-Trials (#22 mit 0.5303 und #31 mit 0.4885). Die blaue Beste-Wert-Linie steigt steil bis Trial ~5, dann nur noch marginale Verbesserung bis Trial ~13, ab dort flaches Plateau nahe 1.0. Rechte Sidebar: Trial-Log, hier zu den Trials #8–#36 gescrollt, 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 Gaussian-Obergrenze, SSIM-Gewicht und Densify-Schwelle 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 sie bei der Entwicklung der mitgelieferten Presets durchgeführt wurden) wird ein separater Auswertungs-Weg außerhalb der App benutzt; das Fenster ist die Live-Variante zum Zusehen.

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 fünfzehn eingebauten Presets nicht perfekt passen. Definiere mental einen Suchraum, prüfe ihn hier mit „Bowl demo (1-dim)" oder „densify-until + ssim-weight + grad-thresh", exportiere dann die Best-Config als JSON und nutze sie als Startpunkt für einen echten Trainings-Run. 3. Du willst die mitgelieferten Standard-Suchräume (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: blau = initial sample, grün = 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 blau (initial samples, Latin-Hypercube), die folgenden grün (BayesOpt-akquiriert). Der Convergence-Chart wird steil bis Trial ~13, 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. Die Zahl der Initial-Samples wächst mit dem Budget, aber höchstens bis 8 — also typisch 8 Latin-Hypercube-Samples ab einem Budget von 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 ausgegraut, solange noch kein bester Durchlauf vorliegt).

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 sechs Standard-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 das Zehn- bis Zwanzigfache von d an 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" (blau), „bo" (grün), „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, bei 25% Opacity gefüllt — grau für „init", blau für „bo", orange für „restart"; das sind bewusst andere Farben als die Punktfarben im Chart daneben), 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 sitzen im Inspector im Abschnitt Fortschritt, in der aufklappbaren Gruppe Verlustverlauf (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 zur Orientierung: eine gut ausgeleuchtete Objekt-Szene (etwa Tanks-&-Temples Truck mit P4 Quality) landet bei L1 ≈ 0.023, weiträumige Außenszenen wie die von Mip-NeRF 360 bleiben naturgemäß darüber (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 beim Preset P8 Quality (MCMC)), 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: über das Training-Menü → Continue Training → „+5,000 iterations" kannst du noch eine Verlängerung anhängen, falls du grenzwertige Verbesserung siehst (ein Tastenkürzel gibt es dafür nicht). 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 beantworten erst PSNR/SSIM/LPIPS auf einem unabhängigen Test-Set — die Zahlen dazu stehen in den Benchmark-Reports, die du im Pareto Dashboard (W13–W22) auswertest. Das Holdout-Fenster (W23–W29) liefert diese Metriken nicht; es beurteilt nur, ob dein Kamera-Satz überhaupt eine faire Aufteilung in Trainings- und Test-Blickwinkel zulässt.

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. Die exportierte Fold-Aufteilung ist für externe Werkzeuge; RadianceKit trainiert weiter gegen „every-8th". - BayesOpt Console ist primär ein Lern- und Inspektions-Werkzeug für Suchraum-Definitionen — sie rechnet gegen eine Demo-Funktion, nicht gegen echte Trainings-Läufe. - 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.