Влияние сжатия и цветовой субдискретизации на качество планетных фото

[TownAstro]

Вопрос, допустима ли планетная астросъемка в форматах видео с потерей данных (lossy formats – MPEG, TrueMotion…), уже неоднократно поднимался в различных темах.

На форуме много сторонников идеи недопустимости lossy съемки, в основном это владельцы астрокамер. Есть и сторонники противоположной точки зрения, успешно занимающиеся съемкой на камеры Canon DSLR.

Каждый снимает на своем оборудовании в разных условиях поэтому к какой-то объективной оценке прийти трудно.

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

Так же мне стало интересно как на качество картинки влияют разные варианты дебайеризации (demosaicing, debayering) и цветовой субдискретизации (chroma subsampling).

Эксперименты проводил с видеороликами Руслана Ильницкого www.star-hunter.ru
https://star-hunter.ru/saturn-06-07-2015-training/
https://star-hunter.ru/obrabotka-videorolika-yupitera/
(мои материалы в большинстве своем, это серийная съемка в RAW на фотоаппарат. Т.е. они изначально с сабсэмплингом )

Сатурн:

Сырой ролик в SER формате конвертировался FFMpeg в RAW RGB24 и далее он конвертировался в lossy видео кодеком H264 c битрейтами 2Mbps и 20Mbps и в lossless (для яркостного канала) с сабсэмлингом 4:2:0

Использованные команды Ffmpeg

(кликните для показа/скрытия)

RAW RGB24:
ffmpeg -i Saturn.ser -vcodec rawvideo -pix_fmt bgr24 Saturn_RAW.avi
Lossy:
ffmpeg -i Saturn_RAW.avi -vcodec h264 -profile:v baseline -pix_fmt yuv420p -b:v 2M Saturn_H264_2M.mkv
ffmpeg -i Saturn_RAW.avi -vcodec h264 -profile:v baseline -pix_fmt yuv420p -b:v 20M Saturn_H264_20M.mkv
Lossless with Chroma subsampling:
ffmpeg -i Saturn_RAW.avi -vcodec libx264 -pix_fmt yuv420p -qp 0 Saturn_H264_420p.mkv

Далее делались стеки в 500 кадров из 3754 в Autostekkert (AS!), как из исходного ролика, так и из сконвертированных. И стеки подвергались минимальной обработке: деконволюция и повышение контраста в AstraImage 3.0SI.

Результаты
https://drive.google.com/uc?export=download&id=160Kdi0kB_L1lhpes0csV90bIbSWj8shm

Фото сделанные из SER и из RAW RGB24 роликов отличаются тем, что для первого дебайеризация делалась в AS! А для второго в FFMpeg. Как мне кажется, первое изображение выглядит несколько контрастней, но там больше и «шумов», артефактов дебайеризации. Разницы в передаче деталей не заметно. Но наверно дебайеризация в AS! выглядит предпочитиельней, чем дебайеризация в RGB24 в FFMpeg

Остальные фото показывают, что при lossy сжатии с битрейтом 2Mbps есть явные потери качества, и даже щель Кассини заметно размывается. При сжатии с битрейтом 20Mbps или при сжатии без потерь в яркостном канале но с сабсэмплингом 4:2:0 потерь деталей изображения практически не видно.

Юпитер:

В этом случае я не делал промежуточную конверсию в RGB24. SER файл непосредственно сжимался и сабсэмплился кодеком H264

(кликните для показа/скрытия)

Lossy
ffmpeg -i Jupiter.ser -vcodec h264 -profile:v baseline -pix_fmt yuv420p -b:v 2M Jupiter_H264_2M.mkv
ffmpeg -i Jupiter.ser -vcodec h264 -profile:v baseline -pix_fmt yuv420p -b:v 20M Jupiter_H264_20M.mkv
Lossless with Croma Subsampling
ffmpeg -i Jupiter.ser -vcodec libx264 -pix_fmt yuv420p -qp 0 Jupiter_SER_H264_420p.mkv

Результаты
https://drive.google.com/uc?export=download&id=1jOXftjAf-aD2eF5M7QgbdaqP4PvNuxPR

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

То есть эти эксперименты показывают, что сжатие с потерей качества с высоким битрейтом или сжатие без потерь качества (в яркостном канале) и сабсэмплингом 4:2:0 можно использовать для астро-фото.

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

В формате lossless сжатия с сабсэмплингом 4:2:0 и теоретически нет потери информации по сравнению с SER. В SER используется 8 бит на пиксель в 4:2:0 10 бит на пиксель. В 4:2:0 такое-же разрешение по цветности и большее разрешение по яркости чем в SER. При этом при сжатии мы выигрываем в объеме видеоролика в 3-5 раз. То есть это выглядит как неплохой формат для архивирования или съемки на небыстрые дисковые устройства. 

Надо будет попробовать поснимать в lossless 4:2:0 формате на Raspberry.)

[p.v.]

Фото сделанные из SER и из RAW RGB24 роликов отличаются тем, что для первого дебайеризация делалась в AS! А для второго в FFMpeg.

RGB24 не содержит матрицы Байера. Это RGB

SER файл непосредственно сжимался и сабсэмплился кодеком H264

Как можно сжать raw мпеговским кодеком и чего для?

В SER используется 8 бит на пиксел

В ser используется разрядность камеры. Если она 8 битная вебка, то и не удивительно, что там 8 бит. И откуда в ней ser возьмется? Переводить rgb24 в ser? Смысл?

Это ни в коем случае не призыв ко всем переходить на сжатое с потерями видео

А к чему тогда призыв, мне непонятно.
Теперь по сути. Ser пишется как есть, но главная его проблема в том, что он пишется одним целым здоровенным файлом и пока хватает оперативки. Как только она заканчивается, файл обрывается. По крайней мере у меня было так. Я пишу fits, с ними таких проблем не возникает. Камера держит снимки в буфере, они сливаются, буфер освобождается и так до бесконечности. На длинных роликах это актуально. Ser неудобен тем, что его надо распаковывать. Кто и как это делает нам не ведомо. В кодировщик не залезешь. Тот же PIPP при распаковке выдает 8-битные картинки. А оно надо?
Что делает с картинками AS! вообще никто не знает. Но лично мне не нравится, что он с ними делает. По крайней мере в AS при хорошей болтанке вполне реально из Юпитера получить развернутую портянку вместо диска. Т.е. Выравнивание у него так себе. Непрозрачно это все.
С картинками таких проблем нет. Захотел отфильтровал, захотел отсортировал, захотел, новое видео из них собрал в тех же 16 бит. Зачем чесать левую ногу правым ухом?
По поводу сжатия. Понятно, что при большем битрейте потерь будет меньше, потому как компрессия меньше. Но ить подавляющее большинство снимает вовсе без компрессии и не собирается к ней возвращаться.

[TownAstro]

Я конвертировал из SER в RGB c помощью FFMpeg. Естественно там нет маски байера. Дебайеризацию сделал FFMpeg.

Про разрядность камеры все правильно. Просто я экспериментировал с 8-ми разрядными роликами.

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

[Ihtamnet II]

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

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

[ma][im]

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

Это не тестирование, надо брать итоговую красивую картинку (эталон) с нее генерить с зашумлением гауссом ролик 1000 кадров сохранять в формат SER (там простейший формат - программа пишется за полчаса), и другие форматы какие интересно с сжатием/без и полученные тестовые ролики сложить с одинаковыми параметрами в AS!3 (а можно и в программке сделать простое медианное сложение для автоматизации) и финально посчитать PSNR полученных сумм и стартовой картинки.
Я думаю такую тестовую софтинку можно сделать за пару часов на opencv, ток кому оно надо? Проблем нет хранить SER ролики топовых съёмок - их в год получается не так много к сожалению. Я вообще храню все съёмки в SER за пару лет это всего 4тб - надо повыбрасывать 90%. Стоит ли овчинка выделки с учётом того что цены на винты вполне гуманные? А цена ночи( хотяб часа) с планетным сиингом на вес золота.

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

с нее генерить с зашумлением гауссом

Пуассоном.

[ma][im]

с нее генерить с зашумлением гауссом

Пуассоном.

Ну вот топик стартеру и методика, сделать и оформить в ВАК журнал
Чем ещё хорош искусственно созданный зашумленный ролик - он выровненный, поэтому его очень просто сложить.

[TownAstro]

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

[ma][im]

По большому счету, чтоб максимально использовать оптику и разрешение матрицы, лучше снимать отдельные ролики на ЧБ камеры со светофильтрами, а не цветными в SER

Это справедливо для съёмки с супер детализацией одиночной картинки, если надо снять магкую анимацию вращения планеты цветная камера намного удобнее и как показывает практика не хуже чем моно камерой при записи ессно в SER. Я например сам пишу в SER поток с камеры на лету без буферизации с использованием SDK камеры, это простой бинарный файл с заголовком где указано количество кадров, разрядность и некоторые данные о съёмке, затем идет подряд блок сырых кадров. Одиночные картинки файлы ролика в планетной съёмке это жутко не удобно, при копировании с винта на винт скорость в разы меньше будет.

[ma][im]

То есть серьезным экспериментом была бы обработка большого объема реального материала и его оценка.

Что в этом случае мы возьмём за эталон? Сумму не сжатого ролика? Когда зашумляем мы знаем что в итоге было оригинал

[ma][im]

Что делает с картинками AS! вообще никто не знает. Но лично мне не нравится, что он с ними делает. По крайней мере в AS при хорошей болтанке вполне реально из Юпитера получить развернутую портянку вместо диска. Т.е. Выравнивание у него так себе.

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

[TownAstro]

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

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

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

[TownAstro]

То есть серьезным экспериментом была бы обработка большого объема реального материала и его оценка.

Что в этом случае мы возьмём за эталон? Сумму не сжатого ролика? Когда зашумляем мы знаем что в итоге было оригинал

Да сумму несжатого ролика. Так как нам интересны отклонения качества именно от него.
Вот только боюсь поможет ли нам PSNR в этом случае

[ma][im]

Ну, а если съемка ведется цветной камерой с байеровской маской в SER формате, то почему бы не паковать данные в lossless yuv420.

Зачем это делать, с цветной камеры точно также пишется файл как и моно, отличие в заголовке SER флаг Байера =1, размер кадра одинаков. As3 сам потом его декодирует.

[p.v.]

у него мощнейший алгоритм многоточечного корреляционного выравнивания

Может он и мощнейший, но с обычным мылом, не катастрофическим, он не справляется. При  этом сами исходные кадры вполне себе обычные.
https://astronomy.ru/forum/index.php/topic,140994.msg5455348.html#msg5455348

[ma][im]

Может он и мощнейший, но с обычным мылом, не катастрофическим

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

[TownAstro]

Ну, а если съемка ведется цветной камерой с байеровской маской в SER формате, то почему бы не паковать данные в lossless yuv420.

Зачем это делать,

Размер файла в 3-5 раз меньше (без потерь качества). И например если у вас комп с приличным процессором но с неважной скорость записи, если паковать на лету, это может поднять FPS.

с цветной камеры точно также пишется файл как и моно, отличие в заголовке SER флаг Байера =1, размер кадра одинаков. As3 сам потом его декодирует.

Главное различие, что сигнал из цветной камеры надо дебайеризировать и при этом резкость несколько уменьшается. Насколько она уменьшается зависит от алгоритмов которых довольно много
https://rawpedia.rawtherapee.com/Demosaicing
И это тоже довольно интересная задача, выяснить где алгоритм дебайеризации лучше в PIPP, AS! или FFMpeg. Первый пост этой темы тоже немного касался.

[ma][im]

И это тоже довольно интересная задача, выяснить где алгоритм дебайеризации лучше в PIPP, AS! или FFMpeg

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

[p.v.]

интересная задача, выяснить где алгоритм дебайеризации лучше в PIPP, AS! или FFMpeg

Они везде одинаковы. Отличаются только сами камеры паттерном матрицы Байера. От программы, выполняющей дебайеризацию он не зависит. Падает там не резкость, а разрешение, потому что при дебайеризации пиксель превращается в квадрат 2х2 пикселей или в суперпиксель. Бывают и 3х3, но реже. Это и есть основная проблема цветных камер. Зеленых пикселей в 2 раза больше, чем синих и красных. Цвет пикселя при преобразовании в RGB вычисляется из его ближайшего окружения. Самих паттернов 4 основных, плюс куча вариаций.
В opencv есть реализации дебайера, изобретать ничего не нужно.

[ma][im]

Они везде одинаковы. Отличаются только сами камеры паттерном матрицы Байера.

Сам не углоблялся в методы дебайеризации, просто юзал то что в OpenCV заложено, надо только указывать RG GB и прочее - паттерн.
Но их действительно бывает несколько, вспоминая тот же pixinsight:
ps. считаю подбор методов дебайеризации это ловля блох хотя чем черт не шутит