Предварительный обзор OpenRaster

В статье рассматриваются история и предпосылки к возникновению OpenRaster — проектного формата для хранения и передачи растровых данных с сохранением многослойности и параметров обработки. Рассказывается о возможностях формата на текущем этапе его развития.

История

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

Основная причина — практическая невозможность полностью воспроизвести в фильтре импорта/экспорта возможности «родного» редактора даже при наличии полной спецификации на формат. Мало того, с выходом каждой новой версии продукта, использующего этот формат, фильтры приходится пересматривать. В ряде случаев публично доступными являются спецификации на старые версии формата, в результате чего поддержка актуальной версии формата может быть относительно полной только в той части, которая совпадает с прежней.

Теоретически, эта проблема решается при помощи форматов обмена данными, которые заведомо менее гибки, чем собственные форматы приложений, но передают необходимый минимум проектных данных, позволяющий менять те или иные параметры обработки. Пользователям аудио- и видеоредакторов в этом отношении более-менее повезло — для них существуют проектные форматы обмена данными, такие как OMF, AES31, AAF и MXF, так или иначе поддерживаемые большинством распространённых на рынке программных продуктов высокого уровня.

Если мы говорим о векторной графике, то здесь есть SVG, который пусть и имеет неприятные ограничения для «печатников» ввиду отсутствия «родной» поддержки CMYK, градиентной сетки [1] и прочего, зато несколько лет как поддерживается лидерами рынка — Adobe Illustrator и CorelDRAW [2] и его использование, судя по ряду форумов, становится обычной практикой, не в последнюю очередь благодаря проекту Open Clip Art Library.

В мире растровой графики всё намного сложнее. Для обмена проектными данными с Реальным Миром™ предлагается не заморачиваться и пользоваться PSD. Однако, последняя свободно доступная спецификация на PSD описывает версию от Photoshop 6.0, в то время как текущая версия формата относится к Photoshop 9.0 (CS2). Неудивительно, что его поддержка в свободном софте не идеальна. С какими проблемами сталкиваются мигранты с Photoshop на GIMP, хорошо видно по первому разделу справочной страницы в нашей базе знаний [3].

Прибавим к этому, что с некоторых пор количество полнофункциональных редакторов растровой графики для Linux увеличилось с двух (GIMP и Cinepaint) до четырёх (плюс Krita и Pixel). В каком формате их пользователям обмениваться данными?

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

Теоретически, можно попробовать стандартизовать один из имеющихся проектных форматов свободных программ. Посмотрим, что у нас есть:

  1. XCF. Это собственный формат файлов GIMP. Увы, формат имеет ряд недочётов, так что сами разработчики не рекомендуют использовать его где-либо ещё. Более того, документация на XCF до недавних пор была рудиментарна и только усилиями Хеннинга Макхольма, автора xcftools, это было исправлено. Существуют наброски переработанного и улучшенного варианта XCF, известного как XCF2.
  2. KRA. Это формат файлов Krita — редактора растровой графики из офисного пакета KOffice. Структурно он похож на семью форматов OpenDocument, поскольку все данные (описание на XML и картинки) хранятся в ZIP-архиве. Формат в последнее время претерпел ряд изменений в связи с массированным добавлением функций в сам редактор (управление цветом, коррекционные слои и т.д.). Эти изменения вносились сравнительно стихийно и разработчики тоже не считают его идеалом, так что и KRA не подходит.
  3. CPX. Это новый формат Cinepaint, который проектировался ещё три года назад. Разработчики вскоре переключились на работу над Glasgow [4] и доводку формата временно прекратили. Таким образом, несмотря все интересные задумки авторов (более простой чем XML для синтаксического разбора формат, растровые и векторные слои и т.д.) , стандартизовать CPX тоже нельзя.

После выхода статьи Натана об OpenRaster в разных уголках Интернета приходилось слышать занятные предложения расширить какой-нибудь существующий более распространённый формат конечного представления данных. Это довольно наивное предположение. Из форматов, поддерживающих большую разрядность на канал, подходят разве что TIFF и PNG. TIFF контролируется компанией Adobe и о его расширении лучше сразу забыть. Portable Network Graphics — во многих отношениях приятный формат, но изначально спроектированный с прицелом на веб-графику [5]. К тому же, спецификация на него допускает хранение цветов всего в трёх режимах: индексированный режим, оттенки серого и RGB 8/16 разрядов на канал. Это ограничение не позволяет сделать из него толковый проектный формат — нам нужны ещё как минимум CMYK и CIE LAB, не говоря о YUV и YCbCr.

И вот тут на сцену выходит OpenRaster.

Идея создания универсального формата многослойной растровой графики появилась у нынешнего мейнтейнера KOffice Боудевийна Ремпта (Boudewijn Rempt), который по совместительству последние три года является лидером команды разработчиков Krita. Предпосылка очень простая: весь KOffice понемногу переводится на использование семейства форматов OpenDocument в качестве собственных форматов данных. Из всех приложений занозой в пятке оставался именно Krita, поскольку для него в OpenDocument не было подходящего формата.

Поэтому когда в списке рассылки разработчиков GIMP снова поднялся вопрос о качестве фильтров импорта/экспорта PSD и прозвучала тема универсального формата с массой «наворотов», эта идея была быстро подхвачена в списке рассылки CREATE и развитие событий ускорилось.

Основным условием работы над спецификацией нового формата, получившего рабочее название OpenRaster, со стороны Боудевийна стала заинтересованность и участие разработчиков других программ. Пока что это условие выполняется: над OpenRaster работают Кирилл Бергер (Cyrille Berger) из команды Krita и Ойвинд Колас (Oyvind Kolas) из команды GIMP, параллельно курирующий работу над GEGL.

Давайте посмотрим, что у нас есть на данный момент.

Возможности формата

Модель документа

Модель документа наследуется от OpenDocument, то есть файлы описания данных с разметкой на XML и бинарные данные хранятся в одном архиве ZIP. Предположу, что автосохранение пятисотмегабайтного проекта в архив ZIP каждые десять минут прозвучит для многих как отрывок сценария фильма ужасов. На самом деле, весь фокус в том, что по умолчанию при сохранении будет использоваться нулевое сжатие. А вот для передачи данных можно будет выбрать иной, достаточно высокий уровень компрессии.

Что касается самих бинарных данных, пока неясно, какой пиксельный формат будет избран. Скорее всего, это будет пирамидный тип, как пусть и самый сложный, но зато хорошо зарекомендовавший себя при сжатии без потери в качестве (он используется, к примеру, в PNG) и позволяющий загружать очень большие файлы не сразу полностью, а частями по мере необходимости.

Помимо технических оснований создание формата на основе модели документов OpenDocument имеет ещё и политические основания. Иметь за спиной OpenDocument Format Alliance, в который входят достаточно сильные игроки на рынке информационных технологий — довольно разумно.

Метаданные

Преимущество формата состоит в том, что все метаданные включаемых в проект документов (EXIF, IPTC, GPS) будут сохраняться вместе с исходными документами и доступ к ним можно будет получить в любой удобный момент. Таким образом, если вы создаёте коллаж из работ других людей, опубликованных, скажем, на условиях CC ShareAlike, вам не придётся долго и нудно вбивать их имена в поле «Авторы». Само собой, все текстовые данные будут храниться в кодировке UTF-8 или UTF-16.

Слои

Слои можно будет группировать и назначать им разные режимы совмещения. Если слой был добавлен импортом существующего изображения, встроенный в него ICC-профиль будет сохранён вместе с оригиналом изображения в файле проекта.

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

Текущий подход, изложенный в черновике раздела спецификации, описывающего реализацию слоёв, таков: для описания используется пространство имён. Синтаксис, соответственно — «пространство имён:имя фильтра». Таких пространств имён три:

  1. «standard» — стандартные фильтры и описание их действия.
  2. «composite» — составные фильтры, т.е. фильтры, состоящие из нескольких стандартных.
  3. «applications» — нестандартные фильтры, специфические для приложения, которое записывает файл документа.

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

Настоящее и будущее

В настоящее время существует опубликованный в мае 2006 черновик стандарта. Кирилл и Ойвинд ставят опыты на кошках и прорабатывают особенности реализации. Начальный код поддержки OpenRaster уже есть как в Krita, так и в GEGL. Когда эта работа будет завершена, а все детали — утрясены с другими разработчиками, окончательно сформированный черновик будет переслан в OASIS OpenDocument Format Adoption Technical Committee и начнёт проходить стандартные процедуры рассмотрения.

В более отдалённой перспективе OpenRaster светит статус стандарта ISO, что 1 мая 2006 года уже произошло с Open Document Format (ISO/IEC 26300). Это сделает его не просто интересным и перспективным форматом, поддерживаемым свободными приложениями, но рекомендуемым стандартом.

Кроме разработчиков GIMP, Krita и Pixel в поддержке OpenRaster заинтересованы разработчики редакторов векторной графики, в частности Xara Xtreme и sK1. Прибавится хлопот и разработчикам OpenOffice.org Draw, которым и без того уже не первый год сложно даётся поддержка SVG.

Со своей стороны проект linuxgraphics.ru в лице некоторых его представителей принимает участие в формировании требований к стандарту, готов выслушать пожелания пользователей и обязуется держать общественность в курсе событий.


[1] По последним данным, это совершенно нормально обходится.
[2] Качество экспортируемых ими SVG — отдельная тема.
[3] Между тем, Кирилл Бергер начал работать над общей библиотекой для чтения и записи файлов PSD.
[4] Cinepaint нового поколения с интерфейсом на FLTK
[5] Хотя и используется сейчас при оформлении графического интерфейса разных приложений.

1 Trackback / Pingback

  1. MyPaint 0.6.0 | Мультимедиа в Linux

Комментарии закрыты.