pc_align handling of "gross outliers"

[mkbarker]

Hello,

I am running pc_align (v3.5.0) on two DEMs. The reference DEM (1 m/pix) covers only a portion (about 1/3rd) of the source DEM (10 m/pix). Hence their extents are not the same (the source DEM is 2x2 km). The DEMs are fairly close already -- the max expected translation is ~20 m.

I don't understand why changing the --max-displacement from 1000 m to 100 m has any effect on the "input errors". Since the DEMs are already fairly close (much closer than 1000 and 100 m offsets), I would expect the "input errors" reported by pc_align to be not too different from the initial elevation residuals, which range from -8 to +20 m with a mean of ~3 m and std dev of ~3 m.

I also don't understand why the number of loaded points from the source DEM changes with the --max-displacement option. I thought that the max-displacement was used in the "filtering gross outliers" step, which comes after the loading of the source DEM.

For max-displacement = 100:

Will use datum (for CSV files): Geodetic Datum --> Name: Moon (2015) - Sphere Spheroid: Moon (2015) - Sphere Semi-major axis: 1737400 Semi-minor axis: 1737400 Meridian: Reference Meridian at 0 Proj4 Str: +proj=longlat +R=1737400 +no_defs
Computing the bounding boxes of the reference and source points using 1000000 sample points.
Computation of bounding boxes took 1.25912 s
Reference points box: Min: (-114.548, -89.3524) width: 5.19842 height: 0.073151
Source points box: Min: (-118.27, -89.3549) width: 9.20162 height: 0.11304
Intersection box: Min: (-114.548, -89.3524) width: 5.19842 height: 0.073151
Reading: stereo/M129674288RE_M129701439LE/run-DEM.tif
--> [*] 100%
Loaded points: 1198424
Loading the reference point cloud took 2.08656 s
Data shifted internally by subtracting: Vector3(-7692.49,-19124.8,-1.73884e+06)
Building the reference cloud tree.
Reference point cloud processing took 4.27702 s
Reading: ldem_0_orig.tif
--> [*] 100%
Loaded points: 29437
Loading the source point cloud took 0.10094 s
Filtering gross outliers
Filtering gross outliers took 0.185592 s
Reducing number of source points to: 15904
Not enough points left in the source cloud after filtering. Try loading more.
Reading: ldem_0_orig.tif
--> [*] 100%
Loaded points: 29437
Loading the source point cloud (second attempt) took 0.075794 s
Filtering gross outliers
Filtering gross outliers took 0.168288 s
Reducing number of source points to: 15904
Number of errors: 15904
Input: error percentile of smallest errors (meters): 16%: 1.71357, 50%: 4.85718, 84%: 26.9921
Input: mean of smallest errors (meters): 25%: 1.3538, 50%: 2.53227, 75%: 3.7786, 100%: 13.6009

For max-displacement = 1000:

Will use datum (for CSV files): Geodetic Datum --> Name: Moon (2015) - Sphere Spheroid: Moon (2015) - Sphere Semi-major axis: 1737400 Semi-minor axis: 1737400 Meridian: Reference Meridian at 0 Proj4 Str: +proj=longlat +R=1737400 +no_defs
Computing the bounding boxes of the reference and source points using 1000000 sample points.
Computation of bounding boxes took 1.29609 s
Reference points box: Min: (-117.732, -89.3926) width: 11.5657 height: 0.15352
Source points box: Min: (-121.414, -89.395) width: 15.4894 height: 0.193228
Intersection box: Min: (-117.732, -89.3926) width: 11.5657 height: 0.15352
Reading: stereo/M129674288RE_M129701439LE/run-DEM.tif
--> [*] 100%
Loaded points: 1198424
Loading the reference point cloud took 2.11063 s
Data shifted internally by subtracting: Vector3(-7692.49,-19124.8,-1.73884e+06)
Building the reference cloud tree.
Reference point cloud processing took 4.30769 s
Reading: ldem_0_orig.tif
--> [*] 100%
Loaded points: 58013
Loading the source point cloud took 0.14149 s
Filtering gross outliers
Filtering gross outliers took 0.276972 s
Reducing number of source points to: 41068
Not enough points left in the source cloud after filtering. Try loading more.
Reading: ldem_0_orig.tif
--> [*] 100%
Loaded points: 58013
Loading the source point cloud (second attempt) took 0.107145 s
Filtering gross outliers
Filtering gross outliers took 0.166315 s
Reducing number of source points to: 41068
Number of errors: 41068
Input: error percentile of smallest errors (meters): 16%: 4.02227, 50%: 253.462, 84%: 756.482
Input: mean of smallest errors (meters): 25%: 3.22175, 50%: 50.4311, 75%: 178.47, 100%: 336.291

Any help would be much appreciated.

Thanks!

[rbeyer]

Hmm, that is a head-scratcher. The person who could definitively answer this is Oleg. He's on vacation for the next few weeks, but when he's back, I'm sure he'll speak up.

[oleg-alexandrov]

If you say you expect 5 m of alignment translation but you tell the tool it will be 1000 m, it will declare all points in one cloud within horizontal and vertical 1000 m distance of the other cloud to be potential inliers. I guess we should have options for max expected horizontal alignment and for vertical one. That should allow for tighter filtering. For now, you should not wildly overestimate the expected displacement, as that is used in various heuristics. Such heuristic cannot be avoided especially when a cloud has billions of points and and it is feasible to load only a subset.

…

On Thu, Aug 14, 2025, 2:01 AM Ross Beyer ***@***.***> wrote: *rbeyer* left a comment (NeoGeographyToolkit/StereoPipeline#462) <#462 (comment)> Hmm, that is a head-scratcher. The person who could definitively answer this is Oleg. He's on vacation for the next few weeks, but when he's back, I'm sure he'll speak up. — Reply to this email directly, view it on GitHub <#462 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKDU3FL4ENLNTNZXXMJZEL3NO7SZAVCNFSM6AAAAACD3A3MW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCOBWGA4DMOJRGY> . You are receiving this because you are subscribed to this thread. Message ID: <NeoGeographyToolkit/StereoPipeline/issues/462/3186086916@ github.com>