Комментарии 41
что ж вы замеры потребления памяти не сделали? у GD очень большие аппетиты при обработке больших изображений, порой настолько, что пользоваться им нет возможности. Так что скорость выполнения — это хорошо, но еще есть и памяти и умение не выбрасывать ошибку, если память кончается, а продолжать работать, складывая результаты в файл, как умеет imagick.
Ещё стоило сравнить размеры получаемых файлов.
Хм ну в нашем случае памяти не так жалко. Так как память не такая уж дорогая, и 4 Гб которые есть у сервера не были проблемой ни в одном случае. GD действительно самый прожорливый. Насчет сравнивания размера файлов то здесь больше зависит от степени сжатия (если говорить о JPEG) а не от самой библиотеки, так как алгоритм повсюду похож.
Вы упускаете из виду тот момент, что вы тестировали только на себе. Если это будет частью какого-то сервиса и пользоваться этим будут много людей сразу, то любовь библиотек к процессору и памяти не менее важна, чем быстродействие. Я сам недавно напоролся: применил PHPExcel для обработки, сам протестировал — нормально, всё очень быстро работает. А вот как люди пользоваться начали, 5-10 одновременных обращений к PHPExcel заставляли сервер так задуматься, что иногда в течение 5 минут все остальные обратившиеся получали таймаут.
>Очевидно что выглядеть они будут идентически предидущим.
Если придираться, то ГД сильнее крыло обрезал снизу.
>GD почему-то сделала цвет текста темней и гораздо хуже сработал антиалиасинг
по-моему три одинаковые картинки О_О
Если придираться, то ГД сильнее крыло обрезал снизу.
>GD почему-то сделала цвет текста темней и гораздо хуже сработал антиалиасинг
по-моему три одинаковые картинки О_О
У кого ест много памяти, попробуйте php 5.5. В моем случае (конвертация с предобработками из svg) потребление памяти снизилось с 8.8 МБ (php 5.3) до 3.5 МБ (php 5.5). Imagick, memory_get_peak_info()
Есть еще imagine. Куча функций, поддерживает те же либы. Правда у меня последний раз, когда я ее использовал писанина текстом на картинке не заработала (для GD).
она хороша, особенно нравятся еффекты =)
Если бы в пиксе не было бы своей библиотеки то использовали бы имеджин.
Если бы в пиксе не было бы своей библиотеки то использовали бы имеджин.
Что за библиотека можно поподробней?
В статье есть линк. Фреймворк phpixie.com
Сравнение сделано из рук вон плохо. Вы сохранили картинки в jpg с параметрами по-умолчанию и ни слова не сказав ни о размере картинки, ни о времени сжатия, принялись сравнивать качество. И так известно, что jpeg можно сохранить с разным качеством. И так известно, что у разных библиотек настройки по-умолчанию разные. Нужно подбирать параметры так, чтобы размер получился примерно одинаковый, и тогда смотреть качество и скорость.
Потом, какой алгоритм интерполяции вы использовали для изменения размеров? Качество и время работы в первую очередь зависит именно от него, от выбора библиотеки во вторую. Сравнивать библиотеки нужно было на одном алгоритме.
Не зачет.
Потом, какой алгоритм интерполяции вы использовали для изменения размеров? Качество и время работы в первую очередь зависит именно от него, от выбора библиотеки во вторую. Сравнивать библиотеки нужно было на одном алгоритме.
Не зачет.
Посмотрел в пиксю, по дефолту для JPEG качество 95% стоит
Во-первых, не 95, а 90.
Во-вторых 90 чего? Нет единой шкалы качества jpeg, у каждой библиотеки она разная (в фотошопе вообще от 1 до 12, например). Единственное мирило — сравнение качества при примерно одинаковом размере.
Во-вторых 90 чего? Нет единой шкалы качества jpeg, у каждой библиотеки она разная (в фотошопе вообще от 1 до 12, например). Единственное мирило — сравнение качества при примерно одинаковом размере.
В Imagemagick i Gmagick алгоритм LANCZOS, в GD тоже. Но в любом случае бенчмарк показывает то что главное: скорость и Gmagick явно впереди.
> В Imagemagick i Gmagick алгоритм LANCZOS, в GD тоже.
В GD далеко не LANCZOS, потому что даже не свертки. Тут все написано: habrahabr.ru/post/243285/
В GD далеко не LANCZOS, потому что даже не свертки. Тут все написано: habrahabr.ru/post/243285/
никогда раньше не обращал внимания на Gmagick, оказалось занятная вещь, упор на скорость — обгоняет imagick во всём на многоядерных системах заметно лучше (тесты) + имеет вместо нескольких команд (
convert, mogrify) один бинарник gm, которому можно задавать команду, например gm convert. Буду пробовать в следующем проекте.НЛО прилетело и опубликовало эту надпись здесь
Написание текста
Не очень показательный пример, надо было сравнить вывод текста маленького размера — gd его мягко говоря хреново выводит («багу» хз сколько лет, при желании можно даже найти интересный патч)
Какие опции использовались в ImageMagick для создания превьюшек?
В ImageMagick есть очень большой диапазон возможностей создавать превьюшки, которые очень сильно влияют как на выходной размер файла так и на скорость выполнения. Например по скорости работы сильно отличается адаптивный ресайз vs обычный ресайз.
Каким образом был собран Imagick?
Указали ли при сборке возможность для работы в несколько потоков?
Насколько я понял тест проводился при создании одной превьюшки в одно и тоже время?
В проекте не предполагается ситуации когда в один и тот же момент будет создаваться несколько превьюшек?
В ImageMagick есть очень большой диапазон возможностей создавать превьюшки, которые очень сильно влияют как на выходной размер файла так и на скорость выполнения. Например по скорости работы сильно отличается адаптивный ресайз vs обычный ресайз.
Каким образом был собран Imagick?
Указали ли при сборке возможность для работы в несколько потоков?
Насколько я понял тест проводился при создании одной превьюшки в одно и тоже время?
В проекте не предполагается ситуации когда в один и тот же момент будет создаваться несколько превьюшек?
Спасибо за сравнение, но у PHPixie настолько неудачный маскот, что ей, мне кажется, ничего не поможет.
Почему по коду идет сохранение в JPEG, а сами картинки выложены в PNG?
В простом масштабировании у вас у GD размер картинки по вертикали на 1 пиксель больше. Отсюда и разница на глазе. Между Imagick и Gmagick разницы практически нет вообще (единицы пикселей на все изображение). Разницу лучше всего смотреть в фотошопе через режимы наложения (разница и деление).
В написании текста и создании пустого изображения у вас разное качество сжатия jpg, это же очевидно под лупой в фотошопе. Видимо в GD дефолтное качество стоит ниже всех остальных, а в Gmagick — самое высокое.
В статье не сказано как проводились тесты скорости, а глядя на куски кода — подозреваю что измерялось время исполнения всего скрипта. Очевидно что ресайз изображения это: распаковка графического формата (jpg скорее всего), сам ресайз, упаковка в формат (png/jpg). Хотелось бы видеть тесты времени только ресайза.
Алсо немаловажно я считаю провести тест на чтение формата/сохранение в формате для основных популярных форматов: jpg/png/gif
upd. так же ни слова не сказано о алгоритме интерполяции при ресайзе. Есть ведь линейная, бикубическая, а так же куча их модификаций.
В написании текста и создании пустого изображения у вас разное качество сжатия jpg, это же очевидно под лупой в фотошопе. Видимо в GD дефолтное качество стоит ниже всех остальных, а в Gmagick — самое высокое.
В статье не сказано как проводились тесты скорости, а глядя на куски кода — подозреваю что измерялось время исполнения всего скрипта. Очевидно что ресайз изображения это: распаковка графического формата (jpg скорее всего), сам ресайз, упаковка в формат (png/jpg). Хотелось бы видеть тесты времени только ресайза.
Алсо немаловажно я считаю провести тест на чтение формата/сохранение в формате для основных популярных форматов: jpg/png/gif
upd. так же ни слова не сказано о алгоритме интерполяции при ресайзе. Есть ведь линейная, бикубическая, а так же куча их модификаций.
В комментах уже упомянул что там LACZOS. Насчет шрифтов в ГД то вы не правы. Во первых эти шрифты так же выглядят и в PNG, во-вторых (тоже с комментов) сам фреймворк ставит для джпега по дефолту качество 90%
Мне кажется нужен апдейт поста в духе:
Вот шрифты, делал <спойлер «так и так»>пхп код</спойлер>, картинки получил вот такие и такие <картинка GD.png> <картинка Imagick.png> <картинка Gmagick.png>
Замеры скорости делал <спойлер «так и так»>пхп код</спойлер>, результаты ниже.
Потому что судя по первому бенчмарку — допускаю еще «ляпов». Вы сейчас утверждаете, что качество сжатия одинаковое, и шрифты так же выглядят в PNG, а вы сохраните в PNG и продемонстрируйте, ибо сейчас я вижу что у GD
Причем значительно больше, ибо вокруг стали появляться желтые пиксели
Вот шрифты, делал <спойлер «так и так»>пхп код</спойлер>, картинки получил вот такие и такие <картинка GD.png> <картинка Imagick.png> <картинка Gmagick.png>
Замеры скорости делал <спойлер «так и так»>пхп код</спойлер>, результаты ниже.
Потому что судя по первому бенчмарку — допускаю еще «ляпов». Вы сейчас утверждаете, что качество сжатия одинаковое, и шрифты так же выглядят в PNG, а вы сохраните в PNG и продемонстрируйте, ибо сейчас я вижу что у GD
больше артефактов от сжатия в jpg
Причем значительно больше, ибо вокруг стали появляться желтые пиксели
Этот PNG отличается от того GD JPG-а. Прежде всего шириной надписи, при попиксельном наложении видно что надпись на пару пикселей уже. Кроме того вы опять таки не привели код, которым была нарисована эта надпись. Как тут можно вообще говорить о том, что GD неправильно рисует текст и делает цвет темнее? Если вы делаете бенчмарк — то надо быть точным
Тот же код что и в статье, только поменялся путь сохранения
Кстати я взял пипеткой цвет из PNG от GD. Он оказался в точности 0x5B43AA, а вот попытка взять цвет от Gmagick и Imagick дает примерно 0x5b43a9, но опять же, о каком взятии цвета может идти речь, когда там jpg я не знаю
Стандарт — это всё-таки GD. Кстати, померьте ещё imlib2, если сможете скомпилировать под новые версии PHP, она на масштабировании раньше делала всех.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Бенчмарк графических библиотек для PHP