Cleaning scans in Cyclone

Registering scans from the Great Hall in Edinburgh Castle has been a great opportunity for clarifying certain aspects of the registration process in Cyclone: mainly, the effect of cleaning scans for cloud alignment and registration.

Some laser scanning manuals and practice guides advise that cleaning scans prior to registration can have a positive effect when cloud alignment is used as a registration method. That means removing “bad data”, such as speckle noise or moving objects (cars, people, trees). In the Great Hall project, the effect of cleaning scans was apparent in the cloud-to-cloud alignment statistics  (mainly looking at RMS values). The improvement could also be verified visually: registered clean scans present “crisp” surfaces, in contrast with the noisy, “fuzzy” result from the original scans.

It must be noted that manually cleaning scans can be very time-consuming depending on the number of scans, amount of noise and geometry of spaces/objects. Using features like the limit box or various sections/slices through the point cloud can help to identify, isolate, and remove bad data. Cleaning scans is more important when the main registration method is cloud-to-cloud, as the results depend entirely on the effectiveness of the ICP algorithm and overlap between scans.

Deciding when to clean is also important: immediately after importing scans (before any kind of registration) or half-way through (e.g. after putting scans together with minimum number of cloud constraints, but before auto-adding extra constraints)? In some cases, it was very useful to first quickly register the scans without cleaning. This will not produce the best registration result, but was good enough for identifying data voids or other problems. This initial registration can be done before the data acquisition phase is over and even on site: additional scans can be done without having to return to the site later. After this initial registration phase, the scans can be properly cleaned and the registration updated to work with the clean point clouds.

This process has been followed for the Great Hall registration as well as other projects and has shown good results. The initial registration was in some cases performed using the auto-alignment option in Cyclone, for which the software calculates the relative positions of the scans automatically on import. The results are never perfect: usually, auto-alignment creates several distinct groups of aligned scans that then have to be registered together. That’s usually the best case scenario – although in some cases Cyclone has been able to successfully auto-align smaller projects (small number of scans, very good overlap). In other cases, however, the auto-alignment is just plain wrong: the software fails to match the correct surfaces together, resulting in a jumble of unrelated scans. For this reason, the constraints created by the auto-alignment process should be checked manually. Note that looking at the statistics of the cloud alignment algorithm is not always enough: sometimes constraints with RMS value <<10mm are actually completely wrong when checked visually. Still, the auto-alignment feature has proven extremely useful especially in larger projects, because it can save considerable amounts of processing time. In some cases, however, (perhaps when overlap between scans was rather low) it made more sense to completely disregard the results of the cloud-alignment and start fresh, as trying to fix the constraints would take more time than creating them from scratch.

The correct procedure for cleaning scans before registration in Cyclone is not as straightforward as one might imagine. This is mostly due to the complicated structure of Cyclone databases; one needs to understand the hierarchy and relationships among ControlSpace, ModelSpace, ScanWorld and Scans. After much experimentation and communication with Leica support, it has been determined that in the latest version of Cyclone (9.1.3), the cloud alignment algorithm works with the point cloud inside the ScanWorld’s ControlSpace, not with the ModelSpace or Default Clouds. However, in the registered ScanWorld, it is the Default Clouds that appear for each individual ScanWorld. Which can be useful in some cases, but also very confusing. Do you clean in the ModelSpace or ControlSpace? And if in the ControlSpace, which ControlSpace?*

*Cyclone creates a “child” ControlSpace for every time the ScanWorld appears in a registration within the database.

As it stands at the moment, the process for cleaning scans is as follows:

  1. In the tree view, go to each ScanWorld’s ModelSpace and clean unwanted objects.
  2. Select the clean point cloud and make it the ScanWorld’s Default Cloud.
  3. Delete point clouds from the ControlSpace(s).
  4. Go back to the clean ModelSpace, select clean cloud and Copy to ControlSpace(s).

This process will ensure that (a) the cloud alignment algorithm will use the clean clouds (from the ControlSpace), therefore improving registration results and (b) any new ModelSpaces created, as well as the registered ScanWorld ModelSpace, will contain only the clean clouds (Default Clouds).

 

Advertisements

Edinburgh Castle: Great Hall

This slideshow requires JavaScript.

The 3D documentation programme for Edinburgh Castle included laser scanning the interior of the Great Hall and adjacent rooms and circulation areas. The data capture phase for this part of the Castle had already been finished, but the scans had not yet been registered. My job was to register 6 P20 and 36 Faro scans (mostly freescans) from the interior of the Great Hall and several adjacent rooms and circulations areas, using Leica Cyclone.

After importing all the scans to a Cyclone database (Faro scans exported as PTX files from Scene – although now Cyclone supports FLS files), it was decided that a certain level of cleaning the scans would improve the results of the cloud alignment algorithm. Only a few targets had been used, so the main registration method was cloud-to-cloud. Using clean clouds for registration was especially important for those scans taken inside the Great Hall, which was at the time open to the public and therefore full of people.

after cleaning
P20 scan inside the Great Hall before cleaning.
before cleaning
Same scan, after cleaning.

The process was time-consuming, but the results justified the effort: the improvement over the results of the cloud optimisation algorithm were significant (RMS error dropping from 0.014 to 0.007 or similar). The auto-add constraints options was used, but some of the constraints added automatically were disabled, as the overlap in some cases was very low (only a few thousand points) and they did not seem to improve the overall registration. Based on the registration diagnostics, the mean absolute error was 0.001 m, but based on visual inspection, measurement, and some control targets, the errors are in fact closer to 3-4mm, which is well within the expected tolerance of the survey.

Diagnostics
Cyclone registration diagnostics.

One interesting area covered by the scanning was the “laird’s lug”, a device allowing the lord of the castle to spy on his guests or would-be conpsirators, which consists of an opening on the wall over the fireplace in the Great Hall which is linked through some convoluted tunnels to a room on the third floor, currently used as an office.

lairds lug.jpg
View of the point cloud showing the laird’s lug.

Creating a final registered point cloud for the entire Edinburgh Castle seems like a giant 3D puzzle. The next step for me will be to join the Great Hall interiors to a registered point cloud of the French Prison and underground vaults leading all the way up to the Crown Square, which has already been created in Cyclone).