3

OS X の GIMP 2.8.14 内で Python-Fu を使用して、ゲームのアセット パイプラインの作成を自動化しています。

しかし、スクリプトからpdb.gimp_image_scaleメソッドを実行すると、組み込み機能の "Image > Scale Image..." と比較して遅いことに気付きました。

白い画像を 8000x8000 から 2000x2000 に縮小すると、スクリプトでは 6.8 秒かかりますが、GUI では 1.7 秒かかります。それほど重要ではありませんが、多数のレイヤーを使用してアセットを縮小すると、スクリプトでは 3 分 47 秒かかりますが、GUI では 40 秒かかります。

アクティビティ モニターは、スクリプトを実行したときのCPU 使用率が最大約 30% しかないことを示しました。組み込みの GUI スケーリングは最大 100% を使用します。これは、OS X では単一の CPU コアが可能な限り高速であることを意味します。 .

どうすればその行動を変えることができるか、誰にも考えがありますか?

奇妙なことに、これは gimp_image_scale にのみ起因する継ぎ目です。gimp_image_select_contiguous_color、gimp_selection_grow、gimp_selection_feather、gimp_edit_bucket_fill_full などの他の操作では、CPU 使用率が最大 100% になります。

Windows でも同じですが、実際にはそれほど悪くはありません。スクリプト経由で 1 分 28 秒、組み込み GUI 経由で 33 秒です。

from gimpfu import *

def scale_image(scale):
    image = gimp.image_list()[0]
    w = image.width
    h = image.height

    pdb.gimp_progress_init("Scaling Image...",None)
    pdb.gimp_context_set_interpolation(INTERPOLATION_LANCZOS)
    pdb.gimp_image_scale(image, w/scale, h/scale)
pass

register(
         "jeanluc_scale_image",
         "Scale Image",
         "Scale Image",
         "JeanLuc",
         "JeanLuc",
         "2015",
         "Scale Image...",
         "*",
         [
          (PF_INT, "scale", "Scale of Image", 1)
          ],
         [],
         scale_image,
         menu="<Image>/JeanLuc"
)

main()

更新 1: アクティビティ モニターに「CPU 履歴」機能があることがわかりました。ここで、私の仮定が間違っていることがわかりました。100% は 1 つのコアではなく、4 つのコアに 25% 分散しています。

では、なぜ両方のケースで 25% しか実行されないのでしょうか? gimp_image_scale がマルチスレッド化されていないのはなぜですか?

GUI によるマルチスレッド スケーリング (左) とスクリプトによるシングル スレッド (右)

更新 2: "Filters>Python-Fu>Console" からスクリプトを実行すると、実際にはマルチスレッドで高速です。

更新 3: 入力値 (スケールなど) を指定せずにスクリプトを実行し、値をハードコードすると、マルチスレッドで高速に実行されます。ダイアログからスケーリングがトリガーされると、シングルスレッドになるようです。

4

2 に答える 2

2

ヒントとして、これはこの問題には影響しませんが、ブラシ ストロークや選択範囲と塗りつぶしの作成など、複数 (数百) のピクセル レベルの操作を実行するスクリプトでパフォーマンスの問題を抱えている他のユーザーの助けになるはずです。 UNDO ステップを適切にグループ化します。

したがって、集中的なスクリプトのヒントは、イメージを複製 ( )し、コピーをpdb.gimp_image_duplicate呼び出し 、そこで操作を実行し、終了時に、関連するドローアブルを元のイメージに転送することです。pdb.gimp_image_undo_disablepdb.gimp_edit_copypdb.gimp_edit_paste

于 2015-01-22T10:53:21.740 に答える
1

新しいスレッドから gimp_image_scale を実行するハックな回避策を見つけました。そして今では 3 分 37 秒ではなく 24 秒しかかからないため、40 秒かかるビルトイン GUI ソリューションよりも実際には高速です。

誰かが適切な解決策を知っているか見つけた場合、私はそれを答えとして受け入れます。

#!/usr/bin/env python

from threading import Thread
import time
from gimpfu import *

def scale_image(scale):
    pdb.gimp_progress_init("Scaling Image...",None)
    time.sleep(0.5)
    thread = Thread(target = thread_scale_image, args = (scale, ))
    thread.start()
    thread.join()
pass

def thread_scale_image(scale):
    image = gimp.image_list()[0]
    w = image.width
    h = image.height
    pdb.gimp_context_set_interpolation(INTERPOLATION_LANCZOS)
    pdb.gimp_image_scale(image, w/scale, h/scale)
pass

register(
         "jeanluc_scale_image",
         "Scale Image",
         "Scale Image",
         "JeanLuc",
         "JeanLuc",
         "2015",
         "Scale Image...",
         "RGB*",
         [
          (PF_INT, "scale", "Scale of Image", 4)
          ],
         [],
         scale_image,
         menu="<Image>/JeanLuc"
)

main()
于 2015-01-22T09:13:42.140 に答える