ImageMagick или GraphicsMagick? чем быстрее ресайзить?

http://www.vips.ecs.soton.ac.uk/index.php?title=Libvips очень быстрый

Да одинаково, наверное. А как ты ресайзишь? Может дефолтный фильтр поменять на box или что там ещё попроще?

Насчёт ресайза IM, вероятно как и GM, может в OpenCL, если актуально.

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

ffmpeg

В PPA не последняя версия, которая падает через 5 минут работы. Новую собирать гиморно. Отложили пока не выясним, где скорость накрывается. Это может быть еще сам jpeg, форканье процессов и т.п.

https://github.com/nodeca/nodeca.users/blob/master/models/users/_lib/resize.j...

Жмется через прослойку, но там там передается минимум параметров

- новый размер
- обрезать по краям
- качество jpeg

Больше ничего нет.

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

gmInstance.unsharp('0');

Это точно не лишнее?

// Is image size smaller than 'skip_size' - skip resizing
if (resizeConfig.skip_size && stats.size < resizeConfig.skip_size) {
...
gmInstance.write(...

Зачем что-то куда-то писать, заново компрессить картинку, если она не меняется? Мне кажется, что просто скопировать будет быстрее.

С вычислением размеров там тоже, явно, упростить можно. Мне кажется там должны быть параметры ресайза по любой стороне с сохранением пропорций — чтобы избежать лишней математики и кропа.

И на фильтры, всё же, глянь. Там по умлчанию чуть ли не Ланцош используется.

Сенькс. Проверю. Я пока грешил на тормоза файловой системы из-за временных файлов, и долгий запуск gm.

Уншарп выкидывать не желательно. Но там картинки небольшие, 640х480 и 200x170. А исходные кажется 1024х678. На таких вроде и ланцош и уншарп должны быстро бегать, особенно с MMX.

Ну да, разница в 20 раз, скорее, действительно говорит о том, что это запись тормозит. Попробуй в /dev/null сохранять.

Уншарп выкидывать не желательно.

Не, я в том смысле, что '0' — это, вроде как сильно крутой аншарп. Нужен ли он такой для твоей задачи? А во-вторых, его можно сделать за одно с ресайзом. По крайней мере в сишечке так.

Не, в случае GM - 0 на уншарпе означает «подставить оптимальное значение». Я не вникал в детали, но задраных значений там точно нет, такое видно сразу.

А девелопмент тут притом, что ты все это делаешь для сайтега? Как вы достали уже, малохольные. Ты зачем тут на лоре постишь всякую чушь вообще? Чтобы все узнали, что ты чем то там занимаешься? Ну пости, как ты в киношку сходил, как в булошную згонял, интересно же всем.Почем рыбка кстати?

нагенерить

если генерить, то есть, предварительно, значит, не на ходу, то какая разница, что быстрей?

Benchmarks, Luke. Use them.

http://www.imagemagick.org/Usage/thumbnails/ тут читал?

О, давно туда не заглядывал. Спасибо.

В общем, после замены промежуточных файлов на буферы в памяти, 20 часов превратились в 7. Но gm похоже сам временные файлы еще создает. Попробуем на tmpfs закинуть, но я не понял, откуда такие ограничения и не нашел по доке как заставить convert использовать только память.

Ну чё там?

В процессе. Выходные.

ImageMagick или GraphicsMagick? чем быстрее ресайзить? (комментарий) пока диск тормозит больше, чем математика. Надо еще немного докрутить.

Если кому интересно:

1. Дергать GM/IM через командную строку можно, но долго.
2. Лучше брать нативные биндинги к libvips
3. libvips лучше пересобрать без поддержки liborc, чтобы не падало.
4. Узкое место - не только процессор, но и диск, поэтому надо озаботиться, чтобы все делалось в памяти и не создавались временные файлы.

Начальный вариант, который 650К картинок обрабатывал 20 часов после переделок укладывается в 3-4 часа.

http://www.smashingmagazine.com/2015/06/efficient-image-resizing-with-imagema...