Беда, коль сапоги начнет печи...

Вот, казалось бы, хорошая идея - давить пиковые выбросы прямо в RAW-данных. Hot pixels так можно задавить. Вот мне для LibRaw такой патч и прислали, причем, как я понимаю, он уже вовсю работает в одном опенсорсном RAW-процессоре.

На картике слева (кликабельна, по клику увидите как оно на экране при 150%) показан результат применения этого веселого подхода к снимку resolution target. Сверху - результат фильтрации, снизу - без фильтрации. Холст, масло, Canon 500D, снимок взят с imaging-resource.

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

И ведь не индус какой прислал этот патч, а вполне уважаемый человек, помянутый RAW-процессор пишет, который даже многим нравится.

Такое впечатление, что тестировать результаты собственного программирования - просто не принято в последние годы. Я эту красивую картинку получил в первом же (!) тесте (то, что туда попалась resolution target - случайность, но артефакты полезут на любых контрастных границах).

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

P.S. Второй содержательный патч из того же источника - не тестировал пока, хотя он мне идеологически тоже не нравится. Он давит maze artefacts, но должен и малоконтрастные детали тоже сгрызать.

Comments

А. То есть, удалось полностью и с хорошим запасом убрать эффект АА-фильтра.

Не, привнесенный алиасинг не имеет ничего общего с исходным. На концы линий посмотрите.

Надо было смайлики ставить, да?

Угу, со слезами на глазах

Дык потому и не ставил. Как-то оно слишком мрачно выглядит.

C кровавыми слезами. Готика.

Рискну упомянуть свой subj:
http://fireforge.net/projects/unraw/
Это далеко не панацея, но я стремился как раз к отсутствию артефактов. Было бы интересно сравнить на этом файле.

P.S. Я бы полностью перешёл на LibRaw, если бы там была полноценная возможность определить, с каким типом матрицы я имею дело (без попыток имитировать байера для Fuji). То есть я знаю про тяжкое наследие dcraw и ни в коем случае не обвиняю, это просто констатация факта.

А что вы хотите конкретно?

В отличие от dcraw, фуджевские данные достаются из RAW "как есть" (неповернутые и с черной рамкой), всякие тоновые кривые - тоже можно отключить. А повороты делаются на постпроцессинге, но вам то он не нужен, я надеюсь.

А файл - какая-то resoultion target от 500D с imaging resource, самая обычная, можно самому потестировать

В документации не написано, что будет в filters в случае Fuji.
1. Как вообще узнать, что я имею дело с SCCD? Поиск "Fuji" в названии камеры ненадёжен, ЕМНИП у Fuji был и байер.
2. Как различить
x x
x x
x x
x x
и
x x
x x
x x
x x
?
"raw-identify -v" для S9600 выдаёт "GBRGGBRGGBRGGBRG", это выглядит как повёрнутый байер.
3. Что я могу узнать про два типа ячеек с разной чувствительностью? (и когда есть такая ситуация)

пробелы скушались
я имел в виду
x_x_
_x_x
x_x_
_x_x
и
_x_x
x_x_
_x_x
x_x_

В filters будет именно порядок пикселов в паттерне, оно фуджинезависимо. И эти 49494949 еше много у кого есть.

Увы, но вам для камеры реально надо много знать (привязываясь к make/model и иногда firmware), ну вот хоть цветовые данные и коэффициенты баланса белого для стандартных освещений. Какого-то универсального способа постпроцессинга, который бы со всеми RAW просто брал бы и работал - не существует.
Вот к этим данным и CFA layout полезно тоже хранить свой, так как вы его понимаете....

Быстро посмотрел исходник.

Ну так вы, как раз один из немногих, кто использует LibRaw по назначению - именно для достатия данных из RAW. Весь постпроцессинг у нас - "чтобы было", не надо его использовать (а кто использует - тот пусть не жалуется).

Единственно что - начиная с 0.9-й версии вызов FC(row,col) заменен на COLOR(row,col) и этот самый COLOR как раз с фуджей нормально совместим и все прозрачно делает (см. например пример 4channels в LibRaw). До 0.9-й версии в этом месте был логический баг (т.е. 4channel тоже работал, но Fuji обрабатывался отдельно).

Скачал LibRaw-0.10.0-Beta1.tar.gz, там 4channels.cpp отмечен 28 марта. Это так и должно быть?

И всё-таки непонятно, что делает COLOR(row,col) на отсутствующих пикселах (SuperCCD HR, http://en.wikipedia.org/wiki/Super_ccd).

Пардон, неверно вас послал :)

2010-04-21 Alex Tutubalin
* Finally fixed inconsistency in Fuji files processing
* New COLOR(row,col) call to get bayer color index in image[] array
* Old FC() call is deprecated and will be removed in future releases
* unprocessed_raw sample switched to COLOR() call

Смотреть надо в unprocessed_raw.cpp

Про отсутствующие пикселы - не понял. Там две прямоугольных сетки со смещением. Более того, судя по aspect ratio, смещение там вовсе не по диагонали....

Полтора года назад я про это много тут писал: http://blog.lexa.ru/tags/fuji_superccd

Про отсутствующие пикселы я просто думал, что может быть единственная сетка.
А про aspect ratio мне казалось, что это артефакт формата RAW, а не свойство геометрии матрицы.
(но не готов спорить, пусть производитель рассудит)

P.S. Похоже, что без перечисления камер в коде про универсальность можно забыть, а переход на DNG какой-то не очень массовый...

Ну какой артефакт может быть в aspect ratio, если в S5 размер каждой картинки - 4300x1400 пикселов.
Вторая половина - это вторые 4300x1400, через один по горизонтали, всего значит 4300x2800.

Т.е. там сдвиг не по диагонали, а именно по вертикали, иначе размер был бы другой.

А перечисление в коде - ну многое можно генерализовать, но далеко не все. Очень много сортов этого самого.

Много сортов - это да, но есть ещё один нюанс: нет автоматической поддержки новых камер знакомых типов. Для этого DNG мог бы сильно помочь.

 Проблема, в первую очередь, в цветовых данных. Т.е. в DNG они тоже есть и если камера порождает native DNG с ними, то это лучше чем ничего, но сама по себе тамошняя цветовая модель мне не кажется такой уж хорошей.

Прочитал описание DNG, нашёл 3 недостатка:
1. Сам метод получения цветовых матриц (реакция матрицы только на стандартные спектры). Я бы предпочёл минимизацию средней ошибки для произвольных случайных спектров на входе. И в качестве бонуса - нормальная поддержка четырёхцветных матриц.
2. Пишут про разные виды стандартного освещения, но нет ответа на простой вопрос: какую цветовую матрицу нужно использовать, чтобы поставленый рядом с камерой монитор выглядел прозрачным? Меня интересует только то освещение, которое перед камерой.
3. Для Fuji описывается только геометрия, но не два типа пикселов.

Какие там ещё есть проблемы?

P.S. При всей своей неидеальности он таки единственный опубликованый :-(

Моя камера однажды глюкнула и выдала несколько файлов с таким порядком пикселов:
\/\/\/
\/\/\/
\/\/\/
Это выглядело как наложение двух растянутых картинок (одна зелёная, другая наоборот). Подозреваю, что это сработал какой-то рудимент от другой камеры. То есть там большие затейники, без поллитры не разобраться.

А у S2 - сжатие в другую сторону:

http://blog.lexa.ru/2009/01/11/primenenie_psixotropnix_preparatov_k_obra...
(там картинка есть).

Оно просто выше чем шире, 2144x2944

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

+100

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

Ну вообще "дивный новый мир опенсорца" какг-бэ-говорит-нам: "можешь лучше -- сделай, не можешь -- ..."

Вот и я об этом - на ровном месте взяли и сделали *хуже*

Add new comment