Kapitel 8 — Export-Formate

WO

Menüleiste → Export → 3D Formats → Export PLY… (⌘E). Simple-Mode: Wizard-Schritt Export → Format-Karte „PLY". Größe: typisch 100 % (Referenzwert). Kompatibel mit: SuperSplat, PolyCam, alle 3DGS-Viewer.

TECHNISCH

PLY ist das kanonische Speicherformat für 3D Gaussian Splatting. RadianceKit schreibt eine binäre Little-Endian-Datei mit dem standardisierten 3DGS-Property-Layout: pro Gaussian dreikomponentige Position, drei stets auf Null gesetzte Normalen, drei DC-SH-Koeffizienten (f_dc_0..2) für die Basis-RGB-Farbe, anschließend bis zu 45 weitere SH-Koeffizienten (f_rest_0..44) in der vom Kerbl-2023-Paper definierten transponierten Channel-Major-Anordnung (erst alle R-Kanal-Koeffizienten, dann alle G, dann alle B), gefolgt von Logit-Opazität (rohe pre-Sigmoid-Werte), drei Log-Space-Skalen und einer wxyz-Quaternion-Rotation. Der maximal exportierte SH-Grad wird auf das Minimum aus User-Wunsch und tatsächlich gelerntem Grad geclampt; Default ist 3 (45 Rest-Koeffizienten). Vor dem Schreiben wird die Payload-Größe in 64-Bit-Integer berechnet, um Überlauf bei extrem großen Clouds zu fangen. Die Datei wird atomar geschrieben, was bei großen Clouds kurzzeitig den doppelten Plattenspeicher belegt.

WO

Menüleiste → Export → 3D Formats → Export Compressed PLY…. Simple-Mode: Format-Karte „Compressed PLY". Größe: ca. 10–20 % gegenüber PLY (5- bis 10-fache Kompression). Kompatibel mit: SuperSplat, PlayCanvas-Engine, web-basierte Viewer.

TECHNISCH

Die PlayCanvas-Variante des PLY-Formats mit chunked Quantisierung. Die Gaussians werden in 256er-Chunks gruppiert. Pro Chunk werden Min/Max-Bounds für Position, Scale und Color separat im Header abgelegt; die einzelnen Gaussians referenzieren ihre Werte relativ zu diesen Bounds und werden auf je 32 Bit komprimiert: Position und Skala mit 11-10-11-Bit-Packing, Rotation als 2-10-10-10-Bit „Smallest-Three"-Quaternion, Farbe als 8-8-8-8-RGBA. Höhere SH-Koeffizienten werden mit nur 8 Bit pro Komponente quantisiert (shCoeffCount * 3 uchar pro Gaussian). Das Format selbst ist immer noch ASCII-Header-PLY und damit grundsätzlich validierbar mit PLY-Tools, aber die Vertex-Properties sind als uint-Felder deklariert. SH-Grad ist per Default 0 (keine Rest-Koeffizienten), um die Kompression zu maximieren — höhere SH-Grade können explizit gewählt werden.

WO

Menüleiste → Export → 3D Formats → Export SPZ…. Simple-Mode: Format-Karte „SPZ". Größe: ca. 10 % gegenüber PLY (90 % kleiner). Kompatibel mit: Niantic Scaniverse, Niantic Spatial Fields, MetalSplatter.

TECHNISCH

Niantics SPZ-v2-Format. Positionen werden als 24-Bit-Fixed-Point gepackt (das ergibt ca. 0,25 mm Auflösung), Skalen als 8-Bit-Quantisierung im Log-Raum, Rotationen als 8-Bit-Smallest-Three (in v2 werden nur xyz gespeichert, w wird im Decoder aus der Quaternion-Norm abgeleitet), Opazitäten als sigmoidisierte 8-Bit-Werte. DC-SH wird mit einer SPZ-spezifischen Pack-Formel (dc_raw * 0.15 * 255 + 0.5 * 255) gespeichert, höhere SH-Bands mit 5 Bit (Band 1) bzw. 4 Bit (Band 2-3) pro Koeffizient. Der gesamte gepackte Binärblob wird anschließend mit Standard-gzip (RFC 1952) komprimiert, was ein gzipped-Container-Format mit Magic Bytes 1f 8b ergibt. RadianceKit ruft hierfür das System-gzip auf, weil Apples eingebaute zlib-API proprietäres Apple-Framing erzeugt, das nicht kompatibel zu den SPZ-Readern in Spatial Fields oder MetalSplatter wäre. Das System-gzip bleibt auch innerhalb der macOS-Sandbox spawnbar.

WO

Menüleiste → Export → 3D Formats → Export SOG…. Simple-Mode: Format-Karte „SOG". Größe: ca. 5–6 % gegenüber PLY (15- bis 20-fache Kompression — die kleinste Option). Kompatibel mit: PlayCanvas-Engine, SuperSplat-Editor.

TECHNISCH

„Spatially Ordered Gaussians" — ein PlayCanvas-Format, das die Cloud GPU-ready in mehreren Lossless-WebP-Bildern speichert. Erst werden alle Gaussians per 3D-Morton-Code (30-Bit Z-Order, je 10 Bit pro Achse) räumlich sortiert, was den Bildern spätere Cache-Locality im Renderer beschert. Dann werden Positionen mit symmetrischer Log-Transformation (für besseren Dynamikumfang) auf 16-Bit-Werte quantisiert und in zwei RGBA-Bilder gesplittet (means_l.webp für die unteren 8 Bit, means_u.webp für die oberen). Rotationen werden als Smallest-Three mit 3×8-Bit plus 2-Bit-Mode in einem RGBA-Bild kodiert (Mode landet in Alpha als 252 + largest). Skalen und DC-SH werden mit je einem 256-Eintrag-Codebook quantisiert (Perzentil-basiert über alle Werte verteilt), die Indizes landen in scales.webp und sh0.webp. Die fünf Bilder plus eine meta.json mit Codebooks und Bounds werden in eine ZIP-Datei gepackt (Custom-Encoder, weil die Sandbox das System-zip blockiert) und mit der Endung .sog gespeichert.

Achtung Sandbox: SOG ist die einzige Format-Option, die eine externe Binary erfordert. Die WebP-Encoder-Stufe ruft cwebp aus /usr/local/bin/cwebp oder /opt/homebrew/bin/cwebp auf. Falls keine cwebp-Binary gefunden wird, fällt der Code auf rohes PNG-Encoding zurück — aber: PNG-Fallback funktioniert nicht in SuperSplat. In der App-Store-Version evaluiere die Verfügbarkeit anhand der Build-Variante; in der Developer-Variante muss cwebp via Homebrew installiert sein (brew install webp).

WO

Menüleiste → Export → 3D Formats → Export glTF…. Simple-Mode: Format-Karte „glTF". Größe: vergleichbar mit PLY. Kompatibel mit: glTF-Viewer mit KHR_gaussian_splatting-Extension (Khronos-Draft-Standard).

TECHNISCH

Schreibt eine selbsterhaltende .glb-Binärdatei (kein separater Bin-File-Anhang) gemäß der KHR_gaussian_splatting-Extension-Spezifikation. Positionen werden als reguläre glTF-POSITION-Vertex-Daten (float3) gespeichert, alle anderen Attribute (Rotation als float4, Scale als float3, Opacity als float, SH-Koeffizienten als float3 × shCoeffCount) liegen in zusätzlichen Vertex-Attributen und werden über die Extension referenziert. Wichtig: glTF benutzt rechtshändiges Y-up-Koordinatensystem, COLMAP/3DGS arbeitet Y-down/Z-forward. Der Exporter wendet daher eine 180-Grad-Drehung um die X-Achse an — Positionen werden mit (x, -y, -z) umgeschrieben, Quaternionen werden auf (w, x, -y, -z) angepasst. Das ergibt eine geometrisch korrekte, händige (nicht spiegelverkehrte) Darstellung in glTF-Viewern. JSON- und Binärchunks werden auf 4-Byte-Alignment gepaddet, wie vom GLB-Standard verlangt.

WO

Menüleiste → Export → 3D Formats → Export .splat…. Simple-Mode: Format-Karte „.splat". Größe: exakt 32 Bytes pro Gaussian. Kompatibel mit: gsplat.js, web-basierte Viewer (antimatter15-Referenz), die meisten Browser-3DGS-Demos.

TECHNISCH

Das antimatter15-.splat-Format — 32 Bytes pro Gaussian, kein Header, keine Indirektion. Layout pro Eintrag: 3 × float32 Position (Welt-Koordinaten), 3 × float32 Scale (exp-transformiert aus dem Log-Space des internen Buffers), 4 × uint8 RGBA-Farbe (DC-SH-Koeffizient mit SH_C0 = 0.282... skaliert und auf [0,255] geclampt), 4 × uint8 Quaternion (w,x,y,z, normalisiert und als 128 + 128*q in den Byte-Bereich kodiert). Nur DC-SH wird gespeichert — höhere SH-Bänder werden verworfen. Das macht das Format extrem kompakt, kostet aber die View-abhängigen Farbänderungen, die bei Spiegelungen oder spekularen Highlights auftreten. Die Schreibreihenfolge ist exakt die Index-Reihenfolge der Cloud (keine räumliche Sortierung), Web-Viewer wie gsplat.js rendern davon ausgehend.

WO

Menüleiste → Export → Media → Export Web Viewer…. Simple-Mode: Format-Karte „Web Viewer". Größe: Splat-Daten base64-kodiert (≈ 4/3 Overhead) + ca. 5 KB HTML/JS-Shell. Kompatibel mit: jeder moderne Browser mit WebGL2 (alle Desktops, iOS 15+, Android 5+).

TECHNISCH

Bündelt die Gaussian-Cloud zusammen mit einem vollständig inline geschriebenen WebGL2-Renderer in eine einzelne .html-Datei. Es gibt keine CDN-Abhängigkeiten, kein WASM, kein zweites File. Die Cloud wird intern erst als .splat-Binary kodiert (gleiche 32-Byte-Logik wie E6), dann base64-eingebettet, dann mit atob im Browser dekodiert. Der eingebaute Renderer macht eigene WebGL2-Sortierung, Maus-Orbit-Steuerung und CPU-Sortierung pro Frame; der gesamte JS-Code (Shader, Mathematik, Loop) ist im Output-HTML zu sehen. Die Achsen-Konvention an der Speicher-zu-Renderer-Grenze ist exakt dieselbe wie in E5: Position (x, -y, -z), Quaternion (w, x, -y, -z). Optional kann ein Branding-Overlay eingeblendet werden (Free-Tier-Schalter). Da alles inline ist, funktioniert die Datei auch direkt aus dem file://-Protokoll — kein lokaler Webserver nötig zum Testen.

WO

Menüleiste → Viewport → Record Turntable Video ODER Menüleiste → Export → Media → Export Orbit Video…. Simple-Mode: Format-Karte „Orbit Video" mit Dauer-Slider 3–30 s. Größe: abhängig von Dauer, Auflösung, Bitrate. Kompatibel mit: alle Plattformen (H.264 und HEVC sind Apple-Standard).

TECHNISCH

Rendert die Gaussian-Cloud entlang einer parametrischen Orbit-Kamerafahrt und encodiert jeden Frame über AVAssetWriter in eine MP4- oder MOV-Datei. Die Orbit-Konfiguration steuert Drehzahl (Umdrehungen), Distanz, Elevation, FOV, Dauer und Ease-In/Out-Faktor. Pro Frame wird die Welt-Anpassungsmatrix (vom Renderer berechnet, um die internen Koordinaten in die Y-up-Orbit-Welt zu drehen) mit der Kamera multipliziert, anschließend wird die MetalSplatter-spezifische Y-Spiegelung angewendet. Das Offscreen-Render-Target wird via IOSurface zu einem CVPixelBuffer für den Encoder gezogen. Der Encoder unterstützt H.264 und HEVC, konfigurierbare Bitrate und Auflösung von 480p bis 8K. Vor dem ersten Frame wartet der Renderer 200 ms, damit die initiale Splat-Sortierung abgeschlossen ist. Dieser Export ist GPU-bound — bei 8K und Millionen Gaussians liegt die Render-Zeit pro Frame bei mehreren Sekunden, also Gesamt-Renderzeiten von 10–30 Minuten für 6 s Video möglich.

WO

Menüleiste → Export → Photogrammetry → Export SfM (transforms.json)…. Größe: typisch 1–10 KB (nur Posen + Intrinsics, keine Bilder, keine Gaussians). Kompatibel mit: nerfstudio, Brush, gsplat, OpenSplat, Meshroom, alle modernen feed-forward 3DGS-Trainer.

TECHNISCH

Schreibt das nerfstudio-transforms.json-Format mit einer Liste von Kamera-Posen plus geteilten Intrinsics. Pro Kamera wird die View-Matrix (RadianceKit-intern: World-to-Camera in COLMAP-Konvention) invertiert, anschließend werden die kameralokalen Y- und Z-Basisvektoren gespiegelt, um in die nerfstudio-Konvention (OpenGL-Style, Kamera schaut entlang -Z, +Y ist oben) zu konvertieren. Die finale 4×4-Matrix landet als row-major nested array von Doubles im transform_matrix-Feld jedes Frames. Intrinsics werden auf der Top-Level gespeichert (Brennweite x/y, Hauptpunkt x/y, Bildbreite/-höhe, camera_model = "OPENCV", plus die Distortion-Coefficients k1, k2, p1, p2) — außer wenn der Exporter mehrere unterschiedliche Intrinsics-Sets erkennt, dann werden sie per Frame geschrieben. Bildpfade werden als images/<filename> relativ zur JSON-Datei geschrieben; der User muss einen Sibling-images/-Folder mit den Trainingsfotos anlegen.

WO

Menüleiste → Export → Photogrammetry → Export SfM (COLMAP Workspace)…. Größe: drei Binärdateien zusammen typisch 4–8 MB — points3D.bin dominiert (eine Zeile pro 3D-Punkt der Sparse-Cloud), images.bin und cameras.bin sind jeweils deutlich unter 100 KB. Kompatibel mit: COLMAP selbst, Nerfstudio, Postshot, Meshroom, alle Tools, die ein COLMAP-sparse/-Verzeichnis erwarten.

TECHNISCH

Schreibt das Standard-COLMAP-sparse/0/-Layout mit drei binären Dateien: cameras.bin, images.bin, points3D.bin. Format-Referenz ist die offizielle COLMAP-Dokumentation. cameras.bin enthält die deduplizierte Intrinsics-Liste (Kameras mit identischen Intrinsics + Bildgröße werden zu einem einzigen Eintrag zusammengefasst); das verwendete Camera-Model ist OPENCV (Model 4), mit fx/fy/cx/cy plus den vier Distortion-Coefficients k1/k2/p1/p2. images.bin listet pro Bild die Pose als wxyz-Quaternion plus Translation, gefolgt von der Kamera-ID und dem Dateinamen; keine 2D-3D-Korrespondenzen werden gespeichert. points3D.bin enthält die SfM-Punktwolke mit Position, Farbe (0-255 RGB) und Default-Werten für Reprojektion und Track-Length. Alles wird in Little-Endian geschrieben. Re-Import in RadianceKit funktioniert über das File-Menü → „Import COLMAP/Metashape Workspace…" (siehe Q3 im SfM-Backend-Kapitel).