[pdal] filters.icp transformation

Jed Frechette jedfrechette at gmail.com
Fri Mar 6 12:40:18 PST 2020


On Fri, 6 Mar 2020 11:51:55 -0500 Bradley Chambers wrote:

> See my latest comment in the PR. I think the way to go is to remove the
> centering step altogether. It doesn't address the ease of use, but that's
> really a separate issue anyway.

As a user this would be my preference as well.

A lot of our workflows involve using 4x4 matrices to move
transformation information around. The results of something like an
ICP alignment might be applied to the original data, or some other
derivative data object in a completely different application. A
transform history might also be stored as a series of 4x4 matrices.

Even if filters.icp was using floats and precision was a concern for
large numbers I would prefer to handle the centering myself as a
pretransform rather than have the ICP filter calculate separate
centering values. Typically if we're working on something in a large
number coordinate system, but need to use software without the
required coordinate precision we'll choose a standard global
translation to use for the asset throughout it's lifetime. Unless it
is completely hidden from the user, having filters.icp calculate it's
own translation just adds more bookkeeping we need to keep track of.

In short, all I would want to get out of filters.icp or filters.cpd is
a single transform matrix that can be applied directly with
filters.transformation. For our use case, even getting the transformed
points isn't really needed. More often than not we're applying the
transform to a modified version of the original points so we would
just discard the points output by filters.icp anyway.

Best wishes,

-- 
Jed Frechette


More information about the pdal mailing list