Astrometry.net

Astrometry.net — набор программных инструментов и веб-сервис для автоматической астрометрической привязки астрономических изображений: он определяет, какой участок неба попал в кадр, вычисляет преобразование между пикселями и небесными координатами и возвращает стандартные WCS-метаданные. Продукт рассчитан на астрофотографов, операторов телескопов, разработчиков астрономического ПО, исследователей и владельцев больших коллекций снимков, которым нужно распознать поле даже при отсутствующих или неверных исходных координатах. Основная практическая задача Astrometry.net — превратить изображение со звёздным полем в кадр с проверяемой небесной привязкой, пригодный для идентификации объектов, автоматического наведения, каталогизации, дальнейшей научной обработки и интеграции в сценарии наблюдений.

Что именно представляет собой Astrometry.net

Название Astrometry.net относится не к обычному настольному приложению с единственным графическим окном, а к целому проекту. В его центре находится локальный решатель, который запускается набором команд, прежде всего solve-field. Рядом с ним существуют программы для извлечения источников из изображения, работы с индексами, преобразования координат, построения диагностических файлов и обслуживания WCS. Тот же подход используется веб-сервисом Nova, где пользователь загружает изображение через браузер и получает результат без локальной сборки кода и установки индексных файлов.

Такая идентификация важна, потому что Astrometry.net часто встречается внутри других продуктов. Некоторые программы вызывают локальный движок напрямую, другие обращаются к Nova через API, а Windows-оболочки могут включать собственную сборку Astrometry.net. Эти оболочки и интеграции не являются самой Astrometry.net. В этом обзоре предметом остаются исходный проект, его локальный solver и принадлежащий проекту веб-интерфейс.

Текущий публичный исходный пакет имеет версию 0.98. Пакет astrometry.net-0.98.tar.gz опубликован 19 ноября 2025 года и имеет размер 11 774 435 байт, то есть приблизительно 11,2 МБ. Репозиторий также показывает контейнер solver с тегом 0.98. При этом локальная работа требует не только кода программы: для поиска решения нужны отдельные астрометрические индексные файлы, и их суммарный объём может заметно превышать размер самого исходного пакета.

Для кого предназначена программа

Самый очевидный сценарий — астрофотография. После съёмки кадра пользователь может не знать точный центр поля, реальный масштаб или ориентацию камеры. Astrometry.net извлекает звёздоподобные источники, ищет характерные геометрические комбинации в индексах и строит WCS. Затем координаты центра, размер поля и масштаб в угловых секундах на пиксель можно использовать для подтверждения объекта съёмки, сравнения кадров разных ночей или передачи координат системе управления телескопом.

В автоматизированной обсерватории решатель играет роль независимой проверки положения. Монтировка может сообщать одну позицию, а фактический кадр — показывать другую. Plate solving даёт измеренную позицию по самому изображению. Управляющая программа способна сравнить её с целью, выполнить коррекцию наведения и повторить цикл. Astrometry.net удобна именно тогда, когда начальная подсказка о координатах отсутствует или ей нельзя полностью доверять.

Для старых коллекций и исследовательских задач ценность другая: старый FITS, JPEG или иной поддерживаемый снимок может не иметь пригодной WCS-привязки. После решения появляется связь между координатами пикселей и небесной сферой. Это позволяет сопоставлять изображения с каталогами, искать известные объекты в пределах поля и строить воспроизводимую пространственную привязку вместо ручного угадывания по звёздным рисункам.

Разработчикам Astrometry.net интересна двумя интерфейсами автоматизации. Локальный набор команд можно вызывать из скриптов и пайплайнов, контролируя имена выходных файлов, ограничения масштаба, область поиска и число вычислительных попыток. Веб-сервис предоставляет HTTP API: клиент создаёт сессию, отправляет файл или URL, получает идентификатор submission, отслеживает появившиеся jobs и забирает результаты, включая WCS и FITS с добавленной привязкой.

Модель распространения и лицензирование

Код Astrometry.net открыт. Части, написанные командой проекта, имеют трёхпунктовую BSD-лицензию, однако полный распространяемый комплект использует библиотеки GNU GPL, включая поставляемую с проектом часть GSL. Поэтому совместная работа распространяется по GNU GPL версии 3 или более поздней. Для пользователя это означает возможность изучать, собирать и модифицировать исходный код при соблюдении условий соответствующих лицензий, а для разработчика интеграции — необходимость учитывать лицензионные обязательства именно того способа распространения, который он выбирает.

Публичный релиз распространяется как сжатый исходный пакет, а готовые пакеты доступны через системные экосистемы. Для Debian и Ubuntu предусмотрена установка пакета astrometry.net, для macOS — формула Homebrew astrometry-net. Windows 10 и Windows 11 рассматриваются через Windows Subsystem for Linux: после установки WSL используются те же шаги, что для Debian/Ubuntu. Отдельно существует контейнерный образ solver, что удобно для воспроизводимого запуска без ручной установки всех файлов программы в основную систему.

Веб-сервис не требует локальной установки solver. Это отдельный способ доступа к той же классу задачи, но он меняет эксплуатационную модель: изображение передаётся на удалённый сервер, обработка зависит от очереди и доступности инфраструктуры, а скачивать локальные индексы не нужно. Для конфиденциальных или массовых наборов кадров локальный режим даёт больший контроль над данными и производительностью; для разового определения поля браузерный режим снимает требования к сборке и настройке.

Как Astrometry.net находит участок неба

Решатель не начинает с предположения, что координаты из заголовка FITS верны. Сначала из изображения формируется список заметных источников. Затем из взаимного расположения звёзд строятся геометрические фигуры — характерные «quads». В индексных файлах заранее сохранены аналогичные небесные ориентиры и структуры для их быстрого поиска. Совпадение кандидата само по себе недостаточно: найденная гипотеза проверяется по дополнительным звёздам поля, после чего вычисляется наиболее подходящее астрометрическое преобразование.

Именно наличие предварительно построенных индексов позволяет решать кадры без заранее известного центра. Индекс разбит по угловому масштабу, потому что геометрические фигуры, полезные для широкоугольного кадра, не совпадают по размеру с теми, которые нужны для малого телескопического поля. Чем точнее выбран диапазон подходящих индексов и чем разумнее заданы допустимые масштабы изображения, тем меньше лишних вариантов должен просмотреть solver.

Результатом является World Coordinate System — набор FITS-метаданных, описывающих переход от пиксельных координат к небесным. Для решённых кадров Astrometry.net формирует WCS-заголовок и при необходимости новый FITS с этим заголовком. В решении используются параметры центра, опорного пикселя и матрицы преобразования; для моделирования геометрических искажений программа также работает с полиномиальной коррекцией SIP. Это не просто подпись «объект найден», а численная модель координат изображения.

Интерфейс: командная строка и веб-сервис

Локальная Astrometry.net ориентирована на командную строку. Главная высокоуровневая команда — solve-field. Она принимает изображение или таблицу координат обнаруженных источников, организует извлечение звёзд, запускает backend solver и создаёт набор выходных файлов. Для диагностики доступны подробные сообщения, а параметры запуска позволяют задавать каталог результатов, конфигурацию backend, предел времени CPU, масштаб, область на небе, глубину поиска, downsampling и создание графиков.

Браузерный интерфейс Nova построен вокруг страниц Upload, Submission и страницы решённого изображения. В верхней навигации видны пункты Home, Explore, Upload, API и Support. На странице загрузки есть выбор файла или URL, кнопка Upload и раскрываемый блок Advanced Settings [+]. После отправки страница Submission показывает настройки, идентификатор задания, миниатюру, состояние Success при успешном решении, ссылку Go to results page, изображение извлечённых источников и журнал.

Форма Upload перечисляет поддерживаемые в браузерном сценарии типы входных данных: JPEG, GIF, PNG и FITS-изображения, FITS binary table со списком обнаруженных объектов, текстовый список координат X,Y и tar-пакет с файлами поддерживаемых типов. Для табличного входа важен порядок источников по яркости: solver должен получать список, пригодный для последовательного построения геометрических комбинаций.

На Submission отображаются фактические настройки конкретной отправки. Среди них встречаются Parity, Scale Units, Scale Type, Scale Lower Bound, Scale Upper Bound и Downsample Factor. Эти поля отражают те же классы ограничений, которые локально задаются параметрами solve-field: ориентация, способ задания масштаба, границы масштаба и предварительное уменьшение изображения.

После успеха страница результата объединяет два типа информации. Слева находится изображение с аннотациями распознанных объектов, справа — блоки Job Status и Calibration. В Calibration показываются центр поля в RA/Dec, размер, радиус, pixel scale и ориентация; ниже доступны файлы результата, в том числе WCS и новый FITS. Поэтому веб-интерфейс полезен не только для ответа «где снято», но и для быстрой проверки численных параметров привязки.

Основные команды локального интерфейса

solve-field закрывает типовой путь от исходного файла до готовой WCS. Для просмотра параметров используются -h или --help, а для увеличения диагностической подробности — -v или --verbose. Каталог результатов задаётся --dir, базовое имя — --out, альтернативная конфигурация backend — --backend-config или связанный параметр конфигурации.

Ограничения масштаба задаются параметрами --scale-low, --scale-high и --scale-units. Для масштаба доступны, в частности, единицы ширины поля в градусах, ширины в угловых минутах и угловых секунд на пиксель. Когда известны приблизительные RA и Dec, параметры --ra, --dec и --radius ограничивают поиск областью вокруг ожидаемого центра. Это не обязательные сведения: их назначение — сократить пространство поиска, когда приблизительная позиция всё же известна.

Для больших изображений предусмотрен --downsample, уменьшающий данные до извлечения источников. Параметр --no-plots отключает диагностические изображения, что полезно в headless-среде и в массовых задачах. --cpulimit уменьшает допустимое процессорное время относительно лимита backend. --no-verify запрещает предварительную проверку уже существующего WCS в FITS и заставляет перейти к обычному поиску решения.

Установка и первый запуск

Debian и Ubuntu

Самый короткий путь в Debian-подобной системе — установить пакет astrometry.net из пакетного менеджера. Для сборки исходников нужен набор компиляторов и библиотек: GNU build tools, Cairo, Netpbm, libpng, libjpeg, zlib, bzip2, Python 3, NumPy, SWIG версии не ниже 2.0, CFITSIO и Python-библиотека для FITS — fitsio, Astropy или совместимый вариант. В документации для Ubuntu 20.04 также перечислены pkg-config, wcslib, SciPy и PIL как компоненты окружения полного функционала.

После распаковки исходного пакета короткая последовательность сборки выглядит так: make, затем make py, make extra и make install. Установка по умолчанию помещает файлы в /usr/local/astrometry. Другой путь задаётся переменной INSTALL_DIR. Если команды не находятся из оболочки, каталог INSTALL_DIR/bin добавляют в PATH.

macOS

Для macOS предусмотрена формула Homebrew. Команда brew install astrometry-net устанавливает пакет из core-репозитория Homebrew. Этот путь снимает часть ручной работы с зависимостями. После установки всё равно нужно решить вопрос с индексами: пакет solver и астрометрические данные — разные сущности, и наличие исполняемых файлов без подходящих индексных серий не делает локальное решение готовым к работе.

Windows 10 и Windows 11

Документированный путь для современных Windows — WSL. Сначала включается Windows Subsystem for Linux и устанавливается Linux-дистрибутив, после чего используются шаги Debian/Ubuntu. Это принципиально отличается от нативного Windows-инсталлятора: исполняемые файлы работают в Linux-окружении WSL. Если стороннее астрономическое приложение требует обычный Windows EXE или COM-компонент, оно может использовать отдельную оболочку либо другой solver; такой компонент нельзя автоматически считать текущей Astrometry.net 0.98.

Docker

Контейнерный вариант позволяет запускать solve-field в образе astrometrynet/solver:0.98. Рабочий каталог монтируется в контейнер, чтобы исходный снимок и полученные файлы оставались на хосте. Отдельный каталог с индексами можно примонтировать в /usr/local/data. Такой подход полезен для серверов, CI-процессов и повторяемых вычислительных окружений: версия solver фиксируется тегом контейнера, а массив индексных данных хранится отдельно.

Первая проверка установки

Перед обработкой собственных кадров полезно разделить проверку на три уровня. Сначала убедиться, что solve-field --help запускается и выводит справку. Затем проверить, что astrometry.cfg указывает на каталог, где действительно лежат индексы. После этого запустить решение на тестовом изображении и проверить появление файла .solved и WCS. Такой порядок быстрее локализует проблему: отсутствие команды относится к установке, отсутствие индексов — к данным и конфигурации, а неудача на конкретном кадре — уже к масштабу, извлечению источников или качеству изображения.

Индексные файлы: что нужно установить кроме программы

Индексы — обязательная часть локального plate solving. Они построены из астрометрических каталогов и содержат небесные ориентиры, с которыми сравниваются геометрические фигуры из кадра. Серии разделены по масштабу, а более мелкие угловые поля требуют крупных наборов данных. Скачивать все доступные индексы без необходимости невыгодно: лишние серии увеличивают объём хранения и заставляют solver рассматривать заведомо неподходящие варианты.

Практическое правило выбора основано не на полном размере кадра, а на размере quad-ориентиров, которые должны помещаться в изображение. Для квадратного поля около одного градуса документация приводит диапазон ориентиров примерно от 0,1 до 1 градуса и рекомендует попробовать серии 5203–5206 и 4107–4109, а затем сузить набор до тех индексов, которые дают устойчивый результат быстрее. Это хороший шаблон: начать с диапазона, покрывающего задачу, и убрать заведомо лишние масштабы после проверки на собственном материале.

Файлы можно поместить в INSTALL_DIR/data или установить из каталога исходников через make install-indexes. Дополнительные пути прописываются в INSTALL_DIR/etc/astrometry.cfg. Если backend не видит ни одного индекса, plate solving не начнётся, даже если сама команда solve-field установлена корректно.

Базовый рабочий процесс в локальном режиме

1. Подготовьте исходник. Для обычного изображения достаточно поддерживаемого растрового или FITS-файла. Если звёзды уже обнаружены другим инструментом, можно передать таблицу X,Y вместо повторного поиска источников.
2. Выберите индексы. Убедитесь, что установлен хотя бы один набор, соответствующий угловому размеру поля и масштабу звёздных комбинаций.
3. Запустите solve-field. Для первого теста используйте минимальное число ограничений. Если приблизительный масштаб известен, сразу задайте нижнюю и верхнюю границы — это уменьшит объём поиска.
4. Проверьте статус. Файл [base].solved содержит бинарную единицу при успешном решении. Журнал -v помогает понять, какие индексы и этапы использовались.
5. Откройте WCS. [base].wcs содержит FITS WCS-заголовок, а [base].new — новый FITS с добавленной привязкой.
6. Сверьте геометрию. Используйте диагностические изображения, координаты центра, pixel scale и аннотацию, чтобы убедиться, что решение совпадает со звёздным полем, а не только завершилось технически.

Простой запуск имеет вид solve-field image.fits. Когда известна ширина поля от одного до двух градусов, полезно указать --scale-units degwidth --scale-low 1 --scale-high 2. При известном масштабе камеры можно работать в arcsecperpix. Для приблизительно известного положения ограничение через --ra, --dec и --radius уменьшает область, в которой разрешено искать решение.

Если входной FITS уже содержит WCS, solve-field пытается его проверить перед полным поиском. Это удобно при повторной обработке и контроле старых заголовков. Параметр --no-verify отключает этот этап. При этом поддержка проверки существующего заголовка ограничена подмножеством WCS: документация отдельно отмечает TAN-проекцию с CD-матрицей как основной понимаемый вариант, поэтому нельзя считать программу универсальным валидатором всех допустимых FITS WCS-конструкций.

Какие файлы создаёт solve-field

Не каждый рабочий процесс должен сохранять все эти файлы. В автоматизированном серверном запуске часто достаточно маркера .solved, WCS и нового FITS; графические PNG можно отключить через --no-plots. При поиске причин неудачи, наоборот, диагностические таблицы и графики помогают определить, на каком этапе возникла проблема: извлечение источников, выбор индекса, сопоставление или финальная верификация.

Рабочий процесс через Nova в браузере

1. Откройте страницу Upload и выберите локальный файл или режим URL.
2. При необходимости раскройте Advanced Settings и задайте известные ограничения масштаба, parity, downsampling или область поиска.
3. Нажмите Upload. После принятия файла появляется Submission, который может породить одно или несколько jobs.
4. Следите за статусом. При успешной обработке появляется зелёный Success и ссылка Go to results page.
5. На странице результата проверьте блок Calibration: центр RA/Dec, размер поля, pixel scale и ориентацию.
6. При необходимости скачайте WCS, новый FITS и дополнительные таблицы результатов.

Веб-режим особенно удобен для одиночного незнакомого кадра: не нужно подбирать и хранить локальный массив индексов. Однако это не делает его эквивалентом локальному пакетному solver. Файл передаётся на сервер, задача попадает в очередь, а время ответа зависит не только от изображения. Для регулярной съёмки и автоматизации стабильнее контролировать solver локально, если пользователь готов выделить место под индексы и один раз настроить окружение.

Ключевые функции Astrometry.net

Решение без доверия к исходным координатам

Главная функция — all-sky plate solving. Метаданные изображения могут отсутствовать или быть неверными, а алгоритм всё равно пытается определить поле по геометрии звёзд. Это отличает Astrometry.net от методов, которые требуют довольно точной стартовой позиции и просматривают только близкую область каталога. Подсказки о положении и масштабе поддерживаются, но используются как средство ускорения, а не как обязательная основа идентификации.

Ограничение масштаба

Параметры масштаба позволяют перевести знание оптики в вычислительное преимущество. Можно задавать ширину поля или pixel scale. Solver использует границы при выборе индексных файлов и при отбрасывании quad-сопоставлений, которые дали бы невозможный масштаб. Это один из самых полезных способов ускорить обработку без изменения алгоритма и качества исходного кадра.

Ограничение области неба

Когда приблизительный центр всё же известен, поиск ограничивается кругом заданного радиуса вокруг RA,Dec. Такой режим полезен для автоматического центрирования телескопа: монтировка обычно знает хотя бы приблизительное положение, поэтому нет смысла каждый раз просматривать всё небо. Для неизвестного старого кадра эти параметры можно не задавать.

Проверка существующего WCS

FITS с уже записанной привязкой можно предварительно проверить. Это полезно при обработке старых коллекций, где метаданные есть, но их надёжность неизвестна. Если проверка не подтверждает заголовок, solver способен перейти к поиску нового решения. При необходимости проверку отключают и принудительно выполняют обычное решение.

Извлечение источников и работа с готовыми XY-списками

Astrometry.net может сама извлекать звёздоподобные источники из изображения, но также принимает подготовленные списки X,Y. Это важно в научных пайплайнах: если предобработка уже включает собственный детектор источников с известными параметрами, нет необходимости повторять её внутри solver. Формат FITS BINTABLE и текстовый список позволяют отделить детекцию от собственно астрометрического сопоставления.

Диагностические и аннотационные результаты

Помимо WCS создаются визуальные материалы: карта извлечённых источников, совмещение источников изображения с индексными звёздами и аннотированный кадр. Эти файлы особенно полезны при неудачных или сомнительных решениях. Числовой WCS следует проверять не изолированно, а вместе с тем, насколько каталожные позиции совпадают со звёздами по всему полю.

Пакетный и headless-запуск

Командная архитектура хорошо подходит для оболочек, cron-задач, контейнеров и серверных очередей. Входные имена можно подавать из stdin, графики отключать, каталог результатов задавать отдельно, а по файлу .solved скрипт способен определить успех без разбора визуального интерфейса. Такой режим — одна из причин, по которой Astrometry.net часто используется как компонент другого астрономического ПО.

Форматы, импорт, экспорт и интеграции

В браузерной форме прямо перечислены JPEG, GIF, PNG и FITS image. Кроме полноценных изображений принимаются FITS binary tables с координатами обнаруженных объектов и текстовые списки X,Y, а tar-пакет может содержать поддерживаемые типы. В локальном solve-field входом также служат изображения и XYLS-таблицы; URL допускается передать непосредственно команде, после чего файл будет получен внешним загрузчиком.

Для растровых форматов локальная цепочка использует вспомогательные средства преобразования в формат, удобный для source extraction. FITS обрабатывается непосредственно в астрономическом контексте, а готовые списки источников позволяют миновать этап преобразования изображения. Поэтому понятие «поддерживаемый формат» здесь связано не с редактированием изображения, как в графическом редакторе, а с возможностью получить из входа координаты звёзд и передать их solver.

На выходе центральный формат — FITS WCS. .wcs хранит заголовок решения, .new создаёт новый FITS с добавленной привязкой, .rdls, .axy, .match и .corr передают промежуточные и сопоставленные таблицы. Веб-API выдаёт аналогичные артефакты по URL результатов: WCS file, new FITS file, RDLS, AXY, CORR и изображения визуализации.

Python участвует в сборке и части инструментов проекта; для FITS используются fitsio, Astropy или совместимые библиотеки. На уровне автоматизации стороннее приложение может не импортировать Astrometry.net как единую библиотеку: проще и устойчивее вызвать solve-field как процесс, обработать код завершения и наличие .solved, затем читать WCS стандартными средствами FITS. Веб-сценарий, наоборот, естественно интегрируется через HTTP API и идентификаторы submission/job.

Веб-API: как устроена автоматизация

Клиент сначала выполняет логин и получает session key. Для загрузки файла используется multipart/form-data: JSON-параметры передаются в текстовой части request-json, а сам файл — как application/octet-stream. Альтернативный endpoint позволяет отправить URL изображения, чтобы сервис получил его самостоятельно. После приёма сервер возвращает идентификатор submission.

Submission — не то же самое, что job. Одна отправка может породить ноль, одну или несколько задач. Клиент опрашивает состояние submission, получает список job IDs и затем проверяет конкретные jobs. Такое разделение важно для надёжного кода: нельзя считать, что идентификатор ответа на upload уже является готовым идентификатором решения.

После успешной job доступны машинные результаты. В числе документированных путей — WCS, новый FITS, RDLS, AXY, CORR, аннотированный display, красно-зелёное диагностическое изображение и изображение source extraction. Это позволяет построить сервис, который не открывает браузер: загрузить кадр, дождаться solve, сохранить WCS и передать его следующему этапу обработки.

API поддерживает те же смысловые ограничения, что веб-форма: масштаб, примерное положение, публичность и лицензионные параметры отправки. Для автоматизации важно явно задавать те значения, от которых зависит политика данных. Ключ API и session key следует рассматривать как учётные данные: их не нужно встраивать в публичный исходный код, журнал ошибок или HTML-страницу.

Продвинутые сценарии

Калибровка старых кадров без надёжного заголовка

Для коллекции с разнородными метаданными безопаснее не доверять старым координатам автоматически. Astrometry.net способна решать изображение all-sky, а затем сохранить новый FITS. Дальнейший каталогизатор получает однородный WCS независимо от того, как снимок был подписан при создании. В этом сценарии полезно сохранять исходный файл отдельно и записывать решение в новый файл, чтобы астрометрическая нормализация оставалась обратимой.

Автоматическое центрирование телескопа

Система управления съёмкой делает короткий кадр, запускает solver, сравнивает измеренный центр с целью и корректирует монтировку. Для такого цикла выгодно задавать приблизительные RA/Dec и масштаб: необходимость all-sky устойчивости остаётся страховкой, но типичная задача ограничивается небольшой областью. Важно, чтобы выбранное внешнее приложение умело интерпретировать результат Astrometry.net и безопасно отправлять корректирующую команду монтировке; сам solver не является полноценной программой управления телескопом.

Большие изображения

Для кадров с очень большим числом пикселей source extraction может стать заметной частью времени. --downsample 2 или --downsample 4 уменьшает изображение перед обнаружением источников. Это не универсальная настройка «чем больше, тем лучше»: чрезмерное уменьшение способно стереть слабые или тесные звёздные профили. Значение подбирают так, чтобы сократить обработку, сохранив достаточную структуру поля.

Малые поля и крупные индексы

Узкие телескопические поля требуют индексных серий с малыми quad-ориентирами. Именно эти данные обычно тяжелее широкоугольных наборов. Поэтому сервер, который должен решать разные фокусные расстояния, планируют не по 11,2 МБ исходного пакета, а по объёму всех нужных индексов и кэшу операционной системы. Если прибор имеет фиксированную оптику, хранение только подходящих серий экономит диск и ускоряет обход.

Собственные индексы

Проект включает инструменты подготовки каталогов, их uniformization, deduplication, разрезания и построения индексных файлов. Это не обязательная часть пользовательского сценария: готовые индексы закрывают большинство задач. Собственные индексы нужны, когда исследователь хочет контролировать исходный каталог, область неба, плотность или набор объектов. Такой путь требует понимания структуры индекса и отличается по сложности от обычного solve-field.

Конфигурация backend и воспроизводимая установка

Локальная Astrometry.net разделяет пользовательскую команду solve-field и backend-конфигурацию, которая сообщает astrometry-engine, где лежат индексы и какую политику поиска применять. В типовой конфигурации строка add_path /путь/к/индексам добавляет каталог в список поиска, а директива autoindex загружает обнаруженные там индексные файлы. Вместо автоматического поиска разрешено перечислять конкретные файлы директивами index. Это полезно для сервера, где одна директория содержит больше данных, чем нужно определённой камере.

Параметр --backend-config у solve-field позволяет не менять системную конфигурацию. Для двух телескопов можно держать отдельные cfg-файлы: один с широкоугольными индексами, другой с сериями для малого поля. Тогда одинаковая версия solver запускается с разной политикой поиска без копирования исполняемых файлов. Такой способ проще проверять и переносить между машинами, чем ручное комментирование строк в единственном глобальном файле перед каждой сессией.

Конфигурация также понимает minwidth, maxwidth, cpulimit, depths и inparallel. Эти директивы задают политику backend по умолчанию, тогда как часть параметров конкретного кадра передаётся через solve-field. Разделение полезно в многопользовательской системе: администратор ограничивает предельное процессорное время и набор индексов на уровне сервиса, а отдельная задача задаёт собственный scale range и ожидаемый центр.

inparallel относится к способу проверки индексов и имеет смысл только при подходящем объёме памяти. Комментарии в конфигурации связывают этот режим с возможностью держать используемые индексы в физической памяти. Поэтому включать его автоматически на машине с большим набором данных и небольшой RAM не следует. Для конкретного сервера правильнее измерить resident set и page faults на типичной серии кадров, а затем решить, выгодно ли параллельное обращение.

Воспроизводимая установка фиксирует четыре группы параметров. Первая — версия Astrometry.net, например 0.98. Вторая — точные серии индексных файлов и их расположение. Третья — backend cfg, включая лимиты и способ загрузки индексов. Четвёртая — параметры конкретного запуска: scale, позиционные ограничения, downsample, depth и создание plots. Если сохранены только команды, но после обновления заменились индексы или конфигурация, сравнивать производительность разных запусков уже некорректно.

Для контейнера эта модель особенно ясна. Код solver фиксируется тегом образа, рабочий каталог снимков монтируется отдельно, а индексный каталог подключается отдельным volume. Обновление контейнера не обязано затрагивать гигабайты индексных данных. И наоборот, можно заменить или дополнить индексную серию без пересборки контейнера. Такая декомпозиция удобна для резервного копирования: пользовательские снимки, индексные данные и собственная конфигурация имеют разные жизненные циклы.

Тонкая настройка solve-field без изменения алгоритма

Scale bounds как первый фильтр

Когда известен приблизительный размер поля, --scale-low и --scale-high должны описывать реалистичный диапазон, а --scale-units — выбранный способ измерения. Для системы с известным pixel scale естественны arcsecperpix; для кадра, где проще оценить полную ширину, подходят единицы ширины поля. Solver использует эти ограничения до финальной подгонки WCS, поэтому они уменьшают число индексов и quad-кандидатов, которые вообще имеют смысл рассматривать.

Границы не должны быть чрезмерно узкими. Изменение фокусного расстояния, binning, crop, resampling или неверные метаданные могут сдвинуть фактический масштаб. Диагностический приём прост: если кадр решается без scale bounds, но не решается с ними, проблема находится не в индексах и не в source extraction, а в заданном диапазоне. После этого диапазон расширяют до фактических значений и только затем оптимизируют.

Guess scale и проверка заголовка

--guess-scale просит solve-field попытаться извлечь оценку масштаба из FITS-метаданных. Это компромисс между полностью неизвестным полем и ручным вводом: если значения в заголовке пригодны, поиск сокращается; если нет, сама возможность all-sky решения сохраняется. Для коллекций с сомнительными метаданными этот режим полезнее жёсткого доверия к одному полю заголовка.

Отдельно работает верификация уже существующего WCS. Перед all-sky поиском solve-field может попытаться подтвердить записанную привязку. Если требуется независимое повторное решение, используется --no-verify. Это важно в тестах качества: проверка старого WCS и построение нового WCS — разные задачи, и их результаты нельзя смешивать при сравнении двух методов калибровки.

Depth и порядок перебора источников

Solver начинает с ярких источников и строит комбинации, постепенно вовлекая более глубокие позиции списка. --depth задаёт диапазоны, на которых он переключается между индексами. Например, последовательность 20,30,40 означает сначала работу с наиболее яркими источниками до 20-го, затем расширение до 30 и до 40. Несколько диапазонов можно задавать отдельно. Это позволяет управлять тем, сколько усилий тратится на один индекс до перехода к другому.

Depth имеет смысл настраивать после того, как проверены scale bounds и индексы. Слишком ранняя микротюнинг-попытка может маскировать базовую ошибку: solver старательно перебирает неправильные масштабы. На стабильной установке depth полезен для сложных полей, где ярчайшие объекты не образуют удачного quad, но следующий слой источников уже даёт достаточную геометрию.

Downsample и source extraction

Downsampling выполняется до извлечения источников. Для многомегапиксельного кадра это уменьшает число пикселей, которые нужно анализировать, и может ускорить начало решения. Но оптимизация проверяется по -objs.png: если после уменьшения реальные звёзды сохраняются как компактные источники и шум не доминирует, настройка полезна. Если слабые звёзды исчезают или близкие профили сливаются, коэффициент уменьшают.

Параметр --resort меняет способ сортировки обнаруженных звёзд по яркости, используя background-subtracted оценки. Документация связывает его с изображениями без выраженной туманности, где оценка фона работает лучше. Это не обязательная опция для каждого кадра; её рассматривают, когда исходный порядок источников мешает solver быстро добраться до геометрически полезных звёзд.

CPU limit и политика отказа

--cpulimit задаёт меньший лимит процессорного времени для конкретной задачи, но не может увеличить потолок, установленный backend-конфигурацией. Это принципиально для серверной очереди: пользователь не должен обходить системный лимит одной командой. Если кадры регулярно упираются в ограничение, сначала проверяют масштаб, индексы и source extraction; простое увеличение времени без диагностики лишь откладывает тот же отказ.

При массовой обработке лимит нужно выбирать вместе с политикой повторов. Первый проход может использовать узкий ожидаемый scale range и небольшой radius; неудачные кадры отправляются во второй проход с более широкими ограничениями. Такой двухступенчатый pipeline сохраняет скорость для нормальных кадров и оставляет all-sky устойчивость только тем задачам, которым она действительно нужна.

Plots и минимальный серверный результат

--no-plots отключает создание PNG-диагностики. В автоматической ночной сессии это уменьшает лишнюю работу и количество файлов, если оператор всё равно анализирует только WCS и смещение монтировки. Для тестовой выборки plots лучше оставить: -objs.png показывает source extraction, а -indx.png — связь извлечённых источников с индексными звёздами и решающим quad. После валидации конфигурации их можно отключить в основном потоке и включать только при ошибке.

Контроль WCS после успешного решения

Успешный статус означает, что solver принял гипотезу, но рабочий pipeline всё равно должен проверить, что дальнейшее ПО читает сохранённую привязку так же. Самая простая проверка — открыть .new независимой FITS-библиотекой и получить координаты центра. Они должны совпадать с теми, что вывел solve-field или блок Calibration в Nova в пределах ожидаемой точности представления.

Следующий тест использует несколько звёзд в разных частях кадра. Их пиксельные координаты преобразуются через WCS в RA/Dec и сравниваются с каталожными позициями. Проверка только центра не обнаруживает ошибку масштаба, ориентации или искажения по краям. Распределённые по полю точки дают гораздо более информативную картину.

Файл .corr предназначен именно для соответствий между источниками изображения и референсным каталогом, а .match описывает quad-сопоставление, которое привело к решению. Эти таблицы полезны, если нужно доказать, почему конкретное поле было принято solver, а не просто визуально посмотреть аннотацию. В научной обработке такую информацию можно сохранять вместе с логом версии и параметрами запуска.

WCS из Astrometry.net обычно используется как вход для следующего программного слоя: фотометрии, каталогового cross-match, построения мозаики, управления телескопом или визуализации. Поэтому финальная проверка должна выполняться тем же классом библиотек, который будет читать результат дальше. Если downstream-компонент понимает не все SIP-параметры или ожидает другую запись матрицы, проблема проявится уже после правильного plate solve; это вопрос совместимости потребителя WCS, а не обязательно ошибка Astrometry.net.

Производительность и факторы скорости

Для Astrometry.net нельзя корректно обещать фиксированное время решения. Оно зависит от размера изображения, качества source extraction, ширины поиска, числа и масштаба установленных индексов, дисковой подсистемы, доступной памяти и параметров solver. В веб-сервисе к этому добавляются сетевой обмен и очередь чужих заданий.

Наиболее предсказуемое ускорение даёт правильный диапазон масштаба. Если solver знает, что кадр имеет ширину один-два градуса, ему не нужно проверять индексы с quads, которые физически не помещаются в такой кадр. Аналогично ограничение по RA/Dec/radius полезно, когда положение приблизительно известно. Эти параметры уменьшают число кандидатов до дорогостоящей финальной проверки и не требуют модифицировать изображение.

Второй фактор — набор индексов. Документация прямо предупреждает, что лишние индексные файлы замедляют solver при сохранении того же ожидаемого результата. Для фиксированной камеры разумно определить диапазон масштаба один раз, оставить подходящие серии и провести серию контрольных кадров по разным участкам неба. Массовая установка всех серий имеет смысл только у универсального сервера с разными телескопами и полями.

Третий фактор — память и файловый кэш. Поиск активно читает структуры индексов; Unix-подобные системы используют memory mapping, поэтому повторные обращения к уже прочитанным блокам выигрывают от достаточного объёма физической памяти. Это не превращается в единое минимальное число гигабайт: нужный объём определяется индексами и параллельной нагрузкой. При проектировании сервера полезнее измерить рабочий набор на своих индексах, чем ориентироваться на абстрактную «рекомендованную RAM».

--no-plots убирает построение диагностических изображений, а downsampling сокращает объём source extraction на больших кадрах. --depth управляет тем, как solver перебирает группы самых ярких источников и переключается между индексами. Эти опции относятся к тонкой настройке. Первой мерой при медленной работе всё равно остаётся корректное ограничение масштаба и удаление ненужных индексных серий.

Системные требования

Для локального solver не опубликованы универсальные минимальные значения CPU, RAM и свободного места, поэтому корректнее описывать требования по компонентам. Код ориентирован на Linux/Unix-подобные системы и macOS; для Windows 10/11 документирован запуск через WSL. Готовый пакет доступен в Debian/Ubuntu, а для macOS — через Homebrew. Исходная сборка требует компилятора и набора научных и графических библиотек.

Полный набор зависимостей особенно важен при сборке из исходников. Если некоторые библиотеки недоступны, базовые части solver всё ещё могут собраться, но будет потеряна часть вспомогательных и графических функций. Поэтому для рабочего сервера лучше либо использовать поддерживаемый пакет дистрибутива, либо воспроизводимую контейнерную сборку, либо фиксировать список пакетов и версий в инфраструктурном коде.

Отзывы пользователей и профильных изданий

Что отмечают пользователи

В пользовательских обсуждениях повторяется характерный компромисс между устойчивостью all-sky поиска и скоростью. Астрофотографы нередко оставляют Astrometry.net как резервный blind solver, когда быстрый локальный решатель не справляется или исходная позиция сильно ошибочна. При этом обращения к Nova могут быть заметно медленнее локального решения из-за загрузки файла и очереди сервера; в обсуждениях встречаются как быстрые успешные решения сложных кадров, так и ожидание при перегруженной службе.

Отдельная группа отзывов касается доступности веб-сервиса. В 2025–2026 годах в сообществе фиксировались сообщения об ошибках HTTP 500, кратковременной недоступности из-за инфраструктурных проблем и очереди обработки. Это не говорит о качестве самого алгоритма, но влияет на выбор режима: удалённый Nova удобен для разовых задач, а автоматическая ночная съёмка требует плана на случай, если внешний сервис недоступен.

Локальные пользователи чаще всего сталкиваются не с «неправильной кнопкой», а с индексами. Неверный путь в конфигурации, отсутствующая подходящая серия или слишком широкий набор данных могут соответственно полностью остановить solver или сделать его медленным. В поддержке встречается типовая диагностическая ошибка о том, что в конфигурации не перечислен ни один index. Это одна из причин, по которой установка Astrometry.net фактически состоит из двух независимых этапов: сам код и данные.

Профессиональная и учебная оценка

Руководство American Association of Variable Star Observers (AAVSO) для DSLR-наблюдений использует Astrometry.net как способ определить поле зрения и координаты кадра без предварительного ввода небесной позиции: после Upload предлагается открыть Go to results page и сверить центр, размер поля, pixel scale и orientation. Профильный журнал Astronomy также описывает Astrometry.net как практический инструмент идентификации объектов на собственных астрофотографиях через загрузку изображения и аннотированный результат. В университетских учебных материалах сервис применяется для blind astrometric registration, причём результатом считают не только картинку с подписями, но и файлы new-image.fits и wcs.fits, которые продолжают научный workflow.

Научная основа проекта опубликована в Astronomical Journal в работе 2010 года о blind astrometric calibration произвольных астрономических изображений. Для исследовательского ПО это важная особенность: метод, лежащий в основе продукта, описан в рецензируемой литературе, а код изначально выпускался в том числе для воспроизводимости результатов. С годами проект стал практичнее для широкого круга пользователей, но его интерфейс по-прежнему ближе к научному Unix-инструментарию, чем к мастеру установки «далее — далее — готово».

Ограничения и границы применимости

Astrometry.net решает астрометрию, а не весь цикл астрофотографии. В проекте нет полноценного планировщика ночи, управления камерой, автофокусировки, guiding, стэкинга конечного изображения или развитой ручной обработки. Эти задачи выполняют другие приложения, которые могут вызывать Astrometry.net как один этап. Поэтому оценивать solver по отсутствию фоторедакторских функций некорректно; его ценность определяется качеством привязки и удобством интеграции.

Локальная установка сложнее обычной пользовательской программы. Помимо исполняемых файлов нужны научные библиотеки и индексы, а выбор серий требует понимания поля зрения. На Windows документированный путь идёт через WSL, что добавляет слой Linux-окружения. Пользователь, которому нужен только графический Windows-интерфейс, обычно выбирает оболочку или другой plate solver, а не собирает исходный Astrometry.net вручную.

Качество входа остаётся критическим. Если на кадре слишком мало пригодных звёзд, они сильно размыты, закрыты облаками, насыщены или теряются в шуме и туманности, source extraction может сформировать плохой список. Solver не восстанавливает отсутствующую информацию. При проблемах сначала проверяют сами обнаруженные источники, а уже затем увеличивают предел времени или добавляют индексы.

Очень узкое поле повышает требования к индексам и объёму данных. Очень большое изображение увеличивает стоимость source extraction. Неизвестный масштаб расширяет пространство поиска. Все эти факторы не означают, что задача обязательно не решится, но объясняют, почему один кадр обрабатывается быстро, а другой при тех же CPU и версии требует гораздо больше попыток.

Веб-сервис добавляет ограничения удалённой инфраструктуры. Для отправки нужен интернет, файл покидает локальную машину, а очередь не находится под контролем пользователя. Нет основания обещать фиксированное время ответа или постоянную доступность. Для автоматизации, где пропуск solve ломает всю ночь наблюдений, локальный режим или резервный solver уменьшают зависимость от внешнего сервера.

Безопасность и приватность

Главное различие проходит между локальным и веб-режимом. При локальном solve-field изображение обрабатывается на машине пользователя; после предварительной загрузки индексов сетевое соединение для самой задачи не требуется. Это предпочтительно для неопубликованных научных данных, частных коллекций и автоматических систем, где передача кадров наружу запрещена внутренними правилами.

Nova принимает изображения на удалённую инфраструктуру. В API предусмотрены параметры публичной видимости и лицензионных разрешений для отправки. Перед использованием в закрытом проекте нужно явно проверить выбранную видимость и не полагаться на случайные настройки предыдущей сессии. Если политика организации запрещает внешнюю передачу, правильное решение — локальный solver, а не попытка скрыть файл внутри обычного веб-запроса.

Ключ API и session key не являются частью астрометрических данных и должны храниться как секреты автоматизации. Их не следует записывать в публичный репозиторий, вставлять в клиентский JavaScript или выводить в журналы, доступные третьим лицам. Для контейнера с локальным solver важнее другое: каталог входных данных и индексов монтируется явно, поэтому права файловой системы можно ограничить теми директориями, которые действительно нужны процессу.

Типичные ошибки и диагностика

Ошибка конфигурации индексов

Это самая механическая неисправность. Файл может лежать на диске, но backend не увидит его, если каталог не указан в конфигурации или имя пути содержит опечатку. Проверка должна включать три уровня: файл реально существует, процесс имеет право чтения, astrometry.cfg указывает на правильный каталог. Добавление новых индексов не исправит ошибочный путь.

Неподходящий масштаб

Если установлен только широкоугольный индекс, он не решит очень маленькое телескопическое поле. Обратная ситуация тоже неэффективна. Сначала оцените поле зрения по фокусному расстоянию, размеру сенсора или уже известному pixel scale; затем сопоставьте его с диапазоном серий. Даже грубая оценка лучше установки десятков файлов без понимания их назначения.

Плохое извлечение звёзд

Откройте -objs.png или Source extraction image. Если отметки массово попадают на шум, горячие пиксели или детали туманности, проблема возникает до геометрического поиска. Если выделено очень мало реальных звёзд, бессмысленно только увеличивать CPU limit. Сначала исправляют вход: фокус, экспозицию, калибровку или параметры предобработки, затем повторяют solve.

Слишком жёсткие подсказки

Ограничения ускоряют работу, только когда они близки к правде. Неверный диапазон масштаба или слишком малый радиус вокруг ошибочного RA/Dec исключит правильное решение. Если кадр не решается с подсказкой, повторный тест с более широким диапазоном помогает отделить ошибку метаданных от проблемы изображения или индекса.

Как проверить, что решение действительно пригодно

Первый уровень — технический: существует .solved с признаком успеха, а .wcs и .new сформированы без ошибки. Этого достаточно для автоматики, чтобы перейти к следующему шагу, но недостаточно для научной проверки неизвестного набора.

Второй уровень — визуальный. На аннотированном изображении подписи известных звёзд и объектов должны находиться в логичных местах, а диагностическое совмещение индексных и обнаруженных источников должно совпадать по всему полю. Ошибка, растущая к краям, может указывать на проблемы геометрической модели, и её нельзя обнаружить, проверяя только координаты центра.

Третий уровень — численный. Сравните pixel scale с ожидаемым для камеры и оптики, размер поля — с геометрией сенсора, а RA/Dec центра — с объектом съёмки или координатами монтировки. Для известной установки сильное расхождение этих величин — повод проверить, не использованы ли неправильные ограничения, индекс или входной файл.

Четвёртый уровень — независимое применение WCS. Возьмите несколько пиксельных координат звёзд из разных частей кадра, преобразуйте их в RA/Dec стандартной FITS-библиотекой и сопоставьте с каталогом. Такой тест проверяет не только страницу результата, но и то, что сохранённый WCS корректно читается последующим ПО.

Плюсы и минусы

Плюсы:

• решает поле без обязательных исходных координат и умеет работать при отсутствующей или недостоверной WCS;
• возвращает стандартные FITS WCS-метаданные, пригодные для дальнейшей астрономической обработки;
• поддерживает локальный headless-режим, браузерный сервис и HTTP API;
• принимает не только изображения, но и готовые списки обнаруженных источников X,Y;
• позволяет ограничивать масштаб и область неба для ускорения известного сценария;
• создаёт диагностические таблицы и изображения, по которым можно разбирать качество решения;
• исходный код открыт, а современная ветка поддерживает Python 3 и NumPy 2;
• может работать полностью локально после установки подходящих индексных данных;
• подходит для автоматизации через solve-field, stdin, маркер .solved и контейнерный запуск.

Минусы:

• локальная установка требует отдельных индексных файлов и понимания их масштаба;
• для Windows 10/11 основной документированный путь использует WSL, а не нативный графический установщик;
• размер исходного пакета не отражает реальный объём установки, потому что индексы могут занимать значительно больше места;
• лишние индексы и отсутствие ограничений масштаба способны заметно увеличить время поиска;
• веб-сервис требует передачи изображения наружу и зависит от сетевой доступности и серверной очереди;
• интерфейс локальной версии ориентирован на командную строку и сложнее для пользователя, ожидающего обычное GUI-приложение;
• успех зависит от качества обнаруживаемых звёзд: сильно размытый, шумный или бедный звёздами кадр может не дать решения;
• проверка существующего FITS WCS понимает не все возможные стандартизованные варианты заголовков.

Сравнение с аналогами

Astrometry.net разумно сравнивать с plate solvers, а не с программами обработки изображений в целом. ASTAP и PlateSolve2 решают ту же практическую задачу определения небесной привязки, но делают иной акцент. Сравнение ниже нужно для понимания сценария; оно не превращает эти продукты в замену всем компонентам Astrometry.net, потому что у Astrometry.net есть ещё Nova, API и инструменты построения индексов.

ASTAP проще рекомендовать пользователю, которому нужен локальный графический solver с готовыми установщиками для нескольких ОС и одной выбранной звёздной базой. Astrometry.net выигрывает, когда особенно важна способность решать кадр без доверия к стартовым координатам, нужен веб-API или требуется прозрачный Unix-пайплайн. PlateSolve2 остаётся компактной Windows-утилитой, но требует отдельного каталога и сильнее привязан к сценарию с известной областью поиска.

Практические сценарии выбора режима внутри Astrometry.net

FAQ по Astrometry.net

Astrometry.net — это сайт или программа?

И то и другое в рамках одного проекта. Локальная часть — набор командных инструментов с solve-field в центре. Nova — веб-интерфейс и API, которые дают доступ к plate solving через удалённый сервер. Для технической установки и версии 0.98 речь идёт прежде всего о локальном исходном пакете и контейнере.

Можно ли работать полностью без интернета?

Да. После установки локального solver и нужных индексных файлов обработка собственных изображений не требует сетевого доступа. Интернет нужен на этапе получения программы и индексов. Веб-режим Nova, напротив, всегда требует сети и загрузки изображения.

Есть ли нативная версия для Windows?

Основной документированный путь для Windows 10 и Windows 11 использует WSL. Внутри WSL выполняются Linux-команды и устанавливаются Debian/Ubuntu-пакеты либо собираются исходники. Сторонние Windows-оболочки на базе Astrometry.net существуют, но это отдельные продукты и они могут включать другие версии движка.

Почему одного пакета 11,2 МБ недостаточно?

В исходном пакете находится код, а не полный каталог небесных ориентиров. Локальному solver нужны index files соответствующего масштаба. Именно они определяют основной объём диска. Очень узкие поля требуют более подробных и крупных наборов данных.

Нужно ли скачивать все индексы?

Нет. Каждый индекс рассчитан на узкий диапазон размеров quad-ориентиров. Лишние серии занимают место и замедляют поиск. Для фиксированной камеры лучше подобрать диапазон по реальному полю зрения и проверить несколько соседних серий на наборе контрольных кадров.

Что такое WCS в результате?

World Coordinate System — стандартизованное описание преобразования между координатами пикселей и небесными координатами. Astrometry.net сохраняет его как FITS-заголовок и может записать в новый FITS. После этого другое астрономическое ПО способно определить RA/Dec для точки изображения без повторного plate solving.

Что важнее для ускорения: быстрый CPU или параметры?

Аппаратная скорость важна, но сначала стоит уменьшить ненужный поиск. Правильные границы масштаба, подходящие индексы и известная область RA/Dec/radius часто дают более предсказуемый выигрыш, чем безусловное увеличение CPU limit. Большие кадры дополнительно можно умеренно downsample до source extraction.

Можно ли подавать JPEG вместо FITS?

Да. Веб-форма принимает JPEG, GIF, PNG и FITS, а локальный solve-field умеет работать с обычными изображениями через вспомогательные преобразователи. FITS предпочтителен в научном workflow, потому что сохраняет астрономические метаданные и позволяет записать WCS непосредственно в новый файл.

Можно ли передать уже найденные звёзды?

Да. Astrometry.net принимает XYLS/FITS BINTABLE и текстовые списки X,Y, если источники подготовлены заранее. Это полезно, когда собственный pipeline выполняет детекцию лучше для конкретного типа данных или уже делает её по другим причинам.

Что означает файл .solved?

Это простой машинный признак успешного решения. При успехе файл существует и содержит бинарную единицу. Он удобен для shell-скрипта или управляющей программы: следующий этап можно запускать без разбора изображения и без чтения текстового журнала.

Как понять, что проблема именно в индексах?

Сначала проверьте, видит ли backend хотя бы один индекс. Затем сопоставьте масштаб имеющихся серий с полем зрения. Если путь исправен, но подходящего масштаба нет, solver может перебирать данные и не находить решение. Если источники на -objs.png выглядят корректно, а релевантных индексных серий нет, индексная конфигурация становится главным кандидатом.

Стоит ли всегда задавать RA и Dec?

Нет. Сильная сторона Astrometry.net — работа без этих сведений. Ограничение позиции полезно только когда приблизительные координаты достаточно надёжны. Слишком узкий радиус вокруг неверной позиции способен исключить правильное решение, поэтому неизвестный старый кадр лучше начинать без жёсткой позиционной подсказки.

Что делать, если Nova не отвечает быстро?

Проверьте состояние Submission и дождитесь появления job. Если задача входит в критический автоматический процесс, не стройте его на единственном внешнем сервисе: локальный solver устраняет сетевую очередь. Для разового кадра задержка влияет только на время ожидания, а не на установку или данные на компьютере.

Можно ли использовать Astrometry.net только для аннотаций?

Аннотированное изображение — один из выходов, но не основная ценность solver. Точная WCS-привязка полезнее, потому что позволяет любому совместимому инструменту преобразовывать координаты, выполнять каталоговые запросы и строить собственные аннотации. Веб-страница просто делает эту проверку наглядной.

Подходит ли Astrometry.net для управления монтировкой напрямую?

Solver вычисляет положение кадра, но не заменяет полноценную систему управления телескопом. Sync, slew, повторная экспозиция и критерий центрирования обычно выполняются внешним приложением, которое вызывает plate solver и использует полученные координаты. Такое разделение удобно: астрометрия остаётся независимым измерительным этапом.

Какую версию считать текущей?

Текущий публичный пакет и контейнер solver соответствуют версии 0.98. Каталог загрузок датирует пакет 19 ноября 2025 года. Отдельный Changelog в репозитории заканчивается более ранней версией 0.94, поэтому его нельзя использовать как единственный указатель актуального релиза.

Итог

Astrometry.net имеет смысл выбирать, когда главная задача — получить проверяемую небесную привязку даже для кадра без надёжных исходных координат. Для единичного изображения проще Nova; для регулярной съёмки, обработки старых коллекций и автоматизации практичнее локальный solve-field с заранее подобранными индексами. Самые важные настройки — релевантный диапазон индексных масштабов, разумные scale bounds и, когда позиция известна, ограничение RA/Dec/radius. Пользователю Windows нужно учитывать WSL, а владельцу сервера — объём индексов и файловый кэш. При соблюдении этих условий Astrometry.net остаётся специализированным solver: он не заменяет программу съёмки или обработки, зато даёт им стандартизованную WCS-основу, на которой можно строить дальнейшую автоматизацию.