Комментарии 16
Добавить бы в сравнение Pillow из соседней темы habr.com/post/301576
Да, я ждала, что в комментариях еще библиотек напредлагают. Может, кто-нибудь когда-нибудь за это и возьмется. Задача — очень несложная, студенческая :). Плюс интересно не только и не сколько загрузка-сохранение, но и фильтрация, конвертация цвета и другие операции (хотя там наверняка победит Intel IPP)
В целом, сравнение разных оберток над одинаковыми libPNG/libJPEG/libTIFF должно было показать почти одинаковый результат. Если это не так, то либо дело в накладных расходах (читай — ошибках реализации), либо в ошибках тестирования. Вам обязательно надо было попробовать напрямую замерить скорость самих этих библиотек, без оберток. Отдельно в TIF файле может быть сжатие RLE, JPEG и LZW (+ чуть более редкие варианты), поэтому libTIFF использует libJPEG и в идеальном варианте скорость открытия TIFF-JPEG должна совпасть со скоростью чистой libJPEG.
Так же замерять скорость чтения BMP файла размером 32х32 откровенно несерьезно — после прогрева кеша его чтение должно быть менее 1мс для абсолютно любой реализации и если это не так, то вы что-то делаете не так.
P.S. Я же надеюсь, вы в курсе, что кодирование в DXT1 отличается в разных реализациях в разы по качеству и скорости? Простенький кодер есть и в ImageMagik, который вы почему-то обозвали древним артефактом, хотя он развивается не в пример лучше того же DevIL. Просто, его задачей никогда не была производительность или удобство встраивания, это универсальный комбайн для всех возможных и невозможных операций с картинками. А в целом, сжатие в DXT1 может быть существенно оптимизировано и разбито на потоки, что хорошо сделали ребята из Unity в своей версии crunch.
Так же замерять скорость чтения BMP файла размером 32х32 откровенно несерьезно — после прогрева кеша его чтение должно быть менее 1мс для абсолютно любой реализации и если это не так, то вы что-то делаете не так.
P.S. Я же надеюсь, вы в курсе, что кодирование в DXT1 отличается в разных реализациях в разы по качеству и скорости? Простенький кодер есть и в ImageMagik, который вы почему-то обозвали древним артефактом, хотя он развивается не в пример лучше того же DevIL. Просто, его задачей никогда не была производительность или удобство встраивания, это универсальный комбайн для всех возможных и невозможных операций с картинками. А в целом, сжатие в DXT1 может быть существенно оптимизировано и разбито на потоки, что хорошо сделали ребята из Unity в своей версии crunch.
Это удивительно, но от вашего комментария есть польза. Я увидела, что забыла упомянуть в тексте, что Tiff по условиям-не сжатый. Спасибо!
Это удивительно, но от вашей статьи тоже есть польза — сравнение разных библиотек весьма полезно. Но все перечёркивается очень странными бенчмарками.
FreeImage считывает в память 4220 байт картинки за 5мс? Даже для 1000 итераций это нереально долго, скорость памяти исчисляется в тысячах мегабайт в секунду. Вызов jpeg_start_decompress/jpeg_read_scanlines/jpeg_finish_decompress занимает разное время в разных обертках вокруг одной библиотеки? Почему?
В конце-концов, раз речь шла о кросс-платформенности, где результаты других платформ?
FreeImage считывает в память 4220 байт картинки за 5мс? Даже для 1000 итераций это нереально долго, скорость памяти исчисляется в тысячах мегабайт в секунду. Вызов jpeg_start_decompress/jpeg_read_scanlines/jpeg_finish_decompress занимает разное время в разных обертках вокруг одной библиотеки? Почему?
В конце-концов, раз речь шла о кросс-платформенности, где результаты других платформ?
Давно уже пользуюсь github.com/nothings/stb
Интересно было бы сравнить и его. Так же кроме ImageMagiсk есть еще GraphicsMagick, чья цель как раз была оптимизация — его тоже стоит проверить.
Интересно было бы сравнить и его. Так же кроме ImageMagiсk есть еще GraphicsMagick, чья цель как раз была оптимизация — его тоже стоит проверить.
Но три последние библиотеки, зависящие от таких «монстров» как Boost и SDL, заказчики попросили оставить в запасе на крайний случай, если нужная библиотека не найдется среди первых трех.Данное утверждение касательно Boost GIL противоречит фразе из туториала:
GIL consists of header files only and does not require any libraries to link against. It does not require Boost to be built and including boost/gil.hpp will be sufficient for most projects.
А что такое 8-бит JPEG?
Очевидно — монохромный (8 бит на пиксель)
Честно говоря, я думал, там только YCbCr сжатие бывает. Есть модификация только для Y (luminance) компоненты?
Если верить Википедии, то стандарт JPEG не обязывает использовать пространство YCbCr
Да, весьма интересно. По какой-то причине не сталкивался с ним раньше — декодеры спокойно дают на выходе 24-битное изображение, не думая об оригинале. А с энкодерами я мало сталкивался по разной причине. Да и инфрмации на эту тему весьма мало.
Imagemagick пишет в такой формат, если ему принудительно это указать. Что интересно, при этом параметр quality не работает вообще, PSNR остается неизменным (51.1808 в моем случае), но это не Lossless сжатие, где-то еще есть внутренние преобразования.
P.S. В Википедии как раз ошибка, формат JFIF подразумевает и Y, и YCbCr:
Imagemagick пишет в такой формат, если ему принудительно это указать. Что интересно, при этом параметр quality не работает вообще, PSNR остается неизменным (51.1808 в моем случае), но это не Lossless сжатие, где-то еще есть внутренние преобразования.
P.S. В Википедии как раз ошибка, формат JFIF подразумевает и Y, и YCbCr:
The RGB components calculated by linear conversion from YCbCr shall not be gamma corrected (gamma = 1.0). If only one component is used, that component shall be Y.
Здорово, а как обстоят дела с векторными форматами изображений?
На самом деле под ваше описание подходит libavcodec из ffmpeg/libav. Эта библиотека умеет работать быстро со всеми известными форматами файлов, а не только с видео. Еще и аппаратное сжатие jpeg поддерживает (правда в варианте motion jpeg)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ищем быструю универсальную библиотеку для работы с графическими файлами, разбираемся с Google benchmark