Relative Pose Estimation Causes Major Slowdown vs. COLMAP

[enzohagz]

I've noticed that GLOMAP runs significantly slower than COLMAP on some datasets, with Relative Pose Estimation being the main bottleneck.

On an i7-14700K, this phase takes anywhere from 1 minute to over 30 minutes, while COLMAP finishes the entire reconstruction in 15-25 minutes. This seems excessive, considering I’m only processing ~400 1080p images.

I tried adjusting --RelPoseEstimation.max_epipolar_error, but it had no noticeable impact on runtime.

Setup

• Running in: Docker on WSL2 (Ubuntu 22.04)
• GLOMAP: 1.0.0
• COLMAP: 3.11.1
• CUDA: 11.8.0
• Ceres-Solver: 2.0.0 (I think)
• GPU: RTX 4080 SUPER

I’ve been thinking about updating Ceres-Solver and enabling CUDA support, but haven’t had time to set it up.

Questions

• Is this expected behavior for GLOMAP?
• Is there a way to speed up Relative Pose Estimation?
• Could this be a Poselib issue, or is something else causing the slowdown?

Would appreciate any insights!

[lpanaf]

Hi @enzohagz, thank you for your question. Would you mind sharing more details on the concrete data you are using? For example, which camera model are you using?

[enzohagz]

Hi @lpanaf,

Thanks for your response.

I’m currently running the following setup for COLMAP operations:

colmap feature_extractor \
    --image_path /workspace/images \
    --database_path /workspace/database.db \
    --ImageReader.camera_model RADIAL_FISHEYE \
    --ImageReader.camera_mask_path /workspace/camera_mask/mask.png \
    --ImageReader.mask_path /workspace/image_masks \
    --ImageReader.single_camera 1 

colmap exhaustive_matcher \
    --database_path /workspace/database.db

Additionally, I’m running both COLMAP mapper and GLOMAP mapper with default settings.

Issue Observed

The dataset primarily consists of dashcam footage, which means there's significant colinear motion. Based on your paper, I expected GLOMAP to be more robust under these conditions. However, in practice:

• COLMAP appears faster (though by just about 1.2x), but more importantly more stable.
• GLOMAP’s final pose clustering seems to produce disjoint clusters, which affects reconstruction continuity.

Do you have any recommendations for parameter adjustments in GLOMAP that might improve stability in cases with strong colinear motion?
I've tried fiddling with Triangulation.min_angle, but with mixed results.

Thanks in advance!

[lpanaf]

Hi @enzohagz, your chosen camera model is so far not supported by PoseLib, which causes problems to the step of relative pose estimation. To solve this issue, you can look at pull request #171 or change your choice of camera model (potentially to SIMPLE_RADIAL or OPENCV_FISHEYE). This should very likely solve your problem

[DuVogel87]

I think it is supported:

PoseLib/PoseLib#133

[lpanaf]

Hi @DuVogel87, for the version of poselib we are using in GLOMAP, only the following models are supported

and RADIAL_FISHEYE is not there

[enzohagz]

Hi @lpanaf, @DuVogel87,

Thanks for your inputs. This is an interesting finding.

I’ll see if I can work around it by manually modifying the build of GLOMAP to use the dev version of PoseLib.
If that doesn’t work, I’ll test different camera models—though fisheye has generally worked best for my dashcam data. As a last resort, I can preprocess the images with undistortion and use SIMPLE_PINHOLE as a fallback.

I’ll report back once I’ve tested this. Appreciate the help!

[lpanaf]

@enzohagz If the chosen camera model is really the desired one, I would really suggest you try out the modification in pull request #171, which just undistorts keypoints before feeding into the problem :)

[enzohagz]

@lpanaf Sorry for the late reply—I’ve been caught up with other work these past couple of weeks. Appreciate the suggested fix in PR #171! I’ll try forking a branch and testing it out with my current pipeline.

I’ve actually been meaning to branch glomap to support the changes in the dev branch of PoseLib, but with all the breaking changes (like the camera module rename and revamp), I just haven’t had the time yet to do a proper review and implementation. Hopefully, I can get around to it soon.

Thanks again for the help!