E57, explained: the "PDF of point clouds"
Imagine photographing a room — but instead of a flat picture you captured the exact position of a million tiny dots covering every wall, chair and coffee mug. Spin a laser fast enough and measure how far away everything is, and that is what you get: a point cloud, a 3D "photograph" made of measured dots. This is a friendly, no-jargon tour of what actually lives inside an E57 file — and one neat trick our own software does with it.
Why a special format at all?
A normal photo is just a grid of coloured pixels — simple. A 3D scan is messier. For every one of its millions of points you want to store where it is in space (three numbers: X, Y, Z), what colour it is, how strongly the laser bounced back (its intensity — think of a black-and-white "laser photo"), and often the panoramic photos the scanner took at the same time.
Now imagine one person scans with a Faro, a colleague uses a Leica, and the client opens the result in Autodesk software. Three machines, three programs — and they all need to read the same file, years from now, without begging a vendor for a secret decoder. That is the problem E57 solves. It is an open, vendor-neutral standard (published as ASTM E2807 and built on the open-source libE57 library). People call it the "PDF of point clouds": one portable file everyone agrees how to read.
The big idea: a text map with binary muscle
At its heart, an E57 file is a hybrid of two very different things glued together: a small chunk of XML — plain, human-readable text that acts as a table of contents — and big blocks of binary data holding the raw millions of numbers, stored compactly for speed.
Why put the map at the end? Because while a scanner is writing the file it does not yet know how big everything will be, so it streams the raw data first and writes a tidy summary once it is done. The payoff is huge: to grab one scan out of a 20-gigabyte file, software reads the tiny header, jumps to the XML map, finds the line that says "scan #3 lives at byte 4,812,000,000", and leaps straight there.
Quiet safety net: the whole file is sliced into 1024-byte "pages", and each page reserves its last 4 bytes for a checksum — a fingerprint that lets software notice if the file was corrupted.
Everything hangs off one root
Open that XML map and you find a tree — exactly like folders on your computer. There is a single root, and two branches do most of the work: data3D, a numbered list of scans, and images2D, a numbered list of photos (usually the 360° panoramas the scanner took).
Two ways to write down a point
A laser scanner does not really think in X, Y, Z. It sits in one spot and spins, and for each dot it knows three things: range (how far the beam travelled), azimuth (how far around, left-right) and elevation (how far up or down). That is spherical coordinates — the scanner's mother tongue. Most software, though, prefers plain cartesian X, Y, Z. E57 happily stores either, and converting one to the other is a bit of quick trigonometry.
Three flavours of embedded photo
The photos in images2D are not links to files in some folder — the actual JPEG or PNG is tucked right inside the E57. And there is more than one kind of embedded photo. E57 wraps each one in a "representation" that tells software how much it can trust the image geometrically. The difference boils down to a single question: how completely is the camera described?
sphericalRepresentation— a full 360° × 180° panorama, the familiar stretched 2:1 equirectangular image. Because the projection is known, every pixel matches an exact direction, so it lines up perfectly with the cloud. This is the main road in our pipeline: we read it, tidy the canvas to a clean 2:1, and hand it to the panorama viewer.pinholeRepresentation— one ordinary lens photo, described by the classic pinhole camera model (focal length, sensor size, optical centre). That is enough for software to know each pixel's direction too, just over a narrower view. In practice this is mostly how Leica works: it writes a ready-made cubemap — the six flat cube faces looking outward — straight into the E57, and our cube-face path stitches exactly those into a full panorama. It is one of the easiest cases to turn back into a clean 360° image.visualReferenceRepresentation— a photo with no camera model at all, explicitly "for the human eye only". You cannot measure with it or project it onto the cloud; it is just a reference snapshot. Our importer keeps these as attached comments rather than placing them in 3D.
Here is the catch. sphericalRepresentation is the popular choice, but it is surprisingly easy to get subtly wrong — which is exactly why the same scan can look different from one program to the next.
- Blind zones get cropped. Every scanner has a spot it cannot see — classically straight down, where its own tripod sits. Some exporters simply trim the panorama there, leaving a gap or an off-standard height.
- Rectangular pixels. A clean panorama has square pixels (
pixelWidth=pixelHeight); some files do not, so the image looks stretched until it is rescaled. - The wrong way is “forward”. The rotation stored with a panorama says which direction sits at the centre of the image, and there is no universal agreement on what “forward” even means — some exporters aim it north, others east. A small slip here spins the whole view.
- Editing tools can lose data. Round-tripping an E57 through CloudCompare, for example, can drop the capture position of
pinholeRepresentationimages — the photos survive, but they no longer know where they were taken.
The upshot: out in the wild, different software often shows the same E57 differently. Our importer tries to smooth over the common quirks — squaring up rectangular pixels, correcting the panorama orientation, and standardizing the 2:1 canvas — so a tour comes out looking right no matter which tool wrote the file.
When the panorama is baked into the cloud itself
Here is one of the most elegant — and least appreciated — ideas in the whole format. Besides panoramas stored as separate images, a panorama can also hide inside the point cloud itself. A laser scanner does not fire randomly — it sweeps a tidy grid of angles, row by row, column by column, like an old TV painting a screen. E57 can preserve that order: every point gets a rowIndex and a columnIndex saying which grid cell it came from. A scan stored this way is called structured.
The payoff: if the points sit on a grid, the cloud is already an image. Read it row by row and each point lands on a pixel — the panorama comes back with no clever re-projection at all. The file even records the grid size in its indexBounds (columnMaximum, rowMaximum), so software knows the resolution up front — our synthesizer takes the output width straight from columnMaximum + 1.
But a grid has to be a perfect rectangle, and the real world is not. What about directions where the beam shot into open sky and nothing came back? The answer is pragmatic: fill those cells with fictitious points — very often a range of exactly 0, meaning "beam sent, nothing hit". They keep the rectangle whole but are not real geometry, so a careful reader must set them aside. Ours flags every zero-range point, parks it at a dummy far-away distance so the grid math keeps working, and never treats those phantom sky points as real surfaces when it builds the depth map or exports the cloud.
Turning a scan back into a photo you can stand inside
Not every scan arrives on a ready-made grid — some are just a loose, unstructured bag of points. The good news: the panorama is still recoverable, and this is where the format meets our own work. Because a scan is really "a full sphere of points measured as angles around a single spot", you can unwrap it into a flat panorama.
Note every point's angle, let left-right run across the image width and up-down down its height, and each point lands on a pixel — the familiar stretched 2:1 equirectangular panorama. The depth map is the magic ingredient: with a distance behind every pixel, a flat-looking panorama becomes measurable and walkable — click two points on a wall and the software knows the real distance, because it never forgot the 3D data underneath.
So why does E57 matter?
Because it is the neutral meeting ground. A surveyor scans a bridge with one brand of hardware, an engineer opens it in different software, and an architect archives it for the next twenty years — and E57 is the single file all three can rely on, with no vendor holding the keys. It keeps colour, intensity, geometry, panoramas and the all-important sensor positions together in one place, as an open standard anyone can implement.
One last fun fact: the capture time inside an E57 is counted in GPS time — seconds since 6 January 1980, the moment the GPS satellite clocks switched on — not the usual computer epoch of 1970. Get that wrong and a scan taken today reads as if it happened in 2013.
Want to go deeper?
- libE57.org — the reference open-source library and the format's home base.
- ASTM E2807 — the official standard.
- libE57Format · Image2D — exact definitions of the spherical, pinhole and visual-reference representations.
- Paul Bourke’s E57 notes — a concise technical breakdown of the header and structure.