Ты не мог бы представиться?
Меня зовут Хэл Энгель (Hal Engel). Я руковожу проектом LProf — это программа для создания ICC-профилей устройств. В настоящее время LProf — единственный свободный ICC-профилировщик с графическим пользовательским интерфейсом.
Каков твой предшествующий опыт применительно к управлению цветом? Фотография? Предпечатная подготовка? Что-то ещё?
Как и мой отец, я уже долгое время являюсь фотографом-любителем. У отца была ч/б тёмная комната в подвале, когда я был ещё ребёнком. Позже у меня появилась собственная «цветная» тёмная комната, где я сам проявлял пленку (негативную, позитивную и ч/б). Некоторое время назад я решил перейти на цифру и быстро разочаровался в ней из-за сложности в получении приемлемых результатов. Изучив возможные пути решения возникших проблем, я понял, что правильным ответом было управление цветом. Вот так всё и началось.
Ранее LProf был детищем Марти Марии — бессменного автора LittleCMS. По слухам, он прекратил разработку программы по требованию HP, куда перешёл на работу.
Да, я могу подтвердить, что поддержка LProf была прекращена как условие его перехода на работу в HP, о чём он писал в списке рассылки lcms-users. Кроме того, Марти начал работать над профилировщиком с закрытым исходным кодом, основанным на коде LProf, ещё до перехода в HP и, полагаю, компания HP приобрела права на исходный код закрытого профилировщика. Так что это известный факт, а не слухи. Собственно, вот письмо Марти, где он объясняет происшедшее.
«Во вторник 2004-10-19 в 10:19 marti at littlecms.com написал:
Привет, > > Известны ли причины? Просто интересно…
Как уже ранее писал Герхард, мне не разрешено поддерживать или развивать LProf. Причина заключается в том, что я работаю на компанию (HP), которая приобрела исходный код для частного использования.
Кроме того, технология, которую я использовал в последних версиях профилировщика (не LProf, а того, который я собирался продавать) «чувствительна» в отношении подписанного мной NDA. Поэтому я пожертвовал LProf, чтобы сохранить lcms (модуль управления цветом).
Компания HP любезно позволила мне продолжить разработку lcms с открытым исходным кодом. Более того, они ПОДДЕРЖИВАЮТ эту разработку. Таким образом, я имею возможность общаться с членами ICC (Международный цветовой консорциум), получать доступ к закрытым документам, предлагаемым расширениям и прочему.
Словом, мне очень жаль, но lprof теперь по большому счету мёртв. Во всяком случае, как открытый проект. Вместе с тем, было бы здорово, если кто-то продолжил бы разработку с имеющегося исходного кода. Но, как я уже ранее сказал, я больше не вправе этим заниматься.
С приветом, Марти.»
Обрати внимание, что когда он пишет «Причина заключается в том, что я работаю на компанию (HP), которая приобрела исходный код для частного использования», он подразумевает профилировщик с закрытым исходным кодом, а не LProf. Заодно обрати внимание на то, что в конечном счёте Марти пожертвовал только закрытым профилировщиком и оказался совершенно неправ, назвав LProf «по большому счёту мёртвым», поскольку LProf живее всех живых.
А что в конечном счёте заставило тебя подобрать проект?
Я начал изучать и использовать управление цветом в Windows в конце 90-х, когда попробовал перейти на цифру. Поскольку я IT-специалист, мне в общем-то никогда не нравилось использовать Windows и вместо неё хотелось более стабильную и открытую платформу. Около четырёх лет назад я впервые установил Linux — SuSE 9.1 (сейчас я пользуюсь Gentoo). Поработав с управлением цветом в Windows, я уже знал, что мне нужно тоже самое и в Linux, но обнаружил, что большинство функционала отсутствовало, либо было доступно в виде консольных приложений (т.е. не интегрировано с графическими приложениями).
На одном из дисков дистрибутива SuSE я нашёл последнюю выпущенную Марти версию LProf (т.е. 1.09) и попробовал с ней поработать. Было ясно, что это хорошее начало, но вместе с тем у программы было и немало недочётов. Я также был огорчен решением Марти не развивать этот проект, несмотря на его [проекта] очевидный потенциал.
Узнав о факте заброшенности LProf, я всерьёз задумался, не заняться ли его развитием. Обнаружилось, что я не одинок в этом желании. Например, Жерар Клавер (Gerard Klaver) сохранил пакет с исходниками 1.09 в надежде когда-нибудь продолжить работу над программой, а Крейг Рингер (Craig Ringer) из проекта Scribus обновил файлы сборки для LProf 1.09. Кроме того, на сайте Жерара было выложено несколько патчей от Марка Рубина (Mark Rubin).
В мае 2005 я взял пакет с исходниками с сайта Жерара и принялся изучать их. Поначалу было непросто, поскольку я никогда ранее не имел дело с C++ и Qt, а на C я ничего не писал уже пять или шесть лет. Так что первые шаги давались с трудом. Затем, в июле 2005, я начал переписываться с Жераром и Крейгом о возможности формального старта LProf как проекта. Оба поддержали мою идею и воодушевили меня начать этот процесс.
В первую неделю августа 2005 года Крейг написал Марти письмо, чтобы получить «благословение», и 13 августа я зарегистрировал проект на SourceForge. На этот момент я уже серьёзно занимался работой над ним. Крейг, будучи одним из разработчиков Scribus, некоторое время работал над частью C++/Qt, отвечал на мои вопросы и вообще здорово помогал мне в преодолении начальных сложностей.
Вскоре мы выпустили версию 1.10, которая по сути была версией 1.09 с обновленными файлами сборки от Крейга, патчами Марка Рубина и моими дополнениями, реализующими поддержку файлов TIFF/IT8. В августе 2005 года программу скачали 64 раза, а к августу 2006 число закачек выросло до 521. В ноябре их было уже 774, сейчас — более 11 тысяч раз. Тут стоит помнить, что LProf в Linux как правило устанавливается из репозиториев, поэтому пользователи Linux получают их чаще оттуда, чем с SourceForge, и приведённые цифры — всего лишь верхушка айсберга.
Сейчас LProf использует как LittleCMS (LCMS), так и Argyll. Зачем нужно несколько модулей?
У них разные возможности. LCMS — отлично написанная, но очень базовая библиотека для управления цветом с простым API. У неё нет многих функций, необходимых профилировщику. К примеру, в ней нет поддержки измерительных устройств.
С другой стороны, у ArgyllCMS есть поддержка таких устройств и очень хороший движок анализа регрессии, но API библиотеки очень сложен, да и сама она во многих случаях не слишком годится для приложений, управляемых событиями, типа LProf (например, оно не всегда передает ошибки вверх по цепочке вызовов).
Так что LProf использует любые необходимые библиотеки, которые просто делают своё дело, и мы не собираемся тормозить только потому, что используем две разные библиотеки из одной и той же категории. По сути, сейчас мы используем даже изменённую версию LCMS, в которой есть кое-какие функции, отсутствующие в оригинале.
А кодом-то этим делиться с LCMS будете? :)
Я предлагал Марти патчи, так что если они ему понадобятся, он может получить их в любой момент. Но добавляемая ими функциональность очень специфична и нужна только тем, кто пишет профилировщики. Не думаю, что стоит надеяться в ближайшем будущем увидеть эти патчи в составе LCMS.
Какие ещё сторонние разработки использованы в LProf?
Мы собираемся использовать solvopt, версия которого уже есть в дереве разработки. Но пока это лишь планы на будущее.
Там же лежит часть qwt, статически линкуемая с LProf. Но мы делаем это лишь потому, что qwt везде по-разному устанавливается, из-за чего в разных дистрибутивах возникают проблемы со сборкой. Например, в некоторых дистрибутивах qwt устанавливается как виджетсет Qt3, что не проблема для нас. Но в других он устанавливается как виджесет Qt4, что нам уже совершенно не подходит. В конечном счёте мы просто собираем статическую локальную библиотеку и этим решаем проблему. К тому же, из всего qwt мы используем лишь один графический элемент.
Кроме того, мы используем wwFloatSpinBox из wwwidgets, поскольку в Qt3 нет виджета spinbox с плавающей точкой. Мы также используем библиотеки VIGRA для работы с изображениями.
С другой стороны, кое-какой код LProf используется в digiKam: я особенно не вглядывался, но, кажется, они используют код для построения диаграммы CIE выбранных пользователем профилей. Возможно, это даже не единственная заимствованная часть.
В течение долгого времени измерительные устройства не поддерживались в Linux и свободных UNIX-системах. В следующей версии LProf эта важная функциональность наконец-то появится. Как далеко она сейчас от пригодного к использованию состояния?
Если тебе повезло и ты выбрал удачный момент, чтобы взять срез дерева разработки из CVS, то программа будет вполне пригодна к работе. Но алгоритмы, используемые для создания калибровочных таблиц монитора и профилей, сейчас достаточно просты. Над ними ещё предстоит поработать, чтобы получить то же качество, что и у кода для создания профилей к цифровым камерам и сканерам (а его качество, как я считаю, на мировом уровне).
Я хочу сказать, что версия из CVS будет создавать нормальные профили для мониторов, и эти профили заметно улучшат работу для большинства пользователей. Просто их качество будет не на том же высоком уровне, что у профилей для камер и сканеров.
Количество изменений, недавно внесённых в код LProf, достаточно велико (вероятно, порядка 5 000 строк нового кода за последние шесть месяцев, а то и больше!!), а в нынешних срезах дерева разработки всё ещё полно ошибок, да и новые функции то и дело прибавляются. Так что пока мы исправляем одни ошибки, появляются другие. Словом, код достаточно нестабилен и быстро меняется. Насколько хорошо он работает, меняется ото дня ко дню, а иногда и от часа к часу.
Как долго ждать, пока программа станет достаточно стабильной? Как сказать. Если несколько опытных разработчков вольются в проект, за пару-тройку месяцев мы вполне осилим выпуск новой версии, включая обновление локализации на разные языки. Если же я продолжу ковыряться в одиночку, как последние несколько месяцев, это займёт больше времени.
Например, сейчас у нас появился разработчик, пользующийся OS X, и качество работы LProf на этой системе быстро поднялось на недосигаемую ранее высоту, хотя ещё не всё исправлено. Это просто пример того, что могло бы быть сделано на прочих фронтах, если бы нам помогли. Так что всё зависит от уровня помощи, которую проект получит от разработчиков из сообщества.
Реализация поддержки новых устройств — вопрос дней или скорее недель?
Это теперь не очень актуально. Поддержка Spyder 2 и Huey уже добавлена в CVS и проходит тестирование. Единственным общедоступным устройством, в настоящее время не поддерживаемым даже на уровне альфы, является ColorVision Spyder 3, которое появилось совсем недавно. Я не ожидаю поддержки Spyder 3 в ближайшем времени, поскольку производитель достаточно враждебно настроен по отношению к сообществу open source. Так что прямо сейчас поддерживаются все распространённые измерительные устройства, покуда производители (скажем, ColorVision) не выпустят новую модель.
Кстати, о Huey… Если я правильно помню, эта железка автоматически подставляет нужные ICC-профили в зависимости от текущих условий освещения. Как это должно работать в Linux, если освещение не контролируемо? Разве тут не нужно что-то вроде демона?
Давай разбираться по порядку. В общих случаях системы управления цветом предполагают использование контролируемого и очень специфического освещения. Это относится к количеству и качеству света в зоне просмотра, где изображения показываются на мониторе, равно как и к условиям просмотра отпечатков. Подход, реализованный в ПО Huey, явно ориентирован на ширпотреб, а не рынок профессионалов.
В реальности действительно лучше работать при контролируемом освещении, как это делают специалисты. На мой взгляд, подход Huey — просто припарки, призванные продемонстрировать типичные проблемы с некорректным освещением в зоне просмотра. Я не думаю, что они могут полностью решить эти проблемы. Например, Huey никак не помогает при просмотре отпечатков и никак не компенсирует паршивое освещение.
Как ты уже догадался, подход Huey не кажется мне лучшим способом расправиться с проблемами некорректного освещения. С моей точки зрения, предлагаемое решение — просто маркетинговая уловка.
Я думаю, лучше всего обучать пользователей, чтобы они понимали необходимость правильности освещения. Более того, то, что пытается исправить Huey, можно сделать дешевле — просто вставив в светильники правильные лампочки и зашторив окна. Любой пользователь, серьёзно относящийся к качеству отпечатков и изображения на мониторе, позаботится об освещении должным образом. А раз сделать это несложно, то почему бы просто не сделать это сразу и правильно? Тем, кто интересуется данной темой, я советую ознакомиться с соответствующими стандартами — с устанавливающим минимальные требования ISO 3664:2000 и более строгим ISO 12646 (в России аналогичные требования регламентируются ГОСТ Р 50923-96, так что требуйте сертификации продукции при оснащении комнаты, где сидят цветокорректоры — прим. пер.).
Кстати, недавние новшества в CVS позволяют LProf измерять и отчитываться об окружающих условиях освещения, если измерительное устройство поддерживает данную функцию. Это позволит пользователям замерять и корректировать освещение на основе объективных измерений, а не угадывания. В случае с Huey программа правильно покажет уровень освещённости, но не скорректирует температуру цвета, поскольку сенсор окружающего освещения в Huey понимает лишь уровень освещённости.
Ну и я поправлю тебя: ПО Huey не меняет профиль. Оно всего лишь корректирует яркость монитора в зависимости от условий освещения.
Ну хорошо. А чем именно могли бы помочь наискорейшему выпуску новой версии простые пользователи и программисты?
Пользователи могут тестировать программу и составлять отчёты об ошибках, присылать запросы на новые функции и жаловаться на просчёты в пользовательском интерфейсе… Разумеется, те пользователи, которые тестируют программу, должны понимать, что прямо сейчас качество частей кода находится на уровне альфы, и порой могут возникать ошибки, серьёзно затрудняющие тестирование или делающие его невозможным.
Отзывы от пользователей очень полезны, поскольку пользователи часто находят ошибки, которые мы, разработчики, попросту не видим. Часто это происходит из-за того, что они используют программу не совсем так, как мы. И чем раньше мы исправим эти ошибки, тем быстрее проект в конечном итоге будет развиваться.
В настоящее время новый код поддержки измерительных устройств и создания профилей для монитора по результатам замеров прошёл лишь ограниченное тестирование. К примеру, единственные устройства, которые точно прошли должное тестирование — это EyeOne Display LT и EyeOne Display 2 (это практически одно и то же устройство) и только на Linux, FreeBSD и Windows XP. Наш новый разработчик, специализирующийся на OS X, на своём компьютере немного протестировал только Spyder 2. Я начал тестировать Spyder 2, Huey и DTP92 у себя. Код поддержки Spyder 2 и Huey в библиотеке для работы с устройствами измерений достаточно нов и наверняка не без погрешностей. Тестирование других поддерживаемых устройств нам очень помогло бы. Кроме того, тестирование новой функциональности ограничено главным образом платформами с X11 (Linux и FreeBSD уже достаточно протестированы), в то время как на Windows XP тестов было достаточно мало, а на Mac — считай, не было вовсе.
Как и любому другому проекту с открытым исходным кодом, нам всегда нужны разработчики. Вот несколько областей, требующих применения усилий:
Во-первых, нужно улучшить код итеративного создания калибровочной таблицы для дисплеев. Сейчас он делает один проход измерений и вычисляет таблицы по очень простому алгоритму.
Во-вторых, необходимо 3D-моделирование и анализ регрессии для профилировщика мониторов (сейчас используется моделирование матрицы, которое слишком ограниченно).
Извини, ты имеешь в виду интеграцию ICC Examin?
Нет, я имею в виду реализацию алгоритма анализа регрессии, используемого в профилировщике камер и сканеров, для создания профилей к устройствам вывода, таким как мониторы и, в дальнейшем, принтеры.
Вот что делает этот алгоритм: он берёт грубые и скудные данные результатов замера, например, полученные из изображения шкалы, созданного профилировщиком камеры/сканера, либо данные от измерителя вроде Huey или EyeOne Display, и вычисляет, какой набор разумно сглаженных трёхмерных кривых лучше всего подойдёт к этим данным. Это необходимо для создания цветовых справочных таблиц (CLUT) профиля, равно как и для вычисления точки белого и прочих характеристик устройств.
Понятно. Ну а остальные области приложения сил…?
Код гамма-коррекции видеокарт в OS X работает только в одномониторных конфигурациях и его нужно доработать, чтобы поддерживались двух- и более мониторные конфигурации. Наш новый разработчик, пользующийся «маком», сейчас работает над этим, и предварительная версия кода доступна в CVS, но пока ещё не протестирована.
Далее, мастер калибровки/измерения предоставляет информацию о статусе выполнения задачи, но пользователи по-прежнему могут привести его в нерабочее состояние — например, начав калибровку одного монитора и запустив измерение для другого. Так что нужна дополнительная осведомлённость о статусе.
В Linux, в зависимости от дистрибутива, могут или не могут потребоваться действия, которые необходимо предпринять, чтобы udev и/или hotplug не мешали измерителям с USB- или последовательным интерфейсом корректно работать. Вероятно, идеальным решением было бы написать для scons полнофункциональные сценарии установки, которые позаботились бы об hotplug и udev, если это вообще возможно. Это одна из тех областей, где я бы предпочёл привлечь к работе эксперта.
И, разумеется, нам нужно портировать интерфейс на Qt4.
Необходимо позаботиться о многих ошибках и улучшениях. Но шесть приведенных выше задач — наиболее важные в моём списке, и любому, обладающему навыками и ресурсами разобраться с одним из них, стоит связаться со мной. Мы примем любую помощь.
Нам также очень поможет участие в проекте программистов, имеющих опыт разработки на Windows, в особенности, являющихся экспертами в MinGW и NSIS, и/или OS X. Таким образом мы довели бы поддержку этих платформ до уровня платформ, использующих X11. Система сборки на основе scons теперь работает на трёх основных платформах при использовании GCC (например, MinGW на Windows), есть предварительная версия сценария NSIS для сборки с MinGW.
В дополнение к этому, есть много нетехнических вещей, которые тоже нужно сделать, таких как написание документации и перевод её и интерфейса программы на другие языки. Ещё мне хочется, чтобы у проекта были более удачные логотип и значок, для чего понадобится помощь дизайнера. А новый логотип будет хорошо смотреться на стартовой заставке, которую я тоже хочу добавить.
Это далеко не полный список задач, и если кто-то хочет помочь с тем, что не было упомянуто, наш проект примет помощь на всех фронтах до тех пор, пока это не будет мешать остальной части проекта. Опять же, если кто-то заинтересован помочь нам, пусть свяжется со мной.
Что касается пользователей — как и с какими именно устройствами тестировать?
Сейчас LProf поддерживает следующие устройства для калибровки и измерения:
- GretagMacbeth Spectrolino
- GretagMacbeth EyeOne Display
- X-Rite/GretagMacbeth EyeOne Pro
- X-Rite/GretagMacbeth EyeOne Display 2
- X-Rite/GretagMacbeth EyeOne Display LT
- X-Rite/GretagMacbeth/Pantone Huey
- X-Rite DTP-92
- X-Rite DTP-94
- X-Rite/GretagMacbeth Huey
- различные OEM-версии EyeOne Display
- ColorVision Spyder 2
USB-устройства должны автоматически отобразиться в мастере калибровки и измерения монитора. На самом деле, они появятся, даже если пользователь подключит устройство после запуска мастера. Этого не умеет даже ПО из поставки от производителей, а ПО для EyeOne Display и вовсе не запустится, если устройство не подключено. Мастер калибровки и измерения мониторов в LProf позволяет пользователям подключать и отключать устройства и корректно отслеживать, какие из них доступны в любой момент времени. Устройства, подключаемые к последовательному порту, работают иначе, и для них есть функция установки на вкладке «Параметры». При установке пользователем такое устройство будет также проверено.
Простым тестом на поддержку измерительного USB-устройства будет сборка LProf из CVS, переход к мастеру калибровки и измерения монитора и подключение устройства. Для устройства, работающего через последовательный порт, это выглядит так: открыть вкладку «Параметры» и установить устройство на нужный порт. Если всё в порядке, устройство пройдёт проверку. Ну а ссли устройство может выполнять калибровку и замер монитора, оно появится в списке измерителей «Выберите инструмент:» («Select Instrument:») в диалоге мастера после не более чем секундной задержки.
Большинство остальных устройств уже так или иначе оттестировано, и с ними не должно быть проблем. Устройства, работающие через последовательный порт, тоже должны работать, но мы тестировали только X-Rite DTP92 и DTP41B.
В двух словах, как происходит реверс-инженеринг устройств измерения?
Прежде всего необходимо отметить, что поддержка всех устройств измерения в Linux/BSD/Unix стала возможной исключительно благодаря реверс-инженерингу. НИ ОДИН производитель не поставляет свои устройства с поддержкой Linux или спецификации на интерфейс устройств, находящихся в продаже в настоящее время. Как ни странно, все эти производители когда-то публиковали спецификации на устройства, и эти спецификации были общедоступны. Так что принцип работы этой индустрии коренным образом изменился по сравнению с тем, что было 5-6 лет назад.
Для реверс-инженеринга подобных устройств нужно само устройство и работающий интерфейс (драйвер и ПО) к нему. Это означает, что большая часть работы ведётся в Windows, либо, что намного реже, в OS X, поскольку официально поддерживаются только эти операционные системы. Кроме того, нужен сниффер портов, который записывает трафик ввода-вывода между ПО и устройством. Полученная им информация используется для выяснения протокола коммуникации с устройством, набора команд, пакетов инициализации и данных.
У этих измерительных устройств по большей части достаточно простой протокол. Выполнить его реверс-инженеринг не слишком сложно (просто отнимает время), и любой, кто знает, что делает (как Грэм Джилл (Graeme Gill) из проекта ArgyllCMS, который является автором кода поддержки измерителей в LProf), может написать работающий драйвер к устройству за одну-две недели в зависимости от возможностей устройства.
Сравните это с каким-нибудь видеоадаптером (вспомните Nouveau и их попытки отреверсинженерить графические карты Nvidia), для реверс-инженеринга которого нужна целая группа программистов и один-два года работы. Так что, по-моему, со стороны этих компаний довольно глупо не работать с нами. Всё равно подробности о протоколах будут доступны в коде библиотеки, создаваемой по результатам наших исследований.
Между прочим, насколько различны протоколы внутри одного семейства устройств?
В целом, устройства могут очень отличаться от производителя к производителю и даже внутри производителя. Иногда устройства от одного и того же производителя могут быть очень схожими. Например, у Huey и EyeOne Display 2 (и LT) много общего, но оба они заметно отличатся от EyeOne Pro. В общем, раз на раз не приходится.
Что ты думаешь по поводу прошлогоднего вливания GMB и Pantone в X-Rite? Может ли оно что-либо изменить для нашего сообщества, поскольку Pantone известна как достаточно агрессивная компания, а X-Rite — как более либеральная?
Я не слишком много знаю о слиянии с Pantone, так что не могу это как-либо прокомментировать. Но слияние X-Rite/GretagMacbeth с моей точки зрения — большое разочарование для сообщества, и мои чувства не изменятся до тех пор, пока политика X-Rite не изменится. До слияния X-Rite была достаточно открытой компанией, которая предоставляла спецификации на интерфейс измерителей любому, представившемуся разработчиком.
Раньше вам не нужно было подписывать какие-либо соглашения, не было никаких ограничений по поводу того, как полученная информация используется разработчиком, и не X-Rite отвечала за поддержку получаемых систем. Все, с кем я разговаривал на эту тему, считали такую политику дружелюбной по отношению к сообществу и считали X-Rite хорошими парнями. Теперь это закончилось.
С другой стороны GretagMacbeth уже некоторое время достаточно закрыты. Последними устройствами GretagMacbeth с опубликованными спецификациями была линейка SpectroLino, выпуск которой начался в середине 90-х. Их всё ещё можно было купить на момент слияния, но сейчас их уже нет в продаже. Все сравнительно недавние модели — EyeOne Pro, серия EyeOne Display и Huey — совершенно закрыты и никакие спецификации на них X‑Rite/GretagMacbeth не публикуют.
В GretagMacbeth версия их библиотеки к EyeOne под Linux была написана как минимум в 2004 году, но они до сих пор отказываются публиковать её, хотя я много раз просил их об этом. Мало того, лицензионное соглашение на EyeOne/Huey SDK содержит пункт, исключающий возможность вызовов к библиотеке из свободного ПО. В этом пункте содержится требование запрашивать у GretagMacbeth разрешение на распространение полученного ПО кем-то, кто не является автором этого ПО. Т.е., скажем, Debian пришлось бы получать у GretagMacbeth разрешение на распространение любого ПО, обращающегося к библиотеке EyeOne.
Менеджеры GretagMacbeth сказали мне, что это ограничение было добавлено не для того, чтобы предотвратить возможность использования библиотеки свободным софтом, но подтвердили, что в итоге получилось ровно это. Насколько мне известно, данное ограничение в силе и по сей день.
На момент слияния я и другие разработчики, связанные с сообществом, контактировали с обеими компаниями, постоянно и настойчиво повторяя, что идти по пути GretagMacbeth ошибочно. Но в X‑Rite не послушали нас и вместо этого прекратили выпуск всех устройств, спецификации на которые были опубликованы, а затем приняли политику GretagMacbeth в данной области.
В этом году проект LProf принял участие в Google Summer of Code. Было ли оно успешным? Что нового это дало пользователям?
Да, проект был успешным. Проект Google Summer of Code 2007 позволил реализовать поддержку некоторого числа новых профилировочных шкал, а именно:
- Hutch Color Target
- GretagMacbeth ColorChecker SG
- GretagMacbeth ColorChecker DC
Студент, работавший с нами в рамках Google Summer of Code 2007, также исправил ряд ошибок, упростил интерфейс установщика эталонных файлов и улучшил проверку этих файлов на корректность перед установкой.
В результате основополагающей работы, проведённой в рамках GSoС 2007, уже по окончании проекта в CVS была добавлена поддержка шкалы GretagMacbeth EyeOne Scanner 1.4. Это было, по большому счёту, тривиальным усовершенствованием ровно потому, что мы смогли задействовать базу кода Google Summer of Code 2007. Теперь LProf поддерживает восемь профилировочных шкал (до проекта — только четыре). Мне не известно о существовании иных профилировщиков, которые поддерживали бы так много профилировочных шкал.
Наш студент продолжает участвовать в разработке проекта. Собственно, именно он добавил поддержку EyeOne Scanner 1.4.
Что было самой большой сложностью для тебя в GSoC 2007?
Думаю, что сложнее всего было с приготовлениями к работе. В самом начале возникли проблемы с обустройством рабочей среды — например, с корректной сборкой и запуском LProf. Главным образом, это из-за того, что студент хотел работать в Windows, а настроить среду сборки в этой операционной системе сложнее, чем в Linux. Кроме того, обычно я и сам работаю в Linux, так что помочь ему было непросто. Когда же мы наконец с этим разобрались, оказалось, что студент порядком отстал от намеченного расписания и подрастерял энтузиазм. Но я продолжил работать с ним и толкать его вперёд, возможно, порой несколько сильнее, чем следовало. На момент подведения промежуточных итогов (середина июля — прим.пер.) он уже снова работал по расписанию. Как только он это осознал, дополнительные усилия с моей стороны больше не потребовались.
Судя по тому,что я прочитал на форумах менторов GSoC, подобного рода затруднения являются обычным делом. Насколько я знаю, студент из второго проекта OpenIcc/GSoC испытал те же сложности с работой под Windows. Оглядываясь назад, я понимаю, что надо было подготовить его рабочее место в Windows или Linux до начала Google Summer of Code 2007.
Создать рабочую среду в Linux можно за короткое время, а подготовить среду для разработки LProf — ещё быстрее. Помимо того, он узнал бы о Linux, что было бы полезно для него. С другой стороны, наш студент исправил несколько старых и специфичных для Windows ошибок в LProf. Так что, полагаю, это разумный компромисс. Стоит добавить, что студент недавно всё же установил Linux на свой компьютер и планирует участвовать в GSoC 2008.
А сам проект планирует?
Я бы хотел этого, поскольку проект от участия в GSoC 2007 только выиграл, да и студент получил хороший опыт несмотря на сложный старт. Он время от времени пишет код для проекта — собственно, я только что упоминал подготовленную им поддержку шкалы EyeOne Scanner 1.4 в CVS. Ну и кроме того, на его счету теперь есть неплохая сумма денег, которая, как он говорит, поможет ему покрыть расходы на учёбу. Он также говорил мне, что за время работы в проекте узнал много нового, а это на мой взгляд — самое важное наше достижение.
Мало того, результат работы над проектом GSoC уже несколько месяцев как интегрирован в LProf, и этот код активно используется. Надо сказать, что интеграция кода на таком раннем этапе достаточно необычна для проектов GSoC. Словом, мы очень счастливы, что всё так сложилось.
В 2007 году мы увидели появление управления цветом в GIMP, XSane, digiKam и других приложениях. Как ты думаешь, каких важных функций по‑прежнему нет для пользователей и разработчиков в этом отношении?
Список получится достаточно длинным. Ну вот например:
Нужно поработать над X.Org, чтобы «познакомить» его с управлением цветом. Это подразумевает массовую поддержку RandR 1.2. Прямо сейчас многие драйверы видеоадаптеров совместимы только с RandR 1.1, из-за чего гамма-коррекция на X11 — занятие тоскливое. Но поддержка RandR 1.2 — всего лишь верхушка айсберга. Кроме этого нужна поддержка DDC/CI и много чего ещё.
Многие DE вроде KDE сейчас не поддерживают управление цветом. К примеру, апплет настройки монитора в KDE «задавливает» (сбрасывает) откалиброванную таблицу гаммы видеокарты и не позволяет пользователю отменить это. Упомянутая проблема с KDE — просто небольшой пример задач, которые необходимо решить на этом уровне.
В настоящее время нет полнофункциональной высокоуровневой системной утилиты для управления цветом — чего-то вроде апплета Color Control в Панели управления Windows или ColorSync в Apple Mac OS X. Некоторая работа над решением этой задачи ведётся в рамках проекта Oyranos, но сам проект пока что ещё очень молод и действительно нуждается в более тесной интеграции с рабочим окружением, X.Org и прочим ПО, таким как драйверы принтеров и прочих устройств (буквально на днях в Oyranos появился бэкэнд и фронтэнд для переключения систем управления цветом, так что дела понемногу налаживаются — прим.пер.).
В настоящее время драйверы принтеров и подсистемы, работающие с ними, не имеют ни малейшего понятия об управлении цветом, хотя в CUPS 1.2 и присутствует ограниченная поддержка ICC-профилей. Насколько мне известно, народ в Gutenprint планирует закрыть вопрос со своей стороны, но пока это только планы.
Необходимо поработать над калибровкой и линеаризацией принтеров. У всех существующих подсистем печати всего лишь базовое управление ими, а используемые таблицы «прибиты гвоздями». Поскольку теперь у нас есть поддержка устройств измерения, я не вижу причин, по которым пользователи не могли бы сами создавать таблицы линеаризации, используя функциональность таких приложений, как LProf или ArgyllCMS. В будущем ситуация обязательно исправится. Вопрос лишь в том, когда именно.
На самом деле, нужно сделать очень многое. Выше приведено лишь несколько примеров.
Помимо полноценной поддержки управления цветом на всех этапах технологической цепочки что, по твоему мнению, могло бы сделать Linux более жизнеспособной платформой для, положим, фотографов?
Одно из наибольших провисаний — поддержка более чем восьми разрядов на канал в полнофункциональном редакторе графики. Эта функциональность есть в Cinepaint и Krita, но в них нет прочих функций, необходимых фотографам. В GIMP хороший набор возможностей, но и ограничение в восемь разрядов на канал. Надеюсь, что как только GIMP перейдёт на GEGL, это ограничение будет снято. Но это, вероятнее всего, произойдёт не менее чем через полгода-год.
Какие инициативы и проекты, связанные с управлением цветом, ты бы хотел видеть развивающимися в будущем?
Разумеется, им всем нужно двигаться вперёд. Уже проделана немалая работа по реализации управления цветом в отдельно взятых приложениях, существуют зрелые библиотеки управления цветом, профилировщики постоянно улучшаются. В общем, я думаю, что важнее всего поддержка CM на системном уровне. Кое-какие изменения уже видны в X.Org, но работы ещё навалом, да и десктопам необходимо подключиться к работе или, как минимум, прекратить заниматься отсебятиной. До тех пор среднестатистическому пользователю будет сложно работать в цветоуправляемой среде.
В долгосрочной перспективе хочется, чтобы прогресс шагнул так далеко, что системные администраторы могли бы быстро настраивать цветоуправляемую технологическую цепочку, совершенно «прозрачную» для конечных пользователей вне зависимости от их опыта. Ни на одной платформе этого пока что нет, включая Windows и OS X, но я могу представить себе, как это можно реализовать в свободных системах вроде Linux/BSD/Unix, X.Org, любом количестве рабочих сред, в драйверах принтеров и прочем ПО. Если бы мы смогли это сделать, наши платформы были бы намного продвинутее Windows и OS X применительно к управлению цветом.
У тебя хорошие отношения с разработчиками Scribus, начиная с момента, когда Крейг Рингер помог со средой сборки. Сейчас, когда проект OpenIcc позволяет ещё большему числу проектов (и даже техническим специалистам производителей принтеров) работать вместе, стало ли на твой взгляд проще сотрудничать?
С командой Scribus приятно работать во всех отношениях. Они поддерживали LProf задолго до того, как я занялся этим проектом и, полагаю, успокоились, увидив, что у проекта появился активный мейнтейнер. Кроме Крейга ещё Андреас Фокс (Andreas Vox) помог с кодом гамма-коррекции в OS X (см. CVS). Питер Линнелл (Peter Linnell) тоже немало помогает с самого начала.
Наши проекты обмениваются информацией по разным поводам. Например, когда я столкнулся с проблемой ICC-профилей (не созданных в LProf), не соответствующих стандартам ICC, на которых lcms начинает сходить с ума, они поделились частью кода Scribus, написанной парой недель ранее для обхода этой проблемы. Я лишь немного изменил его и добавил в LProf.
Пожалуй, стоит упомянуть ещё одного разработчика из их команды, который очень нам помогает. Это Олександр Москаленко, который собирает пакет LProf для Debian, причём всегда вовремя обновляет сборки и порой — в течение каких‑то часов после момента выпуска новой версии.
С тех пор как я начал работать над LProf, я вижу заметное взимодействие между разработчиками в сообществе, в частности, в области управления цветом. Но есть кое-что, что можно сделать ещё лучше. К примеру, мне известно, что ребята из проекта X.Org готовы сделать всё возможное, чтобы улучшить ситуацию со своей стороны, но у них недостаточно информации о полной картине.
Иными словами, сообществу разработчиков, сталкивающихся с управлением цветом, необходимо сесть и задокументировать требования и спецификации для других групп вроде X.Org.
Надо думать, тебе помогали не только разработчики Scribus :)
Разумеется, некоторое количество человек работало над LProf в прошлом и/или продолжает работать сейчас.
Пожалуй самым важным участником проекта является Герхард Фрюрнкранц (Gerhard Fruernkranz). Герхард отвечает за львиную долю нового кода анализа регрессии, используемого профилировщиком камер и сканеров. Он же является автором многих уже нашедших воплощение идей по реализации пользовательского интерфейса. Кроме того, он выполнил перевод интерфейса версии 1.11.4 на немецкий язык. Без участия Герхарда LProf едва ли был бы столь же мощным приложением и потому его вклад в проект бесценен.
Джо Пицци (Joe Pizzi) был нашим Windows-разработчиком в прошлом и сделал немало для того, чтобы версия 1.11.4 была снова доступна на этой платформе, впервые с 2001 года.
Грег Троксель (Greg Troxel) отвечает за сборку для NetBSD.
Джозеф Саймон (Joseph Simon) — студент, работавший с нами в рамках проекта Google Summer of Code 2007.
Марк Мунте (Mark Munte) — наш новый разработчик на OS X. Благодаря ему порт на OS X в очень хорошем состоянии, и я надеюсь, что будущие версии для этой системы будут готовы в виде обычных устанавливаемых пакетов.
Крейга Рингера и Жерара Клавера, помогавших в самом начале, я уже упоминал. Кроме того, есть локализаторы интерфейса.
И, наконец, последние в списке, но не по важности — люди, пожертвовашие проекту деньги: Ларс П. Матиансен (Lars P. Mathianssen), Ларс Торе Густавсен (Lars Tore Gustavsen) и Леонард Ивенс (Leonard Evens). Их деньги пошли на закупку измерительных устройств, которые используются для разработки и тестирования LProf. Мы по-прежнему нуждаемся в таких устройствах, но имевшиеся ресурсы (включая, частично, мои личные) уже исчерпаны. Для тестирования нам нужно купить ещё несколько устройств, в частности:
- X-Rite DTP-94
- GretagMacbeth Spectrolino
- X-Rite/GretagMacbeth EyeOne Pro
Только одно из них производится до сих пор, но те, что сошли с производства, и сейчас широко используются. Сошедшие с производства модели можно или подарить нам, или приобрести на вторичном рынке. Если у кого-то есть такая возможность, пускай свяжутся со мной.
Кроме того, как только мы начнём работать над профилированием принтеров, нам понадобятся совсем другие устройства. Я уже купил X-Rite DTP-41, DTP22 и DTP20, и если бы у меня был DTP51, то мы обладали бы полным спектром устройств для тестирования их поддержки и документирования их использования в LProf.
Сейчас проекту LProf уже два с половиной года. Как ты считаешь, много ли достигнуто из запланированного в начале?
Ну, конечно, если поставить планку высоко и её перепрыгнуть, то потом может оказаться, что в реальности планка была слишком низко. Однако LProf прошёл длинный путь, и даже не слишком подробный список новшеств и изменений измерялся бы страницами.
На этом этапе, я думаю, многое из запланированного в августе 2005 сделано, но при этом есть длинный перечень того, что ещё предстоит сделать. В моём списке задач от 2005 года были и такие, реализация которых заведомо заняла бы от трёх до пяти лет, и при наших ограниченных ресурсах ничего с этим поделать нельзя.
Каковы планы на будущее проекта?
Краткосрочные планы — привести в порядок новый код калибровки и профилирования при помощи измерительных устройств, а затем начать работу над версией 1.99 (2.0 будет стабильной версией с поддержкой измерителей).
Когда выйдет версия 2.0, мы начнём работу над профилированием принтеров (версия 3.0), одновременно улучшая 2.0 — например, добавляя поддержку DDC/CI и/или органов управления мониторами USB HID, чтобы нужные параметры автоматически выставлялись при калибровке.
В конечном счёте я хочу, чтобы LProf был первоклассным профилировщиком во всех отношениях. Когда я только начинал работать над проектом, ни одна его часть не могла быть так названа. Пользовательский интерфейс был фрагментирован, сложен в использовании и лишён интеграции. Код для создания профилей поддерживал только изображения с восемью разрядами на канал. Справочной системы не было, интерфейс был доступен только на английском языке, поддержки измерительных устройств не было.
В настоящее время как минимум часть кода находится на высшем уровне или на пути к нему. Актуальная база кода очень продвинута и существенно больше той, едва пригодной к работе, с которой мы начали в августе 2005.
Ну и последнее: твоя собственная цифровая тёмная комната на 100% основана на свободных программах?
До недавних пор мне приходилось печатать снимки из Windows, потому что не было хорошего профиля для Epson R2400 и Gutenprint. Но теперь у меня есть strip reading спектрофотометр и я могу создавать собственные CMYK‑профили для принтера. Так что сейчас я пользуюсь исключительно свободным софтом. Фотографии я печатаю из программы PhotoPrint, которая использует Gutenprint и поддерживает управление цветом.
С Хэлом беседовал Александр Прокудин
Оставить комментарий