トーテムポーる

トーテムポーるはじめました

発光エフェクトスクリプト 使用例
トーテムポーらない [GIMP][script][Python-Fu] 発光エフェクトスクリプトの使用例。
スクリプトの実行パラメーターは上から 2, 5, 70, 0, 2, 100
色は、青白い光がcyan & white、赤っぽい光が red & yellow.

いやーこりゃ便利かっこよいわw
第一回
第二回
第三回
第四回
第五回(前回)



最後です。
今回は線画の処理をします。
処理の方法はいわゆる色トレスと呼ばれるものです。

線画のレイヤーの"アルファチャンネルをロック"します。
そして、線の近くの色をピックアップしてその色を濃くした色で線を塗ります。

この作業は線画を絵に馴染ませるために行います。
目的さえ達成できれば、オレンジやこげ茶の単色塗り、単純にアルファ値を下げる、レイヤーモードで調節するなどなんでもいいです。
ケースバイケースです。


今回はあえて瞳の塗り方の説明はしませんでした。
まぁ、こういうのは教わるよりも盗むのが大事なので。
その方が個性につながりますし。

少しだけコツを付け加えるとすると、
アニメっぽい塗りの場合は虹彩と瞳孔は別のレイヤーにした方が良い結果が得やすいです。
目の色を決めかねるときはとりあえず髪の毛の色と同系色にすると安定します。


あと、自分に言い聞かせる意味も込めて。
色は多少オーバーコントラストだとおもうくらいの方が見栄えがします。

質問はお気軽に。
というか何もいってくれないと何を書いたらいいのかわからないですの
ネタをくださいw
第一回
第二回
第三回
第四回(前回)

今回は明暗を付けて色を塗っていきます。

いろいろと塗り方はありますが、今回は自分がいつもやってる塗り方を紹介します。
(一般的になんて呼ばれる塗り方なのですかね。)

まずは、いわゆるアニメ塗りとかセル塗りとか呼ばれる奴でさっくり塗っていきます。
対象物を立体的にとらえて、明るい部分と暗い部分をはっきりわけて塗ります。
塗るときはブラシツールで強度1.0〜0.9程度のブラシを使います。

次に、明暗の境目が緩やかにグラデーションで変化していくようなところをぼかします。この工程ではにじみツール、ぼかしツール、エアブラシツールなどを使います。
にじみツールやぼかしツールは、明暗の境界面をグラデーションでなだらかに変化させるという目的には合ったツールなのですが、思いきり良く操作しないと色が混ざり合ってくすんでしまうので注意してください。
ある程度試行錯誤しながらきれいに仕上げたいと言う場合にはエアブラシツールを使った方が良い結果が得やすいです。

ぼかすぼかさないのメリハリをどう付けるかによって絵の印象が大きく変わります。
特に、髪の毛の部分を塗るときにはこの傾向が顕著になります。
髪の毛の流れに沿ってぼかして、直行する方向にはぼかさない様にすると、今回のようなアニメ的な光沢の強い髪の毛になります。
逆に、全体的にぼかすと軟らかい印象をあたえる絵になります。


P.S. パーツの下の方で影の部分に紫ないし、それを赤、青に振った色を入れるとちょっとうまいっぽく見えるのでお試しあれ。
GIMPを使い易くするための設定例を示すチュートリアル


あと、他に適切に設定すべき点はタイルキャッシュサイズ。
実メモリより少ない量を設定するのがコツです。
目安は実メモリの40%〜70%位。
1G=1024Mbyte積んでたら512Mbyteあたりが無難。
ブラウザーなどを立ち上げながら作業する場合はそれも考慮して決めるのが良いです。
UNIX系OSならtopのMem:の行のFreeの項目を参考にすると良いです。

自分がいま使ってる実家のPCは実メモリが512Mbyteしかないのでカツカツに400Mbyteあたりを指定して他のソフトは使わないようにするしかないので結構きついです。

メモリガンガンつんで、tempにi-RAMを指定とかほんと神の領域ですね。

あとは、自分は"ものさし"と"メニューバー"を消すのが好みです。
関連: A FreeBSD GIMPer GIMPの画像縮小でLanczos3による補間を可能にするpatch

あのあと、Bug 166130 - Better image scaling algorithms, redux (GIMP)と、それに続く[Gimp-developer] improving image scale: reduction での議論により、どうやら次のような結論を得ました。

GIMP 2.4 および、その開発版である2.3では今回の要求のような画像のリサイズの品質向上に望むことはない。また、次のstable ver. となる2.6 では画像のリサイズに関するルーチンはGEGL のものとなるので、もし、今回の要求を反映したいのであれば、GEGLでの作業となる。
(GEGLについては晴れときどきGIMP: Gimpの次世代画像エンジン (GEGL)を参照されたし。)

まぁ、前回書いたコードはそのまま使えるような品質ではなかったのでそのまま受け入れられるとは思っていなかったのですが、UIに表示されているものと異なるアルゴリズムが用いられると言う根本的な問題にもそれをGEGL以降に先送りするという方針には落胆せざるを得ないです。

一方で、GEGLの取り込みが進むという話は非常に興味深いです。
A FreeBSD GIMPer GIMPの拡大縮小アルゴリズムに付いての調査でGIMPの画像縮小でLanczos3を選択しても実際には平均画素法らしきアルゴリズムで縮小されてしまう問題に付いて言及した。

そこで、Lanczos3で縮小が出来るように変更を試みた。
成果物のpatchをBug 166130 - Better image scaling algorithms, redux (GIMP)に投げておいた。
(場所が適当だったかはわからないが。)

あっちは開発者向けなのでSVN repository headに対するpatchのほうが良いだろうということで、そうしましたが、こちらのblog用にGIMP 2.3.16用 Lanczos3 縮小 patchも用意しました。
2.3.16じゃなくても今年の2007-02-27以降のバージョンのソースコードになら当てられるはずです。


品質ですが、ImageMagickのlanczosやsincと比較するとコントラストが下がりがちです。
ですが、少なくとも、今までの平均画素法よりは空間周波数に忠実な縮小が出来るようになっています。

速度面は、以前の拡大専用のソースコードを縮小にも対応できるように汎化拡張を施すという作り方をしたので、以前よりも遅くなっているはずです。
特にループ回数が固定だったものを可変にした部分が多いのでgcc -O3 でのループ展開には圧倒的に不向きです。

(以下補間品質の検証)
GIMPの拡大縮小アルゴリズムそれぞれの違い
実験環境

縮小アルゴリズムの謎
ソースコードの調査
縮小アルゴリズム

の順に説明していく。
(以下本文)
キーショートカット: b - 前のページ n - 次のページ