Съемка видео-роликов

Для достижения полноценного результата с максимальным качеством при съемке Юпитера, будем снимать монохромные ролики по 2 мин. на канал с цветными фильтрами. Минимальный набор роликов составит последовательность из R, G и B каналов. В зависимости от условий, пожеланий и возможности, можно снимать и несколько серий подряд или их комбинаций, например, в следующем порядке: L, G, R, B, L или R, G, B, L, R, G, B или просто R, G, B, R1, G1, B1, R2, G2, B2. WinJupos позволяет все эти ролики обработать и сложить в один цветной снимок. Однако, должно быть понятно, что с ростом количества отснятого материала трудоемкость обработки растет нелинейно, а скорее по экспоненте, в зависимости от количества обрабатываемых роликов в одной сессии.


Предположительное время съемки должно составить минимум 3 х 2мин=6 мин. На самом деле времени уйдет несколько больше, в зависимости от использования/отсутствия колеса фильтров, пере-фокусировки при смене фильтров, наличия автоматизации и форс-мажорных обстоятельств, типа налетевшего облака, внезапного сброса компьютера, отвалившегося провода или не вовремя проснувшихся домочадцев. Типовой интервал между каналами может составлять от нескольких секунд до 4-5 мин. Если получается больше, то это уже плохо и что-то идет не так.

Чем меньше суммарного времени займет съемка всех каналов, тем лучше, поскольку Юпитер довольно быстро вращается. Полный оборот он совершает примерно за 10 часов. Если поканальные ролики обработать до состояния готового фото и сложить в один RGB снимок, то совмещенные изображения из сложенных кадров каналов дадут ощутимое смещение цветов и итоговое изображение окажется размазанным вдоль экватора. Этот смаз будет тем больше, чем протяженнее ролики и интервалы между ними.

Расчет макс. времени планетного ролика без смаза

В приведенном ниже примере это время составляет около 20 мин.для последовательности L, G, R, B, L, поскольку колесо фильтров не использовалось, а после смены фильтров приходилось заново делать фокусировку и подстройку чувствительности камеры для оптимального заполнения гистограммы.

Длительность ролика в 2 мин. выбирается исходя из предположения, что угловое смещение поверхности планеты за это время не превысит трети углового разрешения телескопа. Для разных диаметров телескопа это время окажется разным. Однако, используя WinJupos и деротацию роликов, время съемки можно увеличить, в разумных переделах. Наша задача - набрать достаточное количество качественных кадров, идущих в стек, для эффективного удаления шумов камеры. Таким образом, более скорострельная камера с небольшим полем будет более предпочтительна, чем медленная, но с широким полем. Попутно заметим, что выгоднее иметь камеру с мелким пикселем с тем, чтобы меньше пришлось разгонять фокус и система телескоп/камера оказалась более светосильной.

Обрезка видео-роликов в PIPP

Итак, в результате съемки мы будем иметь, например, 5 файлов с видеороликами. Это каналы L1, R, G, B, L2. Поскольку камеры у всех разные - у кого-то цветная веб-камера, у кого-то зеркальный фотоаппарат, у кого-то ч/б камера, отличающиеся как размером кадра, так и наличием/отсутствием байеровской (rggb)матрицы, максимально возможным fps, а также, поскольку фокусное расстояние телескопов тоже разное, первым делом нам понадобится унифицировать наши ролики и привести их к пригодному для обработки виду, показанному на рис. ниже. Для этого воспользуемся программой PIPP, которая поможет обрезать лишнее в кадре, отцентрировать Юпитер на всех кадрах ролика, дебайеризировать матрицу, превратить цветной ролик в 3 монохромных, отсортировать кадры по качеству(не рекомендую доверять это PIPP'у) и много чего еще. И, что важно, существенно уменьшить размеры файлов, что положительно скажется на уменьшении последующего итогового времени обработки роликов и занимаемом ими месте на диске.

Полезно упомянуть про формат записи и конвертации. Если вы снимаете в RGB24, т.е. при 8 бит/канал, вы вполне можете пожелать и удовлетвориться на выходе из PIPP получить RGB AVI для последующей обработки. Но если ваша камера снимает в 8-16 бит монохроме, в PIPP вам лучше выбрать выходной формат SER/mono 8/16 бит. Этим вы избежите потери младших разрядов при преобразовании и сможете вытащить более тонкие детали и цвет. Результаты работы в PIPP'е полезно будет поместить в одну, отдельную папку. Вообще, в процессе обработки, на каждом из этапов, лучше размещать обработанные на этом этапе файлы отдельно. Это позволит избежать досадных или случайных ошибок, упорядочит их и сильно упростит просмотр и поиск материала в будущем.



Обратите внимание на название роликов. Имя файла должно содержать информацию о цветовом канале, дате и времени начала записи ролика. Некоторые камеры сами пишут дату и время в название файла. Если этого нет, то в процессе съемки необходимо(!) это сделать вручную. Например, в блокноте эти записи могут выглядеть примерно так:

Фильтры Кадров Время Файл Длина
ir_cut(RGB) 3429 7:48:09 2013-10-19-074809 130 sec
ir_cut+r 3568 7:52:34 2013-10-19-075234 130 sec
ir_cut+g 3722 7:56:04 2013-10-19-075658 130 sec
ir_cut+b 3516 8:00:33 2013-10-19-080033 130 sec
ir_cut(RGB) 3424 8:05:09 2013-10-19-080509 130 sec

Поскольку я снимаю не ролики, а серии кадров в .pgm, которые впоследствии преобразуются в 16 bpp Avi видеофайл (программой PGMania ) , а из него уже в .ser файл, я использую для этой цели таблицы Excel, т.к. при деротации и сложении в WJ нужна детальная информация о ролике. Кроме того, большинство параметров при этом вычисляются автоматически, что удобно. Попутно, файл служит в качестве дневника наблюдений, и по нему можно вести какую-то статистику.



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

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



Поэтому, фиксируем не только время создания, но и длительность процесса съемки каждого ролика, еще до переноса роликов из временной папки и до какой-либо обработки. Позже, при работе в WinJupos нам придется оперировать с UT (Universal Time или время по Гринвичу). Например, для Санкт-Петербурга UT = Мск.время - 4 часа.

Не следует полагаться и на fps камеры при вычислении времени окончания ролика, поскольку fps может "плавать", причем в разных программах по-разному. При деротации в WinJupos программа сама посчитает длительность ролика. Однако, скорее всего, она сделает это исходя из прописанного в метаданных ролика fps, который может не иметь ничего общего с действительностью. Поэтому ролики следует стараться делать примерно одной длины, например по 2 мин., и фиксировать это время на будущее в табличке. Саму табличку сохраняем как текст в той же папке, где будут храниться исходные ролики.

Длительность ролика следует выбирать исходя из минимально необходимого количества кадров в ролике. Для разных апертур и камер это количество может сильно варьироваться. Для моей системы телескоп/камера (SW25012/Flea3), эмпирическим путем мной было подобрано число кадров ~6000/канал. От количества кадров зависит отношени
е сигнал/шум итогового снимка. Понятно, что при скорострельности камеры в 15fps для этого понадобится в 10 раз больше времени, чем при 150 fps. Однако, наиболее эффективный и оптимальный fps, в свою очередь, зависит от чувствительности камеры, апертуры телескопа и состояния атмосферы. Думаю, что лучше стремиться к максимально возможному из доступных fps, поскольку, чем меньше выдержка отдельного кадра, тем меньше искажений вносит в него турбулентность. На практике, с приличной (на момент написания этой статьи) ч/б камерой, это значение "плавает" в пределах 30-70 к/сек. Оптимум у всех будет разным.

Линза Барлоу и тесты оптики

Юпитер снимают при максимальном увеличении и разрешении телескопа. На самом деле само понятие увеличения в астро-фото не корректно. Вместо него говорят о масштабе изображения. Эквивалентный фокус или масштаб снимка для системы телескоп/камера следует подбирать из расчета ~3px/R, где R = 140/D в угл. сек. (") и называется критерием Релея. Это довольно легко проконтролировать, зная текущий угловой диаметр Юпитера в " и его размер в px на получающихся снимках, измерив линейками в Photoshop'е или в PIPP(кнопка "Test options").

Например, для моей системы телескоп/камера (тут имеется ввиду SW25012 (10") и камера Flea3 c пискселем 2,5 мкм) на момент написания этой статьи масштаб диска Юпитера составляет ~330px при текущем размере планеты в 45", при использовании разогнанной ЛБ2x. Понятно, что это соотношение - сэмплинг (масштаб в "/px) для системы телескоп/камера постоянно и не зависит от снимаемого объекта. Оно зависит только от размера пикселя камеры и от относительного фокусного расстояния телескопа, и регулируется подбором (разгоном имеющейся) линзы Барлоу. Подробнее про сэмплинг можно почитать в статье автора

Попутно убедитесь, не хроматит ли ваша ЛБ. Это важно. Например, красивая и неплохо сделанная ЛБ 3x (Levenhook/GSO), приобретенная мной по случаю, выдавала редкостное мыло и жутко хроматила. А невзрачная с виду, штатная ЛБ2x от SW выдает вполне сносную дифракционную точку. С плохой ЛБ добиться хорошего результата не получится. Оптика нужна дифракционного качества.
Отличные результаты показывают focal extender от Explore Scientific. У них в линейке есть экстендеры 3х и 5х. Это высококачественная оптика по адекватным ценам. Преимущество экстендера перед ЛБ в том, что он не изменяет заднего отрезка и его увеличение постоянно, не зависимо от того, на каком расстоянии после него находится камера. При использовании этих экстендеров ни хроматизма, ни сферической аберрации замечено не было. Их можно с успехом применять как для фото, так и для визуальных наблюдений.

Проверить качество системы телескоп/камера довольно просто - снимаете яркую звезду с ЛБ на видеокамеру в предфокале, в фокусе и зафокале. Ролики складываете в Autostakkert и смотрите на результаты. Если в фокусе есть дифракционный диск и одно, два неярких кольца - у вас все хорошо. Если колец нет или их яркость по отношению к центральному диску зашкаливает, надо разбираться в причине. Предфокалы и зафокалы можно оценить в программе WinRoddier, делающей тесты Родье по фото.



Выбор камеры

Для цветной камеры фильтры не нужны. В этом одно из ее преимуществ. Кроме того, на цветной камере делается всего один ролик вместо трех, и сам процесс обработки несколько проще. Многие начинающие любители вообще все снимают на одну зеркалку. Охотно верю, что принципиальной разницы нет. Тот же Canon может делать честный кроп центра и выдавать 60 fps. Но, если смотреть правде в глаза, я не видел ни одного Юпитера, снятого на зеркалку или веб-камеру, сопоставимого по качеству с профессиональной цветной камерой, не говоря о ч/б. Близко, но не то.

Встает вопрос, способна ли цветная камера в принципе выдать сопоставимый с ч/б камерой результат по качеству? Ответ неоднозначный. Скорее всего правильный ответ будет таким - скоростная камера с хорошей матрицей и высокой разрядностью способна с ней конкурировать. Тут основным ограничивающим фактором будет выступать формат записи. Профессиональная астрокамера, пишущая в SER будет одинаково хороша как в цвете, так и в Ч/Б. Формат записи и поток с камеры у них одинаковы.

Бытовая веб камера, пишущая в RGB24 (8 бит/канал) всегда проиграет цветной или ч/б астрокамере, пишущей сигнал без сжатия потока в 12 или 14 бит. Кодек веб камеры может использовать и обычно использует сжатие видео потока. В астрофото сжатия или компресии надо избегать. Поэтому веб камера всегда проиграет астрокамере, пишущей в SER без сжатия как по скорострельности, так и по качеству. По той причине, что первой нужно передавать на ПК в три раза больше информации (три канала вместо одного) и 24 бита вместо 16. При астро съемке налицо 3 основных цели - отсутствие сжатия, разрядность и максимально достижимый fps.

Неоспоримое преимущество ч/б камеры состоит в способности снимать в RGB, в UV, и в IR диапазонах. Цветная камера снимает только в RGB и чувствительность ее матрицы вне этого диапазона не гарантирована, даже если убрать встроенный в нее UV/IR block фильтр. Кроме того, цветная камера всегда страдает от протекания каналов. Это технологически непобедимо.

В планетном астрофото часто используется IR диапазон в качестве яркостного канала. Поскольку инфракрасный фильтр темный, для него нужен яркий объект или большая апертура, собирающая много света. Ультрафиолет (UV) также используется, например, по Венере. Таким образом, наличие цветной камеры никак не исключает необходимости в ч/б камере для многих приложений. Иметь ли вам 2 камеры для одних и тех же задач - решать вам. Мой выбор это 2 одинаковые по формату ч/б и цветная астро камеры с максимальными характеристиками за вменяемую цену. Конкретно, речь про QHY5III178C и QHY5III178М. Они, безусловно, тоже не дешево стоят, но и результаты выдают соответствующие.

Фильтры для Ч/Б камеры

Снимать лучше со специальными высококачественными CCD-фильтрами. Сегодня их разновидностей на рынке от много до очень много. Я использую фильтры Astronomik RGBL TypeII, и узкополосные Ha, OIII, IR742, IR block. Каждый из них пропускает только свою, узкую полосу и отсекает все остальное. Есть и другие производители качественных фильтров - Baader, Astrodon и т.д. Стоят они довольно дорого. Без качественных фильтров про астро съемку на ч/б камеру можно забыть и хорошего результата достичь будет трудно, а может и невозможно.



Важно понимать, что применение цветных или узкополосных фильтров (за исключением отсекающего IR/UV cut/block фильтра) на цветной камере либо бессмысленно, либо носит очень ограниченный характер. Применение RGB или узкополосных фильтров на монохромной камере почти всегда крайне необходимо.

Если интеференционных CCD-фильтров у вас нет, но в наличии имеются визуальные (обычно более дешевые и, соответственно, менее качественные или вовсе непригодные для астрофото) фильтры RGB, их можно (с оговорками) применять для съемки на ч/б камеру RGB диапазона (совместно с отсекающим IR cut/block фильтром). Это поможет разделить сигнал на цвета, исключив протекание инфракрасной и ультрафиолетовой составляющих. В противном случае, на итоговом снимке будет невозможно добиться правильного баланса цветов из-за присутствия постоянной IR составляющей и результат (на рис. ниже) гарантированно пойдет в корзину.



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

Лучше всего снимать, выдерживая заполнение гистограммы на уровне 60-70%, регулируя освещенность матрицы посредством gain или fps и придерживаясь одинакового, заданного количества кадров в ролике.

Стремитесь делать ролики каналов с максимально возможным fps и яркостью, но без пересвеченных участков и с минимально возможными шумами (минимальное или среднее усиление/гейн, макс. shutter/выдержка). Это позволит получить максимальное соотношение сигнал/шум при сложении суммы канала.

На цветной камере при съемке подразумевется предварительно настроенный баланс цветов (баланс белого) и последующую коррекцию цветового баланса каналов при сложении RGB в WinJupos и более тонкую на итоговом снимке, при пост-обработке.

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

Если яркости недостаточно, а fps получается довольно низким (<30), значит кадры, скорее всего, будут еще и мыльными, благодаря турбулентности. Редкая атмосфера позволяет снимать с низким fps. Типовое значение fps лучше выбирать около 50 кадров/ сек или больше, т.к. относительно высокий fps позволяет снимать при типичной (средней) по качеству атмосфере. Увеличить fps можно уменьшив фокус или взяв камеру с большим пикселем, и тем самым поднять яркость картинки на матрице. Но делать сэмплинг меньше расчетного - значит снимать с меньшим разрешением, чем позволяет телескоп. Лучше пойти по пути замены камеры на более чувствительную.

На Ч/Б не нужно стремиться снимать с одними и теми же настройками все каналы, т.к. это приведет к недодержанным кадрам в одних каналах, и к пересвеченным в других, и, в итоге, к повышенному уровню шумов или к полностью испорченному изображению. Каждый канал должен быть снят со своими оптимальными настройками. Кроме гейна(услиления), на яркость влияет также и выдержка(shutter), а также гамма, поэтому вариантов оптимальных настроек может быть множество. Для ч/б камеры баланс белого и результирующий цвет делается уже при сборке планеты в RGB, в WinJupos и окончательно корректируется в Photoshop или в другом редакторе (например, в AstraImage), а сами каналы изначально снимаются с максимально возможным соотношением сигнал/шум.

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

Важное замечание

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

По этой причине, отнеситесь ответственно к хранению ваших исходников. Особенно тех, которые вы считаете лучшими. Поскольку снимать лучше с максимальной разрядностью и fps, без компрессии(!), размер роликов может оказаться очень большим. Например, при съемке в 16 бит, на 80-90 fps, при кадре 600х600 px и продолжительности ролика в 2 мин, суммарный размер одной сессии составляет 40-100Gb.

После обрезки кадров в PIPP и сжатия в RAR суммарный вес уменьшается до 3-6 Gb, что уже вполне приемлемо для длительного хранения, например, на съемном жестком диске. С PIPP надо работать аккуратно и крайне не рекомендуется делать в нем преобразование форматов. Если снимали в SER, сохраняйте тоже в SER. Если вы сделали дебайеризацию, разрядность вы уже потеряли и вместо 12/14 бит получите 8 бит, что крайне негативно отразится на сумме при сложении. Понятно, что для последующей, повторной обработки материал из архива понадобится распаковать к исходному состоянию.

Обработка роликов

Существует несколько программ, позволяющих сложить видео-ролик. Обычно для этого используются Autostakkert, Registax или Avistack. Они просты в освоении и вполне годятся для обработки роликов статических объектов. Качество результата их работы варьируется и зависит, не в последнюю очередь, от качества и содержания исходного материала. Дело вкуса, но я бы рекомендовал начать с Autostakkert, на нем и остановиться. Последние версии AS! не нуждаются в предварительной обрезке и выравнивании ролика в PIPP. Он делает это сам, но результат сильно зависит от качества исходного ролика и сиинга.

Юпитер, снятый в цвете, также можно обрабатывать по традиционной схеме (сложение, усиление резкости, сведение каналов). Однако, в случае монохромных роликов или в случае длительных роликов, в т.ч. и цветных, дело осложняется необходимостью предварительной деротации каналов перед сложением. Именно из-за быстрого вращения планеты. Для этого и существует WinJupos.

Деротация, сложение и компиляция

Тут следует пояснить различие в терминах. В WinJupos есть понятие компиляции и деротации. Для наглядности обратимся к рис. ниже, со схематически изображенными этапами нашей сессии. Компиляцию делают при сборке результирующего фото из снимков отдельных, уже предварительно обработанных и деротированных каналов, получая итоговый, совмещенный по каналам, RGB или LRGB снимок. Например, имеются кадры, сделанные в точках G1, R1 и B1. В качестве опорного кадра WinJupos выберет тот, который находится в середине промежутка G1 - B1. Соответственно, в данном случае это будет кадр R1. При этом, исходные снимки каналов подвергаются коррекции (деротации), а по сути искажению, призванному компенсировать их смещение во времени относительно опорного кадра (времени, когда этот опорный кадр снимался). Это значит, что кадры G1 и B1 будут искажены таким образом, как будто бы они снимались в момент R1. Это смещение возникает вследствие вращения планеты за время, прошедшее с момента (или до этого момента) снятия ролика канала до момента снятия ролика опорного канала.



Теперь посмотрим на точку G1. Как видим, это не совсем точка, но круг, имеющий начало и конец пересечения с экватором. Представим себе, что начало ролика G1 соответствует левой границе круга, а конец ролика G1 соответствует правой границе. Чем длиннее ролик, тем шире круг и тем дальше отстоят его границы от центра, т.е. от точки G1. За время, пока мы снимали ролик G1, планета повернулась на угол, соответствующий диаметру круга G1. Чтобы компенсировать это вращение, делают деротацию ролика или сборку ролика на определенную точку во времени. Этой точкой является момент, приходящийся на середину ролика G1. Для остальных каналов, соответственно будут уже другие точки.

Деротацию делают на ролике каждого канала, "сжимая" во времени размазанное вдоль экватора изображение, возникающее вследствие вращения Юпитера за время съемки , если оно было больше допустимого, т.е. ~2 мин. Например, если чувствительность используемой камеры и ее fps низкие, чтобы накопить достаточный для суммы сигнал (набрать побольше кадров) снимать каждый канал придется не 1 мин, а 5 мин. За это время планета ощутимо повернется и сложенный кадр ролика окажется заметно размазан вдоль экватора. Для компенсации этого явления и используется деротация канала (ролика) .

Допустим, что мы сделали деротацию для всех роликов каналов , т.е для R, G и B и свели каждый из них к некой соответствующей каждому каналу средней точке. Теперь нам нужно сложить эти каналы в единый цветной кадр. Но они сняты в раз ное время и на каждом из них положение и изображение планеты разное. Тут и вступает в дело компиляция. Технически, это та же деротация, но производится она для каждого кадра уже на момент снятия опорного кадра (ролика). Как было показано выше, этим моментом в данном случае выступает точка R1. Именно на этот момент и будут пересчитаны каналы G1 и B1. В итоге все три изображения R,G и B совпадут.

В русском языке оба термина - компиляции и деротации невольно смешиваются между собой и оба называются деротацией. По сути так оно и есть. Однако, они описывают разные этапы обработки и мы будем придерживаться терминологии WinJupos, чтобы не запутаться.

Есть еще один момент, требующий пояснения. Представим себе, что мы снимали на Ч/Б камеру не одну серию RGB, а несколько. Т.е. у нас имеется набор роликов R1, R2, G1, G2 и B1, B2. Тут задача усложняется введением еще одного промежуточного этапа, а именно компиляцией R из R1 и R2, G из G1 и G2, и B из B1 и B2. В этом случае, для G канала время будет соответствовать середине интервала между G1 и G2, и попадет на точку G0. Для других каналов соответственно, на другие точки. Таким образом, мы получим новые промежуточные суммы R, G и B, из которых и будет собран итоговый RGB снимок посредством новой компиляции.

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

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



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

Какой из каналов выбрать в качестве опорного? Логично взять за него канал L (luminance), т.е. сделанный с фильтром IR block, и содержащий информацию по всем цветам RGB с вырезанной из сигнала IR и UV составляющей. Можно использовать и другие фильтры для L, например IR pass, т.е. инфракрасный, для получения дополнительных деталей яркостного канала в IR диапазоне. А можно выбрать в качестве L один из каналов R, G, B. Но более логично снимать отдельные ролики для этого канала с фильтром IR block в начале и в конце всего процесса съемки, с тем чтобы впоследствии сложить кадры L1 и L2 между собой и получить новый опорный кадр с информацией, отсутствующей в цветовых каналах. Как мы видели выше, WinJupos позволяет скомпоновать отдельный канал из нескольких разнесенных во времени кадров. Эта процедура также основана на деротации изображений и их последующей компиляции в одно изображение для получения итогового снимка одного канала.

Поскольку канал L1 будет снят до момента съемки каналов R,G,B, при LRGB компиляции в WinJupos будет наблюдаться потеря информации с одной стороны диска, поскольку на момент съемки R,G,B часть Юпитера (в ролике с L1) была еще невидима. Поскольку L2 будет снят после R,G,B, на нем эта информация будет присутствовать и восполнит пробелы в L1 (и наоборот). Промежуточная компиляция L1 и L2 для получения L будет производиться на момент их среднего времени, приблизительно приходящегося на момент съемки одного из каналов R,G,B. Таким образом, поворот цветовых каналов относительно опорного окажется минимальным, а значит и вносимые деротацией искажения, и информация с них будет максимально подкреплена яркостным сигналом с L (L1 + L2).

Если камера цветная

Изначально я снимал бытовой цветной веб-камерой. Разница между ней и профессиональной астрономической цветной планетной камерой большая, но принципы те же. Главное их отличие от монохромной камеры заключается в том, что цветной камерой смысла снимать по-канально с фильтрами никакого нет. Однако в случае с качественной скорострельной цветной камерой попробовать стоит и достичь улучшения можно. Разница между бытовой цветной веб-камерой и профессиональной астрономической цветной планетной камерой заключается в разрядности матрицы и наличии/отсутствии компрессии. В хорошей камере ролик снимается и сохраняется на ПК без(!) компрессии, что и обеспечивает более качественный результат и наличие тонких деталей на снимке. В меньшей степени на него влияет fps и разрядность АЦП. Но чем выше апертура и качество камеры, тем большее значение приобретают и эти параметры.

Исходный размер кадра типовой веб-камеры составляет Full HD или 1920x1080px. С телескопом 250/1200 и ЛБ 3х, при съемке на такую камеру размер Юпитера получался ~220px при диаметре диска в 33", при угл. размере всего кадра в ~5,5'. Т.е. большая часть кадра не использовалась, но все равно занимала место на диске. Поэтому, чтобы убрать лишнее и ускорить обработку, кадры изначально обрезают, например в PIPP, в зависисмости от размера диска планеты, оставляя запас в ~50%.

Обрезку в PIPP ролика по качеству с оставлением определенного % лучших кадров лучше не делать, поскольку PIPP делает весьма странную сортировку по качеству. Он любит пропускать в результирующий ролик откровенный брак. И потом, заранее не известно, сколько хороших кадров имеется в ролике, а потому есть риск выкинуть из него что-нибудь хорошее и далеко не лишнее. Поэтому, можно (и нужно) доверить этот процесс программе, собирающей стек, например Autostakkert или самому WinJupos.

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

Если используется AutoStakkert

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

В AutoStakkert выбираем монохромный режим(меню Advanced), выбираем опции "Planet", "Gradient", ставим галку "Force global quality" и расставляем опорные точки. Поскольку планета уже отцентрирована в кадрах (благодаря PIPP), размер области "AP Size" и пороговую яркость выбираем такими, чтобы точки покрывали всю поверхность, а их количество варьировалось в районе 40-50-60. Для этого ставим режим "Multiply(MAP)" и подбираем яркость в "Min.Bright", после чего жмем кнопку "Analize".



С данной сессией оказалось все не так плохо и ролик показал довольно большой процент кадров хорошего качества (см. гистограмму), что только подтвердило наше обоснованное недоверие PIPP'у в предварительной обрезке ролика по качеству. Есть прямая зависимость - чем больше кадров в стеке, тем меньше шум на собранном итоговом снимке. Первичный стек в AutoStakkert желательно оставлять в пределах 50% кадров при исходном количестве > 3000 (лучше 6000).

Для веб-камеры с ее 30 fps это, конечно, мало достижимо. П олезно при втором и последующих проходах выставить стек меньше, например 25, и 12%, и включить галку "Last stack in Reference", т.е. использовать первый проход в качестве опорного для второго и последующих проходов AutoStakkert'а. Тем самым, каждый новый проход соберет более качественную картинку, чем предыдущий. Таким же образом иногда полезно дойти и до меньшей суммы, если количество кадров в стеке и шумы результата после деконволюции это позволяют.

После AutoStakkert'а пропускаем полученный кадр через вейвлеты в Astraimage или, что более предпочтительно, делаем деконволюцию на каждой сумме. При сложении 1000-5000 исходных кадров результат получается обычно неплохой. Однако, зачастую, кадр, собранный в WinJupos получается ощутимо лучше кадра собранного в Autostakkert, особенно, если яркость ролика канала недостаточна или качество ролика слабое. На рис. ниже приведен результат сложения в WinJupos того же ролика R канала, после деконволюции в AstraImage.



При малом количестве кадров в стеке вейвлеты могут оказаться бесполезными, равно как и использование деконволюции. Вы можете получить не столько усиление резкости, сколько увеличение шума. Обычно для вейвлетов и деконволюции я использую Astraimage. В этой программе выбираем или деконволюцию Maximum Entrophy с экспонентой(она работает очень мягко, но тонко), или Люси-Ричардсон, тоже с экспонентой(она работает жестче). Вейвлеты, как и деконволюция работают лучше при изначально большом количестве исходных кадров, сложенных в стеке. Камера за 2 мин настреливает 10-12тыс. кадров в формате 600х600px при 80-100fps, что более чем положительно сказывается на собранной картинке, даже при посредственной атмосфере.

Компенсация поворота кадра

На практике, учитывая, что при съемке без колеса фильтров, на всех роликах Юпитер оказывается повернут на разный угол в фокальной плоскости, а деротация ролика или кадра производится строго вдоль экватора, прежде всего нам понадобится развернуть планету в исходное и одинаковое для всех каналов положение (горизонтальное положение экватора, север вверху).

Эту задачу решают так называемые кадры измерений (image measurement) в WinJupos.
Что это такое? Это бинарный файл, хранящий привязки WinJupos к конкретному снимку, а точнее время, когда был снят ролик, информацию о масштабе, размер диска, угол поворота диска относительно горизонта, гамму, яркость, контраст изображения в программе и др.

Грубо говоря, image measurement предлагает нам некий шаблон, адаптированный к месту и моменту съемки, в который нам надо загнать диск планеты на нашем кадре. Он же показывает и положение спутников, чем сильно облегчает задачу. Для того, чтобы развернуть ролики всех каналов в совпадающее горизонтальное положение, нам понадобится изготовить такой файл для каждого канала. Но для создания image measurement канала нам нужен или качественный кадр из ролика или уже сложенный снимок.
Где его взять?

Тут есть несколько вариантов. Мы можем сложить ролик и получить этот кадр. В этом случае мы поочередно складываем ролики в Autostakkert и получаем технические снимки каналов, на базе которых изготовим image measurement для каждого их них. Потом, после использования, НЕ выбрасываем их.

Мы можем открыть ролик в SER Player и сделать скриншот кадра. Файл скриншота будет использоваться только для создания image measurement, т.е. для привязки канала. Одиночный кадр почти наверняка будет содержать искажения формы, поэтому сложенная сумма намного предпочтительней.

Для получения image measurement, я складываю ролики в Autostakkert и прогоняю итоговые суммы через деконволюцию в Astraimage. В результате получаем примерно такой набор изображения для измерительных кадров в tiff или png и кладем их в соответствующую папку.



Работа с WinJupos

Начнем с конца. На скриншоте ниже по шагам показан весь процесс деротации изображений в WinJupos.



Далее подробно опишем весь процесс. Первым делом в меню Program выбираем Celestial body, далее Jupiter. Затем в пункте Preferences задаем путь к рабочей папке с файлами роликов и сохраняем настройки.



Image measurement канала

В качестве заготовки для Image measurement канала возьмем сделанный скриншот кадра этого же канала или сложенный в Autostakkert кадр, изготовленный из ролика с этим каналом. Для этого отправляемся в WinJupos и регистрируем кадр в измерителе. На вкладке "Recording" выбираем пункт "Image measurement".



В окне "Measurements" жмем кнопку "Open image" и открываем наш кадр, например, с L1 каналом. Выставляем дату и время в UT, приходящееся на среднее(!) время между началом и концом данного ролика, т.е на середину временного интервала. Тут нам могут пригодиться записи из нашего блокнотика, сделанные во время съемки ролика. Также ставим на этой вкладке широту и долготу места наблюдения. Далее жмем F11 (это работает только на вкладке "Adj.") и наш Юпитер замечательно подстраивается под прогнозируемый программой размер. Если что-то программу не устроит в кадре, она не сможет автоматически подстроить шаблон. Тогда делаем это вручную - клавишами P и N (вращение), и клавишами PageDn и PageUp(подогнать по размеру к кольцу шаблона).



Если положение планеты не совпадает с горизонтом, ее можно повернуть на вкладке "Adj." или с помощью контекстного меню. Также важно отцентрировать диск в кадре (пункт "Centre outline frame"). Для ручной коррекции поворота относительно горизонта встаем на вкладку "Adj." и клавишами "P" и "N" добиваемся горизонтальности поясов на снимке относительно линии экватора на шаблоне. Горизонтальное и вертикальное смещение корректируем ситрелками на клавиатуре. После этого снова корректируем горизонтальность, выбрав в контекстном меню (правая кнопка мыши) пункт меню "Rotate equator of outline frame (and image) horizontally".

После того, как угол поворота нас удовлетворит, выбираем в том же меню пункт "Center outline frame (and image)", что приведет к центрированию планеты в центре кадра. Корректировкой гаммы, контраста и яркости подгоняем точность заполняемости диском шаблона. Эти настройки влияют на итоговый деротированный снимок. Лучше ставить их в исходных позициях, а вменяемости изображения добиваться еще на уровне процесса съемки.

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

В поле "Image info" указываем, что это R1 канал. Этот префикс будет добавлен в имя файла и потом нам еще понадобится. Завершив манипуляции, сохраняем файл измерений с расширением ".ims". Имя файла программа предложит сама на основании введенной даты и времени, полей Observer и Image Info. Сохраняем полученный Image measurement для канала R1 и переходим к следующему. Набив руку, эта операция занимает пару минут.

Таким же образом изготавливаем файлы измерений для всех остальных каналов, но уже с другими файлами изображений, настройками, временем, Image Info = R, G, B, L2 и так же сохраняем их в той же папке, что и скриншоты. В результате мы должны получить набор измерительных файлов .ims для всех каналов.



Важное замечание

При создании Image measurement для второго и последующих каналов, по-возможности, не применяйте F11 без причины и не нажи майте клавиши PageDn и PageUp (подгон по размеру), оставив эти настройки одинаковыми для всех каналов. Так будет точнее происходить масштабирование и сборка каналов при компиляции. Однако это замечание актуально только в случае, когда все каналы идентичны по яркости, размеру и т.д, что на практике, понятно, редко встречается.

Деротация и сложение роликов

После измерений можно переходить к деротации и сложению роликов каналов. Процедура деротации применяется для "сжатия" вдоль экватора "растянутого" во времени изображения планеты в пределах одного канала. Не путайте это с совмещением каналов на итоговом снимке при компиляции RGB/LRGB.
В меню "Tools" выбираем пункт "Derotation of video streams". Если этого пункта нет, проверьте Celestial body в меню Program.

В окне деротации видео-потоков нам предлагается два варианта конечного результата:
1. Покадровая деротация ролика(нам не нужно)
2. Сложение ролика в итоговый снимок канала с одновременной деротацией.

Выбираем 2-й, т.е. сложение (пункт "Stacked image"). В качестве опорного кадра выбираем файл измерений, приготовленный для этого канала с расширением ".ims".

В пункте "Original video" выбираем ролик канала, ранее обработанный в PIPP (обрезка и выравнивание) и выставляем дату и время начала его съемки. Время окончания WinJupos вставит самостоятельно на основании fps ролика и количества кадров в нем. Скорее всего, он вставит ее неправильно, поскольку WJ вычисляет продолжительность ролика исходя из прописанной в метаданных fps.

Но, как мы видели выше, реальный fps скорее всего будет отличаться, а значит и ролик будет иметь другую длительность. По этой причине важно знать исходную продолжительность ролика, еще до его обработки в PIPP (она была записана нами в табличке, в блокнотике) и в случае надобности подкорректировать поле "End Time".



В нижней части окна программа выведет среднее значение для времени обрабатываемого ролика, т.е. его "Reference time". Ролик будет сложен именно на этот момент, а не на ожидаемый нами, по-первости, как конечный результат, момент среднего времени для каналов L1 и L2, вычисленный для опорного кадра при компиляции LRGB.

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

Если все устраивает, жмем кнопку "Start derotation". На выходе, через довольно продолжительное время, получим сложенный кадр, аналогичный тому, что мы получили бы в AutoStakkert. Но как указывалось выше, качество картинки ожидаемо будет лучше, чем в AutoStakkert при достаточном количестве качественных кадров. Сохраняем установки деротации и сложения для каждого файла, нажав F2.



Таким же образом, обрабатываем и все остальные каналы. Поскольку это длительный процесс, напрямую зависящий от производительности компьютера, полезно запустить сразу несколько сеансов WinJupos, каждый из которых будет складывать свой канал и, как вариант, пойти спать. На стареньком 2-х ядерном ноуте с 3гб памяти, сборка 3х-5ти роликов занимает от 3 до 6 часов. На ноуте i7 и 8гб памяти процесс идет в несколько раз быстрее.

После сборки отправляемся в Astraimage и для каждого сложенного снимка каналов L1, R, G, B, L2 наводим резкость вейвлетами или деконволюцией. Далее сохраняем полученные резкие изображения под теми же именами, но уже с префиксом _ai, как вариант.

Создание опорного кадра

В качестве опорного кадра можно выбрать любой, снятый ближе к середине сессии. Для этого его нужно вставить в строку с Luminescence при компиляции RGB.

Важно!

В этом случае опорный кадр должен содержать информацию по цветам всех каналов R, G и B. Это нужно для правильной цветопередачи, именно потому, что опорный кадр будет выступать в качестве яркостного канала в результирующем RGB снимке. Поэтому ролик для опорного кадра L желательно снимать с фильтром L, прозрачным для RGB и не пропускающим IR и UV. Иногда снимают вместо L в IR, или в качестве L принимают R канал, для большей детализации. Однако, цветопередача от этого неизбежно страдает, при том, что детализация может улучшиться. Что лучше и важнее - цвет или детали - решать вам. Оптимальным решением является именно L фильтр, но его применение требует очень хорошей - прозрачной и устойчивой атмосферы. В противном случае, он скорее испортит суммарный RGB, чем улучшит его. Если атмосфера не очень качественная, пользы от L канала будет не много. Обычно наиболее информативен по деталям на диске именно R канал.

Разумным компромиссом представляется композиция синтетического L канала из уже скомпонованного в WinJupos RGB, при пост-обработке и после(!) цвето-коррекции, и как вариант, вставка его в отдельный слой яркости в Photoshop. На нем же, там же, можно применить и дополнительное усиление резкости. А подобрав уровень прозрачности слоя с L каналом попытаться добиться компромисса между красочностью и резкостью итогового изображения. Кроме того, как вариант, можно попытаться снять 2 ролика с L каналом и сложить их на среднее время, тоже в WinJupos, проведя компиляцию для L канала. Именно этот вариант описывался выше. Это позволит получить лучший результат, но ценой больших усилий. Разберем этот момент подробнее на примере с R каналом.

Итак, наш следующий этап заключается в сведении снимков для R1 и R2 каналов, т.е. мы будем складывать R1 с R2 и делать компиляцию R изображения из этой пары. Для этого выбираем в меню "Tools-->De-rotation of images".



В открывшемся окне, в списке "Edit" выбираем оба файла для каналов R1 и R2. Выставляем размер снимка "Quadratic image size" равным исходному размеру кадра после обработки в PIPP. В нашем случае это 450px. В поле "Observer" задаем базу имени для итогового файла R канала, например, путем комбинирования имен складываемых снимков или просто R (в поле "Image info" прописываем префикс R). В суммарное имя программа сама добавит вставку из интерполированного времени, на момент которого будет осуществляться деротация, например: "2013-10-04-0213_9-Summ_Видео105_110-R.tif".



После этого нажимаем F2 и сохраняем текущие установки для R канала в файле ".icm" Далее нажимаем "Compile Image" и получаем итоговое скомпилированное изображение для R. WinJupos сам сохранит его на диске с указанным выше именем.

Для сложения итогового LRGB снимка нам понадобится измерительный файл для комбинированного снимка R канала. Если R был получен компиляцией R1 и R2, снова возвращаемся в меню
"Recording-->Measurement". Как видно на рисунке, ничего настраивать не нужно, т.к. программа сама уже все сделала, включая заполнение всех полей. Убеждаемся, что все хорошо, время выставлено правильно и сохраняем измерительный файл для R канала.



Ну и, наконец, последний этап - окончательная сборка каналов. Как уже говорилось выше, это можно делать с RGB, а можно с LRGB, т.е. собирать RGB относительно L канала. В последнем случае L будет автоматически назначен опорным кадром(!). Выбираем в меню "Tools-->De-rotation of R/G/B frames".

В качестве файлов измерений для каналов выбираем изготовленные на предыдущих этапах измерительные файлы для каналов R, G, B и L. Встречалась мне и такая странность - в качестве L канала WinJupos может предложить использовать один из каналов R, G или B. Мы вежливо откажемся и подсунем ему наш собственный, заранее заготовленный деротировааный измерительный файл для L канала. П о инерции WinJupos может добавить к его имени нечто вроде "green". Это не важно и мы просто проигнорируем это недоразумение.



Выбираем папку для итогового снимка, размер снимка, шаблон имени файла и префикс. Нажимаем "Compile Image" и получаем долгожданный итоговый результат.

Что тут хочется сказать? Во-первых, я вас поздравляю, что вы мужественно дошли до этого торжественного момента. Во-вторых, то, что мы получили - это только очередной полуфабрикат, с которым еще придется повозиться. В-третьих, качество сборки RGB напрямую зависит от тщательности исполнения всех предыдущих этапов. В-четвертых, желательно подобрать яркость и гамму каналов так, чтобы результирующий RGB хотя бы отдаленно напоминал по цвету то, что вы привыкли видеть на картинках в интернете. Как только вы получите что-то удовлетворительное, можно закрывать WJ и отправляться с этим результатом в Photoshop для пост-обработки. Но это уже совсем другая история и о ней мы поговорим в другой раз.

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

@ P.V., 10.2013, St.Petersburg, Russia.
pterodactilus@rambler.ru

Upd. 11.2022