MatcherCompass: A Deployment-Aware Benchmark to Guide Image Matcher Selection in the Wild
Hyunwoo Kim, Giseop Kim
cs.RO
2026-09-22
MatcherCompass scores nine matchers on four GPUs and four visual conditions; a hardware swap can miss a 20 ms budget, and RGB rankings do not transfer to thermal.
Field robots need correspondences across day, night, visible, and thermal imagery, inside onboard compute, memory, and energy limits. Papers usually report one matcher on one GPU at one resolution. That number does not tell an engineer whether the same config still fits a Jetson, whether lifting 512 px to 1024 px blows VRAM, or whether FP16 can pull 65 ms under a 50 ms budget.
HPatches and RUBIK stress geometry. Image Matching WebUI lets people try matchers. Neither ties condition-specific pose accuracy to runtime, peak GPU memory, and energy on the target board. MatcherCompass is that selection table.
Hyunwoo Kim and Giseop Kim at DGIST split the job into a shared evaluation, a cost measurement, and a budget filter.
Nine pipelines cover classical sparse (ORB CUDA, SIFT GPU), learned sparse (SuperPoint+SuperGlue, SuperPoint+LightGlue), semi-dense (LoFTR, ELoFTR, the ELoFTR variant of MatchAnything), and dense (DKM, MASt3R). Longest-side resolution is 128/256/512/1024 px. Learned matchers run FP32, mixed precision, and FP16; classical ones run Native. That is about 84 configs per task.
Four visual tasks: viewpoint and scale on RUBIK, plus day-night visible, day-night thermal, and daytime visible-thermal on STheReO Valley. Accuracy uses 100 pairs per task; resources use four. Pose error follows SuperGlue: the larger of rotation and translation-direction angles, reported as AUC at 5°/10°/20° on a 0-100 scale. Failed poses get infinite error.
Four GPUs: RTX 5070 Ti, RTX 5060 Ti, Jetson AGX Thor, Jetson Orin Nano. Runtime is matcher call through correspondence return with GPU sync, excluding image IO, model load, and pose solving. Memory is peak CUDA after warmup. Energy is integrated power over completed calls, idle not subtracted. A web GUI returns every measured config that meets a user budget, with its accuracy attached.
The RGB winner does not stay on top. On RUBIK at 512 px FP32, MASt3R hits 74.5% AUC@10°; at 1024 px it drops to 28.8%, while ELoFTR, MatchAnything, and DKM improve. Day-night visible matching at 512 px stays under 10% AUC@10° for every method. Thermal day-night: SuperPoint+SuperGlue 23.9%, DKM 20.1%, MASt3R 3.1%. Daytime visible-thermal: ELoFTR falls from 26.6% at 512 px to 6.7% at 1024 px, while MatchAnything rises from 10.1% to 22.9%. More correspondences do not mean a better pose.
A hardware swap moves the same config across a budget line. SuperPoint+LightGlue FP32 at 512 px: 12.2 ms on a 5070 Ti, 18.3 ms on a 5060 Ti, 57.2 ms on Thor, 113.3 ms on Orin Nano. On Thor, SuperPoint+SuperGlue falls from 65.7 ms FP32 to 20.9 ms FP16 (-68%), with peak memory -65% and energy -73%; the largest absolute AUC change versus FP32 is 4.42 points. On Orin Nano at 1024 px, ELoFTR and MatchAnything OOM in FP32/MP and run in FP16 at about 4.29 and 4.33 GiB.
| Method | Platform | 512 px runtime |
| SuperPoint+LightGlue FP32 | RTX 5070 Ti | 12.2 ms |
| same | Jetson AGX Thor | 57.2 ms |
| same | Orin Nano | 113.3 ms |
| SuperPoint+SuperGlue FP16 | Thor | 20.9 ms (-68% vs FP32) |
| DKM FP32 | 5070 Ti | 651.9 ms, 13.44 GiB |
DKM on the 5070 Ti uses 13.44 GiB and 163.46 J, 40.7× and 54.4× SuperPoint+SuperGlue (0.330 GiB, 3.00 J), and OOMs on Orin Nano. Raising MASt3R from 512 to 1024 px lifts energy from 44.21 J to 330.60 J. A 20 ms budget on Thor leaves Native ORB and SuperPoint+LightGlue FP16.
This is a field-robot selection table, not a new matcher. Visual condition, resolution, precision, and board have to be chosen together; an RGB ranking does not transfer to thermal. FP16 often buys a large latency cut with a small accuracy hit here, but LoFTR peak memory barely moves (under 1%), so faster is not smaller. The GUI lists every feasible config, which beats picking from an average.
Accuracy is measured only on the 5070 Ti; other boards contribute runtime under the assumption that accuracy does not change. Resource medians use four pairs per task. Energy scopes differ: RTX board power, Thor GPU rail, Orin Nano CPU+GPU+CV combined. RUBIK uses 11 of 33 difficulty levels, chosen by hand. Matching settings are locked, with no thermal-specific retraining. The clock covers the matcher call, not a full SLAM cycle.