Программа идентификации ИСЗ в широких полях.

[1212Lupus]

Эмм... Чего-то всё равно не работает. Файл http://www.satir-dev.belastro.net/SatIR_v1_8b.zip ?

[Tau]

http://www.satir-dev.belastro.net/SatIR_v1_9.zip

[1212Lupus]

Всё работает, спасибо.

[Tau]

Обнаружила глюк, появившийся после добавления чтения exif-а. Поэтому версия 1.9 плавно перетекла в версию 2.0 на http://www.satir-dev.belastro.net
На этом делаю паузу недели на две.

[1212Lupus]

Лена, ещё у меня возник такой вопрос: при формировании IOD-файла прописываются строки астрметрии. Но как программа понимает, где начало трека, а где конец? Т.е. в IOD каждой координате соответствует время, но для трека есть два варианта -- правильный (более ранний момент соответствует началу трека) и "перепутанный". С точки зрения логики, какой конец трека отметил первым, тот программа и считает началом. Так? Может можно было бы как-то отмечать при маркировании трека где программа видит его начало, а где конец (т.е. мы кликаем сначала на начало трека (мы знаем, где на фото начало -- это отдельная заморочка), и программа рисует квадратик красненький, кликаем на конец -- и квадратик другого цвета)? Как маркировать -- это вам лучше решать. Это не особо важно, но будет нагляднее.

Вторая проблема: программа имеет свою БД TLE. При поиске кандидатов она использует TLE, ближайшие к дате съёмки (что логично). Но, например, при коррекции орбиты ИСЗ, это может не прокатить. Например, при попытке отыскать кандидата на первом снимке granat'а (ТУТ) у меня ничего не вышло. Запустив Heavensat, и понял в чём дело -- TLE на 18 апреля какие-то левые, USA 234 по ним был ещё под горизонтом, а не в Драконе. Загрузив свежие (23.04.2012) TLE получил полное согласие с фото. Пришлось залезать в директорию ./TLE/ программы SatIR и убирать файл с TLE для USA 234 вручную, потом в программе вводить TLE из файла за 23 апреля, и после этого SatIR'у ничего не оставалось, как считать кандидата по данным на 23 апраля -- трека нашёлся. Я не знаю, насколько это часто бывает. Можно было бы, конечно, спрашивать у пользователя -- TLE за какой промежуток времени он хочет использовать для поиска кандидатов
(хотя ЛОГИЧНЕЕ всегда брать те, что ближе к моменту съёмки). В общем, думаю, не стоит заморачиваться, а считать это исключением.

Вторая проблема снова с IOD. Вот что выдала программа при автоматическом создании IOD:

Код: [Выделить]

38109 12 014A   0000 G 20120419163303000 18 25 1704699+48322817             
38109 12 014A   0000 G 20120419163318000 18 25 1657876+52091217 
Как я и предположил, первая точка -- это та, на которую клликнул сначала. Но мантисса точности тайминга (18) говорит о том, что программа считает в любом случае, что наблюдатель снимает с точностью +/- 1 с. В принципе, это верно в большинстве случаев (хотя, если по EXIF время начало экспозиции фиксируется с шагом 1 с, то чтисто по теории ошибок, точность тайминга +/- 0,5 с, т.е. мантисса MX = 57, но это не существенно). Но нужно предупредить об этом наблюдателя -- он-то может снимать с точностью 1 мс, а программа выдаст IOD с таймингом 1 с, и все его старания в тайминге вылетят в трубу при использовании такого IOD сторонними программами. Подправить вручную не проблема, главное знать, что подправить нужно.

[Tau]

Программа считает началом первый отмеченный конец, концом - второй отмеченный конец трека. Так как при идентификации ошибки вдоль траектории не используются (именно из-за неопределенности, где начало, а где конец ), то это роли не играет. При записи в IOD начало и конец трека меняются в соответствии с направлением движения ИСЗ, который задан в функции "Траектория конкретного ИСЗ", не зря же вызов создания IOD в этой форме находится. В этой части какие-то глюки?

Маркировку начала и конца сделаю. И возможность поменять начало-конец. И запись IOD без ориентировки на конкретный ИСЗ (типа вообще неизвестный померяли).  Уже думала об этом. Для корректного создания IOD, вероятно, нужно вводить отдельную форму, чтобы все мантиссы пользователь сам выбирал?
Но это всё не раньше чем через неделю-две.

[1212Lupus]

В этой части какие-то глюки?

Глюки в моей памяти -- сам в Help'е про выбор начала трека в соответствии с направлением полёта ИСЗ писал. Сказывается вчерашняя прогулка в 21 км под дождём по заболоченной местности...

Для корректного создания IOD, вероятно, нужно вводить отдельную форму, чтобы все мантиссы пользователь сам выбирал?

Вроде, кроме точности тайминга, программа расчитывает всё сама. Условия наблюдений (индексы F, G и т.д.) вообще не учитываются.

[Tau]

про выбор начала трека в соответствии с направлением полёта ИСЗ

Всё равно проверю утром эту часть. Помню, что не на всем диапазоне случаев протестировала.

Тогда только мантиссу точности тайминга пользователь будет выбирать.
А что касается наборов TLE при коррекции, то тут надо подумать, потому что я тоже вчера кадр granat-а пыталась натянуть на Fia radar 2  

[Tau]

Не прошло и двух недель...
Версия 2.1 на http://www.satir-dev.belastro.net
1) Изменены отметки концов трека. Начало трека - розовая метка. Конец трека - зеленая метка.
2) Переделано определение направления трека при вычислении траектории конкретного ИСЗ (Виталий был прав, там действительно что-то неоднозначное было). В зависимости от направления движения ИСЗ метки будут меняться местами (зеленая метка конца трека = направление движения) .
3) Вид формы "Траектория конкретного ИСЗ" поменялся (см.скриншот). Добавился выбор точности тайминга (который будет записан в IOD). Добавился графический значок (c изображением двух треков с разным направлением), при клике на который метки начала и конца на превью поменяются местами. В IOD измерения будут записаны в соответствии с тем направлением трека, который изображен на превью.

[Anton]

Хм.
А не поддержка fits - это как воспринимать?

[1212Lupus]

Много ли ЛА снимают на понто-CCD c полем 20^o-80^o? Нафига козе баян, если никто с такими полями на FLI SBIG etc. не снимает. А если что -- сконвертировать в IRIS'е FITS в BMP не проблема.

[Anton]

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

[rvl]

fits излишен, имхо. Да вообще, идей много всяких можно сгенерить, НО:
у автора есть определенный запаc желания/возможности/времени на интенсивную разработку, и он не бесконечный и от этого надо отталкиваться. Потом хорошо, если будет время на поддержку, типа поправить ошибку или пересобрать программу под очередную версию Windows. Лучше стабильная и долгоживущая утиль с четко очерченным функционалом, чем глючная умеющая все недоделка.

[1212Lupus]

Интересный пример кадра: https://astronomy.ru/forum/index.php/topic,94051.msg1949487.html#msg1949487

На снимке 2 трека -- один похож на метеорный, второй явно спутниковый. Мне пока отождествить не удалось...

[Tau]

Просто если уж программа претендует на некоторую астрономичность..

Программа ни на что не претендует. Работы с фитцами не будет. Приношу свои извинения.
1212Lupus

Интересный пример кадра: https://astronomy.ru/forum/index.php/topic,94051.msg1949487.html#msg1949487
На снимке 2 трека -- один похож на метеорный, второй явно спутниковый. Мне пока отождествить не удалось...

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

[xd]

А там и ответ на вопрос наклюнулся: часы спешат.

[1212Lupus]

Обновляю Help до версии 2.1. Появилось пару вопросов:

1). Что обозначает параметр "Gamma" в info-файле фотографии?
2). От какого направления и в какую сторону отсчитывается поворот поля зрения?

[Tau]

1212Lupus

1). Что обозначает параметр "Gamma" в info-файле фотографии?

Фотография звездного неба - это проекция объектов из сферической системы  координат на плоскость, касательную к сфере в точке пересечения сферы оптической осью. Плоскость изображения имеет геометрические параметры:  масштаб, поворот (если оси изображения не соответствуют осям сферической системы координат) и т.д.  Одним  из параметров является неперпендикулярность оптической оси (приемник излучения криво поставлен, например). Этот параметр наклона обозначают обычно буквой "гамма" (греческой).  В идеальном случае этот параметр равен нулю, в реальности же в этот параметр обычно утягивается часть оптических аберраций (та же дисторсия частично) . При зеркальном изображении (инструмент на экваториальной монтировке в перекладке) гамма уходит в 180 градусов. В инфо-файле этот параметр хранится, потому что он нужен для перехода из экваториальной системы координат в растровую, и обратно. Пользователю этот параметр в программе не  показывается, показывается только "Зеркальность кадра" (Yes/No).
Параметр неперпендикулярности определяется лишь в методе 6 постоянных, потому что это линейная модель проекции, в которой все 6 параметров раскладываются на геометрические параметры (поворот, масштаб и т.д.). В моделях с большим числом параметров (нелинейных) гамма отсутствует.

2). От какого направления и в какую сторону отсчитывается поворот поля зрения?

Это угол между экваториальной системой координат и растровой системой координат (кадра). На картинке нарисованы направления осей прямого восхождения и склонения при трех разных углах. То есть это угол между осью склонения и осью -Y.  Исторически ось Y в декартовой системе координат направлялась вверх, это уже с цифровыми изображениями ее начали вниз направлять, а формулы проекции остались те же самые.  Если кадр снят на экваториальной монтировке, то угол поворота обычно почти нулевой (с точностью выставления полярной оси монтировки и точностью привинчивания приемника излучения в соответствующее положение).

[Tau]

Версия 2.2 на http://www.satir-dev.belastro.net/
Дополнения:
1) На полосе параметров появился графический значок с буквой N (см. картинку). При щелкании по нему откроется возможность ввести норадовский номер ИСЗ. При условии, что время и координаты места наблюдения заданы, вычислится положение ИСЗ на момент середины экспозиции. Эти координаты ИСЗ напечатаются в поле координат для идентификации в режиме номер 2 (для средних полей).  Виталий тут подогнал вагон снимков по конкретным ИСЗ, а поле зрения 14 на 21 градус, с яркими звездами проблема в таком поле... Знакомиться с Тортиллой некогда, пришлось ввести эту функцию.
2) В форме "Траектория конкретного ИСЗ" после вычисленных эфемерид появилась еще пара строк (см. картинку). Это ошибки вдоль и поперек траектории для измеренных концов треков (в угл.секундах). По величине и разбросу этих ошибок можно судить об измерениях. На случае, показанном на скриншоте, большой разброс между двумя точками, это означает, что по-крайней мере одна из них обладает сомнительной ценностью. Как нетрудно догадаться,  вторая точка некорректна, спутник ушел в тень, конец трека не соответствует времени окончания экспозиции.
3) Возможность локальной привязки (Меню->Измерить трек) ограничена до невозможности, в случае избытка слабых звезд на кадре может получиться (и получалось) непредсказумое. В средних полях, кстати, дисторсия довольно слабая, там эта локальная привязка смысла не имеет. Не пользуйтесь ею без необходимости. После введения учета дисторсии эта функция будет удалена.

[1212Lupus]

Нажал на кнопку "N", ввёл номер ИСЗ, но поле осталось 0 градусов (не заметил) -- после выбора "Идентификация звёзд" выскочило окошко с предупреждением "Неверно задан размер поля" (не дословно), окошко смог закрыть только после нажатия "Х" в углу окошка. После этого программа не реагирует на команды -- выбираю в меню разные опции, но ничего не происходит.

Да, возможно это локальные глюки у меня, но ввод новых TLE теперь происходит заметно дольше...