The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Доступна библиотека декодирования изображений SAIL

14.07.2020 18:01

Под лицензией MIT опубликована кросс-платформенная библиотека декодирования изображений SAIL. SAIL - это переписанный на С ребрендинг кодеков из давно не поддерживаемой программы просмотра изображений KSquirrel, но с наличием высокоуровнего абстрактного API и многочисленными улучшениями. Целевая аудитория: просмотрщики изображений, разработка игр, загрузка изображений в память для иных целей. Библиотека находится в стадии разработки, но уже пригодна для использования. Бинарная совместимость и совместимость исходного кода на данном этапе разработки не гарантируется.

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

  • Простая, компактная и быстрая библиотека, написанная на С без сторонних зависимостей (кроме кодеков);
  • Простой, понятный и в тоже время мощный API для всех нужд;
  • Биндинги к C++;
  • Форматы изображений поддерживаются динамически загружаемыми кодеками;
  • Чтение (и запись) изображений из файла, памяти или даже своего собственного источника данных;
  • Определение типа изображения по расширению файла, или по магическому числу;
  • Поддерживаемые на данный момент форматы: APNG (чтение, только на Windows), JPEG (чтение, запись) PNG (чтение, запись). Работа по добавлению новых форматов ведётся. KSquirrel-libs так или иначе поддерживал около 60 форматов, наиболее популярные форматы стоят в очереди первыми;
  • Операции чтения всегда могут выдавать пиксели в формате RGB и RGBA;
  • Некоторые кодеки могут выдавать пиксели в ещё большем списке форматов;
  • Большинство кодеков умеют выдавать также и исходные (SOURCE) пиксели. Это пригодится, например, тем, кто захочет получить полную информацию из CMYK- или YCCK-изображений;
  • Чтение и запись ICC профилей;
  • Примеры на C, Qt, SDL;
  • Поддерживаемые платформы: Windows (installer), macOS (brew) и Linux (Debian).

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

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

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


   struct sail_context *context;

   SAIL_TRY(sail_init(&context));

   struct sail_image *image;
   unsigned char *image_pixels;

   SAIL_TRY(sail_read(path,
                   context,
                   &image,
                   (void **)&image_pixels));

   /*
    * Здесь обработайте полученные пиксели.
    * Для этого используйте image->width, image->height, image->bytes_per_line,
    * и image->pixel_format.
    */

   /* Очистка */
   free(image_pixels);
   sail_destroy_image(image);

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

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

Прямые конкуренты из этой же области:

  • FreeImage
  • DevIL
  • SDL_Image
  • WIC
  • imlib2
  • Boost.GIL
  • gdk-pixbuf

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

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


  1. Главная ссылка к новости (https://github.com/smoked-herr...)
  2. OpenNews: Прототип интерфейса для переноса изображений из реального мира в графический редактор
  3. OpenNews: В рамках проекта Drawing развивается новый редактор изображений для Linux
  4. OpenNews: Уязвимость в библиотеке SDL, приводящая к выполнению кода при обработке изображений
  5. OpenNews: Компания Intel опубликовала библиотеку для шумоподавления и фильтрации изображений
  6. OpenNews: Релиз фреймворка для обработки изображений G'MIC 2.2
Автор новости: Аноним
Тип: Программы
Короткая ссылка: https://opennet.ru/53354-sail
Ключевые слова: sail, image
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (77) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, Аноним (2), 21:26, 14/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    Единственная нормальная новость, от которой веет здоровым юниксом.
     
     
  • 2.5, Аноним (5), 21:59, 14/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А кто сказал, что юникс-подход здоров?
     
     
  • 3.6, Аноним (6), 22:01, 14/07/2020 [^] [^^] [^^^] [ответить]  
  • +16 +/
    Практика показала, что отход от него порождает раздутые переусложнённые решения.
     
     
  • 4.31, Аноним (31), 03:15, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    чья практика? кто сказал, что она что-то показали или показала то, о чем ты говоришь? пока что в твоих словака очередной бурчание ретрограда-хейтера, не более
     
     
  • 5.41, Аноним (41), 09:33, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Моя личная и тех анонимов, которые согласились, поставив плюс.
     
  • 5.52, Аноним (-), 16:11, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Практика Дельфи и Виндовс экосистем.
     
  • 3.62, Аноним (-), 19:14, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А кто сказал, что юникс-подход здоров?

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

     

  • 1.4, Аноним (-), 21:42, 14/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > Поддерживаемые на данный момент форматы: APNG (чтение, только на Windows)

    Что?

     
     
  • 2.21, Аноним (21), 23:20, 14/07/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Animated PNG. SAIL (ранее - ksquirrel-libs) была одна из первых библиотек в мире поддержавших его. Поддержка на иных платформах затруднительна, т.к. требует патчить libpng.
     
     
  • 3.38, анонимм (?), 06:50, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Т.е. оно ещё один биндинг к libpng. Я уж понадеялся что здесь будет хоть одна монолитная библиотека. С линуксом-то норм всё, а вот под винду когда собираешь проект с sdl_image - там ещё с десяток dll тащить
     
     
  • 4.43, Аноним (21), 10:33, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Под виндой библиотеки типа libpng вкомпилируются статически прямо в кодеки. Посмотри инсталлер на странице релизов.
     
     
  • 5.64, Аноним (-), 19:15, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Под виндой библиотеки типа libpng вкомпилируются статически прямо в кодеки. Посмотри инсталлер
    > на странице релизов.

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

     

  • 1.7, Crazy Alex (ok), 22:03, 14/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Декодер изображений общего назначения в 2020-м году без поддердки цветоаых профилей - это бред сивой кобылы
     
     
  • 2.9, НяшМяш (ok), 22:14, 14/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >  Функции управления цветом (применение ICC профилей и т.д.)

    А если чуть внимательнее читать?

    upd. Извиняюсь за наезд, я сам косоглазый, это как раз то что НЕ поддерживается )

     
  • 2.13, Аноним (13), 22:19, 14/07/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вот да, это это уже вишенка на торте, если изначально было не ясно.
     
  • 2.15, Аноним (13), 22:33, 14/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    С другой стороны, этим должен заниматься http://www.littlecms.com/ -- альтернатив у нас нет. Т.е. притащи в код стрёмных легаси либ, сам позаботься о корректном отображении написав кода больше чем в тех либах было, сам реализуй поддержку форматов (уже проходили с pil, но сегодня то вроде 2020 на дворе). Не похоже на включил в проект и теперь работаешь с любыми изображениями. Поспешили-с.
     
     
  • 3.29, Crazy Alex (ok), 02:24, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Волбще-то есть argyll как минимум. Который, насколько я помню, поприличнее, кстати
     
     
  • 4.30, Аноним (13), 02:48, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Волбще-то есть argyll как минимум. Который, насколько я помню, поприличнее, кстати

    Не используется ни одной программой. Ну такое. К тому же оно в 50 раз монструознее (btw что это за дичь у него в зависимостях http://freetype.sourceforge.net/jam/index.html *?). Но спасибо за инфу. Мне не понравился сайт (от этот http://www.argyllcms.com/).

     
     
  • 5.35, Crazy Alex (ok), 06:29, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну да, он монстр потому что умеет всё, что связано с цветом, а не просто профиль применить. И AGPL  к тому же (что с моей точки зрения только плюс). Используется - в основном в составе DisplayCAL, которую многие считают лучшим софтом для калибровки и профилирования. В чисто рисовайках - это да, не прижился.

    Ещё darktable что-то своё для профилей применяет, насколько я помню.

     
  • 5.36, Crazy Alex (ok), 06:32, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Претензий к билдтулу не понял - сейчас их один чёрт зоопарк. К сайту - и подавно, совершенно обычный простой текстовый сайт, без модной фигни, только информация. ну да ладно, это вкусовщина уже
     
     
  • 6.65, Аноним (-), 19:16, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Претензий к билдтулу не понял - сейчас их один чёрт зоопарк.

    Не, вот знаете что! Тут вот хорошая аккуратная либа - и не надо ее скатывать в гомно. А зоопарк пусть у гугловых вебмакак будет, им по статусу положено.

     
  • 2.17, Аноним (21), 23:07, 14/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >Декодер изображений общего назначения в 2020-м году без поддердки цветоаых профилей - это бред сивой кобылы

    Цветовые профили вынимаются и предоставляются клиентскому приложению. В задачи декодера не входит т.н. "применение" цветовых профилей. Если необходимо, приложение с помощью lcms "применит" полученный профиль.

     
     
  • 3.28, Crazy Alex (ok), 02:22, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Пожалуй согласен
     

  • 1.8, Иваня (?), 22:07, 14/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Как создать свой формат изображений, что почитать, посмотреть?🤔 Подскажите please🥺
     
     
  • 2.16, Сишник (?), 22:50, 14/07/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    http://www.compression.ru/compression.ru/book/
     
     
  • 3.33, neAnonim (?), 05:49, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    а поновее есть? хочу почитать про x264,x265, vp1 итд
     
     
  • 4.57, Аноним (57), 17:57, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так берите спеки, и вперёд. Там по 500 и более страниц, хватит надолго.
     
  • 2.66, Аноним (-), 19:18, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Как создать свой формат изображений, что почитать, посмотреть?

    Форумы по сжатию. Например encode.su - соотв. топики. Там есть пара довольно любопытных кодеков/идей, но до ума не доведены.

     

  • 1.10, Аноним (10), 22:16, 14/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Может кто в курсе, оно хоть чем-то лучше stb_image для загрузки PNG/JPEG/BMP? Бегло посмотрел пример C/SDL - API выглядит странноватым и избыточным, как по мне. Так же, увидел пример Qt/C++, зачем оно там, когда все уже есть в Qt? Оно умеет что-то, чего не умеет Qt?
     
     
  • 2.19, Аноним (21), 23:10, 14/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >API выглядит странноватым и избыточным

    напиши почему именно, это можно обсудить.

     
     
  • 3.39, Аноним (39), 07:27, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Это все мое субъективное мнение, возможно, все нормально и хорошо, но Вот это ... большой текст свёрнут, показать
     
     
  • 4.42, Аноним (21), 10:04, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Дельные мысли, спасибо
     
  • 4.46, InuYasha (??), 11:34, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >>Так же мне это говорит о том, что есть некий внутренний код ошибок.

    И ничего страшного в этом нет. Для каждой библятеки заводи отдельый cpp-файл, там обрабатывай ошибки, а весь проект делай по-своему. Никто не заставляет же sail_error_t использовать повсюду.

    Обычные сишные имена. Я бы назвал как-нить типа g_pszImagePixels, но это уже пахнет плюсами )

     
     
  • 5.54, Аноним (10), 16:25, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А я сказал что это страшно или плохо Мне не нравится этот подход Если можно чт... большой текст свёрнут, показать
     
     
  • 6.56, Аноним (21), 17:39, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Я согласен со всем То что можно сделать быстро, так это - опциональный context... большой текст свёрнут, показать
     
     
  • 7.73, Аноним (-), 05:05, 16/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > - свой аллокатор - тоже очевидно что рано или поздно всплывёт опять

    Именно свой аллокатор? А не возможность дать юзеру оверрайднуть на свой, типа как в https://github.com/Dridi/cashpack/blob/master/lib/hpack.c сделано? В идеале иногда еще хочется либу совсем без динамической аллокации, но это специфичная хотелка и не для такой либы походу.

     
     
  • 8.75, Аноним (75), 11:40, 16/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да, это и имел ввиду Свой аллокатор с точки зрения пользователя библиотеки ... текст свёрнут, показать
     
     
  • 9.80, Аноним (80), 22:11, 16/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вон там выше пример, прямо в том файле ... текст свёрнут, показать
     
  • 6.58, Аноним (75), 18:57, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Покажи пожалуйста если есть пример как ты используешь собственный аллокатор совместно с какой-то либоц. Можно в псевдокоде
     
     
  • 7.72, Аноним (39), 02:17, 16/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Эх… Мне откровенно лень делать полноценные примеры.

    Просто скажу, как могло бы быть на мой взгляд.
    Для С:

    Некий внутренний макрос к alloc/free/realloc (https://github.com/nothings/stb/blob/b42009b3b9d4ca35bc703f5310eedc74f584be58/)

    Структура со стабами для пользовательских alloc/free/realloc. Судя по примерам, есть что-то подобное для seek/tell/flush/sync и т.д.

    У себя я использую что-то вроде:
    #define PUSH_TYPE(mem_arena, type, ...) (type *)push_mem__(mem_arena, sizeof(type), ## __VA_ARGS__)

    #define PUSH_ARRAY(mem_arena, size, type, ...) (type *) push_mem__(mem_arena, (size)*sizeof(type), ## __VA_ARGS__)
    И т.д.

    Для C++ мне нравится подход eastl (https://github.com/electronicarts/EASTL).


     
     
  • 8.78, Аноним (75), 18:00, 16/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    С С конечно возникает проблема, т к почти все объекты вызывают С функции То ... текст свёрнут, показать
     
     
  • 9.81, Аноним (81), 12:08, 17/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Большинство известных мне реализаций new в С вызывают внутри себя malloc GCC ... большой текст свёрнут, показать
     
  • 5.76, Аноним (39), 12:31, 16/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > g_pszImagePixels ... уже пахнет плюсами

    Это... (g_)Global (p)Pointer to (s)String with (z)Zero terminator ImagePixels? Это пахнет венгерской нотацией, win api и кокой-то дичью...  

     

  • 1.11, Аноним (13), 22:16, 14/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Jpeg, png (windows-only). Не вкатился что-то. Сегодня нужны webp, heif, и немного png -- жопегом никого не удивить. Тем более в играх жопеги совершенно не упали.

    >KSquirrel

    Выглядит как рипоф faststone image viewer. Тот немного специфичный. Он на паскале, быстрый и удобный, не пестрит багами. Жаль только не поддерживает современные форматы. Но сегодня у нас есть относительно приличный gwenview (код не очень хороший, правда), и нужды в таких стрёмных просмотрщиках нет. Алсо, gwenview что-то тормозноват, если сравнивать с тем же fsiv. Но это видимо претензия тоже к кутям, как и ограниченное число поддерживаемых форматов (libraw и ещё что-то там конечно вкорячены сбоку, грязно, но остальное от кутей зависит).

     
     
  • 2.18, Аноним (21), 23:09, 14/07/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Сегодня нужны webp, heif, и немного png -- жопегом никого не удивить. Тем более в играх жопеги совершенно не упали.

    на всё нужно время, всё есть в планах. HEIF насколько я помню покрывается патентами, и его использование без роялти невозможно.

     
     
  • 3.23, Аноним (13), 23:23, 14/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Но отсутствие tga совершенно непростительно, это основной универсальный формат. И при этом простой (в отличие от tiff и производных). Heif емнип открытый формат, это пакуемые в него данные могут быть продуктом "платного" кодека. А могут быть и роялти фри (нет такой вещи как непокрытые патентами кодеки: есть современные, есть устаревшие, и есть бесплатные для использования на определённых основаниях).
     
     
  • 4.24, Аноним (21), 23:26, 14/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >Но отсутствие tga совершенно непростительно

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

     
  • 2.22, Аноним (21), 23:22, 14/07/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Жаль только не поддерживает современные форматы

    Именно современные форматы и стоят в приоритете. WEBP, AVIF, JPEG-XR, возможно BGP и FLIF.

     
     
  • 3.37, Аноним (37), 06:40, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Хочу чтобы оно могло BMP.
     
     
  • 4.44, Аноним (21), 10:35, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Без вопросов, все популярные форматы будут сделаны. Tiff, bmp, gif, tga и т.п.
     
     
  • 5.47, InuYasha (??), 11:45, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    spr, wad :)
     
     
  • 6.61, Аноним (-), 19:13, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Wad это вообще контейнер, а не формат.
     
  • 6.63, Аноним (13), 19:14, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Наверное dds кроме шуток обязательно должен быть, а если ориентироваться на мультиплатформу, то и мобильные варианты. Но это всё немного вторично. А вот jpg only это проблема. Если мне нужна сеть, я беру curl и openssl. Если мне нужны картиночки, я беру костыли либо подгоняю требования под результат. Всё-таки удобный универсальный интерфейс взаимодействия с графическими файлами должен существовать, а его нет.
     
     
  • 7.67, Аноним (-), 19:20, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Всё-таки удобный универсальный интерфейс взаимодействия с графическими
    > файлами должен существовать, а его нет.

    В libsdl слегка есть, но... но дальше BMP оно на любителя.

     

  • 1.14, Аноним (14), 22:30, 14/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Поделка-самоделка. Как будто мало развитых и проверенных временем библиотек такого толка.
     
     
  • 2.20, Аноним (21), 23:18, 14/07/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Строго говоря, возраст SAIL - 17 лет. Просто она переживает ребрендинг.
     
  • 2.48, user (??), 12:30, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так в том то и проблема, что развитых. Везде добавлены рисование, обработка, шрифты и прочие лишние зависимости, а я хочу просто ввод/вывод.
     

  • 1.25, Аноним (25), 23:32, 14/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    кто то действительно использует сабж (вместо тех же указанных "прямых конкурентов"), или автор новости == автор проекта?
     
     
  • 2.26, Аноним (26), 23:49, 14/07/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    автор
     

  • 1.27, Аноним (27), 00:40, 15/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кому надо просто грузить картинки для OpenGL - есть великолепная libSOIL.
     
  • 1.32, Аноним (32), 05:23, 15/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Заходим в "src/sail-plugins/src/jpeg/jpeg.c"
    Видим: #include <jpeglib.h>

    Заходим в "src/sail-plugins/src/png/png.c"
    Видим: #include <png.h>

    > Простая, компактная и быстрая библиотека, написанная на С без сторонних зависимостей (кроме кодеков);

    Вот это уточнение "кроме кодеков" - полностью ломает всю якобы "независимость", кому она нужна без кодеков?
    Как насчёт независимости приложения от вот таких "библиотек", не лучше ли читать изображения напрямую через libjpeg и libpng?
    Это функция что влезет в один экран, примеры легко гуглятся.

    А кому нужно много возможностей - можно использовать OpenCV.

     
     
  • 2.45, Аноним (21), 10:40, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Можно использовать libjpeg и напрямую, если нужно грузить исключительно жипеги.

    Давай посмотрим с другой стороны. Размер клиентской библиотеки sail под windows - порядка 150 Kb. Плюс 500 Kb на один кодек jpeg, остальные можно просто удалить.

    Получаем оверхед в 150 Kb размера, и микроскопический api из пяти строк конкретно для этой задачи.

    Неплохо, я считаю. Какие есть мысли?

     
     
  • 3.49, Аноним (32), 12:42, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Какие мысли? Я считаю что плохо. Библиотека libjpeg-6b занимает 150кб. А только для чтения будет еще меньше. Сам когда-то уместил в 10кб бинарного кода, выбросив лишний функционал (и то даже поддержку прогрессивных JPEG оставил).
     
  • 3.50, Аноним (32), 13:09, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Для чтения PNG же есть lodepng и libspng без зависимостей от zlib, но тут именно libpng, что будет толще.
     
     
  • 4.51, Аноним (21), 13:35, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Здесь важно соблюсти баланс. Sail - библиотека общего назначения, но стремящаяся к минимализму. Можно конечно использовать libspng, но тут пострадает скорость в угоду размеру как мне кажется. Zlib, например, можно скомпилировать с amd64 инструкциями, что даст прирост скорости декодирования.
     
     
  • 5.59, Аноним (-), 19:07, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > можно скомпилировать с amd64 инструкциями, что даст прирост скорости декодирования.

    Или не даст. Если алгоритм правильный, как с LZ4, то там никаких специальных инструкций даром не надо, оно в память упирается. И для zlib, кстати, есть здорово ускоренная реализация. На zlib просто все подзабили - он работает и ладно. Да и смысл его улучшать? Кто хотел именно улучшений - накодили zstd, он жмет лучше и декодируется быстрее, и это на уровне алгоритмов сразу :D

     

  • 1.34, Анонолекс (?), 06:02, 15/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Годно, пусть будет.
     
  • 1.40, Аноним (40), 08:54, 15/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Прямые конкуренты из этой же области

    Интересно почему ImageMagick (MagickCore, MagickWand и Magick++) не попала в список?

     
     
  • 2.74, Аноним (74), 10:36, 16/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что она тормозная и глючная блотварь с кривым API?
     
     
  • 3.79, Аноним (13), 21:42, 16/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, скорее потому, что im не отдельная либа, а "вещь в себе". А по поводу кривого апи… В любом случае, другого софта, подобного im, нет. Наверное, ни одна программа, кроме этой, не сможет тебе даже корректно ресайзнуть изображение. Там надо ресайзить через колорспейс luv (да, я сравнивал с lab, luv много корректней), чтобы не запороть файл. Особенно бросается в глаза, когда ты ресайзишь 600dpi в ~90dpi. Ну и потом, distort resize тоже выглядит значительно лучше топорного в лоб ресайза. Насчёт глюков не скажу, насчёт тормозов, я бы хотел чтобы cuda или opencl что-нибудь ускоряли там, но они ничего не ускоряют и только добавляют артефактов. Так что уж как есть, альтернатив просто не существует в природе (да, я в курсе про форки, они ни в какое сравнение не идут).
     

  • 1.53, Аноним (-), 16:14, 15/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > APNG (чтение, только на Windows

    Как они этого добились? Чтение apng на других платформах чем-то принципиально отличается? Wtf?!

     
     
  • 2.55, Аноним (21), 17:24, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Чтение Animated PNG требует патченой версии libpng. Это ловушка этого формата. Официальная libpng не может поддерживать APNG, т.к. APNG - это расширение, а libpng - reference PNG implementation. Поэтому поддержка APNG делается только через распространение своей собственной патченой libpng. Распространение своей собственной libpng выглядит натурально только на Windows.
     
     
  • 3.60, Аноним (-), 19:12, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Может тогда послать libpng курить бамбук? Достаточно дурацкая либа. Насколько я вижу, половина прог для работы с apng вообще libpng не пользуются. Не мешает им работать с форматом...
     
  • 3.68, Аноним (13), 19:42, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Это всё замечательно, но у меня в системе libpng с поддержкой apng (как и во многих дистрибутивах, я думаю), а анимации работают только в браузере. Браузер использует всё ту же системную libpng с apng, это значит, проблема исключительно в криво написанном софте,
     
     
  • 4.69, Аноним (21), 20:14, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >это значит, проблема исключительно в криво написанном софте,

    совершенно верно.

     

  • 1.70, мяя (?), 20:42, 15/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Есть такая штука как libvips
     
     
  • 2.71, Аноним (21), 21:31, 15/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >It has around 300 operations covering arithmetic, histograms, convolution, morphological operations, frequency filtering, colour, resampling, statistics and others

    ЭЭ?

     

  • 1.77, Аноним (21), 16:30, 16/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Неоценимой помощью проекту будет звёздочка (star) на Github. Спасибо за отзывы и предложения, друзья.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру