AOISAKURA - 日記(編集)

日記本文

年月日

タイトル:

本文(tDiaryスタイル/書き方):

[gimp][translation] how to write a GIMP plug-in 勝手和訳 3P目
<a href="http://wataru.aoisakura.jp/tdiary/?date=20051112">前回の2P目の和訳</a>からえらい間が空きましたが、<a href="http://developer.gimp.org/writing-a-plug-in/3/index.html">How to write a GIMP plug-in 3P</a>の和訳です。訳出の意図、注意は<a href="http://wataru.aoisakura.jp/tdiary/?date=20051022#p01">1P目同様</a>です。
コードについてはプロトタイプ宣言だけは載せていますので、コード全体は原文を適宜参照してください。
この和訳文書は<a href="http://creativecommons.org/licenses/by-nc-sa/2.5/">creative commons : 帰属 - 非営利 - 同一条件許諾 2.5</a>でライセンスされてます。
<%=ul <<LIST
<a href="http://wataru.aoisakura.jp/tdiary/?date=20051022">How to write a GIMP plug-in私的和訳 1P目</a>
<a href="http://wataru.aoisakura.jp/tdiary/?date=20051112">How to write a GIMP plug-in私的和訳 2P目</a>
LIST
%>

GIMPプラグインの書き方 How to write a GIMP plug-in 3P目
原著者: Dave Neary(bolsh@NOSPAM.gimp.org)
第二章で、私はピクセル単位か行単位での画像データ(image data)の操作を説明した。今回は、さらに進めて、今までに作ったプラグインの性能を改善させられるタイル単位でのデータ処理を行う。また、より大きな半径を配慮したアルゴリズムへの改良を行い、パラメータを変更させることができるようなグラフィカルインターフェイスの構築も行う。

はじめに
前に作った単純なアルゴリズムを確認してみよう。このアルゴリズムは、ピクセル単位で、各レイヤーに(2r+1)x(2r+1) - x,yの形式、rは半径 - の近傍を設定し、その近傍の平均でレイヤーの各ピクセルを置き換えるモノであった。
例の画像で画像の境界で注意を払わなければいけないのはいささか複雑ではある。しかしこのアルゴリズムによるブラー処理は一般的にそれほど悪くはない。
とはいえ、今まで書いてきたアルゴリズムは3x3近傍ピクセルを対象とした処理であった。この章では、対象とする範囲を一般化し、パラメータとして近傍の範囲を取得するようにする。
まずはタイルについて。

タイルの管理
タイルとはサイズ64x64ピクセルの画像データブロックです。通常タイルはプラグインに対して一つ一つ要求に応じて、共有メモリから送られます。もちろん、この処理は大量の資源を必要とし避けるべきである。
普通、特定のキャッシュを必要とすることはない、どのタイルも必要とされたとき送られ、他のタイルが呼ばれれば、開放される。それでもなお、以下の関数を使うことによって、一定間隔で回ってくるround tripを避けてプラグインにタイルキャッシュを保持させることができる。
<pre>gimp_tile_cache_ntiles (gulong ntiles);</pre>
part2の例では、gimp_pixel_rgn_get_row()とgimp_pixel_rgn_set_row()を呼び出したが、キャッシュを使うことはしなかった。
タイル列一列のタイルの数は、タイルの幅でレイヤーの幅を割った数に1足した数となるだろう。そのため、レイヤーの幅が65の場合、我々は二つのタイルをキャッシュすることになる。通常シャドウタイルも処理するので、プラグインの扱うキャッシュのサイズは倍にしている。
<pre>
gimp_tile_cache_ntiles (2 * (drawable->width / 
 gimp_tile_width () + 1));
</pre>
キャッシュによって遅かったプラグインは早くなった。300x300の画像上では、最新のブラー処理は3秒かかった。しかし、2000x1500の画像上では遅くなり、142秒かかった。
上記のコードを追加することで、処理速度は向上し、11秒で終了した。我々はまだタイルの変わり目での変化に要する時間を失っている。2行分のタイルキャッシュを取得する変わりに4行分取得するようにしたら、10秒まで減らすことができた。ある点を堺に処理時間の増加を減らすことができたが、より多くのキャッシュを必要とするようになり、またさらなるハードディスクへのアクセスを発生させることになった。

アルゴリズムの一般化
半径パラメータを考慮するために、アルゴリズムを修正しよう。半径が3の場合、ピクセル近傍は7x7とし、半径1の場合は3x3とする。これを実現するために、以前のアルゴリズムを次のように修正する。
<ul>
<li>2r+1(rは半径)個のタイルの列に必要な領域を割り当てる</li>
<li>境界に注意しながら、タイルの配列を初期化する。</li>
<li>一つ一つの行にたいして以下の処理を行う
 <ul>
 <li>行の各ピクセルにたいして以下の処理を行う
 <ul>
 <li>境界に注意しながら、近傍の平均を計算する。</li>
 </ul>
 </li>
 <li>新しい行を取得し、行の配列を回す。</li>
 </ul>
</li>
</ul>
このアルゴリズムは一つ前のよりも複雑である、なぜなら平均の計算時間がO(r^2)のアルゴリズムだからである。
このように動作するよう修正されたソースコードを以下に示す。ほとんどの処理は、process_row()関数内で行われる。init_mem()関数とshuffle()関数はブラー処理のソースコードをきれいで小さく保つ。
<pre>
static void blur (GimpDrawable *drawable);
...
static void blur (GimpDrawable *drawable) { ... }
static void init_mem (guchar ***row, guchar **outrow, gint num_bytes) { ... }
static void process_row (guchar **row, guchar *outrow, gint x1, gint y1, 
 gint width, gint height, gint channels, gint i) { ... }
static void shuffle (GimpPixelRgn *rgn_in, guchar **row, gint x1, gint y1,
 gint width, gint height, gint ypos) { ... }
</pre>

グラフィカルなインターフェイスの追加とパラメータの保存
ユーザが半径を修正しようとするために、もしくは対話的で無いスクリプトにパラメータとして値を渡す場合、run()関数へ戻る必要があり、それは単純なスクリプトでできる。
まず我々は、オプションを保存し返すことができる構造体を作成する。たいてい、これは一つだけパラメータをもつプラグインの為に使われる。
<pre>
typedef struct {
 gint radius;
 } MyBlurVals;
//
/* Set up default values for options */
static MyBlurVals bvals = {
 3 /* radius */
 };
</pre>
次に、execution modes(実行モード)を考慮するためにrun()関数を修正する。interactive mode(対話モード)や、一つ前のフィルタを繰り返すモードにおいて、われわれはgimp_get_data()関数で利用された値を取得しようとした。この関数は一番最初に入力パラメータとして一意なデータ識別子を提供してくれる。たいてい、プロシージャ名を使う。
最終的には、対話モードで、オプションを修正するためのグラフィカルインターフェイスを構築するための数行を追加した。
<pre>static void run (const gchar *name, gint nparams, const GimpParam *param,
 gint *nreturn_vals, GimpParam **return_vals) { ... }</pre>

グラフィカルなインターフェイス
私は、GTK+プログラミングの詳細は詳しくない、GTK+プログラミングについては他の素晴らしいサイトを参照してくれ。まず最初に試したのは非常に単純なものだ。GIMPのウィジェットユーティリティを使い、ヘッダーを持つウィンドウをGimpDialogで作成し、数値を制御する(GtkAdjustmentと関連付けられた)GtkSpinButtonも作り、そしてGtkFrameでラベルを作成した。
以下のパートでは、このような作業がどれだけ簡単にできるかを示すために、パラメターの効果をリアルタイムに示すプレビューダイアログを追加する。
最終的に、Gladeのツリー表示パネルで以下のように表示される程度になった。
<%=image 4,'Glade tree', nil, [512]%>
GIMP2.2で、GNOMEヒューマンインターフェイスガイドラインに沿って、首尾一貫した振る舞いを行うように考慮された、パラメータを伴うウィジェットが存在する。GimpPreviewは2.2から現れた、とりあえずそれを使わない版を作ってみる。
<%=image 1,'Blur Dialog', nil, [512]%>
<pre>static gboolean blur_dialog (GimpDrawable *drawable) { ... }</pre>

GimpPreviewの追加
GimpPreviewを追加するのは本当に簡単だ。最初に、gimp_drawable_preview_new()関数を使ったGtkWidgetを作成する。その時、無効化シグナル(<a href="http://wataru.aoisakura.jp/tdiary/?date=20060327#p12">訳者注</a>)をこの関数に設定し、プレビューが更新される度にblur()関数を呼ぶようにする。また、MyBlurValsにプレビューが有効かどうかを覚えておくための第二引数を追加する。
簡易的なプレビューの更新方法とは、プレビューパラメータをblur()関数内に追加することです。そして、プレビュー引数がNULLでないなら、限定的にGimpPreviewを行う。そして、run()関数からblur()関数を呼ぶ場合、プレビューパラメータはNULLに設定する。
限定的なGimpPreviewを行う為に、gimp_preview_get_position()とgimp_preview_get_size()を利用する。これで表示されている箇所だけにぼかし処理をかけることができる。
最適な方法に到達するには、コードのいくらかを調整しないといけない。例えば、プレビュー生成時はプログレスバーの更新は必要ないし、GimpPixelRgn初期化時、タイルキャッシュがコアに送り返さないようにさせる。
最終的に、gimp_drawable_preview_draw_region()によって更新されたプレビューを表示させる。プラグインの効果をリアルタイムに表示するダイアログボックスを得られる。さらには、GIMPコアのおかげで既にこのプラグインは選択領域も考慮できているからだ。
<%=image 2,'改良されたダイアログ', nil, [512]%>
<%=image 3,'選択領域のぼかし', nil, [512]%>
<pre>
static void blur (GimpDrawable *drawable, GimpPreview *preview) { ... }
static gboolean blur_dialog (GimpDrawable *drawable) { ... }
</pre>
<a href="http://developer.gimp.org/writing-a-plug-in/3/myblur3.c">タイルキャッシュ処理</a>、<a href="http://developer.gimp.org/writing-a-plug-in/3/myblur4.c">UI</a>、<a href="http://developer.gimp.org/writing-a-plug-in/3/myblur5.c">プレビュー処理</a>についてはそれぞれのコードを見てくれ。

まとめ
この記事では、我々はいくつかのGIMPプラグインの側面を基本的な概念を見てきた。単純なアルゴリズムによる画像データの処理を行ってきた、そしてパフォーマンス問題をどのようにして避けるべきなのかという道を示した。最終的に我々はアルゴリズムを一般化し、パラメータを追加し、GIMPウィジェットを良いユーザインターフェイスにするために使った。

謝辞
この記事を書いている間中、私を助けてくれた妻AnneとDavid Odinへ感謝する。

[gimp] ぐっちゃぐちゃ
体裁がぐっちゃぐちゃなんで、どうにかしたい。っていうかやっぱり、翻訳支援ツールとか使ってみるべきだった。後、語尾もですます調にするべきだったなぁ。
さて、次はどうするべか。ってせっかく訳したんやし何かPlug-inを作ってみんとなぁ、調べたことが無駄になる...。

[gimp] 「invalidated signal」について
<a href="http://developer.gimp.org/api/2.0/libgimp/GimpDrawablePreview.html#gimp-drawable-preview-new">gimp_drawable_preview_new()</a>では、<a href="http://developer.gimp.org/api/2.0/libgimpwidgets/GimpPreview.html#GimpPreview-invalidated">invalidated signal</a>というシグナルが定義されていて、最初何の意味かさっぱりわからなかった。
「無効化されたシグナル」とか直訳して、”シグナルを無効化する関数があるんかなぁ”とか思ったけども、どうやら違うらしい。っていうかそれじゃあ意味が通らないし。
invalidateはGUIプログラミングでupdateやrepaintと同じ再描画に関する信号としてよく使われる名前のようで、<a href="http://www.kanazawa-net.ne.jp/~pmansato/WinApps.htm">「描画した効果がなくなった」</a>ことを示すシグナルだということでした。windowsでのゲームプログラミングの記事で<a href="http://www.itmedia.co.jp/enterprise/0307/04/epn23_7.html">その名前が確認</a>できました。
というわけで、上記の文章でinvalidated signalが表れた箇所は、再描画の必要がある際、invalidated signalが発行されるとblur()関数を呼ぶようにしている。

[life] アームレストの高さ調節は必要だったかどうか
<%=image_left 0,'アーロンチェアBタイプスタンダード', nil, [512]%>
土曜日に机、棚よりも一足早くやってきました、アーロンチェア。一番安い、スタンダードですが、大方問題無し。アームレストの高さ調節がスタンダードではできないので、腕の行き場所に悩みました。しかし、思いっきりリクライニングさせてキーボードに手を伸ばすとそもそもアームレスとが机の下に隠れる上、腕が机に完全に乗っかってしまったので問題解決。
前傾姿勢ではないので座っている間、足に全然力がかかりません。おかげで、立ち上がるとき体を重く感じます(何

[opensource][translation] OSC2006の翻訳BOFより OSSにおける翻訳
<%=ul <<LIST
<a href="http://d.hatena.ne.jp/kazama/20060318/p1">OSSにおける翻訳</a>(Cafe Babe)
LIST
%>
現状まぁそんなもんなんだろうなぁって感じはするけど、「一般的にOSS翻訳は軽視されており」ってのはどうなんだろ。debianやFedoraでは翻訳に関するMLがあったりするし、GNOME、KDE等にしても翻訳が軽く見られているなんて思えないんだけどなぁ。まぁ思えないってだけで中がほんとはどうなのか見たことないからなんともいえんが。
この発表をされてる樋口さんってSunで翻訳スタイルガイドを策定された人かな。ここんとこオープンソースな翻訳支援ツールもいくつかあるんで、これから試してみたい。
いつまでも質の低い和訳を垂れ流す訳にもいかんしのぅ。

更新情報を送る

この日の日記を隠す

AOISAKURA - 日記 [登録]

日記の更新

日記本文