Kapitola 4 — Pomocná okna

Vedle hlavního okna (3D náhled plus Inspektor) RadianceKit spravuje sedm dalších oken, která se všechna otevírají přes menu Help. Seznam shora dolů: User Guide (⌘?), Keyboard Shortcuts (⌘/), Open Training Logs… (neotevírá okno aplikace, ale Finder; proto zde dále neřešeno), Manage Storage…, Pareto Dashboard… (⇧⌘D), Holdout Analysis… (⇧⌘H), BayesOpt Console… (⇧⌘B). Tři z nich — Dashboard, Holdout, BayesOpt — jsou samostatné analytické nástroje. Každý má svůj vlastní view model stack, čte nebo zapisuje JSON soubory na disk, a pro každý existuje CLI argument, kterým můžeš nechat otevřít okno hned při startu aplikace na konkrétní soubor (–dashboard-dir, –holdout-file, –bayesopt-autorun).

Čtyři jednoduchá okna (User Guide, Keyboard Shortcuts, Manage Storage, plus podpoložky Open Training Logs / Open Exports Folder) dostávají na ovládací prvek krátký záznam. Tři analytická okna jsou dokumentována podrobněji — vždy s úvodem, který vysvětluje, co v okně vidíš, kdy ho otevřít a jak interpretovat zobrazený obraz.

Na konci kapitoly je oddíl s odkazy na Inspektor hlavního okna: co v live loss chartu a v zobrazení Gaussian Count během běžícího tréninku můžeš smysluplně odečíst.

User Guide (W1–W4)

Co to je: Vestavěné okno nápovědy, které renderuje s aplikací dodávaný guide_<jazyk>.md. Jazyk se odvozuje z Nastavení (záložka General → Language) nebo, pokud tam stojí „System", z jazykových preferencí macOS. Layout je klasický: vlevo sidebar se všemi nadpisy, vpravo plynulý text.

Když potřebuješ rychlou připomínku jednotlivého bodu — tedy jako náhradu klíčových slov. Podrobná reference je tato příručka; vestavěné okno nápovědy je spíše to, co by bylo –help v příkazové řádce. Aktualizuje se s každým releasem aplikace, ale obsahově zůstává povrchnější.

W1NavigationSplitView (Sidebar + Detail)

KDE

Help → User Guide (⌘?)..

TECHNICKY

Dvousloupcový layout s úzkým sidebarem (minimálně 180 pt široký) pro strom obsahu a scrollovatelnou detailní oblastí pro samotný Markdown obsah. Okno má minimální velikost 700 × 500 pt. Při prvním otevření okno načítá příslušný guide_<lang>.md z balíku aplikace (fallback guide_en.md), parsuje jej do blokových záznamů (nadpisy H1–H4, odstavce, seznamy, tabulky, oddělovače) a samostatně extrahuje strukturu nadpisů pro sidebar. Inline formátování (bold, italic, code span) se renderuje přes vestavěný markdown engine. Jazyk se čte z nastavení aplikace, se speciálním případem čínštiny (zh-Hans) a brazilské portugalštiny (pt-BR), které se zachovávají jako plné locale tagy, protože se tyto varianty odlišují od zh resp. pt.

W2List (Heading sidebar)

KDE

Levý sloupec v okně User Guide..

TECHNICKY

Seznam přes všechny nadpisy H2 a H3 aktuálního Markdown dokumentu. H2 položky se objevují bez odsazení s medium váhou písma, H3 položky s 16 pt odsazením vlevo a redukovaným foreground stylem. H4 a hlubší jsou ignorovány, protože hloubka by jinak udělala sidebar nepřehledným. Kotvící ID se generují z textu nadpisu sluggifikací (lowercase + mezery na pomlčky + filtrování na písmena/čísla/pomlčky — stejný algoritmus, který GitHub používá pro své Markdown kotvy, takže by i externí URL k dokumentaci potenciálně přistály na stejné kotvě). Seznam používá nativní macOS styl.

W3Button (Heading → skok na kotvu)

KDE

Na řádek sidebaru jedno tlačítko..

TECHNICKY

Každá položka sidebaru je tlačítko, které nastavuje aktuální kotvu, ale opticky vypadá jako položka seznamu. Pozorovací proměnná pak spouští scroll skok k odpovídající kotvě s měkkou animací přes 0,3 s. Po skoku se hodnota kotvy resetuje, aby další klik na stejnou kotvu znovu vystřelil (jinak by pozorovatel nestřelil znovu, protože hodnota se nezměnila).

W4ScrollView (detail obsahu)

KDE

Pravý sloupec..

TECHNICKY

Scrollovatelná, vertikálně stohovací oblast obsahu s lazy renderováním, protože delší průvodci mohou snadno mít přes 200 Markdown bloků — ne-lazy varianta by všechny instancovala najednou. Každý blok dostává vlastní ID, buď heading kotvu (pro skočitelné H1–H3) nebo index placeholder. Maximální šířka je 720 pt, padding 32 horizontálně / 24 vertikálně, aby si dlouhé řádky zachovávaly dobře čitelný layout. Tabulky se renderují buňka po buňce s horizontálními stacks a oddělovacími čarami; inline kód přes vestavěný Markdown engine. Skutečné kódové bloky se aktuálně zachází jako s odstavcem — známé omezení okna nápovědy.

Keyboard Shortcuts (W5–W6)

Statický referenční seznam v pěti sekcích. Navigation: Mouse Drag (Orbit/Fly), Shift+Drag/ Right-Drag (Pan), Scroll (Zoom), WASD (fly-through pohyb), Q/E (Up/Down), F (Toggle Orbit/Fly), Double-click (Re-center), Cmd+Scroll (úprava FoV). Views: R (Reset Camera), T (Auto-Rotation), P (Camera Playback), B (Background cycle), 0–9 (skok na training cam 1=10 %/5=50 %/0=last), Left/Right Arrow (Prev/Next Cam). Capture: S (Screenshot na desktop), V (Turntable video), C (Copy Camera Info). Editor: Tab (Edit režim), Click/Drag (paint select), Option+Click (deselect), X / Delete (smazat výběr), Cmd-Z (vrátit poslední mazání), [ / ] (zmenšit/zvětšit štětec), Esc (zrušit výběr). Training: Start, Pause/Resume, Cancel, Continue +5K/+10K/+20K přes shortcuty menu v M9–M14.

Co to je: Jednoduchý statický přehled všech klávesových zkratek — Navigation, Views, Capture, Editor, Training. Obsah je napevno zakódován, žádné Markdown načítání.

Když hledáš nejrychlejší cestu, jak něco udělat v náhledu. WASD fly through, R pro reset kamery, B pro cyklování pozadí — všechny tu stojí.

W5ScrollView (oblast obsahu)

KDE

Help → Keyboard Shortcuts (⌘/)..

TECHNICKY

Jednoduchá scroll oblast s vertikálním seznamem uvnitř. Padding 20 dokola, žádný sidebar navigation tree (seznam je dostatečně krátký). Obsah je seskupený do pěti sekcí (Navigation, Views, Capture, Editor, Training). Na kombinaci kláves jeden řádek s přeložitelným textem v obou sloupcích. Levý sloupec (kód kláves) fixovaný na 180 pt širku, aby popisy vpravo zůstaly vertikálně zarovnané. Žádná interakce kromě scrollování — klik na řádek nic nespouští, klávesové zkratky jsou skutečné modifikátory v menu a na náhledu.

W6VStack (zkratkové sekce)

KDE

Uvnitř ScrollView..

TECHNICKY

Doleva zarovnané stohové sekce s 16 pt rozestupem. Uvnitř pěti sekcí vždy heading + sled řádků. Nadpisy používají sekundární subheadline styl — záměrně bez title formátu, protože sekce nemusí být navigovatelné. Obsah je záměrně plochý (žádné disclosure, žádný search, žádný filtr), aby komponenta na každé verzi macOS běžela nezměněně a soubor zůstal čitelný.

Manage Storage (W7–W12)

Tabulkový pohled všech RadianceKitem spravovaných souborů. Hlavička počítá 693 položek, celkovou velikost 16.74 GB. Toolbar nahoře: „Show in Finder" + „Refresh". Každý řádek: PLY ikona, název souboru (např. training_20260527T211321Z.ply), datum exportu, velikost (variuje 7 KB až 218 MB), ikona lupy (reveal) a ikona koše (move to trash). Soubory jsou seřazeny podle data, nejnovější nahoře. V této demo nahrávce dominují PLY exporty, protože se hodně pracovalo s –benchmark.

Co to je: Přehled využití disku pro vše, co RadianceKit ukládá pod ~/Documents/RadianceKit/ — logy, exporty, scény, capture bundly (z iOS doprovodu), importy (staging kopie vstupních obrázků). Na záznam velikost v bajtech a dvě tlačítka: „zobrazit ve Finderu" a „přesunout do koše". NENÍ to automatický úklid — aplikace sama nic nemaže; rozhoduješ se na záznam.

Když je disk plný. Především logy se sbírají (jeden JSONL na tréninkový pokus, plus _qualityMetrics.json); exporty samozřejmě také (PLY 100 % surová data, jeden na export). Užitečné i po pádu, pokud staging adresář importů ještě má staré kopie vstupních obrázků (viz „Disk-pressure incident" v dev_v549f-needle-reduction.md).

W7Tlačítko „Show in Finder"

KDE

Hlavička vpravo nahoře v okně Storage Browser..

TECHNICKY

Otevírá celý RadianceKit adresář (~/Documents/RadianceKit/) ve Finderu, takže můžeš strukturu složek přímo vidět a také ji manipulovat ve Finderu samotném. Akce otevírá nové okno Finder a nepřepíná do App Sandbox containeru — ~/Documents/RadianceKit/ je doména Documents regulárně přístupná aplikacím, ne cesta sandboxed containeru.

W8Tlačítko „Refresh"

KDE

Hlavička, vedle Finder tlačítka..

TECHNICKY

Spouští background scan, který běží na uživatelem iniciovaném asynchronním tasku, aby skenování velkých stromů adresářů neblokovalo UI. Samotné chození prochází každou známou podsložku (Logs, Exports, Scenes, Captures, Imports) a generuje storage záznam na přímé dítě. Na záznam se zjišťuje rekurzivní velikost — preferenčně skutečná spotřeba disku (včetně sdílení APFS hardlinks) s fallbackem na logickou velikost souboru.

W9List (storage záznamy)

KDE

Hlavní obsah pod hlavičkou..

TECHNICKY

Seznam s tímto layoutem na řádek: kategoricky specifická SF symbol ikona (dokument pro logy, šipka nahoru pro exporty, krychle pro scény, tray pro importy), název + podtitul (kind label + formátované datum modifikace), counter bajtů vpravo (zarovnáno vpravo, monospaced), reveal tlačítko (symbol lupy), trash tlačítko (koš). Třídění: primárně podle kindu (Scenes nejdřív, pak Exports, Logs, Captures, Imports, Other), sekundárně podle data modifikace sestupně (nejnovější nahoře). Pokud skenování ještě běží, ukazuje místo toho „Scanning…" progress. Pokud se nic nenašlo, empty state s tray ikonou.

W10Tlačítko řádku „Reveal in Finder"

KDE

Na řádek, symbol lupy vpravo..

TECHNICKY

Otevírá Finder a označuje konkrétní item (soubor nebo složku). Rozdíl od W7: W7 otevírá root adresář; W10 značí přesně tento jeden záznam. Praktický workflow: identifikuj velký záznam, klikni na lupu, pak ho zkopíruj např. na externí volume.

W11Tlačítko řádku „Move to Trash"

KDE

Na řádek, symbol koše vpravo vedle lupy..

TECHNICKY

Vyvolává potvrzovací dialog box (W12). Až po potvrzení běží macOS standardní operace „přesunout do koše" (tedy reverzibilní, ne přímé mazání). Po úspěšném trashi se záznam odstraňuje ze seznamu a aktualizuje se counter celkových bajtů. Při chybách se zobrazuje modální chybový dialog.

W12ConfirmationDialog (potvrzení mazání)

KDE

Vyvolán přes W11, zobrazen jako macOS sheet..

TECHNICKY

Standardní potvrzovací dialog s dynamickým titulem „Delete <name>?" a řádkem zprávy, který explicitně upozorňuje, že záznam přistane v koši a je z něj obnovitelný (dokud se koš nevyprázdní). Dvě tlačítka: „Move to Trash" jako destruktivní akce (zobrazená červeně) a „Cancel" s automatickou Esc vazbou. Dialog je non-modal v tom smyslu, že blokuje pouze toto okno, ne celou aplikaci — to je macOS standard pro reverzibilní mazání.

Pareto Dashboard (W13–W22)

Prázdný stav (po prvním otevření) — empty state s call-to-action „Open Reports Folder…". Datové body se objevují, jakmile jsou tréninkové reporty načteny, viz další snímek.

Toolbar v hlavičce ukazuje „129 reports of 129" (všechny reporty ve zvolené složce úspěšně sparsovány — 21 dalších souborů nebylo možné sparsovat kvůli staršímu formátu, viz seznam poznámek vpravo). Osy: X-Axis picker na Gaussians, Y-Axis picker na PSNR (dB). Scatter plot: zelené body = Classic-Strategy, modré body = MCMC. Přerušovaná Pareto front čára běží podél nejlepších dosažených PSNR hodnot a plateauje kolem PSNR≈30 dB od asi 500K Gaussianů. Filter chipy vpravo: 7 scén, 2 strategie (classic, mcmc), 3 možnosti Mip-Splatting (All, On, Off). Aktuálně jsou všechny filtry otevřené, proto hustý cluster bodů.

Co to je: Nástroj pro porovnání více běhů. V minulosti jsi trénoval více scén nebo stejnou scénu s různými předvolbami — každý z těchto tréninkových běhů produkuje (pokud jsi přidal –benchmark nebo zavolal přes benchmark funkci) JSON report soubor, který mimo jiné obsahuje finální PSNR, SSIM, LPIPS, Gaussian count a wallclock čas. Dashboard čte celou složku takových reportů najednou a plotuje je jako 2D scatter se selectovatelnými osami. Navíc je vykreslena Pareto fronta (množina nedominovaných bodů) jako přerušovaná čára.

Poté co jsi vytvořil alespoň tři nebo čtyři tréninkové reporty. S méně body fronta čára není výpovědní. Typický use case: zkoušel jsi rekonstruovat outdoorovou scénu a postupně jsi projel P3 Balanced (Classic), P4 Quality (Classic), P7 MCMC Quality a P9 Outdoor (tuned) — nyní chceš vědět, která konfigurace dodává nejlepší PSNR na sekundu tréninkového času nebo která potřebuje nejméně Gaussianů pro danou PSNR.

Obě osy jsou volně volitelné (X osa: psnr, ssim, lpips, …; Y osa stejně). Logika Pareto fronty v ParetoFront2D.indices ví pro každou metriku, zda „menší = lepší" (např. LPIPS, Loss, Time) nebo „větší = lepší" (PSNR, SSIM) — čára tedy podle volby os běží zleva dolů doprava nahoru nebo zleva nahoru doprava dolů, vždy podél nejlepší dosažené kombinace. Bod je Pareto-optimální, pokud ŽÁDNÝ jiný bod není v OBOU dimenzích alespoň stejně dobrý (tedy žádný jiný ho nedominuje). Pareto-optimální body leží na čáře, jiné body vpravo/výše (podle orientace os) od ní. Body NA čáře jsou skuteční kandidáti pro „nejlepší předvolba"; body DALEKO od čáry jsou promarněný tréninkový čas.

Můžeš výběr omezit na konkrétní scénu (pokud chceš např. porovnat pouze outdoorové runy), na konkrétní strategii (Classic nebo MCMC), nebo na Mip-Splatting on/off (relevantní po fázi Q1.5, kde Mip zůstává jako opt-in advanced flag).

Máš tři reporty pro „truck" scénu pod ~/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). Nastav X osu na trainingTime, Y osu na PSNR. Run B leží vpravo nahoře, Run C ještě dál vpravo nahoře, Run A vlevo dole. Pareto fronta spojuje A a C — oba nedominované. Run B je „lost" (C je lepší v Time I PSNR). Poznatek: pro „truck" se MCMC default nevyplatí; buď rychle+OK (A) nebo dlouho+velmi dobře (C). Konfiguraci z C uložit jako vlastní předvolbu (Inspektor → I1 Save Preset).

Další akce: uložit nejlepší konfiguraci jako předvolbu. Konkrétně: podívej se na Pareto body (hover ukazuje PSNR/SSIM/LPIPS/Gs/Time v tooltipu), rozhodni se, který ti z time-vs-quality kompromisu sedí nejlépe, otevři příslušný report (název souboru obsahuje run timestamp), zkopíruj jeho tréninkovou konfiguraci do nového běhu nebo ji ulož po další tréninkové relaci jako předvolbu přes Inspektor.

W13Tlačítko „Open Reports Folder…"

KDE

Toolbar nahoře vlevo..

TECHNICKY

Otevírá výběr složky s výzvou „Select a folder containing benchmark .json reports". Po potvrzení běží background task, který sekvenčně parsuje všechny .json soubory ve složce. Chybné reporty (poškozený JSON, špatné schema) se sbírají a dole v sidebaru se zobrazují jako „N file failed to parse" — žádný pád. Pokud nastane druhý klik, zatímco první load ještě běží, předchozí task se přeruší, takže do stavu nezapisují dva výsledky současně.

Také přes CLI: –dashboard-dir /cesta/k/reports načte složku hned při startu aplikace.

W14Picker „X-Axis"

KDE

Nad chartem, vlevo..

TECHNICKY

Menu picker se všemi dostupnými metric osami modulu dashboardu (PSNR, SSIM, LPIPS, Gaussian count, tréninkový čas atd.). Default je Gaussian count. Při změně se zrušuje pohnutý hover bod, protože dosud zvýrazněná pozice ve starém souřadnicovém systému os po změně os už nemá smysl. Picker je omezen šířkou obsahu, aby netáhl přes celou šířku.

W15Picker „Y-Axis"

KDE

Nad chartem, vedle X-Axis..

TECHNICKY

Identické s W14, jen že default je PSNR. Volba os se ukládá nezávisle, takže uživatel může volit i nesmyslné kombinace (X=PSNR, Y=PSNR — hodilo by všechny body na diagonálu). Takové kombinace ale nejsou odchytávány; vědomé rozhodnutí, protože porovnání „SSIM vs PSNR" je rozhodně zajímavé, aby se vidělo, jak konzistentně se metriky chovají.

W16Toggle „Show Pareto Front"

KDE

Vpravo vedle pickerů os..

TECHNICKY

Standardní macOS toggle. Pokud je aktivní, v Pareto chartu se navíc k mraku bodů kreslí čára s vypočítanou 2D Pareto frontou. Styl: přerušovaný (dash pattern 4–4), šedě poloprůhledný, síla čáry 1.5 pt. Výpočet Pareto fronty běží na hlavním vlákně — u typického počtu reportů (≤ ~50) je to bez problémů rychlé. Pokud je toggle vypnutý, čára se vynechává, takže stojí jen holé body.

W17Chipy „Scene" filtru

KDE

Pravý sidebar v okně Dashboard..

TECHNICKY

Filter chipy pro každou scénu vyskytující se v načtených reportech. Vlastní flow layout, který chipy automaticky balí do více řádků, jakmile je šířka vyčerpaná. Aktivní chipy dostávají akcentové pozadí, neaktivní neutrální standardní material pozadí. Vícenásobný výběr je možný (Set sémantika); pokud není zvolen žádný chip, platí všechny scény jako „propuštěné" — tj. logika setu je „prázdný výběr = vše", ne „prázdný výběr = nic".

W18Chipy „Strategy" filtru

KDE

Pod Scene filtrem v sidebaru..

TECHNICKY

Přesně jako W17, ale pro tréninkové strategie — typicky dvě hodnoty „classic" a „mcmc", odvozené z strategy pole benchmark report JSON. Užitečné, pokud máš reporty obou strategií smíchané a chceš vidět jen jeden druh (např. „ukázat jen MCMC runy, protože Classic jsem už vyloučil").

W19Chipy „Mip-Splatting" filtru

KDE

Pod Strategy filtrem v sidebaru..

TECHNICKY

Trojhodnotový filtr (místo setu jako W17/W18): „All" / „On" / „Off". Pozadí: Mip-Splatting byl ve fázi Q1.5 evaluován jako experimentální vylepšení multi-scale a finální verdikt byl „žádné spolehlivé vítězství; ponechat jako opt-in flag". Pokud děláš mip-on/off porovnání, často chceš ostře oddělit. Proto dedikovaný ternární filtr se stavy „vše propustit", „pouze Mip on", „pouze Mip off". Sekce sidebaru se zobrazuje pouze tehdy, pokud je v datech alespoň jeden Mip report A alespoň jeden ne-Mip report (jinak filtrování nedává smysl).

W20ChipButton (filter toggle, all/on/off)

KDE

Helper komponenta, používá se v W17/W18/W19..

TECHNICKY

Minimalistický button wrapper. Obsah: label text s caption fontem a paddingem 10 horizontálně / 5 vertikálně. Pozadí podmínečné: pokud aktivní → akcentová barva aplikace s bílým textem; jinak neutrální standardní material pozadí s černým textem. Tvar je capsule (pilulkovitý). Plain button style, aby capsule material nebyl překryt systémovým borderem.

W21Chart (Pareto scatter)

KDE

Středová plocha dashboardu..

TECHNICKY

Swift Charts diagram se dvěma vrstvami: 1. jeden bod na report — pozice z vybraných X a Y metrik, barva podle Strategy, symbol podle Mip statusu. Velikost symbolu normálně 80, zvýrazněno 200 (pokud ID odpovídá aktuálně hovered reportu). 2. čára pro Pareto frontu, pouze pokud je toggle zapnut.

Chart overlay: průhledný obdélník registruje pohyb myší; na frame se vypočítává euklidovsky nejbližší pozice bodu v plot frame a aktualizuje se hover report, pokud je vzdálenost pod 24 px (jinak reset). Tak dostaneš tooltip bez klikání — stačí hover.

W22Tooltip (hover detail)

KDE

Pod chartem, zobrazený při hoveru..

TECHNICKY

Horizontální stack: název scény (headline), strategy tag (caption), oddělovací čára, pak PSNR/SSIM/LPIPS/Gs/Time metriky vždy v malé vertikální skupině (label + monospaced hodnota). Pokud byl Mip aktivován, navíc „Mip" capsule tag v akcentové barvě. Pozadí poloprůhledný blur, zaoblený obdélník s 8 pt radiusem. Zobrazuje se pouze tehdy, pokud je myš skutečně nad bodem. Automaticky mizí při opuštění.

Holdout Analysis (W23–W29)

Prázdný stav s empty state a call-to-action „Open transforms.json…". Akceptuje formát Nerfstudio a Instant-NGP.

Prázdný stav (po prvním otevření) — kamerové markery se objevují, jakmile je načten transforms.json, viz další snímek.

Hlavička ukazuje načtený soubor (transforms_train.json) a count kamer („100 cameras"). Levý sidebar: strategy picker se dvěma možnostmi — aktivní Angular (longitudinal) (řadí foldy podle longitudinálních/latitudinálních sektorů na sféře, aby každý test fold byl geometricky hustý) vs Linear (round-robin) (založeno na pořadí, všechny k-té framy jako test set). Slider k-foldů stojí na 5, picker test foldu na Fold 1. Export tlačítko generuje fold-assignment.json pro Nerfstudio/Instant-NGP. Středový panel: 3D globus projekce všech 100 kamer — zelené body = train, červené body = aktuální test fold (Fold 1 s 20 kamerami). Pravý sidebar (Angular Correlation): na fold 20 kamer + Mean Nearest Angle (Fold 1: 7.9°, Fold 2: 7.8°, Fold 3: 7.7°, Fold 4: 7.0°, Fold 5: 6.3°) — menší hodnota znamená, že kamery uvnitř tohoto foldu leží těsně u sebe, tedy holdout split je prostorově koherentní.

Co to je: 3D vizualizér tvého kameraového uspořádání s logikou cross-validation. Načítáš transforms.json (standardní formát Nerfstudio / Instant-NGP pro pozice kamer), aplikace čte všechny kamery, projektuje jejich směry pohledu na jednotkovou kouli a ukazuje je jako malé sférické markery na virtuálním glóbu. Pak dělí kamery do k foldů (podle zvolené strategie: angular nebo linear), zeleně značí tréninkový podíl a červeně test podíl (holdout) a počítá na fold angular correlation score, který říká, jak daleko leží test fold od tréninkového foldu v prostoru úhlů pohledu.

Když chceš dělat holdout evaluaci — tedy: jak dobře generalizuje tvůj model na neviděné úhly pohledu? Standard v tréninku je „every-8th view jako holdout" (Mip-NeRF360 konvence), ale to je velmi lineární rozdělení. Pokud jsou tvé obrázky např. časově clusterované (nejprve jedna strana objektu, pak druhá), pak „every-8th" není reprezentativní — náhodná sekvenční pozice přistane v testu, ale všichni její sousedé jsou v tréninku, to je moc jednoduché. S „angular" se místo toho stratifikuje přes prostor úhlů pohledu: každý fold obsahuje kamery ze všech oblastí orbitu, takže test skutečně testuje mezery v generalizaci.

Angular vs Linear: - Angular (standard): dělí kamery podle longitudinálního úhlu (φ souřadnice kolem osy Y) do k stejných sektorů. Fold 0 jsou kamery s φ ∈ [0°, 360/k°), Fold 1 další, a tak dále. Výhoda: každý fold pokrývá výřez orbitu; test fold je prostorově kompaktní, ale široce rozprostřený přes světový dataset. Dobré pro klasické orbitální záběry. - Linear (round-robin): fold index = (image_index modulo k). To je jednoduchá „every-k-th" distribuce. Funguje, pokud pořadí obrázků NEMÁ prostorový bias (např. náhodně seřazené dronové záběry). Funguje špatně, pokud obrázky časově clusterují.

V 3D glóbu okamžitě vidíš: zelené body (training) a červené body (test). Pokud červené body všechny clusterují v jednom rohu, je holdout špatný (žádný dobrý test generalizace). Pokud leží rovnoměrně mezi zelenými, je dobrý. Angular correlation score na fold (pravý sidebar, ve stupních) navíc říká: menší hodnota = test je blízko tréninku (každá test kamera má blízkou tréninkovou kameru, snadný test); větší hodnota = test je daleko od tréninku (tvrdší generalizace).

Pořídil jsi svou Truck scénu s 251 obrázky, exportuješ přes menu M33 (Export SfM transforms.json) nerfstudio soubor. Otevři Holdout okno (⇧⌘H), načti JSON přes „Open transforms.json…", podívej se na globus. k=5 (default) ti dává 5 foldů. Klik na „Fold 3" — vidíš, zda jsou červené markery zhruba rovnoměrné. Pokud ano: „Export fold-assignment.json", polož exportovaný soubor do reports složky a při dalším training runu s –benchmark (nebo odpovídajícími nastaveními Inspektoru) se použije přesně toto rozdělení foldů jako test holdout — místo standardu „every-8th".

W23Tlačítko „Open transforms.json…"

KDE

Toolbar nahoře vlevo..

TECHNICKY

Otevírá souborový dialog omezený na JSON soubory. Po potvrzení Holdout modul načítá soubor. Loader parsuje jak formát nerfstudio (camera intrinsics plus seznam framů s cestou obrazu a transform maticí), tak formát instant-ngp (stejná stavba). Na frame se z transform matice extrahuje směr pohledu (z osa kamerové lokální báze) a ukládá. Pokud se parsování nezdaří, zobrazuje se chybové hlášení ve stavové oblasti.

Také přes CLI: –holdout-file /cesta/k/transforms.json startuje okno přímo s načteným souborem.

W24Picker „Strategy" (angular/linear)

KDE

Levý sidebar, nahoře..

TECHNICKY

Radio picker se dvěma možnostmi: Angular a Linear. Změna strategie automaticky spouští přepočet foldů. Směry pohledu jsou seznam 3D jednotkových vektorů na sféře; angular strategie je projektuje na longitudinální úhel φ a třídí, linear strategie dělá prostě modulo distribuci přes frame index.

W25Slider „k Folds"

KDE

Levý sidebar, uprostřed..

TECHNICKY

Slider od 3 do 10, krok 1. Při změně se výpočet foldů automaticky spouští znovu, takže seznam foldů, train/test indexy a per-fold score se okamžitě přepočítávají. Zvolená hodnota se zobrazuje jako monospaced digit text vpravo vedle labelu.

Pravidlo: k=5 je standard (dává ti 20 % test na fold, to je obvyklé pro cross-validation). k=10 pokud máš hodně dat a potřebuješ víc foldů pro statistickou výpovědní hodnotu. k=3 pokud máš málo dat.

W26Picker „Test Fold"

KDE

Levý sidebar, pod k sliderem..

TECHNICKY

Menu picker. Možnosti jsou dynamicky 0..<k, label „Fold 1" až „Fold N" (tedy 1-indexed v UI, 0-indexed interně). Pokud je předchozí zvolený index ≥ k (např. protože jsi snížil k z 10 na 5), automaticky se resetuje na 0. Zvolený test fold se v globu zobrazuje červeně, všechny ostatní zeleně.

W27Tlačítko „Export fold-assignment.json"

KDE

Levý sidebar, dole..

TECHNICKY

Otevírá Save dialog s defaultním názvem fold-assignment.json. Po potvrzení Holdout modul kóduje aktuální distribuci do JSON schématu (per frame fold přiřazení plus strategy meta blok). Tento soubor lze pak při dalším tréninku s –benchmark přibalit, takže se pro finální vyhodnocení metrik používá stejný holdout. Chyby zápisu se zobrazují jako chybový text; úspěch v zeleném textu jako „Saved to (filename)".

W28SCNView (3D Camera Globe)

KDE

Středový panel v okně Holdout..

TECHNICKY

SceneKit globus view. Scéna sestává z: wireframe koule (poloměr 1.0, 36 segmentů, tmavě šedá), tří barevných osových pahýlů (červený/zelený/modrý pro X/Y/Z, každý 1.2 dlouhý), a na kameru malá marker koule (poloměr 0.03) na odpovídající pozici pohledu na jednotkové kouli (lehce vně, aby nezmizela V wireframe kouli). Markery se při změně foldu NESTAVÍ znovu — rebuild je potřeba jen tehdy, pokud se mění seznam framů (tedy nová JSON je načtena). Místo toho běží na update in-place aktualizace materiálových barev: červená pro test indexy, zelená pro training, světle šedá pokud ani jedno. Tak zůstávají slider ticky výkonné i u N > 1000 kamer.

Ovládání kamery je aktivováno — můžeš myší globus otáčet, zoomovat, posouvat. Osvětlení se stará, aby markery nevypadaly ploché. Pozadí je tmavě šedé.

W29FoldCard (klikni pro výběr foldu)

KDE

Pravý sidebar, sekce „Angular Correlation"..

TECHNICKY

Na fold karta view — zaoblený obdélník s 6 pt radiusem, padding 10, vertikální layout se dvěma řádky (nahoře „Fold N" + počet kamer, dole „Mean nearest angle:" + hodnota ve stupních). Barva pozadí podmínečně: aktivní fold = akcentová barva poloprůhledně, neaktivní = neutrální standardní material. Klepnutí volí fold, a globus se živě překresluje barvami.

Score „Mean nearest angle" je střední nejmenší úhel na test kameru k nejbližší tréninkové kameře (interně počítáno v radiánech, v UI zobrazeno ve stupních).

BayesOpt Console (W30–W39)

Prázdný stav se search space pickerem (RadianceKit defaults (6-dim)), slider Trial Budget (default 40), Random Seed (42) a tři prázdné panely pro convergence chart, trial log a seznam parametrů search space.

Prázdný stav (po prvním otevření) — convergence chart a trial tabulka se naplňují, jakmile byl spuštěn běh, viz další snímek.

Status vpravo nahoře „Finished — best 0.9943 after 40 trials". Levý sidebar: search space picker na RadianceKit defaults (6-dim), Trial Budget 40, Random Seed 42. Seznam parametrů ukazuje šest ladících hyperparametrů s jejich hodnotovými rozsahy: 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]. Střed: convergence chart (X = trial index 1–40, Y = objective value 0–1) — šedé body = initial samples (LHS), modré body = BayesOpt acquisition, oranžové body = restart trialy (#22 a #31). Best value čára strmě stoupá k trialu ~7, pak už jen marginální zlepšení do trialu 15, od tam plochý plateau na 0.99+. Pravý sidebar: trial log #1–#34 se skórem + tagem (init/bo/restart). Tlačítko Save Best Config vpravo nahoře zapisuje bayesopt-best.json.

Co to je: Bayesovská optimalizační konzole pro hledání hyperparametrů. Bayes-Opt je automatická metoda, která se pokouší s co nejméně experimenty najít optimální bod neznámé funkce — typicky: „která kombinace z mcmcMaxGaussians, capMultiplier, ssimWeight a gradThreshold dodává nejlepší PSNR pro mou třídu scén?" Místo gridu 6^4 = 1296 trialů Bayes-Opt zkusí asi 40–100 informovaných trialů a tím se blíží optimu.

Důležité: aktuální verze dodaná v aplikaci nevede optimalizaci proti skutečným tréninkovým runům (to by trvalo dny), ale proti syntetické demo objective — multimodální krajině s hill-climbing charakterem plus mírným šumem. To je záměrně tak: okno ti má ukázat chování optimizéru (konvergenční průběh, sample body, best-so-far) a nechat tě porozumět definicím search space. Pro skutečné tréninkem řízené BayesOpt runy (jak prováděno ve fázi Q7 pro Scene-Class předvolby) se používá samostatný offline CLI workflow; toto okno je live UI varianta.

Tři použití: 1. Chceš porozumět, jak BayesOpt pracuje — pak spusť demo run a sleduj convergence chart. 2. Plánuješ novou třídu scén (např. „akvária" nebo „antický nábytek"), pro kterou vestavěné 10 předvoleb nesedí dokonale. Mentálně definuj search space, otestuj ho zde s „Bowl demo" nebo „Densify" předvolbou, exportuj pak best config jako JSON a použij ji jako výchozí bod pro skutečný tréninkový run. 3. Chceš inspektovat default search spaces definované v RKBayesOpt balíku (Mip-Subset, RadianceKit Defaults) — jsou listovány v parameter panelu levého sidebaru.

- Convergence chart (středový sloupec): Y = dosud nejlépe dosažená hodnota objective funkce. X = trial index. Zpočátku strmě stoupající (BayesOpt zkouší initial samples náhodně, některé z nich mají štěstí), pak stále plošeji, protože oblast blízkého optima je vyčerpaná. Pokud čára zůstane 20+ trialů plochá, můžeš run zastavit — další trialy už nic nepřinesou. Jednotlivé body v chartu jsou individuální trial hodnoty (tedy ne „best so far"), obarvené podle fáze: šedá = initial sample, modrá = bayesopt acquisition, oranžová = restart. - Trial tabulka (pravý sloupec): #1, #2, #3, … vždy s hodnotou a phase tagem. Dosud nejlepší trial je označen žlutou hvězdou. Z tabulky můžeš identifikovat best trial a jeho parametry si při exportu prohlédnout. - Search space inspector (levý sidebar): ukazuje pro zvolenou předvolbu všechny názvy parametrů a jejich rozsahy hledání [lo, hi]. Pokud stojíš na předvolbě „RadianceKit defaults (6-dim)", vidíš např. „densifyGradThreshold [5e-7, 5e-6]" — tedy log-uniform mezi těmito hodnotami.

Zvol předvolbu „RadianceKit defaults (6-dim)", Trial Budget 40, Seed 42. Klikni „Start". Pozoruj: prvních 8 trialů jsou šedé (initial samples, LHS Latin Hypercube), následné modré (BayesOpt acquired). Convergence chart bude strmý do trialu ~15, poté se zplošťuje. Při trialu ~30–40 se stabilizuje nejlepší hodnota. Klikni „Save Best Config" — uloží se bayesopt-best.json s názvem předvolby, trial indexem, hodnotou a dekódovanými hodnotami parametrů. Tento JSON pak můžeš ručně převzít do své definice předvolby.

W30Tlačítko „Start"

KDE

Toolbar vlevo, ve stavu Idle/Finished..

TECHNICKY

Resetuje seznam trialů, přepíná do Running stavu, generuje nové Run ID (pro stale detection při vícenásobných start klicích) a vytváří čerstvou pause gate. Pak startuje background task, který spouští optimizér jako asynchronní stream. Velikost initial samples vyplývá z min(8, budget / 4 + 1) — tedy typicky 8 Latin Hypercube samples při budgetu ≥ 28, méně u malého budgetu. Trial updaty se přijímají inkrementálně a připojují do seznamu. Stale run protection: pokud mezitím druhý start klik nastaví Run ID znovu, updaty ze starého runu se zahazují.

Primary action style pro prominentní vzhled tlačítka.

W31Tlačítko „Pause"

KDE

Toolbar vlevo, ve stavu Running..

TECHNICKY

Nastavuje pause gate aktivně a přepíná do Paused stavu. Skutečný efekt: runner čeká v 50 ms polling loopu, než vyhodnotí další objective funkci. To znamená, že právě běžící trial se dokončí (je přece syntetický a trvá jen mikrosekundy), ale žádný další trial se nespouští. Jakmile běží Resume, jde to dál tam, kde to skončilo.

W32Tlačítko „Stop"

KDE

Toolbar vlevo, ve stavu Running a Paused..

TECHNICKY

Ruší runner task, nuluje referenci, řeší pause gate (pokud bylo paused), a přepíná do Finished stavu (pokud trialy existují) nebo Idle stavu (pokud žádné). Již vypočítané trialy zůstávají v seznamu viditelné — Stop je nemaže. Destruktivní role tlačítka zobrazuje tlačítko červeně, protože ruší run.

W33Tlačítko „Resume"

KDE

Toolbar vlevo, ve stavu Paused..

TECHNICKY

Řeší pause gate a přepíná zpět do Running stavu. Runner task už běží (čeká v polling loopu); jakmile loop pozná, že pauza je zrušena, běží dál a spouští další trial.

W34Tlačítko „Save Best Config"

KDE

Toolbar vpravo, vždy viditelné (ale disabled, pokud neexistuje bestTrial)..

TECHNICKY

Otevírá Save dialog s defaultním názvem bayesopt-best.json, omezeno na JSON. Po potvrzení se staví payload dictionary: preset name, trial index, hodnota (objective score), parametry (dictionary dekódovaných parameter names → hodnoty). Decodování projektuje normalizované souřadnice search space v [0,1]^d zpět do původního rozsahu hodnot (s log-uniform/ linear/integer škálami příslušně). JSON výstup je pretty-printed a se seřazenými klíči. Při chybě zápisu (v aktuální demo verzi) se tiše ignoruje — žádné error UI, protože je to demo cesta.

Tlačítko zůstává šedé, dokud žádný trial neproběhl.

W35Picker „Search Space" předvolba

KDE

Levý sidebar, nahoře..

TECHNICKY

Menu picker se čtyřmi preset možnostmi: - „RadianceKit defaults (6-dim)" — kompletní standardní search space se všemi Q7 hyperparametry. - „Mip subset (2-dim)" — jen mipSmoothing3DScale [0.05, 0.5] log-uniform a mipFilter2DVariance [0.1, 0.6] linear. Užitečné, pokud chceš ladit Mip-Splatting pro třídu scén. - „densify-until + ssim-weight + grad-thresh" — tři densify relevantní parametry (densifyGradThreshold log-uniform, ssimWeight linear, densifyUntilIter integer). - „Bowl demo (1-dim)" — pedagogický single parameter search space pro „takhle funguje BayesOpt" dema.

Zatímco běh je aktivní, search space nelze měnit (zmátlo by to optimizér).

W36Slider „Trial Budget"

KDE

Levý sidebar, pod search space pickerem..

TECHNICKY

Slider od 10 do 200, krok 5. Default 40. To znamená: BayesOpt smí udělat maximálně N trialů. Z nich jsou prvních pár initial samples (Latin Hypercube), zbytek skutečné BayesOpt trialy. Pravidla pro praxi: search space s d dimenzemi potřebuje asi 10d až 20d trialů pro dobré optimum. U 6-dim defaultů tedy 60–120, u 2-dim Mip Subsetu 20–40, u 1-dim Bowl Dema 10–20.

Během běhu je slider deaktivován.

W37Slider „Random Seed"

KDE

Levý sidebar, pod budget sliderem..

TECHNICKY

Slider od 1 do 100, krok 1. Default 42. Seed se předává jak initial Latin Hypercube samples, tak noise komponentě demo objective. Reprodukovatelnost: stejný seed + stejný search space + stejný budget dává přesně identickou trial sekvenci. Užitečné pro „dostanou všichni tvoji kolegové stejný běh, když demo nastavují podle tebe?". Během běhu deaktivováno.

W38Chart (Convergence)

KDE

Středový sloupec okna..

TECHNICKY

Swift Charts diagram se dvěma vrstvami: 1. čára pro „best-value-so-far" na trial — monotónně stoupající nebo zůstávající křivka v akcentové barvě. 2. bod na trial s individuální objective hodnotou, obarvený podle fáze. Velikost symbolu 40. Tři phase labely: „init" (šedá), „bo" (modrá), „restart" (oranžová).

Malá legenda ukazuje phase barvy nahoře vlevo. Pokud je seznam trialů prázdný (před prvním startem), zobrazí se místo toho empty state s chart ikonou a hintem „Press Start to begin a BayesOpt run."

W39Table (Trial Log)

KDE

Pravý sloupec okna..

TECHNICKY

Scroll oblast s lazy stohovanými trial řádky. Na řádek horizontální stack: trial číslo (3místné monospaced, vlevo), hodnota (monospaced, zarovnáno vpravo, 70 pt široké), phase tag (capsule, vyplněný phase barvou při 25 % opacity), volitelně žlutá hvězda, pokud je tento trial aktuálně nejlepší. Auto scroll mechanismus automaticky skáče na konec, jakmile přijde nový trial — takže můžeš live průběh číst u spodního okraje obrazovky, aniž bys musel sám scrollovat.

Hlavní okno: průběh ztráty a Gaussian Count (I39–I41, křížový odkaz)

Tři ze zobrazení Inspektoru v hlavním okně si zaslouží vlastní vysvětlení, protože jsou během běžícího tréninku stále vidět a existují důležitá pravidla, kdy průběh vypadá zdravě. Zobrazení jsou v Inspektoru pod sekcí „Loss Chart" (viz Kapitolu 2 — Inspektor) a doplňují holdout analýzu z pomocného okna výše.

Kdy je loss křivka zdravá? Zdravá loss křivka ukazuje tři fáze: (1) warmup — v prvních 200–500 iteracích klesá loss strmě z vysoka (typicky 0.15–0.25 pro L1+SSIM kombinováno podle scény) asi na polovinu. Pokud loss v této fázi NEKLESÁ, většinou je vstup špatný (obrázky poškozené, SfM pozice špatné, počet initial Gaussianů příliš malý). (2) densifikace — mezi ~500 a densifyUntilIteration (klasicky 15K, MCMC do 20K nebo 25K) loss klesá dál, často s malými skoky dolů, když densify operace vkládají nové Gaussiany a optimizér je využívá. Gaussian count v této fázi stoupá. (3) refinement — poté loss běží do plošícího se tailu. Typické koncové hodnoty: Tanks-&-Temples Truck s P4 Quality přistává na L1 ≈ 0.023, Horse s Full Classic V546 na L1 ≈ 0.0230, outdoorové Mip-NeRF360 scény často horší (0.04–0.07).

Co znamená plató? Plató (loss křivka běží horizontálně přes několik tisíc iterací) má dvě interpretace: (a) model konvergoval, další trénink už nic nepřinese — to je dobrý případ. (b) model je stuck (lokální minimum, špatná gradient informace, cap na buffer limitu) — špatný případ. Oba vypadají v chartu identicky. Rozlišení: podívej se na Gaussian count. Pokud je také plochý A blízko MCMC capu (např. 150K z 150K u .fullMCMC), jsi na limitu — buď cap zvýšit nebo plató akceptovat. Pokud Gaussian count ještě roste, ale loss neklesá, je to stuck.

Kdy přerušit vs trénovat dál? Pravidlo: 10K iterací bez zlepšení Min Loss → přerušit, další iterace jsou promarněné. Předtím: můžeš přes Cmd+T (menu Training → Continue Training → +5K iterations) ještě připojit prodloužení, pokud vidíš okrajové zlepšení. Pozor: u MCMC je plató často skutečné — cap je přirozená hranice.

Gaussian count plató NENÍ signál „hotovo". Znamená pouze, že MCMC dosáhlo capu nebo že Classic densifikace je vyčerpaná. Skutečnou otázku „hotovo" klade až holdout analýza — PSNR/SSIM/LPIPS na nezávislém test setu, vyhodnoceno v holdout okně (W23–W29) nebo přes –benchmark flag.

PSNR/Holdout je pravda, Loss jen proxy. Loss je relativní metrika: klesá, dokud se tvůj model přizpůsobuje tréninkovým views. Nízký loss ale neznamená automaticky dobrý model — pokud se model nazpaměť naučil tréninkové obrázky (overfitting), byl by loss malý, ale PSNR na neviděných views (holdout) by byla špatná. Proto: pro finální posouzení kvality se vždy dívej na holdout metriky, ne pouze na end loss.

Pravidlo box

- User Guide a Keyboard Shortcuts jsou statická nápověda — u dotazů na klíčová slova rychlé, pro hloubku použij tuto příručku. - Manage Storage otevřít, jakmile disk klesne pod 10 % volného místa. Logy a Imports staging jsou obvyklí viníci. - Pareto Dashboard má smysl až po alespoň třech nebo čtyřech tréninkových reportech. X osa = náklady (Time / Gs), Y osa = kvalita (PSNR / SSIM). Pareto fronta ukazuje efektivní kombinace. - Holdout Analysis použít, než publikuješ PSNR benchmarky s ostatními — zajistí ti, že tvůj test set je skutečně reprezentativní. - BayesOpt Console je primárně učební a inspekční nástroj pro definice search space. Pro skutečné tréninkem řízené ladění hyperparametrů použij offline CLI workflow. - Loss plató a Gaussian count plató je třeba interpretovat odděleně. Cap limit není „hotovo" signál. Skutečnou kvalitu měří jen holdout PSNR. - 10K iterací bez zlepšení Min Loss → trénink zastavit.