Радужные астероиды

Да, я знал об этом эффекте и даже видел уже. Но то было «давно и не правда» :).

А тут сегодня увидел краем глаза мультик про инопланетян Бувов, который смотрели дети. Там всё такое разноцветное, радужное и красивое. Дисней, одним словом, в полный рост. Подхожу к компу, а тут на те — на RGB композиции скопления галактик, на фоне главного пояса астероидов, несколько красивых цветных треков.

Вот полный кадр:

RGBg56 768x567 - Радужные астероиды

, вот его ресолв с помощью недавно найденного плугина к MaximDL для отображения на кадре известных астероидов:

solved

, а вот кроп с камнем 2001 MK25 (17.1m):

rgbg56-crop

И что, спросите вы, случилось с камнем? Откуда такое разнообразие цветов? Лёгкая подсказка. Снимался сначала кадр в красном цвете (400 сек). Тут же снимался кадр через зелёный фильтр. Потом — кадр в синем фильтре. И так по кругу. А камень-то летел в это время. Вот и получилось, что на сумме, выравненной по звёздам, получился не трек из белых полосок, как это обычно выглядит при съёмке через L-фильтр, а разноцветная колбаса с повтором R, G и B цветов.

Задумка: AutoDeepSkyCapture

Уже несколько лет зреет во мне понимание необходимости оптимизации астросъёмки многих объектов в течение ночи / ночей. А так же уменьшения моего участия в процессе, уход от рутины.

Я пробовал триалы разных автоматизаторов, но все они мне показались слишком замороченными. Видать, я туп и хочу чего-то простого и эффективного, в стиле DeepSkyStacker. Я просто хочу иметь возможность сказать «хочу отснять Улитку и хорошо!». И чтобы прога поняла меня.

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

 

Кратко суть планируемой программы

Хочу отказаться от дорогого MaximDL во время съёмки и написать альтернативный софт с основными фичами:

  • пока что поддержка только ASCOM железа (да, пока с кэноном пролёт);
  • план съёмки, сквозняком проходящий через несколько ночей, включающий в себя пожелания типа:
    • «хочу, чтобы при Луне копился свет по объекту NGC7293 в часе вблизи его кульминации с восточной стороны в фильтрах Ha и O3»;
    • «чтобы без Луны по этому же объекту вблизи кульминации с обоих сторон 3 часа в ночь снимался L и цвет в bin2 в пропорциях 2*L, 1*RGB, хочу набрать 10 часов»;
    • и так хоть по двум, хоть по 100 объектам в течение недели, месяца, года, десятилетий.
      То есть прога сама должна находить оптимальное время съёмки объекта / координат и выстраивать план съёмки. С возможностью его корректировки на ходу;
  • Работа с простым usb-реле, покупаемом на али (без пайки), способном перезагрузить глючное железо, как по питанию, так и по USB;
  • работа с простым ИК-термометром с того же али в качестве сенсора облачности. Основной принцип выбора железа — доступность в конкретном магазине и ненужность пайки;
  • ASCOM контроллер купола / крыши (от Ивана) для экстренного закрытия обсерватории по пропаданию неба;
  • статистика по уже отснятому;
  • калибровка, косметика и выравнивание, сложение превьюхи средствами пикса и моего уже написанного скрипта автоматизации сего процесса (скрипт надо допилить, уже есть несколько идей. Но это мелочи);
  • веб-морда, дублирующая Windows.Form приложение.
    Я веб-программист, так что эта часть самая простая для меня;
  • HTTP JSON общение с прогой из стороннего софта.
    Типа того, как это делает PHD2. Базу этой части уже сделал. Протокол расширяю по мере появления функционала;
  • в недалёкой перспективе возможность съёмки несколькими основными камерами (несколько соосных объективов на одной монти). Конечно же, с межкадровыми подвижками.

 

Процесс съёмки

  • планировщик, чуть описанный выше, принимает решение, что сейчас нужно снимать RA/DEC фильтром X выдержкой N;
  • для этого телескоп переводится в нужные координаты. Делается снимок в bin4, ресолвится (сейчас выбираю движок астрометрии), делается уточняющий переход;
  • запускается гид (пока что PHD, в далёкой перспективе свой гидер с расчётом на раздолбанные монти);
  • запускается съёмка кадра;
  • по заданной стратегии осуществляется перефокусировка (изменение температуры на N градусов или каждые N кадров, что наступит быстрее). Вот тут пока пробел. FocusMax уже не запустишь, тот заточен на максим. Я уже написал и провожу тестирование плугина фокусировки по маске на моторчике, с использованием фокусёра почти любой раздолбанности. Но, однозначно, нельзя заставлять пользователя использовать только этот метод фокусировки. Поэтому, придётся сделать свой FWHM-автофокус. Не сложно его сделать. Сложно сделать его хорошим и быстрым;
  • асинхронно: ведётся контроль на зависания и глюки. Предпринимаются попытки их решения по схеме из настроек. Включается аларма, если робот сам не справился;
  • асинхронно: ведётся контроль погоды. Предпринимается попытка парковки в положение из настроек. Закрытие крыши в случае успешной парковки. Аларма оператору по сбою;
  • асинхронно: ведётся уточняющая привязка средствами астрометрии (чужой движок);
  • асинхронно, низкоприоритетно: ведётся контроль качества полученных снимков (пока через DSS консольный, в перспективе свой анализатор);
  • … далее по кругу. Запрос к планировщику, съёмка следующего кадра с переходом в другие RA/DEC, если нужно или остаётся там же.

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

autoastro-2

Запускаясь, программа просит выбрать оборудование (уже реализовано). Запоминает настройки в реестре винды для конкретного пользователя (что даёт возможность запустить N астрографов на одном компе, как это сейчас сделано у меня).

autoastro-3-config

Выбранное оборудование подключается и текущее состояние отображается на закладке «ствтус». Тут же показывается текущий план на эту ночь и реализованная часть зачёркивается.

autoastro-3-status

 

Заранее задаются разные стратегии съёмки. Некие «шаблоны», говорящие, что галактики лучше снимать так, а водородные туманности этак. Что для съёмки астероида нужно отснять 5 кадров в течение ночи, вперемешку с другими объектами, а для съёмки туманностей в HST-палитре выдержки в узкополосниках нужно делать больше, чем в RGB. Разный бининг.

autoastro-3-how-list

autoastro-3-how-add

Форма добавления пока не включает весь функционал стратегии съёмки (бин, вперемешку, минимальное количество кадров за ночь).

 

Задав шаблоны, задаются цели и время их съёмки. В идеале программа должна снимать объекты только близ их кульминации, минимизируя количество перекладок для классического немца (экваториальной монтировки немецкого типа). При съёмке учитывается фаза и расположение Луны. Узкополосниками можно и нужно долбить даже при полной Луне, тогда как L-ку снимать длинными при Луне — близкий путь фитов к мусорной корзине.

autoastro-3-what-add

autoastro-3-what-list

 

Пока что единственный доступный метод фокусировки с использованием маски на моторчике. Способ экспериментальный, так что до выхода второй версии программы планирую реализовать обычный FWHM / FHD способ фокусировки.

autoastro-3-focusmask


В программу я планирую внести весь мелкий функционал в моём понимании, убрав его столь бесящую меня в максиме форму его подачи.

Замах серьёзный. Не готов утверждать, что доведу до конца. И всё же, мысль уже не первый год зреет у меня в голове и сейчас я уже начал её реализовывать. А это важно — сделать первый шаг!