Довольно продолжительное время управление цветом в Linux было занятием для людей с, назовём это так, большим количеством свободного времени. Но два года назад проект GNOME Color Manager, ведомый Ричардом Хьюсом (Richard Hughes), сделал весьма ощутимый прорыв в этом направлении с целью исправить сложившееся положение вещей раз и навсегда. До выпуска GNOME 3.2 осталась всего неделя, так что мы решили задать Ричарду несколько каверзных вопросов.

Собственно апплет управления цветом в GNOME

Ричард, ты работаешь на полную ставку в Red Hat. Насколько поддержка крупным вендором Linux помогает работать над тем, что тебе нравится?

Это не решающий фактор, но действительно помогает. Red Hat — одна из тех клёвых опенсорсных компаний, где вам дают заниматься чем угодно, лишь бы это хоть как-то было связано с работой. Моя работа заключается в том, что я нахожу дыры в десктопной функциональности и затыкаю их. Если для этого надо пропатчить существующее приложение, я его патчу; если надо написать целый фреймворк, я его пишу.

Профессиональным дизайнерам, фотографам и специалистам по предпечатной подготовке не нужно объяснять, зачем им управление цветом. Предполагается, что они прекрасно разбираются в теме. Но как GNOME Color Manager может помочь людям, которые не уверены, зачем тратить сотню баксов на Pantone Huey — самое дешёвое решение на рынке к настоящему моменту?

Как помогает? Я бы сказал, двумя способами.

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

Новая справочная система

Во-вторых, когда вы запускаете апплет «Управление цветом» в панели управления GNOME, в открывшемся диалоге есть кнопка «Узнать больше», по нажатию которой открывается подробная справка. В ней можно найти ответы на такие вопросы как «Для чего нужно управление цветом», «Какие измерительные устройства поддерживаются», «Что такое цветовой профиль» и т.д. Новички получают достаточную вводную информацию, а более опытные пользователи читают конкретику.

GNOME Color Manager является частью GNOME начиная с версии 2.30, так что достаточно много людей как минимум знает о существовании этого апплета и в курсе, что могут с его помощью добиться согласованной цветопередачи для мониторов, принтеров, сканеров и фотокамер. Но с colord, который появляется в новой версии GNOME, практически никто не знаком. Для его он понадобился?

GNOME Color Manager (g-c-m для краткости) действительно впервые появился в GNOME 2.30 и достаточно активно развивался по мере выпуска версий 2.32 и 3.0. За это время из нескольких отдельных приложений он превратился во фреймворк, сделанный, в общем-то, на скорую руку. Это было неприемлемо по целому ряду причин. Вот некоторые из них:

• Проектам вроде CUPS необходимо регистрировать устройства в апплете управления цветом, что оказалось непростой задачей. Проблема в том, что апплет работает в прослойке сеанса и запускается один раз для одного пользователя, а демон CUPS работает в системной прослойке и запускается вместе с системой.
• Нам необходимы профили, доступные для всей системы, чтобы можно было, скажем, использовать один профиль монитора для всех пользователей или даже просто в графическом экране авторизации пользователя.
• Кроме GNOME есть другие рабочие среды, которым неинтересно реализовывать всё то же самое с нуля.

Так что самым очевидным решением было выделить код фреймворка из GNOME Color Manager в простой системный компонент, который мог бы использоваться другими системными приложениями. После чего g-c-m превращается обратно в простое приложение из прослойки сеанса для конфигурирования и применения политик из colord. Таким образом можно легко создать аналогичный модуль управления цветом для KDE или LXDE, который работал бы с colord.

Основные метаданные цветового профиля

Если это для вас звучит подозрительно знакомо, PackageKit и UPower работают примерно так же. Собственно, это тоже мои проекты.

GNOME Color Manager в GNOME 3.2 — первая версия, которая использует не просто colord, но всю переработанную подсистему печати в Linux. Что именно это значит для конечных пользователей?

Поскольку colord является жёсткой зависимостью для GNOME 3.2, это значит, что впервые цветоуправляемая печать просто работает, сразу и «из коробки». Больше не нужно ничего дополнительно устанавливать и конфигурировать. Мониторы автоматически регистрируются в colord через gnome-settings-daemon, а принтеры — через CUPS.

Иными словами, пользователю впервые достаточно сказать «Я хочу вот этот профиль для вот этого устройства», и всё просто заработает. Так что нужно лишь создать профиль для принтера или скачать готовый, связав его с устройством в апплете, чтобы получить предсказуемую цветопередачу при печати через самый обычный диалог, открываемый через «Файл / Печать».

При работе над colord тебе пришлось пропатчить немало системных компонентов: CUPS, Ghostscript, foomatic, GTK+. Полагаю, в результате у тебя есть достаточно чёткое представление о том, как сейчас выглядит весь стек системных компонентов для печати и работы с цифровыми изображениями в Linux. Насколько он соответствует современным требованиям? Какие у него недостатки?

Как CUPS, так и Ghostscript являются сложившимися, надёжными проектами со стабильными API. Добавление более новых технологий, таких как GLib и системная шина сообщений D-Bus, заметно упростили мою работу над colord. Подсистема печати в Linux выглядит страшновато, но когда все наконец перейдут с Postscript на PDF, всё станет намного проще и организованнее. С другой стороны, эта подсистема достаточно стабильна и задокументирована.

Заметно больше проблем возникает с проектом SANE. Это весьма старая библиотека, позволяющая получать список доступных сканеров и собственно выполнять сканирование изображений. Библиотека работает с так называемыми бэкендами, по сути — наборами драйверов для каждого производителя сканеров.

Разброс по качеству у бэкендов просто невероятный. Есть достаточно стабильные, как у HP, а есть такие, что падают в произвольных местах. Кроме того, можно устанавливать проприетарные (закрытые) бэкенды, качество которых ещё более сомнительно. Ну а поскольку библиотека libsane запускается из процесса colord, демон падает вместе с ней.

Я бы сказал, 90% жалоб на ошибки в colord из поставки Fedora на самом деле вызваны ошибками в бэкендах SANE. Именно поэтому в конфиге colord.conf есть строчка EnableSane=false. В долгосрочных планах у меня стоит перенос обнаружения устройств на udev, что уже сделано в других подсистемах, но без помощи разработчиков SANE мне с этим не справиться.

Цветоуправляемая печать в приложениях на GTK+ теперь просто работает. Всегда.

При проектировании colord я осознанно сделал так, чтобы он не принимал и не отдавал никакие растровые данные. Так что colord просто является высокоуровневым демоном, который может сказать приложению вроде Krita или GIMP «Используй вот этот профиль для вот этого устройства» вместо того, чтобы заставлять их резервировать 140-мегабайтный буфер памяти и список операций. Так что мы можем использовать CPU и LittleCMS для преобразований в одних приложениях, и GPU с шейдерами — в других. Все преобразования растровых данных происходят в нужном системным слое ровно так, как надо.

Разумеется, обратной стороной этого является необходимость патчить пользовательские приложения. Мы можем упростить этот процесс, написав код привязки к фреймворку для Clutter и Cairo, но рано или поздно приложению всё равно нужно научиться управлению цветом. На этом я и хочу сконцентрироваться при работе над GNOME 3.4. Теперь, когда фреймворк доступен всем по умолчанию, мы можем сказать разработчикам пользовательских приложений: «Всё уже установлено, не нужны никакие дополнительные зависимости. Просто примените мой патч, и всё заработает».

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

Полагаю, у большинства пользователей всё же скорее один профиль для принтера, но я согласен с тем, что имеет смысл поддерживать выбор между профилями для одного устройства. Собственно, это актуально и для пользователей фотокамер, поскольку им может понадобиться переключаться между профилями вроде «Студийное освещение» и «Съёмка на улице в ясную погоду».

Colord делает то же самое, что и ColorSync на OSX, так что когда приложение (в нашем случае это CUPS) запрашивает цветовой профиль для устройства, оно формирует запрос на основе квалификатора. Т.е. если вы хотите напечатать что-то на обычной бумаге цветными чернилами с разрешением 600dpi, CUPS попросит colord дать ему профиль “RGB.Plain.600dpi”. Этот профиль будет подобран по запрошенным критериям на основе метаданных, которые g-c-m встраивает в создаваемые им цветовые профили. Соответственно, если вам нужно напечатать на глянцевой бумаге, у которой больший цветовой охват, вы выбираете в диалоге печати «Глянцевая бумага», и тогда CUPS попросит профиль “RGB.Glossy.600dpi”. Само собой, если подходящего профиля в системе нет, colord сможет предоставить только обычный профиль.

Единственное, чего сейчас не хватает — это способа встраивать в профили, не созданные g-c-m, метаданные, характеризующие профиль как, скажем, «для печати цветными чернилами на глянцевой бумаге с разрешением 1200dpi». Если вы примерно представляете себе графический интерфейс для такой задачи, зайдите на канал #gnome-design и обсудите этого с дизайнерами интерфейса, а я напишу код для GNOME 3.4.

Как много приложений использует сейчас интерфейс D-Bus в colord, и насколько стабилен сейчас фреймворк в этом отношении?

Полной информации у меня нет, поскольку я никого не принуждаю докладывать мне об этом. Точно знаю про CUPS, GTK+, foomatic, simple-scan, compiz-cms и, конечно, GNOME Color Manager. Алекс Фиестас (Alex Fiestas) планировал сделать интерфейс для KDE.

Публичный API к D-Bus в colord очень стабилен. Мы разломали его всего лишь раз, это было в прошлом году и затронуло только агенты политики сеанса (т.е. даже не пользовательские приложения). Мы постараемся сохранить API стабильным и поддерживаемым, но будем добавлять новые свойства и методы по мере необходимости. Я не обещаю, что мы никогда не сломаем API, если понадобится, предположим, исправить критическую ошибку, но поводов ломать API прямо сейчас я не вижу. Всё-таки, colord — очень простой демон с ограниченной сферой применения.

До недавних пор g-c-m использовал только систему управления цветом Argyll, написанную Грэмом Джиллом (Graeme Gill), для работы с колориметрами и спектрометрами вроде ColorMunki, Colorvision Spyder и прочих. Потом ты, кажется, начал работать над собственными драйверами. Затем Argyll был пропатчен, чтобы удовлетворять твоим требованиям. В чём была проблема с Argyll, как всё выглядит сейчас и каковы планы на будущее?

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

Такой подход несовместим с подходом GCM и colord, который можно описать как «всё просто работает». В GNOME 3.0 и 3.2 это означает, что Argyll запускается из виджета VTE (компонент терминала), после чего g-c-m пытается считать и распознать его вывод. Работает это не слишком хорошо, так что я попросил Грэма сделать взаимодействие через терминал опциональным, что он и реализовал в последней версии системы. К сожалению, я пока не могу сделать эту новую версию доступной в Fedora из-за модифицированной встроенной версии libusb1, так что пока придётся немного помучиться с чтением вывода Argyll.

Пояснение в мастере, как разместить Pantone Huey на мониторе

В обозримом будущем Argyll никуда не денется и по-прежнему будет использоваться для создания профилей, потому что Грэм знает своё дело как никто другой. А вот блокировку измерительных устройств и собственно замеры я переношу в colord. Сейчас есть пока лишь драйвер для Huey и примерно половина драйвера для ColorMunki.

Это позволяет нам делать такие простые вещи как вывод на экран цветового поля для замера, отмену калибровки и вывод индикатора прогресса. Иными словами, процесс, занимающий основную часть времени, мы можем перенести в colord, после чего «скормить» полученные результаты Argyll и получить на выходе готовый профиль. Так что мы продолжаем пользоваться проверенными алгоритмами, реализованными Грэмом, а всю асинхронную работу с аппаратным обеспечением переносим в colord.

Само собой, работая над поддержкой измерительных устройств в colord, я обнаружил, что в GLib не хватает простого способа асинхронной отмены действий при работе с USB. Так появился проект GUsb, первую версию которого я скоро официально выпущу. GUsb уже используется в других программах, например, в SPICE.

Недавно в списке рассылки для разработчиков GNOME было обсуждение на тему полноэкранного управления цветом (FSCM для краткости). Какое дело конечным пользователям до FSCM?

Полноэкранное управление цветом — следующий логический шаг для свободных рабочих сред, который в OSX уже сделан. На самом деле, что-то вроде того уже реализовано — когда мы передаём серверу X данные из тэга VCGT в цветовом профиле при запуске сеанса. Windows и OSX умеют загружать линеаризованное состояние устройства довольно давно, и это позволяет обеспечить более точный вывод. Так можно, к примеру, скорректировать типичный отлив ЖК-мониторов в синеву. Полезная штука, да.

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

Настоящая ценность полноэкранного управления цветом заключается в возможности делать автоматическую проекцию из одного профиля в другой, т.е. по сути из известного цветового пространства в пространство монитора. Обычно предполагается, что все текстовые документы, кнопки в интерфейсе, оформления окон и прочее находятся в пространстве sRGB, поскольку они никак не размечены. Но в приложении вроде Firefox может быть открыт, скажем, Flickr c фотографиями, в которых есть встроенные цветовые профили.

Диаграмма цветового охвата CIE 1931

Сейчас в большинстве случаев неразмеченный контент отправляется на X-сервер безо всякого управления цветом. Можете себе представить головную боль пользователей мониторов с широким цветовым охватом. В то же время программы вроде GIMP (и Firefox, если его настроить) прогоняют изображения через цветовой профиль при помощи библиотеки вроде LittleCMS, которая работает на CPU. Это, конечно, здорово, но означает, что надо просчитать на процессоре каждый пиксел многомегабайтного изображения.

Что можно сделать с необходимостью выполнять массивные параллельные операции над большим количеством изображений, отправляемых на монитор? Ну, так уж вышло, что на современных компьютерах практически всегда есть GPU, который чудесно умеет справляться с такими задачами. Дайте GPU двухмерную текстуру 50Mb RGBA и скажите ему трилинейно интерполировать каждый пиксел по матрице 16x16x16, и он это сделает быстрее чем изображение загрузится в системное ОЗУ.

Ничего принципиально нового в этом нет. Кай-Уве (разработчик Oyranos — прим.ред.) уже пару лет показывает всем своё дополнение к Compiz, которое это делает, а недавно к нему присоединился Габриэль Эбнер (Gabriel Ebner) со своим проектом compiz-cms. Кстати, в последнем для получения правильных профилей используется colord, так что для пользователей Compiz уже есть «изкоробочное» решение — при условии, конечно, что вы можете сказать всем приложениям отдавать наружу только sRGB.

График кривых VCGT

В GNOME 3 мы используем композитный менеджер окон mutter. С ним всё не так просто как с Compiz, где можно к конечному окну применить готовый шейдер. Чтобы рендеринг с прозрачностью был выполнен правильно, нам приходится использовать Clutter и cogl. К этому плюсуется необходимость учитывать области, где управление цветом должно быть отключено, поскольку некоторые программы вроде Blender предпочитают полностью контролировать вид содержимого своих окон, а иные, вроде, Firefox, уже посчитали преобразование на CPU, и двойной пересчёт им совсем ни к чему. Я пока что работаю с авторами mutter и X над стратегией для GNOME 3.4, и похоже, что придётся подправить как минимум mutter, Gtk+ и cogl.

Я даже рассмотрел возможность применить часть существующей спецификации net-color, написанной Каем-Уве, но пришёл к выводу, что приличная её часть попросту ошибочна, а добавление функций вроде сетевой прозрачности приведёт к появлению множества проблем, с которыми мы вряд ли справимся. Кроме того, мне хотелось бы упростить реализацию автоматического принятия управления цветом и отказа от него (opt-in, opt-out) для виджетов и окон, а спецификация net-color подразумевает указание таких областей вручную, что по современным меркам не слишком приемлемо. В остальном же, с удовольствием выслушаю ваши идеи. Главное лишь помнить, что нужно поменьше программных зависимостей, расхода электроэнергии и задержек в отрисовке интерфейса.

Понимаю, что читающим это хотелось бы ответа покороче, но в двух словах это действительно не объяснить. Поле выхода GNOME 3.4 архитектура полноэкранного управления цветом будет достойна отдельной публикации.

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

Wayland — замечательный проект, которым занимаются не менее замечательные люди. На самом деле, это просто протокол для коммуникации композитного менеджера с клиентами, и в его успешном будущем я уверен. Для полноэкранного управления цветом нам нужен клиент для общения с таким менеджером окон, и существующие протоколы вроде атомов _ICC_PROFILE_IN_X, которые загружаются на сервер, станут просто нерелевантными.

Сейчас Wayland не является проектом, который «заменит X-сервер», чтобы там себе ни писали разные безумцы на своих новостных сайтах. При проектировании новой архитектуры FSCM нам нужно просто иметь в виду, что у нас не всегда будет X-сервер, в котором можно хранить произвольные куски данных.

Словом, я не думаю, что Wayland как-то упростит нашу работу, хотя скорости он нам прибавит.

Похоже, что в сообществе разработчиков возникло некоторое устойчивое противоречие между желающими сделать так, чтобы всё просто работало для 95% пользователей, и желающими осчастливить остальные 5% с их потребностью в гибких настраиваемых политиках управления цветом. Есть ли у colord и Oyranos шанс стать совместимыми?

Я бы хотел сказать, что есть, но, к сожалению, не вижу способа сделать так, чтобы всё просто работало, и при этом у пользователя была возможность «подкрутить» каждый нюанс политики. Я всегда придерживался мнения, что мы должны дать возможность 95% пользователей делать 99% того, что им нужно, потому что у оставшихся 5% всё равно свои собственные настроенные технологические процессы, которые их устраивают. Абсолютное большинство пользователей хочет, чтобы управление цветом просто работало и не приставало к ним со всякой тарабарщиной. Те же, кто на этой тарабарщине говорит как на родном языке, прекрасно справятся с конфигами и чтением манов.

Цветовое тело пространства профиля в LAB. Код взят из ICC Examin, использующего Oyranos.

Я не вижу у colord и Oyranos особых возможностей взаимодействовать — по чисто техническим, а не каким-то идеологических соображениям. С функциональной точки зрения они едва пересекаются. У colord очень ограниченная сфера действия, он установлен по умолчанию и пытается сделать так, чтобы всё просто работало. В свою очередь Oyranos является достаточно амбициозным проектом, пытающимся встроиться в каждый аспект технологического процесса. В этом смысле Oyranos совершенно ортогонален colord, и это основная причина, по которой я начал новый проект вместо того, чтобы сидеть и патчить Oyranos.

Работа над GNOME Color Manager для тебя началась как небольшой побочный проект, за который ты взялся из желания привести к одному знаменателю выводы на дисплей ноутбука и внешний монитор. Прошло два года, к G-C-M прибавилось два инфраструктурных проекта, colord и GUsb, ты пропатчил приличную часть подсистемы печати… Ну и как, ты всё ещё получаешь удовольствие от работы над проектом?

Ещё бы! Как оказалось (и любой эксперт тебе это подтвердит), чем больше ты узнаёшь об управлении цветом, тем больше понимаешь, как мало знаешь. То направление, в котором colord сейчас развивается, т.е. низкоуровневая работа с аппаратным обеспечением, мне как любителю поковыряться с электроникой чрезвычайно интересно. Кроме того, мне здорово помогают дизайнеры GNOME, благодаря которым мастер калибровки и профилирования в GNOME 3.2 выглядит действительно здорово. Все вместе мы создаём продукт, который удобен конечным пользователям и тем самым делает наши усилия не напрасными.

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