.png)
.png)
.png)
When a question appeared in SHARE3DCAM's Discord community — "Can I use SHARE3DCAM scan data in COLMAP?" — the answer wasn't a product feature. It was a user who took the initiative, used SHARE3DCAM open raw data and community technical support to build a practical solution to their own workflow problem.
Meet AVsupport (Peter Graf), a SHARE C1 user and early backer of the SHARE3DCAM Kickstarter campaign. Over ten weeks, Peter went from identifying a workflow gap to becoming the primary author of pose2colmap.py — a Python script that converts SHARE3DCAM pose export data into standard formats for COLMAP and RealityCapture.
Peter's story is worth telling on its own terms. But it also points to something broader: when scan data isn't locked behind proprietary walls, the people who use the equipment every day can roll up their sleeves and improve their own workflows. From a Kickstarter backer with a question, to a working format conversion tool — that arc says more about open data than any product page ever could.
The core value of this case is clear: SHARE3DCAM is not only about delivering point clouds, 3DGS models, or CAD outputs. It is also about giving professional users a data foundation they can connect with their own photogrammetry, reconstruction, and development workflows.
Why Open Data Matters Here
Before getting into the details, it's worth understanding the industry backdrop — because it's what made Peter's approach possible.
The Default: Raw Sensor Data Is Usually Inaccessible
In handheld LiDAR scanning and spatial data capture, one persistent reality shapes what users can and can't do: what users typically receive is the manufacturer's processed output — colorized point clouds, meshes, reports — not the raw sensor data captured during the scan. Raw LiDAR frames, IMU inertial streams, camera image sequences, calibration parameter files — on most platforms, these remain locked inside proprietary processing pipelines, inaccessible for direct access or export.
This isn't unique to any one manufacturer. It's the industry's operating default. For manufacturers, locking data controls product quality, ties users to the software ecosystem, and simplifies technical support. But for users, it means one thing: beyond the boundaries of vendor-provided functionality, you cannot explore, reprocess, or integrate your own data.
A typical example: you want to feed your scanner's raw data into COLMAP for dense reconstruction, or optimize the trajectory with a custom algorithm, or reprocess archived data five years later with a new technique. On most platforms, these things are either technically impossible without the vendor's software environment, or require additional commercial licensing and proprietary tooling. Not because the data doesn't exist — but because you can't get to it.
How SHARE3DCAM Handles Data
SHARE3DCAM takes a different approach. Through SHARE PointClouds Studio, users receive professional-grade deliverables: dense colorized point clouds, 3DGS/Gaussian Splatting models, and CAD drawing exports. These are the finished outputs most projects need.
Alongside those results, SHARE3DCAM also provides access to raw data packages behind the processed outputs. From the entry-level SHARE C1 to the professional S100 series, the device workflow is designed not only for finished deliverables, but also for preserving the underlying sensor data that can support later verification, reprocessing, and third-party tool integration.
What follows is the content of a single-mission SHARE3DCAM data delivery:
Raw Capture Data Package
| Data Item | Description |
|---|---|
| **ROSBAG (*.bag)** | Core raw data container. Holds LiDAR point cloud frames, IMU inertial data, camera image frames, and timestamps — the foundation for high-precision trajectory optimization, spatiotemporal synchronization, and model recomputation |
| frame_pose.txt | Per-frame LiDAR position and attitude, ordered by timestamp. Usable for trajectory visualization, extrinsic correlation, and registration verification |
| ROVER_PPKRAW.bin | Raw GNSS satellite observations. Combined with base station data, enables PPK post-processing for improved absolute trajectory accuracy |
| info/ | Camera intrinsic parameters, LiDAR/IMU sensor calibration data, and extrinsic transformation matrices between sensors |
| pointcloud.pcd | Preview point cloud for rapid assessment of scan coverage and completeness |
| project_info.json | Structured metadata: device model, project name, capture time, task attributes |
| control_points_photos/ | On-site GCP reference photographs |
| log/ | Complete operation log: task start/end, capture status, anomalies and errors |
Undistorted Image Data Package (Post-Processing Output via SHARE PointClouds Studio)
| Data Item | Description |
|---|---|
| left / right | Lens-distortion-corrected image sequences from left and right cameras |
| left_mask / right_mask | Pixel validity masks |
| ImgPose.txt | Per-image position, roll/pitch/yaw, quaternion, and timestamp — designed for programmatic parsing and sensor fusion |
| xyzopk.txt | Camera pose expressed as Omega/Phi/Kappa — compatible with traditional photogrammetry software interfaces |
| TransformedCam.json | Structured per-image intrinsic and extrinsic parameters |
| **\\\\\\\\_undistort.opt / \\\\\\\\_undistort_intrinsic.txt** | Post-undistortion camera model, focal length, principal point, and distortion parameters |
What Having the Raw Data Enables
When raw data is available in open formats, three things become possible:
- Freedom to build. Process the data with any programming language and algorithm framework. COLMAP, Open3D, OpenCV, custom Python scripts — no format barriers.
- Workflow autonomy. No lock-in to a single software ecosystem. SHARE PointClouds Studio is the recommended starting point, not the mandatory destination. Data can move into COLMAP, RealityCapture, Metashape, CloudCompare, AutoCAD, Revit, or other trusted professional tools.
- Future-proof archives. Data stored in open formats. Five years from now, when a new algorithm emerges or a project needs reprocessing, project teams still have a path to re-validate, reconstruct, or extend the workflow from the original data.
This is the environment Peter was working in: open data was not an abstract slogan, but the condition that allowed him to start from SHARE C1 project data, test ideas, convert formats, and validate a real workflow.
The Problem Peter Saw
SHARE3DCAM scanners can capture high-quality 3D data. SHARE PointClouds Studio processes that data into professional outputs such as point clouds, 3DGS models, and CAD exports. But many professional users — surveyors, architects, heritage documentation specialists — also need to feed data into established photogrammetry pipelines like COLMAP or RealityCapture for tasks such as dense mesh reconstruction, multi-sensor fusion, or integration with existing professional workflows.
The challenge: SHARE3DCAM's pose output format used camera models and coordinate conventions that didn't map cleanly onto standard photogrammetry formats.
For most users on most platforms, this is where the story would end — with a support ticket and a wait. But because the raw data was open, Peter could access calibration parameters, sensor extrinsics, and per-frame poses directly. What would normally be a vendor feature request became a solvable engineering problem.
He saw the gap. And closed it.
Ten Weeks, Four Development Phases: How Peter Built It
Peter developed pose2colmap.py as an independent open-source project, drawing on SHARE3DCAM's open data, public documentation, and community resources. The development was iterative and public — playing out in SHARE3DCAM's Discord channels from mid-April to late June, progressing from early versions to v1.12.
Phase 1: Foundational Architecture (mid-April to mid-May)
- Dual-camera support (Left + Right stereo baseline, ~79.4mm along X-axis)
- Automatic folder discovery from SHARE PointClouds Studio exports
- Multiple viewer conventions (RealityCapture 2, LichtFeld Studio, PostShot)
- Fisheye camera model mapping (SHARE3DCAM POLYFISHEYE → COLMAP OPENCV_FISHEYE — work-in-progress; no trivial conversion exists, interim estimated bridges in place)
- Camera and point cloud transform decoupling (independent --camera-pitch/yaw/roll controls)
Phase 2: The Chirality Problem (mid-May to late May) — the most technically demanding phase
The rotation matrices in TransformedCam.json had a determinant of -1 (left-handed coordinate system), while COLMAP requires +1 (right-handed). The mismatch caused cameras to "explode" upon import.
Peter's initial attempt — detecting the determinant and negating a rotation matrix column — destroyed the rotation itself. The real breakthrough came from a mathematical insight: expanding the camera center formula C = -R_colmap^T @ t_colmap revealed that the rotation and position transforms could be fully decoupled, simplifying to C = S_pos @ t_slam. This meant camera orientation (for chirality correction) and position (for world-coordinate alignment) could be controlled independently — solving two contradictory requirements simultaneously.
Building on this breakthrough, further iterations confirmed the final yaw+90° orientation correction. Every version was validated against real scan data in public Discord channels.
Phase 3: Calibration Precision (late May to early June)
- Metashape XML calibration support (EquisolidFisheye → OPENCV_FISHEYE conversion, work-in-progress)
- POLYFISHEYE → Kannala-Brandt curve-fitting fallback
- Multiple rounds of distortion coefficient sign convention tuning (k1-k4 negation strategy)
- C1 camera hardcoded reference calibration values
Phase 4: Productionization (June)
- Cross-platform compatibility fixes
--upscaleflag for SHARE PointClouds Studio image upsampling during undistortion- RS2 trailing newline format fixes (RS2 has since received updates addressing these issues through this process)
- Non-fisheye mode crash fix, comprehensive error handling
What Is pose2colmap.py?
pose2colmap.py is an independent open-source Python command-line tool, developed and maintained by Peter Graf. Its core function is converting SHARE3DCAM handheld scanner pose export data into standard formats that can be read by photogrammetry software like COLMAP and RealityCapture. Current version: v1.12, approximately 2,300 lines of code.
Key capabilities:
- Auto-discovers and reads pose files, images, and calibration parameters from SHARE PointClouds Studio export directories
- Maps SHARE3DCAM's POLYFISHEYE camera model to COLMAP's OPENCV_FISHEYE model
- Supports dual-camera stereo baselines (Left + Right) with automatic chirality correction
- Outputs COLMAP format with different conventions to suit RS2 (RealityCapture 2) and PS/LichtFeld Studio workflows, using the same underlying images.txt / cameras.txt / points3D.txt structure
- Compatible with multiple viewer conventions including RS2 (RealityCapture 2) and LichtFeld Studio
- Provides
--upscaleflag to match SHARE PointClouds Studio image upsampling during undistortion
Who it's for:
- Users who need to import SHARE3DCAM scan data into COLMAP for dense point cloud reconstruction or mesh generation
- Survey and engineering teams using RealityCapture for high-precision photogrammetry processing
- Researchers and developers building custom algorithms on top of SHARE3DCAM raw data
- Professional users with existing Metashape calibration data seeking higher-accuracy pose conversion
A note on the fisheye challenge: using ultra-wide fisheye images directly in 3D reconstruction without undistortion remains a technically challenging area, because undistortion can introduce image quality loss and field-of-view reduction. LichtFeld Studio is among those exploring this direction. In the interim, pose2colmap.py provides a practical bridge: when Metashape calibration data (EquisolidFisheye) is available, the script can use it to connect SHARE3DCAM's native Polyfisheye format to COLMAP-supported fisheye models, enabling testing and workflow development that would otherwise be blocked.
Where to get it:
pose2colmap.py is hosted on GitHub at github.com/grafpez/pose2colmap. Documentation, command-line usage guides, and version history are maintained in the SHARE3DCAM Official Discord Community.
What SHARE3DCAM Provided
Peter built pose2colmap.py — the code, architecture decisions, real-world testing, and feature direction were all his. No SHARE3DCAM engineers wrote the script.
SHARE3DCAM's role was providing the conditions that allowed this work to happen and keep moving:
- Open Raw Data — Raw data packages such as ROSBAG, IMU, calibration parameters, and pose data can be accessed and parsed, reducing the friction created by encrypted or proprietary-format barriers.
- SHARE3DCAM Bot — An AI assistant powered by OpenClaw, equipped with a product knowledge base, integrated directly into the Discord community. Peter used it as a real-time technical reference throughout the project.
- Knowledge Base — Internal documentation, calibration models, and technical specifications shared with the community.
- Community Space — Discord channels for public iteration, testing, and feedback.
What This Took
Peter had the skills, the initiative, and ten weeks. He also had a key condition: direct access to the raw data behind the project.
When sensor streams, calibration parameters, and per-frame poses are available in open formats, someone with the right expertise can identify a gap, prototype a solution, and validate it against real data — without starting from reverse-engineering undocumented formats. That's what happened here: a practical attempt by a user to improve their own workflow, using SHARE3DCAM open raw data and community technical support.
If you work with scan data every day and see something that could work better — the raw data is there. The Bot is there. The community is there. What Peter did isn't reserved for one person.
SHARE3DCAM Data Delivery vs. Common Industry Practice
| Dimension | Common Industry Practice | SHARE3DCAM |
|---|---|---|
| Raw sensor data (LiDAR frames / IMU / camera) | Often packaged inside proprietary pipelines; direct access can be difficult | ROSBAG + text formats, supporting raw data delivery |
| Camera / IMU calibration parameters | Often not part of standard user-facing delivery | Provided in the info/ directory for parsing and validation |
| GNSS raw observations | May not be exportable or may require additional workflow steps | ROVER_PPKRAW.bin can be included as part of the project data package |
| Third-party tool integration | Often depends on vendor-supported formats or authorized integrations | Easier access to workflows such as COLMAP, RealityCapture, Open3D, and related tools |
| Community development | Generally outside the scope of standard vendor support | Supported through open data, AI assistant, and community channels |
What's Next
pose2colmap.py is available to the SHARE3DCAM community and beyond. If you're working with COLMAP, RealityCapture, or any photogrammetry pipeline, this tool bridges the gap.
Peter also shared SuperSplat model previews generated through this workflow, so community members can inspect the results directly:
If you're building on SHARE3DCAM's open data — or just want to see what other users are doing with theirs — join the SHARE3DCAM Official Discord Community. From calibration parameter deep-dives, to COLMAP integration questions, to the next community tool idea — this is where the conversation happens.
Development Behind-the-scenes: AVsupport interacts with the SHARE3DCAM bot in the official community
pose2colmap.py is developed and maintained by Peter Graf as an independent open-source project. SHARE3DCAM provided open raw data, the Bot, knowledge base, and collaborative space that supported the development. Special thanks to Peter and the broader SHARE3DCAM Discord community for testing, feedback, and technical discussion.
