Adobe

На третий день зоркий глаз заметил....

А вот, к примеру, Adobe DNG SDK.

Лежит такой у них на сайте, dng_sdk_1_4.zip. И лежит. Если и меняется - снаружи незаметно. 4 года уже лежит.

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

Скачал, посмотрел.

И вот действительно, dng_sdk_1_4 скачаный сегодня и скачаный года полтора назад (октябрь 2015 в моем случае) - это разные DNG SDK. Заметно так разные.

Сюрприз!

P.S. C XMP Toolkit такого свинства нет, там и файлы для скачивания со своими именами и XMP_Version.h унутре есть.

Снова о любимом формате DNG

Перед вами, дети, две RAW-гистограммы. Сверху - оригинальный файл, снизу - конверсия в DNG при помощи Lightroom 5.7:

(кликабельно)

Извините за размер, так вот было удобнее сделать.

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

Справедливости ради, это sRAW то...

Про Adobe DNG и Adobe Bridge

Изучал тут поведение Adobe Bridge с DNG и XMP файлами, а оно смешное:

  • В DNG может быть XMP-секция, Bridge ее, естественно, читает. И пишет. Можно туда Keywords или рейтинги написать.
  • Если рядом с DNG лежит его XMP-файл (c тем же именем и, опционально, с тегом photoshop:SidecarForExtension="DNG"), то все берется оттуда, а XMP-секция в DNG - игнорируется.
  • Если начать редактировать метаданные, содержимое XMP + результаты редактирования будут записаны в DNG, а XMP-файл - удален.
  • С другими известными Бриджу файлами он так себя не ведет - пишет все в XMP (хотя в том же CR2 - может быть XMP-секция).
Меня это все сильно удивляло - ну сказано ведь "писать все в XMP", но нет.

А потом - доперло. Наберут по объявлениям. Типичный же workflow с DNG такой (если они не из камеры вылезают):

  • Запускаем DNG-конвертор
  • И фигачим DNG прямо в тот же каталог, откуда берем исходные RAW (сделать что-то отдельное - это ж морока)
В результате - в одном фолдере оказываются filename.raw, filename.dng, соответственно filename.xmp может быть только один. И прятать метаданные прямо в DNG - это хоть какой-то разумный выход из этой дурацкой ситуации. Потому что 8.3, завести filename.raw.xmp и filename.dng.xmp - не моги.

Вишенка на торте - поведение бриджа с файлами, которые он вроде бы знает (формат известен), а вроде бы и нет. Я пробовал с файлами от Sony A6000 (обычный ARW) и от Canon G1X Mark 2 (в этом файле есть XMP-секция):

  • Sony: писать метаданные отказывается, говорит не наш участок не знаю такого формата.
  • Canon: отказывается писать кейворды, но пишет рейтинги. Но пишет их не в сам файл (хоть там и есть XMP-секция) и не в sidecar-XMP, а в отдельный файл в каталоге .BridgeLabelsAndRatings (сказано, конечно, писать в XMP)
Все мысли на эту тему уже выражены в реплике Ильи. Количество специальных случаев, которые приходится обрабатывать, - удивляет.

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

Суббота для человека или человек для субботы?

Со всевозрастающим изумлением читаю дискуссии про memcpy, glibc, Линуса, Adobe и Дреппера:

(русскоязычные - они свежие, на LWN все уже отшумело три месяца назад).

И думаю я следующую думу: сама тема не оставляет (девелоперов) равнодушной, раз столько понаписали, делит девелоперов на 10 две группы очень четко. Причем, для меня ответ очевиден, равно как он столь же очевиден (но другой) для другой группы.

А значит - это прекрасный вопрос для собеседования, причем важен не столько ответ, сколько его объяснение, а за вторую сторону можно легко потроллить. Я бы сказал, что от PM и выше - просто обязательный вопрос, а для кодеров - мировоззренческий. И не надо собирать в одной команде (компании, стране, вселенной) людей, отвечающих на этот вопрос по-разному.

Для тех кто в танке, суть проблемы (при взгляде с одной из сторон):

DNG, уровень черного и dcraw

В стандарте DNG 1.2 правильной поддержке уровня черного уделена масса внимания: можно задать базовый паттерн произвольного размера с разными уровнями (скажем, поканальными) и коррекцию этого паттерна для каждой конкретной строки и столбца. Для большинства практических применений этого достаточно, нормально описать таким способом нельзя, пожалуй, только неповернутый паттерн Fuji SuperCCD.

Надо сказать, что Adobe DNG Converter креативно пользуется этими возможностями. Скажем, для новых камер Canon (смотрел 50D и 5DmkII) считается только базовое значение, тогда как для старых (смотрел 400D) считается уровень черного для каждой строки. И это правильно, товарищи!

Но вот dcraw, а за ней и все приложения, использующие её код, начиная с LightZone и ACDSee, а заканчивая LibRaw, поступают с этими данными тупо и глупо: все что есть в DNG-файле усредняется и это среднее вычитается из всех значений.

Естественно, это все касается только тех форматов данных, где вычитание базового черного не делает сама камера. Из распространенных - это камеры Canon (все), ряд моделей Sony и многие P&S камеры.

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

Пользователи LibRaw будут со временем осчастливлены кодом получше, а вот пользователям других производных от dcraw я бы посоветовал форматом DNG без нужды не увлекаться.

Универсальный (нецензурно) архивный (нецензурно) формат

О сколько нам открытий чудных....

DNG мы уже пинали с примерами, но пинали мягко, оставаясь в рамках Adobe workflow. Там проблемы, которые создает DNG заметны, только в довольно экстремальных ситуациях.

Но вот если мы живем не Адобом единым, то жизнь становится куда веселее. Вот к примеру LighZone. Отличная по своим идеям программа, все такое, но вот распаковку RAW там делают запуском внешней dcraw.exe.

О мониторном софтпруфинге

srgb-proof-400.jpg Проект LibRaw стал настоящим — у нас завелся живой форумный тролль. Как от многих таких троллей, от него есть и некоторая польза: если кормить его вдумчиво, то можно заодно разобраться с какими-то вещами, до которых не доходили руки. В данном конкретном случае я разобрался с мониторным softproof (т.е. эмуляцией одного монитора на другом) и с пользой от этой техники для обработки изображений:

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

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

Мониторный Softproof и Gamut Warning в Adobe Photoshop
...мониторный софтпруф может быть полезен тем, кто публикуется на фото-сайтах и подобным электронным образом, особенно для тех, кто обзавелся монитором с расширенным охватом и/или использует в качестве рабочего пространства - RGB пространство с охватом, много большим чем мониторный (например, Adobe RGB на обычном мониторе).
Помимо этого, вполне возможна ситуация, когда монитор не способен отобразить все цвета изображения - и это надо вовремя детектировать.

AdobeLabs PixelBender: отличная штука, но....

Что-то я анонс пропустил, а сегодня случайно наткнулся на Pixel Bender от Adobe Labs.

Казалось бы, отличная идея: пишешь шейдеры kernels на скриптовом языке, они исполняются на видеокарте или на CPU. Анонс тоже завлекал: дескать поддержвается любая разрядность цвета, все такое мультиплатформенное и хорошее. Есть плагин для Photoshop т.е. все изыски можно прямо в бою и использовать.

В-общем, я раскатал губу, скачал, поставил, закатал рукава и приготовился творить.

Photoshop CS4: первые впечатления

Два дня всерьез пользую CS4, впечатления смешанные:

  • 64-битный - сцуко, быстрый. Если быть точным, то сохранение (layered tiff, PSD, PNG) не кажется быстрее прошлых версий, а вот работа с большим количеством здоровых открытых файлов - не тормозит.
  • Естественно, ни один из старых 3rd-party плагинов под 64-бита не работает. В результате двустадийный Workflow (RPP - Lab - Photoshop - RGB) стал трехстадийным (RPP - Lab -PSx64(основная обработка) - Lab - PSx32(плагины)). На каждом шаге количество обрабатываемого падает в разы, поэтому жить можно.
  • 32-битный по ощущениям медленее.

Но есть некоторое количество довольно мерзких багов.

Subscribe to Adobe