Обработка RAW

Про черно-белое

lexa - 06/Фев/2012 16:12

Обработка в RPP в черно-белом режиме (Film Curve + немножко экспозиция/контраст), доточено в фотошопе (HIRALOAM, ресайз, финальный sharpen). Никаких channel mixer!

Обычное ч-б, без странностей. Должны, естественно, ч-б фильтры нормально работать, но у меня их нет :)

RAW-Файл: _MG_0295.CR2 (25M), полежит дней 10, как надоест - того.

читающим в ЖЖ: извините за помятую ленту

Один из соседних домов - это старая советская панельная 14-этажка, отделанная мелкой (кафельной?) плиткой, буквально квадратики 3x3 сантиметра или около того. Серая плитка на сером цементе. Ну, многие видели.

Снимаю с рук, 1/800s, камера без антиалиасинговых фильров (и цветового алиасинга на самом деле нет, про камеру ниже), засовываю в Adobe Camera Raw 6.6 и получаю вот такую вот пятнистую прелесть (100% crop):

Черные точки там в натуре есть, я в бинокль посмотрел. Не мыли его много лет.

Оттенок поправлен настолько, насколько конвертор это может: оба движка ББ выкручены максимально влево, дальше никак.

А на самом деле снимок выглядит вот так:

В очередной раз о линейности RAW

lexa - 01/Фев/2012 12:12

Попался мне в руки даташит на АЦП AD9974, это тот, который ставят в Nikon D3 и вроде бы в D3s - тоже.

А там - вот такая вот картинка:

Это - Integral Nonlinearity т.е. максимальное отклонение от линейности в битах (LSB - Least Significant Bit).

И думаю я следующую мысль:

Уровень 3-4k - это самая что ни есть "5-я зона по Адамсу" т.е. важные полутона.
Уровень сигнала там, соответственно, 11.5-12 бит.
Отклонение от линейности - до 7 бит.
Получается, что "достоверных бит" - 4.5-5 т.е. отклонение от линейности 3-5%.

3-5% - это - довольно много, глаз заметит даже без увеличения контраста. И это - без нелинейности сенсора (не знаю, есть ли она, какая она и т.п.).

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

Вполне вероятно, конечно, что такая нелинейность возникает только при выкрученных на максимум усилителях, а на низких ISO (и коэффициентах усиления) все лучше.

Особого веселья добавляет 6-я страница, где таблица спецификаций, в максимальная INL - 15 бит. Это у 14-битного АЦП.

Update: прочистили моск. Это не битов ошибки, а ошибка, считая в единицах младших разрядов. Т.е. 8 и 15, 3 и 4 бита соответственно. А не 8. Отлегло.

О синем цвете и зеленых каналах: Panasonic G3

lexa - 02/Дек/2011 13:40

Я уже про это писал, но во-первых чисто умозрительно (на пальцах), а во-вторых не полностью верно, пришло время вернуться.

Чтобы не троллить больше владельцев Sony A77, возьмем для примера Panasonic G3. А именно, возьмем с imaging resource снимки мишени CoolorChecker и постараемся разобраться, что же камера с них выдает.

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

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

Для начала, сформулируем тезисы, которые ниже я пытаюсь проиллюстрировать.

Суть проблемы (профилирования)

Проблему я формулирую так:

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

Естественно, проблема касается не только профилирования, но и вообще захвата слабых каналов. Посмотрим с этой точки зрения на изучаемый панасоник.

О высоких ISO и о дырках: Sony A77

lexa - 28/Ноя/2011 18:38

Возьмем, к примеру, Sony A77. Самой камеры у меня нету, поэтому возьмем самплы с Imaging Resource. Я взял те, где есть большое серое поле (как на картинке в заставке этого поста) для разных ISO: 50, 100, 800, 1600, 6400, 16000.

А дальше выберем кусочек на сером поле размером, скажем, 450x200 пикселов и построим по нему гистограмму. Прямо вот по RAW-данным.

И вот что получается:

О линейности RAW: Nikon D3, D7000

lexa - 20/Ноя/2011 17:45

Нас спрашивают: "а что с RAW-кривыми в D3 и D7000?"

Отвечаем:

У D3 в 12/14-битном lossy режиме кривая в точности как у D700. Включая и артефакты, когда два разных входных значения дают одно выходное.
У D7000 в 12/14-битном lossy RAW кривая в точности как у D5000/D51000. До копейки.

В lossless-сжатии никакой кривой нет.

О линейности RAW: Nikon D700

lexa - 18/Ноя/2011 13:32

Продолжаем копаться во внутренностях алгоритмов цифровых фотоаппаратов. На очереди Nikon D700.

Благодаря любезности Ольги Бухваловой, у меня в руках оказалось 12 самплов RAW с этой камеры, один и тот же сюжет снятый:

в двух режимах битности (12 и 14);
в трех режимах сжатия: нежатый, lossless и "normal";
с двумя разными тоновыми кривыми

Вытащив оттуда кривые, применяемые при распаковке RAW могу сказать следущее:

Тоновая кривая на вид RAW-кривой не влияет, вероятно накладывается позже.
RAW-кривая есть только при "normal"-компрессии, во всех остальных случаях RAW "честный", просто или вовсе нежатый, или жатый lossless jpeg (то же сжатие без потерь используется в DNG, Canon CR2 и много где еще)

При этом тоновая кривая, сохраняя очевидный принцип (сжатие светов), в деталях заметно отличается о того, что используется в Nikon D5000/D5100.

О линейности RAW: Nikon D5x00

lexa - 10/Ноя/2011 14:14

Модифицировал свой тул для дампа RAW-кривых, так что он стал понимать не только кривые из EXIF (как у Sony), но и кривые, хранящиеся вместе с RAW-данными. И смотрю, значит, в Nikon D5xx.

Вот ~~какие большие огурцы продают теперь в магазинах~~ какая кривая накладывается на распакованное из RAW в Nikon D5000 (после чего данные становятся линейными, а до того они были пожаты обратной кривой):

Масштаб осей - логарифмический, 1 клеточка по вертикальной оси - стоп, отчего тонкие особенности загиба не видны, а общая картина видна прекрасно:

Всего разных RAW-значений - 769 (минимум кривой - 0, максимум 768). То есть больше градаций просто не будет никогда. Это "9.6 бит".
На выходе: 12 линейных бит, диапазон 0-4095
Число градаций в верхних 5 стопах: 229-161-116-86-64. Что, естественно, хуже, чем у честной 12-битной камеры (2048-1024-512-256-128), но для самых важных 4-5-го стопов сверху (полутона) это лучше чем было бы у линейной 10-битной (512-256-128-64-32).
Дальше в тени все линейно, как у "обычной" камеры без RAW-кривой.

На графике в логарифмическом масштабе видно плохо, но наклон доходит до 11 в самом верху самого верхнего стопа (распакованые значения 3687-4016), а на последних 16 строчках таблицы есть закорючка с наклоном 5. Может быть случайно так получилось :), а может быть - чтобы модуляции в самых-самых светах спасти.

Какие из этого есть следствия:

О линейности RAW и ETTR

lexa - 28/Окт/2011 17:36

Рядовой Иванов, о чем вы думаете, глядя на эту кучу кирпича?

На картинке - кривая, которая применяется к RAW-данным камеры Sony NEX-C3 при их распаковке. NEX-C3 просто первая попалась под руку, в компрессированных RAW A77 или A900 совершенно такая же по смыслу кривая, немножно отличается в деталях.

После наложения этой кривой, RAW-данные становятся линейными. Соответственно, при упаковке используется обратная кривая, линейная в тенях и полутонах и загибающаяся в светах (последних 3 стопах диапазона). По сути, три верхних стопа диапазона сжали в 1 стоп сигнала.

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

Собственно, ничего плохого в такой компрессии светов нет. От того, что в верхнем стопе будет не 2048 градаций (предполагая 12-битный АЦП), а "всего" около 600 - становится только хорошо, потому что поэкономленные 1400 градаций переезжают на второй и третий стопы сверху (полутона и следующий стоп за ними).

Об академической науке

lexa - 23/Окт/2011 10:31

демозаика

Читаю на Роеме эпический тред про РОМИП и хочу рассказать следующую историю уже про обработку фото и академическую науку.

Существует огромное количество алгоритмов демозаики. Вот несколько устаревший список. Сайт куда-то подевался, поэтому из архива, но с 2009-го появилось еще немало публикаций, поверьте (или почитайте IEEE Image Processing и подобную литературу).

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

Так я о чем, собственно? А, вот: если алгоритм получился не совсем позорным, то в разделе "сравнение", ближе к хвосту статьи, как правило публикуют сравнение: вот маяк, обработанный нашим алгоритмом, а вот маяк, обработанный стандартным AHD, LMMSE, VCD, наш найкращий!. Так парадокс в том, что "стандартный AHD" в каждой статье - свой, особенный. И "стандартный маяк обработанный стандартным алгоритмом" - соответственно, заметно отличается от статьи к статье.

При этом производители коммерческих конверторов, которые за деньги их продают, на эту тему и вовсе не парятся и используют кто AHD, а кто и вовсе bilinear interpolation для скорости. И, собственно, я согласен: типичным на сегодня 16-18Mpix демозаика нафиг не нужна при печати до A4 (а может и крупнее), не говоря о показе на 2-мегапиксельном мониторе.

LibRaw 0.14.0 (Release)

lexa - 21/Сен/2011 20:53

После трех месяцев разработки и тестирования вышла LibRaw 0.14.

По уже сложившейся традиции, помещу тут несколько отредактированный Changelog.

В этой версии одно принципиальное изменение, влекущее за собой множество мелких:

Разрешены повторные вызовы постобработки (LibRaw::dcraw_process) без переоткрытия файла парой вызовов open()/unpack(). При этом, постобработку можно повторять меняя любые параметры обработки (за исключением выбора кадра через shot_select).

В сочетании с повышением скорости обработки, на (очень) приличной современной машине можно получить:

"Почти realtime" показ изменений изображения при смене параметров RAW-конвертации в режиме половинного разрешения. На 40-мегапиксельное изображение уходит примерно 250 мсек (т.к. half-mode, то выдается 10 мегапикселей, что сильно больше любого современного монитора).
"Совсем realtime" показ изменений небольшого окошка (например, вокруг курсора) в полном разрешениии с настоящей демозаикой (получается 30-50 кадров/сек для окошка 450x300)

Осталось дождаться, пока это подопрут разработчики конверторов. digiKam обещал, но пока еще не сделал...

О legacy и форматах данных

lexa - 27/Авг/2011 09:49

Есть устоявшееся мнение, дескать обработка (изображений) в целых (16-битных) числах - это быстро, а делать то же самое в плавучке - медленно.

А я вот тут читаю ассемблер, порожденный компилятором из C-шного кода обработки изображения. Много думаю.

Имею сказать, что распространенный в настоящее время формат "16-битное целое на компонент" - это максимально неудачный способ с точки зрения эффективности обработки:

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

В результате, сплошные мучения компилятору, а результат - медленно работает. Скажем, вот такой вот код (из dcraw), который делает преобразование по матричному профилю для 3-4 входных каналов (цветов) и трех выходных:

out[0] = out[1] = out[2] = 0;

for (сc=0;сc<colors;сc++) {

  out[0] += out_cam[0][сc] * img[сc];

  out[1] += out_cam[1][сc] * img[сc];

  out[2] += out_cam[2][сc] * img[сc];

}

for(cс=0;сc<3;сc++) img[сc] = CLIP((int) out[cс]);

img[] - unsigned short, out[] - int, out_cam[] - float.

Смотрю на код, который порождает интеловский компилятор. Ну код, да. (три-)четыре load по 2 байта (количество loads зависит от colors /количества цветов/), дальше "вручную" выписанный dot product (нормальный, насколько это возможно), ну и обрезание до диапазона 0-65к и store.

Скорость работы этого кода - 100 мегапикселей в секунду на Sandy Bridge 4.5Ghz (в один поток, понятно что параллелится это на ура). Как-то не очень....

Да, считаем в мегапикселях т.к. в unsigned short у нас 8 байт на (4-компонентный) пиксель, а для float/int - 16 байт.

О фотографическом цвете

lexa - 10/Авг/2011 21:52

Вот смотрю я в новую dcraw, точнее в diff с предыдущей, и вижу там:

-      pix[0] = rp[0] + ((  200*rp[1] + 22929*rp[2]) >> 14);

+      pix[0] = rp[0] + ((   50*rp[1] + 22929*rp[2]) >> 14);

Это расчет красной компоненты пикселя при распаковке из Canon sRAW (YCbCr) в RGB.

А потом весь мир будет удивляться, отчего профили перестали подходить, причем только для sRAW (а для обычного RAW - продолжат работать).

А, да, а потом некто перестроит профили под новую формулу, а затем достанет из загашника старые DNG (где в linear-RGB все распаковано по-старому).

Так и живем.

LibRaw 0.14 Alpha

lexa - 19/Июл/2011 19:24

LibRaw

По сложившейся традиции, анонсирую тут новую major версию LibRaw, которая пока существует в альфа-варианте.

Скачать ее можно в обычном месте, почитать формальный Changelog там же, а тут хочется рассказать об изменениях человеческим языком.

До сего момента жизнь в LibRaw была устроена просто: открыл файл (LibRaw::open()), распаковал (LibRaw::unpack()), если своего постпроцессинга нет, то попользовался нашим (LibRaw::dcraw_process()). Если какие-то параметры поменялись, то все сначала, open, unpack и так далее.

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

Минус - тоже понятно какой: поменял ББ, даже в интерактивной программе и .... опять надо распаковывать RAW, а скажем в кэноновских CR2 тамошний Хаффман (lossless JPEG) устроен так, что хрен распараллелишь его распаковку. И секунда-две только на 30-мегабайтный CR2 - просто в природе вещей.

Что делаем? Правильно, меняем память на скорость.

Начиная с 0.14 байеровские данные распаковываются в один буфер, а весь постпроцессинг идет в другом. Для байеровских камер это penalty по памяти в 25% (40Mb для 20-мегапиксельной камеры), зато счастье велико есть. Для не-байеровских камер потери больше (вдвое), но там и кадры, как правило, небольшие (sRaw - 3-10 мегапикселов, фовеоны - 4Mpix), а владельцы Sigma SD1 или multi-shot задников могут и пару гигабайт памяти докупить.

О цветовом сдвиге за счет светорассеяния

lexa - 21/Май/2011 12:26

А вот другой прикол на тему светорассеяния.

На картинке две серые шкалы снятые/обработанные следующим образом

Экспозиция - одинаковая до копейки.
Обработка в ACR - одинаковая до копейки же. Какой-то баланс белого не подбирался, поставил As Shot по нижнему снимку, он чуть-чуть проврался. Но баланс - одинаковый для двух кадров.
Нижняя снята просто при рассеянном свете из окна, а при съемке верхней в кадре был яркий объект (на 11 стопов ярче патча M), световой столик, свет с которого не попадал на шкалу

Впрочем, это он на сцене не попадал, а внутри камеры очень даже попадал.

Результат таков:

На нижней (без засветки) средний тон ползет чуть-чуть, от -1/-1 (a-b в Lab) на нулевом патче до -2/-7 в 14-м.
На верхней, с засветкой, все куда масштабнее, от -5/-5 в нулевом патче до -5/-18 в 14-м

После этого удивительные цвета на HDR-снимках уже не так удивляют.

Да, насколько я понимаю, механизм примитивен: два источника света с разной ЦТ. Просто смешиваются они не на объекте, а уже в камере.

О светорассеянии

lexa - 20/Май/2011 20:17

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

Важно только, чтобы контраст сцены был более-менее контролируем, тогда получаемые данные будут интереснее.

Методика съемки

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

Под крышку поставим источник света, который не будет освещать серую карту. Я взял ~~мусорный~~ светостолик Hoya, можно было бы взять настольную лампу и загородить ее листом бумаги, несущественно, главное чтобы яркость была в пределах разумного.

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

Включенный световой столик на спотметре выглядит как 1/500-f/5.6@ISO200.
Соответственно, жалюзями я подобрал такие уровни освещения:
1. Патч M цветовой шкалы: 1/6-f/5.6@ISO200. Т.е. контраст от M до столика - ~6.5 стопов.
2. 1s-f/5.6@ISO200, контраст 9 стопов
3. 4s-f/5.6@ISO200, 11 стопов

Дальше я поставил на штатив 5DMarkII с Цейсовским 2/100-Macro, выставил там ручную экспозицию по замеру по патчу M и сделал по паре кадров, с включенным столиком и выключенным.

О фотошопе

lexa - 29/Мар/2011 21:32

Adobe Photoshop

А вот, допустим, вы обрабатываете фотографии в Фотошопе. Цветные.

Внимание, вопрос: должны ли вы обращать внимание на установку Gray profile в Color Settings, а если да, то почему?

О Rawspeed

lexa - 26/Мар/2011 16:45

rawspeed

В духе последних изысканий, важнейшим ~~из искусств~~ является правильное вычисление (и вычитание) уровня черного.

Вспомнив, как я три месяца назад брызгал слюной в направлении RawSpeed сделал svn up, чтобы убедиться, что слюна не подействовала (я в личной переписке автору тоже все рассказал).

Однако, подействовало. Внимательно я не вчитывался, но на первый взгляд все сделано очень хорошо и правильно. Если вызывающее приложение использует scaleValues(), то и прозрачно для него.

Я рад. И за RawSpeed и за использующих ее приложения.

Read more about О Rawspeed

О ДД и ББ в тенях

lexa - 26/Мар/2011 09:06

Предыдущая моя заметка О линейности в тенях как-то не вызвала того эффекта, который я ожидал. Давайте усугубим.

Представим себе некое серое тело разной яркости, снимаемое при некоем (примерно дневном) балансе белого на 5D Mark II.

Вот по уровню "среднесерого" имеем отклики (R-G-B) равные 435-1035-650. Применяя коэффициенты баланса белого 2.38-1-1.59 (я везде немножко округляю), получим серое в среднем тоне: 1035-1035-1035.

Теперь идем на 6 стопов в тени (у нас же камера с 12-ю стопами ДД по DXO Mark и с 9-ю стопами Tonal Range по тем же данным, можем себе позволить), снимаем то же серое тело.

За счет нелинейности стопов и разной чувствительности каналов накопленная за 6 стопов нелинейность будет разной.

Получим отсчеты R-G-B: 5.18-9.68-6.59 (это усреднено по большим плашкам).

Наложим тот же баланс белого, что и в полутонах. Получаем: 12.33-9.68-10.49. Был серый, стал "темно-розовый".

О линейности в тенях

lexa - 24/Мар/2011 19:48

5D Mark II

Товарищи солдаты, о чем вы думаете, глядя на эту картинку:

Как она получена:

Берем серую карту, экспонируем по экспонометру.
Дальше начинаем крутить выдержку (сохраняя диафрагму) в сторону уменьшения, пока не упремся в 1/8000.
Дальше берем (усредненные) RAW-значения для выдержки, скажем, 1/4000 и делим на значения для 1/8000.
Повторяем для пары 1/3000-1/6000, 1/2500-1/5000 и так пока тестовый набор не кончится.
Ожидаем, что значения различаются ровно вдвое.

Понятно, что затвор имеет право немножко ошибаться, поэтому повторяем три раза, для разных диафрагм. Для ISO200 получается достаточно одинаково (а другие я толком и не пробовал).

Механизм явления понятен, у нас не сигнал, а "сигнал+шум", базовый уровень шума (т.е. при околонулевом сигнале) в районе 4-5 единичек, вот шум то и жрет контраст. Если смотреть на значения еще ниже, то там график аккуратно стремится к единице (полному отсутствию контраста).

Кроме того, может быть неверно рассчитанный уровень черного (но с ним я поэкспериментировал численно и ошибки больше чем в единичку не наблюдаю).