第8章 — エクスポート形式

場所

メニューバー → Export → 3D Formats → Export PLY…（⌘E）。 Simple Mode: ウィザードステップExport → 形式カード「PLY」。 サイズ: 標準100%（基準値）。互換性: SuperSplat、PolyCam、すべての3DGSビューア。

技術詳細

PLYは3D Gaussian Splattingの標準的な保存形式である。 RadianceKitは標準化された3DGSプロパティレイアウトを持つバイナリ リトルエンディアンファイルを書き出す：各ガウスにつき3成分の位置、 常にゼロに設定される3つの法線、基本RGB色のための3つのDC-SH係数 （f_dc_0..2）、続いてKerbl-2023論文で定義された転置チャンネル メジャー配置（まずRチャンネルの全係数、次に全G、最後に全B）による 最大45個の追加SH係数（f_rest_0..44）、そしてロジット不透明度 （生のpre-sigmoid値）、3つのログ空間スケール、wxyzクォータニオン 回転が続く。エクスポートされる最大SH次数は、ユーザーの希望と実際に 学習された次数の最小値にクランプされる。デフォルトは3（45個の残余 係数）だ。書き込み前にペイロードサイズは64ビット整数で計算され、 極めて大きなクラウドでのオーバーフローを防ぐ。ファイルはアトミックに 書き込まれるため、大きなクラウドでは一時的にディスク容量が2倍必要に なる。

場所

メニューバー → Export → 3D Formats → Export Compressed PLY…。 Simple Mode: 形式カード「Compressed PLY」。 サイズ: PLY比で約10～20%（5～10倍の圧縮）。互換性: SuperSplat、PlayCanvasエンジン、Webベースのビューア。

技術詳細

チャンク化量子化を伴うPLY形式のPlayCanvas版。ガウスは 256個単位のチャンクにグループ化される。チャンクごとに、位置・スケール・ 色それぞれの最小/最大境界がヘッダーに別々に保存される。個々のガウス はこれらの境界に対する相対値を参照し、それぞれ32ビットに圧縮される： 位置とスケールは11-10-11ビットパッキング、回転は2-10-10-10ビットの 「Smallest-Three」クォータニオン、色は8-8-8-8のRGBAで表現される。 より高次のSH係数は成分あたりわずか8ビットで量子化される（係数・ガウス 1つにつき3バイト）。形式自体は依然としてASCIIヘッダーPLYであり、 基本的にPLYツールで検証可能だが、頂点プロパティはuintフィールド として宣言されている。SH次数はデフォルトで0（残余係数なし）に設定 され、圧縮率を最大化する — より高いSH次数も明示的に選択可能だ。

場所

メニューバー → Export → 3D Formats → Export SPZ…。 Simple Mode: 形式カード「SPZ」。 サイズ: PLY比で約10%（90%小さい）。 互換性: Niantic Scaniverse、Niantic Spatial Fields、 MetalSplatter。

技術詳細

NianticのSPZ v2形式。位置は24ビット固定小数点でパック される（約0.25mmの解像度に相当）、スケールはログ空間での8ビット量子化、 回転は8ビットSmallest-Three（v2ではxyzのみ保存され、wはデコーダ側で クォータニオンのノルムから導出される）、不透明度はシグモイド化された 8ビット値として保存される。DC-SHはSPZ固有のパック式 （dc_raw * 0.15 * 255 + 0.5 * 255）で保存され、より高次のSHバンド は係数あたり5ビット（バンド1）または4ビット（バンド2-3）で保存される。 パックされたバイナリブロブ全体は、その後標準gzip（RFC 1952）で圧縮 され、マジックバイト1f 8bを持つgzip化コンテナ形式となる。 RadianceKitはこのためにシステムのgzipを呼び出す。というのも、 Appleが内蔵するzlib APIは独自のAppleフレーミングを生成し、Spatial FieldsやMetalSplatterのSPZリーダーとは互換性がないためだ。システムの gzipはmacOSサンドボックス内でも起動可能である。

場所

メニューバー → Export → 3D Formats → Export SOG…。 Simple Mode: 形式カード「SOG」。 サイズ: PLY比で約5～6%（15～20倍の圧縮 — 最小の選択肢）。互換性: PlayCanvasエンジン、 SuperSplatエディタ。

技術詳細

「Spatially Ordered Gaussians」— クラウドを 複数のロスレスWebP画像としてGPU-readyな形で保存するPlayCanvas形式。 まず全ガウスが3Dモートンコード（30ビットZオーダー、軸あたり10ビット） で空間的にソートされ、これによりレンダラーでの後のキャッシュ局所性が 確保される。次に位置は対称ログ変換（より優れたダイナミックレンジの ため）により16ビット値に量子化され、2枚のRGBA画像に分割される （下位8ビット用のmeans_l.webp、上位用のmeans_u.webp）。回転は 3×8ビット＋2ビットモードを持つSmallest-Threeとして1枚のRGBA画像に エンコードされる（モードはアルファに252 + largestとして格納）。 スケールとDC-SHはそれぞれ256エントリのコードブックで量子化され （全値にわたるパーセンタイルベースの分布）、インデックスは scales.webpとsh0.webpに格納される。5枚の画像とコードブック・ 境界を含むmeta.jsonはZIPファイルにまとめられ（サンドボックスが システムのzipをブロックするためカスタムエンコーダを使用）、 拡張子.sogで保存される。

サンドボックス注意: SOGは外部バイナリを必要とする唯一の 形式オプションだ。WebPエンコーダ段階は/usr/local/bin/cwebpまたは /opt/homebrew/bin/cwebpからcwebpを呼び出す。cwebpバイナリが 見つからない場合、コードは生のPNGエンコードにフォールバックする — ただし：PNGフォールバックはSuperSplatでは動作しない。 App Store版では、ビルドバリアントに基づいて可用性を評価する。 Developer版ではHomebrew経由でcwebpをインストールする必要がある （brew install webp）。

場所

メニューバー → Export → 3D Formats → Export glTF…。 Simple Mode: 形式カード「glTF」。 サイズ: PLYと同程度。互換性: KHR_gaussian_splatting拡張（Khronosドラフト標準）を持つ glTFビューア。

技術詳細

KHR_gaussian_splatting拡張仕様に従って、自己完結型の .glbバイナリファイル（別途のbinファイル添付なし）を書き出す。 位置は通常のglTF POSITION頂点データ（float3）として保存され、 その他すべての属性（回転はfloat4、スケールはfloat3、不透明度はfloat、 SH係数はfloat3 × shCoeffCount）は追加の頂点属性として存在し、 拡張機能経由で参照される。重要な点：glTFは右手系Y-up座標系を 使用するが、COLMAP/3DGSはY-down/Z-forwardで動作する。そのため エクスポータはX軸周りの180度回転を適用する — 位置は(x, -y, -z) として書き換えられ、クォータニオンは(w, x, -y, -z)に調整される。 これによりglTFビューアにおいて幾何学的に正しく、手性の反転がない （鏡像でない）表現が得られる。JSONとバイナリチャンクはGLB規格の 要求通り4バイト境界にパディングされる。

場所

メニューバー → Export → 3D Formats → Export .splat…。 Simple Mode: 形式カード「.splat」。 サイズ: ガウスあたり正確に32バイト。互換性: gsplat.js、Webベースのビューア（antimatter15リファレンス）、 ほとんどのブラウザ3DGSデモ。

技術詳細

antimatter15の.splat形式 — ガウスあたり32バイト、 ヘッダーなし、間接参照なし。エントリごとのレイアウト：float32位置 ×3（ワールド座標）、float32スケール×3（内部バッファのログ空間から expで変換）、uint8 RGBAカラー×4（SH_C0 = 0.282...でスケールされ [0,255]にクランプされたDC-SH係数）、uint8クォータニオン×4 （w,x,y,z、正規化され128 + 128*qとしてバイト範囲にエンコード）。 DC-SHのみが保存される — より高次のSHバンドは破棄される。これに より形式は極めてコンパクトになるが、鏡面反射やスペキュラーハイライト で生じる視点依存の色変化は失われる。書き込み順序はクラウドのインデック ス順そのままであり（空間ソートなし）、gsplat.jsのようなWebビューア はこれを前提にレンダリングする。

場所

メニューバー → Export → Media → Export Web Viewer…。 Simple Mode: 形式カード「Web Viewer」。 サイズ: スプラットデータをbase64エンコード（約4/3の オーバーヘッド）＋約5 KBのHTML/JSシェル。互換性: WebGL2を持つあらゆるモダンブラウザ（全デスクトップ、iOS 15+、 Android 5+）。

技術詳細

ガウスクラウドを、完全にインライン記述されたWebGL2 レンダラーと共に単一の.htmlファイルにまとめる。CDN依存もWASMも 2つ目のファイルも存在しない。クラウドは内部でまず.splatバイナリ としてエンコードされ（E6と同じ32バイトロジック）、その後base64で 埋め込まれ、ブラウザ内でatobによりデコードされる。組み込みの レンダラーは独自のWebGL2ソート、マウスオービット操作、フレームごと のCPUソートを行う。JSコード全体（シェーダー、数学処理、ループ）は 出力HTML内で確認できる。ストレージ・レンダラー境界での軸規則は E5と完全に同一だ：位置(x, -y, -z)、クォータニオン (w, x, -y, -z)。オプションでブランディングオーバーレイを表示 できる（無料枠での切り替え）。すべてがインラインであるため、 このファイルはfile://プロトコルから直接動作する — テストの ためにローカルWebサーバーは不要だ。

場所

メニューバー → Viewport → Record Turntable Video または メニューバー → Export → Media → Export Orbit Video…。Simple Mode: 3～30秒の長さスライダー付き形式カード「Orbit Video」。 サイズ: 長さ・解像度・ビットレートに依存。 互換性: 全プラットフォーム（H.264とHEVCはApple標準）。

技術詳細

ガウスクラウドをパラメトリックなオービットカメラワーク に沿ってレンダリングし、各フレームをAVAssetWriter経由でMP4または MOVファイルにエンコードする。オービット設定は回転数（周回数）、 距離、仰角、FOV、長さ、イーズイン/アウト係数を制御する。Orbit Video のエクスポートはRadianceKit自身のレンダリングステージを使い、フル SH評価で行われる — アプリ内ビューポートとピクセル完全一致 （WYSIWYG）。フレームごとに、ワールド調整行列（レンダラーが計算し、 内部座標をY-upオービットワールドへ回転させるためのもの）がカメラと 乗算され、続いてカメラ変換用のミラーリング（Orbit Y-up → COLMAP Y-down）が適用される。オフスクリーンレンダーターゲットは IOSurface経由でエンコーダ用のCVPixelBufferに引き渡される。エンコーダ はH.264とHEVCをサポートし、ビットレートと解像度は480pから8Kまで 設定可能だ。最初のフレームの前に、レンダラーは初期スプラットソート が完了するまで200ms待機する。このエクスポートはGPUバウンドだ — 8Kかつ数百万ガウスの場合、フレームあたりのレンダリング時間は数秒に 及び、6秒の動画でも合計10～30分のレンダリング時間になりうる。

場所

メニューバー → Export → Photogrammetry → Export SfM (transforms.json)…。 サイズ: 標準1～10 KB（ポーズと内部パラメータのみ、 画像もガウスも含まない）。互換性: nerfstudio、Brush、 gsplat、OpenSplat、Meshroom、すべてのモダンなfeed-forward 3DGSトレーナー。

技術詳細

nerfstudioのtransforms.json形式を書き出す。これは 共有される内部パラメータを持つカメラポーズのリストだ。カメラごとに、 ビュー行列（RadianceKit内部：COLMAP規約でのWorld-to-Camera）が 反転され、続いてカメラローカルのY軸・Z軸基底ベクトルが反転され、 nerfstudio規約（OpenGLスタイル、カメラは-Z方向を向き、+Yが上） に変換される。最終的な4×4行列は、各フレームのtransform_matrix フィールドにdoubleのrow-majorネスト配列として格納される。内部 パラメータはトップレベルに保存される（焦点距離x/y、主点x/y、画像 幅/高さ、camera_model = "OPENCV"、加えて歪み係数k1, k2, p1, p2） — ただしエクスポータが複数の異なる内部パラメータセットを検出した 場合は、フレームごとに書き出される。画像パスはJSONファイルからの 相対パスimages/<filename>として書き出される。ユーザーはトレーニング 写真を含む兄弟フォルダimages/を用意する必要がある。

場所

メニューバー → Export → Photogrammetry → Export SfM (COLMAP Workspace)…。 サイズ: 3つのバイナリファイル合計で標準4～8 MB — points3D.binが支配的（スパースクラウドの3D点1つにつき1行）、 images.binとcameras.binはそれぞれ100 KB未満。 互換性: COLMAP自体、Nerfstudio、Postshot、Meshroom、 COLMAPのsparse/ディレクトリを想定するすべてのツール。

技術詳細

標準的なCOLMAPのsparse/0/レイアウトを、3つのバイナリ ファイル（cameras.bin、images.bin、points3D.bin）で書き出す。 形式のリファレンスは公式COLMAPドキュメントだ。cameras.binには 重複除去された内部パラメータリストが含まれる（同一の内部パラメータ と画像サイズを持つカメラは1つのエントリにまとめられる）。使用される カメラモデルはOPENCV（モデル4）で、fx/fy/cx/cyと4つの歪み係数 k1/k2/p1/p2を持つ。images.binは画像ごとにポーズ（wxyzクォータ ニオン＋並進）、続いてカメラIDとファイル名をリストする。2D-3D対応 関係は保存されない。points3D.binにはSfM点群が含まれ、位置、色 （0-255 RGB）、再投影とトラック長のデフォルト値を持つ。すべて リトルエンディアンで書き出される。RadianceKitへの再インポートは ファイルメニュー→「Import COLMAP/Metashape Workspace…」経由で行える （SfMバックエンドの章のQ3を参照）。