Laurence
118dc36e92
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.
6 KiB
Decisions
A dated, append only log of decisions and their rationale. Newest at the top. Never rewrite past entries; if a decision is reversed, add a new entry that says so.
2026-07-21: blind solving goes to the estate's own solver first, nova second
The estate now runs Astrometry.net itself
(https://astrometry.ankh-morpork.discworld.network, config in
ankh-morpork-infra astrometry/): solve-field against ~5 GB of local index
files, sized from this repo's own TELESCOPES.md so it covers the whole
iTelescope fleet's fields of view (21.5 arcmin to 10.4 degrees).
blind.py now tries it before nova.astrometry.net. The order is not about
speed, though it is far faster - a blind solve of a real DSS field came back in
0.7s against nova's minutes-in-a-queue. It is that nova requires uploading
the image to a third party and an API key, and neither is now necessary for
the ordinary case. nova stays as the fallback for when the estate service is
unreachable or the field is narrower than the local index set reaches, so
losing the estate costs speed and privacy, not the ability to solve at all.
What deliberately did NOT change: the seeded solver in astrometry.py remains
the primary path (a good header beats a blind search), and every blind solution
- from either source - still has to pass the same Gaia verification and star-count/residual gate. A wrong WCS is worse than no WCS, and a second solver does not change that. The source is recorded in the ASTRSOLV card so it is always possible to tell later which one produced a frame's astrometry.
2026-07-21: the pipeline reads headers, not filenames
The first pipeline parsed calibrated-T32-...-Luminance-BIN2-W-300-001.fit to
learn a frame's filter, binning and exposure. That works for one telescope, one
binning and one exposure length. Three of the four archived sessions have no
luminance channel at all and one is from 2021 with different naming, so the
approach could not survive contact with the archive.
FITS headers carry FILTER, EXPTIME, XBINNING, OBJECT and DATE-OBS precisely so software does not have to guess, and iTelescope fills them in properly. The pipeline opens each frame and asks. Filter aliases are mapped, so H-alpha, Halpha and HA all resolve to Ha.
The colour scheme is then derived from what is present rather than assumed: LRGB, RGB without luminance, SHO, HOO, or mono. That is what lets one command handle a galaxy in LRGB and a nebula in narrowband without being told which is which.
2026-07-21: push-button imaging, hand-driven science
The imaging half - unzip, measure, register, stack, plate solve, compose - is mechanical and should run unattended on any session. The analyses are not: a globular cluster survey suits an elliptical galaxy and is meaningless for an emission nebula, and much of the value in the NGC 5128 work came from noticing when a result was wrong rather than from running the code. So the pipeline is being built to be push-button, and the science stays step by step.
2026-07-21: merge itelescope and astro-pipeline into one repository
The two were split by accident of chronology rather than by design. itelescope
began as a reference to the telescope network and grew into the campaign that
books and runs sessions; astro-pipeline was created three hours before this
merge to hold the processing code once it was moved out of the image directory.
They describe two halves of one activity, and the seam was already leaking: the
campaign's TODO referred to processing results held in the other repo, and the
processing code's README explained a campaign it did not contain.
Merged with both histories preserved, by relocating each repository's files
into a subdirectory in its own history first and then merging the unrelated
histories. 44 commits, and git log --follow still traces a file across the
move.
Layout: itelescope/ for the network and campaign, pipeline/ for the code,
observing/ for in-person plans, with the Default Workflow files (CLAUDE.md,
docs/, state/) at the top level governing the whole repository.
The old repositories are not deleted. The drain campaign is live until
10 Aug with sessions running most nights, and other sessions may be working in
itelescope at the moment of the merge. Both carry a notice pointing here.
Archive them once the campaign closes, not before.
2026-07-21: image data does not live in the repository
A single calibrated frame is 61 MB and a session runs to several gigabytes.
Sessions stay on disk, organised into named subdirectories, and the code finds
them through the ASTRO_SESSION environment variable. Each session carries its
own METHODS.md describing what was done and what was found, so the account of
the data travels with the data while the code travels separately.
2026-07-17: follow the Google Sheet, not the support article
The support article (https://support.itelescope.net/support/solutions/articles/247371) and the maintained Google Sheet (https://docs.google.com/spreadsheets/d/1jZWkkjewOuyNC9YzQ8y2d0pO1e4T7EBeysmQMPBVSOk/) disagree: the article lists T9, T19, T31, T69, which the sheet omits; the sheet has T25, T26, T59, T71-T75, T80, which the article lacks. The article itself points to the sheet as the current source, so the review follows the sheet and notes the discrepancy. The sheet CSV export is snapshotted in data/ so the review's numbers remain reproducible even if the sheet changes.
2026-07-17: single review document, not per-telescope files
23 active scopes each need only a spec block and a short assessment; one TELESCOPES.md grouped by observatory reads better and is easier to keep current than 23 stub files. Revisit if per-scope content grows (photos, session logs).
2026-07-17: no launchpad scraping
https://go.itelescope.net/ is an authenticated app shell with no public data. All content comes from public support pages and the public sheet; nothing in this repo requires iTelescope credentials.
Per-telescope detail pages, if ever needed: support.itelescope.net/support/solutions/articles/231901-231920 (older scopes), 245471 (T68), 251171 (T70), 251556 (T69), 251589 (T19).