ImageMagick批量调整大小性能

Question

 
convert \ 
    original.jpg \ 
    -quality 85 \ 
    -colorspace rgb \ 
    -profile /var/tmp/sRGB.icm \ 
    -strip \ 
    -profile /var/tmp/sRGB.icm \ 
    -filter Lanczos \ 
    -write mpr:17JPCONV1-original \ 
    +delete \ 
mpr:17JPCONV1-original -crop '3000x2001+0+491' -resize '190x126!>' -write thumbWide.jpg +delete \ 
mpr:17JPCONV1-original -crop '2981x2983+8+0' -resize '75x75!>' -write thumbStandard.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x2983+0+0' -resize '163x163!>' -write hpSmall.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x2983+0+0' -resize '1024x1019!>' -write jumbo.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x2983+0+0' -resize '190x189!>' -write articleInline.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x2983+0+0' -resize '2048x2037!>' -write superJumbo.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x2983+0+0' -resize '592x589!>' -write tmagArticle.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x2983+0+0' -resize '3000x2983!>' -write popup.jpg +delete \ 
mpr:17JPCONV1-original -crop '2981x2983+8+0' -resize '640x640!>' -write square640.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x1689+0+647' -resize '3000x1688!>' -write videoSmall.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x2983+0+0' -resize '503x500!>' -write slide.jpg +delete \ 
mpr:17JPCONV1-original -crop '2981x2983+8+0' -resize '151x151!>' -write moth.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x2001+0+491' -resize '337x225!>' -write hpMedium.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x2001+0+491' -resize '395x264!>' -write sfSpan.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x1689+0+647' -resize '3000x1688!>' -write videoLarge.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x1689+0+647' -resize '511x288!>' -write hpLarge.jpg +delete \ 
mpr:17JPCONV1-original -crop '2981x2983+8+0' -resize '320x320!>' -write square320.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x1689+0+647' -resize '600x338!>' -write articleLarge.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x2001+0+491' -resize '3000x2000!>' -write videoThumb.jpg +delete \ 
mpr:17JPCONV1-original -crop '2981x2983+8+0' -resize '150x150!>' -write thumbLarge.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x2983+0+0' -resize '533x530!>' -write blog533.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x2983+0+0' -resize '151x151!>' -write blogSmallInline.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x2983+0+0' -resize '362x360!>' -write tmagSF.jpg +delete \ 
mpr:17JPCONV1-original -crop '2981x2983+8+0' -resize '190x190!>' -write filmstrip.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x2983+0+0' -resize '480x478!>' -write blog480.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x2983+0+0' -resize '427x425!>' -write blog427.jpg +delete \ 
mpr:17JPCONV1-original -crop '2981x2983+8+0' -resize '50x50!>' -write blogSmallThumb.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x1401+0+791' -resize '151x70!>' miniMoth.jpg; 

我试图从原始生成约30个作物使用一个命令（使用一个命令比使用每个作物的单个命令快得多）。但是，这需要很长时间（约30秒）才能完成。任何建议，以加快这一点？ resize命令可以通过OpenCL利用GPU吗？

更新：

• 使用-thumbnail代替调整大小的改善的事情
• （感谢@AR的尖端）编译的ImageMagick用的libjpeg涡轮20％也提高倍

Answer 1

您应该检查您的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命令由500％在每个方向上是按比例的内置的IM logo:图像。该-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 

你可以看到我的当前系统的设置（默认值 - 我没有调整过）。列标题中的每个关键字都可以使用pimp系统。

• 的files定义最多同时打开这ImageMagick的将使用的文件。
• memory,map,area和disk资源限制以字节定义。对于设置他们到不同的值，你可以使用SI前缀，例如500MB）。

如果我有的OpenMP的ImageMagick的这个系统上，我可以为了使2级并行的线程，重新运行基准测试，看看运行

convert -limit thread 2 

，如果它真的有差异，如果是这样多少。在我可以在限制设置为4，甚至8和重复锻炼; Tibial ....

---

最后，你可以用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）在其版本字符串（意思是，它的内部流程考虑所有图像具有16bit的航道水深，这就要求相比Q8双内存） - 这是现在的默认设置 - 您可以通过切换到Q8构建来测试您将获得的性能优势。 （你要付与质量损失你的表现获胜，你必须检查，如果你可以用它或不活....）

Answer 2

你的CPU时间要3个任务：

• JPEG解压缩;
• resize;
• JPEG再压缩

（裁剪本身占用你的时间，也许1％。）

为了解码JPEG，只需做一次，坚持的结果RAM和重用每个输出。 （详情如下。）这样，成本将是微不足道的。

要编码JPEG，请使用libjpeg-turbo;相同的API，但如果使用x86- {32,64}或ARM硬件，则速度提高2-4倍。

为了调整图像大小，ImageMagick以其它任何软件（除PhotoShop和GIMP以外）使用CPU的100倍而闻名。这包括所有照片观看者。它正在为每个像素执行多个三角函数，而其他人只是执行一次乘法。 有时候，如果您看图像边缘附近的像素，可以看到ImageMagick选择比其竞争对手更好的颜色。但是如果你认为HTML5，Flash，Silverlight，Java，GD（很受Perl，PHP和Python网络应用程序的欢迎）等等看起来不错，那么你就不需要这种伪AI（人工智能）。 您可能会将GPU（OpenCL）马力或更多CPU（OpenMP）投入ImageMagick中，但为什么要麻烦？

对于高效率，相当于ImageMagick（事实上的标准）是Imlib2。 它几乎可用于像ImageMagick一样多的OS /语言环境。

您的“convert”shell命令相当于高级语言的10-20行调用Imlib2： 解压缩JPEG，然后重复裁剪，调整大小和压缩JPEG。

没有作物（或多个输出）的一个例子是： Stretch, resize, or thumbnail an image using Perl

让我知道，如果你想其他的例子。

Answer 3

晚会晚会，但这是我目前的方法，如果任何人有同样的问题。 如果您正在批量处理基本变换，但成千上万的图像，按照我的经验，您不会从openMP中获得太多好处，而这种效果可以用于“multicoring”大型复杂变换。 我的解决方案是一个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倍，而我目前正在转换150,000个图像。