VoxelStudio

CloudCutter archive · Publication 13

E57 Reading Principles for Large Point Clouds

Technical articlePhase III · Multi-format architecture

E57 is rich and structured. Efficient reading therefore begins with metadata and schema discovery, followed by block-wise point streaming.

All articlesCloudCutter product page

Simplified logical structure

An E57 file combines a binary container, an XML metadata tree, compressed point records, and optional images or other blobs. The metadata may describe:

  • scan count, names, GUIDs, and poses;
  • point-field definitions and numeric limits;
  • Cartesian or spherical coordinate fields;
  • RGB, intensity, row, column, timestamp, and validity flags;
  • bounds and image metadata;
  • compressed-vector prototypes used to interpret point records.

Practical reading sequence

  1. Open the E57 file through a conforming E57 library.
  2. Validate the container and read the metadata tree.
  3. Enumerate scans and inspect their available point fields.
  4. Record scan poses, bounds, and optional image references.
  5. Prepare a compressed-vector reader for each scan.
  6. Stream point records in bounded blocks.
  7. Transform coordinates consistently where scan poses require it.
  8. Feed only controlled samples into the preview cache.
  9. During export, write selected full-resolution points in bounded blocks.
  10. Copy supported images only when the requested E57 output requires them.

Conceptual block reader

openE57(path);
readMetadata();

for (const ScanInfo& scan : scans) {
    preparePointReader(scan);
    while (reader.readBlock(block)) {
        processBlock(scan, block);
        block.clear();
    }
}

Avoid the full-memory pattern

std::vector<Point> allPoints;
reader.readAllPoints(allPoints); // unsafe for very large sources

The safe design keeps memory related to block size, preview sampling limits, and active output buffers rather than to the total number of points in the source file.

Images should generally remain unloaded during preview. They are large and unnecessary for tile visualization; they become relevant when an E57-to-E57 export explicitly preserves supported scan imagery.

What is an E57 point-cloud file?

E57 is a vendor-neutral 3D imaging exchange format used for laser-scan and point-cloud data. An E57 file can contain one or more 3D data sets together with metadata and, depending on the source, attributes such as intensity or colour.

Why can E57 files become very large?

File size grows with point count, stored attributes, scan count and the way the survey is packaged. A single registered project can contain billions of points from many scan positions.

Frequently asked questions about large E57 files

Can an E57 contain multiple scans?

Yes. E57 can represent multiple 3D data sets in one file, including structured scan data when the producer stores it that way.

Can E57 store RGB and intensity?

Yes, when those attributes are present in the source data and encoded by the producer.

Can a large E57 be read without keeping every point in RAM?

Yes. A streaming reader can process point records in bounded blocks.

Can an E57 file be split into smaller E57 files?

Yes. A spatial splitter can evaluate the full-resolution source stream against saved selections and write matching points to separate outputs.

Can E57 be converted to LAS?

Yes when the required point attributes can be represented in the destination workflow.