Point Cloud Registration and Cleaning in CloudCompare: A Heritage Workflow

Why CloudCompare for Heritage

Heritage projects frequently combine data from more than one source — a laser scanner for large interior volumes, photogrammetry for detailed carved surfaces, a drone for roofs and towers. Each source produces its own point cloud in its own coordinate frame. Bringing them together into one consistent, clean, correctly-scaled dataset is the job CloudCompare does, and it does it without a licence cost, which matters for institutions, academic projects and smaller practices.

Its most valuable heritage capabilities are registration (aligning multiple clouds precisely), cloud-to-cloud distance comparison (verifying a model against the scan, or measuring deterioration between two dated surveys), and effective cleaning tools for the noise that every real-world capture contains. Proprietary scanner software (Faro Scene, Leica Cyclone) handles registration of that vendor's scans well, but CloudCompare is the neutral ground where data from different sources meets.

Before You Start: Importing and Orienting

CloudCompare imports the common heritage point cloud formats — E57 and LAS/LAZ (the archival standards), PLY and PTS, and the OBJ mesh format. On import of a large cloud, CloudCompare may offer to shift the coordinates by a global translation to preserve precision; accept this (it stores the shift and applies it back on export) — very large coordinate values, such as full UTM eastings and northings, otherwise lose precision in the software's internal single-precision representation.

Once imported, orient yourself: use the preset views and the segmentation-free rotation to understand the cloud. Give each cloud a clear name in the DB Tree (the object list on the left), because registration and comparison operations refer to clouds by name and an unlabelled tree of 'Cloud', 'Cloud.1', 'Cloud.2' quickly becomes unmanageable on a multi-source heritage project.

• Accept the global coordinate shift on import for georeferenced clouds — it preserves precision and is reversed on export.
• Rename clouds meaningfully in the DB Tree immediately (e.g. 'TLS_mandapam_interior', 'SfM_east_facade').
• Check the scalar fields present on each cloud (intensity, RGB, classification) — these travel with the points and are useful for cleaning and interpretation.
• Keep a copy of each original cloud untouched; work on duplicates, because most cleaning and subsampling operations are destructive.

Registration: Aligning Point Clouds

Registration is the process of transforming separate point clouds so they share one coordinate system and overlap correctly in space. In heritage work you register when combining multiple scanner stations, when merging photogrammetry with laser scan data, or when tying a new survey to an earlier one. Getting registration right is the foundation of everything downstream — a poorly registered dataset carries a built-in error that no later step can remove.

Coarse Alignment Then ICP

The reliable registration sequence is always coarse-then-fine. First, use the 'Align (point pairs picking)' tool: select the cloud to move ('aligned') and the cloud to register it to ('reference'), then pick at least three, preferably four to six, clearly identifiable matching features that appear in both clouds — a distinct carved corner, a specific stone junction, a target centre. CloudCompare computes a rough transformation that brings the two roughly together. This does not need to be perfect; it needs to be close enough that the fine step can converge.

Second, run 'Fine registration (ICP)' — Iterative Closest Point. ICP iteratively adjusts the alignment to minimise the distance between the overlapping surfaces of the two clouds. Set the final overlap parameter to reflect how much of the two clouds actually overlaps (if only part of the two clouds shares surface, a lower overlap value gives a better result), and let it run to convergence. ICP reports a final RMS (root mean square) error — this is your registration quality indicator, and it should settle to roughly the noise level of the data (a few millimetres for TLS, more for photogrammetry).

Cleaning: Noise, Outliers and Segmentation

Every real capture contains points that should not be in the final dataset: stray points floating in space (from moving people, birds, dust, or scanner edge effects), vegetation, temporary objects, and general measurement noise. Cleaning removes these so the cloud represents only the heritage fabric.

Two tools do most of the work. 'Segment' (scissors icon) lets you draw a polygon around points in the current view and keep or delete them — this is the manual tool for removing obvious unwanted regions like a parked vehicle, scaffolding, or a person. 'Noise filter' and 'SOR filter' (Statistical Outlier Removal) automatically remove scattered noise points based on their distance from their neighbours — SOR removes points whose average neighbour distance is a set number of standard deviations above the mean, which strips the fuzzy halo of stray points that surrounds most raw clouds.

1. 1Manually segment out large unwanted objects first (people, vehicles, scaffolding, vegetation) using the Segment tool from several viewpoints.
2. 2Apply the SOR filter (Statistical Outlier Removal) to remove scattered noise — start with the defaults (6 neighbours, 1.0 standard deviation) and increase the standard deviation multiplier if it removes genuine surface detail.
3. 3Use the Noise filter for surface smoothing of measurement noise where appropriate — but apply it cautiously on carved heritage surfaces, where aggressive smoothing erases the fine detail you captured the surface to record.
4. 4Inspect the result at full density from multiple angles before accepting; cleaning is destructive, so verify you have not removed genuine fabric.

Subsampling and Merging

Heritage point clouds are often far denser than downstream use requires — a combined multi-scanner temple dataset can run to hundreds of millions of points, straining both CloudCompare and any modelling software it feeds. Subsampling reduces the point count to a workable density while preserving the surface. Use 'Subsample' with the 'Space' method, which enforces a minimum distance between points (for example, one point every 5mm) and gives a uniform density — this is preferable to random subsampling because it preserves detail evenly rather than thinning dense and sparse areas equally.

Merging combines several registered clouds into one. Once all clouds are correctly registered in the same coordinate system, select them in the DB Tree and use 'Merge' to create a single cloud. Merge only after registration is verified — merging first destroys the ability to adjust individual clouds' alignment. For a combined laser-and-photogrammetry heritage dataset, register each source, clean each, then subsample and merge into the single deliverable cloud.

Comparison: Measuring Change Between Surveys

One of CloudCompare's most valuable heritage functions is measuring the difference between two point clouds — comparing a photogrammetric or BIM surface against the reference scan to verify accuracy, or comparing two dated surveys of the same monument to quantify deterioration, movement or material loss over time.

Two tools do this. 'Cloud-to-Cloud Distance' (C2C) computes, for every point in one cloud, the distance to the nearest point in the other, and displays the result as a colour-mapped scalar field — an intuitive heat map of where and how much the surfaces differ. For rigorous change detection on complex surfaces, 'M3C2' (Multiscale Model to Model Cloud Comparison) is the more dependable method: it computes distances along the local surface normal and provides a statistically-founded measure of significant change that distinguishes real movement from noise.

• Use C2C for a quick visual comparison — verifying a model against a scan, or a first look at where two surveys differ.
• Use M3C2 for monitoring and deformation analysis where you need to distinguish genuine change from measurement noise, and where the direction of change (along the surface normal) matters.
• Always register the two surveys on stable, unchanging areas before comparing — if you register on the changing surface itself, you register the change away and measure nothing.
• Set and record the colour scale limits explicitly so comparisons between reports are consistent and readable (e.g. ±20mm) rather than auto-scaled differently each time.

Export and Handover

Export the finished cloud in an archival, interoperable format. E57 is the preferred archival and exchange format for heritage point clouds (it carries scan structure, colour and metadata); LAS/LAZ is the standard for georeferenced survey data and integrates with GIS. Avoid delivering only a proprietary or software-specific format as the archival copy — heritage records must remain readable for decades, and open formats are the responsible choice.

On export, confirm the global shift (if one was applied on import) is correctly reversed so the exported coordinates sit in the real-world coordinate system. Record, alongside the deliverable, the registration RMS achieved, the cleaning and subsampling applied, and the coordinate system used — this processing metadata is part of a professional heritage deliverable, not an optional extra.

Common Mistakes

• Trusting a low ICP RMS without visual verification — ICP can settle in the wrong position on featureless surfaces with a deceptively good RMS; always confirm the alignment visually.
• Registering a monitoring comparison on the changing surface — this cancels out the very change you are trying to measure; always register on stable areas only.
• Over-filtering carved surfaces — aggressive noise removal erases genuine surface detail on heritage fabric; filter gently and prefer manual segmentation on ornamented surfaces.
• Merging before verifying registration — once merged, individual clouds cannot be re-aligned; register and check first, merge last.
• Ignoring the global coordinate shift — declining the shift on a large georeferenced cloud causes precision loss; failing to reverse it on export puts the deliverable in the wrong place.
• Working on originals — most operations are destructive; always duplicate the imported cloud and keep the original untouched.
• Delivering only a proprietary format — archival heritage point clouds should be exported to open formats (E57, LAS/LAZ) for long-term readability.

Professional Practice

In professional practice, CloudCompare's value is that it makes a rigorous, verifiable middle stage of the workflow affordable for every project regardless of budget. The registration RMS, the cleaning record and the cloud-to-cloud comparison figures are not just internal steps — they are the evidence that the delivered dataset meets its accuracy specification, and they belong in the project's quality record.

For heritage monitoring specifically — tracking a settling foundation, a spreading crack, or the loss of a deteriorating carved surface — the discipline of registering on stable areas and comparing with M3C2 turns repeated surveys into defensible, quantified evidence of change. That evidence supports conservation decisions and, where structural movement is involved, engineering assessment. A pair of surveys casually overlaid tells a story; a pair rigorously registered and compared provides proof.

Because CloudCompare is free and open-source, it is also the natural tool to specify when working with institutional partners, universities and government heritage bodies who cannot always license proprietary software. Building a heritage workflow around open tools and open formats keeps the data and the methods accessible to the custodians who will hold the records long after the project ends.