Два пути в никуда

в поисках утраченного смысла

За последние 10—15 лет цифровая фотография вытеснила фотопленку практически из всех традиционных областей применения. Конечным потребителям проданы сотни миллионов цифровых фотокамер, не считая камер, проданных в мобильных телефонах. Столь массовая индустрия не может существовать без стандартов — и таковые, казалось бы, имеются: стандартизованы устройства для хранения данных (flash-карточки) и формат изображений JPEG — наиболее массовый и удовлетворяющий потребности подавляющего числа пользователей.

Однако формат JPEG далеко не всегда удовлетворяет требованиям профессионалов — фотографов, дизайнеров, персонал prepress-бюро, а тем более фотобанков и фотоархивов. Зачастую не удовлетворяет он и требованиям "продвинутых" фотолюбителей. Именно поэтому многие модели фотокамер, обычно позиционируемые производителем как профессиональные и полупрофессиональные, поддерживают, кроме JPEG, и запись изображения в так называемом "формате RAW". У стороннего наблюдателя может создаться впечатление, что RAW — это тоже такой стандартный формат, обеспечивающий лучшее качество — "качество для профи".

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

RAW и JPEG: в чем разница

При сохранении фотографии в формате JPEG все стадии обработки изображения (установка баланса белого, контраста, насыщенности и т.п.) выполняются самой камерой перед записью файла. Напротив, RAW-снимок — это практически неизмененные, "сырые" данные, полученные при считывании со светочувствительной матрицы фотокамеры и сохраненные в файле.

Рассуждая в классических фотографических терминах, JPEG — это уже практически готовый снимок (аналог Поляроида), а RAW — полуфабрикат, аналог латентного, скрытого изображения на непроявленной пленке, требующий обязательной обработки /проявки/ ( Обработка исторически называется "конверсией RAW", а программы для нее — RAW-конверторами) — с той существенной разницей, что плёнку проявить можно лишь однажды, а RAW — столько раз, сколько захочется, и при том — воспользовавшись разными "проявителями" (конверторами), экспериментируя столько, сколько понадобится — до достижения требуемого результата.

Разумеется, чтобы получить на выходе камеры JPEG, также выполняется конвертация RAW. Соответствующий конвертор — часть интеллекта камеры. Если конвертация, выполненная самой камерой, оказалась неудовлетворительной (плохой контраст, неестественный цвет, слишком плотные тени, слишком яркие света), то исправить существенные ошибки этой стадии при дальнейшей обработке изображения на компьютере уже невозможно. При сохранении в формате JPEG значительная часть данных изображения, зафиксированного камерой, потеряна безвозвратно. Кроме того, используемое в JPEG сжатие с потерями сильно ограничивает и возможности последующей коррекции снимка.

При записи изображения в формате RAW (в отличие от записи в формате JPEG) в камере никакой цифровой обработки изображения не выполняется — вся обработка ведется после съемки, на мощном компьютере с хорошим монитором. Это позволяет использовать более сложные алгоритмы и визуально контролировать как процесс,так и его результаты. Как правило, качество результирующего изображения оказывается существенно выше, а кроме того, можно подбирать параметры обработки в широких пределах, со значительно меньшим риском возникновения постеризации , роста шумов и появления иных артефактов, т.е. разрушения изображения.

Обработка RAW-файлов требует и дополнительных навыков, и дополнительных затрат времени, поэтому данный формат используется меньшинством фотографов: продвинутыми любителями и профессионалами — в тех случаях, когда качество результата важнее скорости его получения или когда условия съемки не допускают применения JPEG в связи с его ограниченным по сравнению с RAW динамическим диапазоном. Кроме того, иногда съемки в RAW требует заказчик, а иногда ее используют в качестве своеобразной подстраховки. Впрочем, "меньшинство" — это миллионы пользователей во всем мире.

Отнюдь не способствует распространению RAW-формата — при всех его преимуществах — и почти полное отсутствие разумных стандартов на этот формат, в результате чего участники рынка вынуждены иметь дело с десятками (или сотнями — как считать) различных форматов данных.

Форматы данных и совместимость

Фотография — одна из тех отраслей, которая во многом зависит от прозрачного и взаимно-однозначного обмена данными между участниками процесса. Порой эти ожидания оправдываются (JPEG, TIFF, многие другие "стандартные" форматы), однако, в случае RAW — это совсем не так. Например, фотограф, выполнив съемку в RAW и просмотрев ее результаты с помощью своего конвертора, не может вслепую отдать RAW файлы в подготовку к печати — из-за использования различных конверторов или даже различных версий одного конвертора результаты конвертации могут оказаться разными, — даже если фотограф передаст параметры конвертации вместе с самим файлом.

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

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

С точки зрения производителей камер объяснить закрытость форматов очень просто:

  • зарезервированные и вновь появившиеся поля данных могут давать данные (информацию к размышлению) конкурентам;
  • зачастую поля данных добавляются "на всякий случай", раз уж дизайн камеры позволяет эту информацию получить, так нужно ее сохранить — вдруг да пригодится. В число таких полей, например, входят и поля для диагностики и технического обслуживания камеры. Документировать все эти поля — означает затем отвечать за их наличие и содержание.
  • открытость формата может породить ненужную (производителям!) общественную дискуссию. Например, получив доступ к информации о том, на какую дистанцию был сфокусирован объектив, потребитель норовит с рулеткой проверить точность работы автофокуса и затем начинает предъявлять "мотивированные претензии". В реальной истории с претензиями к автофокусу камеры 1D MkIII , моральные и материальные убытки компании Canon могли бы быть неизмеримо большими, если бы метаданные RAW были бы официально документированы и, разумеется, дело не ограничилось бы одной лишь компанией Canon.
  • ряд производителей пытается зарабатывать еще и на программах обработки RAW (а некоторое время назад — они еще и владели монополией на обработку своих форматов RAW), плодить конкурентов им не надо. Мало того, производители часто утверждают, что конверторы, созданные независимыми разработчиками, компрометируют их камеры, не позволяя "выжать" правильный цвет, всю возможную разрешающую способность, а к тому же и отличаются повышенным уровнем шума.

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

Остальные участники рынка, напротив, заинтересованы в открытости форматов и в уменьшении имеющегося сегодня их "зоопарка":

  • Фотографы: хотят обрабатывать снимки, сделанные разными камерами, пользуясь одним-двумя стандартными процессами (как это было с плёнкой), им выгодна конкуренция между разработчиками программ обработки данных, дающая надежду получить или лучшее качество, или меньшую цену, или и то и другое сразу, хотят взаимодействия между программами разных разработчиков.
  • Фотолаборатории: сегодня вообще практически не могут принимать в серийную обработку RAW — отсутствие стандартных процессов приводит, разумеется, и к отсутствию стандартных устройств для обработки. Сегодняшняя работа с RAW — это всегда ручная печать.
  • Разработчики программ обработки: чем больше существует разных форматов и чем менее они документированы, тем большее время разработчики тратят на тяжелую работу по изучению чужих форматов и раскодированного их смыслового содержания — работу, которой при наличии минимальной доброй воли производителей, можно было бы избежать. Зачастую поддержка новых камер появляется в распространенных программных продуктах с задержкой на месяцы.
  • Архивисты (в широком смысле, от фотобанков и фотослужб компаний до отдельных фотографов): для них буйство форматов есть просто кошмар, не дающий спать спокойно. Кроме самих данных, им приходится хранить программы, умеющие работать с этими данными, инструкции по использованию этих программ и свои собственные записи о том, какой именно способ применения этих программ — вплоть до последовательности выполнения коррекций — приводит к нужному результату. Сегодня уже зафиксирован случай, когда изменения в формате RAW привели к несовместимости сверху вниз: параметры обработки, установленные в старой версии программы, не воспринимаются, а иногда приводят к "падению" более новой версии. Мы говорим о конверторе Nikon Capture. Возможно, приведенный пример — не единственный. Авторы не проводили специальных исследований этого вопроса.

Скорость развития цифровой фототехники не позволяет создать универсальный формат данных, который устроил бы всех и навсегда. Вместе с тем, существующее сегодня изобилие явно избыточно. И вызвано оно, в числе прочего, отсутствием внятных попыток стандартизации.

Фотографической индустрии всегда было присуще разнообразие, порой, совершенно неуместное. Появлялись и вымирали форматы пленки (828,110, 126, APS, disc film), хирели или вовсе исчезали вариации химического процесса (Polacolor, C-22, K-14). Не все знают, чем вызвано упомянутое разнообразие (к сожалению, помимо экономических и технологических факторов, сей калейдоскоп зачастую объясняется просто попыткой привязать к себе потребителя или заработать на предоставлении прав конкурентам); но все знают, к чему это привело: архивы, накопленные в "форматах-неудачниках", могут поддерживаться только профессиональными архивными службами, а частным лицам и мелким компаниям это не под силу. Очень не хотелось бы, чтобы подобную судьбу повторили накапливаемые сегодня цифровые фотоархивы. Особенно, если учесть, что за последние пять лет фотографий снято примерно столько же, сколько за предыдущие тридцать.

Данные, метаданные и смыслы

Одним из существенных достижений цифровой фотографии является то, что кроме самого снимка (данных) хранятся еще и дополнительные метаданные:

  • Данные — это сам снимок: информация о яркости света для каждой точки сенсора фотокамеры. Как правило, в RAW-формате эти данные никак не обработаны (разве что пропущены через нормализующий усилитель перед преобразованием в цифровой вид), а в случае формата JPEG — подвергнуты цветовой и тоновой коррекции.
  • Метаданные — это данные о снимке: дата и время съемки, экспозиционные параметры, данные о характере освещения (балансе белого), модель и заводской номер камеры, использованный объектив и так далее.

Описание формата данных (или пара-метаданные) должно описывать как способ хранения данных снимка (битность, способ сжатия и т.п.), так и метаданные.

Пара-метаданные (собственно, формат данных RAW-файла) — это то, что придает хранимым битовым последовательностям смысл ("в данном поле хранится фокусное расстояние объектива, выраженное в десятых долях дюйма"). Так как производители формат не документируют, то поиском смысла байтов приходится заниматься "хакерам" (в хорошем смысле слова), которые различными способами составляют свои описания форматов (об этом мы поговорим чуть ниже).

В целях дальнейшего изложения, поделим данные и метаданные на такие группы:

  1. необходимы для получения качественного изображения из RAW, например: производитель и модель камеры, использованная при съемке чувствительность, данные о балансе белого, использовалась ли вспышка. Ну и сами данные снимка, то есть карта освещённости, зафиксированная сенсором.
  2. могут быть использованы при обработке RAW: использованные настройки камеры (контраст-насыщенность), параметры оптики и фокусировки и т.п.
  3. не нужны для обработки, но полезны для показа, каталогизации и поиска: дата и время, GPS-координаты, автор снимка, описание снимка и т.п.

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

Так же нельзя сказать, что данные и метаданные совсем не документированы, но документированность эта соответствует известной шутке про ядро FreeBSD:

  • Данные и некоторая часть метаданных "документированы" в известной программе dcraw (автор Dave Coffin), которая на сегодня поддерживает (умеет распаковать) форматы 312 цифровых камер.
  • Метаданные "документированы" в программе ExifTool (автор Phil Harvey), которая на самом деле оперирует с гораздо большим объёмом информации, чем просто EXIF — программа распознаёт и расшифровывает и ряд служебных полей, в том числе внедряемых в RAW-файл некоторыми конверторами.

Интересно, что по объему программного кода ExifTool почти на порядок превышает dcraw (75 тыс. строк кода против 8 тыс). Это соотношение вполне адекватно отражает соотношение трудоемкости расшифровки данных и метаданных: метаданные гораздо разнообразнее.

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

В результате даже авторы программ обработки RAW не могут с уверенностью утверждать, что они все делают правильно (кроме конверторов от производителей камер). Забавным следствием является то, что сравнение качества программ обработки RAW на 1-2 примерах становится бессмысленным.

Революционная ситуация

Таким образом, в индустрии цифровой фотографии складывается революционная ситуация в полном соответствии с определением В.И. Ленина:

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

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

Как известно, перерастание революционной ситуации в революцию зависит от наличия партии, готовой и способной возглавить борьбу...

Как оно работает сегодня?

Встает резонный вопрос: а как в этом хаосе работает хоть что-то? Разработчики в основном используют два подхода, хоть как-то снижающих энтропию:

  1. Часть программных решений поддерживает весьма ограниченное количество форматов данных, что резко упрощает задачу.
  2. Если автор программы заявляет поддержку большинства распространенных форматов, то скорее всего он использует исходные тексты dcraw либо как готовое решение, либо как документацию. В числе прочих это делает и такая крупная компания, как Adobe. Приходится констатировать, что огромная индустрия зависит от одного человека и 8 тысяч строк написанного им кода.

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

Adobe DNG

Формат DNG предложен компанией Adobe в сентябре 2004 года в качестве универсального формата "цифрового негатива", предназначенного для вечного архивного хранения данных. Спецификация DNG 1.0 был исключительно плохо продумана (например, там не было места для хранения данных маскированной рамки, которые используются в алгоритмах шумопонижения), через полгода Adobe предложила спецификацию DNG 1.1. Помимо описания формата, был выпущен и DNG SDK, положительных отзывов о котором слышно не было, ибо сделан он был в качестве "отписки": удобочитаемая документация, внятные, полезные примеры, а также программные заготовки практически отсутствуют.

Прежде чем двигаться дальше, проверим оба утверждения Adobe: об архивности и об универсальности.

Архивный?

Эксперимент очень прост: сымитируем ситуацию, которая могла бы иметь место 3 года назад, для чего возьмем исходный RAW-файл от достаточно старой камеры и преобразуем его в DNG старой версией конвертора Adobe (от ACR 2.3). Дляя проверки архивности преобразуем с одинаковыми настройками оба файла — и исходный RAW и производный от него DNG — в растровый RGB-формат, воспользовавшись текущей версией Adobe Camera Raw (ACR 4.5), и посмотрим на разницу в получившихся результатах. В качестве примера был использован файл от камеры Canon Powershot G6.

Сравнение результатов представлено на рисунке 1 (RAW, DNG, усиленная разница в красном канале). Визуальное различие между двумя вариантами конверсии невелико и скорее всего на журнальной печати видна не будет, но механическое вычитание показывает, что разница есть.

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

Универсальный?

Для проверки "универсальности", выполним обратную операцию: возьмем кадр, сделанный с помощью относительно новой камеры, преобразуем его в DNG современной версией DNG-конвертора и попробуем "подсунуть" старой версии конвертора Adobe Camera Raw, которая данную камеру не знает.

Этот эксперимент весьма актуален потому, что поддержка новых камер в Adobe Photoshop CS2 прекращена, однако, далеко не все готовы платить до Adobe Photoshop CS3, не предоставляющей никаких дополнительных преимуществ в применении к их задачам. Со дня на день можно ожидать подобной же участи CS3, который вот-вот будет вытеснен Photoshop CS4. Эксперимент был проведен с кадром от камеры Canon 1D Mark III.

Выяснилось, что версия Camera Raw 2.4 полученный DNG-файл просто не открывает, а версии 3.x — открывают, но результаты конверсии RAW и DNG в RGB отличаются еще больше, чем в предыдущем эксперименте (рисунок 2).

Недостатки и эволюция DNG

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

В вышедшей несколько месяцев назад спецификации DNG 1.2 появились дополнительные поля метаданных — цветовые данные, но предназначены они, в первую очередь, опять же для поддержки собственных продуктов Adobe и поэтому добавлены они ровно в том виде, в каком их используют коверторы Camera Raw и Lightroom. Эти данные не имеют никакого отношения к исходным форматам RAW и являются привнесёнными. Таким образом, DNG все больше становится внутренним форматом разработавшей его компании.

Формат DNG никак не помогает разработчикам поддерживать нестандартные сенсоры (полноцветный Foveon, Fuji SuperCCD SR с двумя разными изображениями в одном кадре и т.п.). Конечно, придумать способ хранения нестандартных данных внутри DNG несложно, но нестандартные данные требуют и нестандартных алгоритмов, а вот их-то стандарт DNG не предусматривает, о чем представители Adobe пишут открытым текстом.

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

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

Кроме того, принятие DNG в его сегодняшнем виде в качестве стандарта ведёт еще и к тому, что следом неявно навязывается и тот способ конвертации, который использует Adobe. Недаром разработчики Adobe употребляют словосочетание "DNG processing model" (Например см. архив рассылки colorsync-users@lists.apple.com, топик "Media Testing for maclife.de"). Однако способ конвертации тоже меняется на глазах. Вот такое вот лето...

OpenRAW

В 2005-м году возникла инициатива OpenRAW. Фактически она сводилась к призыву производителям камер опубликовать спецификации их RAW-форматов. Призыв сей был дружно проигнорирован, несмотря на то, что очень уважаемые люди вели вежливые и неспешные переговоры по всем правилам японского этикета с весьма влиятельными сотрудниками ведущих производителей цифровой фотоаппаратуры.

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

  • Запрограммировать обработку всех форматов данных — огромный труд. Dave Coffin занимается этим уже больше 10 лет, Phil Harvey — около пяти. Конечно, имея описания, не придется "хакать", что сократит объем работы, но и этот сократившийся объем все равно останется непомерно большим.
  • На самом деле, нужно не описание всех битов в формате данных, а только описание важных полей плюс инструкции, что со всем этим делать. Но инициаторы OpenRAW об инструкциях даже и не думали просить.

Про OpenRAW вовсе не имело бы смысла упоминать, если бы не PR-компания, развернутая ими 3 года назад. PR-компания оказалась успешной, многие теперь думают (к сожалению, совершенно ошибочно), что есть такой формат данных — OpenRAW.

Кто виноват и что делать?

Вышеописанные проблемы фотографической индустрии связаны, в числе прочего, с тем, что список требований к RAW-данным никогда всерьез не обсуждался. В результате, набор интерпретируемых конвертором метаданных в каждом конкретном случае отражает мнение разработчиков данного формата о правильном способе обработки этих данных. И далеко ходить за примерами не надо — один из авторов данной статьи сам грешен тем, что хотя и знает, как расшифровываются записанные в метаданных камер Nikon тональные кривые, но считает их плохими и посему со спокойной совестью оные в своем конверторе игнорирует. Формат DNG тоже укладывается в указанную тенденцию: данные, добавленные в версии 1.2 в первую очередь предназначены для использования программами Adobe.

Информационная индустрия многократно сталкивалась с подобными проблемами и решала их путем принятия стандартов на форматы данных. Эти стандарты обсуждаются перед принятием всеми заинтересованными сторонами, а при необходимости — дополняются и пересматриваются по, опять же, стандартной процедуре.

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

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

Отсутствие открытой информации о цветовых характеристиках фотокамеры приводит к тому, что для полноценной ее поддержки требуется либо провести серию утомительных, дорогостоящих и не всегда достаточно точных тестов, либо подбирать цвет на глаз. Это занимает время, поэтому для вновь появляющихся камер какое-то время доступен единственный RAW-конвертор, предлагаемый — иногда за дополнительные деньги — фирмой-производителем камеры. И он далеко не всегда устраивает пользователей, иногда потому, что не обеспечивает достаточного качества, а зачастую — просто потому, что не вписывается в workflow, принятый пользователем или целой большой корпорацией.

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

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

Оба же имеющихся на сегодня подхода — и описание всех особенностей десятков-сотен форматов данных (OpenRAW) (тем более без описания смысла полей форматов), и не соответствующий требованиям куцый единый формат (DNG) проблем индустрии — решить не могут и по сути являются путями в никуда.

Илья Борг, Алексей Тутубалин

Статья написана для журнала Компьютерра и опубликована в номере 758 от 11.11.2008

Comments

Тут есть два момента 1) Ну

Тут есть два момента
1) Ну да, несколько лет назад было модно писать tiff (8-битный, корректированный), потом одумались и этого режима не видно в новых камерах.
2) Ну а толку нет т.к. если камера делает баланс белого, еще какие-то тоновые коррекции и все это в целых числах - результат уже испорчен.

важное отличие JPEG от RAW

Хотелось бы отметить особо одно очень важное отличие RAW от JPEG (а также RGB и CMYK TIFF и многих других форматов).

RAW формат измерительного прибора. В RAW хранятся данные измерений некоторых аспектов наблюдаемых физических явлений.

JPEG формат прибора вывода. В JPEG (и во многих других форматах) хранятся управляющие сигналы устройства вывода (в случае JPEG разности потенциалов на контактах RGB ЭЛТ-трубки, кодированные при помощи люмы и двух цветоразностных компонент фактически, вся история телевидения в одном формате). При этом, очевидно, шкалирование и диапазон управляющих сигналов прибора может не совпадать (собственно, и не совпадает даже близко) с возможностями человеческого зрительного аппарата. В этом смысле JPEG как формат архивного хранения трижды нелеп:

  1. во-первых, храним не столько информацию о сцене, сколько историю цветного телевидения;
  2. во-вторых, храним описание не сцены, но её воспроизведения на уже устаревшем оборудовании;
  3. в-третьих, храним не описание аспектов физических явлений стимулов зрительного аппарата человека, шкалированное для достижения наперёд заданной точности, но величины, шкалированные согласно техническим характеристикам уже устаревшего оборудования.

Боюсь, ни lossless компрессия, ни механическое увеличение битности ситуацию в целом не исправят. Необходимо разработать форматы архивного хранения:

  1. данных измерений универсальный архивный RAW формат, о чём, собственно, говорится в статье;
  2. изображений формат хранения информации о физических аспектах физичесого феномена ЭМИ со спектральным распределением, сосредоточенным в диапазоне чувствительности человеческого глаза , необходимых и достаточных (и с точки зрения спектральных характеристик, и с точки зрения точности шкалирования) для описания механизма стимулирования человеческого зрительного аппарата.

Ещё раз отмечу, ни lossless JPEG, ни lossless JPEG2000, ни lossless 16bit RGB форматы (TIFF, PSD и иже с ними) не очень хорошо подходят для архивного хранения, так как в этих форматах сохраняются не те данные, которые, собственно, составляют описание сцены.

Я вот по второму вопросу. Мне

Я вот по второму вопросу.

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

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

Re: Я вот по второму вопросу

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

Абсолютно с Вами согласен. По всей видимости, недостаточно точно выразился, попробую ещё раз повторить главный посыл.

Хранить нужно необходимые и достаточные характеристики ЭМИ, описывающие воздействие излучения на человеческий зрительный аппарат. Шкалированные с достаточной точностью, где конечным мерилом точности является способность человеческого зрительного аппарата к цветоразличению и малым отклонениям стимулов.

Хранить спектральные распределения очень расточительно. Очень-очень.

А есть какой-то более

А есть какой-то более конкретный конструктив?

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

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

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

Ну и игры с окружением, про которые я тут уже писал в виде общих рассуждений.

Re: А есть какой-то более конкретный конструктив?

Есть. Именно HDRi формат (черновой вариант), отличающийся:
1) хранение цветовых координат и именно их храним измеримые физические величины, эквивалентные колбочковым ответам
2) хранение всех различимых человеком цветов (следствие п.1)
3) шкалирование производится согласно формуле цветового отличия, хорошо коррелирующей с экспериментальными данными Вышецки Филдера (по крайней мере лучше, чем CIE E любого из стандартов 1976-го, 1994-го или 2000-го годов), т.е., в согласии с современными представлениями о чувствительности человеческого зрительного аппарата к малым изменениям визуальных стимулов
4) дополнительные бонусы: нет зависимости от источника освещения (как, например, в формате LogLuv и других CIE L*a*b*/L*u*v*/Lch/Jch based), хороший коэффициент компрессии (следствие пп.1 3), возможность частичной загрузки для быстрого предпросмотра (это уж совсем в сторону от обсуждаемой темы, да)

По RAW форматам, полагаю, Вы гораздо дальше продвинулись, как раз Ваша тема. Мы HDRi кодированием и сжатием занимаемся.

У вас на сайте, к сожалению,

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

Вообще, хранение/шкалирование по формуле dE (пусть и очень хорошей) - этот путь не гарантированно является лучшим. Была бы равномерность "по Манселлу" - было бы просто очень интересно т.к. это прямой путь к правильному редактированию.

Спасибо, очень интересно,

Спасибо, очень интересно, почитаю.

Если хотите знать мое мнение :), то без описания формата _и_ опенсорсного SDK с нормальной лицензией, который его будет читать-писать - вам будет трудно добиться распространения.

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

Ну плагин для Фотошопа уже

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

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

Я взял UCT Studio - и

Я взял UCT Studio - и опечален. Пользоваться с реальным изображением (24Mpix) крайне затруднительно. Просто слишком медленно, хотя казалось бы у меня Core2Quad и памяти сколько хочешь (и видеокарта быстрая :)

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

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

Быстродействие было проблемой

Быстродействие было проблемой в той версии что лежит на вебсайте. Следующий major release эту проблему решает, кроме всего прочего путем распараллеливания вычислений на многоядерных cpu. С другой стороны 24 мегапикселя для просмотра изображения на экране вам не нужны, а программа ориентирована на создание изображений для просмотра на экране. Т.е. если вы уменьшите размер до 2-3 мп, то все будет работать вполне быстро.
Я могу вам прислать превью-версию следующего релиза, если хотите - но где-то через недельку (сейчас еще баги вычищаются). Сможете оценить насколько быстрее стало работать.

Ну, 24 мегапикселя - это то,

Ну, 24 мегапикселя - это то, что лежало под рукой в том формате, которую скушала программа (у меня оно как-то или Lab TIFF или RGB png), вот попалась такая картинка.

Мне нравится что делают движки редактирования (brightness/saturation), когда будет время - будем изучать что вы там наделали в смысле цветового пространства, но вряд-ли раньше января-февраля реально получится.

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

Я думаю что вы ошибаетесь

Я думаю что вы ошибаетесь считая HDR чем-то узким. Возможно на текущий момент это так (хотя тоже уже спорно), но что будет в будущем? На мой взгляд (да и не только мой) HDR это явный вектор развития индустрии. Посмотрите хотя бы на то что происходит в последнее время на стороне дисплеев (например совсем недавно Mitsubishi выпустила очень интересный телевизор LaserVue).
Через какое время у нас появится полноценная HDR-камера, чтоб за один снимок брала диапазон 106? Причем как делать такие сенсоры уже описано (технология называется logarithmic response sensor)? Есть подозрение что true HDR камеры мы увидим весьма и весьма скоро.
Просто то что мы имеем сейчас в виде JPEG/sRGB и остальных всевозможных попыток притянуть старую технологию за уши (например scRGB или xvYCC) - это жалкое убожество, на которое в возможно не таком далеком будущем все будут смотреть с улыбкой. Произойдет смены парадигмы цифрового изображения и того что с ним можно делать. То что сейчас называется HDR фотографией, будет просто фотографией, а то что сейчас называется фотографией, будет называться LDR, и все будут понимать что это очень убого. Также как сейчас если вам предложить 1-2 мегапиксельную камеру из прошлого, вы ее наверное даже даром не возьмете, ибо смешно. Аналогичная ситуация будет в будущем - если камера не имеет HDR возможностей, у нас будет такая же реакция :)

Я имел в виду другое: если у

Я имел в виду другое: если у вас уже есть заказчик, который работает с HDR и ему действительно важно сжатие или минимальные ошибки по цвету, то все мои советы можно выкинуть.
Я же смотрю со своей колокольни: очень хороший формат данных, который нельзя использовать для обмена (для фотошопа - плагин, а вот для ACDSee что?) и тем более для хранения (малоизвестная компания, открытого SDK нет, в длинном цикле надеяться на что-то странно) - ну и зачем все это. Вот если есть полный рабочий цикл, скажем от 3D-моделинга (или фото) до... какого-то конечного продукта, то конечно его можно делать и на закрытом формате.

Про HDR вообще - отдельный ответ, чтобы разделить две темы.

А вы ACDSee используете? ;)

А вы ACDSee используете? ;) Интересно почему - последний раз когда я на нее смотрел она не умела делать color management.

По поводу нашего бизнеса я ничего комментировать не могу, единственно что могу сказать - следите за новостями, будет интересно :)

Несколько слов по поводу формата и плагина. То что вы видите это первая, вообщем-то черновая версия. Причем отмечу что это visual lossless компрессия, работающая примерно в 2 раза лучше всего того что известно (Radiance HDR, OpenEXR, HD Photo) c полным цветовым охватом, любым ДД и контролируемой точностью. Продаем мы кстати только возможность сохранения файлов, т.е. если вы ставите себе плагин он всегда файлы будет читать, даже когда трайл кончится. Направлений куда формат будет развиваться и уже развивается несколько. Во первых это lossy компресия, и там как можно догадаться степень сжатия будет увеличена (в некий момент может получится что файлы будут размером с JPEG, но при этом содержать полноцветное HDR и оставаться в приемлемом качестве). Во вторых есть планы работы над плагинами к браузеру, чтобы HDR можно было показывать везде причем не статически а с возможностью динамического изменения условий просмотра. В третьих - ... много еще чего пока секретного.

ACDsee Pro имеет color

ACDsee Pro имеет color management. До разделения на Pro - пара последних major версий тоже имела.

Что касается компрессии - мне вот как простому пользователю с 600-Gb фотоархивом наверное было бы интересно его в 10 раз ужать, но при этом хотя бы конвертор в RGB-bitmap должен быть такой, чтобы я был уверен, что оно не пропадет (опенсорсный SDK, да). При этом скорость работы такого конвертора меня вообще не волнует (в разумных пределах), а вот собираемость компилятором C (не C++) - волнует очень сильно.

По поводу нашего бизнеса я

По поводу нашего бизнеса я ничего комментировать не могу, единственно что могу сказать - следите за новостями, будет интересно :)
Вообще, стандартная схема -- GPLv2 SDK + избавление от этого вируса за БОЛЬШИЕ деньги. Не говоря уже об адаптации под железо, что вроде как на сайте заявлено.

Вообще про HDR

С HDR в фотографией ситуация, на мой взгляд, следующая

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

2) Финальный результат нужно печатать (выводить на монитор) вполне определенным способом - Оптимальный Визуальный Контраст в районе 1:100 и в этот диапазон нужно запихать все значимые места сцены, кроме того средний тон относительно светов тоже фиксирован (на те самые магические 18%)

3) Проблема с цифрой (отчего стал популярен HDR) связана с тем, что не хватало динамического диапазона для того, чтобы сделать загиб характеристической кривой в светах, поэтому типичная дневная сцена на свежем воздухе могла стать проблемой. Ну и блюминг. В-принципе, 14-битные камеры проблему практически решили.
Конечно, логарифмический респонз будет лечить (если будет) проблему шума в тенях и это хорошо.

4) Конечно же, если производители камер явят чудо и дадут камеру в которой будет 10-11 стопов _и_ то же количество уровней в тенях, что и в среднем тоне, это будет огромным шагом вперед. И если вы хотите быть готовыми к этому моменту, то отлично. Но мне вот кажется, что сначала будут избавляться от байера.

что сначала будут избавляться

что сначала будут избавляться от байера.
Но как? Какие пути, кроме Фовеоновского, ой, простите, уже Сигмаовского, есть?

Кстати, была у меня одна идея -- однобитные ячейки (попал/не попал фотон-другой), но МНОГО... Очень много. Но, поговорив с теми, кто делает полупроводники в Физтехе питерском, понял что это крайне нетехнологично.

1) С пленкой (цветной) есть

1) С пленкой (цветной) есть фундаментальная проблема, помимо того что сам процесс нудный. А именно - точно цвет она никогда не передаст, ибо такова физика явления. Цвет может быть красивым, но никогда точным.

2) Я сейчас работаю на мониторе с контрастом 1:1000 (Dell'овская 24" панель). Сравнение с 1:100 не в пользу последнего. Оптимальный контраст для человека по разным оценкам от 1:10000 до 1:1000000. При возможности посмотрите как выглядят HDR картинки на настоящем HDR мониторе.

3) Про загибы это интересно, но комментировать не буду, каждый волен заблуждаться как он может и хочет ;) У меня 14-ти битовая камера совсем не решает проблему динамического диапазона даже в помещении и ночью на улице. Глаз все равно видит больше чем может снять камера даже если она стоит больше $2K.

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

Спорить на эту тему можно

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

1) Изготовители слайда вполне могут (могли) сделать его гораздо шире по динамическому диапазону, чем он есть. Однако не сделали. А из того что сделали: среди ассортимента Fuji есть очевидный повышенный спрос на Velvia, динамический диапазон которой и вовсе стопов пять. А контраст сцены уменьшают при съемке.

2) Ситуация с просмотром "в темной комнате" действительно иная - поэтому слайды, кино (и в некоторой степени мониторы) имеют больший контраст. И при этом, кстати, совершенно иную развесовку по теням-светам: на качество светов становится более наплевать, на качество теней - менее.

Вдогонку вопрос. UCT и KWE -

Вдогонку вопрос.

UCT и KWE - это одно и то же (с точки зрения стороннего наблюдателя) ?

Да, это те же люди (в

Да, это те же люди (в основном) и те же хозяева. UCT это реструктурированная KWE.

На мой (и не только) взгляд,

На мой (и не только) взгляд, наибольшую практическую проблему на сегодня представляет отсутствие хорошего и стандартного представления для редактирования, а не для хранения. Даже в Lab - меняешь насыщенность и ползет оттенок, про RGB вообще молчу.
Ну я и говорю -- пора софт писать. Ну, дизайнить сначала, конечно. Тут и RAW-конвертер будет нужен с таким выходным форматом, и редаткор для него.
Руки очень чешутся, но моих знаний явно недостаточно.

Ну, я не зря написал, что

Ну, я не зря написал, что моих знаний явно недостаточно.

Мне казалось, что у вас с Ильёй с теорией как раз всё в порядке.

В месте пространства для

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

А где про них какие-то

А где про них какие-то нормальные формальные описания? Обычно HSV/LCH - это специфика конкретного софта и в разных местах они разные.

Ну, вот давайте опишем как

Ну, вот давайте опишем как надо :) И сделаем специфичным для нашего софта :) Если всё будет зашибись -- начнут подтягиваться.

Если уж всё равно надо что-то с нуля делать...

Ну вот честное слово -

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

Ну, не зря я там смайликов

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

А то, что ``им бы все пользовались'' -- дык и Lab в каком там году появился? А когда про него Маргулис написал?

Lab имеет большее отношение к

Lab имеет большее отношение к цветометрии чем к цветокоррекции. В чб варианте - Вы же в стопах мыслите, не в плотностях d, так?

Для сканеров работали часто либо в выходном пространстве - CMYK (что создавало некое подобие визивига вкупе с аннотированными плашками CMYK, висящими на стенке перед оператором), либо в LCH, который очень близок к Lab, но удобнее, так как оттенок теоретически управляется здесь одним движком, а не двумя, как в Lab. Проблема возникает тогда, когда выставление главного цвета вызывает неприятные отклонения в оттенках - они "уезжают". Выставляешь средний тон золота - получаешь зелень в тенях и кирпичные оттенки в светах. Аналогично с кожей на портрете. Проблема имеет название - отсутствие перцептуальной равномерности пространства редактирования. Ещё один неприятный пример - неестественно синящие тени на снимках, сделанных при солнечном свете. Техника баланса белого сегодня не учитывает жту проблему. Отсюда и начинаются точечные коррекции цвета, U-points и прочие заплатки. На самом же деле решение вопроса лежит вовсе в иной плоскости. Точнее, в ином пространстве.

Lab имеет большее отношение к

Lab имеет большее отношение к цветометрии чем к цветокоррекции. В чб варианте - Вы же в стопах мыслите, не в плотностях d, так?
Я не про то, что Lab удачен. Я про то, что аргумент ``если бы было -- пользовались бы'' -- очень слабый, и, в общем, не о чём. Я легко представляю ситуацию, когда оно ЕСТЬ, но не пользуются, потому что в Фотошопе нт или в книжке не написали.

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

> аргумент ``если бы было --

> аргумент ``если бы было -- пользовались бы'' -- очень слабый
Я такого аргумента и не предлагал.

Lab'у альтернативы есть, и в ход они не пошли именно по причинамнеобходимости переписывать не только софт, не только книги, но и мозги - мозги как пользователей, так и разработчиков.

Насчёт того, что проблема - понятна, Вы, ИМХО, не вполне правы. Технически она и впрямь довольно понятна. Понимания нет у маркетинговых департаментов. В первую очередь - понимания размеров бюджета на damage control. Придётся ведь признавать, что раньше ошибались круто, и ошибались всюду. Поэтому процесс идёт медленно, с расчётом на плавное замещение и оправдание изменившейся технологией аппаратуры (например, раньше мы так не могли, так как не хватало вычислительной мощности, или спектрофотометры бвли страшно дороги, медленны и т.п.). Эти аргументы уже начали звучать в дискуссиях.

Я думаю, переход произошёл бы

Я думаю, переход произошёл бы не сразу, как и переход на использование ICC. 3-5 лет, при соответствующей поддержке адептов, займёт. Очень многое зависит от удобства решения, интуитивной понятности его применения. Последние 5 лет наблюдаю аналогичный процесс, но совсем в другой области - переход на синергетическое цифровое управление сварочной дугой. И там, до тех пор, пока не появились понятные технологу и сварщику процедуры настройки дуги и инструкции по процедурам, всё ограничивалось нишевыми и единичными применениями.

Я такого аргумента и не

Я такого аргумента и не предлагал.
Его предлагал Алексей, я ему и отвечал.

Технически она и впрямь довольно понятна. Понимания нет у маркетинговых департаментов.
Я предлагаю разработку OpenSource. Хотя бы proof of concept. Т.е. не связанную с маркетинговыми департаментами. Если получится -- окажемся на острие. Если нет -- развлечёмся. ``Не догоню, так хоть согреюсь''.

>> Я такого аргумента и не

>> Я такого аргумента и не предлагал.

> Его предлагал Алексей, я ему и отвечал.

Ага! Начало доходить :) Вопрос тогда в том, что такое "пользовались бы". Единицы - они и пользовались. Я, например, пользуюсь UpLab. И хотя выяснил недавно, что там не всё гладко (в том числе и в прямом смысле этого слова), пока не сделаю более правильное пространство, буду продолжать пользоваться.

> Я предлагаю разработку OpenSource.

Как мне представляется, тут до этапа программирования (то есть собственно до source) есть что поисследовать, чем и стоило бы на данном этапе заняться.

Как мне представляется, тут

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

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

Представление, куда двигаться

Представление, куда двигаться и что пробовать - имеется. Ограниченный круг экспериментов проведён. Задач, собственно, осталось две - грамотно построить адаптацию (вместо прямолинейного баланса белого) и ввести меру на пространстве, отвечающую условиям перцептуальной равномерности. На самом деле, первое в значительной мере вытекает из второго.

Ну или по крайней мере есть

Ну или по крайней мере есть представление, в какую сторону экспериментировать.

Ну и нечего приспосабливать

Ну и нечего приспосабливать для архивного хранения технологию не предназначенную для сего.
Само сравнение raw/jpg как непроявленная и проявленная пленка
содержит ответ - проявляйте и храните проявленное.
Ну если не JPG, так 16-битный JPG2k или PNG.

Эта проблема существует только для любителей,
Профессионал отснял, скажем, свадьбу, обработал, сделал альбом/диск,
продал результат и хранение raw'ов ему ни к чему.

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

Pages