GD никак. Насколько я помню выхватывает первый кадр.
IMagik отлично может работать. Только придется ручками каждый кадр выгребать и создавать мнослойную картинку во внутреннем формате.
Когда работаешь с GD надо бояться больше не того, как загрузится проц (хотя и этого тоже), а насколько много сожрется памяти. У меня на собственом опыте было такое, что картинка 1280 на 1024 не могла обработаться, потому что gd её тупо не мог впихуть в имеющийся выделенный объем. С Imagick-ом кстати таких проблемм меньше.
Вот тут калькулятор подсказывает 1280*1024*3=3932160, т.е. почти четыре Мб оперативки.
Если лимит 4 Мб (встречается даже на платных хостингах), то куда-ж денешься-то.
Очень интересно как Imagick отработает в такой ситуации.
3. CAPТCHA (просто нужно взять совершенно е**нутый шрифт)
этим ты капчу не сделаешь :), для капчи нужно использовать одновременно несколько шрифтов, смещать и менять угол, каждого символа… вот тогда и будет самая настоящая капча :)… а и да шумы создавать в бекграунде…
кроме этого капча должа сама генерится из выбранных букв (abcdefghijkmnpqrstuvwxyz) и цифр (0-9) о — ненадо брать так как он практически не отличается от нуля… и l тоже, так как похож на большую i.
Модифицируй класс для капчи и будет тибе счастие :)
Спасибо за разъяснения, но я знаю как делается капча.
Таким способом капчу вполне сделаешь, не сверхнадежную конечно, но вполне достаточную что бы распознать её было очень сложно. Переменный шрифт надписи + рандомное смещение + поворот на рандомный угол + переменный цвет + полупрозрачность на «сложном» фоне = вполне надежная капча.
Что то я вообще не понимаю, с каких пор использование GD и написание простого скрипта для работы с ним считается чем то магическим? В нете полно уроков и готовых классов для тех кто не шарит…
А как решается проблема с русскими буквами? Потому как после некоторых экспериментов выяснил, что они печатаются кракозяблями (уж не знаю почему на картинке в примере у автора все нормально в этом плане)… хотя шрифт был русский.
Хм, сожет с кодировкой что-то не то? Возможно вы пытайтесь сделать в вин-1251. Попробуйте преобразовать вывод в utf-8 с помощью mb_convert_encoding для строк, которые выводите.
При установке цвета с помощью imagecolorallocate значения rgb должны быть 1-256. А 0 она воспинимает как отсутствие цвета. Т.е. при тестировании обнаружилось, что при установке #000000 надпись на белом фоне не выводится. Слал разбираться… А дамп забыл убрать.
При создании картинки из файла, лучше пользоваться функцией imagecreatefromstring, а не imagecreatefromjpeg и иже с ней. Будет более универсально и надежно. Потому что никто не застрахует от того, что в файле с расширением jpg на самом деле будет лежать gif картинка. И при таком раскладе функция imagecreatefromjpeg будет выдавать ошибки, так как она рассчитывает на jpeg, а ей подсовывают gif.
Я думаю в данном случае несколько сотых секунд погоды не сделают. Сам по себе процесс наложения текста довольно тяжеловесен и лимитирующим звеном по скорости тут будет он :)
Разбивает на части. Если строка не поместилась в область, обрезает её. С длинными словами происходит тоже самое — слова длинее 24 символов разбиваются на составляющие.
Пишем на картинках