转换\原始.jpg\-质量85\-颜色空间rgb\-配置文件/var/tmp/sRGB.icm\-带材\-配置文件/var/tmp/sRGB.icm\-Lanczos过滤器\-写入mpr:17JPCONV1原件\+删除\mpr:17JPCONV1原始-裁剪"3000x2001+0+491"-调整大小"190x126！>'-write-tumbWide.jpg+删除\mpr:17JPCONV1原始-裁剪'2981x2983+8+0'-调整大小'75x75！>'-write-tumbStandard.jpg+删除\mpr:17JPCONV1原始-裁剪"3000x2983+0+0"-调整大小"163x163！>'-写入hpSmall.jpg+删除\mpr:17JPCONV1原始-裁剪"3000x2983+0+0"-调整大小"1024x1019！>'-写入jumbo.jpg+删除\mpr:17JPCONV1原始-裁剪"3000x2983+0+0"-调整大小"190x189！>'-write-articleInline.jpg+删除\mpr:17JPCONV1原始-裁剪"3000x2983+0+0"-调整大小"2048x2037！>'-write-superJumbo.jpg+删除\mpr:17JPCONV1原始-裁剪"3000x2983+0+0"-调整大小"592x589！>'-写入tmagArticle.jpg+删除\mpr:17JPCONV1原始-裁剪"3000x2983+0+0"-调整大小"3000x2982！>'-写入popup.jpg+删除\mpr:17JPCONV1原始-裁剪'2981x2983+8+0'-调整大小'640x640！>'-写入square640.jpg+删除\mpr:17JPCONV1原始-裁剪3000x1689+0+647'-调整大小3000x1688！>'-编写videoSmall.jpg+删除\mpr:17JPCONV1原始-裁剪"3000x2983+0+0"-调整大小"503x500！>'-写入幻灯片.jpg+删除\mpr:17JPCONV1原始-裁剪'2981x2983+8+0'-调整大小'151x151！>'-write-moth.jpg+删除\mpr:17JPCONV1原始-裁剪"3000x2001+0+491"-调整大小"337x225！>'-写入hpMedium.jpg+删除\mpr:17JPCONV1原始-裁剪"3000x2001+0+491"-调整大小"395x264！>'-写入sfSpan.jpg+删除\mpr:17JPCONV1原始-裁剪3000x1689+0+647'-调整大小3000x1688！>'-编写videoLarge.jpg+删除\mpr:17JPCONV1原始-裁剪"3000x1689+0+647"-调整大小"511x288！>'-写入hpLarge.jpg+删除\mpr:17JPCONV1原始-裁剪'2981x2983+8+0'-调整大小'320x320！>'-写入square320.jpg+删除\mpr:17JPCONV1原始-裁剪"3000x1689+0+647"-调整大小"600x338！>'-write-articleLarge.jpg+删除\mpr:17JPCONV1原始-裁剪"3000x2001+0+491"-调整大小"3000x2000！>'-编写videoThumb.jpg+删除\mpr:17JPCONV1原始-裁剪'2981x2983+8+0'-调整大小'150x150！>'-write-tumbLarge.jpg+删除\mpr:17JPCONV1原始-裁剪"3000x2983+0+0"-调整大小"533x530！>'-写blog533.jpg+删除\mpr:17JPCONV1原始-裁剪"3000x2983+0+0"-调整大小"151x151！>'-写博客SmallInline.jpg+删除\mpr:17JPCONV1原始-裁剪"3000x2983+0+0"-调整大小"362x360！>'-写入tmagSF.jpg+删除\mpr:17JPCONV1原始-裁剪'2981x2983+8+0'-调整大小'190x190！>'-写入filmstep.jpg+删除\mpr:17JPCONV1原始-裁剪"3000x2983+0+0"-调整大小"480x478！>'-写blog480.jpg+删除\mpr:17JPCONV1原始-裁剪"3000x2983+0+0"-调整大小"427x425！>'-写blog427.jpg+删除\mpr:17JPCONV1原始-裁剪'2981x2983+8+0'-调整大小'50x50！>'-写博客SmallThumb.jpg+删除\mpr:17JPCONV1原始-裁剪"3000x1401+0+791"-调整大小"151x70！>'miniMoth.jpg；
我正试图使用一个命令从原始作物中生成大约30个作物（使用一个指令比为每个作物使用单个指令要快得多）。然而，这需要相当长的时间（约30秒）才能完成。有什么加快速度的建议吗？调整大小命令是否可以通过OpenCL利用GPU？
更新：
- 使用-缩略图而不是-调整大小可以改善情况
- （感谢@A R提供的提示）使用libjpeg turbo编译ImageMagick也可以提高20%的时间
您应该检查您的ImageMagick安装是否附带OpenCL支持：
convert -list configure | grep FEATURES
如果它真的（像我的），你应该看到这样的东西：
FEATURES HDRI OpenCL
此命令
convert -version
还应提供有关支持功能的信息。
如果没有，你应该考虑编译支持OpenCL的ImageMagick的最新版本。或者，如果你自己从源代码构建包，请确保使用OpenCL。
更新：
哦，等等。还有一个功能可以帮助您，称为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，所以我只有一个线程（
Performance[1]:） - 它报告说它运行了10次迭代（
10i） - 速度接近每秒0.7次迭代（
0.689ips） - 用户总共花费了14.420秒
您应该通过以下命令了解您的系统是如何设置资源限制的：
标识-列出资源文件区内存映射磁盘线程时间--------------------------------------------------------------------192 4.295GB 2GiB 4GiB无限制1无限制
你可以看到我当前系统的设置（默认设置——我没有调整它们）。列标题中的每个关键字都可以在系统中使用。
files定义ImageMagick将使用的最大并发打开文件数memory、map、area和disk资源限制以字节为单位定义。对于将设置为不同的值，您可以使用SI前缀，例如500MB）
如果我在这个系统上有OpenMP for ImageMagick，我可以运行
convert -limit thread 2
为了启用2个并行线程，请重新运行基准测试，看看它是否真的有影响，如果有，影响有多大。我可以将极限设置为4甚至8，然后重复练习。。。。
最后，您可以尝试ImageMagick的像素缓存的内部格式，称为MPC（Magick像素缓存）。有人说，对于大型运营，这里的性能会有所提高，但我对此没有任何个人经验
首先将您的基本图片转换为MPC：
convert input.jpeg input.mpc
然后才运行：
convert input.mpc [...your long-long-long list of crops...]
看看这是否能大大节省你的时间。
最有可能的是，您甚至可以"内联"使用这种MPC格式（使用特殊的mpr:表示法），类似于使用mpr:格式（内存程序寄存器）将图像读取到命名内存寄存器的技巧。但我从未在现实世界中尝试过这种技术，所以我不能说它在现实生活中是如何运作的。
更新2:
还有一个想法：
首先检查您的ImageMagick版本：运行convert -version。
如果ImageMagick的版本字符串中有Q16（甚至Q32或Q64）（这意味着它的内部进程认为所有图像都有16位通道深度，与Q8相比，这需要双倍的内存）——这是目前的默认设置——你可以测试切换到Q8版本会带来什么性能优势。（你将用质量损失来支付你的性能胜利，你必须检查你是否能接受它……）
您的CPU时间将用于3项任务：
- JPEG解压缩
- 调整大小
- JPEG重新压缩
（修剪本身可能需要1%的时间。）
要解码JPEG，只需执行一次，将结果保存在RAM中，并对每个输出重复使用。（详情如下。）那样，成本将微不足道。
要对JPEG进行编码，请使用libjpeg-turbo；相同的API，但如果您使用x86-｛32，64｝或ARM硬件，则可以加速2-4x。
为了调整大小，ImageMagick以使用大约100倍于除PhotoShop和GIMP之外的任何其他软件的CPU而闻名。这包括所有的照片查看器。它每个像素做多个三角函数，而其他人只做一个乘法。有时，如果你观察图像边缘附近的像素，你会发现ImageMagick选择了比竞争对手更好的颜色。但是，如果你认为HTML5、Flash、Silverlight、Java、GD（流行于Perl、PHP和Python网络应用程序）等看起来不错，那么你就不需要这样的伪AI（人工智能）。你也许可以把GPU（OpenCL）的马力或更多的CPU（OpenMP）投入到ImageMagick中，但为什么要麻烦呢？
为了高效，ImageMagick（事实上的标准）的等效物是Imlib2。它可以在几乎与ImageMagick一样多的操作系统/语言环境中使用。
您的"convert"shell命令相当于调用Imlib2的高级语言的10-20行：解压缩JPEG，然后重复裁剪、调整大小和压缩JPEG。
没有作物（或多个输出）的示例是：使用Perl 拉伸、调整图像大小或缩略图
如果你想要其他例子，请告诉我。
迟到了，但如果有人有同样的问题，这是我目前的方法如果你正在批量处理基本的转换，但要处理成千上万的图像，根据我的经验，你不会从openMP中获得太多好处，因为openMP适合"多环"大型复杂转换。我的解决方案是使用bash脚本来并行生成各个进程。
#!/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文件转换为"giftif"目录下的gif。如果你必须停止这个脚本，下次它会从停止的地方重新开始。这消耗了我MBP中的所有16个核心，比单核心方法快12-14倍，而我目前正在转换150000张图像。