OPX Technical Documentation

Current development status

OPX is currently documented around the verified v0.5.0 release state. The release was merged into the main branch, tagged as v0.5.0, built, installed, packaged and validated successfully.

Design principles

OPX is promoted as an open format, not as a proprietary product suite. The website should therefore focus on the format, the reference SDK, validation tooling, the free viewer concept and the converter. Future domain-specific applications can be built on top of OPX by anyone, but they are not part of the public format positioning.

• Vendor-neutral exchange and working container.
• Spatially indexed access for large reality capture projects.
• Preservation of project context: coordinates, metadata, imagery, vectors, survey control and model references.
• Reference tools that demonstrate interoperability without locking users into a software suite.

Container structure

The OPX container is organized as a versioned block structure. The implementation is intended to support required blocks, optional blocks and forward-compatible extension blocks.

OPX Container
├─ Superblock / format header
├─ Root directory
├─ Spatial index
├─ Point cloud tiles
├─ Image and raster blocks
├─ GIS vector blocks
├─ Survey control and metadata blocks
├─ Model / BIM references
└─ Extension and compatibility blocks

Data model

The public data model describes OPX as a project-level container. It is intended to hold multiple capture and context layers together instead of treating point clouds, vectors, images and metadata as disconnected files.

• Point cloud tiles with attributes such as color, intensity, classification and time where available.
• Spatial indexes for bounding-box queries, lazy loading and future streaming scenarios.
• Image and raster blocks for panoramas, orthophotos, maps and visual context.
• Vector blocks for geospatial project layers.
• Survey control information for reproducibility and quality assessment.

Coordinates & CRS

OPX keeps coordinate reference information as first-class project metadata. The format is intended to support survey-grade coordinate precision, georeferenced projects and explicit documentation of coordinate systems, transformations and related metadata.

Point clouds

Point cloud content is represented through spatially addressable tiles and attributes. The current implementation focuses on robust import/export workflows and validated container behavior rather than application-specific editing tools.

Images and rasters

OPX can document image and raster concepts such as panoramas, perspective images, orthophotos, overview maps and georeferenced imagery. These blocks provide visual context for viewer and downstream application workflows.

GIS vector layers

Vector layers are used for geospatial context such as lines, polygons, multipolygons, labels and attributes. This allows an OPX project to carry GIS context alongside point clouds and survey data.

IFC / BIM context

OPX can act as a project container around model data and model references. IFC/BIM support should be documented as interoperability context for design-versus-reality and digital twin workflows, not as a separate proprietary application.

Survey control

Survey control information may include control points, checkpoints, scan setups, observations, residuals, covariance-related metadata and accuracy information. This keeps georeferencing and quality information close to the captured data.

Metadata

Metadata is central to OPX. The documentation should describe project-level metadata, acquisition metadata, block metadata, coordinate metadata, processing metadata and compatibility flags in a way that supports long-term reuse and validation.

Interoperability

The current release state includes validated progress around E57 interoperability and existing point cloud workflows. LAS import/export remains an important reference pathway for adoption, while E57 support is a key milestone for scanner and registration software ecosystems.

• LAS/LAZ-oriented workflows through import/export tooling.
• E57 interoperability validated in the optional fixture build.
• CMake options keep optional dependencies separated from the default core build.
• Compatibility behavior should preserve unknown optional blocks where possible.

OPX Converter

The OPX Converter should be presented publicly as a reference tool for moving existing datasets into and out of OPX. It is part of the format adoption strategy, not a domain-specific end-user suite.

OPX Viewer (Reference Viewer)

The free OPX Viewer (Reference Viewer) should be positioned as the visual reference entry point for the format. Its role is to open OPX files, inspect structure, visualize layers and demonstrate interoperability. It should not be marketed as a full commercial application suite.

SDK & CLI

The reference implementation is C++20 and CMake-based. It should remain easy to build, test, install and package.

cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release
ctest --test-dir build --output-on-failure
cmake --install build --prefix install

Validation and release checks

The documented v0.5.0 state is based on completed build, test, release-check, install and package validation. This should be reflected consistently across the website so visitors see one clear current release state.

Known limits and positioning

OPX is still evolving. Public communication should be precise: the open format, reference implementation, viewer concept and converter are the focus. Domain applications such as registration, survey extraction, facility workflows or room-book systems may be possible future use cases, but they should not be advertised as OPX products on the public format website.