画像処理 その12

1 名前：デフォルトの名無しさん [2009/07/09(木) 09:52:04 ] 画像処理プログラミングについて質問、議論を行うスレッドです ・画像処理について素人同士で大激論 ・初学者の質問に対してやさしく(的を外れた)解答を与える ・その道の玄人も大歓迎 前スレ 画像処理 その11 pc12.2ch.net/test/read.cgi/tech/1222593978/ 2 名前：デフォルトの名無しさん mailto:sage [2009/07/09(木) 10:22:05 ] 2 gotten 3 名前：デフォルトの名無しさん mailto:sage [2009/07/09(木) 18:26:57 ] ポニーテール 4 名前：デフォルトの名無しさん mailto:sage [2009/07/09(木) 22:50:56 ] アイスラッガー 5 名前：デフォルトの名無しさん mailto:sage [2009/07/09(木) 23:30:21 ] ズレてるだけ 6 名前：デフォルトの名無しさん [2009/07/10(金) 13:38:25 ] かぞえてくれ ttp://www.yomiuri.co.jp/zoom/20090708-OYT9I01080.htm 7 名前：デフォルトの名無しさん [2009/07/10(金) 17:30:00 ] 画像処理って、C言語オンリーでもできるの？ っていうか、ライブラリ関数の中身が知りたいんだけど・・・ 8 名前：デフォルトの名無しさん [2009/07/10(金) 19:00:54 ] OpenCVつかいますか？ 中身も自作？ 9 名前：デフォルトの名無しさん mailto:sage [2009/07/10(金) 19:59:47 ] むしろC言語でライブラリと組み合わせてやるのが主流。 10 名前：デフォルトの名無しさん mailto:sage [2009/07/10(金) 23:27:41 ] >>7 C言語で出来ないんなら、ライブラリはどうやって作ってるんだ？ 11 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 00:45:57 ] pythonで使ってみた うちのpythonは2.5だったのに OpenCV1.1pre1aを入れたらpython2.6用で使えずorz OpenCV1.0を入れ直してうまくいったので快適 12 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 00:46:58 ] 誤爆したorz 13 名前：デフォルトの名無しさん [2009/07/11(土) 01:28:13 ] >>10 C言語の学習っていったら、だいたいライブラリ関数の使い方だからさ どうやったらいいのか不思議でたまらないんだ 14 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 01:40:29 ] www.amazon.co.jp/dp/479800958X 15 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 01:41:02 ] >>13 画像処理系の教科書読めば書いてあるだろ。 16 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 01:44:45 ] >>13 ライブラリ使ってると内部で何やってるのか不明で気持ち悪いのはわかる。 暇な時にBMPファイルの構造やC言語での読み込み方について調べてみるといい。 OpenCVにしろ何にしろ、ライブラリはその読み込み手順とかを関数化しただけだから。 17 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 02:00:10 ] 最近思うんだけど、画像というのはメモリに展開される「データ」であって、ハード（OSとかのネイティブシステム）に依存しないでしょ。 簡単にいえば、bmp,jpgとかは別にmsとかmacじゃなくてもx windowでも開けるし編集も出来る。 だからネイティブに依存しまくってるCでライブラリを作る必要ってあまりないじゃないの？ 画像解析とか１ピクセルごとの処理が必要でハード資源が必要だから、携帯とか組み込みとかでは やらないからCコンパイラ対応である必要もない。 つまりjavaとかc#とかで画像処理ライブラリ自体を仮想化すればいいんじゃないかな。 アルゴリズムの方をvmのコードで作って、各ハード（GPUとかカメラICとか）のIOの方は今までどおりCにして住み分ければいい。 そうすると、GPUのストリームプロセッサで処理されるかどうかを気にしなくてアルゴリズムに集中できるようになる。 18 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 02:03:01 ] 意味不明 19 名前：デフォルトの名無しさん [2009/07/11(土) 02:09:16 ] Java厨なのはよくわかった 20 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 02:16:13 ] >>17 JavaとかC#で実用的な速度出せるようになればいいね。 21 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 02:19:42 ] アルゴリズムの方は、せっかく発明したから隠しておきたいって言うのもわかる。 だけど、結局同じような機能は別の方法で再発見できるわけで、それが多少高速か、アルゴリズムが分かりやすいかの差でしかない。 同じソートアルゴリズムでもクイックソートが必ずしも万能でなはなく、見方によってはマージソートの方が扱いやすいとか。 ２Dでは、輪郭を抽出するとかあるけど、結局誰もが同じようなアルゴになるわけで、多少早いか実装しやすいかとかいわゆる「経験と勘」の差でしかない。 この車輪の再発明で、お互い利益競争（各社高額な画像ソフト）して、足踏み（クローズド）するよりは、それを（賛同者は）公開して共有して、 そのアルゴをブラックボックス化（ライブラリ・モジュール化）して次のステップのアルゴを考えたほうがよっぽど（その分野は）存続していけるとおもうよ。 ただ、輪郭抽出アルゴをあたりまえとして次の話題に進むからより専門化していくのは確かだけど、 若い技術者が、すでに完成している分野のアルゴで立ち止まる必要はなくなり、若い「知」のリソースを有効活用して次のアルゴが生まれるようになると思う。 有効ではあるけど、ピクセルごとにforとifでまわすだけとか、forのなかにifばっかりとかはいいかげん卒業して、ブラックボックスとして自作ライブラリにして、より高度な機械的な処理を目指して欲しい。 ifばかり使うと収拾がつかなくなりそのうち分岐が多すぎて管理できなくなるから、それは高度な処理はとはいえず、for + if だらけのコードは使い捨てコードに等しいよ。 22 名前：デフォルトの名無しさん [2009/07/11(土) 02:31:50 ] なんだライブラリが欲しいだけか これだからC♯厨は 23 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 02:35:10 ] >>20 ３Dの解析じゃないなら、クライアントPCは1G...1.4G程度で十分では？ 600MHzでも十分だと思いますけど。 そのかわりメモリはキャッシュとして使うので、画像アプリ用で多量（３００MB)とか必要ですけど。 3Dの方は今のPCリソースでも、何をやりたいのかはっきりしないし３Dの画像解析の定義とか意味付けがはっきりしないのでどれだけリソースが必要で、どれだけの速度で応答する必要があるのとか未知数ですけど。 １０年前は800...1GぐらいのCPUだったんですけど、その当時の画像処理ソフトは従来の変色フィルターとか歪みフィルターとかで、その当時からあまり高機能に進化してませんよね。 結局「実用的な速度」という概念自体が、理想なものでしかなく、「実用的な速度」という測定できないような空想の速さを追い求める「あなたの理想」だったのでは？F1とかの走り屋の心境と同じなんでしょうか・・・ ある程度満足がいく画像処理アルゴを、より「理想的は速さ」を求めるためにチューニングするよりも、最新のハード（や専用プロセッサ・ハードエンコード）で処理したほうが、よっぽどリアル世界での「実用的な速度」だと思いますが。 24 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 02:38:03 ] 妙な略語を使うのは初心者の特徴だな。 25 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 02:43:03 ] >>23 そもそも、最新のハードをJavaやC#で制御できるの？っていう話が。 Cでさえ遅いってことで CUDAやOpenCLのような並列処理をサポートした処理系を持ち出してるのに。 26 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 02:43:55 ] 画像処理物を自分で実装することはあまり無いし、JNIとか使いこなせるんで別にCで実装してあってもいいんですけど… JAVAとかC#でOOPやってる、どうも原始的なんですよね。CとかGTKとかのフレームワークが。 たぶん、JAVAとかJAVASCRIPTとか現代的な言語を身につけると、言ってる意味が分かるようになりますよ。 ある意味アルゴリズムの実装方法（for + if)自体が変わる( img.filter(*func) )ぐらいのパラダイム変化があるでしょうし。 27 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 02:47:11 ] 画像処理を実装しないのに、なんでこのスレにいるの？ 28 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 02:53:20 ] 言語なんて関係なく、とにかく自分で実装するのが嫌だから、ライブラリ作ってくれって言ってるだけじゃん。 29 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 02:53:31 ] >>25 その最新のハードは上にも書いてありますが、IO（データ、ストリームの入力と出力部分）なので当然Cで実装します。 双じゃなくて、画像処理のための仕組みは、最新ハードに依存しないソフト物（メモリ上でしかない）ので、javaとかで十分です。 関数呼び出しコストとか２０年以上前のしがらみにこだわってる人だと、ある種の宗教なので話は通じないでしょうけど（足踏みしてる人なんでしょう）。 メモリ上で処理ですけど、GPUの場合はGPUのVRAM内なのでCしかないんでしょうけど、まだ最新技術（ハード）でいくつか仕様がありかつデファクトにもなってないから、 上の処理ライブラリの仮想マシン言語での実装はCPUとPCでの話ですけど。 GPUのGPU内のメモリ（VRAM)にアクセスする手段が確立したら、結局同じ議論になると思いますよ。 30 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 02:57:58 ] >>29 JavaとかC#で実用的な速度出せるようになればいいね。 31 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 02:58:32 ] >>27-28 とはいうけど、OOPで作られている現代的フレームワークとか使ったことありますか？ そういう大規模なアプリとか作ったことないでしょ。 自分で実装するのが嫌とか面倒とかじゃなくて、車輪の再発明とは何か、なぜよろしくないのか、もう一度車輪の発明とコードの再利用（旧来はモジュール化とも称していたけど）とはどういうことなのかを勉強したほうがいいと思うよ。 32 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 03:02:26 ] なんだ ただの低レベルな勘違い君だったか 33 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 03:06:10 ] 仮想マシンとネイティブとの関数呼び出しコストがあるかもしれないけど、 1.4G以降のPC（ネットブックとかも）ならもう測定不能誤差って範囲で、関数呼び出しコストは発生せずってところだと思うよ。 400MHzのPC（パームとかスマートホンレベル）だと仮想マシンにあるライブラリを呼び出すのは、呼び出しコストは少しあるかもしれないけど、 そもそもそんな非力なリソースしかないのに高度な画像処理をすることは向いてない。つまり変色フィルターと３Dとかのゆがみ、アフィン変換程度で十分。 画像処理の方法（アルゴ）を考えるよりも、まずこういうリアルの感覚が大事。 34 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 03:08:30 ] なんで関数呼び出しとかの話になってるんだよw 35 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 03:08:40 ] やあアルゴ君 久しぶりだね 36 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 03:09:56 ] つまり関数呼び出しがボトルネックになると思いこんでたのか 37 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 03:09:58 ] どうでもいいが、以上によってIOに関係しない画像処理（フィルターとか次世代の検索・動き検知・補正技術）を書くなら、Javaを見据えてJava用のライブラリを書いてくれ。 そのライブラリをCから呼び出す方式（JNIとか）にしてね。 38 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 03:12:07 ] 自分で書けゴミ 39 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 03:14:59 ] >>31 何を主張したいのか分からん。 言語に関わらず、誰かが実装したものがあればそれ使えばいいんじゃないの？ (タダなのか有償なのかはライセンス次第だろうけど) 誰も実装してなかったら、もしくは高くて買えなかったら残念ね。 諦めるか、自分で実装するか、お金を出して実装してもらうかするしかないよね。 40 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 03:16:30 ] あ？書き方が変で分かりづらかったね。 Cのネイティブ・プラットフォーム（winとかcudaとか）を中心に考えるんじゃなくて、JavaとかC#とか仮想マシンのプラットフォームを中心に考えて処理の設計・アルゴの実装してね。 JavaとかならライブラリAPIへのアクセス方式（の規約）が統一されてるから、他の人のライブラリも同じような使い方だし、自作でも使ってくれる人も多くなるし、すぐその世界で有名になれる。 41 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 03:19:31 ] >>37 Cでかかれたライブラリならまだ他言語から使いようがあるが、 Javaでかかれたクラスライブラリは他言語から使いにくい(車輪の再発明を強いられる)。 よって、Cで書いた方がよい。 42 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 03:19:40 ] 変なのは書き方じゃなくて頭 43 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 03:23:19 ] そういや、アルゴってマンガがあったな。 44 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 03:24:39 ] >>34-36 最悪１ピクセルごとに処理するために関数呼び出しするんですけど、コスト無いんですか？ メモリ上の画像処理で、いつも遅い原因はここだと思ってたんですけど、このスタックへの値渡しがコストじゃないとすると、何がコストの元になってるですか？ for (;;){ c=getPixel(x,y) delegateFilter(c); setPixel(x,y,c); } とかですよ？ 45 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 03:29:05 ] 値渡しは関数（の引数）ローカルスタックへのコピーのことで、int cというわけでもなくstructもありえます。 これ以外は全てどの処理系どの言語でも省けない処理（画素の取得、加工、更新）なのでコストとはいえない思うですけど。 for (;;){ c=getPixel(x,y) delegateFilter(&c); setPixel(x,y,c); } 46 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 03:29:09 ] コストが掛かるかやその大小は実装方法や環境による 47 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 03:32:42 ] >>44 >>33に聞けよ。 48 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 03:37:09 ] >>41 分からなくも無いよ。その発想は。 もともとCはシステム（OS）を記述するために開発された汎用・移植用の言語であって、汎用性は高いけど、画像処理とか２D（GUI)の処理には向いてないよ。 とくに、画像処理は他の画像処理に依存することもあるから他のオブジェクトへのメッセージ、つまりOOPが適しているし、 そもそも画像データとその処理が一体なのであって、これも突き詰めるとOOPとなる。 OOPの言語ならどれでもいいけど(ruby,javascriptとか）、デファクトなJavaかMSのみがターゲットならC#となるだけ。 批判するならもうちょっとちゃんと勉強してからにしたほうがよかったね。でも分かるよ、その自分の知ってる言語で全部済ましちゃいたいって言うその発想は。 結局BasicとCしか手になじまなかったってことで、Java, OOP云々よりも君のスキル不足ってだけなんじゃないの？ 49 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 03:38:10 ] つまんね 50 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 03:41:16 ] >>46 じゃ「実用的な速度」ってなんのことですか？ それならCで実装する必要はありませんよね。 速度やコストがすぐ話題になりますが、結局Java,C#で実装したアルゴリズムが原因ではなく、IO（ネイティブ）じゃないですか？ そういうところをちゃんと分かって、そういう視点で設計を考えたことありますかね？ 51 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 03:48:05 ] CPU boundか IO boundかは処理によって違う。 ものそごく単純化すると、単純な処理ならIO boundになりやすいし、 処理が複雑なら CPU boundになりやすい。 52 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 03:49:44 ] なぜ極狭い一面を見ただけで一般化しようとするかな。 53 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 04:07:30 ] >>51 GPUには期待してますけど、今までのCPUとはまた違うパラダイムでしょうね。 上の議題は、GPUではなくCPUでの画像処理（所詮２D）での話ですけど。 GPUは、ifによる分岐じゃなくストリームのパラダイムなので、２D処理（つまり従来からの画像処理・探索）は向いてないと思いますよ。 CPUは４Gぐらいが限界と分かったので、これ以上はいくらハード・アルゴをチューニングして頑張ってももはや速くはならないでしょうし、0xffff * 0xffffの画像とかデジカメならすぐ到達するんで、２Dのアルゴも違う発想が必要になるでしょう。 54 名前：デフォルトの名無しさん [2009/07/11(土) 04:09:37 ] ここ何人いるの？ 55 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 04:14:48 ] 多分日本人 56 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 04:59:20 ] 車輪の再発明の話は散々出るけど、ならなんで新しい言語が次から次へと登場するのかね。 しかも似たりよったりの言語が。あれは車輪の再発明とは呼ばないのだろうか。 ライブラリの話を見ていて、なんだかそんな気分になった。 57 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 06:51:49 ] 言語は、言語開発者がそれを作る目的によって違うので、いくつもの似たような言語があっても目指すものが違うんですよ。 コンパイラとか作ったこと無いと分からないんでしょうけど。 似たように感じるのは、文法が似てるからだとは思いますが、ハスケルみたく奇抜な文法だと多分あんたじゃ習得できないでしょう。 分かりやすいところでは、Cでは2D,GUI向けの言語ではないので、「ウインドウを作ってボタンを押してハローワールド」 これだけのことをやるのに、win32だと５０行ぐらいは必要でしょう。 それ用のランタイムライブラリや言語だと２−３行でしょうけど、この違いは文法（リテラル）の差ですよ。 この言語上の文法が内部で車輪（よりネイティブに近い実装ライブラリ）を呼び出してるんですけど、これを再発明する必要はないでしょう。 変色フィルターとかアフィン変換とか通常の画像処理はjava,c#でライブラリとしてほとんどあるんで、勉強目的以外なら普通は自分で改めて書いたりませんけどね。 何とかの分離とも言いますが、とくにかくCのコードはIOだけにしてそのハード用の使い捨てにして、画像処理のアルゴリズムなら、javaとかvmのプラットフォームを中心にすえてコードを書くといいですよ。 後２−３年で携帯とか他のOSでもそのアルゴが何の変更も無く普通に使える（再利用できる）ようになるでしょうし。 58 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 06:59:07 ] >>57 ＞作る目的によって違うので、いくつもの似たような言語があっても目指すものが違う ライブラリもそうじゃないのかｗ 59 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 07:37:25 ] またなんか凄いのが沸いてるな。 OOPって単語覚えて嬉しいのはわかるけど、 画像処理技術と設計技術はなんの関係もないので、よそで喚いてくださいね。 60 名前：デフォルトの名無しさん [2009/07/11(土) 07:49:23 ] ARMは固定小数点の方が速いんだよな。 61 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 08:56:00 ] 携帯で「高速な画像処理が出来る」とか期待しないけどね。普通の人は。 62 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 08:57:50 ] >>59 画像処理技術とかたいそうな漢字を並べてみても、君なんか所詮未熟者でしょ？ｗ 63 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 09:04:00 ] >>58 そのライブラリとか、自作の処理を関数化したりを突き詰めると結局「それ用の言語を作ったほうがいい（つまり文法とリテラル）」ってなるんですよ。 例えばマテマテカとかRとか使ったこと無いでしょ。君みたいな貧乏低学歴じゃ。 多少難しいこと買いても、このスレでは無能ばかりだしついてこれようなるまじめな人もいないみたいなので、これぐらいで勘弁してあげましょうかね。ｗ 64 名前：デフォルトの名無しさん [2009/07/11(土) 09:08:57 ] >>59 OOPが未だに理解できないのも分かるんですけど… そんな万年石頭のオジサンに、返して差し上げる言葉ありませんよ。 65 名前：デフォルトの名無しさん [2009/07/11(土) 09:40:12 ] きちがいうぜー 66 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 10:52:58 ] トリップ入れろ てかactionscriptでいいんじゃない？ 67 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 11:04:58 ] 要するに、画像処理専用の言語があればいいんだな。 そういうのはあるよ。たぶん、JavaとかC#には乗らないけど。 68 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 11:12:31 ] 画像処理にOOPが必要かどうかの議論は pc12.2ch.net/test/read.cgi/tech/1243827025 でやった方がいいと思う。 69 名前：デフォルトの名無しさん mailto:sage [2009/07/12(日) 03:16:55 ] >>66 痛いな 70 名前：デフォルトの名無しさん mailto:sage [2009/07/12(日) 03:17:59 ] スレタイとスレ番に期待して覗いてみたら…　半年後にまた来ます。 71 名前：デフォルトの名無しさん mailto:sage [2009/07/13(月) 04:33:40 ] 正しいと思うなら自分で作って証明すればいいだけだし みながそうしてきた結果が今の状態だろ 72 名前：デフォルトの名無しさん mailto:sage [2009/07/13(月) 13:11:26 ] イミフ 73 名前：デフォルトの名無しさん mailto:sage [2009/07/13(月) 14:36:01 ] 頭の悪い高校生（だよね？）のために現状を解説すると、 アルゴリズムの検証や研究などには Matlab などの簡便で高級な環境を使う。 実用品の実装には C 等の高速な言語を使う。 ので、記述力がない上に遅い Java や C# を使う必要があるケースは少ない。 個人的には Matlab 使えないけど手軽に検証したいときには C# は便利だと思うけど、 そういう状況があるのって非専門家だけだからなあ。 74 名前：デフォルトの名無しさん mailto:sage [2009/07/13(月) 14:49:34 ] マットラボ乙 75 名前：デフォルトの名無しさん mailto:sage [2009/07/13(月) 21:36:53 ] >>73 画像処理は何使ってやってんの？ 76 名前：デフォルトの名無しさん mailto:sage [2009/07/13(月) 23:47:39 ] 別に10Bitの浮動小数点数が使えるから 喜んでPascal使ってる俺みたいのがいてもいいじゃんか 77 名前：デフォルトの名無しさん mailto:sage [2009/07/13(月) 23:49:04 ] Byteだったお 78 名前：デフォルトの名無しさん mailto:sage [2009/07/14(火) 01:09:37 ] 1024ﾊｱﾊｱ 79 名前：デフォルトの名無しさん mailto:sage [2009/07/14(火) 12:45:00 ] fp10って奴だろ RGBを10bitずつで、あと2bitをαとか 80 名前：デフォルトの名無しさん mailto:sage [2009/07/14(火) 19:05:21 ] Matlabって画像処理に使いやすいかぁ？ 81 名前：デフォルトの名無しさん mailto:sage [2009/07/14(火) 19:08:32 ] 頭の悪い高校生なんだから相手しちゃダメ 82 名前：デフォルトの名無しさん mailto:sage [2009/07/15(水) 09:37:36 ] 去年matlabからC++への移植＋高速化の仕事があった。 matlab100行がC++で3000行、速度は4〜6桁高速化。 83 名前：デフォルトの名無しさん mailto:sage [2009/07/15(水) 10:20:23 ] それは高速化したんじゃなくて、もともとマトラボのそのコードが糞遅かったんだろｗ 84 名前：デフォルトの名無しさん mailto:sage [2009/07/15(水) 11:35:27 ] 4〜6桁って、1万倍から100万倍ってこと？ 85 名前：デフォルトの名無しさん mailto:sage [2009/07/15(水) 11:50:24 ] 高速化してくれって言う案件を受けるってのが凄いな。 いくらなんでもそんな要求はキリ無いだろ。 もし最適化してプロトタイプ実装しても、その仕様を満たさないならいくら準備料を積んでもらっても無駄骨だしな。 おまえのところは、明日の飯を食うのも困るほどの零細なハウスなんだろう 86 名前：デフォルトの名無しさん mailto:sage [2009/07/15(水) 12:10:25 ] >>83 確かに組み込み関数を並べているだけの芸の無いコードだった。 コアのコードなんて10行くらいｗ。 高速化の内容は 　処理時間の大部分はconv2(fft + ifft)の膨大な繰り返し 　conv2の繰り返し処理に対応する部分を2〜3桁高速化 　今度はmaxに対応する処理が時間の大部分を占めるようになったので、そこを2〜3桁高速化 >>84 1000倍から100,000倍(画素数による) >>85 あなたはエスパーですか？ 他社がさじを投げた案件ばかり回ってくる零細ソフトハウスです。 87 名前：デフォルトの名無しさん mailto:sage [2009/07/15(水) 12:25:30 ] そんなの受けて無駄な時間を使うな。 もし受けざるえないなら料金を吊り上げろ。 お前みたいな低脳低学歴が下らないおせっかいをするからソフト業界の案件受諾価格が下がるだろが。 もしこういうのがやなら、お前のところはフリーソフトでも作ってろカス 88 名前：デフォルトの名無しさん mailto:sage [2009/07/15(水) 12:31:25 ] なんなんだこいつは 89 名前：デフォルトの名無しさん mailto:sage [2009/07/15(水) 12:45:50 ] 87はプロダクト・マネージャーの精霊です 90 名前：デフォルトの名無しさん mailto:sage [2009/07/15(水) 13:54:59 ] 特化したソフトを作る会社があってもいいじゃないか 91 名前：デフォルトの名無しさん mailto:sage [2009/07/15(水) 14:01:22 ] >>88 それで高速化さん、マットラボと画像処理はどう関係あるの？ 92 名前：デフォルトの名無しさん mailto:sage [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」と出てうまくいきませんでした。 何かやり方が悪いのでしょうか、どなたかご教授下さい。 93 名前：デフォルトの名無しさん mailto:sage [2009/07/15(水) 16:36:50 ] OpenCV使え。デフォルトでPNG読み込める。 94 名前：デフォルトの名無しさん mailto:sage [2009/07/15(水) 16:43:43 ] この画像で何がしたいんだ? 95 名前：デフォルトの名無しさん mailto:sage [2009/07/15(水) 17:57:44 ] >>93 LIBPNGを使う前提でやっていますので…。 >>94 この画像でという訳ではなく、 読み込みに失敗する場合があるという点が問題なのです。 96 名前：デフォルトの名無しさん mailto:sage [2009/07/15(水) 18:47:50 ] sample2.pngの中身が分からんと解決しようがない 97 名前：デフォルトの名無しさん mailto:sage [2009/07/15(水) 19:16:53 ] 画像でないが、とあるツールのログ解析するソフト、チョロッと作ったら、10H が20secに短縮したな。 SED等の組み合わせでやっているのを、rubyで字句解析入れてやった。ｗ 98 名前：デフォルトの名無しさん mailto:sage [2009/07/15(水) 19:34:40 ] さっきから画像関係ないよな… 変なのがいついちゃったな 99 名前：デフォルトの名無しさん mailto:sage [2009/07/15(水) 20:58:18 ] >>96 えっと、中身とはどういう事でしょう？ 100 名前：デフォルトの名無しさん mailto:sage [2009/07/15(水) 21:05:06 ] >>99 スレ違いだっつーの さっさと失せろクズ

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef