From 3066aa558b02542cf687a1a233f2210b384caad4 Mon Sep 17 00:00:00 2001 From: Mederic Fourmy <mederic.fourmy@gmail.com> Date: Mon, 27 Jun 2022 16:32:17 +0200 Subject: [PATCH] [skip-ci] Minor comment added --- src/processor/processor_visual_odometry.cpp | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/processor/processor_visual_odometry.cpp b/src/processor/processor_visual_odometry.cpp index 6af484253..2ca9d60de 100644 --- a/src/processor/processor_visual_odometry.cpp +++ b/src/processor/processor_visual_odometry.cpp @@ -243,7 +243,6 @@ unsigned int ProcessorVisualOdometry::processKnown() // if this feature id is in the last->incoming tracks of capture incoming, the track is continued // the matched pairs are stored in tracks_map_li_matched_ which is used in processNew to select the point that have NOT been match as "new" - TracksMap tracks_map_li = capture_image_incoming_->getTracksPrev(); if (tracks_map_li.count(id_feat_last)){ auto kp_track_li = tracks_map_li.find(id_feat_last); @@ -827,7 +826,9 @@ void ProcessorVisualOdometry::filter_last_incoming_tracks_from_ransac_result(con O ---------------------> I to filter last -> incoming track (and tracked keypoint map in incoming) L -------> I - based of the tracks alive after RANSAC check on O --> I + based of the tracks alive after RANSAC check on origin -> incoming + O ---------------------> I + This ugly double loop is due to the fact that features ids in Incoming are in the "values" of both maps, which requires linear search. Ideally, this may be solved a Boost.Bimap. -- GitLab