Extracting 4K Source Images
from PortalCam's Raw Data (.xbin)

01 Why extract source images from raw data

Exporting a PortalCam scan through LCC Studio gives you 3DGS, a point cloud, and a LiDAR mesh. That covers most of what you need for video production, but there are cases where you separately want the 4K images from the camera itself, as captured while walking the site. There are two use cases 3DGS alone can't cover.

• Using them as AI reference material — real 4K photographic images give noticeably better precision than a 3DGS render when used as reference for background fixes or generative AI.
• Trying 3D reconstruction through a different pipeline — it's worth checking whether the same field-captured data can be reused for methods other than 3DGS, such as photogrammetry (later in this article, we'll be honest about what we found when we actually tried this).

PortalCam's LCC Studio does have a GUI feature for exporting images, but this article uses a method that never opens the GUI and works entirely through CLI tools, since that's easier to fold into batch processing and automation.

02 What's inside a PortalCam scan's output

Before extraction, it helps to know what's inside the folder PortalCam creates for a single scan. Under ShotData/<scan name>/, the layout roughly looks like this.

ShotData/<scan name>/
├─ 2026-XX-XX-XXXXXX.xbin        # Raw sensor recording (images + LiDAR + IMU + GNSS)
├─ ply/ply-result/
│  ├─ point_cloud/iteration_100/point_cloud.ply   # The 3DGS itself
│  └─ cameras.json                # Dummy (only the startup.jpg entry — unusable)
├─ Lcc2/lcc2-result/              # LCC2 export (3dgs/*.sog + mesh/*.ply + info/poses.json)
├─ mesh-files/<scan name>.obj    # LiDAR mesh (coarse — tens of thousands of vertices, triangles ~20cm)
└─ project_data/
   ├─ poses.csv                  # Trajectory (ts,x,y,z,qx,qy,qz,qw)
   └─ log/project.json           # DeviceInfo.CameraList shows the camera configuration

The only thing we use here is .xbin — the heaviest file in the set. Its size scales with recording time; a scan of a few minutes lands around 1GB.

03 What xBin actually is: H.264 video, not JPEG

Running a binary analysis on .xbin reveals its real identity: an XBAG-format container (magic number "XBAG"), a "multiplexed sensor data" container similar in spirit to a ROS bag. Camera footage, LiDAR point clouds, IMU, and GNSS are all interleaved in a single file in time order.

You could demux the H.264 stream yourself and hand it to ffmpeg, but that requires correctly walking the XBAG record boundaries, which is a fair amount of work. The XGRIDS-native CLI tool covered in the next section lets you skip worrying about that step entirely.

04 The command to extract 4K source images

The tool used here is extract_images_h264.exe, bundled with LixelStudio. There's no need to launch LCC Studio or Lixel Studio — it's a single command line.

"C:\Program Files (x86)\LixelStudio\extract_images_h264.exe" ^
  --hbc_path <path to .xbin> --out_dir <output directory> ^
  --out_fps 5 --prj_version 1 --device_type 4 --use_blur_detect 1

--device_type specifies the capture device, but PortalCam isn't listed among the documented options. After actually testing it, here's what worked.

Get just these two flags right, and images/camera_0/ and images/camera_1/ appear under your --out_dir, filled with 4000×3000 (12-megapixel) fisheye JPEGs named by timestamp. Note that --out_fps effectively has no effect — every frame from the source data is output regardless.

05 The constraint: only 2 of the 4 cameras come out

PortalCam's camera configuration can be checked in project_data/log/project.json under DeviceInfo.CameraList, and it's a 4-lens setup: left_main / left_seco / right_main / right_seco. Definitions for all four channels exist inside the .xbin header's binary structure as well.

In practice, though, extract_images_h264.exe only decodes left_main and right_main — two streams. We haven't yet found a way to output the seco side.

Fortunately, camera_0 and camera_1 form a synchronized stereo pair with 0ms timestamp difference, so parallax information itself is preserved.

06 Testing it: photogrammetry from the extracted images fails across the board

From here on, the conclusion comes with caveats. We wondered whether, if 4K source images could be pulled out, photogrammetry could also build a mesh from them — and tested it on a conference-room scan (82 capture points × 2 lenses = 163 images). At this point, this route is a dead end.