# Validation Log

## Validation Scenario
UAV flight over Eastern Ukraine agricultural terrain. 1000 images, FullHD resolution, 300m altitude. Several sharp turns creating 3 route segments. Google Maps satellite tiles at zoom 18 (~0.4m/px). VO drift reaches 150m in one segment before satellite anchor. RTX 2060 with 6GB VRAM.

## Expected Based on Conclusions

### Scenario A: Keep current SP+LG
- Fine matching succeeds ~55-60% of frames in Hard conditions (VO drift >150m)
- Processing: ~130-180ms per satellite match attempt on RTX 2060
- VRAM: ~1.6GB peak, well within budget
- Rotation at segment start: 4-retry works, ~520-720ms for the attempt
- All tooling is production-ready, ONNX FP16 works

### Scenario B: Replace with LiteSAM
- Fine matching succeeds ~62-77% of frames in Hard conditions (significant improvement)
- Processing: ~140-210ms (PyTorch, no ONNX), comparable to SP+LG
- VRAM: ~900MB peak, better margin
- Risk: if LiteSAM code has bugs or performs differently on Ukraine terrain, debugging is harder
- Risk: no ONNX means no easy FP16 optimization path

### Scenario C: Replace with EfficientLoFTR
- Fine matching succeeds ~58-62% in Hard conditions (moderate improvement over SP+LG)
- Processing: ~190-280ms (slower)
- VRAM: ~1.0-1.2GB peak
- Better deployment path than LiteSAM (HuggingFace, TensorRT pattern)
- Lower risk than LiteSAM, higher than SP+LG

## Actual Validation Results

### Hit rate impact on system accuracy
The AC requires 80% of photos within 50m, 60% within 20m. Higher satellite match hit rate directly improves this:
- Each successful satellite anchor corrects drift and backward-propagates via iSAM2
- A 7-19pp improvement in Hard mode hit rate could mean the difference between meeting and missing the 80%/60% AC thresholds
- This is the strongest argument for LiteSAM/EfficientLoFTR

### Speed impact
All three approaches process well under the 5s budget. The satellite matching runs overlapped with next frame VO anyway, so ~50ms difference is negligible.

### VRAM impact
All three fit within 6GB. LiteSAM actually provides better headroom.

## Counterexamples

### Counterexample 1: Domain gap
LiteSAM benchmarks use Chinese datasets (Harbin, Qiqihar, UAV-VisLoc). Our target is Eastern Ukraine. Terrain characteristics differ. The self-made dataset (100-500m altitude over Chinese cities) is reasonably similar to our use case, but agricultural Ukraine terrain may have less texture. This could disproportionately affect semi-dense matchers that rely on feature-rich regions.

### Counterexample 2: Outdated satellite imagery
LiteSAM benchmarks use well-matched satellite imagery. Our Google Maps tiles for conflict-zone Ukraine may be 1-2 years old. Seasonal/structural changes could reduce match quality differently for sparse vs semi-dense methods.

### Counterexample 3: Image resolution mismatch
LiteSAM benchmarks use 1184×1184 matching resolution. Our pipeline downscales to 1600px longest edge. The actual matching tile pair would be smaller. Performance characteristics may differ.

## Review Checklist
- [x] Draft conclusions consistent with fact cards
- [x] No important dimensions missed
- [x] No over-extrapolation
- [x] Conclusions actionable/verifiable
- [ ] Note: RTX 2060 performance numbers are estimates — need empirical validation

## Conclusions Requiring Revision
None — the recommendation to keep SP+LG as primary with LiteSAM/EfficientLoFTR as experimental evaluation targets remains sound given the risk/reward profile.

## Updated Recommendation
**Primary approach**: Keep SuperPoint+LightGlue ONNX FP16 (proven, low risk).
**Design for swappability**: Abstract the fine matching stage behind an interface so LiteSAM or EfficientLoFTR can be plugged in later.
**Benchmark plan**: During implementation, run comparative tests with all three matchers on real flight data. If LiteSAM's hit rate advantage holds on our terrain, adopt it after verifying ONNX export or acceptable PyTorch performance.
