solve: prefer the estate's own Astrometry.net over nova for blind solves #2

Merged
laurence merged 1 commit from astrometry-net-fallback into main 2026-07-21 23:00:48 +01:00
Owner

The estate now runs Astrometry.net itself (ankh-morpork-infra astrometry/, PRs #168-170): solve-field against ~5 GB of local index files, sized from this repo's own TELESCOPES.md so the whole iTelescope fleet's fields of view are covered (21.5' on T26 up to 10.4 deg on T68).

blind.py now tries it before nova.

Why, in the order that matters

  1. nova requires uploading the master to a third party. That is now unnecessary for the ordinary case.
  2. nova requires an API key, so blind solving silently did nothing on a machine that had not been set up.
  3. It is much faster - a real blind solve came back in 0.7 s against nova's minutes-in-a-queue - but that is the least of it.

nova stays as the fallback, so an estate outage costs speed and privacy, not the ability to solve. It is also the right fallback for fields narrower than the local index set reaches (below ~5.6' quads), which is a deliberate gap: covering it would have cost 32 GB more index data for scopes the fleet does not have.

What deliberately did not change

  • The seeded solver stays primary. A good header beats a blind search.
  • Every blind solution, from either source, still passes the same Gaia verification and star-count/residual gate. astrometry_net.py is a client and nothing more - it does not decide whether to trust a solution, because two gates that can disagree is worse than one that is trusted.
  • The source (estate / nova) is threaded through the log lines, the returned method, and the ASTRSOLV card - a year from now that card is the only way to tell whether a frame was solved in-house or uploaded.

Also fixed 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: correct to ~4 arcsec in 0.7 s
  • the returned .wcs round-trips through astropy (pixel_to_world on the centre matches)
  • an unreachable service falls through to nova rather than raising

Decision recorded in state/DECISIONS.md.

The estate now runs Astrometry.net itself (ankh-morpork-infra `astrometry/`, PRs #168-170): solve-field against ~5 GB of local index files, **sized from this repo's own TELESCOPES.md** so the whole iTelescope fleet's fields of view are covered (21.5' on T26 up to 10.4 deg on T68). `blind.py` now tries it before nova. ### Why, in the order that matters 1. **nova requires uploading the master to a third party.** That is now unnecessary for the ordinary case. 2. **nova requires an API key**, so blind solving silently did nothing on a machine that had not been set up. 3. It is much faster - a real blind solve came back in **0.7 s** against nova's minutes-in-a-queue - but that is the least of it. nova stays as the fallback, so an estate outage costs speed and privacy, not the ability to solve. It is also the right fallback for fields narrower than the local index set reaches (below ~5.6' quads), which is a deliberate gap: covering it would have cost 32 GB more index data for scopes the fleet does not have. ### What deliberately did not change - The **seeded solver stays primary**. A good header beats a blind search. - Every blind solution, from either source, still passes the **same Gaia verification and star-count/residual gate**. `astrometry_net.py` is a client and nothing more - it does not decide whether to trust a solution, because two gates that can disagree is worse than one that is trusted. - The source (`estate` / `nova`) is threaded through the log lines, the returned `method`, and the **ASTRSOLV card** - a year from now that card is the only way to tell whether a frame was solved in-house or uploaded. Also fixed `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: correct to **~4 arcsec in 0.7 s** - the returned `.wcs` round-trips through astropy (`pixel_to_world` on the centre matches) - an unreachable service **falls through to nova** rather than raising Decision recorded in `state/DECISIONS.md`.
laurence added 1 commit 2026-07-21 23:00:42 +01:00
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.
laurence merged commit 88aaac854c into main 2026-07-21 23:00:48 +01:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: laurence/astrophotography#2
No description provided.