Skip to content

AutoPlatepar/AstrometryNet: optional position_hint for star-starved solves - #967

Open
GlassOnTin wants to merge 3 commits into
CroatianMeteorNetwork:prereleasefrom
GlassOnTin:feature/astrometrynet-position-hint
Open

AutoPlatepar/AstrometryNet: optional position_hint for star-starved solves#967
GlassOnTin wants to merge 3 commits into
CroatianMeteorNetwork:prereleasefrom
GlassOnTin:feature/astrometrynet-position-hint

Conversation

@GlassOnTin

@GlassOnTin GlassOnTin commented Aug 18, 2026

Copy link
Copy Markdown

autoFitPlatepar (via astrometryNetSolve/astrometryNetSolveLocal) always runs a blind all-sky solve; position_hint is hardcoded to None. 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.net Solver. It defaults to None everywhere, 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_template with a known pointing - kept out of this PR to stay minimal.

🤖 Generated with Claude Code

GlassOnTin and others added 2 commits August 24, 2026 14:26
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>
@dvida
dvida force-pushed the feature/astrometrynet-position-hint branch from b353bd1 to 1d54f4e Compare August 24, 2026 18:30
@dvida

dvida commented Aug 24, 2026

Copy link
Copy Markdown
Contributor

Updated this PR directly with the review fixes:

  • Rebased the astrometry feature onto current prerelease and preserved the original author attribution.
  • Dropped the obsolete white-ratio Detection commit, which is already merged through PR Warn when the white-ratio check silently skips meteor detection #970 with its follow-up fixes and tests.
  • Preserved the existing autoFitPlatepar positional API by appending position_hint after the established parameters.
  • Kept position_hint on the tight-to-wide AutoPlatepar retry.
  • Forwarded the hint through local solving, remote coordinate/image solving, and local-error remote fallbacks.
  • Added remote Astrometry.net translation to center_ra, center_dec, and radius.
  • Added focused coverage for current and legacy local solver APIs, blind defaults, all fallback paths, remote upload fields, API order, and the wide retry.

Validation:

  • python3 -m pytest -q Tests/TestAstrometryNet.py Tests/TestDetection.py — 10 passed
  • compileall for all changed Python modules and the new test — passed
  • git diff --check — passed

The PR is now mergeable and its diff is limited to the astrometry implementation and tests.

@dvida

dvida commented Aug 24, 2026

Copy link
Copy Markdown
Contributor

@GlassOnTin could you please test this new version on your end?

@GlassOnTin

Copy link
Copy Markdown
Author

Tested on my station (RPi 5, IMX296 global-shutter + 4 mm f/0.95, ~64×50° FOV, local astrometry.net series‑4100).

Tests/TestAstrometryNet.py — 7/7 pass.

⚠️ One wide‑FOV regression from the hint propagation, though. On a real 68‑star frame:

  • pre‑fix (b2a8da4): tight‑with‑hint fails → wide‑FOV fallback runs blind → solves (44 matched).
  • this PR (1d54f4e): tight‑with‑hint fails → wide‑FOV fallback now runs with the hintno solution.

Reproducible. Cause is hint‑radius vs field size: my hint was radius=15°, but the FOV half‑diagonal is ~35°, so the local solver restricts the catalog to 15° around the centre and drops the outer stars → quad match fails. The same PR code with radius=45° (> field radius) solves fine (identical result to the blind fallback).

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 wide_fov_search=True. Happy to test whichever you prefer.

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>
@GlassOnTin

Copy link
Copy Markdown
Author

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 radius_hint of the hint centre, so when that radius is smaller than the image's own angular field it drops the outer stars and the quad match fails. The commit clamps radius_hint up to the field's circum-radius (half-diagonal, +10% margin) before building the PositionHint, only when a FOV estimate is available (always, from autoFitPlatepar).

On my station the previously-failing 15° hint now solves — clamped to ~49° — with the identical result to the blind fallback, and Tests/TestAstrometryNet.py stays 7/7. Narrow-FOV cameras are unaffected (their hint radius is already ≥ their small field), and the blind path is unchanged. Margin's arbitrary (10%) — tweak as you like.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants