Съемка слабых объектов в условиях сильной засветки

[ArtDen]

Но вообще сама мысль пробовать выделять общее в кадрах и выкидывать все остальное - хорошая

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

[VladTsVs]

Ну борьба с спутниками и метеорами это чуть отдельная тема. Я то борюсь с случаями, когда неравномерности засветки по кадру сильнее полезного сигнала. Пробую различные алгоритмы пока что

[VladTsVs]

и зарегистрировать объекты менее яркие чем она сама становится невозможным - при вычитании фона вычитается вместе с полезным сигналом .

почему же? если мы смогли адекватно оценить засветку по кадру, то мы можем вычесть ее, даже если она по яркости сильнее снимаемого объекта. Другое дело, что шум от засветки будет сильнее шума от самого объекта, поэтому картинка будет шумной.

[PavelGhost]

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

Это простите как ?
Если сигнал утонул в засветке то он вычтется совместно с ней, никаким количеством кадров постоянную составляющую засветки уменьшить не получится.

[VladTsVs]

Если сигнал утонул в засветке то он вычтется совместно с ней, никаким количеством кадров постоянную составляющую засветки уменьшить не получится.

Так не-шумовая часть засветки вычитается не количеством кадров, а построением модели распределения засветки по кадру и вычитанием. Вот пример вычитания

Важно чтобы уровень полезного сигнала был больше, чем случайный шум засветки. А вот как раз случайный шум засветки давится накоплением кадров, после чего мы аппроксимируем засветку полиномами (или как-либо еще) и вычитаем из снимка.

чтобы было понятнее:

яркость пикселя = сигнал от источника + шум сигнала от источника + сигнал от неба (засветка) + шум засветки

шум засветки давим количеством кадров, а сигнал засветки давим вычитанием

[Дмитрий Маколкин]

Если сигнал утонул в засветке то он вычтется совместно с ней, никаким количеством кадров постоянную составляющую засветки уменьшить не получится.

Сигнал и засветка аддитивны. Это одни и те же фотоны. Если все они зарегистрированы, то там, где есть засветка А и сигнал Б отсчет АЦП будет больше, чем там, гда только засветка А.
(А + Б) - А = Б.   Есть сомнения?

[PavelGhost]

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

[VladTsVs]

Ну все что выше фона остается, все что ниже - исчезает вместе с ним.

Не бывает "отрицательного" света) Свет от засветки добавляется к свету от снимаемого источника. Поэтому в любой точке снимка яркость пикселя выше чем была бы яркость от только засветки

[PavelGhost]

Поэтому в любой точке снимка яркость пикселя выше чем была бы яркость от только засветки

Насколько выше то.
На величину порядка 1-2 электрона ?

[Дмитрий Маколкин]

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

Что значит - ниже фона? Сигнал не высасывает из фона фотоны, фотоны всегда складываются.

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

[VladTsVs]

На величину порядка 1-2 электрона ?

На столько же, какую бы яркость имело изображение под черным небом.

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

[Дмитрий Маколкин]

Поэтому в любой точке снимка яркость пикселя выше чем была бы яркость от только засветки

Насколько выше то.
На величину порядка 1-2 электрона ?

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

[VladTsVs]

Я так комету c/2020 neowise фоткал в Питере. Когда наконец стала хорошая погода, то к тому времени комета уже была на отлете и глазом не видна вот вообще. Особено с учетом того, что небо в то время на севере, где располагалась комета, было отчетливо голубое, хоть уже и не белые ночи, но около того. В общем, после суммирования кадров едва-едва проглядывалась кома кометы, но ни о каком наблюдении хвоста не могло идти и речи. Хвост был в многие разы тусклее неба. Но ничего, после хорошей аппроксимации неба, хвост вполне себе проявился. Только шумновато было.

[PavelGhost]

Вот суточное накопление в ухкополосниках.
Уровень шума ниже 2 электрона.
Дно достигнуто, но мелких деталюшек не видно аднака ?

[Дмитрий Маколкин]

Вот суточное накопление в ухкополосниках.
Уровень шума ниже 2 электрона.
Дно достигнуто, но мелких деталюшек не видно аднака ?

Мелкие и слабые - это разное, не путайте тёплое с мягким!

[Дмитрий Маколкин]

Вот суточное накопление в ухкополосниках.
Уровень шума ниже 2 электрона.
Дно достигнуто, но мелких деталюшек не видно аднака ?

У меня есть предположение, почему могут теряться слабые (с малой яркостью) детали туманности.
Обратил внимание, что в Вашем примере результат записан в FITS, и если это INT16, то для отображения слабых вариаций фона вызванных деталями туманности, может просто не хватить разрядности этого формата данных. Посмотрите формат Ваших сумм, и если это INT16, то стоит пересмотреть рабочий процесс сложения.
В том же Pixinsight XISF результат сохраняется в IEEE 754 binary32 floating point, там разрядности выше крыши и ничего не теряется.

Второе узкое место - экранное отображение. Всяческие нелинейные преобразования яркости в постпроцессинге направлены на впихивание всего диапазона яркостей объекта в 8 (максимум 10) бит экранной разрядности.
Т.е. если с форматом данных всё в порядке, то слабые детали не будут видны пока не вычтен фон, а остаток не растянут по яркости так, чтобы быть видным на мониторе с его ограниченной разрядностью.

P.S. Исправил опечатку про формат с большой разрядностью.

[PavelGhost]

В том же FITS результат сохраняется в IEEE 754 binary32 floating point, там разрядности выше крыши и ничего не теряется.

Отлично, только например ФитСтекер как заставить сложить сумму в 32 бита флоат ?

[VladTsVs]

Ну складывайте в софте, который позволяет складывать с любой нужной точностью)

Я для своего удобства и небольшого упражнения в программировании написал на питоне простую складывалку с использованием numpy массивов и какую разрядность захочешь такая и будет

[PavelGhost]

Я для своего удобства и небольшого упражнения в программировании написал на питоне простую складывалку с использованием numpy массивов и какую разрядность захочешь такая и будет

Сомневаюсь, что она лучше ФитСтекера

[VladTsVs]

Ну по крайней мере она умеет работать  с float32 и float64)