Point Cloud File Formats

When a 3D laser scanner captures a building, structure, or site, the resulting point cloud — millions or billions of XYZ coordinate measurements — needs to be stored in a file. The file format you choose determines how that data is structured, what metadata is preserved, which software can read it, and how efficiently it can be stored and transferred.

Choosing the wrong format can lead to vendor lock-in, where your data can only be opened in one manufacturer's software. It can mean losing critical metadata like scanner position, intensity values, or color information during export. And it can result in unnecessarily large files that slow down processing and consume storage.

The point cloud industry has converged on a handful of dominant formats, each designed for specific use cases. E57 serves as the universal exchange and archival standard. LAS/LAZ dominates geospatial and aerial LiDAR workflows. RCP/RCS is optimized for the Autodesk ecosystem. And legacy formats like PTS, PTX, PLY, and XYZ persist in specialized niches.

The Interoperability Challenge

A typical scanning project involves multiple software tools — the scanner's native software for capture, a registration tool for aligning scans, a processing application for cleaning and colorizing, and a downstream platform like Revit, AutoCAD, or a GIS system for final use. Each software tool has its own preferred format, creating a chain of imports and exports where data fidelity is at risk.

Understanding the strengths and limitations of each format enables you to plan a data management strategy that preserves accuracy, avoids unnecessary conversions, and ensures your point cloud data remains accessible for the life of the project and beyond.

E57 is an open, vendor-neutral file format for storing 3D imaging data, defined by the ASTM E2807 standard (originally published 2011, reapproved 2019). Developed under the ASTM E57 Committee on 3D Imaging Systems, E57 was specifically designed to be a universal exchange format that could handle the diverse outputs of laser scanners, structured light systems, and other 3D capture devices without vendor lock-in.

File Structure

E57 uses a hybrid XML/binary architecture. The file contains an XML metadata section that describes the structure, coordinate systems, sensor information, and data organization, alongside binary data sections that store the actual point coordinates, colors, and intensity values efficiently. This design gives E57 two critical advantages: human-readable metadata (XML) and compact data storage (binary).

• XML Section: Contains file header, data structure definitions, coordinate reference systems, sensor positions, image references, and custom metadata fields
• Binary Section: Stores point data (XYZ, RGB, intensity, return number) in compressed binary format with configurable precision
• Image Data: E57 can embed 2D imagery (photos from the scanner) alongside point data, linking visual reference to spatial measurements

Key Characteristics

Software Compatibility

E57 is supported by virtually every professional point cloud application: Autodesk ReCap, Leica Cyclone, Trimble RealWorks, FARO SCENE, Bentley PointTools, CloudCompare, and dozens more. It is the most universally accepted exchange format in the 3D scanning industry. The open-source libE57 reference implementation ensures consistent read/write behavior across software platforms.

LAS (LASer) is the binary file format maintained by the American Society for Photogrammetry and Remote Sensing (ASPRS) for exchanging LiDAR point cloud data. First published in 2003 and now at version 1.4 (Revision 16), LAS is the dominant format for aerial LiDAR, topographic surveys, and geospatial applications. LAZ is the lossless compressed variant developed by Martin Isenburg using the LASzip algorithm.

LAS File Structure

A LAS file is a structured binary file with three main components:

• Public Header Block: Contains file metadata — version, point count, coordinate system (scale/offset), bounding box, creation date, and generating software
• Variable Length Records (VLRs): Extensible metadata fields for coordinate reference system definitions (WKT or GeoKeys), classification lookup tables, waveform descriptors, and custom application data
• Point Data Records: The actual point measurements in one of 11 defined record formats (0-10), each with different attribute combinations

Point Record Formats

LAS 1.4 defines point record formats 0 through 10, each storing different combinations of attributes:

Classification Codes

One of LAS's most powerful features is its classification system. LAS 1.4 supports 256 classification codes (8-bit, up from 32 in LAS 1.2), with ASPRS-defined standard codes including:

• Code 2: Ground — bare-earth terrain points
• Code 3-5: Low, medium, and high vegetation
• Code 6: Buildings — roof and wall surfaces
• Code 7: Low noise — outlier points below ground surface
• Code 9: Water — surface water bodies
• Code 17: Bridge decks — overpass structures
• Codes 19-63: Reserved for ASPRS future definition
• Codes 64-255: User-defined for custom classification schemes

LAZ Compression

LAZ is the lossless compressed version of LAS, using the LASzip algorithm developed by Martin Isenburg. LAZ is fully lossless — decompressing a LAZ file reproduces the original LAS file bit-for-bit. Compression ratios depend on data characteristics:

For a practical example: a 10 GB aerial LiDAR LAS dataset typically compresses to 700 MB - 1 GB as LAZ (90-93% reduction). Terrestrial scan data with more attribute variation compresses to 15-20% of original size (80-85% reduction). The difference in compression efficiency stems from aerial data's higher spatial redundancy — points on flat terrain compress more efficiently than complex interior building scans.

RCP (ReCap Project) and RCS (ReCap Scan) are Autodesk's proprietary point cloud formats, designed for use within the Autodesk ecosystem — ReCap Pro, Revit, AutoCAD, Navisworks, Civil 3D, and InfraWorks. These formats use spatial indexing (octree structures) to enable fast rendering and navigation of billion-point datasets directly inside Autodesk design tools.

RCP vs. RCS: How They Work Together

The relationship between RCP and RCS is a project-file-to-data-file architecture:

• RCS (Scan File): Contains the actual point cloud data for a single scan or unified cloud — binary point coordinates, color, intensity, normals, and spatial index. RCS files are typically large (hundreds of MB to several GB per scan).
• RCP (Project File): A lightweight container (typically KB to low MB) that references one or more RCS files. The RCP stores registration information, scan groupings, coordinate system settings, and visualization preferences. It does not contain point data itself.

When you import an RCP file into Revit, Revit reads the project metadata and loads the referenced RCS scan files as needed. This architecture allows Revit to handle multi-scan projects (50-200+ scans) by loading and unloading individual RCS files based on the current viewport, keeping memory usage manageable.

Spatial Indexing

The key technical advantage of RCP/RCS is spatial indexing. During import into ReCap, point cloud data is restructured into an octree — a hierarchical spatial data structure that subdivides 3D space into nested cubes. This indexing enables:

• Level-of-detail rendering: Only points visible in the current viewport are loaded, enabling smooth navigation of billion-point clouds
• Rapid spatial queries: Selecting or clipping regions of the cloud is nearly instantaneous
• Memory management: Points are streamed from disk as needed rather than loaded entirely into RAM

Creating RCP/RCS Files

RCP/RCS files are created through Autodesk ReCap Pro by importing source point cloud data in formats like E57, LAS, PTS, PTX, or XYZ. During import, ReCap registers scans, applies transformations, and builds the spatial index. The resulting RCP/RCS files are optimized for performance in Autodesk products but cannot be opened by most non-Autodesk software (CloudCompare is a notable exception with limited RCS read support).

XYZ is the simplest possible point cloud format — a plain ASCII text file where each line represents one point. The minimum content is three space-delimited or comma-delimited numbers representing the X, Y, and Z coordinates. Additional columns can include RGB color values (0-255), intensity, and normal vectors.

File Structure

A typical XYZ file looks like this:

There is no formal specification for XYZ — it is a convention rather than a standard. Different software tools may expect different column orders, delimiters (space, tab, comma), or header rows. This lack of standardization is both XYZ's greatest strength (universal readability) and its greatest weakness (ambiguity).

File size warning: Because XYZ stores every number as human-readable ASCII text, files are dramatically larger than binary equivalents. A point cloud that occupies 1 GB as an E57 file may require 3-5 GB as an XYZ file. For projects with billions of points, this size difference makes XYZ impractical for storage or transfer.

PLY (Polygon File Format, also known as Stanford Triangle Format) was developed at Stanford University in the mid-1990s for storing 3D data from digitized objects. Originally designed for triangle meshes from 3D scanning research, PLY has become widely used in computer graphics, 3D printing, and academic point cloud research.

File Structure

PLY files begin with a human-readable ASCII header that declares the data structure, followed by either ASCII or binary data. The header explicitly defines which properties each element (vertex, face) carries, making PLY highly flexible:

PLY's strength is its flexible property system. You can define any combination of per-vertex attributes — coordinates, colors, normals, confidence values, temperature, or custom fields. This makes PLY particularly popular in research environments where non-standard data attributes need to be stored alongside geometry.

ASCII vs. Binary Variants

• ASCII PLY: Human-readable, easy to inspect and debug, but 3-5x larger than binary. Used for small datasets, testing, and interoperability.
• Binary PLY: Compact and fast to read/write. Available in both little-endian and big-endian byte orders. The standard choice for production use.

PLY is not commonly used in AEC scanning workflows because it lacks scan metadata, coordinate system definitions, and the geospatial attributes that E57 and LAS provide. However, PLY remains relevant for visualization deliverables, 3D printing preparation, and research applications.

PTS and PTX are ASCII-based point cloud formats originating from Leica Geosystems. Despite being legacy formats largely superseded by E57, they remain in widespread use because of their simplicity and the massive installed base of Leica scanners in the AEC industry.

PTS Format

PTS is a column-based ASCII format. The first line contains the point count, and subsequent lines contain space-delimited point data:

Each line typically contains X, Y, Z, intensity, R, G, B values. The format is straightforward but carries no metadata — no coordinate system, no scanner position, no project information.

PTX Format

PTX extends PTS by adding a header block for each scan that includes the 4x4 transformation matrix — the scanner's position and orientation in the project coordinate system. This makes PTX significantly more useful for multi-scan projects because each scan's spatial relationship is preserved:

The transformation matrix in PTX headers allows registration software to reconstruct the multi-scan alignment without re-registration. This is the key advantage of PTX over PTS.

Industry trend: The scanning industry has largely moved away from PTS/PTX toward E57 for data exchange. However, many organizations still have archives of PTS/PTX data from Leica Cyclone workflows, and some legacy pipelines continue to use these formats. If you receive scan data in PTS or PTX format, converting to E57 before archival is recommended.

The following table compares the seven major point cloud file formats across the attributes that matter most for 3D scanning workflows — compatibility, compression, metadata support, and typical use cases.

Choosing the right point cloud format depends on three factors: your software ecosystem, your project type, and your data management needs. Here is a decision guide based on common scenarios.

By Software Ecosystem

By Project Type

The Golden Rule: Always Archive in E57

Regardless of what working format you use day-to-day, we recommend keeping a master copy of your scan data in E57. As the only ASTM-standardized open format, E57 offers the best long-term guarantee that your data will remain accessible as software and hardware evolve. Proprietary formats depend on vendor support; open standards depend on the community.

Format conversion is a routine part of point cloud workflows. Most professionals need to convert between formats multiple times per project — importing scan data into processing software, exporting for design teams, and creating archival copies. Understanding which tools handle which conversions and what data may be lost during conversion is essential.

Common Conversion Tools

Data Loss Considerations

Not all conversions are lossless. When converting between formats, be aware of what may be lost:

Best Practices for Format Conversion

• Always keep original source files. Never overwrite the original scan data with a converted copy. Store the scanner's native output and E57 export as permanent archives.
• Convert copies, not originals. Work with duplicate files when converting. A failed or incorrect conversion should never affect your master data.
• Verify after conversion. Open the converted file in the target software and spot-check point counts, coordinate values, and visual appearance against the original. Point count differences indicate data loss.
• Document the conversion chain. Record which software, version, and settings were used for each conversion. This audit trail is critical for quality assurance and troubleshooting.
• Minimize conversion steps. Each conversion is an opportunity for data loss or corruption. Plan your format strategy to minimize the number of conversions between capture and final use.