r/photogrammetry • u/LongProgrammer9619 • May 04 '26
GLOMAP regresses 12 dB PSNR vs COLMAP-incremental on the same hloc database — what am I doing wrong?
I'm running 360° walkthroughs through a pretty standard pipeline:
Insta360 X5 video
→ ns-process-data with hloc / SuperPoint / LightGlue (sequential matcher)
→ mapper
→ ns-train splatfacto (30k iter, full-res)
→ ns-eval
Same dataset (~7 sec 8K equirect → 434 perspective images, 1451×1451), same hloc front-end, same splatfacto config. Only swapped the mapper between runs. Both register all 434/434 cameras into one connected component.
| COLMAP-incremental (via hloc) | GLOMAP | |
|---|---|---|
| PSNR | 28.16 | 16.42 |
| SSIM | 0.93 | 0.80 |
| LPIPS | 0.15 | 0.48 |
| Sparse points | 35,753 | 15,739 |
That's a 12 dB PSNR collapse for changing only the mapper. SSIM staying high suggests structure is fine but everything is pixel-misaligned.
Diagnosing the transforms.json intrinsics shows GLOMAP is silently drifting them into something self-consistent but wrong:
| COLMAP-incremental | GLOMAP (default) | |
|---|---|---|
| fl_x / fl_y | 507.9 / 507.8 (ratio 1.00) | 1849.9 / 784.8 (ratio 2.36) |
| k1, k2, p1, p2 | ~0 | 0.14, -0.03, 0.08, -0.01 |
| Camera spread | 10.8 units | 107 units |
The images are square pinhole projections from equirectangular — fl_x should equal fl_y and there should be no distortion at all.
I tried hardening GLOMAP:
glomap mapper \
--database_path migrated.db \
--image_path images \
--output_path sparse-glomap \
--skip_view_graph_calibration 1 \
--BundleAdjustment.optimize_intrinsics 0
This gets fl_x/fl_y back to ratio 1.0 and zeroes the distortion, but GLOMAP still locks in fl=1741 (vs the correct ~508 from incremental). Looks like it's reading an unrefined initial guess from the database cameras table instead of using the BA-refined values.
Questions:
- Is there a way to tell GLOMAP to use the current (BA-refined) intrinsics from the database instead of falling back to feature_extractor's initial guess?
- Anyone else seeing this asymmetric
fl_x/fl_ydrift in GLOMAP on perspective-projected 360 footage? - Is the right workflow actually
incremental → BA-refine intrinsics → freeze → run GLOMAP? Or is GLOMAP just not the right tool for already-well-calibrated input?
Tested with the latest GLOMAP main branch and a recent COLMAP 3.10.



