Register & compare¶

Align two datasets and measure how well they match. Phytograph supports automatic registration (no starting guess needed), three flavors of ICP for refining an alignment, and simple multi-cloud stitching.

Which one do I want?

Clouds are far apart or rotated → Auto-Register
Clouds are nearly aligned already → Cloud-to-cloud ICP
Clouds are already correct and you want one file → Stitch

Stitch¶

The simplest case: you have several point clouds of the same plant (e.g., from different scan positions) that are already roughly aligned in world coordinates, and you want a single combined cloud.

Open Stitch from the Pre-processing toolbar group (merge icon) or Tools → Pre-processing → Stitch…. The toggle at the top of the dialog picks what to merge: Point clouds (this section) or Meshes (below).
In the dialog, check the two or more clouds to merge. (If you had clouds selected in the scene, they're pre-checked — you can change the choice here.)
Optionally tick Keep original clouds to merge non-destructively — see below.
Click Stitch. The clouds are combined in the backend (a brief progress indicator shows while the merged cloud's octree is built), and a single new cloud replaces the originals in the scene.

Stitching is reversible: a single Undo removes the merged cloud and restores the original clouds exactly as they were, so you can re-stitch with a different subset.

Keep original clouds¶

By default the source clouds are removed from the scene when they merge. Tick Keep original clouds and they stay instead — hidden, so the viewport looks the same, but still listed and still fully usable. Click the eye icon next to one to bring it back.

This is useful when you want the merged cloud for a whole-plot view while keeping the individual scans for per-scan analyses — the retained clouds keep their scanner origins, so Backfill Misses, Helios triangulation, and Leaf Area Density still run on them even though they're unavailable on the merge itself.

Undo with retained originals

With Keep original clouds ticked, Undo removes the merged cloud but leaves the originals hidden — showing and hiding clouds isn't part of the undo history. Click the eye icons to bring them back.

Stitch ≠ register

Stitch concatenates the clouds' points into one cloud. Clouds imported with different global shifts are lined up in true world coordinates automatically, so a stitch never mis-places a shifted cloud. What it does not do is register — it won't correct clouds that are genuinely mis-aligned in the world. For that, use Cloud-to-cloud ICP (below) on each pair first, then stitch.

Stitching discards scanner origins

A stitched cloud has no single scanner origin, so scan parameters (origin, trajectory) from the source clouds are dropped on the merge. That means origin-dependent analyses are unavailable on the merged cloud:

Backfill Misses — recovered sky/miss points can't be placed for the viewer overlay (they'd still be computed for LAD directions, but LAD itself is unavailable — see below).
Helios triangulation (the Helios method, which projects to per-pulse spherical angles from the scanner origin).
Leaf Area Density (needs the beam origin for the Beer's-law inversion).

If any cloud you're stitching carries an origin, the Stitch dialog shows a warning and the button reads Stitch anyway so the loss is a deliberate choice. You have three ways around it: tick Keep original clouds so the sources (and their origins) survive the merge, run these analyses on the individual scans before stitching, or — if the clouds are mis-aligned — register them with Cloud-to-cloud ICP first (that preserves each scan's own origin) rather than stitching.

The underlying points, colors, intensity, and scalar attributes are all preserved (attributes present on only some inputs are carried through and filled with zeros for the clouds that lacked them).

Stitch meshes¶

The Meshes side of the toggle merges two or more mesh objects into a single mesh. The dialog opens on it automatically when only meshes are selected in the scene, or when the scene has no point clouds.

Open Stitch and switch the toggle to Meshes.
Check the meshes to merge.
Optionally tick Keep original meshes to keep the sources, hidden.
Optionally tick either overlap option.
Click Merge.

Each mesh is merged where it is drawn: a mesh you moved, rotated, or scaled with its Transform editor contributes its geometry at that placement. The merged mesh is named after its sources (cube_sphere_merged) and is one Undo step — undo removes it and restores the sources (and, with Keep original meshes, shows them again).

What carries over:

Vertex colors — if any source has per-vertex colors, or the sources have different solid colors, the merged mesh is vertex-colored; a source without its own colors is filled with its solid display color. Sources that all share one solid color stay a solid-colored mesh.
Normals — kept only when every source has them.
Textures and materials — kept when every source is textured.

Where the meshes overlap¶

Scans of one object taken from different angles cover some of the same surface, each under its own lighting. A plain merge changes nothing there: both surfaces stay, each with its own colors, so the overlap shows two slightly different shades interleaved and a hard step where one scan's coverage ends. Two options, both off by default, deal with that:

Match colors where meshes overlap — first scales each mesh's color by one brightness factor per color channel so the meshes agree, on average, across their overlaps (no mesh is the reference; each moves part of the way). Then, inside each overlap, it blends the surfaces toward one color, giving more say to whichever is farther from the edge of its own coverage, so a scan fades out toward its border instead of stopping at a step. The correction is smooth, so each mesh keeps its own fine detail. It applies to meshes that have per-vertex colors; a mesh with only a solid display color is left alone (it is a different-colored object, not a lighting difference), and so are textured meshes, whose color lives in the texture image.
Remove overlapping surface — where two meshes cover the same surface, keeps the copy that is farther from the edge of its own coverage and deletes the other's triangles. Two registered scans never sit exactly on each other, so cutting one away would leave its cut edge hanging over the other; to avoid that, the surfaces are first drawn together across the overlap, each vertex moving along its own surface normal by at most the gap between the scans, so they meet where the seam falls. This changes vertex positions inside the overlap. The meshes are trimmed, not sewn together: along the seam a strip about one triangle wide stays doubled, so there are no gaps but the result is not a single watertight surface.

Both options only act where the meshes are already aligned — register them first. Registration is never exact, so the distance within which two surfaces count as the same is measured from the meshes themselves: about 2.5 times the typical gap between them, and never less than three quarters of a typical triangle edge. Scans tend to agree in the middle of their shared surface and peel apart toward a scan's edge, so from wherever the surfaces do agree the overlap is followed outward into such a flap, up to four times that distance. Meshes that agree nowhere are treated as separate surfaces and left alone. Surfaces must also face the same way, so the two sides of a thin leaf are never treated as one surface. The confirmation message reports the distance used and what was done, including when no overlapping surface was found.

Both options run in the app window, which is unresponsive while they work — several seconds for two meshes of 800,000 triangles each.

The merged mesh is an ordinary mesh: it keeps the first source's color and opacity, but a merged plane no longer shows a plane's center/size readout or its ground-grid depth offset.

Only imported meshes and primitive shapes can be merged. Other meshes are listed but grayed out, with the reason in the tooltip:

Triangulations carry per-scan data and an adjustable triangle filter that a merge would discard.
Voxel grids, generated plants, DEMs, and fitted crowns carry state describing the whole object (cells, growth parameters, an elevation raster, crown metrics).

Textured and untextured meshes don't mix

A textured mesh and an untextured one can't share a single mesh, so the dialog disables Merge and says so when the checked set contains both. Merge the textured ones and the untextured ones separately.

Auto-register (when clouds start far apart)¶

Align Clouds (ICP) below can only polish a pair that already starts close together. Auto-Register handles the case it can't: two scans of the same plot that are arbitrarily rotated or offset, with no manual pre-alignment.

The difference is what gets matched. Matching raw points fails on a planting, because every plant's foliage looks like every other plant's — the match happily snaps the source onto a neighboring plant, one row-spacing off, and still reports a good score.

Auto-Register instead matches the overall pattern of the planting: it looks down on each cloud from above and finds the rotation and shift that make the two patterns line up. Because it uses the whole cloud at once, it does not depend on recognizing the same individual plants in both scans — which matters, since two scan positions typically detect only about half the same plants, the rest being hidden behind others.

Open Auto-Register Clouds from the Pre-processing toolbar group (sparkles icon), Tools → Pre-processing, or the command palette (⌘/Ctrl+K).
Pick the target (stays fixed) and the source (moves onto it). Either may be a streamed cloud.
Click Register.

There is nothing else to set. Auto-Register used to ask you to declare the scene type, the search method and which plant part to match on; those settings either could not change the result or made it worse, so they are gone. What they were trying to decide is now either measured from the cloud (see Built scenes) or, when several scans are registered together, settled by trying the alternatives and keeping whichever produces alignments that agree with each other.

Registering is fast, even for many scans

Registered clouds move as soon as the match is found, and the move is stored straight away — so every tool afterwards works on the aligned data with no waiting, however many scans were registered.

The display index a streamed cloud is drawn from is not rebuilt (after a rotation that would take far longer than the alignment itself); the viewer draws the existing index in its new position instead. The only operations that need it rebuilt are a freeform or rectangle crop, the erase brush, or the label brush, because those select points using the view you drew them in — the first of those shows an Updating display… indicator, then applies normally.

Built scenes¶

Vegetation and built sites need genuinely different methods: buildings have no per-plant landmark to find, and the large flat walls and roofs they do have are what surface matching is designed for.

You are not asked to declare which you have. Auto-Register measures it from the cloud in a fraction of a second — buildings are assemblies of large continuous planes, foliage is never flat at any scale, and the two are far apart on that measure — and if the scene looks built, it stops and asks before doing any of the slow work:

Switch to Buildings or built site — matches on surface shape.
Match as Crops or orchard anyway — your call still wins.

It never changes method on its own, and it only interrupts for a disagreement that would change the method. Anything milder rides along as a note on the result.

Built scenes: try plain ICP too

For buildings, Align Clouds (ICP) below is often all you need. Flat walls, roofs and corners are exactly what ICP is good at — the opposite of the vegetation case, where the lack of such surfaces is what makes Auto-Register necessary. Reach for Auto-Register when a built scene starts badly out of alignment.

Use the scanner heading¶

Most terrestrial scanners record their own position and heading (GNSS, inclination sensors, compass). When your scans carry that information, leave Use the scanner heading ticked — it makes registration markedly more reliable, and it is on by default.

The option is offered only when every scan in the run recorded a position. On scans imported without one — a plain XYZ or LAS file with no pose — it is shown grayed out and the full circle of orientations is searched instead. That gate matters more than it looks: the option works by assuming your scans are already placed in a common frame and so differ by roughly zero heading, which narrows the search to ±30°. Assume that of data which never recorded a pose and the correct answer can sit outside the search entirely — a pair 90° apart came back 90° wrong, reported as a confident result. Phytograph will not make that assumption on your behalf any more.

The reason is worth knowing. An orchard scanned from within looks much the same from several directions, so a search over all possible rotations can find an alignment that fits the points better than the correct one while being completely wrong. A lower residual does not mean a better alignment — on a regular planting a row-flipped result still lands plant on plant.

The heading is used to narrow the search, not to skip it. That distinction matters: an earlier version treated a known heading as "these clouds are already close enough" and went straight to fine alignment. Measured against RiSCAN PRO's own registration of a real peach orchard, that left three of five scan pairs a full 180° out, because fine alignment on its own cannot tell which end of a symmetric row it started from. Narrowing the search to the recorded heading instead brought every pair to within 0.1°.

Untick the box only if the recorded heading is missing or you know it to be wrong — registration then searches every orientation, which is slower and more easily fooled on repetitive plantings.

If a run looks wrong¶

Auto-Register reports two things worth acting on, and neither is fixed by a setting:

"another alignment fits almost as well" — the scene is too repetitive to tell two poses apart. On a regular planting this is the failure no residual can catch, because a row-shifted result genuinely lands plant on plant.
"too few plants found" — it fell back to matching raw surface shape.

The fix for both is a third overlapping scan, not a different setting. See below for why that works where re-running with different options does not.

Why three scans beat two¶

On a regular planting a wrong alignment is not a poor fit. A result shifted by a whole number of rows lands plant on plant, so it can score better than the correct one — measured on a real vineyard, a pose four rows out fitted more tightly than the right answer. Nothing measurable from a single pair of clouds separates those two cases, so with only two scans a warning is the most honest output available.

Three or more overlapping scans break the tie. Going around a closed loop of scans has to bring you back where you started, and a row-shifted pose does not cancel around that loop even though it fits its own pair well. Measured across three orchards: loops whose alignments are all correct close to within about a tenth of a meter, while a loop containing a bad one misses by several meters.

Two practical consequences:

Scan so the positions overlap in a loop, not as a chain. Three scans that all see some common ground can validate each other; three in a line cannot.
With four or more scans the culprit is identified, not just detected. The good alignments close their own loops, so the bad one is the alignment no passing loop vouches for. With exactly three, the problem is detected but any of the three could be responsible.

If a scan cannot be placed consistently, Auto-Register reports it as unresolved rather than putting it somewhere plausible-looking.

Registering a whole set at once¶

Given three or more scans, registering them together rather than one pair at a time lets the loop check above do its work. As well as validating the result, it can recover scenes that pair-at-a-time registration gets wrong: the matching settings that suit a tall orchard are not the ones that suit a low vineyard, and the only reliable way to tell which is right for your scene is to try them and see which produces a set of alignments that agree with each other.

On a real vineyard this was the difference between failing completely and registering to about 0.1 m — the correct settings were not the ones that scored best on any individual pair.

Each scan is matched to the reference scan and to its neighbor in a closing ring, not to every other scan, so time grows roughly in proportion to the scan count. Expect about a minute for four to six full-resolution terrestrial scans (10–14 million points each).

Reading the result¶

Auto-Register always tells you which method actually ran. Normally it matches the plants it found; if it could not find enough, it says so and matches the overall surface shape instead. That fallback still often works, but it is the weaker path — worth knowing before you trust the result.

Two warnings are worth acting on:

"This planting is too regular to be sure" — another alignment fits almost as well. On a perfectly regular block, an alignment shifted by one plant (or rotated a quarter turn) can line up just as convincingly as the right one, and no error measurement can tell them apart. Check the result visually, or crop to an area with some irregularity — a gap, an edge, a size difference — and register that first.
"This alignment may be wrong" — too few plants were matched to be confident. Run Reset Registration, then try a different match method or detail size.

A quiet result means the plants matched unambiguously.

Like ICP, the transform is applied to the source's points and its scanner origin/trajectory.

Seeing what has been registered¶

A scan that Auto-Register moved is marked registered in the Scans panel, next to its name. This matters because the alignment is baked into the points themselves — without the marker there is nothing about the scan afterwards to show it was ever moved.

Expand the scan's row for the detail: which scan it was registered onto, how far it traveled, and how many registration passes have been applied to it.

The scan you registered onto is marked too, but differently — as reference, in a lighter outline. It did not move, and resetting the registration will not move it. Expanding a reference scan lists the scans that were registered onto it.

So a scan is in one of three states:

Marker	Meaning	Affected by Reset Registration?
registered	Auto-Register moved this scan	Yes — it moves back
reference	Others were registered onto it; it never moved	No
(none)	Untouched by registration	No

The reference marker is derived from the scans currently registered onto it, so it disappears on its own once those are reset or deleted.

Undoing a registration¶

Registration is not covered by Undo. It permanently rewrites the scan's points, and Phytograph deliberately keeps changes of that size off the undo stack (the same is true of cropping, baking a transform, and segmentation).

To reverse one, use Tools ▸ Registration ▸ Reset Registration…. It returns every registered scan — and its scanner origin and trajectory — to the position it held before Auto-Register ran, and clears the registered marker. If a scan has been registered more than once, the reset undoes all of the passes at once, returning it to where it started.

The command lives in the menu bar only, not the toolbar: it acts on the whole project rather than the current selection, and it is a corrective rather than a step in a workflow. It is grayed out until something has actually been registered, so the menu tells you whether there is anything to reset without your having to open it.

It confirms first, listing the scans that are about to move, because the reset itself cannot be undone — recovering the alignment afterwards means running Auto-Register again. Reference scans are not listed: they never moved.

Reset restores position, not edits

Reset Registration moves the points back. It does not roll back anything else you did while the scan was registered — crops, erased points, labels and segmentation results all stay as they are.

How accurate is it?¶

Validated against RiSCAN PRO's Multi Station Adjustment on three real terrestrial surveys. Each ships the same scans twice, unregistered and registered, so RiSCAN's pose for every scan is recoverable exactly and can be compared point for point. The figure below is the median distance a point lands from where RiSCAN put it, across every scan that had to move:

Survey	Scans	Typical difference from RiSCAN	Worst scan
Farm, 6 M pts/scan	4	1.7 cm	1.7 cm
Olive orchard, 9 M pts/scan	5	0.5 cm	0.6 cm
Peach orchard, 14 M pts/scan	6	1.0 cm	5.7 cm

For scale, the scans themselves resolve about 5 mm at 10 m and 100 mm past 40 m, so on two of the three surveys the difference from RiSCAN is at the level of the data.

The peach survey's worst scan is the honest caveat: one position of the six kept a 0.65° tilt that the initial pattern match introduced and the refinement could not undo. A tilt is invisible near the scanner and grows with range — that scan is within a centimeter close in and roughly 20 cm out at the edge of the plot. If a registered scan looks fine near the tripod and drifts further out, that is the shape to look for; re-running Auto-Register with a different reference scan usually resolves it.

Two other things that test showed. Scans sitting at ~170° to the rest were recovered with no starting guess — Align Clouds (ICP) cannot do that, it needs the clouds to start close together. And the trunk-bases method was the least reliable, where crowns and canopy peaks both agreed closely with RiSCAN — if a result looks wrong, switching method is the first thing to try.

Auto-register first, then fine-tune

Auto-Register finishes with a full-resolution refinement pass, so its output is usually final — running Align Clouds (ICP) straight afterwards has nothing left to find. Do run it if you later crop or clean the clouds.

Cloud-to-cloud ICP¶

Align one cloud to another by matching local surfaces, coarsest detail first and then progressively finer. Use this to polish a pair that is already roughly lined up; if the clouds start far apart or rotated, use Auto-Register above instead.

Open Align Clouds (ICP) from the Pre-processing toolbar group (globe icon) or Tools → Registration → Align Clouds (ICP)….
In the dialog, pick the target (stays fixed) and the source (moves onto the target). Either can be any cloud — a large streamed cloud can be the source too; its transform is applied on the backend and its octree rebuilt.
Click Align.

ICP runs and reports:

RMSE — root-mean-square distance after alignment
Overlap % — the fitness score, i.e. the share of source points that found a correspondence
A transformation matrix applied to the source cloud

ICP is not undoable

The source cloud is updated in place and its backend session rewritten, so ⌘/Ctrl+Z will not revert an alignment (it pops whatever edit preceded it). Duplicate the scan first if you want to keep the pre-alignment version.

Read the RMSE against the cloud's own extent, not the overlap figure — fitness can read near-100% on a badly wrong alignment.

Unlike stitching, ICP preserves the source's scan parameters: the scanner origin (and, for a moving-platform scan, the whole trajectory) is moved by the same rigid transform as the points, so it stays consistent with the aligned cloud. Origin-dependent analyses (LAD, triangulation) therefore keep working on a registered source scan.

Mesh-to-mesh ICP¶

Same idea as cloud-to-cloud but on surfaces.

Run Align Mesh to Mesh (ICP)… from Tools → Registration or the command palette (⌘/Ctrl+K).
In the dialog, pick the target (stays fixed) and the source (moves onto the target). If you had meshes selected in the scene, they're pre-picked — you can change the choice here.
Click Align. The source mesh is transformed to best fit the target; the toast reports the fit. As with the other ICP tools, this is not undoable.

Mesh-to-mesh is typically more accurate than cloud-to-cloud because points are sampled uniformly off both surfaces, giving a denser and more even correspondence set than raw scan points.

The two meshes do not need to start in the same orientation. Before refining, the tool brings their centers together and tries a fixed set of 84 starting orientations, keeping the one whose surfaces agree best — so two scans of the same object taken a quarter turn apart align without a manual pre-rotation. A rotated start is only preferred when it fits clearly better than the mesh as placed, so a symmetric object (a box, a cylinder) that is already aligned is not flipped onto an equivalent face. The meshes do need to cover largely the same surface: the centers are matched first, so a mesh that is a small piece of the other may not be found.

The source mesh's existing position, rotation and scale are respected: it is aligned as drawn, and the result is applied on top of its current transform.

Cloud-to-mesh distance¶

Measure how well a mesh fits a point cloud — e.g., comparing a real scan against a procedural model or any cloud-versus-mesh ground truth — without moving anything.

Run Cloud-to-Mesh Distance… from Tools → Registration or the command palette.
In the dialog, pick the point cloud and the mesh. (Pre-picked from the scene selection when available.)
Click Compute Distance.

The Alignment panel opens with point-to-mesh distance statistics:

Mean / Median / RMSE and standard deviation
Min / Max distance and the 90th / 95th / 99th percentiles
Coverage — the share of cloud points within three distance bands. The panel labels these < 1mm, < 5mm, and < 10mm, but they are relative, not absolute: the thresholds are 0.1%, 0.5%, and 1% of the cloud's bounding-box diagonal. On a 10 m cloud, "< 1mm" means within 10 mm
The point count the statistics were computed from

Cloud-to-mesh ICP (snap to fit)¶

To actually move a mesh onto a cloud:

Run Align Mesh to Cloud (ICP)… from Tools → Registration or the command palette.
In the dialog, pick the point cloud (stays fixed) and the mesh (moves onto it). Click Snap to Fit (ICP).

The mesh is transformed to best fit the cloud, and the toast reports the RMSE (the average residual distance after alignment) alongside the overlap percentage. Like the other ICP tools, this is not undoable.

Read the RMSE, not the overlap percentage

Overlap (ICP's "fitness") is the share of points that found a match — it reaches 100% whenever the search radius is generous relative to the object, including for a visibly wrong alignment. RMSE is the honest number: a good registration lands well under 1% of the cloud's size. When the residual is large relative to the scene, the toast turns into a warning telling you to review the result before keeping it, rather than reporting success.

Distance then snap

The Alignment panel from a Cloud-to-Mesh Distance run also has a Snap to Fit (ICP) button that registers the same cloud + mesh you just measured — so you can check the fit, then snap, in one place.

Progress and canceling

Every registration and the cloud-to-mesh distance run shows a progress pill at the top of the viewport while it works. The cloud alignments name the scale they are working at ("Aligning at 8 cm detail", then 4 cm, then 2 cm) — that number shrinking is the run progressing, and the finest passes are the slow ones. Click the ✕ on the pill to cancel; the alignment stops (within one iteration batch) and nothing is moved, exactly as if it hadn't been run.

When ICP fails¶

ICP finds a local minimum, so it needs the inputs to be roughly pre-aligned. If RMSE comes back huge, or the result looks visibly wrong:

Try Auto-Register — for two clouds of a planting, this is usually the fix rather than a workaround: it does not need a starting guess at all.
Pre-align manually with Transform — translate and rotate to within ~10 cm and a few degrees before running ICP.
Crop away non-overlapping regions so the correspondence search isn't dominated by geometry the other input doesn't contain.

The ICP dialogs are deliberately minimal — pick a source, pick a target, run. There are no voxel-size or iteration-count settings to tune, so improving a bad result means improving the inputs.

A zero-error result is not always a good result

If the two clouds share no overlap at all, ICP can report zero error simply because it found nothing to compare. Phytograph now flags this ("no overlapping points were found") instead of showing it as a perfect fit — if you see that warning, the clouds need a rough pre-alignment or they may not cover the same ground.

For very different inputs (e.g., a sparse cloud and a dense mesh), expect higher RMSE than for similar-density inputs.