Preprocessing Pipeline

[tizianoGuadagnino]

Motivation

I finally wanted to tackle #295, as the preprocessing has been an asymmetry in the design for a while, and I would like to have an emotional closure with it. As a side effect, this also allows control of the number of threads for deskewing, as now all preprocessing is performed in a single module (similar to the attempt already made in #400).

This PR

Introduce the Preprocessor module, which is in charge of clipping the scan to the min/max range and performing the motion compensation. For now, I kept the voxel downsampling outside the preprocessing pipeline, although we could merge it in this module if we like the idea.

Results

Of course, I obtained the same numbers in terms of runtime and "accuracy" for the few sequences I tested.

[benemer]

Amazing! It looks good to me. Now we also use tbb for deskewing + only deskew the points that are not clipped :)

It's OK to keep the voxel downsampling for now because we also use it in the VoxelHashMap, which is not part of Preprocessing.

The base branch was changed.

[tizianoGuadagnino]

Successive commits represents the fact that me and @benemer realize that the numbers were differing slightly from main in terms of accuracy, while the runtime seemed to be affected the most based on single thread vs multi-thread. For these reasons we converged to the current solution which replicates the code present in main but wrap it into a function so that we can get both a separate module for the preprocessing and control over the threads used for deskewing, while getting the same numbers for runtime and accuracy.