Я предметку снимаю, как правило, в сугубо утилитарных целях (ну там продать что-то ненужное), но мимо олимпусовского focus stacking пройти не мог. Попробовал на ночь глядя - и вот прямо сейчас и хочется опубликовать.
А ты, Вовочка, молчи, а то мы всю физику к ..уям сведем... анекдот
О консенсусе
Несмотря на мой скепсис в отношении цветовой науки и любви потоптаться по святому,
прикладную задачу копирования изображений я считал решенной (как минимум, в простых случаях).
Ну вот есть файл (RGB), к нему прилагается профиль (ICC), следует ожидать что на одном и том же устройстве (LCD мониторе, чтобы быть конкретным) он
при включенном Color Engine отобразится более-менее разумно и одинаково.
Естественно, предполагается что все необходимые условия соблюдены: монитор отпрофилирован, показываемые цветовые данные привязаны к цвету (снабжены профилем), условия наблюдения постоянные, программа показа розумиет ICC, наливай да пей бери и выводи.
Конечно, жизнь несколько богаче и 2.5 года назад я уже исследовал проблему точности CMM (Color Management Module) и написал про это серию статей.
Но я наблюдал в эксперименте разумные ошибки - 5-6, а для хороших CMM и 8 бит данных сохранялись, отклонения от смены CMM в худшем случае были
заметны глазом, но не были фатальными.
Да, на картинке слева вы видите кусочек из этого файла, показанный на одном и том же мониторе, с одним и тем же профилем монитора, одним
и тем же профилем при цветовых данных файла, одной и той же программой (Adobe Photoshop) с одними и теми же настройками за исключением одной....
На LibRaw появился новый автор: Dan Margulis. Хочется надеяться, что сотрудничество будет не разовым, но гарантировать я это не могу. Пока же представляем вниманию читателей один текст на двух языках:
The question that needs an answer is, for what purpose is the module designed. I can think of four different approaches to acquisition.
I want the module to do nothing more than open the file without damage. I understand that it will probably be flat and colorless if I do this. I intend to fix the problems in Photoshop.
Although I will refine the image in Photoshop, I would like to be able to make quick, obvious moves in the acquisition module to make life easier later.
Вопрос, которым следует задаться в первую очередь, - это место RAW конвертора в цепочке обработки изображения. Иными словами, требуется определить те цели, которые должны быть решены на этапе конвертации RAW-данных. Я могу представить себе 4 различных подхода к определению задач этого модуля.
От модуля требуется лишь преобразование RAW-данных без потери качества. Мы отдаем себе отчет в том, что результат будет плоским (малоконтрастным) с ненасыщеными цветами. Для того чтобы вернуть изображение к жизни мы будем использовать Photoshop.
Проект LibRaw стал настоящим — у нас завелся живой форумный тролль. Как от многих таких троллей, от него есть и некоторая польза: если кормить его вдумчиво, то можно заодно разобраться с какими-то вещами, до которых не доходили руки. В данном конкретном случае
я разобрался с мониторным softproof (т.е. эмуляцией одного монитора на другом) и с пользой от этой техники для обработки изображений:
поиск невидимых (искаженных) цветов на собственных картинках;
оценка того, как изображение будет выглядеть на чужом мониторе (в том числе и в приложении, которое ничего не знает про профили и ICC).
Все эти вещи - интуитивно понятны, но их систематизация оказалась полезной и выродилась в отдельный текст:
Мониторный Softproof и Gamut Warning в Adobe Photoshop
...мониторный софтпруф может быть полезен тем, кто публикуется на фото-сайтах и подобным электронным образом, особенно для тех, кто обзавелся монитором с расширенным охватом и/или использует в качестве рабочего пространства - RGB пространство с охватом, много большим чем мониторный (например, Adobe RGB на обычном мониторе).
Помимо этого, вполне возможна ситуация, когда монитор не способен отобразить все цвета изображения - и это надо вовремя детектировать.
С новым фотошопом регулярно натыкаюсь на проблему: при печати больших форматов на печать вылазит только узкая полоска (1-3 сантиметра) с нижней стороны картинки. Обычно у меня там рамка и все.
Проблема меня реально мучала, экспериментируя выяснил что
Если включить Print Preview в драйвере принтера, то проблему видно и в нем. Т.е. это проблема печатающего приложения, а не драйвера.
А3 и меньше я печатаю редко, но не могу вспомнить чтобы столкнулся с проблемой. Вылезает только на А2, особенно часто вылезает на полюбившемся мне 17-дюймовом рулоне (типичный размер печатаемого: 420x660 мм).
Проблема редко была у Photoshop CS3, у 32-битного CS4 проявляется гораздо чаще. Если на preview увидели, надо закрыть фотошоп, открыть фотошоп и скорее всего пройдет.
Проблемы нет у 64-битного фотошопа. Вообще. Ни разу не видел.
Другими словами, что-то где-то с памятью намудрили. Или буфер выделяется не целиком, или что-то (иногда) переполняется, чего не случается. Кто там поближе к Сан-Хосе, зашлите им диарейных лучей.
Workflow с этими двумя версиями фотошопа получается какой-то ужасающий:
Основные действия производим в Lab, в 64-битном фотошопе (ибо быстрее).
Переводим в RGB, закрывает 64-битный, запускаем 32-битный, делаем финальный sharpen (Photokit Sharpener, у них есть 64-битная версия, но у меня не заработало).
Что-то я анонс пропустил, а сегодня случайно наткнулся на Pixel Bender от Adobe Labs.
Казалось бы, отличная идея: пишешь шейдеры kernels на скриптовом языке, они исполняются на видеокарте или на CPU.
Анонс тоже завлекал: дескать поддержвается любая разрядность цвета, все такое мультиплатформенное и хорошее. Есть плагин для Photoshop т.е. все изыски можно прямо в бою и использовать.
В-общем, я раскатал губу, скачал, поставил, закатал рукава и приготовился творить.