Планетная фотография начинающих

[p.v.]

Как можно видеть, несмотря на отсутствие деротации в моем варианте значительная часть деталей получилась заметно лучше. Только у самых краев диска четкость слегка снижена.

Если честно, я не вижу никаких улучшений. Зато вижу краевые артефакты, которые отсутствуют в моем варианте сложения autostakkert'ом. И как быть с моим вариантом и Маколкина, где деротация не применялась? Там все сливается. Или Вы дробили ролик? Или странно это все.
 

[Yurik]

со своими Юпитерами  Учимся обрабатывать

неплохой результат, но диск планеты выглядит немного плоско, как вырезанный кружок, наклеенный на фон.

А как тогда можно исправить это?

[Aleksandrrr]

Если честно, я не вижу никаких улучшений. Зато вижу краевые артефакты, которые отсутствуют в моем варианте сложения autostakkert'ом. И как быть с моим вариантом и Маколкина, где деротация не применялась? Там все сливается. Или Вы дробили ролик? Или странно это все.

Очевидно, что вся центральная часть диска в моем варианте лучше. Разница не слишком велика, конечно, ибо материал довольно однороден по качеству и его улучшить особо нельзя, только ухудшить. Краевые артефакты без проблем удаляются в фотошопе (а они практически при любой обработке будут после ряда преобразований и с ними в конечном счете бороться придется).
Что вам странным кажется? Хотите сказать, что я безбожно вру и втихую тут кручу ролик в винюпосе? Я не знаю, почему у Маколкина получилось плохо. Думаю, вследствие низкой яркости ролика. Я уже упоминал, что перед обработкой подправил его в virtualdub. Я ролик ни на что не дробил.

[Aleksandrrr]

Я проверял, кстати, исчезнут ли артефакты на краю, если обработать отдельный кусок ролика секунд на 20 - нет. Видимо, что-то тут связано с низкой яркостью ролика или преобразованием уровней. Если обрабатывать как есть, на краю все более-менее нормально (но в целом с деталями ничего хорошего), а после применения уровней к ролику получается неважная картина именно на краях.

[Yurik]

Лучше привести пример, чем спорить!
Анимация из двух фото с промежутком 2 минуты.
Атмосфера была ниже средней.
Подробное описание - https://astronomy.ru/forum/index.php/topic,4408.msg2095508.html#msg2095508

А чем складывают анимации?

[p.v.]

Очевидно, что вся центральная часть диска в моем варианте лучше. Разница не слишком велика, конечно..

Ни в чем я Вас не обвиняю. На рис. мой вариант с WJ сверху, Ваш внизу. Разница есть. Если всматриваться, края у вас расплылись. В центре тоже разрешение меньше. Подозреваю, что Вы прошлись тонкой деконволюцией, которая подтянула детали(это нормально), но не решила проблему смещения в принципе. Пояс в Вашем варианте чуть лучше, чем в моем варианте с Autostakkert или чем у Маколкина, но заметно хуже, чем сделал WJ, как в центре, так и по краям. Плюс ко всему, WJ убирает гребенку на краю в темной стороне, возникающую от полосатости камеры (из-за недостатка света), а в Вашем варианте она есть. Это почерк Autostakkert'а.
Поскольку речь не идет о том, кто круче, а о том, заметен ли сдвиг за 2 мин, мое мнение, что сильно заметен и без WJ не обойтись.

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

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

[Aleksandrrr]

Я использовал только вейвлеты в registax 5

Боюсь, что приведенный фрагмент слишком неоднозначен и вряд ли показывает преимущество деротации во всей красе. Некоторые "темные точки" парадоксальным образом более ужаты на нижнем варианте. Отмечу еще, что сравнивать нужно в адекватном масштабе. А при таком увеличении непонятно, где шумы, а где детали.
Тут нужна, пожалуй, "помощь зала". Но на мой взгляд, по совокупности деталей и в этой области планеты нижний вариант получился, как минимум, не хуже.

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

P.S. И вообще, те или иные преимущества обоих вариантов могут быть обусловлены прежде всего особенностями сложения, а не использованием или неиспользованием винюпоса. Стоит несколько раз сложить один и тот же ролик с разной конфигурацией точек, чтобы убедиться, что каждый вариант в чем-то отличается. Это неизбежно, по крайней мере, для неидеального материала.

[Aleksandrrr]

к чему эта фраза.

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

[p.v.]

Ок. Я удаляюсь - нам Луну дали!

[Alex_O]

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

Для уменьшения погрешности сложения я делаю несколько вариантов сложения в Autostakkert с разным количеством и расположеним точек а затем после обработки вейвлетами все результаты складываю в RegiStax и делаю небольшую деконволюцию. Опытным путем установил, что выигрыш по шумам дает сложение 3-4 результатов после Autostakkert.
Немного, но есть.

[Alex_O]

Кол-во кадров невелико(1900). Яркость в норме. Шумы огромны. Причина - малое кол-во кадров в сложении.

Причина - малая выдержка!
На предыдущей странице я привел два примера с 250 и 400 кадрами. Шумов меньше. Выдержка была 0,2 сек. Камера старый 8-битный NexImage.

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

Есть какие-то сомнения? Нигде не увидел упоминания про компресиию и 8 бит. AVI, насколько я понимаю, это контейнер, в который можно положить что угодно. камера кладет туда равы. В чем проблема?

Если бы у Вас было 16бит в градациях серого, то в FourCC было бы что-то типа Y16.



Ваш файл:

[Alex_O]

А есть ли для планетного фото разница 8 - 16 бит?

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

Для записьи данных с камеры в 16бит был разработан формат SER, который сначала появился в Lucam Recorder для камер Lumenera, потом его поддержку сделали в программах обработки планетных съёмок. FireCapture, который умеет работать с Point Grey напрямую через её SDK может взять с камеры 16бит/пиксель и записать в формат SER. Его потом скармливаем в AutoStakkert и имеем сквозной тракт в 16 битах.
В Вашем случае программа FlyCap2 берет с камеры 16бит, делает все линейные и нелинейные преобразования (яркость, гамма и иные, которые есть в её настройках) и результат пишет в 8бит AVI.

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

А есть ли для планетного фото разница 8 - 16 бит?

Вполне достаточно 8 бит, при достаточном заполнении гистограммы (2/3 - 3/4 от максимума). 16 бит могут быть нужны при съёмках солнца или венеры, т.е. когда света много. Народ в Клаудях много экспериментировал, преимущества 16бит по планетам не нашёл. Там если покопаться, можно найти ссылку на хорошую статью на эту тему, с съёмками и мат. выкладками.

[hemispherus]

А как тогда можно исправить это?

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

[Aleksandrrr]

Для уменьшения погрешности сложения я делаю несколько вариантов сложения в Autostakkert с разным количеством и расположеним точек а затем после обработки вейвлетами все результаты складываю в RegiStax и делаю небольшую деконволюцию. Опытным путем установил, что выигрыш по шумам дает сложение 3-4 результатов после Autostakkert.

Да я и сам так делаю. Только деконволюцию использую на другом этапе обработки.

[bigol]

Если бы у Вас было 16бит в градациях серого, то в FourCC было бы что-то типа Y16.

Еще мне кажется можно просто прикинуть по размеру, зная количество кадров и формат снимка. Например, отрезать в дубе 1000 кадров - и посмотреть размер получившегося ролика. 500х500х1000х8 - совсем не то, что то же самое, но на 16.

[p.v.]

В Вашем случае программа FlyCap2 берет с камеры 16бит, делает все линейные и нелинейные преобразования (яркость, гамма и иные, которые есть в её настройках) и результат пишет в 8бит AVI.

вот тут https://astronomy.ru/forum/index.php/topic,111861.msg2630204.html#msg2630204 , на 2-м рисунке приведен формат кадра - raw 16 бит, размер кадра 608х608 и его вес 739 кб. Размер ролика (см.рис) в 65 кадров составляет 68 мб. скриншот с этим же роликом, открытым в VD был приведен выше в ветке.
считаем: 68мб/65=1071кб, что  > 739 кб, но никак не меньше. 8 бит ролик без компрессии весил бы 24мб. и потом, было бы странно всерьез воспринимать утверждения, что камера передает на комп один поток, а пишет другой. вряд ли такая камера и фирма, которая занималась бы подобными делами) прожила бы более одного дня.. поэтому, с Вашей стороны, было бы здорово пояснить, откуда такая дезинформация поступает. Если Вы и сами всерьез воспринимаете то, что тут говорите, то даже не знаю..
И потом, медиа проигрыватель VLC, показывающий 15 к/c и 8 бит, это не критерий истины. VD показал 70к/c, ну так понятно, откуда он  их взял - из метаданных, которые пишет камера. А откуда взялись 15 при реальных 35? UPD: догадался. Это уже PIPP прописал свои заголовки. Ну так дальше еще смешнее. Когда этот ролик открываешь в WJ, тот считает, что его длина полчаса..

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

В Вашем случае программа FlyCap2 берет с камеры 16бит, делает все линейные и нелинейные преобразования (яркость, гамма и иные, которые есть в её настройках) и результат пишет в 8бит AVI.

вот тут https://astronomy.ru/forum/index.php/topic,111861.msg2630204.html#msg2630204 , на 2-м рисунке приведен формат кадра - raw 16 бит, размер кадра 608х608 и его вес 739 кб. Размер ролика (см.рис) в 65 кадров составляет 68 мб. скриншот с этим же роликом, открытым в VD был приведен выше в ветке.
считаем: 68мб/65=1071кб, что  > 739 кб, но никак не меньше. 8 бит ролик без компрессии весил бы 24мб. и потом, было бы странно всерьез воспринимать утверждения, что камера передает на комп один поток, а пишет другой. вряд ли такая камера и фирма, которая занималась бы подобными делами) прожила бы более одного дня.. поэтому, с Вашей стороны, было бы здорово пояснить, откуда такая дезинформация поступает. Если Вы и сами всерьез воспринимаете то, что тут говорите, то даже не знаю..

А никто и не говорил, что будет легко!
Что с Баслером, что с Поинт Грей, что с любой другой камерой, предназначенной для машинного зрения производитель не даёт софта, который раскроет все возможности камеры. Ещё раз повторюсь, с камеры может браться и 16 бит поток, с ним потом программа проделает все математические операции, которые Вы ей закажете в настройках, а результат запишет в ограниченный набор форматов.
Хотите большего - берите в руки SDK и пишите свой софт. Готовых решений от производителя нет. Причина в том, что в сгменте камер для машинного зрения запись видеопотока от камеры практически никому и не нужна. Нужен софт под определенные задачи, в которых с захвата кадра всё только начинается. Например, определение геометрических размеров деталей, идущип по конвейеру и выдача команды на остановку в случае брака. Или подсчёт клеток крови под микроскопом.

Я сейчас специально посмотрел, в каком формате пишет AVI программа FlyCap2. Там RGB24. Так что ещё раз - проверьте свои видеофайлы на формат, чудес там нет.

P.S. У меня камера Point Grey Blackfly 1280x1024, 60к/сек. на e2v матрице. Модель BFLY-PGE-13E4M-CS