An E57 file (.e57) is a laser scan project stored in the format defined by ASTM E2807, published in 2011 and maintained by the ASTM E57 committee on 3D imaging systems. Where a LAS file is one flat list of points, an E57 is a container for several things at once: one or more scans, each in its own coordinate frame with a pose that places it in the project's common frame; the photographs the scanner took at each station; and metadata about the sensor, the acquisition and, sometimes, the coordinate system.
It exists because every terrestrial scanner manufacturer had its own format and nobody could exchange a project without losing something. Nearly all of them export E57 now, and it is the usual form in which a tripod, handheld or mobile-mapping scan leaves the vendor's own software.
What is inside
| Part | What it holds |
|---|---|
| File header | 48 bytes: the signature, the version, and where the XML section lives. |
| XML section | A description of everything else: the list of scans and images, each field's type and range, poses, sensor names, GUIDs, dates, and the coordinate metadata. |
| One binary section per scan | The points, bit-packed field by field: coordinates, intensity, colour, invalid-state flags, and optionally row and column indices, return numbers and timestamps. |
| One blob per image | A JPEG or PNG, with its pose and projection described in the XML. |
Everything is stored in 1024-byte pages, each ending in a four-byte CRC-32C checksum, so a reader can tell a damaged file from a misread one — a property LAS does not have.
Scans and poses
Each scan's points are stored in the scanner's own frame, with the scanner at the origin. The pose — a rotation and a translation — says where that station stands in the project's common frame. Apply every scan's pose and a registered project assembles itself; ignore them and every station collapses onto one spot. Coordinates may be Cartesian or spherical; a spherical scan stores range, azimuth and elevation and the reader converts.
Each point can also carry an invalid state. A value other than zero means the coordinate is not real geometry — a pulse that never returned, a direction with no range — and a reader that keeps such points draws a spike at the scanner origin.
Fields and their ranges
Every field declares its type and its range, and integers are stored using exactly as many bits as that range needs. A colour channel declared 0 to 255 costs eight bits per point; an invalid-state flag on a clean scan, declared 0 to 0, costs none at all. The declared range is also the only way to know what a value means: an intensity of 0.4 is dim if the range is 0 to 1 and negligible if it is 0 to 4095, and the file says which.
Images
Terrestrial scanners photograph each station to colour the points, and the format keeps those photographs with the scan they belong to. Each image has a pose and a projection — pinhole, spherical, cylindrical, or a plain reference picture with no geometry at all. Some exporters write six 90-degree pinhole faces per station, which together form a cubemap; others write one equirectangular panorama. Most point cloud software drops the images on import; the E57 viewer lists them by station, shows any of them on demand, and for a cubemap lets you stand at the station and look around inside it.
Coordinate system
The root of the XML has a coordinateMetadata field meant to hold a WKT description of the common frame. Georeferenced surveys often fill it; indoor, as-built and handheld scans usually leave it empty, because their common frame is simply "the first station" and means nothing outside the project. An E57 with no coordinate system is not defective — it is a local scan — but converting it produces a LAS whose coordinates have no declared meaning either.
E57 compared with LAS and LAZ
| E57 | LAS / LAZ | |
|---|---|---|
| Origin | Terrestrial scanning (ASTM) | Airborne LiDAR (ASPRS) |
| Structure | Project: several scans, each with a pose | One flat list of points |
| Imagery | Photographs per station, with poses | None |
| Classification | Not in the standard | Per point, standardised codes |
| Returns | Optional return index and count | Per point, standard |
| Coordinate system | Optional WKT text, often empty | WKT or GeoTIFF keys in a record; often present |
| Compression | Bit-packing only | None (LAS) or lossless LASzip (LAZ) |
| Integrity | CRC-32C on every page | None |
Neither is better; they answer different questions. E57 is the right container while a scan project is being registered, checked against its photographs and handed between scanning packages. LAS and LAZ are the right containers once the points are the deliverable: classified, in a known coordinate system, going into a GIS or a terrain model. The LAS article covers that side.
Size and speed
Because there is no entropy coding, an E57 is usually several times the size of the same points as LAZ, and roughly comparable to uncompressed LAS once the imagery is set aside. It also decodes quickly for the same reason: reading an E57 is slicing bits, not running a decompressor, and skipping over points that are not needed costs nothing, which is why a multi-gigabyte project opens in a browser.
Working with an E57 here
Open an E57 in the viewer — every scan placed by its pose, each station listed and toggleable, its photographs shown on demand. Multi-scan projects come out registered, and a file whose scans carry no poses is reported as such rather than silently stacked.
Convert an E57 to LAS or LAZ — one file for the whole project, the scan number kept as the point source ID, colour and intensity carried, the coordinate system copied when the file declares one. The converter shows each decision before it runs, and says plainly what is not carried: the images, return numbers and timestamps. Both tools run in the browser, and nothing is uploaded.