Когда-то давно я хвалил книжку Vincent(а) Versace 'Welcome to Oz'.
А вот сейчас мне интернет принес книжку того же автора про правильную разнообразную конверсию в BW.
Вот такую: From Oz to Kansas.
Стал я ее смотреть, а там примеры, а примеры - интернет не принес. И мне совершено не жалко книжку купить, но покупать бумажный (+CD) вариант не хочу, он хрен знает сколько будет ехать, да и доставка удвоит цену.
Практический вопрос: если купить Kindle Edition, то в каком виде там окажутся примеры, предусматривает ли Kindle-формат то, что кроме книги бывают всякие дополнительные материалы? Аппаратного киндла нету (испортилсо), буду использовать программный (на PC и на ойпаде).
Update: вопрос снят: при первом же появлении примеров в тексте, отсылают к секции Last Words, а там написано откуда скачать примеры. Буду, значит, пользоваться книжкой как Donationware - куплю только если понравится....
А ты, Вовочка, молчи, а то мы всю физику к ..уям сведем... анекдот
О консенсусе
Несмотря на мой скепсис в отношении цветовой науки и любви потоптаться по святому,
прикладную задачу копирования изображений я считал решенной (как минимум, в простых случаях).
Ну вот есть файл (RGB), к нему прилагается профиль (ICC), следует ожидать что на одном и том же устройстве (LCD мониторе, чтобы быть конкретным) он
при включенном Color Engine отобразится более-менее разумно и одинаково.
Естественно, предполагается что все необходимые условия соблюдены: монитор отпрофилирован, показываемые цветовые данные привязаны к цвету (снабжены профилем), условия наблюдения постоянные, программа показа розумиет ICC, наливай да пей бери и выводи.
Конечно, жизнь несколько богаче и 2.5 года назад я уже исследовал проблему точности CMM (Color Management Module) и написал про это серию статей.
Но я наблюдал в эксперименте разумные ошибки - 5-6, а для хороших CMM и 8 бит данных сохранялись, отклонения от смены CMM в худшем случае были
заметны глазом, но не были фатальными.
Да, на картинке слева вы видите кусочек из этого файла, показанный на одном и том же мониторе, с одним и тем же профилем монитора, одним
и тем же профилем при цветовых данных файла, одной и той же программой (Adobe Photoshop) с одними и теми же настройками за исключением одной....
Как и собирался, побывал в пятницу на мастер-классе Маргулиса. Имею сказать
Натурально, рулит. Действительно выступал примерно 6 часов в сумме, конечно на английском семинаре впихнул бы в слушателей больше (был последовательный перевод, процентов 20-30 времени терялось, хотя некоторые короткие реплики Дэна были на русском).
Если будут другие семинары в Москве - пойду обязательно.
Видеокурсы от Kelby (есть на торрентах.ру) стали сильно понятнее, как по логике (после того, как весь workflow был несколько раз разжеван, каждая отдельное упражнение понятно), так и по английскому (но я 6 часов просидел прямо под Дэном и английский его научился понимать).
Интегрально - определенно стоит потраченных денег и времени. О самом PPW четко сложившегося мнения не имею.
Цитата из лектора (о некоей коррекции):
это как литр водки: очевидно что много, но сама идея - неплохая
Ну и "фе" организаторам: на подобных семинарах в Штатах пользователи имели какие-то напечатанные материалы (workbook) и это не та PDF-ка, которая доступна по секретной ссылке (ибо PDF-ка на этот workbook ссылается). Т.е. в сочетании с пиратскими видеокурсами - нормально, а без них - доза получается явно недостаточной. В остальном организация - приемлемая.
Если кто не знает: 18 сентября 2009 года, в Москве, в "Метрополе", будет однодневный семинар Дэна Маргулиса, посвященный преимущественно Picture Postcard Workflow (PPW) - новому быстрому workflow от Дэна.
Я уже которую неделю маленькими кусочками смотрю видео от Kelby Training, продираясь через устный английский, ибо без этого обсуждение в ACT (которое по следам видео) на душу не ложится. Умучался неимоверно и решил, что пусть лучше мне за 120 баксов устроят синхронный перевод.
Если кто-то считает нужным перепостить это в тематические сообщества (по фотошопу, по обработке фото), то сделайте это пожалуйста.
P.S. Сожалею что не могу дать общедоступную ссылку в ACT, ибо рассылка Applied Color Theory даже для чтения требует одобрения модератора, которое, впрочем, легко дают.
В качестве алаверды к предыдущему посту имею сообщить, что хвалимый многими модуль дисплейной калибровки Argyll CMS мне не понравился:
Задача-максимум: добиться одинакового визуального воспроизведения нейтральных плашек на двух мониторах не достигнута. Формально dE меньше единицы, но реально глаз видит разницу (которую можно устранить кривой в зеленом, но удобных средств редактирования LUT монитора у меня под рукой не было).
Задача-минимум, собственно калибровка и профилирование, выполняются относительно неплохо, но калибровка идет средствами LUT видеокарты (т.е. 8-битной таблицы на DVI), точность работы средств, пищущих в LUT монитора - сильно выше (это видно при рассмотрении серого ступенчатого клина). Матричные профили имени Argyll мне при этом вполне нравятся, табличные - не нравятся.
Использовать сам Argyll (коммандлайновые утилиты) необычайно мучительно, GUI сильно упрощает процесс. dispcalGUI задачу управления вполне решает.
С учетом вышесказанного, остался жить с basICColor.
В процессе этих упражнений, пронаблюдал эффект с потерей точности уже в CMM-engine (в фотошопе), который легко воспроизводится (и как только я его объяснил в уме, он перестал быть неожиданным):
Калибровка и рабочий профиль у меня совпадают по точке белого (D50) и тоновой кривой (L*).
Берем ступенчатый серый клин (я использую мишень от Norman Koren) в пространстве sRGB (D65 и степенная гамма-кривая), выводим фотошопом на экран, получаем (видимую) разноцветность по патчам.
Эффект проявляется только для табличных (LUT) профилей и связан, естественно, с ошибками интерполяции содержащихся там таблиц (при построении условного device-link профиля пространство файла-пространство монитора). Для матричных профилей такой пересчет интерполяции не требует и, соответственно, ошибок не создает.
В частности, "в ответ" на Smarter Sharpen, который тут уже обсуждали, Дан Маргулис выкатил свою action, которая кажется черезвычайно удобной в применении: можно пускать батчем сразу, а потом доточить по месту, регулируя прозрачность слоев и их маски. Результат - хороший, но предназначенный для печати, для веба нужно, по всей видимости, подобрать параметры и сделать по образу и подобию.
К сожалению, нормальную прямую ссылку прямо на архив дать не получается, группа закрытая, поэтому могу только порекомендовать подписаться. Для этого нужна регистрация на Yahoo, а потом посылается запрос на подписку на группу (синяя кнопка Join Group). По моему опыту, запрос должен быть содержательным, а не просто "хочу читать"). Язык всего (и запроса на подписку и самой группы) - английский.
Если кто-то не поленится и адаптирует эту action к Lab (она RGB-only), я буду весьма благодарен....
Подписаться на Color Theory у меня получилось с третьего раза, которые отличаются тем, что я писал в сообщении модератору. Первые два раза было просто "хочу читать" (и меня завернули), а на третий написал подробнее.
Проект LibRaw стал настоящим — у нас завелся живой форумный тролль. Как от многих таких троллей, от него есть и некоторая польза: если кормить его вдумчиво, то можно заодно разобраться с какими-то вещами, до которых не доходили руки. В данном конкретном случае
я разобрался с мониторным softproof (т.е. эмуляцией одного монитора на другом) и с пользой от этой техники для обработки изображений:
поиск невидимых (искаженных) цветов на собственных картинках;
оценка того, как изображение будет выглядеть на чужом мониторе (в том числе и в приложении, которое ничего не знает про профили и ICC).
Все эти вещи - интуитивно понятны, но их систематизация оказалась полезной и выродилась в отдельный текст:
Мониторный Softproof и Gamut Warning в Adobe Photoshop
...мониторный софтпруф может быть полезен тем, кто публикуется на фото-сайтах и подобным электронным образом, особенно для тех, кто обзавелся монитором с расширенным охватом и/или использует в качестве рабочего пространства - RGB пространство с охватом, много большим чем мониторный (например, Adobe RGB на обычном мониторе).
Помимо этого, вполне возможна ситуация, когда монитор не способен отобразить все цвета изображения - и это надо вовремя детектировать.
Прочитал вчера статью Алексея Шадрина Воспитание по доктору Маргулису: работа над ошибками и, кажется, осознал в чем заключается противоречие между двумя подходами к обработке изображений. О чем и написал сам.
Кит против слона: о двух подходах к цифровым изображениям
Позволю себе пару цитат:
....Есть "два лагеря" (Илья Борг предлагает называть их "колориметристами" и "перцептуалистами"), которые на текущий момент договориться не могут и я не уверен, что в ближайшее время это вообще будет возможно. ....
....фотограф вынужденно попадает в самый центр вышеописанного конфликта и избежать его не может. А основная ошибка, которая регулярно делается многими уважаемыми людьми, - это отрицание ... одного из подходов.....
Что-то я анонс пропустил, а сегодня случайно наткнулся на Pixel Bender от Adobe Labs.
Казалось бы, отличная идея: пишешь шейдеры kernels на скриптовом языке, они исполняются на видеокарте или на CPU.
Анонс тоже завлекал: дескать поддержвается любая разрядность цвета, все такое мультиплатформенное и хорошее. Есть плагин для Photoshop т.е. все изыски можно прямо в бою и использовать.
В-общем, я раскатал губу, скачал, поставил, закатал рукава и приготовился творить.
Я редко пишу в блог о прочитанных книжках, но для этой хочется сделать исключение, из общего ряда она довольно сильно выбивается:
Дочитал лежавшую с лета книжку Vincent Versace Welcome to Oz и всячески ее рекомендую к прочтению, несмотря на довольно двойственные впечатления, о которых ниже. Необходимо заметить, что в отличие от многих других фотошопных книжек, где примеры элементарные (в том смысле, что иллюстрируют один элемент) и понятны просто при взгляде на печатную картинку, у Versace примеры сложные и их необходимо проделать самостоятельно. Так в финальном примере я насчитал 63 слоя, правда 23 из них - вспомогательные, а формируют изображение "всего" 40.
Книжка - про активное применение локального редактирования. Конечно, почти каждое действие - глобальное (кривые, фильтры, channel mixer), но затем делается выпиливанием маски к слою, которое делается вручную, хотя и весьма быстро. Предлагаемая техника очень похожа на схемы черно-белой печати, как у Адамса в книжках и много у кого еще. Плюс фильтр Lighting Effects, который для меня был вовсе внове.
Получаемый результат крайне интересен, не говоря о (специально подобранных?) примерах, где из дерьма делается конфетка.
Два дня всерьез пользую CS4, впечатления смешанные:
64-битный - сцуко, быстрый. Если быть точным, то сохранение (layered tiff, PSD, PNG) не кажется быстрее прошлых версий, а вот работа с большим количеством здоровых открытых файлов - не тормозит.
Естественно, ни один из старых 3rd-party плагинов под 64-бита не работает. В результате двустадийный Workflow (RPP - Lab - Photoshop - RGB) стал трехстадийным (RPP - Lab -PSx64(основная обработка) - Lab - PSx32(плагины)). На каждом шаге количество обрабатываемого падает в разы, поэтому жить можно.
32-битный по ощущениям медленее.
Но есть некоторое количество довольно мерзких багов.
Ctrl-0 делает картинку больше, чем экран. Точнее, в старом фотошопе все было бы отлично, а вот если использовать новомодное окно с табами, то поправку на высоту табов не делают.
В ряде случаев, сохранение файла Фотошопом сбивает рейтинг, поставленный бриджем. Пока кажется, что это бывает если файл не открывался через бридж, но буду изучать.
Перетаскивание окна Bridge между окнами не меняет экранный профиль "в который" рендерит бридж.
Настройка 'Remember Panel Location' ужасающа - Panel можно чуть-чуть сдвинуть с места, а дальше оно не дается. Уроды.
Ну а вообще, принципиальное отличие - это скорость работы. Действительно многое сильно быстрее. Остальное - косметические удобства (или я пока чего-то важного не нашел).
В предыдущих сериях мы рассматривали ошибки обработки цвета, возникающие при использовании матричных профилей, т.е. таких, где преобразование в PCS (profile connection space) и обратно задается простой матрицей 3x3. В реальной жизни матричные профили используются как рабочие пространства, а на стадиях импорта изображений и печати используются табличные профили, описывающие нелинейности реальных устройств.
Методология тестирования подробно описана в первой и второй статьях серии.
Upd: включены данные по Argyll для линейной гаммы. Конечно, "гонки по кругу" для...
В первой части CMM-эпопеи с дистанции была снята CMS Argyll: в области с высокими насыщенностями наблюдались видимые взглядом артефакты. В то же время, на 16-битных файлах Argyll показала великолепные результаты, сравнимые, а на части данных и сильно лучшие, чем у лучших коммерческих CMM.
Как и я и обещал, я заслал автору баг-репорт. К моему приятному изумлению, ответ был получен через час и содержал патч к cctiff (тестовому приложению, которое я использовал в тестах). В самой CMM-engine...
Из опыта известно, что цифровой шум в тенях чаще всего возникает при обработке данных с линейной «гаммой», а это те изображения, которые мы получаем с линейных сенсоров: цифровых камер и сканеров. Давайте посмотрим, что...
sRGB был выбран по той причине, что все цвета sRGB входят в Lab, следовательно, при абсолютной точности преобразований, вышеописанное преобразование не должно приводить к потере данных. В то же время, в реальной жизни для редактирования и хранения используются RGB-пространства с более широким gamut: Adobe RGB, ProPhoto, BetaRGB, EktaSpace и так далее.
Пространство BetaRGB обладает массой достоинств в качестве пространства хранения и редактирования: большим охватом реальных цветов, большой эффективностью кодирования данных. Интересно посмотреть, как ведут себя CMM-модули с этим пространством.
В предыдущей публикации были рассмотрены ошибки, которые происходят в Color Management Modules (CMM) разных систем при обработке 8-битных данных. Было показано, что такое "неразрушающее" действие как конверсия из RGB в Lab и обратно оставляет от 3-5 значащих бит от восьми.
На сегодняшний день, 8 бит неактуальны, большинство изображений производятся с большей разрядностью. Следовательно, нужно изучить и их.
Начнем с гаммы 2.2, как наиболее часто используемой при редактировании изображений.
Смена координат
Первые же эксперименты показали, что ошибки при...
Все, кто работает с цветом, догадываются, что любая операция редактирования немножко разрушает изображение за счет округления дробных результатов вычислений до целых значений. Вот например, наложили вы кривую, таким образом, что значение 1 должно стать 1.8, а 2 — 2.2. После округления, оба результата будут округлены до 2, отчего вместо двух разных цветов получатся два одинаковых.
Неявно предполагается, что отклонения от идеала при цифровом редактировании невелики и влияют только на младшие биты значений, что практически незаметно на глаз. В то же время, мне никогда не попадались количественные исследования. Да, на практике я знаю, что инструмент Levels в фотошопе полностью разрушает тени, а остальные инструменты ведут себя приличнее, но это единственное знание, накопленное за 8 лет работы с цветом.
Неточность работы всех средств редактирования затрудняет корректную постановку задачи: нет идеала с которым можно было бы сравнивать. По счастью, задачу можно корректно поставить для преобразования, которое должно быть минимально разрушающим: преобразование цветовых пространств в ситуации, когда мы не выходим за gamut.
Простые упражнения с фотошопом (прогнать картинку по циклу RGB->LAB->RGB, а потом посмотреть разницу через Image—>Calculations) показали, что разница по красному каналу достигает 24 единиц т.е. речь идет о 5 битах ошибки в 8-битном изображении.
Дальнейшие упражнения потребовали создания инструментальных средств и аккуратной постановки эксперимента.