Тема: Скрипт для расчета весов при сложении в Pixinsight (Прочитано 3163 раз)

Ветер · « : 16 Березня 2016, 17:33:44 »

Вечер добрый.

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

Логика скрипта достаточно простая - в диалоговом окне нужно выбрать файлы для обработки (файлы должны к моменту обработки уже должны быть выровнены) и указать координаты областей с фоном и объектом. X1/Y1 - верхний левый угол, X2/Y2 - нижний правый. Координаты нужно предварительно определить вручную по одному из файлов.

Программа просканирует файлы, определит SNR для каждого их них, найдет кадр с максимальным SNR и после этого запишет посчитанное значение как FITS keyword SNRW. Для его использования при суммирование нужно выбрать в процессе ImageIntegration параметр:
Weights: FITS keyword и ввести Weight keyword: SNRW.

Еще пробовал реализовать алгоритм, описанный в теме про FitStacker.

Цитувати

Если для двух сложенных серий отнормированных кадров измерены
SN1, SN2 - соотношение сигнал/шум для любого непересвеченого объекта на суммарном изображении,
N1, N2, где
SNi=(Ii - BGi)/Ni,
Ii - сигнал (Max) для объекта,
BGi - среднее (Mean) значение сигнала фона в (окрестностях)объекта,
Ni - значение шума (Sigma) сигнала (фона) для i-того кадра, которые нужно сложить.

Пусть
SN2 = m*SN1,
N2 = k*N1,
где m и k - известные коэффициенты, определяемые на основании измерений параметров снимков.

Задача состоит в определении коэффициента n, на который необходимо умножить второй снимок для того, чтобы получить сумму с наилучшим соотношение сигнал/шум для исходных (суммарных) кадров, описываемых относительными коэффициентами m и k.

Несложная задача на поиск экстремума (максимума) соотношения сигнал/шум даёт ответ, что коэффициент n вычисляется как
n=m/k.

Вот только после тестовых запусков у меня получались снимки с меньшим SNR, чем у первого вариант.

Для запуска скрипта нужно его распаковать и потом в меню Script -> Execute script file и выбрать данный файл.

В общем, посмотрите, покритикуйте, ну и попробуйте воспользоваться, если есть желание.

PS: ссылка на сообщение с актуальной версией, позволяющей выбирать области фона/объекта через превью.

Andrei Ioda

У меня на маке что то не запускается.

Ветер

Баг) Пофиксил, файл заменил. Попробуй еще разок

bigol

Видел что для пикса появился скрипт, позволяющий присваивать веса по куче разных параметров.
http://www.astronomy.ru/forum/index.php/topic,29203.msg3587844.html#msg3587844

Ветер

Цитата: bigol від 16 Березня 2016, 20:46:35

Видел что для пикса появился скрипт, позволяющий присваивать веса по куче разных параметров.
http://www.astronomy.ru/forum/index.php/topic,29203.msg3587844.html#msg3587844

Ага, Олег, есть такое дело. С ним я тоже сравнивал. При использовании SubframeSelector и веса SNRWeight в нем у меня результат все равно был хуже, чем в FitStacker. Так что это не панацея. Для выборки и назначения весов по другим параметрах - отличный инструмент, хотя и не всегда корректно определяет звезды на моих исходниках. Но вот SNR он не очень хорошо считает. Если бы туда добавили возможность вручную выделять области с обхектом и фоном - тогда был бы порядок.

M_M

Для целей сравнения алгоритмов хорошо бы использовать какой-то фиксированный набор данных.

Ветер

Цитата: M_M від 16 Березня 2016, 21:19:51

Для целей сравнения алгоритмов хорошо бы использовать какой-то фиксированный набор данных.

Я запускал проверку на одном наборе данных (27 кадров по слабому объекту, снятых в разные дни, SNR исходников 1.5-2.5). У суммы, полученной в FitStacker, SNR = 10.77, после моего скрипта 10.69, после SubframeSelector с весом SNRWeight - 9.6.

Разница не сильно большая, но все же...

M_M

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

Само по себе весовое сложение - примитивная функция и особых отклонений от разных реализаций быть не должно. М.Б. FITSTACKER использует какой-то свой хитрый алгоритм, учитывающий кроме весовых коэффициентов что-то еще...
Размер FITSов тестового набора может быть небольшим, тут важна повторяемость результата.

Ветер

В скриптах я копался немного, но нигде не нашел логики по автоматическому определению области с объектом и области с фоном. Так что на мой взгляд, ручной выбор этих областей и подсчета SNR именно для них и дает этот выигрыш в итоговом SNR.

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

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

M_M

Вообще-то странно, для каждого FITs PI подсчитывает несколько шумовых параметров, поканально. И при сложении было бы естественно их использовать.

У меня в FITS после сложения появляется
ImageIntegration.weightMode: noise evaluation
Что бы это значило?

Это вот к чему... всяческих параметров у PI много, хотелось бы просто повторить цепочку действий и получить результат, худший или лучший чем у FitStacker - неважно. Главное - результат повторяемый, от которого можно отталкиваться. В случае использования разных источников результаты будут отличаться, получается лишняя степень свободы, т.е. источник возможных разночтений и разногласий. Ведь кроме весовых коэффициентов есть проблема сшивки смещенных друг от друга изображений. Если просто выбрать другой базовый FITS - получится другой финальный S/N ... Это не считая неведомых настроек. Поэтому для предметного разговора стоит отталкиваться от одинаковых исходников.

Кто-то даже пробовал делать сложение в несколько проходов. Сначала делаем несколько сложений с разными базовыми FITS. Потом результаты сложения еще раз складываем между собой. Результирующая картинка получается намного чище...
А это можно реализовать в один проход. И если понять причину, скорее всего можно будет существенно оптимизировать к-во вычислений.
В оригинальном варианте время обработки растет пропорционально квадрату к-ва изображений. А это означает, что если у меня 100 изображений обрабатывались час, то "хитрая" обработка потребует 100 часов.

bigol

Саша, а само сложение было одинаковым в ПИ и ФС? Какое именно?
В ФС SNR зависит от выбора кусочков фона и объекта. В ПИ тоже так можно сделать? Или как ты оценивал?

Ветер

Цитата: bigol від 17 Березня 2016, 09:06:27

Саша, а само сложение было одинаковым в ПИ и ФС? Какое именно?
В ФС SNR зависит от выбора кусочков фона и объекта. В ПИ тоже так можно сделать? Или как ты оценивал?

В Пиксе я ставил тип сложения Average, нормализация Additive with scaling, Weight - FITS keyword по ключу, добавляемому скриптом и Rejection Winsorized sigma clipping
В ФС только врубал Сигма клиппинг, а метод сложения там один, как я понимаю.

По определению SNR - в том-то и дело, что в ФС области можно выбрать и для этого я и писал скрипт для пикса, чтобы была возможность точно так же выбрать руками область с фоном и объектом, посчитать SNR для значений, рассчитанные по этим областям и выставить итоговые веса для суммирования.

Сегодня заново собирал свою M13, на которую поступило много критики) Сложил со стандартными весами (NoiseEstimate из ImageIntegration) и с весами, полученными при помощи скрипта SNRWeights, прочие параметры не менял.

В результате (сумма 58-ми 2х минутных кадров) получил следующие SNR по каналам:

ImageIntegration cо встроенным NoiseEstimate
R: 127.8, G: 108.7, B: 67.1

ImageIntegration cо скриптом SNRWeights
R: 132.5, G: 110.7, B: 68.6

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

bigol

Насколько я помню, в ФС используется медианное сложение. Либо с сигама клиппингом, либо без него. Либо с весами либо без. Average и Median всегда дают несколько разный итог, поэтому неудивительно.
Не так давно меня поразил тот факт, что если складывать калибровочные в ФС для получения мастера (без весов и сигмаклиппинга), то на сумме отклонение получается лучше, чем например в максиме. При любом способе.

Поэтому калибровочные сейчас складываю в ФС. Просто отмечаешь кусочек фона, сигмаклиппинг не отмечаешь - и вперед. Попробуй, интересно как по сравнению с ПИ получится.

Andrei Ioda

Попробовал скрипт. Эффект есть, шумы меньше. Говорить о цифрах пока не буду.

bigol

Попробовал взять свои 11 снимков ngc1499 в водороде и сравнить.
Складывал максимом, фитстэкером и ccdstack.
Максим при разных вариантах сложения дает лучший результат 9.75 (SNR) - это SD Mask в 3 прохода с Sigma factor 0.5
CCDStack дает 9.6 (Mean)
Фитстэкер дает 10.81 без сигмаклиппинга, 10.74 с сигмаклиппингом.

Ветер

Цитата: bigol від 17 Березня 2016, 18:47:52

Попробовал взять свои 11 снимков ngc1499 в водороде и сравнить.
Складывал максимом, фитстэкером и ccdstack.
Максим при разных вариантах сложения дает лучший результат 9.75 (SNR) - это SD Mask в 3 прохода с Sigma factor 0.5
CCDStack дает 9.6 (Mean)
Фитстэкер дает 10.81 без сигмаклиппинга, 10.74 с сигмаклиппингом.

Вот давай и пиксом пройдемся со стандартными весами и после скрипта. Выложи архив, пришли мне в ссылку?

OlegBr

Хорошее и долгожданное начинание

Я взял 30 кадров M63 в L фильтре, снятых в разные годы на разной оптике, в разном масштабе с разными выдержками.
Сложил шестью разными способами:
1 раз в Fitstacker (sigma=3, sigma fade=0.2)
5 раз в Pixinsight (sigma = 2.8 - 3.2):
- sigma_median
- sigma_average_noise
- sigma_average_SNRW
- Winsorized_average_noise
- Winsorized_average_SNRW

Результаты прилагаю (скриншоты из Fitstacker и CCDInspector, а также текстовый файл с результатами сложения в Pixinsight).

И еще: этот скрипт кроме всего прочего, дает возможность, подобно фитстакеру, вручную корректировать вес хороших кадров с жирными спутниками. Для этого надо просто вручную откорректировать (уменьшить) значение SNRW в FitsHeader такого кадра.
Ссылка для скачивания исходников и готовых сумм в конце прилагаемого текстового файла PI_SNRW.txt

M_M

Ну вот и объяснение фокуса. Если заблюрить изображение S/N возрастает.
FWHM падает -> SNR растет.

Ветер

Цитата: M_M від 17 Березня 2016, 20:27:06

Ну вот и объяснение фокуса. Если заблюрить изображение S/N возрастает.
FWHM падает -> SNR растет.

Вот сравнение сумм, полученных в пиксе стандартным методом сложения и после скрипта (файл с именем SNR). После скрипта SNR выше

M_M

Который метод в пиксе считается стандартным и с какими параметрами? Как производилось выравнивание перед сложением? На каких исходниках?
Результат теста OlegBr понятен. Ваш - нет.
Хотелось бы разобраться. Идея, описанная на страницах обсуждения FitStaсker, понятна, и достаточно просто реализуется в PI, если речь идет только о подсчете весовых коэффициентов. Но непонятно какой алгоритм используется для сложения изображений с дробным смещением. Вполне возможно, что проблема PI не в весовых коэффициентах, а именно в этом алгоритме. А там вариаций куча.

У Вас и OlegBr наверняка разные частотные распределения в исходном материале, поэтому и разные результаты.

Новини:

Автор Тема: Скрипт для расчета весов при сложении в Pixinsight (Прочитано 3163 раз)