Бенчмарк графических библиотек для PHP

[matweew]

что ж вы замеры потребления памяти не сделали? у GD очень большие аппетиты при обработке больших изображений, порой настолько, что пользоваться им нет возможности. Так что скорость выполнения — это хорошо, но еще есть и памяти и умение не выбрасывать ошибку, если память кончается, а продолжать работать, складывая результаты в файл, как умеет imagick.

[RubaXa]

Ещё стоило сравнить размеры получаемых файлов.

[jigpuzzled]

Хм ну в нашем случае памяти не так жалко. Так как память не такая уж дорогая, и 4 Гб которые есть у сервера не были проблемой ни в одном случае. GD действительно самый прожорливый. Насчет сравнивания размера файлов то здесь больше зависит от степени сжатия (если говорить о JPEG) а не от самой библиотеки, так как алгоритм повсюду похож.

[danko]

Вы упускаете из виду тот момент, что вы тестировали только на себе. Если это будет частью какого-то сервиса и пользоваться этим будут много людей сразу, то любовь библиотек к процессору и памяти не менее важна, чем быстродействие. Я сам недавно напоролся: применил PHPExcel для обработки, сам протестировал — нормально, всё очень быстро работает. А вот как люди пользоваться начали, 5-10 одновременных обращений к PHPExcel заставляли сервер так задуматься, что иногда в течение 5 минут все остальные обратившиеся получали таймаут.

[Anisotropic]

>Очевидно что выглядеть они будут идентически предидущим.
Если придираться, то ГД сильнее крыло обрезал снизу.

>GD почему-то сделала цвет текста темней и гораздо хуже сработал антиалиасинг
по-моему три одинаковые картинки О_О

[gaelpa]

По-моему, не хватает «диффа» картинок для объективного сравнения.

[jigpuzzled]

Разницу видно меньше потому-что картинки немного пережал сам сервер (imgur) на который я аплоудил. Но код есть в статье так-что можете попробовать сгенерить их сами =)

[fshp]

Это всё ваш jpeg. Png+habrastorage решает эти проблемы.

[fshp]

Каюсь. Не прав.

[ilyaerin]

Нужно смотреть на мелкие детали. Например на нитки под попой феи) Там явно видна разница между GD и остальными.

[synergy]

У кого ест много памяти, попробуйте php 5.5. В моем случае (конвертация с предобработками из svg) потребление памяти снизилось с 8.8 МБ (php 5.3) до 3.5 МБ (php 5.5). Imagick, memory_get_peak_info()

[Claud]

Есть еще imagine. Куча функций, поддерживает те же либы. Правда у меня последний раз, когда я ее использовал писанина текстом на картинке не заработала (для GD).

[jigpuzzled]

она хороша, особенно нравятся еффекты =)
Если бы в пиксе не было бы своей библиотеки то использовали бы имеджин.

[Claud]

Что за библиотека можно поподробней?

[jigpuzzled]

В статье есть линк. Фреймворк phpixie.com

[Claud]

Извиняюсь, я думал это просто аналог imagine, название какое-то картиношное.

[homm]

Сравнение сделано из рук вон плохо. Вы сохранили картинки в jpg с параметрами по-умолчанию и ни слова не сказав ни о размере картинки, ни о времени сжатия, принялись сравнивать качество. И так известно, что jpeg можно сохранить с разным качеством. И так известно, что у разных библиотек настройки по-умолчанию разные. Нужно подбирать параметры так, чтобы размер получился примерно одинаковый, и тогда смотреть качество и скорость.

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

Не зачет.

[jigpuzzled]

Посмотрел в пиксю, по дефолту для JPEG качество 95% стоит

[homm]

Во-первых, не 95, а 90.

Во-вторых 90 чего? Нет единой шкалы качества jpeg, у каждой библиотеки она разная (в фотошопе вообще от 1 до 12, например). Единственное мирило — сравнение качества при примерно одинаковом размере.

[jigpuzzled]

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

Спасибо что поправили с 95, я что-то недосмотрел

[homm]

> не так качество как скорость работы
А я вот увидел, что вы именно качество сравниваете, причем по результату сжатия jpeg сравниваете качества рендеринга шрифтов, что вообще бред. Вы можете убрать это из топика.

[jigpuzzled]

В Imagemagick i Gmagick алгоритм LANCZOS, в GD тоже. Но в любом случае бенчмарк показывает то что главное: скорость и Gmagick явно впереди.

[homm]

> В Imagemagick i Gmagick алгоритм LANCZOS, в GD тоже.

В GD далеко не LANCZOS, потому что даже не свертки. Тут все написано: habrahabr.ru/post/243285/

[matweew]

никогда раньше не обращал внимания на Gmagick, оказалось занятная вещь, упор на скорость — обгоняет imagick во всём на многоядерных системах заметно лучше (тесты) + имеет вместо нескольких команд (convert, mogrify) один бинарник gm, которому можно задавать команду, например gm convert. Буду пробовать в следующем проекте.

[matweew]

вы не поняли, можно делать так gm convert, gm mogrify, mogrify montage, т.е. те же команды, только внутри одного бинарника. Я считаю, что удобнее использовать — скомандовал gm и сразу видишь список команд.

[LastDragon]

Написание текста

Не очень показательный пример, надо было сравнить вывод текста маленького размера — gd его мягко говоря хреново выводит («багу» хз сколько лет, при желании можно даже найти интересный патч)

[demimurych]

Какие опции использовались в ImageMagick для создания превьюшек?
В ImageMagick есть очень большой диапазон возможностей создавать превьюшки, которые очень сильно влияют как на выходной размер файла так и на скорость выполнения. Например по скорости работы сильно отличается адаптивный ресайз vs обычный ресайз.

Каким образом был собран Imagick?
Указали ли при сборке возможность для работы в несколько потоков?

Насколько я понял тест проводился при создании одной превьюшки в одно и тоже время?
В проекте не предполагается ситуации когда в один и тот же момент будет создаваться несколько превьюшек?

[jigpuzzled]

ресайз LANCZOS, при компиляции оставлял все по дефолту. А вот насчет возможности работы в несколько потоков то при чем тут? ведь Imagick для пхп и так только по одному обрабатывает. Если я бы генерил много превюшек нараз то делал бы не через ПХП а напрямую используя mogrify.

[ajaxtelamonid]

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

[jigpuzzled]

ну вы ж не на маскоте пишете ) зато оригинально)))

[sunnybear]

Почему по коду идет сохранение в JPEG, а сами картинки выложены в PNG?

[jigpuzzled]

Чтобы слить все картинки в одну, PNG lossless формат так что своих недостатков не вносит

[MrShoor]

В простом масштабировании у вас у GD размер картинки по вертикали на 1 пиксель больше. Отсюда и разница на глазе. Между Imagick и Gmagick разницы практически нет вообще (единицы пикселей на все изображение). Разницу лучше всего смотреть в фотошопе через режимы наложения (разница и деление).

В написании текста и создании пустого изображения у вас разное качество сжатия jpg, это же очевидно под лупой в фотошопе. Видимо в GD дефолтное качество стоит ниже всех остальных, а в Gmagick — самое высокое.

В статье не сказано как проводились тесты скорости, а глядя на куски кода — подозреваю что измерялось время исполнения всего скрипта. Очевидно что ресайз изображения это: распаковка графического формата (jpg скорее всего), сам ресайз, упаковка в формат (png/jpg). Хотелось бы видеть тесты времени только ресайза.

Алсо немаловажно я считаю провести тест на чтение формата/сохранение в формате для основных популярных форматов: jpg/png/gif

upd. так же ни слова не сказано о алгоритме интерполяции при ресайзе. Есть ведь линейная, бикубическая, а так же куча их модификаций.

[jigpuzzled]

В комментах уже упомянул что там LACZOS. Насчет шрифтов в ГД то вы не правы. Во первых эти шрифты так же выглядят и в PNG, во-вторых (тоже с комментов) сам фреймворк ставит для джпега по дефолту качество 90%

[MrShoor]

Мне кажется нужен апдейт поста в духе:
Вот шрифты, делал <спойлер «так и так»>пхп код</спойлер>, картинки получил вот такие и такие <картинка GD.png> <картинка Imagick.png> <картинка Gmagick.png>
Замеры скорости делал <спойлер «так и так»>пхп код</спойлер>, результаты ниже.

Потому что судя по первому бенчмарку — допускаю еще «ляпов». Вы сейчас утверждаете, что качество сжатия одинаковое, и шрифты так же выглядят в PNG, а вы сохраните в PNG и продемонстрируйте, ибо сейчас я вижу что у GD

больше артефактов от сжатия в jpg

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

[jigpuzzled]

Вот GD в формате PNG i.imgur.com/m1n5zh7.png
Как по мне то идентично

[MrShoor]

Этот PNG отличается от того GD JPG-а. Прежде всего шириной надписи, при попиксельном наложении видно что надпись на пару пикселей уже. Кроме того вы опять таки не привели код, которым была нарисована эта надпись. Как тут можно вообще говорить о том, что GD неправильно рисует текст и делает цвет темнее? Если вы делаете бенчмарк — то надо быть точным

[jigpuzzled]

Тот же код что и в статье, только поменялся путь сохранения

[MrShoor]

Кстати я взял пипеткой цвет из PNG от GD. Он оказался в точности 0x5B43AA, а вот попытка взять цвет от Gmagick и Imagick дает примерно 0x5b43a9, но опять же, о каком взятии цвета может идти речь, когда там jpg я не знаю

[bolk]

Стандарт — это всё-таки GD. Кстати, померьте ещё imlib2, если сможете скомпилировать под новые версии PHP, она на масштабировании раньше делала всех.