• Главная
• Избранное
• Популярное
• Новые добавления
• Случайная статья

Список Linux управляемые цветом заявления

• КАНИТЕЛЬ, Программа Манипуляции ГНУ Изображения (CMS доступен в 2,3 версиях развития и более поздних версиях)

,

• Firefox (так как версия 3, включенная по умолчанию с тех пор v3.5), веб-браузер
• Опера, веб-браузер
• CinePaint, 16-битный способный редактор изображений
• Darktable, применение технологического процесса фотографии, НЕОПЫТНЫЙ разработчик, виртуальный lighttable и темная комната для фотографов
• Krita и Karbon14, редактор изображений и векторный редактор графики, соответственно (части Calligra Suite)
• Scribus, программное обеспечение расположения страницы (использующий Мало CMS)
• digiKam, цифровая программа управления фотографиями для KDE (использующий Мало CMS)
• F-пятно, цифровая программа управления фотографиями для ГНОМА
• Про Bibble, (теперь Corel AfterShot Pro) СЫРОЙ конвертер цифрового изображения
• Пиксельная Про Студия, редактор изображений (поддерживает 8bit/16bit RGB, CMYK, Лабораторию, 32-битный HDR и СЫРЫЕ файлы)

,

• LightZone, редактор изображений и процессор RAW
• UFRaw, СЫРОЙ конвертер и плагин КАНИТЕЛИ
• RawTherapee, СЫРОЙ конвертер (поддерживает 8-bit/16-bit RGB)

,

• PhotoPrint, полезность, разработанная, чтобы помочь в процессе печати цифровых фотографий (печатает с GutenPrint)

,

• Geeqie, зритель изображения и фото организатор
• XSane, просматривая frontend для Доступа Сканера, Теперь Легкого (поддержка CMS с тех пор XSane-0.992/0.993)
• LPROF, ICCv2-послушный Профилировщик Цвета Аппаратных средств для камер, сканеров и мониторов
• xcalib - xcalib - крошечный погрузчик калибровки монитора для XFree86 (или X.Org) и MS Windows
• Инкскэйп, векторный редактор графики, который использует SVG в качестве его родного формата файла (CMS доступен с версии 0.46)

,

• Фотография Phatch КОМПЛЕКТУЕТ процессор и exif renamer, который поддерживает RGB (A), CMYK, YCbCr, я (32-битные пиксели целого числа) и F (32-битные пиксели с плавающей запятой). У этого есть много особенностей: вычисление, подрезание, вращение, тени, закругленные углы, отражение, перспектива...
• PixInsight, программная платформа обработки изображения специализировалась на астрофотографии и других технических областях отображения.

См. также

• Международный цветной консорциум

Внешние ссылки

• Точка зрения разработчика Аргайла о том, как использовать их программное обеспечение. Немного слишком технический

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

• Профили ICC в X спецификациях

• Обзор использования монитора - и принтер представляет в Scribus

• Дом ICC Examin и Oyranos. Также поддерживает подачу последних новостей в управлении цветом Linux

• Самый всесторонний список общих связей управления цветом; «не связанный с Linux» внедрение
• Мало CMS, маленький след, оптимизированный скоростью, двигатель управления цветом бесплатного программного обеспечения

• Управление цветом в мягкой фетровой шляпе

• Менеджер по цвету ГНОМА

Ричард, ты работаешь на полную ставку в 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.

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