LINUX.ORG.RU

Пурум-пум-пум, или SAIL: Библиотека декодирования изображений

 , , , ,


0

1

Привет!

Я начал новый проект под лицензией MIT и был бы очень рад вашим отзывам и фич-реквестам :)

Проект: https://github.com/smoked-herring/sail

Это библиотека декодирования изображений, ребрендинг кодеков ksquirrel-libs из давно почившего просмотрщика изображений KSquirrel.

Целевая аудитория:

  • Просмотрщики изображений
  • Разработка игр
  • Загрузка изображений для иных целей

Возможности:

  • Простая, маленькая, и быстрая библиотека написанная на С без сторонних зависимостей (кроме кодеков)
  • Простой, понятный, и в тоже время мощный API для всех нужд
  • биндинги к C++
  • Форматы изображений поддерживаются динамически загружаемыми кодеками
  • Чтение изображений из файла, памяти, или даже своего собственного источника данных
  • Определение типа изображения по расширению файла, или по магическому числу
  • Операции чтения всегда могут выдавать пиксели в формате RGB и RGBA
  • Большинство кодеков умеют выдавать также и исходные (SOURCE) пиксели. Это пригодится например тем, кто захочет выбить весь дух из CMYK изображений
  • Некоторые кодеки могут выдавать пиксели в ещё большем списке форматов
  • Чтение и запись ICC профилей
  • Примеры на C, Qt, SDL
  • Лучшие MIME иконки в компьютерной индустрии :)

Чего SAIL не предоставляет:

  • Редактирование изображений
  • Функции конверсии цветовых пространств кроме тех, что дают низлежащие кодеки (libjpeg и т.д.)
  • Функции управления цветом (применение ICC профилей и т.д.)

Поддерживаемые форматы на данный момент:

  • APNG (чтение, только на Windows)
  • JPEG (чтение, запись)
  • PNG (чтение, запись)

Работа по добавлению новых форматов ведётся. KSquirrel-libs так или иначе поддерживал около 60 форматов, так что работы предстоит много :)

Поддерживаемые платформы:

  • Windows (installer)
  • MacOS (brew)
  • Linux (Debian rules)

Простейший пример декодирования на C:

struct sail_context *context;

/*
 * Initialize SAIL context. You could cache the context and re-use it multiple times.
 * When it's not needed anymore, call sail_finish(context).
 */
SAIL_TRY(sail_init(&context));

struct sail_image *image;
unsigned char *image_pixels;

/*
 * sail_read() reads the image and outputs pixels in BPP32-RGBA pixel format for image formats
 * with transparency support and BPP24-RGB otherwise. If you need to control output pixel
 * formats, consider switching to the deep diver API.
 */
SAIL_TRY(sail_read(path,
                   context,
                   &image,
                   (void **)&image_pixels));

/*
 * Handle the image pixels here.
 * Use image->width, image->height, image->bytes_per_line,
 * and image->pixel_format for that.
 */

free(image_pixels);
sail_destroy_image(image);

Краткое описание уровней API:

  • Новичок: Я просто хочу загрузить этот чёртов JPEG
  • Продвинутый: Я хочу загрузить этот чёртов анимированный GIF из памяти
  • Глубоководный дайвер: Я хочу загрузить этот чёртов анимированный GIF из памяти, и иметь полный контроль над выбранными кодеками и форматом отдаваемых пикселей
  • Технический дайвер: Я хочу всё то, что выше, и мой собственный источник данных

Отличия от других библиотек:

  • Человеческий API с ожидаемыми сущностями - изображениями, палитрами и т.д. Никакого ада а-ля WIN32 API ;)
  • Большинство кодеков умеют отдавать не только RGB/RGBA пиксели
  • Писать кодеки можно на любом языке, и добавлять/удалять их без перекомпиляции всего проекта
  • Сохранение информации об исходном изображении
  • «Прощупывание» (probing) - получение информации об изображении без декодирования пиксельных данных
  • Размер и скорость

Кому интересна эта тема, приглашаю всех посмотреть! Отзывы и разного рода отчёты категорически приветствуются.

Если вы хотите как-то помощь проекту, то даже звёздочка (star) на Github будет огромной помощью.

SAIL всё ещё в разработке, но уже пригодна для использования. Бинарная совместимость и совместимость исходного кода пока что не гарантируется.



Последнее исправление: sailor (всего исправлений: 1)

без сторонних зависимостей
(кроме кодеков)

Теперь давай ещё раз медленно и печально. Ты лепишь общий унифицированный интерфейс к декодированию битмапов в RGB(A) / (A)RGB или что?

Размер и скорость

В сравнении с чем?

LamerOk ★★★★★
()
  • 1 TGA добавляй, без тигры (TiGrA :D) любое связанное с картинками неполноценно

  • 2 Альтернатив миииилллиард, поэтому сделай киллер фичу тнранскодер прозрачный для пользователя, пользователь грузить любую муть jpg,tga,bmp,gif оно внутрях налету транскодит это в dds и отдаёт memory_ptr у тебя там указано доя игр типа, так вот такая фича будет полезна.

Вроде всё, удачи =)

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от Harald

Ты хотел сказать ImageMagic? Ну так он начал. Линукс же тоже был ненужен раньше =)

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

TGA

зачем это ненужно куда-то добавлять

anonymous
()
Ответ на: комментарий от LINUX-ORG-RU

1 TGA добавляй

в планах есть, конечно же

Альтернатив миииилллиард

перечисли какие знаешь, например. Я всегда рад посмотреть как они организованы.

тнранскодер прозрачный для пользователя

Оно сейчас так и есть, но без поддержки dds пока :)

Use-case в твоём примере в терминах SAIL:

sail_start_reading_file -> sail_read_next_frame -> sail_stop_reading -> sail_start_writing_mem -> sail_write_next_frame -> sail_stop_writing

sailor
() автор топика

Сразу, кстати, вопрос: что будет, если в «чёртовом JPEG» искажения отдельных байт в заголовке, в частности, смещения в таблицах ссылаются за пределы области памяти с картинкой? Или этот вопрос целиком на совести libjpeg?

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

Для JPEG используется libjpeg-turbo. Поэтому да, обработка этой ситуации в первую очередь на совести libjpeg. Если он отдаёт ошибку и завершает декодирование, то далее SAIL эту ошибку ловит и отдаёт пользователю.

sailor
() автор топика
Ответ на: комментарий от Harald

космический корабль тоже грузы перевозит, но в общем случае машина или даже самолёт справится намного лучше :) FFmpeg - это сверхкомбайн для такой задачи как декодирование изображений. Она никогда и не позиционировалась как таковая.

sailor
() автор топика
Ответ на: комментарий от sailor

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

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

Harald ★★★★★
()
Ответ на: комментарий от Harald

А пакеты FFmpeg-а с поддержкой всех возможных форматов

FFmpeg не поддерживает достаточно большое множество форматов изображений. Это логично, т.к. ffmpeg - это не image decoding library, и никогда таковой не хотела быть.

наверняка уже притянуты по зависимостям другими программами на десктопе

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

так что на общий вес просмотрщика зависимость от FFmpeg-а скорей всего не повлияет.

опять не соглашусь, ибо это невероятно большие лишние зависимости. SAIL - это лёгкая библиотека. Если вы захотите её установить, она не предложит вам установить 100 Mb файлов.

Плюс сверхоптимизированное масштабирование изображений и конвертация между форматами пиксела

SAIL не предоставляет функции редактирования, это не её задача. Если хотите, то после декодирования с помощью SAIL можете использовать ffmpeg чтобы сверхбыстро масштабировать RGBA данные :)

плюс аппаратное ускорение кодирования-декодирования

для JPEG или PNG? :)

куча различных фильтров и вспомогательных функций

всё это лежит за пределами решаемой задачи. Есть область - кодирование и декодирование изображений, не более того. Я перечислил прямых конкурентов. Это настоящие конкуренты. Но никак не ffmpeg. Бенчмарки я планирую сделать в ближайшее время +/- и сравнить их :)

sailor
() автор топика
Ответ на: комментарий от RazrFalcon

Написаны.

Даже не знаю хорошо это или плохо. Скорее всего плохо, и говорит о невероятном техническом долге. Просто мнение, не хочу спорить.

sailor
() автор топика
Ответ на: комментарий от hobbit

«Новичок» пишется через «о»

Ну вот, исправлен первый баг :)

sailor
() автор топика
Ответ на: комментарий от sailor

FFmpeg не поддерживает достаточно большое множество форматов изображений. Это логично, т.к. ffmpeg - это не image decoding library, и никогда таковой не хотела быть.

Например, какие? Но всё равно уже умеет всяко больше, чем PNG, APNG и JPEG.

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

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

опять не соглашусь, ибо это невероятно большие лишние зависимости. SAIL - это лёгкая библиотека. Если вы захотите её установить, она не предложит вам установить 100 Mb файлов.

equery size ffmpeg
 * media-video/ffmpeg-4.2.2
         Total files : 267
         Total size  : 22.34 MiB

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

для JPEG или PNG? :)

Для JPEG - да, для PNG нет

Я перечислил прямых конкурентов. Это настоящие конкуренты

Среди настоящих конкурентов незаслуженно забыт Qt, где класс QImage покрывает все задачи сабжа

https://doc.qt.io/qt-5/qimage.html

Harald ★★★★★
()
Ответ на: комментарий от Harald

Но всё равно уже умеет всяко больше, чем PNG, APNG и JPEG.

Космические корабли тоже грузы доставляют.

И это в Gentoo, где ffmpeg идёт одним пакетом, включая статические библиотеки и заголовочные файлы

https://packages.ubuntu.com/groovy/libavcodec58

14 Mb + 30 библиотек зависимостей. Для целей «открыть этот чёртов JPEG» - мягко говоря перебор. Однако, никто ведь не запрещает использовать ffmpeg для этих целей. Ваше право.

Среди настоящих конкурентов незаслуженно забыт Qt

аналогично - сверхкомбайн, не прямой конкурент ни разу. Скорее gdk-pixbuf. Поддержка форматов бедная. НО Qt никогда и не позиционировался как image decoding library. Так что бедность форматов не может быть каким-то сильным аргументом против.

sailor
() автор топика
Ответ на: комментарий от sailor

аналогично - сверхкомбайн, не прямой конкурент ни разу. Скорее gdk-pixbuf. Поддержка форматов бедная. НО Qt никогда и не позиционировался как image decoding library. Так что бедность форматов не может быть каким-то сильным аргументом против.

Если мы вдруг пишем кросплатформенный просмотрщик изображений, то с вероятностью > 50% используем Qt в роли графического тулкита, и тогда дополнительные библиотеки для декодирования не нужны. Ну а если Gtk, тогда да, надо выбирать из чего-то

Harald ★★★★★
()
Ответ на: комментарий от Harald

используем Qt в роли графического тулкита, и тогда дополнительные библиотеки для декодирования не нужны

это зависит от того как Qt собран, его можно собрать с использованием внешних библиотек и тогда появляется зависимость, а с учётом того что Qt обновляется сравнительно редко обычно так и делают, так как находящиеся в нём libjpeg/libpng/… сравнительно старые

imb ★★
()
Ответ на: комментарий от RazrFalcon

Нет, очевидно. Иначе ты бы воровал чужой код, как и прочие адепты.

К тому же, ты обгадился. Говнораст никак не поможет. Зачем эникей пытается рассуждать о том, о чём ничего не знает? Наворовал чужого и решил кому-то о чём-то рассказывать?

nomihos
()
Ответ на: комментарий от Harald

зачем оно нужно, когда есть FFmpeg

Одиночное изображение - частный случай видео.

Толстый, неумный троллинг. Либо шокирующее дилетантство и безграмотность в обсуждаемом вопросе. Зачем врываться в обсуждение, если нечего сказать по теме? Ненужнисты не нужны.

Как ffmpeg служит для воспроизведения видео в разных форматах, а libarchive — для открытия разных архивов, так и эта библиотека позиционируется как общее решение для множества разных форматов картинок. Принципиальные аналоги из этой ниши — freeimage, DevIl, SDL_image и тому подобные.

Среди настоящих конкурентов незаслуженно забыт Qt

…используем Qt в роли графического тулкита, и тогда дополнительные библиотеки для декодирования не нужны…

Как уже было сказано, неумный троллинг или шокирующее дилетантство.

Если мы «используем Qt» — то появляется привязка к языку C++, компилятору C++, объектной системе Qt, библиотекам Qt, и системам препроцессинга и сборки всего этого барахла. Тем, кто пишет на Православной Сишечке™, Go, D, Pascal, Python, Ruby, Java, Kotlin, Lua, Perl, и прочая — оно нафиг не сдалось.

Посмотрим, какие же форматы поддерживает упомянутый QImage из состава Qt, даже с внешними плагинами из поставки. Раз, два, и обчёлся. А за остальными необходимо лезть в сторонние библиотеки, например в kImageFormats от KDE.

А теперь посмотрим, сколько форматов поддерживают нормальные, специализированные просмотрщики изображений — например, IrfanView, xnView, ACDSee, Geeqie, KSquirrel :D и так далее, множество их.

anonymous
()
Ответ на: комментарий от anonymous

жаль что ООП не знаете и С++ не владеете, Автор «[i]знал ООП и владел C++[/i]» двенадцать лет тому назад, когда пилил KSquirrel. Наверное, с тех пор чего–то да понял.

anonymous
()

Хорошо хоть Царь с искрой и огоньком подходит к обсуждениям, интересно читать на фоне серых, унылых троллей с односложными сообщениями.

anonymous
()

Если вы хотите как-то помощь проекту, то даже звёздочка (tsar) на Github будет огромной помощью.

Был бы на рАсТе – поставил бы с двух аккаунтов, а так звыняй.

Флакон

anonymous
()
Ответ на: комментарий от anonymous

Я бы с удовольствием обсудил отличия этих библиотек от sail. Что именно там лучше? Это может быть поводом для улучшения sail.

sailor
() автор топика
Ответ на: комментарий от sailor

Что именно там лучше?

Количество форматов, учтены особенности форматов (цветовые пространства).

Это может быть поводом для улучшения sail.

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

anonymous
()
Ответ на: комментарий от anonymous

Можешь не продолжать.

Всегда пожалуйста. :)

anonymous
()
Ответ на: комментарий от anonymous

Количество форматов

Количество форматов в iio равно трём и расширяться не будет, т.к. это не библиотека общего назначения для декодирования. Количество форматов во freeimage больше, но это пока. Автор никогда не ставил своей целью сделать freeimage более generic. Ksquirrel-libs так или иначе поддерживали 60 форматов. Думаю этого вполне хватит для целей библиотеки общего назначения 😁 Многие из них будут портированы в sail с исправлениями неудачных идей, которые там были

учтены особенности форматов

Что это значит? Я хорошо знаком с freeimage с 2003 года.

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

Знаешь, я ожидал большего, чем цитирование Гугла 😉 С freeimage я знаком с 2003 года. Я могу много чего о нем сказать, но это не тред ненависти к fi.

sailor
() автор топика
Ответ на: комментарий от sailor

Количество форматов в iio равно трём и расширяться не будет, т.к. это не библиотека общего назначения для декодирования.

На IPOL Journal думают по другому. Хмм. С чего бы это?

Что это значит? Я хорошо знаком с freeimage

BW, gray, RGB, RGB, YUV.

я ожидал большего

Ну ты чудак! :)

anonymous
()
Ответ на: комментарий от anonymous

BW, gray, RGB, RGB, YUV.

Что это значит? FI отдаёт либо BGR, либо RGB пиксели в зависимости от флага компиляции. SAIL, например, помимо RGB/RGBA, может отдавать и исходные пиксели. Так что ты можешь работать с YUV (или чем угодно) напрямую. FreeImage такого не умеет.

Открой например YCCK JPEG в Qt deep-diver демке из SAIL, и при открытии файла выбери вывод SOURCE пикселей. Изображение будет ожидаемо distorted, но для целей демонстрации как работает получение исходных пикселей вполне подойдёт.

sailor
() автор топика
Ответ на: комментарий от sailor

FI отдаёт либо BGR, либо RGB

Уверен? Только? У нас с тобой разные FI? Возефак? :)

anonymous
()
Ответ на: комментарий от anonymous

В SAIL используется самая лучшая парадигма ООП.

sailor
() автор топика
Ответ на: комментарий от Harald

почему сборка не на автотулзах, а на богомерзком cmake?

говорят, мертвецов не стоит трогать ;) AutoTools разве не «всё»? CMake не идеален, это правда. Но по сравнению autotools - просто великолепен как Аполлон :)

sailor
() автор топика
Ответ на: комментарий от anonymous

На IPOL Journal думают по другому. Хмм. С чего бы это?

Более того - принцип использования динамически загружаемых кодеков даёт невероятную мощь:

  • грузятся только те кодеки, которые ты реально используешь. FreeImage и другие библиотеки грузят сразу все имеющиеся кодеки со всеми зависимостями. Речь идёт о мегабайтах. Неважно, что ты хочешь открывать только JPEG-и. Монолитный принцип грузит сразу всё и много
  • кодеки можно удалять и добавлять не трогая клиентскую библиотеку вообще
  • кодеки можно писать на любом языке, включая Rust ;) Главное обеспечить С интерфейс
sailor
() автор топика
Ответ на: комментарий от sailor

принцип использования динамически загружаемых кодеков даёт невероятную мощь

«- Мужчина! Проснитесь! Вы обосрались!» «- А я и не спал.»

Где ты МОЩЬ то увидел, чудик? Кроме грабель нихрена не наблюдается.

anonymous
()
Ответ на: комментарий от sailor

Более того - принцип использования динамически загружаемых кодеков даёт невероятную мощь

Даю подсказку: imlib. Интересно когда это поделие окончательно сдохнет.

anonymous
()

а почему бы не использовать libjpeg или libpng напрямую, зачем лишние прокладки-обёртки

Harald ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.