プラグインは機能拡張の手軽さで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.6/plugins/
) にインストールされます。 これで次回のGIMP起動時よりこのプラグインが自動的に読み込まれるようになります。 この作業はルートになる必要がありません。 むしろなってはいけません。 ところでもしもプラグインのコンパイルに失敗してしまっても、 これを前向きにとらえて創造的になりましょう。
プラグインのインストールができたとして、 どうすれば呼び出せるのでしょう。 どこのメニューに入るかはプラグイン自身が決定しますので、 その答えはプラグイン付属の文書 (もしあればの話です) を読むか、 画像ウィンドウメニューより 「プラグインブラウザ」を開き、 プラグインの名前で 検索 して ツリー表示 のタブをご覧になって得てください。 それでも依然として分からない場合は、 メニューをしらみつぶしに探すかソースコードの登録動作部分 (例えば gimp_install_procedure
) を見付けるかのどちらか簡単な方をするしかもう成す術がありません。
複雑なプラグインともなると複数のファイルがディレクトリ内にまとめられており、 その扱い方を記載した INSTALL
もしくは README
というファイルがあるはずです。 もしなければそのようなプラグインは即刻ごみ箱に放り込んで時間を節約するほうがよいと心からご忠告いたします。 どんなコードもユーザーに対する思い遣りを欠いて書かれれば無数の失望を買うようなものです。
プラグインのなかには (とくにGIMPプラグイン用雛形をもとに作成されたものは) GIMPの個人用ディレクトリではなくシステム用のディレクトリに導入することを前提にしています。 これらにおいては最後の導入の段階 (つまり make install を実行する段階) でルートになって作業する必要があるでしょう。
個人用のプラグインディレクトリに入れる場合で、 そのプラグインの名前と同じものがシステムディレクトリにあると、 読み込まれるのはひとつだけ、 ホームディレクトリにある方になります。 このことをGIMPは起動時に毎回知らせてくるはずです。 このような状況は避けたほうがよいでしょう。
Windows™ は UNIX™ 系のシステムと比べるとソフトウェアを構築するには随分と問題の多い環境です。 たとえば適切な Linux™ ディストリビューションならばいずれもコンパイル関係のツールが一式揃っていて、 その動作の状況はどれも非常によく似ているのに対し、 Windows™ にはそういったツールが一切付いてきません。 Windows™ でもソフトウェア構築の良好な環境を整えることは可能ですが、 それにはかなり多額の費用をかけるか、 もしくはたいへんな努力と知識を積む必要があります。
このことがGIMPプラグインと関わるとどういう意味があるかを、 ソフトウェア構築の環境が整っている場合とない場合に分けて見てゆきましょう。 コンパイル環境がない場合はコンパイル済みのプラグインソフトウェアを探す (もしくは誰かに頼んでコンパイルしてもらう) ことになります。 そのあとは個人用のプラグインディレクトリに収めれば完了です。 ソフトウェア構築環境 (その目的からしてGIMPをビルドできる環境とも言えます) がある場合には、 こういったことは既にかなりご存知のはずですから、 Linux の方法に従っていただくだけで十分です。
構築環境の設営をしようとお考えでしかもその渦中に飛び込む勇気と覚悟をお持ちならば、 GIMP Wiki の HowToCompileGimp/MicrosoftWindows のページ [GIMP-WIKI-MS] をご覧になればそのやり方について適度に最新の記述が読めます。 もちろんこれは Wiki なので誰でも自由に編集できますから、 是非ともあなたの経験に基づくアドバイスを書き加えて、 最新情報を保つことにご協力していただきたく思います。
プラグインを OS X にインストールする方法はどのようにGIMP自身をインストールしたかにかなり依存します。 もし darwinports [DARWINORTS] や fink [FINK] のようなパッケージマネージャを通じてGIMPを導入する勇者の仲間に入るつもりならば、 プラグインの導入はまさに既にUNIX系の説明で述べた方法でできます。 たったひとつの違いは、 パッケージマネージャのレポジトリでもプラグインが2つ手に入るということですので、 試してみてはいかかでしょうか。
それとは逆にGIMP.appのような一発インストールが可能なGIMPパッケージを好むユーザーならば恐らくコンパイル済みのもの一本に絞りたいのではないかと思います。 つまりプラグインの作者からコンパイル済みのパッケージを入手できたらとの考えではないかと思うわけですが、 この方法には賛成しかねます。 先に触れたパッケージマネージャがバイナリ実行ファイルをビルドする際にGIMPのインストールも実施するはめになるからです。
プラグインの書き方を学ぶ際にGIMPの開発者用ウェブサイト [GIMP-DEV-PLUGIN] (英語) をご覧になれば豊富な手掛かりがつかめます。 GIMPは複雑なプログラムですが、 開発チームはプラグインが書けるまでに学ぶべきことの壁ができるだけなだらかになるように奮闘しています。 既に優れたてびきや例がありますし、 プラグインがGIMPと交信するためのライブラリ (「libgimp」という) には十分に文書化されたAPIがあります。 優れたプログラマは既にあるプログラムを改変するところから学び、 ほんの一両日中のうちに何か面白いことができてしまう場合が少なくありません。