14 
変換 \
   オリジナル.jpg \
  -品質 85 \
  -色空間 RGB \
  -プロファイル /var/tmp/sRGB.icm \
  -ストリップ\
  -プロファイル /var/tmp/sRGB.icm \
  -フィルター ランチョス \
  -write mpr:17JPCONV1-original \
  +削除\
mpr:17JPCONV1-original -crop '3000x2001+0+491' -resize '190x126!>' -thumbWide.jpg の書き込み +delete \
mpr:17JPCONV1-original -crop '2981x2983+8+0' -resize '75x75!>' -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!>' -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!>' -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!>' -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;

1 つのコマンドを使用してオリジナルから ~30 のクロップを生成しようとしています (1 つのコマンドを使用すると、クロップごとに 1 つのコマンドを使用するよりも大幅に高速になります)。ただし、これにはかなりの時間がかかります (~30 秒)。これをスピードアップするための提案はありますか？サイズ変更コマンドは、OpenCL 経由で GPU を利用できますか?

アップデート：

  • -resize の代わりに -thumnail を使用すると改善されます
  • (ヒントについては @AR に感謝します) libjpeg-turbo を使用して ImageMagick をコンパイルすると、時間も 20% 短縮されます
4

3 に答える 3

34

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

このコマンドは、組み込みの IMイメージを各方向に 500%拡大縮小するコマンド-resize 500%を実行するように ImageMagick に指示します。この部分は、同じコマンドをループで 10 回実行し、パフォーマンス結果を出力するように指示します。convertlogo:-bench 10

  • OpenMP を有効にしていないため、スレッドは 1 つしかありませんでした ( Performance[1]:)。
  • 10 回の反復を実行したことが報告されています ( 10i)。
  • 速度は 1 秒あたり約 0.7 回の反復でした ( 0.689ips)。
  • ユーザー割り当て時間の合計は 14.420 秒でした。

次のコマンドを使用して、リソース制限に関してシステムがどのように設定されているかを確認する必要があります。

特定 - リスト リソース
  ファイル エリア メモリ マップ ディスク スレッド時間
  -------------------------------------------------- ------------------
   192 4.295GB 2GiB 4GiB 無制限 1 無制限

現在のシステムの設定を確認できます (デフォルト -- 微調整はしていません)。使用できる列ヘッダーの各キーワードは、システムをポン引きします。

  • filesは、ImageMagick が使用する同時オープン ファイルの最大数を定義します。
  • 、memory、およびリソース制限はバイト単位で定義されますmap。それらを異なる値に設定するには、SI プレフィックス (.eg 500MB) を使用できます。areadisk

このシステムに ImageMagick 用の OpenMP があれば、実行できます。

convert -limit thread 2

2 つの並列スレッドを有効にするには、ベンチマークを再実行して、実際に違いがあるかどうかを確認します。制限を 4 または 8 に設定して、演習を繰り返すことができます....

最後MPCに、 (Magick Pixel Cache)と呼ばれる ImageMagick のピクセル キャッシュの内部形式を試すことができます。大規模な操作の場合、ここでパフォーマンスが向上すると言う人もいますが、個人的な経験はありません。

最初に基本画像を MPC に変換します。

convert input.jpeg input.mpc

そして、次のように実行します:

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

これにより時間を大幅に節約できるかどうかを確認してください。

ほとんどの場合、この MPC 形式を "インライン" (特別な表記法を使用) でも使用できます。これは、イメージを名前付きメモリ レジスタに読み込む形式 (メモリ プログラム レジスタmpr:)を使用するトリックを適用した方法と同様です。しかし、私はこの手法を実際の問題に適用したことがないので、実際にどのように機能するかはわかりません。mpr:

更新 2:

もう1つのアイデア：

最初に正確な ImageMagick のバージョンを確認します: run convert -version。

ImageMagick のバージョン文字列に (または または ) がある場合Q16(Q32つまりQ64、内部プロセスはすべての画像を 16 ビットのチャネル深度と見なし、 と比較して 2 倍のメモリを必要としQ8ます) -- これは最近のデフォルトです -- テストできますQ8 ビルドに切り替えることで得られるパフォーマンス上の利点。（パフォーマンスの勝利には品質の低下が伴います。それを受け入れられるかどうかを確認する必要があります....）

于 2012-07-30T19:47:58.377 に答える
11

CPU時間は3つのタスクになります。

  • JPEG解凍;
  • サイズ変更;
  • JPEG再圧縮

（トリミング自体はおそらくあなたの時間の1％かかります。）

JPEGをデコードするには、一度だけ実行し、結果をRAMに保持して、出力ごとに再利用します。（詳細は以下を参照してください。）そうすれば、コストはわずかになります。

JPEGをエンコードするには、libjpeg-turboを使用します。同じAPIですが、x86-{32,64}またはARMハードウェアを使用すると2〜4倍高速化されます。

サイズを変更するために、ImageMagickはPhotoShopとGIMPを除く他のソフトウェアの約100倍のCPUを使用することでよく知られています。これには、すべての写真ビューアが含まれます。ピクセルごとに複数の三角関数を実行しますが、他のすべての関数は1回の乗算を実行します。画像の端に近いピクセルを見ると、ImageMagickが競合他社よりも優れた色を選択していることがわかる場合があります。しかし、HTML5、Flash、Silverlight、Java、GD（Perl、PHP、Python Webアプリで人気）などがうまく見えると思うなら、そのような疑似AI（人工知能）は必要ありません。GPU（OpenCL）馬力以上のCPU（OpenMP）をImageMagickに投入できるかもしれませんが、なぜわざわざするのでしょうか。

高効率の場合、ImageMagick（事実上の標準）に相当するのはImlib2です。ImageMagickとほぼ同じ数のOS/言語環境で使用できます。

「変換」シェルコマンドは、Imlib2を呼び出す高級言語の10〜20行に相当します。つまり、JPEGを解凍してから、JPEGのトリミング、サイズ変更、および圧縮を繰り返します。

切り抜き（または複数の出力）がない例は次のとおりです 。Perlを使用して画像を拡大、サイズ変更、またはサムネイル化

他の例が必要な場合はお知らせください。

于 2012-07-30T23:17:02.467 に答える