E57 and LAS both hold point clouds, and choosing between them is not a question of quality. They were designed for different stages of different workflows, and the useful question is not "which is better" but "which one should this data be in right now, and what does moving it cost?"
The one-line version: E57 describes a capture; LAS describes a result. E57 keeps the scans separate, each with the pose that places it in the project, plus the photographs the scanner took. LAS flattens everything into one list of points with standardised attributes.
For what is physically inside each file, seewhat is an E57 file andwhat is a LAS file. This article is about choosing and converting.
Where each comes from
The differences make more sense given the origins. LAS was standardised by ASPRS for airborne LiDAR: an aircraft flies, a sensor sweeps, and the output is one continuous swath of points already placed in a map projection. There are no "scan positions" to preserve — the trajectory was solved during processing — so a flat list is the natural shape, and what matters per point is classification, return number and flight line.
E57 was standardised by ASTM for terrestrial scanning, where the situation is structurally different. A scanner sits on a tripod, records everything visible from that spot, and is moved. Each position produces its own cloud in its own frame, and the central problem is registration: determining how those frames relate. A format for this data has to keep the scans distinct, because the relationship between them is the thing being worked on. It also has to carry the photographs, since those are what the registration is checked against.
Nearly every difference between the formats follows from that one distinction.
What converting actually costs
This is the part worth being precise about, because "some metadata is lost" is not actionable. Field by field:
| What | Survives? | Detail |
|---|---|---|
| Coordinates | Yes | Each scan's pose is applied, so a registered project arrives registered. |
| Colour (RGB) | Yes | Needs a point format that carries it — 2, 3, 7 or 8. |
| Intensity | Yes, rescaled | E57 declares its own range; LAS uses 0–65535. Relative values are preserved, absolute ones change. |
| Which scan a point came from | As a number | Can be kept in the point source ID. The grouping survives; the scan as an object does not. |
| Scan poses | No | Applied and then discarded. You cannot recover where the scanner stood. |
| Imagery | No | LAS has nowhere to put a photograph. |
| Return number and count | Usually no | Optional in E57 and often absent; commonly written as return 1 of 1. |
| Timestamps | Usually no | E57 per-point times do not map cleanly onto LAS GPS time. |
| Row/column indices | No | The scan's grid structure. LAS has no concept of it. |
| Coordinate system | If there was one | Copied when the E57 declares WKT. Frequently there is none to copy. |
| Per-page checksums | No | E57 has CRC-32C on every page; LAS has no integrity checking at all. |
| Classification | Nothing to lose | E57 has no classification field. Converting enables it. |
The row that matters most is scan poses. Everything else is either preserved or obviously absent, but the poses are silently consumed: the points land in the right places, and the information aboutwhere the scanner was — which is what registration produced — is gone. If the registration later turns out to need adjusting, it has to be redone from the original E57. That is the whole argument for keeping it.
The conversion is one-way
You can write a LAS file into an E57 container, and it gains nothing. A single-scan E57 holding exactly the LAS data, several times larger, with no poses and no imagery, is not a restoration — it is a repackaging.
Keep the E57. Treat the LAS or LAZ as a derived product, the same way you would treat a terrain raster derived from a point cloud.
Choosing, by situation
| Situation | Use | Why |
|---|---|---|
| Registering scans, or checking a registration | E57 | The scans and their poses are the working material. |
| Moving between scanning packages | E57 | What it was standardised for. |
| Archiving a capture | E57 | Preserves imagery and structure. Checksums help too. |
| Delivering points into a GIS | LAS / LAZ | Universal support; carries a CRS properly. |
| Classifying ground and vegetation | LAS / LAZ | E57 has no classification field at all. |
| Building a terrain or surface model | LAS / LAZ | Every tool in that chain expects it. |
| Merging with airborne LiDAR | LAS / LAZ | One flat cloud in one projection. |
| Long-term storage on a size budget | LAZ | Several times smaller, losslessly. |
| Streaming to a web viewer | COPC | Neither format streams; COPC exists for this. |
In practice most projects want both, and the sequence is usually: scan → register in E57 → convert to LAZ for delivery → keep the E57 as the archive.
The coordinate system, in practice
The most frequent surprise when converting is that the output has no coordinate reference system — and it is worth understanding that this is usually correct rather than a fault.
A terrestrial scan begins in the scanner's own local frame: origin at the instrument, axes aligned to however it was set up. Registration relates the scans to each other, which produces a consistent project frame — but not a georeferenced one. Tying that project to the Earth is a separate step needing control points or GNSS observations, and for a great deal of indoor and handheld work it is never done, because it is not needed.
E57 carries a coordinateMetadata field for a CRS, and it is frequently empty. A converter faced with that has two options: write no CRS record, or invent one. The first is correct. An honestly unreferenced file can be georeferenced later; one confidently labelled with a guess is a harder problem than the one it solved. Seewhat is a CRS for why.
Converting here
Convert an E57 to LAS or LAZ in your browser. Nothing is uploaded. The specific choices it makes:
- Every scan into one file, registered. Each scan's pose is applied, and the scan number is kept in the point source ID, numbered from 1 — the one per-point field that every downstream tool preserves, so the grouping survives even though the scans do not.
- LAS 1.4, point format 7 or 6 — 7 when any scan has colour, 6 otherwise. Colour as 16-bit RGB; intensity rescaled onto 0–65535 from the range the E57 declares.
- 1 mm coordinate precision, with the offset at the first point.
- The CRS is copied, never guessed. WKT if the E57 has it, nothing if it does not — and the panel says which.
- Invalid points are dropped, rather than written as a spike at the scanner origin.
- Not carried: return numbers, timestamps, row and column indices, vendor extensions and the imagery. Every point is written as return 1 of 1 with GPS time 0.
Around that:
- Open the E57 first — each station listed and toggleable, with the scanner's photographs — to check the registration before flattening it.
- Inspect the output to confirm the point format, coordinate system and record count are what you expected.
- Classify the result, now that it is in a format with a classification field.
Common mistakes
- Deleting the E57 after converting. The poses and imagery cannot be recovered from the LAS.
- Expecting a CRS that was never there. Check the source before blaming the converter.
- Comparing intensity across the two formats. The rescaling changes absolute values by design.
- Assuming E57 means registered. It can hold unregistered scans just as easily; a scan with no pose is a scan sitting at the origin.
- Converting before checking the registration. Errors are visible per scan in E57 and baked in afterwards.