Commit graph

2 commits

Author SHA1 Message Date
118dc36e92 solve: prefer the estate's own Astrometry.net over nova for blind solves
The estate now runs Astrometry.net itself (ankh-morpork-infra astrometry/):
solve-field against ~5 GB of local index files, sized from this repo's
TELESCOPES.md so the whole iTelescope fleet's fields of view are covered.

blind.py now tries it before nova.astrometry.net. Speed is the least of the
reasons - a blind solve of a real DSS field returns in 0.7s where nova queues
for minutes. The reasons that matter are that nova requires UPLOADING the
master to a third party and holding an API key, and neither is necessary any
more for the ordinary case. nova remains the fallback, so an estate outage
costs speed and privacy rather than the ability to solve.

pipeline/astrometry_net.py is the client and nothing more: stdlib-only POST,
parses the returned .wcs so the full TAN solution is used rather than a
re-derivation from the summary numbers. It deliberately does NOT decide whether
to trust a solution - blind.py already verifies every blind solve against Gaia
and applies a star-count and residual gate, and two gates that can disagree is
worse than one that is trusted.

The source ('estate' or 'nova') is threaded through the log lines, the returned
method, and the ASTRSOLV card, because a year from now that card is the only
way to tell whether a frame was solved in-house or uploaded.

Also corrected astrometry.py's 'cannot solve without a blind solver' message,
which has been untrue since run.py started falling through to blind.py.

Tested against the live service: blind solve of a DSS2 field with a known
centre returned within ~4 arcsec in 0.7s; the WCS round-trips through astropy;
and an unreachable service falls through to nova instead of raising.
2026-07-21 23:00:23 +01:00
2f268c7ca9 Add blind plate solving as the fallback when the seeded solver cannot match
The seeded solver starts from the header's pointing, scale and roll
angle and matches against Gaia. That works whenever the image and the
catalogue hold recognisably the same stars, and fails when they do not: a
single 60 second narrowband frame over a four degree field records a
sparse, shallow population that overlaps poorly with any magnitude slice
of Gaia, and no amount of window sliding fixes a population mismatch.

A blind solver does not care about any of that. It builds geometric
hashes from the image's own stars and looks them up in pre-built indexes,
so it needs no pointing, no scale and no orientation - only pixels.
blind.py drives nova.astrometry.net through astroquery, passing the plate
scale as a hint where one is known, which turns a search over every
possible scale into a search over one.

Two properties worth stating plainly. It needs a free API key, and
without one it says so clearly and the pipeline continues unsolved rather
than failing. And it uploads the image to a third-party service, which is
fine for these targets but is a fact worth knowing before pointing it at
something unpublished.

The result is verified rather than trusted. Whatever the service returns
is matched back against Gaia locally and put through the same gate as the
seeded solver - 40 stars and 1.5 px - so a solution has to be good, not
merely returned. A wrong WCS remains worse than no WCS whoever produced
it.
2026-07-21 22:47:29 +01:00