Chapitre 8 — Formats d'export

OÙ

Barre de menus → Export → 3D Formats → Export PLY… (⌘E). Mode Simple : étape de l'assistant Export → carte de format « PLY ». Taille : typiquement 100 % (valeur de référence). Compatible avec : SuperSplat, PolyCam, tous les viewers 3DGS.

TECHNIQUE

PLY est le format de stockage canonique pour le 3D Gaussian Splatting. RadianceKit écrit un fichier binaire little-endian avec la disposition de propriétés 3DGS standardisée : par gaussienne, une position à trois composantes, trois normales toujours mises à zéro, trois coefficients SH DC (f_dc_0..2) pour la couleur RVB de base, puis jusqu'à 45 coefficients SH supplémentaires (f_rest_0..44) dans la disposition transposée channel-major définie par l'article de Kerbl 2023 (d'abord tous les coefficients du canal R, puis tous ceux du canal G, puis ceux du canal B), suivis de l'opacité en logit (valeurs brutes avant sigmoïde), trois échelles en espace logarithmique et d'une rotation en quaternion wxyz. Le degré SH maximal exporté est plafonné au minimum entre le souhait de l'utilisateur et le degré réellement appris ; la valeur par défaut est 3 (45 coefficients restants). Avant l'écriture, la taille de la charge utile est calculée en entier 64 bits, pour intercepter un dépassement de capacité pour des nuages extrêmement grands. Le fichier est écrit de manière atomique, ce qui occupe temporairement le double de l'espace disque pour les grands nuages.

OÙ

Barre de menus → Export → 3D Formats → Export Compressed PLY…. Mode Simple : carte de format « Compressed PLY ». Taille : env. 10 à 20 % par rapport au PLY (compression de 5 à 10 fois). Compatible avec : SuperSplat, moteur PlayCanvas, viewers basés sur le web.

TECHNIQUE

La variante PlayCanvas du format PLY avec une quantification chunked. Les gaussiennes sont regroupées en blocs de 256. Par bloc, les limites min/max pour la position, l'échelle et la couleur sont stockées séparément dans l'en-tête ; les gaussiennes individuelles référencent leurs valeurs par rapport à ces limites et sont comprimées sur 32 bits chacune : position et échelle avec un packing 11-10-11 bits, rotation en quaternion « Smallest-Three » 2-10-10-10 bits, couleur en RVBA 8-8-8-8. Les coefficients SH supérieurs sont quantifiés avec seulement 8 bits par composante (trois octets par coefficient et gaussienne). Le format lui-même reste un en-tête ASCII PLY et peut donc en principe être validé avec des outils PLY, mais les propriétés de sommet sont déclarées comme champs uint. Le degré SH par défaut est 0 (aucun coefficient restant), afin de maximiser la compression — des degrés SH plus élevés peuvent être choisis explicitement.

OÙ

Barre de menus → Export → 3D Formats → Export SPZ…. Mode Simple : carte de format « SPZ ». Taille : env. 10 % par rapport au PLY (90 % plus petit). Compatible avec : Niantic Scaniverse, Niantic Spatial Fields, MetalSplatter.

TECHNIQUE

Le format SPZ v2 de Niantic. Les positions sont compactées en virgule fixe 24 bits (ce qui donne une résolution d'env. 0,25 mm), les échelles en quantification 8 bits dans l'espace logarithmique, les rotations en Smallest-Three 8 bits (en v2, seuls xyz sont stockés, w est dérivé par le décodeur à partir de la norme du quaternion), les opacités en valeurs 8 bits passées par sigmoïde. Le SH DC est stocké avec une formule de packing spécifique à SPZ (dc_raw * 0.15 * 255 + 0.5 * 255), les bandes SH supérieures avec 5 bits (bande 1) ou 4 bits (bandes 2-3) par coefficient. L'ensemble du blob binaire compacté est ensuite comprimé avec le gzip standard (RFC 1952), ce qui donne un format de conteneur gzippé avec les octets magiques 1f 8b. RadianceKit appelle pour cela le gzip système, car l'API zlib intégrée d'Apple génère un framing propriétaire Apple, qui ne serait pas compatible avec les lecteurs SPZ de Spatial Fields ou MetalSplatter. Le gzip système reste exécutable même à l'intérieur du bac à sable macOS.

OÙ

Barre de menus → Export → 3D Formats → Export SOG…. Mode Simple : carte de format « SOG ». Taille : env. 5 à 6 % par rapport au PLY (compression de 15 à 20 fois — l'option la plus petite). Compatible avec : moteur PlayCanvas, éditeur SuperSplat.

TECHNIQUE

« Spatially Ordered Gaussians » — un format PlayCanvas qui stocke le nuage prêt pour le GPU dans plusieurs images WebP sans perte. D'abord, toutes les gaussiennes sont triées spatialement par code de Morton 3D (Z-order 30 bits, 10 bits par axe), ce qui procure aux images une meilleure localité de cache lors du rendu ultérieur. Ensuite, les positions sont quantifiées sur 16 bits avec une transformation logarithmique symétrique (pour une meilleure plage dynamique) et réparties en deux images RVBA (means_l.webp pour les 8 bits inférieurs, means_u.webp pour les 8 bits supérieurs). Les rotations sont encodées en Smallest-Three avec 3×8 bits plus un mode 2 bits dans une image RVBA (le mode se retrouve dans le canal alpha comme 252 + largest). Les échelles et le SH DC sont quantifiés avec chacun un tableau de correspondance à 256 entrées (réparti par percentile sur l'ensemble des valeurs), les indices se retrouvant dans scales.webp et sh0.webp. Les cinq images plus un fichier meta.json contenant les tableaux de correspondance et les limites sont regroupés dans un fichier ZIP (encodeur personnalisé, car le bac à sable bloque le zip système) et enregistrés avec l'extension .sog.

Attention bac à sable : SOG est la seule option de format qui nécessite un binaire externe. L'étape d'encodage WebP appelle cwebp depuis /usr/local/bin/cwebp ou /opt/homebrew/bin/cwebp. Si aucun binaire cwebp n'est trouvé, le code se rabat sur un encodage PNG brut — mais attention : le repli PNG ne fonctionne pas dans SuperSplat. Dans la version App Store, la disponibilité est évaluée en fonction de la variante de build ; dans la variante développeur, cwebp doit être installé via Homebrew (brew install webp).

OÙ

Barre de menus → Export → 3D Formats → Export glTF…. Mode Simple : carte de format « glTF ». Taille : comparable au PLY. Compatible avec : viewers glTF avec l'extension KHR_gaussian_splatting (standard préliminaire Khronos).

TECHNIQUE

Écrit un fichier binaire .glb autonome (pas de fichier bin séparé en annexe) conformément à la spécification de l'extension KHR_gaussian_splatting. Les positions sont stockées comme données de sommet glTF POSITION régulières (float3), tous les autres attributs (rotation en float4, échelle en float3, opacité en float, coefficients SH en float3 × shCoeffCount) se trouvent dans des attributs de sommet supplémentaires et sont référencés via l'extension. Important : glTF utilise un système de coordonnées droitier Y-up, COLMAP/3DGS travaille en Y-down/Z-forward. L'exportateur applique donc une rotation de 180 degrés autour de l'axe X — les positions sont réécrites avec (x, -y, -z), les quaternions sont adaptés en (w, x, -y, -z). Cela donne une représentation géométriquement correcte, non spéculaire (pas inversée) dans les viewers glTF. Les chunks JSON et binaires sont alignés sur 4 octets, comme l'exige le standard GLB.

OÙ

Barre de menus → Export → 3D Formats → Export .splat…. Mode Simple : carte de format « .splat ». Taille : exactement 32 octets par gaussienne. Compatible avec : gsplat.js, viewers basés sur le web (référence antimatter15), la plupart des démos 3DGS dans le navigateur.

TECHNIQUE

Le format .splat d'antimatter15 — 32 octets par gaussienne, pas d'en-tête, pas d'indirection. Disposition par entrée : 3 × float32 position (coordonnées monde), 3 × float32 échelle (transformée par exponentielle depuis l'espace logarithmique du buffer interne), 4 × uint8 couleur RVBA (coefficient SH DC mis à l'échelle avec SH_C0 = 0,282... et plafonné à [0,255]), 4 × uint8 quaternion (w,x,y,z, normalisé et encodé dans la plage d'octets comme 128 + 128*q). Seul le SH DC est stocké — les bandes SH supérieures sont abandonnées. Cela rend le format extrêmement compact, mais fait perdre les changements de couleur dépendants de la vue, qui apparaissent lors de reflets ou de brillances spéculaires. L'ordre d'écriture correspond exactement à l'ordre des index du nuage (pas de tri spatial), les viewers web comme gsplat.js s'en servent comme base pour le rendu.

OÙ

Barre de menus → Export → Media → Export Web Viewer…. Mode Simple : carte de format « Web Viewer ». Taille : données splat encodées en base64 (surcoût ≈ 4/3) + env. 5 Ko de coquille HTML/JS. Compatible avec : tout navigateur moderne avec WebGL2 (tous les ordinateurs, iOS 15+, Android 5+).

TECHNIQUE

Regroupe le nuage de gaussiennes avec un moteur de rendu WebGL2 entièrement écrit en ligne dans un seul fichier .html. Il n'y a aucune dépendance CDN, pas de WASM, pas de second fichier. Le nuage est d'abord encodé en interne comme binaire .splat (même logique 32 octets que E6), puis intégré en base64, puis décodé avec atob dans le navigateur. Le moteur de rendu intégré effectue son propre tri WebGL2, son propre contrôle d'orbite à la souris et un tri CPU par image ; tout le code JS (shaders, mathématiques, boucle) est visible dans le HTML de sortie. La convention d'axes à la frontière stockage-moteur de rendu est exactement la même qu'en E5 : position (x, -y, -z), quaternion (w, x, -y, -z). En option, un overlay de marque peut être affiché (interrupteur du palier gratuit). Comme tout est en ligne, le fichier fonctionne aussi directement depuis le protocole file:// — pas besoin de serveur web local pour tester.

OÙ

Barre de menus → Viewport → Record Turntable Video OU Barre de menus → Export → Media → Export Orbit Video…. Mode Simple : carte de format « Orbit Video » avec curseur de durée 3 à 30 s. Taille : dépend de la durée, de la résolution, du débit. Compatible avec : toutes les plateformes (H.264 et HEVC sont des standards Apple).

TECHNIQUE

Effectue le rendu du nuage de gaussiennes le long d'un déplacement de caméra en orbite paramétrique et encode chaque image via AVAssetWriter dans un fichier MP4 ou MOV. La configuration d'orbite contrôle la vitesse de rotation (tours), la distance, l'élévation, le champ de vision, la durée et le facteur d'accélération/décélération. L'export Orbit Video passe par la PROPRE étape de rendu de RadianceKit avec évaluation SH complète — pixel pour pixel identique au viewport intégré à l'app (WYSIWYG). Par image, la matrice d'ajustement du monde (calculée par le moteur de rendu, pour faire pivoter les coordonnées internes vers le monde orbite Y-up) est multipliée par la caméra, puis une réflexion de conversion caméra (orbite Y-up → COLMAP Y-down) est appliquée. La cible de rendu hors écran est transférée via IOSurface vers un CVPixelBuffer pour l'encodeur. L'encodeur prend en charge H.264 et HEVC, un débit configurable et des résolutions de 480p jusqu'à 8K. Avant la première image, le moteur de rendu attend 200 ms, pour que le tri initial des splats soit terminé. Cet export est limité par le GPU — en 8K et avec des millions de gaussiennes, le temps de rendu par image se situe à plusieurs secondes, donc des temps de rendu totaux de 10 à 30 minutes sont possibles pour une vidéo de 6 s.

OÙ

Barre de menus → Export → Photogrammetry → Export SfM (transforms.json)…. Taille : typiquement 1 à 10 Ko (uniquement poses + intrinsèques, pas d'images, pas de gaussiennes). Compatible avec : nerfstudio, Brush, gsplat, OpenSplat, Meshroom, tous les entraîneurs 3DGS feed-forward modernes.

TECHNIQUE

Écrit le format transforms.json de nerfstudio avec une liste de poses de caméra plus des intrinsèques partagées. Par caméra, la matrice de vue (en interne RadianceKit : monde vers caméra en convention COLMAP) est inversée, puis les vecteurs de base locaux à la caméra Y et Z sont inversés, pour convertir vers la convention nerfstudio (style OpenGL, la caméra regarde selon -Z, +Y est en haut). La matrice 4×4 finale se retrouve sous forme de tableau imbriqué row-major de doubles dans le champ transform_matrix de chaque frame. Les intrinsèques sont stockées au niveau supérieur (focale x/y, point principal x/y, largeur/hauteur d'image, camera_model = "OPENCV", plus les coefficients de distorsion k1, k2, p1, p2) — sauf si l'exportateur détecte plusieurs jeux d'intrinsèques différents, auquel cas ils sont écrits par frame. Les chemins d'image sont écrits comme images/<filename> relatif au fichier JSON ; l'utilisateur doit créer un dossier images/ voisin avec les photos d'entraînement.

OÙ

Barre de menus → Export → Photogrammetry → Export SfM (COLMAP Workspace)…. Taille : trois fichiers binaires totalisant typiquement 4 à 8 Mo — points3D.bin domine (une ligne par point 3D du nuage clairsemé), images.bin et cameras.bin font chacun nettement moins de 100 Ko. Compatible avec : COLMAP lui-même, Nerfstudio, Postshot, Meshroom, tous les outils attendant un répertoire COLMAP sparse/.

TECHNIQUE

Écrit la disposition standard COLMAP sparse/0/ avec trois fichiers binaires : cameras.bin, images.bin, points3D.bin. La référence de format est la documentation officielle de COLMAP. cameras.bin contient la liste dédupliquée des intrinsèques (les caméras avec des intrinsèques identiques + taille d'image sont regroupées en une seule entrée) ; le modèle de caméra utilisé est OPENCV (modèle 4), avec fx/fy/cx/cy plus les quatre coefficients de distorsion k1/k2/p1/p2. images.bin liste pour chaque image la pose sous forme de quaternion wxyz plus translation, suivi de l'ID de caméra et du nom de fichier ; aucune correspondance 2D-3D n'est stockée. points3D.bin contient le nuage de points SfM avec position, couleur (RVB 0-255) et valeurs par défaut pour la reprojection et la longueur de piste. Tout est écrit en little-endian. Une réimportation dans RadianceKit fonctionne via le menu Fichier → « Import COLMAP/Metashape Workspace… » (voir Q3 dans le chapitre backend SfM).