2022/05/20(金) [n年前の日記]
#1 [gimp][linux][ubuntu] Linux版GIMPはPython-Fuが使えなくなってた
最近の Linux版GIMP は Python-Fu (Gimp-Python) が使えない状態になっていたらしい。恥ずかしながら今頃になってようやく知った。
正確には、Debian Linux 11 bullseye や Ubuntu Linux 20.04 LTS の公式リポジトリからインストールできる GIMP 2.10 は、Python-Fu (Gimp-Python)が利用できない状態で何年も放置されている模様。
理由としては、Pythonが絡んでいるっぽい。Debian も Ubuntu も、Python 2.x から 3.x への移行を進めているので、Python 2.x を利用するパッケージを切り捨てる方向で動いているそうで。そして、GIMP の Python-Fu (Gimp-Python) は Python 2.x に依存しているので、関連パッケージも公式リポジトリからあっさり削除されてしまったのだとか。
昔は gimp-python というパッケージが存在していて、sudo apt install gimp-python をするだけで使えるようになったらしいけど…。今は、そんなパッケージは存在しない。Debian 11、Ubuntu 20.04、どちらも見つからなかった。
回避策は無いのかとググってみたら、flatpak (flathub) 版GIMPなら Python-Fu もサポートしているので、「Python-Fu が使いたければ公式リポジトリ版ではなく flatpak版を使いましょう」ということになっているっぽい。
そんなわけで試してみた。環境は、Ubuntu Linux 20.04 LTS 64bit。Xubuntu関連パッケージをインストールして、デスクトップ環境は Xfce4 で利用している。ちなみに CPU は AMD A8-3850。
正確には、Debian Linux 11 bullseye や Ubuntu Linux 20.04 LTS の公式リポジトリからインストールできる GIMP 2.10 は、Python-Fu (Gimp-Python)が利用できない状態で何年も放置されている模様。
理由としては、Pythonが絡んでいるっぽい。Debian も Ubuntu も、Python 2.x から 3.x への移行を進めているので、Python 2.x を利用するパッケージを切り捨てる方向で動いているそうで。そして、GIMP の Python-Fu (Gimp-Python) は Python 2.x に依存しているので、関連パッケージも公式リポジトリからあっさり削除されてしまったのだとか。
昔は gimp-python というパッケージが存在していて、sudo apt install gimp-python をするだけで使えるようになったらしいけど…。今は、そんなパッケージは存在しない。Debian 11、Ubuntu 20.04、どちらも見つからなかった。
回避策は無いのかとググってみたら、flatpak (flathub) 版GIMPなら Python-Fu もサポートしているので、「Python-Fu が使いたければ公式リポジトリ版ではなく flatpak版を使いましょう」ということになっているっぽい。
そんなわけで試してみた。環境は、Ubuntu Linux 20.04 LTS 64bit。Xubuntu関連パッケージをインストールして、デスクトップ環境は Xfce4 で利用している。ちなみに CPU は AMD A8-3850。
◎ flatpakをインストール。 :
Ubuntu Linux 20.04 LTS 上で flatpak をインストールする手順は以前の日記でメモしてあった。
_mieki256's diary - wxPython関係をUbuntu 20.04上で試用
_mieki256's diary - wxPython関係をUbuntu 20.04上で試用
sudo apt install flatpak sudo apt install gnome-software-plugin-flatpak flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo sudo reboot
◎ GIMPをインストール。 :
基本的には以下のページに従えば良い。
_GNU Image Manipulation Program - Linux Apps on Flathub
ただ、今回は、GUIアプリ上から ―― gnome-software (ソフトウェア)経由でインストールしてみた。
インストールが終了したら、インストールしたアプリの一覧を表示して確認してみる。端末を開いて以下を打つ。
中に、以下の行がある…はず。
これで、GIMP 2.10.30 がインストールされた。
_GNU Image Manipulation Program - Linux Apps on Flathub
flatpak install flathub org.gimp.GIMP
ただ、今回は、GUIアプリ上から ―― gnome-software (ソフトウェア)経由でインストールしてみた。
- スタートメニュー(?)の検索欄に「software」と打ち込んだら「ソフトウェア」がリストアップされたので起動。
- 左上の虫メガネアイコンをクリックして、「gimp」で検索。
- リストアップされた「GIMP (GNU Image...」をクリックして詳細説明(?)を表示。
- 右上の「ソース」の項目が「Flathub」になっていることを確認して、「インストール」をクリック。
インストールが終了したら、インストールしたアプリの一覧を表示して確認してみる。端末を開いて以下を打つ。
flatpak list
中に、以下の行がある…はず。
GIMP (GNU Image Manipulation Program) org.gimp.GIMP 2.10.30 stable flathub system
これで、GIMP 2.10.30 がインストールされた。
◎ GIMPを起動。 :
実行は、端末上で以下を打つ。
しかし、一々こうして打ち込んで起動するのは面倒臭い。
本来、flatpak 経由でインストールすると、スタートメニューの類にも登録されるらしいのだけど、何故か自分の環境では、メニューに登録されなかった。
ただ、メニューに登録されるべき、.desktop ファイル (Windowsのショートカットファイルみたいなもの?)は、以下の場所に存在している。
中に、org.gimp.GIMP.desktop というファイルが存在する。これを、自分のアカウントの、所定の場所にコピーする。
これで、Ubuntu (Xubuntu) のスタートメニュー(?)の、「グラフィックス」の項に、GIMPの項目が追加された。
flatpak run org.gimp.GIMP
しかし、一々こうして打ち込んで起動するのは面倒臭い。
本来、flatpak 経由でインストールすると、スタートメニューの類にも登録されるらしいのだけど、何故か自分の環境では、メニューに登録されなかった。
ただ、メニューに登録されるべき、.desktop ファイル (Windowsのショートカットファイルみたいなもの?)は、以下の場所に存在している。
ls /var/lib/flatpak/exports/share/applications/
中に、org.gimp.GIMP.desktop というファイルが存在する。これを、自分のアカウントの、所定の場所にコピーする。
cp /var/lib/flatpak/exports/share/applications/org.gimp.GIMP.desktop /home/(USERNAME)/.local/share/applications/
これで、Ubuntu (Xubuntu) のスタートメニュー(?)の、「グラフィックス」の項に、GIMPの項目が追加された。
◎ GIMPのプラグインの場所。 :
GIMP を起動してみたところ、フィルターメニューの中に、Python-Fu が存在していた。
ということで、たしかに flatpak版GIMPなら Python-Fu が使えるらしい。
また、編集 → 設定 → フォルダー → プラグイン or スクリプト、で、Python-Fuスクリプトや Script-Fuスクリプトを置く場所が指定されているはずだけど、自分の環境では、記述が無いのに、何故か以下のフォルダの内容も読み取っていた。
この2つのフォルダは、Ubuntu公式リポジトリ版の GIMP をインストールした際に参照される場所なのだけど…。でもまあ、動いてるから良しとする。
ちなみに、 *.py や *.scm に実行権限がついてないとGIMPがプラグインとして認識しない、という話もどこかで見かけたので、一応、念のため、各スクリプトファイルに対して実行権限をつけておいた。
flatpak版GIMPを導入することで Python-Fu も使えると分かったので、以下のスクリプトが動作することも確認できた。
_mieki256/sci-fi-texture-generator: Sci-Fi bump mapping texture generator with GIMP Script-fu.
以下、証拠画像。
このスクリプトが動いたということは…。flatpak版GIMP は、pycairo も使える状態になっているようだなと。Python-Fuコンソールを開いて、import cairo と打ってみても、エラーが出ないし。
pycairo の現行バージョンは 1.21.0 だけど、それと比べると、GIMP同梱の pycairo は 1.10.0 と結構古い。
また、Ubuntu公式リポジトリ版の python-cairo は、バージョンが 1.16.2-2ubuntu2 と表示されたので *1 、flatpak版GIMP には、公式リポジトリ版とは違う pycairo が含まれているのだろう。たぶん。
ということで、たしかに flatpak版GIMPなら Python-Fu が使えるらしい。
また、編集 → 設定 → フォルダー → プラグイン or スクリプト、で、Python-Fuスクリプトや Script-Fuスクリプトを置く場所が指定されているはずだけど、自分の環境では、記述が無いのに、何故か以下のフォルダの内容も読み取っていた。
~/.config/GIMP/2.10/plug-ins/*.py ~/.config/GIMP/2.10/scripts/*.scm
この2つのフォルダは、Ubuntu公式リポジトリ版の GIMP をインストールした際に参照される場所なのだけど…。でもまあ、動いてるから良しとする。
ちなみに、 *.py や *.scm に実行権限がついてないとGIMPがプラグインとして認識しない、という話もどこかで見かけたので、一応、念のため、各スクリプトファイルに対して実行権限をつけておいた。
cd ~/.config/GIMP/2.10/plug-ins/ chmod +x *.py
flatpak版GIMPを導入することで Python-Fu も使えると分かったので、以下のスクリプトが動作することも確認できた。
_mieki256/sci-fi-texture-generator: Sci-Fi bump mapping texture generator with GIMP Script-fu.
以下、証拠画像。
このスクリプトが動いたということは…。flatpak版GIMP は、pycairo も使える状態になっているようだなと。Python-Fuコンソールを開いて、import cairo と打ってみても、エラーが出ないし。
>>> cairo.version '1.10.0' >>> cairo.cairo_version_string() '1.16.0'
pycairo の現行バージョンは 1.21.0 だけど、それと比べると、GIMP同梱の pycairo は 1.10.0 と結構古い。
また、Ubuntu公式リポジトリ版の python-cairo は、バージョンが 1.16.2-2ubuntu2 と表示されたので *1 、flatpak版GIMP には、公式リポジトリ版とは違う pycairo が含まれているのだろう。たぶん。
◎ 2022/05/21追記。 :
Ubuntu Linux 18.04 LTS 上でも動作確認してみた。Ubuntu 18.04 LTS なら、公式リポジトリ版 GIMP 2.8.22 でも Python-Fu (Gimp-Python) が利用できた。また、Python-Fuコンソール上で import cairo もできた。cairo.version は '1.16.2'。cairo.cairo_version_string() は '1.15.10'。
*1: sudo apt show python-cairo と打てばバージョンが確認できる。
[ ツッコむ ]
#2 [python][gimp] Python 3 でARGBからRGBAに変換
Windows10 x64 21H2 + Python 3.9.12 64bit の環境で、ARGB(BRGA)からRGBAに変換する処理を試してみた。
ちなみに、Python 2.7.18 を使って処理する版は、 _昨日 試した。
とりあえず、Python 3.9.12 で動く処理だけ抜き出してベンチマークを取ってみた。
_05_argb_rgba_conv_py3.py
ベンチマーク結果は以下。
やはり、bytearray を使って入れ替えていく書き方は、struct.pack や unpack、リスト内包表記を使う書き方と比べると、ちょっと遅い模様。
また、Python 2.7 より 3.9 で処理するほうが、処理時間が短くなる場合もあるらしい。Python 2.7 では 1秒台だった処理が、Python 3.9 では 0.84秒になった。
ちなみに、Python 2.7.18 を使って処理する版は、 _昨日 試した。
とりあえず、Python 3.9.12 で動く処理だけ抜き出してベンチマークを取ってみた。
_05_argb_rgba_conv_py3.py
from benchmarker import Benchmarker import struct import sys # check_data_enable = True check_data_enable = False LOOP = 5 if sys.version_info.major != 3: print("This script is compatible only with Python3.") sys.exit() def create_src_data(): print("start.") r, g, b, a = 0, 1, 2, 3 w, h = 2048, 2048 rgba = bytearray(w * h * 4) for i in range(0, len(rgba), 4): rgba[i], rgba[i + 1], rgba[i + 2], rgba[i + 3] = b, g, r, a src = rgba print("create source data. %d byte" % len(src)) # for i in range(8): # print(src[i]) return src def get_rgba_str_g(src): lmax = len(src) // 4 argb = list(struct.unpack("=%dL" % lmax, src)) rgba = [(((d & 0x0ffffff) << 8) + ((d >> 24) & 0x0ff)) for d in argb] return struct.pack(">%dL" % lmax, *rgba) def get_rgba_str_j(src): cnt = len(src) dst = bytearray(cnt) if sys.byteorder == "little": for i in range(0, cnt, 4): dst[i], dst[i + 1], dst[i + 2], dst[i + 3] = src[i + 2], src[i + 1], src[i], src[i + 3] else: for i in range(0, cnt, 4): dst[i], dst[i + 1], dst[i + 2], dst[i + 3] = src[i + 1], src[i + 2], src[i + 3], src[i] return dst def check_result(src): print("compare") dst = [] dst.append(get_rgba_str_g(src)) dst.append(get_rgba_str_j(src)) for i in range(1, len(dst)): if dst[0] == dst[i]: print("Success [%d]" % i) else: print("Failure [%d]" % i) src = create_src_data() if check_data_enable: # compare result data check_result(src) sys.exit() with Benchmarker(LOOP, width=20) as bench: @bench("rgb shift G") def check_use_rgb_shift_g(bm): get_rgba_str_g(src) @bench("rgb shift J") def check_use_rgb_shift_j(bm): get_rgba_str_j(src)
ベンチマーク結果は以下。
> py -3 05_argb_rgba_conv_py3.py start. create source data. 16777216 byte ## benchmarker: release 4.0.1 (for python) ## python version: 3.9.12 ## python compiler: MSC v.1929 64 bit (AMD64) ## python platform: Windows-10-10.0.19044-SP0 ## python executable: C:\Python\Python39-64\python.exe ## cpu model: AMD64 Family 23 Model 113 Stepping 0, AuthenticAMD ## parameters: loop=5, cycle=1, extra=0 ## real (total = user + sys) rgb shift G 0.8407 0.8438 0.7344 0.1094 rgb shift J 1.4964 1.5000 1.4844 0.0156 ## Ranking real rgb shift G 0.8407 (100.0) ******************** rgb shift J 1.4964 ( 56.2) *********** ## Matrix real [01] [02] [01] rgb shift G 0.8407 100.0 178.0 [02] rgb shift J 1.4964 56.2 100.0
やはり、bytearray を使って入れ替えていく書き方は、struct.pack や unpack、リスト内包表記を使う書き方と比べると、ちょっと遅い模様。
また、Python 2.7 より 3.9 で処理するほうが、処理時間が短くなる場合もあるらしい。Python 2.7 では 1秒台だった処理が、Python 3.9 では 0.84秒になった。
[ ツッコむ ]
以上、1 日分です。