tabstop @Wiki

MixBrushパッチ

2011-12-08T02:40:02+09:00

*これは何をするものか gimpのブラシツールに混色機能を追加するためのパッチです。混色機能のついたペンをMixBrushと呼んでいます。混色ブラシの技術的な内容は[[Mixbrushパッチ/アルゴリズム比較]]にあります。 &image(mix-brush-test-071008-3.jpg) &image(mix-brush-test-071008-2.jpg) &image(mix-brush-test-071009-1.jpg) SAIやNekoPaintのブラシツールの設定項目を眺めながら作ったので、多分同じような効果になっていると思います。設定をいじってやると、SAIの水彩筆や筆ツールのような効果が出てくるはずです。挙動はちょっと違うかもしれませんが...... *ライセンス gimpのソースコードの派生物なのでGPLです。 *ダウンロード [[SourceForgeのプロジェクトサイト>http://sourceforge.jp/projects/gimp-painter/]]からダウンロードしてください。 ***テスト環境 **2.2系列のテスト環境 - ubuntu 07.04 (Feisty Fawn) -- OSは関係いはず。 - gimp-2.2.17 (本家よりダウンロード) - diff -uNrでパッチ作成 - ./configure --disable-print でテスト(gutenprint非対応?だから) **2.4系列のテスト環境 - ubuntu 07.10 (Gusty Gibbon) -- OSは関係いはず。 - gimp-2.4.1 (本家よりダウンロード) - diff -uNrでパッチ作成 - ./configure ; make; sudo make installでテスト ***パッチ適用方法 gimpのソースコードを展開 (例えばtar jxf gimp-2.2.17.tar.bz2 など) cd gimp-2.2.17 patch -p1 < <パッチのディレクトリ>/gimp-パッチ名.diff ./configure [オプション: 2.2では--disable-print] make make install #ルート権限必要 *使い方 -道具箱パレットに"MixBrush"が追加されます。(アイコンは絵筆と一緒。) -ブラシツールと同じように使います。 -筆で線を引くと、下地の色が徐々に混ざります。 --設定によっては、筆圧に応じて混ざり具合が変わります。 -ツールオプションに"Canvas Color"、"Original Color"という項目が追加されます。各オプションの意味は次のとおり。 ***Canvas Color |"Rate(割合)" |下地の色を足す割合です。値が大きいほど、下の色を拾って混ぜるようになります。| |"Pressure(圧力)" |筆圧に応じて下地の色を混ぜる割合を変化させます。Pressureの値が大きいほど、混ぜる割合が筆圧によって変化します。| ***Original Color |"Rate(割合)" |前景色を足す割合です。値が大きいほど、パレットの色を塗り込むようになります。Canvas ColorのRateの方が優先度が高いため、Original ColorのRateを大きくしてもCanvas ColorのRateが強いと色が出ません。| |"Pressure(圧力)" |筆圧に応じて前景色を混ぜる割合を変化させます。Pressureの値が大きいほど、混ぜる割合が筆圧によって変化します。Pressureの値がRateより大きい場合、ある閾値以下の筆圧では前景色をまったく足さなくなります。他のツールで”ぼかす”と読んでいる状態になります。| *Tips -不透明度が高いと、あまり上手く混色してくれません。不透明度=50くらいにして、圧力感度の不透明度のチェックをはずすくらいの設定がいいと思います。 -Original ColorのRate値を0.5以下にして、Pressureを0.5〜0.8くらいにすると、水彩っぽい感じになります。 -Canvas Color,Original ColorのPressureを0にすると、しぃお絵描き掲示板の"水彩2"のような効果になります。 *既知のバグ - 透明レイヤーで使うと黒くなってしまう。→にじみツールと同じ理屈です。一回白で塗りつぶしてから全部を消去すると白が混ざるようになります。 -- 071029版より修正しました。 *ソースコード - やっていることはG-penと大差ありません。すごく簡単です。 *コメント・フィードバック - 時期が時期だけに、2.4 rc3に実装した方がよいのでは、とも思うのですが……。 &br()週末暇があったら移植してみます（2.2系はもはや使う気にならないので）。 -- やまかわ (2007-10-12 03:47:48) - ＞既知のバグ &br()＞透明レイヤーで使うと黒くなってしまう。→にじみツールと同じ理屈です。 &br() &br()これってまで修正されていませんでしたか。 &br()http://bugzilla.gnome.org/show_bug.cgi?id=70335 &br() &br()あとこれ見てColor Jitterを思い出しました。 &br()http://adrian.gimp.org/patches/gimp-color-jitter/ &br() &br()# こういうのがあるとますますpluggable toolが欲しくなりますね -- いっちー (2007-10-12 16:42:05) - >やまかわさん &br()2.4には、手元の環境が移行できるようになったら &br()移ろうと思ってます。 &br() &br()>いっちーさん &br()どうやら、個別に注意してねっていう雰囲気のようです。 &br() &br()pluggable toolは、APIをクリーンアップしたいって言ったっきり &br()お蔵入りしちゃってますね。 &br()作る側としては、Gimpの内部構造をそのまま見せてでも継続して欲しかったんですけどね。 -- しげっち (2007-10-14 00:57:04) - 先にブログの方でコメント残してきてしまいましたが、2.4-rc3への移植をやってみました。これで自分も遊べます;-) &br()Wikiの方から先にチェックするという方のために、一応こちらにもWindowsバイナリのアドレス書いておきます。 &br()http://cue.yellowmagic.info/files/gimp-2.4.0-rc3-gpen+mixbrush_bin_win32.7z -- やまかわ (2007-10-14 11:54:03) - パッチをアップロードしました。 &br()http://preview.tinyurl.com/27xgqu &br()多少修正をしているのでバイナリも更新されています。 &br()http://preview.tinyurl.com/26bkll &br()バイナリの方に入っているreadmeファイルはこちらに。 &br()http://preview.tinyurl.com/27455q -- やまかわ (2007-10-15 03:55:31) - Painterのにじみ（Bleed）のような効果のテストです。 &br()とりあえず2.4-rc3のWindows用バイナリをアップしました。 &br()説明は前回のreadmeを差し替えましたのでそちらを読んでみてください。 &br() &br()例によってパッチはまた後ほど……。 &br() &br()http://preview.tinyurl.com/355t43 -- やまかわ (2007-10-18 20:19:54) - パッチの準備ができたのでアップロードしました。 &br()http://preview.tinyurl.com/387qfm -- やまかわ (2007-10-19 01:46:07) - やまかわさん、パッチ拝見しました。 &br()レイヤ結合色をとってくる方法とか、計算の丸め誤差を残しておくところとか参考になります。 &br() &br()071008-1のcanvas_color_rateで混色をした色は、 &br()次回のペイント色に繰り越すんで、実はこのパラメータは &br()PainterのBleedと同じ働きをします。 &br()ちょっとPainterを調べてみましたけど、 &br()・Resat=original_color_rateとoriginal_color_pressure_rate &br()・Bleed=canvas_color_rateとcanvas_color_pressure_rate &br()と同じ感覚です。 &br()やまかわさんのBleedは混色前のクローンレイヤと混ぜてますよね。 &br()これも面白いですね。 &br() &br()白を混ぜるっていうのは、背景色を混ぜるとかにした方が &br()汎用的かもってちょこっと考えてます。 &br() &br()Ubuntuが新しくなってGIMP 2.4が動きそうなので、 &br()そろそろ移行も考えながらまとめたいですね。 -- しげっち (2007-10-21 01:29:17) - ひょっとしたらPainterもバージョンによって違うかもしれませんが、 &br()効果の内容が違うような気がします。 &br()厳密に一致していないですが、手持ちの10.1で挙動を見る限りは、 &br()Resat->canvas_color_rate &br()Bleed->Bleed &br()の方が近いように感じます。 &br()例えば、PainterでResat=0のときと、MixBrushでcanvas_color_rate=0のときとでは &br()Bleedの効果の出方はだいぶ似ています（ややこしくなるので、不透明度は100％に &br()固定して試してみてください）。 &br()特に、Bleed=0のとき最初に置いた描点のカラーを引きずり続けるところに注目して &br()ください。 &br()Painter上で色々試してみた結果としては、やはり最近の描点（ストロークではなく）を &br()置く前のカラーを拾えないと（Painterの）Bleedの効果は出せないと思います。 -- やまかわ (2007-10-21 02:13:06) - あと、Painterの"塗料（Well）"のところにはoriginal_color_rateにあたるパラメータはなさそうですね。 &br()内部的に同様の処理をしているとは思いますが、値は固定か自動で決まるのかもしれません。 -- やまかわ (2007-10-21 02:23:16) - >MixBrushでcanvas_color_rate=0のときとでは &br()1.0の間違いです。すみません。 -- やまかわ (2007-10-21 02:28:05) - Painterは文献見ているだけなので、実験的にはわかりません。 &br()手持ちの実感を持って比べてもらえているようなので心強いです。 &br()http://wiki.cgsociety.org/index.php/Creating_a_Smeary_Oil_Brush_in_Corel_Painter &br()この記事を読んでだいぶんわかりました。 &br() &br()Painterでは、実際に描画する度合と、混ぜる度合が独立しているんですね。 &br()濃く塗ってたくさん混ぜるとか、薄く塗るけどあまり混ぜないとかできるんでしょうか。 &br()いまのMixBrushは大雑把に言うと &br()・濃く塗る→混ざらない &br()・薄く塗る→混ざる &br()って感じです。実際に塗った色が次の入力になるんで、 &br()濃く塗るか、薄く塗るかで大分変わります。 &br()いまのMixBrushとはかなり考え方が違うようです。 &br()ちょっとこっちのバージョンも作ってみようかと思います。 -- しげっち (2007-10-21 02:53:51) - >濃く塗ってたくさん混ぜる &br()個人的にはそういう塗り方を好んでやるので、どうしてもPainter風の &br()動作を考えてしまうんですよね（苦笑 &br() &br()# まあ、Painterなら旧水彩をベンチマークにしている人の方が多いとは &br()# 思いますが…… &br() &br()ちなみに、現在の勝手改造版だと自分自身のストロークをにじませる &br()ことができないので、Drawableのコピーを作る代わりに遅延処理を入れる &br()やり方に切り替えているところです（Painterも遅延があります。どちら &br()かと言うとぶれ・ゆがみの補正が主目的と思われますが）。 &br() &br()それができたら、あとは筆圧の反転があればだいたい当初の予定は一通り &br()こなしたような感じですね。レイヤー結合色は何とかしたいですが、 &br()APIを十分に理解していないと無理っぽいので、現時点では諦めてます。 &br() -- やまかわ (2007-10-21 03:18:17) - なんとなく、色を拾うのがカーソル下の1ピクセルだけを混ぜる対象に &br()している現在の実装が問題の根本じゃないかと思います。 &br()このへんは迷ったところなんですけど、筆の下の平均値とか考え始めると &br()ちょっと計算量が重くてクラっときちゃいそうなんでやめちゃってました。 &br()> APIを十分に理解していないと無理っぽい &br()そうですよね…… &br()やっぱり、GimpはAPIが膨大なのがいい点で、同時に悪い点ですね。 -- しげっち (2007-10-21 03:39:00) - >1ピクセルだけ &br()まあそれはありますね。 &br()ただ、Bleedは直近の描点を絶対に混ぜてはいけないので、この事は分けて &br()考えないとアレかなあとも思います。 &br() &br()ちなみに、試してみたことがないので実際は分かりませんが、 &br()gimp_pickable_pick_color関数の引数を見る限りは、平均を取ってくれそう &br()な感じがします。 &br() &br()gboolean gimp_pickable_pick_color (GimpPickable *pickable, &br() gint x, &br() gint y, &br() gboolean sample_average, &br() gdouble average_radius, &br() GimpRGB *color, &br() gint *color_index); &br() -- やまかわ (2007-10-21 04:08:23) - Bleedの動作の変更と、透明部分のペイントで背景色が混ざるオプション、 &br()筆圧の反転、Bleedへの筆圧の適用を行いました。 &br()まずはWindows用バイナリから。 &br()http://preview.tinyurl.com/ysemlr &br() &br()同梱のreadmeファイルを読みたい方はこちら。 &br()（以前のと同じアドレスです） &br()http://preview.tinyurl.com/27455q -- やまかわ (2007-10-21 13:37:52) - >やまかわさん &br()多分、統一した場所で配る方がよいと思うので、 &br()もしよかったら、sourceforgeのアカウントをとって &br()そちらにアップロードするようにしませんか？ &br()sourceforgeのサイトの方も、コミッタがたくさんいた方が &br()心強くて助かります。 -- しげっち (2007-10-21 16:51:34) - 利用方法がよく分かっていませんが、あとで確認してみます。 &br() &br()# 自分にできる範囲のことは一通りやってしまったので、 &br()# この先はあまり貢献できない……かも。 -- やまかわ (2007-10-21 17:01:10) - sourceforgeのアカウントはとりました。 &br()次はIDをそちらにお知らせすればいいのかな。 -- やまかわ (2007-10-26 01:05:13) - はい。アカウント名を教えてもらえれば、 &br()こちらでプロジェクトに追加します。 -- しげっち (2007-10-26 20:48:52) - 2.4のパッチを試してみました。 &br()同じ効果になるはずのパラメータ(Bleed=0,Dryout=0,delay=0)でちょっと書き味が変わっちゃってますね。 &br()入りの部分で強く塗りすぎちゃっているような... &br()ちょっと調べてみます。 -- しげっち (2007-10-28 05:35:36) - 値を取ってみるとgimp_image_get_pixel_atが悪さをしているかもしれません。 &br()ちょっと手直ししてみます。 -- しげっち (2007-10-28 17:39:12) - 筆圧の適用方法をいじってしまったからですね。 &br()先ほど10月29日版をsourceforgeの方に置いておきましたが、 &br()そちらは元に戻してあります。 -- やまかわ (2007-10-29 04:34:47) - ちゃんとした検証をしていないのでこちらだけに置きますが、 &br()いろいろ取り込んだ2.4用パッチを追加しました。(ページ下部からダウンロードできます) &br()いろいろと変わってしまっているので、後からドキュメントを作ります。 &br()とりあえず、内部の処理をすべてGimpRGBに切り替えたので、 &br()誤差の問題とかgimp_pickable*の問題とか、直っているはず（というか、考える必要がない）です。 &br() -- しげっち (2007-10-29 05:11:32) - 下のパッチは、"paint the tail stroke"が未実装です。 &br()それと、"remove color"の背景色が白限定になっています。 &br()時間がとれたら直します。 &br()（白か背景色をstartで取得してGimpMixbrushに保存するようにします。) &br() -- しげっち (2007-10-29 05:15:57) - 10/29版のドキュメントを[[Mixbrushパッチ/アルゴリズム比較]]に載せました。 -- しげっち (2007-11-04 04:05:10) - べっ、べつにあんたなんかに興味は無いんだからね！d(´∀｀*)グッ♂ http://ktjg.net/ -- 名無し (2011-12-08 02:40:02) #comment(vsize=2,nsize=20,size=40)

GEGL/GEGLとGIMP

2009-06-07T21:25:06+09:00

*GEGLとGIMP SVGみたいなおもしろい構造をもつGEGLですが、ではGEGLとGIMPはどのように連携するのでしょうか？ **GIMP(svn rev25323版) 直近の開発では、GEGLの目的はとりあえず置いといて、まずは簡単にGEGLを使うようになっています。ズバリこうです。 #image(gegl3.jpg) 漢らしいです。これまでのGIMPのコアとGEGLを併存させるために、これまでの画像バッファ管理をしているTileManagerからGEGLの内部バッファにデータをコピーしてからGEGLの処理を実行しています。そして、その結果をTileManagerに戻しています。実に2倍のワーキングセットが必要となります。そして、GEGLのノードは保存せずに捨てます。漢らしいです。 #comment

GEGL/GEGLの基礎

2009-06-07T21:24:46+09:00

*GEGLの基礎 **はじめに GEGLは次期GIMPの画像操作のコアとなるライブラリです。 GEGLはたくさんの色空間への対応、編集をあとから何回でも調節できる非破壊編集などの特徴を備えています。が、GEGLはこれまでの一般的な画像操作ライブラリとはかなり考え方が異なる構造になっています。勉強ついでに、GEGLがどういうものかを自分でわかった範囲でまとめてみたいと思います。 **GEGLことはじめ普通、画像を操作するライブラリでは「画像データ」と「画像データに対するフィルタなどの操作」が中心になります。ライブラリにとって、 -画像データにいかに効率的にアクセスできるか -汎用的なアルゴリズムが描けるか -アンドゥのメモリを効果的に削減できているかなどが重要な点になります。しかし、GEGLはすでにここから考え方が違います。GEGLでは「画像データ」はライブラリを使う人には見せません。「画像データに対する操作」だけを見せます。イメージ的には、script-fuを使うのに似ています。ライブラリのユーザはscript-fu(見たいなデータ構造)を作ってGEGLに渡しておき、あとで結果を見たくなったときに、GEGLに描画要求を出します。 GEGLは描画要求があったときにデータを見て画像に操作を加えます。描画結果を適当な1枚の画像に書き出したり、ファイルに保存したりします。この操作はすべてオンデマンドで実行されます。もしかすると、毎回全体の絵を再描画するかもしれませんし、一度加工した結果をキャッシュとして保存しておいて高速に表示するかもしれません。ライブラリのユーザはそのポリシーを決めることは出来ません。すべてGEGLに任されています。 **GEGLの構造ライブラリのユーザは、ちょうどgimpに対してscript-fuとpluginを書くのと同じように、GEGLに対してGEGLNodeとGEGLOperationを作って使います。 GEGLNodeはDAG(有向非循環グラフ)と呼ばれるデータ構造です。DAGは木構造と似ていますが、複数のノードが１つの子ノード、親ノードを共有しても良い点が異なります。 GEGLNodeは画像データに対する変更操作(Operation)を表すグラフです。複雑な構造を持った変更履歴と考えることもできます。 GEGLのオペレーションは、Source/Filter/Composer/Sinkの４つが基本となっています。 #image(gegl1.jpg) -Source --Sourceはファイルや他の画像データを画像にロードする操作です。 -Filter --Filterはその名のとおり、画像に対するフィルタです。"input"から渡された画像に加工をして"output"に結果の画像を渡します。 -Composer(合成) --２つの画像を合成する操作です。"input"と"aux"から渡された画像を合成して"output"に結果の画像を渡します。GEGLでは、レイヤーも数ある合成操作の１つとしてみなされます。 -Sink --加工した画像をファイルや他の画像データにセーブする操作です。それぞれのオペレーションはパイプラインのように数珠つなぎにすることが出来ます。通常は、Sourceオペレーションでデータを読み出してFilter/Composerで変更し、Sinkオペレーションでデータを書き出します。例えばこんな感じです。 #image(gegl2.jpg) 「データ構造を作っておいて、最後に一括して処理する。」なんだかHTMLやSVGみたいな感じです。 #comment

G-Penパッチ/アルゴリズム比較

2009-06-07T21:24:06+09:00

*アルゴリズム比較いくつかの方法の有効性を調べてみました。ちなみに、このページの元データとデータ加工のためのスクリプトはこのページの最下段の「添付ファイル」にある"lines3.txt.gz"と"lines.rb"です。 #実行 ruby lines.rb 関数名 < lines3.txt > 出力ファイル名 #グラフ化 (出力ファイル=lines-move_avg.txtの場合) gnuplot > set terminal postscript eps color enhanced solid > set size square > set output 'lines3.eps' > plot 'lines3.txt' using 1:(-$2) title "base" with lines 9 > set output 'lines3-dots.eps' > plot 'lines3.txt' using 1:(-$2) title "base" with points ps 0.3 > set output 'lines-move_avg.eps' > plot 'lines-move_avg.txt' using 1:(-$2) title "moving-avg" with lines 4 > set output 'lines-move_avg-comp.eps' > plot 'lines3.txt' using 1:(-$2) title "base" with lines 9, \ 'lines-move_avg.txt' using 1:(-$2) title "moving-avg" with lines 4 とかやると結果が出てきます。単純にgnuplotの形式で"x y velocity"が並んでいるだけなので、いろいろいじってみると楽しいかもしれません。 **元絵まずはベースとなる絵を用意します。フリーハンドで適当に描いてみて、そのときのインクのモーションを全部ファイルに落としておきました。 &ref(lines3.png) イベントで拾った点を見てみると...... &ref(lines3-dots.png) -入りの部分は大体細かく点が並んでいます(慎重に描いているようです) -抜きの部分はゆっくりにはなりますが、入りよりは速度が速いことが多いです。 -顔の輪郭、目、頭部、腰のラインなどの形を気にするところはゆっくり描いています。大体、ゆっくり描いたところがブレてます。力が入るから筋肉が震えてるんでしょうか。ともかく、こういうところはちゃんと補正してあげたくなります。 **単純移動平均元絵を一番簡単な移動平均で補間するとこんな感じになります。 (2007-08-16版) ***パラメータ |履歴長|20| ***結果 #image(lines-move_avg.png) #image(lines-move_avg-comp.png) いろんな方法の比較のポイントはこんなところでしょうか。 +顎のライン:手ブレをしているラインが綺麗になるか。 +後頭部のライン:手ブレをしているラインが綺麗になるか。 +右側の線:手ブレをしているラインが綺麗になるか。 +眉毛、二重まぶたの線: ちゃんと最後まで伸びているか。 +前髪:ちゃんと最後まで伸びているか。 +鼻:最後まで伸びているか。 +髪の毛の裾、服の襟:元絵の線に近いか。単純移動平均では1〜3までは文句無しです。4〜6は惨敗です。線が遅れる感じが出てしまうのがよくわかります。特に、鼻は軽くさっと描く線なので、こういった軽く引く線は弱いようです。また、補正が強いので、襟や髪の毛、右側の線ではカーソルの動きに合わせてカーブの山が内側に入ってしまっています。丸い線がかけるようになるので、この辺は人それぞれで好みが分かれそうです。 **重み付け移動平均。重み付けを加えてみました。 ***パラメータ |履歴長|20| |重み関数|h(n)=20-n (n=0,1,...,19 : n個前のデータを表す)| ***結果 #image(lines-w_move_avg.png) #image(lines-w_move_avg-comp.png) 多少は良くなっているのですが...... **速度ベースの減衰関数速度によって過去のデータを減衰させていく方法を作ってみました。 (2007-08-18版) ***パラメータ |履歴長|20| |重み関数|h(n)=Π(サンプル点iでの速度のAnnealing関数)[i=1〜n]| |Annealing係数|2.5| ***結果 #image(lines-v_move_avg.png) #image(lines-v_move_avg-comp.png) 重み付けバージョンより、髪の毛の伸びなどが良くなっています。クオリティが変わらずに追随性が良くなったように見えてきます。 **単純ガウシアン重み付け GIMP萌え絵スレの898さんのアドバイスを聞いて、ガウシアン関数での重み付けを作ってみました。 ***パラメータ |履歴長|20| |重み関数|h(n)=Gaussian(n)| |Gaussianのσ|5| ***結果 #image(lines-g_move_avg.png) #image(lines-g_move_avg-comp.png) 重み付けと比べて格段に良くなっています。追随性もかなり良いです。ディティールが細かくなっています。細かいブレは補正するけど、大きな周波数のブレはそのまま出てしまうかもしれません。とにかく、かなり優れています。鼻のトレースはこの方法がもっとも良くなっています。 **速度ベースガウシアン重み付けガウシアンの入力値を、過去の履歴のインデックスではなく、それまでの速度の総和にしてみます。速度の和にする根拠がないので、数学的にはでたらめです。 (2007-08-19版) ***パラメータ |履歴長|20| |重み関数|h(n)=Gaussian(Σ(iの速度)[i=1〜n])| |Gaussianのσ|20| ***結果 #image(lines-gv_move_avg.png) #image(lines-gv_move_avg-comp.png) 追随性が良くなります。これまでの方法の中で最も良いです。補正の感じもガウシアンと同等です。線がカーソルから大きく外れないというのも良いところです。ただし、逆に言うと人によっては補正が弱いと感じるかもしれません。この方法でガウシアンのσを50に変えるとこんな感じになります。σひとつで大きく特性が変わるので、今回の結果もあくまでも参考程度って感じですね。 #image(lines-gv_move_avg_50.png) #comment

G-Penパッチ

2009-06-07T21:23:44+09:00

*これは何をするものか gimpのインクツールに手ブレ補正機能を追加するためのパッチです。手ブレ補正のついたペンを便宜上G-Penと呼んでいます。 &image(hosei-070819-3.png) 技術的に言うと、線を引く座標を過去数点の座標位置の移動平均の座標に変更します。補正レベル(座標サンプル数)を上げると強力に内挿されます。いろいろな手法との技術的な比較は[[G-Penパッチ/アルゴリズム比較]]を参照してください。 *ソースコードパッチ現在、ソースコードパッチのみ公開中です。 **対象者 gimpを自分でコンパイルできる人。 **ライセンス gimpのソースコードの派生物なのでGPLです。 **ダウンロード最新版にするには、下記のパッチをすべてダウンロードして、上から順番にパッチをすべて当ててください。 - [[gimp-2.2.17-gpen-work.diff>http://www24.atwiki.jp/sigetch_2007?cmd=upload&act=open&pageid=17&file=gimp-2.2.17-gpen-work.diff]] - [[gimp-2.2.17-gpen-work-070818-1.diff>http://www24.atwiki.jp/sigetch_2007?cmd=upload&act=open&pageid=17&file=gimp-2.2.17-gpen-work-070818-1.diff]] -[[gimp-2.2.17-gpen-work-070819-1.diff>http://www24.atwiki.jp/sigetch_2007/?cmd=upload&act=open&page=G-Pen%E3%83%91%E3%83%83%E3%83%81&file=gimp-2.2.17-gpen-work-070819-1.diff]] --ページの最下段にもリンクあり。(上のリンクがダメな場合は下のリンクを試してください) ***変更履歴 - 2007-08-19 --補正関数を速度ベースのガウシアンフィルタに変更。 ---カーソルへの追随性が向上。 --ツールオプションのデフォルト値を変更。(+下のパラメータ説明にお奨め範囲を記載) - 2007-08-18 --ポインタの補正に重み付けを導入。 - 2007-08-16 --最初のリリース **テスト環境 - ubuntu 07.04 (Feisty Fawn) -- OSは関係いはず。 - gimp-2.2.17 (本家よりダウンロード) - diff -uNrでパッチ作成 - ./configure --disable-print でテスト(gutenprint非対応?だから) **パッチ適用方法 gimp-2.2.17のソースコードを展開 (tar jxf gimp-2.2.17.tar.bz2 など) cd gimp-2.2.17 patch -p1 < <パッチのディレクトリ>/gimp-2.2.17-gpen-work.diff patch -p1 < <パッチのディレクトリ>/gimp-2.2.17-gpen-work-<日付>-<番号>.diff ...... ./configure [オプション: 当方では--disable-print] make make install #ルート権限必要 **使い方 -道具箱パレットに"G-Pen"が追加されます。(アイコンはインクと一緒。ショートカットは"G") -インクツールと同じように使います。 -線を引くときに手ブレが補正されます。 --(2007-08-18より)カーソルを動かす速度によって補正率が変わります。ゆっくりマウスを動かすと強く補正され、素早くマウスを動かすと補正率は弱くなります。 -ツールオプションに"Pointer Adjustment"という項目が追加されます。各オプションの意味は次のとおり。 |"Quality" | 補正するために使用する過去のサンプル数を指定します(1-20)。数が大いほど滑らかな曲線の補正になります。 1の場合は普通のインクツールと同じです。(20をお奨め)| |"Rate"(2007-08-18より) | 補正に関する適用割合を指定します(0-1000)。数値が大きいほど補正の適用割合が大きくなります。ただし、適用される効果は割合と比例関係にはないので注意が必要です。デフォルト値=25 (20-50程度がお奨め)| |"Draw pen line to finished point" | 補正が強くなると抜きの部分が途中で止まるような感覚になる。このチェックを入れると最後のカーソル位置まで線を引くようになる。(これはこれで使いづらい) (オフにすることをお奨め)| &image(hosei-070816-6.jpg) **既知のバグ - 線の「入り」の部分の補正が弱い。→アルゴリズム上しかたない。多分気にならないレベル。 - ツールオプションにブラシの選択メニューが出る。なぜ？ - ときどき、undo tileがないと言われる。undo関係はサボりまくっているので詳細未調査。 - 移動平均なので、最後の抜きが変。"Draw pen line to finished pointer"のチェックオン・オフでちょっと挙動が変わることで回避中。 **ソースコード - なんでGimpInk関係のファイルをGimpInk2にリネームしているの？ -- ここだけモジュール化できたらいいなぁっていう部分を抜き出しました。モジュールでgimpオブジェクトを参照できれば、本体に手を加えなくても良くなるはず... - なんでGimpInk2はGimpInkを継承してないの？ -- 継承するようにしたら動かなくなったから。push_undo関係が継承関係に依存したコードになってるような... 謎です。 - なんで移動平均なの？ -- 線分補完をする方法だと、いくつかのサンプル点が集まったときにようやくある区間の線分がかけるようになります。こういった方法だと、補間曲線をかくときに一気に数点で指定される曲線をかくことになります。一方、gimpはmotionイベントがあるたびに、直前の位置から新しい位置までの直線を引く処理になっています。つまり、毎回一本の直線を引く処理になっています。これを最初に言った方法に変えるのは面倒だったので（ぉぃ）、最小限の変更で済む、しかも簡単な方法として移動平均を使ってます。結果的には結構良い特性を持っていたようです。(補完点が必ず内挿されるのでブレが小さくなる→手ブレ補正にピッタリ) **コメント・フィードバックもしなにかあればこちらへどうぞ。(レスポンスは遅いと思います...) - 投稿テスト。お気軽にどうぞ。 -- しげっち (2007-08-17 02:22:37) - おんなじ用な内容の論文を発表していた人がいるそうです。&br()移動平均で補完するって一般的なんでしょうか。&br()http://ci.nii.ac.jp/naid/110003272091/ -- しげっち (2007-08-17 12:02:45) - 070819-1を2.4.0-rc1に移植したパッチとWindowsのバイナリです。&br()有用と思われましたら引き取ってあげてください。&br()http://cue.yellowmagic.info/files/gimp-2.4.0-rc1-gpen-work_bin_win32.7z&br()http://cue.yellowmagic.info/files/gimp-2.4.0-rc1-gpen-work.diff -- やまかわ (2007-08-21 20:15:34) - 記入ミス……&br()～.7zまでがWindowsバイナリのアドレスで、次のhttp:～が差分のアドレスになります。 -- やまかわ (2007-08-21 20:22:49) - ありがとうございます。&br()ひとまず自分のマシンへ保存しました。&br()このwikiだと、アップロードできるファイルが1MBまでなので、&br()どうやってアップするかはもうちょっと考えさせてください。 -- しげっち (2007-08-23 23:25:05) - ここにコメントできたんですね。はじめまして。&br()Ubuntu用の野良ビルドを勝手配布しています。&br()http://ub.x0.to/ub3/2007/08/gimpgpenubuntu_1.html -- ub3 (2007-08-29 21:23:42) - やまかわさん、申し訳ないです。&br()勝手に頂いた身でありながら僭越ではございますが、そのファイルで上書きするとテキストが使えないと言う状態になってしまいました。&br()いえ、正式に言えばテキストを開いて文字を入力した際に強制終了してしまうと言う現象が。。。&br()もしお暇な時間があれば、良かったら修正していただけないでしょうか・・・？&br()もしくは安定版で移植したパッチかバイナリか・・・。&br()かれこれリアルで１０時間ぐらい戦っているのですが、スキルの無い私には厳しいので・・・。&br()勝手なお願いですが、聞き届けてくださるとありがたいです・・・。 -- riku (2007-09-05 17:00:12) - 詳しいことはわかりませんが、FreeTypeのライブラリが関係しているような感じです。&br()先ほどrc2のバイナリを置いておきました。FreeTypeのDLLも念のため入れてあるので、そちらもgimp-2.4.exeと一緒にコピーしておくと改善するかもしれません。&br()ファイルのアドレスは上記の"rc1"を"rc2"に書き換えたものになります。 -- やまかわ (2007-09-08 18:04:07) - sourceforge.jpにプロジェクトを作りました。&br()http://sourceforge.jp/projects/gimp-painter/ &br()時間ができたらそっちに内容を移します。&br() -- しげっち (2007-09-14 00:02:23) - rc3もビルドしてみました。&br()とりあえず自サイトに置いておけばいいのかな… -- やまかわ (2007-09-27 05:02:18) - 5万円で買ったタッチパネルPCで、ペン入れができるなんて夢のようです。 &br()本当にありがとうございます! -- kana (2007-11-07 20:07:06) #comment(vsize=2,nsize=20,size=40)

Creative Commonsブラシ

2008-11-16T20:05:14+09:00

*Creative Commons ロゴブラシ自分の作品を[[Creative Commons>http://www.creativecommons.jp/]]ライセンスにしたいけど、リンク生成をいちいちするのが面倒……　だったので、ペタッと一発、Creative Commonsライセンスのロゴを画像に貼り付けるブラシを作りました。 #ref(cc-logos.png) **ダウンロード - [[cc-logo.zip>http://www24.atwiki.jp/sigetch_2007?cmd=upload&act=open&pageid=25&file=cc-logos.zip]] **ライセンス - [[CCロゴのライセンス>http://www.creativecommons.jp/learn/policies/post_4/]]に従ってください。 - あれ？結局リンク生成しないとダメなんですね…… - ……意外に自由がないライセンスですね。使い勝手が悪いというか…… - この@Wikiに表示させようとすると、そのままじゃ出来ないんですが、どうしましょう…… - この辺のライセンスが厳格に運用されるのか、意を汲み取ってある程度柔軟な運用になるのか……　難しいところですね。 **その他日本のCreative Commonsサイトの使いづらさは異常です。これは普及させないために作ってるとしか思えません…… 素直に、本家の方を使いましょう… 本家のバナー選択ページは[[こちら>http://creativecommons.org/license/?lang=ja]]です。 [[このページ内のコンテンツはCreative Commonsのライセンスにしたがっています>http://creativecommons.org/licenses/by/2.1/jp/]] #ref(http://i.creativecommons.org/l/by/2.1/jp/88x31.png)

Mixbrushパッチ/アルゴリズム比較

2007-11-05T00:32:26+09:00

*Mixbrushのアルゴリズム比較 Mixbrushのアルゴリズムに付いてのメモ書きです。 **基本コンセプト Mixbrushを実現するときのコンセプトは、SAIとNekoPaintのパラメータを参照して、 - 地の色が描画色に混色する (canvas_color_rate=bleed) - 地の色が混ざり過ぎないように、描画色に前景色が少しずつ混ざる (original_color_rate=resat) - 混ざり具合がタブレットの圧力に追随する(*_pressure_rate) の3つにしました。 **初期実装(071008+計算誤差修正版) ***問題点１：混色の方法最初の実装での大きな問題は、描画色に何を混色するかです。これにもいろんなオプションが考えられます。例えば、描画色にはキャンバスの色だけ混色して、実際に描画するときに一定の割合で前景色を足す方法があります。この方法では、描画色の混色には前景色を使いません。（間接的に、次回のキャンバス色には入るのでしょうが...） Webの資料を読む限り、Painterなどはこの方法じゃないかと思っています。（本当かどうかはまったくわかりませんけど。）２つめの方法としては、描画色に前景色とキャンバスの色を足し込んで、その色をキャンバスに置くという方法があります。そのほかにも、本当にいろいろな混ぜかたがあると思います。そして、その方法ごとに地の色の強さや、混ざり具合の特性が大きく変わってくるはずです。ここでは「とりあえず」ということで２番目の方法を選択します。 ***問題点２：パラメータの指定方法次の問題は"地の色"と"前景色"と"元の描画色"の割合をどう指定するか、という点にあります。３つの色データのソースがあるので、単純に考えると"地の色割合"、"前景色割合"、"元の描画色割合(=1 - 地の色 - 前景色)" として、合計が1になるように制限してあげることです。しかし、合計が1になるというパラメータはユーザにとって設定しづらいという問題があります。もうひとつの方法として、"地の色の割合"と"前景色割合"の間に関係式を作っておき、一定の法則にしたがって値が決定するという方法です。この方法では、ユーザが指定した値から、適当に本当の値が決まりますが、パラメータの影響が直感的でなくなるという欠点があります。ここでは、実装の手間を考えて、後者にしています。パラメータとしては、本当の前景色割合 = (1 - 地の色の割合) × 前景色割合という式を使っています。つまり、前景色割合は完全に地の色の割合に負けてしまうパラメータというわけです。本当はもっと凝った方法もあると思います。例えば、本当の前景色割合 = 前景色割合 / MAX(1.0 , 前景色割合 + キャンバス色割合) 本当のキャンバス色割合 = キャンバス色割合 / MAX(1.0, 前景色割合 + キャンバス色割合) 元の描画色割合 = 1 - 本当の前景色割合 - 本当のキャンバス色割合などとする方法があります。お互いに"1.0"に対する割合としておき、合計が1.0を越えてしまったら（=出力がサチったら)、その割合で按分する方法です。かなりフェアな方式と言えます。そんなこんなで、071008+計算誤差修正版の場合の混色フローはこんな感じです。 &image(mixbrush-sigetch-algorithm-071028.jpg) **やまかわさんの実装やまかわさんの実装では、Bleedというパラメータが追加されました。このときの混色フローはこんな感じです。 delayステップだけ点を打つのを遅らせて、まだ色が塗られる前の描画色をピックアップするようにしています。感じとしては、delayステップ前までのストロークは乾ききっていないので地の色に定着しない状態で、それ以前のストロークは乾いて地の色に定着するイメージです。（071008版では、すぐに乾いてしまうイメージです。描画色が強いと、地の色があまり混ざりません。） &image(mixbrush-y-algorithm-071028.jpg) すごく表現の幅がひろがって役立つすばらしい実装ですが、Bleedパラメータが非常にわかりづらい位置付けになってしまっているように見えました。パラメータの強さがcanvas_color_rate > Bleed > original_color_rateとなり、original_color_rateが２つのパラメータに左右されるようになってしまったことと、Bleedの0-1.0という（絶対値の）範囲が意味する内容がわかりづらくなってしまっていることが問題だと感じました。そこで、実装はほとんどそのままいただいて、計算順序を変更するようにしました。 **071029版(仮) 現在使用している実装です。混色フローを単純化しました。 &image(mixbrush-sigetch-algorithm-071029.jpg) 地の色として、現在のキャンバス色とdelayステップ前のキャンバス色を混ぜるようにしました。混ぜる割合をdelayed_color_rateで決定するようにしました。パラメータの強さは canvas_color_rate > delayed_color_rate canvas_color_rate > original_color_rate となっていますが、delayed_color_rateとoriginal_color_rateがそれぞれ影響をしなくなったので、調整が楽になっています。そして、地の色の調整(Painterでいうところのbleed)はcanvas_color_rateで一本化したので、delayed_color_rateの役割と調整が簡単になりました。 **誤差の扱い 071008版では内部の計算は原則としてgucharで行っていました。計算をする度に桁落ちが発生してしまうという欠点がありました。そこで、1029版（仮）からはブラシの色としてGimpRGBを使って内部計算を行うようにしました。 **レイヤーの扱い混色する場合に、地の色が混ざってくるので、白いキャンバスの上では色が白く(薄く)なっていく効果があります。ところが、レイヤーでは背景の色がない（不透明度<1.0)ので、混ぜるという方式がうまくできません。透明な部分にはなんらかの色が隠れているように仮定する"Hidden Color"の方式で色を補完してあげると計算できるようになりますが、透明なレイヤーに線を引いたのに、突然白（や背景色）が混ざってくるという動作になってしまいます。できれば透明度を保護しつつ色を塗りたいという考えになります。そこで、レイヤー（不透明度<1.0)の場合は、以下の方法でcanvas_color_rateと不透明度を調節します。旧brushのcolor_rate = 1 - 旧canvas_color_rate 新canvas_color_rate = 旧canvas_color_rate × レイヤ不透明度新brushのcolor_rate = 1 - 新canvas_color_rate 新不透明度 = 旧不透明度 × 旧brushのcolor_rate / 新brushのcolor_rate このようにすると、混色のロジックとしては新canvas_color_rateを使用するようになるので、透明なキャンバス色はあまり色計算に反映されなくなります。一方、実際に表示されるときの色の割合は、色×不透明度なので、ブラシ色の割合 = 新brushのcolor_rate × 新不透明度 = 新brushのcolor_rate × (旧不透明度 × 旧brushのcolor_rate / 新brushのcolor_rate) = 旧不透明度 × 旧brushのcolor_rate canvas色の割合 = 新canvas_color_rate × 新不透明度 = (旧canvas_color_rate × レイヤ不透明度) × (旧不透明度 × 旧brushのcolor_rate / 新brushのcolor_rate) = (旧canvas_color_rate × (1 - 旧canvas_color_rate) × レイヤ不透明度 * 旧不透明度) / (1 - 旧canvas_color_rate * レイヤ不透明度) ※a = レイヤ不透明度 * 旧canvas_color_rate と置くと = (旧canvas_color_rate × 旧不透明度) × ((レイヤ不透明度 - a) / (1 - a)) となります。ブラシ色の割合は、地の色がある場合と同じ割合（旧不透明度×旧brushのcolor_rate)になります。一方、canvas色の割合は (レイヤ不透明度 - a) < (1 -a)なので、地の色がある場合（旧canvas_color_rate × 旧不透明度)よりも薄くなっていきます。ブラシの割合が同じ一方で、canvas色の割合が弱くなるということは、結果的に、白（もしくは地の色)が混ざったように見えます。ただし、この方法では透明度は薄くなりますが、色には白が混ざってこないので、やはり地の色があるキャンバスとは結果が変わります。ついでに、"Hidden Color"として背景色か白を選んだ場合は、不透明度が1.0になるので、旧canvas_color_rateと新canvas_color_rateが変わりません。なので、まったくなんの効果もあたえないということになり、この式が悪さをすることはありません。 #comment

選択領域から新規レイヤーを作るScript-fu

2007-11-04T17:13:24+09:00

選択領域から新規レイヤーを作成します。そのとき、選択領域の形にくりぬいたレイヤーマスクを付けることができます。セル塗りアニメのようなイラストを描くときに、ベタ塗りをするパーツを切り出していく「パーツ分け」という作業がありますが、それを楽にすることが出来ます。 **ダウンロード -2.4対応版:[[selection-to-layer-20071104.scm>http://www24.atwiki.jp/sigetch_2007?cmd=upload&act=open&pageid=12&file=selection-to-layer-20071104.scm]] **使いかたまず、パーツ分けしたい部分を選択ツールを使って選択します。範囲選択などを使うとエイリアスのかかった部分がきちっと選択できないときもありますが、そのままにします。 #ref(image1.jpg) そして、Sciprt-fu→ANIME-Coloring Support を実行します。下の絵のようなダイアログが表示されます。 #ref(image2.jpg) それぞれの意味はこんな感じです。 :Layer Name|作成されるレイヤの名前 :Fill Color|レイヤを塗りつぶす色 :Padding border to the selection size|新規レイヤを作成するときに、選択領域の回りに一定サイズのパディング領域を入れる。新規レイヤのサイズは選択領域よりも指定した割合だけ拡大される。 :Grow Selection|選択領域を拡大するピクセル数。指定したサイズだけ選択領域を拡大（負値の場合は縮小）する。 :Clip new layer with selection|レイヤマスクを自動的に適用するかどうか。例えば、こんな感じにしてみると... #ref(image3.png) こうなります。新規レイヤでは選択領域の回りに２割のすき間領域が出来ています。 #ref(image4.jpg) レイヤの構造はこんな感じになります。 #ref(image5.jpg) ちなみに、"Clip new layer with selection"を実行すると、マスクが自動的に適用されて、レイヤがクリップされます。 #ref(image6.png) #ref(image7.jpg)

Gimp拡張

2007-10-09T23:29:40+09:00

*Gimp拡張(仮トップページ) **はじめにこのコーナーはGimpをお絵描きツール仕様に拡張してしまおうという試みのページです。現在のところ、次のパッチを作っています。 -[[G-Penパッチ]] -[[MixBrushパッチ]] バイナリ、ソースのパッチ配布は http://sourceforge.jp/projects/gimp-painter/ に移行する予定です。 **ToDo [[Gimp拡張/ToDo]]

Gimp拡張/ToDo

2007-10-09T23:24:41+09:00