プラグインがあるおかげで手軽に機能拡張できるところは GIMP の最大の魅力のひとつといえます。 プラグインは外部プログラムでありながら GIMP の中枢アプリケーションの制御下で動作し、 両者は緊密に相互作用します。 ユーザーが[手で]行う画像操作はほとんど何でもプラグインで実行できます。 ちょっとばかりプラグインのコードを書けば、 GIMP 中枢部の膨大な量の複雑なコードに手をつけることなく、 簡単に機能を GIMP に追加できるところが強みです。 現に価値あるプラグインの大多数はほぼ 100 行から 200 行の C 言語ソースだけでできています。
GIMP には数十個のプラグインが配付版に入っていて、 自動的に GIMP と一緒にインストールされます。 それらのほとんどが 「正規化」コマンドは実際にはプラグインなのですが、 使っている人にそのことを伝えるものは何もありません。
メニュー (実はこのメニューの中身はいずれもプラグイン[もしくはスクリプト]) から呼び出せますが、 他のメニューに属するものもかなりあります。 プラグインを使うといっても十中八九はプラグインであることに気付くことはないでしょう。 たとえば色の自動補正フィルターのプラグインは GIMP 同梱のもの以外にもネット上にはもっとたくさんあります。 プラグインの中心的な貯蔵庫の役割を担う目的で設立された GIMP Plugin Registry (英語) [GIMP-REGISTRY] でならたくさん見付かるでしょう。 プラグインを制作したら誰でもここにアップロードできます。 特定の用途のプラグインを探すにもこのサイトならいろいろな検索方法が使えます。
世界中の誰でも自作の GIMP プラグインを GIMP Plugin Registry や自身のウェブサイト上で公開できますし、 数有る有益なプラグインがそうしたところから手に入ります。 この使用のてびきのどこかでもそんなプラグインのことに触れています。 しかし自由勝手さの反面で、 ある程度の危険が伴います。 誰でもできるということは実質的な品質管理が行なわれないことを意味します。 GIMP 同梱で配布されるプラグインならば開発者によるテストと調整を経ていますが、 ダウンロードで手に入る物のなかにはほんの数時間だけで捻り出してすぐ流布された代物が少なくありません。 また動作の健全さに注意を払わずに作成する者もいますし、 たとえ意識はしてもあらゆるシステムを試しあらゆる状況で何度も動作確認できるような人は限られています。 つまりどこからかプラグインをダウンロードしたら、 それは基本的にタダで得られるものである反面、 時には代償を幾許か払わなくてはならないものなのかもしれないということです。 でもダウンロードを思い止まって欲しいからこんな話をしているわけではありません。 ただ現実がどうなのか理解していただきたかったからです。
警告 | |
---|---|
プラグインはれっきとした動作可能プログラムの一種なので他のプログラムができることなら何でも実行できます。 つまり密かにバックドア (裏口) プログラムをあなたのシステムに潜り込ませたり、 他にもその安全保障を脅かすことが可能なのです。 信頼のおける配布者を通じて得たものでなければインストールしてはいけません。 |
プラグインの配布者について以上の話の要点は Plugin Registry の内外を問いません。 この登録サイトはプラグインを作成したら誰でも使える場所です。 組織立った取締りはありません。 明らかな悪意のある代物が置かれているのを管理者が気付けば、 削除の対象となるでしょう。 (まだそのような事態は起きていません。) しかしながら GIMP やそのプラグインは、 他のどのフリーソフトウェアとも同様、 無保証 です。
注意 | |
---|---|
プラグインはいつも GIMP の各バージョンの目玉でありつづけてきました。 ところがある版の GIMP のために書かれたプラグインが他の版でちゃんと使えたという例はめったにありません。 移植が必要なのですが、 簡単に済むこともあればそうはいかない場合もあります。 多くのプラグインは既にさまざまな版に対応ができています。 プラグインを導入する際には最低限それがお使いの GIMP に適合しているかどうかご確認ください。 |
だいたいいつもはプラグインだと意識せずとも他の GIMP ツールと同じように使えます。 しかし僅かですが理解しておくと便利な事柄があります。
ひとつには通常プラグインは GIMP 中枢部と比較して頑丈にはできていないといえます。 仮にも GIMP が異常終了するのは非常に深刻な事態です。 ユーザーにとっても計り知れない災厄と頭痛が襲いかかるでしょう。 一方でプラグインが異常終了した場合にその結果は通常さほど酷くはありません。 ほぼ通常はそういったことを恐れないで作業を続けられます。
注記 | |
---|---|
プラグインは分離独立したプログラムなので、 GIMP 中枢部とは特別な方法で通信を行います。 GIMP 開発者はそれを 「talking over a wire」 (有線会話) と呼んでいます。 プラグインが異常終了して通信が途絶えた時には、 「wire read error」 (通信線解読障害) を知らせるエラーメッセージが出ます。 |
ティップ | |
---|---|
プラグインが異常終了すると GIMP はあたかもそのプラグインで壊れてしまったかのように言い、 画像を保存して一旦終了するように促す非常に気味の悪いメッセージを出します。 厳密な意味では、 プラグインには GIMP のほぼすべてを改変する能力があるのでこの指摘は決して間違いではありませんが、 実際的な面でみるとそういった破壊が起きた経験は事実上ほとんど無く、 気にせずそのまま作業を続ける人が大勢です。 私たちが申し上げたいのは、 何か問題が発生したときにどの程度の影響がご自身に及ぶかをちょっと考えて被害を推し量っていただきたいということです。 |
プラグインと GIMP の通信方法には、 プラグインを実行している最中に画像の変更があってもそれを伝えるしくみがありません。 プラグインを開始してから他のツールで画像に手を加えると、 プラグインが異常終了するのがほとんどで、 仮にそうならなくても大抵は別物になり果ててしまいます。 画像に対し一度にひとつ以上のプラグインを走らせることの無いようにすべきですし、 プラグインの動作が終了するまでは絶対に画像に手をつけてはいけません。 この忠告を無視した場合は画像がめちゃくちゃになるかもしれないばかりか、 作業履歴のシステムまでめちゃくちゃになるおそれがあり、 過ちから挽回する手立てさえ失うことになりかねません。
GIMP 同梱のプラグインについては特別なインストール作業は全く必要ありません。 逆にご自身でダウンロードされたプラグインにはそれが必要です。 作業の順路はお使いの OS が何であるかや、 プラグインの構成によっていくつかに分かれています。 Linux™ をはじめ UNIX™ システム風のシステムなら新しいプラグインの導入は通常きわめて易しいものです。 Windows™ では簡単にできることもあれば非常に難しいこともあります。 いずれにせよ最良と考えられている順路は 2 つあります。
大多数のプラグインは 2 つに分類できます。 片や配布されるソースコードがたったひとつの .c
ファイルだけのものと、 対して Makefile
を含め複数のファイルを収めたディレクトリーからなる配布形態をとる大きなものです。
たとえば borker.c
と名付けられた単一ファイルのプラグインがあるとすると、 導入作業に必要なのは gimptool-2.0
というコマンドを走らせることだけです。 このコマンドでプラグインのコンパイルが行われ、 個人用プラグインのディレクトリー (初期設定どおりなら --install
borker.c
~/.gimp-2.8/plugins/
) にインストールされます。 これで次回の GIMP 起動時よりこのプラグインが自動的に読み込まれるようになります。 この作業はルートになる必要がありません。 むしろなってはいけません。 ところでもしもプラグインのコンパイルに失敗してしまっても、 これを前向きにとらえて創造的になりましょう。
プラグインのインストールができたとして、 どうすれば呼び出せるのでしょう。 どこのメニューに入るかはプラグイン自身が決定しますので、 その答えはプラグイン付属の文書 (もしあればの話です) を読むか、 画像ウィンドウメニューより プラグインブラウザー を開き、 プラグインの名前で 検索 して ツリー表示 のタブをご覧になって得てください。 それでも依然として判らない場合は、 メニューをしらみつぶしに探すかソースコードの登録動作部分 (たとえば gimp_install_procedure
) を見付けるかのどちらか簡単な方をするしかもう成す術がありません。
複雑なプラグインともなると複数のファイルがディレクトリー内にまとめられており、 その扱い方を記載した INSTALL
もしくは README
というファイルがあるはずです。 もしなければそのようなプラグインは即刻ごみ箱に放り込んで時間を節約するほうがよいと心からご忠告いたします。 どんなコードもユーザーに対する思い遣りを欠いて書かれれば無数の失望を買うようなものです。
プラグインのなかには (とくに GIMP プラグイン用雛形をもとに作成されたものは) GIMP の個人用ディレクトリーではなくシステム用のディレクトリーに導入することを前提にしているものもあります。 これらにおいては最後の導入の段階 (つまり make install を実行する段階) でルートになって作業する必要があるでしょう。
個人用のプラグインディレクトリーに入れる場合で、 そのプラグインの名前と同じものがシステムディレクトリーにもあると、 読み込まれるのはひとつだけ、 ホームディレクトリーにある方になります。 このことを GIMP は起動時に毎回知らせてくるはずです。 このような状況は避けたほうがよいでしょう。
Windows™ は UNIX™ 系のシステムと比べるとソフトウェアを構築するには随分と問題の多い環境です。 たとえば適切な Linux™ ディストリビューションならばいずれもコンパイル関係のツールが一式揃っていて、 その動作の状況はどれも非常によく似ているのに対し、 Windows™ にはそういったツールが一切付いてきません。 Windows™ でもソフトウェア構築の良好な環境を整えることは可能ですが、 それにはかなり多額の費用をかけるか、 もしくはたいへんな努力と知識を積む必要があります。
このことが GIMP プラグインと関わるとどういう意味があるかを、 ソフトウェア構築の環境が整っている場合とない場合に分けて見てゆきましょう。 コンパイル環境がない場合はコンパイル済みのプラグインソフトウェアを探すか、 もしくは誰かに頼んでコンパイルしてもらうことになります。 そのあとは個人用のプラグインディレクトリーに収めれば完了です。 ソフトウェア構築環境 (その目的からして GIMP をビルドできる環境とも言える) がある場合には、 こういったことは既にかなりご存知のはずですから、 Linux の方法に従っていただくだけで十分です。
プラグインを OS X にインストールする方法はどのように GIMP 自身をインストールしたかにかなり依存します。 もし darwinports [DARWINORTS] (現在の macports) や fink [FINK] のようなパッケージマネージャーを通じて GIMP を導入する勇者の仲間に入るつもりならば、 プラグインの導入はまさに既に UNIX 系の説明で述べた方法でできます。 たったひとつの違いは、 パッケージマネージャーのレポジトリーでもプラグインが 2 つ手に入るということですので、 試してみてはいかかでしょうか。
それとは逆に GIMP.app のような一発インストールが可能な GIMP パッケージを好むユーザーならば恐らくコンパイル済みのもの一本に絞りたいのではないかと思います。 つまりプラグインの作者からコンパイル済みのパッケージを入手できたらとの考えではないかと思うわけですが、 この方法には賛成しかねます。 先に触れたパッケージマネージャーがバイナリー実行ファイルをビルドする際に GIMP のインストールも実施するはめになるからです。
プラグインの書き方を学ぶ際に GIMP の開発者用ウェブサイト [GIMP-DEV-PLUGIN] (英語) をご覧になれば豊富な手掛かりがつかめます。 GIMP は複雑なプログラムですが、 開発チームはプラグインが書けるまでに学ぶべきことの壁ができるだけなだらかになるように奮闘しています。 既に優れたてびきや例がありますし、 プラグインが GIMP と交信するためのライブラリー (「libgimp」という) には十分に文書化された API があります。 既にあるプログラムを改変するところから学ぶ優れたプログラマーなら、 ほんの一両日中のうちに何か面白いことができてしまう場合が少なくありません。