Вжик, сказала пила.....

Как и обещал ранее, я тут засунул лом в японскую бензопилу сделал мишеньку для выведения алгоритмов интерполяции на чистую воду.

В том смысле, что преобразовал показанную слева картинку в DNG и скормил двенадцати демозаикам в LibRaw. Ну и тройке настоящих конверторов, попавших под горячую руку.

Ну и написал на эту тему статью, как водится, читайте: Байеровский муар.

Комментировать и обсуждать лучше там, но для тех кому лень, я комментарии тут тоже не закрываю.

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

Вот найдите три отличия (картинки кликабельны):

Гляжу я на эти две картинки и видится мне, что в HDR Photostudio на тему правильного дебайера особо не думали. Ну то есть на сто баксов спорить бы не стал, а на пару десяток - запросто.

Полная таблица наблюденного в LibRaw приведена в статье.

Кроме того, меня было неожиданным наличие сильного муара у half_size интепроляции даже по размытой мишени (по неразмытой - было понятно, что будут странности). Пораскинув мозгами, я понял, что от муара никуда не деться и half_size в силу своей локальности защищен от него меньше прочих алгоритмов.

Из позитива: LMMSE, который мне очень понравился своей простотой, на тесте на размытой мишени проявил себя весьма достойно.

P.S. Картинки (открывающиеся по клику) - превьюшки 640x640 вместо 1000x1000. Полноразмер - пока только в статье, пошел править настройки в блоге...

Comments

Увлекательнейшее занятие и чтение!
Кроме, собственно, сабжевого муара в статье то и дело мозолит глаз конвертер "Camera One"

Логично. Сейчас поправлю.

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

< с Foveon наверно таки можно !

Не-не, у Foveon цвет ползет со сменой релиза сигмовского софта :)

Т.е. там другая проблема, фильтры слишком широкие....

что же они там в С1 нахимичили?

А как они там с шарпеном (дефолтными установками) нахимичили - это просто жесть.

Возьми мишеньку (там внизу статьи обе прилеплены), покрути, вставляет.

я всякие шарпены и прочие обработки скрутил в ноль

стоит только color noice reduction в 35
всё остальное по нулям

Ниче, мы color noise reduction тоже выведем на чистую воду!

ВАХ.
А таки DCB у нас с вами разный оказался. У меня предыдущая версия, по другому выглядит.
По мне - лучше. Почту вы мою я думаю видите, могу выложить слепым линком.

И чегож LMMSE себя так ведет хотя бы на второй картинке из равтерапее форума?
У меня гдето еще были равы. Но вот не найду сейчас.

Не, не надо скрытым линком.

У меня к постпроцессингу в LibRaw очень простое отношение - если кто-то что-то делает, то я готов импортировать правки. Хорошо бы - через GitHub, но и вручную могу.

А сам это место расчесывать точно не собираюсь.

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

Я имел ввиду результат. А уж потом можно и пилу, если решите что нужно.

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

Ага, да, вижу о чем вы. При этом, со светофором и фарами лучше всего справился bilinear (из четырех опробованных, все 12 - поленился).

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

Да не подбирал я. В том то и дело. Я сначала попробовал на мире, правда сфотографированной, а потом на нескольких реальных равах. Это один из них.

Ну не хотите слепую:

http://www.faonet.com/tmp/tutubalin/porcupine-dcb.tiff
http://www.faonet.com/tmp/tutubalin/porcupine-lmmse.tiff

Потом уберу.
Ну с ДЦБ понятно почему, а чегойто ЛММСЕ тоже другой.
Результат dcraw.

На глаз похоже, что у вас auto-brightness включена. А у меня - выключена.

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

http://www.faonet.com/tmp/tutubalin/porcupine-dcb-W.tiff
http://www.faonet.com/tmp/tutubalin/porcupine-dcb-W-b40.tiff

http://www.faonet.com/tmp/tutubalin/porcupine-lmmse-W.tiff
http://www.faonet.com/tmp/tutubalin/porcupine-lmmse-W-b40.tiff

Все равно разные. Ну и извечный русский вопрос возник (кто и что).

Да вроде не надо ничего подгонять, dcraw_emu -W -T -a -q $Q - и все.

Ну вот не выходит каменный цветок.
Не полнолуние случайно, или может бури магнитные или солнечные где.
Я правда dcraw пользую. Ну немного поменялись коэффициенты со всех 1 при усреднении по всему раву, ну уровень черного был 100
во всех предыдущих.
ключи: -v -W -a -T -q и по вкусу -k 0 -b 4.0

Loading LibRaw LLC DNG Creator image from porcupine.dng ...
Scaling with darkness 0, saturation 34764, and
multipliers 1.001997 1.003029 1.002191 1.000000
LMMSE interpolation...

Исходник демозаика сравнил.
Вот то что вас интересует больше:

http://www.faonet.com/tmp/tutubalin/porcupine-lmmse-W-a-k0.tiff
http://www.faonet.com/tmp/tutubalin/porcupine-lmmse-W-a.tiff
http://www.faonet.com/tmp/tutubalin/porcupine-lmmse-W-b40-a-k0.tiff
http://www.faonet.com/tmp/tutubalin/porcupine-lmmse-W-b40-a.tiff

Ну вот вроде меньше артефактов и все тут.
Если надоел - скажите.

Я не вижу той имплементации, которой вы пользуетесь.

Могу предположить три вещи:
1) В том варианте LMMSE, который мне достался, аллоцируется на 4 байта меньше и последний элемент указывает в космос.
2) Судя по крикам valgrind, оно там с гиканьем начинает сортировать неиницализированные значения.
(эти две проблемы я поправил в LibRaw, что за версия у вас - не знаю)

3) LMMSE бывает с гаммой и без. У меня используется вариант с гаммой, возможно это неправильно, я не вдавался, могу вдаться. Если "без гаммы", то проблема-1 не проявится.

Ну начально гитом я пользоваться умею. Поэтому перед предыдущим постом сделал git clone.
Кстати поправьте линки на libraw.su для клоне.
Diff разницы, о которой вы пишите в тех исходниках и моих не нашел (я и написал). Только заголовки, #ifdef DCRAW_VERBOSE и один каст к double.

Вариант получается без гаммы (вызов с 0). Ну да, это может быть причиной.
А зачем гамма на рав данных до демозаика? А при преобоазовании в srgb ее приделают.

Про гамму: я, приделывая эти паки, голову не включал. Что мне Christos выдал, то и всосал. И по вашей наводке еще AMaZE перевсосал.

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

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

Следует ли из этого, что классические алгоритмы расчета резкости объектива (глубины или ограничения резкости по закрытию диафрагмы из-за дифракции) по сути не верны, ибо оперируют как раз попиксельной резкостью? Под "не верны" подразумеваю фотографически не верны, с позиции восприятия изображения с верным цветом. Математически понятно что верны, поскольку верно решают поставленную задачу, вне зависимости от восприятия человеком ее результата.

Формулы глубины резкости оперируют с "кружком нерезкости", который задается в 25-30 микрон для 135-го формата.

В кружке диаметром 30 микрон помещается ~20 пикселов размером 6 микрон (типичный современный размерчик).

Если вы начнете считать глубину резкости "под 6 микрон", то она у вас получится в 4-5 раз меньше "привычной".

Это если формально.

А по физике - на dslr есть anti-alias filter на сенсоре, ровно для борьбы с муаром. Который размывает "точку" на какой-то размер, пиксела 2-3, как я думаю.

То есть да, есть конфликт между разными одновременными желаниями.

Так ant-alias фильтр (он же фильтр НЧ) не только в dslr есть, на мыльницах думается он тоже должен быть. Это ведь даже не физика, это скорее математика - говорящая что нельзя с байера требовать попиксельной резкости и контраста. Ведь не пытаемся же мы цифровому аудиотракту с частотой дискретизации АЦП 44кГц скармливать частоты выше 22кГц?
Поэтому,как мне кажется, подобные "издевательства" над алгоритмами несколько "нечестные" - мы пытаемся алгоритмам подсунуть данные на которые он даже и не должны быть расчитаны. В смысле непонятно как судить по ним о качестве алгоритма. Вот например то, что у AMaZE меньше цветных артефактов говорит о том что он точнее восстаналивает яркостную компоненту или о том что он успешнее "портит" цветовую? И что важнее?

Да, все верно, поэтому неразмытый тест интересен только для получения "отпечатков пальцев" алгоритмов (хотя на многих цифровых задниках и некоторых DSLR фильтра НЧ-нету).

А вот размытый - интересен "на самом деле".

Кстати, насчет идентификации - идея безусловно хорошая.
Но вот результат из HDR PhotoStudio очень похож на то что выдает DarkTable c демозаиком AHD и Photivo c демозаиком modified AHD. Точнее это AHD modified очень похож по результату на bilinear, И вот тут непонятно становиться - это так AHD испортили или все же это побочные эффект за гранью "применимости" алгоритма.

Не-не, Дэвид Блейн.

Возьмите два окошка с bilinear и с HDR Photostudio, точно их под друг другом спозиционируйте и попереключайте. Или back-forward в браузере в одном окошке.

В данном конкретном случае оно не "похоже", оно "идентично" (плюс-минус яркость, я ее не подгонял).

Так то, да, результат очень сильно зависит и от точности (int/float) и от цветового пространства и от того что делается до-после интерполяции (скажем если оставить auto-brightness, то все начинает сильно ползать), это тоже понятно.

на мыльница сами объективы достаточно плохие + диффракция так что там AA фильтров наверно и нет...

вообще-то "равчик" какой-то багнутый получился.

я взял Rawnalyze, и вот чего увидел:

выделен фрагмент диагонали, а дисперсия по пикселям - нулевая.

Исходник легко восстанавливается через dcraw -D

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

в данном случае [сразу же] видно, что отображение на r-g-b-g выполнено неправильно (при условии, что исходное изображение могохромное).

Там цифровой CFA, берет один компонент из трех, нет места для ошибки.

я так понимаю, что целевым объектом была мира.
то, что подсовывают конвертору в сегменте 6-9, уже не мира, а муар "отображателя", причём "отображателя" совершенно нефизичной природы. Соотв. результаты интерполятора в этом сегменте уже из разряда "наблюдение за наблюдающим" - "очень тонкое извращение", но никак не инструментальный результат. :-)

Ну да, естественно, с практической точки зрения интересна размытая мишень