AutoPlatepar/AstrometryNet: optional position_hint for star-starved solves - #967
Conversation
autoFitPlatepar/astrometryNetSolve always did a blind all-sky solve -- position_hint was hardcoded to None -- even when the caller knew roughly where the camera points. For narrow-FOV or faint cameras (e.g. a mono global-shutter sensor behind a longer lens), a blind solve needs far more stars than such a field yields, so it fails. Thread an optional position_hint=(ra_deg, dec_deg, radius_deg) through autoFitPlatepar -> astrometryNetSolve -> astrometryNetSolveLocal to the astrometry.net Solver. When given, it collapses the all-sky search to a small patch and the solve converges with far fewer stars. Defaults to None everywhere, so the blind behaviour is unchanged for every existing caller. Verified on an IMX296 mono / 4 mm f/0.95 station: the blind solve needed ~100 stars to lock; with a zenith hint (RA=LST, Dec=lat) the same field solves at ~28 stars. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
b353bd1 to
1d54f4e
Compare
|
Updated this PR directly with the review fixes:
Validation:
The PR is now mergeable and its diff is limited to the astrometry implementation and tests. |
|
@GlassOnTin could you please test this new version on your end? |
|
Tested on my station (RPi 5, IMX296 global-shutter + 4 mm f/0.95, ~64×50° FOV, local astrometry.net series‑4100). ✅
Reproducible. Cause is hint‑radius vs field size: my hint was So forwarding the hint into the wide‑FOV all‑sky fallback can hurt wide‑field cameras when the caller's radius is smaller than the field. Options: keep the wide‑FOV fallback blind (it's the last‑resort recovery path), or clamp the hint radius up to ≥ the field angular radius when |
The local astrometry.net solver restricts the reference catalog to within the hint radius of the centre. When that radius is smaller than the image's own angular field, the outer stars are excluded and the quad match fails - a regression on wide-FOV cameras (a 15 deg hint on a ~64 deg fisheye dropped every star past 15 deg from centre, so a frame that solved blind no longer solved). Clamp radius_hint up to the field circum-radius (half-diagonal, +10% margin) before building the PositionHint, only when a FOV estimate is available. Narrow- FOV cameras are unaffected (their hint radius is already >= their small field), and the blind path is unchanged. Verified on-station (RPi5, IMX296 4mm fisheye, local astrometry.net): the previously-failing 15 deg hint now solves, identical result to the blind fallback; Tests/TestAstrometryNet.py still 7/7. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Pushed a fix for that regression in b83ed7f — keeps the hint flowing everywhere (no revert of the propagation), just makes it safe on wide fields. The local solver restricts the reference catalog to within On my station the previously-failing 15° hint now solves — clamped to ~49° — with the identical result to the blind fallback, and |
autoFitPlatepar(viaastrometryNetSolve/astrometryNetSolveLocal) always runs a blind all-sky solve;position_hintis hardcoded toNone. Narrow-FOV or faint cameras extract too few stars for a blind solve, so it fails with "No solution found".This adds an optional
position_hint=(ra_deg, dec_deg, radius_deg)threaded through to the astrometry.netSolver. It defaults toNoneeverywhere, so existing callers are unchanged.Tested on an IMX296 mono + 4 mm f/0.95 Pi 5 station (~75° field, ~25-40 extractable stars per frame). The blind solve only locks when the field happens to reach ~100 stars; with a zenith hint (RA = LST, Dec = latitude) the same ~28-star field solves cleanly.
A follow-up could derive the hint automatically from a
platepar_templatewith a known pointing - kept out of this PR to stay minimal.🤖 Generated with Claude Code