Обработка RAW

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

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, коя в полтора-два раза быстрее)

Индикация пересветов в 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 (квадратик с розовой окантовкой) и посмотрим на его гистограмму:

Про 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 делаем быстро из файлов низкого разрешения, а финальный рендер делаем в фоне).
Имею про это сказать:

RawDigger + RawSpeed, вторая попытка

Если репортить об ошибках, то они будут исправлены. Качаем-тестируем RawDigger+RawSpeed, вторую попытку:

Исправлена "ошибка строчной развертки" для форматов, где использовался RawSpeed, а длина строки RAW была некратна 8. Таких, на удивление, немного.

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

Mac: RawDigger+RawSpeed

Граждане фотографы-маководы!

Помимо виндовой версии, RawDigger с встроенным RawSpeed теперь доступен и для Mac:

Качаем: по ссылке из этого поста

Это альфа-версия: тестировано на нескольких маках, теперь хочется на живых тестерах.

Что изменилось:

  • Открытие файлов .CR2, .NEF, compressed-.DNG - должно стать заметно быстрее. Файлов .ARW, .PEF, .SRW, .ORF, .RW2 - несколько быстрее (незаметно).
  • Для файлов с камер Sony (не всех) - значения пикселов и уровня черного умножатся на 4.
Других видимых изменений быть не должно, все остальное должно быть как в версии 0.9.12. Если у вас изменилось что-то еще, особенно в худшую сторону - пишите.

Второе невидимое (я надеюсь) изменение - это переход с Qt 4.8.1 на Qt 4.8.3.

Update: достоверно известно о глюках со старыми .CR2 (30D, 5D), репортить уже не надо.

Снова о странностях Nikon D800

О странностях D800 я уже писал, кроме того слегка отметился в дискуссии у Владимира Медведева, похоже что тема богатая.

Смотрел всякие кадры, где была сфотографирована белая стенка с вилкой, чесал репу, но на ровных плашках особо выдающегося ничего видно не было. А тут прислали ссылку на такой вот кадр: imaging-resource.com/PRODS/nikon-d800/YDSC_0099.NEF.HTM, собственно вот он открытый в RawDigger:

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

Смотрим подробнее:

RawDigger + RawSpeed = RawDigger

Можно попробовать: качаем по ссылкам из этого поста.

В чем фишка:

Большие файлы CR2, NEF, жатые DNG - открываются на 300-500мс быстрее на быстрой машине (i7-2600k@4.5Ghz), на медленных разница должна быть еще заметнее. На других поддерживаемых RawSpeed форматах (Sony, Panasonic, Olympus, Pentax, Samsung) - разница тоже есть, но не такая большая. Все неподдерживаемые форматы открываются, как и ранее, LibRaw.

Больше (кроме файлов Sony о которых ниже) - фишки не должно быть (еще чуть больше памяти используется). Собственно, это и хочется проверить.

Сравнить можно открыв закладку Preferences, менять положение галки и жать Apply. Если при этом не меняются статистики, гистограммы и т.п. - то все отлично.

Что мне интересно:

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

RawSpeed возвращает значения пикселов для Sony в 4 раза бОльшие, чем LibRaw. Это ни на что не влияет в реальной жизни. При этом, конечно, на такое плавание уровня черного машинка не рассчитана и при нажатии Apply и стоящей галке 'Reset Black Level on file load' - ничего не поресетится в диалоге.

Это нормально и надо забить т.к. в следующих версиях поддержка Sony RawSpeed-ом будет отключена: разница в скорости для этого формата копеечная (не сотни миллисекунд как для CR2, а десятки), изменение значений в 4 раза рвет башню, а всякие полезные вещи вроде 'ARW2 Hack' и отключения тоновой кривой - не работают т.к. RawSpeed ничего такого не умеет.

Update: достоверно известно о глюках со старыми .CR2 (30D, 5D), репортить уже не надо.

LibRaw+RawSpeed=LibRaw :)

RawSpeed - это такая библиотека раскодирования RAW, которая:
  1. Очень быстрая (к примеру, 21-мегапиксельный файл от Canon 5D2 распаковывается на моей машине за 230мс, а код на основе dcraw делает это за 750мс. Притом, это сильно улучшенный мной код, до улучшений было больше секунды, насколько я помню).
  2. Поддерживает мало форматов, правда все они популярные (свежие камеры Canon, Nikon, Olympus, Panasonic, Pentax, Samsung и DNG-файлы).
Авторы darktable давно просекли эту фишку и используют LibRaw как fallback на неизвестных камерах, а как основную библиотеку для открытия RAW - используют RawSpeed.

В то же время, RawSpeed распаковывает данные в буфер с очень похожим (но немного разным) форматом, поэтому использовать RawSpeed в качестве читалки файлов изнутри LibRaw (но иметь при этом единый API, единый постпроцессинг и т.п.) - было делом техники. И эта техника - применена в LibRaw 0.15-Alpha4.

Что получилось

  • LibRaw::open_file()+LibRaw::unpack() /т.е. распаковка/ - в ~3 раза быстрее на CR2, в ~2-2.5 раза быстрее на NEF, в 1.5-2 раза быстрее на прочих поддерживаемых форматах. Реально это заметно на больших NEF и CR2 (выигрыш в 400-500 миллисекунд на моей i7-2600K @4.5Ghz), соньки и раньше распаковывались быстро, а у остальных форматов редко бывают совсем уж большие файлы.
  • dcraw_emu -h ..список из 182 файлов.. - без RawSpeed было 150 секунд, стало 100 секунд. Разница "не в 2-3 раза" потому что постпроцессинг не изменился (хотя с -h он и так быстрый)

RawDigger 0.9.12

Я был уверен, что написал анонс и сюда, однако его не вижу. Аберрации сознания, значит.

RawDigger 0.9.12 (Beta) вышел (позавчера вечером):

Относительно technical preview есть только одно изменение: на Винде 64-битная версия ставится в "Program Files", а не в "Program Files (x86)", это я документацию по InnoSetup дочитал до этого места.

Анонсы в подходящих сообществах, форумах и т.п. - приветствуются.

RawDigger 0.9.12 (technical preview 1)

Граждане фотографы и примкнувшие к ним!

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

Вот он:

Мне интересны глюки, мешающие выпуску на широкую публику: падения, полностью неправильное поведение и т.п. Всякая мелочь, вроде разрешенного "Average green" для черно-белых RAW - не является шоу стоппером (в частности, по той причине, что монохромных камер у людей - примерно ноль).

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

Отдельная просьба: не надо эту версию более нигде анонсировать. Если она работает, то буквально завтра я ей поменяю название и номер билда - и выпущу. А если нет, то надо же доделывать. На неприслушавшихся к этой просьбе - затаю.

Что новенького

Про меру соответствия критерию Лютера-Айвса

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

Несколько месяцев назад я задал вопрос на forum.rudtp.ru, по некоторым причинам (не имеющим отношения к цветовой науке) тема была спрятана и закрыта, но недоразумение разрешено и она теперь распрятана и открыта.

Вот она: "... лучше соответствует критерию Лютера-Айвса".

Если имеете что сказать по теме - я буду благодарен. Лучше - прямо там, если по каким-то причинам удобнее здесь, можно и здесь. Очень хочется разобраться.

Pages

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