XFeat Revisited: Reproducibility and Evaluation of a Lightweight Image Matcher
Lazar Đoković, Aimee Lin
cs.CV, cs.LG
2026-08-10
Reproducing XFeat: efficiency holds and beats the original on pose estimation, but two design claims are overstated, Aachen won't reproduce, and cross-modal matching fails.
XFeat is a lightweight local-feature extraction and matching network from 2024, built to do image matching (finding the same physical point across two images) fast and accurately on resource-constrained hardware like a CPU. It uses very few channels with large feature maps and comes in two modes: sparse XFeat keeps only the most confident keypoints, while semi-dense XFeat first matches a large coarse set and then refines it for more geometric constraints. Because it is fast and cheap, it sees heavy use in real-time robotics and AR.
This paper proposes no new method. It is a reproducibility study: re-implement and retrain XFeat from the paper and supplementary material, compare against the authors' released checkpoint, run architectural ablations the original under-justified, and push evaluation into cross-modal settings the original never touched. The authors carefully separate "reproduction" (their own retrained model) from "re-evaluation" (running the authors' checkpoint), because the paper, supplement, and released code disagree on the backbone layout, fusion block, and training losses, leaving "the original" itself ambiguous.
XFeat's backbone is six convolutional blocks with very few channels (4/8/24/64/64/128), keeping resolution early and downsampling with stride 2 only where convolution is cheap. A descriptor branch fuses the last three blocks into a 1/8-resolution 64-dimensional dense descriptor map, and a reliability head scores each descriptor. A separate keypoint branch eats the grayscale image directly and predicts keypoints per 8x8 cell. Semi-dense mode uses an MLP to refine coarse correspondences.
Reproduction training uses MegaDepth plus a 20k COCO subset (6:4), images resized to 800x600, four random seeds, about 17 hours per model on an L4 GPU. Evaluation covers MegaDepth-1500 and ScanNet-1500 (relative pose), HPatches (homography), and Aachen Day-Night (visual localization), extended to RUBIK (driving-scene pose), FIRE (retinal registration), MTV (thermal-visible aerial), and SRIF (optical/SAR/infrared remote sensing).
The four original claims, verdict by verdict.
| Claim | Verdict | Key numbers |
| Accuracy-efficiency trade-off (CPU) | Supported | Sparse XFeat hits 11.8 FPS and Acc@10deg 76.2 on M1 Pro, the fastest learned method; XFeat 86.2 / 6.3 FPS |
| Separate keypoint branch helps semi-dense | Partly supported | Coupling to backbone drops sparse MegaDepth AUC@10deg 57.9 to 55.4, XFeat 65.7 to 53.8 (bigger hit but variance +-11.9) |
| Single skip-connection is better | Largely unsupported | Removing it hurts ScanNet but not MegaDepth; ResNet and Input skips match or exceed it |
| Competitive on downstream tasks | Partly supported | HPatches homography reproduces closely; Aachen visual localization does not reproduce |
On pose estimation the reproduced model does not just match but slightly beats the original: sparse XFeat on MegaDepth-1500 AUC@10deg rises from the reported 56.4 to 57.9, and XFeat on ScanNet-1500 from 34.7 to 37.1. The core "fast and accurate" claim holds.
Two architectural justifications are overstated, though. The separate keypoint branch matters mainly in semi-dense mode, with a weaker payoff in sparse mode. The single skip-connection shows no advantage over alternatives, so the authors' claim that this specific placement is optimal does not hold. The most notable reproduction failure is Aachen visual localization: both the released checkpoint and the reproduction fall below the reported numbers at every threshold (daytime 0.25m/2deg drops from 84.7 to 76.3), a gap more likely caused by underspecified localization pipeline details (HLoc retrieval, reference-map construction, geometric verification) than by the model.
The extended evaluation is colder: cross-modal matching largely fails. On the driving benchmark RUBIK, XFeat reaches about 15% success versus 30% to 37% for LightGlue-paired methods. On thermal-visible MTV, matching precision is only about 9% and AUC@20deg about 1.4% (LoFTR is 27.5%). On remote-sensing SRIF, optical-optical is still usable (S@10 about 40%), optical-infrared drops to 12.86%, and optical-SAR is near zero (below 2%). Semi-dense mode does not help cross-modal settings and mainly adds noise.
For anyone using XFeat, this is a trustworthy health check whose conclusions are safe to act on. On natural RGB images and standard matching tasks, keep using XFeat as-is; the efficiency is real. Do not trust it for zero-shot cross-modal work: thermal, SAR, and other severe modality gaps need separate adaptation. And do not treat its two architectural selling points as axioms: the separate keypoint branch matters only in semi-dense mode, and the single skip-connection is essentially irrelevant.
For paper authors, this is a template: separating "re-evaluate the released weights" from "reproduce and retrain" pinpoints whether a gap comes from the model or the evaluation protocol. The Aachen case shows that when a downstream number fails to reproduce, the first suspect is an underspecified pipeline, not the model.
As a reproducibility study, the limits are coverage and certainty. The authors note that training variance grows markedly under harder matching conditions (XFeat coupled-detector MegaDepth AUC@10deg variance reaches +-11.9), so the magnitude of several ablation gaps should be read cautiously. They did not contact the original authors to resolve ambiguous implementation details; all choices rest on paper plus code plus empirical judgment. The Aachen gap is plausibly attributed to HLoc configuration but not confirmed, since the authors' exact setup could not be reproduced. In the cross-modal extensions, preprocessing, thresholds, and normalization differ per dataset, so absolute numbers are not fully comparable across them. CPU frame rates are also heavily hardware-dependent: absolute FPS does not match the original, only the relative ordering does.