You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As exposed in #290 where we made the registration module a class, I think we should go ahead and do the same with the preprocessing module, allowing us for more customization/parametrization of this bit. I'm copying the last part of that PR in here:
From a system point of view, it's nice that we now have this design:
Makes me wonder if we shouldn't merge Deskew into Preprocessing and convert it to another component as well 👀 , similar to how we do it in Python 🤔 , but to be discussed later
Items to address
Deskew is a preprocessing step, should be there
I'd love to move the preprocessing step for Kitti out of our CORE library and just drop it in the Python bindings to avoid people reporting the wrong number in papers
Decide if it's worth doing the deskewing with tbb, probably we should benchmark it (I think the answer is yes). If we keep it, we should decide on a clean way to control the number of threads "globally" Add support for limiting num_threads in tbb task #252 (comment)
As exposed in #290 where we made the registration module a class, I think we should go ahead and do the same with the preprocessing module, allowing us for more customization/parametrization of this bit. I'm copying the last part of that PR in here:
From a system point of view, it's nice that we now have this design:
// KISS-ICP pipeline modules Registration registration_; VoxelHashMap local_map_; AdaptiveThreshold adaptive_threshold_;
Makes me wonder if we shouldn't merge
Deskew
intoPreprocessing
and convert it to another component as well 👀 , similar to how we do it in Python 🤔 , but to be discussed laterItems to address
CC @tizianoGuadagnino , @benemer
The text was updated successfully, but these errors were encountered: