Entry tags:
Дебайеризация
Что-то сильно расхваливаемый авторами алгоритм дебайеризации дает довольно-таки много артефактов:

Работает, кстати, медленно. Код мало того, что не оптимизирован, так еще и авторы зачем-то почти чистый (ну, заменить new на malloc, а delete на free — и будет совсем чистый) сишный код в cpp файлы запихали.
Ищу дальше...

Работает, кстати, медленно. Код мало того, что не оптимизирован, так еще и авторы зачем-то почти чистый (ну, заменить new на malloc, а delete на free — и будет совсем чистый) сишный код в cpp файлы запихали.
Ищу дальше...
no subject
no subject
Может быть сойдет тупая билинейная интерполяция.
Вообще же, главное — не цветную картинку получить (толку от нее 0), а как можно лучше избавиться от влияния этой дурацкой маски Байера. Я вообще поражаюсь: какой мудак мог придумать наклеивать на all-sky камеру фильтр Байера?! Дело в том, что для упрощения вычисления координат звезд фон желательно сделать равномерным.
Хотя, может быть сойдет и такой вариант: тупо уменьшить разрешение в 2 раза, сложив значения пикселей в каждом квадрате, а по результирующему изображению уже звезды искать и определять процент облачности. Я даже на подобное именно для этой матрицы натыкался, но там было для питона, что совсем нехорошо.
no subject
было еще что то где совсем как электронная таблица изображение открывалось... но склероз мешает вспомнить :(
no subject
no subject
Может попробовать Тутубалинский LibRaw, который на базе dcraw, если правильно помню ...
no subject
no subject
no subject
В принципе, учитывая то, что изображение неба — это практически один сплошной фон, можно попробовать элементарнейшим образом сделать: компоненты R, G и B по-отдельности (соответственно, уменьшенное в 4 раза изображение; компоненту G брать как среднее в каждом квадрате) усреднить медианой 3х3, таким образом получить значения дополнительных цветов в каждом квадрате. Оригинальные компоненты оставлять без изменения, а к ним добавлять полученные дополнительные. В итоге и звезды останутся на изображении, и цвет будет.
Попробую этот алгоритм завтра.
no subject
no subject
no subject
no subject
Он у меня, оказывается, установлен.
Полистал исходники. Испугался и закрыл: 10200 с хвостиком строк в одном файле! Автор — точно наркоман!
no subject
Да, у libraw автор нет то, что и у dcraw ;)
no subject
Их там аж три.
Но скорее всего с наскоку - вашу камеру не распознает, надо строчку добавить по типу тех, что описывают андроидные дампы сенсора.
no subject
no subject
no subject
no subject
- или +1 строчка в коде
- или подать фактически эту же строчку в parse_custom_cameras() и подсунуть потом в параметры.
Но мне нужен этот дамп (не так чтобы очень нужен - можете трахаться сами если предпочитаете так)
no subject
no subject
Прямо вот такой какой libraw будем подсовывать.
Я ж написал там выше (про порядок байт и тп)
no subject
дамп: https://drive.google.com/open?id=0B859YEB17d8veDVlUUpJNzJsXzg
Формат uint16_t, little endian, 640x480 пикселей, сохранено построчно. Экспозиция 0.5с. Получился эдакий псевдофлэт (морду я обмотал белой бумагой).
no subject
Вот патчик к LibRaw (к dcraw.c тоже подойдет, найдете там эту табличку в identify() и руками поставите), дамп совпадает по размеру с сенсором Kodak KAI-0340, поэтому кодак я закомментировал:
diff --git a/internal/dcraw_common.cpp b/internal/dcraw_common.cpp
index 4738c29..df78fde 100644
--- a/internal/dcraw_common.cpp
+++ b/internal/dcraw_common.cpp
@@ -15318,7 +15318,8 @@ void CLASS identify()
{12241200, 4040, 3030, 2, 0, 0, 13, 0, 0x49, 0, 0, "Kodak", "12MP"},
{12272756, 4040, 3030, 2, 0, 0, 13, 0, 0x49, 0, 0, "Kodak", "12MP", 31556},
{18000000, 4000, 3000, 0, 0, 0, 0, 0, 0x00, 0, 0, "Kodak", "12MP"},
- {614400, 640, 480, 0, 3, 0, 0, 64, 0x94, 0, 0, "Kodak", "KAI-0340"},
+// {614400, 640, 480, 0, 3, 0, 0, 64, 0x94, 0, 0, "Kodak", "KAI-0340"}, // Same size, so disable Kodak for it
+ {614400, 640, 480, 0, 0, 0, 0, 0, 0x94, 0, 0, "Some", "Shit"},
{15360000, 3200, 2400, 0, 0, 0, 0, 96, 0x16, 0, 0, "Lenovo", "A820"},
{3884928, 1608, 1207, 0, 0, 0, 0, 96, 0x16, 0, 0, "Micron", "2010", 3212},
{1138688, 1534, 986, 0, 0, 0, 0, 0, 0x61, 0, 0, "Minolta", "RD175", 513},
Но я не уверен в том что каналы угадал, мне бы чего цветное с известными цветами, а то вдруг я не тот паттерн подставил байеровский, по этой картинке не узнать, все белое.
Следующим сообщением - скриншоты из RawDigger (может упасть в спам - поэтому отдельным)
no subject
no subject
Это егонный декодер срабатывает, я такую картинку уже видал сегодня
no subject
Вполне прилично. Разве что цветовые профили надо пилить. Но скорость, конечно, намного выше, чем в алгоритме Buades & Co.
no subject
Там по make/model потом разруливается.
Очень это хрупкое место и черезжопное - разбор raw имени dcraw (а мы оттуда много наследуем)
no subject
Потому что у меня вот нет уверенности, что там CFA pattern сейчас правильная.
no subject
no subject
https://drive.google.com/open?id=0B859YEB17d8vSjdoMUhYTDRtbzQ
В фильтрах B,V и R экспозиция по 2 секунды. Фильтры — стандартные джонсоновские.
Еще приложил дампы дарков: 2, 10, 100 и 300 секунд.
Судя по статистике, bias где-то на уровне 1400. Шум примерно на уровне 0.24 отсчета в секунду.
no subject
no subject
no subject
Надеюсь, вы сумеете ее сделать по образу и подобию
no subject
А гистограмма, ну как и глазом видно, тотальная засветка, легли на максимум АЦП (или какой еще максимум) везде: https://www.dropbox.com/s/0hsxqrrnw34fq7n/Screenshot%202017-02-02%2015.08.58.png?dl=0
no subject
0x94, 0x49, 0x16, 0x61 (в принципе, если два зеленых отличаются, то возможны еще варианты).
Ну или дайте что-нибудь цветное с известным цветом (только ярким, идеально чтобы было и красное и зеленое и синее яркие в кадре) - подберу сам.
no subject
На нормальной выдержке и на минимально короткой. Оценить bias (уровень черного) и тоже в табличку добавить, иначе линейность уползет.
no subject
Чуть позже выложу кадры.
no subject
Тут прежде чем пробовать алгоритм - хорошо бы на сами данные посмотреть.
В частности, вот эта вот регулярная хрень в светах на картинке - в исходных данных нет такой же хрени?
Если есть, то чего на байера (демозаику) пенять, ей че дали, то она и сделала.
Если вы умеете выгнать эти данные в дамп (без заголовка, ну там 16 бит на пиксель) - RawDigger сумеет их прочитать (см. раздел Support of non-standard cameras в его мануале в разделе настроек).
Ну или дайте пару файликов для опытов, гляну.
no subject
Мне нужны бы пара файликов с изображением и пара темновых т.е. снятых на той же выдержке (и температуре), но с объективом закрытым крышкой.
Посмотрим что там за полосатость и нет ли ее в темновых кадрах тоже.
no subject
no subject
Ту (стороннюю) утилиту, вообще, на самом деле неплохо было бы на реальном снимке неба проверить. Вдруг и она сгодится? Учитывая то, что считывание данных с матрицы длится около минуты, те 5-10 секунд, что работает утилита — фигня.
Примеры:
https://drive.google.com/open?id=0B859YEB17d8vd2ktYUJMMHIyQlE
https://drive.google.com/open?id=0B859YEB17d8vbWVRZTk3cTNoa2c
https://drive.google.com/open?id=0B859YEB17d8vbWVRZTk3cTNoa2c
no subject
Но судя по tiff - у вас там реально же вот сеточка в светах. То есть надо или баланс белого применять, или еще чего хорошее.
Де-байеризатор отработал как надо. Дали ему сеточку - он ее нарисовал почетче.
no subject
> дамп сенсора
Просто бинарные данные? Так их из тифа чем угодно можно вытащить - хоть той же октавой. В каком формате нужны данные?
no subject
То есть я больше 5 минут на это не собираюсь тратить (примерно столько нужно для поддержки новой камеры типа "дамп сенсора")
Дамп мне нужен
- раз у вас там 16-битный АЦП, то вот прямо 2 байта на пиксель.
- порядок байт в слове - без разницы, но (чуть) лучше интеловский.
- нужно знать сколько строк-столбцов в сенсоре
- нужно знать как сделан дамп, по строкам или столбцам (удобнее - по строкам).
Если с одного раза получится - будет вам libraw с поддержкой вашей камеры.
Что касается флетов: раз у вас там байер т.е. светофильтры, то в зависимости от освещения будет (не может не быть) разбаланс по каналам (т.е. серая карта имеет разные сигналы в каналах), а значит нужен баланс белого.
Его можно накладывать до дебайера, можно после (тоже нормально выходит), но обычно делают до.
no subject
Про баланс белого — имеете в виду деление на флэт?
no subject
Обычно просто на поканальные коэффициенты умножают.
Вот представьте хорошую серую карту (с плоским спектром).
Вы на нее посветили лампой накаливания (сильно желтая), а другой раз - голубым небом (сильно синее).
Поканальные отклики (их отношение) будут же разные? А карта - как была серой, так и осталась.
no subject
no subject