Brugervejledning

Kapitel 4 — Hjælpevinduer

Foruden hovedvinduet (3D-viewport plus Inspector) forvalter RadianceKit syv yderligere vinduer, der alle åbnes via Help-menuen. Listen er fra top til bund: User Guide (⌘?), Keyboard Shortcuts (⌘/), Open Training Logs… (åbner ikke et app-vindue, men Finder; derfor ikke yderligere behandlet her), Manage Storage…, Pareto Dashboard… (⇧⌘D), Holdout Analysis… (⇧⌘H), BayesOpt Console… (⇧⌘B). Tre af dem — Dashboard, Holdout, BayesOpt — er selvstændige analyse-værktøjer. De har hver deres egen view-model-stack, læser eller skriver JSON-filer på disk, og for hver findes der et CLI-argument, hvor du kan få vinduet til at pege direkte på en bestemt fil ved app-start (–dashboard-dir, –holdout-file, –bayesopt-autorun).

De fire enkle vinduer (User Guide, Keyboard Shortcuts, Manage Storage, plus undermenu-punkterne Open Training Logs / Open Exports Folder) får pr. styreelement en kort post. De tre analyse-vinduer er mere udførligt dokumenteret — hver med en indledning, der forklarer, hvad du ser i vinduet, hvornår du bør åbne det, og hvordan du fortolker det viste billede.

Sidst i kapitlet er der et krydshenvisnings-afsnit til hovedvinduets Inspector: hvad du fornuftigt kan aflæse i live- loss-charten og gaussian-count-visningen under en kørende træning.

User Guide (W1–W4)

User Guide-vindue med sidebar til venstre og rendret markdown-indhold til højre
User Guide-vindue med sidebar til venstre og rendret markdown- indhold til højre

Hvad det er: Et indbygget hjælpevindue, der rendrer den medfølgende guide_<sprog>.md. Sproget afledes af indstillingerne (fanen General → Language) eller, hvis „System" står der, af macOS-sprogpræferencerne. Layout er klassisk: til venstre sidebar med alle overskrifter, til højre brødteksten.

Når du har brug for en hurtig påmindelse om et enkelt punkt — altså som stikordsersrtning. Den udførlige reference er denne manual; det indbyggede hjælpevindue er snarere det, en –help på kommandolinjen ville være. Den opdateres ved hver app-udgivelse, men holdes indholdsmæssigt overfladisk.

W1NavigationSplitView (sidebar + detalje)

HVOR

Help → User Guide (⌘?).

TEKNISK

Tospalte-layout med smal sidebar (mindst 180 pt bred) til indholdstræet og et scrollbart detaljeområde til selve markdown-indholdet. Vinduet har en minimumsstørrelse på 700 × 500 pt. Ved første åbning indlæser vinduet den passende guide_<lang>.md fra app-bundlen (fallback guide_en.md), parser den til blok-records (overskrifter H1–H4, afsnit, lister, tabeller, separator-linjer) og udtrækker separat overskriftsstrukturen til sidebaren. Inline-formatering (fed, kursiv, code-span) rendres via den indbyggede markdown-engine. Sproget læses fra app-indstillingerne, med specialtilfældet kinesisk (zh-Hans) og brasiliansk portugisisk (pt-BR), som bevares som fulde locale-tags, fordi disse varianter adskiller sig fra zh og pt.

W2List (heading-sidebar)

HVOR

Venstre kolonne i User Guide-vinduet.

TEKNISK

Liste over alle H2- og H3-overskrifter i det aktuelle markdown-dokument. H2-poster optræder uden indrykning med medium skriftsnit, H3-poster med 16 pt indrykning til venstre og reduceret foreground-stil. H4 og dybere ignoreres, fordi dybden ellers gør sidebaren uoverskuelig. Anker-ID'er genereres fra heading-teksten via slugifisering (lowercase + mellemrum til streger + filtrering på bogstaver/tal/streger — samme algoritme, som GitHub bruger til sine markdown-ankre, så også eksterne URL'er til dok potentielt ville lande på samme anker). Listen bruger native macOS-stil.

W3Button (heading → anker-spring)

HVOR

Pr. sidebar-linje en knap.

TEKNISK

Hver sidebar-post er en knap, der sætter det aktuelle anker, men optisk ser ud som en liste-post. En observator-variabel udløser så scroll-springet til det tilsvarende anker med en blød animation over 0,3 s. Efter springet nulstilles anker-værdien, så næste klik på samme anker udløser igen (ellers ville observatoren ikke udløse på ny, fordi værdien ikke har ændret sig).

W4ScrollView (detalje-indhold)

HVOR

Højre kolonne.

TEKNISK

Scrollbart, vertikalt stablende indholdsområde med lazy rendering, fordi længere guides nemt kan have over 200 markdown-blokke — en ikke-lazy variant ville instantiere dem alle samtidigt. Hver blok får et eget ID, enten heading-ankeret (for hopbare H1–H3) eller en index-pladsholder. Maksimumbredde er 720 pt, padding 32 horisontalt / 24 vertikalt, så lange linjer bevarer et godt læsbart layout. Tabeller rendres celle-vis med horisontale stacks og separator-linjer; inline-kode af den indbyggede markdown-engine. Egentlige kodeblokke behandles aktuelt som paragraph — en kendt begrænsning ved hjælpevinduet.

Keyboard Shortcuts (W5–W6)

Keyboard Shortcuts-vindue — fem grupper Navigation/Views/Capture/Editor/Training med hotkey-kolonne til venstre og beskrivelse til højre
Keyboard Shortcuts-vindue — fem grupper Navigation/Views/Capture/ Editor/Training med hotkey-kolonne til venstre og beskrivelse til højre

Statisk reference-liste i fem sektioner. Navigation: Mouse Drag (orbit/fly), Shift+Drag/Right-Drag (pan), scroll (zoom), WASD (fly-through- bevægelse), Q/E (op/ned), F (toggle orbit/fly), dobbeltklik (re-center), Cmd+scroll (FoV-justering). Views: R (reset camera), T (auto-rotation), P (camera playback), B (background- cycle), 0–9 (spring til training-cam 1=10 %/5=50 %/0=last), venstre/højre pil (prev/next cam). Capture: S (screenshot til desktop), V (turntable-video), C (copy camera info). Editor: Tab (edit-mode), klik/træk (paint-select), Option+klik (deselect), X / Delete (slet selektion), Cmd-Z (fortryd sidste sletning), [ / ] (pensel mindre/større), Esc (ophæv selektion). Training: Start, Pause/Resume, Cancel, Continue +5K/+10K/+20K via menu-genvejene i M9–M14.

Hvad det er: En enkel statisk oversigt over alle tastaturgenveje — Navigation, Views, Capture, Editor, Training. Indhold er hårdkodet i, ingen markdown-loading.

Når du leder efter den hurtigste vej til at gøre noget i viewporten. WASD-fly-through, R til camera-reset, B til background-cycling — alle står her.

W5ScrollView (indholdsområde)

HVOR

Help → Keyboard Shortcuts (⌘/).

TEKNISK

Et enkelt scroll-område med en vertikal liste i. Padding 20 hele vejen rundt, ingen sidebar-navigations-tree (listen er kort nok). Indhold er grupperet i fem sektioner (Navigation, Views, Capture, Editor, Training). Pr. tastekombination en linje med oversættelig tekst i begge kolonner. Venstre kolonne (tastekode) fastgjort til 180 pt bredde, så beskrivelserne til højre forbliver vertikalt aligned. Ingen interaktion ud over scrolling — klik på en linje udløser intet, tastegenvejene er ægte tastatur- modifiers i menuen og på viewporten.

W6VStack (shortcut-sektioner)

HVOR

Inden for ScrollView.

TEKNISK

Venstrejusteret stablede sektioner med 16 pt afstand. Inden for de fem sektioner hver heading + linje-følge. Headings bruger en sekundær subheadline-stil — bevidst ikke title-format, fordi sektionerne ikke behøver at være navigerbare. Indhold er bevidst fladt (ingen disclosure, ingen search, ingen filter), så komponenten kører uændret på enhver macOS-version, og filen forbliver læselig.

Manage Storage (W7–W12)

Manage Storage-vindue — header viser „693 items · 16.74 GB total”, tabel med export-PLY-filer sorteret efter dato, hver med format-pille + filnavn + størrelse + dato
Manage Storage-vindue — header viser „693 items · 16.74 GB total", tabel med export-PLY-filer sorteret efter dato, hver med format-pille + filnavn + størrelse + dato

Tabelvisning af alle filer, som RadianceKit forvalter. Header tæller 693 items, 16.74 GB samlet størrelse. Toolbar øverst: „Show in Finder" + „Refresh". Hver linje: PLY-ikon, filnavn (f.eks. training_20260527T211321Z.ply), export-dato, størrelse (varierer 7 KB til 218 MB), forstørrelses- ikon (reveal) og papirkurv-ikon (move to trash). Filer er sorteret efter dato, nyeste øverst. I denne demo-optagelse dominerer PLY-eksporter, fordi der er arbejdet meget med –benchmark.

Hvad det er: En disk-usage-oversigt for alt, hvad RadianceKit lægger under ~/Documents/RadianceKit/ — logs, exports, scenes, capture-bundles (fra iOS-companion), imports (staging-kopier af input-billederne). Pr. post en størrelse i bytes og to knapper: „vis i Finder" og „flyt til papirkurv". Det er INGEN automatisk oprydning — appen sletter intet selv; du beslutter pr. post.

Når disken bliver fuld. Især logs samles (en JSONL pr. trænings-forsøg, plus _qualityMetrics.json); exporterne også (PLY 100 % rå data, en pr. eksport). Også nyttig efter et crash, hvor imports-staging-mappen har gamle kopier af input-billederne liggende (se „disk-pressure incident" i dev_v549f-needle-reduction.md).

W7Knappen „Show in Finder"

HVOR

Header øverst til højre i storage-browser-vinduet.

TEKNISK

Åbner hele RadianceKit-mappen (~/Documents/RadianceKit/) i Finder, så du kan se mappestrukturen direkte og også manipulere den med Finder selv. Handlingen åbner et nyt Finder-vindue og skifter ikke til app-sandbox-containeren — ~/Documents/RadianceKit/ er det regulært app-tilgængelige Documents-domæne, ingen sandboxed-container-sti.

W8Knappen „Refresh"

HVOR

Header, ved siden af Finder-knappen.

TEKNISK

Udløser en baggrunds-scanning, der kører på en bruger-initieret asynkron task, så scanningen af store mappetræer ikke blokerer UI'en. Selve gennemgangen går hver kendt undermappe (Logs, Exports, Scenes, Captures, Imports) igennem og genererer en storage-post pr. direkte barn. Pr. post bestemmes den rekursive størrelse — helst det faktiske diskforbrug (inklusive APFS-hardlinks-sharing) med fallback på den logiske filstørrelse.

W9List (storage-poster)

HVOR

Hovedindhold under headeren.

TEKNISK

Liste med dette layout pr. linje: kategori- specifikt SF-symbol-ikon (dokument for logs, upload-pil for exports, terning for scenes, tray for imports), navn + undertitel (kind-label + formateret modifikations-dato), bytes-counter til højre (højrejusteret, monospaced), reveal-knap (forstørrelses- symbol), trash-knap (papirkurv). Sortering: primært efter kind (scenes først, så exports, logs, captures, imports, other), sekundært efter modifikationsdato faldende (nyeste øverst). Hvis scanningen stadig kører, viser stedet i stedet et „Scanning…"- fremskridt. Hvis intet blev fundet, en empty-state-visning med tray-ikon.

W10Row-knap „Reveal in Finder"

HVOR

Pr. linje, forstørrelses-symbol til højre.

TEKNISK

Åbner Finder og vælger den specifikke post (fil eller mappe). Forskel fra W7: W7 åbner rod-mappen; W10 markerer præcis denne ene post. Praktisk workflow: identificér en stor post, klik på forstørrelsen, kopiér den så f.eks. til et eksternt volume.

W11Row-knap „Move to Trash"

HVOR

Pr. linje, papirkurv-symbol til højre for forstørrelsen.

TEKNISK

Udløser bekræftelses-dialog-boksen (W12). Først efter bekræftelse kører macOS-standard-operationen „flyt til papirkurv" (altså reversibel, ingen direkte sletning). Efter vellykket trash fjernes posten fra listen, og total-byte-counteren opdateres. Ved fejl indkobles en modal fejldialog.

W12ConfirmationDialog (slette-bekræftelse)

HVOR

Udløses af W11, vises som macOS-sheet.

TEKNISK

Standard bekræftelsesdialog med dynamisk titel „Delete <navn>?" og en besked-linje, der eksplicit påminder om, at posten lander i papirkurven og kan gendannes derfra (indtil papirkurven tømmes). To knapper: „Move to Trash" som destruktiv handling (vist rødt) og „Cancel" med automatisk Esc-binding. Dialogen er non-modal i den forstand, at den kun blokerer dette vindue, ikke hele appen — det er macOS-standard for reversible sletninger.

Pareto Dashboard (W13–W22)

Pareto Dashboard — tom tilstand før report-import
Pareto Dashboard — tom tilstand før report-import

Tom tilstand (efter første åbning) — empty-state med call-to-action „Open Reports Folder…". Datapunkterne optræder, så snart trænings-reports er indlæst, se næste shot.

Pareto Dashboard med 129 indlæste benchmark-reports — Gaussians vs PSNR med Pareto-front, Scene/Strategy/Mip-filter
Pareto Dashboard med 129 indlæste benchmark-reports — Gaussians vs PSNR med Pareto-front, Scene/Strategy/Mip-filter

Header-toolbar viser „129 reports of 129" (alle reports i den valgte mappe blev parsed med succes — 21 yderligere filer kunne ikke parses pga. ældre format, se hint-listen til højre). Akser: X-Axis-vælger på Gaussians, Y-Axis-vælger på PSNR (dB). Scatter-plot: grønne punkter = Classic-strategi, blå punkter = MCMC. Den stiplede Pareto-front- linje løber langs de bedst opnåede PSNR-værdier og plateauer omkring PSNR≈30 dB fra ca. 500K gaussians. Filter-chips til højre: 7 scener (bicycle, bonsai, family, flowers, kitchen, stump, truck), 2 strategier (classic, mcmc), 3 Mip-splatting-muligheder (All, On, Off). I øjeblikket er alle filtre åbne, derfor den tætte punkt-klynge.

Hvad det er: Et multi-run-sammenligningsværktøj. Du har i fortiden trænet flere scener eller samme scene med forskellige presets — hver af disse træningskørsler producerer (hvis du har givet –benchmark med eller kaldt via benchmark-funktionen) en JSON-report-fil, der bl.a. indeholder final-PSNR, SSIM, LPIPS, gaussian-count og wallclock-tid. Dashboardet indlæser en hel mappe af sådanne reports samtidigt og plotter dem som 2D-scatter med valgbare akser. Derudover tegnes Pareto-fronten (mængden af ikke-dominerede punkter) som stiplet linje.

Efter du har oprettet mindst tre eller fire trænings-reports. Med færre punkter er frontier-linjen ikke sigende. Typisk use-case: du har prøvet at rekonstruere en outdoor-scene og har spillet P3 Balanced (Classic), P4 Quality (Classic), P7 MCMC Quality og P9 Outdoor (tuned) igennem efter hinanden — nu vil du vide, hvilken konfiguration der leverer bedste PSNR pr. sekund træningstid, eller hvilken der kræver færrest gaussians til given PSNR.

Begge akser kan frit vælges (X-akse:,, psnr, ssim, lpips, …; Y-akse ligeså). Pareto-front-logikken i ParetoFront2D.indices ved for hver metrik, om „mindre = bedre" (f.eks. LPIPS, Loss, Time) eller „større = bedre" (PSNR, SSIM) — linjen løber altså alt efter akse-valget fra nederst til venstre til øverst til højre eller fra øverst til venstre til nederst til højre, altid langs den bedste opnåede kombination. Et punkt er Pareto-optimalt, hvis INTET andet punkt i BEGGE dimensioner er mindst lige så godt (altså intet andet dominerer det). Pareto-optimale punkter ligger på linjen, andre punkter til højre/over (alt efter akseorientering). Punkter PÅ linjen er de ægte kandidater til „bedste preset"; punkter LANGT fra linjen er spildt træningstid.

Du kan begrænse valget til en bestemt scene (hvis du f.eks. kun vil sammenligne outdoor-runs), til en bestemt strategi (Classic eller MCMC), eller Mip-splatting til/fra (relevant efter fase Q1.5, hvor Mip forbliver som opt-in advanced flag).

Du har tre reports for „truck"-scenen under ~/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). Sæt X-aksen til trainingTime, Y-aksen til PSNR. Run B ligger øverst til højre, Run C endnu længere mod øverst til højre, Run A nederst til venstre. Pareto-fronten forbinder A og C — begge ikke-dominerede. Run B er „lost" (C er bedre i både time OG PSNR). Indsigt: for „truck" er MCMC-default'en ikke værd det; enten hurtig+ok (A) eller lang+meget god (C). Gem konfigurationen fra C som egen preset (Inspector → I1 Save Preset).

Næste handling: Gem bedste konfiguration som preset. Konkret: kig på Pareto-punkterne (hover viser PSNR/SSIM/LPIPS/Gs/ Time i tooltippet), beslut hvilken time-vs-quality-tradeoff der passer dig bedst, åbn den tilhørende report (filnavnet indeholder run-timestampet), kopiér dens trænings-konfiguration i en ny run eller gem den efter næste trænings-session som preset via Inspectoren.

W13Knappen „Open Reports Folder…"

HVOR

Toolbar øverst til venstre.

TEKNISK

Åbner en mappe-vælger med opfordringen „Select a folder containing benchmark .json reports". Efter bekræftelse kører en baggrunds-task, der parser alle .json-filer i mappen sekventielt. Fejlagtige reports (defekt JSON, forkert skema) samles og vises nederst i sidebaren som „N file failed to parse" — intet crash. Hvis der kommer et andet klik, mens en første load stadig kører, afbrydes den tidligere task, så der ikke skrives to resultater ind i state samtidigt.

Også via CLI: –dashboard-dir /sti/til/reports indlæser mappen direkte ved app-start.

W14Vælger „X-Axis"

HVOR

Over charten, til venstre.

TEKNISK

Menu-vælger med alle tilgængelige metrik-akser i dashboard-modulet (PSNR, SSIM, LPIPS, gaussian-count, træningstid og så videre). Default er gaussian-count. Ved skift nulstilles det hoverede punkt, fordi en hidtil highlightet position i det gamle akse-koordinatsystem ikke længere giver mening efter akseskift. Vælgeren er begrænset til indholdsbredden, så den ikke spænder over hele bredden.

W15Vælger „Y-Axis"

HVOR

Over charten, ved siden af X-Axis.

TEKNISK

Identisk med W14, bortset fra at default er PSNR. Akse-valget gemmes uafhængigt, så brugeren også kan vælge sludder-kombinationer (X=PSNR, Y=PSNR — ville kaste alle punkter ned på en diagonal). Sådanne kombinationer fanges dog ikke; bevidst beslutning, fordi en sammenligning „SSIM vs PSNR" sagtens kan være interessant for at se, hvor konsistent metrikkerne opfører sig.

W16Toggle „Show Pareto Front"

HVOR

Til højre for akse-vælgerne.

TEKNISK

Standard macOS-toggle. Når aktiv, tegnes ud over punktskyen i Pareto-charten en linje med den beregnede 2D-Pareto-front. Stil: stiplet (stregmønster 4–4), grå halvtransparent, linjestyrke 1,5 pt. Pareto-beregningen kører på hovedtråden — ved det typiske antal reports (≤ ~50) er det problemfrit hurtigt. Når toggle er fra, udelades linjen, så kun de nøgne punkter står.

W17Chips „Scene"-filter

HVOR

Højre sidebar i dashboard-vinduet.

TEKNISK

Filter-chips for hver scene, der optræder i de indlæste reports. Eget flow-layout, der automatisk ompakker chips i flere linjer, så snart bredden er udnyttet. Aktive chips får accent-baggrund, inaktive en neutral standard-material-baggrund. Multivalg er muligt (set-semantik); hvis ingen chip er valgt, gælder alle scener som „lukket ind" — dvs. set-logikken er „tomt valg = alt", ikke „tomt valg = intet".

W18Chips „Strategy"-filter

HVOR

Under scene-filteret i sidebaren.

TEKNISK

Præcis som W17, men for trænings-strategier — typisk de to værdier „classic" og „mcmc", afledt fra strategy- feltet i benchmark-report-JSON'erne. Hjælpsom, hvis du har blandet reports fra begge strategier og kun vil se den ene type (f.eks. „vis kun MCMC-runs, fordi jeg har udelukket Classic").

W19Chips „Mip-Splatting"-filter

HVOR

Under strategy-filteret i sidebaren.

TEKNISK

Treværdigt filter (i stedet for set som W17/W18): „All" / „On" / „Off". Baggrund: Mip-splatting blev evalueret i fase Q1.5 som eksperimentel multi-skalering, og den endelige verdict var „ingen pæn win gennemgående; beholdt som opt-in flag". Når du laver Mip-on/off-sammenligninger, vil du ofte kunne adskille meget skarpt. Derfor det dedikerede ternære filter med tilstandene „lad alt igennem", „kun Mip til", „kun Mip fra". Sidebar-sektionen indkobles kun, hvis der er mindst én Mip-report OG mindst én ikke-Mip-report i data-mængden (ellers giver filtreringen ingen mening).

W20ChipButton (filter-toggle, all/on/off)

HVOR

Helper-component, bruges i W17/W18/W19.

TEKNISK

Minimalistisk knap-wrapper. Indhold: label-tekst med caption-skriftgrad og padding 10 horisontalt / 5 vertikalt. Baggrund betinget: når aktiv → app-accentfarve med hvid tekst; ellers neutral standard-material-baggrund med sort tekst. Formen er en capsule (pilleformet). Plain-buttonstyle, så capsule-materialet ikke overdækkes af en system-border.

W21Chart (Pareto-scatter)

HVOR

Midten af dashboardet.

TEKNISK

Swift-Charts-diagram med to lag: 1. et punkt pr. report — position fra de valgte X- og Y-metrikker, farve efter strategy, symbol efter Mip-status. Symbol-størrelse normalt 80, highlightet 200 (når ID svarer til den aktuelt hoverede report). 2. en linje for Pareto-fronten, kun hvis toggle er tændt.

Chart-overlay: et transparent rektangel registrerer musebevægelse; pr. frame bestemmes den euklidisk nærmeste punktposition i plot-frame, og den hoverede report opdateres, hvis distancen er under 24 px (ellers nulstillet). Sådan får du tooltippet uden klik — hover rækker.

W22Tooltip (hover-detalje)

HVOR

Under charten, indkoblet ved hover.

TEKNISK

Horisontalt stack: scene-navn (headline), strategy- tag (caption), separator-linje, så PSNR/SSIM/LPIPS/Gs/Time-metrikker i hver en lille vertikal gruppe (label + monospaced værdi). Hvis Mip var aktiveret, desuden et „Mip"-capsule-tag i accentfarve. Baggrund halvtransparent blur, afrundet rektangel med 8 pt radius. Vises kun, når musen faktisk er over et punkt. Forsvinder automatisk ved forlading.

Holdout Analysis (W23–W29)

Holdout Analysis — tom tilstand før indlæsning af en transforms.json
Holdout Analysis — tom tilstand før indlæsning af en transforms.json

Tom tilstand med empty-state og call-to-action „Open transforms.json…". Accepterer NeRF-Studio- og Instant-NGP-format.

Tom tilstand (efter første åbning) — kamera-markørerne optræder, så snart en transforms.json er indlæst, se næste shot.

Holdout-globe med 100 NeRF-Blender-mic-kameraer, 5 folds à 20 kameraer, Angular-strategi aktiv
Holdout-globe med 100 NeRF-Blender-mic-kameraer, 5 folds à 20 kameraer, Angular-strategi aktiv

Header viser indlæst fil (transforms_train.json) og cam-count („100 cameras"). Venstre sidebar: strategy-vælger med to muligheder — Angular (longitudinal) aktiv (justerer folds efter længde-/breddesektorer på sfæren, så hver test-fold er geometrisk tæt) vs Linear (round-robin) (rækkefølge-baseret, alle k'te frames som test-sæt). k-Folds-slider står på 5, test-fold-vælger på fold 1. Export-knap genererer en fold-assignment.json til Nerfstudio/Instant-NGP. Midter-panel: 3D-globe-projektion af alle 100 kameraer — grønne punkter = train, røde punkter = aktuel test-fold (fold 1 med 20 kameraer). Højre sidebar (Angular Correlation): pr. 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°) — mindre værdi betyder, at kameraerne inden for denne fold ligger tæt sammen, altså at holdout-splittet er rumligt kohærent.

Hvad det er: En 3D-visualizer for din kamera-arrangement med cross-validation-logik. Du indlæser en transforms.json (standardformatet fra Nerfstudio / Instant-NGP for kameraposer), appen læser alle kameraer, projicerer deres kigge-retninger på en enhedskugle og viser dem som små kugle-markører på en virtuel globus. Derefter opdeler den kameraerne i k folds (efter valgt strategi: angular eller linear), markerer grønt for træningsdelen og rødt for testdelen (holdout) og beregner pr. fold en angular-correlation-score, der fortæller dig, hvor langt test-folden ligger fra trænings-folden i kigge-vinkel-rummet.

Når du vil lave holdout-evaluering — altså: hvor godt generaliserer din model til usete kigge-vinkler? Standard i træningen er „every-8th view som holdout" (Mip-NeRF360-konvention), men det er en meget lineær opdeling. Hvis dine billeder f.eks. er tidsmæssigt klyngede (først én side af objektet, så den anden), er „every-8th" ikke repræsentativ — en tilfældig sekvens-position lander i testen, men alle dens naboer er i træningen, det er for nemt. Med „angular" stratificerer man i stedet over kigge-vinkel-rummet: hver fold indeholder kameraer fra alle dele af orbitten, så testen virkelig prøver generaliserings-huller.

Angular vs Linear: - Angular (standard): opdeler kameraerne efter longitudinalvinkel (φ-koordinat omkring Y-aksen) i k lige sektorer. Fold 0 er kameraer med φ ∈ [0°, 360/k°), fold 1 de næste, og så videre. Fordel: hver fold dækker en delegnet af orbitten; test-folden er rumligt kompakt, men bredt fordelt over verdens-datasættet. God til klassiske orbit-optagelser. - Linear (round-robin): fold-index = (image_index modulo k). Det er den simple „every-k-th"-opdeling. Fungerer, hvis billedrækkefølgen ingen spatial bias har (f.eks. tilfældigt sorterede droneoptagelser). Fungerer dårligt, når billederne klyngеr tidsmæssigt.

I 3D-globussen ser du straks: grønne punkter (træning) og røde punkter (test). Hvis de røde punkter alle klynger sig i et hjørne, er holdout dårlig (ingen god generaliserings-test). Hvis de ligger jævnt mellem de grønne, er den god. Angular-correlation- scoren pr. fold (højre sidebar, i grader) fortæller derudover: mindre værdi = testen er tæt på træningen (hver test-kamera har en nær trænings-kamera, let test); større værdi = testen er langt fra træningen (hårdere generalisering).

Du har optaget din truck-scene med 251 billeder, eksporterer via menupunkt M33 (Export SfM transforms.json) en nerfstudio-fil. Åbn holdout-vinduet (⇧⌘H), indlæs JSON'en via „Open transforms.json…", kig på globussen. k=5 (default) giver dig 5 folds. Klik på „Fold 3" — se, om de røde markører er nogenlunde jævne. Hvis ja: „Export fold-assignment.json", læg den eksporterede fil i reports-mappen, og ved næste training-run med –benchmark (eller tilsvarende Inspector-indstillinger) bruges præcis denne fold-opdeling som test-holdout — i stedet for standarden „every-8th".

W23Knappen „Open transforms.json…"

HVOR

Toolbar øverst til venstre.

TEKNISK

Åbner en filvælger, begrænset til JSON-filer. Efter bekræftelse indlæser holdout-modulet filen. Loaderen parser både nerfstudio-formatet (kamera-intrinsics plus liste over frames med billedstier og transform-matrix) og instant-ngp-formatet (samme opbygning). Pr. frame udtrækkes kigge-retningen fra transform-matricen (kameraets z-akse i lokalbasis) og gemmes. Hvis parsning fejler, vises en fejlmeddelelse i status-området.

Også via CLI: –holdout-file /sti/til/transforms.json starter vinduet direkte med indlæst fil.

W24Vælger „Strategy" (angular/linear)

HVOR

Venstre sidebar, øverst.

TEKNISK

Radio-vælger med to muligheder: Angular og Linear. Strategy-skift udløser automatisk en gen-beregning af folds. Kigge-retningerne er en liste over 3D-enhedsvektorer på sfæren; angular-strategien projicerer dem på longitudinalvinklen φ og sorterer, linear-strategien laver bare en modulo-opdeling over frame-index.

W25Slider „k Folds"

HVOR

Venstre sidebar, i midten.

TEKNISK

Slider fra 3 til 10, skridtstørrelse 1. Ved ændring udløses fold-beregningen automatisk, så folds-listen, train/test-indices og pr.-fold-scoren beregnes med det samme. Den valgte værdi vises som monospaced-digit-tekst til højre for labelet.

Tommelfingerregel: k=5 er standard (giver dig 20 % test pr. fold, hvilket er almindeligt for cross-validation). k=10 hvis du har meget data og brug for flere folds til statistisk sigende værdi. k=3 hvis du har lidt data.

W26Vælger „Test Fold"

HVOR

Venstre sidebar, under k-slideren.

TEKNISK

Menu-vælger. Muligheder er dynamisk 0..<k, label „Fold 1" til „Fold N" (altså 1-indexed i UI'en, 0-indexed internt). Hvis den tidligere valgte index er ≥ k (f.eks. fordi du har reduceret k fra 10 til 5), nulstilles den automatisk til 0. Den valgte test-fold vises rødt i globussen, alle andre grønt.

W27Knappen „Export fold-assignment.json"

HVOR

Venstre sidebar, nederst.

TEKNISK

Åbner en gem-dialog med default-filnavn fold-assignment.json. Efter bekræftelse koder holdout-modulet den aktuelle opdeling til et JSON-skema (per-frame fold-tildeling plus strategy-meta-blok). Denne fil kan så gives med til næste træning med –benchmark, så samme holdout bruges til den endelige metrik-evaluering. Skrivefejl vises som fejltekst; succes i grøn tekst som „Saved to (filename)".

W28SCNView (3D camera globe)

HVOR

Midter-panel i holdout-vinduet.

TEKNISK

SceneKit-globus-view. Scenen består af: en wireframe-kugle (radius 1.0, 36 segmenter, mørkegrå), tre farvede akse-stumper (rød/grøn/blå for X/Y/Z, hver 1.2 lang) og pr. kamera en lille markerkugle (radius 0.03) ved den tilsvarende kigge-retnings-position på enhedskuglen (let udenfor, så den ikke forsvinder I wireframe-kuglen). Markørerne genopbygges IKKE ved hver fold-ændring — genopbygning er kun nødvendig, når frame-listen ændres (altså når en ny JSON indlæses). I stedet kører en in-place-opdatering af materialefarverne pr. update: rødt for test-index, grønt for træning, lysgrå hvis hverken eller. Sådan forbliver slider-tikker performante også ved N > 1000 kameraer.

Kamera-styringen er aktiveret — du kan rotere globussen med musen, zoome, panorere. Belysning sørger for, at markørerne ikke ser flade ud. Baggrund er mørkegrå.

W29FoldCard (tap to select fold)

HVOR

Højre sidebar, „Angular Correlation"-sektion.

TEKNISK

Pr. fold en kort-view — afrundet rektangel med 6 pt radius, padding 10, vertikalt layout med to linjer (øverst „Fold N" + kamera-antal, nederst „Mean nearest angle:" + værdi i grader). Baggrundsfarve betinget: aktiv fold = accentfarve halvtransparent, inaktive = neutralt standard-material. Tap vælger folden, og globussen farver om live.

„Mean nearest angle"-scoren er den gennemsnitlige mindste vinkel pr. test-kamera til den nærmeste trænings-kamera (i radian internt beregnet, vist i grader i UI'en).

BayesOpt Console (W30–W39)

BayesOpt-konsol — tom tilstand før trial-start
BayesOpt-konsol — tom tilstand før trial-start

Tom tilstand med search-space-vælger (RadianceKit defaults (6-dim)), trial-budget-slider (default 40), random-seed (42) og tre empty-panels for convergence-chart, trial log og search- space-parameter-liste.

Tom tilstand (efter første åbning) — convergence-chart og trial-tabel fylder sig, så snart en run er startet, se næste shot.

BayesOpt-konsol efter 40 trials — convergence-chart stiger stejlt indtil trial 15, Best Value 0.9943, trial log med init/bo/restart-tags
BayesOpt-konsol efter 40 trials — convergence-chart stiger stejlt indtil trial 15, Best Value 0.9943, trial log med init/bo/restart-tags

Status øverst til højre „Finished — best 0.9943 after 40 trials". Venstre sidebar: search-space- vælger på RadianceKit defaults (6-dim), trial-budget 40, random seed 42. Parameter-liste viser de seks hyperparametre, der skal tunes, med deres værdiområder: 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]. Midt: convergence-chart (X = trial-index 1–40, Y = objective value 0–1) — grå punkter = initial samples (LHS), blå punkter = BayesOpt-acquisition, orange punkter = restart-trials (#22 og #31). Bedste-værdi-linjen stiger stejlt til trial ~7, derefter kun marginal forbedring til trial 15, fra da af fladt plateau ved 0.99+. Højre sidebar: trial-log #1–#34 med score + tag (init/bo/restart). Save- Best-Config-knappen øverst til højre skriver bayesopt-best.json.

Hvad det er: En Bayes-optimerings-konsol til hyperparameter-søgning. Bayes-Opt er en automatisk metode, der forsøger at finde det optimale punkt for en ukendt funktion med så få eksperimenter som muligt — typisk: „hvilken kombination af mcmcMaxGaussians, capMultiplier, ssimWeight og gradThreshold giver den bedste PSNR for min scene-klasse?" I stedet for et grid på 6^4 = 1296 trials prøver Bayes-Opt ca. 40–100 informerede trials og kommer dermed tæt på optimum.

Vigtigt: Den aktuelt leverede version i appen kører ikke optimeringen mod ægte trænings-runs (det ville tage dage), men mod et syntetisk demo-objektiv — et multi-modalt landskab med hill-climbing-karakter plus let noise. Det er bevidst sådan: vinduet skal vise dig optimizerens adfærd (konvergens-forløb, sample-punkter, best-so-far) og lade dig forstå search-space- definitionerne. Til ægte trænings-drevne BayesOpt-kørsler (som udført i fase Q7 for scene-class-presets) bruges et separat offline CLI-workflow; vinduet er live-UI-varianten.

Tre anvendelses-tilfælde: 1. Du vil forstå, hvordan BayesOpt arbejder — så start en demo-run og iagttag convergence-charten. 2. Du planlægger en ny scene-klasse (f.eks. „akvarier" eller „antikke møbler"), som de indbyggede 10 presets ikke passer perfekt til. Definér mentalt et søgerum, tjek det her med „Bowl demo" eller „Densify"-preset, eksportér så best-config som JSON og brug det som startpunkt for en ægte trænings-run. 3. Du vil inspicere de default-search-spaces, der er defineret i RKBayesOpt-pakken (Mip-subset, RadianceKit defaults) — de listes i parameter-panelet i venstre sidebar.

- Convergence-chart (midter-kolonnen): Y = bedste hidtil opnåede objective-funktion-værdi. X = trial-index. I starten stejlt stigende (BayesOpt prøver de initial-samples tilfældigt, nogle af dem er heldige), derefter tiltagende fladt, fordi nær-optimum-regionen er udtømt. Hvis linjen forbliver flad i 20+ trials, kan du stoppe kørslen — flere trials giver intet mere. De enkelte punkter i charten er de individuelle trial-værdier (altså ikke „best so far"), farvet efter fase: grå = initial sample, blå = bayesopt acquisition, orange = restart. - Trial-tabel (højre kolonne): #1, #2, #3, … hver med værdi og fase-tag. Det hidtil bedste trial er markeret med en gul stjerne. Ud fra tabellen kan du identificere best-trial og se dets parameter-værdier senere ved eksport. - Search-space-inspector (venstre sidebar): viser for det valgte preset alle parameter-navne og deres søgeområder [lo, hi]. Hvis du står ved presetet „RadianceKit defaults (6-dim)", ser du f.eks. „densifyGradThreshold [5e-7, 5e-6]" — altså log-uniform mellem disse to værdier.

Vælg preset „RadianceKit defaults (6-dim)", trial-budget 40, seed 42. Klik „Start". Iagttag: de første 8 trials er grå (initial samples, LHS-Latin-Hypercube), de følgende blå (BayesOpt-erhvervet). Convergence-charten bliver stejl til trial ~15, derefter flader den ud. Ved trial ~30–40 stabiliseres den bedste værdi. Klik „Save Best Config" — en bayesopt-best.json gemmes med preset-navn, trial-index, værdi og de dekodede parameter-værdier. Denne JSON kan du så manuelt overtage i din preset-definition.

W30Knappen „Start"

HVOR

Toolbar til venstre, i idle/finished-state.

TEKNISK

Nulstiller trial-listen, skifter til running-state, genererer en ny run-ID (til stale-detection ved flere start-klik) og opretter en frisk pause-gate. Derefter starter en baggrunds-task, der kører optimizeren som asynkron stream. Initial- samples-størrelsen følger af min(8, budget / 4 + 1) — altså typisk 8 Latin-Hypercube-samples ved budget ≥ 28, færre ved lille budget. Trial-updates modtages inkrementelt og vedhæftes listen. Stale-run-beskyttelse: hvis et andet start-klik i mellemtiden sætter run-ID på ny, kastes updates fra den gamle run væk.

Primary-action-stil til den prominente knap-look.

W31Knappen „Pause"

HVOR

Toolbar til venstre, i running-state.

TEKNISK

Sætter pause-gate aktiv og skifter til paused-state. Den egentlige effekt: runneren venter i et 50-ms-polling-loop, før den evaluerer næste objective-funktion. Det betyder, at et igangværende trial føres til ende (det er syntetisk og varer kun mikrosekunder), men intet yderligere trial startes. Så snart resume kører, fortsætter den, hvor den slap.

W32Knappen „Stop"

HVOR

Toolbar til venstre, i running- og paused-state.

TEKNISK

Afbryder runner-tasken, nuller referencen, løser pause-gate (hvis stadig paused), og skifter til finished-state (hvis trials findes) eller idle-state (hvis ingen). De allerede beregnede trials forbliver synlige i listen — stop sletter dem ikke. Destruktiv knap-rolle viser knappen rød, fordi den afbryder kørslen.

W33Knappen „Resume"

HVOR

Toolbar til venstre, i paused-state.

TEKNISK

Løser pause-gate og skifter tilbage til running-state. Runner-tasken kører allerede (den venter jo i polling-loopet); så snart loopet bemærker, at pausen er ophævet, kører den videre og starter næste trial.

W34Knappen „Save Best Config"

HVOR

Toolbar til højre, altid synlig (men deaktiveret, hvis ingen bestTrial findes).

TEKNISK

Åbner en gem-dialog med default-filnavn bayesopt-best.json, begrænset til JSON. Efter bekræftelse bygges en payload-dictionary: preset-navn, trial-index, værdi (objective- score), parametre (dictionary af dekodede parameter-navne → værdier). Dekodningen projicerer de normaliserede søgerum- koordinater i [0,1]^d tilbage til det oprindelige værdiområde (med log-uniform/linear/integer-skalaer tilsvarende). JSON-output er pretty-printed med sorterede keys. Ved skrivefejl ignoreres det (i den aktuelle demo-version) stille — ingen error-UI, fordi det er en demo-sti.

Knappen forbliver grå, så længe ingen trial er kørt.

W35Vælger „Search Space"-preset

HVOR

Venstre sidebar, øverst.

TEKNISK

Menu-vælger med fire preset-muligheder: - „RadianceKit defaults (6-dim)" — det fulde standard-søgerum med alle Q7-hyperparametre. - „Mip subset (2-dim)" — kun mipSmoothing3DScale [0.05, 0.5] log-uniform og mipFilter2DVariance [0.1, 0.6] linear. Nyttig, hvis du vil tune Mip-splatting for en scene-klasse. - „densify-until + ssim-weight + grad-thresh" — tre densify-relevante parametre (densifyGradThreshold log-uniform, ssimWeight linear, densifyUntilIter integer). - „Bowl demo (1-dim)" — pædagogisk single-parameter-søgerum til „sådan virker BayesOpt"-demoer.

Mens en kørsel er aktiv, kan søgerummet ikke skiftes (ville forvirre optimizeren).

W36Slider „Trial Budget"

HVOR

Venstre sidebar, under search-space-vælgeren.

TEKNISK

Slider fra 10 til 200, skridtstørrelse 5. Default 40. Det betyder: BayesOpt må maksimalt lave N trials. Heraf er de første par initial samples (Latin-Hypercube), resten er ægte BayesOpt-trials. Tommelfingerregler i praksis: et søgerum med d dimensioner kræver ca. 10d til 20d trials for et godt optimum. Ved 6-dim defaults altså 60–120, ved 2-dim Mip-subset 20–40, ved 1-dim Bowl-demo 10–20.

Under kørslen er slideren deaktiveret.

W37Slider „Random Seed"

HVOR

Venstre sidebar, under budget-slideren.

TEKNISK

Slider fra 1 til 100, skridtstørrelse 1. Default 42. Seedet sendes både til de initiale Latin-Hypercube-samples og til noise-komponenten i demo-objective. Reproducerbarhed: samme seed + samme søgerum + samme budget giver præcis identisk trial-sekvens. Nyttig til „får alle dine kolleger samme kørsel, hvis de bygger demoen efter?". Under kørslen deaktiveret.

W38Chart (convergence)

HVOR

Midt-kolonnen i vinduet.

TEKNISK

Swift-Charts-diagram med to lag: 1. en linje for „best-value-so-far" pr. trial — en monotont stigende eller konstant kurve i accentfarve. 2. et punkt pr. trial med den individuelle objective-værdi, farvet efter fase. Symbol-størrelse 40. Tre fase-labels: „init" (grå), „bo" (blå), „restart" (orange).

En lille legende viser fase-farverne øverst til venstre. Hvis trial-listen er tom (før første start), vises i stedet en empty-state-visning med chart-ikon og hintet „Press Start to begin a BayesOpt run.".

W39Table (trial log)

HVOR

Højre kolonne i vinduet.

TEKNISK

Scroll-område med lazy stablede trial-linjer. Pr. linje et horisontalt stack: trial-nummer (3-cifret monospaced, til venstre), værdi (monospaced, højrejusteret, 70 pt bred), fase-tag (capsule, fyldt med fase-farve ved 25 % opacity), valgfrit en gul stjerne, hvis dette trial er det aktuelt bedste. En auto-scroll-mekanisme springer automatisk til enden, så snart et nyt trial kommer til — så du kan medlæse live-forløbet i skærmens bund uden selv at scrolle.

Hovedvindue: loss-forløb og gaussian-count (I39–I41, krydshenvisning)

Tre af Inspector-visningerne i hovedvinduet fortjener en egen forklaring, fordi de ses konstant under en kørende træning, og der er vigtige tommelfingerregler for, hvornår forløbet ser sundt ud. Visningerne er i Inspectoren under „Loss Chart"-sektionen (se kapitel 2 — Inspector) og supplerer holdout-analysen fra hjælpevinduet ovenfor.

Hvornår er loss-kurven sund? En sund loss-kurve viser tre faser: (1) Warmup — i de første 200–500 iterationer falder loss'en stejlt fra højt (typisk 0.15–0.25 for L1+SSIM-kombineret afhængigt af scenen) til ca. halvdelen. Hvis loss'en IKKE falder i denne fase, er input som regel forkert (billeder defekte, SfM-positioner dårlige, antal initial-gaussians for lille). (2) Densification — mellem ~500 og densifyUntilIteration (klassisk 15K, MCMC til 20K eller 25K) falder loss'en videre, ofte med små spring nedad, når densify- operationerne indsætter nye gaussians, og optimizeren udnytter dem. Gaussian-count stiger i denne fase. (3) Refinement — derefter kører loss'en ud i en fladere hale. Typiske slutværdier: Tanks-&-Temples Truck med P4 Quality lander ved L1 ≈ 0.023, Horse med Full Classic V546 ved L1 ≈ 0.0230, outdoor-Mip-NeRF360-scener ofte dårligere (0.04–0.07).

Hvad betyder et plateau? Et plateau (loss-kurven løber horisontalt over flere tusinde iterationer) har to fortolkninger: (a) modellen er konvergeret, yderligere træning giver intet mere — det er den gode situation. (b) Modellen er stuck (lokalt minimum, dårlig gradient-information, et cap ved buffer-grænsen) — den dårlige situation. Begge ser identiske ud i charten. Skelnen: kig på gaussian-count. Hvis den også er flad OG tæt på MCMC-cap'et (f.eks. 150K af 150K ved .fullMCMC), er du ved grænsen — enten hæv cap'et eller acceptér plateauet. Hvis gaussian-count stadig vokser, men loss'en ikke falder, hænger den fast.

Hvornår afbryde vs videretræne? Tommelfingerregel: 10K iterationer uden forbedring af min-loss → afbryd, yderligere iterationer er spildt. Før: kan du via Cmd+T (training-menuen → Continue Training → +5K iterations) stadig hænge en forlængelse på, hvis du ser grænsemæssig forbedring. Advarsel: ved MCMC er plateauet ofte ægte — cap'et er den naturlige grænse.

Gaussian-count-plateau er IKKE et „færdig"-signal. Det betyder kun, at MCMC har nået cap'et, eller at Classic densification er udtømt. Det egentlige „færdig"-spørgsmål stilles først af holdout-analysen — PSNR/SSIM/LPIPS på et uafhængigt test-sæt, evalueret i holdout-vinduet (W23–W29) eller via –benchmark-flag.

PSNR/holdout er sandheden, loss kun proxy. Loss'en er en relativ metrik: den falder, mens din model tilpasser sig trænings-views. En lav loss betyder dog ikke automatisk god model — hvis modellen har lært trænings-billederne udenad (overfitting), ville loss'en være lille, men PSNR på usete views (holdout) ville være dårlig. Derfor: til den endelige kvalitetsbedømmelse kig altid på holdout-metrikker, ikke på end-loss alene.

Tommelfingerregel-boks

- User Guide og Keyboard Shortcuts er statisk hjælp — ved stikordsspørgsmål hurtigt, til dybde brug denne manual. - Manage Storage åbnes, så snart disken falder under 10 % fri plads. Logs og imports-staging er de sædvanlige syndere. - Pareto Dashboard er først meningsfuldt efter mindst tre eller fire trænings-reports. X-akse = omkostninger (time / Gs), Y-akse = kvalitet (PSNR / SSIM). Pareto-fronten viser de effektive kombinationer. - Holdout Analysis bruges, før du offentliggør PSNR-benchmarks med andre — det sikrer dig, at dit test-sæt virkelig er repræsentativt. - BayesOpt Console er primært et lærings- og inspektions-værktøj til søgerum-definitioner. Til ægte trænings-drevet hyperparameter-tuning brug offline CLI-workflowen. - Loss-plateau og gaussian-count-plateau skal fortolkes adskilt. Cap-grænse er ikke et „færdig"-signal. Ægte kvalitet måler kun holdout-PSNR. - 10K iterationer uden min-loss-forbedring → stop træning.