E57, LAS, LAZ or PLY: which point cloud format for scan-to-BIM

Every scanner exports a point cloud in its own native format and in two or three exchange formats, and every scan-to-BIM tool reads some subset of them. The choice rarely changes what the model looks like, but it does change whether the pipeline can read the file at all, how big the upload is, and whether colour and intensity survive. This is a practical guide to the four formats our pipeline reads, from the point of view of a facade model.

What a facade pipeline actually needs from the file

Before comparing formats, it helps to know how little is required. To model a facade, the pipeline needs:

• XYZ for every point, in one frame. That is the whole geometry.
• Colour (RGB), if the scanner captured it. It is not required, but it tells a door from a window and a grille from a patch, and AutoIFC is measurably better with it.
• A header that says how many points there are and what the bounding box is, so the pipeline can quote the facade area before reading anything.

It does not need intensity, return number, scan angle, timestamps, normals or classification. Those fields make files bigger and add nothing to a facade model. It also does not need the file to be in any particular coordinate system: a local frame with the origin at the first station is fine.

E57: the archival format

E57 (ASTM E2807) was designed by the scanning industry to exchange everything a scanner captures: multiple scans with their poses, images, intensity, colour, and structured (grid) or unstructured points. It is the format to keep if you want a single file that any future tool can read completely.

For scan-to-BIM it has two practical properties. First, it can hold several scans in one file, each with its own pose, which is convenient but means the poses must be applied to get one registered cloud; ours does. Second, it is not compressed in the way LAZ is, so an E57 of a facade scan is usually the largest of the four. A 150-million-point scan with colour is on the order of 4 to 5 GB in E57.

Use E57 when the scan comes straight from registration software and you want to keep the images and the station structure alongside the points.

LAS: the surveying format

LAS (from the ASPRS) is the lidar format of the surveying and mapping world, built for airborne data and widely used for terrestrial data because everything reads it. A LAS file is one cloud in one frame with a fixed record layout per point: XYZ as scaled integers, intensity, return information, classification, and optionally RGB. Point format 2, 3, 7 or 8 carries colour; point format 0, 1 and 6 do not, and a scan exported in one of those loses its colour silently.

Our example scan is a LAS 1.4 file of 149,773,407 points with RGB: 3.6 GB. The header gives the count and the bounding box in a few milliseconds, which is what lets the pipeline estimate the facade area before the upload has even finished.

Use LAS when the downstream tools are surveying tools, and check the point format carries colour.

LAZ: LAS, compressed

LAZ is LAS with lossless compression (the LASzip codec). The content is bit-for-bit the same as the LAS it came from; the file is typically five to ten times smaller. The same 3.6 GB LAS is around 500 to 700 MB as LAZ. Reading is slower than LAS because of the decompression, but for an upload over the internet the trade is obvious.

One caution: a few older tools write LAZ with a non-standard codec, and a few readers do not include the codec at all. Ours reads LAZ through the standard codec; if a file fails to open, re-export it from the registration software rather than converting it with a third tool.

Use LAZ for uploads and archives. It is what we recommend by default.

PLY: the research format

PLY (the Stanford polygon format) is the simplest of the four: a text header describing the properties of each vertex, then the vertices in ASCII or binary. It carries whatever properties you put in, including colour and normals, and it is what photogrammetry tools and research code tend to produce. It has no standard for multiple scans or for coordinate systems, and a text PLY of a large scan is enormous.

Use PLY when the cloud comes from photogrammetry or a research pipeline, and export it binary.

The comparison

Export settings that matter more than the format

In our experience the format is rarely the problem; the export settings are. Four things to check before sending a scan to any scan-to-BIM tool:

1. Registered, one frame. If the file holds stations that are not yet registered, the pipeline sees several ghost facades. Register first, export once.
2. Colour on. Many exporters default to XYZ and intensity. Turn RGB on and, for LAS, pick a point format that carries it.
3. No subsampling below 5 mm on the facade. A facade at 20 mm point spacing still models; at 50 mm the window openings stop being separable from the wall. If you must reduce the file, crop away the ground and the trees instead of thinning the wall. AutoIFC reads every point it is given and does its own subsampling only to fit the facade plane; everything else sees the full cloud.
4. Units in metres. A file in millimetres or feet is a facade a thousand times too big or three times too small. The header does not always say; check the bounding box makes sense for a building.

Registration software and what it exports

Most facade scans go through one of a handful of registration tools before they reach a modelling pipeline, and each has a default export that is not always the right one.

Two general rules cover most of that table. Export the registered, unified cloud rather than the stations. And export colour, at full density on the facade, in LAZ if the upload is over the internet and E57 if the file is going into an archive.

A ten-second sanity check before upload

Open the file in any free viewer and look at three things. The building should be one building, with no doubled edges, which confirms registration. The colours should be plausible, which confirms RGB survived the export. And the bounding box, shown in the header or the viewer’s properties, should be tens of metres across, which confirms the units. Ten seconds there saves a run on a file that would have produced two ghost facades or a facade a thousand times too big.

What happens to the file after upload

For the curious: the pipeline reads the header, then streams the whole file once to fit the facade plane on a subsample and once more to project every point into the facade’s frame. From then on the original file is not touched again; everything after that works from the projected array. On the example scan the two passes take 98 seconds and peak at 6.6 GB of memory. The scan itself stays in your project, downloadable until you delete it.

File sizes other than the measured LAS are estimates from typical compression ratios. Reading behaviour describes the AutoIFC engine; other tools differ, and the export advice applies to all of them.