Как много приложений использует сейчас интерфейс 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 архитектура полноэкранного управления цветом будет достойна отдельной публикации.



Поделиться:




Поиск по сайту

©2015-2024 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2017-04-01 Нарушение авторских прав и Нарушение персональных данных


Поиск по сайту: