Point Cloud Formats: Overview and Practical Use

The chosen format affects file size, processing speed, interoperability, preserved metadata and how efficiently large datasets can be accessed. This becomes particularly relevant in workflows involving applications such as Revit. Scan data may originate as E57, LAS/LAZ or a proprietary scanner format, while Autodesk's native point cloud workflow is based primarily on indexed RCP/RCS data.

In this article, we take a look at the following questions: Which formats are currently common? What are their strengths, and where do they reach their limits? Which formats are particularly well suited for efficiently visualizing large point clouds or collaborating on them?

Example of a digitized flyover.

LAS was originally developed for airborne laser scanning and has become one of the established formats for LiDAR data.

Unlike plain-text formats, LAS stores point information in a compact binary structure. LAZ adds lossless compression and can reduce the required storage considerably.

This makes LAS and LAZ particularly well suited to applications such as:

• airborne laser scanning,
• mobile mapping,
• terrain surveys,
• GIS,
• large unstructured point clouds.

Their limitations become more apparent with terrestrial laser scanning. Structured scan information, panoramic imagery and other information associated with individual scan positions are not the focus of the format.

LAS/LAZ is therefore an excellent fit for many LiDAR applications, but less suitable when the original scan structure and photographic documentation are important parts of the workflow.

Diagram of the E57 format.
Source: https://www.ri.cmu.edu/pub_files/2011/1/2011-huber-e57-v3.pdf.

E57 was developed specifically for exchanging 3D imaging data between different systems.

Its biggest advantage is versatility. E57 can store both structured and unstructured point clouds and can preserve additional information such as scanner positions, intensity values, color and imagery.

That makes it particularly useful for terrestrial laser scanning and workflows where data needs to move between different manufacturers and software packages.

The flexibility comes with additional complexity. Different applications do not always interpret every part of an E57 dataset in exactly the same way, particularly when optional metadata or imagery is involved.

Nevertheless, E57 has become one of the most important exchange formats for reality-capture data. It provides a useful balance between interoperability and the ability to retain much more information than simple point-only formats.

Most scanner manufacturers also use proprietary project and scan formats.

These formats allow manufacturers to preserve information that might otherwise be lost during export, including raw measurements, calibration information, scanner positions, imagery and registration data.

For initial processing and registration, these formats are often the best representation of the original measurement data.

The downside is dependency on the respective ecosystem. Documentation and third-party access vary, and some formats require manufacturer software or specific SDKs.

This can become a limitation when data needs to be reused years later or exchanged with other applications.

A common strategy is therefore to retain the original scanner data while also creating an open exchange copy, for example in E57 format.

Modern scanners can capture hundreds of millions of points from a single location. In larger projects, the resulting datasets can quickly grow to hundreds of gigabytes or even terabytes.

At that scale, workflows based on copying and processing complete datasets become increasingly cumbersome.

This is especially noticeable when:

• several users need access to the same project,
• data is stored on a network,
• users work from different locations,
• local copies need to be maintained,
• or the complete point cloud is much larger than the portion currently required.

Streaming approaches address this differently. Instead of treating the point cloud as one large block of data, the points are organized hierarchically. The application can retrieve a coarse representation first and progressively load more detail for the areas currently visible.

Octrees are frequently used for this purpose. Space is subdivided into smaller regions, and the point cloud is stored at multiple levels of detail.

This means the amount of data that needs to be transferred and rendered can depend more on the current view than on the total size of the dataset.

In combination with caching, this approach allows very large point clouds to remain interactive even when the complete dataset cannot or should not be loaded at once.

Gradual subdivision of a point cloud into an octree data structure.
Source: https://www.cg.tuwien.ac.at/research/publications/2020/SCHUETZ-2020-MPC/

Potree was originally developed for web-based point cloud visualization. Its hierarchical structure makes it possible to load only the nodes required for the current view and progressively request more detailed information as the user moves closer to an object. Earlier Potree datasets could consist of very large numbers of individual files, which made copying and backup cumbersome. Newer versions improved the storage structure and conversion process.

EPT, or Entwine Point Tile, originates from the geospatial ecosystem. It also organizes point clouds hierarchically and is designed for scalable access to large spatial datasets. The data is typically distributed across a tiled structure, making it suitable for server- and cloud-based workflows.

COPC, or Cloud Optimized Point Cloud, follows a somewhat different approach. It builds a hierarchical structure into a LAZ-based file so that compatible applications can access specific spatial regions without processing the entire dataset first. This combines the compact storage and ecosystem of LAS/LAZ with a structure designed for selective access.

Projects involving point cloud data can easily accumulate hundreds of gigabytes or more. That’s why having an efficient and, above all, cost-effective archiving strategy is so important. Ideally, your archiving plan should meet these key criteria:

• Lossless Storage: Data should be preserved as accurately as possible. This is particularly important for future analyses where even small details can matter.
• Quick Access Based on Need: Depending on how likely it is that the data will be accessed soon, it should be stored in a way that doesn’t require a lengthy reprocessing sequence just to view it again.
• Reliable, Long-Term Storage: Data should be safely stored for at least as long as legally required. This often means considering cloud solutions in addition to redundant NAS systems.

A practical approach is to store data both in its raw format and in E57 format. This ensures that all information is preserved while also allowing for faster access when needed. While E57 is technically a standardized format, there’s no guarantee that every implementation will adhere to the standard. To cover all bases, it is a good idea to also archive installers for the entire toolchain along with links to where they can be obtained. Regular backup recovery tests can further ensure that data remains accessible over time.

When choosing storage media, local options like additional hard drives or NAS systems might seem like the obvious choice. However, they’re not always the most cost-effective or reliable in terms of data integrity. Large cloud providers offer special plans for long-term storage of big data volumes, sometimes at rates as low as a fraction of a cent per gigabyte.

For a balanced strategy, consider a mix of fast-access storage (which costs more per gigabyte) and slower, less expensive long-term storage. It's also worthwhile to check general virtual server providers. Some also offer competitive rates, often between 1–2 cents per gigabyte.

Special thanks to the Laser Scanning Forum community for their insights on this topic.

The chosen point cloud format has a major impact on storage requirements, loading times, data exchange, and further processing. Traditional text-based formats are hardly practical today. Open standards like E57 or LAZ provide a solid foundation for flexible workflows. Proprietary formats are often well suited for internal processes but quickly reach their limits when it comes to data exchange.

Anyone working with very large point clouds, or in the cloud, should opt for modern streaming formats like CopC or Potree 2 from the outset. This ensures high performance and scalable projects.

Practical tip:

• For data exchange: use standardized and compressed formats like E57
• For processing: use manufacturer formats, but stay within the same system
• For large, collaborative projects: plan a streaming strategy early on
• For archiving, consider storing the data in it's raw format, as well as E57, along with the software toolchain.

Qbitec takes a practical approach here: it brings the advantages of streaming formats directly into Revit. Thanks to a smart data structure and efficient caching, users can switch quickly between levels of detail even in very large projects, without loading times or data loss. This keeps access to the point cloud flexible, high-performing, and independent of project size or network environment, including panorama integration and smart visualization.