PixInsight

[Юрий Торопин]

При выравнивании фона DBE выдает фон в виде изолиний, нет плавных переходов цвета.

Проверьте, что
1. FITS с суммой М101 сохранён как 32- или 64-бит floating point и
2. в секции Model Image процесса DynamicBackgroundExtraction выбрано Sample Format = 32 bit ... Floating Point.
3. попробуйте Correction = Division вместо Subtraction, поставьте галку Normalize.

4. исходники и все каллибровочные, включая плоские поля, конечно же, были в 12 или 14 бит RAW файле, не в 8 битном JPEG'e?
5. гистограмма исходника - нормальная, занимает весь диапазон от 0 до 1 (посмотрите Statistics).

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

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

[Юрий Торопин]

Обращаю внимание общественности на скрипт SubframeSelector (Scripts -> BatchProcessing), выглядит очень многообещающе, хоть для кого-то и будет слишком заумным.

Документация.

Позволяет измерять несколько параметров снимков в серии
property =
[ Index | FWHM | FWHMSigma | Eccentricity | EccentricitySigma | SNRWeight | SNRWeightSigma | Median | MedianSigma |
MeanDeviation | MeanDeviationSigma | Noise | NoiseSigma | StarSupport | StarSupportSigma | StarResidual | StarResidualSigma |
NoiseSupport | NoiseSupportSigma | FWHMMeanDev | FWHMMeanDevSigma | EccentricityMeanDev | EccentricityMeanDevSigma |
StarResidualMeanDev | StarResidualMeanDevSigma ]
и конструировать из них "веса" кадров, которые потом можно подсунуть в ImageIntegration.

[Василий_К]

   Сложение производил  в MaximDl,   Fits сохранялся как 16-bit int.
Все исходники с камеры QHY10 16 bit RAW.  Буду искать  где "просочились" 8 бит.
Ссылка на сумму, М101 14кадров по 10 минут,   https://yadi.sk/d/jZMSvfCppxzfw   

[DiiMaxx]

Обращаю внимание общественности на скрипт SubframeSelector (Scripts -> BatchProcessing), выглядит очень многообещающе, хоть для кого-то и будет слишком заумным.

Согласен, в начале года для себя его открыл и теперь именно с него начинаю работу со снимками. В частности смотрю Eccentricity (бракую самые вытянутые снимки), FWHM (бракую пухлые звезды), StarSupport (бракую снимки с плохой проницаемостью). Обычно в каждом виде по 1-2 снимка удаляются. В итоге общий сигнал становится хуже, но теоретически контраст повышается. Также в ней иногда сравниваю готовые суммы с разными подходами сложения - также можно проанализировать.

[passer_by]

Обращаю внимание общественности на скрипт SubframeSelector (Scripts -> BatchProcessing), выглядит очень многообещающе, хоть для кого-то и будет слишком заумным.

Спасибо огромное. Ведь чувствовал, что что то подобное в Пиксе должно быть, сильно не хватало
 По поводу:

     При выравнивании фона DBE выдает фон в виде изолиний, нет плавных переходов цвета.

Просто маленькая Tolerance стоит - 2. Поставте, для пробы, 7 и все станет нормально Ну и строго говоря ее подбирать нужно...

[Юрий Торопин]

Сложение производил  в MaximDl,   Fits сохранялся как 16-bit int.

Посмотрел выложенную сумму. Вся проблема в том, что она сохранена в 16 бит.
Если посмотреть на кроп у Вас на скриншоте выше, то значение в красном канале в правом верхнем светлом углу исходной выложенной суммы будет  порядка R = 442 ADU, в самом тёмном месте фона рядом с галактикой - что-то около R = 419 ADU. Диапазон изменения яркости фона получается всего 23 ступеньки. Именно ступеньки, потому что значения фона (в красном канале) в 16 бит могут быть только целочисленными 419, 420, ...., 442. Никаких промежуточных значений в 16 бит нет и быть не может.

Аппроксимирующая поверхность "фона" описывается гладкой 2 мерной функцией через вещественные 32 бит значения, которые могут принимать любые не целые значения. Поэтому после вычитания "фона" из суммы (или деления целочисленной суммы на вещественный "фон") те же самые 23 ступеньки по фону останутся (они там будут "скошенными", как зубья пилы). И будут вылезать при растяжении гистограммы и проч.

Мораль - надо записывать суммы всегда в 32/64 битном вещественном формате с плавающей запятой, чтобы избежать появления ступенек из-за дискретизации.

Да и калибровать, совмещать и  суммировать тоже лучше в Пиксе.

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

[passer_by]

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

Ну... и да и нет. При установке малой, для данного кадра, Tolerance, сгенерятся реперные точки, охватывающие именно этот разброс по фону, но если он (фон) оказывается с гораздо большим разбросом расчет пойдет неправильно, как бы растянутым на больший диапазон фона, а градация уже задана в Tolerance. Вот и получаем изолинии с градацией, заданной в Tolerance.
Вот пример - скрины экрана с одного и того же FITS 16 бит. реперные точки не менялись.

[Юрий Торопин]

Вот пример - скрины экрана с одного и того же FITS 16 бит. реперные точки не менялись.

Обратите внимание, что на скрине с "красно-зелёным" цевтом (верхний) в STF совсем не растянут синий канал, отчего и "фОны" кажутся настолько разными. При одних и тех же точках при низком tolerance часть точек будет исключена из списка опорных (возможно, только в одном из каналов).

В разбираемом примере всё дело именно в 16 бит и узком диапазоне, приходящемся на фон, при значительном градиенте фона. Эффект будет проявляться не на каждом 16 бит снимке, у Василия_К он присутстует.

[xd]

Добавлю мааленький комментарий: 32-битное вещественное число имеет точность представления (мантиссу) 23 двоичных знака, что может быть неприемлемым ограничением в некоторых случаях.

[Василий_К]

Последовал совету

Да и калибровать, совмещать и  суммировать тоже лучше в Пиксе.

Сделал  все в Пиксе.  На извлеченном фоне "полосатость" осталась, зато ушла на откорректированном  изображении.

[Юрий Торопин]

На извлеченном фоне "полосатость" осталась,

В текущей(?) версии Пикса, похоже, есть некоторая проблема с отображением некоторых картинок.
Разбираюсь, пытаюсь понять, в чём дело.

Похоже, проблема именно с отображением на экране, со значениями в файлах всё в порядке, там нет никаких ступенек...

Василий, выложите куда-нибудь и новую сумму, сделанную в Пиксе, пожалуйста.

Рад, что проблема решилась!

[Василий_К]

   Новая сумма  М101  в пиксе. ( калибровка, выравнивание, сложение). Добавил еще исходников . Итого 44  по 10 минут.
https://yadi.sk/d/h8W_raXDpyozs

[Юрий Торопин]

Спасибо!
Ок, судя по всему, проблема в том, что ScreenTransferFunction перед отображение (растяжением) переводит любое изображение во внутреннее преставление 16 bit unsigned integer.
При этом проблема - только в отображении STF, не в данных, с данными всё нормально и корректно. В том числе, и в представлении "модельного фона" после DBE.

Судите сами. Ниже:
Скриншот 1, кропнутый исходник M101 Vasily_K и модельй "фон" (синтетическое плоское поле) как результат выполнение DBE. ОПЯТЬ ЭТИ СТУПЕНЬКИ?!?!? Что за фигня?!?!?

К счастью, для Пикса доступен скрипт 2D Plot, который позволяет построить график интенсивностей (яркости) вдоль произвольного "разреза" изображения.

На скриншоте 2 показано диалоговое окно скрипта 2D Plot и положение линии "разреза" относительно исходного изображения "фона", полученного в DBE. Кстати, "ступенек" нет.

На скриншоте 3 показан профиль яркости (в канале В) вдоль линии разреза. Самое главное то, что значения профиля непрерывны, НЕ ступенчаты. Это означает, что с математикой всё правильно, "хромает" только отображение через STF...

Скриншот 4 ещё раз показывает, что проблемы - только в STF. На этот раз к модельному "фону", полученному в DBE, применён HistogramTransform, с параметрами, взятыми из STF. И что удивительно, при линейном отображении растянутого изображения "фона" - никаких линеек...

Резюме: в математике PixInsight проблем нет, DBE работает корректно, генерит правильное непрерывное (в мат.смысле, везде есть производная) изображение "фона".
Float изображение после коррекции DBE выглядит и обрабатывается нормально, никаких ступенек.
Сохраняйте суммы в 32 float - и будет вам счастье!

Проблема есть ТОЛЬКО в алгоритме отображения, применяемом в STF, который "мэппит" сигнал в 16 bit unsigned integer перед отображением и тем самым привносит ступеньки (на отображении!!!), которых на самом деле нет.

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

[Юрий Торопин]

Скриншот 4

[NKV]

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

Juan уже это освещал...
Сделано для быстрого отображения на экране. В том числе чтоб RTP быстрее считался.
А чтоб увидеть реальную картинку, надо HT вместо STF использовать.

[Юрий Торопин]

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

Juan уже это освещал...
Сделано для быстрого отображения на экране. В том числе чтоб RTP быстрее считался.
А чтоб увидеть реальную картинку, надо HT вместо STF использовать.

Ок, значит - известная фича, так и запишем

[DiiMaxx]

Не обращал внимание на ошибку раньше, но решил всё таки узнать, может кто сталкивался. При попытке откалибровать флеты выскакивает ошибка (фото1), но при этом продолжает калиброваться. Дальше на некоторых флетах при их калибровке выскакивает ошибка (Фото2), но почему-то не на всех. Кто может подсказать что не так делаю.  При создание дарков же нигде не указываем CFA, а ошибка как будто говорит что он NO CFA...
При калибровке лайтов аналогичная ситуация при начале калибровке (фото3), а дальше вроде уже ошибка как на ФОто2 уже не выскакивает.

[Юрий Торопин]

Это не ошибки, только предупреждения.

По поводу "The file format reports no CFA pattern..." ("про мастер дарк не сказано, что он CFA, но работа как с CFA была навязана установками процесса" (вольное изложение )) - это просто декларация факта, никаких проблем в этом нет.

"No correlation between master dark and target frame" ("не обнаружено корреляции между мастер дарком и обрабатываемым изображение") - опять же только предупреждение ровно о том, что написано в сообщении, насколько я понимаю, для таких кадров (когда корреляция не обнаружена) не делается калибровка на мастер дарк. Обычно случается, когда выдержка дарков и флэтов (иногда и лайтов) существенно различается.

[DiiMaxx]

Это не ошибки, только предупреждения.

Спасибо, успокоили
Еще один вопрос возникает. Пытался делать флеты в Пиксе по значениям Statistics - 70% от максимального. Но значение "Maximum" выше 3826 из 16383 не поднималось, независимо от выдержки.
Ладно, установил плагин Ивана и в нем сделал флет со значением 11528 из 16383 (фото1). Взял этот же файл, загрузил в Пикс - и вижу значение 3826,3 из 16383 (фото 2). Как так? Почему в Пиксе не вижу необходимого заполнения 70% ?

[buklikovx]

Обращаю внимание общественности на скрипт SubframeSelector (Scripts -> BatchProcessing), выглядит очень многообещающе, хоть для кого-то и будет слишком заумным.

Юрий, спасибо за наводку. Очень удобный и полезный скрипт. Особенно радует возможность копировать-переносить подходящие-неподходящие файлы в разные папки. Приятно было перед сложением рассортировать 630 файлов раздельно по  FWHM и SNRWeight.))