Pull to refresh

Comments 36

Полгода назад, в статье "Фотошопим на php", писал о аналогичных возможностях другой библиотеки: magickwand. Там немного лучше дела со сглаживанием.
Только с момента написания статьи iMagick стал намного стабильней, приобрел нормальный объектно ориентированный интерфейс.

Небольшой пример использования
enartemyНаверно как-то так и счетчики рисуются, да?
ну вот… тэг неправильно закрыл =(
Так и рисуются… самое полезное применение это для отрисовки информеров.
Так много чего рисуется. Или с помощью Imagick. В отдельных случаях используются и собственные библиотеки.

Кстати, никто не знает, как gd и imagick работают с анимированными gif-ами? Сам не проверял, но интересно, а проверять лень. Мож кто знает?
GD никак. Насколько я помню выхватывает первый кадр.
IMagik отлично может работать. Только придется ручками каждый кадр выгребать и создавать мнослойную картинку во внутреннем формате.
Что-то еще кром IMagikа может делать анимированные гифы?
На сколько это будет проц грузить если картинок под сотню на странице…
Когда работаешь с GD надо бояться больше не того, как загрузится проц (хотя и этого тоже), а насколько много сожрется памяти. У меня на собственом опыте было такое, что картинка 1280 на 1024 не могла обработаться, потому что gd её тупо не мог впихуть в имеющийся выделенный объем. С Imagick-ом кстати таких проблемм меньше.

А вообще — конечно надо кешировать.
Вот тут калькулятор подсказывает 1280*1024*3=3932160, т.е. почти четыре Мб оперативки.
Если лимит 4 Мб (встречается даже на платных хостингах), то куда-ж денешься-то.
Очень интересно как Imagick отработает в такой ситуации.
enartemy
3. CAPТCHA (просто нужно взять совершенно е**нутый шрифт)

этим ты капчу не сделаешь :), для капчи нужно использовать одновременно несколько шрифтов, смещать и менять угол, каждого символа… вот тогда и будет самая настоящая капча :)… а и да шумы создавать в бекграунде…
кроме этого капча должа сама генерится из выбранных букв (abcdefghijkmnpqrstuvwxyz) и цифр (0-9) о — ненадо брать так как он практически не отличается от нуля… и l тоже, так как похож на большую i.
Модифицируй класс для капчи и будет тибе счастие :)
а еще можно поверх букв кошечек и собачек нарисовать и сказать чтоб вводили тока те буквы на которых собачки:) ну или кошечки:)
Да, меня эта хрень на рапидшаре заколебала в свое время. Там капча «угадывалась» с 2-3 попытки.
Спасибо за разъяснения, но я знаю как делается капча.

Таким способом капчу вполне сделаешь, не сверхнадежную конечно, но вполне достаточную что бы распознать её было очень сложно. Переменный шрифт надписи + рандомное смещение + поворот на рандомный угол + переменный цвет + полупрозрачность на «сложном» фоне = вполне надежная капча.
Что то я вообще не понимаю, с каких пор использование GD и написание простого скрипта для работы с ним считается чем то магическим? В нете полно уроков и готовых классов для тех кто не шарит…
хабр — филиал phpclasses.org
А как решается проблема с русскими буквами? Потому как после некоторых экспериментов выяснил, что они печатаются кракозяблями (уж не знаю почему на картинке в примере у автора все нормально в этом плане)… хотя шрифт был русский.
Хм, сожет с кодировкой что-то не то? Возможно вы пытайтесь сделать в вин-1251. Попробуйте преобразовать вывод в utf-8 с помощью mb_convert_encoding для строк, которые выводите.
Ай, спасибо, дорогой!
Все получилось — как по маслу.

$text = mb_convert_encoding(«Testing...\r\n вторая строчка», 'UTF-8', 'CP-1251');
блин, не могу плючик поставить :(
Думаю, стоит убрать var_dump(array_map('hexdec', str_split(ltrim($color, '#'), 2)));
C чего бы это? Всё правильно.
Да, действительно… Отладка.

При установке цвета с помощью imagecolorallocate значения rgb должны быть 1-256. А 0 она воспинимает как отсутствие цвета. Т.е. при тестировании обнаружилось, что при установке #000000 надпись на белом фоне не выводится. Слал разбираться… А дамп забыл убрать.
При создании картинки из файла, лучше пользоваться функцией imagecreatefromstring, а не imagecreatefromjpeg и иже с ней. Будет более универсально и надежно. Потому что никто не застрахует от того, что в файле с расширением jpg на самом деле будет лежать gif картинка. И при таком раскладе функция imagecreatefromjpeg будет выдавать ошибки, так как она рассчитывает на jpeg, а ей подсовывают gif.
Возможно, надо попробывать. Но работать наверно все же подольше будет…
Я думаю в данном случае несколько сотых секунд погоды не сделают. Сам по себе процесс наложения текста довольно тяжеловесен и лимитирующим звеном по скорости тут будет он :)
Хорошая вещь.
Вопрос — а что он делает с длинными строками? Разбивает на части и перносит или обрезает?
Разбивает на части. Если строка не поместилась в область, обрезает её. С длинными словами происходит тоже самое — слова длинее 24 символов разбиваются на составляющие.
а не лучше использовать ImageMagick? он побыстрее
Не везде стоит ImageMagick.
На хостингах например только 40% ставят
Sign up to leave a comment.

Articles