PortalCamの生データ(.xbin)
から4K元画像を取り出す

01 なぜ生データから元画像を取り出すのか

PortalCamのスキャンをLCC Studioで書き出すと、3DGSと点群、それにLiDARメッシュが出てきます。ここまでで映像制作にはほぼ困りませんが、現場を歩いたときのカメラそのものの4K画像が別に欲しい場面があります。3DGSからは作れない使いどころが2つあります。

• AIの参照素材として使う ── 3DGSのレンダリング画像より、実写の4K画像のほうが背景修正・生成AIの参照精度が上がります。
• 別のパイプラインでの3D再構成を試す ── フォトグラメトリなど、3DGS以外の手法にも同じ現場データを流用できないか検証できます（この記事の後半で、実際に試した結果を正直に書きます）。

PortalCamのLCC StudioにもGUIから画像を書き出す機能はありますが、この記事ではGUIを開かず、CLIツールだけで完結する方法を使います。バッチ処理や自動化に組み込みやすいためです。

02 PortalCamのスキャン成果物の中身

抽出の前に、PortalCamが1回のスキャンで作るフォルダの中身を把握しておきます。ShotData/<スキャン名>/ 配下は、だいたい次のような構成になっています。

ShotData/<スキャン名>/
├─ 2026-XX-XX-XXXXXX.xbin        # 生センサー記録（画像＋LiDAR＋IMU＋GNSS）
├─ ply/ply-result/                # 3DGS本体
├─ Lcc2/lcc2-result/              # LCC2書き出し（3DGS＋メッシュ）
├─ mesh-files/<スキャン名>.obj    # LiDARメッシュ（粗い）
└─ project_data/                  # 移動軌跡・カメラ構成などのログ

この中で今回使うのは、いちばん重いファイルである.xbinだけです。ファイルサイズは撮影時間に比例し、数分のスキャンで1GB前後になります。

03 xBinの正体：JPEGではなくH.264動画

.xbinを実際に解析すると、正体はXBAG形式という「センサーデータをまとめて詰め込んだ入れ物」でした。カメラ映像・LiDAR点群・IMU・GNSSが時系列で1本のファイルに混在しています。

自前で動画部分を取り出してffmpegに渡す方法もありますが、ファイル構造を正しく辿る実装が要るため手間がかかります。次の章で使うXGRIDS純正のCLIツールなら、この工程を意識せずに済みます。

04 4K元画像を抽出するコマンド

使うツールは、LixelStudioに同梱されているextract_images_h264.exeです。LCC StudioやLixel Studioを起動する必要はなく、コマンド1行で完結します。

"C:\Program Files (x86)\LixelStudio\extract_images_h264.exe" ^
  --hbc_path <xbinのパス> --out_dir <出力先> ^
  --out_fps 5 --prj_version 1 --device_type 4 --use_blur_detect 1

--device_typeは撮影機材を指定するフラグですが、PortalCamは選択肢の一覧に載っていません。実際に試した結果、次の値が正解でした。

この2つのフラグさえ合わせれば、あとは指定した出力先にカメラごとのフォルダができ、4Kクラスの魚眼JPEGがタイムスタンプ付きファイル名で並びます。なお出力フレームレートの指定は実質効かず、元データの全フレームがそのまま出力されます。

05 4カメラのうち2台しか出せない制約

PortalCamは左右にメインとサブ、合わせて4眼を積んでいます。.xbinの中にも、この4本分の定義が入っています。

ところがextract_images_h264.exeが実際にデコードするのは左右のメイン2本だけです。サブ側を出力する方法は今のところ見つかっていません。

幸い、出てくる2本は同時刻に記録された同期ステレオペアになっているので、視差情報そのものは確保できています。

06 検証：抽出画像からのフォトグラメトリは全滅

ここからは条件付きの結論です。「4K元画像が取れるなら、フォトグラメトリでメッシュも作れるのでは」と考え、会議室のスキャンで実際に試しましたが、現時点ではこの道は塞がっています。

本質的な原因は撮り方の違いです。歩きながら点在して撮った程度の枚数では、特徴点マッチングが成立しません。PortalCamは歩きながら連続的に3DGS用のデータを集める設計であり、フォトグラメトリが前提とする「1点にとどまって、写真どうしの重なりを大きく取りながら撮る」撮り方とは根本的に噛み合いません。加えて、検証した会議室は無地の壁が多く、手がかりになる特徴点自体が少ない現場でした。魚眼から透視投影への変換自体は問題なく機能しており、詰まっているのはあくまで再構成側です。

07 使いどころとまとめ

この記事の流れをまとめると、PortalCamの生データ(.xbin)はXBAG形式のH.264動画で、extract_images_h264.exeに--prj_version 1と--device_type 4を指定すれば4K元画像を抽出できる、という一本道です。ただし4眼のうち出せるのは2眼のみで、抽出画像そのものからのフォトグラメトリ再構成は現状うまくいっていません。

いちばん実用的な使いどころは、AIの参照素材です。抽出した連番フレームは現場の実写そのものなので、Nano Banana ProやGeminiで背景の破綻を修正するときの参照や、動画生成AIにロケーションを指定するときの参照として強力に効きます。実際のAI活用ワークフローは3DGSから「空撮カット」を生成する方法で詳しく解説しているので、あわせて参照してください。

生データの取り扱いや3DGS制作についてご相談があれば、お気軽にお問い合わせください。