画像処理 その10 ..
[2ch|▼Menu]
445:デフォルトの名無しさん
08/03/08 21:23:01
「似ている」とは何を意味するのかが問題ですな

446:デフォルトの名無しさん
08/03/08 22:04:39
彩度が高いと色相が支配的になるだろうし、
色相によっては明度が違って見えるし、
明度が両極端だと彩度の意味がなくなるし、
……

447:デフォルトの名無しさん
08/03/08 22:19:07
いわゆる特殊な色覚を持っている人が似ていると判断する色と
そうじゃない人が似ていると判断する色は違うからなぁ

448:デフォルトの名無しさん
08/03/08 22:22:03
周波数領域での加工を前提とすると、
FFT前に窓がけしないと、周波数領域の信号レベルの確度が悪くなる
逆FFT後に窓がけしないと、時間領域で接続性が悪い

上の理由から実務上2度窓がけする必要があって、かつ、2度の窓がけ後の結果の
オーバーラップが元信号に戻らないといけない。でも、han窓は1回の窓がけの
結果のオーバーラップで元に戻るように設計されてるから適さない。


449:デフォルトの名無しさん
08/03/08 22:43:01
なぜサウンドプログラミングスレのコピペが

450:デフォルトの名無しさん
08/03/08 23:18:56
>>443
まずyuy2にする。それで輝度と色度に分ける。
人間の眼は輝度>色度だから色度の重要さを下げる。
音よりは低いが人間の感じる感触は指数に比例しがちだからそれも考慮する。

ってのを考慮すればそこらのフリーソフトよりは精度上がるよ。
それ以上は研究の分野になる。

アナログ<->デジタルはいつの時代も研究さ。

451:デフォルトの名無しさん
08/03/08 23:40:01
研究とか言い出す前に「均等色空間」という言葉くらい出そうぜ。
塗料とか製造業の分野では色の違いは黙ってΔE*abで評価するものだ。

452:443
08/03/09 00:04:22
>>444
RGBのそれぞれの差に、緑を大めに掛けてみるってこと?

>>445
色が近いかどうかって意味。
赤と青はだいぶ色が違うけど、緑と黄緑は色が近いとかって感じ。

>>446
色とかの判断方法は全然知らないのでちょっと調べてみたんですけど、画像関係のアルゴリズムは奥が深そうで・・・。

>>447
まー、一般的な人が似ている色とするってことで。

>>448
よくわからんけど、サウンド関係ってことかな。

>>450,451
YUY2とか、均等色空間とか、聞いたことない単語が出てきたから、明日調べてみる。


453:433
08/03/09 13:36:32
以下のページを参考に、色差を求めることにしました。ΔE*abってやつですかね。
URLリンク(image-d.isp.jp)
URLリンク(www11.tok2.com)
多少、感覚と違う値となることはありますが、似ているのに違う色と判断することがないよう、閾値を大きくすることにしました。20とか。
違う色なのに似ていると誤判定されても多少は許される用途なので。

それにしても、規格が多く、変換に使用する値が複数あったりしてややこしいですね。

454:デフォルトの名無しさん
08/03/09 13:40:32
まあそんなんでいいと思うよ

455:デフォルトの名無しさん
08/03/12 15:45:35
パターンマッチ+サブピクセル処理をいろいろ調べたいのですが、
いいサイト、本などございませんでしょうか。
本をみたりしていますが、なかなかいいものがなくて。

やりたいことは、撮影位置に移動してきた
丸いものの画像を取ったときのずれ量(XY座標)
を検出したいです。

先生方よろしくお願いします。


456:デフォルトの名無しさん
08/03/13 18:13:55
どこまで調べた?
本のタイトルとか。
あと、それで満足できない理由は何かを教えといて。


457:455
08/03/14 00:37:18
>456
すいません。
あと一日調べ倒してから、
再質問することにします。



458:デフォルトの名無しさん
08/03/14 00:39:34
そういやJPEG XRってどうなってるんだろ

459:デフォルトの名無しさん
08/03/14 02:55:21
DATファイルに格納されている画像を取り出すにはどうすればいいですか?

460:デフォルトの名無しさん
08/03/14 03:16:56
スレ違い

461:デフォルトの名無しさん
08/03/14 15:52:04
ある意味画像処理だなw

462:デフォルトの名無しさん
08/03/14 17:01:45
>>459
拡張子をmpgに書き換えてダブルクリック

463:デフォルトの名無しさん
08/03/14 19:39:31
>455
やりたいことから考えると、パターンマッチングよりハフ変換のような気がする。
その「丸いもの」は何?
カメラ視野に入ってきたり出て行ったりするもの?
形や大きさが決まっているならテンプレートマッチングでいいけど。決まっていないならハフかな。

理論が知りたいなら、Forsyth「コンピュータビジョン」あたりが、理論はどうでもよくとりあえずできればいいならOpenCVでいいのでは。


464:455
08/03/15 03:34:20
>463
ご返信ありがとうございます
ハフ変換(円弧)実験してみます。

丸いものは、ちょっと答えられないのですが、すいません。

あと精度を高めるためにサブピクセル処理を調べていますが
いまいち理解ができていないためか、
ハフ変換で円弧検出後、サブピクセル処理をどう実装すればいいか
わかりません。頭悪くてトホホ。


明日、都会までいくので
Forsyth「コンピュータビジョン」
OpenCVの本も買ってみます。
楽しみです。電車の中で読んでみることにします。
ありがとうございます。

制御ソフトとは、また違って画像処理は奥が深く
興味深いです


465:デフォルトの名無しさん
08/03/15 03:42:07
Computer Visionは日本語訳が出てますよ(調べてるだろうけど…)

466:デフォルトの名無しさん
08/03/15 09:10:23
丸いもの……
ディスク? 半導体ウェファー? 月? 鼈?

467:デフォルトの名無しさん
08/03/15 11:00:17
Wikipedia項目リンク

丸いものがいっぱい。

468:デフォルトの名無しさん
08/03/15 12:51:12
Forsyth「コンピュータビジョン」を持ち歩くのか...

469:デフォルトの名無しさん
08/03/15 18:14:49
>464
サブピクセル処理、わからなければ元画像を10倍に広げてやれば、元の0.1ピクセル処理したのと同等。

あと、フォーサイス&ポンスの本は理論偏重なのでズバリと書いてあるわけではないし、方向性が違えば全く役に立たない。読んでいて面白いから価値はあるけど。本屋で見てみるべし。


470:デフォルトの名無しさん
08/03/15 21:42:00
>>467
灌漑農業の上空写真か。
まるで圧縮画像のブロックノイズだな

471:デフォルトの名無しさん
08/03/17 21:18:51
画像の回転について質問があるのですが、回転行列を
固定小数点にて表現するときにはどの程度の精度があれば十分なのでしょうか?
自分の考えだとVGAの場合2^10>640であるため符号も込めて10ビットの精度が必要
であると思うのですが如何でしょうか?


472:デフォルトの名無しさん
08/03/17 21:48:27
君に目は無いのか

473:デフォルトの名無しさん
08/03/17 22:51:06
無いんです

474:デフォルトの名無しさん
08/03/18 03:25:33
このスレの住人なら知っていますね、あの糞開発ツールのことを

・自分のプログラムのバグなのかコンパイラのバグなのかわからない
・他の仕事に応用できない糞開発ツールの独自世界を必死に学習している
・テキストエディタで書いたほうが効率的なのに糞UIツールを懸命に使っている

糞だけど、政治的な理由で無理やり使わされているんですよね。
もう、あんな厨の作った糞ツールを我慢して使うのはやめましょう。

・糞開発ツールを部下に押し付ける上司の命令は無視しましょう。
 上司は糞開発ツールが使われる実績を作ることであの会社のごきげんをとっているのです。
・あの糞開発ツール提供会社には「おたくの糞開発ツールは話にならない」と突き放しましょう。
 バグレポートなどしてはいけません。改善要求などもってのほかです。
 あの会社はあなたたちのことをテスター/モルモットとしか思っていません。
・あの会議で「糞開発ツールを使ったら生産性がxx%アップしました」
 なんて話が出たら力強く机を叩き、会議室を出ましょう。
 あの人たちは糞開発ツールをマンセーすることで立場を確保しているのです。

糞な開発ツールを糞だと言える、そんな当たり前の環境をみんなの力で取り戻しましょう。

475:デフォルトの名無しさん
08/03/18 04:49:43
あれってどれだ
いっぱいありすぎてわからん

476:デフォルトの名無しさん
08/03/18 15:34:41
Javaだろ。

477:デフォルトの名無しさん
08/03/18 16:42:14
Javaってツールなのか?

478:デフォルトの名無しさん
08/03/18 17:50:02
コンピュータ自体がツールです

479:デフォルトの名無しさん
08/03/18 18:15:39
Oracleのツール類だろ。

480:デフォルトの名無しさん
08/03/18 19:41:17
人間はわたしの道具です

481:デフォルトの名無しさん
08/03/18 22:28:54
我が共和国の同士は全て将○様の道具ニダ。

同士でないのは、奴隷ニダ。

482:デフォルトの名無しさん
08/03/20 11:16:20
アーア

483:デフォルトの名無しさん
08/03/25 13:20:42
lisp使ってる人っています?
pythonなら沢山いるのかな
ほとんどはc?

484:デフォルトの名無しさん
08/03/26 02:37:08
> lisp使ってる人っています?
> pythonなら沢山いるのかな
どちらも好きだが本格的に使うに至らない

485:デフォルトの名無しさん
08/03/26 02:49:37
簡単な処理ならPython+PILでやるときもある

486:デフォルトの名無しさん
08/03/26 04:46:31
>>483
何か遅いよなぁと思いつつJava

487:デフォルトの名無しさん
08/03/26 21:10:17
URLリンク(www.cliki.net)
lispの画像処理、いろいろあるけど
OpenCVみたいにメジャーなのはどれ?

488:デフォルトの名無しさん
08/04/03 22:12:23
URLリンク(dc.watch.impress.co.jp)
すげえ

489:デフォルトの名無しさん
08/04/03 22:32:58
>488
確かにすげぇ。
ピンボケしても元の情報って落ちてないのか。
落ちてると思い込んでた。

490:デフォルトの名無しさん
08/04/03 22:43:36
>>488
これはデコンボリューションの1種という捉え方であってるのかな…

491:デフォルトの名無しさん
08/04/03 22:46:32
いや、落ちますよ。写真として再現するレベルには足りているようですが。

492:デフォルトの名無しさん
08/04/03 22:57:27
この人は元Stanford大なんだね
研究成果を活かしたベンチャーらしい
だれか興味がある人は元の論文読んでくれ


493:デフォルトの名無しさん
08/04/03 23:05:47
>>488
この"Light Field Camera"ってカメラ自体も特殊なんじゃねーの?
URLリンク(dc.watch.impress.co.jp)

494:デフォルトの名無しさん
08/04/03 23:28:32
URLリンク(graphics.stanford.edu)
URLリンク(graphics.stanford.edu)
URLリンク(graphics.stanford.edu)
センサの手前に挿入するマイクロレンズが肝で、
4次元ライトフィールドをキャプチャできる代わりに解像度が犠牲になります。
本当にありがとうございました。

495:デフォルトの名無しさん
08/04/04 00:41:38
>>494
リンクにある顕微鏡版のはyoutubeにデモがあがってたな

496:デフォルトの名無しさん
08/04/04 07:52:55
あの〜、ピンボケの自動補正なんて、すごく地味で超初心者向けな機能なんですけど。
この手法を応用して、もっと別な面白いことに発展したらいいね。

497:デフォルトの名無しさん
08/04/04 08:54:40
つまり、記事を書いた香具師は画像処理の基本も判っていない半可通だと言うことで宜しいか。

498:デフォルトの名無しさん
08/04/04 09:01:18
記事ではマイクロレンズにも言及しているし、仕組みを何も理解せずに書いたわけではないだろう。
ただ、タイトルが「ソフトウェア技術」となっているのは誤解を招きやすい。

499:デフォルトの名無しさん
08/04/04 10:09:20
>>498
発表者がマイクロレンズって言ってたのをそのまま書いただけだろ。
ボディとレンズの間にマイクロレンズがあるって、あとから訂正されてるし。

500:デフォルトの名無しさん
08/04/04 10:33:54
ああ、さっき初めて記事を読んだから気づかなかったけど、>>494の1時間後に訂正されてたのか。

501:488
08/04/04 21:16:52
やっぱりそういう話なのか(´・ω・`)
光学屋には面白いけど、画像処理はそこまで
複雑じゃないよなあ

502:デフォルトの名無しさん
08/04/04 21:33:56
これってあとから被写界深度も変えられるのかな


503:デフォルトの名無しさん
08/04/05 01:00:37
>>501
>>494の2つ目の論文(SIGGRAPH 2005採択)を読んだ上で「そこまで複雑じゃない」と言ってる?
4Dライトフィールドと2D写真の関係を周波数空間で解析する理論のほうもかなり興味深いと思うけどなぁ

504:デフォルトの名無しさん
08/04/11 15:33:18
C以外を使ってる人って本当にいないのかい?

505:デフォルトの名無しさん
08/04/11 16:01:32
>>504
いくらでもいるだろ。このスレでもアセンブラの話をしてるやつがいた。
ただ、言語の話はスレ違い。

506:デフォルトの名無しさん
08/04/12 07:01:58
c#でもそこそこスピードでたので移行した。

507:デフォルトの名無しさん
08/04/15 17:48:02
himatsubushiってサイトの人は、
昔、VBで書いてた

508: ◆Cgjmdh7/b6
08/04/16 00:24:35
test

509:デフォルトの名無しさん
08/05/01 00:28:36
グレースケールのある程度変化のある背景から明度の差がある
繋がった図形をどうやって抽出すればいい?

背景は基本的に連続的だが規則性はない
抽出するものは例えば中が塗られたいびつな円とかだけど輪郭は、ぼやけてる
抽出条件は基本的に周りより暗いってことだけ
人間がみれば見つけられるが、輪郭強調すると背景のパターンも強調されてしまう
背景は暗い部分もあれば明るい部分もあり、閾値は使えない

510:デフォルトの名無しさん
08/05/01 00:37:26
>> 509
何で背景は暗い部分と明るい部分に分かれるの?
安定した状態にならない理由は?

511:デフォルトの名無しさん
08/05/01 07:50:54
とりあえず1階微分とって観察。
2階微分とって観察してみれば?

512:デフォルトの名無しさん
08/05/01 21:36:44
シェーディング補正とかは使えないのかな?

513:デフォルトの名無しさん
08/05/02 10:09:17
boost.gilの正式版でたけど使ってる人いる?

514:デフォルトの名無しさん
08/05/02 11:46:16
3月にでたBIASのリリース版使ってる人いますか?
深刻なバグあったりしないですか?
うちは挙動がおかしかったので前のバージョンに戻しました

515:デフォルトの名無しさん
08/05/02 11:51:37
なにそれ

516:デフォルトの名無しさん
08/05/02 18:53:26
>509

面積・幅・形状よって適した方法が変わるので、モノは何?
言いたくなければ、近いものでもWebイメージから指定したら?

汎用の回答でいいなら、「Photoshopでアンシャープ後、2値化する。」


517:デフォルトの名無しさん
08/05/03 13:20:46
BIAS
URLリンク(www.mip.informatik.uni-kiel.de)

ver 2.5.0で問題なく動いていたプログラムが
ver 2.6.1にしたとたんセグメントフォルトで落ちるようになった

何かの関数を連続で呼ぶと関係ない配列データの中身を書き換えているぽい

誰か使ってる人いないの?
画像の幾何学処理してくれるlibraryって他にある?


518:デフォルトの名無しさん
08/05/03 18:15:49
例外が発生するバグほどデバッグしやすいものはないと思うが。
デバッガ使えばすぐにどこが悪いか分かるだろう。

519:デフォルトの名無しさん
08/05/05 02:07:10
>>513
使ってるよ

520:デフォルトの名無しさん
08/05/05 10:36:36
BIAS::Vector3<double> v=hoge();



BIAS::Vector3<double> v;
v=hoge();

を繰り返し呼ぶと答えが違う

c++の行列計算はもうublas以外信じねえわ

521:デフォルトの名無しさん
08/05/05 23:55:15
>>520
x86では普通

522:デフォルトの名無しさん
08/05/06 00:06:58
どうせ80ビットで計算するならlong double残しといてくれって話だよな

523:デフォルトの名無しさん
08/05/09 12:04:20
VBやVCから使えるDLLで、2枚の画像を半透明合成できるものってあるかなあ・・・

524:デフォルトの名無しさん
08/05/09 13:17:07
今から作れば?
おやつ前にはできるだろ。

525:デフォルトの名無しさん
08/05/09 13:27:29
作れないザコのゴミレス程、存在価値のないものはないなw

>>523
mDibでググれ

526:あいちゃん
08/05/09 13:29:30
2枚の画像の半透明合成って、対象の画像を1bitずつ交互に描画していくだけじゃだめなの?

527:デフォルトの名無しさん
08/05/09 13:33:27
半透明のコードぐらいググればすぐ出てくるじゃん。

528:デフォルトの名無しさん
08/05/09 14:33:44
本件に関しては、DLLを探して使い方調べているより自分で作った方が早い
に一票

529:デフォルトの名無しさん
08/05/09 14:36:44
>>524=528
作る技術もないのにエラソーにw

530:デフォルトの名無しさん
08/05/09 14:40:23
いくらなんでもそれはスキル低すぎだろ。
DLL作ったことありませんとか、BMPの扱い方が分かりませんのレベルか?

531:あいちゃん
08/05/09 14:42:29
えらそーにしてるのは>>529だと思います!!

532:デフォルトの名無しさん
08/05/09 15:09:34
>>529
10行程度のプログラムに「作る技術」もないだろ

533:デフォルトの名無しさん
08/05/09 16:01:11
煽ればムキになってコードが返ってくる
と思ってるくさい

534:デフォルトの名無しさん
08/05/09 18:08:28
口だけのやつばっかだなw

>>532
10行程度なら書いてみな? 無理だろほーらばかw

535:デフォルトの名無しさん
08/05/09 18:23:43
普通にググったらソース出てくるのに。もうアホかと。

536:デフォルトの名無しさん
08/05/09 18:29:08
>>533
大正解
おめでとう

537:523
08/05/09 18:39:14
>>525
ありがとう


538:デフォルトの名無しさん
08/05/09 18:39:45
>>535
ソースがあれば何でもできると思っている基地外発見ww

539:デフォルトの名無しさん
08/05/09 18:42:02
どんだけスキルないねん。ここム板やで。

540:デフォルトの名無しさん
08/05/09 18:45:32
普通にググったら詳細な説明も出てくるのに。ゆとりか?

541:デフォルトの名無しさん
08/05/09 18:46:59
>>537
おまえのせいで荒れてるのに、不自然なんだよ。
自演してんじゃねー、ボケ。

542:デフォルトの名無しさん
08/05/09 18:47:46
>>537
どういたしまして

543:名無し募集中。。。
08/05/09 21:31:00
あるふぁぶれんど?

544:デフォルトの名無しさん
08/05/09 22:06:40
ちょっと上の方でも出てるので便乗で。
現在様々なブレンドモードに多対応させるため、いろいろ組んでるのですが、
通常のアルファブレンドの部分でどうしてもエッジが黒ずんでしまいます。
合成前のイメージはGDIなどで貼り付けた場合は黒ずまないので補間処理が
間違っている訳ではないみたいなのですが…

byte tb;//前景色(青)
byte t;//背景色
byte ta;//前景のアルファ
(((tb - t) * ta) >> 8) + t

これを各色回してるのですが、どこを間違っているのでしょうか?

545:デフォルトの名無しさん
08/05/09 22:21:15
>>544
それbyteじゃ駄目だろう。
あとαが0〜255なのに、256で割ったら駄目だろう。

546:デフォルトの名無しさん
08/05/09 22:33:23
>>545
byteは演算式の中ではintに自動格上げされるから問題ないだろ

547:デフォルトの名無しさん
08/05/09 22:36:33
>>545
回答ありがとうございます。

byteは引き算が入ると自動的にintにアップキャストされるはずですが…
αを256で割るのはどこのページを見ても256で割ってるor8ビットシフトしてる
のであってるのかと思いましたがそうではないのでしょうか?

とりあえず、変数をdoubleにし、255で割ってみましたがだめでした orz


548:デフォルトの名無しさん
08/05/09 22:39:52
元画像が前乗算済みARGBになってたりはしないよな?
GDI+で言うPixelFormat32bppPARGB

549:デフォルトの名無しさん
08/05/09 22:41:10
アルファが正しいかどうか疑うべきだな

550:デフォルトの名無しさん
08/05/09 22:50:25
>>548
それはないです。ちゃんとPixelFormat32bppArgbとなっています。

>>549
αはGDIで合成したときは黒ずまないのであってると思いますが…
一応補間部分の式も載せておきます。

byte c1, c2, c3, c4;//各ピクセルの色
byte c1a, c2a, c3a, c4a;//各ピクセルのα
float px, py;//位置
float pp = px - Math.Floor(px);
float qq = py - Math.Floor(py);
float ip = 1 - pp;
float iq = 1 - qq;
float a = (ip * ((iq * c1a) + (qq * c3a))) + (pp * ((iq * c2a) + (qq * c4a)));
float c = ((ip * ((iq * c1 * c1a) + (qq * c3 * c3a))) + (pp * ((iq * c2 * c2a) + (qq * c4 * c4a)))) / ta;

こんな感じなのですが…

551:デフォルトの名無しさん
08/05/09 23:08:12
>>550
cの計算でα掛けちゃってるのが悪いんじゃないか?

552:デフォルトの名無しさん
08/05/09 23:28:23
>>551
元々cでアルファは掛けてませんでしたが、その頃からすでに黒い線は
出ていたので、αを掛けてる例もあったので試してみましたが… orz

553:デフォルトの名無しさん
08/05/10 00:09:48
んー、どういう画像を元にして、処理後どうやって表示したとき変に見えるのか、とかちゃんと書こうぜ。

554:デフォルトの名無しさん
08/05/10 00:33:26
>>553
画像は32bitARGBな画像で、背景がα=0でないとき、重ねるイメージを0.5px移動や回転など
で1px未満でずれたイメージのエッジ部分が黒ずんで見えます。

0  0.33  0.67  1 (px)

└─┐
    │←こことか   重ねたイメージ
    └─┐
        │←こことか
        └─┐
背景        │
            └─...

上の0 < x < 1の部分が黒(灰色?)っぽくみえます。

555:デフォルトの名無しさん
08/05/10 00:40:23
上の図は画像ではこんな感じです。

0  0.33  0.67  1 (px)

├───┐
│//////////│←こんな風に黒っぽく
│//////////│
│//////////│  重ねたイメージ
│//////////│
│//////////│
└───┼─...
            │////
背景        │...

556:デフォルトの名無しさん
08/05/10 00:48:30
お前それ、もしかしてバイリニアの色漏れ・・・・
αと関係ないだろ・・・・・・・・・・・・・・

557:デフォルトの名無しさん
08/05/10 01:39:34
>>556

マジすか orzorzorz
でもなぜ変形後のイメージをGDIで重ねたときは黒っぽくならないんだろ…

558:デフォルトの名無しさん
08/05/10 01:53:08
GDI描画でちゃんと補完モードはバイリニアになってるか?

いいから一回描画する画像のαが0のピクセル全部を緑色とかにしてやってみろ。
今度は暗くならず緑色が出てれば間違いなくバイリニア補完での色漏れ。

559:デフォルトの名無しさん
08/05/10 02:10:59
>>558
やってみました。
GDIの補間はバイリニアになってますが、暗くならず、ちゃんと緑になってます。
ただ、自前のバイリニアだと暗くなってます orz

しかも、もっとキモイ事に32bitPNGで保存したときは黒ずみが消えているという…
何をしたWinForm orzorz

560:デフォルトの名無しさん
08/05/10 02:29:44
けっ、どとねと使いか・・・
説明わかりにくいし、状況小出しだし、もうめんどう。
後は自分でがんばりや。

561:デフォルトの名無しさん
08/05/10 03:02:22
先ほど書き出したPNGをPsで見たところ、エッジの部分のαが背景と重ねたイメージが
255なのに対して、少し減っている事がわかりました。
やはりアルファブレンドの処理で何かやらかしていたようです。

>>560
とりあえず原因がつかめたのでどうにかなりそうです。
長々とおつきあいいただきありがとうございました。


//どとねとってどこ行っても嫌われてるのは何でだろう?

562:デフォルトの名無しさん
08/05/10 03:59:36
>>561
補間一つ取っても、どんなアルゴリズムで実装されているのかわからないメソッドなんかがあるから嫌われる。
# なんだよ「『HighQuality』BiCubic」って……

563:デフォルトの名無しさん
08/05/10 11:16:12
>>562
字面通りに捉えれば、BiCubicの高精度版ってだけなんじゃね?
小数点以下の有効桁数の問題なのでは。


564:デフォルトの名無しさん
08/05/10 11:23:07
それにしては違いすぎているから、多分そうじゃない

565:デフォルトの名無しさん
08/05/10 13:11:56
それってドトネトじゃなくてGDI+じゃないの?

566:デフォルトの名無しさん
08/05/10 14:41:37
>>565
ドトネトのはGDI+のラッパーだからドトネトにもあるよ


567:デフォルトの名無しさん
08/05/10 16:38:40
.NET使いのやつには、まず自分の知識不足、理解不足を疑う必要があるのに、WinFormのせいにするような輩が多いからだよ。
まずは自分を疑えと。話しはそれからだ。

568:デフォルトの名無しさん
08/05/10 17:02:31
それはC++でもJavaでもPHPでも同じだと思うけど?

569:デフォルトの名無しさん
08/05/10 19:04:41
>>566
だから>>562は「どとねとってどこ行っても嫌われてるのは何でだろう?」への回答としては不十分だって話だろ

570:デフォルトの名無しさん
08/05/10 21:02:36
VC、VB屋でもDLLだけ欲しがる奴もいるし、
コード張ってくれなきゃ逆切れする奴もいるし、
.net屋だからというのは偏見だと思うな。

571:デフォルトの名無しさん
08/05/10 23:19:53
自分のプライドを守るために卑しむわけです。

572:デフォルトの名無しさん
08/05/11 01:40:54
イラストと写真を判定したいのですが
よい基準ありますか

573:デフォルトの名無しさん
08/05/11 01:47:20
>>567
それ.NET使いに関係なくどの言語・基盤技術上でも底辺プログラマには共通


574:デフォルトの名無しさん
08/05/11 02:48:29
イラストの写真

575:デフォルトの名無しさん
08/05/11 03:21:59
アイドルマスターは実写。


576:デフォルトの名無しさん
08/05/11 05:37:40
>>572
勃起したらイラスト
萎えたら写真

俺の基準

577:デフォルトの名無しさん
08/05/11 06:02:53
>>572
もう釣りにしか見えないけど、自分が絶対断れない立場でこれをやれといわれたら
光の分布をチェックすると思う。方向ならなおよし。


578:デフォルトの名無しさん
08/05/11 07:15:59
>>577
詳しく
写真から3Dモデルを作るくらい難しい?


579:デフォルトの名無しさん
08/05/11 07:57:02
イラストを写真に撮ったのはどうすんの

580:デフォルトの名無しさん
08/05/11 08:22:41
イラストだけならイラスト
額が映っていたり遠近法で歪んで見えると実写だろ
3DCGは?



581:デフォルトの名無しさん
08/05/11 08:50:42
実写に手を加えたものは?

582:デフォルトの名無しさん
08/05/11 09:25:43
属するクラスの選択によって結果が違うだろうな。
両方やって妥当なほうを選択するだろうから
手を加える割合によるんじゃね。


583:デフォルトの名無しさん
08/05/11 10:52:48
完全に汎用なのかどうかにもよるが、画像の特徴抽出をいくつか実装して、
インターネット上に転がっているイラストや写真をどんどん喰わせて出力、
抽出されたパラメータを眺めて相違点を取り出し実装するのが一番現実的
じゃないか?
有意な相違点がなかったら? それは区別できないってことだ。


584:デフォルトの名無しさん
08/05/11 15:56:53
輪郭線

585:デフォルトの名無しさん
08/05/11 17:09:36
>>579
これらのスレを有効活用してくれ
スレリンク(erocg板)
スレリンク(erocg板)

586:デフォルトの名無しさん
08/05/11 18:03:27
>>583
だろうなあ。
今、2割誤判定する方法をふたつ作ったので
こういうのを増やしていってAdaBoostなんかで繋げばいいのかな。
>>584
イラストは縁取りがある判定は一番初めにやったがダメだった。方法がダメなのかもしれないけど、
(1). 微分フィルタでエッジを出す
(2). 暗い色、または鮮やかでない色を抽出
(3). 3近傍内に(1)がある場合、3均衡内に(2)がある割合を求める
ってしたが、縁取りが無いイラストがあったり、あっても縁取りの色がイラストによってまちまちなのと
写真もエッジが出るあたりは暗くなっているので単純に暗い色でやるとうまくいかなかった。
まずは、イラストで縁取りされている輪郭線の色特徴からかな・・・。


587:デフォルトの名無しさん
08/05/11 18:42:55
コンピュータで書かれているイラストなら
色の変化が機械的に整っている。


588:M1
08/05/11 20:50:55
大学院で3次元の画像認識・理解をやろうと思ってるのですが、お奨めの参考書とかありませんか?

ネットで調べると情報は多くあるが内容は少ない。参考書探そうとすると参考とできる書籍自体がない(´・ω・`)

学部ではOpenCVで画像処理やってました。機械の制御の研究室なので、誰も当てにできないヽ( ´Д`)ノ;

589:デフォルトの名無しさん
08/05/11 21:12:20
コンピュータビジョン (単行本)
David A.Forsyth (著), Jean Ponce (著)


590:デフォルトの名無しさん
08/05/11 21:48:51
>>588
論文嫁

591:デフォルトの名無しさん
08/05/11 21:49:51
2chよりは、論文探してその人にメールした方が確実だな。

592:デフォルトの名無しさん
08/05/12 01:44:46
この分野は進歩が激しいので教科書より論文とかプロシーディングだろうな。

593:デフォルトの名無しさん
08/05/12 08:40:24
>>586
個々の判定方法の出力をうまいことひとつにまとめることが出来るなら、
その出力を利用してどちらかを判定する部分に、学習を行わせるツールを作成するといいよ。
面倒だったら、いくつか初期設定した後、どちらかがはっきりしている
1000枚くらいの画像を利用して、GAで境界値(または値の分布表)を
収束させると、うまくいくときは楽でいいだろう。GA部分の作成はたいした手間でもないし。

あとは勝ち残ったアルゴリズムに未知の画像を分類させて、分類に利用する既知の画像を
増やしていくことで、10万枚くらいまでデータを増やせれば、代表的な画像の判定なら
かなりのところまで精度を上げられると思うよ。それ以上は難しいだろうが。


594:デフォルトの名無しさん
08/05/12 08:42:14
>>588
そういう大学で、大学院があるなら、画像研究をやってる研究室があるだろ。
そこにいって相談するのが一番早い。
ないなら、教授のつてで他大学の研究室を紹介して貰え。
縦割りの大学に将来はないぞ。

595:デフォルトの名無しさん
08/05/12 10:34:01
>>594
自宅警備員が偉そうに大学語るなよ(笑)

596:デフォルトの名無しさん
08/05/12 10:48:01
>>588
cinii辺りで検索してみれば?

597:デフォルトの名無しさん
08/05/12 14:05:34
>>593
その程度で難しいって・・・スキル低いやつだなww

598:デフォルトの名無しさん
08/05/12 14:29:39
>>597
日本語よく読めよ

599:デフォルトの名無しさん
08/05/12 17:43:56
言い訳www

知識を無理に披露しようとした>>523かな。乙w

600:デフォルトの名無しさん
08/05/12 18:29:24
>>513
>>519
boost.gil何に使ってます?


601:デフォルトの名無しさん
08/05/12 21:50:24
オカズに使ってます

602:M1
08/05/13 12:28:28
>>589-594
レスthx!やっぱ論文とか他の研究室あたるしかないようだな・・・

>>589
\14,000・・・・
図書館に申請か・・・・・






マンドクサ('A`)

603:デフォルトの名無しさん
08/05/13 18:54:38
ImageMagickで、24bit-BMPを8bit-BMPに変換したいのですが、
どうすればいいか分かる方いらっしゃいましたら教えてくださいm(__)m


604:デフォルトの名無しさん
08/05/13 19:28:50
>>603
URLリンク(www.ss.iij4u.or.jp)
こういう感じ?。

605:デフォルトの名無しさん
08/05/13 22:36:38
何のために減色したいのか知らないけれど、ファイルサイズを気にしているなら小さい画像だと逆効果なので要注意。
8ビットカラーBMPはパレットカラーだからパレットサイズが馬鹿にならない罠。

606:デフォルトの名無しさん
08/05/15 10:06:12
スレ違いの謗りを免れないが、教えてください。
jpeg で圧縮後のサイズを指定できるという書き込みを見かけて、最近また
そういうのができるといいと思い出して、やり方を探しているが分からない。
quality 指定の説明しかない。サイズ指定って出来ないですよね。

607:デフォルトの名無しさん
08/05/15 10:56:48
作るとしたら、DCTを済ませておいて
予め用意しておいた複数の量子化テーブルで圧縮試行を繰り返す、みたいな感じになるのかな・・・

608:デフォルトの名無しさん
08/05/15 11:36:45
ハフマン符号化があるから、処理前にサイズを求めるのは難しいね。
Qualityとファイルサイズの関係はだいたいどの画像も同じような曲線になるから
近似関数を求めておいて、適当なQualityで圧縮してから逆算してみるとか。
単純に二分探索でも良さそうだが。

609:デフォルトの名無しさん
08/05/15 14:16:55
QRコード画像を作りたいけど
どう作ればいいか載ってるサイトか本ありますか?

610:デフォルトの名無しさん
08/05/15 14:28:45
はい。

611:デフォルトの名無しさん
08/05/15 14:41:02
【2次元コード】QRコード総合スレ3【バーコード】
スレリンク(phs板)

612:606
08/05/15 15:35:57
>>607-608
ありがとうございました。

613:デフォルトの名無しさん
08/05/15 15:54:12
>>606-608
ファイルの話で、どうしても指定サイズ丁度にしたいのなら、
圧縮した後、非圧縮部分を付け加えて指定サイズにするのが簡単だ。


614:612-606
08/05/15 23:23:52
>>613
写真のJpegデータをトリムした後、Exif ヘッダ内に埋め込まれた2つの画像
データも更新して置こうと思っているのだが、小さい縦横の画像のJpegデータ
を作ると、そのサイズが大きくなって、Exif ヘッダに収まらない。(で今は
収まらなければ Exif 形式を諦めている。デジカメではうまく収まるように
よく作っているもんだと感心している。)


615:デフォルトの名無しさん
08/05/16 17:20:31
画像データの余白部分を指定した幅にしたいのですが、
どうすれば、できるのでしょうか。
画像データが複数ありバッチ処理できると良いのですが。

具体的には、
画像データの空白(白色)以外の部分に外接する四角形と
画像データの外周との幅が、指定された値になるよう、
余白部分を切り取ったり、追加したりする機能です。

よろしくお願いします


616:デフォルトの名無しさん
08/05/16 17:28:09
スレ違い

617:デフォルトの名無しさん
08/05/16 18:13:01
Visual C++を使って画像ビューアを作成(bmp・jpegが表示でき、色調・コントラスト機能が実装できるもの)したいのですが、どうしたらよいでしょうか??初心者なので何から手を付けていいのかもわかりません。環境はVisual studio 2005です。よろしくお願いします。

618:デフォルトの名無しさん
08/05/16 18:17:48
開発環境のスレできけ

619:デフォルトの名無しさん
08/05/16 18:29:15
ImageMagick でいいんじゃね。


620:デフォルトの名無しさん
08/05/16 18:38:15
>>618
スレ違いでしたか、失礼しました。

>>619
ImageMagicとは何でしょうか?

621:デフォルトの名無しさん
08/05/16 18:40:57
ゴミ

622:デフォルトの名無しさん
08/05/16 19:51:55
聞く前にググらないとか有り得ないし100%釣り

623:615
08/05/16 20:52:18
>>616
スレ違いですか。申し訳ありません。
ググるキーワードか、お薦めスレ等を教えて頂けると幸いですが。
よろしくお願いします。


624:デフォルトの名無しさん
08/05/16 21:59:20
>>617
Express EditionならGDI+を使えばJPEG、TIFF、BMP、PNGを
読み込むことができる。

Standard以上でMFCが使用できるならCImageクラスを使用するなど
できますよ。

625:デフォルトの名無しさん
08/05/16 22:57:30
>615
Photoshopでアクション(SelectAll ->領域をshrink->領域反転->削除)を設定し、フォルダごと適用すればいいのでは。

>617
OpenCVのサンプルコードにあったと思う。とりあえずOpenCVインストールして、あとはそちらのスレへ。


626:デフォルトの名無しさん
08/05/16 23:53:42
>>624さん>>625さん、ありがとうございました。

627:615
08/05/17 11:09:43
>>625
レスありがとうございます。
今現在は理解できませんが、勉強いたします。

628:デフォルトの名無しさん
08/05/17 11:38:51
>>625
>Photoshopでアクション(SelectAll ->領域をshrink->領域反転->削除)を設定し、フォルダごと適用すればいいのでは。
これだとデータを削ることになるジャマイカ。>615の目指すところとは違うと思うぞ。

629:デフォルトの名無しさん
08/05/17 11:57:04
何をしたいのかはっきりしないけど、
Photoshopアクション(カンバスサイズの拡張->上下左右20ピクセル)だと、元画像を削らない。


630:デフォルトの名無しさん
08/05/17 12:05:12
もう一度読むと、何がしたいのかなんとなくわかった。
もともとある程度の白枠があるわけね?
それなら、アクション(位置(0,0)を許容値0で自動選択->削除->カンバスサイズの拡張->上下左右20ピクセル)。


631:デフォルトの名無しさん
08/05/17 13:54:36
板違いもいいとこだ。自分でプログラム書けば簡単だろ。

632:デフォルトの名無しさん
08/05/19 16:22:24
フーリエ記述子から振幅スペクトルと振幅スペクトルの2乗であるパワースペクトルを求めると何の役に立つん?
振幅スペクトルって2次元ベクトルを足して1次元にしてるだけにしか見えないんですがー

633:デフォルトの名無しさん
08/05/19 17:20:11
はじめまして。
すごく初歩的なことをお尋ねします。

CMYKカラーのJpegファイルには、解像度(dpi)情報は含まれていないのでしょうか。
RGBカラーの場合は、取得することができているのですが・・

634:デフォルトの名無しさん
08/05/19 18:23:30
そもそも、RGBカラーのJPEGなんてあったっけ?

635:デフォルトの名無しさん
08/05/19 19:54:25
>>633
とりあえず、そのファイルをうpしてみろ

636:デフォルトの名無しさん
08/05/19 22:09:40
>632
フーリエ記述子って知らんけど、フーリエ変換からのアナグラムと同じだと考えると、
振幅とパワースペクトルとの違いは位相成分なので、起点が違うんじゃね?
パワースペクトルだけだと形の同一性しか分からないけど、位相まで含めれば向きが特定できるとか。



637:デフォルトの名無しさん
08/05/22 19:43:11
>>600
かなり亀レスだけど研究に使ってる

638:デフォルトの名無しさん
08/05/22 21:45:40
>>634
あるよ。規格上は。
現物のファイルでは見たこと無いな

639:デフォルトの名無しさん
08/05/22 23:40:41
epsの入出力に対応して欲しい>gil

640:デフォルトの名無しさん
08/05/23 06:32:39
.NET Framework 1.1 の C# で実装しています
Bitmapクラスに画像イメージを作成・編集し
Bitmap.Save にて Tiff フォーマットを指定して保存しています
この時に Tiff が圧縮された状態で保存されてしまうのですが
無圧縮での保存は可能なのでしょうか
よろしくお願い致します

641:640
08/05/23 07:27:32
>>640 です
EncoderValue.CompressionNone
を指定する所までは行ったのですが、実行すると圧縮されている・・・

642:デフォルトの名無しさん
08/05/23 07:40:14
スレ違い
.NETスレに池

643:デフォルトの名無しさん
08/05/23 07:49:35
無圧縮TIFFくらい自分で書けば?

644:デフォルトの名無しさん
08/05/23 17:18:34
>>643 = NEET

645:デフォルトの名無しさん
08/05/23 18:45:59
>>644
まだコード書けないのか。おまえ何でム板にいるんだ?

646:デフォルトの名無しさん
08/05/23 22:14:52
>>644


647:デフォルトの名無しさん
08/05/23 23:20:15
>>646
>>645

648:デフォルトの名無しさん
08/05/24 01:29:24
>>648

649:デフォルトの名無しさん
08/05/24 06:13:08
また、自分でコード書けないいつものバカが暴れてるのか。

650:デフォルトの名無しさん
08/05/24 10:37:07
ぼかしの高速化について質問です。
現在ガウスぼかしの処理を書いてるのですが、640x480範囲5で1枚あたり0.5秒もかかって
しまい、非常に遅いです。一応1次元に落としてはいるのですが、重み付きぼかしの場合、
通常のぼかしのように処理済みのピクセルの結果を流用することができないため、どう
計算量を減らすのかわかりません。
SSEも見様見真似で使ってみましたが、アルファ加重なしで40%高速化、ありではSSEなしと
同じ速度でした。これはたぶん書き方が悪いのだとは思いますが…
なにか参考になるところ、もしくは検索キーワードをいただければうれしいです。
よろしくお願いします。



651:デフォルトの名無しさん
08/05/24 10:48:04
例えば5x5ピクセルを参照して1ピクセルの値を求める場合。
計算上問題がなければ、縦5ピクセルx横1ピクセルの加重平均を横一列分計算して、
次にその結果の横5つを加重平均するようにすれば多少は処理を減らせる。

まあ、それでもぼかしって基本的に参照するピクセルが多くなりがちだからそうそう高速化は。

652:デフォルトの名無しさん
08/05/24 11:07:40
>>650
具体的に、0.5秒かかっているときのカーネルの大きさ(or ガウシアンの標準偏差)はどれくらい?

653:デフォルトの名無しさん
08/05/24 11:10:32
GPU使っちゃダメ?10倍以上速くなると思うけど。

654:デフォルトの名無しさん
08/05/24 11:20:24
質問です。
例えば下のような図があったときに、1〜11のそれぞれ領域を、
隣接する他の領域と異なる色で塗り分けるプログラムを作りたいのですが、
各領域の色を決定するアルゴリズムにはどういうものがありますか?

     〈`ー─-、_ノ^j
      `>     <__, ─-、____
     /            j         / ̄ ̄ ̄Tー‐─┬''⌒ヽー-- 、
    r'            /、   1   /      |  5   | 7  |    |9
    └---─、        /  ` ー─/   3   |    │    |    l |
            \    /       /     ┌┴─‐─┴┐ / 8  l |
          \  /   2   /ー─ ----l     6     |‐┤    l |
            V        /    4  └─‐─┘ |     l |
            し个 、   /                   |   ハ〈
                |  ` ーl─‐┬─----------─┬─イ´ ̄ヽヽヽ
              |   /ヽ  |             |   ハ    〉 〉 〉
                  |  /   | |                  |  / │ / 〈ノ
                | |   | |             | /  | /
             __/ |  __/  |10            __/  | __/  |10
               (__」 ゙ー-‐'           ゙ー-‐'(___」    人
                                            (__)
                                           (__)11

655:デフォルトの名無しさん
08/05/24 11:24:56
宿題は自分で考えましょう

656:650
08/05/24 11:54:39
>>651
とりあえずそうしているのですが、その結果が0.5秒です orz

>>652
5です。 10だと約1秒でしたので、カーネルサイズと比例関係になっていると思います。

>>653
GPUですか…
DirectXは全くさわったことがないのでそこから始めなければならないんですよね… orz
もしGPUを使うとしたらシェーダは自分で書かなければならないのでしょうか?

657:デフォルトの名無しさん
08/05/24 12:12:57
GPUはCG言語から扱えるのでは

658:デフォルトの名無しさん
08/05/24 12:15:13
CgよかBrookGPUの方がよくね?
いっそCUDAかCAL使うのも手だけど。

659:デフォルトの名無しさん
08/05/24 12:15:32
ageちゃったスマソ

660:デフォルトの名無しさん
08/05/24 12:29:26
URLリンク(tpot.jpn.ph)
速度比較のお試し程度ならこれで十分じゃない?自分で理解できた方が良いけどさ。

661:650
08/05/24 12:49:23
うーん、できれば古いPCでも動くように作りたかったのですが、計算量はこれ以上減らせる
見込みはないのかな… 周りとの平均をとる以上無理か orz

>>657,658
やっぱり自前でシェーダ書かなければ無理ですよね orz
というか、かなり大きめの画像(HD以上)も扱えるようにしたいのですが、テクスチャ作れますかね?

>>660
ありがとうございます。
見た感じなんかCとはちょっと違いますね。
大きくは違わないけどCのノリで行ったら痛い目見そうだ

662:デフォルトの名無しさん
08/05/24 13:07:29
単に広範囲をぼかすだけなら小さめのガウスぼかしを複数回かける手もある。
クォリティ下げていいなら移動平均にすれば大きくぼかしても負荷ほとんど増えないが。

663:デフォルトの名無しさん
08/05/24 13:18:35
広範囲で極端な精度を求めないならパスカルの三角形を繰り返してやれば
擬似ガウシアンだよな。

664:デフォルトの名無しさん
08/05/24 13:21:08
そのくらい単純な処理の場合、計算量を減らすよりも
キャッシュのヒット率を考えた方が速くなると思うよ。

665:デフォルトの名無しさん
08/05/24 13:24:31
OpenCVのガウスぼかしはCPUにしてはわりと速いと思う

666:650
08/05/24 17:51:01
遅くなってすいません。

>>662
移動平均ということはモーションブラーのようにちょっとずつずらして
いくつも重ねてレンダリングするということでしょうか?

>>663
調べてみましたが、これも良さそうですね。 あんまり見た目も変わらないですし。

>>664
基本的に全部のピクセルを順番に走査するのであまり変わらないような気もしますが…
そこまでキャッシュミスするものなのでしょうか?

>>665
OpenCVですか。 言葉は聞いたことがあるのですが、どんなものなのでしょうか?
ちょっと調べてみます。

667:デフォルトの名無しさん
08/05/24 18:27:49
ぼかしは、計算時間かかるから、0.5秒なら妥当だと思うけど。
ちなみに、ガウシアンカーネルをコンボリューションしているの?FFTしてから掛け算しているの?
一般的に、前者は遅い。

ぼかしくらいで、OpenCV導入することはないと思うけど、OpenCVのブラーはたぶん後者。
3次元でブラー掛けた時、FFT2回分の時間と同じくらいだった気がするので。


668:650
08/05/24 19:13:06
>>667
>>651のように縦横別々に分けて掛けてます。
この方法だとO(2n)になるのでFFTよりは速い(たしかO(nlogn)だったと思うので)のでは
ないかと思うのですが、どうでしょうか?


いろいろ試したところ、通常のぼかしやカーネルの小さいガウスぼかしを重ねがけするのが
結果的にも時間的にもいい感じなのでもうちょっと調べてみます。


次ページ
最新レス表示
スレッドの検索
類似スレ一覧
話題のニュース
おまかせリスト
▼オプションを表示
暇つぶし2ch

5355日前に更新/198 KB
担当:undef