Работа с графикой (GD).Как сделать быстрее??

[Шелест]

Добрый вечер,уважаемое сообщество.
Хотел бы получить Ваш совет.
Что есть: Скрипт,который создает изображение подставляя вместо пикселей подходящие по цвету картинки(Пиксель арт)
Как сделано: С помощью библиотеки GD.Сначала читаем цвет каждого пикселя "родительского" изображения в массив...сохраняем.Затем также попиксельно считываем цвета "дочерних" картинок,формируем для каждой картинки "средний" цвет..и затем сравниваем цвета пикселей "родителя" с "средними" цветами "детей" и заменяем пиксель на наиболее подходящую картинку.
Проблема: Если изображение большое (>500x500) перебор изображения попиксельно выполняется очень долго...
Как сделать метод pixelColor() или общий алгоритм быстрее.?
Cпасибо за уделенное время.

Код: https://github.com/hungry-devel/pixelArt
Пример того что получается.

 

[WMix]

а ты его сожми jpegом, уменьши и в битмап, перед парсингом ну или нареж и параллельно обработай

 

[Шелест]

а ты его сожми jpegом, уменьши и в битмап, перед парсингом ну или нареж и параллельно обработай

Спасибо,очень хороший совет!
p.s. я правильно понимаю,что потеря качества неизбежна?))

 

[WMix]

а ты ее сам не делаешь? по сути у тебя джипеговый тип (потеря качества) сжатия

 

[Шелест]

аааааа....понял.
Извините..фигню написал)

 

[Шелест]

а ты его сожми jpegом, уменьши и в битмап, перед парсингом ну или нареж и параллельно обработай

Объясните,пожалуйста,что нам даст конвертация jpg->bmp? ..нагуглил спецификацию,прочел ...но полезность пока не осознал)

UPD: еще раз перечитал...я правильно понял что это даст существенный прирост скорости обработки изображения?

 

[WMix]

прогнал немного, по идеи просто уменьшить до размера ( result_width/icons_width; result_height/icons_height ) достаточно
bmp/raw читается сразу jpg будет сконвертирован хоть ты это и не замечаешь (тыж пикселами читаешь а jpg это градиент-волна через фое в матрицу с поледующей трансформацией) ну это так крошки

 

[флоппик]

Кстати, еще можно распараллелить, порезав на меньшие секции для обработки и поклеить потом.

 

[grigori]

Можно попробовать и сравнить по скорости с http://php.net/manual/en/imagick.getimagepixelcolor.php
и с http://php.net/manual/en/class.gmagickpixel.php
Главная проблема imagick - у либы течет память, то есть процессы надо регулярно перезапускать.

 

[grigori]

вопрос - насколько сильно заморочиться,
можно, например, написать демона с очередью, у которого воркер будет считывать картинку, определять несколько областей обработки, и форкаться по числу ядер, потом возвращать родителю матрицу вторичных изображений для своего участка, но это уже не подключаемая библиотека

 

[WMix]

http://codepad.org/a7B0BZDQ
gif самый шустрый (но у него и размер самый маленький), голый bmp не получилось

 

[флоппик]

гиф кстати логично быстрее всех, он же индексированный

 

[antson]

@Шелест, для быстроты я считаю лучше всего заранее обработать коллекцию картинок . думаю в реальности хватит палитры из 256 цветов .
на каждый цвет складываем одинаковое кол-во файлов, а еще лучше склеить их в спрайт

исходную картинку конвертируем к нужной глубине цвета и размерам деленным на размер иконок

ну а дальше 256 раз повторяем
открыть спрайт
бежим по строкам столбцам конвертированной картинки
цвет равен текущему в выходное изображение скопировать случайный спрайт

таким образом по обращениям к диску нам нужно 1+256+1 операций
памяти потребуется приблизительно 3 размера исходного изображения .

вот только количество операций сравнений многовато,
но тут можно не тупо циклы гонять по всем , а
развернуть это в один массив M(x,y,color) и исключать после того как цвет совпал.

 

[antson]

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