Фото

О сортах 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) не пользуется):

Об эффективном использовании современных 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, которая дает побитово такой же процессинг, если автоматическое определение максимума отключить), то в светах в "середине верха кадра" мы увидим такое вот:

О маках у фотографов

Статистика даунлоадов RawDigger 0.9.13 (в процентах)

OSRU (75% - россия+украина)EN (45% США-Канада, остальное - европа)
Windows, x645248
Windows, x323719
Mac1132

Забавно, да.

P.S. Сумма в последней колонке не совпадает т.к. дробные части разлеглись неудачно, .3, .4 и .3.

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() и понятно будет все.

О переходниках Hasselblad - Mamiya 645

Вдруг кому интересно.

  1. Если вы используете, к примеру, мирексовский адаптер а на нем бутерброд из хасселевской оптики и переходника с хасселя на 645-ю мамию
  2. И если у вас, как и у меня, в этом бутерброде нет бесконечности (не безумная проблема на тилт-переходнике, можно наклонить на градус-другой, но неаккуратненько).
  3. То: на ebay появились переходники другой конструкции (не Fotodiox и полные аналоги), которые оную бесконечность дают.
Отличаются конструкцией, у них не два кольца вставляющиеся друг в друга (как у Fotodiox), а выточено из одного кольца и байонетная часть сделана накладной пластиной.

Вот такие вот:

Но есть ньюанс, о котором ниже.

На следующей картинке, под катом, те, которые бесконечности не дают, все черные:

RawDigger 0.9.13

Как и предсказывалось, вышли новые "релизные" версии RawDigger:

Русская 0.9.13 от 0.9.13-RC3 отличается только номером версии. Соответственно, RC3 вам должна сказать, что есть версия поновее.

Отличаются языковые версии, как и всегда:

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

RawDigger 0.9.13 RC3

Попрошенные вчера вечером изменения оказались настолько небольшими, что я их взял и сделал.

Хочется надеяться, что "релиз" 0.9.13 от этой версии будет отличаться только названием версии:

Изменения:
  • Убраны всплывающие информационные окошки (при чтении файла и т.п.), теперь эти тексты выводятся в нижней строке окна.
  • При достижении пределов по "Next file"/"Prev file" - программа (противно) пищит и сообщает о проблеме в нижней статусной строке.
  • Опция 'Multi-core/Multi-CPU processing' - ликвидирована, как и было обещано. Многопоточность включается сама при количестве CPU/ядер более одного.
  • Актуализирован мануал.

RawDigger 0.9.13 - второй релиз-кандидат

Кто скачал "RC1" (т.е. по ссылкам из предыдущего поста до 22:10 10.11.12 время Московское) - возьмите теперь RC2. Исправления:
  • 'Next File' не работала на первом файле каталога (да, я так тестирую :) - у меня в тестовом каталоге, так уж совпало, первый файл лежит неподдерживаемого формата и на него я никогда не попадал).
  • Если Next или Prev - запрещена т.к. мы дошли до одного из краев, то при смене порядка сортировки в Preferences - это запрещение сбрасывается.

RawDigger 0.9.13 (RC3)

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

Вашему вниманию предлагается RawDigger 0.9.13 Release Candidate 1 2 3:

Update: В RC2 исправлена бага с "залипанием" на первом файле каталога: на нем не работало "Next file".

Часть из этих изменений уже была показана изумленной публике, а часть - совсем свежая.

Документация пока не обновлена, остается от версии 0.9.12, поэтому привожу

Changelog с комментариями

Про смотрелки RAW

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

А есть какая-то смотрелка RAW, которая позволяет баланс белого менять/ставить? А то у меня куча всего снята в UniWB и, мягко скажем, неудобно.

Ну то есть я смотрю в Adobe Bridge: выделяешь сотню кадров, открываешь в ACR, ставишь ББ, закрываешь и дальше можно смотреть. Но уже достало... Я готов даже денег дать (как-то разумно, в пределах $20 легко, а $50 - только если реально хорош) за такой варез.

Update: добрые люди подсказали, у faststone нужно выставить автобаланс и показ RAW (а не превьюхи). Правда 4 секунды на кадр (с 5D2) в режиме half и 10 в режиме full-size (и некоторые строчки в fsplugin01.dll) говорят мне, что у него в пузе dcraw 8.99 (а даже не LibRaw, коя в полтора-два раза быстрее)

Если бы губы Никанора Ивановича да приставить к носу Ивана Кузьмича

Вдруг кому будет интересно:

Экспериментально установлено, что "челюсти" Really Right Stuff ставятся на головы PhotoClam (я пробовал на PC40, но хочется надеяться, что они все совместимые).

Обратное - неверно. Т.е. в челюстях PhotoClam прорезы под шипы на шейке слишком узкие и не влезет.

При этом, резьба в шейке голов RRS - дюймовая (1/4"), а в шейке PhotoClam - метрическая (на взгляд, M6), т.е. винты нужны родные. Соответственно, если нужен нестандартный винт (как на RRS-овской PCL-1), то придется иметь по отдельному винту на каждую голову.

Индикация пересветов в RawDigger: версия для Mac и обновление виндовой.

Если кто скачал версию "OE1" из предыдущего поста, то самое время ее стереть и взять новую. Если кто хотел маковскую версию, то вот она: Изменения (в виндовой версии) касаются тех режимов, которые я сам не использую, а потому и не тестировал:
  • На "черной рамке" не рисуется область недодержки.
  • При показе RAW в режиме "1 пиксель на пиксель" (а не размазывание пиксела на 2x2) - нет противного серого фона.

RawDigger: индикация пересветов (и челубеев)

Индикация выбитых светов (и недодержаных теней) - сделана.

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

Выглядит это так:

В окошке Display появились пимпы OvExp и UnExp, если их включить, то отрисовываются выбитые пикселы (красным, как в ACR) и недодержаные (синим).

В окошке OvExp/UnExp Stats - показывается статистика по пикселам по всему изображению. Сколько выбито в штуках и в процентах (от общего количества пикселов данного цвета).

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

Естественно, уровни отсечки сверху и снизу - настраиваются. Мануал пока не правился, поэтому опишу настройки прямо тут.

Обращение к владельцам 5D2 (2)

Граждане фотографы - владельцы 5D mk II!

С прискорбием сообщаю, что мое обращение подействовало слабо - прислали мне файлы считанные единицы, гораздо меньше примеров, чем было перепостов. Мне пока недостаточно данных для анализа. Ну прямо вот хоть в RawDigger вставляй уведомление "я нашел у вас кадры от 5D2, не соблаговолите ли снять тест...".

Ну вот хоть на выходных - ну потратьте 20 минут. Жалко 20 минут или нету колочекера - потратьте 10 (ровное поле есть у всех). Жалко 10 минут - потратьте три.

Программа-минимум: Мне нужны темновые кадры (т.е. с крышечкой на объективе или на камере) с такими выдержками:

  • ISO200: 1/125, 1/30 и 1s. По три кадра каждой выдержки.
  • ISO1600: 1/125, 1/30 и 1s. По три кадра каждой выдержки.
  • ISO6400: 1/125, 1/30 и 1s. По три кадра каждой выдержки.
Программа-медиум: снимаете таки серое поле как описано (по экспонометру и -5EV) и с теми же выдержками - темновые кадры.

Программа-максимум: с колорчекером (или его представлением на экране): в соответствии с описанной технологией

Вот даже минимум - уже очень поможет. А дела там - реально же на три минуты.

Обращение к владельцам Canon 5D Mark II

Не корысти ради, а общественной пользы для!

Тема разницы экземпляров (sample variance) цифровых камер регулярно всплывает, но каких-то систематических исследований мне неизвестно. Не систематически регулярно приходится слышать от владельцев нескольких ( одинаковых ) тушек, что они на самом деле разные (разный шум, разный banding, все разное), но никаких цифр видеть не доводилось.

Есть желание этот пробел устранить, придумать и отработать методику и все такое прочее. Начать мне проще с хорошо известной мне камеры Canon 5D Mark II.

Обращение к владельцам Canon 5D Mark II

Уважаемые владельцы поименованной камеры! Пожалуйста, пожертвуйте 10-20-40 минут своего времени общественной пользы для, снимите десяток-другой-пятый кадров и пришлите их мне.

Мне бы надо примеров с десятка разных камер. Можно больше.

Другие камеры пока не интересуют, отработаем методику займемся и другими.

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

Что снимать

Опять-снова о светах у D800(E)

Тема странности D800 поднималась тут минимум два раза (1 и 2) и в комментариях ко второму обсуждению я просил владельцев таких камер поснимать колорчекер с вилкой по экспозиции и прислать мне результаты.

Двое откликнулось, прислали мне в сумме под 20 гигабайт NEF-ов (так много - потому что на разных ISO), совсем детально я эти файлы еще не разглядывал, стал просматривать только две серии на ISO250 (почему-то первые попались именно они) и увидел там странное.

На третьем слева сером квадратике сделаем selection (квадратик с розовой окантовкой) и посмотрим на его гистограмму:

Q: фотошопные книжки, Kindle edition

Когда-то давно я хвалил книжку Vincent(а) Versace 'Welcome to Oz'.

А вот сейчас мне интернет принес книжку того же автора про правильную разнообразную конверсию в BW. Вот такую: From Oz to Kansas.

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

Практический вопрос: если купить Kindle Edition, то в каком виде там окажутся примеры, предусматривает ли Kindle-формат то, что кроме книги бывают всякие дополнительные материалы? Аппаратного киндла нету (испортилсо), буду использовать программный (на PC и на ойпаде).

Update: вопрос снят: при первом же появлении примеров в тексте, отсылают к секции Last Words, а там написано откуда скачать примеры. Буду, значит, пользоваться книжкой как Donationware - куплю только если понравится....

Опять о позитивном корейском дюрале

О "позитивном корейском дюрале" имени Маркинса я уже писал и у меня такие стаканы стояли/стоят на двух мелких штативах: на Gitzo 2541L маркинсовский TB-20, а на 1541 - Кирковский FP100.

Правда во все выезды, которые не пешком (водные и автомобильные), я последние годы брал Gitzo 3530L. Он, конечно, на 400 граммов потяжелее, но устойчивость с 25-й серией совершенно несравнимая. 2541-й остался для выходов пешком, а 1541-й - для таких выходов пешком, где каждый грамм на счету и куда телевики длиннее 135(200)-мм все едино не берутся т.к. не унести (т.е. автономка в горы).

В 35-м Gitzo меня устраивало все, кроме ширины его площадки: 13.5 сантиметров - это дохрена, в рюкзаке занимает очень много места, а если/когда вяжешь снаружи-сбоку, то цепляешь все кусты и деревья. 25-й, у которого ширина по верху около 10 сантиметров, в этом смысле кардинально лучше (собственно, неудивительно, занимаемое место пропорционально квадрату диаметра).

Но пару месяцев назад я наткнулся на Markins TH-30. И хотя $180 (с доставкой) за кусок дюраля и болт - это сильный перебор, проблема ширины штатива настолько назрела, что платил я их с радостью. И, до кучи, TH-200 для 2541-го штатива тоже купил.

И вот что вышло:

Про DNG 1.4

Не прошло и полгода Прошло почти 7 месяцев с выпуска LightRoom 4, и Adobe таки выпустила в свет спецификации DNG 1.4 и DNG SDK той же версии (брать отсюда).

Существенные нововведения:

  • Lossy-компрессия. Правда вот такая вот:
    Lossy JPEG is allowed for IFDs that use PhotometricInterpretation=34892 (LinearRaw) and 8-bit integer data.
    То есть 8-битные линейные данные после демозаики. На практике этот режим полезен, пожалуй, только для какой-то quick-n-durty обработки, например в очень ограниченных ресурсах. Да и то, линейные 8 бит - это как-то не того, разве только тонововая кривая как-то спасет.
  • Поддержка floating point (16, 24 и 32 бита) - теперь в стандарте (не знаю, будут ли float-DNG от darktable быть совместимыми). К этой поддержке прилагается новый поддерживаемый формат сжатия (ZIP/Deflate), а к этому формату сжатия - новые предикторы 'Horizontal Difference X2 и X4', которые, по идее, позволят эффективно сжимать байеровские данные.
  • Transparency masks, которые позволяют, к примеру, удобно/эффективно хранить в DNG склеенные панорамы с неровным краем изображения.
  • ProxyDNG Files - файлы с низким разрешением, но содержащие указание на оригинальные размеры. Как следствие, всё редактирование, сделанное над Proxy - можно без изменений перенести на исходный файл. Если этот Proxy-вариант еще и пожать с потерями, то получается достаточно вкусно для многих применений (помимо работы на мелких ноутбуках и планшетах, в голову приходят еще всяческие операции с несколькими кадрами сразу: панораму или focus stacking делаем быстро из файлов низкого разрешения, а финальный рендер делаем в фоне).
Имею про это сказать:

Pages

Subscribe to Фото