1001コメント334KB

画像処理その６

■ このスレッドは過去ログ倉庫に格納されています

0001デフォルトの名無しさん

2006/02/21(火) 17:31:10

・画像処理について素人同士で大激論
・初学者の質問に対してやさしく(的を外れた)解答を与える
・その道の玄人も大歓迎

前スレ
http://pc8.2ch.net/test/read.cgi/tech/1127705848/
過去スレッド
画像処理その４
http://pc8.2ch.net/test/read.cgi/tech/1107854973/
画像処理その３
http://pc5.2ch.net/test/read.cgi/tech/1090897159/
画像処理その２
http://pc5.2ch.net/test/read.cgi/tech/1054545005/
画像処理
http://pc5.2ch.net/tech/kako/992/992671330.html

0153デフォルトの名無しさん

2006/03/04(土) 21:49:46

>>151
それは任意サイズや多角形マスクも考慮してやってますか？

0154デフォルトの名無しさん

2006/03/04(土) 22:09:03

>>152
ミニマップが有効なのはぴったり規定サイズのときだけですけどね

0155デフォルトの名無しさん

2006/03/04(土) 22:15:40

>>153
任意サイズやマスクのせいで遅いなら、見るべきはαの処理じゃないよね。
拡大縮小アルゴリズムとマスク処理は何を使ってどう書いているの。

0156デフォルトの名無しさん

2006/03/04(土) 22:38:08

いやだからアルゴリズム違いを突き詰めたってたいしてかわらんでしょ

0157デフォルトの名無しさん

2006/03/04(土) 23:06:00

埒が開かないな。
もっともっと細かくどの部分にどれだけの時間がかかるか調べたら？
5秒もあればボトルネックをはっきり特定できるでしょ。

0158デフォルトの名無しさん

2006/03/04(土) 23:11:52

ボトルネックというか求める速度は単純にもろもろ判定処理を除いた41msですら遅いです
それこそ1msとかのレベルじゃないと拡大やマスクやGDI描画にかかるコストの総和になってくるので
どこがネックかといえば拡大とブレンドですね
これをなんとかして2msくらいまでおさえたい

0159デフォルトの名無しさん

2006/03/04(土) 23:41:29

つーか使用しているマシンスペックは？
それと現時点で各処理にどのくらいかかっているか、
とかもっと具体的に書かないとこれ以上アドバイスしようが無いと思う。

0160デフォルトの名無しさん

2006/03/04(土) 23:51:40

Photoshopが1msで処理してるって信じてるなんてアホちゃう

0161デフォルトの名無しさん

2006/03/04(土) 23:53:57

私の求めてるのはちまちました速度アップではありません
そんなものは気が向いたらやります
>>138のように劇的なものを求めてるだけです
>>138のだけではすべてがそろいません
アルファブレンドされた１０枚の壁紙サイズの合成画像をマスク処理もやってです拡大縮小もです
操作が行われてから100msでください
操作とは倍率変更、透過率変更、色変更、移動などがあります
すべての操作において100msです
アルゴリズムの工夫だけでは不可能です
>>138のような手法がほしいです
>>138だけでは全体像が見えないです

0162デフォルトの名無しさん

2006/03/04(土) 23:54:37

要求する仕様と現状のソースと速度の測定環境晒してみ

0163デフォルトの名無しさん

2006/03/05(日) 00:00:41

wxWidgetsなんでさらしても多分理解してもらえませんｗ
内部でなにをやってるかは全部把握してるので私はわかりますが
今やってるのが元のサイズのままでアルファブレンドで画像を作ります
これは変更があったときだけ
W_PAINTにこの画像を拡大縮小してBitBltです
拡大縮小は早いですよかなりね
ブレンド方法は>>149に書いたとおり
ブレンドとマスクは同時にやってます
これが更新時だけですが５秒近いです

0164デフォルトの名無しさん

2006/03/05(日) 00:11:50

wxWidgetsのスレ池やアホか。スレ違いじゃ

0165デフォルトの名無しさん

2006/03/05(日) 00:15:15

ぜんぜんスレ違いじゃありません
wxWidgetsはWindowsネイティブをラップしてるだけで内部はまったく同じです
アルファブレンドをMFCやSDIやBCCで実装するのにそれぞれのスレにいかないといけないんですか？

0166デフォルトの名無しさん

2006/03/05(日) 00:18:45

なら別にwxWidgetつかってようがなんだろうが理解されないってことはないな。
お前脳味噌腐ってる？

0167デフォルトの名無しさん

2006/03/05(日) 00:21:59

例えば拡大縮小は
wxImage::Scale(w,h)
って書くだけです
画素情報は
wxImage::GetRed(x,y)
です
unsingned char * wxImage::GetData()
もあります
こんな羅列書いて理解できますか？

0168デフォルトの名無しさん

2006/03/05(日) 00:25:23

問題を切り分けられるようになってからおいでください

0169デフォルトの名無しさん

2006/03/05(日) 00:25:52

そんなAPI経由でアルファブレンド処理してるんだとしたらその時点で阿呆スギ

0170デフォルトの名無しさん

2006/03/05(日) 00:28:54

いま適当にJavaでXGAサイズで10枚、アルファブレンドしてついでに
アフィン変換してみたけど、100msなんて余裕だな。

0171デフォルトの名無しさん

2006/03/05(日) 00:30:02

for(i=0;i<layers;i++){
for(x=0;x<dest.GetWidth();x++){
　　　for(y=0;y<dest.GetHeight();y++){
image = layer[i];
mask = layermask[i];
　　　　　if(!INRECT(mask,x,y))continue;
if(!INRECT(image,x,y)continue;
if(mask.GetRed(x,y){
　　　　　　 int r = dest.GetRed(x,y) ...................
　　　　　　　int g
　　　　　　　int b
dest.SetRGB(x,y,r,g,b);
}
}
}

ざっと書くとこんな感じ

0172デフォルトの名無しさん

2006/03/05(日) 00:31:14

>>170
専用クラスですか？

0173デフォルトの名無しさん

2006/03/05(日) 00:32:14

てかVGAってちっちぇーよｗ

0174デフォルトの名無しさん

2006/03/05(日) 00:32:50

誤爆ですｗ

0175デフォルトの名無しさん

2006/03/05(日) 00:37:46

>>171
ふつーはな、単なるunsigned char[]あたりに画像展開してそこで全部の処理を済ませてから最後の表示だけAPIでやる。
まぁ、WindowsならDIBSectionとか使うが。

0176デフォルトの名無しさん

2006/03/05(日) 00:52:28

やっぱwxWidgetsが遅いんじゃねーの。スレ違いだって

0177デフォルトの名無しさん

2006/03/05(日) 01:00:48

>>175
GetDataメソッドでポインタはとれるよ
内容は[RGBRGBRGB]ね
ふつーははわかるがそうすることで劇的に早くなるとは思えないわけですが
せいぜい２倍とかじゃないですかね？足りませんよ？

0178デフォルトの名無しさん

2006/03/05(日) 01:02:47

>>176
GetRed毎に座標をポインタに計算してunsigned char をreturnしてるだけです

0179デフォルトの名無しさん

2006/03/05(日) 01:04:17

1ピクセルごとにINRECTとか間抜けなことやるな。
事前に矩形の重ね判定やって必要な部分だけループ回せ。

0180デフォルトの名無しさん

2006/03/05(日) 01:06:00

>>179
そうすれば１０枚100msいけますか？

0181デフォルトの名無しさん

2006/03/05(日) 01:09:12

171の内容、どっからつっこんでいいかわからん......
とりあえずレイヤ一枚に対していちいちウィンドウシステム側の
バッファをワークエリア代わりにするのやめれ。

0182デフォルトの名無しさん

2006/03/05(日) 01:10:22

ワークエリア専用クラスですｗ

0183デフォルトの名無しさん

2006/03/05(日) 01:11:08

素直にGetRed()、SetRGB()辺りが遅いんじゃないかと思われ。

0184デフォルトの名無しさん

2006/03/05(日) 01:12:10

>>183
それはわかってるけど100msはいかないでしょ？

0185デフォルトの名無しさん

2006/03/05(日) 01:13:25

>>183
釣りじゃないとするとそうとしか考えられないよね。
処理速度上げたいっていうなら自分でメモリ確保して、ポインタでループまわしたらいいのに。

0186デフォルトの名無しさん

2006/03/05(日) 01:13:54

wxWidgetsが速いとか遅いとかいう以前に使う奴に最適化に関する知識が０なのが原因だろう。

0187デフォルトの名無しさん

2006/03/05(日) 01:16:16

　　　　　　,.ｨ , - ､.＿　　　、
.　　　　 ,ｲ/ l/　　　　￣￣｀ヽ!__
　　　ﾄ/ |'　{　　　　　　　　　　｀ヽ.　　　　　　　　　　　 ,ﾍ
　　Ｎ│ ヽ. `　　　　　　　　　　ヽ　　　　　 /ヽ　/　 ∨
　　 N.ヽ.ヽ、　　　　　　 ,　　　　　 }　　　　l＼/　　`′
.　　ヽヽ.＼　　　　　　 ,.ｨｲﾊ　　　　　 |　　＿|
　　ヾニｰ　__　_　-=_彡ｿﾉ u_＼ヽ、　 |　　＼　　　レイヤーが数百枚だとか
.　　　￣ﾞr=<‐ﾓﾐ､ﾆr;＝=ｪ;ｭ＜_ゞ-=7´ヽ　　　>　　　CPUが486とかいうオチの
.　　　　　 l 　￣ﾘーh ｀ｰ‐‐'　l‐''´冫)'./　∠__　　釣りだったんだよ！
　　　　　　ﾞiｰ- ｲ'__　ヽ､..＿__ノ　　ﾄr‐'　　　　/　　　
　　　　　　　l　　 `＿__,.、　　 u　./│　　　　/＿　
.　　　　　　ヽ.　 }z‐r--|　　　／　ﾄ,　　　　　 |　 ,、
　　　　　　　 >､`ｰ-- '　　.／　／　|ヽ　　　　　l／　ヽ　　 ,ﾍ
　　　　　　_,.／| ヽ`ｰ--‐ _´.. ‐''´ 　 ./　＼､　　　　　　　＼/　ヽ/
-‐ '''" ￣ /　 :| 　 ,ゝ=＜　　　　　　/　　　 |　`'''‐-　､.._
　　　　　/　　 !.／l;';';';';';';＼　　　 ./　　　　│ 　＿
　　　 _,＞ '´|l. ﾐ:ゝ､;';';_/,´＼　 ./|._ , --､　|　i´!⌒!l　 r:,＝i 　　
.　　　 | 　　 |:.l.　/';';';';';|=　　ヽ/:.|　.|l⌒ｌｌﾆ._ | ﾞｰ=':|　|. L._｣　））
　　　 l.　　 |:.:.l./';';';';';';'!　　 /:.:.| i´|.ｰ‐' | /　|　　 |.　!　　 l
.　　　　 l.　　 |:.:.:.!';';';';';';';'|　　/:.:.:.:!.|"'|.　　 l'　 │-==:|.　!　==l　　 ,. -‐;
　　　　　l　　 |:.:.:.:l;';';';';';';';|　/:.:.:.:.:| i＝!ｰ=;: l　　 |　　 l.　|　　 |　/ 　 //
　　　　 l　　|:.:.:.:.:l;';';';';';';'|/:.:.:.:.:.:.!│　l　　 l、　:|　　 |　}　＿|,.{::　　7　））
　　　　 l　 |:.:.:.:.:.:l;';';';';'/:.:.:.:.:.:.:.:|　|__,.ヽ､__,. ヽ._｣ｰ=:::ﾚ'　 ::::::|;　　 7
.　　　　　　l　|:.:.:.:.:.:.l;';';'/:.:.:.:.:.:.:.:.:.|.　＼:::::＼:::::　ヽ　 ::::::!′　:::| 　 .:/
.　　　　　　ｌ |:.:.:.:.:.:.:∨:.:.:.:.:.:.:.:.:.:.:.! 　 /ヽ:::　`:::　　　　::::　　....::....／　

0188デフォルトの名無しさん

2006/03/05(日) 01:16:55

xのループを外側に持ってくるやつとは話したくないなあ。

0189デフォルトの名無しさん

2006/03/05(日) 01:17:17

>>186
論点は100msオーダーを出す方法ですよ
最適化うんぬんは関係ありません
速度把握するために組んだコードなので最適化されてなくて当然です
まず組んでみて最適化したときの速度を予測します
いきなり最適化からはいるとデバッグ作業で何倍も時間を使います
そこで私なりに予測した結果この方法で100msオーダーは出せないという結論になったから
ここで質問してるわけです
経緯を説明するとこんな感じです

0190デフォルトの名無しさん

2006/03/05(日) 01:18:58

>>188
ぜんぜん話題がそれるけど、画像処理は走査線を意識してやる人が多いからxが内側でコーディングする人の方が多いよ

0191デフォルトの名無しさん

2006/03/05(日) 01:20:40

>>188
ああ、今書いたから外側になってるわｗ

0192デフォルトの名無しさん

2006/03/05(日) 01:27:20

どこが遅いのか把握できてないのに駄々をこねる厨がいるスレはここですか？

0193デフォルトの名無しさん

2006/03/05(日) 01:27:31

だってCPUも書いてないから比較のしようがないじゃん。いい加減消えろよ

0194デフォルトの名無しさん

2006/03/05(日) 01:32:25

ゆとり教育の弊害が画像処理スレッドにも・・・

0195デフォルトの名無しさん

2006/03/05(日) 01:32:30

Javaで100ms余裕だと言った人は結局どこへ？
その最適化したほうほうで100ms余裕だというのなら私にはそれをためす価値が出てくるわけですよ
使ってる平均的なものならね
多少高くでも１Gｈｚあたりでどうなるかくらい想像がつくでしょ
1GHxで100msです！！
えーっとCeleronにしといてｗ

0196デフォルトの名無しさん

2006/03/05(日) 01:35:07

JavaってなんだかんだいってもOpenGL実装しちゃってますからね
その辺詳しく

0197デフォルトの名無しさん

2006/03/05(日) 01:35:22

教える価値がない

0198デフォルトの名無しさん

2006/03/05(日) 01:36:42

>>197
なんだロジックを否定したいがためだけにここにいたんですか？ｗ

0199デフォルトの名無しさん

2006/03/05(日) 01:39:45

もういなくなるから安心しろ

0200デフォルトの名無しさん

2006/03/05(日) 01:42:21

語尾にｗ付き出したし釣り or 宿題確定な気がするが。

MMX以外の今まで言われたことをこなしてから出直してこい。

0201デフォルトの名無しさん

2006/03/05(日) 01:43:34

250x250程度の2枚の画像を回転させながら130枚くらい合成するのにCeleronM1.4GHｚで1秒弱程度。
DIBSectionを直接アクセスするけど、特に最適化なし。
多分、もまいのコードは遅すぎだと思われ。

0202デフォルトの名無しさん

2006/03/05(日) 01:57:01

>>201
ありがとう
そこまで実測値だしてくれると説得力がありますね
糸口が見つかりました

0203デフォルトの名無しさん

2006/03/05(日) 02:00:19

>>202
　　　　　　,.ｨ , - ､.＿　　　、
.　　　　 ,ｲ/ l/　　　　￣￣｀ヽ!__
　　　ﾄ/ |'　{　　　　　　　　　　｀ヽ.　　　　　　　　　　　 ,ﾍ
　　Ｎ│ ヽ. `　　　　　　　　　　ヽ　　　　　 /ヽ　/　 ∨
　　 N.ヽ.ヽ、　　　　　　 ,　　　　　 }　　　　l＼/　　`′
.　　ヽヽ.＼　　　　　　 ,.ｨｲﾊ　　　　　 |　　＿|　　
　　ヾニｰ　__　_　-=_彡ｿﾉ u_＼ヽ、　 |　　＼　　　当たり前のことをやってから
.　　　￣ﾞr=<‐ﾓﾐ､ﾆr;＝=ｪ;ｭ＜_ゞ-=7´ヽ　　　>　　　でかい口叩きやがれ！！
.　　　　　 l 　￣ﾘーh ｀ｰ‐‐'　l‐''´冫)'./　∠__　　　相手してくれた全員に
　　　　　　ﾞiｰ- ｲ'__　ヽ､..＿__ノ　　ﾄr‐'　　　　/　　　誤れ！！！！
　　　　　　　l　　 `＿__,.、　　 u　./│　　　　/＿　
.　　　　　　ヽ.　 }z‐r--|　　　／　ﾄ,　　　　　 |　 ,、
　　　　　　　 >､`ｰ-- '　　.／　／　|ヽ　　　　　l／　ヽ　　 ,ﾍ
　　　　　　_,.／| ヽ`ｰ--‐ _´.. ‐''´ 　 ./　＼､　　　　　　　＼/　ヽ/
-‐ '''" ￣ /　 :| 　 ,ゝ=＜　　　　　　/　　　 |　`'''‐-　､.._
　　　　　/　　 !.／l;';';';';';';＼　　　 ./　　　　│ 　＿
　　　 _,＞ '´|l. ﾐ:ゝ､;';';_/,´＼　 ./|._ , --､　|　i´!⌒!l　 r:,＝i 　　
.　　　 | 　　 |:.l.　/';';';';';|=　　ヽ/:.|　.|l⌒ｌｌﾆ._ | ﾞｰ=':|　|. L._｣　））
　　　 l.　　 |:.:.l./';';';';';';'!　　 /:.:.| i´|.ｰ‐' | /　|　　 |.　!　　 l
.　　　　 l.　　 |:.:.:.!';';';';';';';'|　　/:.:.:.:!.|"'|.　　 l'　 │-==:|.　!　==l　　 ,. -‐;
　　　　　l　　 |:.:.:.:l;';';';';';';';|　/:.:.:.:.:| i＝!ｰ=;: l　　 |　　 l.　|　　 |　/ 　 //
　　　　 l　　|:.:.:.:.:l;';';';';';';'|/:.:.:.:.:.:.!│　l　　 l、　:|　　 |　}　＿|,.{::　　7　））
　　　　 l　 |:.:.:.:.:.:l;';';';';'/:.:.:.:.:.:.:.:|　|__,.ヽ､__,. ヽ._｣ｰ=:::ﾚ'　 ::::::|;　　 7
.　　　　　　l　|:.:.:.:.:.:.l;';';'/:.:.:.:.:.:.:.:.:.|.　＼:::::＼:::::　ヽ　 ::::::!′　:::| 　 .:/

0204デフォルトの名無しさん

2006/03/05(日) 02:03:39

64x64のグレイ画像を10段ほどのフィルタリング処理して結果をリファレンスと比較するってループを
ざっと千万回ほど繰り返すと流石に数十分掛かるけどこれってアルゴリズムを見直せば速くなりますか?w

0205デフォルトの名無しさん

2006/03/05(日) 02:04:57

なります。

0206デフォルトの名無しさん

2006/03/05(日) 02:05:16

たいして実績もないのに便乗して言ってただけだから
具体的数字をだせと何度言ってもけむにまくばっかりだし
誤る？！必要性がないｗ

0207デフォルトの名無しさん

2006/03/05(日) 02:05:16

wxWidgetsがどんなもんか知らんけど、Get???(x,y)内部で入力範囲を検査したり、インライン関数になってなかったりするんじゃない？
そうだとしたら、直接アクセスするのと比べてかな～り遅くなるべ。

0208デフォルトの名無しさん

2006/03/05(日) 02:07:36

調べたらアルファブレンド事態の計算式を工夫する方法があったよ
a + (a -b) x apha
こっちのがでかいんじゃないかね？

0209デフォルトの名無しさん

2006/03/05(日) 02:09:26

>>206
>>201　=　>>203　だし。
>>201のコードの内容は、>>171が出た後にみんなが言ってるぐらいしかやってないんだよね。
当たり前のことをやってからでかい口きけと。

0210デフォルトの名無しさん

2006/03/05(日) 02:10:12

最初から言えばいいじゃんｗ

0211デフォルトの名無しさん

2006/03/05(日) 02:11:15

ｷﾀｺﾚ
恩を仇

0212デフォルトの名無しさん

2006/03/05(日) 02:14:51

>>189
5秒もかかるからなんとかしてくれって話じゃなかったの？
ヘタな釣りだな。釣られたけど。

0213デフォルトの名無しさん

2006/03/05(日) 02:18:23

>>212
100msは目標ですよ。
機能性文盲ですか？

0214デフォルトの名無しさん

2006/03/05(日) 02:19:35

今から組んでみるからまってくれｗ

0215デフォルトの名無しさん

2006/03/05(日) 02:25:05

改めてスレを見直して吹いた
ピクセルにアクセスするのにGetなんとか使ってる癖に>>131でMMXとか書いてるよｗｗｗ
ほんとになんも知らないんだな
チキショウ！釣りだといってくれｗｗハライテー

0216デフォルトの名無しさん

2006/03/05(日) 02:30:23

>>204
繰り返しの回数減らせばいいんじゃね。

0217デフォルトの名無しさん

2006/03/05(日) 02:49:31

VCが壊れたorz

0218デフォルトの名無しさん

2006/03/05(日) 02:52:44

int x,y,w,h;
grr_layer layer = m_layerlist[idx];
x = y = 0;
w = dest.GetWidth();
h = dest.GetHeight();
if(x < layer.m_x){
x=layer.m_x;
w = w - x;
}
if(y < layer.m_y){
y=layer.m_y;
h = h - y;
}
if(x + w > layer.m_x + layer.m_image.GetWidth())w = layer.m_x + layer.m_image.GetWidth() - x;
if(y + h > layer.m_y + layer.m_image.GetHeight())h = layer.m_y + layer.m_image.GetHeight() - y;

unsigned char *ptr_dest = dest.GetData();
unsigned char *ptr_image = layer.m_image.GetData();
unsigned char *ptr_mask = layer.m_mask.GetData();

ptr_dest += y * dest.GetWidth() * 3 + x * 3;
int ix = x - layer.m_x;
int iy = y - layer.m_y;
ptr_image += iy * layer.m_image.GetWidth() * 3 + ix * 3;
ptr_mask += iy * layer.m_image.GetWidth() * 3 + iy * 3;

int span_dest = dest.GetWidth() - (x + w) + x;
int span_image = layer.m_image.GetWidth() - (x + w) + x;
span_dest*=3;
span_image*=3;

0219デフォルトの名無しさん

2006/03/05(日) 02:53:17

int i,j,k;
for(i=y;i<=y+h;i++){
for(j=x;x+w;j++){
if(*ptr_mask){
for(k=0;k<3;k++){
int v = ptr_image[k] + (ptr_dest[k] - ptr_image[k]) * alpha;
}
}
ptr_dest+=3;
ptr_image+=3;
ptr_mask+=3;
}
ptr_dest += span_dest;
ptr_image += span_image;
ptr_mask += span_image;
}

これでいいだろｗ
コンパイラがいかれたｗ

0220デフォルトの名無しさん

2006/03/05(日) 02:57:22

>>219
厨の相手乙。素直なコードだとおもた。

VCがどうした？

0221デフォルトの名無しさん

2006/03/05(日) 03:01:06

>>220
厨が書いたコードですが何か？ｗ

0222デフォルトの名無しさん

2006/03/05(日) 03:02:54

>>189
いまさらだけど君ながらの予測がおかしいでFAじゃね？

ちまちました最適化のひとつが速度を2倍に上げるとわかったら
そんな方法を10個並べればktkr！っていうのが基本だから、
何かひとつのブレイクスルーですっきり速度100倍なんて期待しない方がいいよ。

0223デフォルトの名無しさん

2006/03/05(日) 03:03:41

>>221
で、100ms秒切った？

0224デフォルトの名無しさん

2006/03/05(日) 03:07:38

>>222
速度が倍になる最適化10個並べたら1024倍高速になるぞ。

0225デフォルトの名無しさん

2006/03/05(日) 03:11:45

1024倍までは無理でも5秒が50msになったら100倍だな。

0226デフォルトの名無しさん

2006/03/05(日) 03:13:23

>>224
何か問題でも？

0227デフォルトの名無しさん

2006/03/05(日) 03:18:38

>>223
ソースバグいっぱいあったけど
切った切ったｗ

0228デフォルトの名無しさん

2006/03/05(日) 03:19:53

最適化スレ逝け

0229デフォルトの名無しさん

2006/03/05(日) 03:20:59

もうちょっといろいろ負荷かけてみますｗ

0230デフォルトの名無しさん

2006/03/05(日) 03:25:53

まあがんがれ。

描画にも20msかかるとか。
ttp://diarynote.jp/d/35749/20051213.html
いや、全く違う話ならｽﾏｿ。

0231デフォルトの名無しさん

2006/03/05(日) 03:28:24

やっぱ１０枚くらいかさねると１秒くらいかかるｗ

0232デフォルトの名無しさん

2006/03/05(日) 03:31:24

>>230
はなからwxBitmapにすることもできるのでその辺はなんとかなります

0233デフォルトの名無しさん

2006/03/05(日) 03:55:28

for(i=y;i<=y+h;i++){　＊A
　for(j=x;x+w;j++){　＊A
　　if(*ptr_mask){
　　　for(k=0;k<3;k++){　＊B
　　　　int v = ptr_image[k] + (ptr_dest[k] - ptr_image[k]) * alpha;
　　　}
　　}
　　ptr_dest+=3;
　　ptr_image+=3;
　　ptr_mask+=3;
　　}
　ptr_dest += span_dest;
　ptr_image += span_image;
　ptr_mask += span_image;
}

＊A　初期値、終了条件、増分の演算をポインタで行いましょう。
＊B　ループを展開しましょう
･･･この程度のことはコンパイラがやるんで、これ以上の最適化はSIMD命令に挑戦しましょう。

0234・∀・）っ-○●◎- ◆Pu/ODYSSEY

2006/03/05(日) 04:44:29

wx使ってるのはクロスプラットフォームにしたいから？
それともVC++やBCB製品版が高いから？

0235デフォルトの名無しさん

2006/03/05(日) 12:42:49

>>231
くどいようで巣漫画、どこで時間を浪費してるか細かく推測しろ。
せめてループの中か外か。2枚を10枚にするときに他に増えてる処理とか。
「よくわからんが、このやり方じゃ遅いよママン！」では話にならんｗ

もうひとつ。
wxWidgetsや他のでもいいけど同様の処理をしてるプログラムを
くまなく探した？

0236デフォルトの名無しさん

2006/03/05(日) 13:32:59

>>234
高いからってのもあるし、クロスにしたいってのもある
クロスを維持したままアセンブラ入れるとなるとこれは日と手間ですねｗ
あとwxWidgetsはほとんどの画像形式をたった２行でRGB配列に変換できるし
メモリ管理を気にしないですむからMFCより画像処理は優秀だよ
もとからRGB配列で管理してるからCreateDIBより高速だしね

>>235
アルファブレンドが高速になったからこんどは拡大縮小や更新範囲がネックになってきた
かなり手をいれないといけないｗ
一応さがしたというか、wxWidgetsはグラフィック処理の特別なアルゴリズム実装はほとんど持ってない
完成品でグラフィック系のものは見つからなかったね
もともとドキュメント資料がほとんど皆無だしねｗ

0237デフォルトの名無しさん

2006/03/05(日) 14:29:46

>>236
いや、wxWidgetに関係なく速く動いてるソースを持ってきて、
あとは特有の処理が必要な部分だけ書きなおせばいいでしょ。
完成品でなくてもその部分だけで十分だし。

wxWidgetが内部で何してるか把握してるんだから
速度の見積もりも含めて簡単だよｗ
がんがれ。

0238デフォルトの名無しさん

2006/03/05(日) 22:33:57

いくらなんでも、こりゃ釣りじゃないの？
高速化なんて、まずアルゴリズムを考えて、あとは地道にやって行くしか
ないことは、普通のプログラマなら誰でも知ってるだろ。

ただ、もし本気で言っているなら、あなたに高速化は無理だ。
計測→高速化、を繰り返して地道にツブしていくのが本質だから。

αブレンドなんて、処理自体は単純だし、枯れてるわけだから、
ソフトウェアでそれを行うためのアルゴリズムに画期的なものがあるわけじゃない。
例えば、ＭＭＸで最高８倍だからムダなんて事はない。
もちろん問題によっては（細かい領域を毎回関数を呼び出して転送し、その中だけ
ＭＭＸで記述しているような場合）EMMSによるオーバーヘッドが多すぎて
役に立たないだろうけれど、1024x768の領域の転送なら十分役に立つよ。
試しに、PIII-1G でMMXのコードを書いてみた。パイプラインは特に考慮しないで、
1024x768(32bit BMP) １枚のブレンドに最悪（転送のない部分がない状態）で
10ms くらいだよ。通常は透明な部分があるので、5ms-7msくらいだろう。

ま、地道にがんがれ。

0239デフォルトの名無しさん

2006/03/05(日) 23:06:59

これまでのスレで画像処理すげーと思ったやつ。
他に何かないですか？
ttp://www.cs.huji.ac.il/~yweiss/Colorization/
ttp://www.cse.ucsc.edu/~milanfar/SR/sr-examples.htm

0240デフォルトの名無しさん

2006/03/06(月) 00:09:00

MMXもDNowもできれば使いたくないな

0241・∀・）っ-○●◎- ◆Pu/ODYSSEY

2006/03/06(月) 00:12:29

EMMSっていちいち関数抜けるたびにやる必要ないよ。
x87のオペレーション使う前にMMステートが確実にクリアされてればいい。
MS C/C++コンパイラならコンパイル時に警告してくれるしね。

0242デフォルトの名無しさん

2006/03/06(月) 02:11:45

sage

0243デフォルトの名無しさん

2006/03/06(月) 02:15:10

まあ、MMX使うほど速度にシビアな処理で、インライン展開されない関数呼び出しとかやる奴は無条件ではったおしていいと思うが。

0244デフォルトの名無しさん

2006/03/06(月) 03:20:25

>>239
俺はこれも感動した。
ttp://autotrace.sourceforge.net/
ttp://potrace.sourceforge.net/

ただ、potraceのサンプルのepsファイルをDLしても
上手く開けなかったが…

このスレで見たわけじゃないけど、俺は↓も結構好き。
ttp://scale2x.sourceforge.net/
ttp://www.hiend3d.com/hq2x.html
どちらも、色数少なめの低解像度画像をリアルタイムで
綺麗に拡大するアルゴリズム。

何か面白い使い道ないか考え中。
ちなみに、写真に適用してみたら全然駄目だった。

0245デフォルトの名無しさん

2006/03/06(月) 07:45:41

＞ttp://www.hiend3d.com/hq2x.html
これはなかなかオって思ったけど、2倍とか切りの良い数字意外に適用できるのか？
サンプル画像には1.1倍や微妙に回転などが残念ながら見当たらなかった。

あと、フォトショが速いって言ってる上の奴だけど、前提が
間違ってるんじゃない？　フォトショは全画面更新するケース
ではかなり遅いよ。場合によっちゃ目に見えるくらい。

編集中はストレスにならないように更新したペンの周囲だけ
計算してるだろうから、レイヤーが重なりまくっててもそう
負担にならないだけだろ。ペンのサイズを極端に大きくすれば
更新しているティアリング（横に切れる奴）が見える場合もある。

それとレイヤーが12345(5が上)の場合、3を更新したとき12は
あらかじめ計算できるけど45もあらかじめやっとけって言うのは
知識の無い奴の言ってることなのか？　45が計算し直しなのは
そちらが正しい。

あらかじめ45を計算できる手法があったら俺も知りたいもんだ。
4が不透明な場合以外は計算し直しになるだろ。

0246デフォルトの名無しさん

2006/03/06(月) 09:15:28

>>245
Scale2xもhq2xも整数倍の拡大のみ。
ちなみにScale2xの方は色数を増やさず、元の色のまま変換する。

Scale2xはソースを見るまでもなく、Algorithmってページを見れば
30秒で理解できるような簡単な処理。

0247デフォルトの名無しさん

2006/03/06(月) 10:14:52

>>245
> あらかじめ45を計算できる手法があったら俺も知りたいもんだ。
なんかできそうだぞ。

　α*上の画像 + (1 - α)*下の画像
の dest を１つずつ下のレイヤにしていけばいいわけだろ？
で、構文木を再帰で生成させて出力したのを観察して、手でまとめたのが下。
　x0*a0
+ x1*a1*(1 - a0)
+ x2*a2*(1 - a0 - a1*(1 - a0))
+ x3*a3*(1 - a0 - a1*(1 - a0) - a2*(1 - a0 - a1*(1 - a0)))
+ x4* (1 - a0 - a1*(1 - a0) - a2*(1 - a0 - a1*(1 - a0)) - a3*(1 - a0 - a1*(1 - a0) - a2*(1 - a0 - a1*(1 - a0))))

x4 は、12 を合成したもの。
で、3 を編集中に変更があるのは、a3 と x3。
αがピクセル単位じゃなければ割といいんじゃない？
合成が加算になるのもポイント高いかもよ？

って、実は試してないんだｗ
構文木出力にバグがあったり、手でまとめるときにミスしてたらゴメンｗ
「知識の無い奴」なんて言ったんだから、責任もって検算か反証してくれるよねｗ

0248デフォルトの名無しさん

2006/03/06(月) 10:36:33

でもさ、先に計算しておくって・・・
1+2と1+2+3と1+2+3+4と、とか、全部用意しとかないと意味無いと思うんだけど、
そういうもん？

0249デフォルトの名無しさん

2006/03/06(月) 12:06:52

さすがに現在使ってるレイヤくらいはわかってるだろ

0250デフォルトの名無しさん

2006/03/06(月) 12:12:49

なるほど　ゴミレスすまんかった

0251デフォルトの名無しさん

2006/03/06(月) 14:29:22

>>247
計算コストが変わらない気がするんだがｗ

0252デフォルトの名無しさん

2006/03/06(月) 14:36:50

変なのがいついちゃったな･･･

■ このスレッドは過去ログ倉庫に格納されています

画像処理 その６

画像処理その６