- 1 名前：デフォルトの名無しさん [2011/04/04(月) 14:56:41.07 ]
- 画像処理プログラミングについて質問、議論を行うスレッドです
・画像処理について素人同士で大激論
・初学者の質問に対してやさしく(的を外れた)解答を与える
・その道の玄人も大歓迎
前スレ
画像処理 その12
hibari.2ch.net/test/read.cgi/tech/1247100724/
- 413 名前：デフォルトの名無しさん mailto:sage [2012/02/04(土) 16:41:48.44 ]
- マシンパワーに頼った実装ってなんかつまらないな
- 414 名前：デフォルトの名無しさん [2012/02/04(土) 20:06:53.47 ]
- マシンパワーを引き出すのも面白いぞ
- 415 名前：デフォルトの名無しさん mailto:sage [2012/02/04(土) 21:37:39.20 ]
- だからって16bitCPUで32bit使ったり、32bitCPUで16bit扱うのはマヌケだろう？
グラフィック分野では、CPUやGPUの実装に合わせてゴリゴリ書いて
パフォーマンスを叩き出すのが昔からの慣例。
- 416 名前：デフォルトの名無しさん mailto:sage [2012/02/04(土) 23:00:30.46 ]
- 最適化ってその時々の中流機で速いことに意味があると思う
ハードを追加することが前提ならいくらでも金かけりゃいいってことになってつまらん
- 417 名前：デフォルトの名無しさん mailto:sage [2012/02/04(土) 23:13:43.23 ]
- ハードを追加することでコンスタントに処理速度が上がってく段階になると、
さすがにプログラマとしてはつまらなくなると思う
でも、例えばシングルコアがマルチコアになったとか、
複数のマシンをLANで繋いで負荷を分散できるようになったとか、
GPUが計算に使えるようになったとか、
CPUがCellに変わったとか
そういう劇的な変化時におけるパワープレイは、それはそれで面白い
その環境に最適化する場合の考え方ががらっと変わるからな
パワープレイの方法を間違うと本来の力が全然が出せないし
- 418 名前：デフォルトの名無しさん [2012/02/04(土) 23:16:59.74 ]
- >>417
>ハードを追加することでコンスタントに処理速度が上がってく段階になると、
>さすがにプログラマとしてはつまらなくなると思う
処理速度に余裕ができた分、新しいアルゴリズムを追加できるように
なるんだから面白くなるんじゃないの
- 419 名前：デフォルトの名無しさん mailto:sage [2012/02/04(土) 23:46:23.11 ]
- >>418
人によって段階をどう捉えるかは違うけど、私は次のような段階を考える
1. 様々なアルゴリズムを考え、実験し、検証する（計算上の仮想実験も含む）
2. ハードが変化し、1のアルゴリズムで実用的になるものも現れる
3. ハードの追加によってコンスタントに処理速度が上がってく
この段階で私がプログラマとして最も面白いと感じるのは 1 の段階
次に面白いのは 2 の段階だが、これはどちらかと言うと、
1 のアルゴリズムが使えるようになったおかげで可能になった
他の処理の実装などが面白い
3 の段階になると、処理速度が上がることが分かっているから、
単なる作業と確認でしかなくなる
確かにこの段階でも 2 の様なことは起きるのだが、
ワクワク感やドキドキ感は無いな
- 420 名前：デフォルトの名無しさん [2012/02/04(土) 23:51:17.93 ]
- いや、だから、3の段階に達したらまた別の
アルゴリズムを考える1に戻ればいいじゃん
処理速度に余裕ができたんだから新しいアルゴリズムを追加できるんだよ
- 421 名前：デフォルトの名無しさん mailto:sage [2012/02/05(日) 00:18:39.70 ]
- >>420
> いや、だから、3の段階に達したらまた別の
> アルゴリズムを考える1に戻ればいいじゃん
全くその通り
どうも言い方が悪かったみたいだ
あるひとつの方法に関して、その実装が
ハードを追加することでコンスタントに処理速度が上がってく段階になると、
その環境でその方法を使い続けることはプログラマとしてはつまらなくなる
（仕事としては、こちらの方が圧倒的に多いが）
- 422 名前：デフォルトの名無しさん mailto:sage [2012/02/05(日) 00:39:57.52 ]
- >>421
いや、違うか
何て言えば良いのかな・・・
目標 --> 達成 --> 目標 --> 達成・・・というプロセスが続いていくわけだが、
ハードを追加することでコンスタントに処理速度が上がってく段階というのは、
その目標を達成するのにハードの追加で事足りてしまう段階だ
>>419 の 1 の段階は目標を達成するための行為であり、そこで複数の方法を考える
その方法は 2 の段階で実用になるものもあるだろうし、そこで新たな課題が出ることもある
しかし、3の段階になると、その方法を使ってあとはマシンパワーを上げていくだけになる
要求に対して足りないパワーを補うだけ
例えばサーバーやコアの数を増やしたり、メモリを増やしたり
この段階では、この方法に関してはもうプログラマ（私）があれこれ模索することもなくなり、
プログラム的にはほとんどメンテだけの状態に入る
何が言いたいのかというと、>>413 はつまらんと言うが、
3 と違って 2 の段階でマシンパワーに頼るのはスゲー面白いだろ、と言うこと
ほとんどスレチだからもう終わる、長々とすまんかった
- 423 名前：デフォルトの名無しさん mailto:sage [2012/02/05(日) 03:54:10.98 ]
- 既存の画像処理をOpenCLで並列化なんてのはおもしろいぞ。
画像処理はほとんど反復処理だから劇的に高速化する。
- 424 名前：デフォルトの名無しさん mailto:sage [2012/02/05(日) 04:42:11.21 ]
- 元々が糞プログラムじゃない限り劇的にはならないよ
- 425 名前：デフォルトの名無しさん mailto:sage [2012/02/05(日) 08:10:58.82 ]
- 無知乙
ハードウェアの性能が何桁違うと思っているんだ
- 426 名前：デフォルトの名無しさん mailto:sage [2012/02/05(日) 09:52:01.29 ]
- 最近は何桁も違わないよ
- 427 名前：デフォルトの名無しさん mailto:sage [2012/02/05(日) 11:47:31.03 ]
- GPUとかFPGA使って高速化したっていう発表は学会でもあるけど、フーン当たり前じゃんって反応だな
既存のアルゴリズムを複数スレッドに分けるだけじゃなくて、マルチコアを前提とした新しいアルゴリズムでないと感動しないな
- 428 名前：デフォルトの名無しさん mailto:sage [2012/02/05(日) 11:50:11.65 ]
- フーン。
- 429 名前：デフォルトの名無しさん mailto:sage [2012/02/05(日) 12:00:10.26 ]
- >>427
へー
- 430 名前：デフォルトの名無しさん mailto:sage [2012/02/05(日) 12:03:23.32 ]
- 感動って無知だからできるんだぜ。
- 431 名前：デフォルトの名無しさん mailto:sage [2012/02/05(日) 18:35:00.12 ]
- ハードによる高速化はシングルスレッドものと比較して早いって言ってるだけで
マルチスレッドCPUで真面目に記述したものとは大差ないんだよな
それとCPUのシングルとマルチでの比較だけど
マルチだとどうしても制御構造で無駄な処理が大量に入り込むから
シングルでMMXとか使った場合と比較しても大差ないんだよな
CPUのコア数が数十とかにでもならない限りは恩恵は実感出来ないだろうな
- 432 名前：デフォルトの名無しさん mailto:sage [2012/02/05(日) 19:16:35.65 ]
- SSE ならまだしも、MMX って古代技術だろ
今の時代 MMX の恩恵が受けられる分野って何がある？
- 433 名前：デフォルトの名無しさん mailto:sage [2012/02/05(日) 19:33:58.25 ]
- たぶんSIMD拡張全般を指して言ってる？
- 434 名前：デフォルトの名無しさん mailto:sage [2012/02/05(日) 20:16:11.16 ]
- MMXじゃなくてMMXとかって書いてあるだろ
日本語読めない人なのか？
- 435 名前：デフォルトの名無しさん mailto:sage [2012/02/05(日) 20:27:06.92 ]
- >>434
だから、その中には MMX も含まれてるんだろ？
シングルでMMX使った場合と比較しても大差ない場合もあるんだろ？
- 436 名前：デフォルトの名無しさん mailto:sage [2012/02/05(日) 20:49:39.87 ]
- 一番わかり易い例を出せば
シングルスレッドで画像処理をする場合はたいていメモリポインタは加算演算だけで
現在のピクセルデータの場所を計算出来る
しかしマルチスレッドでやろうとするとピクセル毎に乗算でポインタを計算しないと出来ない
アルゴリズム的な総計算回数ではシングルのほうが圧倒的に高速なんだよな
- 437 名前：デフォルトの名無しさん mailto:sage [2012/02/05(日) 21:18:04.03 ]
- >>436
画像の一部に処理を施すのなら、どちらにしても
アドレスは (ベースアドレス + x + y * ピッチ) で計算する必要があると思うが
それに、そもそも今時かけ算が足し算の2倍時間がかかるなんてことは無いんだから、
マルチコアの環境ならマルチスレッドにして同時に計算した方が速い場合の方が
圧倒的に多いと思うぞ
輪郭摘出しかり、グレースケール化しかり、ノイズ除去しかり・・・
- 438 名前：デフォルトの名無しさん mailto:sage [2012/02/05(日) 21:37:49.20 ]
- >>437
>ベースアドレス + x + y * ピッチ
足し算と掛け算が同じ処理時間だと過程してもこの式を見る限り４倍ですが？
- 439 名前：デフォルトの名無しさん mailto:sage [2012/02/05(日) 21:47:39.87 ]
- >>438
おまえの言ってる意味が分からない。コード書いたことないだろ。
- 440 名前：デフォルトの名無しさん mailto:sage [2012/02/05(日) 21:51:09.74 ]
- >>439
ほとんどの画像処理は１次元の概念だけで処理出来る
だから1ピクセルにつきポインタ加算を１度すればいいだけ
- 441 名前：デフォルトの名無しさん mailto:sage [2012/02/05(日) 22:16:47.17 ]
- >>440
言ってる意味が分からない。おまえ画像処理したことないだろ。
- 442 名前：デフォルトの名無しさん mailto:sage [2012/02/05(日) 22:24:24.94 ]
- ノイズリダクションというよくあるフィルターを考えても1ピクセルだけで処理すとかないし。
100歩譲って全ピクセルなめるだけと仮定しても、
2スレッドに分けたときそれぞれのベースアドレスが変わるだけで、
どっちのスレッドでも、ポインタをインクリメントするだけ。
なにが4倍なのか本当に意味が分からない。
- 443 名前：デフォルトの名無しさん mailto:sage [2012/02/05(日) 23:05:33.38 ]
- >>442
ノイズリダクションも全８方向の１時限的相対位置を加減算するだけでデータ位置が特定出来る
- 444 名前：デフォルトの名無しさん mailto:sage [2012/02/05(日) 23:14:40.65 ]
- もともと掛け算命令のない8ビットCPUの頃からアドレス計算は加減算と論理演算で計算してる。
ベースアドレス + x + y * ピッチなんてのは人間の理解用だ。
そもそもx86のアドレッシングは強力だ。アドレっシングで遅くなるとかほんと意味不明。
はっきりいって画像処理なんていう並列しやすい処理は、
スレッドが二つになれば速度は倍近く早くなる。
- 445 名前：デフォルトの名無しさん mailto:sage [2012/02/05(日) 23:19:37.83 ]
- だからこそスレッド数を増やすだけのGPU実装を最適化というのは夢が無いよ
- 446 名前：デフォルトの名無しさん mailto:sage [2012/02/05(日) 23:32:15.18 ]
- >>438
お前さ、簡単なグレースケール化でいいから、
シングルスレッドと、マルチコア＋マルチスレッドの両方をプログラムしてみて、
処理速度を計測してみなよ
- 447 名前：デフォルトの名無しさん mailto:sage [2012/02/05(日) 23:37:38.86 ]
- GPU内部で死ぬほど並列化していて、しかもそれがプログラマブルだというのに
それを使わないほうが夢があるとかどうかしてる。
楽してGPGPUライブラリ使えよ。
- 448 名前：デフォルトの名無しさん mailto:sage [2012/02/05(日) 23:44:02.87 ]
- これから画像処理の最適化が盛り上がりそうなのってスマートフォンじゃん
NEONベースの最適化ってどれくらい効果あんの？
- 449 名前：デフォルトの名無しさん mailto:sage [2012/02/05(日) 23:52:59.78 ]
- >>446
9600GTでさんざんやったが結局CPUと変わらないという結論に達した
CPUでのマルチスレッド化もやってみたが
区画を複数に分割してもそれぞれの境界をうまく相互作用させないといけない
単純にシングルでやるみたいな加算でループ一発とは行かないんだよ
だから２コアでやってみたが結果は変わらない
４個なら多少は早いかもしれないが多少だろうな
- 450 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 00:00:24.29 ]
- >>449
CPUでのマルチスレッド化をやっても上手く行かなかった原因が
> 区画を複数に分割してもそれぞれの境界をうまく相互作用させないといけない
であり、また >>436 だと結論づけたのか
分析力が欠乏していると言わざるをえない、仕事仲間じゃなくて本当に良かった
では、他の人たちが画像処理のマルチスレッド化で成功しているのを見て、お前はどう思う？
魔法でも使ってると思ってるのか？
- 451 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 00:03:29.85 ]
- >>431
まずSIMDとマルチスレッドは同時に使えるわけだが
GPUはメモリの転送でかなりのオーバーヘッドがあるから
グレースケールのような単純処理だとほとんど変わらないけ
大きいガウシアンフィルタのような転送するデータ量に対して計算が多い処理ならかなり速くなるぞ
- 452 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 00:05:17.93 ]
- >>450
何も成功してる例なんてないって
だからSIMDを使ったシングルが一番効率がいい
速度と作りやすさのバランスでね
早くなったと言ってるのは最適化されてないプログラムと比較して言ってるか
CPUはスペック低くしてハードだけ高スペックにしてるとかそんなもん
詐欺だよ詐欺
- 453 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 00:06:03.66 ]
- >>451
だからマルチスレッドのアルゴリズムが高コストになるから意味ないってｗ
- 454 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 00:36:35.56 ]
- >>452
例えば Adobe Lightroom がマルチコア環境で処理が速くなるのは、
シングルコア環境時は拙いコードが走っていたり、
CPUはスペック低くしてハードだけ高スペックにしてる環境での比較だからなのか？
- 455 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 00:52:22.64 ]
- >>449
ありえね～www
100%おまえのバグだろw
- 456 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 01:04:47.31 ]
- アセンブラの知識が不足しまくってんだろうな。
どういう処理にコストがかかるとか全然分かってないのだろう。
境界をうまく相互作用と言ってる時点で設計が間違ってる。
無駄な分岐判定でストールしまくってるコード書いてるんだろ？
- 457 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 01:11:57.79 ]
- この流れだとGPU凄いよ派と大したことない派で簡単なコード公表するしか決着つかないんじゃね？
2値化くらいの簡単な処理なら表にできないもんかね
- 458 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 01:17:06.29 ]
- >>454
使ったことがないから知らないが早くなるのか？
明らかに見ただけで分かるくらい劇的か？
単に画像処理とは無関係なUI関係が早くなってるだけじゃなく？
>>456
だいたいグレースケールみたいに単純な処理はむしろマイノリティだろう
例えばラベリング処理とかどうする？
- 459 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 01:30:40.18 ]
- >>457
そのくらい単純だとメモリアクセスやディスクIOが律速になりそう
- 460 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 01:30:51.41 ]
- >>457
簡単すぎる処理だと、たんなるメモリ速度のベンチマークになるだけ。
それなりに複雑な処理やらせないと駄目。
- 461 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 01:41:23.67 ]
- 複雑な処理になるとピクセル情報を判定タスクという単位にしてスタックにためていって
各スレッドはスタックから順次取り出して判定処理をしてタスクを追加するという作業を繰り返すことになる
スタックの排他制御での時間ロスが発生する
メモリも膨大に食うし
遅い
- 462 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 01:45:00.77 ]
- なぜ排他制御がいる？
マルチスレッドでは同期コストが一番高いというのに。
基本を無視して設計し杉。
同期が頻発するところは分けてはいけない。鉄則です。
- 463 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 01:47:33.21 ]
- スタックを複数スレッドで共有とか狂気w
- 464 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 01:47:50.08 ]
- >>462
>同期が頻発するところは分けてはいけない。鉄則です。
そんなこといったら画像処理のほとんどは並列化出来ないってことだから
言ってる通り、マルチスレッドの恩恵はない
- 465 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 01:50:15.89 ]
- 意味不明。全くの逆で画像処理のほとんどは並列化可能。
そもそもGPUはバケモノじみた並列化をした実装になってる。これをどう説明するのか。
いくらなんでも素人過ぎる。
- 466 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 01:55:41.29 ]
- そんな事よりマンガミーヤのリニューアル版作れる人が居ない事のほうが問題
- 467 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 02:10:11.56 ]
- 高速化出来るのはもともと高速な分野だけ
- 468 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 02:25:04.14 ]
- カメラ画像解析プログラムを良くかくけど、並列計算してくれるライブラリー(IPPとかIPL,MP）に処理を投げるとかなり速くなるよ。
ただ主にはやくなるのは画像取得や画面描写のところだね
二値化→オープニング→ラベリング
とか処理結果を引き継いで処理していくのはなかなか並列計算しにくいかな
- 469 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 07:23:18.71 ]
- >>458
全く違う、目に見えて速くなる
それはそうと
> 単に画像処理とは無関係なUI関係が早くなってるだけじゃなく？
こう思った理由が気になる
マルチコア＋マルチスレッドで速くなるという話で、
なんで画像処理とは無関係なUI関係が速くなると思ったのだ？
お前はマルチスレッドでUI関係が速くなるライブラリでも自作してたのか？
今時UI関係が速くなるという状況がよく分からんのだが
そもそも、お前の言う「UI関係」って何だ？
- 470 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 09:02:03.08 ]
- >>463
461が1ピクセルごとにタスク切って同期化してるならアホとしか言えんが
Producer-Consumerでキューなりスタックなりがいるのは当たり前だろ
- 471 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 12:20:37.71 ]
- GPUのレンダリングパイプイランの実装がどうなってるか理解してるか？
同期というのは、同時にアクセスする可能性がある設計になってるから必要なんだよ。
もしそういう設計ならその設計は既に間違ってんだよ。
Producer-Consumerとか言ってる時点で設計が間違ってる。
画像処理で採用するパターンではない。
- 472 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 13:10:38.39 ]
- >>470はスレッドプールみたいなモノの事を言いたかったんじゃないの？
- 473 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 13:11:48.78 ]
- ていうのは嘘で、タスクキューみたいなやつ。
- 474 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 13:13:09.51 ]
- というわけでさようなら！
- 475 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 19:06:06.63 ]
- 同期するようなのは並列化出来ないってのが本来の主張であって
なぜなら画像処理の大部分は同期処理が必須という前提があるからね
「同期を伴うものを並列化するのは設計の時点で間違い」という主張は意味不明なんだけど
- 476 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 19:09:32.98 ]
- なにを言ってる意味が分からない。
- 477 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 19:19:34.09 ]
- >>475
同期処理が必須の画像処理と、並列化できる画像処理
10個くらいそれぞれ箇条書きで書いてみなよ
（10個も思いつかんかも知れんが）
認識が間違ってたらみんなで指摘し合えば良い
- 478 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 20:06:10.38 ]
- >>477
高速化出来るのは単純な微積分問題だけ
つまりぼかしやグレースケールやらといったフィルタ系の
CPUでも十分実用レベルだろってものだけ
同期が必要になるのは
オブジェクト検出、ラベリング、パターンマッチなど
一番高速化したいものたち
- 479 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 21:41:08.71 ]
- どうも、処理全体を一つの大きな塊と考え、
それを等分しようとしてできないと言っているような感じがする
- 480 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 22:15:02.97 ]
- >>478
君が同期が必要だと思っているその３つは全て並列処理することで高速化可能
それぞれ一例を挙げると・・・
オブジェクト検出は検出したいオブジェクトのサイズがだいたい分かっていれば、
画像を分割して、それぞれでオブジェクト検出を並列にできる
検出したいオブジェクトが分割の境界にまたがる恐れがあるのなら、
単に分割するのではなく、オブジェクトのサイズを考慮してオーバーラップさせればいい
（この方法はオブジェクトに対して画像サイズが小さいと効果が無いが）
ラベリングは行毎に横方向にスキャンし上の行との関連を調べながら行うのなら、
画像を何行かずつに分けてそれぞれ並列にラベリングし、
最後に境界線の上下の繋がりを調べれば良い
パターンマッチも、ある程度絞った候補を最後に総当たりして、
それぞれとのマッチング度合いを測るところで並列処理できる
ランダムな数値が並んでいる１次元配列に特定の数値が入ってるかを調べる処理が
マルチスレッドで高速処理できるのと「概念的には」同じだ
この部分を並列化することで高速化できるから、
その前のある程度絞る部分も検査基準を下げて高速化の恩恵が受けられる
- 481 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 23:46:15.31 ]
- GPU意味ない派がシングルコアAVXでGPU並の速度出せば納得するけどね
ラベリングでもテンプレートマッチングでも何でもいいけど
- 482 名前：デフォルトの名無しさん mailto:sage [2012/02/07(火) 00:02:57.93 ]
- 並列処理もまともに設計できない馬鹿素人を相手にするのはもう止めときましょう。
建設的ではない。
- 483 名前：デフォルトの名無しさん mailto:sage [2012/02/07(火) 00:55:53.73 ]
- >>480
条件が限られすぎ
一部分だけ並列化したって労力の割に効果はほとんどない
>>481
GPUが早いかどうやって話はしてない
無駄なプログラムを書く労力を使ってまでして得るような速度ではないという話
>>482
まともに設計しないといけない時点で思想自体が馬鹿なんだと気がつこう
- 484 名前：デフォルトの名無しさん mailto:sage [2012/02/07(火) 01:32:59.67 ]
- オーダー減らないと意味ない派の研究者と20%も高速化すれば御の字の技術者が争ってたりしないか？
- 485 名前：デフォルトの名無しさん mailto:sage [2012/02/07(火) 07:23:06.33 ]
- >>483
> 条件が限られすぎ
オブジェクトのサイズがだいたい分かっていればの部分か？
普通は何のオブジェクトを抽出するか設計する段階で、
画像のサイズに対するオブジェクトのサイズの割合は
だいたい適正値の範囲を決めておくものだが、君は決めないのか？
定点カメラで車の交通量を測る場合然り、
デジカメで被写体の顔を認識する場合然り
> 一部分だけ並列化したって労力の割に効果はほとんどない
その一部は全体のボトルネックになっている部分だったりする
君は当然「>>480 と同じ方法」で実験してみて、
でもそれほど処理速度が出なかったんだよね
分析した結果どこがボトルネックになってたと結論づけた？
- 486 名前：デフォルトの名無しさん [2012/02/08(水) 05:57:38.34 ]
- 馬鹿は黙ってろ
- 487 名前：デフォルトの名無しさん mailto:sage [2012/02/08(水) 08:51:43.04 ]
- 具体的な移動体検出 背景差分なんかで並列処理する方法を知りたい。
私はオーダー計算減らさないとあんまり効果ないんじゃね？派
- 488 名前：デフォルトの名無しさん mailto:sage [2012/02/08(水) 09:17:38.77 ]
- >>487
フレーム間のピクセルの差をとるループやその累積を更新するループを並列化するだけだ。
オーダー減らなくても4倍、8倍、300倍速くなれば、
他のもっと複雑な計算もできるようになって
時間的な制約でできなかった高精度な方法も使えるようになってきたり
数日かかってたような処理が数時間でできるようになってうれしいだろ。
実用に使ってないやつは時間的制約なんてのが無いから分からないだろうが。
- 489 名前：デフォルトの名無しさん mailto:sage [2012/02/08(水) 15:50:38.82 ]
- >>487
初心者なのになんで～派とか言ってんの？
- 490 名前：デフォルトの名無しさん mailto:sage [2012/02/08(水) 17:34:29.60 ]
- >>489
初心者も細分化されてんだよ
- 491 名前：デフォルトの名無しさん mailto:sage [2012/02/08(水) 17:40:09.72 ]
- 単に「自分は馬鹿だから並列処理ができない派」ってことだろ。
- 492 名前：デフォルトの名無しさん mailto:sage [2012/02/08(水) 19:21:22.06 ]
- そもそも並列化によってオーダーが減る事はあり得ない
にも関わらず並列化の研究が盛んで、かつ有益な結果が出続けてるのは、
>>488 の言うように同じオーダーでも係数の違いに意味がある処理もあるからだ
- 493 名前：デフォルトの名無しさん mailto:sage [2012/02/09(木) 05:57:44.86 ]
- 確かに、アルゴリズムの工夫で計算量のオーダーが2次元から1次元になったとしても
計算速度が100倍、1000倍になるとは限らないからな
並列化で処理速度が100倍、1000倍になるほうが嬉しいことのほうが多いんじゃないか？
- 494 名前：デフォルトの名無しさん mailto:sage [2012/02/09(木) 08:17:35.72 ]
- 専用ハード使って１００倍ならスーパーコンピューターで１兆倍でもやればって話なわけで
現状のマルチコアCPUもGPUも１０倍すらいかないよ
- 495 名前：デフォルトの名無しさん mailto:sage [2012/02/09(木) 12:38:45.86 ]
- 数倍になれば大成功だと思うが
５日かかってた解析が１日で終わる
５日かかってたレンダリングが１日で終わる
５日かかってた・・・
- 496 名前：デフォルトの名無しさん mailto:sage [2012/02/09(木) 13:14:57.71 ]
- 今時マルチコアが普通なんだし、並列化しないと1個しか使われなくてもったいないよ。
HD動画をリアルタイムに処理するとかだとぜんぜん違う。
- 497 名前：デフォルトの名無しさん mailto:sage [2012/02/09(木) 14:36:18.82 ]
- ちょっと関係ないが、映画のVFXは、一フレームの処理が
1時間程度以下が要求されるそうな。
フレームひたすら多いからね。
まああの世界はふつうのマルチコアPCでやってるとは思えんが。
- 498 名前：デフォルトの名無しさん mailto:sage [2012/02/09(木) 16:22:21.65 ]
- 画像処理というか数値計算みたいなものだけだと
ほとんどはコア数に線形に速くできるだろ。
最近は4コアか8コアだから4倍か8倍くらいにはできるものが多いのに
それをやっていないと、いくらいいアルゴリズムを使っていても
大損していると思うわ。
GPUはフィルタ処理なら数百倍は速くなるぞ。
複雑な処理は異常に書きにくい上にあまり速くできないが。
- 499 名前：デフォルトの名無しさん mailto:sage [2012/02/10(金) 12:43:32.45 ]
- GPU使ったり並列処理使ったり
linuxでもwinでもMacでもポータブルに実装する方法ってないですか？
Boost.threadは並列処理のポータブルなラッパー？
GPUでも同じ感じのあるといいのだけど
- 500 名前：デフォルトの名無しさん mailto:sage [2012/02/10(金) 13:04:52.64 ]
- OpenCLとか
- 501 名前：デフォルトの名無しさん mailto:sage [2012/02/10(金) 15:23:26.79 ]
- Javaの失敗を見て分かるとおり、そんなの不可能。
プログラマなら常識のはずだけど。
Write once, debug everywhere!!が鉄則。
- 502 名前：デフォルトの名無しさん mailto:sage [2012/02/10(金) 15:42:59.72 ]
- write once, debug you
- 503 名前：デフォルトの名無しさん mailto:sage [2012/02/11(土) 01:12:51.51 ]
- OpenCVのGPU使う方法ってポータブルなんだろうか
- 504 名前：デフォルトの名無しさん mailto:sage [2012/02/11(土) 13:38:10.70 ]
- >>503
CUDA Toolkit が使える環境なら、ポータブルかと。
opencv.willowgarage.com/wiki/OpenCV_GPU
opencv.willowgarage.com/wiki/OpenCV%20GPU%20FAQ
OpenCL はサポートしてない。DirectComputing もたぶんサポートしていない。
- 505 名前：デフォルトの名無しさん mailto:sage [2012/02/11(土) 17:16:38.72 ]
- 昔見限ったImageMagickを入れてみたが相変わらずXCFも作れないのな
PSD期待したがopacityなんかすぐ実装出来るだろうに
- 506 名前：デフォルトの名無しさん mailto:sage [2012/02/11(土) 19:53:21.65 ]
- 一度見限ったらもうそいつには期待しない
二度とチャンスは与えない
そうやって生きていきましょう
- 507 名前：デフォルトの名無しさん mailto:sage [2012/02/11(土) 20:32:18.66 ]
- XCFもPSDもライセンス絡みの問題があるだけだろ
- 508 名前：デフォルトの名無しさん mailto:sage [2012/02/11(土) 21:26:25.18 ]
- libpngで例外落ちする画像があって、Gimpでは読み込めるから問題ないんだろうけど
読み込む度に落ちるタイミングが違う
そこでpng_read_endをする直前にSleep(5000)といれてみたら
落ちずに待機して止まってる様子で５秒たつと例外が発生する
そしてこのSleepの直前にprintf("end\n")と入れてみたら５秒もせずに例外落ちする
なにこれ
- 509 名前：デフォルトの名無しさん mailto:sage [2012/02/11(土) 21:35:09.56 ]
- libpng のソースを落として問題の画像でデバッグしてみれば、
「なにこれ」の疑問が解消されるかも知れない
- 510 名前：508 mailto:sage [2012/02/12(日) 01:35:05.59 ]
- 最新版ダウンロードしてやったら出来た
- 511 名前：デフォルトの名無しさん mailto:sage [2012/02/13(月) 06:40:52.44 ]
- ポータブルでいうならOpenCLだろう
AMDとnVidia両方のGPUでいけるし、CPUもいける
- 512 名前：デフォルトの名無しさん mailto:sage [2012/02/13(月) 06:44:40.49 ]
- しかし、これからのお薦めはなんと言ってもDirectComputeだろうな。
- 513 名前：508 mailto:sage [2012/02/13(月) 06:51:50.42 ]
- プログラム側が対応するというよりはハード側が現行のプログラムを並列処理するようになる流れだと思う
その流れでしか普及しない
- 514 名前：デフォルトの名無しさん mailto:sage [2012/02/13(月) 07:14:26.83 ]
- DirectComputeって、HLSLを使わなきゃいけないし
Macで使えないからないな
- 515 名前：デフォルトの名無しさん mailto:sage [2012/02/13(月) 09:10:00.21 ]
- Macで使えないってどんだけメリットなんだよ。最強じゃん。
- 516 名前：デフォルトの名無しさん mailto:sage [2012/02/13(月) 10:48:49.63 ]
- いまのMacはソースコードからコンパできるでしょ
がまんなさい
- 517 名前：デフォルトの名無しさん mailto:sage [2012/02/13(月) 10:52:48.98 ]
- 今時はコンパって言うのかｗ
- 518 名前：デフォルトの名無しさん mailto:sage [2012/02/13(月) 10:57:34.38 ]
- コンパｗｗｗｗ
勉強させてもらったわ
- 519 名前：デフォルトの名無しさん mailto:sage [2012/02/13(月) 11:39:19.78 ]
- 結局、画像処理を並列化するには何使うのがいいんだ？
- 520 名前：デフォルトの名無しさん mailto:sage [2012/02/13(月) 12:01:32.06 ]
- 画像処理にも色々あるでしょ
得て増えてガール
- 521 名前：デフォルトの名無しさん mailto:sage [2012/02/13(月) 12:13:01.79 ]
- とりあえずはFPGA並べて試作だな
- 522 名前：デフォルトの名無しさん mailto:sage [2012/02/13(月) 13:50:26.65 ]
- 前の会社の時はFPGAで処理させて、
ってことをたくらんでたけど結局やらなかったなぁ…。
ハードの知識ないし、詳しい人たちはひたすら忙しかったし…。
- 523 名前：デフォルトの名無しさん mailto:sage [2012/02/13(月) 17:23:47.52 ]
- その手の謎の挙動はメモリ関係だな。
- 524 名前：デフォルトの名無しさん mailto:sage [2012/02/13(月) 17:24:06.03 ]
- うわ誤爆
- 525 名前：デフォルトの名無しさん mailto:sage [2012/02/13(月) 22:52:46.37 ]
- >>515
Macで使えない＝他の大抵のOSで使えない
だから、やっぱ採用しにくいわな。
- 526 名前：デフォルトの名無しさん mailto:sage [2012/02/13(月) 22:58:06.27 ]
- DirectComputeがそれに当てはまるわけだが。
しかし、OSの採用比率で言うと、圧倒的な割合なわけだ。
それを採用しにくいとかマカーのステマだろうな。
- 527 名前：デフォルトの名無しさん mailto:sage [2012/02/13(月) 23:01:54.67 ]
- 最近はスマホの影響でOpenGLとかもそれなりに流行ってるし、
Windowsだけやるのはお気楽だけど、あちこちでコードを使いまわす事考えたら、
ちょっと考えちゃう。
- 528 名前：デフォルトの名無しさん mailto:sage [2012/02/16(木) 00:59:58.59 ]
- OpenCLが一番汎用性高そうだね
OpenCVはCUDAぽいけど
- 529 名前：508 mailto:sage [2012/02/16(木) 01:15:21.62 ]
- OpenCLがマルチコアCPUでも動くなら普及するんだがな
- 530 名前：デフォルトの名無しさん mailto:sage [2012/02/16(木) 05:32:17.83 ]
- OpenMPとCUDAの複合
- 531 名前：デフォルトの名無しさん mailto:sage [2012/02/16(木) 07:46:03.36 ]
- OpenCLはCUDAほどパフォーマンスが出ないから
せっかくそこまでやるならCUDAってことになるのでは
- 532 名前：デフォルトの名無しさん mailto:sage [2012/02/17(金) 16:40:08.99 ]
- >>529
OpnCLはマルチコアCPUでも動く。しかもIntelでもAMDでもおｋ
- 533 名前：デフォルトの名無しさん mailto:sage [2012/02/28(火) 17:39:06.95 ]
- >>392
dag_vector: ランダムアクセス可能な圧縮配列
tp://research.preferred.jp/2011/06/dag_vector/
こんなのあるのね
- 534 名前：デフォルトの名無しさん mailto:sage [2012/03/03(土) 23:32:10.37 ]
- DTAMの論文読んだけど、なんだかよくわからん。
読んだ人いますか？
KinectFusionは分かった気にはなった。
- 535 名前：デフォルトの名無しさん mailto:sage [2012/03/04(日) 00:48:25.40 ]
- >>534
読んだには読んだけど、解説出来るかは箇所による
- 536 名前：デフォルトの名無しさん mailto:sage [2012/03/04(日) 01:49:08.58 ]
- ああいうのは論文通りに安定して動かないことがほとんどだから微妙だね
PTAMもすげー不安定だったし
- 537 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/01(日) 00:33:26.88 ]
- 画像処理について勉強中のものです。
質問があるのですが、
Harris-affine領域を抽出するのに
R=detM-k(traceM)^2=λ_1λ_2-k(λ_1+λ_2)^2
を求めてRの値が大きければコーナーと判定するのはいいのですが、そのあとの
求められた点に対して、周囲の画素の輝度勾配を計算し、注目画素を中心とす
る楕円領域を求める。
この箇所がよくわかりません。
具体的にどのようにして楕円領域を求めるのでしょうか？
- 538 名前：508 mailto:sage [2012/04/01(日) 09:48:18.11 ]
- Harris-affineって初めて聞いたし画像処理も素人だが
英語のwiki見て適当に答えるなら
楕円領域ってのは繰り返しパターン検出法だろ
ある点に注目した時の周囲の特徴点で算出された計算値が
隣接する点を中心にした場合と同じである場合は同じパターンの繰り返しということになって
その中間地点が境界領域ということになる
それをXYの両方向で特定すると楕円形になる
- 539 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/02(月) 01:09:12.02 ]
- >>538
ぜんぜん違う
>>537
とりあえず藤吉先生のSIFT解説文献読め
- 540 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/02(月) 06:03:24.11 ]
- >>539
アフィン変換不変の詳しい解説はないだろ
- 541 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/02(月) 06:13:19.08 ]
- >>539
藤吉先生の"一般物体認識のための局所特徴量（SIFTとHOG）"というのを読んでみましたが、
Harris-affine領域の記述はなかったのですが・・・
主曲率のところで固有値が出てくる似たような式がでてきましたが、
楕円領域の求め方はわからなかったです。
- 542 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/03(火) 01:25:55.01 ]
- 固有値の根の逆比が楕円領域の2軸でしょ
そもそもハリスとかDoGの特徴点検出がどうやってるかわかってんの？
- 543 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/04(水) 21:31:46.56 ]
- ハリスは
(Ix)^2 IxIy
[ ] Ix,Iyはx,y方向の1階微分
IyIx (Iy)^2
それぞれをガウス平滑化したものをMとすると
R=detM-k(traceM)^2=λ_1λ_2-k(λ_1+λ_2)^2
で求める
DoGは
異なるσ(kσ,k^2σ,...)の平滑化画像の差分をとった元をDoG画像とし、
DoG画像3枚1組で注目点のまわり26近傍をみて極値であれば特徴点候補とする(ダウンサンプリングし繰り返すのは省略)
こんな感じだと思うのですが、DOGは実装したことがあるのですが、
ハリスはしたことがないので固有値がどのような値をとるのかがよくわかりません。
固有値の根のといのはルートのことでしょうか？
たとえば固有値がλ1、λ2(λ1>λ2)とすると
長軸が1/√λ2、短軸が1/√λ1
となるということでしょうか？
また楕円の傾きはどのように求めるのでしょうか？
- 544 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/04(水) 23:45:44.68 ]
- 固有値に対応する固有ベクトルが軸の方向
- 545 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/05(木) 01:55:51.75 ]
- 固有値と楕円の関係は主軸変換とかでググれば分かると思う
ところで横からだけど
これって勾配を計算する範囲がアフィン変換に不変ではないと思うけど
楕円領域のほうが大きいから問題になりにくいということ？
- 546 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/06(金) 22:27:48.65 ]
- 楕円領域を実際にアフィン変換して円に正規化するんだよ
そんで勾配と特徴量計算する
- 547 名前：543 mailto:sage [2012/04/06(金) 22:57:17.57 ]
- ありがとうございました！
- 548 名前：508 mailto:sage [2012/04/06(金) 23:30:15.39 ]
- 一番正確な領域分割アルゴリズムって何？
- 549 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/07(土) 01:48:36.39 ]
- >>546
楕円用の固有値と固有ベクトルを求めるための行列を計算する範囲のことだよ
楕円領域を計算する前だからその範囲はアフィン変換に強いわけではないでしょうと
- 550 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/07(土) 11:49:27.88 ]
- そういうことか。確かにそれはかなり影響ある。
実際Harris-Affineの検出力は他と比べてかなり低いよ。
- 551 名前：デフォルトの名無しさん [2012/04/12(木) 21:25:52.13 ]
- 画像関連、全くの初心者なのですが質問させてください。
たまにテレビで、背景（壁）が真っ赤や真っ青にしてある画像処理用のスタジオが写ってますが、
あれで映像の背景部分と人間部分をデジタル的に分けてるんでしょうか？
その様な技術を一般的になんていうんですが？
似たようなことをして物体の形状をカメラで調べられるのを作りたいと思ってます。
最終的には背景（壁）の適した表面処理等も調べてみたいです。
先輩方、よろしくお願いいたします。m(_ _)m
- 552 名前：デフォルトの名無しさん mailto:sage [2012/04/12(木) 21:58:40.27 ]
- クロマキー
- 553 名前：デフォルトの名無しさん [2012/04/12(木) 22:51:32.55 ]
- >>552
ありがとうございます。m(_ _)m
「クロマキー」というんですね。色々と調べてみます。
小学生の時に聞き覚えがあります。それはクロマティか。
背景にはクロマティ用の「布」を使うようですね。
私の場合、工場の生産ラインで長期間使いたいので、「布」は保守性に難かな。
クロマティ用の塗料が販売してるみたいなので問い合わせてみます。
あと被写体の色が様々で、青い背景だと、青い被写体を識別するのは難しいですよね。
背景に設置する板を、対象物に応じて取り換えるしかないのかな。
複数の異なる色のLEDで、対象物に応じて手動で発光する色を切り替えることも考えられますが、コストの面で難が出るだろうな。
何か良い方法思い浮かぶ方がいましたら、何でも書いてくれると嬉しいです。m(_ _)m
- 554 名前：デフォルトの名無しさん mailto:sage [2012/04/12(木) 23:17:06.65 ]
- 背景だけを撮った映像（Ａ）と人物＋背景を撮った映像（Ｂ）を作り、
ＢからＡを減算して人物や屋台だけを抽出して、別の背景と合成する
というのを高校の文化祭でやった
３階の教室から模擬店で賑わっている庭をビデオカメラで撮って、
人物と屋台を宇宙空間や水中の映像と合成した
映像Ａは前日に同じ場所から同じ角度で撮っておいた静止画一枚だけ
所詮は高校生がやることなんでとても拙く、
壁や地面に落ちた影もいっしょに抽出されてしまってたし、
切り抜き自体も綺麗にはいかなかったが、それはそれで面白かった
- 555 名前：デフォルトの名無しさん [2012/04/12(木) 23:25:42.99 ]
- >>554
なるほど楽しそうですね。
クロマティを教えてもらった私ですが、その方法も考えてみます。
それでうまくいけば、背景に特別なものを用意する必要がないですね。
背景で、機械が動いていたり、人が横切ったり、人の影が変わったりと色々難が出そうですが、それも試してみます。
- 556 名前：デフォルトの名無しさん mailto:sage [2012/04/12(木) 23:52:00.48 ]
- LEDのパネルがクロマキーに優れてると思うよ。と書こうとしたら既に検討してたか。
光の屈折やレンズ内の反射で物体が小さく映ると思うから1画素程度膨張させるのいいね。
あと、エッジを見るようにすると色は気にしなくてもなんとかなる
- 557 名前：デフォルトの名無しさん [2012/04/13(金) 08:03:35.38 ]
- >>556
おはようございます。
ありがとうございます。LEDパネルを購入してみます。
実験レベルでは、安価な白色のLEDパネルに、フィルム？を貼ればいいでしょうか。
なるほど、強い光がしみだしてくるんですね。確認してみます。
＞あと、エッジを見るようにすると色は気にしなくてもなんとかなる
これは、色判定と同時に、エッジ検出も同時うということでしょうか。
- 558 名前：デフォルトの名無しさん mailto:sage [2012/04/13(金) 15:50:50.49 ]
- HALCONのスレが無いので、本スレで質問致します。
sobel_amp(), edges_image()等で抽出したエッジから領域を
生成する方法で悩んでます。
sobel_amp(), edges_image()で得たエッジのみ白く
その他は真っ黒な画像をthreshold(),hysteresis_threshold()しても
エッジで囲まれた面を抽出できません。
大変、恐縮ですが何か、コツなどを教えて頂けないでしょうか。
宜しく御願い致します。
- 559 名前：デフォルトの名無しさん mailto:sage [2012/04/14(土) 19:42:10.43 ]
- >>558
サポートに聞けよw
- 560 名前：デフォルトの名無しさん mailto:sage [2012/04/14(土) 22:56:19.17 ]
- >>557
エッジというのは554の言ってることをやる手段のことね。
背景画像と今の画像を引き算して移動物体を見つける。この引き算の仕方にも流行りがあって最近はエッジ画像でやるのが流行りなんだよ。
背景画像を使う事が廃れてきてはいるけどね。
- 561 名前：デフォルトの名無しさん mailto:sage [2012/04/15(日) 18:15:56.51 ]
- 面白いと思ってわざと間違えを引っ張ってるんだろうが
つまんねえからそのクロマティっての
死ね
- 562 名前：デフォルトの名無しさん mailto:sage [2012/04/15(日) 18:45:34.11 ]
- 些末なところに突っ込むなよ
どうでも良いだろ
|
 |
