Registration & Cleaning

A scanner sees only what is in line of sight from where it stands. One scan position captures a single viewpoint: the near faces of things, with a shadow of missing data behind every object and around every corner. To capture a whole room you must move the scanner and scan again from a new spot; to capture a building you repeat this dozens or hundreds of times. Each of those scans is recorded in its own local coordinate system, centred on the instrument, with no knowledge of where the others were taken. You end up with a pile of overlapping jigsaw pieces, each correct in itself but floating free of the rest.

Registration is the process of bringing all those separate scans into one common coordinate system, so that the point of a doorway captured from the corridor and the same doorway captured from inside the room land exactly on top of each other. Done well, the many viewpoints merge into a single continuous cloud of the whole space, gaps from one position filled by coverage from another. Done badly, the same doorway appears twice, slightly offset - a 'double wall', the tell-tale sign of a registration error - and every measurement across that join is wrong.

Registration is fundamentally a problem of finding the rigid transformation (rotation and translation) that best lines up each scan with its neighbours, using the regions where they overlap. This is why overlap is planned deliberately: neighbouring scan positions must share enough common surface for the software, or the surveyor, to lock them together. Too little overlap and scans cannot be reliably aligned; this is one reason a capture is planned, not improvised.

There is a deeper point here that connects to the whole course. Registration is where the honest limit of 'accuracy accumulates' becomes concrete. Each pairwise alignment carries a small error, and across a long chain of scans - down a corridor, around a courtyard, up through floors - those small errors can accumulate and drift, so a cloud that looks crisp in any local area may be subtly distorted over the whole building. Controlling that drift is the heart of good registration, and for any survey-grade or georeferenced result it is managed with proper control - surveyed reference points the whole network is tied to - which is the province of a licensed surveyor. For most architectural and interior work the aim is more modest but the principle identical: register so the whole reads true, and know how much error the join carries.

There are two broad methods for registering scans, often used together, and understanding the difference helps you judge a dataset and plan a capture.

Target-based registration places physical reference objects in the scene before scanning - spheres on stands, flat checkerboard targets on walls - positioned so that several are visible from each scan position. Because each target has a precise, identifiable centre that multiple scans can all see, the software (or surveyor) matches the same target across scans and uses those shared points to compute the alignment. Targets give strong, reliable, checkable registration, and they are the traditional choice for accurate work, especially over larger or repetitive spaces where cloud geometry alone is ambiguous. The cost is effort and planning: targets must be placed well, kept still, surveyed if georeferencing is needed, and not moved mid-job. In heritage or sensitive interiors you may not be allowed to fix anything to surfaces, which constrains the method.

Cloud-to-cloud registration dispenses with targets and aligns scans directly by matching their overlapping geometry - the software searches for the transformation that makes the shared surfaces coincide, typically using an iterative algorithm that nudges the scans together until the overlap fits as closely as possible (the classic family is 'iterative closest point'). Its great advantage is freedom: no targets to place, so capture is faster and less intrusive, which suits interiors, cluttered spaces and fast mobile or handheld scanning. Its weakness is that it needs sufficient overlap and enough distinctive geometry to lock onto - a long, featureless corridor or a bare symmetrical room gives the algorithm little to grip, and alignment can slip or drift. Modern workflows, including mobile SLAM systems, rely heavily on cloud-to-cloud methods and are remarkably good, but they are most robust when the space has plenty of shape to match.

In practice the two are combined: cloud-to-cloud for speed and convenience, with a scatter of targets (or surveyed control points) to anchor the network, check the result and stop drift over the whole job. Whichever is used, the essential discipline is the same - the software will always produce *an* alignment, so you must verify it, not just accept it. Which leads directly to reading the registration error.

The single most important habit in processing is this: registration software always gives you an answer, and the answer is not always right. Feed it scans with too little overlap, a featureless corridor, or targets that moved, and it will still confidently report an alignment - one that may be subtly, or badly, wrong. A cloud can look perfectly crisp on screen and still be distorted. So you never judge registration by eye alone; you read its error.

Good registration software reports a measure of how well the scans actually agree where they overlap - typically a residual distance: on average, how far apart are points that should be the same surface, across all the joins? A small residual (well under the data's noise level) means the scans agree tightly; a large one means they do not, and something is wrong - insufficient overlap, a moved target, a mis-matched pair, or accumulated drift. You read these numbers scan by scan and for the network as a whole, find the worst joins, and fix them - adding overlap, re-matching, removing a bad scan - before trusting the dataset. This is quality control, and skipping it is how bad data reaches a design team looking authoritative.

There is an honest subtlety worth stating plainly: a low registration error means the scans are consistent with each other, not necessarily that the cloud is correct in the real world. You can register a set of scans beautifully into an internally perfect cloud that is nonetheless rotated, scaled slightly off, or floating away from true position - internally tight, externally wrong. Tying the cloud to reality - real-world coordinates, true scale, a known datum - is georeferencing, and it depends on surveyed control. For everyday architectural and interior work, an internally consistent cloud of good relative accuracy is often all you need, and that is a reasonable, honest deliverable. But the moment the result must sit correctly in real-world coordinates, align to a legal boundary, or serve as a survey-grade deliverable, that is georeferenced survey - the domain of a licensed surveyor working to recognised standards with proper control, and not something to infer from a good-looking internal alignment. Know which you have: relative consistency is one claim, absolute correctness in the world is a much bigger one, and the figures that back the bigger claim come from the surveyor and the spec, not from the viewer.

A freshly registered cloud is whole but still raw: it contains everything that was in front of the scanner, wanted or not. Cleaning is the work of removing what is not the permanent fabric, so that the surviving points describe the building you actually care about. It is tedious, it is largely manual, and it is where a great deal of a deliverable's real quality is made or lost.

Several things get removed. Transient objects - people who walked through the scans, parked vehicles, temporary furniture, site equipment, a trolley someone left - are not the building and must go, or they will confuse every downstream use. Vegetation - plants, overhanging branches, grass - is usually stripped for building work, though it may be kept for landscape or heritage purposes. Noise and outliers - the fuzzy spread around surfaces and the stray points floating in space from beam splitting, reflections off glass, or dust - are filtered out so measurements and meshing behave. And often the cloud is cropped to the area of interest, discarding the street, the sky and the neighbouring buildings that the scanner happened to catch.

The tools range from automatic to entirely manual. Algorithms can strip many outliers statistically (points with too few neighbours are likely noise), and classification routines - increasingly machine-learning based - can label and remove vegetation or isolate the ground or walls. But the messy reality is that automated cleaning is imperfect, and a careful human still goes through by hand, deleting the van the algorithm missed and rescuing the thin railing it mistook for noise. This is a judgement-laden job: remove too little and clutter corrupts the model; remove too aggressively and you delete real features - a delicate moulding, a slender post, a genuine but sparse surface - that you needed. Good cleaners keep the master data and work on copies, and keep notes on what was removed.

Stand back and the importance is clear. Registration and cleaning together are the post-processing that turns raw capture into a usable dataset, and they typically take far longer than the scanning did. The field time produces the raw material; this desk work produces the deliverable. It is genuinely where capture quality is won or lost - and it is a real, valuable, often under-appreciated skill. Respect it, budget time for it, and never hand on an unregistered, uncleaned cloud as if the scanning alone were the job.