Kapittel 4 — Hjelpevinduer

Foruten hovedvinduet (3D-viewport pluss Inspector) forvalter RadianceKit syv ytterligere vinduer, som alle åpnes via Help-menyen. Listen er fra topp til bunn: User Guide (⌘?), Keyboard Shortcuts (⌘/), Open Training Logs… (åpner ikke et app-vindu, men Finder; derfor ikke ytterligere behandlet her), Manage Storage…, Pareto Dashboard… (⇧⌘D), Holdout Analysis… (⇧⌘H), BayesOpt Console… (⇧⌘B). Tre av dem — Dashboard, Holdout, BayesOpt — er selvstendige analyseverktøy. De har hver sin egen view-model-stack, leser eller skriver JSON-filer på disk, og for hver finnes det et CLI-argument hvor du kan få vinduet til å peke direkte på en bestemt fil ved app-start (–dashboard-dir, –holdout-file, –bayesopt-autorun).

De fire enkle vinduene (User Guide, Keyboard Shortcuts, Manage Storage, pluss undermeny-punktene Open Training Logs / Open Exports Folder) får per styreelement en kort oppføring. De tre analysevinduene er mer utførlig dokumentert — hver med en innledning som forklarer hva du ser i vinduet, når du bør åpne det, og hvordan du tolker det viste bildet.

Sist i kapittelet er det et krysshenvisningsavsnitt til hovedvinduets Inspector: hva du fornuftig kan lese av i live- loss-charten og gaussian-count-visningen under en kjørende trening.

User Guide (W1–W4)

Hva det er: Et innebygd hjelpevindu som rendrer den medfølgende guide_<sprog>.md. Språket avledes av innstillingene (fanen General → Language) eller, hvis „System" står der, av macOS-språkpreferansene. Layout er klassisk: til venstre sidefelt med alle overskrifter, til høyre brødteksten.

Når du trenger en rask påminnelse om et enkelt punkt — altså som stikkordserstatning. Den utførlige referansen er denne manualen; det innebygde hjelpevinduet er heller det en –help på kommandolinjen ville være. Det oppdateres ved hver app-utgivelse, men holdes innholdsmessig overflatisk.

W1NavigationSplitView (sidefelt + detalj)

HVOR

Help → User Guide (⌘?).

TEKNISK

Tospalters layout med smalt sidefelt (minst 180 pt bredt) for innholdstreet og et scrollbart detaljområde for selve markdown-innholdet. Vinduet har en minimumsstørrelse på 700 × 500 pt. Ved første åpning laster vinduet den passende guide_<lang>.md fra app-bundlen (fallback guide_en.md), parser den til blokk-records (overskrifter H1–H4, avsnitt, lister, tabeller, separator-linjer) og trekker ut separat overskriftsstrukturen for sidefeltet. Inline-formatering (fet, kursiv, code-span) rendres via den innebygde markdown-engine. Språket leses fra app-innstillingene, med spesialtilfellet kinesisk (zh-Hans) og brasiliansk portugisisk (pt-BR), som bevares som fulle locale-tags fordi disse variantene skiller seg fra zh og pt.

W2List (heading-sidefelt)

HVOR

Venstre kolonne i User Guide-vinduet.

TEKNISK

Liste over alle H2- og H3-overskrifter i det aktuelle markdown-dokumentet. H2-oppføringer dukker opp uten innrykk med medium skriftsnitt, H3-oppføringer med 16 pt innrykk til venstre og redusert foreground-stil. H4 og dypere ignoreres fordi dybden ellers gjør sidefeltet uoversiktlig. Anker-ID-er genereres fra heading-teksten via slugifisering (lowercase + mellomrom til streker + filtrering på bokstaver/tall/streker — samme algoritme som GitHub bruker til markdown-ankrene sine, slik at også eksterne URL-er til doc potensielt ville lande på samme anker). Listen bruker native macOS-stil.

W3Button (heading → anker-sprang)

HVOR

Per sidefelt-linje en knapp.

TEKNISK

Hver sidefelt-oppføring er en knapp som setter det aktuelle ankeret, men optisk ser ut som en liste-oppføring. En observatør-variabel utløser så scroll-spranget til det tilsvarende ankeret med en myk animasjon over 0,3 s. Etter spranget nullstilles anker-verdien slik at neste klikk på samme anker utløser igjen (ellers ville observatøren ikke utløse på nytt fordi verdien ikke har endret seg).

W4ScrollView (detalj-innhold)

HVOR

Høyre kolonne.

TEKNISK

Scrollbart, vertikalt stablende innholdsområde med lazy rendering fordi lengre guides lett kan ha over 200 markdown-blokker — en ikke-lazy variant ville instansiere dem alle samtidig. Hver blokk får en egen ID, enten heading-ankeret (for hoppbare H1–H3) eller en indeks-plassholder. Maksimumsbredde er 720 pt, padding 32 horisontalt / 24 vertikalt, slik at lange linjer beholder et godt lesbart layout. Tabeller rendres celle-vis med horisontale stacks og separator-linjer; inline-kode av den innebygde markdown-engine. Egentlige kodeblokker behandles aktuelt som paragraph — en kjent begrensning ved hjelpevinduet.

Keyboard Shortcuts (W5–W6)

Statisk referanseliste i fem seksjoner. Navigation: Mouse Drag (orbit/fly), Shift+Drag/Right-Drag (pan), scroll (zoom), WASD (fly-through- bevegelse), Q/E (opp/ned), F (toggle orbit/fly), dobbeltklikk (re-center), Cmd+scroll (FoV-justering). Views: R (reset camera), T (auto-rotation), P (camera playback), B (background- cycle), 0–9 (hopp til training-cam 1=10 %/5=50 %/0=last), venstre/høyre pil (prev/next cam). Capture: S (skjermbilde til desktop), V (turntable-video), C (copy camera info). Editor: Tab (edit-mode), klikk/dra (paint-select), Option+klikk (deselect), X / Delete (slett seleksjon), Cmd-Z (angre siste sletting), [ / ] (pensel mindre/større), Esc (opphev seleksjon). Training: Start, Pause/Resume, Cancel, Continue +5K/+10K/+20K via menyhurtigtastene i M9–M14.

Hva det er: En enkel statisk oversikt over alle hurtigtaster — Navigation, Views, Capture, Editor, Training. Innhold er hardkodet i, ingen markdown-loading.

Når du leter etter den raskeste veien til å gjøre noe i viewporten. WASD-fly-through, R til camera-reset, B til background-cycling — alle står her.

W5ScrollView (innholdsområde)

HVOR

Help → Keyboard Shortcuts (⌘/).

TEKNISK

Et enkelt scroll-område med en vertikal liste i. Padding 20 hele veien rundt, ingen sidefelt-navigasjonstre (listen er kort nok). Innhold er gruppert i fem seksjoner (Navigation, Views, Capture, Editor, Training). Per tastekombinasjon en linje med oversettbar tekst i begge kolonner. Venstre kolonne (tastekode) fastgjort til 180 pt bredde, slik at beskrivelsene til høyre forblir vertikalt aligned. Ingen interaksjon ut over scrolling — klikk på en linje utløser ingenting, hurtigtastene er ekte tastatur- modifiers i menyen og på viewporten.

W6VStack (shortcut-seksjoner)

HVOR

Innenfor ScrollView.

TEKNISK

Venstrejustert stablede seksjoner med 16 pt avstand. Innenfor de fem seksjonene hver heading + linjefølge. Headings bruker en sekundær subheadline-stil — bevisst ikke title-format fordi seksjonene ikke trenger å være navigerbare. Innhold er bevisst flatt (ingen disclosure, ingen search, ingen filter), slik at komponenten kjører uendret på enhver macOS-versjon, og filen forblir lesbar.

Manage Storage (W7–W12)

Tabellvisning av alle filer RadianceKit forvalter. Header teller 693 items, 16.74 GB samlet størrelse. Toolbar øverst: „Show in Finder" + „Refresh". Hver linje: PLY-ikon, filnavn (f.eks. training_20260527T211321Z.ply), eksportdato, størrelse (varierer 7 KB til 218 MB), forstørrelses- ikon (reveal) og papirkurv-ikon (move to trash). Filer er sortert etter dato, nyeste øverst. I dette demo-opptaket dominerer PLY-eksporter fordi det er arbeidet mye med –benchmark.

Hva det er: En disk-usage-oversikt for alt RadianceKit legger under ~/Documents/RadianceKit/ — logs, exports, scenes, capture-bundles (fra iOS-companion), imports (staging-kopier av input-bildene). Per oppføring en størrelse i bytes og to knapper: „vis i Finder" og „flytt til papirkurv". Det er INGEN automatisk opprydding — appen sletter ingenting selv; du bestemmer per oppføring.

Når disken blir full. Spesielt logs samles opp (en JSONL per treningsforsøk, pluss _qualityMetrics.json); eksportene også (PLY 100 % rådata, en per eksport). Også nyttig etter en krasj der imports-staging-mappen har gamle kopier av input-bildene liggende (se „disk-pressure incident" i dev_v549f-needle-reduction.md).

W7Knappen „Show in Finder"

HVOR

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

TEKNISK

Åpner hele RadianceKit-mappen (~/Documents/RadianceKit/) i Finder, slik at du kan se mappestrukturen direkte og også manipulere den med Finder selv. Handlingen åpner et nytt Finder-vindu og bytter ikke til app-sandbox-containeren — ~/Documents/RadianceKit/ er det regulært app-tilgjengelige Documents-domenet, ingen sandboxed-container-sti.

W8Knappen „Refresh"

HVOR

Header, ved siden av Finder-knappen.

TEKNISK

Utløser en bakgrunnsscanning som kjører på en brukerinitiert asynkron task, slik at scanningen av store mappetrær ikke blokkerer UI-en. Selve gjennomgangen går hver kjent undermappe (Logs, Exports, Scenes, Captures, Imports) gjennom og genererer en storage-oppføring per direkte barn. Per oppføring bestemmes den rekursive størrelsen — helst det faktiske diskforbruket (inkludert APFS-hardlinks-sharing) med fallback på den logiske filstørrelsen.

W9List (storage-oppføringer)

HVOR

Hovedinnhold under headeren.

TEKNISK

Liste med dette layoutet per linje: kategori- spesifikt SF-symbol-ikon (dokument for logs, upload-pil for exports, terning for scenes, tray for imports), navn + undertittel (kind-label + formatert modifikasjonsdato), bytes-teller til høyre (høyrejustert, monospaced), reveal-knapp (forstørrelses- symbol), trash-knapp (papirkurv). Sortering: primært etter kind (scenes først, så exports, logs, captures, imports, other), sekundært etter modifikasjonsdato fallende (nyeste øverst). Hvis scanningen fortsatt kjører, viser stedet i stedet en „Scanning…"- fremgang. Hvis ingenting ble funnet, en empty-state-visning med tray-ikon.

W10Row-knapp „Reveal in Finder"

HVOR

Per linje, forstørrelses-symbol til høyre.

TEKNISK

Åpner Finder og velger den spesifikke oppføringen (fil eller mappe). Forskjell fra W7: W7 åpner rotmappen; W10 markerer nøyaktig denne ene oppføringen. Praktisk workflow: identifiser en stor oppføring, klikk på forstørrelsen, kopier den så f.eks. til et eksternt volume.

W11Row-knapp „Move to Trash"

HVOR

Per linje, papirkurv-symbol til høyre for forstørrelsen.

TEKNISK

Utløser bekreftelsesdialogboksen (W12). Først etter bekreftelse kjører macOS-standardoperasjonen „flytt til papirkurv" (altså reversibel, ingen direkte sletting). Etter vellykket trash fjernes oppføringen fra listen, og total-byte-telleren oppdateres. Ved feil slås det inn en modal feildialog.

W12ConfirmationDialog (slettebekreftelse)

HVOR

Utløses av W11, vises som macOS-sheet.

TEKNISK

Standard bekreftelsesdialog med dynamisk tittel „Delete <navn>?" og en meldingslinje som eksplisitt påminner om at oppføringen lander i papirkurven og kan gjenopprettes derfra (inntil 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 bare blokkerer dette vinduet, ikke hele appen — det er macOS-standard for reversible slettinger.

Pareto Dashboard (W13–W22)

Tom tilstand (etter første åpning) — empty-state med call-to-action „Open Reports Folder…". Datapunktene dukker opp så snart treningsreports er lastet inn, se neste shot.

Header-toolbar viser „129 reports of 129" (alle reports i den valgte mappen ble parsed med suksess — 21 ytterligere filer kunne ikke parses pga. eldre format, se hint-listen til høyre). Akser: X-Axis-velger på Gaussians, Y-Axis-velger på PSNR (dB). Scatter-plot: grønne punkter = Classic-strategi, blå punkter = MCMC. Den stiplete Pareto-front- linjen løper langs de best oppnådde PSNR-verdiene og platåer omkring PSNR≈30 dB fra ca. 500K gaussians. Filter-chips til høyre: 7 scener (bicycle, bonsai, family, flowers, kitchen, stump, truck), 2 strategier (classic, mcmc), 3 Mip-splatting-alternativer (All, On, Off). For øyeblikket er alle filtre åpne, derav den tette punktklyngen.

Hva det er: Et multi-run-sammenligningsverktøy. Du har i fortiden trent flere scener eller samme scene med forskjellige presets — hver av disse treningskjøringene produserer (hvis du har gitt med –benchmark eller kalt via benchmark-funksjonen) en JSON-report-fil som bl.a. inneholder final-PSNR, SSIM, LPIPS, gaussian-count og wallclock-tid. Dashbordet laster inn en hel mappe med slike reports samtidig og plotter dem som 2D-scatter med valgbare akser. I tillegg tegnes Pareto-fronten (mengden av ikke-dominerte punkter) som stiplet linje.

Etter at du har opprettet minst tre eller fire treningsreports. Med færre punkter er frontier-linjen ikke sigende. Typisk use-case: du har prøvd å rekonstruere en outdoor-scene og har spilt P3 Balanced (Classic), P4 Quality (Classic), P7 MCMC Quality og P9 Outdoor (tuned) gjennom etter hverandre — nå vil du vite hvilken konfigurasjon som leverer beste PSNR per sekund treningstid, eller hvilken som krever færrest gaussians for gitt PSNR.

Begge akser kan fritt velges (X-akse:,, psnr, ssim, lpips, …; Y-akse likeså). Pareto-front-logikken i ParetoFront2D.indices vet for hver metrikk om „mindre = bedre" (f.eks. LPIPS, Loss, Time) eller „større = bedre" (PSNR, SSIM) — linjen løper altså avhengig av akse-valget fra nederst til venstre til øverst til høyre eller fra øverst til venstre til nederst til høyre, alltid langs den beste oppnådde kombinasjonen. Et punkt er Pareto-optimalt hvis INGEN andre punkter i BEGGE dimensjoner er minst like gode (altså ingenting annet dominerer det). Pareto-optimale punkter ligger på linjen, andre punkter til høyre/over (avhengig av akseorientering). Punkter PÅ linjen er de ekte kandidatene for „beste preset"; punkter LANGT fra linjen er bortkastet treningstid.

Du kan begrense valget til en bestemt scene (hvis du f.eks. bare vil sammenligne outdoor-runs), til en bestemt strategi (Classic eller MCMC), eller Mip-splatting på/av (relevant etter fase Q1.5 hvor Mip forblir 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). Sett X-aksen til trainingTime, Y-aksen til PSNR. Run B ligger øverst til høyre, Run C enda lengre mot øverst til høyre, Run A nederst til venstre. Pareto-fronten forbinder A og C — begge ikke-dominerte. Run B er „lost" (C er bedre i både time OG PSNR). Innsikt: for „truck" er MCMC-defaulten ikke verdt det; enten rask+ok (A) eller lang+veldig god (C). Lagre konfigurasjonen fra C som egen preset (Inspector → I1 Save Preset).

Neste handling: Lagre beste konfigurasjon som preset. Konkret: kikk på Pareto-punktene (hover viser PSNR/SSIM/LPIPS/Gs/ Time i tooltippet), bestem hvilken time-vs-quality-tradeoff som passer best, åpne den tilhørende reporten (filnavnet inneholder run-timestampet), kopier dens treningskonfigurasjon i en ny run eller lagre den etter neste treningssesjon som preset via Inspector.

W13Knappen „Open Reports Folder…"

HVOR

Toolbar øverst til venstre.

TEKNISK

Åpner en mappevelger med oppfordringen „Select a folder containing benchmark .json reports". Etter bekreftelse kjører en bakgrunnstask som parser alle .json-filer i mappen sekvensielt. Feilaktige reports (defekt JSON, feil skjema) samles og vises nederst i sidefeltet som „N file failed to parse" — ingen krasj. Hvis det kommer et annet klikk mens en første load fortsatt kjører, avbrytes den tidligere tasken slik at det ikke skrives to resultater inn i state samtidig.

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

W14Velger „X-Axis"

HVOR

Over charten, til venstre.

TEKNISK

Menyvelger med alle tilgjengelige metrikkakser i dashboard-modulet (PSNR, SSIM, LPIPS, gaussian-count, treningstid og så videre). Default er gaussian-count. Ved bytte nullstilles det hoverede punktet fordi en hittil highlightet posisjon i det gamle aksekoordinatsystemet ikke lenger gir mening etter aksebytte. Velgeren er begrenset til innholdsbredden slik at den ikke spenner over hele bredden.

W15Velger „Y-Axis"

HVOR

Over charten, ved siden av X-Axis.

TEKNISK

Identisk med W14, bortsett fra at default er PSNR. Aksevalget lagres uavhengig, slik at brukeren også kan velge tøysekombinasjoner (X=PSNR, Y=PSNR — ville kaste alle punkter ned på en diagonal). Slike kombinasjoner fanges imidlertid ikke; bevisst beslutning fordi en sammenligning „SSIM vs PSNR" sikkert kan være interessant for å se hvor konsistent metrikkene oppfører seg.

W16Toggle „Show Pareto Front"

HVOR

Til høyre for akse-velgerne.

TEKNISK

Standard macOS-toggle. Når aktiv tegnes utover punktskyen i Pareto-charten en linje med den beregnede 2D-Pareto-fronten. Stil: stiplet (stregmønster 4–4), grå halvtransparent, linjetykkelse 1,5 pt. Pareto-beregningen kjører på hovedtråden — ved det typiske antallet reports (≤ ~50) er det problemfritt raskt. Når toggle er av, utelates linjen slik at bare de nakne punktene står.

W17Chips „Scene"-filter

HVOR

Høyre sidefelt i dashboard-vinduet.

TEKNISK

Filter-chips for hver scene som dukker opp i de innlastede reportene. Eget flow-layout som automatisk ompakker chips i flere linjer så snart bredden er utnyttet. Aktive chips får accent-bakgrunn, inaktive en nøytral standard-material-bakgrunn. Multivalg er mulig (set-semantikk); hvis ingen chip er valgt, gjelder alle scener som „sluppet inn" — dvs. set-logikken er „tomt valg = alt", ikke „tomt valg = ingenting".

W18Chips „Strategy"-filter

HVOR

Under scene-filteret i sidefeltet.

TEKNISK

Nøyaktig som W17, men for treningsstrategier — typisk de to verdiene „classic" og „mcmc", avledet fra strategy- feltet i benchmark-report-JSON-ene. Hjelpsom hvis du har blandet reports fra begge strategier og bare vil se den ene typen (f.eks. „vis bare MCMC-runs fordi jeg har utelukket Classic").

W19Chips „Mip-Splatting"-filter

HVOR

Under strategy-filteret i sidefeltet.

TEKNISK

Treverdis-filter (i stedet for set som W17/W18): „All" / „On" / „Off". Bakgrunn: Mip-splatting ble evaluert i fase Q1.5 som eksperimentell multi-skalering, og det endelige verdiktet var „ingen pen win gjennomgående; beholdt som opt-in flag". Når du gjør Mip-on/off-sammenligninger, vil du ofte kunne skille veldig skarpt. Derfor det dedikerte ternære filteret med tilstandene „la alt igjennom", „bare Mip på", „bare Mip av". Sidefelt-seksjonen slås på bare hvis det er minst én Mip-report OG minst én ikke-Mip-report i datamengden (ellers gir filtreringen ingen mening).

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

HVOR

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

TEKNISK

Minimalistisk knapp-wrapper. Innhold: label-tekst med caption-skriftgrad og padding 10 horisontalt / 5 vertikalt. Bakgrunn betinget: når aktiv → app-accentfarge med hvit tekst; ellers nøytral standard-material-bakgrunn med sort tekst. Formen er en capsule (pilleformet). Plain-buttonstyle slik at capsule-materialet ikke dekkes over av en system-border.

W21Chart (Pareto-scatter)

HVOR

Midten av dashbordet.

TEKNISK

Swift-Charts-diagram med to lag: 1. et punkt per report — posisjon fra de valgte X- og Y-metrikkene, farge etter strategy, symbol etter Mip-status. Symbolstørrelse normalt 80, highlightet 200 (når ID svarer til den aktuelt hoverede reporten). 2. en linje for Pareto-fronten, bare hvis toggle er på.

Chart-overlay: et transparent rektangel registrerer musebevegelse; per frame bestemmes den euklidisk nærmeste punktposisjonen i plot-frame, og den hoverede reporten oppdateres hvis distansen er under 24 px (ellers nullstilt). Slik får du tooltippet uten klikk — hover holder.

W22Tooltip (hover-detalj)

HVOR

Under charten, slått inn ved hover.

TEKNISK

Horisontalt stack: scenenavn (headline), strategy- tag (caption), separatorlinje, så PSNR/SSIM/LPIPS/Gs/Time-metrikker i hver en liten vertikal gruppe (label + monospaced verdi). Hvis Mip var aktivert, dessuten en „Mip"-capsule-tag i accentfarge. Bakgrunn halvtransparent blur, avrundet rektangel med 8 pt radius. Vises bare når musen faktisk er over et punkt. Forsvinner automatisk ved forlating.

Holdout Analysis (W23–W29)

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

Tom tilstand (etter første åpning) — kameramarkørene dukker opp så snart en transforms.json er lastet inn, se neste shot.

Header viser innlastet fil (transforms_train.json) og cam-count („100 cameras"). Venstre sidefelt: strategy-velger med to alternativer — Angular (longitudinal) aktiv (justerer folds etter lengde-/breddesektorer på sfæren slik at hver test-fold er geometrisk tett) vs Linear (round-robin) (rekkefølge-basert, alle k-te frames som test-sett). k-Folds-slider står på 5, test-fold-velger på fold 1. Export-knapp genererer en fold-assignment.json for Nerfstudio/Instant-NGP. Midt-panel: 3D-globus-projeksjon av alle 100 kameraer — grønne punkter = train, røde punkter = aktuell test-fold (fold 1 med 20 kameraer). Høyre sidefelt (Angular Correlation): per 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 verdi betyr at kameraene innen denne folden ligger tett sammen, altså at holdout-splittet er romlig koherent.

Hva det er: En 3D-visualizer for kameraarrangementet ditt med cross-validation-logikk. Du laster inn en transforms.json (standardformatet fra Nerfstudio / Instant-NGP for kameraposer), appen leser alle kameraer, projiserer blikkretningene deres på en enhetskule og viser dem som små kulemarkører på en virtuell globus. Deretter deler den kameraene inn i k folds (etter valgt strategi: angular eller linear), markerer grønt for treningsdelen og rødt for testdelen (holdout) og beregner per fold en angular-correlation-score som forteller deg hvor langt test-folden ligger fra trenings-folden i blikkvinkel-rommet.

Når du vil gjøre holdout-evaluering — altså: hvor godt generaliserer modellen din til usette blikkvinkler? Standard i treningen er „every-8th view som holdout" (Mip-NeRF360-konvensjon), men det er en veldig lineær oppdeling. Hvis bildene dine f.eks. er tidsmessig klyngete (først én side av objektet, så den andre), er „every-8th" ikke representativ — en tilfeldig sekvensposisjon lander i testen, men alle naboene er i treningen, det er for lett. Med „angular" stratifiserer man i stedet over blikkvinkel-rommet: hver fold inneholder kameraer fra alle deler av orbiten, slik at testen virkelig prøver generaliseringshull.

Angular vs Linear: - Angular (standard): deler kameraene etter longitudinalvinkel (φ-koordinat rundt Y-aksen) i k like sektorer. Fold 0 er kameraer med φ ∈ [0°, 360/k°), fold 1 de neste, og så videre. Fordel: hver fold dekker en delregion av orbiten; test-folden er romlig kompakt, men bredt fordelt over verdens-datasettet. God for klassiske orbit-opptak. - Linear (round-robin): fold-indeks = (image_index modulo k). Det er den enkle „every-k-th"-oppdelingen. Fungerer hvis bilderekkefølgen ingen spatial bias har (f.eks. tilfeldig sorterte droneopptak). Fungerer dårlig når bildene klynger seg tidsmessig.

I 3D-globusen ser du straks: grønne punkter (trening) og røde punkter (test). Hvis de røde punktene alle klynger seg i et hjørne, er holdout dårlig (ingen god generaliseringstest). Hvis de ligger jevnt mellom de grønne, er den god. Angular-correlation- scoren per fold (høyre sidefelt, i grader) forteller dessuten: mindre verdi = testen er tett på treningen (hvert test-kamera har et nært treningskamera, lett test); større verdi = testen er langt fra treningen (hardere generalisering).

Du har tatt opp truck-scenen din med 251 bilder, eksporterer via menypunkt M33 (Export SfM transforms.json) en nerfstudio-fil. Åpne holdout-vinduet (⇧⌘H), last inn JSON-en via „Open transforms.json…", kikk på globusen. k=5 (default) gir deg 5 folds. Klikk på „Fold 3" — se om de røde markørene er noenlunde jevne. Hvis ja: „Export fold-assignment.json", legg den eksporterte filen i reports-mappen, og ved neste training-run med –benchmark (eller tilsvarende Inspector-innstillinger) brukes nøyaktig denne fold-oppdelingen som test-holdout — i stedet for standarden „every-8th".

W23Knappen „Open transforms.json…"

HVOR

Toolbar øverst til venstre.

TEKNISK

Åpner en filvelger, begrenset til JSON-filer. Etter bekreftelse laster holdout-modulet filen. Lasteren parser både nerfstudio-formatet (kamera-intrinsics pluss liste over frames med bildestier og transform-matrise) og instant-ngp-formatet (samme oppbygning). Per frame trekkes blikkretningen ut fra transform-matrisen (kameraets z-akse i lokalbasis) og lagres. Hvis parsing feiler, vises en feilmelding i status-området.

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

W24Velger „Strategy" (angular/linear)

HVOR

Venstre sidefelt, øverst.

TEKNISK

Radiovelger med to alternativer: Angular og Linear. Strategy-bytte utløser automatisk en gjenberegning av folds. Blikkretningene er en liste over 3D-enhetsvektorer på sfæren; angular-strategien projiserer dem på longitudinalvinkelen φ og sorterer, linear-strategien gjør bare en modulo-oppdeling over frame-index.

W25Slider „k Folds"

HVOR

Venstre sidefelt, i midten.

TEKNISK

Slider fra 3 til 10, skrittstørrelse 1. Ved endring utløses fold-beregningen automatisk, slik at folds-listen, train/test-indices og per-fold-scoren beregnes umiddelbart. Den valgte verdien vises som monospaced-digit-tekst til høyre for labelet.

Tommelfingerregel: k=5 er standard (gir deg 20 % test per fold, noe som er vanlig for cross-validation). k=10 hvis du har mye data og trenger flere folds for statistisk sigende verdi. k=3 hvis du har lite data.

W26Velger „Test Fold"

HVOR

Venstre sidefelt, under k-slideren.

TEKNISK

Menyvelger. Alternativer er dynamisk 0..<k, label „Fold 1" til „Fold N" (altså 1-indexed i UI-en, 0-indexed internt). Hvis den tidligere valgte indeksen er ≥ k (f.eks. fordi du har redusert k fra 10 til 5), nullstilles den automatisk til 0. Den valgte test-folden vises rødt i globusen, alle andre grønt.

W27Knappen „Export fold-assignment.json"

HVOR

Venstre sidefelt, nederst.

TEKNISK

Åpner en lagre-dialog med default-filnavn fold-assignment.json. Etter bekreftelse koder holdout-modulet den aktuelle oppdelingen til et JSON-skjema (per-frame fold-tildeling pluss strategy-meta-blokk). Denne filen kan så gis med til neste trening med –benchmark, slik at samme holdout brukes for den endelige metrikk-evalueringen. Skrivefeil vises som feiltekst; suksess i grønn tekst som „Saved to (filename)".

W28SCNView (3D camera globe)

HVOR

Midt-panel i holdout-vinduet.

TEKNISK

SceneKit-globus-view. Scenen består av: en wireframe-kule (radius 1.0, 36 segmenter, mørkegrå), tre fargede aksestumper (rød/grønn/blå for X/Y/Z, hver 1.2 lang) og per kamera en liten markørkule (radius 0.03) ved den tilsvarende blikkretnings-posisjonen på enhetskulen (litt utenfor, slik at den ikke forsvinner i wireframe-kulen). Markørene gjenoppbygges IKKE ved hver fold-endring — gjenoppbygging er bare nødvendig når frame-listen endres (altså når en ny JSON lastes inn). I stedet kjører en in-place-oppdatering av materialfargene per update: rødt for test-index, grønt for trening, lysgrå hvis hverken eller. Slik forblir slider-tikker performante også ved N > 1000 kameraer.

Kamerastyringen er aktivert — du kan rotere globusen med musen, zoome, panorere. Belysning sørger for at markørene ikke ser flate ut. Bakgrunn er mørkegrå.

W29FoldCard (tap to select fold)

HVOR

Høyre sidefelt, „Angular Correlation"-seksjon.

TEKNISK

Per fold en kortvisning — avrundet rektangel med 6 pt radius, padding 10, vertikalt layout med to linjer (øverst „Fold N" + kameraantall, nederst „Mean nearest angle:" + verdi i grader). Bakgrunnsfarge betinget: aktiv fold = accentfarge halvtransparent, inaktive = nøytralt standard-material. Tap velger folden, og globusen farger om live.

„Mean nearest angle"-scoren er den gjennomsnittlige minste vinkelen per test-kamera til det nærmeste treningskameraet (i radian internt beregnet, vist i grader i UI-en).

BayesOpt Console (W30–W39)

Tom tilstand med search-space-velger (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 (etter første åpning) — convergence-chart og trial-tabell fylles så snart en run er startet, se neste shot.

Status øverst til høyre „Finished — best 0.9943 after 40 trials". Venstre sidefelt: search-space- velger på RadianceKit defaults (6-dim), trial-budget 40, random seed 42. Parameter-liste viser de seks hyperparametrene som skal tunes, med verdiområdene deres: 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, oransje punkter = restart-trials (#22 og #31). Beste-verdi-linjen stiger bratt til trial ~7, deretter bare marginal forbedring til trial 15, fra da av flatt platå ved 0.99+. Høyre sidefelt: trial-log #1–#34 med score + tag (init/bo/restart). Save- Best-Config-knappen øverst til høyre skriver bayesopt-best.json.

Hva det er: En Bayes-optimerings-konsoll for hyperparameter-søking. Bayes-Opt er en automatisk metode som prøver å finne det optimale punktet for en ukjent funksjon med så få eksperimenter som mulig — typisk: „hvilken kombinasjon av mcmcMaxGaussians, capMultiplier, ssimWeight og gradThreshold gir den beste PSNR for min sceneklasse?" I stedet for et grid på 6^4 = 1296 trials prøver Bayes-Opt ca. 40–100 informerte trials og kommer dermed nær optimum.

Viktig: Den aktuelt leverte versjonen i appen kjører ikke optimeringen mot ekte trenings-runs (det ville ta dager), men mot et syntetisk demo-objektiv — et multi-modalt landskap med hill-climbing-karakter pluss litt noise. Det er bevisst slik: vinduet skal vise deg optimizerens atferd (konvergensforløp, sample-punkter, best-so-far) og la deg forstå search-space- definisjonene. For ekte treningsdrevne BayesOpt-kjøringer (som utført i fase Q7 for scene-class-presets) brukes et separat offline CLI-workflow; vinduet er live-UI-varianten.

Tre anvendelsestilfeller: 1. Du vil forstå hvordan BayesOpt arbeider — så start en demo-run og iaktta convergence-charten. 2. Du planlegger en ny sceneklasse (f.eks. „akvarier" eller „antikke møbler") som de innebygde 10 presetene ikke passer perfekt til. Definer mentalt et søkerom, sjekk det her med „Bowl demo" eller „Densify"-preset, eksporter så best-config som JSON og bruk det som startpunkt for en ekte trenings-run. 3. Du vil inspisere de default-search-spacene som er definert i RKBayesOpt-pakken (Mip-subset, RadianceKit defaults) — de listes i parameter-panelet i venstre sidefelt.

- Convergence-chart (midt-kolonnen): Y = beste hittil oppnådde objective-funksjon-verdi. X = trial-index. I starten bratt stigende (BayesOpt prøver de initial-samples tilfeldig, noen av dem er heldige), deretter tiltagende flatt fordi nær-optimum-regionen er uttømt. Hvis linjen forblir flat i 20+ trials, kan du stoppe kjøringen — flere trials gir ingenting mer. De enkelte punktene i charten er de individuelle trial-verdiene (altså ikke „best so far"), farget etter fase: grå = initial sample, blå = bayesopt acquisition, oransje = restart. - Trial-tabell (høyre kolonne): #1, #2, #3, … hver med verdi og fase-tag. Det hittil beste trial er markert med en gul stjerne. Ut fra tabellen kan du identifisere best-trial og se parameter-verdiene dens senere ved eksport. - Search-space-inspector (venstre sidefelt): viser for det valgte presetet alle parameter-navn og søkeområdene deres [lo, hi]. Hvis du står ved presetet „RadianceKit defaults (6-dim)", ser du f.eks. „densifyGradThreshold [5e-7, 5e-6]" — altså log-uniform mellom disse to verdiene.

Velg preset „RadianceKit defaults (6-dim)", trial-budget 40, seed 42. Klikk „Start". Iaktta: de første 8 trials er grå (initial samples, LHS-Latin-Hypercube), de følgende blå (BayesOpt-ervervet). Convergence-charten blir bratt til trial ~15, deretter flater den ut. Ved trial ~30–40 stabiliseres den beste verdien. Klikk „Save Best Config" — en bayesopt-best.json lagres med preset-navn, trial-index, verdi og de dekodede parameter-verdiene. Denne JSON-en kan du så manuelt overta i preset-definisjonen din.

W30Knappen „Start"

HVOR

Toolbar til venstre, i idle/finished-state.

TEKNISK

Nullstiller trial-listen, skifter til running-state, genererer en ny run-ID (for stale-detection ved flere start-klikk) og oppretter en frisk pause-gate. Deretter starter en bakgrunns-task som kjører optimizeren som asynkron stream. Initial- samples-størrelsen følger av min(8, budget / 4 + 1) — altså typisk 8 Latin-Hypercube-samples ved budsjett ≥ 28, færre ved lite budsjett. Trial-updates mottas inkrementelt og legges til listen. Stale-run-beskyttelse: hvis et annet start-klikk i mellomtiden setter run-ID på nytt, kastes updates fra den gamle run bort.

Primary-action-stil for den prominente knapp-looken.

W31Knappen „Pause"

HVOR

Toolbar til venstre, i running-state.

TEKNISK

Setter pause-gate aktiv og bytter til paused-state. Den egentlige effekten: runneren venter i et 50-ms-polling-loop før den evaluerer neste objective-funksjon. Det betyr at et pågående trial føres til ende (det er syntetisk og varer bare mikrosekunder), men ingen ytterligere trial startes. Så snart resume kjører, fortsetter den der den slapp.

W32Knappen „Stop"

HVOR

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

TEKNISK

Avbryter runner-tasken, nuller referansen, løser pause-gate (hvis fortsatt paused), og bytter til finished-state (hvis trials finnes) eller idle-state (hvis ingen). De allerede beregnede trialene forblir synlige i listen — stop sletter dem ikke. Destruktiv knapp-rolle viser knappen rødt fordi den avbryter kjøringen.

W33Knappen „Resume"

HVOR

Toolbar til venstre, i paused-state.

TEKNISK

Løser pause-gate og bytter tilbake til running-state. Runner-tasken kjører allerede (den venter jo i polling-loopet); så snart loopet merker at pausen er opphevet, kjører den videre og starter neste trial.

W34Knappen „Save Best Config"

HVOR

Toolbar til høyre, alltid synlig (men deaktivert hvis ingen bestTrial finnes).

TEKNISK

Åpner en lagre-dialog med default-filnavn bayesopt-best.json, begrenset til JSON. Etter bekreftelse bygges en payload-dictionary: preset-navn, trial-index, verdi (objective- score), parametere (dictionary av dekodede parameter-navn → verdier). Dekodingen projiserer de normaliserte søkerom- koordinatene i [0,1]^d tilbake til det opprinnelige verdiområdet (med log-uniform/linear/integer-skalaer tilsvarende). JSON-output er pretty-printed med sorterte keys. Ved skrivefeil ignoreres det (i den aktuelle demo-versjonen) stille — ingen error-UI, fordi det er en demo-sti.

Knappen forblir grå så lenge ingen trial er kjørt.

W35Velger „Search Space"-preset

HVOR

Venstre sidefelt, øverst.

TEKNISK

Menyvelger med fire preset-alternativer: - „RadianceKit defaults (6-dim)" — det fulle standardsøkerommet med alle Q7-hyperparametere. - „Mip subset (2-dim)" — bare mipSmoothing3DScale [0.05, 0.5] log-uniform og mipFilter2DVariance [0.1, 0.6] linear. Nyttig hvis du vil tune Mip-splatting for en sceneklasse. - „densify-until + ssim-weight + grad-thresh" — tre densify-relevante parametere (densifyGradThreshold log-uniform, ssimWeight linear, densifyUntilIter integer). - „Bowl demo (1-dim)" — pedagogisk single-parameter-søkerom for „slik virker BayesOpt"-demoer.

Mens en kjøring er aktiv, kan søkerommet ikke byttes (ville forvirre optimizeren).

W36Slider „Trial Budget"

HVOR

Venstre sidefelt, under search-space-velgeren.

TEKNISK

Slider fra 10 til 200, skrittstørrelse 5. Default 40. Det betyr: BayesOpt kan maksimalt gjøre N trials. Av disse er de første par initial samples (Latin-Hypercube), resten er ekte BayesOpt-trials. Tommelfingerregler i praksis: et søkerom med d dimensjoner krever 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 kjøringen er slideren deaktivert.

W37Slider „Random Seed"

HVOR

Venstre sidefelt, under budsjettslideren.

TEKNISK

Slider fra 1 til 100, skrittstørrelse 1. Default 42. Seedet sendes både til de initiale Latin-Hypercube-samples og til noise-komponenten i demo-objective. Reproduserbarhet: samme seed + samme søkerom + samme budsjett gir nøyaktig identisk trial-sekvens. Nyttig for „får alle kolleger samme kjøring hvis de bygger demoen etter?". Under kjøringen deaktivert.

W38Chart (convergence)

HVOR

Midt-kolonnen i vinduet.

TEKNISK

Swift-Charts-diagram med to lag: 1. en linje for „best-value-so-far" per trial — en monotont stigende eller konstant kurve i accentfarge. 2. et punkt per trial med den individuelle objective-verdien, farget etter fase. Symbolstørrelse 40. Tre fase-labels: „init" (grå), „bo" (blå), „restart" (oransje).

En liten legende viser fase-fargene ø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øyre kolonne i vinduet.

TEKNISK

Scroll-område med lazy stablede trial-linjer. Per linje et horisontalt stack: trial-nummer (3-sifret monospaced, til venstre), verdi (monospaced, høyrejustert, 70 pt bred), fase-tag (capsule, fylt med fase-farge ved 25 % opacity), valgfritt en gul stjerne hvis dette trial er det aktuelt beste. En auto-scroll-mekanisme hopper automatisk til enden så snart et nytt trial kommer, slik at du kan medlese live-forløpet i bunnen av skjermen uten selv å scrolle.

Hovedvindu: loss-forløp og gaussian-count (I39–I41, krysshenvisning)

Tre av Inspector-visningene i hovedvinduet fortjener en egen forklaring fordi de ses konstant under en kjørende trening, og det er viktige tommelfingerregler for når forløpet ser sunt ut. Visningene er i Inspector under „Loss Chart"-seksjonen (se kapittel 2 — Inspector) og supplerer holdout-analysen fra hjelpevinduet ovenfor.

Når er loss-kurven sunn? En sunn loss-kurve viser tre faser: (1) Warmup — i de første 200–500 iterasjonene faller loss-en bratt fra høyt (typisk 0.15–0.25 for L1+SSIM-kombinert avhengig av scenen) til ca. halvparten. Hvis loss-en IKKE faller i denne fasen, er input som regel feil (bilder defekte, SfM-posisjoner dårlige, antall initial-gaussians for lite). (2) Densification — mellom ~500 og densifyUntilIteration (klassisk 15K, MCMC til 20K eller 25K) faller loss-en videre, ofte med små sprang nedover når densify- operasjonene setter inn nye gaussians og optimizeren utnytter dem. Gaussian-count stiger i denne fasen. (3) Refinement — deretter går loss-en ut i en flatere hale. Typiske sluttverdier: 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).

Hva betyr et platå? Et platå (loss-kurven løper horisontalt over flere tusen iterasjoner) har to tolkninger: (a) modellen er konvergert, ytterligere trening gir ingenting mer — det er den gode situasjonen. (b) Modellen er stuck (lokalt minimum, dårlig gradient-informasjon, et cap ved buffer-grensen) — den dårlige situasjonen. Begge ser identiske ut i charten. Skille: kikk på gaussian-count. Hvis den også er flat OG tett på MCMC-cap-et (f.eks. 150K av 150K ved .fullMCMC), er du ved grensen — enten hev cap-et eller aksepter platået. Hvis gaussian-count fortsatt vokser, men loss-en ikke faller, henger den fast.

Når avbryte vs videretrene? Tommelfingerregel: 10K iterasjoner uten forbedring av min-loss → avbryt, ytterligere iterasjoner er bortkastet. Før: kan du via Cmd+T (training-menyen → Continue Training → +5K iterations) fortsatt henge en forlengelse på hvis du ser grensemessig forbedring. Advarsel: ved MCMC er platået ofte ekte — cap-et er den naturlige grensen.

Gaussian-count-platå er IKKE et „ferdig"-signal. Det betyr bare at MCMC har nådd cap-et, eller at Classic densification er uttømt. Selve „ferdig"-spørsmålet stilles først av holdout-analysen — PSNR/SSIM/LPIPS på et uavhengig test-sett, evaluert i holdout-vinduet (W23–W29) eller via –benchmark-flagg.

PSNR/holdout er sannheten, loss kun proxy. Loss-en er en relativ metrikk: den faller mens modellen din tilpasser seg trenings-views. En lav loss betyr imidlertid ikke automatisk god modell — hvis modellen har lært treningsbildene utenat (overfitting), ville loss-en være liten, men PSNR på usette views (holdout) ville være dårlig. Derfor: for den endelige kvalitetsbedømmelsen kikk alltid på holdout-metrikker, ikke på end-loss alene.

Tommelfingerregel-boks

- User Guide og Keyboard Shortcuts er statisk hjelp — ved stikkordsspørsmål raskt, for dybde bruk denne manualen. - Manage Storage åpnes så snart disken faller under 10 % fri plass. Logs og imports-staging er de vanlige synderne. - Pareto Dashboard er først meningsfullt etter minst tre eller fire treningsreports. X-akse = kostnader (time / Gs), Y-akse = kvalitet (PSNR / SSIM). Pareto-fronten viser de effektive kombinasjonene. - Holdout Analysis brukes før du offentliggjør PSNR-benchmarks med andre — det sikrer deg at test-settet ditt virkelig er representativt. - BayesOpt Console er primært et lærings- og inspeksjonsverktøy for søkerom-definisjoner. For ekte treningsdrevet hyperparameter-tuning bruk offline CLI-workflowen. - Loss-platå og gaussian-count-platå må tolkes adskilt. Cap-grense er ikke et „ferdig"-signal. Ekte kvalitet måler bare holdout-PSNR. - 10K iterasjoner uten min-loss-forbedring → stopp trening.