Обработка RAW

Oly EPL3, часть 3: это НЕ ослабление светового потока

В комментариях ко вчерашнему посту про постепенную "деградацию" пересвеченных областей на камере Olympus E-PL3 многократно высказывалась идея, что дело в ослаблении светового потока:
  • за счет захода солнца
  • за счет "помутнения органики" (микролинз и/или светофильтров)

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

Как следствие, в районе 41-го снимка в серии (4-й пример в предыдущем посте), который с отдельными крапинками насыщенных пикселов, мы увидели бы эти крапинки распределенными случайно.

Посмотрим, так ли это.

Вот 40-й снимок в серии, увеличение 1000%, обведены крапинки, объединившиеся в столбик:

41-й снимок:

Oly EPL3: оно устало!

В продолжение вчерашней темы про Oly E-PL3.

В той длинной тайм-серии нашелся набор кадров с такими вот условиями:

  • Начиная с первого кадра серии - солнце в кадре.
  • Перед началом (под-)серии у камеры был перерыв на ~15 минут (я ел еду и про серию маленько забыл). То бишь оно успело немного отдохнуть.
  • Это уже совсем вечер, весьма прохладно, существенного нагрева от солнца - не было.

Вот первый кадр из серии (красное - OverExposure в исполнении RawDigger):

Гистограмма квадратика (на солнце):

Oly EPL3: загадочное поведение в насыщении

Есть у меня Oly E-PL3, который я использую как мыльницу (с набором фикс-оптики). И угораздило меня летом попытаться снять для нее кадры для Time-Lapse.

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

Ну то есть да, обычные розовые облака, но если посмотреть гистограмму серого квадратика на розовом, то там вовсе безумно странное:

RawDigger 0.9.15 (релиз)

Так как на RC1 никто не жаловался, RawDigger 0.9.15 пошел в народ. Переходите по ссылке и скачивайте.

Помимо упомянутых в прошлом посте удобств для профилирования камер, в 0.9.15 добавлены и другие фишки:

  • 32-битная виндовая версия маркирована как совместимая с /3GB switch (инструкции по включению на 32-битных Windows). В результате 32-битной версии RawDigger доступны 3GB памяти на 32-битной винде (с включенным /3GB) и 4GB памяти на 64-битной винде (включать ничего не надо, правда зачем бы на 64-битной винде гонять 32-битную версию приложения - не могу придумать). А в результате этого - 80-мегапиксельные RAW с Leaf/Phase One прекрасно рендерятся в RGB, памяти хватает.
  • Поддержаны нежатые NEF-файлы с камер Nikon D5100 и D7000 (этот режим доступен после хака фирмвари).
  • Для файлов с полным диапазоном значений 0..65535 (16-битные задники) корректно индицируется передержка и не менее корректно считается статистика передержки.
  • Поправлена ошибка при сохранении (таблицы замеров, гистограмм), когда выбран файл для сохранения и нажат Esc.
Жаловаться на эту версию лучше бы в правильном месте

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

RawDigger 0.9.15 (RC1): удобное профилирование камер

Граждане фотографы!

В очередной раз предлагаю потестировать Release Candidate свежего RawDigger:

В версии 0.9.14 в RawDigger была добавлена удобная работа с цветовыми шкалами, но результат этой работы выводился в виде усредненных RAW-значений: в диапазоне значений камеры, без баланса белого, без гамма-коррекции. Как следствие, для нормального использования в программах профилирования эти данные приходилось предварительно обрабатывать в Excel или подобных программах: накладывать ББ, масштабировать, гамма-корректировать.

Версия 0.9.15 исправляет этот недостаток, теперь можно получить CGATS-файлы, пригодные для прямого скармливания в Profile Maker, Argyll и подобные программы.

Кроме этого, 0.9.15 умеет корректировать неравномерность освещения мишени.

Подробности:

Про Nikon D7100

В связи с выходом Nikon D7100 без противомуарного фильтра имею сказать:

  • Сам факт такого выхода - приветствую. Надо, естественно, на картинку посмотреть, но так вот из общих соображений 16Mpix на 4/3, 24Mpix на APS и, соответственно, 40-50Mpix на 24x36 - более-менее адекватны очень хорошей оптике. С учетом понятно а) прикрытия ее на пару стопов б) дифракции.

    Понятно, кроме АА-фильтра там еще микролинзы, которые тоже дают угля. Ну и вообще, надо бы у D7100 посмотреть на MTF, стало ли лучше без АА-фильтра.

  • С очень хорошей оптикой все непросто. Пресловутый Дистагон 1.4/55 (стоимостью в районе 3 килоевро, весом примерно кило и фильтровой резьбой 82мм - и это все полтинник) - не останется одинок. Не так оно и просто - сделать хороший полтинник, а хороший широкоугольник - еще непроще. С телевиками, конечно, немного полегче.

    То есть и цена у оптики будет "как у MF", и размеры/вес - судя по всему, тоже.

  • Да, автофокус при таком разрешении - сильно теряет смысл. Равно как и съемка с рук.
Все это вместе выглядит забавно. Хотите влезть в MF-область по качеству (ну хоть краешком, сравнивать можно с MF на пленке, и только "по разрешению") - получите MF и по цене и по особенностям работы.

Update: ссылка в тему: blogs.zeiss.com/photo/en/wp-content/uploads/2011/12/en_CLB41_Nasse_LensNames_Distagon.pdf

LibRaw 0.15.0-Beta4

Тем временем вышла LibRaw 0.15 Beta4.

Изменения:

  • Исправлено возможнле переполнение буфера, возникавший при использовании библиотеки RawSpeed для распаковки некоторых форматов файлов (проявилось на Samsung NX-100, но вообще подвержены очень многие некомпрессированные форматы)
  • Добавлены новые методы
    C++ API: LibRaw::recycle_datastream(),
    C API: libraw_recycle_datastream()
    и новый код ошибки LIBRAW_INPUT_CLOSED для вызовов unpack/unpack_thumb()

    Эти методы/вызовы позволяют освободить file handle (и ассоциированные буферы), если ваше приложение больше не собирается вызывать unpack() или unpack_thumb() и, сдедовательно, может разблокировать файл и освободить память, которая использовалась для чтения RAW-файла.

  • Поддержаны Multishot-файлы Imacon Ixpress 39Mpix
Первое изменение - это замазывание ошибки в RawSpeed, за буфер вылазит именно она (а значит надо дать буфер побольше). Это - цена оптимизации, выбирать по k бит и каждый раз проверять не вылезли ли - очень дорого.

Вдогонку про Nikon D5200

Я был неправ, когда писал что у Nikon D5200 нет тоновой кривой. Это в RawDigger тоновой кривой нет при работе через RawSpeed (а я про это постоянно забываю). А в этих файлах - очень даже есть.

Вот такая вот (синяя линия):

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

В остальном - все обычное, примерно как в D5100: 11.6 бита (3072 градации всего), странная загогулина наверху кривой.

Обращаю внимание, что клеточки на графике - "квадратные", 512 единиц по каждой из сторон. Для удобства чтения.

Про Nikon D5200

Update: мои рассуждения об отсутствии тоновой кривой были вызваны моей торопливостью. Тоновая кривая есть и приводится тут. Текст данного поста править не стал, пусть останется для истории (на него уже сослались много где).

Попались тут в руки тестовые кадры с D5200. Ну я их сразу в RawDigger и давай мучать:

Кадр, как мы видим, немножко недодержан, максимум на уровне 5900 (из чего мы делаем очевидный вывод о "14-битности"), тоновая кривая отличается от обычной никоновской.

Возьмем кусочек серого поля (прямогольник на нем) построим гистограмму:

О цифровом среднем формате и экранных превьюшках

Разбирался вчера с вопросом "а поддерживает ли RawDigger файлы с новых Leaf/PhaseOne" (это которые IQ180, Leaf Credo 80 и т.п.).

В процессе - набрел на совершенно феноменальный эффект, который мое отношение к цифровому MF заметно изменил.

А именно (манипуляции - долгие т.к. автор тестовых снимков запретил их републикацию):

  • Берем Вот этот вот обзор Leaf Credo 80
  • Скачиваем файлики из из любезно предоставленной автором ссылки на Dropbox.
  • Нам нужен вот этот вот файл Mamiya Leaf Credo and Cambo Wide AE.iiq, на нем эффект проявляется лучше всего.
  • Напрямую - он ничем (кроме Capture One) не открывается, но на самом деле это ZIP-файл (сделанный этой самой Capture One), содержащий 0.IIQ (собственно RAW-файл) и несколько файликов с настройками Capture One.

    Распаковываем его: unzip "Mamiya Leaf Credo and Cambo Wide AE.iiq" или еще как и открываем получившийся 0.IIQ RawDigger-ом

  • Выбираем RGB Render и автоматический WB (с другим ББ лично мне эффект виден хуже).

    Внимание: если у вас 32-битная версия RawDigger, то RGB-render будет недоступен при настройках по-умолчанию. Preferences-Display Options-Disable RGB Rendering for files larger... и поставьте туда эдак 90. Но с большой вероятностью - поможет не сильно, а просто начнет падать. 80-Mpix файлы требуют реально много памяти: 160M на байер, 640M на рендер, 320M на экранную копию, а их нужно две т.к. double buffering - и с учетом фрагментации не влезть в 2Gb даваемые 32-битным программам очень даже легко. А при показе второго кадра - он сначала рендерится, а потом из памяти выносится старый, т.е. расход памяти почти удваивается (лечение: Misc Options - Unload opened file before loading new one).

  • Смотрим. Видим эффект (кадр резко отличается от всего с "узкой цифры"). Или не видим.
Кадр является некоторым аналогом "кирпичной стенки" в том смысле, что мелкие детали там именно каменной кладкой и образуются.

Так как перепубликация картинок - запрещена их автором, попробую объяснить словами что именно я там вижу:

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

При этом, окошко у меня - 1200x800, т.е. каждый пиксель образовался из примерно 8x8 пикселей исходника.

Казалось бы, с многомегапиксельных узких (FF и APS) камер в окошке 1200x800 тоже будет оверсамплинг, ну пусть не в 8x8 раз, а в 4-6x4-6. Но ТАКОГО эффекта локального контраста на необработанных снимках - я, пожалуй, никогда не видел. А всяких чужих необработанных фото я смотрю много.

После того, как эффект вербализован - его стало видно и на других кадрах, где не все поле кадра резкое, а только часть. Вот, скажем, кадр PhaseOne IQ180 Lizard Far.iiq (который не требует упражнений с unzip т.к. это чистый RAW с камеры, а не архив, включающий настройки Capture One) - ящерица на нем выглядит особенно, но я это заметил только после предыдушего кадра, с резкостью на все поле, поняв что именно надо искать.

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

P.S. В окошке ACR и в файлах открытых затем в фотошопе - эффект виден хуже. Судя по всему, по той причине, что RawDigger никогда ничего не сглаживает, ни при увеличении, ни при уменьшении, а у адобовских тулзов имеется сглаживание/подавление артефактов при уменьшении. Но "кирпичная стенка", открытая ACR-ом в фотошоп тоже смотрится необычно, хотя и менее необычно, чем в RD.

RawDigger 0.9.14

Вышел RawDigger 0.9.14. От Release Candidate ничем (кроме номера версии) не отличается. Перепост и распространение - приветствуются.

RawDigger 0.9.14 RC1

Граждане фотографы!

А потестируйте, кому не лень, новый RawDigger:

  • RawDigger-0.9.14-RC1-RU-Setup.exe
  • RawDigger-0.9.14-x64-RC1-RU-Setup.exe
  • RawDigger-0.9.14-RC1-RU.dmg
Уже потестировали. Берем 0.9.14 отсюда и наслаждаемся.

Из новых фишек там есть вот такое вот (доступно через Menu-Selection-Selection Grid):

Если простыми словами, то появился инструмент для удобного замера цветных шкал. Натягиваете на шкалу сетку того же размера, размещаете углы, таким образом, чтобы красные квадратики попадали в ячейки мишени - и вуаля. Вуаля в том, что по одной кнопке (Selection to Samples) в таблице Samples оказываются ваши замеры, которые потом можно сохранять (в CSV и CGATS), смотреть гистограмму и все такое прочее:

О зонной системе в цифровую эпоху

Вот раздумываю я, как должна выглядеть зонная система в светах в эпоху цифры (когда никакого плавного загиба ХК в светах более не существует). И видится мне как-то так

Зона 5: примерно как экспонометр настроен. На 2.7-3.4 стопа вниз от уровня насыщения для большинства камер при дневном свете. Можно, например, жестко решить что 3 стопа от насыщения для зеленого канала, независимо от освещения, так еще проще.

Зоны 6-8: от экспонометра до насыщения одного из каналов.

Зона 9: насыщены 1-2 канала, по трепыханиям в оставшемся можно как-то восстановить яркостную составляющую, а цвет - только всесьма приблизительно (и, скорее всего, ошибочно).

Зона 10: как и завещал Адамс, без деталей. Все три канала - в насыщении.

С зонами 0-4 все не менее интересно. Как-то так, наверное:

Зона 0: все три канала "ниже шума", доверять яркости нельзя, все черное.

Зона 1: 1-2 канала "ниже шума", доверять яркости как-то можно, цвету - нельзя

Зоны 2-4: нормальная цветная картинка в тенях.

Понятно что нумерация зон несколько условная, между "зоной 1" и "зоной 9" запросто может оказаться как больше 7 стопов (малошумная камера, низкое ISO), так и меньше 7 стопов (все наоборот). Вряд-ли в этом случае осмысленно рисовать больше зон, просто "нормальные цветные зоны" будут чуть шире или чуть (или сильно) уже одного стопа. Это не говоря о том, что обе границы "зоны 1" можно провести только пролетарским чутьем.

Ну и "яркостные зоны", 9-я и 1-я, будут разной ширины для разных камер и разного освещения.

Хочу какого-то обсуждения, наверное.

Логарифмируя шум

Прислали тут темновой кадр с Canon 7D, снятый на ISO3200 (на 1/250s, если вдруг существенно). Стал я туда смотреть и несколько удивился....

Берем, значит, RawDigger, открываем этот файл, ставим уровень черного в 0, чтобы увидеть не только правую половинку пика, смотрим. Видим вот такое:

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

Берем и включаем логарифмическую вертикальную ось. И видим такое:

Ищем альфа-тестеров

Граждане отдыхающие цифровые фотографы!

Если вы:

  • cнимаете в формат RAW (или много снимаете в RAW),
  • имеете немного свободного времени для тестирования новой софтинки,
  • имеете компьютер и фотокамеру, удовлетворяющие описанным ниже требованиям,
то вы можете совершенно бесплатно поработать альфа-тестерами нового вареза.

А какого вареза - пока скажу только тестерам (открытое тестирование начнется, по моим ощущениям, не раньше, чем через пару месяцев).

Чтобы принять участие в этом развлечении, вам нужно

  • Зайти на сайт beta.libraw.com
  • Зарегистрироваться там, согласившись с правилами участия (которые сводятся к "не разглашать без разрешения")
  • Подождать, пока аккаунт будет мной подтвержден (о чем придет E-mail)
  • Установить пароль, скачать с сайта дистрибутив, попробовать, отреагировать.

О сортах RAW у Sony

Про тоновую кривую в новых камерах Sony я уже писал и повторяться не буду.

Но тут переписывался с Ллойдом Чамберсом на тему Sony RX1 (прежде всего, конечно, как щупать RawDigger-ом неподдерживаемые камеры, как уровень черного определить и т.п.) и обнаружил массу веселья в самом формате ARW, точнее в новых его версиях.

В камерах Sony используются три формата записи RAW:

  • "Старый ARW" - камеры поколения Sony A100-A290 (точный список не составлял, по ощущениям это именно "старые камеры"). Это обычное такое хаффмановское сжатие, без потерь.

    При использовании этого режима - RAW-файлы будут сильно разного размера, в зависимости от детализации и шума.

  • Нежатый 12-битный RAW. Просто пишутся 2 пикселя в 3 байта, без сжатия, без потерь, без прочих глупостей. Этот формат используется в A900 в режиме "большие файлы" (~36Mb + размер JPEG), в Minolta 5D, возможно в еще каких-то, опять же не изучал.

    При использовании этого режима размер файлов "примерно одинаковый", полтора байта на пиксель плюс размер JPEG-а и EXIF-блоков. Соответственно, с A900 получается 36-37-мегабайтный файл.

  • Формат "ARW2" (так его называет Dave Coffin, а за ним и я).

    Этот режим записи используется во всех новых камерах Sony: NEX-xx, SLT-Axx, RX1, RX100. Его можно включить и на A900 (никогда не было этой камеры, надеюсь что этот режим включился не насильно после апдейта фирмвари, а есть возможность переключения юзером).

    При использовании этого режима RAW-файл имеет размер "1 байт на пиксель" (+JPEG и EXIF, конечно). 24-мегапиксельная A99 или NEX7 (или A900 в этом режиме) выдают, соответственно, 24-мегабайтный файл.

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

Вот как выглядит исходный код кусочка декодера (тот кусочек, который собственно распаковывает) этого формата в библиотеке RawSpeed (в dcraw - то же самое по смыслу, но Dave Coffin - истинный хакер и всякими глупостями вроде getBits(7) не пользуется):

LibRaw 0.15.0-Beta3

Вышла LibRaw 0.15-Beta3, доступна в обычном месте.

Никаких серьезных внутренних изменений нет, только поддержка новых камер:

  • Canon 6D и EOS M
  • Casio EX-ZR100
  • Fujifilm X-E1
  • Leica D-LUX6 and V-LUX4
  • Nikon P7700
  • Olympus XZ-2
  • Panasonic G5
  • Samsung EX2F
  • Sony RX-1

Об эффективном использовании современных CPU

Практика вот к этой презентации:

Берем 36Mpix файлик с D800, распаковываем егонный RAW в 16-битный однокомпонентный битмеп, дальше начинаем процессить.

Процессим без "интерполяции", т.е. 4 пикселя исходного байера образуют один выходной пиксель (режим half_size у LibRaw/dcraw). Получаем такие вот времена:

  1. LibRaw::dcraw_process() плюс формирование RGBA-битмепа: 420ms.
  2. Перепишем этот самый dcraw_process() на SSE3, процессить будем в плавучке (с эмуляцией особенностей dcraw), выдаем такой же 8-битный RGBA: 110ms (и более-менее понятно где еще выиграть миллисекунд 20).
  3. Добавим в предыдущий суп еще: подсчет RAW-гистограммы и сохранение исходного float-битмепа нетронутым (и без дублирования по памяти), т.е. баланс белого и конверсию цвета делаем два раза, один раз для подсчета гистограммы результирующего файла, а второй раз - прямо на вывод. 180ms.
Это все был один поток. Распараллелим его:
  1. "распараллеленный dcraw_process": 130ms (так в RawDigger сделано, тамошний RGB render устроен именно так, но гистограммы и статистика в эти 130ms не входят, равно как и битмеп для показа там готовится иначе и потому дольше).
  2. "распаралеленный ассемблерный dcraw_process": не делал, ожидаю <50ms (потому что вариант с двойным вычислением, как следующий, но без гистограмм - 57ms).
  3. параллельная ассемблерная версия с гистограммами, сохранением float RAW: 75ms
Сравнивая последний вариант с последовательным C-шным, нужно понимать, что в C-шном варианте еще где-то 200ms придется на гистограммы и еще 200 на конверсию int16 - float. То есть реальное ускорение от SSE и параллельной обработки - раз в 10 (75ms против 800). И это оптимизированный C-шный, в LibRaw это место заметно пооптимизировано в сравнении с исходным dcraw.

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

О процессинге RAW: плавучка или целое

Обработка RAW в плавучке позволяет избавиться от артефактов вылета за диапазон, да и вообще получить более качественную картинку.

Тем интереснее обратные случаи.

Возьмем вот такой вот кадр:

Это D800 с его приколами в светах, вот на света и посмотрим.

Если обработать картинку dcraw (или LibRaw, которая дает побитово такой же процессинг, если автоматическое определение максимума отключить), то в светах в "середине верха кадра" мы увидим такое вот:

LibRaw 0.15.0-Beta2

По традиции, анонсирую LibRaw 0.15-Beta2

Полный changelog доступен у библиотеки в гнезде, а тут я остановлюсь только на самом существенном:

  • Поддержано 20 новых камер:
    • Canon: G15, S110, SX50
    • Fujifilm: F800EXR, XF1
    • Nikon: 1 J2, 1 V2, D600
    • Olympus: E-PL5, E-PM2
    • Panasonic: FZ200, GH3, LX7
    • Pentax: K-5 II, K-5 IIs, K-30, Q10
    • Sony: SLT-A99, NEX-5R, NEX-6
  • RawSpeed может использоваться не только для байеровских данных, но и для полноцветных (3-цветные DNG, sRAW).
    Правда если вы захотите использовать эту фишку, то вам придется запатчить RawSpeed. Тот же патч положен в дистрибутив LibRaw (в каталоге RawSpeed).
    Пользы от RawSpeed достаточно много даже для нежатых DNG: к примеру, 60-мегабайтный 3-цветный нежатый DNG распаковывается за 130мс родным кодом LibRaw и за 70мс - при помощи RawSpeed.
  • В API добавились флажки, позволяющие понять - использовалась ли библиотека RawSpeed, а если да, то к чему это привело.
  • В очередной раз перебраны потроха (интересно только тем, кто в них копается, сам LibRaw API не изменился)
    • В 0.15-Alpha-Beta1 в imgdata.rawdata были два указателя: raw_image указывал на буфер с байеровскими данными, а color_image - на буфер с 4-компонентными RGBG. Ну то есть для байеровских RAW первый был не нулевым, а для полноцветных - второй.

      В Beta2 этот самый color_image ращеплен на два: color3_image ненулевой если в буфере (на который он указывает) лежат 3-компонентные данные, а color4_image - если данные надо рассматривать как 4-компонентные.

    • Введенный в Alpha4 параметр imgdata.sizes.raw_pitch (шаг строк в RAW-буфере) теперь в байтах, а не в пикселях. И один и тот же raw_pitch используется для доступа к imgdata.rawdata.raw_image, color3_image, color4_image
    Кому интересно совсем в деталях - читайте исходник LibRaw::raw2image() и понятно будет все.

Pages

Subscribe to Обработка RAW