Обработка RAW

Некоторые пользователи LibRaw тусуются здесь, поэтому я тут и поспамлю немножко.

LibRaw 0.10 Release

Это формальный выпуск, признание того факта, что версия 0.10 - стабильна, каких-то значимых нареканий на нее за лето не было. Значимых отличий от 0.10-Beta3 нет.

LibRaw 0.11 Beta1

А это, наоборот, дивный новый мир с дополнениями и изменениями:

• Выходное изображение (результат) можно кропать. Кроппинг делается до постпроцессинга, поэтому для маленького выходного размера постпроцессинг будет очень быстрым^*.
• Сильно изменена обработка вычитания уровня черного: теперь для всех камер (за единственным, но никому не интересным исключением, которое я просто протестировать не могу^**) на этапе распаковки RAW-данных вычитание черного не производится. Дальше можно вычитать одним из трех способов: постпроцессинг (dcraw_process()) сделает все сам, если вы делаете демозаику и т.п. сами - вам подойдет новый вызов LibRaw::subtract_black(), ну и полностью самостоятельно все можно делать, данные черной рамки доступны и все такое.
• Ну и всякие изменения по мелочи, скажем аллоцированное dcraw_make_mem_image()(_mem_thumb()) теперь надо освобождать через dcraw_clear_mem(), обсуждению этого парадокса посвящен предыдущий пост.

Я знаю, этот блог читают разработчики нескольких софтин, использующих LibRaw, поэтому я и сюда немножко поспамлю.

Вышла LibRaw 0.9, из нового, крупными мазками:

• Отдельных полной/-Lite/-коммерческой версий больше нет, есть одна LibRaw. Поддерживать три немножко разных библиотеки очень мучительно.
• Никакого GPL. LGPL/CDDL/собственная лицензия, на выбор пользователя (точнее, разработчика программы, использующей LibRaw).
• Фовеона тоже больше нет. Унаследованный из dcraw код его поддержки был GPLed и при этом кисть хороший цвет не давал. Пусть пользователи Сигм как-нибудь сами...
• Розовые облака правятся автомагически, по-умолчанию эта функциональность включена. Можно выключить, смотрите документацию (это место рулится через adjust_maximum_thr).
• Много существенных исправлений в обработке RAW с камер Fuji, теперь если вы делаете постпроцессинг сами, то не нужны многие дополнительные пассы (обязательные ранее).

Павел Косенко, заполучив непубличную бету Raw Photo Processor с профилями пленки, дразнит своих читателей результатами финальной обработки.

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

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

На картинке слева - фрагмент изображения (жмякните, чтобы увеличить), к левой половине применен профиль V50 (Velvia 50) и снижен до -6 контраст (для изображения с богатыми тенями профиль Вельвии излишне контрастен), правая половина - рендеринг по-умолчанию. Впечатление, как вы можете видеть, что левую половину просто протерли тряпкой от пыли.

Естественно, подобный эффект легко достижим через, например, HIRALOAM (Unsharp Mask с HIgh-RAdius-LOw-AMount), но важно что профильное преобразование - локальное, с каждым пикселем отдельно, никаких нелокальных побочных эффектов вроде гало - не возникает.

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

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

На картинке - два результата конверсии Адобом (другие конверторы - дают другие результаты, но интегрально не лучше), две Сигмы (DP2 и SD14) и один 5DmkII. Попробуйте угадать где что.

Наиболее показателен, конечно, темно-красный патч C3, который правильный у Кэнона и совершенно разным способом неправильный у двух сигм. Но вообще, со всеми красно-оранжевыми цветами беда, да и с E3 тоже не подарок, да и вообще... SD9, кстати, еще хуже, там C2 и C3 вообще почти сливаются.

Нет, я понимаю, что счастье должно быть достижимо со специальным фильтром, но это теория такая, а на практике таких фильтров не существует.

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

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

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

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

То бишь подходы принципиально противоположны. А почему, собственно?

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

Тормоза на таможне счастливо завершились и ColorChecker Passport до меня счастливо добрался.

Имею сказать:

1. Если вы сторонник таскания ColorChecker на природу (и вообще на выезд), то эта штука как раз для вас: отличный форм-фактор (как паспорт в обложке), 100 граммов веса. Всяко лучше, чем ColorChecker Mini вставлять в коробку от DVD (хотя по данной ссылке у мужика самопальный): компактнее, жестче.

2. Часть, предназначенная для тонкой настройки баланса белого (верхняя половинка на фото) мне очень понравилась. И идея хорошая и реализация хорошая и пользоваться удобно.

3. ColorChecker (нижняя половинка разворота) - он ColorChecker и есть. Я свой пока не проверял, промеряю со временем, сравню со спектральным референсом (идет в комплекте софта), расскажу. Спектрального референса верхней половинки в поставке софта нет, при расчете профиля он не используется.

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

О консенсусе

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

Ну вот есть файл (RGB), к нему прилагается профиль (ICC), следует ожидать что на одном и том же устройстве (LCD мониторе, чтобы быть конкретным) он при включенном Color Engine отобразится более-менее разумно и одинаково.

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

Конечно, жизнь несколько богаче и 2.5 года назад я уже исследовал проблему точности CMM (Color Management Module) и написал про это серию статей. Но я наблюдал в эксперименте разумные ошибки - 5-6, а для хороших CMM и 8 бит данных сохранялись, отклонения от смены CMM в худшем случае были заметны глазом, но не были фатальными.

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

Да, на картинке слева вы видите кусочек из этого файла, показанный на одном и том же мониторе, с одним и тем же профилем монитора, одним и тем же профилем при цветовых данных файла, одной и той же программой (Adobe Photoshop) с одними и теми же настройками за исключением одной....

Не на правах рекламы, а от чистого сердца.

Если кто не знает: 18 сентября 2009 года, в Москве, в "Метрополе", будет однодневный семинар Дэна Маргулиса, посвященный преимущественно Picture Postcard Workflow (PPW) - новому быстрому workflow от Дэна.

Я уже которую неделю маленькими кусочками смотрю видео от Kelby Training, продираясь через устный английский, ибо без этого обсуждение в ACT (которое по следам видео) на душу не ложится. Умучался неимоверно и решил, что пусть лучше мне за 120 баксов устроят синхронный перевод.

• Анонс мероприятия
• Рекламная листовка про PPW, к сожалению не могу отослать к более содержательному месту в сети, ибо не нашел.
• еще чуть ближе к регистрационной форме.

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

P.S. Сожалею что не могу дать общедоступную ссылку в ACT, ибо рассылка Applied Color Theory даже для чтения требует одобрения модератора, которое, впрочем, легко дают.

P.P.S. А видео от Kelby есть на torrents.ru

Вот этот вот комментарий, как мне кажется, заслужил отдельного обсуждения.

В самом деле, имеет место некий фенОмен (который виден, например, по dE т.е. инструментально):

• C одной стороны, цифровые камеры в светах (но до начала блюминга) - высоколинейны. Т.е. отпрофилировав их в среднем тоне мы вправе ожидать приличных цветов и в светах.
• C другой стороны, практика это опровергает, если снять цветовую шкалу +2 (без всяких вылетов) и наложить профиль камеры, то цвет уползет достаточно сильно (по меньшей мере, dE вырастет в разы)

Я тут вижу несколько соображений:

• Во-первых, блюминг. И, наоборот, всякие антиблюминговые решения, которые должны характеристическую кривую загибать.
• Во-вторых, всякие игры RAW-конвертеров (которые тоже характеристическую кривую загибают).
• В-третьих, следующий интересный эффект:
  1. Давайте представим себе профилировочную таблицу, вроде ColorChecker SG. Вот на ней есть зеленый патч E9, который на 1.5-2 стопа (на глазок) ниже среднесерого.
  2. Уровень красного в этом зеленом будет еще на пару стопов ниже (красного в нем мало), потом у красного канала чувствительность на стоп-полтора хуже т.е. красным мы попадем куда-то в -5 от среднего тона (или -8 от самых светов).
     Это, на минуточку, вообще на пределе какого-то сигнала в красном.
  3. Но красный канал нужен, чтобы отличить сине-зеленый от зелено-синего т.е. в этом месте профиля красный будет с очень большим весом (т.к. сам сигнал - маленький).
  4. Но красный - зашумлен, в рассматриваемом месте он уже сильно нелинеен (по причине шума)
• Собственно, вот: профиль для таких "предельных" цветов будет как-то компенсировать нелинейность слабых каналов, а если мы переедем на 3 стопа вверх - то перекомпенсировать (ибо на три стопа вверх в красном канале уже все отлично).

Такие дела.