トップページ⇒tech
981コメント308KB

画像処理 その12

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2009/07/09(木) 09:52:04
画像処理プログラミングについて質問、議論を行うスレッドです
・画像処理について素人同士で大激論
・初学者の質問に対してやさしく(的を外れた)解答を与える
・その道の玄人も大歓迎

前スレ
画像処理 その11
http://pc12.2ch.net/test/read.cgi/tech/1222593978/
0052デフォルトの名無しさん2009/07/11(土) 03:49:44
なぜ極狭い一面を見ただけで一般化しようとするかな。
0053デフォルトの名無しさん2009/07/11(土) 04:07:30
>>51
GPUには期待してますけど、今までのCPUとはまた違うパラダイムでしょうね。
上の議題は、GPUではなくCPUでの画像処理（所詮２D）での話ですけど。

GPUは、ifによる分岐じゃなくストリームのパラダイムなので、２D処理（つまり従来からの画像処理・探索）は向いてないと思いますよ。
CPUは４Gぐらいが限界と分かったので、これ以上はいくらハード・アルゴをチューニングして頑張ってももはや速くはならないでしょうし、0xffff * 0xffffの画像とかデジカメならすぐ到達するんで、２Dのアルゴも違う発想が必要になるでしょう。
0054デフォルトの名無しさん2009/07/11(土) 04:09:37
ここ何人いるの？
0055デフォルトの名無しさん2009/07/11(土) 04:14:48
多分日本人
0056デフォルトの名無しさん2009/07/11(土) 04:59:20
車輪の再発明の話は散々出るけど、ならなんで新しい言語が次から次へと登場するのかね。
しかも似たりよったりの言語が。あれは車輪の再発明とは呼ばないのだろうか。

ライブラリの話を見ていて、なんだかそんな気分になった。
0057デフォルトの名無しさん2009/07/11(土) 06:51:49
言語は、言語開発者がそれを作る目的によって違うので、いくつもの似たような言語があっても目指すものが違うんですよ。
コンパイラとか作ったこと無いと分からないんでしょうけど。
似たように感じるのは、文法が似てるからだとは思いますが、ハスケルみたく奇抜な文法だと多分あんたじゃ習得できないでしょう。

分かりやすいところでは、Cでは2D,GUI向けの言語ではないので、「ウインドウを作ってボタンを押してハローワールド」
これだけのことをやるのに、win32だと５０行ぐらいは必要でしょう。
それ用のランタイムライブラリや言語だと２−３行でしょうけど、この違いは文法（リテラル）の差ですよ。
この言語上の文法が内部で車輪（よりネイティブに近い実装ライブラリ）を呼び出してるんですけど、これを再発明する必要はないでしょう。

変色フィルターとかアフィン変換とか通常の画像処理はjava,c#でライブラリとしてほとんどあるんで、勉強目的以外なら普通は自分で改めて書いたりませんけどね。
何とかの分離とも言いますが、とくにかくCのコードはIOだけにしてそのハード用の使い捨てにして、画像処理のアルゴリズムなら、javaとかvmのプラットフォームを中心にすえてコードを書くといいですよ。
後２−３年で携帯とか他のOSでもそのアルゴが何の変更も無く普通に使える（再利用できる）ようになるでしょうし。
0058デフォルトの名無しさん2009/07/11(土) 06:59:07
>>57
＞作る目的によって違うので、いくつもの似たような言語があっても目指すものが違う
ライブラリもそうじゃないのかｗ
0059デフォルトの名無しさん2009/07/11(土) 07:37:25
またなんか凄いのが沸いてるな。
OOPって単語覚えて嬉しいのはわかるけど、
画像処理技術と設計技術はなんの関係もないので、よそで喚いてくださいね。
0060デフォルトの名無しさん2009/07/11(土) 07:49:23
ARMは固定小数点の方が速いんだよな。
0061デフォルトの名無しさん2009/07/11(土) 08:56:00
携帯で「高速な画像処理が出来る」とか期待しないけどね。普通の人は。
0062デフォルトの名無しさん2009/07/11(土) 08:57:50
>>59
画像処理技術とかたいそうな漢字を並べてみても、君なんか所詮未熟者でしょ？ｗ
0063デフォルトの名無しさん2009/07/11(土) 09:04:00
>>58
そのライブラリとか、自作の処理を関数化したりを突き詰めると結局「それ用の言語を作ったほうがいい（つまり文法とリテラル）」ってなるんですよ。
例えばマテマテカとかRとか使ったこと無いでしょ。君みたいな貧乏低学歴じゃ。

多少難しいこと買いても、このスレでは無能ばかりだしついてこれようなるまじめな人もいないみたいなので、これぐらいで勘弁してあげましょうかね。ｗ
0064デフォルトの名無しさん2009/07/11(土) 09:08:57
>>59
OOPが未だに理解できないのも分かるんですけど…
そんな万年石頭のオジサンに、返して差し上げる言葉ありませんよ。
0065デフォルトの名無しさん2009/07/11(土) 09:40:12
きちがいうぜー
0066デフォルトの名無しさん2009/07/11(土) 10:52:58
トリップ入れろ
てかactionscriptでいいんじゃない？
0067デフォルトの名無しさん2009/07/11(土) 11:04:58
要するに、画像処理専用の言語があればいいんだな。
そういうのはあるよ。たぶん、JavaとかC#には乗らないけど。
0068デフォルトの名無しさん2009/07/11(土) 11:12:31
画像処理にOOPが必要かどうかの議論は
http://pc12.2ch.net/test/read.cgi/tech/1243827025
でやった方がいいと思う。
0069デフォルトの名無しさん2009/07/12(日) 03:16:55
>>66
痛いな
0070デフォルトの名無しさん2009/07/12(日) 03:17:59
スレタイとスレ番に期待して覗いてみたら…　半年後にまた来ます。
0071デフォルトの名無しさん2009/07/13(月) 04:33:40
正しいと思うなら自分で作って証明すればいいだけだし
みながそうしてきた結果が今の状態だろ
0072デフォルトの名無しさん2009/07/13(月) 13:11:26
イミフ
0073デフォルトの名無しさん2009/07/13(月) 14:36:01
頭の悪い高校生（だよね？）のために現状を解説すると、
アルゴリズムの検証や研究などには Matlab などの簡便で高級な環境を使う。
実用品の実装には C 等の高速な言語を使う。
ので、記述力がない上に遅い Java や C# を使う必要があるケースは少ない。

個人的には Matlab 使えないけど手軽に検証したいときには C# は便利だと思うけど、
そういう状況があるのって非専門家だけだからなあ。
0074デフォルトの名無しさん2009/07/13(月) 14:49:34
マットラボ乙
0075デフォルトの名無しさん2009/07/13(月) 21:36:53
>>73
画像処理は何使ってやってんの？
0076デフォルトの名無しさん2009/07/13(月) 23:47:39
別に10Bitの浮動小数点数が使えるから
喜んでPascal使ってる俺みたいのがいてもいいじゃんか
0077デフォルトの名無しさん2009/07/13(月) 23:49:04
Byteだったお
0078デフォルトの名無しさん2009/07/14(火) 01:09:37
1024ﾊｱﾊｱ
0079デフォルトの名無しさん2009/07/14(火) 12:45:00
fp10って奴だろ
RGBを10bitずつで、あと2bitをαとか
0080デフォルトの名無しさん2009/07/14(火) 19:05:21
Matlabって画像処理に使いやすいかぁ？
0081デフォルトの名無しさん2009/07/14(火) 19:08:32
頭の悪い高校生なんだから相手しちゃダメ
0082デフォルトの名無しさん2009/07/15(水) 09:37:36
去年matlabからC++への移植＋高速化の仕事があった。
matlab100行がC++で3000行、速度は4〜6桁高速化。
0083デフォルトの名無しさん2009/07/15(水) 10:20:23
それは高速化したんじゃなくて、もともとマトラボのそのコードが糞遅かったんだろｗ
0084デフォルトの名無しさん2009/07/15(水) 11:35:27
4〜6桁って、1万倍から100万倍ってこと？
0085デフォルトの名無しさん2009/07/15(水) 11:50:24
高速化してくれって言う案件を受けるってのが凄いな。
いくらなんでもそんな要求はキリ無いだろ。
もし最適化してプロトタイプ実装しても、その仕様を満たさないならいくら準備料を積んでもらっても無駄骨だしな。
おまえのところは、明日の飯を食うのも困るほどの零細なハウスなんだろう
0086デフォルトの名無しさん2009/07/15(水) 12:10:25
>>83
確かに組み込み関数を並べているだけの芸の無いコードだった。
コアのコードなんて10行くらいｗ。

高速化の内容は
　処理時間の大部分はconv2(fft + ifft)の膨大な繰り返し
　conv2の繰り返し処理に対応する部分を2〜3桁高速化
　今度はmaxに対応する処理が時間の大部分を占めるようになったので、そこを2〜3桁高速化

>>84
1000倍から100,000倍(画素数による)

>>85
あなたはエスパーですか？
他社がさじを投げた案件ばかり回ってくる零細ソフトハウスです。
0087デフォルトの名無しさん2009/07/15(水) 12:25:30
そんなの受けて無駄な時間を使うな。
もし受けざるえないなら料金を吊り上げろ。
お前みたいな低脳低学歴が下らないおせっかいをするからソフト業界の案件受諾価格が下がるだろが。
もしこういうのがやなら、お前のところはフリーソフトでも作ってろカス
0088デフォルトの名無しさん2009/07/15(水) 12:31:25
なんなんだこいつは
0089デフォルトの名無しさん2009/07/15(水) 12:45:50
87はプロダクト・マネージャーの精霊です
0090デフォルトの名無しさん2009/07/15(水) 13:54:59
特化したソフトを作る会社があってもいいじゃないか
0091デフォルトの名無しさん2009/07/15(水) 14:01:22
>>88
それで高速化さん、マットラボと画像処理はどう関係あるの？
0092デフォルトの名無しさん2009/07/15(水) 15:25:07
ttp://www1.axfc.net/uploader/He/so/234773

VC++2008 を使用しています。

PNG 画像を扱う時に _aligned_malloc でメモリ確保する方法を使ってみた所、
sample1.png の画像は読み書きに成功したのですが、sample2.png の画像は
「libpng error: Too many IDAT's found」と出てうまくいきませんでした。

何かやり方が悪いのでしょうか、どなたかご教授下さい。
0093デフォルトの名無しさん2009/07/15(水) 16:36:50
OpenCV使え。デフォルトでPNG読み込める。
0094デフォルトの名無しさん2009/07/15(水) 16:43:43
この画像で何がしたいんだ?
0095デフォルトの名無しさん2009/07/15(水) 17:57:44
>>93
LIBPNGを使う前提でやっていますので…。

>>94
この画像でという訳ではなく、
読み込みに失敗する場合があるという点が問題なのです。
0096デフォルトの名無しさん2009/07/15(水) 18:47:50
sample2.pngの中身が分からんと解決しようがない
0097デフォルトの名無しさん2009/07/15(水) 19:16:53
画像でないが、とあるツールのログ解析するソフト、チョロッと作ったら、10H が20secに短縮したな。

SED等の組み合わせでやっているのを、rubyで字句解析入れてやった。ｗ
0098デフォルトの名無しさん2009/07/15(水) 19:34:40
さっきから画像関係ないよな…
変なのがいついちゃったな
0099デフォルトの名無しさん2009/07/15(水) 20:58:18
>>96
えっと、中身とはどういう事でしょう？
0100デフォルトの名無しさん2009/07/15(水) 21:05:06
>>99
スレ違いだっつーの
さっさと失せろクズ
0101デフォルトの名無しさん2009/07/16(木) 07:15:27
LIBPNGを使った画像の読み書きは、
このスレではスレ違いなのですか？
どちらのスレでなら大丈夫なのでしょう？
0102デフォルトの名無しさん2009/07/16(木) 07:19:13
環境依存OKのC/C++スレか、スレ立てるまでもないC/C++スレ辺りじゃね?
0103デフォルトの名無しさん2009/07/16(木) 08:09:32
なるほどです。
教えて下さりありがとうございました。
0104デフォルトの名無しさん2009/07/16(木) 14:41:00
>>101
失敗した場合のエラーコードくらいみたら
0105デフォルトの名無しさん2009/07/19(日) 13:00:45
>>17
超高速プロセッサと超高性能コンパイラがあれば「僕の考えた最強の開発環境」が実現できるよね
0106デフォルトの名無しさん2009/07/19(日) 13:05:17
>>48
画像処理にはＯＯＰの方が向いているというのには納得するけど、Ｊａｖａは糞言語だからC#にするべき。
0107デフォルトの名無しさん2009/07/19(日) 13:07:46
>>82
matlab使いは例外なくクズ
0108デフォルトの名無しさん2009/07/19(日) 14:36:04
画像処理？
使う言語はverilogとFPGAに決まってるだろ？
0109デフォルトの名無しさん2009/07/19(日) 17:42:59
どのように使っていますか
0110デフォルトの名無しさん2009/07/20(月) 00:15:58
うわー堕ちたなーこのスレ
0111デフォルトの名無しさん2009/07/20(月) 00:20:54
きちがいうぜー

正しいと思うなら自分で作って証明すればいいだけだし
みながそうしてきた結果が今の状態だろ

スレタイとスレ番に期待して覗いてみたら…　半年後にまた来ます。
0112デフォルトの名無しさん2009/07/20(月) 09:55:26
>>110
ならいつまでもROMってないでこのスレに貢献したらどうだ？
なんの能力ないなら黙ってろよ
0113デフォルトの名無しさん2009/07/20(月) 12:10:00
無能な奴はこのスレに居て欲しくないよな…
0114デフォルトの名無しさん2009/07/20(月) 12:20:19
君は有能なのかい？
0115デフォルトの名無しさん2009/07/20(月) 12:46:15
matlabを使う画像処理ってどうやるんですか？
0116デフォルトの名無しさん2009/07/20(月) 20:59:46
>>115
matlabスレで聞けば？自分はmatlab使った事ないけど複数の知り合いはガリガリ使ってるから可能である事は確か。
0117デフォルトの名無しさん2009/07/20(月) 21:13:07
fft
0118デフォルトの名無しさん2009/07/21(火) 10:21:24
>>113
まず君が去らなきゃな
0119デフォルトの名無しさん2009/07/24(金) 16:16:14
αチャンネルを持つ画像同士の、
αブレンドの方法を教えてもらえないでしょうか。
0120デフォルトの名無しさん2009/07/24(金) 16:29:05
すみません、言葉が足りませんでした。
↑の式を教えて貰えませんでしょうか。
0121デフォルトの名無しさん2009/07/24(金) 16:33:39
まだ足りない
0122デフォルトの名無しさん2009/07/24(金) 16:43:47
α×画素値A＋（1−α）×画素値B
0123デフォルトの名無しさん2009/07/24(金) 16:57:06
すみません、画像Aのαと画像Bのαを使ってください。
01241222009/07/24(金) 17:51:04
α_A/(α_A＋α_B)×画素値A＋α_B/(α_A＋α_B)×画素値B
01251222009/07/24(金) 17:53:36
α_A/(α_A＋α_B)×画素値A×α_A＋α_B/(α_A＋α_B)×画素値B×α_B
01261222009/07/24(金) 17:55:27
すなわち
(α_A^2×画素値A＋α_B^2×画素値B)/(α_A＋α_B)
0127デフォルトの名無しさん2009/07/24(金) 18:40:10
Acos^2(α)+Bsin^2(α)
0128デフォルトの名無しさん2009/07/24(金) 19:11:51
上の式は量子化で分かるのですが、
α_A/(α_A＋α_B)×画素値A×α_A
でα_Aが２回出るのはどういう意味なんですか？
0129デフォルトの名無しさん2009/07/24(金) 19:13:28
f(x)＝f(a)*(ｘ−ａ)^0/０!＋f'(a)*(x-a)^1/１!＋f"(a)*(x-a)^2/２!＋・・＋f^n(a)*(x-a)^n/ｎ!＋・・
01301222009/07/24(金) 19:15:12
そういえばもともとα値で薄くなってるな〜とおもってα_Aをもう一回かけてみた。
0131デフォルトの名無しさん2009/07/24(金) 20:02:40
>>129
数値微分は精度悪い（半分の桁しかない）ですよね…
なにか上手い方法ないでしょうか？
0132デフォルトの名無しさん2009/07/24(金) 20:06:48
>>130
それが計算式の根拠なんです。なら
α_A^2がcos^2(α)
となるのは無理（不可能）がありますけど。
0133デフォルトの名無しさん2009/07/25(土) 00:04:43
色のスペクトル（横長）は出来たのですが、
こんどは色相環（円形）を描画したいのですがどのような方法になるんでしょうか？
やっぱりsin,cosなど角度を使って描画するのが簡単なのでしょうか。
0134デフォルトの名無しさん2009/07/25(土) 00:06:13
うん
0135デフォルトの名無しさん2009/07/25(土) 00:36:47
そうなんですか。ベクトルに詳しい人がいるみたいなので期待してたんですけどsin,cos使ってやります。
0136デフォルトの名無しさん2009/07/25(土) 01:00:05
sin,cosとベクトルを切り離して考える方がおかしい
0137デフォルトの名無しさん2009/07/25(土) 01:13:12
ベクトルのことをろくに知らないくせによく言うよカス
0138デフォルトの名無しさん2009/07/25(土) 01:28:00
ベクトル（回転行列とか？）使ってやるよりSin,Cosの方が直観的だし簡単だろう。
0139デフォルトの名無しさん2009/07/25(土) 01:33:23
このスレもレベル下がったな
糞スレ決定だろ
0140デフォルトの名無しさん2009/07/25(土) 01:36:21
前からだけどな
専門家はどこにもいない
0141デフォルトの名無しさん2009/07/25(土) 02:04:22
回転行列も中身は結局三角関数だよな
0142デフォルトの名無しさん2009/07/25(土) 02:15:42
sin,cosが問題じゃなくて角度θ使ったほうが簡単なんですか？
回転とか行列とかじゃなくて、int,floatとかそういう数学の基礎的なところなんですけど・・・
float使うとなるとアルゴリズムが大分違うんですよね。
0143デフォルトの名無しさん2009/07/25(土) 06:10:54
それはベクトルじゃなくて
DDTのことを言っておるのか？
0144デフォルトの名無しさん2009/07/25(土) 07:16:58
DDTってなんじゃ？
0145デフォルトの名無しさん2009/07/25(土) 07:29:39
マクローリン展開して……
0146デフォルトの名無しさん2009/07/25(土) 08:03:08
マクローリン展開？？
0147デフォルトの名無しさん2009/07/25(土) 11:14:34
いくらなんでも池沼過ぎるだろオイ
0148デフォルトの名無しさん2009/07/25(土) 11:35:18
>>145
それならpoly展開だと何項ぐらいにしますか？
8ビット機ならともかく、cpu 33MHz(33)ぐらいあれば角度もintにするのははちょっと複雑ですけどね・…
0149デフォルトの名無しさん2009/07/25(土) 12:10:19
一応手順としては、色スペクトル（横長）を作ってこれをaffineとかでリング（円形状）に仕様と考えてるんです。
だいたい一円の解像度も40-60分割ぐらいなのでθを使わず、やっぱり（数学的に単純考えると）affineがいちばん簡単だと思いますが、画像処理の手法として他に伝統的な方法はあるんでしょうか？という質問です。
0150デフォルトの名無しさん2009/07/25(土) 13:18:46
つまりはバイナリで読み出して、数値を変換してバイナリで書き出すと思えばおｋ？
0151デフォルトの名無しさん2009/07/25(土) 15:06:20
これだけヒントを出しえもやっぱり答えられる御人は居ませんね。
数学（幾何）的にやれは何でもできるんですけど、画像処理すれなので画像の特性に特化した画像処理手法があると期待してたんですが・・・
現代のPCならdoubleでもぜんぜん処理が遅くないので（ほぼリアルタイム）、この様子だと数学公式とハードでごり押しになっていき画像処理の小手先技はすたれていくんでしょうね。
■ このスレッドは過去ログ倉庫に格納されています