Эффективность изменения размера изображения ImageMagick

Ответ 1

Вы должны проверить, установлена ​​ли ваша установка ImageMagick с поддержкой OpenCL:

convert -list configure | grep FEATURES

Если это так (как и мое), вы должны увидеть что-то вроде этого:

FEATURES      HDRI OpenCL

Эта команда

convert -version 

также должна содержать информацию о поддерживаемых функциях.

Если это не так, вы должны следить за тем, чтобы получить самую последнюю версию ImageMagick, в которую включена поддержка OpenCL. Если вы сами создаете пакет из источников, убедитесь, что используется OpenCL.

Update:

О, подождите. Еще одна функция, которая может вам помочь, называется OpenMP (для многопроцессорной обработки).

Когда OpenMP включен, команды ImageMagick могут выполняться параллельно на всех ядрах вашей системы. Поэтому, если у вас есть четырехъядерная система и изменение размера изображения, изменение размера происходит на 4 ядрах (или даже 8, если у вас есть гиперпоточность).

Теперь вы можете использовать встроенную опцию -bench, чтобы сделать ImageMagick запустимым эталоном для вашей команды. Например:

convert logo: -resize 500% -bench 10 logo.png
  Performance[1]: 10i 0.689ips 1.000e 14.420u 0:14.510

Эта команда с -resize 500% сообщает программе ImageMagick команду convert для масштабирования встроенного изображения IM logo: на 500% в каждом направлении. Часть -bench 10 сообщает, что она запускает ту же самую команду 10 раз в цикле, а затем печатает результаты производительности:

• Так как у меня нет OpenMP включен, у меня был только 1 поток (Performance[1]:).
• Сообщается, что он выполнил 10 итераций (10i).
• Скорость была около 0,7 итераций в секунду (0.689ips).
• Общее время автономной работы составляет 14.420 секунд.

Вы должны узнать, как ваша система настроена относительно ограничений ресурсов с помощью этой команды:

identify -list resource
  File       Area     Memory     Map       Disk    Thread         Time
  --------------------------------------------------------------------
   192    4.295GB       2GiB    4GiB  unlimited         1    unlimited

Вы можете видеть мои текущие системные настройки (по умолчанию - я не настраивал их). Каждое из ключевых слов в заголовках столбцов вы можете использовать сутенер вашей системы.

• files определяет максимальные одновременно открытые файлы, которые будет использовать ImageMagick.
• Ограничения ресурсов memory, map, area и disk определены в байтах. Чтобы установить их на разные значения, вы можете использовать префиксы SI, например 500 МБ).

Если бы я имел OpenMP для ImageMagick в этой системе, я мог бы запустить

convert -limit thread 2

чтобы включить 2 параллельных потока, повторите тест и посмотрите, действительно ли это имеет значение, и если да, то сколько. Я мог установить предел 4 или даже 8 и повторить упражнение....

Наконец, вы можете поэкспериментировать с внутренним форматом кэша пикселей ImageMagick, называемым MPC (Magick Pixel Cache). Некоторые говорят, что для больших операций производительность здесь улучшается, но у меня нет личного опыта.

Сначала преобразуйте базовое изображение в MPC:

convert input.jpeg input.mpc

и только затем запустите:

convert input.mpc [...your long-long-long list of crops...]

и убедитесь, что это значительно сэкономит ваше время.

Скорее всего, вы можете использовать этот формат MPC даже "inline" (используя специальную нотацию mpr:), подобно тому, как вы применили трюк использования формата mpr: (регистр программы памяти), который считывает изображение в названный регистр памяти. Но я никогда не пробовал эту технику для реальной проблемы, поэтому я не могу сказать, как она работает в реальной жизни.

Обновление 2:

Еще одна идея:

Сначала проверьте свою точную версию ImageMagick: запустите convert -version.

Если ваш ImageMagick имеет Q16 (или даже Q32 или Q64) в своей строке версии (это означает, что его внутренние процессы рассматривают все изображения с глубиной в 16 бит канала, что требует двойной памяти по сравнению с Q8) - это по умолчанию в настоящее время - вы можете проверить, какую выгоду вы достигнете, переключившись на Q8-build. (Вы будете платить за свои победы в производительности за потери качества, и вам придется проверить, можете ли вы с ним жить или нет).

Ответ 2

Время процессора уходит в 3 задачи:

• Декомпрессия JPEG;
• размер
• Рекомпрессии JPEG

(Само порезание занимает, возможно, 1% вашего времени.)

Чтобы декодировать JPEG, просто сделайте это один раз, удерживайте результат в ОЗУ и повторно используйте для каждого выхода. (Подробности ниже.) Таким образом, стоимость будет незначительной.

Чтобы кодировать JPEG, используйте libjpeg-turbo; тот же API, но ускорение 2-4 раза, если вы используете x86- {32,64} или аппаратное обеспечение ARM.

Чтобы изменить размер, ImageMagick хорошо известен тем, что использует процессор размером ~ 100x, как и любое другое программное обеспечение, кроме PhotoShop и GIMP. Это включает в себя все зрители фото. Он выполняет несколько тригонометрических функций на пиксель, тогда как все остальные просто делают одно умножение. Иногда, если вы посмотрите на пиксели рядом с краем изображения, вы можете увидеть, что ImageMagick выбирает лучший цвет, чем его конкуренты. Но если вы считаете, что HTML5, Flash, Silverlight, Java, GD (популярный с веб-приложениями Perl, PHP и Python) и т.д. Выглядят отлично, тогда вам не нужен такой псевдо-AI (искусственный интеллект). Вы могли бы бросить в ImageMagick GPU (OpenCL) мощность или больше CPU (OpenMP), но зачем беспокоиться?

Для высокой эффективности эквивалент ImageMagick (стандарт де-факто) - Imlib2. Он может использоваться почти из многих OS/языковых сред, таких как ImageMagick.

Ваша команда "convert" shell эквивалентна 10-20 строкам языка высокого уровня, вызывающему Imlib2: распаковать JPEG, а затем повторно обрезать, изменить размер и сжать JPEG.

Пример без обрезки (или нескольких выходных данных): Нарисуйте, измените размер или уменьшите изображение с помощью Perl

Сообщите мне, хотите ли вы другие примеры.

Ответ 3

Поздно к партии, но это мой текущий метод, если у кого-то такая же проблема. Если вы выполняете базовые преобразования пакетной обработки, но по многим тысячам изображений, по моему опыту вы не получаете большой пользы от openMP, который швы хороши для "мультикорирования" больших сложных преобразований. Мое решение - это bash script для параллельной обработки отдельных процессов.

#!/bin/bash
counter=0
for i in tif/*.TIF;
do
    y=${i%.TIF}
    ((counter++))
    if [ -s gif$y.gif ];then
        :
    else
        gm convert $i gif$y.gif &
    fi
    if [ $counter -eq 30 ];then 
        ((counter =0))
        wait
    fi
done
wait  

Это преобразует все файлы TIF в каталог "tif" в gif в каталоге "giftif". Если вам нужно остановить этот script, он заберет место, где он будет отключен в следующий раз. Это разжевывает все 16 ядер в моей MBP и примерно на 12-14 раз быстрее, чем одноядерный метод, пока я в настоящее время конвертирую 150 000 изображений.