# Reasoning Chain

## Dimension 1: Accuracy

### Fact Confirmation
On UAV-VisLoc (Fact #1, #3, #4): LiteSAM leads in hit rate across all difficulties (66.66/65.37/61.65) vs EfficientLoFTR (65.78/63.62/57.65) vs SP+LG (60.34/59.57/54.32). RMSE values are nearly identical (~17.8m for all three).

On self-made dataset at lower altitude (Fact #13): LiteSAM shows a larger advantage — RMSE 6.12m vs SP+LG 6.76m vs EfficientLoFTR 7.28m. Hit rates: LiteSAM 77.30% (Hard) vs EfficientLoFTR 61.84% vs SP+LG 58.31%.

### Reference Comparison
LiteSAM's advantage over SP+LG in Hard mode: +7.33pp on UAV-VisLoc, +18.99pp on self-made. This is significant — Hard mode simulates large search offsets (300-600m) which matches our scenario where VO drift can reach 100-200m from true position.

### Conclusion
LiteSAM offers meaningfully higher satellite matching success rates, especially in difficult conditions (large search offset from VO drift). The RMSE difference is negligible — all methods achieve similar precision when they succeed. The key differentiator is HOW OFTEN they succeed (hit rate), where LiteSAM leads significantly in Hard mode.

### Confidence
✅ High — numbers from the same paper under identical conditions.

---

## Dimension 2: Inference Speed on RTX 2060

### Fact Confirmation
RTX 3090 measured (Fact #1, #3, #4): SP+LG 44.15ms, LiteSAM 83.79ms, EfficientLoFTR 112.60ms.

RTX 2060 estimates (Fact #14): RTX 2060 Turing has ~40-60% of RTX 3090 throughput. BUT: SP+LG uses ONNX FP16 (optimized for Turing), while LiteSAM/EfficientLoFTR would run as PyTorch models without ONNX.

### Reference Comparison
Current solution spec: SP+LG ONNX FP16 ~130-180ms total on RTX 2060 (SuperPoint 80ms + LightGlue 50-100ms).
LiteSAM PyTorch on RTX 2060: ~140-210ms estimated (no ONNX optimization available).
EfficientLoFTR PyTorch on RTX 2060: ~190-280ms estimated.

Critical: LiteSAM without ONNX on RTX 2060 would be roughly comparable to current SP+LG with ONNX. If LiteSAM got ONNX/FP16 support, it could be faster (given 2.4x fewer params).

### Conclusion
Speed-wise, LiteSAM and the current SP+LG ONNX solution are roughly comparable on RTX 2060 (~140-210ms vs ~130-180ms). EfficientLoFTR is slower. All are well within the 5s budget. The lack of ONNX for LiteSAM is a deployment concern but not a blocking performance issue.

### Confidence
⚠️ Medium — RTX 2060 numbers are estimates; actual ONNX vs PyTorch performance gap varies.

---

## Dimension 3: VRAM Footprint

### Fact Confirmation
Current pipeline peak (Fact #5, draft03): XFeat 200MB + DINOv2-S 300MB + SuperPoint 400MB + LightGlue-ONNX 500MB = ~1.6GB peak.
LiteSAM: 6.31M params → ~25MB model weights. Feature maps at 1184×1184 at 1/8 scale plus multi-scale features → estimated ~300-500MB total.

### Reference Comparison
With LiteSAM replacing SP+LG: XFeat 200MB + DINOv2-S 300MB + LiteSAM ~400MB = ~900MB peak.
Savings: ~700MB VRAM, well within 6GB RTX 2060 budget.

### Conclusion
LiteSAM would significantly reduce VRAM usage compared to current SP+LG approach. Both approaches fit within the 6GB RTX 2060 budget, but LiteSAM leaves more headroom.

### Confidence
⚠️ Medium — LiteSAM VRAM not officially measured, estimated from params and architecture.

---

## Dimension 4: Rotation Handling

### Fact Confirmation
None of the three approaches (SP+LG, LiteSAM, EfficientLoFTR) are rotation-invariant (Fact #10). The current solution handles this with: (1) 4-rotation retry at segment start, (2) heading-based rectification during flight, (3) SIFT+LightGlue fallback.

### Reference Comparison
LiteSAM or EfficientLoFTR would require the same rotation strategy. For the 4-rotation retry: 4 × LiteSAM = ~560-840ms (RTX 2060 est.) vs 4 × SP+LG = ~520-720ms. Acceptable since this only happens at segment starts.

SIFT+LightGlue fallback is still needed regardless. This fallback uses SIFT (rotation-invariant detector) + LightGlue matcher, which is independent of the primary matcher choice.

### Conclusion
Rotation handling is NOT a differentiator. All three approaches need the same rotation strategy. The SIFT+LightGlue fallback must be retained regardless.

### Confidence
✅ High — rotation invariance is a well-understood property of these architectures.

---

## Dimension 5: Codebase Maturity & Deployment Readiness

### Fact Confirmation
LiteSAM (Fact #7): 5 stars, 0 forks, 4 commits, no releases, no ONNX, no TensorRT, PyTorch only, weights on Google Drive, built upon EfficientLoFTR.
EfficientLoFTR (Fact #9): 964 stars, HuggingFace, TensorRT pattern exists, CVPR 2024.
SP+LG: SuperPoint 4.5K+ stars, LightGlue 3.2K+ stars, LightGlue-ONNX dedicated project with FP16/Turing support.

### Reference Comparison
SP+LG is the most production-ready by far. EfficientLoFTR is moderately mature. LiteSAM is academic prototype quality.

### Conclusion
LiteSAM's codebase immaturity is a significant deployment risk. No ONNX/TensorRT support means running PyTorch in production, which is heavier and harder to optimize. If LiteSAM's core improvement is TAIFormer + MinGRU on top of EfficientLoFTR, the safer path might be to use EfficientLoFTR (which has deployment tooling) and accept slightly lower accuracy.

### Confidence
✅ High — directly observable from repositories.

---

## Dimension 6: Pipeline Integration

### Fact Confirmation
All three approaches are fine matchers, not retrievers (Fact #11). DINOv2 coarse retrieval remains necessary. The integration point is Stage 2 of the satellite matching pipeline.

### Reference Comparison
SP+LG: Modular — can independently update detector (SuperPoint) or matcher (LightGlue). Features are reusable.
LiteSAM/EfficientLoFTR: End-to-end — takes image pair, outputs correspondences. Less modular but fewer integration points.

Current pipeline caches SuperPoint features for satellite tiles. With LiteSAM/EfficientLoFTR, caching doesn't apply the same way — feature extraction is coupled with matching.

### Conclusion
Switching to LiteSAM/EfficientLoFTR simplifies the pipeline (one model instead of two) but loses modularity and changes the caching strategy. SuperPoint tile features can no longer be pre-computed independently. However, LiteSAM/EfficientLoFTR can still cache one side's features internally if adapted.

### Confidence
✅ High — architectural analysis.

---

## Dimension 7: Risk Assessment

### Fact Confirmation
LiteSAM risks (Fact #7, #12): immature codebase, no community support, no deployment tooling, single paper, acknowledges limitations with viewpoint changes.
EfficientLoFTR: proven at CVPR 2024, active community, but also not trivially deployable on RTX 2060 without ONNX work.
SP+LG: battle-tested, ONNX FP16 verified on Turing, large community.

### Conclusion
Adopting LiteSAM carries the highest risk: single point of failure on an immature codebase. If a bug is found or the approach doesn't work on our terrain data, there's no community to help. EfficientLoFTR is a safer "upgrade" option. The current SP+LG approach carries the lowest risk.

**Recommended strategy**: Keep SP+LG as the primary matcher (low risk, proven). Evaluate LiteSAM and EfficientLoFTR as experimental alternatives during implementation — run comparative benchmarks on actual flight data. If LiteSAM delivers on its accuracy promises with our data, consider adopting it as the primary matcher after it matures.

### Confidence
✅ High — risk is based on observable maturity indicators.
