画像処理スレッドその5

1 ：デフォルトの名無しさん：2005/09/26(月) 12:37:28

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

前スレ
画像処理その４
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

2 ：デフォルトの名無しさん：2005/09/26(月) 12:49:45

乙

3 ：デフォルトの名無しさん：2005/09/27(火) 00:57:53

4 ：デフォルトの名無しさん：2005/09/27(火) 01:01:59

>>前988
>このプログラムで使用しているフィルターは、色の違いを識別し
>て同一色と認められる色同士のつながりを考慮して平滑化します。

高周波除去に頼るから輪郭がぼやけて凡雑な処理が必要になる。
KL変換を使えばいいのに、そういうフィルタはマイナーだな('A`)

5 ：前988：2005/09/27(火) 01:19:12

>>4
どうもです。
前スレが終了したので、そのまま流されるかと思った。
ＫＬ変換、チェックします。

6 ：前スレ994：2005/09/27(火) 01:27:39

前スレの996と997は、974,979,981をちゃんと読んでくれ。
質問者は普通に合成するのは分かっている。
ユーザが任意のレイヤを合成した場合にどう処理するのか
聞いているんだよ。

俺の回答は「そんな処理に正解はないから好きにしてくれ」

7 ：デフォルトの名無しさん：2005/09/27(火) 01:29:03

996と997は同じ人だったorz
990と996だな。

8 ：デフォルトの名無しさん：2005/09/27(火) 01:34:28

デジタルフィルタみたいに、厳密な数学にこだわる面もあるにはあるけど、
画像処理って、わりと、
「作ったよ。数学的正しさ？　わかんない。
きれいに見えるから／ちゃんと認識するから／高速で動作するから／いいじゃん？」
が、通用する楽しくてありがたい世界だと思う。（皮肉じゃなくて本気で）

その反面、どうやっていいか分からないときには、悩むけどね。

9 ：デフォルトの名無しさん：2005/09/27(火) 04:22:34

>>8
それ皮肉で言うんだけどね(w。
現場のエンジニアだとそののりで良いけど、研究者でそれだとかなり痛いんだよな(w。
お前らは基本原理を探せよと、小一時間問い詰めたいやつらが多すぎ。

10 ：デフォルトの名無しさん：2005/09/27(火) 04:55:48

>>9
うん、確かに。商売なら、「役に立つからいいじゃん！」は最強だけど、
基礎研究すべき立場の人なら、収束性とか数学的安定性とか、
適用可能な問題の上限下限とか、いろいろ理詰めできちんとやって
欲しい。成果はありがたく使わせてもらうから。

11 ：デフォルトの名無しさん：2005/09/27(火) 08:43:54

>>1
おつかれちゃん！

12 ：デフォルトの名無しさん：2005/09/27(火) 11:07:01

流れからちょっと聞きにくいなと感じているんですが、教えて下さい。
暗い写真を明るくすると光源のせいか赤味を帯びてくるんで青味を増すといいかと
カラーバランスを試みています。調べると R,G,B を弄るようなので
ttp://www.geocities.co.jp/Milkyway/4171/graphics/002-4.html
を使ってみました。やってみると調整は出来ますが、試行錯誤になって難しい。
スライダ１本で青み<->赤味を動かせないかと思っていますが、どんなキーワードで
探せばやり方が分かるでしょうか。

13 ：デフォルトの名無しさん：2005/09/27(火) 11:22:15

えーと、単に RGB の R と B にある比率を掛けるだけでしょ。
画像の色成分に個別にアクセスする処理ならなんでも参考になる。グレイスケール
とか。

14 ：デフォルトの名無しさん：2005/09/27(火) 22:20:37 ID:0

画像処理その２

が、どうやってもみつかんない。どして？

15 ：12：2005/09/27(火) 23:11:34

>>13
レスをありがとうございます。スライダから得た値を赤の方だったら R に加えて
B から引き、青の方だったら逆にするよう組んで見ました。
単に R, B のみの計算では色セロファンを濃くするように変化します。
どう変化させればいいか他の例を調べながら試して見たいと思います。

16 ：デフォルトの名無しさん：2005/09/27(火) 23:22:51

基本的には、HSVに変換→Hueを調整→RGBに戻す
でいいんじゃなかろうか。

17 ：デフォルトの名無しさん：2005/09/27(火) 23:38:38

私はR⇔BじゃなくてR⇔Cでやったなぁ。つーか、Rを+2したらGとBを-1する感じで。
#勿論、Rを-2するときはG,Bを+1。

18 ：デフォルトの名無しさん：2005/09/28(水) 00:17:18

>>14
私も探してます。
前スレ 992氏のおかげで３は入手できました。

19 ：前すれ992：2005/09/28(水) 00:39:22

探したけど、うまくDATに落ちていないのか、何なのかよく分からなかった。
こういうのなら見つかったよ。ただし、途中で切れているのが残念。

画像処理その２
http://makimo.to/cgi-bin/dat2html/dat2html.cgi?pc2/2/tech/1054545005/

おまけ。
画像処理
http://makimo.to/2ch/pc2_tech/992/992671330.html

20 ：デフォルトの名無しさん：2005/09/28(水) 00:40:38

かちゅーしゃのログ 1054545005.dat ならあるが？
俺は逆に３が無いな

21 ：デフォルトの名無しさん：2005/09/28(水) 00:46:51

>>14,>>18
dat でも html でもないけど、
うｐろだドットネット（中物用）
upload10000032776.txt

22 ：デフォルトの名無しさん：2005/09/28(水) 00:50:36

ごみん。間違って消しちゃった。
upload10000032783.txt です。

23 ：デフォルトの名無しさん：2005/09/28(水) 01:08:23

>>22
ダウンしてみました。
これをどう利用すればいいのですか？

24 ：デフォルトの名無しさん：2005/09/28(水) 01:14:08

>>23
「画像処理その２」スレのテキストログだけど、何かおかしな所あった?

25 ：デフォルトの名無しさん：2005/09/28(水) 01:35:56

>>12
> 暗い写真を明るくすると光源のせいか赤味を帯びてくるんで

RGB ---> HSL L を調整 ---> RGB

こことか
http://junki.main.jp/delphigr/028Luminance.htm
http://junki.main.jp/delphigr/028Hue.htm

26 ：前スレ966：2005/09/28(水) 02:37:36

>>990
>>質問者は、複数のレイヤーの同時合成について言っているように見えるんだか？
「下のレイヤーと結合」は、前スレ994さんの説明にあるように、任意のレイヤをひとつ下のレイヤーと合成します。
「全レイヤーを合成してひとつにまとめる」ときは、表示するときと順番で合成するので、
似ても似つかないシロモノに画像が置き換わることはないです。

>>997
>>そもそも、２枚のレイヤーの合成でも、非線形演算なら
>>分配則や交換則、結合側が成り立たないから、逆順にはできないぞ。
逆順に出来る場合で合成したいときに使用します。
間違って意図しない結果になっても、Undoで戻せるので困ったことはないです。

>>6
>>俺の回答は「そんな処理に正解はないから好きにしてくれ」
透過率を含まない式から透過率を含む式の決め方でもあれば使いかったのですが、
結果がPhotoshopと同じになるように適当に決めてみます。

ありがとうございました。

27 ：デフォルトの名無しさん：2005/09/28(水) 04:03:01

おっしゃ、質問者が納得したところで次の話題カモーン！
以後、前スレ966にまつわるアルファブレンディングの話は禁止！

28 ：デフォルトの名無しさん：2005/09/28(水) 05:12:24

http://graphics.stanford.edu/papers/fourierphoto/
これどういうこと？

29 ：デフォルトの名無しさん：2005/09/28(水) 08:08:33

>>28
Fourier Slice Photographyの論文でしょ。
どういうこともなにも、読んだままだと思うけど。

30 ：デフォルトの名無しさん：2005/09/28(水) 08:11:07

離散コサイン変換について勉強していますが、
離散フーリエ変換との関連性が良く分からず難航しています。

↓例えばこちら
ttp://laputa.cs.shinshu-u.ac.jp/~yizawa/InfSys1/advanced/dct/

離散信号を係数に変換する行列が出てきますけど、
その中に平方根が出てくる理由がピンときません。
信号が対象形だから複素数の虚部は無視出来るとしても、
平方根は一体どこから…？

離散コサイン変換の式を載せているサイトは良く目にしますが、
背後にある理屈を載せているサイトがなかなか見つからなかったりします。

お勧めの解説サイトor書籍があったら教えてください。

31 ：12：2005/09/28(水) 08:59:37

>>16-17, >>25
レスをありがとうございます。
>>17 試してみました。青みが空色気味でこっちの方がいいですね。
画面から、この赤味ってのを指定して hue を取りだし補色を求めて、
赤味成分と補色成分の変更をやるってことかなと思っています。
>>16 明度だけは HSV でも可能にしてあるのですが、hue の調整はまだです。
単に hue の値を変えると色相環の周辺を動くようでちょっと違うかなとまだ
躊躇してました。
>>25 hue はやってませんが、同じことです。
しかしスライダがもう６本並んで、radio button も増えた。hue でまた増える。
色温度調整って例があるいいなと思ったりしてます。

32 ：デフォルトの名無しさん：2005/09/28(水) 14:10:00

ECCV投稿した人
手あげて！

33 ：デフォルトの名無しさん：2005/09/28(水) 18:03:11

>>30
ヒント：Unitary DFT

34 ：デフォルトの名無しさん：2005/09/28(水) 18:34:54

http://www2s.biglobe.ne.jp/~niitsuma/STLLCV/
試しにＵｐしてみたんだけど感想求む

35 ：デフォルトの名無しさん：2005/09/28(水) 21:24:17

>>24
テキストエディタで開いたんだけど、中身がバイナリっぽかったです。

36 ：デフォルトの名無しさん：2005/09/28(水) 23:27:06

lassoって実は凄い難しいのかな？
http://www.mainichi-msn.co.jp/shakai/wadai/news/20050928k0000m040137000c.html

37 ：デフォルトの名無しさん：2005/09/28(水) 23:47:36

>>30
ユニタリ変換にしとくと順方向も逆方向も同じ処理でできて好都合だからかな?
つーか、一口に離散コサイン変換って言っても数種類なかったかな?
昔ちょっと触れただけなんで覚えてないな～。

38 ：デフォルトの名無しさん：2005/09/28(水) 23:56:43

>>34
わーIPAの超人だ～キャッキャ(≧∇≦*)(*≧∇≦)pキャッキャいわゆるゴッドだ～キャッキャ(≧∇≦*)(*≧∇≦)pキャッキャ
なんか、興味分野も近いし～僕も研究がんばらなきゃ～でも才能の違いを感じるよなぁ（ﾊｧ･･･

39 ：デフォルトの名無しさん：2005/09/29(木) 01:40:07

>>35
すんません。文字コードを変換して下さい。
nkf とか qkc を通すか、Web ブラウザで文字コードを設定すれば見られます。

40 ：30：2005/09/29(木) 07:24:27

うげぇ、ユニタリですか…。その辺はさっぱり分かりません。
まだまだ力不足のようです。昨日紀伊国屋に行って痛感しました。

当分は基礎力養成に努めます。

41 ：デフォルトの名無しさん：2005/09/29(木) 07:53:59

「画像処理その２」の981まで（おそらく全部）のdatファイルが手元にあるんだけど、欲しい人いますか？

42 ：デフォルトの名無しさん：2005/09/29(木) 08:13:57

>>40
そんなに深く考えなくても、ひとまず、平方根と円周率の混ざった定数は、

「変換したものを逆変換したときに、もともとのデータと大きさが変わらないように、
変換結果や再変換結果を適当に定数倍して、ゲイン調整している」

くらいに思ってくださいな。

43 ：デフォルトの名無しさん：2005/09/29(木) 10:33:18

画像認識に関するスレはどこですか?

44 ：デフォルトの名無しさん：2005/09/30(金) 17:00:27

>>9
自分の閥でない人が成果を上げた場合も
同じこという

45 ：デフォルトの名無しさん：2005/09/30(金) 17:11:17

画像フォーマットの質問もこちらでいいのでしょうか？
PNGについて質問なのですがフィルターのパラメーターで0を指定しても
内部では5種類ぐらいフィルターが用意されてそれが使われてるらしいですが
どうやってフィルーターを指定するのでしょう。

46 ：デフォルトの名無しさん：2005/09/30(金) 20:07:25

>>45
どうやって指定しているかというのが方法のことなら、
圧縮前のscanlineの各列冒頭に1バイトを追加して
そこにフィルター番号を指定する。

47 ：デフォルトの名無しさん：2005/09/30(金) 20:54:37

>>44
画像処理研究してる人たちってみみっこいね。

48 ：マイク ◆yrBrqfF1Ew ：2005/09/30(金) 21:48:22

笑い男って何だ？

49 ：デフォルトの名無しさん：2005/09/30(金) 23:29:15

>>47
画像処理にかぎらねぇべさ。

50 ：デフォルトの名無しさん：2005/10/01(土) 23:27:20

>>48
今や、懐かしささえ覚える単語だな。

51 ：デフォルトの名無しさん：2005/10/03(月) 20:13:48

>>45,46,49
少なくとも
人工知能　と　物理　は同じ雰囲気だった
生物もそうっぽい

多分他の分野も研究の世界は同じだと思う

52 ：デフォルトの名無しさん：2005/10/04(火) 10:05:04

>>51
門外漢だが、学科別のドクターになる人数の推移などと相関はない？

繰り返し実験が出来る、よい計測機器が次々に出ている、試料試薬が出ている
などにより、無人の荒野を行くがごとく論文が書ける分野はおおらかだと思う。

他人に見えないものを見るため計測器から作るって時代もあったが、今はスピ
ードの時代でそんな悠長な人は少ないのかな。

53 ：デフォルトの名無しさん：2005/10/06(木) 01:40:29

画像処理関係で就職するならどこですかね？

54 ：デフォルトの名無しさん：2005/10/06(木) 01:50:40

>>53
凸版とか大日本印刷とか。
ジャンプを木曜に読めるよ。

55 ：デフォルトの名無しさん：2005/10/06(木) 02:12:35

大日本印刷で音声の研究していて有名な人がいるのを思い出した。

56 ：デフォルトの名無しさん：2005/10/06(木) 03:09:36

　　ﾎﾟｯﾎﾟｰ
　　(　⌒　)
　　　l | /
　　
⊂（#・д・）　理論だとか実装だとか！
　/　　　ﾉ∪ 　もうやってらんないっすよ！
　し―-J　|l| |　　　
　　　　　人ﾍﾟﾀﾝｯ!! 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　（＿）　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　）（＿＿）（_　　　　　　　　　　　　　　　　　　　　　　　　
　　　　⌒）　　　（⌒　

57 ：デフォルトの名無しさん：2005/10/06(木) 18:06:37

この板はエンドユーザ向きではないよ

58 ：デフォルトの名無しさん：2005/10/06(木) 20:28:28

パターン、形状認識をする良い方法って無いでしょうか。

59 ：デフォルトの名無しさん：2005/10/06(木) 23:15:44

>>58
そりゃ、料理をつくる良い方法ってないでしょうか。と、同じくらい漠然とした質問で
誰にも答えることができないよ。

60 ：デフォルトの名無しさん：2005/10/07(金) 16:15:26

>>58
OpenCVのパターン認識関数で終わり

61 ：デフォルトの名無しさん：2005/10/07(金) 16:45:56

オプティカルフローを求めたいのですが、計算式だけだとイメージがつかめないので
どこかにサンプルコードが落ちて無いですか？

62 ：デフォルトの名無しさん：2005/10/07(金) 18:39:57

動画(aviかmpg)を読み込みフレームごとキャプチャして静止画にすることなんて
できますか？そのようなアプリケーションを探しているのですがないので
自作しようと思っています。

63 ：デフォルトの名無しさん：2005/10/07(金) 22:07:05

このスレに無関係な話題だが、
普通の動画編集ソフトなら大抵は出来る。むしろ出来ないものを探すのが難しい。
例：AviUtl, VirtualDub, Avisynthその他商用ソフトいろいろ。

64 ：デフォルトの名無しさん：2005/10/08(土) 10:54:51

どうもです。ソフト作るの初心者ですが自作もできますかね？

65 ：デフォルトの名無しさん：2005/10/08(土) 12:02:26

出来ないとは言わないが、
いつになったら出来上がるかは未知数だな。
一々作り方をここで聞くつもりなら、出来ないと思った方がいい。

66 ：デフォルトの名無しさん：2005/10/08(土) 15:57:49

DirectShow使えばすぐできる。
ttp://www.geekpage.jp/programming/directshow/getcurrentimage.php

67 ：デフォルトの名無しさん：2005/10/08(土) 17:07:57

そりゃソース提示すりゃだれでもできるだろ。

68 ：デフォルトの名無しさん：2005/10/10(月) 22:26:42

すみません、hough変換についてちょっと教えて欲しいのですが・・・

hough変換の処理を高速化するのに適した手法にはどの様なものが
あるのでしょうか。できればその手法の原理なども教えて下さい。

あと、hough変換には色々手法があると思いますが、一般的に使用されている
のはどういったものなのでしょうか。差し支えなければ御教授願います。

69 ：デフォルトの名無しさん：2005/10/10(月) 23:48:46

手法としては「直線を局座標に変換して、角度θと距離ρの空間で投票を行う」（フルスクラッチによる(ｒｙより）

高速化に関しては「三角関数をテーブル展開」（同上）

70 ：デフォルトの名無しさん：2005/10/11(火) 01:23:42

hough変換でぐぐったら、一杯親切な解説がヒットするが読んで見た？

71 ：デフォルトの名無しさん：2005/10/11(火) 05:33:46

>>69
ありがとう御座います^^この本欲しいですが、
在庫切れのところばかりですね・・・

>>70
はい。一応googleで検索してhitしたのは読みました。
ですが処理を高速化するための方法(例えばθ-ρパラメータ平面の2次元
配列を1次元配列で代用する方法や、一般化hough変換等)について
詳細に述べている処が無かったので教えを請いました。

72 ：デフォルトの名無しさん：2005/10/11(火) 06:54:43

hough変換はエッジ点をθ-ρ平面にプロットするのに
時間がかかるよね　画像の解像度落としたり
エッジ点をうまく減らせば速くなると思う
俺的にはエッジの方向も使ってθのプロット範囲を限定
するのがおすすめ

73 ：68：2005/10/11(火) 13:22:54

>>72
それは一般化hough変換の様な2点(参照点と任意点)がなす角度と
距離,エッジの接線を求めて参照点を検出する方法で、θのプロット範囲
を限定する、っていうことですか？

74 ：72：2005/10/11(火) 14:02:45

一般化hough変換はよく分からんけど
エッジ方向とは画像fの濃度勾配方向 atan(fy/fx)です。
エッジ方向を９０度回転させた方向に抽出輪郭が通るべきだから
その範囲にθを限定する。

75 ：68：2005/10/11(火) 14:35:54

>>74
成る程、確かにこれなら範囲が大分狭められて
高速処理できそうですね。
今からその辺を考えてちょっとプログラム組んで見たいと思います。
有難う御座いました

76 ：デフォルトの名無しさん：2005/10/11(火) 17:44:13

http://www2s.biglobe.ne.jp/~niitsuma/STLLCV/
たいした内容じゃないけど、約に立つだろうと思って公開したけど
使ってもらうにはドキュメントと例が抜けてたので追加しました。

77 ：デフォルトの名無しさん：2005/10/11(火) 20:04:41

恐縮です。
大変助かります

78 ：デフォルトの名無しさん：2005/10/11(火) 21:55:01

画像の傾き補正を行う方法はどんな物があるでしょうか。
どの角度に回転していても、同一の画像を出力出来るようにしたいんです。
photoshopなんかだと直線成分を元に補正するみたいですが、
直線の無いような絵でも自動的に補正したいんです。

絵の重心を求めて、中心と重心の角度を一定にするように回転させる事で出来るかと考えたんですが、
重心が中心に近いと全然ダメだったり、ノイズに非常に弱くて困っています。
何か良い方法は無いでしょうか。

79 ：デフォルトの名無しさん：2005/10/11(火) 23:06:31

>>78
まず傾き検出と傾き補正を分けて考えるべきではないかと

80 ：デフォルトの名無しさん：2005/10/12(水) 02:03:51

同一の絵なら、実際に回転させて基準絵とだいたい一致すればOKでいいじゃない、とか。
円グラフのように、画像中心から5度毎に情報の偏りを求めて、とかなんとか。

81 ：デフォルトの名無しさん：2005/10/12(水) 13:26:05

rotate invariant feature

82 ：デフォルトの名無しさん：2005/10/12(水) 14:04:09

オプティカルフロー、、誰か・・・。
どんなアルゴリズムなのかさっぱりわからんです。
周辺画素の探索したり、時系列探索したりとかですか？

83 ：デフォルトの名無しさん：2005/10/12(水) 18:13:26

本を一冊買うとかしないもんなのか・・・

84 ：デフォルトの名無しさん：2005/10/12(水) 19:53:13

Optical Flow でググると色々見つかりますけど・・・

85 ：デフォルトの名無しさん：2005/10/13(木) 07:53:29

上にhough変換やら傾き補正やらの質問が出てるので便乗したいんですが、
格子模様をカメラで撮って、その画像の傾きをhough変換で検出するとき
って、格子模様の一つの横線についてのみ考えれば良いんですかね？

86 ：デフォルトの名無しさん：2005/10/13(木) 08:18:43

カメラキャリブレーションならなるべく多くの信頼できる
画像特徴を抽出して最小二乗法で推定したほうが良い
そのために格子がいくつかある

87 ：デフォルトの名無しさん：2005/10/13(木) 10:22:05

ベクトル量子化のコードブックの生成について詳しく説明しているサイトを教えていただけないでしょうか？
ぐぐったんですが、わかりにくいところや説明が省略されているところばかりでした。
お願いします

88 ：デフォルトの名無しさん：2005/10/14(金) 08:41:49

ベクトル量子化何度目だ･･･。

89 ：デフォルトの名無しさん：2005/10/14(金) 09:32:56

何度も課題に出す先生がいるのかも

90 ：デフォルトの名無しさん：2005/10/14(金) 09:59:21

最近の大学には図書館が無いのか？

91 ：デフォルトの名無しさん：2005/10/14(金) 10:20:55

図書館があることすら知らんのだろう

92 ：デフォルトの名無しさん：2005/10/14(金) 11:37:11

図書館で本を読んだのですが、どうも理解できなかったので
わかりやすい説明のされたものを探しております。
何かないでしょうか？

93 ：デフォルトの名無しさん：2005/10/14(金) 12:20:29

>>92
何についてわからなかったの？
ピンポイントで質問すれば答えて貰えるかもよ。

94 ：デフォルトの名無しさん：2005/10/14(金) 12:22:10

よくわかるベクトル量子化
http://www.amazon.co.jp/exec/obidos/ASIN/4198617651/250-7665984-0484200

95 ：デフォルトの名無しさん：2005/10/14(金) 13:49:45

>>94
おぉ、いいねこれ。さっそく注文した。

96 ：デフォルトの名無しさん：2005/10/14(金) 14:28:05

みなさんありがとうございます。

コードブックの生成アルゴリズムがよくわかりません。
k-meanアルゴリズムやLBGアルゴリズムです。
本やWEBにもこの説明について書かれたものはあるのですが、
私の能力不足でよくわからない状態です。

97 ：デフォルトの名無しさん：2005/10/14(金) 16:34:11

オートホワイトバランスってどのようなアルゴリズムで実現するのでしょう？

98 ：デフォルトの名無しさん：2005/10/14(金) 16:43:54

>>97
画像全体の平均がグレーになるようにするってのが最も単純なAWB

99 ：デフォルトの名無しさん：2005/10/15(土) 08:32:56

>>96
まじ？君頭大丈夫？
それぞれのどこがわからないの?

100 ：デフォルトの名無しさん：2005/10/15(土) 08:58:46

まさか平均、分散、ベクトルとかの数式、要するに高校数学が理解できんとか言うんじゃなかろうな？

101 ：デフォルトの名無しさん：2005/10/15(土) 11:16:12

96です。
自分ではk-meanアルゴリズムは、
例えば、8＊8の画像（RGB形式）があったとします。ここではベクトルを1*1と考えた場合、
64ベクトルあると考えられます。
で、この64ベクトルを32ベクトルにしたい場合（コードブックの作成）、
64ベクトルの中でもっとも近いベクトル同士をくっつけて、その重心をとります。
二つのベクトルを一つのベクトルにするわけで、その結果まずは63ベクトルになります。
これを繰り返して32ベクトルまで減らし、これをコードブックとして採用し、符号化するときに
使います。
この考え方であっているんでしょうか？

102 ：デフォルトの名無しさん：2005/10/15(土) 12:09:00

>>98
それだけだとかなり単純なように聞こえるのですが、例えば、デジカメでもAWBの精度の良いものと悪いものでは
かなりの差が出ますが、このアルゴリズムだけでは、うまくいかないことも多いのでしょうか？
他にどのような処理をしているのでしょうか？

103 ：デフォルトの名無しさん：2005/10/15(土) 12:42:14

>>101
全然違うような気がするんだが、
全然違いすぎていて気味が悪いな。
俺が間違ってんの？

104 ：デフォルトの名無しさん：2005/10/15(土) 13:52:52

101は階層的クラスタリングとしても気持ち悪い書き方だな。

105 ：デフォルトの名無しさん：2005/10/15(土) 18:05:32

>>101
つっこみがいのある文章だけど、イメージとしては多分あってると思われ。

106 ：名無し募集中。。。：2005/10/15(土) 20:49:52

中央付近でWBとるのと、周辺でWB取るのでは違う結果になるからね

107 ：デフォルトの名無しさん：2005/10/15(土) 21:35:50

101です。みなさんありがとうございます。

>>103
よければ教えていただけないでしょうか

>>104
文章表現がおかしいといわれることが多々あるのですみません

>>105
イメージはあっているとのことですが、細かいところはどうでしょうか？
重点を取るというのはベクトルとベクトルの真ん中ということでわかります。

例えば101の例ででてきた画像を仮にAとします。
次のBという画像でも同じように32ベクトルを生成します。

このAとBのそれぞれ32ベクトル（二つあわせて64）をひとつにしたいときは101と同様に
64を32まで減らすという方法でよろしいのでしょうか？
それともAとBのベクトル（それぞれ64ベクトル）をまず足しあわせて128にしたあと
32まで減らすという方法なのでしょうか？
この二例だと微妙にコードブックが変わってくると思っていて、疑問に感じております。

108 ：デフォルトの名無しさん：2005/10/15(土) 21:55:11

>>107
>この二例だと微妙にコードブックが変わってくると思っていて、疑問に感じております。

統計的に性質の異なる画像だとコードブックが変わるのは当然で、それぞれに対して最適なコードブックは異なるのが普通。
動画の圧縮では各フレーム毎にコードブックの更新が行われる(ビットレートに収まるようにね)。

109 ：デフォルトの名無しさん：2005/10/15(土) 23:09:11

>>108
ありがとうございます。
言葉足らずでした。109のAとBというのは連続フレームの二枚のことです。
ですので、各フレームごとにCBの更新を行うのではなく、その二枚からCBを作るときには
どうしたらいいのかということがわからい状態です。
（AでCBを、BでCBを作って、その二つをまとめるべきなのか。
それとも、AとBをまとめてからそのCBを作るのか）

110 ：デフォルトの名無しさん：2005/10/15(土) 23:10:45

109の追加で
連続フレームの定義としては、例えば動画だと1秒に30フレームなどの場合が在ると思いますが、
そのときの連続したフレームなので、画像としてはほとんど違いがありません。時系列にそったデータということです。

111 ：デフォルトの名無しさん：2005/10/16(日) 00:36:26

>>102

>>106みたいに平均するエリアを変えるとか、
複数のエリアで重み付けするとか、
輝度の極端に高いところや低いところをカットするとか、
色がグレーから大きく外れたところをカットするとか、
やり方はいろいろある。

もっと賢いやりかたも知ってるけど守秘義務があるので書けん。自分で工夫汁。

112 ：デフォルトの名無しさん：2005/10/16(日) 03:50:27

>>102
そこから先は、ノウハウの世界。

そもそも撮影対象が何かという点で、条件は変わる。そして、
何の色味を死守し、何についてはあきらめる、という判断基準は用途しだいだし、
光源の変動範囲をどのくらいに見積もるかも設計者が決めなきゃいかんわけで、
「こうすれば大丈夫」という万能薬はない。

例えば光源が黒体放射に限られるなら、「緑だけが強くて赤と青は弱い」なんて
光源はありえないから、たとえ画面全体を積分したときに緑成分が強くても、
それはたまたま緑色のものが画面いっぱいに写っているというだけであって、
それは光源に由来するホワイトバランスのずれとして補正するのは間違いである
可能性が高い。

一方、もし照明に蛍光灯も使う可能性があるなら、緑が強く出るのは照明の
せいかもしれないから、ホワイトバランスの補正の対象になりうる。

こればっかりは、自分が撮影する可能性のあるものと撮影条件をもとに、
自分で設計するしかないよ。

113 ：30：2005/10/16(日) 18:27:15

以前離散コサイン変換について質問したものです。
>30
一応、平方根が使われる理由については理解できました。

同じ分野でもう一つ質問したい事があるのですが、
↓例えばこちらに
http://uchikawa-www.ip.titech.ac.jp/~masuda/J/memo/signal.html
＞鏡像信号をつなげた2倍周期の信号のフーリエ変換に等しい

という一文があります。言うまでも無く離散コサイン変換の説明ですけど、ここで述べられている「2倍周期の信号」について。

例えば
f(0)=1 f(1)=2 f(2)=3 f(3)=2 f(4)=1
という要素数（N）が5の信号f(x)があるとします。
ここで鏡を使ってf(x)の2倍周期信号f'(x)を作るとしたら、
①
f'(0)=1 f'(1)=2 f'(2)=3 f'(3)=2 f'(4)=1
f'(5)=1 f'(6)=2 f'(7)=3 f'(8)=2 f'(9)=1
N=10
という信号になるのか、それとも他の信号
②
f'(0)=1 f'(1)=2 f'(2)=3 f'(3)=2 f'(4)=1
f'(5)=2 f'(6)=3 f'(7)=2 f'(8)=1
N=9
のような形になるのかが分かりません。

f'(x)の具体的な形を教えて貰えないでしょうか。

114 ：デフォルトの名無しさん：2005/10/16(日) 18:35:37

そのページ見ただけでも0次の不連続性を無くすんだから
②だって推測可能だが、一応張っとく。
ttp://momonga.t.u-tokyo.ac.jp/~ooura/fftman/ftmn2_3.html#sec2_3

115 ：30：2005/10/17(月) 08:01:16

レスありがとうございます。
うーん、やはり②ですか。

＞そのページ見ただけでも0次の不連続性を無くすんだから

①でもf'(9)==f'(0)だからf'(9)とf'(0)の間は無理なく繋がる。
だから連続信号じゃん、って事で①、②共に０次の不連続性を無くした
信号だと思っていました。

しかし根本的に理解が間違っていたようですね。
連続信号の解釈が間違っているのか…。もうちょい勉強します。

116 ：デフォルトの名無しさん：2005/10/17(月) 10:07:34

>>109
あんた、前に同じこと質問してない？

117 ：デフォルトの名無しさん：2005/10/17(月) 19:08:05

>>115
>f(0)=1 f(1)=2 f(2)=3 f(3)=2 f(4)=1
この関数の形が問題なんだな。
f(4)=4で考えてみれば①じゃ
①
f'(0)=1 f'(1)=2 f'(2)=3 f'(3)=2 f'(4)=4
f'(5)=1 f'(6)=2 f'(7)=3 f'(8)=2 f'(9)=4
でx=4とx=5、x=9とx=10で不連続にしかならないんで変な高周波成分が出る。
②は省略。言わずもがなだしね。

118 ：30：2005/10/18(火) 11:51:47

>>117
レスありがとうございます。
ひょっとしたら設問の悪さから、
妙な誤解を与えていたかも知れません。

>>f(0)=1 f(1)=2 f(2)=3 f(3)=2 f(4)=1
>この関数の形が問題なんだな。
>f(4)=4で考えてみれば

仰る通りにf(4)=4で考えてみて、
①
f'(0)=1 f'(1)=2 f'(2)=3 f'(3)=2 f'(4)=4
f'(5)=4 f'(6)=2 f'(7)=3 f'(8)=2 f'(9)=1
N=10
と
②
f'(0)=1 f'(1)=2 f'(2)=3 f'(3)=2 f'(4)=4
f'(5)=2 f'(6)=3 f'(7)=2 f'(8)=1
N=9
ならどちらが離散コサイン変換の2倍周期信号として適切？　
と言うのが質問の趣旨でした。

これなら如何でしょうか…？

119 ：30：2005/10/18(火) 11:59:42

改めて見ると最初の設問最悪ですね…。
信号を折り返しても、０から繰り返しても同じ形だなんて（汗）
申し訳ありません。

120 ：デフォルトの名無しさん：2005/10/20(木) 08:31:08

Exifのタグ名などが日本語で記述されたインターネット上で入手できる文書はありませんか？

121 ：デフォルトの名無しさん：2005/10/20(木) 10:11:16

>>120
http://park2.wakwak.com/~tsuruzoh/Computer/Digicams/exif.html

122 ：デフォルトの名無しさん：2005/10/20(木) 18:36:45

画像処理本来の問題ではないのですが、こちらの方が分かるかと参りました。
dialog の preview 欄に画像を StretchDIBits() で表示していて、一方
明度などの変更をスライダで受けて WM_HSCROLL で変更を広い、明度計算して
preview 欄を update しています。ところが、前の update が終わらない
うちに次の update を出すと、StretchDIBits() が失敗しているようです。
global 変数で BOOL busy; を置いて StretchDIBits() の前後でオンオフし
WM_HSCROLL で受け付けないようにしていますが、スライダが空走している
ような感じになり不自然です。みなさん、どうしていますか。
（サイズの小さい写真などでは追随しているようですが、大きくなるとダメみた
　いです。自分で小さい DIB を作って送り込むとかもしましたが、遅くなり
　ますので、StretchDIBits() は捨てがたいと思っています。）

123 ：デフォルトの名無しさん：2005/10/20(木) 20:15:09

Win32APIスレ池
画像処理と全然関係ない。

124 ：名無し募集中。。。：2005/10/20(木) 23:15:00

ダイアログの表示はすべてOnPaintで描画すればよろしい

125 ：120：2005/10/21(金) 16:50:59

>>121
ありがとうございます。
しかしながら、残念ながらこのサイトもXResolutionなどタグ名は英語なので・・・

126 ：デフォルトの名無しさん：2005/10/21(金) 17:08:06

>>125
つ[英和辞典]

127 ：デフォルトの名無しさん：2005/10/22(土) 14:44:37

キャリブレーションってなんですか？

128 ：デフォルトの名無しさん：2005/10/22(土) 15:03:45

規格や基準に整合するよう電子回路を調整すること

129 ：デフォルトの名無しさん：2005/10/22(土) 16:13:48

つ[較正]

130 ：デフォルトの名無しさん：2005/10/22(土) 18:34:14

比例ってこと？

131 ：デフォルトの名無しさん：2005/10/22(土) 18:44:51

>>130
頼むから相手に伝わるように質問してくれ。

132 ：デフォルトの名無しさん：2005/10/22(土) 22:02:49

>>131
小選挙区では苦しいっていうことですか？

133 ：デフォルトの名無しさん：2005/10/23(日) 00:20:23

苦しいですね。

134 ：デフォルトの名無しさん：2005/10/23(日) 00:22:52

こりゃドイツしかないかもしれんね

135 ：デフォルトの名無しさん：2005/10/23(日) 00:23:54

選挙って縮小ですよね？

136 ：デフォルトの名無しさん：2005/10/23(日) 02:05:00

いや絶対オランダ

137 ：デフォルトの名無しさん：2005/10/24(月) 21:45:25

level setってどうよ

138 ：デフォルトの名無しさん：2005/10/25(火) 17:01:46

教えてください。

フォトショ（5.5）のイメージ→色調補正→明るさ、コントラスト

で入力された値が画素にどのように作用しているか処理の
資料（数式だとありがたいです）をお持ちの方は居られませんか？

書籍やリンクなどでも構いませんのでよろしくお願い致します。

ageさせていただきます。

139 ：デフォルトの名無しさん：2005/10/25(火) 22:36:44

PhotoShopのそれは知らんが、PaintShopProのそれならこの前調べた。
ついでに言えば、LeadToolProのそれは変態入ってた(ぉぃ

140 ：デフォルトの名無しさん：2005/10/25(火) 23:12:22

一般論なら分かるが特定のアプリの機能はリバースでもしないとわからんね。

141 ：デフォルトの名無しさん：2005/10/25(火) 23:13:30

>>139
レスどうも

パラメータいじってカラー拾えば大体見当は付くのですが、
イマイチ挙動不審なところがあってそこが分からんのです。

142 ：デフォルトの名無しさん：2005/10/25(火) 23:22:39

>>141
0-255のグレイグラデーション作って、調整したらスポイトで濃度値確認。
これを只管繰り返すw

143 ：デフォルトの名無しさん：2005/10/26(水) 01:01:23

>>142 >>140
まあそんな感じにしました

144 ：138：2005/10/26(水) 12:25:00

また質問に来ました。

一般的にコントラストの明暗の切り替えを行う分岐点（輝度）って、
どうやって算出するのでしょうか？

全ピクセルの輝度の平均より明るいところはより明るく、
暗いところはより暗く、ってやるとそれっぽくなるのですが、

セオリーとしてこうだ、というのは無いでしょうか？
ご存知の方お願い致します。

145 ：デフォルトの名無しさん：2005/10/26(水) 17:55:33

すみません、我侭な質問ですが・・
RGBの値がそれぞれ与えられていて
そこから色合い、鮮やかさ、明るさの値を算出するには、どのようにRGBの値を弄ればいいでしょうか
参考サイトがあると嬉しいのですが..

146 ：デフォルトの名無しさん：2005/10/26(水) 17:59:07

>>145
Google RGB HSV 変換式

147 ：デフォルトの名無しさん：2005/10/26(水) 18:00:55

>>145
http://www.google.co.jp/search?hl=ja&c2coff=1&q=rgb+hsl+%E5%A4%89%E6%8F%9B&lr=lang_ja

148 ：デフォルトの名無しさん：2005/10/26(水) 18:25:27

>>146
>>147
有り難うございます、勉強してきます

149 ：デフォルトの名無しさん：2005/10/26(水) 23:15:27

>>144
明度の計算なんぞで面白い（VBだけど）ソースがある。
ttp://www.geocities.co.jp/Milkyway/4171/graphics/

150 ：その4のどっか：2005/10/26(水) 23:56:07

>149のサイトのHSB/RGB変換、私が「自分で当たりをつけて作ってみた」ロジックと同じ模様。
「なんか腑に落ちない」と書いたのだけど、同じアルゴリズムが出てきて一安心w

その他の処理も、私がやってることと似ていてなんとなく共感。

151 ：138：2005/10/28(金) 09:56:11

>>149
どうもです。参考になりました。

フォトショの明暗の切り替えも画素の値を拾って見たところ、
>149のサイト同様、中間地点で決め打ちでやってるみたい
です。

152 ：デフォルトの名無しさん：2005/10/28(金) 10:44:30

つーかそのサイト、PhotoShopを前提としていないか?

153 ：149：2005/10/28(金) 14:10:34

>>152
そうなの？　もう一辺よく見よう。

154 ：30：2005/11/01(火) 14:11:34

離散コサイン変換：
ttp://www.mm.media.kyoto-u.ac.jp/education/DIP/imageproc_fourier.pdf

↑ここが参考になった。
cos( πk(2i+1)/2N )中、（2i+1）の意味が分からなかったのだが、
ようやく分かりかけてきた。

報告まで。

155 ：デフォルトの名無しさん：2005/11/01(火) 14:54:10

画像認識についてのいい参考書ない？

156 ：デフォルトの名無しさん：2005/11/01(火) 15:57:00

>>155
"画像認識"って一口に言っても結構広い範囲含んじゃうよ。
もうちっと絞り込んで具体的に聞いた方がいいのでは?

157 ：デフォルトの名無しさん：2005/11/01(火) 21:34:37

bitmapならファイルフォーマットがわかるから、独自の関数を作れるんだけど。
ＪＰＥＧはぜんぜんわからん。もうこれは本家のライブラリ引っ張ってくるしかないの？

158 ：デフォルトの名無しさん：2005/11/01(火) 22:42:09

別に他のライブラリでもいいんじゃないの。
VCLとか。
imgctl.dllとか。

159 ：デフォルトの名無しさん：2005/11/01(火) 23:44:19

つ[libjpeg]
つ[ImageMagick]
つ[LeadToolPro]

160 ：名無し募集中。。。：2005/11/02(水) 01:35:16

画像の読み込みはsusieプラグイン使ってるよ

161 ：名無し募集中。。。：2005/11/03(木) 01:24:30

OpenCV LINUX 0.9.7　をインストールして
使ってみようとしたのですが　doc を見たところ
疑問に思ったことがあったので、分かる方がいらしたら
ご教授ください。

・POSIT　て関数の意味が分かりません。何に使うんですか？
・ステレオ視の対応点探索の関数は、無いのでしょうか？

162 ：デフォルトの名無しさん：2005/11/03(木) 04:18:14

>>161
POSIT : 特徴点位置が既知な物体を撮影した画像から物体の向き位置を推定する関数群？だったと思う。
わかり難い説明文ですまん。使ったことないからよく知らない。

ステレオ : 一つ前のバージョンにはDPで対応付けする奴があったけど、無くなったくさい？オレも困ってるんだけど。
前のバージョンの奴はレンズの歪みとかホワイトバランスの不一致があると対応付けがうまくいかないことが多くて実際あんまり使えないんだよね。
高速で、そこそこ使えるステレオマッチングアルゴリズム知ってる？
オレもいろいろ調べてるんだ。

163 ：デフォルトの名無しさん：2005/11/04(金) 23:46:05

http://www.ces.clemson.edu/~stb/klt/

164 ：デフォルトの名無しさん：2005/11/06(日) 16:01:39

>>163
点で対応付けて三角パッチで補完するってか。
補完作業はVGAで高速にやれるしね。

他に候補無いかね。

165 ：163：2005/11/06(日) 16:15:19

岡大の金谷せんせの所でされてるみたいね。

166 ：デフォルトの名無しさん：2005/11/06(日) 16:16:19

<日記>
163と164番号間違えた。
</日記>

167 ：デフォルトの名無しさん：2005/11/07(月) 11:28:31

OpenCVのcvauxあたりのヘッダ眺めてたら
// Name: cvFindStereoCorrespondence
// Purpose: find stereo correspondence on stereo-pair
// Context:
// Parameters:
// leftImage - left image of stereo-pair (format 8uC1).
// rightImage - right image of stereo-pair (format 8uC1).
// mode - mode of correspondence retrieval (now CV_DISPARITY_BIRCHFIELD only)
// dispImage - destination disparity image
// maxDisparity - maximal disparity
// param1, param2, param3, param4, param5 - parameters of algorithm
// Returns:
// Notes:
// Images must be rectified.
// All images must have format 8uC1.
ってのが有ったけど、これってステレオマッチングの関数じゃないのかね？

168 ：デフォルトの名無しさん：2005/11/07(月) 12:20:02

画像の各種拡大アルゴリズムが載っているページか本を教えてください

169 ：デフォルトの名無しさん：2005/11/07(月) 17:17:17

>>168
まず、ググレ。

170 ：デフォルトの名無しさん：2005/11/07(月) 17:32:58

ぐーたらここにつきました

171 ：デフォルトの名無しさん：2005/11/07(月) 20:27:10

>>168
ttp://www.amazon.co.jp/exec/obidos/ASIN/4789833992/
各種と言っても3つくらいだったと思うが。

172 ：デフォルトの名無しさん：2005/11/07(月) 20:43:26

>>171
いや、周波数空間に持っていってとか、
アップサンプリング+アンチエイリアシングとかも入れると、
微妙にいろいろ増えるけど。

その先生、教授になったんだね。一度講演を聞いたことがあって
結構分かりやすかった。でも資料(書籍)は細かいミスがあるので、
二版以降がお勧め。

173 ：デフォルトの名無しさん：2005/11/08(火) 13:16:37

今さらだが、『フルスクラッチによるグラフィックスプログラミング入門』は、
どうやら増刷がかかったらしい。アマゾンで注文できるようだ。

しかし、ちょっと高いなぁ・・・　図書館に購入申請でもしようか。

174 ：デフォルトの名無しさん：2005/11/08(火) 18:07:43

>>172
171で紹介した本に載っているのが3つくらいってことね。

175 ：デフォルトの名無しさん：2005/11/08(火) 19:07:27

市販の拡大印刷ソフトの印刷結果をショップで見たことあるけど
あんなに拡大してもモザイクっぽくならないのねぇ。

176 ：デフォルトの名無しさん：2005/11/09(水) 15:16:45

あの…質問なんですが
画像を拡大させるときに順変換ではなく逆変換を用いる利点ってなんですか？

177 ：デフォルトの名無しさん：2005/11/09(水) 15:38:35

順変換ってsrc->dest転送ってこと？
やってみればわかるけど、穴空くからでしょ

画像変換の基本はdest->src転送

178 ：デフォルトの名無しさん：2005/11/09(水) 16:08:44

ソースを拡大する、という発想ではなく、拡大後のピクセルの色をソースからどうやって
決定するか、と考えると分かりやすい。リサンプリングにともなう補間はそういうふうに
考えられている。

179 ：デフォルトの名無しさん：2005/11/09(水) 16:09:55

>>176
177が言うように穴が空くし、逆変換のほうがプログラムがシンプルになるよ。

180 ：デフォルトの名無しさん：2005/11/09(水) 16:32:56

穴があくとか、コードがシンプルになる、とかそういう副次的な問題ではないのだが

181 ：デフォルトの名無しさん：2005/11/09(水) 16:48:14

「フルスクラッチによる～」ってサンプルプログラムはどの言語で書かれてるのでしょうか？

182 ：デフォルトの名無しさん：2005/11/09(水) 16:55:05

C++

LibNeetで検索してみな

183 ：181：2005/11/09(水) 17:33:50

>>182
ありがとうございます。
C++わからないけど勉強がてらに読んでみようかな。

184 ：デフォルトの名無しさん：2005/11/09(水) 20:31:36

>>180
本質はどこ?
トリリニア補完でも理論的には順方向も逆方向も変換式は書けるよ。

185 ：デフォルトの名無しさん：2005/11/09(水) 21:35:49

ほんと？順方向にはそもそも補間すべきデータがないのでは？

186 ：デフォルトの名無しさん：2005/11/09(水) 21:42:26

理論的に完全に順方向補間ができるなら穴あくことはないのでは？

187 ：デフォルトの名無しさん：2005/11/09(水) 22:41:28

特に何も無くて、終わり。大学の同級生は、みんな忙しそうだ。
俺だけこんなんでいいのかな。帰宅して絵を描きました。
[oC] の細線アンチを理想の形に出来て、まぁ満足だった＞仕事。
あぁ、ローテクノロジーな事しかやってないなぁ、恥ずかしい。
取手BOXHILLが閉まってて、無地ノートが買えなくて不満。
あ、あとどういう形だかは教えられないけど、ラブひなポケットでチョイ遊ぶ。
この絵で、声無しっつーのはヤバいね・・・（当然だけど）。
声・絵、双方必要とまでは言わない。
どちらかがハイクオリティなら満足するんだと思うなぁ。
ハイクオリティというか、忠実、というか。

188 ：デフォルトの名無しさん：2005/11/09(水) 22:56:11

>>184
>>185
>>186
拡大率が1以上の場合、最近隣法を順方向でやると穴が空く。
線形補完以上でやると逆変換と同じ。ちなみに処理が面倒。

189 ：デフォルトの名無しさん：2005/11/09(水) 23:26:10

> 線形補完以上でやると逆変換と同じ。

Bicubic でも Bilinear でも２ｘ２、または４ｘ４なんだから、倍率２倍以上
３倍以上では、順方向補間では穴があくのでは？

190 ：デフォルトの名無しさん：2005/11/09(水) 23:29:58

拡大の場合は、１対多の対応関係だから、完全な順方向補間っていうのは
考えづらいが、本当に可能なの？

191 ：デフォルトの名無しさん：2005/11/10(木) 00:33:31

なんかの勘違いじゃないの？
でも、元画像の1ピクセルのデータを出力画像の幾つかのピクセルに振り分けながら計算していくとできそうな気もするな。
？
できるんか？できないんか？
できる気がしてきかけど、そんなコード書こうとは思わんな。
相当面倒くさそうだ。

192 ：191：2005/11/10(木) 00:37:53

考えたら単純な線形補完ならできるね。
トリリニアは…頭いい人はかけると思う(w

193 ：デフォルトの名無しさん：2005/11/10(木) 00:55:41

格子状に並んでいないN個の代表画素値(x_n, y_n, I_n)を
与えた場合の画像全体の補間方法としては
どのようなものがあるのでしょうか？

与えられた点をドロネー三角分割して、各座標(x, y)
に対してどの三角形に含まれるか判定してたのですが
どうにも処理が遅すぎます。

194 ：デフォルトの名無しさん：2005/11/10(木) 03:10:21

一対多でシステマティックに割り当て可能なら、Nearest でも穴が開かない論理が可能じゃないの？
この場合、Nearest っていうのは dst ピクセルから見た場合だけど。

195 ：デフォルトの名無しさん：2005/11/10(木) 03:13:11

まっ、どっちにしてもリサンプリングは逆方向で、が論理的に正しい。順方向が
可能かどうかによらず。

196 ：デフォルトの名無しさん：2005/11/10(木) 11:29:47

> 一対多でシステマティックに割り当て可能なら、Nearest でも穴が開かない論理が可能じゃないの？

そう。これが本質。補間の有無は補間範囲が有限な場合、穴があくかどうかに関係ない。
１対多の順方向変換が論理的に可能かどうかにかかっている。

197 ：デフォルトの名無しさん：2005/11/10(木) 12:29:32

>>193
すべての三角パッチをOpenGLとかで一気に描画してZバッファを取得。

198 ：デフォルトの名無しさん：2005/11/10(木) 14:45:28

>>197
んなあほな

199 ：デフォルトの名無しさん：2005/11/10(木) 20:43:02

>>193
N点を通る格子線を引いて、精密な補間法で新しい格子点の画素値を求めてから
バイリニア等の高速な補間をするってのはダメかな？
N^2オーダーで格子点が発生するからNがある程度小さいことが前提となるが

200 ：デフォルトの名無しさん：2005/11/10(木) 21:24:16

>>193
もう少し詳しく。

>>198
良いアイデアだと思うけどな。

201 ：193：2005/11/10(木) 22:03:08

>>199
大まかな格子点での値を三角パッチ補間で計算してから
その間を線形補間するという方法でしょうか？
三角パッチだと複雑な輪郭形状でも綺麗に表現できるのが
利点だと思いますが、大まかな格子状では輪郭部分が
ぼけてしまいそうです。

>>200
ようするに164のように2枚の画像のマッチングを特徴点ベースで
行って特徴点間の補間をやりたいのです。
点列→３角形パッチの変換はドロネー分割でやって、
任意座標の濃度値はどの３角形パッチに含まれるか調べて補間してました。

今気付いたのですが全ての三角形を塗りつぶしていけば高速にできそうですね・・
逆方向での補間方法しか頭にありませんでした。
OpenGLはどういう方法でやっているのだろう。

202 ：デフォルトの名無しさん：2005/11/10(木) 22:45:42

>>197
頂点カラーで単純にシェーディングする方法もあるよね・・・

203 ：デフォルトの名無しさん：2005/11/10(木) 23:21:06

>>202
Zバッファとるより素直な方法かも♪

204 ：デフォルトの名無しさん：2005/11/12(土) 17:26:33

.　　　　　　　　　＼　　　　　　　　　　　　　　　／
.　　　　　　　　　　　＼　　　　　　　　　　　　／
.　　　　　　　　　　　　＼　　　　　　　　　／
.　　　　　　　　　　　　　　＼ ∧∧∧∧／
.　　　　　　　　　　　　　　＜　　　俺　＞
.　　　　　　　　　　　　　　＜　予　し　＞
.　　　　　　　　　　　　　　＜　　　か　＞
.　─────────＜　.感　い　＞──────────
.　　　　　　　　　　　　　　＜　　　な　＞
.　　　　　　　　　　　　　　＜　!!!!　い　＞
.　　　　　　　　　　　　　　　／∨∨∨∨＼
.　　　　　　　　　　　　　／　　　　　　　　　＼
.　　　　　　　　　　　　／　　　　　　　　　　　　＼
.　　　　　　　　　　／　　　　　(-＿-)　　　　　　＼
.　　　　　　　　　／　　　　　　 (∩∩)　　　　　　　　＼

205 ：デフォルトの名無しさん：2005/11/12(土) 17:49:24

206 ：名無し募集中。。。：2005/11/12(土) 19:05:36

画像認識だったり、画像加工だったりするからな、このスレは

207 ：デフォルトの名無しさん：2005/11/12(土) 19:10:29

すんません質問です。
カラー画像のラベリングをしたいのですが、良いアルゴリズムはないでしょうか？
画像サイズは640*480。色数は50色程度で、4近傍でのラベリングです。
再帰的な方法でやってみたのですが、再帰の処理が4のn乗で増えていくので途中で落ちてしまいます。
開発環境はVC++ SDK で、画像処理に関することはcomctl32.libを使用しています。
よろしくですm(_ _)m

208 ：デフォルトの名無しさん：2005/11/12(土) 19:37:07

色毎に逐次ラベリングはどうかな

209 ：デフォルトの名無しさん：2005/11/12(土) 22:00:36

ラベリングの質問と回答は画像処理の過去スレにたくさんでとる
画像処理　その２が参考になるかな

210 ：デフォルトの名無しさん：2005/11/14(月) 11:27:55

211 ：デフォルトの名無しさん：2005/11/15(火) 19:04:22

過去ログのdatを全て持っている人いましたら、うｐしてもらえませんか？

212 ：デフォルトの名無しさん：2005/11/15(火) 19:24:32

にくちゃんねるは見に行ったのかね？

213 ：デフォルトの名無しさん：2005/11/15(火) 20:19:22

専ブラで見たいので、datが欲しいのですが…。

214 ：デフォルトの名無しさん：2005/11/15(火) 20:22:02

あそこもdat手に入るじゃん

215 ：デフォルトの名無しさん：2005/11/15(火) 20:37:28

にくちゃんねるでdat手に入るんですか？
あと、画像処理その２が見つかりません。

216 ：デフォルトの名無しさん：2005/11/15(火) 21:15:40

質問です。
squares.obj : error LNK2001: 外部ｼﾝﾎﾞﾙ "_cvReleaseImage" は未解決です』
というエラーがたくさんでます。
何か設定が足りないのでしょうか？
OSはXPです。

217 ：デフォルトの名無しさん：2005/11/15(火) 21:19:38

つ【google】

218 ：216：2005/11/15(火) 21:19:52

忘れました。
openCVをvisual C++ 6.0で動かす場合です。

219 ：デフォルトの名無しさん：2005/11/15(火) 21:43:33

>> 216
linkerの設定で、OpenCVのlibを指定すれば直ると思うよ。

220 ：デフォルトの名無しさん：2005/11/15(火) 22:09:05

cもしくはc++で、jpegの画像を読み込み、ピクセルを抽出し、jpegとして
書き出すという単純なことをまず行いたいと思っているのですが、
画像処理を研究、あるいは勉強している人だったら
とりあえずこれ使うよっていうものにどのようなものがあるでしょうか？

とりあえずOpenCVをダウンロードしてやっているのですが、このほかに
フリーで使えるものがあればお願いします。

221 ：デフォルトの名無しさん：2005/11/15(火) 22:12:07

>>220
>>158-160

222 ：デフォルトの名無しさん：2005/11/16(水) 01:47:41

>>220
君はまず219に反応するべきだと思った

223 ：デフォルトの名無しさん：2005/11/16(水) 12:05:12

>>216
もしかして、サンプルのsquaresをビルドしようとしてる?
OpenCV\_makeのopencv.dswからプロジェクト開いてビルドすべきだと思うよ。

224 ：デフォルトの名無しさん：2005/11/16(水) 12:07:55

>>220
PNGとかPPMみたいな単純なフォーマットに変換してから使うってのは無し?
研究用のプログラムならこのくらいで十分でしょ。

225 ：216：2005/11/16(水) 18:53:58

>>223
ビルドできました。ありがとうございます★

226 ：デフォルトの名無しさん：2005/11/17(木) 00:00:06

>>224
PNGのどこが単純?
まぁ、JPGと違って可逆圧縮だからJPG使うよりましなわけだが。

227 ：デフォルトの名無しさん：2005/11/17(木) 00:06:05

OpenCVってカメラの画像を非圧縮aviで動画として保存したりできます？

228 ：デフォルトの名無しさん：2005/11/17(木) 00:40:42

>>221
ありがとうございます.

>>225
確かに同じ画像使うならppmでもよさそうですね.

229 ：デフォルトの名無しさん：2005/11/17(木) 19:54:33

>>227
動画出力はWindowsでしかできないつーことで、私は使ったことがないっす。
たぶん、DirectX使ってるだろうからできるんじゃない?

230 ：デフォルトの名無しさん：2005/11/17(木) 19:56:30

>>226
PGMのうち間違いだと思われ。

231 ：デフォルトの名無しさん：2005/11/22(火) 01:52:02

>227 >229 LINUX用OpenCVでも、FFMPEGのライブラリをインストールすれば
動画出力できるよ。
関数はcvCreateVideoWriter(),cvWriteFrame()とか。

FFMPEGはたくさんのCODECに対応してるみたい。
でもOpenCVがFFMPEGを呼び出すところで、数種類以外のCODECだと
エラーを返すようなソースになってる
otherlib/highgui/cvcap.cpp だったかな。
CODEC_ID_云々かんぬんってところ。

後は、その保存した動画ファイルからキャプチャする、
cvCaptureFromAVI だっけ。この関数、ファイル名から
CODECを予想したりしてるみたい。

僕自身もよく分かってなくて、
OpenCVでカメラ画像を動画として保存できたけど、
それを再生するところまでは出来てないんですよね。
(mpeg1では普通に出来てますが)

画像処理に使うので、CODECは可逆圧縮のhuffYUVとか
使いたいと思っているんですけど、キャプチャの関数で
読み込めないんですね。

誰か、分かってる人いましたらご教授ください。
長文スマソ

232 ：デフォルトの名無しさん：2005/11/25(金) 05:09:15

画像の先鋭度判定(ピントが合ってるかどうか)ができる
コードはどこかに公開されてないでしょうか？

233 ：名無し募集中。。。：2005/11/25(金) 16:23:14

BOOL IsFocus( WORD *RowData );

234 ：デフォルトの名無しさん：2005/11/26(土) 09:14:17

ひどい(笑)

235 ：デフォルトの名無しさん：2005/11/26(土) 11:29:09

>>233
Win厨乙

236 ：デフォルトの名無しさん：2005/11/26(土) 18:18:33

処理にMMXとかSSE使ってる人いる?
どうやって入門したら良いの?

237 ：デフォルトの名無しさん：2005/11/26(土) 18:42:13

>>236
ふつうに一般のアセンブラで組むのと（もっと言えばC言語の場合と同じで）
同じ要領でやればいいだろ。
最初から最適化とかカリカリに考えず、確実に動くコードを作成して
改良していけば良いと思うよ。

238 ：名無し募集中。。。：2005/11/26(土) 21:49:54

でもよほどうまく書かないとコンパイラのほうが早いコードをはくよ

239 ：デフォルトの名無しさん：2005/11/28(月) 00:02:28

各バンドが16bit-depthの画像(16bitTIFFとか)の
読み書きができるライブラリはご存知ないですか？
GNUのLIBTIFFだとできないようです。

240 ：デフォルトの名無しさん：2005/11/28(月) 00:08:28

>>239
つ[ImageMagick]

241 ：デフォルトの名無しさん：2005/11/28(月) 00:47:55

つ[libPNG]

242 ：デフォルトの名無しさん：2005/11/28(月) 01:33:48

libPNGでどうやって16bitTiffを扱えというのだろう。

243 ：デフォルトの名無しさん：2005/11/28(月) 01:59:21

「とか」って書いてあるから別にフォーマットは何でもいいんじゃねえの？

244 ：デフォルトの名無しさん：2005/11/28(月) 02:56:30

逆に寧ろ、tiffを含む複数のフォーマットを扱いたいのでは?

245 ：デフォルトの名無しさん：2005/11/28(月) 03:02:11

というわけで、>>239はどうしたいのか言ってくれ

246 ：239：2005/11/28(月) 03:34:46

ImageMagick（コマンドラインのほう）を使うと画像操作ができました。
ソースみるとLIBTIFFを使っているようですね。
ということはLIBTIFFでも16bit読み込みできるということだけど
おとなしくImageMagickでrawデータに変換して使うことにします。
ありがとうございました。

247 ：239：2005/11/28(月) 03:38:30

「とか」という表現でお騒がせしました。入力が巨大サイズ16bitTIFF、
要するに衛星画像なんですが、扱いづらいので、なんとか簡単に読み込む、
もしくは他のフォーマットに変換する方法を探してました。

248 ：デフォルトの名無しさん：2005/11/28(月) 06:44:26

ImageMagickのコマンドラインってConvert?
あれってすごく便利だよね～。
シェルスクリプト組んで一気に変換とか便利すぎ。
作った人に感謝してるよ。

249 ：デフォルトの名無しさん：2005/11/28(月) 11:26:43

LibTiffはコンパイルオプションを指定しないと8ビットのみ対応じゃなかったかな。

ImageMagickは確か8ビット版と16ビット版の両方を配布してた気がするけど。
convertが余りに便利でスタティックライブラリとして使わずにプロセスとして使うもんだから、
既にインストールされていたImageMagickが8ビット版でそっちが呼ばれててバグったって話を聞いたよ。

250 ：デフォルトの名無しさん：2005/11/28(月) 22:06:41

>>236
金が有ればIntel C++ Compiler使うのもよし。
シンプルなループは軒並みSIMD命令でベクトル化される。
俺のヘタッピソースでもVC6.0と比べて4倍高速化されたこともあった。

251 ：ちもし：2005/11/29(火) 21:52:16

淫厨宣伝乙

252 ：デフォルトの名無しさん：2005/11/29(火) 21:56:07

>>250
それはアルゴリズムが蛸で、シンプルなループだらけだったということで宜しいか。

253 ：デフォルトの名無しさん：2005/11/30(水) 04:22:49

>>252
なんのアルゴリズムか知らないけどさ、優れた実装ほどシンプルになるんじゃない?

254 ：デフォルトの名無しさん：2005/11/30(水) 04:35:48

優れたプログラマほど給料が安い
残業しないから

255 ：デフォルトの名無しさん：2005/11/30(水) 04:40:48

優れたプログラマに仕事が集中するだけのような

256 ：デフォルトの名無しさん：2005/11/30(水) 07:44:39

>>253
いや、「無駄な」シンプルなループが山ほどあるんだろうよ。

257 ：デフォルトの名無しさん：2005/11/30(水) 07:45:33

>>254
それだけ優れたプログラマなら残業しなくても単価が高いだろ。

258 ：デフォルトの名無しさん：2005/11/30(水) 09:20:42

>>257
そうとは限らないんですね

259 ：デフォルトの名無しさん：2005/11/30(水) 09:28:08

お前らマ板にいけ

260 ：デフォルトの名無しさん：2005/11/30(水) 10:37:48

自称優れたプログラマほど給料が安い（同時にまかせれる仕事が少ない）。
本当に優れている人間には次々に仕事が任されて、結局残業しちゃうんじゃないの？

261 ：デフォルトの名無しさん：2005/11/30(水) 11:37:27

残業なんて無能のする行為だ

262 ：デフォルトの名無しさん：2005/11/30(水) 11:45:46

画像処理・・・

263 ：デフォルトの名無しさん：2005/11/30(水) 13:52:27

本当に優れている人間は、（画像処理などで）残業しなくても多く稼げる方法を知ってるだろ。

264 ：デフォルトの名無しさん：2005/11/30(水) 13:54:08

本当に優れている人間 ≠ 本当に優れたプログラマ

265 ：デフォルトの名無しさん：2005/11/30(水) 16:16:26

お前らマ板にいけ

266 ：デフォルトの名無しさん：2005/11/30(水) 19:37:15

ビデオキャプチャーボードなんかで取り込んだ × とか＋みたいな図形の
クロスした点を求めるロジックの参考文献を教えてください。

267 ：デフォルトの名無しさん：2005/11/30(水) 20:13:14

>>266
断る

268 ：デフォルトの名無しさん：2005/11/30(水) 20:23:50

>>266
外出

269 ：デフォルトの名無しさん：2005/12/01(木) 00:14:38

優れた画像処理プログラマーは、自分自身の仕事のプロファイルを
計測し、チューニングする。

270 ：デフォルトの名無しさん：2005/12/01(木) 00:31:25

>>266
水平垂直45度などの方向に濃度変化の微分を取って、そのピークの中間。

271 ：デフォルトの名無しさん：2005/12/04(日) 20:53:08

保守。

書き込みが少ないけど、みんな卒論がおわったってこと？(w

272 ：デフォルトの名無しさん：2005/12/04(日) 20:55:13

■■■■■■■■■■■■■■■■
■　　　　　　　　　　　　　　　　　　　　 ■　　違う板にコピペすると、四角の枠の中に
■　　　　　　　　　　　　　　　　　　　　 ■　　メッセージとURLが現れる不思議な絵。
■　　　　　　　　　　　　　　　　　　　　 ■
■　　　　　　　　　　　　　　　　　　　　 ■　　（その仕組みがリンク先に書いてある）
■　　　　　　　　　　　　　　　　　　　　 ■
■　　　　　　　　　　　　　　　　　　　　 ■　　この原理を応用すると、まったく新しい
■　　　　　　　　　　　　　　　　　　　　 ■　　コピペが作れる。
■■■■■■■■■■■■■■■■

273 ：デフォルトの名無しさん：2005/12/05(月) 00:18:07

>>271
まさか。これから始めるとこだよ。

274 ：デフォルトの名無しさん：2005/12/05(月) 09:33:42

>>272
うまくできなかったんだけど、板の指定とかあるの？

275 ：デフォルトの名無しさん：2005/12/05(月) 10:26:06

>>274
ネタにマジレスry

276 ：デフォルトの名無しさん：2005/12/05(月) 10:44:51

>>275
マダ善人がいるという証左。

277 ：デフォルトの名無しさん：2005/12/05(月) 11:51:32

その善人もいずれ

278 ：デフォルトの名無しさん：2005/12/05(月) 13:52:23

272デフォルトの名無しさんsage2005/12/04(日) 20:55:13
■■■■■■■■■■■■■■■■
■　　　　　　　　　　　　　　　　　　　　 ■　　違う板にコピペすると、四角の枠の中に
■　　　　　　　　　　　　　　　　　　　　 ■　　メッセージとURLが現れる不思議な絵。
■　　　　　　　　　　　　　　　　　　　　 ■
■　　　　　　　　　　　　　　　　　　　　 ■　　（その仕組みがリンク先に書いてある）
■　　　　　　　　　　　　　　　　　　　　 ■
■　　　　　　　　　　　　　　　　　　　　 ■　　この原理を応用すると、まったく新しい
■　　　　　　　　　　　　　　　　　　　　 ■　　コピペが作れる。
■■■■■■■■■■■■■■■■

274デフォルトの名無しさん2005/12/05(月) 09:33:42
>>272
うまくできなかったんだけど、板の指定とかあるの？

279 ：デフォルトの名無しさん：2005/12/05(月) 18:16:51

ディザリングの話なんですが、誤差拡散と平均誤差最小法は、全く違うという説と、
フィルタの大きさと種類が違うだけでやることは同じという説の二つを聞くんですが、
私の見たソース付きの文献では、後者の方しか見つけられませんでした。

前者を押す意見としては、
ttp://www.pag1u.net/hatumei/gosa_kakusan.html
があったんですが、具体的なアルゴリズムを乗せているソースなどは発見できませんでした。
平均誤差最小法は、誤差拡散とは全く違うアルゴリズムだという場合は、
フィルタ以外に違う部分があるんでしょうか？

280 ：デフォルトの名無しさん：2005/12/05(月) 18:47:18

>>279
見方によって同じか違うか意見が分かれるところだね。
比較器の閾値を誤差でいじるか、誤差をフィルタ通してフィードバックするか。
実装するとどっちもラスタスキャンで処理できるから係数が違うだけジャンと言えるかもしれないし。
誤差をフィードバックする位置が微妙に違うだけで本質は同じジャンと言えるかもしれないし。

人の視覚特性を考慮したフィルタを明示的に組み込める誤差拡散法が個人的に好き。
えっ?!平均誤差最小法でもできるって?

281 ：279：2005/12/05(月) 19:01:49

>>280
そうなんですよね。
実際、コードを書くと係数と範囲が違うだけの同じ物になってしまうんですが、
そうすると、
ttp://www.pag1u.net/hatumei/gosa_kakusan.html
で言っているような実際例にはならないんじゃないかとも思ったので、
全然別な方法でもあるかと思ったんですよ。

282 ：デフォルトの名無しさん：2005/12/05(月) 20:10:29

>>281
出発地点となるアイデアが違っていてもゴールとなる実装では同じになるというのは多々あることだしね。
ところで、今どきディザ表現やってるって出力関係の人?

283 ：デフォルトの名無しさん：2005/12/05(月) 20:12:50

･･･
お前ら･･･フィルタの係数がちがっとったら明らかに別物だろうが･･･。

284 ：279：2005/12/05(月) 20:33:44

>>282
いや、只のオンラインソフト作家です、はい

>>283
あ、いや、フィルタの係数が全然違うってのはわかるんですよ

そうすると、
ttp://www.pag1u.net/hatumei/gosa_kakusan.html
で言ってる、隣接ピクセルしか参照しない例とか言っている意味が通じなくて、orz なんです

本当にトホホです

285 ：デフォルトの名無しさん：2005/12/05(月) 21:25:41

>>279
15年くらい前にファクスの開発をしていて誤差拡散法についてかなり深く調査した
けど、オレの解釈では、誤差拡散法と平均誤差最小法は同一アルゴリズム
だと思う。数学的には同じだし、１次元のデルタ・シグマ変調を２次元に
拡張したもの。量子化ノイズのスペクトルを変形させて（ノイズシェイピングして）、
低周波のノイズを減らすことで、階調、つまり直流や低周波の成分の
再現性を向上する技術だ。

286 ：279：2005/12/05(月) 21:46:30

>>285
なるほど、フィルタの大きさと係数は違うだけで、やっぱり数学的には同じなんですね。

あと、色々検索してみたら、Cマガの訂正記事　ttp://www.cmagazine.jp/bugs/　の
2000年6月号のところで

>誤差分散と平均誤差最小法はまったく同一ではありません。一部書籍などでは同一とされていることもあります。
>誤差分散が最適パレットに向いているとは表現されていません。

という、これまた微妙な表現がしてあったのですが、これは、
誤差拡散（分散）と平均誤差最小法は、全く同一である、ということはない、って意味なんでしょうね多分。

287 ：デフォルトの名無しさん：2005/12/06(火) 00:01:34

まずpag1のページを参照するのを止めることだな。

288 ：デフォルトの名無しさん：2005/12/06(火) 00:55:33

dense stereo のデンスってなんですか？

289 ：285：2005/12/06(火) 01:21:33

>>286
たとえば、誤差拡散の係数の総和を1.0ぴったりにしないで、もう少し控えめに
すると通常の２値化に近づくし、２値化の閾値にヒステリシスを持たせたりすること
も、非常に早い時期から提案されていて（これは、ランレングス圧縮の効率を
あげるため）、はっきり言って、誤差拡散法と平均誤差最小法の
どちらが本家だと決めることはできないけど、一方が他方のバリエーションに
過ぎないと言っても、間違いじゃないと、オレは思うよ。

正直、言葉にあんまりこだわっても仕方ないんじゃないかなぁ・・・

290 ：デフォルトの名無しさん：2005/12/06(火) 06:31:47

あの文章は正しくないと思った方がいい？

291 ：デフォルトの名無しさん：2005/12/06(火) 12:01:56

>>288
dense→密、sparse→粗。数学でも sparse matrix とか言うでしょ?
dense stereo correspondence algorithmって言う場合は画面全体の視差を求めるアルゴリズムになるね。
sparce stereo correspondence algorithmは数十～数百個の特徴点を抜き出して視差を求めるアルゴリズムかな。

292 ：デフォルトの名無しさん：2005/12/06(火) 12:02:58

>>291
×sparse○sparce

293 ：デフォルトの名無しさん：2005/12/06(火) 12:20:02

>>287
pag1の作者って今何してるの？

294 ：デフォルトの名無しさん：2005/12/07(水) 16:17:39

五角形の画像はどう扱えば良いのでしょうか？
四角形ではない画像を作りたいのですが

295 ：デフォルトの名無しさん：2005/12/07(水) 16:23:50

>>294
死ね

296 ：デフォルトの名無しさん：2005/12/07(水) 16:24:24

質問が漠然としすぎ

297 ：デフォルトの名無しさん：2005/12/07(水) 16:45:20

>>296
Visualstudioとかでビットマップ画像を加工しても
ﾀﾃとﾖｺを指定するので必ず四角形の中に描画する画像になります
CADツールで作ったベクトル画像などはソフトを持っていないので扱えません

298 ：デフォルトの名無しさん：2005/12/07(水) 17:16:18

だからなに？

299 ：デフォルトの名無しさん：2005/12/07(水) 17:22:28

透過色のことでもいってんのかね

300 ：デフォルトの名無しさん：2005/12/07(水) 17:22:29

>>298
＞だからなに？

答えられないの？ｗ

301 ：デフォルトの名無しさん：2005/12/07(水) 17:47:25

答えられません。

302 ：デフォルトの名無しさん：2005/12/07(水) 17:54:20

なら、もうプログラム内で切り取りします

303 ：デフォルトの名無しさん：2005/12/07(水) 18:11:19

かんべんしてください

304 ：デフォルトの名無しさん：2005/12/07(水) 18:22:50

>>303
なら死んでください。

305 ：デフォルトの名無しさん：2005/12/07(水) 18:26:35

今visual C++ でOpenCVとdirectXを合わせて使いたいのですが、
OpenCVは画像がiplimage形式で扱っているためdirectXにそのまま送れません。
ネットを探すとcvConvertToDib()という関数を見つけたのですがどのように
使えばbitmap形式に直せるのかOpenCVを始めたばかりなのでわかりません。
どうか教えてください。

306 ：デフォルトの名無しさん：2005/12/07(水) 18:27:24

だからなに？

307 ：デフォルトの名無しさん：2005/12/07(水) 18:28:47

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

308 ：デフォルトの名無しさん：2005/12/07(水) 19:44:13

>>305
基本的な考え方としてはセパレートなDIBヘッダを作って画像サイズとかヘッダの内容をセットする。
で、バッファをIplImageのimageDataをさすようにすれば良い。
そんなに難しくないよ。

昔はIPLっていうライブラリに
iplConvertFromDIBSepとかあるってそれ使ってたな。

309 ：308：2005/12/07(水) 19:51:43

昔のコードがまだあったみたい。
IPLのConvertToDIBだとこういった使い方になる。cvの方はしらないけど、似たようなもんじゃないかな?
ところで、OpenCVにConvertToDIBってどこにあるの?
見てみたいんで、ファイル名教えて。

int DIB2IPL(BITMAPINFO *pbmi, unsigned char *pbuf, IplImage *pimg)
{
if (pbuf == NULL || pbmi == NULL) return -1;

iplConvertFromDIBSep (&(pbmi->bmiHeader), (const char *)pbuf, pimg);

return 0;
}

int IPL2DIB(BITMAPINFO *pbmi, unsigned char *pbuf, IplImage *pimg)
{
if (pimg == NULL || pbmi == NULL || pbuf == NULL) return -1;
iplConvertToDIBSep(pimg, &(pbmi->bmiHeader), (char *)pbuf,
IPL_DITHER_FS, IPL_PALCONV_POPULATE);
return 0;
}

310 ：つづき：2005/12/07(水) 19:52:06

バッファを共有する場合はこう。

int DIB2IPLDS(BITMAPINFO *pbmi, unsigned char *pbuf, IplImage **pimg)
{
if ( NULL == pbmi || NULL == pimg) return -1;
if ( NULL != *pimg )
cvReleaseImageHeader(pimg);

*pimg = cvCreateImageHeader(cvSize(pbmi->bmiHeader.biWidth, pbmi->bmiHeader.biHeight),
IPL_DEPTH_8U, 3);
(*pimg)->imageData = (char *)pbuf;

return 0;
}

311 ：305：2005/12/07(水) 20:24:06

cvというのは自分の勘違いでiplでした。
間違いの情報を言ってしまって申し訳ございません。
iplをインストールしてやってみます。
308さんホントにありがとうございます。

312 ：デフォルトの名無しさん：2005/12/07(水) 20:43:57

>>297
ビットマップそのものは矩形から逃れられない。
描画するときに、ライブラリによっては透過色を指定したり、または、
リージョンをつかってどんな形にでもクリップできる。

313 ：伝説新人タクシ：2005/12/07(水) 20:55:02

さわやかベクタ対応仕様のDIBver1.1…

314 ：305：2005/12/08(木) 00:37:47

たびたびすいません。iplをダウンロードしてincludeにipl.hをしていしたら、次のようなエラー
がでできました。
ipl.h内
299:typedef enum {
230: IPL_PREWITT_3x3_V=0,
231: IPL_PREWITT_3x3_H,
232: IPL_SOBEL_3x3_V, /* vertical */
233: IPL_SOBEL_3x3_H, /* horizontal */
234: IPL_LAPLACIAN_3x3,
235: IPL_LAPLACIAN_5x5,
236: IPL_GAUSSIAN_3x3,
237: IPL_GAUSSIAN_5x5,
238: IPL_HIPASS_3x3,
239: IPL_HIPASS_5x5,
240: IPL_SHARPEN_3x3
241:} IplFilter;
c:\program files\intel\plsuite\include\ipl.h(237) : error C2059: 構文ｴﾗｰ : 'constant'
c:\program files\intel\plsuite\include\ipl.h(241) : error C2143: 構文ｴﾗｰ : ';' が '}' の前に必要です。
c:\program files\intel\plsuite\include\ipl.h(241) : error C2501: 'IplFilter' : 識別名を宣言するのに、型が指定されていません。
何が悪いのかまったくわかりません。どうか教えてください。

315 ：デフォルトの名無しさん：2005/12/08(木) 00:55:06

>>314
そのipl.hをインクルードする順番を変えたらエラーが変わったりしない?

316 ：デフォルトの名無しさん：2005/12/08(木) 11:59:08

>>314
FAQｓくらい嫁。

When using OpenCV and IPL simultaneously, I get compiler errors. How to resolve this problem?

To be completely independent from IPL, OpenCV duplicates declarations of IplImage and few other structures and
constants if it is not told explicitly that IPL is present. Defining HAVE_IPL before including OpenCV headers or
putting "#include <ipl.h>" before OpenCV headers resolves the conflict.

317 ：305：2005/12/08(木) 14:40:55

正常に動きました。どうもありがとうございました。

318 ：デフォルトの名無しさん：2005/12/08(木) 18:39:07

IPLってもうサポートされてないんでしょ？大丈夫なの？

319 ：デフォルトの名無しさん：2005/12/08(木) 19:35:17

つーか、24bitRGBとか決めうちなら変換関数作るの簡単なんだが･･･。

320 ：デフォルトの名無しさん：2005/12/10(土) 21:03:07

動画から切り出した連続画像があるんですが、いわゆるシーンチェンジ部分を判定するのには、
何か定石みたいなものはあるんでしょうか

321 ：デフォルトの名無しさん：2005/12/11(日) 00:07:30

みなさんはどういう業界の会社にお勤めなのでしょうか？
工学的な画像処理プログラムの仕事がしたいです。

322 ：デフォルトの名無しさん：2005/12/11(日) 03:49:52

テンプレートマッチングのさいの誤差を検出したいのですが，
なにかよい方法があればどうか教えて下さい。
よろしくお願いします。

323 ：デフォルトの名無しさん：2005/12/11(日) 09:01:45

>>321
それはここで尋ねる話題じゃねーぞ

324 ：デフォルトの名無しさん：2005/12/11(日) 12:22:56

>>321
ニートです。

325 ：デフォルトの名無しさん：2005/12/11(日) 17:42:24

>>322
何の誤差だよ？

326 ：名無し募集中。。。：2005/12/11(日) 21:07:06

m_ErrorValue = 1.0f - GetMatchingValue() ;

327 ：321：2005/12/11(日) 21:58:10

>>323
失礼しましたm(_ _)m

>>324
ニートなのに画像処理をされているんですか？？

328 ：デフォルトの名無しさん：2005/12/11(日) 22:21:38

画像から特徴抽出して、その特徴をもとにして特定の線分だけを認識・抽出みたいな事をしたいんですが
何か参考になる書籍ありませんかね？
具体的にはＣＴとかＭＲＩ画像から肺領域の輪郭だけを抽出のような感じです

329 ：デフォルトの名無しさん：2005/12/11(日) 23:14:51

>>327
画像処理の研究が趣味のニートです。

330 ：デフォルトの名無しさん：2005/12/11(日) 23:33:33

>>325
マッチングのさいの精度のようなものを検出したいのですが，
マッチングのさいミスが何パーセントあるのかとかを検出したいんです。
これを計算する方法を教えていただきたいのですが，
うまく説明できなくてすいません。

331 ：デフォルトの名無しさん：2005/12/11(日) 23:48:16

>>330
プログラムが判定したマッチしたサンプルの数と、
人間が目視するなりして判定した正解数の差をとって
全サンプル数で割ればエラー率（のようなもの）が出ますよ。

332 ：デフォルトの名無しさん：2005/12/12(月) 01:17:33

>>331
回答ありがとうございます。
プログラムが判定してマッチしたとみなした点と，
目視でマッチしているとみなした点を正解として，
その差をとって，マッチングした全ての点の数で
割るというこなんでしょうか？

333 ：331：2005/12/12(月) 01:33:11

>>331は大間違いですね。

プログラムが検出したマッチ数を A 、目視なりで判断した正解を B、
Aのうち実際には誤りであるものの数をCとして、

・　A / B が 1 より大きいことを「過検出」と呼び、この数を指標として用い、
・　(A - C) / B が1より小さい場合を「見逃し」と呼び、この数(or 1から引いた数)を指標として用います。

過検出と見逃しは背反するものではなく、両方同時に発生し得ます。
どちらも発生しないのが理想ですが、それが不可能な場合には
どちらかに寄せるのが普通です。

334 ：331：2005/12/12(月) 01:36:12

追記：
工学的応用まで考えると、誤りが過検出なのか見逃しなのかは重要ですが、
その辺に転がってる簡単な論文なんかでは単純に判定が正解である率なんかも
多く用いられているみたいです。

335 ：デフォルトの名無しさん：2005/12/12(月) 02:14:59

>>333
マッチングした点が一つに対して一つしか検出されない場合は
どうなるのでしょうか？

336 ：名無し募集中。。。：2005/12/12(月) 08:13:20

all or nothing

337 ：デフォルトの名無しさん：2005/12/12(月) 08:55:14

>>328
書籍の記述をソースにしているこんなのある。
ttp://www13.plala.or.jp/kymats/program/program_picture.html

338 ：デフォルトの名無しさん：2005/12/12(月) 09:16:48

画像なのに雑音処理って・・・

339 ：デフォルトの名無しさん：2005/12/12(月) 10:25:33

雑色とか雑画とか雑光とかでどうか

340 ：デフォルトの名無しさん：2005/12/12(月) 10:29:43

テンプレートマッチングのアルゴリズムかソースを探しています
いいHPを教えていただけますでしょうか？
自作のテンプレートマッチングは余りにも遅くて使い物になりませんです

341 ：デフォルトの名無しさん：2005/12/12(月) 10:42:22

ノイズをそのまま訳したのか

342 ：デフォルトの名無しさん：2005/12/12(月) 11:15:46

雑味

343 ：デフォルトの名無しさん：2005/12/12(月) 13:57:54

>>340
無い。

344 ：デフォルトの名無しさん：2005/12/12(月) 17:58:22

なんか変なの来てるな。
何でもクレクレの初心者は出てけ。

345 ：名無し募集中。。。：2005/12/12(月) 21:11:23

おそすぎるのは、SEXとかMMXつかってないからだお

346 ：デフォルトの名無しさん：2005/12/12(月) 21:30:16

つっこんでいいですか？

347 ：デフォルトの名無しさん：2005/12/12(月) 22:09:55

優しくしてね

348 ：名無し募集中。。。：2005/12/12(月) 22:11:16

>>345
俺以外にも狼住人が居るのか?

349 ：デフォルトの名無しさん：2005/12/12(月) 23:58:22

VIPPERかよｗｗｗｗｗ

350 ：340：2005/12/13(火) 09:05:46

やっぱり無いですかね
テンプレートマッチングだけはなかなか簡単にはいきませんです
>>345
もちろんMMXは使ってます
でコアソースはasmで書いてます
某ライブラリで5msec程度のマッチングが30msecかかります
どうやって端折ってるんだろう・・・

351 ：デフォルトの名無しさん：2005/12/13(火) 11:34:13

ライブラリのソースみてみたら？

マッチングのエラー値が一定を越えたら
次の領域の計算に移るとかやってるとか( わからんけど

352 ：デフォルトの名無しさん：2005/12/13(火) 13:22:12

>>350
正規化相関つかってるのかな？
正規化相関を高速に計算するためのアルゴリズムがどっかの論文誌に載ってたけどね。
探してみたら?

353 ：デフォルトの名無しさん：2005/12/13(火) 13:24:05

マッチングの評価方法と画像のサイズがわからんが、30msecってのは早いほうじゃないのか?

354 ：名無し募集中。。。：2005/12/13(火) 18:29:49

某ライブラリとはキャノンソリューションとかMatroxとか
ファーストとかCognexとかLinxとかかしら

355 ：デフォルトの名無しさん：2005/12/13(火) 20:49:39

>>354
ｼﾛｳﾄｻﾝｶﾞﾀﾀｶｲｦｲﾄﾞﾑﾆﾊﾑﾎﾞｳｽｷﾞ・・・

356 ：340：2005/12/13(火) 21:35:11

>>351
ソースは公開されてないです
>>354
はいそうです
一応正規相関＋荒から高精細サーチなどを行って30msecにまでしましたけどこれ以上考えつきません
>>353
1000*1000pix中の100*100pixですね
残念ながらまだ実用レベルじゃないです・・・
>>354
ＭＩＬ、ＦＡＳＴ、Cognexあと,Euresysの開発ライセンス持ってます
今回の案件はセカンドライセンスが毎回発生するとほとんど利益で無いので
仕方なく自己開発ですＴＴ

357 ：デフォルトの名無しさん：2005/12/13(火) 21:49:33

>>356
＞1000*1000pix中の100*100pixを30msec
プログラムの素人から見たらすっごい早いですよ！
実装面じゃなくってアルゴリズムの見直しをするならこれとか参考になるんじゃない？
"正規化相関演算の単調関数化による高速テンプレートマッチング"，電子情報通信学会論文誌　VOL.J83-DII No.9 September 2000

SIMD命令使ったプログラム書きたいんだけど、なにかいい本とかないですか?
取っ掛かりさえわからない状態です。

358 ：357：2005/12/13(火) 21:54:07

上の文献だけど、"相関演算を単調関数化できて、係数の伸びの悪いピクセルでの演算を途中で打ち切れる"という内容だったと思います。
精読してないから使えるかどうかわかりません。
違うアプローチとしてはFFTとかで畳み込み演算をやってしまうというのもあるみたいです。

では、お勤めがんばってください。

359 ：デフォルトの名無しさん：2005/12/13(火) 22:08:24

おいおいこまるよー。あんたらー。
その道の玄人さんはトリップ付けてはなそーぜ。

みんないろいろ聞きたいからさ。

360 ：デフォルトの名無しさん：2005/12/13(火) 22:38:50

>>359
うるさい黙れ

361 ：デフォルトの名無しさん：2005/12/13(火) 23:32:19

>>357
本ならCQ出版から15日発売のx86アセンブラ入門とか。
ただし地雷の可能性高し。立ち読み必須。

WebならHerumiさんのHPとかIntelのPDFとか見ればいいと思うよ。

362 ：デフォルトの名無しさん：2005/12/14(水) 00:23:01

128x128同士のテンプレートマッチングを0.5M回ほど回して一時間ほどだった希ガス。
まぁ、条件が違いすぎるけど。

363 ：デフォルトの名無しさん：2005/12/14(水) 11:56:49

X86のアセンブラ入門というと、ひとつトンデモナイいんちきな
やつがあったなぁ・・・　さすがにCQ出版ならあんなものを
出したりはしないけど。

364 ：デフォルトの名無しさん：2005/12/14(水) 12:33:00

橋本＆山本の本ですかね

365 ：デフォルトの名無しさん：2005/12/14(水) 15:08:16

みなさんに質問があるのですが、最近モバイルや携帯用に画像が小さくなってますが、
どう処理されてますか？ピクセル計算して削る以外に方法ってあります？

366 ：デフォルトの名無しさん：2005/12/14(水) 15:14:07

>>365
既存のソフト何種類か触ればどんなやり方があるかわかるだろ？

367 ：デフォルトの名無しさん：2005/12/14(水) 15:18:22

すみません。言葉がたりませんでした。画像処理のプログラムでDIBを
使ってますが、ピクセル削るにも限界があって・・そもそもDIB以外の
APIってあるんですか？

368 ：デフォルトの名無しさん：2005/12/14(水) 15:27:12

ピクセル削るってどういうこと？
DIBってAPIなの？

369 ：デフォルトの名無しさん：2005/12/14(水) 15:30:11

頭痛くなってきたｗｗｗ

370 ：デフォルトの名無しさん：2005/12/14(水) 15:30:39

>>368
画像を小さくするために、均等にピクセルを間引いて小さくしてます。
DIBは、win32のAPIで、画像を描画したり、BITMAP形式で保存したり
できます。

371 ：デフォルトの名無しさん：2005/12/14(水) 15:31:33

要するに、ｲｹてる縮小アルゴリズムｷﾎﾞﾝってことか？

372 ：デフォルトの名無しさん：2005/12/14(水) 15:32:53

>>371
そのとおりです。なにか、ないでしょうか？

373 ：デフォルトの名無しさん：2005/12/14(水) 15:34:23

>>372
既存のソフト何種類か触ればどんなやり方があるかわかるだろ？

374 ：デフォルトの名無しさん：2005/12/14(水) 15:36:01

画素を間引きして縮小するという時点ですでに間違っている
過去スレに縮小アルゴリズムは何度もでてるから参照せよ

375 ：デフォルトの名無しさん：2005/12/14(水) 15:36:51

>>373
既存ってフォトショップとか？

376 ：デフォルトの名無しさん：2005/12/14(水) 15:37:32

>>372
じぶんでぐぐってみ

377 ：デフォルトの名無しさん：2005/12/14(水) 15:38:20

バイリニア、バイキュービックあたりでイインジャネ

もしくは、
SetStretchBltModeでHALFTONE指定して
StretchBltすれば単純に間引くよりはマシかぽね

378 ：デフォルトの名無しさん：2005/12/14(水) 15:39:24

>>374
了解しました。間違いってことは、あるんですね。ありがとう。
参照してまた来ます。

379 ：デフォルトの名無しさん：2005/12/14(水) 15:42:02

>>377
ありがとう。そのヒントでも調べてみます。

380 ：デフォルトの名無しさん：2005/12/14(水) 15:42:50

>>374
処理速度優先で画質はどうでもいい場合は間引いて縮小することもあるんで、一概に間違いとはいえないと思う。

381 ：340：2005/12/14(水) 15:54:38

皆さん色々有難う御座いました
>>357
ためになる文献を教えていただき有難う御座いました
>>357
mmxならば結構色々落ちてますね
僕の場合は昔々に買ったMMXのチューンアップ本を見てますけど
７～８年前なので今でも売ってるか分かりません
sseはあまり分からないです
intelのドキュメントは充実してますのでそれから覗いてはどうでしょうか

>>372
単純にデータ量を減らしたいのであれば、縮小と減色が一般的でしょうか
画像減色ディザ拡散法とかでググるとか
画像縮小バイキュービック法でググるとか
nxlibってDIBを操るライブラリのソースも結構参考になります

>>380
動きのある拡大縮小ならそれで全然OKですね

382 ：デフォルトの名無しさん：2005/12/14(水) 15:58:07

縮小方向でバイキュービックってどうなんだ？
ちょっとした縮小ならバイリニア、ある程度以上の縮小で手間かけたくないなら面積平均法、
真面目にやるならLanczosって気がするんだが。

まぁ、速度と画質と手間のトレードオフではあるけど。

383 ：デフォルトの名無しさん：2005/12/14(水) 16:12:58

縮小専用なら面積平均法でいいんでない？
速い綺麗簡単の三拍子

384 ：デフォルトの名無しさん：2005/12/14(水) 16:17:36

速いか？Lanczosなんかと比べてってだけ？

385 ：デフォルトの名無しさん：2005/12/14(水) 16:29:26

縮小で、アルゴリズムを選択するなら、
ニアレストネイバー・バイリニア・面積平均法・Lanczos3ってとこかね

見栄えの綺麗さ Lanczos＞面積平均法＞＞バイリニア＞（超えられない壁）＞ニアレストネイバー
計算量の少なさニアレストネイバー＞＞バイリニア＞＞面積平均法＞＞Lanczos
画像圧縮効率　ニアレストネイバー＞（超えられない壁）＞バイリニア＞面積平均法＞＞Lanczos

かな？
ゲームなんかじゃ、バイリニアが多いよね。
速度と綺麗さのバランスが良くて。
Lanczos3は、シャープネスがかかって見栄えがいいけど、計算量は多いし、圧縮画像が大きくなるんだよな。

386 ：デフォルトの名無しさん：2005/12/14(水) 16:45:13

バイリニアって1/2以下の縮小でも画質的に使い物になるの？

387 ：デフォルトの名無しさん：2005/12/14(水) 17:31:21

その1/2ってのがどこから出てきたのかな？

388 ：386じゃないけど：2005/12/14(水) 17:34:56

近傍2画素、縦横4画素を参照するから、でしょ。
同様にバイキュービックは16画素参照になるから、1/4以下への縮小は
やっぱり汚くなる気がするんだけど・・・なんか認識まちがってる？

リサイズとリサンプルの違いがよくわからん。
Lanczos3は、単純に36画素参照ではないのん？

389 ：デフォルトの名無しさん：2005/12/14(水) 17:35:05

多分、バイリニアで1/2未満にすると、参照されない元ピクセルが出てくるから、ってことじゃないの。

理にはかなっているな。

390 ：デフォルトの名無しさん：2005/12/14(水) 17:37:16

>>388
重み付けがLanczos窓関数によるわけだけど、
どうも、いろんなLanczosを採用したアプリをいくつか比べてみると、
結構出力画像が違うんだよな

それぞれのアプリで結構味付けをしているっぽい

391 ：デフォルトの名無しさん：2005/12/14(水) 17:38:53

ちょっきり1/2でもひとつおきに参照されないしょ。小数部がないから。

392 ：デフォルトの名無しさん：2005/12/14(水) 17:47:15

>>391

ちょっきり整数分の１はバイリニア＝ニアレストネイバーだわね

393 ：デフォルトの名無しさん：2005/12/14(水) 21:34:48

>>387
>その1/2ってのがどこから出てきたのかな？
サンプリング定理じゃまいか？

394 ：デフォルトの名無しさん：2005/12/14(水) 21:36:17

画像処理嫌い。エムペグ視ね！視ネイsねいんしねいんしねいんしにえｗにｓにｓにｓ

395 ：デフォルトの名無しさん：2005/12/14(水) 21:58:05

まあ、なんというか、画像処理は面白いよな。
結果がすぐ見えるから。

396 ：デフォルトの名無しさん：2005/12/14(水) 23:25:59

でも濃淡画像を数百枚もテンプレートマッチングしたり、数枚を10数段のフィルタリングしたり、
数千画素の画像を扱ったりしていると結果をすぐ見るって訳に行かなくて困る。

397 ：デフォルトの名無しさん：2005/12/14(水) 23:31:37

画像処理はどんなところで使われるのですか？
映像関係や工場などでの製品検査などがあると思うのですが、
他にはどんなものがあるでしょうか？

398 ：デフォルトの名無しさん：2005/12/14(水) 23:35:25

>>397
＞工場などでの製品検査
これだけとっても滅茶苦茶幅が広い。

399 ：デフォルトの名無しさん：2005/12/14(水) 23:37:11

テレビの番組がドラマとニュースとCMでそれぞれ画質が違う
フィルタが掛かってる

400 ：デフォルトの名無しさん：2005/12/15(木) 02:05:25

>>397
軍事用のミサイルも画像処理を使うぞ。

401 ：デフォルトの名無しさん：2005/12/15(木) 02:06:24

>>395
それしかできないから好きなタイプだな。

402 ：デフォルトの名無しさん：2005/12/15(木) 02:11:56

>>401
それさえ出来ないから皮肉るタイプだな

403 ：デフォルトの名無しさん：2005/12/15(木) 02:13:35

>>402
皮肉ってないよ

404 ：デフォルトの名無しさん：2005/12/15(木) 02:19:47

結果が多少バグってても見つかりにくいからだろうね

405 ：デフォルトの名無しさん：2005/12/15(木) 02:49:07

音声処理と比べれば楽なもんだ

406 ：397：2005/12/15(木) 10:04:19

>>398
そうなんですか。
画像処理で製造業に携わる機会が多そうですね。

>>399
たしかに違うかんじがしますよね。
これは芸術系、表現系ともいうべき分類になりそうですね。

>>400
たしかに誘導弾が赤外線カメラ画像から標的を捉えているような
映像を見たい事があります。
芸術から軍需まで幅広い･･･

将来、画像処理のお仕事をしたい場合、何を勉強するのが良いでしょうか？
フーリエ変換や行列、統計工学なんか良いですよね？
画像処理検定を受けてそう感じました。

407 ：デフォルトの名無しさん：2005/12/15(木) 11:34:36

>>406
ハードウェアも勉強しといた方がいいよ

408 ：デフォルトの名無しさん：2005/12/15(木) 12:17:18

>>406
それだけの画像処理のノウハウを役立てるにはそれなりの企業のそれなりの部署に就くか、
運良くそういう仕事にありつけるか、自分で営業するしかない。
学生なら、そういう企業に入れるように努力するのがいいかもしれない。

409 ：デフォルトの名無しさん：2005/12/15(木) 15:28:52

大学の研究室でそういう研究やってるとこに入り込むってのもいいかも

410 ：デフォルトの名無しさん：2005/12/15(木) 21:22:25

エムペグってわざと小難しくしてるだろ。しねしねいsんえいsネイsに絵にsに栄ｓにえんしえにｗｓにえんしえに

411 ：デフォルトの名無しさん：2005/12/15(木) 22:08:53

>> 406
CだけでなくVHDLやverlogもやった方がよいと思う。

412 ：デフォルトの名無しさん：2005/12/15(木) 22:15:14

>>411
ASICでも作るのか？ああDSPか。

413 ：デフォルトの名無しさん：2005/12/15(木) 22:33:05

なんで笑むペグって１，２、ってきて次が４なの？ばかじゃん
数もまともにカウントできねぇのかこのひねくれもの！！

414 ：デフォルトの名無しさん：2005/12/16(金) 02:27:35

>>412
アホですか？

415 ：397：2005/12/16(金) 10:06:16

みなさん、貴重なご意見ありがとうございますm(_ _)m

>>407
ハードウェア好きなので是非勉強したいです。

>>408
なるほど。
来年は就職活動なのですが、そういう事をやってそうな企業として
精密・光学機器メーカーを中心に考えています。
大きい企業なのでがんばりたいです。

>>409
研究室の担当教授は計測工学を専門としていて現在、画像処理をやっています。
自分のテーマはそれとは関係ないのですが、そういうのには触れやすい環境なので
恵まれていると思います。

>>411
そこらへんの言語も必要になってくるんですね。
マイコンをやろうと思っているので、まずはメジャーなCでやって、おいおいその他の
言語も勉強してみようと思います。

416 ：デフォルトの名無しさん：2005/12/16(金) 13:02:49

>>413
物事には理由があるんだよ。

417 ：デフォルトの名無しさん：2005/12/16(金) 13:18:56

>>413
三男が死んでも四男は三男に繰り上がったりはしないわけで。
民法にも文句家よ。

418 ：デフォルトの名無しさん：2005/12/16(金) 15:06:02

MPEG-7, MPEG-21の立場は？

419 ：デフォルトの名無しさん：2005/12/16(金) 21:36:22

4の次は７かよ。ﾌﾟおめでてーな
かっこいいと思ってんのか？コラ
コルァエムペグ

420 ：デフォルトの名無しさん：2005/12/16(金) 21:55:41

(・∀・)つ MPEG-2000

421 ：411：2005/12/16(金) 22:38:18

>> 412

ちゅうか、検査内容によるがリアルタイム画像処理
をやる場合、ソフト処理だけでパフォーマンスを稼
げるのか？？

漏れは、携帯端末の画像処理しかやった事ないんで
しらんが？

422 ：デフォルトの名無しさん：2005/12/17(土) 12:31:58

>>415
インターンも探してみれば？
結構インターンでそういう学生が来る職場にいます。
国内からのだと2週間ぐらい（まれに3ヶ月って長期のもいるが）、
海外からだと3ヶ月～半年くらい。

423 ：デフォルトの名無しさん：2005/12/18(日) 00:43:35

ddbで作成したbmpをaviファイルに変換したいのですが
何かいい方法はありませんでしょうか。

24fps, 100KB/枚, 平均bmp枚数600枚

424 ：デフォルトの名無しさん：2005/12/18(日) 12:10:58

>>423
aviutilあたりで読み込ませてみては？

425 ：423：2005/12/18(日) 13:24:48

ソフトウェア板でaviutilスレを見つけました。
そちらで質問してみたいと思います。
424さんありがとうございました。

426 ：デフォルトの名無しさん：2005/12/18(日) 17:58:12

　　　　　　　/＼＿＿_／ヽ
　　　　　／　　　　　　 :::::::＼
　　　　　.|　　　　　　　　　　.::::|
　　　　　|　 ''''''　　　''''''　　 .:::::|
　　　　　.|（●）,　　　､（●）､::::|
　　　　　＼　,,ﾉ(､_, )ヽ､,,.:::::／
　　　　　　／｀｀ｰﾆ=-'"一´＼
　　　　＿/((┃))＿＿＿＿_i　|＿　ｷｭｯｷｭｯ
　..　／ /ヽ,,⌒)￣￣￣￣（,,ノ　＼
　／　 /＿＿＿＿＿＿＿＿＿ヽ.. 　＼
　.￣￣￣￣￣￣￣￣￣￣￣￣￣￣

　　　　　　/＼＿＿_／ヽ
　　　　　／''''''　　　'''''':::::::＼
　　　　 . |（●）,　　　､（●）､.:|　＋
　　　　　|　　 ,,ﾉ(､_, )ヽ､,,　.::::|
　　　. 　 |　　｀-=ﾆ=- '　.:::::::|　+
　　　　　＼　　｀ﾆﾆ´　 .:::::／　　　　　+
　　　　　　／ヽ、ﾆ__ ーーノﾞ＼_
　　　　　.|.￣￣￣￣￣￣￣￣.|　　ﾄﾝ
　　　　_（,,)　>>397　　　　　　(,,）_
　　　　　.|　実装より理論　　|
　　　　　.|＿＿＿＿＿＿＿＿_|

427 ：デフォルトの名無しさん：2005/12/18(日) 18:06:14

画像処理は、「画像を見る人」がいるのが学問として三流なんだよな。

428 ：デフォルトの名無しさん：2005/12/18(日) 19:25:51

>>427
意味不明

429 ：デフォルトの名無しさん：2005/12/18(日) 19:33:56

>>428
主観に頼る部分がある、と言いたいんだろう

430 ：デフォルトの名無しさん：2005/12/18(日) 19:46:10

>>428
そんなレスしかできないとは・・・三流の中の三流か。

431 ：デフォルトの名無しさん：2005/12/18(日) 19:48:44

ここは釣り堀ではありません

432 ：デフォルトの名無しさん：2005/12/18(日) 20:54:59

そんな学問一杯ありそうだけど？
哲学、社会学、心理学
一流じゃない？

433 ：397：2005/12/18(日) 21:54:44

>>422
ありがとうございます。
インターン、探してみます。

434 ：デフォルトの名無しさん：2005/12/19(月) 00:37:20

>>432
哲学＝青鷺
社会学・心理学は客観的だからＯＫ

435 ：デフォルトの名無しさん：2005/12/19(月) 00:38:22

いや、社会学はそのときの政治的な理由でいろいろ解釈が変えられたりすることがあるから×か。

436 ：デフォルトの名無しさん：2005/12/19(月) 00:48:21

一般人のサンプリングなんて普通にやってるし。
確率論とか今じゃどの人文学でも必修だよ。
見る人ってのも結局一人じゃなくサンプル数が重要なので同じこと。

437 ：デフォルトの名無しさん：2005/12/19(月) 00:53:30

>>436
数字をどう解釈するかは人間次第だろう。
純粋数学じゃないんだから、数字だけを扱う訳ではない。

438 ：デフォルトの名無しさん：2005/12/19(月) 01:03:49

そのための確率論。

439 ：デフォルトの名無しさん：2005/12/19(月) 01:24:27

>>438
？？？？

440 ：デフォルトの名無しさん：2005/12/19(月) 01:27:42

関係ないけど、現代の心理学には
わけ分からん数式がいっぱいでてくるね。
数学なしじゃ成り立たない学問と成り果てたよ。

441 ：デフォルトの名無しさん：2005/12/19(月) 02:03:14

>>438
統計学では？

442 ：デフォルトの名無しさん：2005/12/19(月) 02:08:29

心理学の統計って↓みたいなイメージあるな。

世界中の研究者がアレコレ実験やって、
偶然有意な結果が出た者は論文を書く。
ごく稀には再検証でも偶然有意な結果が出る。

443 ：デフォルトの名無しさん：2005/12/19(月) 02:57:09

そういや心理学の講義ノートが数式の羅列だらけだった記憶があるなあ。
統計なんて簡単な数式じゃなくて。

444 ：デフォルトの名無しさん：2005/12/19(月) 08:45:35

多変量解析の手法をたくさん考え出してくれた心理学者には
画像処理もお世話になってまつ

445 ：デフォルトの名無しさん：2005/12/19(月) 22:36:21

>>34の人ってこのスレにまだいるのかな?

446 ：デフォルトの名無しさん：2005/12/19(月) 22:45:16

なんだい坊や？かまってほしいのかい？

447 ：デフォルトの名無しさん：2005/12/20(火) 23:35:39

>>444
ある事象が「偶然」に起こる確率がある数値以下（例えば５％）であるときに、「有意」とか「有意差」という言葉を使うのだから、「偶然有意な結果が出る」というのは妙な言い回しな気がする。

448 ：デフォルトの名無しさん：2005/12/20(火) 23:38:04

誤；>>444
正；>>442

449 ：デフォルトの名無しさん：2005/12/21(水) 02:05:57

>>447
統計論やりなおし。

450 ：デフォルトの名無しさん：2005/12/21(水) 23:23:13

>>449
推計論やりなおし。

451 ：デフォルトの名無しさん：2005/12/22(木) 06:41:38

>>451
人生やりなおし。

452 ：デフォルトの名無しさん：2005/12/22(木) 06:43:40

がんばれ

453 ：デフォルトの名無しさん：2005/12/23(金) 13:13:46

漏れも人生やりなおしたいよ

454 ：デフォルトの名無しさん：2005/12/24(土) 00:15:12

円に対するhough変換で、半径を決め打ちにして高速化するにはどうしたらいいんでしょうか。
ttp://homepage3.nifty.com/ishidate/vcpp6_g15/vcpp6_g15.htm
このページのコードを見ると、半径決め打ちって出来なさそうなのですが。。

455 ：デフォルトの名無しさん：2005/12/24(土) 01:08:49

>>454
半径固定なら、変換後の空間が3次元から2次元になるわけで、
それだけでもかなり高速化可能だろう。

あとは、変換元の点が変換先で円に対応することを考えれば、
高速な円描画アルゴリズムがあればよい。
キーワードはbresenham、michenerかな。

456 ：名無し募集中。。。：2005/12/24(土) 01:51:57

ハリセルダンの歴史心理学

457 ：デフォルトの名無しさん：2005/12/24(土) 02:36:04

>>455
ありがとうございます。
高速に円を描く方法があるとは知りませんでした。

458 ：デフォルトの名無しさん：2005/12/26(月) 03:47:49

ちょっとお聞きしたいのですが、ある画像が写真であるか絵であるかを
ＰＣに判別させる事は可能でしょうか。

459 ：デフォルトの名無しさん：2005/12/26(月) 07:05:49

OpenCVでカメラキャリブレーションを行いたいのですが、
カメラの内部パラメータを求めるcvCalibrateCameraの使い方が分かりません。
どなたか使い方を教えてください。

460 ：デフォルトの名無しさん：2005/12/26(月) 12:10:56

>>459
Zhangの論文、FAQ、ソース嫁。
手っ取り早くキャリブレーションしたいんだったら
http://w3.impa.br/~pcezar/3dp/original/CVL_html/appPage/doc_calib.html
CalibFilterかここのMatlab用のツールキットでも使え。

461 ：デフォルトの名無しさん：2005/12/26(月) 15:19:14

>>458
使われている色数やFFTでもして周波数分布見れば大体判る

462 ：デフォルトの名無しさん：2005/12/26(月) 17:01:57

>>461
ありがとうございます。判るんですか！なるほど。

例えば、Googleイメージ検索のオプションに
「検索する画像の種類」という項目つくって、検索対象から
「写真だけ」又は「絵だけ」を抽出するという事も出来そうですね。

あったら結構便利そうな機能なのに。
なんでやらないんだろう？

463 ：デフォルトの名無しさん：2005/12/26(月) 19:29:13

SIMDによる処理の高速化-アセンブラ画像処理プログラミング-
この本読んだ人いる?

464 ：デフォルトの名無しさん：2005/12/26(月) 19:40:12

たけー

465 ：デフォルトの名無しさん：2005/12/26(月) 19:46:51

x86アセンブラ入門
これ読んだ人いる？
買おうかどうか考えてるんだけど。
アセンブラ画像処理プログラミングの方が実践的でいいかなと思ったんだけど、いかんせん高すぎる。
両方読んでる人がいたらレビューが欲しいなと。
もしかしたら両方買うかも。

466 ：デフォルトの名無しさん：2005/12/26(月) 19:52:27

>SIMDによる処理の高速化

うお、魅力的だな・・・どうしたもんか

467 ：デフォルトの名無しさん：2005/12/26(月) 20:19:09

>>465
x86アセンブラ入門読んだよ。
全体の印象としては、安い金額相当の説明は十分載ってるって感じ。

SIMDの部分はIntelのPDF以外でSSE2の日本語解説ってほとんどなかったから使える。
ただし、SSEとSSE2を一緒に説明してて区別しにくい。
そしてなにより、CQの宿命か説明量がやや少ない。
表はよくまとまってるし、図やらソースやらは沢山載ってるんだけどね。

それ以外のところは標準的から心持ち少ない気がする程度。
これは簡潔にまとまってると考えれば見過ごせるレベル。
gasについても載ってるのがうれしい所。
索引がないのがやや困った所。目次見ればいいかもしれないけど。

林のアセンブラ本見たいな裏切られ方はしないから、安さに引かれて買ってみるのもありだと思うよ。

#俺がいった本屋ではなぜか入荷した本全部170P前後の部分でページに折れ目が付いてたんで注意。

468 ：デフォルトの名無しさん：2005/12/26(月) 20:21:51

おっしゃお年玉貰って両方買うわ。

469 ：デフォルトの名無しさん：2005/12/26(月) 20:26:12

（ﾟдﾟ）

470 ：デフォルトの名無しさん：2005/12/26(月) 21:15:50

ﾟ（ д ）ﾟ

471 ：デフォルトの名無しさん：2005/12/26(月) 23:09:42

>>458
写真の画像を手書きで作成できたら、判別は不能になる。
ってそういう話じゃないのかな…。

472 ：デフォルトの名無しさん：2005/12/27(火) 02:03:06

旨く減色すると２５６色にもなるし

473 ：458：2005/12/27(火) 05:35:55

>>471-472
うーん、確かに「写真みたいな絵」ってありますからねぇ。
人間さえも一瞬「これ写真？」って思うような緻密な絵ならば、
機械が判別するのは難しそうですね。

474 ：458：2005/12/27(火) 05:40:11

だったら、それぞれの可能性をパーセンテージで表すとか・・・かな？
「写真の可能性９５％　絵の可能性５％」とか。
んで、「写真の可能性○○％以上」の画像だけ、とか指定して抽出するとか。

475 ：デフォルトの名無しさん：2005/12/27(火) 06:09:50

誰が使うんだ、そんなもの

476 ：デフォルトの名無しさん：2005/12/27(火) 10:04:56

画像処理についてあまり詳しくないのですが質問させてください

カメラからの入力をＰＣ上で画像処理するためには大まかに分類して
「画像処理ボードを使用する方法」と
「ソフトウェア的に全てＰＣ上で処理する方法」の
２通りの方法があると思います。
それぞれメリット・デメリットはなんでしょうか？

素人考えでは、前者は速度で有利・後者はコストで有利、
といったところだと思うのですが・・・実際のところはどうなのかご教授下さい

477 ：デフォルトの名無しさん：2005/12/27(火) 13:09:06

>>476
画像処理ボードのメリット
○組み込み用小型PCとの併用（これがほとんど？最近ではPenMがあるからそうでもない？）
○CPUとの並列処理

くらいしか思いつかん。

478 ：デフォルトの名無しさん：2005/12/27(火) 18:20:28

>>474
「絵の写真」を絵らしいとするのか写真らしいとするのか
についてはどう思いますか？

479 ：デフォルトの名無しさん：2005/12/27(火) 18:26:09

>>475
虹か惨事かを見分けるんだろ？

>>458
半角行け

480 ：デフォルトの名無しさん：2005/12/27(火) 21:25:56

>>445
たまに見てる。なにか御意見いただけると幸せです

481 ：デフォルトの名無しさん：2005/12/28(水) 00:27:35

>>479
なるほど、絵か写真というと必ず478のような奴が現れるから、二時か三時とすればいい訳だな。
ところで、二時と三時を見分けて何に使うのか？>>458
まだ用途が見えない。

482 ：デフォルトの名無しさん：2005/12/28(水) 00:37:50

絵って絵画だよね？油絵とか？
2次、3次を見分けるのって、周波数成分で見ても難しそう。
微分して変化量を見ても（輪郭抽出とか）判別つかない気がする。

483 ：デフォルトの名無しさん：2005/12/28(水) 00:51:50

>>476
高速にカメラから入力しようとすれば、絶対カメラ入力用のボードが必要になる。
そんなことは考慮してる？

グラバーにFPGAだの、画像処理プロセッサだのが載ったのを使う手もあるわけだ。

484 ：デフォルトの名無しさん：2005/12/28(水) 03:57:44

OpenCV を使ってみようと思ったのですが、
zsh: illegal hardware instruction
というメッセージが出てサンプルプログラムが使えません。

もしかして、intel のライブラリだから、インテルのCPUでしか使えないのですか？
千奈美に、私は VIA C3 プロセッサを使っています。

485 ：458：2005/12/28(水) 05:16:38

>>478
例えば絵の表面に局所的に光源からの反射が映り込んでいれば、それを元に
写真だと判別できるかも・・・？　でも、スキャナで取り込むのと同じ位
自然な状態で撮影されたら見分けが付かなさそうですね。　＞絵の写真

>>479
まぁそんなところです（笑）　＞虹か惨事か
後はその画像が人物なのか、物なのか、風景なのか、図表なのか等判別できると、
Googleで画像探すとき色々と楽になりそう。
Googleがそういうサービス始めてくれないかなぁ？

486 ：458：2005/12/28(水) 05:56:20

>>481
えーと・・・すみません、白状します。
解りやすく言うと、例えば「萌え」で画像検索して出てくるもののうち、
2次元の物だけ集められたら便利だな～、とかいう素朴な、かつ頭悪い疑問から
質問させていただいた訳です・・・orz

>>482
いえ、自分が考えてるのはイラスト・・・つーか、漫画やアニメの方です。
漫画やアニメって輪郭線がはっきりしてますよね？　だから判別しやすい
んじゃないかと思うんだけどなぁ・・・。これだけ「ヲタ文化は金になる」
とか騒がれてる昨今、絶対需要はあると思うんですが・・・

あとついでに言えば、あるテーマで調べ物をしているときに、関連するグラフだけ
集めてくるとか・・・図だけ集めてくるとか・・・
そういう方向の実用性もあると思います。

487 ：デフォルトの名無しさん：2005/12/28(水) 06:26:38

肌色の多い画像を集めてくるとか、そういうことだな

488 ：458：2005/12/28(水) 06:31:45

その手があったか（笑）
でもそれだと２次と３次の区別がつかないね。

489 ：デフォルトの名無しさん：2005/12/28(水) 07:05:21

で、相撲取りやプロレスラーの画像が混ざるわけだな

490 ：458：2005/12/28(水) 07:13:04

（486への自己レス）
＞輪郭線がはっきりしてる

輪郭の境界がはっきりしてるのは写真も同じか。
輪郭が有限の幅を持つ線で描かれている事を目安に判別すればいいかな？
あとセル画調のイラストなら色数が少ないこと、そして色が非連続に変化すること、
の２点を目安に判別できるかな？

491 ：458：2005/12/28(水) 07:16:49

>>489
わはは！あり得るｗ

492 ：デフォルトの名無しさん：2005/12/28(水) 09:20:10

ニューロとか遺伝的アルゴリズムで、学習させていくのも面白白そうな
テーマではあるが

493 ：デフォルトの名無しさん：2005/12/28(水) 10:19:49

>>489
現実的でﾜﾛﾀｗ

494 ：デフォルトの名無しさん：2005/12/28(水) 11:08:18

>>492
萌えを理解するプログラムか・・・実行したくねぇｗ

495 ：デフォルトの名無しさん：2005/12/28(水) 11:46:16

虹は同じ色が連続しやすく、惨事はそうでない。

496 ：デフォルトの名無しさん：2005/12/28(水) 12:15:47

そんな単純なアルゴリズムが通用すれば苦労はしないのだけどね。

497 ：476：2005/12/28(水) 12:43:23

>>477, >>483
お二人が上で指摘してくださった事を考えるに、
「画像処理ボードは速度が要求される環境下で必要とされている」
という理解で良いようですね。

例えば、「数msecの時間間隔で物体の変位を認識・処理」のような場合で
ソフトウェア的なアプローチのみではCPUがリアルタイムに処理仕切れない、
そんな状況で画像処理ボートが必要とされている、といったところでしょうか。

逆に見れば、このままCPUの性能が右肩上がりで進歩すれば、ソフトウェア的な
アプローチは重要性と比重を増していくといった事も言えそうですね。

どうもレスありがとうございました！　参考になりますー

498 ：デフォルトの名無しさん：2005/12/28(水) 13:02:19

>>497
CPUの性能が上がると同時に、処理する画像の解像度が上がるから画像処理ボードは不要にならない罠。

499 ：デフォルトの名無しさん：2005/12/28(水) 13:05:02

>>497
もう１点。
CPUＵは右肩あがりだけど、ﾊﾞｽの大域幅は段階的というか固定なので、
CPUに処理させるための元映像を望みのﾚｲﾃﾝｼで転送できるかどうかで選択肢が変わる。

ボード側の独自のメモリ積んでて、そこで処理させて、結果のみをﾊﾞｽに流すとか
ボード側は小さいFIFOﾊﾞｯﾌｧのみで DMA 転送してるとか
元映像自体の更新速度は数百ms オーダーで十分だから USB2.0 でちまちまもらうとか

500 ：名無し募集中。。。：2005/12/28(水) 22:45:49

NTSCで30fps。偶数奇数フィールドを別に処理しても60fps。
1画像をキャプチャするのに33(16)msがかかるわけで、
「数msecの時間間隔で物体の変位を認識・処理」というのは処理能力以前の話
# 一番近いアプリケーションとしてはビデオ信号オートフォーカスかな

501 ：デフォルトの名無しさん：2005/12/28(水) 23:19:15

なんか後処理があるんじゃないのか？
画像認識処理に数msしか掛けられないような重い処理が待ち構えているんだと思う。

502 ：デフォルトの名無しさん：2005/12/29(木) 04:12:23

最近、自前のプログラム（公開はしてない）に組み込もうとRichardson-Lucy Algorithmってのを
調べ始めたんですが、詳しい方います？

拡大・縮小ともにかなり綺麗だし、海外のページをヘロヘロと読んでると
実装が簡単とか、高速で少メモリとか、良く知られた人気のアルゴリズムとか
そんな紹介がされているんだが、今まで聞いたこと無いよ（泣。

503 ：476：2005/12/29(木) 14:25:49

>>497
>>498, >>499
おぉぉぉぉぉ・・・
そこまで考えが至っていませんでした、甘かったです。
特に転送速度の方は仕様に直結ですね。そのあたりもこの先勉強させて頂きます！
貴重なアドバイスどうもありがとうございます！

>>500
確かに！　カメラの仕様は要注意ですね！
// 一応、自分が497を書いた時点で念頭にあったのは
// Windowsのタイマー最小値と処理速度でした。
// 　「Windowsってたしか頑張っても10msecオーダーだったような
// 　気がするし、もう一個ケタ下げて『数msec』って書いとくかー！」
// ってノリで。　（OSに関してはリアルタイムOSの選択肢もありますけどとりあえずWinで。）
// しかし、「画像」処理に関してはOS云々よりカメラの周期のほうが根本的問題ですよねー・・・。
肝に銘じておきます、ありがとうございます！

>>501
ハイ！　画像処理と並行にオンラインで「後処理」をブリブリさせようと目論んでいます。
なんで、画像認識処理は可能な限り短い時間が望ましいです。その意味では
数msecを狙いたいです！・・・500に対しての言い訳みたいですが（笑

画像処理、奥が深いですね。気を引き締めて頑張りたいと思います！
皆さん本当にご意見・コメントありがとうございました！

504 ：デフォルトの名無しさん：2005/12/29(木) 14:32:52

>>500
カメラがNTSCだけとはかぎらんだろ。

505 ：名無し募集中。。。：2005/12/29(木) 23:09:53

質問者はソフトの実行速度しか頭に無いみたいだから
NTSCを例に挙げたけど、見直すと例を挙げたように書いてなかったね
I/FにはCameraLinkとかLVDSとかいろいろあるが、フレームレートも高く
画像サイズも大きいとPCIバスの帯域を超える心配をしないといけなくなる
最近はﾌﾚｰﾑｸﾞﾗﾊﾞの2枚刺しで同時取り込みだと帯域overになる事も考慮してる

506 ：デフォルトの名無しさん：2005/12/29(木) 23:33:25

２枚の画像を比較して「似ている画像」か「まったく別な画像」かをできるだけ高速に判断したいんですが、
なにかいい手法があれば教えてください。

507 ：デフォルトの名無しさん：2005/12/30(金) 00:10:14

自分で作るのが目的なの？
そうじゃなきゃ、もうあるよ。

508 ：デフォルトの名無しさん：2005/12/30(金) 00:13:56

ここは自分で作る人が集まる板だと思っていたんだが違うのか？

509 ：デフォルトの名無しさん：2005/12/30(金) 00:36:06

>>507
くわしく

510 ：デフォルトの名無しさん：2005/12/30(金) 00:45:17

画像比較ツール　でぐぐれ

511 ：名無し募集中。。。：2005/12/30(金) 01:41:32

xorして積算

512 ：デフォルトの名無しさん：2005/12/30(金) 02:31:57

>>484
i686固有な命令例えばcmovとかだけど、こいつらが悪さしてるんだろうね。
エラー見る限りLinux環境なひとだよね？
コンパイルする時にMakefiles, cvconfig.hの-march="i686" and -mcpu="i686"を -march="c3" -mcpu="c3"とかにすればいいんじゃないか？
ちゃんと動くかしらんけど。

513 ：デフォルトの名無しさん：2005/12/30(金) 07:20:17

>507 AbleCV
http://member.nifty.ne.jp/h_c_yoda/

514 ：デフォルトの名無しさん：2005/12/30(金) 11:11:44

その「画像比較ツール」のアルゴリズムが知りたい

515 ：506：2005/12/30(金) 12:11:01

説明不足ですみません。
そういうツールを使いたいのではなく、自作のアプリ内で画像が似ているかどうか判断したいのです。

例えば動物園で撮影した写真画像が何万枚もあったとして、ライオンの画像と像の画像は当然分けて、
同じライオンでも顔のアップ写真と全身写真と遠くから写した写真はそれぞれ分類したい。

ライオンを同じような構図で写したのであれば、ライオンの顔の向きやポーズが多少違っても
似ていると判断したいのです。

対象の画像の枚数が多いため、「あきらかに違う画像」を高速にはじければ全体の処理速度
があげられると思ってるのですが、できるだけ少ない計算量で「明らかに違う画像」
を判断する方法はないでしょうか。
とりあえず今は、二枚の画像のRGB/HSBの平均値を比較するやり方でやってます。

516 ：デフォルトの名無しさん：2005/12/30(金) 12:21:52

>>515
人の顔画像の認識なら有名だけど、全体の認識は難しいと思う。

517 ：デフォルトの名無しさん：2005/12/30(金) 14:34:21

ブロック単位で輝度平均を比較するとか。

518 ：デフォルトの名無しさん：2005/12/30(金) 15:14:30

こういうのはどうだろうか？まずスクリーン全体を16x16とかのブロックに分割して
ブロックの平均色と周波数分布を求める。
次にブロック単位でなめながら平均色とグレースケールの周波数分布が近いモノが隣にあれば
「なると」形状に大きくしながら特長点として登録する。極端に変われば打ち止め。
グレースケールにするのは高速化の為ね。

比較するときは「なると」のデカイものから順に座標、平均色、周波数分布が近いモノを「同じ」
と認識して一定数以上マッチしたら似ている画像と認識。前処理の「なると」作成には時間が
かかるが比較は早いってわけ。あと座標と「なると」サイズをスケーリングすれば
解像度の違う画像も平気。
たった今適当に考えたけど多分誰か似たような方法でペーパー出してるんじゃないかな。

519 ：デフォルトの名無しさん：2005/12/30(金) 16:36:49

http://pc7.2ch.net/test/read.cgi/software/997665607/
に類似画像判定法を妄想しているレスがいくつかついてる。

類似画像判定ソフトの用途の９９％はエロ画像の整理のようだが。

520 ：デフォルトの名無しさん：2005/12/30(金) 22:03:46

>>515
成果がでたら論文なり学会発表なりしてくれ。

521 ：デフォルトの名無しさん：2005/12/30(金) 23:10:32

>>515
HSBの平均値って色相もそのまま平均とってるの？

522 ：デフォルトの名無しさん：2005/12/31(土) 02:28:09

画像間のズレを検出するためにテンプレートマッチングで相関を
とっていくプログラムを作っているのですが、馬鹿正直に画像の隅々まで相関係数を
式通りに求めているからか処理がとても遅いです。
何か高速化するためのいい工夫はないでしょうか？

523 ：デフォルトの名無しさん：2005/12/31(土) 02:57:41

>>522
>>340あたりから同じこと議論してるじゃん。

524 ：デフォルトの名無しさん：2006/01/01(日) 02:28:22

カラー画像同士の相関係数って、どうやって求めたら良いでしょうか？
RGBそれぞれで求めて平均とか取るんでしょうか？

525 ：デフォルトの名無しさん：2006/01/01(日) 10:41:41

リサイズ方法として、Photoshopでは、
ニアレストレイバー法とバイリニア法とバイキュービック法があります。
難しいことは抜きにして、一般的にはバイキュービック法がキレイにリサイズできるということが分かりました。

一方、IrfanViewというソフトで同様の機能にリサイズ/リサンプルというものがありますが、
こちらはリサンプルフィルタとして、さまざまなフィルタがあります。
そのうちの、Lanczosフィルタが高画質と書いてありました。
疑問として、バイキュービック法とLanczosフィルタの特徴と違い
そして、Photoshopのバイキュービック法とIrfan ViewのLanczosフィルタ
のどちらが高画質なのか教えていただけないでしょうか？

526 ：デフォルトの名無しさん：2006/01/01(日) 11:36:13

Irfan ViewのLanczosフィルタでしょ。遅いけど。

527 ：デフォルトの名無しさん：2006/01/01(日) 11:38:28

> バイキュービック法とLanczosフィルタの特徴と違い

うーむ、補間関数が違う。補間について一般的な知識があれば、こんな質問しないでしょうけど。

528 ：デフォルトの名無しさん：2006/01/01(日) 11:42:29

Lanczosのほうがキレイっぽい。

529 ：デフォルトの名無しさん：2006/01/01(日) 11:47:19

>>528
ありがとうございました。

530 ：デフォルトの名無しさん：2006/01/01(日) 12:33:13

>>529
Irfanviewで画像を縮小するときは、バイリニアしか使えない仕様になってますので、
画像を縮小する時は、ほかのソフトを使用した方がいいと思いますよ。

531 ：デフォルトの名無しさん：2006/01/01(日) 13:16:27

超解像に興味ある者です。

実体Xから画像になる仮定をモデル化（動き・PSF・サンプリング・雑音）
して、複数の観測値Ynとの誤差が少なくなるように推定するみたいです
が、動きがない場合には単純に複数画像を平均化して逆フィルタを
かけることと似たことにならないでしょうか。

ttp://www.cse.ucsc.edu/~milanfar/SR/sr-examples.htm
これを見ると脅威的だけど、先ほどの単純な方法では
絶対なりそうにないけど・・・

532 ：531：2006/01/01(日) 14:42:04

>>502
Lucy Algorithmはdeblurの時に使う逆フィルタの一種ではないですか？
拡大縮小にも使えるのかな。周波数空間での拡大方法で拡大した画像の
周波数画像に元の画像の周波数成分をそのままコピーしてその他は
ゼロを埋める、という方法がありますが、それと関連あるのでしょうかね。

533 ：デフォルトの名無しさん：2006/01/01(日) 22:28:47

>>531
驚異的･･･

534 ：デフォルトの名無しさん：2006/01/02(月) 00:21:42

胸囲的・・・

535 ：デフォルトの名無しさん：2006/01/02(月) 00:36:08

一番下の凄いな。
個人的には、服だけを透視するカメラに匹敵する凄さだ。

536 ：デフォルトの名無しさん：2006/01/02(月) 01:01:28

動画から動画を生成って処が味噌なのかな?

537 ：デフォルトの名無しさん：2006/01/02(月) 01:19:18

エッジの接線を出すのはどうしたらよいですか？
適当に近傍の2点の傾きから出しているのですがあまり正確でない…

538 ：デフォルトの名無しさん：2006/01/02(月) 11:23:38

>>531
これは素晴らしいね。
技術的に可能であろう事は想像に難くないけど、
現実的なアルゴリズムを完成させて実装しているのは驚愕と尊敬に値する。

539 ：デフォルトの名無しさん：2006/01/02(月) 12:18:53

静止画の方は、薄目にすると両方同じに見えるから、なんとか頑張れば・・・
とか思うけど、動画の方はすごいね。複数の画像のなんらかの平均じゃなくて
どうしたらいいのか・・・・

540 ：デフォルトの名無しさん：2006/01/02(月) 15:00:09

531を見てみんな同じことを考えたはずだが、誰も言おうとしないなｗ

541 ：デフォルトの名無しさん：2006/01/02(月) 15:19:38

MOSAIC

542 ：デフォルトの名無しさん：2006/01/02(月) 16:09:48

しかし薄目でみるより解像度が上がってる感じじゃないから、モザイクを処理しても
あまり興奮しそうもないけどね

543 ：デフォルトの名無しさん：2006/01/02(月) 16:24:10

そういうことかｗ
ﾜﾛﾀｗ

544 ：デフォルトの名無しさん：2006/01/02(月) 16:28:07

古いネタだけど
【ソフトウェア】万華鏡写輪眼って
http://pc7.2ch.net/test/read.cgi/software/1121271094/

545 ：デフォルトの名無しさん：2006/01/02(月) 23:08:04

どうやら単純に平均を取るのではなく、
画像のサブピクセルレベルの微妙なズレを検出して
拡大画像に貼り付けて空間解像度を稼いでいる（Shift&Add）
あとは誤差を絶対値で測る、正則化等の画像回復のテクニックを
駆使している模様。

>>539
よく見ると一番下のは動画出力だったのですね。
フレーム間の画像のマッチングがうまくいけば
可能なんでしょうね。

546 ：デフォルトの名無しさん：2006/01/02(月) 23:19:37

>>545
論文読んで言ってるの？
こういうのって最尤推定だとかの言葉が出てくるんだと思うけど。

547 ：デフォルトの名無しさん：2006/01/02(月) 23:32:20

>>546
はい、読んでいるところです。実は画像回復は素人ですが、
面白そうだし式は載っているので作ってみようかなーという
感じです。L1ノルムでの最小化は最尤推定になるという
記述はありました。

548 ：デフォルトの名無しさん：2006/01/02(月) 23:52:16

>>547
アプリはリンク先のサイトにあったんじゃない？
車輪の最発明乙。
つーのは嘘で、俺も興味あるから作業の進捗でもここに書き込んでください。

549 ：531：2006/01/03(火) 00:58:37

再発明でもなんでもないですけどね
真似して作るのが趣味なんです
形になればまた書きます

550 ：名無し募集中。。。：2006/01/03(火) 01:16:51

アプリケーションは置いていないみたいだったけど？

551 ：デフォルトの名無しさん：2006/01/03(火) 10:30:14

>>548
車輪の再発明の意味を全くわかってない予感。
論文見ながら実装するのは再発明でもなんでもないぞ。

552 ：デフォルトの名無しさん：2006/01/03(火) 19:35:34

こまかいな

553 ：デフォルトの名無しさん：2006/01/03(火) 19:41:32

>>547
MATLABベースのツールが置いてあるよ。
>>551
分かってないのはお前。

554 ：デフォルトの名無しさん：2006/01/03(火) 19:46:53

>>553
分かってないのはお前。
「再実装は無駄」という文脈で車輪の再発明という言葉を使うのは知ったか君。

555 ：デフォルトの名無しさん：2006/01/03(火) 19:52:55

言葉の定義は置いといて、

ソース引っ張ってこれるならともかく、理屈しかないなら
自分で実装するしかあるまい。

556 ：デフォルトの名無しさん：2006/01/03(火) 19:56:31

　　　　　　　　　　　　＿＿/　　/　|　　　＿＿　　──
　─　/　　/　＼　○　　　|　　 /　 |　　　　 |　　　￣￣/　──
　＿/　　/　　　＼　　　　|　　/　　レ　　─┴─　　＿/

　　　　　　/＼＿＿_／ヽ　　　
　　　　／''''''　　　'''''':::::::＼　　　
　　　 . |（〇）,　　　､（〇）､.:|　
　　　　|　　 ,,ﾉ(､_, )ヽ､,,　.::::|　　　
　　. 　 |　　｀,rｪｪｪ､ '　.:::::::|　
　　　　＼　　|,ｒ-ｒ-|　 .::::／　　　　　
　　,,.....イ.ヽヽ、｀ﾆﾆ´ーノﾞ-､.
　　:　　| 　';　＼_____ ノ.| ヽ　i
　　　　 |　　＼/ﾞ（__)＼,| 　i　|
　　　　＞　　ヽ. ハ　 | 　 |｜

557 ：556：2006/01/03(火) 19:57:33

間違えた。
Matlabベースのツールならソース読めるよ。

558 ：デフォルトの名無しさん：2006/01/03(火) 20:14:19

556がどのスレを荒そうとしてここに誤爆ったのか気になる。

559 ：デフォルトの名無しさん：2006/01/03(火) 21:50:39

新規性があるかどうかが研究としては重要。
実装をする上で新しい事が解ったなら、それは立派な研究だよ。

560 ：デフォルトの名無しさん：2006/01/03(火) 21:58:12

「つーのは嘘で、」を無視して外野で大議論。
それがVIPクオリティ。

561 ：デフォルトの名無しさん：2006/01/04(水) 01:23:06

　＿＿　　　　＿＿　　　　　　ｎ　　　　　＿＿＿＿＿　　＿＿＿＿_　　　　___　___　　　___
　|　　 |　　　 /　　/　　　　　　/ /　　　　/　　　　　　　|　/＿＿　　__/ [][] ＿|　|_|　|＿_　_|　|_
　| 　　|.　　 /　　/ 　　　／⌒ヽ/　　　 /　　 /￣￣|.　l　　　　/　/　　　　 |　　　＿　　| |_　　ﾚ'~￣|
　|　　 |　　/　　/　　　（＾ω＾ )　　　 /　　 /.　　／　/　　　　|　 |___ 　　　￣| 　|　/　/　/ 　／|　|
　|　　 |　 /　　/　　　ﾉ/ /　ﾉ　　　/　　　￣￣　／　　　　　＼＿_|　　　　　| 　|　￣　/_　 /　　|　|_
　| 　　|. /　　/　　　／/ /　ノ　　 /　　 /￣￣￣　　　　　　　　　　　　　　　|＿|　　　　 |__|　　　＼/
　|　　 |/　　/　 ⊂（　し'.／　　　　/　　 /　　
　|.　　　　 /　　　 |　ﾉ'　　　　　 /　　 /　　　　　　　　　　　　　　　　　　　　　ニュー速VIP
　|　　　　/. 　　　　し' 　　　　　./　　 /　　　　　　　　　　　　　　　　　　http://ex14.2ch.net/news4vip/
　￣￣￣　　　　　　　　　　　　￣￣

562 ：名無し募集中。。。：2006/01/04(水) 02:50:52

VIPPERに画像処理する人っているのか？
という俺は狼住人

563 ：デフォルトの名無しさん：2006/01/04(水) 21:46:54

研究室の学生全員Vipperですが何か？

564 ：デフォルトの名無しさん：2006/01/04(水) 22:09:17

助教授でVipperですが何か？

565 ：デフォルトの名無しさん：2006/01/04(水) 22:16:41

教授と助教授の違いってなんですか？

566 ：デフォルトの名無しさん：2006/01/04(水) 23:11:00

校長と教頭の違いと同じ

567 ：デフォルトの名無しさん：2006/01/04(水) 23:40:41

教授=お山の大将
助教授=奴隷頭
その他=奴隷

568 ：デフォルトの名無しさん：2006/01/05(木) 00:11:11

そういうのは大学によって違うよ。
講師も助教授も教授も位が違うだけで同じ教職だ、というような認識の大学もあれば、
完全な上下関係で成り立っているところもある。

569 ：デフォルトの名無しさん：2006/01/05(木) 01:33:23

小講座制度とか大講座制度とかの違いかな。
どちらもメリット・デメリットがあるし、すれ違い。

570 ：デフォルトの名無しさん：2006/01/05(木) 16:48:07

平均値シフト(mean-shift)のアルゴリズムについて質問なのだが、
輝度値をRGBで分けたほうがいいのか(r[64],g[64],b[64])、まとめたほうがいいのか(rgb[8][8][8])で困っている。

調べたところ分けた手法が見つかった(最後に足している)のだが，その場合黒を対象にした赤は2/3の重みを持つから、
まとめたほうがいいのではないかという気がしてきた。
ご教授お願いいたします。

571 ：デフォルトの名無しさん：2006/01/05(木) 17:11:32

単純にメモリとかはどうなの？
(r[64],g[64],b[64])なら192バイトだし
(rgb[8][8][8])なら512バイトだし

572 ：デフォルトの名無しさん：2006/01/05(木) 17:34:01

速度やメモリに関しては分けた方が優れていることはわかるのですが、
正確性を考えるとrgb[8][8][8]のほうが上なんじゃないかと思うんです。

なぜ輝度を3つに分けて最後に足すのかが・・・
実際に作ってみて分けててもほぼ正常に動作したんですが、何故分けなくても正確に動作したのかが・・・？なので。。。

重みが大きいほうに移動するプログラムで、一発で位置を指定しなくてもいいから分けてもいいということなんだろうか・・・？

573 ：531：2006/01/05(木) 20:28:44

531のリンク先の論文を参考に
２０枚の低解像度画像から高解像度画像を推定する
テストプログラムができました。まだ正則化はやってません。

ttp://g0307.hp.infoseek.co.jp/SRtest_ver1.0.zip

574 ：デフォルトの名無しさん：2006/01/05(木) 21:12:02

>>573
仕事はやいっすね～！

575 ：デフォルトの名無しさん：2006/01/05(木) 21:15:10

>>573
ウィルス！

576 ：デフォルトの名無しさん：2006/01/05(木) 21:54:11

ウィルスバスターじゃ検出されなかった･･･けど？

577 ：名無し募集中。。。：2006/01/05(木) 21:57:38

実行したら画像が出来たよ
ウィルスを疑うのは当たりまえだが作者には失礼に当たるからね

578 ：デフォルトの名無しさん：2006/01/05(木) 23:07:37

使ってみたけどすげーな。
この速さで実装なんてすごすぎ。
俺なんて論文読む時点で挫折したぜ。
バージョンアップ期待。

579 ：デフォルトの名無しさん：2006/01/06(金) 01:03:09

>>576
ウィルスなんて作ればいくらでもあるだろ。
今回は違ったようだがな！

580 ：名無し募集中。。。：2006/01/06(金) 03:39:01

使ってみたけどよくわからないのは論文を読んでないから
ザクっと解説してくれまいか

581 ：デフォルトの名無しさん：2006/01/06(金) 09:27:38

カメラ側を微小角振動してたくさんの枚数を取り込めば超解像処理ソフト
だけでズームアップ処理ができるのかな？

582 ：デフォルトの名無しさん：2006/01/06(金) 09:34:55

>>581
それだと、手振れみたいにボケちゃうんじゃない？

583 ：デフォルトの名無しさん：2006/01/06(金) 10:22:31

普通に何回も対象を撮影するだけで微妙にずれるので
そのあと超解像処理

584 ：531：2006/01/06(金) 13:51:33

少し修整。
ttp://g0307.hp.infoseek.co.jp/SRtest_ver1.1.zip

>580
複数の画像が重なるようにサブピクセルで位置合わせしたあと
推定したい画像と複数画像の各ピクセル値の絶対誤差の和が
少なくなるように、推定したい画像のピクセル値を足したり
引いたりしてるだけです。サブピクセル位置合わせも
単に拡大した画像でブロックマッチングをやってるだけ。

585 ：デフォルトの名無しさん：2006/01/07(土) 03:08:49

>>584
step2で落ちます(涙

586 ：デフォルトの名無しさん：2006/01/07(土) 16:47:15

技術的なことだけど、MFC以外にライブラリとか使ってないの？
しんどくない？

587 ：デフォルトの名無しさん：2006/01/07(土) 16:49:16

>>584
おい、ソースはどうした？

588 ：デフォルトの名無しさん：2006/01/07(土) 16:50:13

ソースないと本当に正しくアルゴリズムが実装できているか判断できないだろ

589 ：デフォルトの名無しさん：2006/01/07(土) 17:30:35

それ以前に、アルゴリズムが正確に実装できているか判断するには論文の内容を理解する必要があるのでは？

ってかアルゴリズムが理解できてるんなら他人のソースなんか興味ないけどなぁ・・・
ってのはオレだけ？

590 ：デフォルトの名無しさん：2006/01/07(土) 17:45:14

>>589
自分が理解するだけならそれでも良い。
しかし、これは他人のためなんだよ。

591 ：デフォルトの名無しさん：2006/01/07(土) 18:24:49

>>585
同じく。
デバッガ走らせてみたらSSE2だったから
SSEまでのAthlonXPでは動かないぽ。

>>589
釣りにマジレry

592 ：デフォルトの名無しさん：2006/01/07(土) 18:40:26

実行結果と処理内容の簡単な説明があれば十分だよな。

593 ：デフォルトの名無しさん：2006/01/07(土) 19:06:53

正直に見せられるような出来映えのソースじゃないっていえよ

594 ：デフォルトの名無しさん：2006/01/07(土) 19:29:08

>>589
おれもそう思う。

595 ：531：2006/01/07(土) 20:30:44

>>585, >>591
そうですブロックマッチングでSSE2を使ってます。
画像間の位置あわせは対象物が静止しているなら、
カメラの動きを推定した方が処理も速いし正確だと思います。
この部分は重要だけど上の論文の範疇ではないです。

ソースですが汚いのはもちろん、クラス自体に別の内容が
含まれているので、その部分を整理するのが面倒です。
整理できれば公開するかもしれません。

596 ：tana：2006/01/08(日) 16:01:50

あのオプティカルフローについての質問です。
あるサイズの画像（例えば縦i＊横j）があってその中に剛性を持った動物体が
移動している場合、ｎ番目のフレームと（n+1）番目のフレームの
オプティカルフロー（u,v）を全画素について（つまりi*jPIXEL）求めたとします。
その求めたオプティカルフローをuとvそれぞれについて全画素数分足し
全画素数で割ります。そうすると１画素あたりの平均速度速度ベクトルが
でます（よね？）。それに１画素あたりの距離をかけることで動物体の
速度を算出することって理論的に正しいでしょうか？

597 ：デフォルトの名無しさん：2006/01/08(日) 20:07:50

>596
動物体の速度って何？
1画素あたりの距離って、動物体とカメラの距離が分かってるってことかい？
物体が静止していてカメラがパンしてる場合は？
光軸上で光軸方向に移動してる場合、平均は 0 になると思うけどその辺どうよ？

598 ：デフォルトの名無しさん：2006/01/08(日) 21:04:01

>>596
動いていない領域があるなら除外しないと明らかにマズイ。
ということを考えると「動いている物体（領域）」を判断して、
そこだけでの平均が必要になる。

599 ：デフォルトの名無しさん：2006/01/10(火) 00:25:30

>>596
剛体の速度なら背景との差分で抽出するほうがよっぽど楽そうに思えるが。

600 ：tana：2006/01/10(火) 15:06:38

>>597,598,599
皆さんご返答ありがとうございます。成人式があったもので
お返事が遅くなってしましました、スイマセンm(__)m
>>597
自分のイメージとしては、一般的な３次元空間（x､y、z軸）があったとして、
対象は、x､y軸上を移動しているものと仮定しています。つまり奥行き方向には
移動しないってことですね。（少し説明しにくいですが...）
また、カメラは固定してあるものと考えています。
>>598
やはり、動いてない領域は除外する必要があるんですね。
すいません、そこで質問なんですがこの処理をするには、
フレーム間差分や背景差分を使って対象の移動領域を求めて
その移動領域のオプティカルフロー平均を求める方法が
一番よい方法でしょうか？別の方法として、オプティカルフローの絶対値が
ある閾値以上なら強制的に移動領域とみなす方法も可能だと思うのですが
...その辺は、いかがでしょうか？
>>599
自分もフレーム間差分や背景差分を使って速度を出すところまでは実験
したんですが、実験より得られた動画像を静止画にしたところ理想的な
対象がえられなかったんです。（実験は、サッカーボールを使って放物線を
描くようにゆっくり投げるシーンを撮影しました。下にその画像をおいてお
いておくのでみていただけたら幸いです。）
この実験をして思ったのは、解像度の高いカメラ（例えば毎秒１０００
フレーム撮影可能とか）を使い背景差分等の手法を使えばよい精度で速度
が得られる...。しかしこういうカメラは一般的に高コスト。
逆に一般的なビデオカメラ（できるだけ安価なカメラ）でいかに精度よく
速度を求めることができるかについて検証してみたいなと思ったわけです。

オプティカルフローが、普通は対象の次フレームでの移動量推定に用いられる
ことは知っているのですが（これは偏見ですかな？）、これを速度検出に
使ってみようかなと思いまして。

601 ：tana：2006/01/10(火) 15:14:50

http://www4.axfc.net/uploader/7/so/N7_5654.png.html

passは、「5959」
ダウンロードしたら、拡張子をpgmにしてgimpなどで見てください。

602 ：デフォルトの名無しさん：2006/01/10(火) 15:50:00

つーか、pgmを生で置くなよ。圧縮できる画像フォーマットかせめて圧縮してくれ。

603 ：tana：2006/01/10(火) 15:53:35

すいません。そこまで気がきかなかったですｍ（＿＿）ｍ

604 ：デフォルトの名無しさん：2006/01/10(火) 20:38:46

>>600
>実験より得られた動画像を静止画にしたところ理想的な対象がえられなかったんです。
シャッター速度。

>速度検出に使ってみようかな
速度はオプティカルフローと対象物・カメラ間の距離の関数になる。

605 ：デフォルトの名無しさん：2006/01/11(水) 17:04:59

>>604
スレッドストッパー?

606 ：デフォルトの名無しさん：2006/01/12(木) 18:14:35

画像のリサイズをしてるんですが、

long Width,Height;

607 ：デフォルトの名無しさん：2006/01/12(木) 18:24:48

すいません、途中で送信してしまいました。

画像のリサイズをしてるんですが、

float Resizep = 0.3;
int i,j,x,y;
long Width,Height,Rewidth,Reheight;
unsigned char r,rer,g,reg,b,reb,a,rea;

//画像を読み込む(略)

Rewidth = Width * Resizep;
Reheight = Reheight * Resizep;

for(i = 0;i / Resizep < Width;i++){
y = i / Resizep;
for(j = 0;j / Resizep < Height;j++){
x = j / Resizep;
rer[i*ReWidth+j] = r[y*Width+x];
reg[i*ReWidth+j] = g[y*Width+x];
reb[i*ReWidth+j] = b[y*Width+x];
rea[i*ReWidth+j] = a[y*Width+x];
}
}
自分なりに考えてみたのですが、このソースになにか問題や改善点はありますか？
画質とかは特に求めてないので複雑なアルゴリズム等は使いません。

608 ：デフォルトの名無しさん：2006/01/12(木) 18:41:04

超初心者なんですが・・・
本を開いた状態でキャプした画像があるのですが軽く開いてあるので真ん中が窪んでしまって読みにくいんで
編集して真直ぐにしたいんですが、どのソフトでどんな処理をすればよいのでしょうか？？

609 ：デフォルトの名無しさん：2006/01/12(木) 19:05:26

>>607
・一般的に、高さ方向を外ループにした方がいい。
・オフセット計算を4回ずつ行なうのは効率がよろしくない。
・i / Resizep < Widthの代わりにi < Rewidthを使った方がいい。
・Heightも同様に。

610 ：デフォルトの名無しさん：2006/01/12(木) 19:06:36

>>608
それだけの目的なら、PhtoShopなりなんなりで地道に変形させるとか。

611 ：デフォルトの名無しさん：2006/01/12(木) 21:50:16

>どのソフトでどんな処理をすればよいのでしょうか

これはここでする質問じゃねーよボケ。

612 ：デフォルトの名無しさん：2006/01/12(木) 22:44:15

4つの制御点からなるBezier曲線を分割する方法、どなたかご存じないでしょうか
曲線上の分割点における接線を求めて云々…とやってみたのですが、どうも恣意的で

たぶん制御点からビシッと求める方法があるんでしょうねぇ…

613 ：デフォルトの名無しさん：2006/01/12(木) 23:14:40

>>609
アドバイスありがとうございます。
高さが内側になってるのは書き間違いですorz

＞・オフセット計算を4回ずつ行なうのは効率がよろしくない。
これは速さの問題ですよね。

こんなソースになりました。

for(i = 0;i < Reheight;i++){
　y = i / Resizep;
　for(j = 0;j < Rewidth;j++){
　　x = j / Resizep;
　　of = i*ReWidth+j;
　　reof = y*Width+x
　　rer[of] = r[reof];
　　reg[of] = g[reof];
　　reb[of] = b[reof];
　　rea[of] = a[reof];
　}
}

614 ：デフォルトの名無しさん：2006/01/13(金) 00:18:54

>>612
de Casteljauでググってみそ。

パラメトリック曲線関係は、それほど難しくなくても
自分ではちょっと思いつかないようなのがあるから
何か本でも買った方がいいと思う。

615 ：デフォルトの名無しさん：2006/01/13(金) 01:05:25

>>607
そのコードだと、山ほどあるけどな･･･

一つ挙げるとしたら、ループ中でfloatを使わないとか
int iResizep = Resizep * 256.0f;
y = ( i << 8 ) / iResizep;

616 ：デフォルトの名無しさん：2006/01/13(金) 01:14:20

>>614
ありがとうございます、バッチリでした。

こういうのサッと出るところが…やはり専門にやっている(いそうな)方は違うなぁ…。
数学苦手ですが、なにか専門書も求めてみます。助言感謝です。

617 ：デフォルトの名無しさん：2006/01/13(金) 01:24:19

>>607
構造体を使う

typedef struct {
　unsigned char r;
　unsigned char g;
　unsigned char b;
　unsigned char a;
} Color;

618 ：デフォルトの名無しさん：2006/01/13(金) 01:39:29

横からすいません、>>612さんと似てるのですが、
ある一つのBezier曲線上の任意の点を分け目にして、Bezierを2つに分ける数式ってありますでしょうか？
（つまり最終的にコントロールポイントが2x4に）

しょぼい教書がひとつあるんですが、どうも描画する方法ばかりで・・・・

619 ：デフォルトの名無しさん：2006/01/13(金) 04:48:52

>>618
似てるもなにも一緒。

620 ：デフォルトの名無しさん：2006/01/13(金) 06:16:53

発生源が不明な何らかの要因でノイズがまじったり、ボケてたりして
写ってる物体の形があいまいになってる画像から、物体の本来の輪郭線を正確に抽出するにはどうすればいいの？
２値化すれば輪郭は取れるけど、閾値のとり方によっていくらでも輪郭の形や大きさが変わってくるから
正確とはいえないですよね。
何か参考になる文献とかあったら教えてください。

621 ：デフォルトの名無しさん：2006/01/13(金) 07:09:34

ぼけの原因がわかっているなら逆フィルタをかけるとか。
でも、エッジを雑音にも強く求めるには、ある程度ぼかして
から計算しますね。

エッジの位置精度を調べるには具体的にエッジモデル（＋雑音モデル）
を考える必要があると思います。

当然、対象物と背景の濃度で位置ずれは変わってくるけど、
濃度が分かっていればずれは解析可能だと思います。
有名なCannyの論文や、C.Stegerのラインフィルタの文献が
参考になるのではないでしょうか。

622 ：デフォルトの名無しさん：2006/01/13(金) 08:39:41

>>620

>>531
ttp://www.cse.ucsc.edu/~milanfar/SR/sr-examples.htm

623 ：609：2006/01/13(金) 11:55:19

>>615
それ考えたんだけど、速度的メリットってそんなに大きいかな?
大きくない画像だとファイルアクセスに較べて無視できる気もするのだけど。
#最近のCISCならFPUは半ば並行動作することだし。

>>607
ということで、見易さを犠牲にしても速度を求めるならループ内で実数演算は行なわない方向で。

624 ：デフォルトの名無しさん：2006/01/13(金) 12:14:08

つーか、intの除算とfloatの除算だと後者のほうが高速だったりするが。

625 ：618：2006/01/13(金) 12:42:50

>>619
すいません、講義の先入観からde Casteljau = 分割によるベジエ描画方法と記憶してました
勉強し直します

626 ：デフォルトの名無しさん：2006/01/13(金) 12:55:16

>>623
拡大･縮小・回転変換だと、x/y方向のステップ幅は一定になるから、毎回割り算しないで足し算に置き換えられる。

>>624
それﾏｼﾞ?

627 ：デフォルトの名無しさん：2006/01/13(金) 12:56:58

>>607
漏れならDDAするな。src側幅を sw, dst側幅を dw としたとき
参考までに一行分のループはだいたいこんな感じ。

int k = sw/2, j = 0;
for (int i = o; i < dw; i++) {
　dst_line[i] = src_line[j];
　k += sw;
　while (k >= dw) { k-= sw; j++; }
}

628 ：デフォルトの名無しさん：2006/01/13(金) 13:07:44

>>624
intの除算は余り求めたりする必要があるから、概算でできないからなのでは？
floatは逆数をニュートン法で求めてから掛けるとかで高速化できる。
なんとなくfloatからintに戻すときのコストが気になるけど、最近はそうでもないのかな。

629 ：デフォルトの名無しさん：2006/01/13(金) 13:52:39

あんまり突っ込んだ話なら最適化に関するスレでやれってことになるが。

まあ、結局はプログラミング作法でも読んで自分で実測してみろってことになるが、CPUにもよるが実数演算が速いつーか、整数除算が他の演算に比べて極端に遅い。

あとintとfloatが遅かったりするのは変換そのものじゃなくてコンパイラによっては毎回丸めモードなんかを設定しなおすせいだとどこかのサイトで読んだ記憶がある。

630 ：デフォルトの名無しさん：2006/01/13(金) 16:29:10

あんまり突っ込んだ話なら最適化に関するスレでやれ

631 ：デフォルトの名無しさん：2006/01/13(金) 20:14:06

>>629
float vs doubleか？あれ嘘だから捨てとけ

632 ：デフォルトの名無しさん：2006/01/13(金) 20:26:20

>>631
あれには騙された。

633 ：デフォルトの名無しさん：2006/01/13(金) 20:28:49

ついでだから聞くけど、やっぱりfloatの方が速いの？
VCだとfloatで書いてもdoubleに最適化されるけどさ。
Delphiなんかだと、floatと同等のsingleで書いた方が速いんだよな。

634 ：デフォルトの名無しさん：2006/01/13(金) 20:37:16

>633
>VCだとfloatで書いてもdoubleに最適化
そうか？
テンプレートでfloatとdouble使い分けてみると速度違うよ？
FFTとかの数値演算

635 ：デフォルトの名無しさん：2006/01/13(金) 20:50:38

除数が2のn乗になるように工夫すると速くなる

636 ：デフォルトの名無しさん：2006/01/13(金) 20:53:59

>>635
>> とか　<< に書き換えられればってことね。
最適化でそこらへんのことも勝手にやってくれるのかな？

637 ：デフォルトの名無しさん：2006/01/13(金) 21:08:57

画像処理とC言語の勉強をはじめて間もない者です。
離散コサイン変換をそのままCで記述して行ったところ、
処理にすごく時間がかかってしまいました。
どうもFFTを使うと速くなるようですので、それをプログラムしようと思います。
そこで、FFTのアルゴリズムを勉強するのにおススメのサイトや本をご存知でしたら
教えていただきたいです。
できればサイトが良いです。
よろしくお願いします。

638 ：デフォルトの名無しさん：2006/01/13(金) 21:14:46

http://laputa.cs.shinshu-u.ac.jp/~yizawa/InfSys1/basic/chap7/

639 ：デフォルトの名無しさん：2006/01/13(金) 22:07:29

というわけで、floatとdoubleの演算速度を比較してみた
ttp://gamdev.org/up/upload.php

パスはメル欄

とりあえず、VCでリリースビルドする限り、doubleとfloatの演算速度に差が出ないね。
ただし、デバッグビルドだと、明らかにdoubleの方が遅いので、
最適化がなんかしているはず。

てなわけで、普通使うときは、メモリ容量の問題がなければ、
doubleで良いと思うよ。

あと、さっきも言ったとおり、Delphiでは、明らかにsingleの方が速い。

640 ：デフォルトの名無しさん：2006/01/13(金) 23:08:58

>>639
コード斜め読みだが、構造体も配列もアクセスが無いコードで変数の数も少ない。
これは殆どの場合レジスタに収まるし、
全て同じソースに収まっているから
dt = d * 1000000000 と最適化してもいいし、
もっと頭が良ければコンパイル時に計算結果を代入しておいても構わない。

641 ：デフォルトの名無しさん：2006/01/13(金) 23:30:21

せっかく、>>640 のような反応をもらったので、
乱数をからめてみた。
場所はさっきのとこで、パスも同じだから、良かったら試してみてね。

ちなみに、結果としては、やっぱり、floatもdoubleも速度は殆ど変わらなかった。

642 ：デフォルトの名無しさん：2006/01/14(土) 00:14:55

>>639 >>641
x87のモード変更はしたの？
しなければ FPU は全部 80bit で計算するけど。

どちらにしろ今だと SSE で浮動小数点計算しろ、しゅうりょーだけど。

float の除算は逆数を取っておいて掛け算で処理するとかはよくやる。

643 ：640：2006/01/14(土) 00:27:22

>>641
ttp://gamdev.org/up/img/4360.zip

644 ：デフォルトの名無しさん：2006/01/14(土) 00:38:36

#define RAND_MAX 0x7fff

定数での除算は逆数との乗算になる

645 ：デフォルトの名無しさん：2006/01/14(土) 01:22:01

>>643
㌧楠
勉強になるねー

646 ：デフォルトの名無しさん：2006/01/14(土) 05:27:20

>>642
アフォ？

647 ：デフォルトの名無しさん：2006/01/14(土) 07:41:17

ソースだけ見て実行はしてないが、ウダウダ言うより
コンパイラが吐いたコードを見れば一発で終了だと思うが。

まぁ、画像処理では無くなっているので、これ以上は
スレ変えた方がいいかと。

648 ：デフォルトの名無しさん：2006/01/14(土) 08:10:27

実際画像処理やってるアプリケーションで
高速化のために一旦x87のモード切り替えて
floatで処理するように作ってあるような
実例はありますか？

649 ：名無し募集中。。。：2006/01/14(土) 08:48:59

画像処理は早いほうがいいのだからfloatやらn倍した整数演算したり
アセンブラもSIMD演算だって何でもやる。
しかし今の最適化手段に関しては画像処理とかけ離れているので別スレでやってくれ
処理速度向上にはアルゴリズムの改良のほうが効果あると思うよ

650 ：637：2006/01/14(土) 10:30:59

>>638
ありがとうございましたm(_ _)m

651 ：デフォルトの名無しさん：2006/01/14(土) 22:36:47

>>647がスレ移動を進めてる後で書くのは気が引けるけど、ちょっとだけ。
float VS double とか実装の話は処理の種類や環境依存（コンパイラ・CPU）なんで議論するだけ無駄だと思うよ。
doubleが速いってのは高度な数学関数（三角関数とか2乗根）の計算の場合で、大量の四則演算をする場合はメモリバンドやSIMD命令の関係でfloatがずっと速くなるんです。

コードの最適化は具体的なコードが無いとできないし、その方法は環境依存。
結局>>649の結論です。

日記みたいなこと書いてすんまそ。

652 ：デフォルトの名無しさん：2006/01/14(土) 23:02:49

>>651
覚えておくよ

653 ：デフォルトの名無しさん：2006/01/15(日) 04:09:50

画像2値化をするのに、判別分析を使ってやろうと思ったんですが、
画像撮影の条件の関係で、すごい明るかったり暗かったりして、状況によってはうまいことできないんですが、
照明状況が変わってもうまいこと2値化する方法ってないでしょうか？

一応、可変しきい値処理みたいなものも考えたのですが、
ちょっと処理時間がかかりすぎてしまって無理でした。

654 ：デフォルトの名無しさん：2006/01/15(日) 05:53:38

画像処理プログラムを作っていてふと思ったのですが、画像処理によって
何らかの計測を行う場合（例えばある形状や重心の計測等）に、得られた
画像を平滑化しその画像を用いて計測を行うのって大丈夫なのですか...？
実際に平滑化フィルタに画像を通すと原画像がぼやけたりしますよね...。
それによって計測精度の低下につながったりしないんでしょうか？
（伝わりにくい質問ですみませんが）

655 ：デフォルトの名無しさん：2006/01/15(日) 06:37:01

エッジの位置精度と平滑化のかけ具合はトレードオフ。

656 ：デフォルトの名無しさん：2006/01/15(日) 09:24:07

>>653
対象物の大きさが変わらないなら、Pタイル法かな？

判別分析は対象物と背景の面積が同じぐらいじゃないと、
あまり美しくなかったと思います。
クラスタリングで二値化する方法は、
経験上、だいたいこの傾向ですす。

657 ：デフォルトの名無しさん：2006/01/15(日) 10:59:17

>>656
最初Pタイル法を使っていたんですが、対象物が結構大きく変化しちゃうため、
断念して、判別分析法で色々やってました・・・。

判別分析法をそのまま使うのは無理だと思うので、輝度の平均を取って
その値から閾値を補正してみる、みたいな感じでうまいこと照明状況の変化にも耐えられるようなもの作れないかなぁ。

658 ：デフォルトの名無しさん：2006/01/15(日) 11:34:31

>>657
可変しきい値って、ピクセルごとにしきい値を変える動的しきい値のこと？
現状速度と目標速度は、どのくらいのオーダーなのでしょうか？

659 ：デフォルトの名無しさん：2006/01/15(日) 12:02:30

>>658
はい、動的しきい値のことです。
ちょっと細かく確認していないので、現状速度と目標速度がどの程度か分からないのですが、
通常用いられる判別分析法を使って、ギリギリです。

ただ、動的しきい値処理が現在の判別分析法よりもよい結果を得られた場合は、
その分他の処理を減らすことができるので、一概に絶対無理とは言い切れませんが。。

660 ：デフォルトの名無しさん：2006/01/15(日) 13:15:30

判別分析法かどうかと、動的しきい値法かどうかとは全く別だと思いますが。
判別分析法を使った動的しきい値法もあるわけで...

661 ：デフォルトの名無しさん：2006/01/15(日) 13:30:53

ttp://www.cis.nagasaki-u.ac.jp/~hotta/gke/index.html

ここに書いてあることと同じことをやろうとしているのですが
課題2-2は理解できましたが課題3がさっぱり分かりません・・

各色の出現頻度を求めればいいのは分かっているのですが
肝心の”この画素は64色の中のこの色である”、と判別できる方法が思い浮かばないです

それぞれの画素が64パターンのうちのどれに属するか・・・どういうプログラムにすればいいんでしょう？

662 ：デフォルトの名無しさん：2006/01/15(日) 13:37:39

普通にユークリッド距離が一番近いものでいいんでない？

663 ：デフォルトの名無しさん：2006/01/15(日) 13:46:04

>>661
64色まで減色済みなんでしょ。
その64色のrgb値が判っているなら、画像中の画素のrgb値をそれと比較して何番目か判断すればいい。
そうでないなら、64要素のバッファを用意して新しいrgb値に遭遇するたびにそのバッファにrgb値をセット。
既にバッファ内にrgb値があるなら画素数をカウントアップすればいい。

664 ：デフォルトの名無しさん：2006/01/15(日) 14:01:45

JPEGのAPPxのAPP0以外のやつって削除しちゃっても問題ないですか？
例えばAdobeとか、duckyとか書かれているんですが・・・

665 ：デフォルトの名無しさん：2006/01/15(日) 15:10:46

>>661
各色2bitに圧縮されているから、r+g*4+b*16でindexが求まるって
説明しようと思ったが、2-2のサンプルプログラムを見たら、
8bitのまま処理してんのね。

switch-caseでも使って、RGBを32⇒0、96⇒1、160⇒2、224⇒3と
変換してから上式を適用すればいいかと。

666 ：デフォルトの名無しさん：2006/01/15(日) 16:13:40

2.2 カラー画像の減色
>そしてRが0から63の間で，Gも0から63の間，Bも0から63の間であるカラー値をカラー値0とし，
>Rが64から127の間で，Gが0から63の間，Bも0から63の間であるカラー値をカラー値1，Rが128
>から191の間で，Gが0から63の間，Bも0から63の間であるカラー値をカラー値2，としていき
>最後の，Rが192から255の間で，Gも192から255の間，Bも192から255の間であるカラー値を
>カラー値63とする．

#define MAXHIST 64
#define DOTS 128
#define R 0
#define G 1
#define B 2

unsigned char RGB[DOTS][3]; /* R: RGB[*][R], G: RGB[*][G] B: RGB[*][B] */
int index; /* ヒストグラムインデックス 0->63 */
int histgram[MAXHIST]; /* ヒストグラム */
int i;

for (i = 0; i < MAXHIST; i++) {
histgram[i] = 0;
}

for (i = 0; i < DOTS; i++) {
index = 1*(RGB[i][R]/64-1) + 4*(RGB[i][G]/64-1) + 16*(RGB[i][B]/64-1);
histgram[index]++;
}

※ヒストグラムインデックスの計算式
　1*(R/64-1) + 4*(G/64-1) + 16*(B/64-1)
がみそです。

667 ：666：2006/01/15(日) 16:45:30

間違えたな
×　index = 1*(RGB[i][R]/64-1) + 4*(RGB[i][G]/64-1) + 16*(RGB[i][B]/64-1);
○　index = 1*RGB[i][R]/64) + 4*RGB[i][G]/64 + 16*RGB[i][B]/64;
だな

668 ：デフォルトの名無しさん：2006/01/15(日) 17:23:20

>>664
他で聞いた方がいいんじゃないか。

win98 ではサイズが小さくなるんで削除していたが、今は残すように過去の自作のアプリを
変更している最中。画像をいじったときサムネイルを差し替えるって結構面倒だよね。

残して何がいいかって、自分にとってはフォルダ内の写真を（サムネイル）一覧するのに
速くはなる。昨今 3008x2000 のが何十枚とかだと表示に時間がかかっていた。

669 ：デフォルトの名無しさん：2006/01/15(日) 18:16:22

>>668
ありがとうございます。
どこで聞いたらよろしいでしょうか？

残すとサムネイルが早くなるのは重要ですよね。
これに関するドキュメントが見つかれば、
この部分のAPPxだけ残してみようかなと思ってみたり・・・

670 ：tana：2006/01/16(月) 16:13:37

質問です。今画像データの右端に速度を（セグメントで）表示したいのですが
どのようにすればいいかわからなくて困ってます。
速度は、あるファイルに書き込まれています。そのファイルの値を読み出して
任意の画像データに表示したいのです。とりあえず、１２．４などの（でーた）数字が
あったとしてこれらを、「１」「２」「.」「４」と分割して値を配列にいれたいの
ですがどうすればよいでしょうか？

671 ：デフォルトの名無しさん：2006/01/16(月) 16:25:59

>>670
どうみても画像処理じゃありません

使用する環境に合ったスレへどうぞ

672 ：デフォルトの名無しさん：2006/01/16(月) 19:18:46

>>670
char str[256];
sprintf (str, "%2.1f", speed);
putstring(image, px, py, str);

673 ：661：2006/01/16(月) 22:23:02

>>662-663,>>665-667
ありがとうございました、やりやすそうな>>665さんのを試してます

それでお聞きしたいことなんですが↓このプログラムの問題点です（ヘタクソなのは仕様です・・）。
ttp://monoganac2.sakura.ne.jp/src/milktea8092.zip.html

>>661のサイトの比較方法を使って類似領域を探し出して貼り付けるというプログラムをつくってます。
しかし色合いがかなり違ってても同じところからしか取得して来なく、まともに探索できてないようなんですが原因が分かりません・・・

674 ：673：2006/01/16(月) 22:30:18

すみません、言い忘れたことが
説明には黒で塗ったところを～って書いてありますが無視してください

根本的に何もないところで似たような部分がもってこれない限りどうしようもないですから
適当に道路の２点をクリックしてマスクして実行しても空から取得してたりするんですよ・・

675 ：デフォルトの名無しさん：2006/01/17(火) 02:37:42

ウインドウズで最初からあるペイント機能で、
いつも画像を開き、それをサイズを修正して保存し、
それを携帯に送って携帯で見てました。
しかし、初期化してからは、ｊｐｇ画像のサイズを保存しようとしたら、
かならずｂｍｐ画像でしか保存できません。
以前は、名前を付けて保存でそのままｊｐｇだったのに、
なぜかそうなってしまいました。直りませんか？
ｂｍｐなら携帯では見れません。

676 ：デフォルトの名無しさん：2006/01/17(火) 02:51:52

('A`)

677 ：デフォルトの名無しさん：2006/01/17(火) 05:44:47

('A`)

678 ：名無し募集中。。。：2006/01/17(火) 07:28:38

それまで画像処理といいはりますか？

679 ：デフォルトの名無しさん：2006/01/17(火) 15:10:56

オプティカルフローの検出プログラムを作ってみたんですがちゃんとできている
か不安なのでみていただけないでしょうか？みていただきたいのは、関数opti
とbibunです。下においておきます。

680 ：デフォルトの名無しさん：2006/01/17(火) 15:14:04

http://www4.axfc.net/uploader/7/so/N7_7303.c.html

pass [1111]

681 ：デフォルトの名無しさん：2006/01/17(火) 15:17:36

afxcを使う奴は池沼

682 ：デフォルトの名無しさん：2006/01/17(火) 15:20:44

>>681
斧を使う奴は、「肛門上げ」が好きな奴だよ。
簡単に落とせないようにして、なかなか落とせない悲鳴を聞いて
一人ほくそ笑む、心が歪んだ奴だ。

683 ：デフォルトの名無しさん：2006/01/17(火) 16:13:31

>>682
そうなんですか？
日頃ファイルアップする必要性がないので、適当にアップできるところ
探したらそこにたどり着いたんです...お許しあれ

684 ：デフォルトの名無しさん：2006/01/18(水) 12:41:57

すいません、フリーで高速な画像処理のライブラリってありますか？
具体的には二値化と細線化がやりたいんですけど。

685 ：デフォルトの名無しさん：2006/01/18(水) 12:54:38

自分で書け。以上。

686 ：デフォルトの名無しさん：2006/01/18(水) 12:58:56

orz

687 ：デフォルトの名無しさん：2006/01/18(水) 13:19:31

IPPのLinux版には無料の非商用ライセンスがあった気がするが。

688 ：デフォルトの名無しさん：2006/01/19(木) 00:30:45

今までC言語だけでプログラムを書いていて、最近MMXの存在を知ったのですが、
↓の本を読まれた方いませんか？

アセンブラ画像処理プログラミング
http://www.cbook24.com/bm_detail.asp?sku=4877831398

MMXを初めて勉強する人間に十分な質やレベルでしょうか？結構値段が高いので
買うのに躊躇してまして…
他にも、勉強するのに良いサイトとかがあったら教えてください。

689 ：デフォルトの名無しさん：2006/01/19(木) 01:24:55

RAWデータの画像処理をC++でしたいんですけど
初歩的なTIPSがのってるWEBないでしょうか？

690 ：デフォルトの名無しさん：2006/01/19(木) 01:34:06

>>688
アセンブラ…　ヽ(ﾟ∀ﾟ)ﾉﾌｫｰｳ!
http://pc8.2ch.net/test/read.cgi/tech/1132761638/253-275

691 ：デフォルトの名無しさん：2006/01/19(木) 02:11:24

ImageMagickをC/C++から使うにはどのようにすればいいか
簡単な解説があるページないでしょうか？

http://vision.kuee.kyoto-u.ac.jp/~nob/doc/imagemagick/imagemagick.html#doc1_291

ここに解説があったのですが、こういう関数が用意されていてそれを
直接呼び出せるようになどなっていないのでしょうか？

692 ：デフォルトの名無しさん：2006/01/19(木) 07:40:21

言ってる意味わかんないけど
http://www.imagemagick.org/Magick++/Documentation.html

693 ：デフォルトの名無しさん：2006/01/19(木) 12:20:04

　32bitBMP(XRGB8)間透過付き転送でDirectDrawのBltFastに勝てる
アセンブリコードの書き方を教えてください。orz
(DirectDraw側もシステムメモリ上に作成したサーフェス間転送として)

　とりあえず以下のようなコードが自前では最速だったのですが(Pen4)、
DirectDrawのメモリ間転送より20%程遅いのです。
　というか、透過色部分が多ければ多いほどDirectDrawとの差が開く
ので単純に透過色のスキップ部分に違いがあるのだと思うのですが・・・
(透過色なし転送では rep movsd しか選択肢が無いのか、こちらは
容易にDirectDrawと同等の転送速度を得られました)

694 ：デフォルトの名無しさん：2006/01/19(木) 12:20:48

改行が多すぎると指摘されたのでコードを別にします
// S:転送元 D:転送先 T:透過色 H:縦幅 W:横幅
// DADD:転送先のピッチ - １ライン分の転送幅*4byte
// SADD:転送元のピッチ - １ライン分の転送幅*4byte
_asm
{
mov esi, S
mov edi, D
mov edx, T
mov ebx, H

LOOP1:
mov ecx, W
LOOP2:
mov eax, [esi]
cmp eax, edx
je LABEL
mov [edi], eax
LABEL:
add esi, 4
add edi, 4
dec ecx
jnz LOOP2

add edi, DADD
add esi, SADD
dec ebx
jnz LOOP1
}

695 ：デフォルトの名無しさん：2006/01/19(木) 12:48:40

ここより最適化スレとか、
SIMD系のスレとかで聞いた方が良いんじゃないかな・・・

696 ：デフォルトの名無しさん：2006/01/19(木) 13:41:23

ちょっとした興味なのですが、
カラー画像をグレースケール化しないで直にエッジ検出などの処理をする方法ってあるのでしょうか？
それとも、そんなことをしても意味がないのでしょうか？
グレースケールにすると情報が減ると思うので、そのままできる手法のほうが良いような気がします。
ただその場合どのようにフィルタを通してやるのかな。と。
はたまた、グレースケールに変換しても情報が減らないような変換方法もあるのでしょうか？

697 ：デフォルトの名無しさん：2006/01/19(木) 13:55:02

チャンネルごとに判定してやったら？
そんなことする意味ねーと思うけど

698 ：デフォルトの名無しさん：2006/01/19(木) 14:13:58

>>>696
やりたければコンポーネント毎にエッジ検出（フィルタ処理）を行った後に最大値を取っても良いよ。
そうすればグレイスケールにすると同じ輝度になってしまうような色同士の間の境界も検出できる。

699 ：デフォルトの名無しさん：2006/01/19(木) 14:39:17

>>698
なるほど。でも、その最大値という部分がちょっと気持ち悪いです。
ほんとにそれで大丈夫なのでしょうか？

700 ：デフォルトの名無しさん：2006/01/19(木) 14:41:15

喧嘩売ってるのか？

701 ：デフォルトの名無しさん：2006/01/19(木) 14:56:32

>>699
その辺はフィルタ特性をどう作るかっていう話なんで好きにすれば良いと思うけど、

輝度成分のみからなる画像にフィルタを適用してエッジ検出を行った場合と、
R,G,Bが同値のRGB３要素からなるフルカラー画像に対してエッジ検出を行った場合とで
同じ結果が得られるようにしておいた方が便利なような気がする。好き好きだけど。

あるいは出力もフルカラーにして、フィルタの出力をコンポーネント別にそのまま
入れておくっていう手もある。画像処理ソフトなんかではこの方が主流ですね。

でもまぁ、最初に書いたように好きに・・・というか必要なように作ればよいと思う。

702 ：デフォルトの名無しさん：2006/01/19(木) 15:08:47

ほんとにそれで大丈夫なのでしょうか？

703 ：デフォルトの名無しさん：2006/01/19(木) 15:10:56

ほんとにほんとにそれで大丈夫なのでしょうか？

704 ：デフォルトの名無しさん：2006/01/19(木) 15:14:53

ほんとにほんとにほんとｎ(ry

705 ：デフォルトの名無しさん：2006/01/19(木) 15:42:10

ほんとにほんとにほんとにほんとにライオンだ～♪

706 ：デフォルトの名無しさん：2006/01/19(木) 15:53:13

近すぎちゃって～どーしよ～♪

707 ：デフォルトの名無しさん：2006/01/19(木) 16:46:33

>>701
なるほど、出力もフルカラーですか。
その後最終的には２値化にもっていくわけですが、
フルカラーから２値化する手法も同様に最大値をとる、などの
方法を使うことになってしまいそうですね。

>>700
最大値をとる、という手法だと、かなり単純化しますが、
[0 0 0] [0 0 255]
という変化と
[0 0 0] [0 255 0]
という変化も同じ変化とみなされてしまいそうですよね。
本質的には別の変化であるのに、同等の変化とみなしてしまう。
ということに対して気持ち悪いという表現をしました。
また、この例ではエッジ検出としてはどちらにしろ問題ないでしょうが、
色が違うのに、エッジ検出が失敗する可能性は捨て切れません。
その辺りのことが証明かなにかされているのかということを気にして尋ねました。

フルカラーはどうにも処理しにくいので、グレースケール化してから
処理するのが一般的なのでしょうが、
うまいこと扱う手法がないものでしょうか？

708 ：デフォルトの名無しさん：2006/01/19(木) 17:03:44

>色が違うのに、エッジ検出が失敗する可能性は捨て切れません。

それは実装次第。コンポーネントを同等に実装すると色違いで失敗することはない。

709 ：デフォルトの名無しさん：2006/01/19(木) 17:05:15

> フルカラーはどうにも処理しにくいので

RGB ３値で単に処理が３倍になるだけ。コードは論理が同じなら３倍にならないし。
なにが問題なのかわからんな

710 ：デフォルトの名無しさん：2006/01/19(木) 17:06:40

>>707
勉強し直した方が良いと思う。
例えば「失敗」なんて言葉を使ってるけど、
変移の絶対値みたいなフィルタの動作に失敗も成功も無い、
ってことわかりますか？

あと「色が違う」という言葉で示していることの意味、
わかっていますか？

711 ：デフォルトの名無しさん：2006/01/19(木) 23:59:43

前に出た「輪郭抽出」で輪郭を求めているんだけれど、ここの話を見て、単色でなく
equalizer の例にあった「見た目の明度」で試して見た。
結果、２値化したとき多少輪郭線がクリアかなという程度だった。境界でない部分に
ゴミが少ない感じもあった。（拡大係数にもよるだろうが）

見た目の明度は、(77*R + 150*G - 29*B)/256
で求めた。

712 ：デフォルトの名無しさん：2006/01/20(金) 00:43:15

>>696
色の差を厳密考えるならば、
RGB→Labに変換してからやれ、
Lab空間では色差=距離なので。
変換の計算量が多いが。
色を絡めた処理をやるならLab空間や、abを極座標にしたLCh空間は便利。

713 ：デフォルトの名無しさん：2006/01/20(金) 00:52:13

>>690
うーん、微妙な感じなのか。やっぱ買わないほうが良さそうですね。
ありがとうございました。

714 ：デフォルトの名無しさん：2006/01/20(金) 03:40:29

２枚の画像を繋ぎあわせて( 横にならべて )
一枚の画像に画像にしたいのですが、
OpenCV にそのような関数ありますか？

715 ：デフォルトの名無しさん：2006/01/20(金) 12:41:57

>>711
そのようなグレースケール変換だと色が違うのに変換された値が同じになる場合があるので、
問題があるのではないかということを危惧した質問です。
>>712
Lab空間ですか。そういうのを聞きたかった。
調べてみます。

716 ：デフォルトの名無しさん：2006/01/20(金) 12:56:20

>>712
http://image-d.isp.jp/commentary/color_cformula/Lab.html
Lab空間というのはこれですか？
これでも、L*a*b という３次元になってしまうのですよね？
その後の、２値化のためのステップとして、
いずれグレースケール化すると思うのですが、
RGB の場合と同じく、入力の数値が違っても、出力が同じになってしまう場合があると思います。

グレースケール化のステップを踏まずに、
３次元空間で分離して、２値にもっていく方法をとればよいのでしょうか？
そのような手法としてなにかあるのでしょうか？

717 ：デフォルトの名無しさん：2006/01/20(金) 12:57:21

>>715
まずは「色が違う」の意味を自分なりに（というか応用に合わせて）
定義しないと、一歩も進めないと思うよ。

718 ：デフォルトの名無しさん：2006/01/20(金) 13:14:00

>>717
色が違うと言うのは、
３次元空間における、点の位置が違うということではないですか？

719 ：デフォルトの名無しさん：2006/01/20(金) 13:24:37

>>718
「ないですか」ではなく、>>718がやろうとしている輪郭抽出処理において
輪郭を描くに足る条件としての「色が違う」とは、いったいなんなのか、
とこちらが聞いているわけです。

点の位置が違うってことなら r,g,b の各々の差の絶対値の総和でもいいし、
最大値でもいいし、差の二乗の平方根でもいいことになる。
もちろん他の色空間でやっても良い。

それらのうちのどれを使いたいんですか、ということ。

720 ：デフォルトの名無しさん：2006/01/20(金) 13:27:55

アホに何を与えても満足しないよ

721 ：デフォルトの名無しさん：2006/01/20(金) 13:29:24

もっと言えば、それなりに多くの応用では何らかのフィルタで2値化して
から処理を行うこともあるわけで、

その場合「色が違う」というのは「フィルタを適用して違う値になるもの」と定義される。
別に屁理屈じゃなくて、応用毎にその目的に合わせて定義するより無いということ。
なにか教科書的な正解があるわけじゃないから。

722 ：デフォルトの名無しさん：2006/01/20(金) 13:30:09

釣りだった場合に恥ずかしいので退散しまｓ

723 ：711：2006/01/20(金) 13:56:01

>>715
自分の場合はカメラを縦にしてフラッシュをたいて撮った写真の人物の横に
影が出来ているのを消したくて輪郭取って影の領域を背景の色で埋めるため
だけに必要だったのですが、クダンの輪郭抽出にある３種類の変換で、ある
写真によい方法は別の写真ではだめという結果なので、目で見て一番輪郭が
きれいな方法の結果を選んで２値化して先に進めるようにしました。
輪郭抽出ってこんなもんか程度の理解ですが、最適な抽出方法が決められれ
ばクリック一発で影を消せるかなと期待しています。
いいことが見つかったら要点だけでもご開示頂けると助かります。

724 ：デフォルトの名無しさん：2006/01/20(金) 13:59:49

なんかますます新手の釣りのような気がしてきた

725 ：デフォルトの名無しさん：2006/01/20(金) 14:01:05

>>719
私にとって、「色が違う」というのはあくまでも、三次元空間における点の位置が違うという意味で使用していました。
カラー画像の値、入力の値が違うという意味です。
「ないですか？」というのはあくまでも確認の意味にすぎません。このように日本語が使われることはよくあります。
r,g,b の最大値をとるという手法では、入力 r,g,b の三次元空間における点の位置が違ったとしても、
出力の max(r,g,b) では同じ位置になってしまうことがあります。
そこを問題視しているということをわかっていただけますでしょうか？
これはみなさん、画像処理の基礎でグレースケール化を学んだときに、
気になった点であると思います。

確かにエッジ検出においては、あるグレースケール変換をした際に、
同じ値になってしまいエッジが見づらくなったとしても、
別のグレースケール変換をして、それと合わせればよいかもしれません。
もしくは、ただ１つのグレースケール変換でもうまくいく場合もあるかもしれません。
しかし、それは個々の問題において、エキスパートが独自に判断しなければいけない問題になりますよね。
そうではなく、根本的に解決できる手法はあるのではないかと思い、質問していました。
根本的に解決できる手法があるのならば、それにこしたことはありませんよね？
そこに異議はないと思います。

>>721

>別に屁理屈じゃなくて、応用毎にその目的に合わせて定義するより無いということ。

やはり、そうなってしまうのですか？
ならばここには研究の余地がありそうですね。

726 ：デフォルトの名無しさん：2006/01/20(金) 14:14:51

画像処理に用いられているフィルタは信号処理でもちいられたフィルタを
２次元に拡張したものなので、
x,y, 値という座標空間までしかとれないのですよね。
このフィルタそのものを x,y,A1,A2,A3 ととれるように拡張することができれば問題はクリアできそうな気がします。
ただこのフィルタの拡張というのが難しいわけですが。
現実、x, 値の状態で利用しているフィルタのほうが多いくらいですし。

727 ：デフォルトの名無しさん：2006/01/20(金) 14:40:38

何かいろいろ言いたいけど、うまく言えない漏れガイル

728 ：デフォルトの名無しさん：2006/01/20(金) 14:44:54

>>725
あまりにも変なので釣りっぽいけど一応

>>707の
＞最大値をとる、という手法だと、かなり単純化しますが、
＞[0 0 0] [0 0 255]
＞という変化と
＞[0 0 0] [0 255 0]
＞という変化も同じ変化とみなされてしまいそうですよね。
＞本質的には別の変化であるのに、同等の変化とみなしてしまう。
＞ということに対して気持ち悪いという表現をしました。
＞また、この例ではエッジ検出としてはどちらにしろ問題ないでしょうが、
＞色が違うのに、エッジ検出が失敗する可能性は捨て切れません。
＞その辺りのことが証明かなにかされているのかということを気にして尋ねました。

の「色が違うのに、エッジ検出が失敗する可能性は捨て切れません」について、
どんな可能性があるのか書いてみると話が通じるようになると思います。

例えば各色の視覚的特性を考慮して加重平均を取った方がいいのでは、とか。

729 ：デフォルトの名無しさん：2006/01/20(金) 14:46:04

>x,y,A1,A2,A3 ととれるように拡張することができれば問題はクリアできそうな気がします。

５次元に拡張したとして、座標以外の処理すべきデータがなくなるじゃん。何言ってるの？

730 ：デフォルトの名無しさん：2006/01/20(金) 14:53:34

なんだかもう高校生以下って感じだな・・・

731 ：デフォルトの名無しさん：2006/01/20(金) 14:53:59

具体的に複数ケース出して、どういう問題が発生するのか
提示してくれんことには何も言いようが無い。

漠然と不安だ、問題だって言われてもな。

732 ：デフォルトの名無しさん：2006/01/20(金) 14:55:08

>>730
ヒント：　ゆとり教育

733 ：デフォルトの名無しさん：2006/01/20(金) 14:56:12

ならばここには研究の余地がありそうですね。

734 ：デフォルトの名無しさん：2006/01/20(金) 15:10:23

そこに異議はないと思います。

735 ：デフォルトの名無しさん：2006/01/21(土) 05:14:09

3次元空間内での2点のユークリッド距離でも計算したら？

まあ、
「絶対に自分の思い通りの結果が出るという保証をしてもらわない限り、
プログラムを作るつもりは無い」
と、言わんばかりの態度で掲示板に質問を書くやつのために、
相談に乗ってやるような人はいないよ。

「教えてもらったアイデアで実際にやってみたら、こういう結果になりました。
で、ここが不満なんですけど・・・」という実験報告があれば、答えた人も
「じゃあ、もうちょっと一緒に考えてやるか」と思うこともあるだろうが、
相談に乗ってくれた人に、「それで大丈夫ですか」と詰問すれば、
答えた人はあきれて逃げる。無料奉仕だけではあきたらず、
品質保証まで要求するとはどういう了見だ？
どこかの技術コンサルタント会社に行って金を払って相談にのってもらえ。

736 ：デフォルトの名無しさん：2006/01/21(土) 10:07:11

やはり、そうなってしまうのですか？

737 ：デフォルトの名無しさん：2006/01/21(土) 10:16:34

喧嘩売ってるのか？

738 ：デフォルトの名無しさん：2006/01/21(土) 11:45:08

カラーエッジの話題ですが上のほうであったようにＲＧＢ画像を
色空間を(x,y,R,G,B)の５次元のユークリッド空間
の中に埋め込まれた２次元リーマン多様体と
考える論文が昔ありました。勾配やラプラシアンを
もっと一般的に考えようというものです。

739 ：デフォルトの名無しさん：2006/01/21(土) 13:10:10

低レベルなスレッドですね。皆技術者畑？

740 ：739：2006/01/21(土) 13:13:12

>>738
あ、この人は科学者的

741 ：デフォルトの名無しさん：2006/01/21(土) 13:24:04

質問者と回答者の見ているベクトルが違うような気がする。
それがズレの原因じゃない？

742 ：デフォルトの名無しさん：2006/01/21(土) 13:57:26

ベクトルって便利な言葉だよね。

743 ：デフォルトの名無しさん：2006/01/21(土) 14:03:54

質問者と回答者の見ている行列が違うような気がする。

いや、違うか。

744 ：デフォルトの名無しさん：2006/01/21(土) 14:13:34

質問者と回答者の見ている四元数が違うような気がする。

745 ：デフォルトの名無しさん：2006/01/21(土) 14:22:35

つーか、このスレ的には違う色空間で話しているって感じ?

746 ：デフォルトの名無しさん：2006/01/21(土) 14:44:11

Threshold はある意味１次元空間でも Linear な Clustering ともいえるから、
3次元空間であるRGB空間では３次元でクラスタリングしてやればいいんじゃない？
というか、なぜこれをまずだれも言っていないのかが不思議。
レビュー論文の
http://www.cs.usu.edu/~cheng/paper.ps
のカラーについての部分にちょろっと書いてある。

>>742-745
きみら邪魔。ってか同一人物か？

747 ：デフォルトの名無しさん：2006/01/21(土) 23:42:23

俺らは本当に複数だよ

748 ：デフォルトの名無しさん：2006/01/21(土) 23:47:19

>>746
日本語の中に英単語を混ぜて書くと、ルー大柴の
喋り方みたいな印象になるぞ。

749 ：デフォルトの名無しさん：2006/01/22(日) 00:09:56

カラー画像→グレイスケール化→エッジではなく
カラー画像→エッジ。
ttp://www.linx.jp/image/products/halcon/index_halcon_7.0.html

上の方にあったようにリーマン計量を考える方法もあるけど
これの元になってる論文では、計算が面倒だし実際にはノイズも
入るから、ということでもっと簡単な計算で勾配を計算してるようです。

750 ：デフォルトの名無しさん：2006/01/22(日) 00:36:02

Magick++を使って画像を読み込んでいるのですが、
pixelColorを使うとRGBが

0.988235, 0.988235, 0.988235

のようになるのですが、これを0-255の階調になるような
関数などはあるのでしょうか？

751 ：デフォルトの名無しさん：2006/01/22(日) 01:17:27

x * 256.0

752 ：デフォルトの名無しさん：2006/01/22(日) 03:26:43

リーマン計量ってなに?

753 ：デフォルトの名無しさん：2006/01/22(日) 10:26:55

>>751
xに1を入れてみ

754 ：750：2006/01/22(日) 12:12:00

やはり255倍して出すのですか。
画像処理のライブラリとかでは0-255で表現するよりも
0-1.0までの実数で表現するほうが一般的なのでしょうか？

755 ：デフォルトの名無しさん：2006/01/22(日) 12:17:58

色の強さが直感的に分かるでしょう。
赤が128というよりは赤が0.5のほうが分かりやすいでしょ。
こてこてのプログラマなら0-255のほうが分かりやすいでしょうし、
画像専門のプログラマ、画像ソフトを専門的に扱う人間なら少数
のほうが分かりやすいんじゃないでしょうか。

756 ：デフォルトの名無しさん：2006/01/22(日) 12:18:37

一般的だ
理由は自分で考えろ

757 ：デフォルトの名無しさん：2006/01/22(日) 12:29:40

>>755
専門的に、という表現はあまり正確ではない。

758 ：デフォルトの名無しさん：2006/01/22(日) 12:44:21

ここを釣堀にするのやめてもらえない？

759 ：696：2006/01/22(日) 13:39:57

ありがとうございました。
しかし小学生のような方が多いスレでした。
ほんと釣堀にするのやめてほしいですね。それでは。

760 ：デフォルトの名無しさん：2006/01/22(日) 14:12:59

原画像を回転した画像を、矩形領域にぴったりおさめて
画像を出力するプログラムを作ってます。
(ESPLIB6.5というフリーのライブラリ関数を使ってます)

線形補間まではできるようになって、見た目９５％程度は滑らかになったのですが、
背景部分と変換した原画像の境目だけ、まだギザギザしたエッジが残っています。
これを取り去って滑らかにしたいのですが、何か良い手法はありますでしょうか。
HPでも本でも何か参考になるものがありましたら、教えてください。

761 ：デフォルトの名無しさん：2006/01/22(日) 15:01:31

>>760
撮る方向を変えて撮った写真を繋ぎ合わせてパノラマ写真を作る例がどっかに
あったと思う。（ちょっと探したけど見つからない）
個々の写真の端はそれぞれピタッと合わないので伸ばしたり縮めたりして合わせ
ていた。伸ばしたところは当然ボーとしていた。

762 ：デフォルトの名無しさん：2006/01/22(日) 23:21:52

>761

レスありがとうございます。ところで自己解決しました。
原画像を読み込む配列IMAGE[x,y]を、
原画像の縦横のピクセルの値をそのままコピーするのではなく、
縦横とも＋２０にとってまず内部を全部背景色で塗り、
その後で原画像を[10,10]平行移動して画素値をコピーしました。
この配列をもとに座標変換を行い、線形補間…云々を行うとできました。
原画像を背景色が取り囲んでいる画像を変換しているわけですから、
画像の端もきれいに線形補間されるというわけです。

763 ：デフォルトの名無しさん：2006/01/23(月) 00:50:13

hough変換の(画像の傾きθを求めるときの)精度を向上させる方法で
何か良いものはないですか？
分解能上げるだけとか最小二乗法の参照する点を増やすだけだと
処理速度が落ちてしまうし、なるべく処理速度を減少させないで精度を
上げる方法があれば良いんですが。

因みに対象画像はカメラ取り込んだ格子模様を2値化処理をかけて
特徴を抽出したものです。

764 ：デフォルトの名無しさん：2006/01/23(月) 03:31:00

>>754
画像データがいつでも8ビットであると決まっているわけではないし、
実際、計測分野などでは8ビットでは全然足りない。そうかと思うと、
RGBそれぞれ5ビットとか6ビットのハードもある。

データ幅として8ビットを採用している場合でも、例えば家庭用テレビの
デジタル回路などでは、同期信号のパルスの高さまで含めて256段階で
表現しているので、画像のRGB値のとりうる範囲は0から255ではなく、
それよりも狭い。

そんなわけで、表現可能な上下限の幅を1.0として正規化するほうが一般的。
ここでいう「一般的」とは、「世間で広く使われている」という意味ではなくて、
「特定のハードウェアの仕様から独立している」という意味。

765 ：754：2006/01/23(月) 12:52:04

なるほど、ありがとうございます。

766 ：デフォルトの名無しさん：2006/01/23(月) 22:18:21

二値化した画像上に二等辺三角形があり、その二等辺三角形の重心を求める
プログラムは作成することができました。
しかし、周囲長・主軸方向を求めるにはどのようにしたらよいのかわかりません。
どなたか教えていただけたらと思います。

以下は、重心を求めるプログラムの一部です。

for(ix=1; ix<640;ix++){
for(iy=0;iy<480;iy++){
if (userimage[iy][ix]>=128){ //もし閾値が１２８以下であれば
userimage[iy][ix]=0; //閾値を０にする
points = points++;
sumX = sumX+ix;
sumY = sumY+iy;
}
else{
userimage[iy][ix]=255; //それ以外であれば閾値を２５５にする
}
}
}
pgX = sumX / points;
pgY = sumY / points;

767 ：デフォルトの名無しさん：2006/01/23(月) 22:28:32

関係ないが閾値という言葉の使い方が間違っている希ガス

768 ：デフォルトの名無しさん：2006/01/23(月) 22:36:03

すみません。
128以上の画素値を
画素値０にする

でした。少し勘違いがあったようです。

769 ：デフォルトの名無しさん：2006/01/23(月) 23:44:06

>>766
まず頂点の座標を求めてはどうか

770 ：デフォルトの名無しさん：2006/01/24(火) 01:13:37

2値画像中の多角形とか楕円の検出って懐かしいな。
この辺の成果がまとめられた本とか文献って無いのかな？

771 ：デフォルトの名無しさん：2006/01/24(火) 10:41:53

　恥ずかしながら、頂点の検出とはどのようにやるのでしょうか。

772 ：デフォルトの名無しさん：2006/01/24(火) 11:18:03

触ると痛い

773 ：デフォルトの名無しさん：2006/01/24(火) 12:39:00

辺が平行とか垂直じゃなければ、pointsにしたところの
XYのそれぞれ最大最小に頂点の情報が少し得られる気がする。
あとは、重心位置と二等辺の条件でうまく束縛できるかも。

逆に二等辺三角形を描いてみて、元画像との誤差を最小にしていくとか。

774 ：デフォルトの名無しさん：2006/01/24(火) 13:10:05

>>771
2値化がうまくいっていると仮定して：

(1)たぶん遅いやりかた
重心から一番遠い点は頂点の1つ。
その頂点から一番遠い点はもう一つの頂点。
２頂点を結ぶ線分から一番遠い点は最後の頂点。

(2)ちょっとだけ工夫
各ラインの最左点と最右点について、
すぐ上のラインの最左点、最右点との変移を調べてゆく。
変移が変わったらそのあたりが頂点。

775 ：771：2006/01/24(火) 13:51:28

なるほど、ありがとうございます。

776 ：デフォルトの名無しさん：2006/01/24(火) 14:01:46

>>774
(1)で2つ目の頂点を見つけるところまでは、
「距離」としてdx^2 + dy^2 ではなく | dx | や | dy | を
使って簡略化してもよいような気がする。

三角形を1次元に押しつぶせば、左右の点はそれぞれ
もとの三角形の頂点になるから。

777 ：デフォルトの名無しさん：2006/01/24(火) 22:09:21

ありがとうございます。
（１）の簡単なやり方で求めました。
ユークリッド距離を用いて一番遠い画素を見つけ出しました。
コレで一応問題解決です。

この頂点が求められたので、角度θも求めることができました。
tanθ=dy/dx

コレで頂点がどちらを向いているかを把握することができます。
ヒントをありがとうございました。

778 ：デフォルトの名無しさん：2006/01/25(水) 00:13:15

アフィン変換かかってる画像に対しての
テンプレートマッチングを高速かつロバストに行いたいんですけど
どうすればいいでしょうか…

Harris特徴点から幾何学的にマッチングするといいらしいんですが
具体的にどうすればいいのかまったくつかめません。

779 ：デフォルトの名無しさん：2006/01/25(水) 11:09:57

>766
2値化、頂点の検出を別々にするのなら。
以下のようにしたほうが速いと思う。
char *p[sizeof(unsigned int)];
unsigned char *pp;
unsigned int *up;
int xmin, xmax, ymin, ymax;
int foo;
p[0] = image;
for(i=1;i<sizeof(unsigned int);i++){
p[i] = p[i-1]+1;
}
//一気に2値化
for(i=0;i<480*640/sizeof(unsigned int);i++){
for(j=0;j<4;j++){
*p[4*i+j] >>= 7;
}
}
up = image;
for(i=0;i<480*640/sizeof(unsigned int);i++){
*up ^= ~(unsigned int)0;
}
//2値化完了

780 ：デフォルトの名無しさん：2006/01/25(水) 11:10:58

//最小頂点検出
pp = image;
while(*pp == 255){
pp++;
}
foo = pp - image;
ymin = foo / 640;//このときのxもfoo % 640で求めておいてあげて。
//最上頂点検出
pp = image + (640 * 480 - 1)
while(*pp == 255){
pp--;
}
foo = pp - image;
ymax = foo / 640;//このときのxもfoo % 640で求めておいてあげて。

//ymin <= iy <= ymaxの範囲でループをまわして最左最右頂点を見つける。
んで、4点の距離を比べて三角形の頂点3点を見つける。
頂点から重心を求めるという風にしたほうが速いと思う。

while()辺りからめんどくさくなったので途中止めにしてしまった。
ごめん。

781 ：デフォルトの名無しさん：2006/01/25(水) 11:25:45

一気に2値化で、論理シフトしかできない場合は

up = image;
pp = up;

for(i=0;i<480*640/sizeof(unsigned int);i++){
*up[i] &= 0x80808080;
*up[i] >>= 7;
for(j=0;j<4;j++){
pp[4*i+j] = -pp[4*i+j]);
}
}

とすれば良いかも。

782 ：デフォルトの名無しさん：2006/01/26(木) 04:56:40

>>778

Hough変換とかでぐぐって文献名調べたら、
図書館で探しましょう。

関連研究から高速化技法まで詳しく解説してくれている論文が色々あります。

783 ：デフォルトの名無しさん：2006/01/26(木) 10:22:46

>>782
m9（＾Д＾）ﾌﾟｷﾞｬｰｰｰｯ

784 ：デフォルトの名無しさん：2006/01/26(木) 12:29:05

>>782
m9（＾Д＾）ﾌﾟｷﾞｬｰｰｰｯ

785 ：デフォルトの名無しさん：2006/01/26(木) 13:36:53

>>782
m9（＾Д＾）ﾌﾟｷﾞｬｰｰｰｯ

786 ：デフォルトの名無しさん：2006/01/26(木) 17:57:22

いったい何事かと思ったよ。

787 ：デフォルトの名無しさん：2006/01/26(木) 20:27:35

まぁm9（＾Д＾）ﾌﾟｷﾞｬｰｰｰｯといいたくなるのはわかるが、ガキだらけだな。

788 ：デフォルトの名無しさん：2006/01/26(木) 21:03:59

>>763
亀レス

結局の処、傾き求めるときにhoughと最小二乗どっち使ってんの？
処理速度考えるんなら最小二乗法の方が良いだろうし精度なら
houghの方が良いのかな、普通の直線式で表せないものもでるだろうし。

789 ：デフォルトの名無しさん：2006/01/26(木) 22:10:03

>>782
generalized hough transform使えってことですか？
一般化ハフじゃ残念ながら話にならんのですよ…
特徴点列から幾何学マッチングしたいんですよ…

790 ：デフォルトの名無しさん：2006/01/27(金) 01:01:09

このスレは実にハードですね

791 ：デフォルトの名無しさん：2006/01/27(金) 14:06:54

>>789
そういうのって特徴点の位置関係を属性付きグラフとかで表現するのかな?
点集合のマッチングを固有値展開でできると聞きかじったこともあるけど･･･
素人だけど興味あるな。

792 ：デフォルトの名無しさん：2006/01/27(金) 19:33:53

>>778

プギャーといわれてちとブルーだけど、私自身現在勉強中の身なので的外れならごめんなさい。

思うにHarris等の特徴点から直接、高精度の相似変換パラメーターを得るのは難しいのではないでしょうか？
領域や投票空間を絞り込んで候補立てすることは可能だと思いますが。

GHTだと話にならないということでしたが、それは速度についてですか？
絞り込んだあとでしたら、様々な高速化技法も提案されてますし、試してみる価値はあると思います。

793 ：デフォルトの名無しさん：2006/01/27(金) 20:39:14

>>792
＞　思うにHarris等の特徴点から直接、高精度の相似変換パラメーターを得るのは難しいのではないでしょうか？

以前、ビジョン関係の展示会で特徴点集合によるパタン検出のデモを見たんだ。
マッチングも変換パラメータ推定もやってた。
探索パタンのデータベース件数が100件位だったけど、普通のノートPCで10fps程度で処理してたんで驚いた。
製品名は忘れたけどさ。

794 ：デフォルトの名無しさん：2006/01/27(金) 21:00:10

>>793

http://www.cognex.co.jp/vision/technical.asp
これじゃないですか？

ここ「論文」って名前のカタログしかおいてないんだよね…

795 ：デフォルトの名無しさん：2006/01/29(日) 02:38:19

OpenCVのソース読んでて思ったんだけど、みんなこの位のプログラム平気で書いてるの?
理論とかじゃなくって実装のスキルにおいての話。
ヘッダ部分つーか、関数のプロトタイプ生成するのに##、#使ってるのとかはじめてみた。
ほかにもいっぱい参考になるところあったんだけどさ・・・。
俺と俺の周りって相当レベル低い？

スレ違いなんでsageで…。

796 ：デフォルトの名無しさん：2006/01/29(日) 02:54:57

大人数での仕事してたら自然とそうなるが

797 ：デフォルトの名無しさん：2006/01/29(日) 11:38:19

>>795
ソースの見た目じゃなくて性能とかで比べてみたら？
自分の方が見た目拙くても速いって場合とかもあるしな

798 ：793：2006/01/29(日) 12:15:25

>>789
家探したらデモ見せてもらった製品のパンフレットが出てきた。
ここの製品だ。
http://www.evolution.com/jp/

ついでに、いろいろ調べまわったらどうもLowe先生（大御所、特徴点がどうのって言ってるんならSIFT feature位知ってるよな?!）もかかわってるようだ。
この人の文献にそれらしきもがあったから参考にしたら?
http://www.cs.ubc.ca/~lowe/

799 ：デフォルトの名無しさん：2006/01/29(日) 12:21:45

>>795
アルゴリズムを知っているかということと，言語の細かい仕様まで理解して利用しているか，ということは別だしね。

800 ：デフォルトの名無しさん：2006/01/29(日) 12:27:01

>>798
ビジョン関係の世界的大御所ってどんな人がいるのかね?
俺、カナデさんくらいしか知らんわ。

801 ：デフォルトの名無しさん：2006/01/29(日) 12:45:04

>>798
確率とか統計は嫌いやわ。
俺はこれを薦める。
http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/trans/tp/&toc=comp/trans/tp/2003/02/i2toc.xml&DOI=10.1109/TPAMI.2003.1177151

802 ：デフォルトの名無しさん：2006/01/29(日) 13:26:45

上の人と同じように２枚の画像のレジストレーションに
Harris特徴を対応付けして射影変換行列を求めてます。
ぱっと見た目には正確に重なるのですが、拡大してみると
一部では数ピクセルのずれが出てぼけてしまいます。

対応点ベースでは限界あって、
さらに精度を上げるには
射影行列の成分を最急降下法などで求める
方がよいのでしょうか？

803 ：デフォルトの名無しさん：2006/01/29(日) 22:14:54

>>798,801
778です。SIFT feature失念してました。
以前パノラマ自動生成のときに調査したんですが
考えてみりゃ同ジャンルの問題でしたね。
ありがとうございました

論文読んで見ます

>>802
最小二乗法でパラメータ最適化してみては？

804 ：デフォルトの名無しさん：2006/01/30(月) 11:19:38

>>802
つーかさ、二つの特徴点集合の対応を矛盾無く決定するのが難しいんであって、射影行列の成分を求めるのは難しくない。

805 ：802：2006/01/30(月) 12:47:28

>>802
ランダムサンプルした対応点を最小二乗法で解いて
射影行列の成分を求めてます。
その中で画像間の絶対濃度差が少なくなるものを選んでます。
もう少し精度（絶対濃度差の意味で）を上げたいのです。

>>804
仮に対応付けに問題ないとしても特徴点自体の位置精度に
問題があると思うのです。

806 ：デフォルトの名無しさん：2006/01/30(月) 15:30:28

>>805
>特徴点自体の位置精度に問題
せいぜい重み付最小二乗問題か共分散の固有値問題程度じゃないの？
解き方山ほど在るじゃない。
俺の見識が狭いのかな?

>一部では数ピクセルのずれが出てぼけてしまいます
それって歪曲収差とかのレンズ校正に起因しないズレ?

807 ：デフォルトの名無しさん：2006/01/30(月) 17:04:50

>>806
m9（＾Д＾）ﾌﾟｷﾞｬｰｰｰｯ

808 ：デフォルトの名無しさん：2006/01/30(月) 17:57:13

>>806
　　　　　　　　　　　　ｽﾎﾟﾎﾟﾎﾟﾎﾟﾎﾟﾎﾟｰﾝ!!!
　　　　　　。　　　　　。
　　　　　　　　。　　｡　。　。ﾟ
　　　　　　。　　｡ﾟ。゜。ﾟ｡　。
　　　　　　/　／/ ／／
　　　　　(　Д ) Д)Д))

809 ：デフォルトの名無しさん：2006/01/30(月) 18:15:00

この香ばしい人たちいなくなってくれないかな。

810 ：デフォルトの名無しさん：2006/01/30(月) 18:19:45

>>808
目玉の数がおかしくね？

811 ：デフォルトの名無しさん：2006/01/30(月) 20:32:47

目玉と一緒に涙も出てんでしょ。

812 ：デフォルトの名無しさん：2006/01/31(火) 07:08:55

このスレは最もハードですか？

813 ：デフォルトの名無しさん：2006/01/31(火) 09:12:41

いいえ、このスレはもっともハードではありません。

814 ：デフォルトの名無しさん：2006/01/31(火) 09:56:37

どのスレが最もハードですか？

815 ：802：2006/01/31(火) 15:19:22

>>806
１枚の画像に、人工的に作成した射影行列で
変形させたものでも、少しずれるのです。
理想的な場合よりも平均濃度残差が大きいので
もう少し近づけたいのです。

816 ：デフォルトの名無しさん：2006/01/31(火) 16:04:46

　おら！でてこい >>806
＿＿＿＿　＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　∨　　　　　　　
　
　　　　　　　　　　　　ドッカン
　　　　　　　　　ｍ　　　　ドッカン
　　━━━━━））＝　　　　　　　　　☆ゴガギーン
　　　　　 ∧_∧ |　|　　　　　　　　　／　　　　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣
　　　　　（　　　）|　|＿＿＿＿＿　　　　∧＿∧　　　＜　 >>806でかい口叩いてんじゃねーよ！
　　　　　「　⌒￣　| 　　　　　　||　　　（｀∀´　）　　　　＼＿＿＿＿＿＿＿＿＿＿＿
　　　　　|　　　/ 　　　　　　　|/　　　/ 　　＼
　　　　　|　　　| | 　　　　　　　|　　　 | | 　　/＼＼
　　　　　|　　　 | | 　　　　　　　|　　へ//|　　|　　| |
　　　　　|　　　 | |. 　　　　◎　|／,へ＼|　　| 　 | |
　　　　　|　∧　| |　　　　　　　　|／　　＼　　/　（　）
　　　　|　|　|　| >　　　　　　　|　　　　　|　|
　　　　 / /　/ / |.　 |三三|. .　 |　　　　　|　|
　　　 / /　/ /　| 　　　　　　　||　　　　　|　|
　　　 / /　/ /　└──┴──┘　　　　 |　|

817 ：デフォルトの名無しさん：2006/01/31(火) 16:37:22

なんか懐かしいAAだな（ｗ

818 ：デフォルトの名無しさん：2006/01/31(火) 20:18:41

やはりこのスレが最もハードですね？

819 ：デフォルトの名無しさん：2006/01/31(火) 20:20:25

>>815
良い解法を思いついたが、テキストで書くのは困難だ。

820 ：デフォルトの名無しさん：2006/01/31(火) 20:26:46

>>819
それなんてフェルマー？

821 ：デフォルトの名無しさん：2006/01/31(火) 20:50:43

/*imgに描画していく。img[height][width]
*描画文字列 *msg, 文字の高さ msg_h
*描画文字列の初期位置 x, y
*原点は画面左上、画面は最初白で塗りつぶされており、黒で文字を書いていく。
*/
void img_printf(uchar *img, int height, int width, int y, int x, char *msg, int msg_h)
{
.....
}

というような関数を作りたいんですが、文字の描画方法が分かりません。
winapiを使わずになるべくC言語の機能のみで作りたいのですが、
何かいい方法か、サイトを教えていただけないでしょうか。
直線、四角形は自分で描画できるのですが、文字列だけはどうやったら
いいのか全く分かりません。

822 ：デフォルトの名無しさん：2006/01/31(火) 21:07:31

>>821
フォントのために何らかのAPIが必要と思われ。
直線の組み合わせで文字を描画する関数を用意するとか、スケーラブルフォントでなくていいなら自分でビットマップフォントを用意して透過処理をしながら貼り付けるとか。

GLUTとかOpenCVは前者の方法で文字を書くようになってたかな？
ライブラリを作ることが目的で無いなら、既存のAPIを使うようにする方がいいんじゃない？
WinAPIのラッパーみたいのをつくるとか。

823 ：デフォルトの名無しさん：2006/01/31(火) 21:51:54

>822さんありがとうございます。
最低限16進数が表示できればいいので、自前で文字を描画する関数を作成するこ
とにします。

失礼しました。

824 ：デフォルトの名無しさん：2006/01/31(火) 21:53:25

>>820
スレ違いだけど、俺はフェルマーは本当はちゃんと
証明できてなかったのではないかと思うｗ
不完全な証明で証明できた気になってただけみたいな。

825 ：デフォルトの名無しさん：2006/01/31(火) 21:58:30

>>823
出来たら公開きぼん

826 ：デフォルトの名無しさん：2006/01/31(火) 22:57:16

>>823
自分も bitmap の絵を何分割化してそれぞれを外字で登録して、その外字を
TextOut() したら絵になるんでは思って調べたことがあるが、外字登録とか
を API で行う方法がわからず挫折したことがある。外字はファイルで人に
渡せて貰った人が登録すれば、その字は出るんだよね。

827 ：デフォルトの名無しさん：2006/02/01(水) 19:37:12

　おら！でてこい >>806
＿＿＿＿　＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　∨　　　　　　　
　
　　　　　　　　　　　　ドッカン
　　　　　　　　　ｍ　　　　ドッカン
　　━━━━━））＝　　　　　　　　　☆ゴガギーン
　　　　　 ∧_∧ |　|　　　　　　　　　／　　　　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣
　　　　　（　　　）|　|＿＿＿＿＿　　　　∧＿∧　　　＜　素人がでかい口叩いてんじゃねーよ！
　　　　　「　⌒￣　| 　　　　　　||　　　（｀∀´　）　　　　＼＿＿＿＿＿＿＿＿＿＿＿
　　　　　|　　　/ 　　　　　　　|/　　　/ 　　＼
　　　　　|　　　| | 　　　　　　　|　　　 | | 　　/＼＼
　　　　　|　　　 | | 　　　　　　　|　　へ//|　　|　　| |
　　　　　|　　　 | |. 　　　　◎　|／,へ＼|　　| 　 | |
　　　　　|　∧　| |　　　　　　　　|／　　＼　　/　（　）
　　　　|　|　|　| >　　　　　　　|　　　　　|　|
　　　　 / /　/ / |.　 |三三|. .　 |　　　　　|　|
　　　 / /　/ /　| 　　　　　　　||　　　　　|　|
　　　 / /　/ /　└──┴──┘　　　　 |　|

828 ：デフォルトの名無しさん：2006/02/01(水) 19:42:21

質問なんですが、pdfで選択した部分を画像としてepsで保存したいのですが、
上手くいきません。たとえばpdfファイル上のある図をepsで保存して、
tex上に貼りたいのですが、どうすればいいのでしょうか？

829 ：デフォルトの名無しさん：2006/02/01(水) 19:47:13

Viewr からキャプチャ、切り取り、保存

830 ：デフォルトの名無しさん：2006/02/01(水) 19:50:37

viewrとはacrobat readerでしょうか？

831 ：デフォルトの名無しさん：2006/02/01(水) 19:57:50

lanczos3での画像縮小を解説している本ってないですか？

832 ：デフォルトの名無しさん：2006/02/01(水) 20:29:37

最近は、Foxit Readerが軽くていいな。

833 ：デフォルトの名無しさん：2006/02/01(水) 22:04:14

>>829
acrobar readerで切り取ってもepsにならんのじゃない？
acrobatを使うとできるのかな？
Unixのツールにpdf2epsとかpdf2psとかあるみたいだけど、図とか取り出せたっけ？

834 ：デフォルトの名無しさん：2006/02/01(水) 22:10:18

だから画面キャプチャ

835 ：デフォルトの名無しさん：2006/02/01(水) 22:11:39

> lanczos3での画像縮小を解説している本ってないですか？

Bicubic ができるんなら補間関数が違うだけで論理は同じ

836 ：デフォルトの名無しさん：2006/02/01(水) 23:23:17

>>835
その理論だと、○ンコもアナルも同じになるが？？？

837 ：デフォルトの名無しさん：2006/02/01(水) 23:33:35

>>836
本気でそう思ってるのならちょっと諦めた方が・・・

838 ：デフォルトの名無しさん：2006/02/01(水) 23:34:23

>>831
Graphics Gems III

839 ：デフォルトの名無しさん：2006/02/02(木) 01:39:29

>>831
http://www.worldserver.com/turk/computergraphics/ResamplingFilters.pdf
これよめばわかる。

840 ：デフォルトの名無しさん：2006/02/02(木) 03:59:24

このスレは板を代表するハードさですか？

841 ：831：2006/02/02(木) 13:41:22

すんません、もうちょっと質問させて下さい。

例えば４０％に縮小するとして、

平均画素法だと、
下みたいな3×3の画素の情報で 0 の部分は100%、2の部分は50%、4の部分は25%の重みを
付けて縮小後の1つの画素を決めるわけですよね。

002
002 ---> "0"*4*1.00 + "2"*4*0.50 + "4"*1*0.25 = 6.25 個々のRGBの重み付けの和を6.25で割る。
224

Bicubic で、拡大する場合、4×4の画素から曲線補間してやるようなのですが、
縮小する場合も、本来必要ないと思われる、外側の画素の情報も含めて重み付けて処理するんでしょうか？
また、上の例の場合、どの範囲の画素までが補間の対象になるのでしょうか？

>>838
洋書は苦手なのとちょっと値段が・・・。
>>839
そこ、見たんですが英語が苦手なのもあり、さっぱり分かりませんでした。

842 ：デフォルトの名無しさん：2006/02/02(木) 13:53:27

まずは英語を勉強しろということだ
どっちみちプログラミングやる上で英語の文献読めなくては
下の下

843 ：デフォルトの名無しさん：2006/02/02(木) 16:09:05

>>842
ITドカタに英語とか数学とか言っても無駄だって。

844 ：デフォルトの名無しさん：2006/02/02(木) 16:24:46

それはプログラミングではなくて学問全般の話だね
論文は書くのも読むのも英語
プログラミング全般に当てはめるのは無理があるんじゃないかな

845 ：デフォルトの名無しさん：2006/02/02(木) 16:30:30

なにいってんのこいつ

846 ：デフォルトの名無しさん：2006/02/02(木) 19:48:05

おまえらそんなことより、Magick++で画像の幅を取得する方法がわからず、
widthやGetWidthのような文字列ばかり探し、４０分近く
ドキュメントの中をさまよったオレを力の限り罵れ。

847 ：デフォルトの名無しさん：2006/02/02(木) 19:49:03

>>846
やーい。

848 ：デフォルトの名無しさん：2006/02/02(木) 19:57:47

>>846は都昆布

849 ：デフォルトの名無しさん：2006/02/03(金) 12:24:20

>>844
プログラミング全般も英語は重要じゃね?
情報産業がアメリカの一人勝ちという状況を鑑みると仕方なくね?
新しいアイデアや技術を発信したり触れたりするには英語が必須じゃね？
それを理解したり説明したりするとき数学を必要とすることは多くね？
それができなきゃ一生下請けドカチンじゃね?

850 ：デフォルトの名無しさん：2006/02/03(金) 17:25:47

>>848
厳しさの中に優しさを見た。

851 ：デフォルトの名無しさん：2006/02/03(金) 17:31:36

>>850
kwsk

852 ：デフォルトの名無しさん：2006/02/03(金) 17:51:37

>831
http://www.marumo.ne.jp/
AUFをたどってくと、ソースやら解説やらあるから読むべし

便乗して質問してもよろしい？

Bicubicで縮小時の場合、座標変換した元画像の座標の周辺4画素を
参照すると思うんだけど、縮小がきれいといわれるLanczos3の場合、
縮小画像の6画素分に含まれる元画像をすべて参照するわけだよね？
同じようにBiCubicでも、縮小画像の周辺4画素に含まれる元画像の
画素を参照すれば、それなりにきれいにできるような気がするんだけど、
そうしないのはなんででしょう？

853 ：デフォルトの名無しさん：2006/02/03(金) 17:58:50

>>852
実際にやってみろよ
というか、おまいさんは、根本から何か誤解しているから、Bicubicから勉強し直せよ

854 ：852：2006/02/03(金) 18:26:18

コード自体は問題なく理解できているんですけどね・・・。
なんとなく、補完時の重みを出す関数の違いくらいしか感じないので。
実際、拡大時にはそうなりますよね？

理論的な話をされるとイマイチよくわからんのは確かです。
根本的な誤解があるのなら、そのへんのとっかかりだけでも教えてもらえると
嬉しいんですけど・・・。

855 ：デフォルトの名無しさん：2006/02/03(金) 18:38:44

おそらくコード云々のレベルじゃないと思う。
もう一度、そこらの本を読み直してみてね。

856 ：852：2006/02/03(金) 18:52:25

ネットで拾ったコードを解析して実装してるだけなんで、理論などが書かれた本は
持ってませんので、どうしようもないっす。
別に研究者でもないし、処理自体はまともに動いてるので、別に答えてもらえないなら
それはそれでしょうがないです。ちょっと疑問に思っただけなんで。

そんなに簡単な話じゃないって事なんですかね。
答えが本を読めしかでてこないくらいには。
ここの話はいつもレベルが高そうなんで、さっくり答えてくれるハイレベルな人が
いるのかなぁとも思ったんですが・・・。残念。

857 ：デフォルトの名無しさん：2006/02/03(金) 19:04:59

>>856 は釣りに決定しました

↓気を取り直して次の質問ﾄﾞｿﾞｰ

858 ：856：2006/02/03(金) 19:15:01

答えがもらえなくて残念、的なことを書くと、大概釣りって言われるよね・・・orz

859 ：デフォルトの名無しさん：2006/02/03(金) 19:18:29

>>854
だって大元の質問>>831が「lanczos3での画像縮小を解説している本ってないですか？」なんだも～ん。

860 ：デフォルトの名無しさん：2006/02/03(金) 19:21:37

ところで、みなさん、画像処理でGPUが実際使われているって話は、すでにあります？
GPGPUが割と面白そうなんですけれども。

861 ：デフォルトの名無しさん：2006/02/03(金) 19:23:26

>>854
> 理論的な話をされるとイマイチよくわからんのは確かです。
> 根本的な誤解があるのなら、そのへんのとっかかりだけでも教えてもらえると
誤解かどうかはよくわからないけど、とりあえず

つ[インパルス応答、フーリエ変換]

862 ：デフォルトの名無しさん：2006/02/03(金) 19:25:54

Windows APIの StretchBlt 最強伝説

863 ：デフォルトの名無しさん：2006/02/03(金) 19:28:59

>>862
ある意味真理だな

864 ：デフォルトの名無しさん：2006/02/03(金) 19:29:14

>>862
処理結果がVGAカード(?)に依存するけど、表示させるだけならそれでいいよね。

865 ：デフォルトの名無しさん：2006/02/03(金) 19:31:02

>>863
つまり、ITドカタの人たちは人の作ったブラックボックスを組み立てるだけでいいと・・・。

866 ：デフォルトの名無しさん：2006/02/03(金) 19:37:34

>>865
その通り。「車輪の再発明はするべきではない」という免罪符の元にな。

867 ：デフォルトの名無しさん：2006/02/03(金) 19:38:23

>>860
興味あるけど、まだ手出してないな。
一般に広がるには最低でもdoubleが使えるとか、浮動小数をまじめに丸めるとかが条件だと思う。
GPUから高速線形代数専用チップに進化してくれるかな?

868 ：852：2006/02/03(金) 19:43:21

>>861
どもです。ググってみました。
複雑そうなんで、時間をかけて理解してみます。

869 ：デフォルトの名無しさん：2006/02/03(金) 19:46:09

一応関連スレ

GPGPU
http://pc8.2ch.net/test/read.cgi/tech/1128780920/

サンプルとか出回ると面白そうだね

870 ：デフォルトの名無しさん：2006/02/03(金) 21:50:43

>>861
そのキーワードから理解に到達したら結構すごいな。
キーワードを含む分野があまりに広大なもんで・・・

871 ：デフォルトの名無しさん：2006/02/03(金) 21:56:12

>>870

>>861 は時間をかけて理解してみるっていってるんだから大丈夫だろw

872 ：デフォルトの名無しさん：2006/02/03(金) 21:57:14

>>871
('A`)

873 ：861：2006/02/03(金) 22:55:36

>>870
あー、そうだね。
では追加しよう。

インパルス応答、フーリエ変換
　　│　　　　　　　　　　　　│
　　│ピクセル単位なので、嫌でも離散化せざるを得ないことに気づく
　　↓　　　　　　　　　　　　│
方形波、フーリエ変換　　.│
　　↓　　　　　　　　　　　畳み込み
Sinc関数　　　　　　　　　 │
　　↓　　　　　　　　　　　　↓
Sinc関数を近似して畳み込みをしたものがLanczos法であることに気づく
　　↓
(ﾟдﾟ)ｳﾏｰ

874 ：デフォルトの名無しさん：2006/02/03(金) 23:53:34

>>873
ヒントつーか、ほぼ答えだね。
それだけ示されて理解できなかったら信号処理の基礎知識が足りないと言うことでFA?

875 ：デフォルトの名無しさん：2006/02/03(金) 23:55:07

∩(　´Α｀)＜　先生、Sinc関数って何？

876 ：デフォルトの名無しさん：2006/02/03(金) 23:58:02

>>875
sinc(x)　=　　　1　　　　if x =0
　　　　　　　sin(x)/x　 otherwise

877 ：デフォルトの名無しさん：2006/02/03(金) 23:58:40

あー…窓関数？

878 ：デフォルトの名無しさん：2006/02/03(金) 23:59:07

Integral [ sinc[x], { x, -Inf, Inf } ] = Pi

879 ：デフォルトの名無しさん：2006/02/04(土) 00:00:51

>>877
使い方としてはそう言うことだね。

880 ：877：2006/02/04(土) 00:02:31

>>879
画像処理なんてほとんどやらんから忘れちまったけど…
なんか三次関数で近時して使うんだっけ？
(線形内挿しか実装したことない…)

881 ：デフォルトの名無しさん：2006/02/04(土) 00:04:38

>>873の先生戻ってきてください!

882 ：デフォルトの名無しさん：2006/02/04(土) 09:38:32

ところで、このスレの人は、画像処理自体にマルチスレッド使ってる？
この前、奇数と偶数のスキャンラインで別々にスレッド立ててみたけど
全然速くならなかったよ
プログレスバー表示以外でなんかマルチスレッドのうまい使い道あるのかな？

883 ：デフォルトの名無しさん：2006/02/04(土) 09:51:19

>>882
CPU二つ積んでれば速くならね?

884 ：デフォルトの名無しさん：2006/02/04(土) 10:12:07

> この前、奇数と偶数のスキャンラインで別々にスレッド立ててみたけど
> 全然速くならなかったよ

ワラタ。「スレッド」意味が分かっていれば、こんな馬鹿なことはしないだろ。

885 ：デフォルトの名無しさん：2006/02/04(土) 13:33:43

人の論文内容を勝手に実装して公開するのって問題ないの？

886 ：デフォルトの名無しさん：2006/02/04(土) 14:01:01

ライセンスによるだろ。

887 ：デフォルトの名無しさん：2006/02/04(土) 15:30:12

論文にライセンス？　そうなの？

888 ：デフォルトの名無しさん：2006/02/04(土) 16:40:10

特許とかの話でしょ。
ライセンスっていうとGPLとかっていう印象には確かになるな

889 ：デフォルトの名無しさん：2006/02/04(土) 16:42:48

論文じゃないけど、GIFとか問題なかったはずなのに
問題になったべ。

雑誌や論文に掲載されたものは、特許の対象にはならない
ことになっているらしいが、

> 特許出願は論文発表前に行いましょう。
>
> 論文発表をしてしまうと、その内容が公に知られることとなります（公知）。その後、特許出願をした場合は、
> たとえそれが発明者自身の発表であったとしても、公知の技術として特許を受けることができません。
> それゆえ、論文発表は、必ず特許出願をした後に行うことが重要です。

知って得する特許の世界
http://www.tohoku.meti.go.jp/koho/kohoshi/mokuji/0105/tokkyonosekai.htm

何が起こるかﾜｶﾗﾝのがこの業界。発表前に特許を取られている可能性が高い、と。

890 ：デフォルトの名無しさん：2006/02/04(土) 16:50:09

著作権と特許権の二つが別々にからむからめんどいんだよな

891 ：デフォルトの名無しさん：2006/02/04(土) 16:51:24

>>890
example希望

892 ：デフォルトの名無しさん：2006/02/04(土) 17:02:55

>>891
XviD

893 ：デフォルトの名無しさん：2006/02/04(土) 17:19:49

例のエロゲ騒動は、LGPL違反ばっかり話題になってたけど、
MPEG4特許も侵害してたんだよな多分。

894 ：デフォルトの名無しさん：2006/02/04(土) 18:51:54

>>890
>著作権と特許権の二つが別々にからむからめんどいんだよな
著作権：論文は著作物なので文章や図版を引用する場合出典を明らかにすること、著作者に許可を得ることが必要。
特許権：特許出願/取得された手法を使用する場合権利者の許可が必要。

っていう理解でいいのかな?

895 ：デフォルトの名無しさん：2006/02/04(土) 18:56:30

>>882
CPUが二つ以上ある場合OSが対応していればスレッドをそれぞれのCPUに割り当ててくれるっていう話でしょ?
処理の並列性とか問題の局所性とかも考慮する必要があるから、単純に複数のスレッドに処理を割り当てればいいという問題じゃないよ。

896 ：デフォルトの名無しさん：2006/02/04(土) 18:59:49

>>894
例えば、論文にCでのサンプルとか載ってたら、それを自分のコードで使うには、
決められたライセンスに従わないと、著作憲法違法になりかねない、ということだね。

そういえば、GPL3のDraftでは特許権にまで記述が及んだらしいんだけど、
GPL2に関しては、著作権についてのみのライセンスと思っていいんだよね？
XviDとかLameとか見てると。
（二つとも今はLGPLだけど、Lameは元々GPLだった。）

897 ：デフォルトの名無しさん：2006/02/04(土) 20:30:00

>>894
論文にのってるアルゴリズムを使ったソフトってどうなるんだろ？
引用じゃないから、著作権は気にしなくていいんだよね？アイデアだし。
特許とられてたら、プログラム公表したり売ったりは許可なしではだめってことでいいんだよね？
論文に特許とったとか申請中とか書いてないから一々調べんとあかんか。

898 ：デフォルトの名無しさん：2006/02/04(土) 20:37:07

>>897
結局そうなるな。
そういうわけで、特許に侵害しないように、
ソースだけを配布っていう例も結構ある訳だな。

899 ：デフォルトの名無しさん：2006/02/04(土) 20:52:42

>>882
　ｳｨｰｯｽ　 ∧＿∧∩　　／￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　（´∀｀*//　＜　安かったんでIntelのDual Core買ってきたゾー
　　　　⊂二　　／　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　 |　　)　　/
　　【CeleD】　￣）
　　　　　 ( <⌒<.<
　　　　　　>/

900 ：デフォルトの名無しさん：2006/02/04(土) 20:53:09

>>899
∵(´ε(○＝(ﾟ∀ﾟ　)

901 ：デフォルトの名無しさん：2006/02/04(土) 20:56:10

>>897
レンダー関係の論文は特許取得されてるのが多いから注意な。
製品に組み込むんだったら特許調査は絶対必要だね。

902 ：デフォルトの名無しさん：2006/02/04(土) 22:03:16

ソース載せときゃいいの？

903 ：デフォルトの名無しさん：2006/02/04(土) 22:08:54

んにゃ、バイナリを配布しなければいいってこと
ソース配布だけで特許侵害が認められたことが無いから

904 ：デフォルトの名無しさん：2006/02/04(土) 22:11:29

j;;;;;j,. ---一､｀　―--‐､_ l;;;;;; 　　　　ソースだけ配布しても
　｛;;;;;;ゝ T辷iﾌ i 　　f'辷jァ　 !i;;;;;　　特許権侵害には当たらない
　ヾ;;;ﾊ　　　　ﾉ　　　　　　　.::!lﾘ;;rﾞ　　
　　 `Z;i　　　〈.,_..,.　　　　　　ﾉ;;;;;;;;>　　そんなふうに考えていた時期が
　　,;ぇﾊ、　､_,.ｰ-､_',. 　　,ｆﾞ: Y;;f 　　　　俺にもありました
　　 ~''戈ヽ　｀二´ 　　 r'´:::.　`!

905 ：デフォルトの名無しさん：2006/02/04(土) 22:15:36

>>904
はいはいワロスワロス（AA略

906 ：デフォルトの名無しさん：2006/02/04(土) 22:26:36

>>903
はいはいワロスワロス（AA略

907 ：デフォルトの名無しさん：2006/02/04(土) 22:32:26

ライセンススレいけよ

908 ：デフォルトの名無しさん：2006/02/04(土) 23:52:57

>>907
URLも貼るのが、親切ってモンだ。それがなければ、タダの煽りレベル。

909 ：デフォルトの名無しさん：2006/02/05(日) 01:57:16

>>907
　ｳｨｰｯｽ　 ∧＿∧∩　　／￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　（´∀｀*//　＜　道ばたで拾ってきたぞ～
　　　　⊂二　　／　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　 |　　)　　/
　　【ﾏｰﾀﾞｰ】　￣）
　　　　　 ( <⌒<.<
　　　　　　>/

910 ：デフォルトの名無しさん：2006/02/05(日) 05:59:51

>>909
URLﾏｰﾀﾞｰ? ﾁﾝﾁﾝ（AA略

911 ：デフォルトの名無しさん：2006/02/05(日) 08:01:16

>>903
へーそうなの？それとも
>>904 なの？
ここで間違えて覚えると後で痛い目みそうだし調べてみるか。

912 ：デフォルトの名無しさん：2006/02/05(日) 08:14:18

調べるもなにも、上で出ていたXviDもLameもそれのせいで、
公式サイトではソースだけで、バイナリは配ってないんだろうが。

913 ：911：2006/02/05(日) 08:17:38

とりあえずちょっとだけぐぐってみた
http://www.initialt.org/lame/patent.html
それで午後のこーだとかソースだけ配布だったのか。
じゃ、論文読んでおもしろそうだな、と組んでみて
ウェブサイトに、作ってみました。とおいてみてもいいのだな。

914 ：デフォルトの名無しさん：2006/02/05(日) 08:21:19

しかし、ソースコードは設計図だからおｋってのもちょっと変だよな。
機械の設計図とは違うんだし。ま、完璧スレ違いか。

915 ：デフォルトの名無しさん：2006/02/05(日) 09:55:32

PHPとかだとどうなるんだ？

916 ：デフォルトの名無しさん：2006/02/06(月) 09:12:59

>>873
>Sinc関数を近似して畳み込みをしたものがLanczos法である

・・・これ、Bicubicも同じなんじゃないの？

917 ：デフォルトの名無しさん：2006/02/06(月) 22:44:22

ちょっとさ、お前らに酒の肴として話し合ってもらいたいことがある。

for(y=0;y<HEIGHT;y++){
for(x=0;x<WIDTH;x++){

918 ：デフォルトの名無しさん：2006/02/06(月) 22:48:46

for(y=0;y<HEIGHT;y++){printf("(　・ω・)ノ●　ウンコー");}
for(x=0;x<WIDTH;x++){printf("('Ａ｀)ノ●　コレでも食ってろ");}

919 ：デフォルトの名無しさん：2006/02/06(月) 22:49:11

舐めてんのか

920 ：デフォルトの名無しさん：2006/02/06(月) 23:57:14

for(y=0;y<HEIGHT;y++){
for(x=0;x<WIDTH;x++){
//image[y*WIDTH+x] = 0xff0000;　プログラマ派
//image[x+y*WIDTH] = 0xff0000;　数学派
}
}
いや、上下のどっちがも前らの好みかなって思ってさ。
漏れはプログラム組むとき、メモリを考えながら組んでるから
上が自然なスタイルなんだが、隣のやつが馬鹿にしてくるからさ。
どっちがいいんじゃろか？

921 ：デフォルトの名無しさん：2006/02/07(火) 00:06:57

>>920
メモリは線形だから、<base>+<offset>が一般的だと思う、だから上を推奨
俺は

922 ：デフォルトの名無しさん：2006/02/07(火) 00:07:37

マジレスすると、x+WIDTH*y
きっと馬鹿にされてるのはy*WIDTHの部分だな

923 ：デフォルトの名無しさん：2006/02/07(火) 00:07:42

どうでもいい

924 ：デフォルトの名無しさん：2006/02/07(火) 00:19:12

正直コードの意味が変わらんのだしどうでも良いよなぁ。
可読性も差なんぞこの程度じゃ0だし

925 ：デフォルトの名無しさん：2006/02/07(火) 00:22:01

俺ならこうする

for(i=0; i<WIDTH*HEIGHT; i++){
　image[i] = 0xff0000;
}

926 ：デフォルトの名無しさん：2006/02/07(火) 00:23:05

一番頭の悪い子ｷﾀ━━━(ﾟ∀ﾟ)━━━ｯ!!!

927 ：デフォルトの名無しさん：2006/02/07(火) 00:26:19

//どっちも中途半端で嫌い

// プログラマ派
for( int *i=image; i<image+(WIDTH*WIDTH); i++) *i = 0xff0000;

// 数学派
int image[HEIGHT][WIDTH];
for(y=0;y<HEIGHT;y++){
for(x=0;x<WIDTH;x++){
image[y][x] = 0xff0000;
}
}

928 ：デフォルトの名無しさん：2006/02/07(火) 00:36:52

>>927
WIDTH*WIDTH ?

// 俺(C++)
std::fill(image,image+WIDTH*HEIGHT,0xFF0000);

929 ：デフォルトの名無しさん：2006/02/07(火) 00:58:08

>>927
気になるんだが

int x[][];
って
int* x[];
と透過なのか？
もしそうなら、
char x[][];
は
char* x[];
と透過になるよな？

で、xはchar*(16bitか32bitか64bit)の配列だから、かなり大きなものになるんじゃないのか？

930 ：デフォルトの名無しさん：2006/02/07(火) 00:58:31

// 漏れ
static inline int index(int x, int y, int width) {return x + y * width;}
for (int y = 0; y < HEIGHT; ++y) for (int x = 0; x < WIDTH; ++x) image[index(x, y, WIDTH)] = 0xff0000;
// とは絶対書かないなぁw

931 ：デフォルトの名無しさん：2006/02/07(火) 08:51:21

画像を扱うクラスのメソッドにindexに相当するものを置くことはよくある

>>929
…なにがいいたいのかﾜｶﾘﾏﾍﾝ。C言語を知らないの？

932 ：デフォルトの名無しさん：2006/02/07(火) 09:19:04

ポインタの配列は互換性がある、程度の認識でいいだろ
文字列代入の時とかで、挙動に違いがあるから、イコールではない

というか、画像処理と関係ないじゃん

933 ：デフォルトの名無しさん：2006/02/07(火) 12:01:53

横からだけど、>>931 なんでわかんないの？
ポインタと配列の違いは？なんてよくある話じゃん。
どっちにしろ画像処理そのものじゃないのでよそでやってほしいが。

934 ：デフォルトの名無しさん：2006/02/07(火) 12:06:13

釣りレベル：MIN-----------+--MAX
　　　　　　　 ∩＿＿＿∩　　　/)
　　　　　　　 | ノ　　　　　ヽ　 ( i )))
　　　　　　　/　　●　　　● | /　/
　　　　　　 |　　　　( _●_)　 |ﾉ　/
　　　　　　彡､　　　|∪|　　　　，/
　　　　　／　　　　ヽノ　　　/´ 　　　ここだクマー

言いたいことがあっても、発言を控えましょう。

935 ：デフォルトの名無しさん：2006/02/07(火) 12:10:24

>>909
読み直して気がついたけど、"殺しのライセンス"の事？
THE BLUE HEARTSだったっけ？
なつかしい。

936 ：デフォルトの名無しさん：2006/02/07(火) 19:44:38

スレ残量：1000----------------+-MAX
　　　　　　　　　 ∩＿＿＿∩　　　/)
　　　　　　　　　 | ノ　　　　　ヽ　 ( i )))
　　　　　　　　　/　　●　　　● | /　/
　　　　　　　　 |　　　　( _●_)　 |ﾉ　/
　　　　　　　　彡､　　　|∪|　　　　，/
　　　　　　　／　　　　ヽノ　　　/´ 　　　ここだクマー
さっさと埋めて次のスレを立てるニダ。

937 ：デフォルトの名無しさん：2006/02/07(火) 19:45:48

誤）MAX
正） 0

938 ：デフォルトの名無しさん：2006/02/10(金) 13:35:51

一気に過疎化したね。

939 ：デフォルトの名無しさん：2006/02/10(金) 18:33:43

あきらめて逃げるのを木の陰から見ているようなもん

他に行く場所がないとまた来るよ

940 ：デフォルトの名無しさん：2006/02/10(金) 20:42:59

うーむ、比喩の意味がわからん＞あきらめて逃げるのを木の陰から見ているようなもん

941 ：デフォルトの名無しさん：2006/02/10(金) 22:03:00

うむ、わかりにくいし、わかってもいみないし、どうでもいいな。

942 ：デフォルトの名無しさん：2006/02/10(金) 22:29:55

画像処理ライブラリを高級言語で実装するのと、アセンブラで実装するのとでは、
処理速度にどれくらいの違いが出るもんなんでしょうか？

高級言語はCでコンパイルはGCCの最適化オプションを指定するものとして、
アセンブラで実装時の速度を1として教えてもらえないでしょうか。

直線・四角形内の塗りつぶし・円の描画などなど・・・

943 ：デフォルトの名無しさん：2006/02/10(金) 22:30:33

>>942
何か勘違いしていないか…？

944 ：デフォルトの名無しさん：2006/02/11(土) 02:43:01

942が書いたアセンブリコードの速度を1とすると
GCCは100くらいだよ
ほんとだよ

945 ：デフォルトの名無しさん：2006/02/11(土) 03:54:43

GCCﾊｴｰ

946 ：デフォルトの名無しさん：2006/02/11(土) 11:39:43

>>944
動作するものが書けると仮定すると、アセでその遅さは逆にすごい。

947 ：デフォルトの名無しさん：2006/02/11(土) 11:42:36

>>946
>>944は1命令ごとにcall→90個くらいのNOPの塊→retを想定してるんだよ

948 ：デフォルトの名無しさん：2006/02/11(土) 11:46:05

そうか・・・。nopやcallを使いこなすとはさすがだな。

949 ：デフォルトの名無しさん：2006/02/12(日) 12:23:19

>>916
Lanczosは、縮小時は「変換後の解像度にあったローパスフィルタ」
(拡大時は「変換前の解像度にあったローパスフィルタ」)
になるような、sinc関数ベースのFIRフィルタ

Bicubic は近傍4点(×2次元で16点)だけの窓で、変換後の解像度のことは何も考えていない。
変換前の解像度で、補間で画素間の色を求める拡大用フィルタ。
sinc窓じゃなくて、3次スプライン補間。

というわけで縮小時は全然パラメータが異なるし、
拡大時は似たようなパラメータになるが、元の理論は全然違う。

950 ：デフォルトの名無しさん：2006/02/12(日) 17:56:33

こんにちは。
ＲＧＢ各色３段階に再量子化を行う場合、
０～２５５の値をどの範囲で区切ってどの値にするとバランスの良い配色になりますか？

951 ：デフォルトの名無しさん：2006/02/12(日) 18:02:43

とりあえずrgb->hsvをググってみました
http://www.google.co.jp/search?complete=1&hl=ja&q=rgb+hsv&lr=

952 ：デフォルトの名無しさん：2006/02/12(日) 18:09:26

どうせディザ必須だろうから適当で構わんと思うよ

953 ：デフォルトの名無しさん：2006/02/12(日) 21:39:08

ワードに、Illustratorで作ったEPS形式画像をはったら、重すぎました。
どんな処理をすれば軽くてより鮮明な画像ではれますか？

954 ：デフォルトの名無しさん：2006/02/12(日) 21:45:04

emf、wmf、拡張メタファイル、ピクチャは軽い。
つ、いた違い。

955 ：デフォルトの名無しさん：2006/02/12(日) 22:02:52

>>955
アドヴァイスありがとうございます。やってみます。（パソコン関係の板に来たのは初めてなので・・・
こういうのってどこで聞けばいいんですかね？）

956 ：デフォルトの名無しさん：2006/02/12(日) 22:08:39

>>955
文字が読めない人ですか？

957 ：デフォルトの名無しさん：2006/02/12(日) 22:08:43

http://menu.2ch.net/bbsmenu.html
ビジネスsoftかCG
（行ったことないから知らんけど）

958 ：デフォルトの名無しさん：2006/02/13(月) 00:41:46

板の名前が悪いのかもな。
プログラムではなくて、プログラミングにした方がいいかも。

959 ：デフォルトの名無しさん：2006/02/13(月) 11:41:11

むしろ『ソフトウエア開発』とか一般人が敬遠する響きで

960 ：デフォルトの名無しさん：2006/02/13(月) 11:49:21

一般の人は「開発」というと難しいと思ってしまうよね。

961 ：デフォルトの名無しさん：2006/02/13(月) 11:53:23

ム板の一般人って？

962 ：デフォルトの名無しさん：2006/02/13(月) 12:03:58

>>970
次スレは　画像処理ソフトウェア開発　で

963 ：デフォルトの名無しさん：2006/02/13(月) 12:54:04

もうちょっとおたかくしてみた
【博士と】画像処理ソフトウェア開発【助手の】

964 ：デフォルトの名無しさん：2006/02/13(月) 13:01:11

博士と助手なら
画像処理ソフトウェア研究・開発あたりで。
つ、画像処理について素人同士で大激論なんだか

965 ：デフォルトの名無しさん：2006/02/13(月) 13:02:56

助手も博士だったりする場合はどうすればいいんですか？

966 ：デフォルトの名無しさん：2006/02/13(月) 13:46:14

>>961
スレ違いだけどもうちょっと話の流れや行間を読む訓練した方がいいよ。

>>953の書き込みに対して、アプリケーションとプログラミングを区別
しやすい板の名前はどうか？　という話の流れくらい見えると思うん
だけど、そんなに察しの悪い人がこの世には多いのだろうか。

スレッドの名前について書き込みもあるが、板の名前に関しての話が
どうしてそうおかしな方へ解釈されるんだか不思議でならない。

967 ：デフォルトの名無しさん：2006/02/13(月) 13:55:59

板の名前が悪いのかもしれんが、そんなもんこちらとしてはどうしようもないから
せめてスレの名前を変えれば何とかなるかも、という流れだと思っていたが

968 ：デフォルトの名無しさん：2006/02/13(月) 14:02:40

ソフトウェア開発って・・・ここは実装専門のスレですか。

969 ：デフォルトの名無しさん：2006/02/13(月) 16:48:26

実装とか理論のスレだべ？

970 ：デフォルトの名無しさん：2006/02/13(月) 17:22:30

学問・理系に移る？

971 ：デフォルトの名無しさん：2006/02/13(月) 17:23:31

どーでもいいことだけど、日本語で博士って言うとコントの響きがあるね。

972 ：デフォルトの名無しさん：2006/02/13(月) 17:24:57

【理論】博士と助手の画像処理ソフトウェア【実装】

973 ：デフォルトの名無しさん：2006/02/13(月) 17:35:56

ドクターといえば中松

974 ：デフォルトの名無しさん：2006/02/13(月) 18:35:32

ドクターといえば神谷

975 ：デフォルトの名無しさん：2006/02/13(月) 20:57:19

ペッパーライス食べたい。

976 ：デフォルトの名無しさん：2006/02/13(月) 23:11:37

秩父山！秩父山！

977 ：デフォルトの名無しさん：2006/02/15(水) 23:34:08

お勧めの画像処理の教科書はありますか。
なるべく新しい内容が載っていて説明がしっかりしたやつ。

978 ：デフォルトの名無しさん：2006/02/16(木) 00:43:41

>>977
「画像処理スレッド1～5」
ネットでダウンロードできる。

979 ：デフォルトの名無しさん：2006/02/16(木) 07:27:08

説明、しっかりしてるかな？自信ないな・・・

980 ：デフォルトの名無しさん：2006/02/17(金) 19:00:23

本に載った時点で”新しい内容”じゃなくなる気がするが。

981 ：デフォルトの名無しさん：2006/02/17(金) 19:06:28

んなこたーない

982 ：デフォルトの名無しさん：2006/02/18(土) 11:58:37

２値マスクをパスに変換するアルゴリズムを教えてください
検索しても、単一の単純な多角形の輪郭パスの方法しかみつからなかった
オブジェクトすべてのパスを拾い出して、中抜きがあればそのパスも拾いだす
というのを探してます、単一オブジェクトの輪郭検出を何度も繰り返せばできますが
スピードが遅すぎるのでなにかいいアルゴリズムとかあったら教えてください

983 ：デフォルトの名無しさん：2006/02/18(土) 19:34:17

>>982
ラベリングとほとんど一緒で、画像のラインのスキャンを１回すれば良いのでは

984 ：デフォルトの名無しさん：2006/02/19(日) 21:07:10

http://autotrace.sourceforge.net/
http://potrace.sourceforge.net/

985 ：デフォルトの名無しさん：2006/02/19(日) 23:49:35

>>984
それ面白いな。
超解像とは違うのかな。

986 ：デフォルトの名無しさん：2006/02/20(月) 01:56:41

>>984
2値画像の輪郭をベクトル化するツールですか。
おもしろげ。

987 ：デフォルトの名無しさん：2006/02/20(月) 01:57:17

>>990
新スレよろしくね。

988 ：デフォルトの名無しさん：2006/02/20(月) 20:30:54

http://g0307.hp.infoseek.co.jp/srdlg.zip

989 ：デフォルトの名無しさん：2006/02/20(月) 20:58:23

>>984
正直ストリームラインが最強だと思っていました・・・。

990 ：982：2006/02/21(火) 01:34:28

>>983
もうちょっと詳しくｗ
ラベリングした後に領域単位で拾い出すのは>>982で書いたのとあんまり変わらない気がするんですが
一回の走査で出来るとは思えませんそのあたり詳しくｗ

>>984
これはこれで面白そうですね
いずれ使うこともあるかもしれません
一般的にベクトル化は遅いので、望んでるものとちょっと違うかもしれません
パスといっても数式化までしなくても、順番に並んだ点情報だけあれば十分です

991 ：デフォルトの名無しさん：2006/02/21(火) 13:12:20

文末にｗつけるやつは氏ねｗ

992 ：デフォルトの名無しさん：2006/02/21(火) 13:16:51

>>990
情報提供者を嘲笑するような人間って幸せ？

993 ：デフォルトの名無しさん：2006/02/21(火) 13:31:20

>>990
1回のスキャンで結果が得られない形状の例を挙げられますか？

漏れは想像力が無いのでどう考えても１回の走査で出来るものしか思いつかん・・・
（↑言いすぎ。でも予めノイズを消しておけば1回のスキャンで十分でそ）

994 ：デフォルトの名無しさん：2006/02/21(火) 14:23:51

　　　　　　　　　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　　　　　　　　|　ちょっとまって、残り少ないから続きは次スレで。>>990は早く立てなきゃ。
　　　　 , ,-;:;:;:;:;:;:;:;:;:;:;:;:;:;:;:,.ヽ─ｙ──────────────　　　　 ,-v-、
　　　　/;:;:;:;:;:;:ミミ;:;:;:;:;:;:;:;:;:;`､　　　　　　　　　　＿_ -──‐-､,.._　　　　　　 ./ _ﾉ_ﾉ:^)
　　　 /;:;:;:;:彡―ー-､_;:;:;:;:;:;:;:;|　　　　　　　　i:::::::::;;;;;;;;;;;;;;;;;;;;;;;;::::::ヽ　　　　　/ _ﾉ_ﾉ_ノ／）
　　　 |;:;:;:ノ、　　　　　`､;;:;:;:;:;:i　　　　　　　 /::::::::|　 -─‐- 　 |::::::ヽ　　　 /　ﾉﾉノ／／
　　　 |;:/＿ヽ　,,,,,,,,,,　　|;:;:;:;:;:;!　　　　　　　.|:::::::/ ,-‐　Ll　‐-､ヾ::::::l　____/　 ______　ノ
　　　　| ' ﾟ ''/ ┌｡-､　　|;:;:;:;:/　　　　　　　 .ヽ;;/　,━　　　━､　_.. r（" 　`ｰ"　、ﾉ
　　　　|` ノ(　ヽ　ソ　 |ノ|/　　　　　　　　（(（　　　 ./ ＼_. -‐ '"´l　l-､　　　ﾞノ
＿,-ー| /＿` ”'　　＼　ノ　　 __　　　　　　 .　-‐ ' "´ ￣　　　　　 l　ヽ`ー''"ｰ'"　
　|　:　 | ）ヾ三ﾆヽ　　 /ヽ ' "´／｀ﾞｰｧ' "´　　‐'"´　　　　　　　　　ヽ､`ｰ／ノ
　ヽ　　`､＿＿＿,.-ー'　|　　 /　　　/　　　　　　　　　　　　　　　 __.. -'-'"
　　|　　　 |　＼　　　/　|　　 l　　　/　　　　　　　　　　　 .　-‐ '" |::＼
　　＼　　 |＿__＞＜　/　ヽ

995 ：982：2006/02/21(火) 15:14:40

>>993
まずラベリングで領域を分離するために一回全走査するよね
これが完了してないとある点がどの領域に属してるのかわからない
ラベリング自体一回の走査とはいっても交差点を後で見つけたら
最初からやりなおすので正確には一回分じゃない
ラベリングが終わったあとに各ラベル付けされた領域の外枠と内枠を
拾い出すにはラベル内をもう一度走査しないといけない
（内枠は一つとは限らない）
これをさらに経路追跡してないオブジェクトがある限り繰り返す
とりあえず思いつくのはこんな感じです
これだと目的とするものには遅すぎるので
一回の走査にするためにはどこを具体的に変えればいいのか
教えてください

996 ：デフォルトの名無しさん：2006/02/21(火) 17:31:39

http://pc8.2ch.net/test/read.cgi/tech/1140510670/
立てました

997 ：デフォルトの名無しさん：2006/02/21(火) 19:15:11

>>996
もつカレー

998 ：デフォルトの名無しさん：2006/02/21(火) 19:44:25

988って何？

999 ：デフォルトの名無しさん：2006/02/21(火) 20:35:07

>>995
>まずラベリングで領域を分離するために一回全走査するよね

ライブラリとか使わずにラベリング自体を自分で実装してみれば、
この時点で既に外枠が求められていることがわかるし、
並行して内枠を見つける（これもラベリング）ことができることもわかると思うけど・・・

ラベリング等にライブラリを使うという要件が必須なら話は別ですが。

1000 ：デフォルトの名無しさん：2006/02/21(火) 20:39:11

？

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。