Обзор библиотек для работы с изображениями

В мире свободного ПО идёт гигантская работа над созданием отличных приложений для работы с растровой графикой. И это значит, что существует немало бесплатных или открытых библиотек, на основе которых можно создать редактор графики.

Тем не менее, большинство приложений используют собственное ядро. Krita использует pigment для управления цветом и kritaimage для работы с растром. Точно так же, в digiKam свой класс для работы с графикой, а у GIMP своё ядро, хотя его давно собираются заменить на GEGL, ну и так далее.

Существует три общепринятых способа хранения данных изображений: мозаика (tiles), растровые строки и блобы. Мозаика используется в Krita, GIMP, библиотека JAI из Java и Photoshop, не говоря о многих других. Размер элементов мозаики в Krita — 64×64 пиксела. Растровые строки используются в новой версии Cinepaint (Glasgow) и MosfetPaint Мосфета. Блобы, насколько мне известно, используются в digiKam и, разумеется, в самом Qt: QImage сама по себе маленькая библиотека, равно как и QPainter.

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

Время от времени появляются люди, которые предлагают использовать в Krita ту или иную библиотеку работы с изображениями. Раньше это было болезненным вопросом, но сейчас Krita дорос до 100.000 строк кода и собственного ядра работы с изображениями, которое может быть и не самое оптимизированное, зато очень удобное и простое.

Наиболее близкой к ядру Krita библиотекой является, пожалуй, Vigra, поскольку и Krita, и Vigra используют не мозаику с растровыми строками, а итераторы. В части использования темплейтов к нему близка Generic Image Libary компании Adobe.

Далее следует вовсе не исчерпывающий список библиотек (или приложений, если у них свои библиотеки) для обработки изображений с моей оценкой каждой из них. Этот список был подготовлен ещё в 2003 году, но сейчас ради такого случая я его обновил.

Krita

В Krita своя библиотека обработки двухмерных изображений, состоящая из менеджера мозаики, классов слоёв и KisPainter. Начиная с KOffice 2.0 библиотека цветовых пространств выделена в pigment, а библиотека обработки изображений полностью отделена от GUI. Было бы неплохо полностью отделить их от KOffice, но это не приоритетная задача.

Преимущества:

  • уже работает
  • оптимизирована для интерактивной работы
  • допускает работу с разными цветовыми моделями

Недостатки:

  • не оптимизирована (пока что)
  • серьёзные проблемы с большими изображениями
  • не поддерживается индексированный режим

GIMP

В GIMP сложное ядро, позволяющее осуществлять интерактивную манипуляцию изображениями в режиме 8бит/канал.

Преимущества:

  • хорошо протестировано, достаточно самоценно
  • оптимизировано для интерактивного использования

Недостатки:

  • написано на C
  • недоступно в виде библиотеки
  • зависит от glib и gtk
  • ограничение в 8 бит на канал
  • нет цветовых моделей — «прибиты гвоздями» gray8, rgb8 и, местами, индексированный режим
  • проблемы с обработкой действительно больших изображений

Vigra

Vigra — библиотека на C++, написанная Ульрихом Кётте (Ullrich Koetthe) в качестве демонстрации к его докторской диссертации по гибким алгоритмам обработки изображений. Читать эту диссертацию — сплошное удовольствие. Она заметно повлияла на разработку Krita, хотя мы тут скорее машем собакой, чем хвостом, в плане использования шаблонов (Боудевийн ссылается на известную поговорку «Почему собака виляет хвостом? Потому что она умнее хвоста. Если бы хвост был умнее, он сам вилял бы собакой.» — прим.пер.).

Преимущества:

  • работает с очень большими изображениями
  • поддерживает разные цветовые модели
  • поддерживает различную глубину цвета через C++ темплейты
  • современный C++
  • достаточно мала
  • хорошо документирована
  • интересные алгоритмы

Недостатки:

  • не оптимизирована для интерактивного использования
  • заточена под исследовательскую работу

VIPS

VIPS — библиотека на C, но с C++ интерфейсом. Она спроектирована для обработки очень больших изображений, главным образом, для исследований картин в музеях вроде Национальной Галереи (имеется в виду Национальная Галерея в Лондоне — прим. пер.). К ней прилагается графический пользовательский интерфейс на Gtk2 под названием nip2, который больше похож на Excel для обработки графики.

Преимущества:

  • работает с очень большими изображениями
  • работает с разными цветовыми моделями
  • поддерживает различную глубину цвета
  • интерфейс на C++

Недостатки:

  • не оптимизирована для программ, в которых рисуют (хотя доработка возможна)
  • очень большая

VXL

VXL — набор небольших библиотек, используемых в академических исследованиях при визуализации образов и результатов вычислений.

Преимущества:

  • работает с очень большими изображениями
  • написана на C++

Недостатки:

  • давно не обновлялась
  • использует свои базовые библиотеки, заменяющие стандартный C++
  • оптимизирована для простых изображений в RGB
  • нет лицензии
  • плохо документирована

CImg

CImg — прекрасная и очень маленькая библиотека, в которой реализованы действительно инновационные эффекты обработки изображений, такие как зарисовывание (inpainting) испорченных или шумных изображений. Мы используем её в расширении greycstoration в Krita.

Преимущества:

  • маленькая
  • GPL
  • офигенная

Недостатки:

  • абсолютно всё, включая GUI, живёт в одном заголовочном файле
  • плохо документирована

GEGL

Ожидалось, что GEGL станет ядром GIMP 2.0, но разработка застопорилась настолько, что перехода на GEGL до выхода 2.0 не произошло (как известно, его и до выхода 2.4 не произошло — прим. пер.). В целом, это попытка написать темплейтную библиотеку на C при помощи собственного языка описания операций над изображениями. Недавно Ойвинд Колас aka Pippin подобрал упавший флаг разработки. Прогресс налицо, но я всё же не уверен в том, что будет просто или вообще возможно взять и сходу портировать GIMP на GEGL.

Преимущества:

  • маленькая библиотека
  • вместе с babl поддерживаются все мыслимые цветовые модели
  • оптимизирована для интерактивного использования
  • Pippin — клёвый

Недостатки:

  • пока не завершена
  • написана на C
  • сложный хак вокруг факта низкоуровневости С

libart_lgpl

На самом деле, libart — не библиотека для обработки изображений, а скорее канва для рисования изображений. Он оптимизирован под векторную графику и используется в Karbon 1.x для рендеринга фигур перед выводом на экран. Karbon 2.x будет использовать Arthur. (Вообще говоря, libart_lgpl много где используется — например, в Scribus и в GIMP. В последнем — для рендеринга контуров, хотя есть планы уйти на librsvg — прим. пер.)

Преимущества:

  • Раф Левьен (Raph Levien) — отличный специалист, и libart это своим качеством доказывает

Недостатки:

  • написана на C
  • в общем-то, это не библиотека обработки изображений
  • сложно использовать
  • устарела и подлежит замене на Cairo или Arthur

java2D

Java2D — более или менее полноценная библиотека для созданий «рисовательных» программ. Она позволяет работать с изображениями разных форматов, цветовыми пространствами, алгоритмами преобразования пикселов изображения и текстом. Само собой, написана она на Java, и свободная реализация пока не готова (Есть мнение, что автор давно не смотрел в GNU Classpath — прим. пер.), да и к тому же она использует Cairo. Когда-то у меня была программа с открытым исходным кодом, основанная на Java2D, но исходники я потерял, а названия уже не помню.

Преимущества:

  • приятная объектно-ориентированная архитектура
  • полнофункциональная (даже слишком)

Недостатки:

  • Java
  • не свободна
  • содержит кое-какой легаси-хлам

ImageMagick/GraphicsMagick

GraphicsMagick — это ImageMagick под другой лицензией и с фокусом на стабильный API. Теперь GM и IM отличаются ещё и функциональностью. Ранее Krita активно использовал IM (ещё в 2004 можно было найти его куски в коде программы), но затем от ядра на основе IM отказались в пользу нынешнего: оказалось, что IM сложно использовать в интерактивном приложении.

Недавно мы сделали большую часть фильтров импорта и экспорта независимыми от ImageMagick и оставшийся код ради стабильности API переписали под GraphicsMagick.

Преимущества:

  • зрелая
  • интерфейс на C++
  • полнофункциональная
  • RGB и CMYK (но не более того)
  • лицензионно совместима с Krita
  • в активной разработке

Недостатки:

  • глубина цвета — параметр, жёстко задаваемый при компиляции
  • не оптимизирована для интерактивного использования

The Visualization Toolkit (VTK)

Огромная библиотека на С++ от создателей CMake для работы с двух- и трёхмерными изображениями и визуализации данных. Слишком огромная, чтобы я мог её всесторонне оценить.

Преимущества:

  • используется в прочих приложениях на Qt вроде Julius
  • вероятно, очень хороша

Недостатки:

  • книга с документацией к ней очень дорога
  • использует свой эквивалент make под названием CMake — но ладно, в наши дни это же преимущество!
  • очень большая

GIL

Это набор заголовочных файлов, зависящих от Boost и реализующих алгоритмы работы с изображениями. Приятно то, что GIL одинаково работает с обычными и планарными изображениями, т.е. с изображениями, где каждый канал занимает свой блок памяти, и изображениями, где пикселы пишутся один за другим в память. GIL используется в приложениях Adobe и Mission Photo (опенсорсный каталогизатор фотографий на PyGtk).

Преимущества:

  • в Adobe своё дело крепко знают
  • очень современный C++

Недостатки:

  • довольно сложно вникнуть
  • не совсем полноценная библиотека — как про неё однажды сказали, «это библиотека обобщённых парсеров и конвертеров для разнообразных типов изображений, которая позволяет обрабатывать их с такой же лёгкостью, как если бы это изображение имело простую попиксельную внутреннюю структуру»

Прочие

Библиотеки для обработки изображений или самостоятельные приложения — Perico, Digikam, Cinepaint (and Glasgow), PIL, Java Advanced Imaging API — их ещё много… Я упомянул лишь те, которые исследовал сам, когдща взялся за разработку Krita и искал библиотеку, на которой можно было бы базировать код.

Думаю, что создание собственной было правильным решением: мы многому научились и создали свои, уникальные функции. Решение использовать итераторы стоило нам производительности, но сделало разработку функционала намного проще.

В настоящее время мы заменяем архитектуру прямого наследования в библиотеке цветовых пространств на темплейты, что ещё больше упрощает написание кода поддержки новых цветовых пространств. Нам больше не понадобится целых два дня, чтобы реализовать поддержку L*a*b!


Автор: Boudewijn Rempt
Источник: http://www.valdyas.org/fading/index.cgi/software/image_libraries.html?seemore=y

Оставьте первый комментарий

Оставить комментарий

Ваш электронный адрес не будет опубликован.


*


Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.