This thread (laserscanningforum.com/forum … =44&t=8826) posted on the Laser Scanning Forum last week reminded me of a short conversation I had at the Sequoia SPAR booth a couple months ago. Doing these types of transform manipulations is a pretty core part of our workflows so I thought I would expand a little on what works for us.
One of the key principles of our pipeline design is that it should be as nondestructive as possible. One of the implications of this is that we want to keep our data as individual scans and avoid aggregating them into big “unified” data sets until absolutely necessary. In addition, we generally don’t want to bake transforms in to the point coordinates, instead the data should stay in its original scanner object coordinate system and have associated transforms that place them in to a world coordinate system.
Managing transforms separately from the heavy underlying point data offers several advantages. Being able to quickly transfer registration updates over a slow network as described in the LSF thread is certainly one use case. Having transforms decoupled from the point data also means that segmentation and feature extraction can begin before the scan registration has been finalized. Similarly, if problems are identified in a “final” registration during segmentation and feature extraction it is easy to go back and fix them without losing work. Since the transformation data is so light weight it is also easy to cache out multiple registration versions to keep a history of what you’ve done or provide versions of the data in multiple coordinate system, e.g. local site and georeferenced coordinate systems.
The Python script I linked to in the LSF thread is a pretty good example of the type of object transform tools we find useful and we have similar tools for interacting with various other programs and data formats. PolyWorks is currently the core of our pipeline so we’ve standardized on storing transforms in their format which is just a 4x4 matrix in a text file with a header. There is nothing particularly special about that format though and Riegl, for example, has a similar text format that they use.
A pretty typical workflow is to finalize a registration then export the calculated transforms (1 text file “scan???.txt” for each data object “scan???.e57”). In a separate editing program (or project version) the transforms are applied from the text files by matching their base names to the scan files. Editing can then proceed with any later registration updates being applied as needed by importing new transform text files.
Some programs make this easy (e.g. RiScan, PolyWorks, most 3D DCC apps) while others are less friendly (e.g. Faro SCENE, Cyclone, Realworks). Thinking about what would get Sequoia on to the first list, being able to import and export the transform stack in a user friendly way would obviously be great. The other big component would be making it easier to work with large numbers of objects. I think most of the basic stuff to make the later work has already been mentioned before (e.g. grouping, automatic object naming, scripting etc.). Note that since meshing is inherently a lossy operation anyway we don’t generally try to maintain individual scan objects after that point.
Thanks for the detailed feedback and link to the laser scanning forum discussion. I’ve been thinking about being non-destructive, but for being able to perform well with large point clouds there’s a big advantage to transforming the data into something like the SPRT format. Keeping track of where the points came from, and being able to easily reconstruct the SPRT from source with tweaks would hopefully integrate well with your workflows.
Regarding tracking the source of points, the LAS file format has a “Point Source ID” field in its point data record. Is this field being used well in other tools?
Keeping the transform matrix in a file apart from the point cloud makes good sense to me, would it make sense for Sequoia to automatically look for such a file and apply it? Looking for a .txt file doesn’t seem quite right, as I would expect that to be free-form text, not a parsable matrix format, but maybe a .xform or .transform file?
Yeah, I think this works fine, in fact, I really like the way Sequoia treats the SPRT as a cache that can be invalidated and regenerated as needed. The main feature of our workflow that isn’t well supported currently is that, instead of having 1 source file with 1 billion points in it we are much more likely to have 100 source files with 10 million in each. Sequoia’s current tools make this difficult to manage. Thinking about ways to present the user with a more abstract aggregate representation of those objects that is easier to manage in bulk (typical use case) while still allowing them to dig down and adjust individual objects (less common but necessary) would be really helpful. Maybe something like a Point Sequence Loader that could be passed a series of scans (scan_000.e57, scan_001.e57, …, scan_N.e57) and would present them as a top-level object with children to the user?
Hopefully someone else can answer this better than me. We don’t really use LAS, except occasionally as a publication format for clients who want it. The LAS data model just doesn’t really fit what we need very well. If you’re generating a single SPRT from multiple source files that kind of ID approach seems reasonable though.
It depends on what you mean by automatic. I wouldn’t necessarily want it to be as automatic as watching a directory for files and automatically applying them. Instead I would rather have functions in the UI to do the following for all objects (point clouds, meshes, image projectors, etc).:
Reset transform matrix to identity.
Apply 1 transform from 1 file to N objects (optionally resetting object matrix to identity before applying).
Apply N transforms from N files to N objects based on pattern matching (optionally resetting object matrix to identity before applying).
Apply inverse of 1 transform from 1 file to N objects (optionally resetting object matrix to identity before applying).
Apply inverse of N transforms from N files to N objects based on pattern matching (optionally resetting object matrix to identity before applying).
Export object’s transform stack to file.
Bake transform in to object coordinates and set transform matrix to identity.
Inspect entire transform stack and select specific transform to revert to. This is similar to the “Remove Current” function we already have, just a bit more user friendly.
Sure, I think I’ve seen xfo used as an abbreviation other places too. As long as the data is encoded in some reasonably accessible format so that I can read and manipulate it with external tools I’ll be happy. Since Sequoia is already keeping track of the entire transform stack it would probably make sense to be able to save out that entire stack rather than just the current global transform. For that I imagine you would also want to use something a bit more structured (JSON?) than just some ad-hoc text format.