Registered Image Output
Resulting metrics over golden eval set
Architecture Flow Diagram

Inspiration

Lunar missions never give you one clean view of one place. They give you images from different instruments, taken at different times of the lunar day, at resolutions that differ by more than two orders of magnitude. Before any of it can feed a map, a mosaic or a landing-site study, it has to be registered into a common georeferenced frame, and three things get in the way at once:

Different sensors: OHRC, TMC-2 and IIRS each see the surface with their own radiometry, resolution and geometry.
Changing Sun angle: shadows migrate, contrast reverses, and at incidence angles above $70^\circ$ much of the terrain simply disappears.
Scale: the same crater can span a handful of pixels in one image and hundreds in another.

We kept hitting the same wall. A matcher that works well at moderate Sun angles degrades near the terminator, while the one that survives extreme illumination is slow and sparse everywhere else. In our own tests, the fastest matcher we tried, a fine-tuned EfficientLoFTR, reached sub-pixel registration on none of the pairs whose Sun angles differed by 90° or more.

No single method covers the range, so we built LUNAr Image Registration & Invariant Synchronization (LUNA-IRIS) around two ideas: choose the matcher for each image pair, and trust no match until it has been validated. It was built for Smart India Hackathon 2026, problem statement 26166.

What it does

LUNA-IRIS registers an OHRC, TMC-2 or IIRS image to an LROC reference and exports a georeferenced product. From the source image's metadata it can search NASA's PDS archive for candidate LROC products, rank them by resolution, incidence angle and footprint overlap, and crop and rectify the best-matching footprint.

Each run produces:

a registered, georeferenced image (GeoTIFF)
ground control points (CSV)
transformation parameters (JSON)
quality metrics: RMSE, inlier ratio and SSIM
a match visualization

Results with poor GCP coverage are flagged for human review instead of being silently accepted. A web interface handles upload, sensor selection, execution and download.

The pipeline reads the incidence angle $i$ and selects the matcher:

$$ M(i)=\begin{cases} \text{RoMa} + \text{PWIFT} & i \ge 70^\circ \ \text{fine-tuned EfficientLoFTR} & i < 70^\circ,\ \text{real-time required} \ \text{fine-tuned RoMa v2} & i < 70^\circ,\ \text{otherwise} \end{cases} $$

How we built it

1. Normalize before matching. We read the image metadata (coordinates, resolution, incidence, emission and phase angles) and estimate any missing values. Photometric normalization with the Akimov model brings images to a common illumination geometry, where $D$ is the Akimov disk function and $(\alpha_0,\beta_0,\gamma_0)$ is a reference geometry:

$$ I_{\text{norm}}=I_{\text{obs}}\,\frac{D(\alpha_0,\beta_0,\gamma_0)}{D(\alpha,\beta,\gamma)} $$

Dark-current, flat-field and cosmic-ray corrections follow.

2. Match adaptively. Under extreme illumination, RoMa's dense matches are combined with PWIFT. An Akimov-based mask selects reliable pixels, a phase-congruency map captures crater rims and edges independent of brightness, and structural keypoints are extracted from it. Under normal illumination, a fine-tuned EfficientLoFTR serves real-time use and a fine-tuned RoMa v2 serves offline precision. Every branch feeds a single scored candidate set.

3. Validate before trusting. Weak candidates are rejected or down-weighted. The survivors are checked on $9\times9$ patches with normalized cross-correlation, then tested for structural consensus:

$$ \mathrm{NCC}=\frac{\sum (P_s-\bar P_s)(P_r-\bar P_r)}{\sqrt{\sum (P_s-\bar P_s)^2\,\sum (P_r-\bar P_r)^2}} $$

4. Verify the geometry and georeference. MAGSAC rejects outliers and verifies the geometric model. MiHo handles relief with local piecewise-planar models instead of one global plane. The surviving matches become GCPs, and the image is resampled and georeferenced. Accuracy is reported as

$$ \mathrm{RMSE}=\sqrt{\tfrac{1}{N}\sum_{k=1}^{N}\lVert \hat{x}_k-x_k\rVert^{2}} $$

The stack is Python, PyTorch with CUDA, OpenCV, NumPy, Pandas and FastAPI.

Challenges we ran into

Agreement is not accuracy. EfficientLoFTR had the highest inlier ratio (93.3%) and the worst RMSE (9.13 px). Matches can agree with each other and still be wrong, so inlier ratio alone cannot certify a registration. This is why validation has several independent layers.
Repetitive terrain. Similar craters produce false correspondences that survive simple geometric checks. Patch-level correlation and structural consensus catch them before geometric verification.
Speed against robustness. The hybrid takes about 3.5 s per registration and EfficientLoFTR about 88 ms, roughly 40× apart. We route by condition instead of running the expensive path everywhere: about $9.7\times10^{-4}$ GPU-hours per hybrid registration against $2.4\times10^{-5}$ for EfficientLoFTR.
Uneven GCP coverage. Sparse matches cluster on high-texture terrain. Dense matching improves coverage, and anything still poorly covered is flagged for review.
Missing metadata. Incidence and resolution drive both routing and normalization, so the pipeline estimates them when fields are absent.

Accomplishments that we're proud of

We evaluated five configurations on real lunar imagery:

Configuration	Inlier ratio	MMA@1px	RMSE (px)	Latency (ms)	Sub-pixel success, ΔSun ≥ 90°
EfficientLoFTR	93.3%	71.3%	9.13	87.8	0.0%
RoMa v2	84.8%	77.9%	6.57	430.8	23.1%
PWIFT	59.8%	36.7%	1.23	2915	14.8%
PWIFT + EfficientLoFTR	73.4%	55.2%	9.60	3127	0.4%
PWIFT + RoMa v2	65.8%	61.7%	6.76	3475	40.6%

On the hardest pairs, the PWIFT + RoMa v2 hybrid reaches sub-pixel registration 1.8× as often as RoMa v2 alone and 2.7× as often as PWIFT alone. Its mean RMSE is no better than RoMa v2's, so we report the metric where it wins instead of the one where it does not. The whole system runs end to end, from metadata and reference retrieval to GCPs and GeoTIFF export, behind a working interface.

What we learned

No model dominates. EfficientLoFTR is fastest, RoMa v2 has the best MMA@1px, and PWIFT has the lowest RMSE but the weakest coverage. The routing logic follows from these measurements.
Averages hide failures. Slicing results by illumination difference exposed a spread from 0% to 40.6% that overall means concealed.
Registration is a systems problem. Photometric normalization, routing, validation and geometric verification each address a different failure mode.
Metadata is an input, not a footnote. Sun and viewing geometry decide which method deserves trust.

What's next for LUNA-IRIS

Today, LUNA-IRIS registers one pair at a time. We want it to be the step that turns raw orbital imagery into a trustworthy lunar basemap.

From single pairs to mission-scale mosaics. Run registration over whole archives: queue thousands of strips, score each result, and hand mission teams a consistent, georeferenced basemap with a quality report per tile. That is the input that landing-site assessment, hazard mapping and 3D reconstruction all depend on.
Closed-loop, human-supervised registration. The system already flags low-coverage results for review. Next, it acts on what it sees: when validation is weak, it retries with a different matcher, and when it is still unsure, it shows a reviewer the match overlay and coverage map, then feeds the correction back into fine-tuning. A scientist sees evidence before approving a result, instead of picking control points by hand.
Strategy chosen by how different two views are. Routing today depends on how extreme one image's illumination is. We want it to depend on how much the two views actually disagree, since that is where registration breaks.
Real-time guidance for rovers and landers. The lightweight path already runs in under 100 ms. We want rovers to localize against pre-registered maps in the field, and the same architecture to carry over to other sensors and to Mars and Earth-observation imagery.

Our goal is for cross-sensor lunar registration to be a push-button, auditable step that downstream science can build on.

LUNA-IRIS is built for the people who turn orbital data into decisions: mission planners choosing landing sites, lunar scientists aligning multi-sensor datasets, and rover teams that need pre-registered maps.