![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Дебайеризация
Что-то сильно расхваливаемый авторами алгоритм дебайеризации дает довольно-таки много артефактов:
Работает, кстати, медленно. Код мало того, что не оптимизирован, так еще и авторы зачем-то почти чистый (ну, заменить new на malloc, а delete на free — и будет совсем чистый) сишный код в cpp файлы запихали.
Ищу дальше...
Работает, кстати, медленно. Код мало того, что не оптимизирован, так еще и авторы зачем-то почти чистый (ну, заменить new на malloc, а delete на free — и будет совсем чистый) сишный код в cpp файлы запихали.
Ищу дальше...
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
Обычно просто на поканальные коэффициенты умножают.
Вот представьте хорошую серую карту (с плоским спектром).
Вы на нее посветили лампой накаливания (сильно желтая), а другой раз - голубым небом (сильно синее).
Поканальные отклики (их отношение) будут же разные? А карта - как была серой, так и осталась.