Rozdział 8 — Formaty eksportu


Co widać na obrazie: Wielkość podana pod każdą kartą formatu jest obliczana na żywo na podstawie aktualnej liczby Gaussianów i narzutu formatu — nie jest zakodowana na sztywno. Z tej samej sceny powstają więc 2,2 MB PLY, 142 KB cPLY, 89 KB SOG, 216 KB SPZ, 2,1 MB glTF i 279 KB .splat; Web wypada z 378 KB wyżej, bo tam do pliku dołączany jest także sam viewer. Video i Wiggle pokazują „Zero KB", ponieważ wielkość znana jest dopiero po zakodowaniu. Wybrany kafelek ma niebieską ramkę, a przycisk poniżej przejmuje jego nazwę — tutaj „Export PLY (3DGS Standard)". Pod nagłówkiem widnieje wiersz „Leveling the floor turns the view at once; the chosen orientation and format apply when saving".
Zakończony trening dostarcza chmurę Gaussianów — zbiór od kilkuset tysięcy do milionów rozkładów Gaussa 3D, które razem rekonstruują scenę. Ten rozdział opisuje dziesięć sposobów zapisania tej chmury na dysku. Sześć z nich to czyste formaty danych 3D (PLY, Compressed PLY, SPZ, SOG, glTF, .splat), jeden łączy chmurę z gotowym viewerem HTML (Web Viewer), jeden renderuje plik MP4 z przejazdu kamery po orbicie (Orbit Video), a dwa nie eksportują żadnej zawartości Gaussianów, tylko wynik SfM (pozy kamer i zgrubną chmurę punktów) do ponownego wykorzystania w innych pipeline'ach treningowych (transforms.json + workspace COLMAP).
Osiem z tych sposobów dostępnych jest jako kafelek w sekcji eksportu — transforms.json i workspace COLMAP znajdują się tylko w menu. Poza tym siatka zawiera dziewiąty kafelek Wiggle, a pod przyciskiem eksportu znajduje się Upload to SuperSplat…, które zamiast do pliku wysyła scenę bezpośrednio do edytora SuperSplat w sieci.
To, który format jest właściwy w danej sytuacji, zależy od celu. Do archiwizacji pełnych danych bez utraty jakości wybierz PLY. Do viewerów internetowych na własnej stronie zwykle wystarczy .splat lub wbudowany viewer webowy. Jeśli plik musi być minimalny, warto sięgnąć po SPZ lub SOG. Do ponownego wykorzystania wyniku SfM w Nerfstudio, Postshot lub Brush właściwą drogą są transforms.json i workspace COLMAP.
Wszystkie funkcje eksportu znajdują się w menu „Export" oraz w trybie Simple na ostatnim etapie kreatora. Większość formatów jest w pełni zgodna z sandboxem i działa w wersji z App Store. Tylko SOG wymaga zewnętrznej binarki (cwebp), która w wersji z App Store nie musi być koniecznie dostępna — szczegóły patrz E4.
E1 — PLY (.ply)
GDZIE
Pasek menu → Export → 3D Formats → Export PLY… (⌘E). Tryb Simple: krok kreatora Export → karta formatu „PLY". Wielkość: typowo 100 % (wartość odniesienia). Kompatybilny z: SuperSplat, PolyCam, wszystkie viewery 3DGS.
TECHNICZNIE
PLY to kanoniczny format zapisu dla 3D Gaussian Splatting. RadianceKit zapisuje binarny plik little-endian ze standardowym układem właściwości 3DGS: na każdy Gaussian przypada trójskładnikowa pozycja, trzy zawsze wyzerowane normalne, trzy współczynniki SH DC (f_dc_0..2) dla podstawowego koloru RGB, następnie do 45 dodatkowych współczynników SH (f_rest_0..44) w transponowanym układzie channel-major zdefiniowanym w pracy Kerbl 2023 (najpierw wszystkie współczynniki kanału R, potem wszystkie G, na końcu wszystkie B), po czym opacyjność w przestrzeni logit (surowe wartości pre-sigmoid), trzy skale w przestrzeni logarytmicznej i rotacja w postaci kwaternionu wxyz. Maksymalny eksportowany stopień SH jest przycinany do minimum z życzenia użytkownika i faktycznie wyuczonego stopnia; domyślnie jest to 3 (45 współczynników rest). Przed zapisem wielkość payloadu jest obliczana jako 64-bitowa liczba całkowita, aby wychwycić przepełnienie przy ekstremalnie dużych chmurach. Plik jest zapisywany atomowo, co przy dużych chmurach chwilowo zajmuje podwójną ilość miejsca na dysku.
E2 — Compressed PLY (.ply)
GDZIE
Pasek menu → Export → 3D Formats → Export Compressed PLY…. Tryb Simple: karta formatu „Compressed PLY". Wielkość: ok. 10–20 % w stosunku do PLY (5- do 10-krotna kompresja). Kompatybilny z: SuperSplat, silnik PlayCanvas, viewery internetowe.
TECHNICZNIE
Wariant formatu PLY firmy PlayCanvas z podziałem na chunki i kwantyzacją. Gaussiany są grupowane w chunki po 256. Dla każdego chunka granice min/max dla pozycji, skali i koloru są zapisywane osobno w nagłówku; poszczególne Gaussiany odnoszą się do swoich wartości względem tych granic i są kompresowane do 32 bitów każdy: pozycja i skala z pakowaniem 11-10-11-bitowym, rotacja jako kwaternion „Smallest-Three" 2-10-10-10-bitowy, kolor jako RGBA 8-8-8-8. Wyższe współczynniki SH są kwantyzowane z zaledwie 8 bitami na składową (trzy bajty na współczynnik i Gaussian). Sam format nadal jest PLY z nagłówkiem ASCII, a więc zasadniczo można go zweryfikować narzędziami PLY, ale właściwości wierzchołków są zadeklarowane jako pola uint. Stopień SH domyślnie wynosi 0 (bez współczynników rest), aby zmaksymalizować kompresję — wyższe stopnie SH można wybrać jawnie.
E3 — SPZ (.spz)
GDZIE
Pasek menu → Export → 3D Formats → Export SPZ…. Tryb Simple: karta formatu „SPZ". Wielkość: ok. 10 % w stosunku do PLY (o 90 % mniejszy). Kompatybilny z: Niantic Scaniverse, Niantic Spatial Fields, MetalSplatter.
TECHNICZNIE
Format SPZ v2 firmy Niantic. Pozycje są pakowane jako 24-bitowa liczba stałoprzecinkowa (co daje ok. 0,25 mm rozdzielczości), skale jako kwantyzacja 8-bitowa w przestrzeni logarytmicznej, rotacje jako Smallest-Three 8-bitowe (w v2 zapisywane są tylko xyz, w jest wyprowadzane w dekoderze z normy kwaternionu), opacyjności jako 8-bitowe wartości po sigmoidzie. DC-SH jest zapisywane wg specyficznej dla SPZ formuły pakującej (dc_raw * 0.15 * 255 + 0.5 * 255), wyższe pasma SH z 5 bitami (pasmo 1) lub 4 bitami (pasmo 2-3) na współczynnik. Cały spakowany blob binarny jest następnie kompresowany standardowym gzip (RFC 1952), co daje format kontenera gzipped z magicznymi bajtami 1f 8b. RadianceKit wywołuje w tym celu systemowy gzip, ponieważ wbudowane API zlib Apple'a generuje własnościowe formatowanie Apple, które nie byłoby kompatybilne z czytnikami SPZ w Spatial Fields czy MetalSplatter. Systemowy gzip można nadal uruchomić w ramach sandboksa macOS.
E4 — SOG (.sog)
GDZIE
Pasek menu → Export → 3D Formats → Export SOG…. Tryb Simple: karta formatu „SOG". Wielkość: ok. 5–6 % w stosunku do PLY (15- do 20-krotna kompresja — najmniejsza opcja). Kompatybilny z: silnik PlayCanvas, edytor SuperSplat.
TECHNICZNIE
„Spatially Ordered Gaussians" — format PlayCanvas, który zapisuje chmurę gotową do GPU w kilku bezstratnych obrazach WebP. Najpierw wszystkie Gaussiany są sortowane przestrzennie za pomocą kodu Mortona 3D (30-bitowy Z-order, po 10 bitów na oś), co zapewnia obrazom późniejszą lokalność cache w rendererze. Następnie pozycje są kwantyzowane do wartości 16-bitowych za pomocą symetrycznej transformacji logarytmicznej (dla lepszego zakresu dynamiki) i dzielone na dwa obrazy RGBA (means_l.webp dla dolnych 8 bitów, means_u.webp dla górnych). Rotacje są kodowane jako Smallest-Three z 3×8 bitami plus 2-bitowym trybem w jednym obrazie RGBA (tryb trafia do alfa jako 252 + largest). Skale i DC-SH są kwantyzowane za pomocą po jednej 256-wpisowej książki kodowej (rozłożonej na bazie percentyli po wszystkich wartościach), indeksy trafiają do scales.webp i sh0.webp. Pięć obrazów plus meta.json z książkami kodowymi i granicami są pakowane do pliku ZIP (własny encoder, bo sandbox blokuje systemowy zip) i zapisywane z rozszerzeniem .sog.
Uwaga, sandbox: SOG to jedyna opcja formatu, która wymaga zewnętrznej binarki. Etap enkodera WebP wywołuje cwebp z /usr/local/bin/cwebp lub /opt/homebrew/bin/cwebp. Jeśli nie zostanie znaleziona żadna binarka cwebp, kod przechodzi na surowe kodowanie PNG — ale: zapasowe rozwiązanie PNG nie działa w SuperSplat. W wersji z App Store dostępność jest oceniana na podstawie wariantu builda; w wariancie deweloperskim cwebp musi być zainstalowany przez Homebrew (brew install webp).
E5 — glTF (.glb)
GDZIE
Pasek menu → Export → 3D Formats → Export glTF…. Tryb Simple: karta formatu „glTF". Wielkość: porównywalna z PLY. Kompatybilny z: viewery glTF z rozszerzeniem KHR_gaussian_splatting (standard roboczy Khronos).
TECHNICZNIE
Zapisuje samowystarczalny binarny plik .glb (bez oddzielnego załącznika bin) zgodnie ze specyfikacją rozszerzenia KHR_gaussian_splatting. Pozycje są zapisywane jako zwykłe dane wierzchołków glTF POSITION (float3), wszystkie pozostałe atrybuty (rotacja jako float4, skala jako float3, opacyjność jako float, współczynniki SH jako float3 × shCoeffCount) znajdują się w dodatkowych atrybutach wierzchołków i są odwoływane przez rozszerzenie. Ważne: glTF używa prawoskrętnego układu współrzędnych Y-up, COLMAP/3DGS pracuje w konwencji Y-down/Z-forward. Eksporter stosuje więc obrót o 180 stopni wokół osi X — pozycje są przepisywane jako (x, -y, -z), kwaterniony są dostosowywane do (w, x, -y, -z). Daje to geometrycznie poprawną, zgodną z konwencją ręczności (nielustrzaną) reprezentację w viewerach glTF. Segmenty JSON i binarne są dopełniane do wyrównania 4 bajtów, jak wymaga standard GLB.
E6 — Splat (.splat)
GDZIE
Pasek menu → Export → 3D Formats → Export .splat…. Tryb Simple: karta formatu „.splat". Wielkość: dokładnie 32 bajty na Gaussian. Kompatybilny z: gsplat.js, viewery internetowe (referencja antimatter15), większość demek przeglądarkowych 3DGS.
TECHNICZNIE
Format .splat antimatter15 — 32 bajty na Gaussian, brak nagłówka, brak pośrednictwa. Układ na wpis: 3 × float32 pozycja (współrzędne świata), 3 × float32 skala (transformowana wykładniczo z przestrzeni logarytmicznej wewnętrznego bufora), 4 × uint8 kolor RGBA (współczynnik DC-SH skalowany przez SH_C0 = 0.282... i przycinany do [0,255]), 4 × uint8 kwaternion (w,x,y,z, znormalizowany i zakodowany do zakresu bajtów jako 128 + 128*q). Zapisywane jest tylko DC-SH — wyższe pasma SH są odrzucane. Dzięki temu format jest niezwykle kompaktowy, ale kosztuje zależne od kąta patrzenia zmiany koloru, które występują przy odbiciach czy specularnych połyskach. Kolejność zapisu jest dokładnie kolejnością indeksów chmury (bez sortowania przestrzennego), viewery internetowe takie jak gsplat.js renderują na tej podstawie.

flowers-01.html otwarty bezpośrednio z Findera przez dwuklik w domyślnej przeglądarce — osadzony program WebGL2 renderuje chmurę Gaussianów od razu, bez sieci czy serwera. Czarne znaczniki wokół bukietu to kamery treningowe, opcjonalnie możliwe do wyświetlenia. Przeciąganie myszą obraca, przewijanie przybliża/oddala.E7 — Web Viewer (.html)
GDZIE
Pasek menu → Export → Media → Export Web Viewer…. Tryb Simple: karta formatu „Web Viewer". Wielkość: dane splat zakodowane w base64 (≈ 4/3 narzutu) + ok. 5 KB powłoki HTML/JS. Kompatybilny z: każdą nowoczesną przeglądarką z WebGL2 (wszystkie komputery, iOS 15+, Android 5+).
TECHNICZNIE
Łączy chmurę Gaussianów wraz z w pełni wbudowanym w linii rendererem WebGL2 w jeden plik .html. Nie ma zależności od CDN, żadnego WASM, żadnego drugiego pliku. Chmura jest wewnętrznie najpierw kodowana jako plik binarny .splat (ta sama logika 32-bajtowa co w E6), następnie osadzana w base64, następnie dekodowana w przeglądarce za pomocą atob. Wbudowany renderer wykonuje własne sortowanie WebGL2, sterowanie orbitą myszy i sortowanie CPU na klatkę; cały kod JS (shadery, matematyka, pętla) jest widoczny w wynikowym HTML. Konwencja osi na granicy przechowywanie–renderer jest dokładnie taka sama jak w E5: pozycja (x, -y, -z), kwaternion (w, x, -y, -z). Opcjonalnie można wyświetlić nakładkę brandingową (przełącznik warstwy darmowej). Ponieważ wszystko jest w linii, plik działa również bezpośrednio z protokołu file:// — nie jest potrzebny lokalny serwer webowy do testowania.

E8 — Orbit Video (.mp4/.mov)
GDZIE
Pasek menu → Viewport → Record Turntable Video LUB Pasek menu → Export → Media → Export Orbit Video…. Tryb Simple: karta formatu „Orbit Video" z suwakiem czasu trwania 3–30 s. Wielkość: zależna od czasu trwania, rozdzielczości, bitrate'u. Kompatybilny z: wszystkimi platformami (H.264 i HEVC to standard Apple).
TECHNICZNIE
Renderuje chmurę Gaussianów wzdłuż parametrycznego przejazdu kamery po orbicie i koduje każdą klatkę przez AVAssetWriter do pliku MP4 lub MOV. Konfiguracja orbity steruje prędkością obrotu (liczbą obrotów), odległością, elewacją, FOV, czasem trwania i współczynnikiem ease-in/out. Eksport wideo orbity działa na WŁASNYM etapie renderowania RadianceKit z pełną ewaluacją SH — pikselowo identyczny z viewportem w aplikacji (WYSIWYG). Na klatkę macierz dopasowania świata (obliczona przez renderer, aby obrócić wewnętrzne współrzędne do świata orbity Y-up) jest mnożona przez kamerę, następnie stosowane jest lustrzane odbicie konwersji kamery (orbita Y-up → COLMAP Y-down). Cel renderowania offscreen jest przeciągany przez IOSurface do CVPixelBuffer dla kodera. Koder obsługuje H.264 i HEVC, konfigurowalny bitrate i rozdzielczość od 480p do 8K. Przed pierwszą klatką renderer czeka 200 ms, aby wstępne sortowanie splatów zostało zakończone. Ten eksport jest ograniczony przez GPU — przy 8K i milionach Gaussianów czas renderowania na klatkę wynosi kilka sekund, a więc łączne czasy renderowania 10–30 minut dla 6 s wideo są możliwe.
E9 — SfM Transforms (transforms.json)
GDZIE
Pasek menu → Export → Photogrammetry → Export SfM (transforms.json)…. Wielkość: typowo 1–10 KB (tylko pozy + intrinsics, brak obrazów, brak Gaussianów). Kompatybilny z: nerfstudio, Brush, gsplat, OpenSplat, Meshroom, wszystkie nowoczesne trenery 3DGS typu feed-forward.
TECHNICZNIE
Zapisuje format transforms.json z nerfstudio z listą póz kamer plus wspólnymi intrinsics. Dla każdej kamery macierz widoku (wewnętrznie w RadianceKit: World-to-Camera w konwencji COLMAP) jest odwracana, następnie kamerowe lokalne wektory bazowe Y i Z są odbijane lustrzanie, aby przekonwertować do konwencji nerfstudio (styl OpenGL, kamera patrzy wzdłuż -Z, +Y jest górą). Finalna macierz 4×4 trafia jako zagnieżdżona tablica row-major typu double do pola transform_matrix każdej klatki. Intrinsics są zapisywane na poziomie najwyższym (ogniskowa x/y, punkt główny x/y, szerokość/wysokość obrazu, camera_model = "OPENCV", plus współczynniki dystorsji k1, k2, p1, p2) — chyba że eksporter wykryje wiele różnych zestawów intrinsics, wtedy są zapisywane per klatka. Ścieżki obrazów są zapisywane jako images/<filename> względem pliku JSON; użytkownik musi utworzyć siostrzany folder images/ ze zdjęciami treningowymi.
E10 — COLMAP Workspace (sparse/0/)
GDZIE
Pasek menu → Export → Photogrammetry → Export SfM (COLMAP Workspace)…. Wielkość: trzy pliki binarne razem typowo 4–8 MB — dominuje points3D.bin (jeden wiersz na punkt 3D rzadkiej chmury), images.bin i cameras.bin są zwykle znacznie poniżej 100 KB. Kompatybilny z: sam COLMAP, Nerfstudio, Postshot, Meshroom, wszystkie narzędzia oczekujące katalogu COLMAP sparse/.
TECHNICZNIE
Zapisuje standardowy układ COLMAP sparse/0/ z trzema plikami binarnymi: cameras.bin, images.bin, points3D.bin. Referencją formatu jest oficjalna dokumentacja COLMAP. cameras.bin zawiera zdeduplikowaną listę intrinsics (kamery z identycznymi intrinsics + rozmiarem obrazu są łączone w jeden wpis); użyty model kamery to OPENCV (model 4), z fx/fy/cx/cy plus czterema współczynnikami dystorsji k1/k2/p1/p2. images.bin wylicza dla każdego obrazu pozę jako kwaternion wxyz plus translację, po czym następuje ID kamery oraz nazwa pliku; nie są zapisywane żadne odpowiedniości 2D-3D. points3D.bin zawiera chmurę punktów SfM z pozycją, kolorem (0-255 RGB) i domyślnymi wartościami dla reprojekcji i długości ścieżki. Wszystko jest zapisywane w little-endian. Ponowny import w RadianceKit działa przez menu File → „Import COLMAP/Metashape Workspace…" (patrz Q3 w rozdziale o backendzie SfM).
Który format kiedy?
| Cel | Format |
|---|---|
| Przeglądarka internetowa na własnej stronie | E7 Web Viewer (.html) |
Przeglądarka internetowa z gsplat.js | E6 Splat (.splat) |
| Dalsze wykorzystanie w Postshot / Nerfstudio | E9 transforms.json + E10 COLMAP Workspace |
| Edycja w SuperSplat | E1 PLY lub E2 Compressed PLY |
| Niantic Scaniverse / Spatial Fields | E3 SPZ |
| Maksymalna kompresja | E4 SOG (wymagane cwebp) |
| Wideo marketingowe/social media | E8 Orbit Video |
| Dalsza edycja sceny w sieci | Przycisk „Upload to SuperSplat…" pod siatką formatów |
Szybkie porównanie
| Format | Rozszerzenie | Sandbox | Rozmiar (1M Gauss) | Najlepsze zastosowanie |
|---|---|---|---|---|
| E1 PLY | .ply | tak | ~250 MB | Archiwum, najwyższa kompatybilność |
| E2 Compressed PLY | .ply | tak | ~40 MB | Web + SuperSplat |
| E3 SPZ | .spz | tak (proces gzip) | ~40 MB | Niantic + Mobile |
| E4 SOG | .sog | warunkowo (cwebp) | ~20 MB | Maksymalna kompresja |
| E5 glTF | .glb | tak | ~250 MB | Pipeline Khronos |
| E6 Splat | .splat | tak | ~32 MB | Przeglądarka internetowa gsplat.js |
| E7 Web Viewer | .html | tak | ~45 MB | Samodzielny plik przeglądarki |
| E8 Orbit Video | .mp4/.mov | tak | zmienny | Social/Marketing |
| E9 SfM Transforms | .json | tak | ~5 KB | Przekazywanie póz |
| E10 COLMAP Workspace | Katalog | tak | ~4–8 MB | Przekazywanie póz (binarnie) |
Kolumna z rozmiarami zawiera przybliżone wartości orientacyjne dla 1 mln Gaussians przy stopniu SH 3. Rzeczywiste wartości różnią się w zależności od stopnia kompresowalności sceny; stopień SH 0 zmniejsza rozmiar PLY/glTF czterokrotnie.