2013年09月22日

アンサンブル平均で表面下散乱をやってみたかった

肌の表面下散乱を表現する場合に、光の波長で散乱の量が変わってくるので、複数半径のブラーを利用して再現する手法が用いられています[1]。

アンサンブル平均でも、カメラ(もしくは光源)の振動の分散を、RGBでそれぞれ変えてレンダリングすればそれっぽいのができないかなということで試してみることにしました。

実行結果

分散をR0.0004, G0.0009, B0.0010でレンダリングした結果です。光源もちょっと赤っぽくしています。
antialias_sss_small.jpg
多少輪郭辺りが赤っぽくはなってる気がしないでもないですが、効果は微妙でした。

[1] http://news.mynavi.jp/column/graphics/061/index.html

web拍手 by FC2
posted by シンドラー at 23:24 | Comment(0) | TrackBack(0) | OpenGL & Metasequoia | このブログの読者になる | 更新情報をチェックする

2013年09月20日

1/fゆらぎのテスト

昨日はランダムに光源を動かしてみたのですが、光源の位置によって明るくなったり暗くなったりして1/fゆらぎを思い出したので、少し試してみました。

1/fゆらぎとは、fが周波数ですので、周波数に反比例してパワースペクトルが弱くなるようなノイズらしいです[1][2]。
作り方の手順としては、[3]が分かりやすかったです。

まず最初に、1次元1024個のデータを一様乱数を使って作ります。
fnoise_signal.png
この信号を離散フーリエ変換します。
パワースペクトルを図示すると、下図のようになり、色々な周波数が偏りなく混ざっていることがわかります。
fnoise_spectrum.png
実数のデータを離散フーリエ変換したものですので、1024個のデータのうち、0番目が直流成分で、1〜511番目と513〜1023番目が512番を中心に対称になっています。

1/fゆらぎを持つデータとは、このfが増えるにしたがってパワースペクトルも減っていくことになりますので、実部、虚部のデータともに1/fフィルタを掛けます。
1/fフィルタは[3]では1/sqrt(f)で定義されていましたので、0番目を除いて、512番を中心にフィルタを掛けていきます。

1/fフィルタを掛けた後に計算したパワースペクトルは下図のようになりました。
一応反比例になっている感じです。
fnoise_spectrumF.png
このデータを逆フーリエ変換してあげれば、1/fゆらぎになるみたいです。
fnoise_signalIFFT.png
sin波に1/fゆらぎを足した例は下図のようになりました。
fnoise_sin.png
実行結果

1/fゆらぎは癒しの効果があるらしいので、照明の明るさに1/fゆらぎを加えてみました。



モデルデータとして[4]のすず式ミクダヨーさんを使わせていただきました。

[1] http://ja.wikipedia.org/wiki/1/f%E3%82%86%E3%82%89%E3%81%8E
[2] http://www.mathworks.com/tagteam/56754_LN527_Introduction_of_useful_features_in_SL_for_signal_processing.pdf
[3] http://doilab.net/web/doilab/fi95/
[4] http://www.nicovideo.jp/watch/sm18881886
web拍手 by FC2
posted by シンドラー at 02:17 | Comment(0) | TrackBack(0) | OpenGL & Metasequoia | このブログの読者になる | 更新情報をチェックする

2013年09月19日

アンサンブル平均でシャドウマッピング

前回の続きです。

モデルの場合、カメラを振動させすぎるとボケてしまって良くないということだったのですが、影の場合はボケた方がソフトシャドウっぽくなって良さそうじゃないかな、ということで、今回は光源を分散大きめで振動させながらのシャドウマッピングを試してみました。

実行結果

640x480の画像で、デプスマップも等倍サイズのものを使用してシャドウマッピングしています。
光源は分散0.01で、カメラは前回最も良かった0.0004で振動させています。

 

深度オフセット値の影響か振動させすぎの影響か、たまに床全体が黒くなったりしていますし、かなり荒い影ですね。

softshadow_00005_0.00040.jpg
5回のアンサンブル平均

softshadow_00050_0.00040.jpg
50回のアンサンブル平均

softshadow_00100_0.00040.jpg
100回のアンサンブル平均

softshadow_01000_0.00040.jpg
1000回のアンサンブル平均

softshadow_10000_0.00040.jpg
10000回のアンサンブル平均

100回ぐらいでノイズも大体取れてソフトシャドウっぽくなってますかね。
シャドウマッピング×(テクスチャの色+スペキュラ)のかなり適当なレンダリングなので微妙ですが、ちゃんとアンチエイリアスすると結構きれいに見える気がします。

web拍手 by FC2
posted by シンドラー at 02:35 | Comment(0) | TrackBack(0) | OpenGL & Metasequoia | このブログの読者になる | 更新情報をチェックする

2013年09月17日

アンサンブル平均でアンチエイリアス

アンサンブル平均でCGっぽいものということで、アンチエイリアスに使ってみました。

レイキャスティングでレイが進む方向に乱数を加えて色を計算して、その結果をアンサンブル平均する方法がいいのかなと思いましたが、面倒でしたのでカメラの位置と方向に乱数を加えてレンダリングした結果のアンサンブル平均をとることにしました。

Kinectに振動モータをつけて複数台設置時の干渉を取り除く研究[1]などが行われていますので、カメラを振動させてみるのもたまにはいい気がします。

手順
1. カメラの変換行列にノイズを加えてFBOにレンダリング
2. レンダリング結果をテクスチャに取得
3. 別のテクスチャ領域を用意しておいて、取得したレンダリング結果を加算
4. 別のテクスチャ領域を用意しておいて、3.の加算結果を加算数で割って(アンサンブル平均)表示する画像を作成
5. glTexImage2Dでテクスチャを貼り付けた板を表示

GPU→CPUがglGetTexImageで、CPU→GPUがglTexImage2Dですよね。
時間が少し空くと忘れてしまっていて困ったものです。

実行結果

カメラの位置座標と対象座標に平均0、分散0.0001〜0.0010の間を0.0001間隔で、正規分布に従うノイズを加えてレンダリングしました。

分散0.001



分散0.001でも結構揺れますね。まぁカメラ座標のスケールに依存しますので値に意味はありませんが。

分散0.0001



これぐらいの振動が普通でしょうか。

以下、それぞれの分散で5, 100, 10000回のアンサンブル平均をとった結果です。

AntiAlias00005_0001.jpg AntiAlias00100_0001.jpg AntiAlias10000_0001.jpg
分散0.0001 振動が少なすぎて、アンチエイリアスの効果が殆どないですね。

AntiAlias00005_0004.jpg AntiAlias00100_0004.jpg AntiAlias10000_0004.jpg
分散0.0004 今回の結果では、髪の毛のジャギーが消えて、かつ、他の領域も殆どボケてない値でした。

AntiAlias00005_0010.jpg AntiAlias00100_0010.jpg AntiAlias10000_0010.jpg
分散0.001 振動が強すぎてボケてます。

まぁ実用性はないと思いますが、Kinectの記事を見て思いついた小ネタということで。

[1] http://www.precisionmicrodrives.com/tech-blog/2012/08/28/using-vibration-motors-with-microsoft-kinect

web拍手 by FC2
posted by シンドラー at 22:57 | Comment(0) | TrackBack(0) | OpenGL & Metasequoia | このブログの読者になる | 更新情報をチェックする

2013年09月09日

色ヒストグラムと共起確率を用いたテンプレートマッチングについて

前回の続きです。

カラーで試す場合、RGBそれぞれの成分に分けてやる方法もあるかと思いますが、今回は減色して色ヒストグラム的な手法で試してみました。

前回は、ある画素P(x,y)の濃度値pで、そこからd離れた場所の濃度値がqの場合、グレースケールで考えていますので、pが0〜255の256段階、qも0〜255の256段階ですので、共起ヒストグラムを画像にすると256x256の画像にできました。

今回は、RGBそれぞれ16段階に減色して、16^3=4096種類の階調値をとるとみて共起ヒストグラムを作成します。この場合、pとqが4096段階になって4096x4096の画像になるぐらいで、ヒストグラムや共起確率の計算等は、前回と同様の方法でできます。

問題はテンプレートマッチング時の色の類似度計算をどうするかについてなのですが、せっかく?色ヒストグラムを使うので、今回はHistogram Intersection[1]で類似度計算をしてみました。

4096段階の色ヒストグラムを作成し、テンプレート画素の個数がN個の場合は、N個の色ヒストグラムをあらかじめ計算しておき、マッチング時には、対象画像からN個の画素をとってきて、その色ヒストグラムを作成して、Histogram Intersectionで類似度の計算を行います。

実行結果

今回も前回と同様に、PRMUアルコン2009の画像[2]を使用させていただきました。

羊のテンプレート画素(1000個)と狼のテンプレート画素(1000個)

cptm_ps_sheep.bmp cptm_ps_wolf.bmp

羊の検出結果(類似度の閾値0.4) と 類似度画像

cptm_detection_sheep_result.png cptm_dot_sheep_result.png

狼の検出結果(類似度の閾値0.2) と 類似度画像

cptm_detection_wolf_result.png cptm_dot_wolf_result.png

緑色は一番類似度が高かったところです。テンプレートに用いた部分なので当然で類似度も1.0でした。
手法的に回転や拡大縮小には弱そうですね。前回の参考文献には対応方法も載っていたと思いますが、多分やらないと思います。
後は今回は絵でしたので16×16×16に減色してもほぼ問題ありませんでしたが、自然画像だと影響が出てきそうです。

[1] http://aidiary.hatenablog.com/entry/20091003/1254574041
[2] http://www2c.comm.eng.osaka-u.ac.jp/~alcon2009/


web拍手 by FC2
posted by シンドラー at 22:41 | Comment(0) | TrackBack(0) | Image Processing | このブログの読者になる | 更新情報をチェックする

2013年09月07日

濃度共起ヒストグラムを用いたテンプレートマッチングについて

共起ヒストグラムというものをちょっと試してみたくなったので、[1]をやってみることにします。

ある点の濃度値pを縦軸に、その点からd離れた場所の濃度値qを横軸にしたヒストグラムが濃度共起ヒストグラムというものだと思います。

テンプレートマッチングの計算に、テンプレート画像の全画素を使うと時間がかかるので、濃度共起確率というものを計算して、濃度共起確率が低い点を選んで、その点だけ使ってテンプレートマッチングする手法のようです。

実行結果

やりやすそうな画像として、[2]のPRMUアルコン2009の画像を使用させていただきました。

白い磁石画像(グレースケール化)とそのテンプレート画素(共起確率が低い順に200?点)
cptm_grayscale_white.bmp cptm_ps_white.bmp

青い磁石画像(グレースケール化)とそのテンプレート画素(共起確率が低い順に200?点)
cptm_grayscale_blue.bmp cptm_ps_blue.bmp

白い磁石のテンプレート画像を用いた場合の検出結果
cptm_detection_white.png

青い磁石のテンプレート画像を用いた場合の検出結果
cptm_detection_blue.png

左上の白い磁石が検出できていないのは、テンプレートマッチングの手法を適当にしてしまっているからでしょうか。
色情報をなくしてしまうのももったいないので、とりあえずカラー画像でできるように変えてみたいと思います。

[1] http://isl.sist.chukyo-u.ac.jp/Archives/cptm.html
[2] http://www2c.comm.eng.osaka-u.ac.jp/~alcon2009/
web拍手 by FC2
posted by シンドラー at 22:32 | Comment(0) | TrackBack(0) | Image Processing | このブログの読者になる | 更新情報をチェックする

2013年09月05日

巡回セールスマン問題のテスト

いつの間にやら9月ですね。先月1回しか書いていない・・・。

Hopfield型ネットワークで巡回セールスマン問題[1]を解いてみたのですが、都市数をNとすると、ユニット数がN*N必要で、相互結合型ネットワークなので単純計算で各ユニットがN*N個の重みを持ちますので、計N*N*N*N個の重みが必要です。
double型で8bytes使うとすると、N*N*N*N*8bytes必要になりますので、1024都市の場合8PB(ペタバイト)ほどメモリが必要になる気がするのですが、合ってるんでしょうかね。

そんなわけで方向転換して2-opt法という良く知られているらしい方法を試してみました[2]。
最初適当に経路を作成して、その後2本直線を選んで、つなぎかえて距離が短くなるのであればつなぎかえるというとてもわかりやすいアルゴリズムです。

50都市での実行結果



500都市の実行結果

tsp_500_result.png

500都市の場合は収束しましたが、800都市以上辺りから収束しなくなりました。
原因として、短くなれば必ずつなぎかえる点などが考えられますので、温度・確率を取り入れるシミュレーティド・アニーリング法などを組み合わせればうまくいくかもしれません。
気が向いたら試してみたいと思います。

[1] http://www.eva.ie.u-ryukyu.ac.jp/~endo/HFTSP.pdf
[2] http://www.geocities.jp/m_hiroi/light/pyalgo64.html
web拍手 by FC2
posted by シンドラー at 17:42 | Comment(0) | TrackBack(0) | Computational Geometry | このブログの読者になる | 更新情報をチェックする

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。