Point Cloud Compression: What Gets Traded Away

Every figure on this page is derived from inputs stated in the sentence that uses them. There is no public price list for point cloud storage and no universal compression ratio — ratios depend entirely on the data — so what follows is the arithmetic and the mechanism, with the ratios marked as inputs you supply from your own archive.

The uncompressed baseline, derived

Start from the record size, because that is a specification number rather than an estimate. The ASPRS LAS 1.4 specification defines Point Data Record Format 1 as 28 bytes: twelve for three int32 coordinates, two for intensity, one for the return and scan-direction bit field, one for classification, one for scan angle rank, one for user data, two for point source ID, and eight for GPS time.

assumption: a corridor survey archive of 500 million points
assumption: stored as LAS point data record format 1, 28 bytes

  500,000,000 x 28 = 14,000,000,000 bytes
                   = 14.0 GB  (13.04 GiB)

the same points in format 3 (adds 6 bytes of RGB, 34 total)
  500,000,000 x 34 = 17.0 GB

the same points in format 6 (LAS 1.4 core, 30 bytes)
  500,000,000 x 30 = 15.0 GB

naive alternative: three float64 coordinates with no attributes
  500,000,000 x 24 = 12.0 GB
  — barely smaller, and it has thrown away every attribute

That last line is the first useful result. LAS is already a compact format: storing coordinates as scaled 32-bit integers rather than 64-bit floats is a design decision that halves the coordinate cost while increasing precision for the ranges surveys use, because the scale factor puts all 32 bits where the data is.

What is actually redundant

Compression works on structure, so it is worth naming the structure a point cloud has.

• Spatial coherence. Consecutive points in a scan line are millimetres apart, so the high-order bits of their coordinates are identical. The difference between neighbours is small and therefore cheap to encode; the absolute coordinate is large and expensive.
• Attribute coherence. Neighbouring points usually share a classification code, have similar intensity, and have GPS times that increase by a near-constant step. A run of ten thousand “ground” codes compresses to almost nothing.
• Empty space. The bounding box of a survey is almost entirely void, and any structure that encodes where points are not costs almost nothing to describe.
• Excess coordinate precision. A scanner accurate to 5 mm reporting positions at 0.1 mm resolution is spending bits on noise. Those low-order bits are incompressible because they are random, which is why they dominate the size of a losslessly compressed file.

Lossless: reordering and prediction

LASzip, described by Martin Isenburg in Photogrammetric Engineering and Remote Sensing in 2013, is the standard lossless codec for survey LiDAR. It predicts each field from the previously decoded points — coordinates from a linear extrapolation of the last few, GPS time from the last time difference, classification from the previous point — and entropy-codes the residual with an arithmetic coder, using separate contexts per field so intensity residuals do not pollute coordinate statistics.

assumption: your archive measures an 8:1 ratio on this data
            (run it and read the number; do not assume ours)

  14.0 GB / 8 = 1.75 GB

at a stated 5:1   ->  2.80 GB
at a stated 12:1  ->  1.17 GB

what changed in the data: nothing. every bit is recoverable.

The ratio is entirely a property of your points. A dense airborne strip with tidy scan-line ordering compresses far better than a merged, shuffled archive, because prediction from the previous point is worthless once the order is random. If a merge step in your pipeline sorts points by classification or shuffles them for training, it has quietly cost you most of your compression, and re-sorting spatially before archiving gets it back.

Octree geometry coding

The lossy route encodes structure rather than coordinates. Take the bounding box, split it into eight octants, and emit one byte whose eight bits say which octants contain any points. Recurse into the non-empty ones. After d levels the leaf size is the bounding box extent divided by 2^d, and a point’s coordinate is implied entirely by the path taken to reach its leaf. No coordinate is ever written.

bounding box 100 m across, octree depth 14

  leaf size = 100 / 2^14 = 100 / 16,384 = 6.1 mm

cost: one occupancy byte per non-empty internal node.
near the leaves most nodes hold one or two points, so the
node count approaches the point count and the geometry cost
lands in the region of 1-3 bytes per point once the
occupancy bytes are themselves entropy coded against a
context model of neighbouring occupancy.

compare: 12 bytes per point for raw int32 coordinates.

This is the geometry coder in MPEG’s G-PCC, standardised as ISO/IEC 23090-9 in the immersive-media series. Its sibling, V-PCC (ISO/IEC 23090-5), takes a completely different route for dense clouds: project the cloud onto planes to produce 2D patch images of geometry and colour, then compress those with an ordinary video codec, inheriting decades of hardware-accelerated video encoding. ISO lists 23090-9 as geometry-based point cloud compression. Google’s Draco is the widely deployed open-source alternative for web delivery, using kd-tree and connectivity coding with an explicit quantisation-bits parameter.

Attributes are the other half

Once geometry is down to a couple of bytes per point, colour and intensity dominate. Attribute coding has to solve a problem geometry does not: the points have no natural order, so there is no “previous pixel” to predict from.

The standard answer is to impose one. Serialise the points along a space-filling curve — Morton order, which falls out of interleaving the bits of the integer coordinates — so that consecutive entries are spatial neighbours. Then predict each attribute from a weighted average of already-coded neighbours and code the residual, either directly or through a hierarchical transform such as the region-adaptive Haar transform. Quantising those residuals is where lossy attribute coding gets its ratio, and it is independent of the geometry quantisation: you can keep millimetre geometry and heavily quantise colour, or the reverse.

What gets traded away

• Coordinate precision, to the leaf size. After octree coding at depth 14 over a 100 m box, every point is at a 6.1 mm grid position. If your deliverable is a deformation measurement at millimetre level, that is your entire signal.
• Duplicate points. Two returns at the same quantised position usually merge. Normally harmless, occasionally not — return counts and multi-return vegetation analysis depend on them.
• Point order. Nearly every codec reorders, and if anything external holds an index into the original point sequence, that index is now wrong. This is a real and recurring integrity bug in pipelines that store per-point results in a separate table.
• Attributes the codec does not model. A generic geometry-and-colour codec has nowhere to put GPS time, classification, scan angle or user data. Converting a classified LAS file through such a codec silently drops the classification — the same failure mode as converting between point cloud file formats, where the loss is in the field mapping rather than in the coder.
• Random access, sometimes. A codec that predicts from everything decoded so far cannot start in the middle. Formats intended for streaming chunk their data to keep spatial random access, which costs a few per cent of ratio and is usually worth it for anything served to a viewer.

The cheapest compression is usually not compression at all. Reducing the capture resolution, or thinning to the density the deliverable needs, removes points permanently and predictably, and the density and resolution trade-offs page derives what that costs you downstream. Compressing data you should not have collected is solving the second problem.