昨日の続き。 for/nextをrepeat/untilに修正して、一次元ガウス関数で重みを取得、配列に予め保存してから縦と横に暈し処理を分けてみたら圧倒的速ｽｷﾞｨ! 100*100で3分かからないくらいです。真っ暗になりますが。 IOSのぼかしとか見ると全然遅いと感じますね (スクショは7*7ガウシアン暈し)

×修正 ○変更

37*37

1次元での仕組み、やっと分かった(多分)。 色混ぜ範囲が3×3の場合、2次元のままだと3×3=9回計算しなきゃならないところ、1次元だと3+3=6回の計算で済むという訳ですね。 色混ぜ範囲広い程効果が大きいし、これは良いですね(^o^) 因みにσ(ｼｸﾞﾏ)の値ですが、もし適当な値決め打ちしているようであれば、色混ぜ範囲のサイズによって計算する方法もあるみたいですよ。 σ=0.215*((SIZE-1)/2-1)+0.81 ＃SIZEは3×3なら3 0.215とかの数値はサイトによって若干違ってたりします^^;

ARYOP使わない？11*11で25秒弱(目検） なんか出力が変

僕の技術力だとrgbreadを四則計算で出来ないので(現在はビットシフトで分解)aryopは使ってません 11*11で約23秒ですね。

・・・・・・自分RGBREADをARYOPで使っているのに香辛料氏の方が早い・・・orz、全然関係ありませんが時間計測のやりかたおしえてくだちぃ(；´Д｀)

処理前に適当な変数へmillisecを代入、処理後に現在millisec値から変数の値を引いたのを1/1000すれば秒数が得られます。 参考になるのか分かりませんが公開しました。 key:【4DYD13K3】file:「BOKASHI4」

millisecシステム変数！！そういうのもあるのか！！ (今知った）

22.4秒なのでほぼ一緒でした・・・ARYOPの意味なし・・・orz

あっ、色コードから四則計算でどうやってrgb要素取り出すのか教えてくだちぃ

ガウシアンぼかし処理作るにあたってRGB分離関数作っときました SBKEY:Z5LX3KQE　　「SU_GAU」 関数名「SUARY2RGB」 引数として入力配列､出力R配列､出力G配列､出力B配列)を渡すと それぞれの配列に値が入っている仕様です。 理屈としてはビットシフトっぽい動作を行うために指数乗数で割ってやると 上位nビットの値が取得できるので、ARGBの各ビット毎8bitずつ上位ビットかあら削って抽出していく感じです。

配列の値は同じにしておく必要があります。

×配列の値 ○配列の要素数

19*19ぼかし改善前約40秒に対し、改善後約31秒までに軽くなりました！ありがとうございます！

1次元ガウス関数→パスカルの三角形→二項定理、と迷走してしまいました(>_<) 1次元ガウス関数の重みの配列、分子はパスカルの三角形から、分母は16の「広げる範囲のピクセル幅」乗(範囲3×3なら16の1乗、5×5なら16の2乗)で計算できればスッキリするかなぁと(なるべく整数値で持っといて、最後に分母で割れば誤差抑えられるとか)思ったんだけど、肝心の分子のパスカルの三角形のところが良い方法思い付かなくてハマり中。 例えば範囲5×5の5から、1,4,6,4,1をさらっと求められれば良いのだけれど。 ＃すごく単純な気がする。けど思い付かん。