Мащабиране на изображение с python-fu в GIMP по-бавно, отколкото чрез вграден GUI

Използвам Python-Fu в GIMP 2.8.14 на OS X, за да автоматизирам производството на конвейера на активи за игра.

Но забелязах, че методът pdb.gimp_image_scale е по-бавен, когато го изпълнявам от моя скрипт, в сравнение с вградената функция "Изображение > Мащабиране на изображение... ".

Намаляването на бяло изображение от 8000x8000 до 2000x2000 отнема 6,8 секунди от скрипт в сравнение с 1,7 секунди от GUI. Това не е толкова критично, но намаляването на моите активи с много слоеве отнема 3 минути и 47 секунди от скрипт, в сравнение с 40 секунди от GUI.

Моят монитор на активността ми показа, че използването на процесора, когато изпълних скрипта си, достига само до около 30 %, където вграденото GUI мащабиране използва до 100%, което означава, че в OS X едно ядро ​​на процесора работи възможно най-бързо.

Някой има ли идея как мога да променя това поведение?

Странното нещо: Това изглежда е причина само за gimp_image_scale. Други операции като gimp_image_select_contiguous_color, gimp_selection_grow, gimp_selection_feather и gimp_edit_bucket_fill_full карат използването на процесора до 100%.

В Windows е същото, но всъщност не е толкова лошо: 1 минута 28 секунди чрез скрипт и 33 секунди чрез вграден GUI.

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: Открих, че Activity Monitor има функция „Хронология на процесора“, където видях, че предположението ми е погрешно: 100% не е на 1 ядро, а е разпределено 25% на 4 ядра.

Така че защо и в двата случая работи само при 25% процента? и защо gimp_image_scale не е многонишков?

Многонишково мащабиране чрез GUI (вляво) срещу еднонишково чрез скрипт (вдясно)

АКТУАЛИЗАЦИЯ 2: Когато стартирам скрипта си от "Filters>Python-Fu>Console", той всъщност е многонишков и бърз.

АКТУАЛИЗАЦИЯ 3: Когато стартирам скрипта си без входна стойност (напр. мащаб) и твърдо кодирам стойността, той също работи многопоточно и бързо. Изглежда, че когато мащабирането се задейства от диалоговия прозорец, то е еднопоточно.


gimp python-fu
person JeanLuc    schedule 21.01.2015    source източник
comment
Дали може би използва GPU, когато се извиква през GUI, чудя се?   -  person Mark Setchell    schedule 21.01.2015
comment
Опитах се да профилирам това, но след това открих проблема от страна на процесора, вижте моя актуализиран въпрос.   -  person JeanLuc    schedule 21.01.2015

Отговори (2)


arrow_upward
2
arrow_downward

Като намек, това няма да засегне този проблем, но би трябвало да помогне на други при проблеми с производителността на скриптове, които извършват операции на ниво няколко (стотици) пиксела, като щрихиране с четка или създаване на селекции и запълвания: системата UNDO плъзга всичко надолу, дори когато правилно групиране на стъпките за ОТМЕНЯНЕ.

И така, подсказката за интензивен скрипт е да се дублира (pdb.gimp_image_duplicate) изображението, да се извика pdb.gimp_image_undo_disable на копието, да се изпълнят операциите там и на финала pdb.gimp_edit_copy и pdb.gimp_edit_paste да се прехвърлят съответните чертежи към оригиналното изображение.

person jsbueno    schedule 22.01.2015
comment
Благодаря за този намек: тъй като моята система за контрол на версиите може да прави отмяна/връщане, нямам нужда от нея в GIMP. Така че просто го деактивирах. Производителността на моя скрипт беше увеличена от 2 минути 13 секунди на 1 минута 51 секунди. - person JeanLuc; 22.01.2015

arrow_upward
1
arrow_downward

Намерих хакерско решение за изпълнение на gimp_image_scale от нова нишка. И сега вместо 3 минути и 37 секунди, това отнема само 24 секунди, така че всъщност по-бързо от вграденото GUI решение, което отнема 40 секунди.

Ако някой знае или намери подходящо решение, ще го приема като отговор.

#!/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()
person JeanLuc    schedule 22.01.2015
comment
Мисля, че това е повече от правилното решение за случая. Ако имахте време, бихте могли да подадете информацията, съдържаща се в този въпрос, в GIMP bugzilla - това може би ще ни помогне да се справим с това в обозримо бъдеще. bugzilla.gnome.org/buglist.cgi?product=GIMP - person jsbueno; 22.01.2015
comment
Ако се чувствате смели, може би бихте могли да опитате да използвате обвързвания на Python GEGL - трябва да се върна, за да ги хакна скоро, но те предоставят прозрачен Pythonic достъп до повечето функции на GEGL. GEGL, Generic Graphics Library е кодът, който всъщност се използва като машина за манипулиране на изображения от текущите версии на GIMP. Недостатъкът е, че трябва да работите с API, напълно различен от този, предоставен от GIMP. Положителната страна не е изненада от проблеми с производителността, дължащи се на U.I. въпроси. - person jsbueno; 22.01.2015
comment
благодаря, поне ще изпратя доклад за грешка. Може да погледна Python GEGL в бъдеще, когато имам нужда от повече контрол над GIMP или срещна друг хит в производителността. - person JeanLuc; 22.01.2015
comment
Да, разбира се - забравих да спомена, но ако човек не манипулира изображението интерактивно, винаги има смисъл да деактивирате отмяната. - person jsbueno; 22.01.2015
comment
Голяма грешка: GNOME Bugzilla ще покаже моя имейл на обществеността. Съжалявам, но не благодаря, предпочитам дори третичният ми имейл да е личен. - person JeanLuc; 22.01.2015