画像処理その10

1 ：デフォルトの名無しさん：2007/12/16(日) 08:03:02

画像処理プログラミングについて質問、議論を行うスレッドです
・画像処理について素人同士で大激論
・初学者の質問に対してやさしく(的を外れた)解答を与える
・その道の玄人も大歓迎

前スレ
画像処理その９
http://pc11.2ch.net/test/read.cgi/tech/1183910525/

2 ：デフォルトの名無しさん：2007/12/16(日) 10:30:48

8bit インデックスカラー画像を、さらに可逆圧縮する方法は無いでしょうか？
汎用的な圧縮アルゴリズム以外で。

3 ：デフォルトの名無しさん：2007/12/16(日) 10:40:05

ある

4 ：デフォルトの名無しさん：2007/12/16(日) 11:32:31

9 http://pc11.2ch.net/test/read.cgi/tech/1183910525/
8 http://pc11.2ch.net/test/read.cgi/tech/1168868527/
7 http://pc10.2ch.net/test/read.cgi/tech/1148864160/
6 http://pc8.2ch.net/test/read.cgi/tech/1140510670/
5 http://pc8.2ch.net/test/read.cgi/tech/1127705848/
4 http://pc8.2ch.net/test/read.cgi/tech/1107854973/
3 http://pc5.2ch.net/test/read.cgi/tech/1090897159/
2 http://pc5.2ch.net/test/read.cgi/tech/1054545005/
1 http://pc5.2ch.net/tech/kako/992/992671330.html

5 ：デフォルトの名無しさん：2007/12/16(日) 11:33:03

画像処理系のライブラリ

OpenCV ttp://sourceforge.net/projects/opencvlibrary/
Gimp ttp://www.gimp.org
Vigra ttp://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/
Vips ttp://www.vips.ecs.soton.ac.uk/
VXL ttp://vxl.sourceforge.net/
CImg ttp://cimg.sourceforge.net/
Gegl ttp://www.gegl.org/ ttp://pippin.gimp.org/gegl/
ImageMagick/GraphicsMagick ttp://imagemagick.org/ ttp://www.graphicsmagick.org/
GIL ttp://opensource.adobe.com/gil/
CxImage ttp://www.codeproject.com/bitmap/cximage.asp
FreeImage ttp://freeimage.sourceforge.net/
ITK ttp://www.itk.org
GD ttp://libgd.org/Main_Page
Imlib2 ttp://www.enlightenment.org/Libraries/Imlib2/
MIST ttp://mist.suenaga.cse.nagoya-u.ac.jp/trac/

6 ：デフォルトの名無しさん：2007/12/16(日) 15:20:21

我蔵

7 ：デフォルトの名無しさん：2007/12/16(日) 15:24:30

>>2
汎用でないのが良いなら俺俺圧縮でいいじゃん

8 ：デフォルトの名無しさん：2007/12/19(水) 20:37:48

射影変換の８個の係数は最小２乗法で求めるってよく本に書いてあるけど、
どうやって求めればいいのでしょう？
線形の式じゃないし・・・
求め方よろしくお願いします。

9 ：8：2007/12/19(水) 20:43:19

式は
u=((a*x)+(b*y)+c)/((d*x)+(e*y)+1)
v=((d*x)+(e*y)+f)/((d*x)+(e*y)+1)

10 ：デフォルトの名無しさん：2007/12/20(木) 00:57:06

そりゃあ非線形最小二乗法（Levenberg-Marquardt法とか）で。
MATLABはデフォルトだと違うアルゴリズムだったような気がするけど忘れちった。

11 ：デフォルトの名無しさん：2007/12/20(木) 06:08:03

シンプレックス法じゃなかったっけ？

12 ：デフォルトの名無しさん：2007/12/21(金) 04:36:43

前スレ988です。3次元計測に関して回答して下さった皆様どうもありがとうございました。

質問の補足をさせて下さい。
自分の用途でネット検索してみると、光学マーカを使用した専用システムなどが
見つかるのですが、（例えば：製品情報 SV-Tracker
http://www.okk-inc.co.jp/product/index2.html#SVTRACK
）、数百万円からの金額であること・サイズの制限があることなどあり、
もっと安価・簡便なシステム構築が出来ないか考え、質問させて頂いた次第です。

一応、自分なりのポンチ図を作ってみました：
http://deaiup.com/up/src/up0385.jpg
なお、自分は画像処理は専門外です（画像処理ボードやOpenCVで遊んだ程度の経験です）。

教えて頂いたキーワードを調べつつ、
もっと上手い方法が無いかもう少し考えてみたいと思います。
サポート感謝です！

13 ：デフォルトの名無しさん：2007/12/21(金) 07:04:23

自分は画像処理初心者なんですが、あと、一ヶ月くらいで
何か卒業研究をしなければいけないんです。
何かいいテーマとかありませんんか？

14 ：デフォルトの名無しさん：2007/12/21(金) 07:18:29

http://www.nicovideo.jp/watch/sm1779811

15 ：デフォルトの名無しさん：2007/12/21(金) 07:49:59

>>13
画像処理なんて選ばないほうがいいとマジレス

16 ：デフォルトの名無しさん：2007/12/21(金) 08:00:17

関係者トリップ情報　(偽者に注意)

2007/12/19(水)
ID:E8Oequ3N0 kz氏 packagedの人 ◆BH0nmndX96
ID:1Xu1qks40 Lividusの人 andromeca ◆CPNbxm3EIg
ID:vAwHZgjx0 メルトの人
ID:oSQ+FDNN0 えんじぇぅの人◆scM/nI4V.Y
ID:keBCp+3K0 鼻毛P(Frogging Dance)
ID:oMYHiaXq0 タイムリミットの人◆YYTZgV0LJk

2007/12/20(木)
ID:P7leIPBs0 鼻毛P ◆MP8vzeiN.w
ID:P7leIPBs0 鼻毛P ◆xUn5MII0Bg トリ修正
ID:3EXHazn00 melody...の人 mikuru396 ◆cFNknPxyis
ID:l4i4oFd60 ● 乳酸菌 ◆yHPARVlesM
ID:kxFiBz8Z0 kz氏 packagedの人 kz ◆BH0nmndX96
ID:YUkCq5Ml0 歌姫の人 azuma ◆mf21aXMzrg
ID:HRmiQ+iM0 ツンデレの人 ←みんなの嫁

2007/12/21(金)
ID:qexz2Bij0　SOSOSO ◆0g8QI5iRQk
ID:91k/f2Ze0　kz ◆BH0nmndX96
ID:imXF3cx20　azuma ◆mf21aXMzrg
ID:2AjhCl7I0　◆scM/nI4V.Y
ID:rvuHxWqG0　鼻毛P ◆xUn5MII0Bg

17 ：デフォルトの名無しさん：2007/12/21(金) 08:01:27

http://deftv.atspace.com/?X&1255970&0414@TestX1TV
http://deftv.atspace.com/?X&1255970&0414?X&1255970&0414@TestX2TV
http://deftv.atspace.com/?X&1255970&0414?X&1255970&0414?X&1255970&0414@TestX3TV

18 ：デフォルトの名無しさん：2007/12/21(金) 15:33:01

>>12
2枚の画像の点の対応からカメラのパラメータを復元する方法はあって、
Eight-Point Algorithmとかいうものをつかって、8点が決まるとエピポーラ幾何のFundamental Matrixが求まるんだそうだ。

これを使えば、はじめに任意の8点でキャリブレーションを行っておければ、カメラの位置は適当でよくて、
あとはエピポーラ幾何でわかったカメラパラメータを用いて
2つのカメラからレイを飛ばして交点が元の点ってことになるような気がするけどダメですかね。

19 ：デフォルトの名無しさん：2007/12/21(金) 22:50:01

画像処理でのアセンブラ化は中毒性があるな。
めちゃくちゃ処理速度が向上して笑いが止まらない。
SIMD万歳！

20 ：デフォルトの名無しさん：2007/12/22(土) 01:03:20

>>19
よっぽどしょぼいコンパイラを使っていたんですね。

21 ：デフォルトの名無しさん：2007/12/22(土) 01:13:05

>>20
そうなんかな？
Visual C++ 2005 Proで最大輝度でグレースケールする例だと
Cだと4.6ms、ASMだと2.2msぐらいだからかなり改善したと思うけど

画像ソースは、1920x1200、24Bitビットマップ画像
CPUはCore2Dure 6600/メモリ 2GB

同じ画像ソースで3×3Sobelでエッジ抽出を求める処理で、
2.8msだからかなり早いはずだけど、遅いの？
(1920x1200 グレースケール後8bit画像から)

22 ：デフォルトの名無しさん：2007/12/22(土) 02:06:44

「アセンブラを使って速くなった」→「コンパイラのコードが遅かった」ってことじゃないの?
実際、CコンパイラだってSIMD演算位すると思うのだけど。

23 ：デフォルトの名無しさん：2007/12/22(土) 03:27:14

SIMD 使うかはオプション次第じゃないの

24 ：デフォルトの名無しさん：2007/12/22(土) 03:42:11

最初のCoreに引っ張られたんだろうけどDureてｗ

25 ：デフォルトの名無しさん：2007/12/22(土) 04:57:09

計算量のオーダーが変わったり1桁以上速くなるのでなければ
あまり気にしないことにした

26 ：デフォルトの名無しさん：2007/12/22(土) 05:03:46

JITまんせー

27 ：デフォルトの名無しさん：2007/12/22(土) 05:05:18

>>21
1920x1200 とはいえ、E6600 でグレスケに2.2msもかかるか？
式は 0.298912 * R + 0.586611 * G + 0.114478 * B　？
精度はどのくらいでやってるの？

28 ：デフォルトの名無しさん：2007/12/22(土) 10:07:32

>>27
最大輝度だから式は 0.298912 * R + 0.586611 * G + 0.114478 * Bではなく
bin = ((R > G) ? (R) : (G));
bin = ((B > bin) ? (B) : (bin));

dst = bin
ってな感じで計算している。

夜頃までに上記式での比較をやってみる。
あと、もう少し比較命令を改善してみるよ。
やっぱり遅いのか…orz

29 ：デフォルトの名無しさん：2007/12/22(土) 12:20:12

ICC最強

30 ：デフォルトの名無しさん：2007/12/22(土) 13:47:34

iccってそんなに良い？
前gcc4.0とicc9.0でコンパイル出来るようにしてたけど10%弱しか改善しなかった

31 ：デフォルトの名無しさん：2007/12/22(土) 14:06:57

bin = ((R < G) - 1 & R - G) + G;
bin = ((bin < B) - 1 & bin - B) + B;

32 ：デフォルトの名無しさん：2007/12/22(土) 15:59:47

>>30
巧くsimd使える状況にはまればね。
gccに較べて改善できないときは、それでもまだintrinsicを使うと言う手も残っているから、
自前でアセンブリコードを書く機会は最早殆どなくなってしまったよ。

33 ：デフォルトの名無しさん：2007/12/22(土) 17:40:55

ICC使ってみたけど、期待したほど速くないぞ？

34 ：デフォルトの名無しさん：2007/12/22(土) 19:40:09

Intel といえば ipp (integrated performance primitives) なら速いんじゃない?
誰か使ってる人いる?

35 ：デフォルトの名無しさん：2007/12/22(土) 20:01:24

まぁ、iccや最適化の話やアセンブラの話はスレ違いなんで該当スレへ。

36 ：デフォルトの名無しさん：2007/12/23(日) 01:11:20

SIMDっつーても流石に数百個単位の並列動作する石だと
もう言語以前にアルゴリズムが凄い事に。

というかバス速度の方がよっぽどボトルネックな罠。

37 ：デフォルトの名無しさん：2007/12/23(日) 12:30:24

>>2
パレット値に置き換えた時点で、画像アルゴリズムの範疇ではなく、
記号処理の範疇だと思うが。

38 ：デフォルトの名無しさん：2007/12/23(日) 15:22:05

>>36
>35

39 ：12：2007/12/23(日) 16:06:28

>>18
亀レスすみません
非常に重要な指針を教えてくれてありがとう！
詳しくはこれから調べようと思いますが
>>18 を読んでいるとそれで行けるような気がします！

未知のことだらけで遣り甲斐があります！

40 ：デフォルトの名無しさん：2007/12/23(日) 16:07:27

MagickWandの構造体、MagickWand型の定義について教えてください。
ヘッダファイルをあさくってもどこにも定義されて無く困っています。

41 ：デフォルトの名無しさん：2007/12/23(日) 18:51:48

＞あさくっても
???

例えばcc -Eしてみたら?

42 ：デフォルトの名無しさん：2007/12/23(日) 19:22:27

「あさくって」は方言「あさくる」の活用形です。

43 ：デフォルトの名無しさん：2007/12/23(日) 21:10:50

>>41
>例えばcc -Eしてみたら?
それはもうしたんだけれど、
ないんだよぅ。

44 ：デフォルトの名無しさん：2007/12/23(日) 21:30:21

知らんけど opaque な型なんじゃないの
ライブラリのソース当たってみるとか

45 ：デフォルトの名無しさん：2007/12/23(日) 22:07:38

wand/MagickWand.h
wand/magick-wand-private.h

46 ：デフォルトの名無しさん：2007/12/23(日) 22:12:06

明日の朝、食ってきます...

47 ：デフォルトの名無しさん：2007/12/23(日) 23:09:13

MagickWand日本語の情報少なすぎじゃね?
phpのモジュールの情報(しかもコンパイル方法)しか引っかからん。

48 ：デフォルトの名無しさん：2007/12/23(日) 23:14:13

>>42
>「あさくって」は方言「あさくる」の活用形です。
あさくるって九州の方言だったの!
生まれて初めて知った。
っーか、今北海道に住んでるから、突っ込んでくれよ、道産子。
お前ら俺の話真面目に聞いてないんだな!

49 ：デフォルトの名無しさん：2007/12/23(日) 23:30:19

別に画像処理アルゴリズムの実装くらいはこのスレで扱ってもいいと思うんだけどなあ

50 ：デフォルトの名無しさん：2007/12/23(日) 23:39:40

40年生きてきて、「あさくる」ってことばは初めて知った。
「漁る」って意味でいいのかな?

>>49
同意。但し、何の前提もなしにSIMDがどうのはスレ違いだと思う。

51 ：デフォルトの名無しさん：2007/12/25(火) 00:40:41

いじる、いじくる
と似ている気がした。

52 ：デフォルトの名無しさん：2007/12/25(火) 00:59:56

>>51
いじくる、は俗語表現だが、あさくる、は単なる方言。
ちなみにいじくるの語源は、何事にも本気にならずあそびで触ってかっこつけるところから、
easy cool がなまったもの。もちろんあさくるは、朝が来るまで探し回るところからだ。
これ豆鉄砲知識な。

って、ここ画像処理板だよ・・・ OTZスマソ

53 ：デフォルトの名無しさん：2007/12/25(火) 03:15:39

>>52
安心しろ、ここはム板だ。

54 ：デフォルトの名無しさん：2007/12/25(火) 05:54:56

>>52　は嘘

55 ：デフォルトの名無しさん：2007/12/25(火) 08:02:26

Ω　ΩΩ

56 ：デフォルトの名無しさん：2007/12/26(水) 09:51:30

ちょっとヒマっぽいので前から懸案の緑かぶり補正を自作のソフトに機能追加
しようと思うんだけど、各ピクセルにマゼンタを足すだけでは、絵が白っぽく
なりますよね。
足す前の明度を覚えて置いて足した後その明度に戻すとかするんでしょうか。

どの程度のマゼンタの値がいいかってのも予め求められるんでしょうか。
それとも、スライダ操作可能にして自分で見ながらやるんでしょうか。

57 ：デフォルトの名無しさん：2007/12/26(水) 12:40:49

YCrCbで補正すればいいんじゃない？
補正量もフルオートでやるなら、全てのピクセルの平均が
無彩色になるようにするとか。

58 ：デフォルトの名無しさん：2007/12/26(水) 13:03:55

写真系の板で訊けよ

59 ：56：2007/12/26(水) 15:10:48

>>57-58 レス感謝。
YCrCb 補正ですか、今これは組み込んであるんで試して見ます。

写真系の板で、アルゴリズムやコーディングの話は無理かと。
もし２チャンネルに限らず、良い板があるならご紹介を。外国語は
英語までで。

せいぜい、カメラのセットを変えろとか、フィルタ付けろとか、
Photoshop 買えとか使えとかになる気がする。
（フィルタも銀塩時代の 52mm なら２種類もあるんだが）

60 ：デフォルトの名無しさん：2007/12/26(水) 15:17:09

Photoshop 買え

61 ：デフォルトの名無しさん：2007/12/26(水) 21:39:14

>>56
要するにAWBだな。
アルゴリズムはいろいろあるけど、>>57のように画像全体の平均がグレーになるようにするってのが最も単純な方法。
YCCじゃなくても、Rの平均、Gの平均、Bの平均が同じ値になるように補正すればいい。
もっと賢いアルゴリズムについては、デジカメ板あたりにプロフェッショナルがいそうではある。

62 ：59-56：2007/12/27(木) 06:55:23

>>61
ありがとうございます。だんだん様子が見えるようです。
世の中には、緑の成分を薄めるというのもありますね。

>>60
絶対アプリは買わない方針にしている。
コンパイラも買わずに済ませようとしているんだが、VC++ 2008 EE の登録が
なぜか出来ない。年明けくらいまでにやっつつけて、最悪２月購入か。

63 ：デフォルトの名無しさん：2007/12/27(木) 07:16:35

要するにケチなわけですね

64 ：デフォルトの名無しさん：2007/12/27(木) 07:43:11

>>63
それ以前に、その姿勢でなぜOSがwindowsなのかと。

65 ：デフォルトの名無しさん：2007/12/27(木) 07:50:48

Windows無しのPCなんか買っても節約にならんから。

66 ：デフォルトの名無しさん：2007/12/27(木) 08:43:05

OS の値段だけじゃないだろ

67 ：62-56：2007/12/27(木) 18:15:08

>>64
OS 止めるとセットじゃなくなって、高くなるんよ。

>>63
早く言えばそう。しかし高額のソフト買っても全部の機能は使い切れないし、
フリーソフトは、自分ならこうするってのが出来ない。

大口をたたくと、PCは消費財ではあるが、生産財でもある。ソフト自作は
その機能を活用していることである。成果が社会的に有益かどうかの問題
が残るけど。

68 ：デフォルトの名無しさん：2007/12/27(木) 22:10:49

>>67
64が言ってるのは、その姿勢でなぜLinuxじゃなくてwindowsなのかってことじゃないの。
同じ構成でLinuxセットの方が１万以上安い製品は普通にあるが。
開発ツールも完全に無料でそろうのに。

69 ：デフォルトの名無しさん：2007/12/27(木) 22:40:01

Windowsでも開発ツールは無料で揃うよ。
というか、OSなんてどうでもいいだろ。画像処理の話をしよう。

70 ：デフォルトの名無しさん：2007/12/27(木) 23:47:53

開発ツールだけじゃなくてライブラリやアプリも無料でそろう
しかもソース付きだから、自分ならこうするってのも出来ちゃう
VC++ 2008 EE の登録が何故か出来ないなんて事にもならない

たったそれだけだけどね

71 ：デフォルトの名無しさん：2007/12/28(金) 00:26:35

画像処理の強い大学ってどこ？
東大？東工大？

72 ：デフォルトの名無しさん：2007/12/28(金) 01:04:01

コロンビア大学

73 ：デフォルトの名無しさん：2007/12/28(金) 03:05:14

大学より研究室見た方がいい

74 ：デフォルトの名無しさん：2007/12/28(金) 05:49:13

http://comition.net/
ってどうなん?
俺は面白いと思うけれど。
専門家的には、「くだらねぇ」って感想?
それと、
http://slashdot.jp/articles/07/12/25/0257235.shtml
で
>目の位置の抽出なんて、顔認識技術として転がっているし、
>クローラーを実装するのも、どうと言うことの無い技術でしょ。
残念ながら、これはとっても先の目標です。最終目標です。
これが出来るようになるよう精進します。がんばります。
って作者がやり取りしてるけれど、
どっちが本当なの?
顔認識技術って漫画にも応用できるん?

75 ：デフォルトの名無しさん：2007/12/28(金) 06:08:29

少しかじった程度だけど
顔認識技術はむしろ漫画みたいなほうがやりやすいはず。
漫画は顔ってわかるようにラインがきっちりしてるから特徴が出やすい。間違ってたらスマン。

76 ：sage：2007/12/28(金) 07:17:29

ふーん、じゃあ、検索エンジン作るのは簡単なのかな?
でも、マンガの場合、人間と違って目の色が違ったり、鼻がなかったり、口がなかったりするけれど、
そんなのあんまり関係ないのかな?

77 ：デフォルトの名無しさん：2007/12/28(金) 07:52:26

頭に尻があったりするしな

78 ：デフォルトの名無しさん：2007/12/28(金) 08:42:45

>>74
パターン認識のプロジェクトやりなさいって日本の修士生になげると
漫画の作者認識をやるやつが必ず一人はいる。

79 ：デフォルトの名無しさん：2007/12/28(金) 08:44:31

>>73
画像処理の研究したくてどこの大学院行くか迷ってます。
医療系の人間なので、「画像処理ならココだ！」的な大学が分からないので聞いてみました。
将来的に企業の研究所とかで医療画像の研究開発とかしたいです。

80 ：67-56：2007/12/28(金) 08:47:43

>>70
>>69 氏のように画像処理からずれるとお叱りがあるんで短くするが、
実は、Xp機は Linux との dual にしてあり、今度の Vista 機も HDD に
パーティション切って貰ってある。Xp 機に 68 Mac エミュレータの
Basilisk II を入れて、古いSymantec C++ も動くが、なんせネット関係
で Jave エラー頻発になって、使わなくなった。
Linux 向けのソフトのソースを随分使わせてもらっている。実は自作ソフト
の半分は、ソース解析と言える位。

81 ：sage：2007/12/28(金) 09:24:49

>>78
へぇ、じゃあ意外とたいしたことでもないのかな。
でも、その割には似たようなことやってるサイトって見ないけれど。
下らないから投げちゃうのかな。成果として残せばよいのに。
ちなみに、Comitionって未来あると思う?

82 ：デフォルトの名無しさん：2007/12/28(金) 09:44:14

>>81
おまえパターン認識やったこと無いのか？
すっげー単純なのから高度なのまでいろいろあるんだぞ。
同じ漫画作者認識にしたって高度にはなりうる。

83 ：デフォルトの名無しさん：2007/12/28(金) 09:46:13

>>81
論文を読みなちゃい。
ウェブページなんていくらでも情報があるようでその実なんの情報もないよ

84 ：デフォルトの名無しさん：2007/12/28(金) 09:49:57

>>82,83
ええっ。
いや、論文読め言われても、おれただの素人だし。
ふーん、じゃぁ成功はComitionの作者のがんばり次第なのかな。
外国にはこんなの無いから、イラスト関係のポータルサイトとして成長できるように頑張ってほしいね。
たぶん消えると思うけれど。

85 ：デフォルトの名無しさん：2007/12/29(土) 02:48:05

ImageMagickを軽くする方法ってないかね？
10万ファイルのサイズ変換に時間がかかりすぎる。

86 ：デフォルトの名無しさん：2007/12/29(土) 03:02:13

あんなもん使ってるのが悪い

87 ：デフォルトの名無しさん：2007/12/29(土) 04:21:03

じゃあ最速の画像変換ソフトって何かね？
商用でもいいので教えてくれ。

88 ：デフォルトの名無しさん：2007/12/29(土) 04:45:43

>>85,87
板違い
せめて>>1くらい読んでから書き込みしてくれ

89 ：デフォルトの名無しさん：2007/12/29(土) 05:23:41

>>84
目の自動切り出しに独自のアルゴリズムが必要だから、そこ次第。
現実の人の顔ならともかく、漫画絵のTゾーンなんて普遍的な検出は不可能そうだし。
従来の検出手法はあまり役に立たないだろうことは、容易に想像できる。
もっとも、/.みてると、手で切り出しても全然精度はないみたいだけどね。

90 ：デフォルトの名無しさん：2007/12/29(土) 09:20:33

輝度って何ですか?

91 ：デフォルトの名無しさん：2007/12/29(土) 11:17:01

ググレカス

92 ：デフォルトの名無しさん：2007/12/29(土) 11:30:30

ttp://www.google.co.jp/search?q=ググレカス

93 ：デフォルトの名無しさん：2007/12/29(土) 11:33:52

URLエンコードぐらいしようぜ

94 ：デフォルトの名無しさん：2007/12/29(土) 15:03:12

二ヶ月ほど前に撮った写真です
場所はバトルロワイヤルの撮影地にもなった
軍艦島での一枚です。
http://www.uploda.net/cgi/uploader1/index.php?file_id=0000278909.bmp
撮影し現像した物を
心霊写真がないかな～っと面白半分で探していると
偶然にも一枚だけ物凄い写真が在りました
最初に見えたのは右下の子供の様な顔です
左にはボーっと立ち尽くし
こっちを見ている子供がうっすらと写っています
上部には青白い叫び顔があります
それだけではありません
探せば探すほど気持ち悪い顔があるのです
私は現在で約30ほどの顔を見つけました、全てこっちを見ています
探せば探すほどあまりにも出てくるので
気持ち悪くなり頭が痛くなりました
この写真ですが、ある友人に貸した所
夜に1時間程笑い声の様なものが聞こえてかなり
怖かったらしいです・・・
霊感がある方はぜひ鑑定をお願い致します。

因みに、スキャナーで高画質でスキャンした上で
見易いように画質調整をしています
ですのでファイルサイズが9MBにもなります・・・

95 ：デフォルトの名無しさん：2007/12/29(土) 15:05:59

>>94
ブラクラ

96 ：デフォルトの名無しさん：2008/01/02(水) 17:48:09

画像処理ってどういうところで使われているの?
gimpみたいなソフトウェアを作るのは画像処理の中に入る?

97 ：デフォルトの名無しさん：2008/01/02(水) 19:29:27

gimpの各処理については画像処理に入るだろうけど。

98 ：デフォルトの名無しさん：2008/01/02(水) 19:45:15

画像処理って何なのさ?
漠然としてて分かりずらい。
SIGGRAPHみたいなのも無いし。

99 ：デフォルトの名無しさん：2008/01/02(水) 20:04:39

コンピュータビジョンとか

100 ：デフォルトの名無しさん：2008/01/02(水) 21:57:48

>>96
医療や、工場の生産技術等等

101 ：デフォルトの名無しさん：2008/01/02(水) 22:01:54

テレビなんか画像処理の固まりだよ

102 ：デフォルトの名無しさん：2008/01/02(水) 22:03:22

脳はちょっと違うか

103 ：デフォルトの名無しさん：2008/01/02(水) 22:12:05

デジタル画像処理だったら
画像ファイルとか動画ファイルとか使ってなんかやってたら全部画像処理でおｋ！

104 ：デフォルトの名無しさん：2008/01/02(水) 22:43:22

食っていけない研究No1

105 ：デフォルトの名無しさん：2008/01/03(木) 20:24:13

OpenCVのライブラリにあるcvFindFundamentalMatrix使って
２つの画像間のエピポーラを求めようとしてるんですけど
この場合って各画像の特徴点はどうやってもとめるのが一番いんでしょうか？

106 ：デフォルトの名無しさん：2008/01/03(木) 20:30:09

医療画像処理が強い研究室ってどこだか分かりますか？

あと、工学部とかではどんな画像処理の教科書を使ってるんですか？知ってたら教えてください。

107 ：デフォルトの名無しさん：2008/01/03(木) 20:35:25

どいつもこいつもageるなよ

108 ：デフォルトの名無しさん：2008/01/03(木) 21:19:09

>>105
そりゃ用途によるだろうけど、お手軽なのはチェスボードのやつかな

109 ：デフォルトの名無しさん：2008/01/03(木) 23:20:27

>>106
全部を知ってる訳じゃないし
特定のを上げるのも公平じゃないので
自分で探して。

医用生体工学（科）とかでぐぐるといくつかでてくる。

あとは学会誌を見た方がいい。
日本医用画像工学会
ttp://www.jamit.jp/index-j.html
日本生体医工学会
ttp://www.asas.or.jp/jsmbe/
電子情報通信学会
ttp://www.ieice.org/jpn/index.html

110 ：デフォルトの名無しさん：2008/01/04(金) 17:33:32

>>109
てんくす

111 ：デフォルトの名無しさん：2008/01/05(土) 01:23:02

>>105
興味あるので
上手くいったら教えてくださいな

112 ：デフォルトの名無しさん：2008/01/07(月) 01:24:03

パターン認識を利用したビジネスって
大掛かりなものや研究開発しか思いつかないのですが
中小企業にもお勧めできる使い方ってなにかあるでしょうか？

113 ：デフォルトの名無しさん：2008/01/07(月) 01:26:36

>>112
保守的な企業にはお勧めできない

114 ：デフォルトの名無しさん：2008/01/07(月) 01:33:15

>>112
なんであんたの金儲けの手助けせにゃならんの？

115 ：デフォルトの名無しさん：2008/01/07(月) 01:36:40

>>114
いいじゃん別に。
嫌なら答えなくていいじゃん。
もしかして、他の人への「答えるな」という意思表示ですか？
営業妨害ですよ。

116 ：デフォルトの名無しさん：2008/01/07(月) 01:44:14

>>115
自分で売り方を思いつけず、2chで聞かなきゃならないとは、
なんともお粗末な営業ですなぁ。

117 ：デフォルトの名無しさん：2008/01/07(月) 01:46:27

情報収集はあらゆるところで行うものですよ。

118 ：デフォルトの名無しさん：2008/01/07(月) 01:52:25

君んとこで作れる程低レベルなものねぇ・・・
無いんじゃね

119 ：デフォルトの名無しさん：2008/01/07(月) 02:13:10

>>115
それって営業妨害なの？

120 ：デフォルトの名無しさん：2008/01/07(月) 02:20:15

釣られすぎｗ

121 ：デフォルトの名無しさん：2008/01/07(月) 02:21:19

ム板はおもろいなぁｗ
生真面目にどんなレスにも答えてくれる
他の板じゃ余裕でスルーするようなレスでもなｗ

122 ：デフォルトの名無しさん：2008/01/07(月) 02:30:01

でしょでしょ

123 ：デフォルトの名無しさん：2008/01/07(月) 03:35:45

CG系のこともここで聞いていいんだろうか…。
スポットライトのライティング計算ってどうやるの？
調べても、線光源とか点光源くらいしか出てこない。

124 ：デフォルトの名無しさん：2008/01/07(月) 03:40:04

ここじゃない

125 ：デフォルトの名無しさん：2008/01/07(月) 08:12:45

CG板

126 ：デフォルトの名無しさん：2008/01/07(月) 08:25:21

面光源ってなかったっけ

127 ：デフォルトの名無しさん：2008/01/07(月) 09:19:11

>>123
とりあえずここらへんに移動しろ。
http://pc11.2ch.net/test/read.cgi/tech/1155153009/

>>125
CG板は理論寄りのスレはほぼ皆無でしょ。

128 ：デフォルトの名無しさん：2008/01/07(月) 09:24:42

>>118
「使い方」って聞いているだろうが。
ものを作る必要なんか無い。

パターン認識の手法を考えるやつの儲けを１とすると
それを使ってアプリを作るやつが10儲けて
アプリを使うやつが100儲ける

129 ：デフォルトの名無しさん：2008/01/07(月) 10:02:13

指紋でも使って部屋の出入り管理でもすれば？

営業妨害っていうけどさ、おまいが振った話って守秘義務違反にあたらないか

130 ：デフォルトの名無しさん：2008/01/07(月) 10:05:20

>>129
守秘義務？
どこに企業秘密が書き込まれていますか？
また、それはどの企業の情報か推定できますか？

131 ：デフォルトの名無しさん：2008/01/07(月) 11:03:35

珍しく伸びていると思ったらｗ

そろそろ画像処理の話しようぜ

132 ：デフォルトの名無しさん：2008/01/07(月) 14:13:29

>>123
CG板は行ったんだけど、何か違った。

>>127
サンクス。それこそ探してたスレだ。

133 ：デフォルトの名無しさん：2008/01/09(水) 06:34:19

>>131

最近の流行が知りたいです。
学会とか入ってないので。

NECのIMAPCARみたいなプロセッサや
FPGAを用いて複数の異なる画像処理を並列にやらせるのはまだ流行中ですか？
なにか面白い成果でてますか？
そういうハードウェアを持てない研究者や開発者のために
SIMDライクな計算方法で画像処理をやらせるのは進展あるのかしら？
やはりそういう研究開発でもOpenCV/IPPが主流なんでしょうか？

134 ：デフォルトの名無しさん：2008/01/09(水) 09:42:41

>>133
> FPGAを用いて複数の異なる画像処理を並列にやらせる

異なる処理だと同期が難しそう。ちなみにどういう応用例があるの？

135 ：名無し募集中。。。：2008/01/09(水) 10:40:36

gpgpuは昔からあるし最近じゃないね

136 ：デフォルトの名無しさん：2008/01/09(水) 18:43:19

>>134

応用例というか最近だと車の運転補助装置・危険回避補助装置かな。
FPGAというか並列処理できるならなんでもいいんだろうけど、
レクサスに採用されている
NECエレのIMAPCARというのがそういうものらしいです。

これね
ttp://www.necel.com/ja/solutions/applications/auto/imapcar/imapcar_04.html

富士通も昨年暮れあたりになんかだしてたな
東芝もNECエレとおんなじようなの持ってたような気がします。

ちょっとこのスレの趣旨とは違ってきちゃうけど
ハードウェア設計言語で実装というのもありだろうなと。

137 ：デフォルトの名無しさん：2008/01/09(水) 23:00:38

ウィンドウズでＭＩＳＴの設定をしようとしたけどチュートリアル読んでも
出来ませんでした。
あれはＶＢ．ＮＥＴが入っていないと出来ないのでしょうか？
今、ＶＩＳＵＡＬＣ＋＋６．０を使用して画像処理のプログラムを書いているの
ですが、どのようにすればＣ＋＋でＭＩＳＴを使えるのかどなたか教えて頂けない
でしょうか？

138 ：デフォルトの名無しさん：2008/01/10(木) 02:08:03

読めねぇ…
ttp://pc11.2ch.net/test/read.cgi/cg/1178517379/827-

139 ：デフォルトの名無しさん：2008/01/10(木) 16:00:04

>>137

MISTはUbuntu上で使ってみただけだからわからんなぁ。

140 ：デフォルトの名無しさん：2008/01/10(木) 20:16:06

だったら黙ってろよ

141 ：デフォルトの名無しさん：2008/01/10(木) 20:39:58

>>137
MIST自身に説明があるが・・・
ttp://mist.suenaga.m.is.nagoya-u.ac.jp/trac/wiki/HowToSetEnvironment　（自分でVC6用に直せ）
というか、VC6でのライブラリのリンク方法、それどころかヘッダの意味すら分かってない？

142 ：デフォルトの名無しさん：2008/01/11(金) 01:19:17

MIST俺も導入しようとして挫折した経験あるわ～
結局OPENCV使用したけど

143 ：デフォルトの名無しさん：2008/01/11(金) 15:39:32

だったら黙ってろよ

144 ：デフォルトの名無しさん：2008/01/11(金) 19:17:57

MISTなんてプロジェクトが有ったんだ!
お手伝いしたいけれど、プログラムの面では全く役立たずだろうしなぁ。
っーかCしかできなくて、C++分かんないし。
ドキュメントくらいは書けるかなぁ。

145 ：デフォルトの名無しさん：2008/01/11(金) 23:20:09

MISTのメーリングリスト、名古屋大限定かよ。
排他的だなぁ。
俺の指導教官、名古屋大出てるけど駄目かな?

146 ：デフォルトの名無しさん：2008/01/12(土) 08:03:17

COEでたんまり金もらってこの程度かあ

147 ：デフォルトの名無しさん：2008/01/12(土) 08:54:02

なんじゃこりゃ
ひとりで１年もかからずにできるような内容だな

148 ：デフォルトの名無しさん：2008/01/12(土) 20:54:05

OpenCVのように世界的に使われるものじゃないとそりゃクソだろ。
自分たちだけで使っていればフィードバックもないだろうし。

149 ：デフォルトの名無しさん：2008/01/13(日) 16:37:29

濃淡画像にインパルス埋め込んで拡散させてるって実験やってるのですが
実数だけじゃなくて複素も使うメリットを教えてもらえませんか？
劣化を抑えられるとか何とか

150 ：デフォルトの名無しさん：2008/01/13(日) 16:58:12

もうちと詳しくplz

151 ：半可通：2008/01/13(日) 17:39:23

透過系を考えるときに、複素数の虚部が位相に相当するってことじゃなかったかな?

152 ：デフォルトの名無しさん：2008/01/13(日) 18:06:54

線形の制御理論一般に何でも使える考え方だな。
その辺、全部常微分方程式が素だから当然といえばそうか

153 ：デフォルトの名無しさん：2008/01/13(日) 18:24:50

お前ら頭良いな。
何言っているのかさっぱりだ。
たかがメモリの固まりに、そこまで深い意味が有るとは...

154 ：デフォルトの名無しさん：2008/01/13(日) 18:38:43

>>149
インパルスって、レーザーか何かを想定して広がりのある濃淡画像の
一点に1波長程度の長さの光を与えたって意味なの？

155 ：デフォルトの名無しさん：2008/01/14(月) 04:49:24

感圧センサの上で手を広げて
指の間をナイフでトントントンと・・・
失敗したら血が拡散するんです

156 ：デフォルトの名無しさん：2008/01/14(月) 05:03:47

ひゃぁ
お社様のたたりじゃ～

157 ：デフォルトの名無しさん：2008/01/14(月) 05:06:39

感圧センサをナイフで突いちゃダメー!

158 ：149：2008/01/14(月) 10:10:59

レスありがとうございます。　

複素フーリエ→インパルス埋め込み→逆複素フーリエで元の
画像に戻るって感じのことやってます。
　
埋め込みは複素でも実数でも良いんですが、同じインパルスを
埋め込んで実数のみの変換よりも複素を利用した方が元の画像に
近くなるって事を示さないといけないんです…

159 ：デフォルトの名無しさん：2008/01/14(月) 10:20:51

だから、その「インパルス」とはなんなのだ。

160 ：デフォルトの名無しさん：2008/01/14(月) 10:29:12

どっかに適当に1を埋め込んでるんじゃね？
複素共役の話だけな気がする…

161 ：149：2008/01/14(月) 11:30:39

説明不足ですみません。
実数だったら画像の一点の振幅値を増加させるって事です。
それを拡散させて原画像に近い画像を得るって実験です。

162 ：デフォルトの名無しさん：2008/01/14(月) 11:43:21

なんかの宿題か？
つーか、
フーリエ変換→逆フーリエ変換
フーリエ変換→実数部のみ→逆フーリエ変換
の時点で当たり前に前者のほうがオリジナルに近い値に戻せるのだから、
一点増幅とか関係なくね？

163 ：149：2008/01/14(月) 11:53:43

埋め込みが大事みたいなんです。
埋め込むインパルス強度は共通として実数よりも複素を
利用した方が原画像に近く（ピークSN比が大きく）なる手法を
証明しないといけないのです…

164 ：デフォルトの名無しさん：2008/01/14(月) 12:27:16

どうでもいいが、インパルスは「埋め込む」ものなのか？
畳み込みならわかるが・・・

165 ：デフォルトの名無しさん：2008/01/14(月) 12:45:09

もうこれ以上は無粋

166 ：デフォルトの名無しさん：2008/01/14(月) 12:57:07

余計なものを混ぜると原画像に近くなる？
何か変じゃね？

167 ：デフォルトの名無しさん：2008/01/14(月) 19:56:01

http://www.nicovideo.jp/watch/sm2028210
みた?
webカメラから手だけを抽出して背景の画像と合成までは出来そうなんだけれど、
どうやれば、背景の画像の中のオブジェクトを動かせるのかさっぱり見当がつかない。

168 ：デフォルトの名無しさん：2008/01/14(月) 20:03:55

手領域だけを取り出して、
それをゲーム空間内に突っ込んで物理エンジンで動かしてるだけだろ。
難しくもなんともない

169 ：デフォルトの名無しさん：2008/01/14(月) 20:17:39

マリオじゃなくて、マリオっぽい奴を自作したのかな

170 ：デフォルトの名無しさん：2008/01/14(月) 20:17:48

ああ、なるへそ。
何となくイメージできた。
Webカメラから手画像だけ抽出して、
ゲーム画面の中でマウスポインタの代わりに、その手画像を貼付けているって
解釈で良いのかしら?

171 ：デフォルトの名無しさん：2008/01/14(月) 20:32:43

マウスポインタじゃなくてゲーム内の障害物として貼り付けてる

172 ：デフォルトの名無しさん：2008/01/14(月) 20:39:26

ありがとん。
最初見た時はスゲーって思ったけれど、
よく考えてみると、俺が深く考えすぎてたみたいね。
っーか、DirectX凄いね。
俺もWindowsプログラミング始めるべきかなぁ。

173 ：デフォルトの名無しさん：2008/01/14(月) 20:48:30

DirectXは関係ないだろう。
Webカメラの入力にDirectShow、画面の出力にDirectDrawか3Dは
使っていると思うが、肝の部分は全く関係ない。

174 ：デフォルトの名無しさん：2008/01/14(月) 20:50:47

>Webカメラの入力にDirectShow、画面の出力にDirectDrawか3Dは
いやいや、LinuxとかBSDとかでコレを実現させるのが一苦労って意味で。

175 ：デフォルトの名無しさん：2008/01/15(火) 00:50:57

それはマジで言ってるの？

176 ：デフォルトの名無しさん：2008/01/15(火) 00:55:43

マジです

177 ：デフォルトの名無しさん：2008/01/15(火) 02:58:30

そうじゃないの?
外部ライブラリを使わずに、
>Webカメラの入力にDirectShow、画面の出力にDirectDrawか3Dは
をBSDやLinuxで簡単に実現できる?

178 ：デフォルトの名無しさん：2008/01/15(火) 03:04:38

これってマリオらしきものも作ってんの？
そこが一番苦労しそうなんだが

179 ：デフォルトの名無しさん：2008/01/15(火) 03:11:37

ゲームのプログラミングなんだから簡単だろ

180 ：デフォルトの名無しさん：2008/01/15(火) 03:14:31

>>166
>余計なものを混ぜると原画像に近くなる？
>何か変じゃね？
非常に笑った
今日一番笑ったかもしれん

181 ：デフォルトの名無しさん：2008/01/15(火) 03:34:08

まあ３時間しか経ってないからな

182 ：デフォルトの名無しさん：2008/01/15(火) 04:03:54

複素数理解してない奴としては普通の反応だよ

俺とかなー

183 ：デフォルトの名無しさん：2008/01/15(火) 22:20:52

笑い所がわからん
マジで。

184 ：デフォルトの名無しさん：2008/01/16(水) 02:12:09

カメラの前に置いてある物の形を認識する方法ってどうやればいいの？
三角、四角、丸とかに分けれる程度でいいんだけど。
ググってもそこまで初歩的なのは見つからない…

185 ：デフォルトの名無しさん：2008/01/16(水) 02:16:52

>>184
初歩的じゃないよ。
割とむずかしい。
色分けがはっきりしているなら簡単。

186 ：デフォルトの名無しさん：2008/01/16(水) 02:26:53

コンピュータビジョンの技術使って、高度なレベルで
３Ｄアニメーションを機械に自動生成させることってできないかな、って考えてます。
例えば、動画と人型３Ｄモデルを用意して、動画に移ってる人物の動作を抽出し、
その動きを用意した３Ｄモデルに適用するっていう風に。

これができたら、シロートでも簡単に３Ｄモデルがぐりぐり動く動画エンターテイメントを
作り出せると思うんだ。最近、ニコニコとかでもアマチュアの映像制作が活発だし、
需要あるかなーと思うんだけど、似たようなこと考えてる人っているかな？

187 ：デフォルトの名無しさん：2008/01/16(水) 02:30:36

カラーとマーカーを使わないモーションキャプチャーと理解していいの?

188 ：デフォルトの名無しさん：2008/01/16(水) 02:35:45

初歩的で高度なレベル？

189 ：デフォルトの名無しさん：2008/01/16(水) 02:35:53

>187
そうなるのかな。
個人で用意できるカメラ１つで（特別な装置なしで）モーションキャプチャするのって
難しいのだろうか？

190 ：デフォルトの名無しさん：2008/01/16(水) 02:39:17

>>189
モーションキャプチャしたいなら、数台のカメラを使って、
いったんボクセルとして処理しなきゃいけないから、
クラスタが必要になるよ。

191 ：デフォルトの名無しさん：2008/01/16(水) 02:47:27

>190
ええと、つまり新しく撮る分にはいいけど、
既存の映画とかのアクションシーンとかから動きを実用レベルで
抽出するのは今の技術じゃ困難ってこと？

192 ：デフォルトの名無しさん：2008/01/16(水) 02:49:34

アイデア盗まれるから誰にも相談せず独りでやればいいよ

193 ：デフォルトの名無しさん：2008/01/16(水) 02:53:26

基礎理論と応用技術の区別もつかない奴が
ちょっとやそっとで簡単に出来ると思ってるだろ

194 ：デフォルトの名無しさん：2008/01/16(水) 02:57:49

>192
あ、・・どもｗ
とりあえず陳腐ではなさそうってことが分かったので真剣に情報集めてみるよ

>193
おっしゃるとおり、現時点で完全に門外漢でございます。
３次元復元は大変困難な分野なのでしょう。お気に触ったのならごめんなさい。

195 ：デフォルトの名無しさん：2008/01/16(水) 03:03:50

>>186
よく見るよ。けっこう難しいよ。
これから研究としてやるにはいい分野かも。
でも、流石にもう追いつけない所に行かれてるかな？

196 ：デフォルトの名無しさん：2008/01/16(水) 03:08:54

なんかビンゴなのが見つかった。しかも2003年ってｗ
ttp://ascii24.com/news/i/soft/article/2003/03/01/642163-000.html

>195
確かに、とても追いつけそうにないかもｗｗ
何か違う視点を考えないとなぁ

197 ：デフォルトの名無しさん：2008/01/16(水) 03:19:06

>>196
へー、こんな物が有るんだ。
でも、儲かってなさそう。

198 ：デフォルトの名無しさん：2008/01/16(水) 03:56:44

>>196
これって、フレーム毎にマーキングしなくちゃいけないの？

199 ：デフォルトの名無しさん：2008/01/16(水) 05:02:44

CVの人とCGの人が組んで別々にがんばった方がよさそうだおね

200 ：デフォルトの名無しさん：2008/01/16(水) 06:07:20

>>198
aftereffectsのモーショントラッキングのようにある程度は追従するみたい。
でもアクション映画のような複雑な動きの入力はむりぽ。

201 ：デフォルトの名無しさん：2008/01/16(水) 06:30:13

みんな画像処理でどんなプログラム書いてる?
もうかってる?

202 ：デフォルトの名無しさん：2008/01/16(水) 07:02:44

研究でやってるだけだし＾＾；

203 ：デフォルトの名無しさん：2008/01/16(水) 08:48:10

>>185
色分けがはっきりしてるってのは、背景が真っ白で物体に色がある場合とか？
その場合はどうすればいいの？

204 ：デフォルトの名無しさん：2008/01/16(水) 13:25:25

>>203
その色を探す。

205 ：デフォルトの名無しさん：2008/01/16(水) 23:53:10

らくがき王国は分野としては
画像処理に入るの?
それとも、3DCGなの?

206 ：デフォルトの名無しさん：2008/01/17(木) 11:42:32

>>149
今更だけど、フーリエ変換後にインパルス突っ込むっていうのは
ある周波数の成分を突っ込む話になるから
画像には結構影響が出ると思うんだが。

画像の特定の部分が破壊されても、
画面全体に分散してることになるので
破壊されにくいって意味じゃないのかな

でも、これだと
複素使うかどうかというより、フーリエ変換自体の特性の話か

てか電子透かしのための基礎実習みたいな感じ？

>>205
３DCGかと。

画像処理っていうのは、平面画像にある変換をかけてうんぬん
ってやつをいうんじゃないかな

ちょっと気になってるのはデジカメの顔フォーカス
単に肌色っぽい部分にフォーカスかけてるのかね？
PCで無制限に時間かけていいならわかるけど
デジカメみたいなポータブルで瞬間で判断しなきゃいけない
＆複雑な処理もできないデバイスで
どうやって実装してるのか興味ある

207 ：デフォルトの名無しさん：2008/01/17(木) 11:51:59

顔認識とかだと解像度めいっぱいの画像に対してやらんでもいいから、適当に縮小した画像でやってんじゃね？
縮小してつぶれるほど小さい顔にはヒットする必要もないだろうし。

208 ：デフォルトの名無しさん：2008/01/17(木) 12:14:10

>>207
おお、それだ
確かに拡大や縮小はプレビューのためにもともと実装されているから
その実装ならできそうですな

209 ：デフォルトの名無しさん：2008/01/17(木) 12:40:37

俺もCMとか見て気になってた
顔検出ってテンプレートマッチングくらいしか知らんけど使ってんのかな？
笑ったら撮影するのとか横顔でも検出できる製品もあるよね

210 ：デフォルトの名無しさん：2008/01/17(木) 14:01:26

研究でやるのは構わないが、顔関係は特許でガチガチだからな

211 ：デフォルトの名無しさん：2008/01/17(木) 16:09:24

>>206
>画像処理っていうのは、平面画像にある変換をかけてうんぬん
ってやつをいうんじゃないかな

2Dの画像に対して変換をかけて、3Dモデルを作るんだから
画像処理じゃないの？

212 ：デフォルトの名無しさん：2008/01/17(木) 18:46:05

>>205
そういうのは、単一の分野に分類されるものじゃなくて
色んな分野の技術が組み合わさってできてるんだよ。

213 ：デフォルトの名無しさん：2008/01/17(木) 18:48:52

明らかに両方の分野またがってるな。
カツ丼は肉料理ですかご飯物ですかって言ってるようなもの。

214 ：デフォルトの名無しさん：2008/01/18(金) 01:36:24

ネットが使えるようになってから、そういう混成技術も調べられるようになって
嬉しい限り。理系大学生のブログならともかく、専門本は10年経っても出なかったりするからねｗ

215 ：デフォルトの名無しさん：2008/01/18(金) 07:48:04

RGBをHSVに変換する理由って、
0～255 赤～黄色
256～511 黄色～緑
512～767 緑～シアン
768～1023 シアン～青
1024～1279 青～マゼンダ
1280～1535 マゼンダ～赤
みたいな感じで、簡単に色の範囲?を抽出しやすくするため?

216 ：デフォルトの名無しさん：2008/01/18(金) 07:50:23

いいえ。

217 ：デフォルトの名無しさん：2008/01/18(金) 07:59:26

>>215
そう思っておいていいよ

218 ：デフォルトの名無しさん：2008/01/18(金) 08:46:54

どっちが正しいのでしょうか?

219 ：デフォルトの名無しさん：2008/01/18(金) 08:51:46

>>217

220 ：デフォルトの名無しさん：2008/01/18(金) 10:08:37

>>215
RGBやCMYKより人間が感覚的に色を選びやすいから。
選びやすい色空間にはいろいろあるけど、コンピュータで処理するのが簡単って理由でHSVが使われる。

221 ：デフォルトの名無しさん：2008/01/18(金) 10:49:10

理由なんて色々あるべさ。RGBのままだと印刷できない色も表現できてしまうことだし。

222 ：デフォルトの名無しさん：2008/01/18(金) 19:23:06

色空間は、色域が問題にならないなら自分の都合で選択するといいよ。

223 ：デフォルトの名無しさん：2008/01/19(土) 15:44:24

Sobelフィルタとかを調べると3x3の例が多いのですが、
5x5、7x7のSobelフィルタってどうすればエッジ抽出が
できるのでしょうか？

224 ：デフォルトの名無しさん：2008/01/19(土) 16:24:11

3x3と同じ要領

225 ：デフォルトの名無しさん：2008/01/19(土) 21:02:05

3x3が多いけど増やすと効果ある？

226 ：デフォルトの名無しさん：2008/01/20(日) 05:10:17

ある

227 ：デフォルトの名無しさん：2008/01/20(日) 15:33:17

このスレで合ってるのかよくわからないけど･･･
ゲームの会話ウィンドウなんかによくある、半透明のボックス。
背景が半分透けてる画像というか。ああいうのってどうやって作るの？

228 ：デフォルトの名無しさん：2008/01/20(日) 15:36:02

背景の画素を混ぜて描画する

229 ：デフォルトの名無しさん：2008/01/20(日) 15:46:27

>>227
windowsにはSetLayeredWindowAttributesというapiが用意されてる

230 ：デフォルトの名無しさん：2008/01/20(日) 19:02:36

ゲームでそんなAPI使わんだろ

231 ：デフォルトの名無しさん：2008/01/20(日) 19:03:17

>>227
そのまま「半透明画像処理」とかでググれば見つかると思う。
プラットフォームや言語も入れて絞り込めば、すぐに見つかるんじゃない？

232 ：デフォルトの名無しさん：2008/01/20(日) 21:23:55

ゲームに出てくる女の子の服を半透明にするにはどうすればよろしいですか

233 ：デフォルトの名無しさん：2008/01/20(日) 21:34:07

背景の画素を混ぜて描画する

234 ：デフォルトの名無しさん：2008/01/20(日) 21:47:33

なんかワラタｗ

235 ：デフォルトの名無しさん：2008/01/20(日) 22:51:52

心霊写真かよ w

236 ：デフォルトの名無しさん：2008/01/21(月) 01:15:18

奇才あらわる

237 ：デフォルトの名無しさん：2008/01/21(月) 02:59:36

>>232
普通にプレイすれば脱いでくれるのに、半透明とはまたマニアックな…

238 ：デフォルトの名無しさん：2008/01/21(月) 04:49:53

多分泣きゲ

239 ：デフォルトの名無しさん：2008/01/21(月) 15:51:43

>>237
何でもエロゲーだと思うなよw

240 ：デフォルトの名無しさん：2008/01/21(月) 15:53:15

エロゲじゃなければ服を脱がないじゃないか。服が半透明になっても素肌が見えるわけじゃないんだぞ。

241 ：デフォルトの名無しさん：2008/01/21(月) 21:36:07

人間は賢い。
脳内補完すればNO問題

コンピュータで脳内補完はあと10年経ってもできる気がしねぇ。

242 ：デフォルトの名無しさん：2008/01/21(月) 22:29:47

それも膨大な学習時間を経てるからなせる技術。

243 ：デフォルトの名無しさん：2008/01/21(月) 23:18:59

脳内よりVR
ttp://jp.youtube.com/watch?v=Y9HMn6bd-v8

244 ：デフォルトの名無しさん：2008/01/22(火) 10:35:03

>>189-191が一台のカメラで出来てしまう技術だよねそれ
wktkしてるよ

245 ：デフォルトの名無しさん：2008/01/23(水) 15:48:41

マッチングの勉強している初心者ですが、
輝度の正規化っていうと画像内の最高/最低輝度を
0と255に割り当てて、その間の輝度値を線形変換するという事であってますでしょうか。
よろしくおながいします。

246 ：デフォルトの名無しさん：2008/01/23(水) 15:51:52

最高/最低なら、255/0だろ。常考
尤も、処理している間は1/0(実数値)で扱うことも多いが。

247 ：デフォルトの名無しさん：2008/01/23(水) 16:40:09

>>246
書き込んでから、気がつきました。ｽﾏｿ
平均値で割ったり、引いたりするように書いてあるとこも
あるのですが、効果に差があるのでしょうか。
輝度の変化に強いマッチングを目指しているのですが…

248 ：デフォルトの名無しさん：2008/01/23(水) 17:12:01

勉強なら、いろいろやってみたら委員で内科医?

249 ：デフォルトの名無しさん：2008/01/26(土) 21:24:35

単眼カメラでカメラで取得した座標から実空間の座標を
求めたいんですけど、みなさんどうやってもとめてますか？
あと、実空間と画像との誤差はどれくらいでるのか気になります。
よろしくお願いします。

250 ：デフォルトの名無しさん：2008/01/26(土) 22:37:29

マルチうぜえ

251 ：デフォルトの名無しさん：2008/01/26(土) 22:38:11

>>249
キャリブレするか特定の平面からしか無理じゃね？

252 ：デフォルトの名無しさん：2008/01/26(土) 22:46:01

律儀に両方に返信する >>251 萌え

253 ：デフォルトの名無しさん：2008/01/27(日) 00:19:54

>>249
>>243

254 ：デフォルトの名無しさん：2008/01/27(日) 10:36:01

深度マップ（高さマップ）の画像処理について質問です。

http://gamdev.org/up/img/10987.jpg

Aのような画像からBのような画像に変換する
アルゴリズム、またはフリーソフトのようなものは無いでしょうか？

255 ：デフォルトの名無しさん：2008/01/27(日) 10:57:13

無理じゃね？

256 ：デフォルトの名無しさん：2008/01/27(日) 11:10:57

>>254
A、Bがそれぞれどんな意味を持つのか説明しないと、
仮令AをBに変換できたとしても意味がないと思うぞ。

257 ：デフォルトの名無しさん：2008/01/27(日) 12:14:00

すみません。

デジカメの素材写真から高さマップを取りたいのです。
似たようなフィルタはいろいろあるのですが（ndiviaとか）
多くの場合、影が邪魔になります。
暗くなった影部分が凹部分と認識されてしまうのです。

何か方法はないかとおもったのですが
たとえば便宜的にでも光の方向を指定してやって
影から高さを生成してやる、見たいな事をやりたいのです。

正確じゃなくてもある程度のディティールを取れるだけでも
だいぶ作業の効率化が見込めると思えます。

これで説明が足りてると良いのですが。どうでしょうか？

258 ：デフォルトの名無しさん：2008/01/27(日) 12:28:53

卒業研究みたいな話だな

259 ：デフォルトの名無しさん：2008/01/27(日) 12:46:23

Bで表される山にどんな光を当てたらAみたいな影ができるんだろう・・・

260 ：デフォルトの名無しさん：2008/01/27(日) 12:53:29

円錐だな、実際の影の付き方じゃないから難解だが。

261 ：デフォルトの名無しさん：2008/01/27(日) 13:02:44

A->Bは無理だろ。
複雑な図形だったら一方向からのライティングだけではどうにもならないから、最低120度刻みで
３方向くらいの写真を使えば、画像の比較で床に落ちる影は消せるような気もする。

262 ：デフォルトの名無しさん：2008/01/27(日) 13:05:05

つか、Aの右上半分は真っ白にしか見えないんだけど、どうやったらここの形状を求められるの？

263 ：デフォルトの名無しさん：2008/01/27(日) 13:07:39

デジカメ素材に白飛びもあるという前提なのかね

264 ：デフォルトの名無しさん：2008/01/27(日) 16:41:48

うーん、Bの山って、明度でグラフにすると円錐からは随分離れた傾斜になっているんだけど。
どう見てもAみたいな直線の影ができるように見えない。
# jpgにした所為って可能性はあるけど。

265 ：デフォルトの名無しさん：2008/01/27(日) 19:14:26

800*600の画像があったとします。
逆透視変換のためにその画像を上辺900、下辺800、高さ1000の等脚台形に変換したいのですが、
.N簡単な方法があれば教えていただきたいです。

OpenCVのアフィン変換とかになるんですかねやっぱり

266 ：265：2008/01/27(日) 19:18:39

誤爆しました。
開発環境がC#2008なので、まずC#スレで聞いてきます。

267 ：254 ：2008/01/27(日) 20:01:25

ﾚｽありがとうございます。

ああ、皆さん、すいません、Aの画像とBの画像は手でつくったので必ずしも
一致するわけではないです。
こんな感じの処理がしたい、というサンプルです。

>>258
卒制ではないです。
うちのデザイナが高さマップをある程度簡単に作れる奴が欲しいと
のたまいやがるのです。

>>261
写真は一枚が多いですね。
しかも屋外の自然光が多い場合もあります。
あとフラッシュの影とかもある場合が多いです。

>>262
>>263
その辺りは別の処理をしてなんとかします。
必ずしも一回の処理で全てをまかなおうとは思っていません。
最悪手で描くことも想定しています。

>>264
一応線形の円グラデなので多分綺麗な円錐になると思います。

268 ：デフォルトの名無しさん：2008/01/27(日) 20:05:46

そもそもAの図は、グラデーションが付くのは右上で
左下は影になるのが普通だと思うが。
影の中に陰はできないよ。

269 ：デフォルトの名無しさん：2008/01/27(日) 20:24:16

http://www.itmedia.co.jp/news/articles/0801/26/news005.html

270 ：デフォルトの名無しさん：2008/01/27(日) 20:59:46

そりゃー平均顔を作れれば精度はあがるだろうけど、
どうやってその平均顔を作るための大量データを query の度に得るんだ？

271 ：デフォルトの名無しさん：2008/01/27(日) 21:43:35

>>270
そりゃ研究室のみんなに頼むに決まってるだろ。
後輩とか含めて２０人分ぐらい集まるんじゃね？

272 ：264：2008/01/27(日) 21:48:53

>>267
＞一応線形の円グラデなので多分綺麗な円錐になると思います。
だからなってねぇってばよ。
それはさておき、実際にAからBが得られた訳じゃないということは判った。

273 ：デフォルトの名無しさん：2008/01/27(日) 21:54:15

英国秘密情報部が集めて来ます

274 ：デフォルトの名無しさん：2008/01/27(日) 22:00:33

>>270
もしかしたら出入国管理くらいには使われるかもな

275 ：デフォルトの名無しさん：2008/01/27(日) 22:53:49

>>271
おまえはちゃんとリンク先を読め
>デビッド・ベッカム、クリント・イーストウッド、ショーン・コネリー、ビル・クリントンなどの著名人の写真を照合したところ、本人だと正しく判定されたのは半数のみだった。ところが彼らの平均的なイメージ写真をアップすると、識別度はほぼ100％に上昇したという。

つまり、クエリが平均顔でないといけない。
つまり、出入国の度にいろいろな光源の元やノイズのもとで写真を複数とって
平均顔作って入力とするってことだろ？どんだけぇ～

276 ：デフォルトの名無しさん：2008/01/27(日) 22:58:22

>>275
平均顔なんて１０人ぐらいあれば十分なんだよ。

277 ：デフォルトの名無しさん：2008/01/27(日) 23:02:09

10・・・人？

278 ：デフォルトの名無しさん：2008/01/27(日) 23:03:35

読解力無さ杉ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

279 ：デフォルトの名無しさん：2008/01/27(日) 23:08:12

>>276
ベッカムを10人集めるのは大変だと思うぞ

280 ：デフォルトの名無しさん：2008/01/27(日) 23:12:48

すまん、リンク先読んでなかった
顔認証で簡易鍵とかの用途ならできるんじゃね？

281 ：デフォルトの名無しさん：2008/01/28(月) 07:10:02

>>280
カメラの前で、
「少し右を向いて下さい」
「少し下を向いて下さい」
とかやるのか？　指紋や掌紋や網膜認証の方が早いし確実な気がする。

普通に考えて、ずっと映像を取得している監視カメラの映像から平均顔を
作成して、それをキーに検索するってことだろうね。

282 ：デフォルトの名無しさん：2008/01/28(月) 07:49:13

>>254
面白い課題だなぁ。B→Aはできるだろうけど…

閃いた
1.手当たり次第にあらゆるBを作る
2. 大量のBから大量のA的画像を作る
3. 大量のA的画像とAと比較して大体似たような感じなら「たぶんこんな形じゃね？」と
そんな冗談を書いてみるテスト

形状が限られているなら…例えば円錐しか存在しないという仮定ができるなら
底辺の円のサイズ（中心と半径）と、影の頂点をユーザがマウスクリックで指定して（3回クリック）
てなツールを作って作業効率向上ができそうだけど、でもそれって画像処理じゃないな…
底円を求める処理と、影の頂点を求める処理を別にして、得られた2つの情報から類推して…とか…

Aの画像なら、黒い部分で三角形ができるから
そのうちの2つの頂点が低円の直径、かつ、円の中心点を通る直線で、残りの1点が影の頂点
と類推できそうな気もするけど、リアルワールドを撮影した場合に実際Aのような画像になるかどうかは判らないし
例えば航空写真を持ち込んできた場合は自動化は無理な気配

283 ：282：2008/01/28(月) 08:14:51

3DCGツールで円錐を作ってレンダリングしてみたが
http://gamdev.org/up/img/10991.jpg
>>254より判りやすいし見てるうちに方法が見出せそうでもあるけれど
実写の画像となったらこんな綺麗な見え方はしないよな…形状も多岐に渡るだろうし

284 ：デフォルトの名無しさん：2008/01/28(月) 08:25:33

パターン認識

285 ：デフォルトの名無しさん：2008/01/28(月) 10:46:10

>>254
この種の問題は "shape from shading" と呼ばれる一大研究分野だよ。
ググればいっぱい論文が見つかると思う。

286 ：254 ：2008/01/29(火) 02:36:00

ﾚｽありがとうございます！

>>282
残念ながら撮る対象は限定されていないのです。
ソースはデジカメだったり航空写真とかだったりが多いのではないかと思います。

画像はめっさわかりやすいですね！
それをデプスでレンダリングしていただけるとBのような画像になります。

>>285
ググッて見ました。
火星地表面とか宇宙とか・・・ﾃﾗ壮大です。

でも多分これですね。

殆ど英文なのでさっぱりわかりませんが
ちょっくらがんばって読んでみます。

287 ：デフォルトの名無しさん：2008/01/29(火) 10:05:16

>>285
オラも勉強になりました
「陰影からの形状復元」でググると色々出てきますな
これは面白い…

288 ：デフォルトの名無しさん：2008/01/29(火) 11:17:33

http://d.hatena.ne.jp/niitsuma/20080107/1201322983
BIAS libの日本語解説がないみたいなので作りました

289 ：デフォルトの名無しさん：2008/01/31(木) 15:44:39

RGB8各ビットのカラー画像を8ビットグレースケール画像に減色する方法って何がありますか？

290 ：デフォルトの名無しさん：2008/01/31(木) 16:44:07

足し算と割り算でおっけ

291 ：デフォルトの名無しさん：2008/01/31(木) 16:45:27

( R + G + B ) / 3

292 ：デフォルトの名無しさん：2008/01/31(木) 16:53:24

ttp://ofo.jp/osakana/cgtips/grayscale.phtml

293 ：sage：2008/01/31(木) 17:32:57

>290
>291
>292
ありがとうございます。参考にしてみます。

294 ：デフォルトの名無しさん：2008/01/31(木) 17:34:12

sage間違えたｗ

295 ：デフォルトの名無しさん：2008/02/07(木) 04:28:18

http://gigazine.net/index.php?/news/comments/20080206_not_photos/

296 ：デフォルトの名無しさん：2008/02/08(金) 18:41:40

おききしたいことがあります。非常に安価な（３～４万くらい）な画像処理
ボード（ライブラリでとりあえず一連の画像処理が可能）
を探しているのですが、ネット上で色々探したのですがみつかりません。
もしあったら教えていただけないでしょうか？よろしくお願いします。

297 ：デフォルトの名無しさん：2008/02/08(金) 18:51:12

自分で作ったら？

298 ：デフォルトの名無しさん：2008/02/08(金) 20:13:55

>>296
FPGAは？

299 ：デフォルトの名無しさん：2008/02/09(土) 10:03:06

ハードはwebカメラとPC、ソフトは適当なライブラリやソフトでも探してきたら？
PCIボードまで付いてるような奴だと専用のドライバが必要だったりして困る
新しいOSになったときにドライバが提供される保証もないし

300 ：デフォルトの名無しさん：2008/02/11(月) 22:02:36

今、RGB値からグレイスケールに変換するプログラムを書いているんだけど、
http://image-d.isp.jp/commentary/color_cformula/index.html
ここ見て書いてるんだけど
RGB -> R'G'B'の変換が時間を食いすぎると思うんだけど
これは仕方ないんでしょうか。

いろいろ検索してみるとRGB -> R'G'B'の変換ははしょっているものがほとんど(ですね
R'G'B'はガンマ補正とのことですが

301 ：デフォルトの名無しさん：2008/02/11(月) 22:04:01

ごめ、途中で送られた。

R'G'B'はガンマ補正とのことですがあるとないとではどのくらい変わりますでしょうか。
自分で感じ取られないならどっちも同じと言われそうですが。

302 ：デフォルトの名無しさん：2008/02/11(月) 22:15:31

まずは実際の画像を変換して見たら

303 ：デフォルトの名無しさん：2008/02/11(月) 22:39:54

>>300
たかだか8bitのRGBなら変換テーブルつくるだけでそこそこの速度出ると思うが。

304 ：300：2008/02/12(火) 00:26:02

>>302
>>303
Thank you.
実際の画像を変換してみても自分の目にはそれほど違いは見られませんでした。
まぁ、こんなもんかな。と思います。

ですが、しかし、RGB->R'G'B'の変換を除いてもそんなに速度は変わりませんでした。
.Net in C#で組んでいるのですがBitmap.(set|get)Pixelが遅いのかな ?
これ以上はC#か.Net固有の問題になるとおもうので当該スレで聞きます。ありがとうございました。

# 変換テーブルと聞いて256 x 256 x 256 x 4 byteの変換テーブルを考えた俺涙目。
# この場合f(x) = x ^ 0.45のテーブルだけでいいんですね。

305 ：デフォルトの名無しさん：2008/02/12(火) 01:29:10

>>304
3*256じゃね？

そんなに時間がかかるとも思えんが。

306 ：デフォルトの名無しさん：2008/02/12(火) 03:21:26

画像処理の技術はどういった業界で生かされるのでしょうか

307 ：デフォルトの名無しさん：2008/02/12(火) 03:36:59

いろんなの

308 ：デフォルトの名無しさん：2008/02/12(火) 07:55:35

>>304
おまえがRGBだと思っている値がすでにR'G'B'な気がしてならない。
通常使われている8ビット画像（sRGBやAdobeRGBとか）では、
各画素の値（0～255）は線形輝度じゃなくてガンマ補正後の値だよ。

309 ：デフォルトの名無しさん：2008/02/12(火) 09:46:00

>>13は留年になったのだろうか

310 ：デフォルトの名無しさん：2008/02/12(火) 12:21:52

>Bitmap.(set|get)Pixelが遅いのかな ?

めちゃくちゃ遅い
その遅さに比べたらRGB->Grayの演算なんて無視可能
バッファリングしろ

311 ：300：2008/02/14(木) 02:12:34

>>308
Thank you.
そうだよね。いちいち変換が必要な形式で保管しておくのは非効率的だよね。

>>310
バッファリングって
http://junki.lix.jp/csgr/002ColorDataAccess1.htm
に乗ってることでいいのかな ?
このとおりにやったら(unsafe使わずとも)めちゃくちゃ速くなってわろた。

おかげさまで満足な速度が得られました。
ありがとうございました。

312 ：デフォルトの名無しさん：2008/02/15(金) 03:17:34

イメージベースドレンダリングに興味があるのですが、これって普通、何を使ってやるもんなんでしょうか？
Ｃ＋＋とか?
それともOpenGLとか？
ご存じの方がいればぜひ教えて欲しいです。

313 ：デフォルトの名無しさん：2008/02/15(金) 04:06:58

何でも良いよ。

314 ：デフォルトの名無しさん：2008/02/15(金) 09:58:16

>>313
ありがとうございます。
OpenGLを使う場合、どのようにすればいいんでしょうか？
画像を２方向から貼り付けて、かぶってるところをブレンドするとか？

315 ：デフォルトの名無しさん：2008/02/15(金) 10:47:31

輝度値のみの画像において、
別の縞模様が混在するとき、

縞模様別にグループ分けを行うにはどうすればいいでしょうか？

316 ：デフォルトの名無しさん：2008/02/15(金) 12:08:57

cgal

317 ：デフォルトの名無しさん：2008/02/17(日) 02:14:55

フーリエ変換の話・・・？

318 ：デフォルトの名無しさん：2008/02/17(日) 21:13:03

>>314
SIGGRAPHの論文でも読めばいろいろわかるよ

319 ：デフォルトの名無しさん：2008/02/22(金) 02:35:37

エッジの抽出を行ってみたのですが、もと画像のエッジを強調したようにそれ
を適用したい場合どのような計算を行うのでしょうか?

エッジの抽出はカラー画像をグレースケールに変換して、それをラプラシアン
フィルタで行っております。エッジを抽出したエッジだけの画像があるのです
が、これをもと画像をどのような計算をしたらエッジの強調ができるのかを知
りたいです。

320 ：デフォルトの名無しさん：2008/02/22(金) 02:58:44

>>319
エッジ＋元画像でいいんじゃね

321 ：319：2008/02/22(金) 03:20:01

>>320
ありがとうございます。私もそう思いやってみたのですが、ものすごい不自然
なできになりました。

やったこととしては、エッジの値を256階調のグレースケールで保存しているた
め、これを足してしまうと各カラーが256を越えてしまうため、適当な値で
(64)で割りました。
その値を、各カラーに足したのですがエッジに当たる部分が強調されるのでは
なく、予期しない色になってしまいました。

322 ：デフォルトの名無しさん：2008/02/22(金) 03:22:42

>>321
単なるバグだな。
もうちょっと考えて作れ。

323 ：319：2008/02/22(金) 03:32:30

考え方としてはあっているのでしょうか？

エッジのみを表示するとエッジが抽出できていることは確認できているので、
それ以降の処理としては値を足しているだけなので、簡単に確認できると思います。
注意深く確認してみます。

324 ：デフォルトの名無しさん：2008/02/22(金) 03:54:43

まぁそりゃー変な色になるだろうなぁ。
(0,10,20) + 230 = (230,240,250)
とされたら大分かんじは違うもんな。
RGB チャネル別々にするとか、
HSV の V の部分にだけ適用するとか(HSI でもいいけど）、
そういうが必要になるんじゃない？
それでも強調の表現として Intensity を高めるのがうまい表現なのか、
とか考える必要がありそうな気もする。
「エッジ辺りは赤っぽくして強調してみました」なんて表現もありうるんだろうし。

なにもぐぐらず書いているので、ぐぐったほうが早いかも。

325 ：デフォルトの名無しさん：2008/02/22(金) 10:05:47

エッジは足すんじゃなく元の画像から引け。

326 ：デフォルトの名無しさん：2008/02/22(金) 12:03:02

エッジ強調とかソフトとかのフィルタを書けたときに、その効果が
見やすい画像ってどんな画像だろう。

327 ：デフォルトの名無しさん：2008/02/22(金) 12:30:32

横入り失礼。
おれも昔にエッジ抽出とか試したことあるんだけど、なかなかうまく行かなかった。
{{ 1 1 1}
{ 1 -8 1}
{ 1 1 1}}
ってなフィルタを作って、それらを全部足して行ったら256越えちゃうの。
おれって阿呆なの？

これをどうやったら256までの値にできるの？

328 ：デフォルトの名無しさん：2008/02/22(金) 12:59:39

つうか、こんな話は画像処理の基礎なんだから
本屋で立ち読みするなり、図書館で本を読むなりする
程度の努力はしようよ…

329 ：デフォルトの名無しさん：2008/02/22(金) 13:03:14

そんなこと言うなら、答えてやればいいのに

330 ：デフォルトの名無しさん：2008/02/22(金) 13:26:57

ソフトよりはエッヂの方が確かに難しいかもな

331 ：デフォルトの名無しさん：2008/02/22(金) 17:05:31

>>327
つ飽和演算

332 ：デフォルトの名無しさん：2008/02/22(金) 17:07:06

すまOTZ。
×>>327
○>>321

333 ：デフォルトの名無しさん：2008/02/22(金) 18:26:19

普通気付くでしょ、阿呆だよ

334 ：デフォルトの名無しさん：2008/02/22(金) 22:08:19

>>327
阿呆だなぁ。超えるのが普通だと思えないとはなぁ。
255 255 255
255　　0 255
255 255 255
なら 255 * 8 の値になるだろ？超えるさ。

335 ：デフォルトの名無しさん：2008/02/22(金) 22:29:50

コーシー・シュワルツの不等式置いときますね
-|X||Y| ≦ X・Y ≦ |X||Y|

336 ：デフォルトの名無しさん：2008/02/23(土) 00:18:41

>>334
越えるからどういうふうにしたらいいか聞いてるんじゃないんでないか？

337 ：デフォルトの名無しさん：2008/02/23(土) 00:20:34

適当に正規化すればいいんじゃないの?

338 ：デフォルトの名無しさん：2008/02/23(土) 00:35:21

うむ。そもそも画像ファイルとして表示しなければいけないというわけでもないしね。
どうしても画像ファイル的に表示したい場合 0-255 の範囲に正規化してやればいい

339 ：デフォルトの名無しさん：2008/02/23(土) 05:13:24

内部は全部 double にして、出力時だけ正規化してる

>>326
Lenna みたいなテスト画像だと似たような処理例が見つかる確率が高いのでいいんじゃない?
ttp://en.wikipedia.org/wiki/Lenna

340 ：デフォルトの名無しさん：2008/02/23(土) 17:55:11

>内部は全部 double にして
計算速度、遅そう。

あと、正規化するんなら、アンダーフローもお忘れずに

341 ：デフォルトの名無しさん：2008/02/23(土) 18:11:50

内部はintとかでよくね？

342 ：デフォルトの名無しさん：2008/02/23(土) 18:31:16

用途による。FFTする必要があるなら実数にしなきゃならんし。

343 ：デフォルトの名無しさん：2008/02/23(土) 18:55:48

doubleの演算はfloatより早いよ

344 ：デフォルトの名無しさん：2008/02/23(土) 18:56:37

というのはガセ

345 ：デフォルトの名無しさん：2008/02/23(土) 18:58:05

というのもガセ

346 ：デフォルトの名無しさん：2008/02/23(土) 19:03:22

画像処理で整数型とかどんだけニッチな用途なんだよ

347 ：デフォルトの名無しさん：2008/02/23(土) 19:12:03

画像処理で浮動小数点とかどんだけニッチな用途なんだよ

348 ：デフォルトの名無しさん：2008/02/23(土) 19:38:42

画像処理とかどんだけニッチな用途なんだよ

349 ：デフォルトの名無しさん：2008/02/24(日) 00:20:25

正規化って何？

350 ：デフォルトの名無しさん：2008/02/24(日) 00:40:54

エッジ強調のCのソース無いかな

351 ：デフォルトの名無しさん：2008/02/24(日) 02:35:31

エッヂの強調は誰もが通る道なのか

352 ：デフォルトの名無しさん：2008/02/24(日) 03:24:58

むっつりですまん

353 ：デフォルトの名無しさん：2008/02/24(日) 11:54:40

漏れも通った
20年くらい前に

354 ：デフォルトの名無しさん：2008/02/24(日) 12:09:50

20年前って8ドットで16中2色しか使えない時代じゃん。

355 ：デフォルトの名無しさん：2008/02/24(日) 12:24:25

ハードウェアの制約があっても計算式は制約ないんじゃね？
多くの技術がそういうもんだろ

356 ：デフォルトの名無しさん：2008/02/24(日) 12:30:21

そもそも縁の強調って通ったとか悩むほどのものなのか

357 ：デフォルトの名無しさん：2008/02/24(日) 13:32:34

>>354
TMS9918乙、つーかもう26年前だそれは。
つーかX68kももう20年超えてるのか…。

358 ：デフォルトの名無しさん：2008/02/24(日) 14:45:48

>>356
結構難しいでしょ。
抽出なら簡単だけど、抽出した箇所を厳選(エッジの輪郭抽出とか、ノイズ除去)して
それをもと画像に適用しなくてはならん。
適用するのにもどの範囲を適用するか、適用の強度は、適用後のノイズ除去は。
とか色々な問題が出て来る。ライブラリ使ったら簡単だし、Windowsでも簡単だけど。

359 ：デフォルトの名無しさん：2008/02/24(日) 17:27:35

多分、ここのやつらはWindowsでしょ。
画像加工の難しさを知らない

360 ：デフォルトの名無しさん：2008/02/24(日) 18:08:04

専用組み込み機器でやってるオレも見てますよ

361 ：デフォルトの名無しさん：2008/02/24(日) 21:00:14

アンシャープマスクじゃ駄目なのか？

362 ：デフォルトの名無しさん：2008/02/24(日) 22:10:24

>>359
OSはあんまり関係ないような
むしろ用途

363 ：デフォルトの名無しさん：2008/02/25(月) 08:27:30

>>361
ソフトは足した後割るだけでいいでしょ

364 ：319：2008/02/25(月) 09:25:18

色々と調べてみたのですが、わからなかったです…。
私がやっているのは、8近ほうの各値(RGB255値)にフィルターの値を積算してそれを全て和算しています。
その値が120よりおおきければ、各値(RGB255値)に2を足しています。
この値を変えてもエッジが強調されているようには見えません。

皆さんはどのような計算をなさっているのでしょうか？

365 ：デフォルトの名無しさん：2008/02/25(月) 09:29:19

1%明るくしたくらいじゃ、強調にならないだろ。常考

366 ：デフォルトの名無しさん：2008/02/25(月) 09:42:53

ラプラシアンフィルタはエッジの抽出であって、強調はできないでしょ。

367 ：デフォルトの名無しさん：2008/02/25(月) 21:24:29

せっかく>>361が教えてくれているというのに皆ガン無視なのな
ラプラシアンでもやることは一緒やん

368 ：デフォルトの名無しさん：2008/02/25(月) 21:26:08

アンシャープマスクってソフトフィルタだろ？

369 ：デフォルトの名無しさん：2008/02/25(月) 21:33:51

ググれカス！がこれほどよく似合う>>368は居まい

370 ：デフォルトの名無しさん：2008/02/25(月) 21:37:36

na\\なんですかそれは

371 ：デフォルトの名無しさん：2008/02/26(火) 03:10:04

>>364
＞その値が120よりおおきければ、各値(RGB255値)に2を足しています。

何のために？

372 ：デフォルトの名無しさん：2008/02/26(火) 08:47:02

>>349
正規化とは変な値を都合のいいように直すことだよ。

たとえば角度の-90度を270度に直すとか。
都合によっては逆に角度270度を-90度に直すのも正規化。

8ビットの画素の値なら
if(x > 255) x = 255; else if(x < 0) x = 0;
このxで描画すればいい。

373 ：デフォルトの名無しさん：2008/02/26(火) 09:32:29

>>372
>if(x > 255) x = 255; else if(x < 0) x = 0;
>このxで描画すればいい。
大学の課題でこれ提出したら減点だな。
画像として表示して何がしたいのかといったら、
エッジとしての強度を目視したいわけで、
256 も 1100 も全部同じ強度として表示するってんじゃぁ、
こまっちんぐだぜ

374 ：デフォルトの名無しさん：2008/02/26(火) 10:04:31

それは気がつきませんでした。
エッジ強度の目視とか
そんなに大きな値を加算しているとは思いませんでした。

375 ：デフォルトの名無しさん：2008/02/26(火) 14:01:55

>>371
その値は0から1000を越えるものまであり、それをRGBの値に足すとおかしな画像になってしまいます。
なので、このばあいは120以上をエッジとするようにして、そのエッジ部分に一律2を足そうと考えました。

この考えは間違っているのでしょうか？

376 ：デフォルトの名無しさん：2008/02/26(火) 14:17:20

ラプラシアンなら負の値も出てくるだろ。
つうか、何で2を足すんだ？

377 ：デフォルトの名無しさん：2008/02/26(火) 14:24:54

>>376
負の値がでたら、絶対値に擦るようにしています。
2を足すのは、エッジの部分に対応するもと画像を強調したいためです。

378 ：デフォルトの名無しさん：2008/02/26(火) 14:25:16

すみません。足していません。引いています。

379 ：デフォルトの名無しさん：2008/02/26(火) 14:44:24

だから、1%程度明るくなろうが暗くなろうが目立つわけないだろと。

380 ：デフォルトの名無しさん：2008/02/26(火) 14:46:05

では、どのような加工をしたらいいのでしょうか？

381 ：デフォルトの名無しさん：2008/02/26(火) 14:50:34

少しは頭を使え。手を動かせ。

382 ：デフォルトの名無しさん：2008/02/26(火) 14:59:45

エッジ抽出以前に、画素の量子化とその値についての理解が全然足りないように思える。

383 ：デフォルトの名無しさん：2008/02/26(火) 15:31:10

スレ伸びてると思ったらｗｗｗｗ
久々にﾜﾛﾀｗｗｗｗ

384 ：デフォルトの名無しさん：2008/02/26(火) 18:42:49

まだやってたのか

385 ：デフォルトの名無しさん：2008/02/26(火) 19:08:11

誰も的確な答えを出さないからでしょ

386 ：デフォルトの名無しさん：2008/02/26(火) 19:13:30

ぷっ

387 ：デフォルトの名無しさん：2008/02/26(火) 19:22:51

理解不足しているだろうから、弄っているだｊけ。

断片的な返答から的外れなのは分かるが、どこまで的を外しているか
全体像が掴めないので、誰も的確な返答が出来ない。ｗｗｗ

388 ：デフォルトの名無しさん：2008/02/26(火) 19:26:37

まぁ、回答者の大半も意味が分かってないけどな。

389 ：デフォルトの名無しさん：2008/02/26(火) 19:32:23

問題が何なのかすらわからん俺にとって関係ない話だな

390 ：デフォルトの名無しさん：2008/02/26(火) 20:27:02

必要の無い奴まで書き込むから、こんな風になるんだよ。

391 ：デフォルトの名無しさん：2008/02/26(火) 22:04:19

ソースコードでもうｐしてみれば盛り上がるんじゃね？

392 ：デフォルトの名無しさん：2008/02/26(火) 22:31:07

そのラプラシアンって元画像に合成しても
画像のエッジ強化につかえねーんじゃねーの？

ラプラシアンてどんな値の範囲になるのかしらないけどさ。

393 ：デフォルトの名無しさん：2008/02/26(火) 22:33:53

>>321
65で割れ

394 ：デフォルトの名無しさん：2008/02/26(火) 23:55:23

薄緑だけ濃くしたいんですけど、どんな計算が有効ですか？

395 ：デフォルトの名無しさん：2008/02/27(水) 00:14:46

>>394
if (画素.色 == 薄緑の範疇) 画素.濃く(適当に)

396 ：デフォルトの名無しさん：2008/02/27(水) 00:59:16

>>395
上手く処理できました。ありがとうございます。

397 ：デフォルトの名無しさん：2008/02/27(水) 01:35:29

ﾜﾗﾀ

398 ：デフォルトの名無しさん：2008/02/27(水) 02:40:26

たまたまWindowsの画像を扱ってるコード見たけどひどいな。
ライブラリに展開とかすべてまかせて、それをWindowにはっつけてるだけ。
WindowにはっつけるのもAPI。
画像の加工はライブラリのできる範囲内でやってるし。

399 ：デフォルトの名無しさん：2008/02/27(水) 03:08:43

間違いなくお前の日本語が一番酷い

400 ：デフォルトの名無しさん：2008/02/27(水) 04:01:29

>>398
で？

401 ：デフォルトの名無しさん：2008/02/27(水) 05:02:45

画像処理技術者って、結局『やってみなきゃ解らない』を逃げ場にしている人達のことですか？

402 ：デフォルトの名無しさん：2008/02/27(水) 05:08:02

で？

403 ：質問です：2008/02/27(水) 08:05:51

ここの人は親切だから、つい聞いてしまうんだが、
古いカラーのネガフィルムをスキャンして、データ化しました。中にカビだろうか
緑色のアメーバ状の汚れがあります。これを取るのって、範囲を指定して
緑の要素が強いピクセルのみ緑を弱くするしか方法はないでしょうか。
>>401 氏の発言も考慮の上、お教えください。

404 ：デフォルトの名無しさん：2008/02/27(水) 08:11:12

手でレタッチしたほうがはやいんじゃね

405 ：デフォルトの名無しさん：2008/02/27(水) 08:14:49

>>398
車輪の再発明はお好きですか

406 ：デフォルトの名無しさん：2008/02/27(水) 08:18:40

いつもの写真馬鹿か

407 ：デフォルトの名無しさん：2008/02/27(水) 08:44:30

もう学生の宿題ネタはお腹一杯

408 ：デフォルトの名無しさん：2008/02/27(水) 09:10:24

>>403
緑の汚れが乗っていると言うことは、その為に情報量が落ちていると言うこと。
従って、仮令緑を弱くしても元の画質が完全に再現できるわけではないことに注意。

409 ：デフォルトの名無しさん：2008/02/27(水) 21:21:35

if (画素. == カビ含む) 画素.取る(カビ)

410 ：デフォルトの名無しさん：2008/02/27(水) 22:16:45

カビの無修正画像

411 ：デフォルトの名無しさん：2008/02/27(水) 22:23:49

フィルムからカビを除去して再スキャン
プログラムにまかせるよりも着実な気がする。

412 ：デフォルトの名無しさん：2008/02/27(水) 22:43:30

カビキラーでおｋ

413 ：デフォルトの名無しさん：2008/02/27(水) 22:55:55

>>409
実装して下さい

414 ：デフォルトの名無しさん：2008/02/27(水) 23:28:05

C++嫌い

415 ：デフォルトの名無しさん：2008/02/28(木) 00:03:16

昔、ノイズ除去をやって思ったが、何をノイズと捉えるかが難しい。
「こっち」「そっち」の境界線が曖昧なのと一緒でノイズだと思いはじめたら全部ノイズに思えて来る。
画像上のカビも何をしてカビと特定するかが問題だ。
画像上でそこにあるカビの成分が検出できればもっと簡単かもしれん。

416 ：デフォルトの名無しさん：2008/02/28(木) 00:08:50

どう考えても>411だなぁ。>408の指摘する問題も解決するわけだし。

417 ：デフォルトの名無しさん：2008/02/28(木) 00:18:13

カビを見たい人だっているかもしれないからな

418 ：デフォルトの名無しさん：2008/02/28(木) 00:31:54

このスレ的な話題ではないが、
実際にフィルムをスキャンする仕事をしていたが、カビの除去はできない。
ある程度はできるが、ある程度以上はフィルムに傷がいくからそれ以上は繁殖を抑える加工をして
スキャンして、将来的にカビを綺麗に除去できる技術ができるのを待つだけ。
個人のフィルムならどうでもいいと思うが、仕事として請け負うフィルムは歴史的なものが多いから。

色々な業務用のフィルム画像の補正ソフトを使ってみても、結局ホコリが綺麗に見えなくなるくらいが限界。
あとの変色とかは1ピクセル毎に手作業で修正する。
自動ソフトで頑張る価値はあんまりないと思う。

419 ：デフォルトの名無しさん：2008/02/28(木) 10:01:48

>>403
画像処理　その８で話題になっていた
gimpのプラグインもあるのですぐ試せる

http://www.greyc.ensicaen.fr/~dtschump/greycstoration/demonstration.html

420 ：デフォルトの名無しさん：2008/02/28(木) 16:38:35

http://www.itmedia.co.jp/news/articles/0802/27/news027.html

421 ：403：2008/02/28(木) 19:32:14

皆さん & >>419 さんありがとう。
解があることが分かった。気分は途も半ば。

422 ：デフォルトの名無しさん：2008/02/29(金) 01:32:04

ほこりや傷があった方が味がいいと思う。

423 ：デフォルトの名無しさん：2008/03/01(土) 12:12:00

jpegの量子化テーブルって8以下指定出来るん？
8bitに収まらんと思うんだが。

424 ：デフォルトの名無しさん：2008/03/03(月) 11:13:28

>>423
何が言いたいのかワカランが
量子化テーブルって1-255だろ・・・？

425 ：デフォルトの名無しさん：2008/03/04(火) 00:50:59

元画像とそれを画像処理したものを比較して、元の画像が含まれるかどうやって識別するのがいいのか
回転拡大縮小は無い前提で

426 ：デフォルトの名無しさん：2008/03/04(火) 01:05:58

目視

427 ：デフォルトの名無しさん：2008/03/04(火) 01:07:41

>>425
bool isInclude() { return true; }
他にどうしろと。

428 ：デフォルトの名無しさん：2008/03/04(火) 02:20:55

is includeって酷い関数名だな

429 ：デフォルトの名無しさん：2008/03/04(火) 04:03:23

テンプレートマッチングだかなんとか

430 ：デフォルトの名無しさん：2008/03/04(火) 08:30:43

process(元画像).eq.比較画像

まさかね…

431 ：デフォルトの名無しさん：2008/03/04(火) 10:04:14

>>425
適当に特徴抽出して、その特徴で比較すりゃいいだろ。

432 ：デフォルトの名無しさん：2008/03/04(火) 10:58:13

含まれるという言い方が悪かった
部分的に色合いが変化してたり、ネガポジ反転していても元画像と同じだと判断する方法が欲しかった
やっぱり特徴抽出か

433 ：デフォルトの名無しさん：2008/03/04(火) 10:59:00

>>432
どんな画像処理をしたのか見当がついているなら、特徴を抽出する必要はないけどね。

434 ：デフォルトの名無しさん：2008/03/05(水) 03:11:24

＞部分的に色合いが変化してたり、ネガポジ反転していても元画像と同じだと判断する方法が欲しかった

RGB変化ならエッジ検出でいいんじゃない。

435 ：デフォルトの名無しさん：2008/03/06(木) 23:36:38

>>424
ん？えと、jpeg（てかDCT)の計算式だと0～255の
8x8ブロックの計算結果が-1024～1024になる（可能性がある）んよ。
つまり情報量が3bit増える訳なのね。

それを削除するためにjpeg基準テーブルは8以上を指定しているんだな、と。
つまり3bit以上減らすのが前提だと判断してたのよ、俺は。

でも某jpeg本が「超高画質なら1を指定しる」とか書いてたんで
「あれれれ？それマジ有り？」と思ったので聞いてみた。

知ってる人答え教えてちょ！

436 ：435=423：2008/03/06(木) 23:37:29

ってことで一つヨロシク

437 ：デフォルトの名無しさん：2008/03/06(木) 23:41:39

-1024～1024なら5bit増えてない？

438 ：デフォルトの名無しさん：2008/03/06(木) 23:45:23

5？

439 ：デフォルトの名無しさん：2008/03/06(木) 23:47:51

あ、-1024～1024じゃなく-1024～1023だな。すまん。
ま、内部計算次第だけどさ。

ちなみに0-2047は11bitだぞう。

440 ：デフォルトの名無しさん：2008/03/06(木) 23:48:11

増えてるな。

441 ：デフォルトの名無しさん：2008/03/07(金) 09:05:15

>>435
DCTの結果についてはそのとおり

けど、量子化によって、8bitに収めるわけじゃない
量子化したあと、
ハフマン符号化でその範囲の値を受け入れるだけ

442 ：デフォルトの名無しさん：2008/03/07(金) 21:47:58

>>441
おお、ありがとう！
そうか、ハフマン忘れてたんだ。

いや、本当にありがとう。今度一杯奢るよ。

443 ：デフォルトの名無しさん：2008/03/08(土) 21:04:36

二つの色を比べてどのくらい似ているかを判断したいのですが、どのような方法がありますか。
生の色情報は、RGBのフルカラーで持っています。速度は要求していないので、変換するのは問題ありません。

赤、緑、青のそれぞれの色の差で単純に比較でも良い気はするのですが、65536色では緑に多くビットを割り当てるくらいだし、色の濃さによっては同じ差分でも感じ方が違うと思うので、もう少しましな方法がないかなと思っています。

444 ：デフォルトの名無しさん：2008/03/08(土) 21:13:28

RGBの差に輝度の係数かけてみたら?

445 ：デフォルトの名無しさん：2008/03/08(土) 21:23:01

「似ている」とは何を意味するのかが問題ですな

446 ：デフォルトの名無しさん：2008/03/08(土) 22:04:39

彩度が高いと色相が支配的になるだろうし、
色相によっては明度が違って見えるし、
明度が両極端だと彩度の意味がなくなるし、
……

447 ：デフォルトの名無しさん：2008/03/08(土) 22:19:07

いわゆる特殊な色覚を持っている人が似ていると判断する色と
そうじゃない人が似ていると判断する色は違うからなぁ

448 ：デフォルトの名無しさん：2008/03/08(土) 22:22:03

周波数領域での加工を前提とすると、
FFT前に窓がけしないと、周波数領域の信号レベルの確度が悪くなる
逆FFT後に窓がけしないと、時間領域で接続性が悪い

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

449 ：デフォルトの名無しさん：2008/03/08(土) 22:43:01

なぜサウンドプログラミングスレのコピペが

450 ：デフォルトの名無しさん：2008/03/08(土) 23:18:56

>>443
まずyuy2にする。それで輝度と色度に分ける。
人間の眼は輝度＞色度だから色度の重要さを下げる。
音よりは低いが人間の感じる感触は指数に比例しがちだからそれも考慮する。

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

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

451 ：デフォルトの名無しさん：2008/03/08(土) 23:40:01

研究とか言い出す前に「均等色空間」という言葉くらい出そうぜ。
塗料とか製造業の分野では色の違いは黙ってΔE*abで評価するものだ。

452 ：443：2008/03/09(日) 00:04:22

>>444
RGBのそれぞれの差に、緑を大めに掛けてみるってこと？

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

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

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

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

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

453 ：433：2008/03/09(日) 13:36:32

以下のページを参考に、色差を求めることにしました。ΔE*abってやつですかね。
http://image-d.isp.jp/commentary/color_cformula/Lab.html
http://www11.tok2.com/home/yoshih/color_abc_5.html
多少、感覚と違う値となることはありますが、似ているのに違う色と判断することがないよう、閾値を大きくすることにしました。20とか。
違う色なのに似ていると誤判定されても多少は許される用途なので。

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

454 ：デフォルトの名無しさん：2008/03/09(日) 13:40:32

まあそんなんでいいと思うよ

455 ：デフォルトの名無しさん：2008/03/12(水) 15:45:35

パターンマッチ＋サブピクセル処理をいろいろ調べたいのですが、
いいサイト、本などございませんでしょうか。
本をみたりしていますが、なかなかいいものがなくて。

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

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

456 ：デフォルトの名無しさん：2008/03/13(木) 18:13:55

どこまで調べた？
本のタイトルとか。
あと、それで満足できない理由は何かを教えといて。

457 ：455：2008/03/14(金) 00:37:18

＞４５６
すいません。
あと一日調べ倒してから、
再質問することにします。

458 ：デフォルトの名無しさん：2008/03/14(金) 00:39:34

そういやJPEG XRってどうなってるんだろ

459 ：デフォルトの名無しさん：2008/03/14(金) 02:55:21

DATファイルに格納されている画像を取り出すにはどうすればいいですか？

460 ：デフォルトの名無しさん：2008/03/14(金) 03:16:56

スレ違い

461 ：デフォルトの名無しさん：2008/03/14(金) 15:52:04

ある意味画像処理だなｗ

462 ：デフォルトの名無しさん：2008/03/14(金) 17:01:45

>>459
拡張子をmpgに書き換えてダブルクリック

463 ：デフォルトの名無しさん：2008/03/14(金) 19:39:31

>455
やりたいことから考えると、パターンマッチングよりハフ変換のような気がする。
その「丸いもの」は何？
カメラ視野に入ってきたり出て行ったりするもの？
形や大きさが決まっているならテンプレートマッチングでいいけど。決まっていないならハフかな。

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

464 ：455：2008/03/15(土) 03:34:20

>463
ご返信ありがとうございます
ハフ変換（円弧）実験してみます。

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

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

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

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

465 ：デフォルトの名無しさん：2008/03/15(土) 03:42:07

Computer Visionは日本語訳が出てますよ（調べてるだろうけど…）

466 ：デフォルトの名無しさん：2008/03/15(土) 09:10:23

丸いもの……
ディスク? 半導体ウェファー? 月? 鼈?

467 ：デフォルトの名無しさん：2008/03/15(土) 11:00:17

ttp://ja.wikipedia.org/wiki/%E7%94%BB%E5%83%8F:Crops_Kansas_AST_20010624.jpg

丸いものがいっぱい。

468 ：デフォルトの名無しさん：2008/03/15(土) 12:51:12

Forsyth「コンピュータビジョン」を持ち歩くのか...

469 ：デフォルトの名無しさん：2008/03/15(土) 18:14:49

>464
サブピクセル処理、わからなければ元画像を１０倍に広げてやれば、元の0.1ピクセル処理したのと同等。

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

470 ：デフォルトの名無しさん：2008/03/15(土) 21:42:00

>>467
灌漑農業の上空写真か。
まるで圧縮画像のブロックノイズだな

471 ：デフォルトの名無しさん：2008/03/17(月) 21:18:51

画像の回転について質問があるのですが、回転行列を
固定小数点にて表現するときにはどの程度の精度があれば十分なのでしょうか？
自分の考えだとVGAの場合2^10>640であるため符号も込めて10ビットの精度が必要
であると思うのですが如何でしょうか?

472 ：デフォルトの名無しさん：2008/03/17(月) 21:48:27

君に目は無いのか

473 ：デフォルトの名無しさん：2008/03/17(月) 22:51:06

無いんです

474 ：デフォルトの名無しさん：2008/03/18(火) 03:25:33

このスレの住人なら知っていますね、あの糞開発ツールのことを

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

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

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

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

475 ：デフォルトの名無しさん：2008/03/18(火) 04:49:43

あれってどれだ
いっぱいありすぎてわからん

476 ：デフォルトの名無しさん：2008/03/18(火) 15:34:41

Javaだろ。

477 ：デフォルトの名無しさん：2008/03/18(火) 16:42:14

Javaってツールなのか？

478 ：デフォルトの名無しさん：2008/03/18(火) 17:50:02

コンピュータ自体がツールです

479 ：デフォルトの名無しさん：2008/03/18(火) 18:15:39

Oracleのツール類だろ。

480 ：デフォルトの名無しさん：2008/03/18(火) 19:41:17

人間はわたしの道具です

481 ：デフォルトの名無しさん：2008/03/18(火) 22:28:54

我が共和国の同士は全て将○様の道具ニダ。

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

482 ：デフォルトの名無しさん：2008/03/20(木) 11:16:20

ｱｰｱ

483 ：デフォルトの名無しさん：2008/03/25(火) 13:20:42

lisp使ってる人っています？
pythonなら沢山いるのかな
ほとんどはc?

484 ：デフォルトの名無しさん：2008/03/26(水) 02:37:08

> lisp使ってる人っています？
> pythonなら沢山いるのかな
どちらも好きだが本格的に使うに至らない

485 ：デフォルトの名無しさん：2008/03/26(水) 02:49:37

簡単な処理ならPython+PILでやるときもある

486 ：デフォルトの名無しさん：2008/03/26(水) 04:46:31

>>483
何か遅いよなぁと思いつつJava

487 ：デフォルトの名無しさん：2008/03/26(水) 21:10:17

http://www.cliki.net/graphics%20library
lispの画像処理、いろいろあるけど
OpenCVみたいにメジャーなのはどれ？

488 ：デフォルトの名無しさん：2008/04/03(木) 22:12:23

ttp://dc.watch.impress.co.jp/cda/other/2008/04/03/8249.html
すげえ

489 ：デフォルトの名無しさん：2008/04/03(木) 22:32:58

>488
確かにすげぇ。
ピンボケしても元の情報って落ちてないのか。
落ちてると思い込んでた。

490 ：デフォルトの名無しさん：2008/04/03(木) 22:43:36

>>488
これはデコンボリューションの1種という捉え方であってるのかな…

491 ：デフォルトの名無しさん：2008/04/03(木) 22:46:32

いや、落ちますよ。写真として再現するレベルには足りているようですが。

492 ：デフォルトの名無しさん：2008/04/03(木) 22:57:27

この人は元Stanford大なんだね
研究成果を活かしたベンチャーらしい
だれか興味がある人は元の論文読んでくれ

493 ：デフォルトの名無しさん：2008/04/03(木) 23:05:47

>>488
この"Light Field Camera"ってカメラ自体も特殊なんじゃねーの？
http://dc.watch.impress.co.jp/cda/parts/image_for_link/132797-8249-1-1.html

494 ：デフォルトの名無しさん：2008/04/03(木) 23:28:32

http://graphics.stanford.edu/papers/lfcamera/
http://graphics.stanford.edu/papers/fourierphoto/
http://graphics.stanford.edu/projects/lfmicroscope/
センサの手前に挿入するマイクロレンズが肝で、
4次元ライトフィールドをキャプチャできる代わりに解像度が犠牲になります。
本当にありがとうございました。

495 ：デフォルトの名無しさん：2008/04/04(金) 00:41:38

>>494
リンクにある顕微鏡版のはyoutubeにデモがあがってたな

496 ：デフォルトの名無しさん：2008/04/04(金) 07:52:55

あの～、ピンボケの自動補正なんて、すごく地味で超初心者向けな機能なんですけど。
この手法を応用して、もっと別な面白いことに発展したらいいね。

497 ：デフォルトの名無しさん：2008/04/04(金) 08:54:40

つまり、記事を書いた香具師は画像処理の基本も判っていない半可通だと言うことで宜しいか。

498 ：デフォルトの名無しさん：2008/04/04(金) 09:01:18

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

499 ：デフォルトの名無しさん：2008/04/04(金) 10:09:20

>>498
発表者がマイクロレンズって言ってたのをそのまま書いただけだろ。
ボディとレンズの間にマイクロレンズがあるって、あとから訂正されてるし。

500 ：デフォルトの名無しさん：2008/04/04(金) 10:33:54

ああ、さっき初めて記事を読んだから気づかなかったけど、>>494の1時間後に訂正されてたのか。

501 ：488：2008/04/04(金) 21:16:52

やっぱりそういう話なのか(´･ω･`)
光学屋には面白いけど、画像処理はそこまで
複雑じゃないよなあ

502 ：デフォルトの名無しさん：2008/04/04(金) 21:33:56

これってあとから被写界深度も変えられるのかな

503 ：デフォルトの名無しさん：2008/04/05(土) 01:00:37

>>501
>>494の2つ目の論文（SIGGRAPH 2005採択）を読んだ上で「そこまで複雑じゃない」と言ってる？
4Dライトフィールドと2D写真の関係を周波数空間で解析する理論のほうもかなり興味深いと思うけどなぁ

504 ：デフォルトの名無しさん：2008/04/11(金) 15:33:18

Ｃ以外を使ってる人って本当にいないのかい？

505 ：デフォルトの名無しさん：2008/04/11(金) 16:01:32

>>504
いくらでもいるだろ。このスレでもアセンブラの話をしてるやつがいた。
ただ、言語の話はスレ違い。

506 ：デフォルトの名無しさん：2008/04/12(土) 07:01:58

c#でもそこそこスピードでたので移行した。

507 ：デフォルトの名無しさん：2008/04/15(火) 17:48:02

himatsubushiってサイトの人は、
昔、VBで書いてた

508 ： ◆Cgjmdh7/b6 ：2008/04/16(水) 00:24:35

test

509 ：デフォルトの名無しさん：2008/05/01(木) 00:28:36

グレースケールのある程度変化のある背景から明度の差がある
繋がった図形をどうやって抽出すればいい？

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

510 ：デフォルトの名無しさん：2008/05/01(木) 00:37:26

>> 509
何で背景は暗い部分と明るい部分に分かれるの？
安定した状態にならない理由は？

511 ：デフォルトの名無しさん：2008/05/01(木) 07:50:54

とりあえず１階微分とって観察。
２階微分とって観察してみれば？

512 ：デフォルトの名無しさん：2008/05/01(木) 21:36:44

シェーディング補正とかは使えないのかな？

513 ：デフォルトの名無しさん：2008/05/02(金) 10:09:17

boost.gilの正式版でたけど使ってる人いる？

514 ：デフォルトの名無しさん：2008/05/02(金) 11:46:16

３月にでたBIASのリリース版使ってる人いますか？
深刻なバグあったりしないですか？
うちは挙動がおかしかったので前のバージョンに戻しました

515 ：デフォルトの名無しさん：2008/05/02(金) 11:51:37

なにそれ

516 ：デフォルトの名無しさん：2008/05/02(金) 18:53:26

>509

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

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

517 ：デフォルトの名無しさん：2008/05/03(土) 13:20:46

BIAS
http://www.mip.informatik.uni-kiel.de/~wwwadmin/Software/

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

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

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

518 ：デフォルトの名無しさん：2008/05/03(土) 18:15:49

例外が発生するバグほどデバッグしやすいものはないと思うが。
デバッガ使えばすぐにどこが悪いか分かるだろう。

519 ：デフォルトの名無しさん：2008/05/05(月) 02:07:10

>>513
使ってるよ

520 ：デフォルトの名無しさん：2008/05/05(月) 10:36:36

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

と

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

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

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

521 ：デフォルトの名無しさん：2008/05/05(月) 23:55:15

>>520
x86では普通

522 ：デフォルトの名無しさん：2008/05/06(火) 00:06:58

どうせ80ビットで計算するならlong double残しといてくれって話だよな

523 ：デフォルトの名無しさん：2008/05/09(金) 12:04:20

VBやVCから使えるDLLで、2枚の画像を半透明合成できるものってあるかなあ・・・

524 ：デフォルトの名無しさん：2008/05/09(金) 13:17:07

今から作れば？
おやつ前にはできるだろ。

525 ：デフォルトの名無しさん：2008/05/09(金) 13:27:29

作れないザコのゴミレス程、存在価値のないものはないなｗ

>>523
mDibでググれ

526 ：あいちゃん：2008/05/09(金) 13:29:30

2枚の画像の半透明合成って、対象の画像を1bitずつ交互に描画していくだけじゃだめなの？

527 ：デフォルトの名無しさん：2008/05/09(金) 13:33:27

半透明のコードぐらいググればすぐ出てくるじゃん。

528 ：デフォルトの名無しさん：2008/05/09(金) 14:33:44

本件に関しては、DLLを探して使い方調べているより自分で作った方が早い
に一票

529 ：デフォルトの名無しさん：2008/05/09(金) 14:36:44

>>524=528
作る技術もないのにエラソーにｗ

530 ：デフォルトの名無しさん：2008/05/09(金) 14:40:23

いくらなんでもそれはスキル低すぎだろ。
DLL作ったことありませんとか、BMPの扱い方が分かりませんのレベルか？

531 ：あいちゃん：2008/05/09(金) 14:42:29

えらそーにしてるのは>>529だと思います！！

532 ：デフォルトの名無しさん：2008/05/09(金) 15:09:34

>>529
10行程度のプログラムに「作る技術」もないだろ

533 ：デフォルトの名無しさん：2008/05/09(金) 16:01:11

煽ればムキになってコードが返ってくる
と思ってるくさい

534 ：デフォルトの名無しさん：2008/05/09(金) 18:08:28

口だけのやつばっかだなｗ

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

535 ：デフォルトの名無しさん：2008/05/09(金) 18:23:43

普通にググったらソース出てくるのに。もうアホかと。

536 ：デフォルトの名無しさん：2008/05/09(金) 18:29:08

>>533
大正解
おめでとう

537 ：523：2008/05/09(金) 18:39:14

>>525
ありがとう

538 ：デフォルトの名無しさん：2008/05/09(金) 18:39:45

>>535
ソースがあれば何でもできると思っている基地外発見ｗｗ

539 ：デフォルトの名無しさん：2008/05/09(金) 18:42:02

どんだけスキルないねん。ここム板やで。

540 ：デフォルトの名無しさん：2008/05/09(金) 18:45:32

普通にググったら詳細な説明も出てくるのに。ゆとりか？

541 ：デフォルトの名無しさん：2008/05/09(金) 18:46:59

>>537
おまえのせいで荒れてるのに、不自然なんだよ。
自演してんじゃねー、ボケ。

542 ：デフォルトの名無しさん：2008/05/09(金) 18:47:46

>>537
どういたしまして

543 ：名無し募集中。。。：2008/05/09(金) 21:31:00

あるふぁぶれんど?

544 ：デフォルトの名無しさん：2008/05/09(金) 22:06:40

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

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

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

545 ：デフォルトの名無しさん：2008/05/09(金) 22:21:15

>>544
それbyteじゃ駄目だろう。
あとαが0～255なのに、256で割ったら駄目だろう。

546 ：デフォルトの名無しさん：2008/05/09(金) 22:33:23

>>545
byteは演算式の中ではintに自動格上げされるから問題ないだろ

547 ：デフォルトの名無しさん：2008/05/09(金) 22:36:33

>>545
回答ありがとうございます。

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

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

548 ：デフォルトの名無しさん：2008/05/09(金) 22:39:52

元画像が前乗算済みARGBになってたりはしないよな？
GDI+で言うPixelFormat32bppPARGB

549 ：デフォルトの名無しさん：2008/05/09(金) 22:41:10

アルファが正しいかどうか疑うべきだな

550 ：デフォルトの名無しさん：2008/05/09(金) 22:50:25

>>548
それはないです。ちゃんとPixelFormat32bppArgbとなっています。

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

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

こんな感じなのですが…

551 ：デフォルトの名無しさん：2008/05/09(金) 23:08:12

>>550
cの計算でα掛けちゃってるのが悪いんじゃないか？

552 ：デフォルトの名無しさん：2008/05/09(金) 23:28:23

>>551
元々cでアルファは掛けてませんでしたが、その頃からすでに黒い線は
出ていたので、αを掛けてる例もあったので試してみましたが… orz

553 ：デフォルトの名無しさん：2008/05/10(土) 00:09:48

んー、どういう画像を元にして、処理後どうやって表示したとき変に見えるのか、とかちゃんと書こうぜ。

554 ：デフォルトの名無しさん：2008/05/10(土) 00:33:26

>>553
画像は32bitARGBな画像で、背景がα=0でないとき、重ねるイメージを0.5px移動や回転など
で1px未満でずれたイメージのエッジ部分が黒ずんで見えます。

0　 0.33　 0.67　 1　(px)
│
└─┐
　　 │←こことか　　重ねたイメージ
　　 └─┐
　　　　 │←こことか
　　　　 └─┐
背景　　　　 │
　　　　　　 └─...

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

555 ：デフォルトの名無しさん：2008/05/10(土) 00:40:23

上の図は画像ではこんな感じです。

0　 0.33　 0.67　 1　(px)
│
├─────┐
│//////////│←こんな風に黒っぽく
│//////////│
│//////////│　重ねたイメージ
│//////////│
│//////////│
└─────┼──...
　　　　　　 │////
背景　　　　 │...

556 ：デフォルトの名無しさん：2008/05/10(土) 00:48:30

お前それ、もしかしてバイリニアの色漏れ・・・・
αと関係ないだろ・・・・・・・・・・・・・・

557 ：デフォルトの名無しさん：2008/05/10(土) 01:39:34

>>556

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

558 ：デフォルトの名無しさん：2008/05/10(土) 01:53:08

ＧＤＩ描画でちゃんと補完モードはバイリニアになってるか？

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

559 ：デフォルトの名無しさん：2008/05/10(土) 02:10:59

>>558
やってみました。
GDIの補間はバイリニアになってますが、暗くならず、ちゃんと緑になってます。
ただ、自前のバイリニアだと暗くなってます orz

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

560 ：デフォルトの名無しさん：2008/05/10(土) 02:29:44

けっ、どとねと使いか・・・
説明わかりにくいし、状況小出しだし、もうめんどう。
後は自分でがんばりや。

561 ：デフォルトの名無しさん：2008/05/10(土) 03:02:22

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

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

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

562 ：デフォルトの名無しさん：2008/05/10(土) 03:59:36

>>561
補間一つ取っても、どんなアルゴリズムで実装されているのかわからないメソッドなんかがあるから嫌われる。
# なんだよ「『HighQuality』BiCubic」って……

563 ：デフォルトの名無しさん：2008/05/10(土) 11:16:12

>>562
字面通りに捉えれば、BiCubicの高精度版ってだけなんじゃね？
小数点以下の有効桁数の問題なのでは。

564 ：デフォルトの名無しさん：2008/05/10(土) 11:23:07

それにしては違いすぎているから、多分そうじゃない

565 ：デフォルトの名無しさん：2008/05/10(土) 13:11:56

それってﾄﾞﾄﾈﾄじゃなくてGDI+じゃないの？

566 ：デフォルトの名無しさん：2008/05/10(土) 14:41:37

>>565
ﾄﾞﾄﾈﾄのはGDI+のラッパーだからﾄﾞﾄﾈﾄにもあるよ

567 ：デフォルトの名無しさん：2008/05/10(土) 16:38:40

.NET使いのやつには、まず自分の知識不足、理解不足を疑う必要があるのに、WinFormのせいにするような輩が多いからだよ。
まずは自分を疑えと。話しはそれからだ。

568 ：デフォルトの名無しさん：2008/05/10(土) 17:02:31

それはC++でもJavaでもPHPでも同じだと思うけど？

569 ：デフォルトの名無しさん：2008/05/10(土) 19:04:41

>>566
だから>>562は「どとねとってどこ行っても嫌われてるのは何でだろう?」への回答としては不十分だって話だろ

570 ：デフォルトの名無しさん：2008/05/10(土) 21:02:36

VC、VB屋でもDLLだけ欲しがる奴もいるし、
コード張ってくれなきゃ逆切れする奴もいるし、
.net屋だからというのは偏見だと思うな。

571 ：デフォルトの名無しさん：2008/05/10(土) 23:19:53

自分のプライドを守るために卑しむわけです。

572 ：デフォルトの名無しさん：2008/05/11(日) 01:40:54

イラストと写真を判定したいのですが
よい基準ありますか

573 ：デフォルトの名無しさん：2008/05/11(日) 01:47:20

>>567
それ.NET使いに関係なくどの言語・基盤技術上でも底辺プログラマには共通

574 ：デフォルトの名無しさん：2008/05/11(日) 02:48:29

イラストの写真

575 ：デフォルトの名無しさん：2008/05/11(日) 03:21:59

アイドルマスターは実写。

576 ：デフォルトの名無しさん：2008/05/11(日) 05:37:40

>>572
勃起したらイラスト
萎えたら写真

俺の基準

577 ：デフォルトの名無しさん：2008/05/11(日) 06:02:53

>>572
もう釣りにしか見えないけど、自分が絶対断れない立場でこれをやれといわれたら
光の分布をチェックすると思う。方向ならなおよし。

578 ：デフォルトの名無しさん：2008/05/11(日) 07:15:59

>>577
詳しく
写真から3Dモデルを作るくらい難しい？

579 ：デフォルトの名無しさん：2008/05/11(日) 07:57:02

イラストを写真に撮ったのはどうすんの

580 ：デフォルトの名無しさん：2008/05/11(日) 08:22:41

イラストだけならイラスト
額が映っていたり遠近法で歪んで見えると実写だろ
3DCGは？

581 ：デフォルトの名無しさん：2008/05/11(日) 08:50:42

実写に手を加えたものは？

582 ：デフォルトの名無しさん：2008/05/11(日) 09:25:43

属するクラスの選択によって結果が違うだろうな。
両方やって妥当なほうを選択するだろうから
手を加える割合によるんじゃね。

583 ：デフォルトの名無しさん：2008/05/11(日) 10:52:48

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

584 ：デフォルトの名無しさん：2008/05/11(日) 15:56:53

輪郭線

585 ：デフォルトの名無しさん：2008/05/11(日) 17:09:36

>>579
これらのスレを有効活用してくれ
http://set.bbspink.com/test/read.cgi/erocg/1209311236/
http://set.bbspink.com/test/read.cgi/erocg/1154381933/

586 ：デフォルトの名無しさん：2008/05/11(日) 18:03:27

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

587 ：デフォルトの名無しさん：2008/05/11(日) 18:42:55

コンピュータで書かれているイラストなら
色の変化が機械的に整っている。

588 ：M1：2008/05/11(日) 20:50:55

大学院で3次元の画像認識・理解をやろうと思ってるのですが、お奨めの参考書とかありませんか？

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

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

589 ：デフォルトの名無しさん：2008/05/11(日) 21:12:20

コンピュータビジョン (単行本)
David A.Forsyth (著), Jean Ponce (著)

590 ：デフォルトの名無しさん：2008/05/11(日) 21:48:51

>>588
論文嫁

591 ：デフォルトの名無しさん：2008/05/11(日) 21:49:51

2chよりは、論文探してその人にメールした方が確実だな。

592 ：デフォルトの名無しさん：2008/05/12(月) 01:44:46

この分野は進歩が激しいので教科書より論文とかプロシーディングだろうな。

593 ：デフォルトの名無しさん：2008/05/12(月) 08:40:24

>>586
個々の判定方法の出力をうまいことひとつにまとめることが出来るなら、
その出力を利用してどちらかを判定する部分に、学習を行わせるツールを作成するといいよ。
面倒だったら、いくつか初期設定した後、どちらかがはっきりしている
１０００枚くらいの画像を利用して、ＧＡで境界値（または値の分布表）を
収束させると、うまくいくときは楽でいいだろう。ＧＡ部分の作成はたいした手間でもないし。

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

594 ：デフォルトの名無しさん：2008/05/12(月) 08:42:14

>>588
そういう大学で、大学院があるなら、画像研究をやってる研究室があるだろ。
そこにいって相談するのが一番早い。
ないなら、教授のつてで他大学の研究室を紹介して貰え。
縦割りの大学に将来はないぞ。

595 ：デフォルトの名無しさん：2008/05/12(月) 10:34:01

>>594
自宅警備員が偉そうに大学語るなよ（笑）

596 ：デフォルトの名無しさん：2008/05/12(月) 10:48:01

>>588
cinii辺りで検索してみれば？

597 ：デフォルトの名無しさん：2008/05/12(月) 14:05:34

>>593
その程度で難しいって・・・スキル低いやつだなｗｗ

598 ：デフォルトの名無しさん：2008/05/12(月) 14:29:39

>>597
日本語よく読めよ

599 ：デフォルトの名無しさん：2008/05/12(月) 17:43:56

言い訳ｗｗｗ

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

600 ：デフォルトの名無しさん：2008/05/12(月) 18:29:24

>>513
>>519
boost.gil何に使ってます？

601 ：デフォルトの名無しさん：2008/05/12(月) 21:50:24

オカズに使ってます

602 ：M1：2008/05/13(火) 12:28:28

>>589-594
レスthx！やっぱ論文とか他の研究室あたるしかないようだな・・・

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

ﾏﾝﾄﾞｸｻ('A`)

603 ：デフォルトの名無しさん：2008/05/13(火) 18:54:38

ImageMagickで、24bit-BMPを8bit-BMPに変換したいのですが、
どうすればいいか分かる方いらっしゃいましたら教えてくださいm(__)m

604 ：デフォルトの名無しさん：2008/05/13(火) 19:28:50

>>603
http://www.ss.iij4u.or.jp/~somali/web/im_example/quantize.html
こういう感じ？。

605 ：デフォルトの名無しさん：2008/05/13(火) 22:36:38

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

606 ：デフォルトの名無しさん：2008/05/15(木) 10:06:12

スレ違いの謗りを免れないが、教えてください。
jpeg で圧縮後のサイズを指定できるという書き込みを見かけて、最近また
そういうのができるといいと思い出して、やり方を探しているが分からない。
quality 指定の説明しかない。サイズ指定って出来ないですよね。

607 ：デフォルトの名無しさん：2008/05/15(木) 10:56:48

作るとしたら、DCTを済ませておいて
予め用意しておいた複数の量子化テーブルで圧縮試行を繰り返す、みたいな感じになるのかな・・・

608 ：デフォルトの名無しさん：2008/05/15(木) 11:36:45

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

609 ：デフォルトの名無しさん：2008/05/15(木) 14:16:55

QRコード画像を作りたいけど
どう作ればいいか載ってるサイトか本ありますか？

610 ：デフォルトの名無しさん：2008/05/15(木) 14:28:45

はい。

611 ：デフォルトの名無しさん：2008/05/15(木) 14:41:02

【2次元コード】QRコード総合スレ３【バーコード】
http://hobby11.2ch.net/test/read.cgi/phs/1148931749/

612 ：606：2008/05/15(木) 15:35:57

>>607-608
ありがとうございました。

613 ：デフォルトの名無しさん：2008/05/15(木) 15:54:12

>>606-608
ファイルの話で、どうしても指定サイズ丁度にしたいのなら、
圧縮した後、非圧縮部分を付け加えて指定サイズにするのが簡単だ。

614 ：612-606：2008/05/15(木) 23:23:52

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

615 ：デフォルトの名無しさん：2008/05/16(金) 17:20:31

画像データの余白部分を指定した幅にしたいのですが、
どうすれば、できるのでしょうか。
画像データが複数ありバッチ処理できると良いのですが。

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

よろしくお願いします

616 ：デフォルトの名無しさん：2008/05/16(金) 17:28:09

スレ違い

617 ：デフォルトの名無しさん：2008/05/16(金) 18:13:01

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

618 ：デフォルトの名無しさん：2008/05/16(金) 18:17:48

開発環境のスレできけ

619 ：デフォルトの名無しさん：2008/05/16(金) 18:29:15

ImageMagick でいいんじゃね。

620 ：デフォルトの名無しさん：2008/05/16(金) 18:38:15

>>618
スレ違いでしたか、失礼しました。

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

621 ：デフォルトの名無しさん：2008/05/16(金) 18:40:57

ゴミ

622 ：デフォルトの名無しさん：2008/05/16(金) 19:51:55

聞く前にググらないとか有り得ないし100%釣り

623 ：615：2008/05/16(金) 20:52:18

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

624 ：デフォルトの名無しさん：2008/05/16(金) 21:59:20

>>617
Express EditionならGDI+を使えばJPEG、TIFF、BMP、PNGを
読み込むことができる。

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

625 ：デフォルトの名無しさん：2008/05/16(金) 22:57:30

>615
Photoshopでアクション（SelectAll ->領域をshrink->領域反転->削除）を設定し、フォルダごと適用すればいいのでは。

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

626 ：デフォルトの名無しさん：2008/05/16(金) 23:53:42

>>624さん>>625さん、ありがとうございました。

627 ：615：2008/05/17(土) 11:09:43

>>625
レスありがとうございます。
今現在は理解できませんが、勉強いたします。

628 ：デフォルトの名無しさん：2008/05/17(土) 11:38:51

>>625
＞Photoshopでアクション（SelectAll ->領域をshrink->領域反転->削除）を設定し、フォルダごと適用すればいいのでは。
これだとデータを削ることになるジャマイカ。>615の目指すところとは違うと思うぞ。

629 ：デフォルトの名無しさん：2008/05/17(土) 11:57:04

何をしたいのかはっきりしないけど、
Photoshopアクション（カンバスサイズの拡張->上下左右20ピクセル）だと、元画像を削らない。

630 ：デフォルトの名無しさん：2008/05/17(土) 12:05:12

もう一度読むと、何がしたいのかなんとなくわかった。
もともとある程度の白枠があるわけね？
それなら、アクション（位置（０，０）を許容値０で自動選択->削除->カンバスサイズの拡張->上下左右20ピクセル）。

631 ：デフォルトの名無しさん：2008/05/17(土) 13:54:36

板違いもいいとこだ。自分でプログラム書けば簡単だろ。

632 ：デフォルトの名無しさん：2008/05/19(月) 16:22:24

フーリエ記述子から振幅スペクトルと振幅スペクトルの2乗であるパワースペクトルを求めると何の役に立つん？
振幅スペクトルって2次元ベクトルを足して1次元にしてるだけにしか見えないんですがー

633 ：デフォルトの名無しさん：2008/05/19(月) 17:20:11

はじめまして。
すごく初歩的なことをお尋ねします。

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

634 ：デフォルトの名無しさん：2008/05/19(月) 18:23:30

そもそも、RGBカラーのJPEGなんてあったっけ?

635 ：デフォルトの名無しさん：2008/05/19(月) 19:54:25

>>633
とりあえず、そのファイルをうｐしてみろ

636 ：デフォルトの名無しさん：2008/05/19(月) 22:09:40

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

637 ：デフォルトの名無しさん：2008/05/22(木) 19:43:11

>>600
かなり亀レスだけど研究に使ってる

638 ：デフォルトの名無しさん：2008/05/22(木) 21:45:40

>>634
あるよ。規格上は。
現物のファイルでは見たこと無いな

639 ：デフォルトの名無しさん：2008/05/22(木) 23:40:41

epsの入出力に対応して欲しい＞gil

640 ：デフォルトの名無しさん：2008/05/23(金) 06:32:39

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

641 ：640：2008/05/23(金) 07:27:32

>>640 です
EncoderValue.CompressionNone
を指定する所までは行ったのですが、実行すると圧縮されている・・・

642 ：デフォルトの名無しさん：2008/05/23(金) 07:40:14

スレ違い
.NETスレに池

643 ：デフォルトの名無しさん：2008/05/23(金) 07:49:35

無圧縮TIFFくらい自分で書けば?

644 ：デフォルトの名無しさん：2008/05/23(金) 17:18:34

>>643 = NEET

645 ：デフォルトの名無しさん：2008/05/23(金) 18:45:59

>>644
まだコード書けないのか。おまえ何でム板にいるんだ？

646 ：デフォルトの名無しさん：2008/05/23(金) 22:14:52

>>644

647 ：デフォルトの名無しさん：2008/05/23(金) 23:20:15

>>646
>>645

648 ：デフォルトの名無しさん：2008/05/24(土) 01:29:24

>>648

649 ：デフォルトの名無しさん：2008/05/24(土) 06:13:08

また、自分でコード書けないいつものバカが暴れてるのか。

650 ：デフォルトの名無しさん：2008/05/24(土) 10:37:07

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

651 ：デフォルトの名無しさん：2008/05/24(土) 10:48:04

例えば5x5ピクセルを参照して1ピクセルの値を求める場合。
計算上問題がなければ、縦5ピクセルx横1ピクセルの加重平均を横一列分計算して、
次にその結果の横5つを加重平均するようにすれば多少は処理を減らせる。

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

652 ：デフォルトの名無しさん：2008/05/24(土) 11:07:40

>>650
具体的に、0.5秒かかっているときのカーネルの大きさ（or ガウシアンの標準偏差）はどれくらい？

653 ：デフォルトの名無しさん：2008/05/24(土) 11:10:32

GPU使っちゃダメ？10倍以上速くなると思うけど。

654 ：デフォルトの名無しさん：2008/05/24(土) 11:20:24

質問です。
例えば下のような図があったときに、１～１１のそれぞれ領域を、
隣接する他の領域と異なる色で塗り分けるプログラムを作りたいのですが、
各領域の色を決定するアルゴリズムにはどういうものがありますか？

　　　　　〈｀ｰ─-､＿ノ＾j
　　　　　　｀> 　　　　＜＿＿, ─-､＿_＿_
　　　　　／　　　　　　　　j 　　　　　/￣￣￣Tー‐─┬''⌒ヽー-- ､
　　　r' 　　　　　　　　　　/､　　１　　/ 　　　　　|　５　 |　７　|　　　　|９
　　 └---─､　　　　/ 　｀ｰ──/ 　　３　　|　　　　│ 　　| 　　　ｌ |
　　　　　　＼　　　/ 　　　　　　/ 　　　　┌┴─‐─┴┐　/　８　ｌ |
　　　　　　　　　　＼　/　　　２　　/ｰ─ ----l 　　６　　 |‐┤ 　　　ｌ |
　　　　　　　　　　　　Ｖ　　　　　　/ 　　４　└──‐──┘　| 　　　ｌ |
　　　　　　　　　　　　し个､　　　/ 　　　　　　　　　　　　　　　　|　　　ﾊ〈
　　　　　　　　　　　　| 　｀ーl─‐┬─----------──┬─ｲ´￣ヽヽヽ
　　　　　　　　　　　　　　| 　　／ヽ　|　　　　　　　　　　　　　| 　　ﾊ　　〉〉〉
　　　　　　　　　　　| 　/ 　　|　| 　　　　　　　　　| 　/　│　/ 〈ノ
　　　　　　　　　　　　　|　|　　　|　|　　　　　　　　　　　　　|　/　　|　/
　　　　　　　　　　　　　__/　| 　__/ 　|１０　　　　　　　__/ 　| __/ 　|１０
　　　　　　　　　　(＿＿」　ﾞー-‐'　　　　　　　　　　　ﾞー-‐'(＿＿_」　　　　人
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　（＿_）
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　（＿＿）１１

655 ：デフォルトの名無しさん：2008/05/24(土) 11:24:56

宿題は自分で考えましょう

656 ：650：2008/05/24(土) 11:54:39

>>651
とりあえずそうしているのですが、その結果が0.5秒です orz

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

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

657 ：デフォルトの名無しさん：2008/05/24(土) 12:12:57

GPUはCG言語から扱えるのでは

658 ：デフォルトの名無しさん：2008/05/24(土) 12:15:13

CgよかBrookGPUの方がよくね？
いっそCUDAかCAL使うのも手だけど。

659 ：デフォルトの名無しさん：2008/05/24(土) 12:15:32

ageちゃったｽﾏｿ

660 ：デフォルトの名無しさん：2008/05/24(土) 12:29:26

ttp://tpot.jpn.ph/t-pot/program/79_Gauss/index.html
速度比較のお試し程度ならこれで十分じゃない?自分で理解できた方が良いけどさ。

661 ：650：2008/05/24(土) 12:49:23

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

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

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

662 ：デフォルトの名無しさん：2008/05/24(土) 13:07:29

単に広範囲をぼかすだけなら小さめのガウスぼかしを複数回かける手もある。
クォリティ下げていいなら移動平均にすれば大きくぼかしても負荷ほとんど増えないが。

663 ：デフォルトの名無しさん：2008/05/24(土) 13:18:35

広範囲で極端な精度を求めないならパスカルの三角形を繰り返してやれば
擬似ガウシアンだよな。

664 ：デフォルトの名無しさん：2008/05/24(土) 13:21:08

そのくらい単純な処理の場合、計算量を減らすよりも
キャッシュのヒット率を考えた方が速くなると思うよ。

665 ：デフォルトの名無しさん：2008/05/24(土) 13:24:31

OpenCVのガウスぼかしはCPUにしてはわりと速いと思う

666 ：650：2008/05/24(土) 17:51:01

遅くなってすいません。

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

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

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

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

667 ：デフォルトの名無しさん：2008/05/24(土) 18:27:49

ぼかしは、計算時間かかるから、0.5秒なら妥当だと思うけど。
ちなみに、ガウシアンカーネルをコンボリューションしているの？FFTしてから掛け算しているの？
一般的に、前者は遅い。

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

668 ：650：2008/05/24(土) 19:13:06

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

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

669 ：デフォルトの名無しさん：2008/05/24(土) 19:44:02

>>668
その方法ではせいぜいO(n^2)までしか行かない
縦横別々にFFTを使うほうが効率がいい

670 ：650：2008/05/24(土) 20:23:25

>>669
マジっすか orz
手元にFFTの乗った教科書があるのでちょっと見てみます。

…2^nのみじゃないといいなw

671 ：デフォルトの名無しさん：2008/05/24(土) 20:26:42

教科書みるよりOpenCVのソース見たほうが速くない?
用途にもよるけどAvisynthのフィルタもいろいろな処理のソースあるよGPLだけど。

672 ：デフォルトの名無しさん：2008/05/24(土) 20:34:06

FFTはFFTWを使うとして、係数を事前計算しておけばガウス暈しは(周波数空間像の)画素ごとに係数を掛けるだけなんだっけ?

673 ：デフォルトの名無しさん：2008/05/24(土) 20:34:19

畳み込みの勉強をすればいいかも

674 ：デフォルトの名無しさん：2008/05/24(土) 20:58:54

ちょこっと書いてみた所
Window Sizeは5×5
Pentium-4 2.4GHzで640×480、24ビットカラーで70ms
同8ビットグレイスケールで20ms
コンパイラはVS.net 2003 ProのC++でSSEもアセンブラもなし最適化は/G6
実数演算しているので整数演算にすればもう少し速くなると思う。

このくらいの速度はでるという参考にでも。

675 ：デフォルトの名無しさん：2008/05/24(土) 21:05:34

>>650の実行環境すら分からない状態で、0.5秒が遅いという本人の印象だけで
実装アルゴリズムもソースも、言語すら書かれていないというのに、
どうしてこんなに速いだの遅いだの言う話が進むのか。みな超能力者なのか。

とおもたよ。

676 ：デフォルトの名無しさん：2008/05/24(土) 21:07:59

理論的な早さは実行環境によらず語れるじょん？

677 ：デフォルトの名無しさん：2008/05/24(土) 21:17:20

>>675
「遅い」と言われたら、だいたい原因の想像がつくからだよ

678 ：デフォルトの名無しさん：2008/05/24(土) 21:29:29

>>676
速さ、な。
650が現状どの程度計算量を減らす手段をとったのか正しくわからない状態では、
適切な助言はできないだろ。もしかしたら、環境が遅いだけで650は最速に近い
アルゴリズムを実装しているのかもしれないぞ。
いずれにしても、ワークを直接ポインタで操作しているという前提で、汎的な工夫なら、

1.640x480なら、650x490のワークを利用することで境界判定をなくして
2.１次元化して座標からのアドレス計算を減らして
3.平均化も縦横個別に１次元化して(>>651)
4.必要な精度にもよるが適当でいいなら固定小数点化して整数演算に帰着させる

くらいしかないんじゃないかな。

679 ：650：2008/05/24(土) 21:40:10

FFTのソースやら説明を読んでたら頭が爆発しそうになりました。
ろくに数学をやってないのに手を出すべきじゃなかったかもしれません orz

>>674
(ﾟДﾟ)

>>675
ソースが糞だからだと思います。
しかし、自分も糞なので糞が直しても糞にしかなりません。

>>678
現在は2と3をやってます。
1はコピーに時間がかかりそうですが、コピーはしないのでしょうか?

680 ：デフォルトの名無しさん：2008/05/24(土) 23:58:56

FFTは別に理解していなくても、使えればいいよ。
（気持ちに余裕があるときクーリ＆ターキの大発明を理解したらいい。元はガウスだっけ？）

FFTは特にFFTWくらい高速なものになると理解困難。
サイズによってアルゴリズム変化するらしい。
使い方もちょっと特殊。

ま、何も考えずに使いたければ、OpenCVにIPL組み込むことだ。ボカシ命令実行するだけで、すべてやってくれる。

681 ：デフォルトの名無しさん：2008/05/25(日) 01:12:20

8bit インデックスカラー画像を、さらに可逆圧縮する方法は無いでしょうか？
汎用的な圧縮アルゴリズム以外で。

682 ：デフォルトの名無しさん：2008/05/25(日) 01:21:48

誰かエスパーいたら、相手にしてやれよ

683 ：デフォルトの名無しさん：2008/05/25(日) 03:08:35

>>681
自分で考えれば良いんじゃない？
これだけじゃ、これぐらいしか回答できない

PNGにデータを保存すれば良いんじゃない？
可逆圧縮だし、8bitデータも扱えるし

何も意識せず、保存したいならGDI+で良いと思うよ
アルゴリズムも気にする必要もない

684 ：デフォルトの名無しさん：2008/05/25(日) 08:17:15

>>681
BMPで画像サイズが小さいなら、24ビットにした方が小さくなる。

685 ：デフォルトの名無しさん：2008/05/27(火) 09:41:00

お勧めのTIFFからJPEGに変換ツール教えてください。
JavaServletから使いたいです。

686 ：デフォルトの名無しさん：2008/05/27(火) 11:39:52

ImageMagick
Serveletから使えるかはしらね。

687 ：デフォルトの名無しさん：2008/05/27(火) 13:18:56

>>686
いいですね！

688 ：デフォルトの名無しさん：2008/05/28(水) 10:11:21

おまいら、YYフィルタってどうよ？

689 ：デフォルトの名無しさん：2008/05/29(木) 19:00:05

アホクサ20年前のレベルやん

690 ：デフォルトの名無しさん：2008/05/29(木) 23:44:57

>685

普通に、SDKのクラス使えばできる。
java　画像変換でぐぐれ！

691 ：デフォルトの名無しさん：2008/06/01(日) 02:28:32

shape context ってわかる人いますか？
http://en.wikipedia.org/wiki/Shape_context

概念はわかったけど、このshape context histogramがどう作られてるのか
さぱーりわかりません。
Step 2: Computing the shape context
のところ。

692 ：デフォルトの名無しさん：2008/06/01(日) 16:47:50

vine4.2でImageJをインストールしているんですが、
□□□など文字化けが起こるのですがいい解決方法がありませんか？

693 ：デフォルトの名無しさん：2008/06/01(日) 19:15:22

フォント指定してないからだろ

694 ：デフォルトの名無しさん：2008/06/01(日) 20:35:15

それは一般に豆腐と呼ばれる現象なのでググるとなんかわかるかもね

695 ：デフォルトの名無しさん：2008/06/02(月) 21:01:37

>>691
まるかいてー、角度でわけてー、半径でわけてー、
その半径のわけかたはー、log っぽくてー、
で、点の数をかぞえるー

696 ：デフォルトの名無しさん：2008/06/03(火) 00:46:49

百戦錬磨の職人の皆様、教えてください。

アドビのフォトショップにあるフィルタ...変形...渦巻きと同じことをやりたいです。
画像端部はそのままで中心部のみをネジる感じです。

http://charaku.maxs.jp/PHHENKEI/mihon.html

しかしマッピング曲線がよくわかりません。
http://ja.wikipedia.org/wiki/%E4%BB%A3%E6%95%B0%E8%9E%BA%E6%97%8B#.E3.83.AA.E3.83.81.E3.83.A5.E3.83.BC.E3.82.B9
にある「リチュース」というのを使うのでしょうか？

697 ：デフォルトの名無しさん：2008/06/03(火) 01:12:48

>>696
中心からの距離に比例して回転角度が変わるだけ。

698 ：デフォルトの名無しさん：2008/06/03(火) 01:19:26

マッピング「曲線」とか言ってる時点で根本的な部分で勘違いしている気がする。

699 ：デフォルトの名無しさん：2008/06/03(火) 08:43:47

画像輪郭抽出アルゴリズムの話なんだけど
微分値を拾う方法以外の方法で何か有名な方法ってありますか
有用な方法で思い当たる方法もあったら教えてください

700 ：デフォルトの名無しさん：2008/06/03(火) 09:24:31

領域分割してラベリング後に境界をとったら？
やりかたはたくさんある。

701 ：デフォルトの名無しさん：2008/06/03(火) 10:51:20

>>699
微分にもいろいろあるだろうけど、
ほかにも、ぼかし＋HPFとか、ウェーブレットでHH成分を拾うとか、色相変化をチェックするとか、

702 ：デフォルトの名無しさん：2008/06/03(火) 13:02:43

レベルセットの簡単なtutorialどこかにないですか？

703 ：デフォルトの名無しさん：2008/06/03(火) 13:40:36

そういえば
先日サイエンスに視覚神経がポジ画像ネガ画像を同時に送ってるってのがあったな
あといくつかの他のいわゆるレイヤーを同時に脳に送りつけてるって
この方式は輪郭抽出や画像認識で既に使われてるのかな

704 ：696：2008/06/04(水) 00:25:16

>>697 さん
いや、それがですね、中心距離への比例だと思ってやってたんですよ。
周辺から中心にいくにしたがって回転角をまわしてやるようにつくっても、
フォトショップのような自然な渦巻きにならないのです。

>>698 さん、あえて「曲線」と言わせていただきますが、
再マッピングに曲線式をあてはめると、なんらかの減衰項があるような感じなのです。

昨日からずっと調べてたのですが、クロソイド曲線をつかうのかなぁ？

705 ：デフォルトの名無しさん：2008/06/04(水) 00:36:14

じゃあ２乗とかちょっと微調整やるってかんじじゃないのかな。
自然ってのは自分が思うまで微調整やるしか

706 ：698：2008/06/04(水) 01:08:30

>>704
Photoshopが何をやっているかは、
↓のような画像を渦巻き変形してさらに「極座標を直交座標に」の変換をすれば一目瞭然。
┌───┰───┐
│　　　 ┃　　　 │
│　　　 ┃　　　 │
│　　　 ┃　　　 │
│　　　　　　　 │
│　　　　　　　 │
│　　　　　　　 │
└───────┘
回転角度が中心に向かって単純に比例ではなく、
1 - sin(πx/2) に比例していることがわかる（0≦x≦1 は中心からの距離）。
つまり中央付近ではほぼ等速変化だけど、周縁では無変換領域と滑らかにつながるようになっている。
リチュースやクロソイドでは中心付近で回転が加速していくので描画効果としては使い物にならない。

707 ：デフォルトの名無しさん：2008/06/04(水) 09:09:53

もし704が問題なんだったら対数螺旋のような動きにしてみたら如何かな

708 ：デフォルトの名無しさん：2008/06/04(水) 13:41:23

単なる係数と補間精度だけの問題のようなきがする。

709 ：名無し募集中。。。：2008/06/04(水) 18:49:03

>>707
対数螺旋も中央付近で加速していくからフォトショップのようにはならないよ。
696氏はフォトショップの渦巻きフィルタの再現をしたいんでしょ？
フォトショップは中央は一様螺旋で周囲だけ緩和がかかるから>>706が正しい。

710 ：デフォルトの名無しさん：2008/06/04(水) 18:59:38

妥協すれば全て解決。100%コピー目指すなら逆アセしろ。

711 ：デフォルトの名無しさん：2008/06/05(木) 15:10:37

いろんな言語使ってる人いるみたいだけどrubyな人はいないみたいだね

712 ：デフォルトの名無しさん：2008/06/05(木) 16:31:59

エスパー乙

713 ：デフォルトの名無しさん：2008/06/06(金) 00:39:11

>>771
画像処理をしだしてからCばっかりでPerlとかは使わなくなった。
画像解析自体をスクリプト言語でやったりするんやろか

714 ：デフォルトの名無しさん：2008/06/06(金) 00:55:17

多段のフィルタを組み合わせたりするのにLL使うのはいいだろうけど、
画像処理自体に使うのはちょっと‥‥ねぇ

715 ：デフォルトの名無しさん：2008/06/06(金) 01:08:41

exe を走らせるスクリプトとかなら (*´･ω･)(･ω･｀*)ﾈｰ

716 ：デフォルトの名無しさん：2008/06/06(金) 08:55:57

pythonはPILあるけどrubyはそれに相当するものないから使われないってことなのか

717 ：デフォルトの名無しさん：2008/06/06(金) 09:09:15

スクリプト言語は文字列処理が得意なのであって、
画像処理、行列処理、をさせようと思ったら特に意味がない。

718 ：デフォルトの名無しさん：2008/06/06(金) 14:10:18

文字列は配列を切って貼ってする必要があるけど、画像処理はとってきた特徴量を
放り込んでおくだけってイメージ

719 ：デフォルトの名無しさん：2008/06/06(金) 14:21:27

ハァ？

720 ：デフォルトの名無しさん：2008/06/06(金) 16:08:10

>>695
分ける前の半径ってどうやって決めてるん？
曲座標変換が関係してるんかな？

721 ：デフォルトの名無しさん：2008/06/06(金) 17:43:54

あー、半径は自分で適当に設定するのか

722 ：696：2008/06/15(日) 10:37:03

>>697さん、>>698さん、>>705さん、>>707さん、>>708さん、>>710さん
「渦まき」できました！ありがとうございました。

723 ：デフォルトの名無しさん：2008/06/15(日) 10:45:13

どういたしまして

724 ：デフォルトの名無しさん：2008/06/19(木) 02:14:13

MPEG-7のデータセットをgoogleで探していたら
IEEEのサイトに飛ばされることが多いのですが、アカウントをとらないといけないのですか？

725 ：デフォルトの名無しさん：2008/06/19(木) 02:28:34

あ、これかな・・・
http://www.m4if.org/resources.php#section40

726 ：デフォルトの名無しさん：2008/06/22(日) 17:47:13

H.264の実装説明した奴ないですかね？

727 ：デフォルトの名無しさん：2008/06/25(水) 12:06:43

x264のソースを落とした上でmarumoんとこでも読んで来い

728 ：デフォルトの名無しさん：2008/06/26(木) 21:12:02

画像センサや画像処理装置のスレって無い？

729 ：デフォルトの名無しさん：2008/06/26(木) 22:03:13

ハードは板違い

730 ：デフォルトの名無しさん：2008/07/02(水) 12:21:59

>>728
俺も探してるんだが無いね。
できたらCognexのVisionProとかﾘﾝｸｽのHalconだとかの情報も欲しいんだが・・

731 ：デフォルトの名無しさん：2008/07/02(水) 23:52:26

ImageMagick使ってPostScriptの回転・マルチページ化したいんだけどラスターデータみたいなガタガタの画になってしまう…
所詮こんなもんって事？

最終的にはPDFファイルにしたいんだがいきなり頓挫気味です。

732 ：デフォルトの名無しさん：2008/07/03(木) 09:13:39

displayだのconvertだのimportだの無遠慮に使い潰すこのゴミが

733 ：デフォルトの名無しさん：2008/07/04(金) 01:15:23

画像認識で自転車を認識したいのですが、どのように認識させていいのかわかり
ません。
今は自転車の簡単な特徴点をテンプレートととして用意してその点を認識させよ
うとしているのですが
なかなか認識させることができません。（テンプレートは自転車の車輪を想定し
て円状に点を６点取っています。

うまく自転車を認識させる方法がありましたら教えてください。

734 ：デフォルトの名無しさん：2008/07/04(金) 02:05:46

>>733
ハフ変換で円を検出してみるとか

735 ：デフォルトの名無しさん：2008/07/04(金) 04:23:03

横よりも縦から見ること多そうなので、丸で判別するのは難しそう。

結構面倒と思う

736 ：デフォルトの名無しさん：2008/07/04(金) 14:05:40

>>733
認識？検出？認識でいいんだよね？
顔認識とかと同じようなかんじで（ある意味での）情報圧縮を
使って特徴量を得てみたら違いがでるのではなかろうか。
主成分分析 (PCA)とか、線形判別分析 (LDA) とか。
で、識別器はパターン認識のなにかの手法、とりあえず k-nn でもいいし、SVM でもいいし使ってみたらそこそこ動いちゃったりしないだろうか。
ここで書いているのはパターン認識でとりあえず習う当たり前の手法なので、
コードとかもごろごろころがってると思うよ。

737 ：デフォルトの名無しさん：2008/07/04(金) 19:39:11

画像処理技術者の将来は明るいでしょうか？

738 ：デフォルトの名無しさん：2008/07/04(金) 21:29:25

将来タクシーの運ちゃんになりたいなら画像処理やればいいよ。

739 ：デフォルトの名無しさん：2008/07/05(土) 13:02:06

ttp://www.mit.edu/~andoni/LSH/
これってさE2LSH package使いたいならメールしろって書いてあるの？

740 ：デフォルトの名無しさん：2008/07/05(土) 13:17:24

>>739
そうだけど、誰かに確認を手伝ってもらわないとだめですか、そうですか。

741 ：デフォルトの名無しさん：2008/07/05(土) 13:22:38

thanx!

742 ：デフォルトの名無しさん：2008/07/05(土) 13:24:46

メールってどうやって送ったらいいの？

743 ：デフォルトの名無しさん：2008/07/05(土) 13:35:32

そうか、読めもしないんだからそうなるわな。
でも、コードももらってもマニュアルも読めないし、
論文読んで中身が何をしているのかもわからないし、
使いこなせないんじゃない？

744 ：デフォルトの名無しさん：2008/07/06(日) 21:40:38

インターレースとプログレッシブのJpegを見分けるにはどうすればいいでしょうか。

745 ：デフォルトの名無しさん：2008/07/06(日) 21:53:40

画像ロードの瞬間、目をこらしてよくみろ

746 ：デフォルトの名無しさん：2008/07/07(月) 06:05:38

RGB以外の、CMYKやYUVなどのカラースペースのまま
ブラーや半透明合成を行うアルゴリズムの情報源を教えてください！

747 ：デフォルトの名無しさん：2008/07/07(月) 08:04:54

RGBのときのそれらのアルゴリズムが線形演算でできていて
RGBとCMYK、YUVの変換が線形に行えるなら
全体で線形性が保てているからアルゴリズムを線形変換するだけだよね。
(まあ結局RGBに戻して合成してることと理論上は同じにはなるけど)
と思ったけどRGBとCMYKは線形じゃないのが多いだろうな。

748 ：741：2008/07/07(月) 17:38:07

>>743

>>742は自分ではないです。

749 ：デフォルトの名無しさん：2008/07/08(火) 20:52:04

複数のjpg画像から動画を作るためのライブラリとかないでしょうか。
コマンドラインで実行する系で。

750 ：デフォルトの名無しさん：2008/07/08(火) 21:12:05

ffmpeg

751 ：デフォルトの名無しさん：2008/07/12(土) 03:09:15

誘導されてきました。マルチになりますが、アドバイスのほどよろしくお願いします。
現在テンプレートマッチングのプログラムを作っているのですが、
テンプレートマッチングでマッチングした部分の色を変えられず苦労しています。。
画像のある特定の範囲だけの色を変えるのってどうすればいいのでしょうか？

752 ：デフォルトの名無しさん：2008/07/12(土) 03:19:37

エスパーの登場を待つか詳細を書くかしましょうね。

753 ：751：2008/07/12(土) 03:46:45

かなりつたないプログラムですが、途中まで書いてみます。
超初心者なので、根本から間違っているかもしれません。
テンプレートの左下と一致する1ドットだけ色変換が行われるので、マッチング自体はできてると思うのですが…

int i,j,k,l,nx,ny,tmpnx,tmpny;
nx=bmpInfoHeader.biWidth;//元画像の幅
ny=bmpInfoHeader.biHeight;//元画像の高さ
tmpnx=bmpTmpInfoHeader.biWidth;//テンプレートの幅
tmpny=bmpTmpInfoHeader.biHeight;//テンプレートの高さ
//相違度の計算（gray[]はグレースケール化した元画像の一次元配列、tmpgrayはグレースケール化したテンプレート画像の一次元配列）
for(i=0;i<ny;i++){
　　for(j=0;j<nx;j++){
　　　　for(k=0;k<tmpny-1;k++){
　　　　　　for(l=0;l<tmpnx-1;l++){
　　　　　　　　d[i][j]=d[i][j]+(gray[i+k][j+l]-tmpgray[k][l])*(gray[i+k][j+l]-tmpgray[k][l]);
}
　　　　　}
　　　}
　}

754 ：デフォルトの名無しさん：2008/07/12(土) 03:47:43

//テンプレートとマッチしたところ（相違度=0.0）の色を変換。image1は出力先の一次元配列。
for(i=0;i<ny;i++){
　　for(j=0;j<nx;j++){
　　　　if(d[i][j]==0.0){
for(k=i;k<tmpny;k++){
　　for(l=j;l<tmpnx;l++){
image1[3*(k*nx+l)]=255;
　　　　　image1[3*(k*nx+l)+1]=image1[3*(k*nx+l)+2]=gray[k][l];
}
　　　}
　　　　　}else{
image1[3*(i*nx+j)]=image1[3*(i*nx+j)+1]=image1[3*(i*nx+j)+2]=gray[i][j];
}
　　　　}
}
}

755 ：デフォルトの名無しさん：2008/07/12(土) 05:39:28

「画像処理」の範疇とちょっと違うかもしれないけど質問です。

1つの凸多角形（頂点数4か5）と長方形が1つあり、
それらが部分的に重なるものとします。
このとき、重なった部分を表現する多角形の頂点を取り出すような、
何か一般的なアルゴリズムがあれば紹介して頂けないでしょうか。

756 ：755：2008/07/12(土) 05:46:26

図形はビットマップではなくベクタとして処理されるため、
(x, y)を逐一調べて、両方の図形に含まれるかを調べる、
というような方法ではないものを探しています。

757 ：デフォルトの名無しさん：2008/07/12(土) 05:51:13

分野的には計算幾何学だな。
計算幾何学のスレは2chでは全く流行らないから、多分今は無いが。

っていうか、それは普通に交差判定するしかないと思うけど。
魔法のように計算式1つで求まるわけないだろう。

758 ：755：2008/07/12(土) 06:12:47

あ、分かった。
1. 図形AとBの交差点を全て取り出す
2. Aに含まれるBの頂点を取り出す
3. Bに含まれるAの頂点を取り出す

1. + 2. + 3. = 取得すべき全頂点

759 ：デフォルトの名無しさん：2008/07/12(土) 10:45:25

>>755
辺が重なるときの例外処理が大変そう

760 ：デフォルトの名無しさん：2008/07/14(月) 10:15:10

http://geometryalgorithms.com/Archive/algorithm_0108/algorithm_0108.htm

761 ：デフォルトの名無しさん：2008/07/14(月) 13:08:05

>>755
maximaあたりで簡単にできそうだけどな

762 ：デフォルトの名無しさん：2008/07/14(月) 15:15:14

2つの3次元の線図形の類似性ってどうやって調べればいいのだろう
統計的な手法(平均や分散など)を使用できるのかな・・・

763 ：デフォルトの名無しさん：2008/07/14(月) 15:46:17

>>762
単純な形に分割して比較するとか、でっぱったところから特徴抽出するとか。
「3D similarity」でググると論文がでてくる。

764 ：デフォルトの名無しさん：2008/07/14(月) 15:48:42

>>763
なるほど
どうもです

765 ：デフォルトの名無しさん：2008/07/27(日) 20:23:54

単純に画素の算術平均取りたいけど
_mm_sub_epi32()使うと以上に遅い

うーーむ困ったのだ

766 ：デフォルトの名無しさん：2008/07/27(日) 21:16:42

>>765
何以上に遅いの?
そもそも_mm_sub_epi32()ってなに?

767 ：デフォルトの名無しさん：2008/07/27(日) 23:38:57

>>766
SSE2のPSUBDの、インテルC++コンパイラ風の記述かな？

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

インテルのコンパイラは勿論、
VC++やGCCでも使える組み込み関数だし、
割と一般的なんじゃね？

769 ：デフォルトの名無しさん：2008/07/28(月) 11:45:39

>>766
ググレカス

770 ：デフォルトの名無しさん：2008/07/28(月) 12:20:34

SSEネタとかは専門スレに逝くってのはどうだ？

771 ：デフォルトの名無しさん：2008/07/28(月) 12:45:27

だからそれが、画像処理と何の関係が?
一部のCPUに特化した最適化の話なら、そのCPUかそれ用のコンパイラのスレにでも行けばいいじゃん。

772 ：デフォルトの名無しさん：2008/07/28(月) 13:00:19

ここでいいよ

773 ：名無し募集中。。。：2008/07/28(月) 19:31:32

IPP買えばいいんじゃないかなっ

774 ：デフォルトの名無しさん：2008/07/28(月) 19:58:33

>>765
SSE2はsetとloadが遅いけど、本当に引き算が遅い?

775 ：デフォルトの名無しさん：2008/07/28(月) 23:23:55

>>774
VTune大先生がそのように指摘します
先生が間違うはずがありません。
高い値段するのに間違いを指摘するなんてありえません。

776 ：デフォルトの名無しさん：2008/07/29(火) 00:48:56

>>775
一命令単位でパフォーマンス見れるの？
ループしてんじゃないの？
画素の算術平均って具体的に何？
ある矩形内の平均？
平均に引き算ってどんな計算してるの？

777 ：デフォルトの名無しさん：2008/07/29(火) 01:11:41

>>776
775じゃないけど、平均で行う引き算と言えばこれじゃないかな。

ABCD
EFGH
IJKL

例えば上の矩形でFの画素を周囲の画素との平均値にする場合、
A+B+C+E+F+G+I+J+K (=X)って加算するでしょ。（で、割る。）
このXを保存しておけば隣のGの画素についてはB+C+D+F+G+H+J+K+Lって加算するより
X-(A+E+I)+D+H+Lという風にXを元に減算・加算したほうが計算が少なくなる。

778 ：デフォルトの名無しさん：2008/07/29(火) 11:15:59

>>776
vtuneは一命令単位の所要時間を見ることができるよ。
但し、パイプラインの制約だかなんだかで実際のアクセスが遅延している場合は
問題の(時間の掛かる)命令ではなく次の命令辺りで待ち時間が計上されることがある。

要は、>765はロード命令の次の引き算命令だけを見て遅いと言っていると思われる。
つまり、真に遅い原因はロードに起因するメモリアクセスってこと。

まぁ、vtune買うならIntelの講習も受けておけってこった。

779 ：デフォルトの名無しさん：2008/07/29(火) 19:22:38

SSE2でやるなら画素を16bitにして
ABCDEFGHI
JKLMNOPQR
STUVWXYZ0
を
a=load(ABCDEFGHI)
b=load(JKLMNOPQR)
c=load(STUVWXYZ0)
a+=b
a+=c
store(a, m);
として、m[]を計算するとか
アライメントされた連続したメモリブロックを一度に読んで計算しないとパフォーマンスでない。

780 ：デフォルトの名無しさん：2008/07/29(火) 23:56:30

>>779
SSE2でstoreってどれつかえばいいの？

781 ：デフォルトの名無しさん：2008/07/30(水) 02:04:15

>>780
_mm_store_*で、*部分はデータ型による

782 ：デフォルトの名無しさん：2008/07/30(水) 02:05:32

整数なら_mm_store_si128

783 ：デフォルトの名無しさん：2008/07/31(木) 03:54:03

画像をキレイにする方法を色々調べて、逆フィルタ、ウィナーフィルタというのに
辿り着きました・・・。
人間が目を凝らすときにもこういう処理をしているのかもしれないですね。

784 ：デフォルトの名無しさん：2008/07/31(木) 06:08:22

いいえ。

785 ：デフォルトの名無しさん：2008/07/31(木) 23:31:50

画像処理でSSE2つかっても遅くね？
あとさ

なんでSSE2って8bit単位でシフト演算できないんだ？
16と32はあるのに

786 ：デフォルトの名無しさん：2008/08/01(金) 21:13:04

32bitCPUのレジスタは、16bitと32bitだからじゃない？
ローレベルになるほど、ニーモニックに合わせてやらないといけない。

そういえば、Windowsも16bitを切り捨てたとき、動かなくなるソフト結構あったみたい。
64bitWindowsが主流になれば、そのうち32bitも切り捨てられるだろうし。

787 ：デフォルトの名無しさん：2008/08/01(金) 21:45:06

そうならないために.Netが作られたんだろ？

788 ：デフォルトの名無しさん：2008/08/01(金) 22:27:27

>>786
OSそのものが仮想マシンの上で動作しようかという時代に何を言ってるんだ。
でもスレ違いだから、そろそろやめような。

789 ：デフォルトの名無しさん：2008/08/02(土) 08:21:20

ゲームマシンはそのうち１２８ビットになるって１０年以上前に聞いたけど
なんでビット数は大きい方がいいの？　もうなったの？
パチンコ台も画像が増えたけど、あれは何ビット機使っている？

790 ：デフォルトの名無しさん：2008/08/02(土) 08:43:44

そりゃ一度に処理できる情報量が大きくなるからだろ.
PCの場合は,互換性とか対応アプリケーションとかの問題で64bit化さえなかなか進まないが.

791 ：デフォルトの名無しさん：2008/08/02(土) 08:44:14

ビット数というのが、CPUの演算精度の事言ってるのか、バス幅のこと言っているのか…

ＰＣのＧＰＵなんかは、384～512ぐらいのバス幅を持っている。
これをもってきて、512bitマシンと呼ぶのか？

rambusのDRAM-IF使ったらバス幅狭いので、ビット数が落ちるのか？
（データ転送能力はむしろ高いぐらいなのだが）

792 ：デフォルトの名無しさん：2008/08/02(土) 08:56:07

特に指定しない場合は明らかに前者を指すだろ

793 ：デフォルトの名無しさん：2008/08/02(土) 09:15:14

そんなもん、128ビットもあったって屁の足しにもなりゃしねぇ

794 ：デフォルトの名無しさん：2008/08/02(土) 10:08:42

128ビットは今のところ要らないけど、64ビットは有難いよ。
データ幅が64ビットなんじゃなくて、アドレス空間が64ビットあることが重要。
巨大な画像処理とか超楽。もう32ビットプログラミングとかやりたくない。

795 ：デフォルトの名無しさん：2008/08/02(土) 13:32:29

最近、ゲートのコストが落ちてきてな。
8bitの乗算とかなら平気で500個ぐらいチップに入りそうな勢い。(最新ならね)

周辺回路等も入るから、そのまま実装できるわけでもないのだが、
バス幅多ければその分パラに処理して演算能力を高めることが可能…

ここまできちゃうと、プログラムとかの世界ではないが。

796 ：デフォルトの名無しさん：2008/08/03(日) 22:35:46

>>794
それって、一枚の巨大な画像なのですか？
それとも一枚は普通の大きさだけど、連続した長～いストリームなのですか？

797 ：デフォルトの名無しさん：2008/08/04(月) 09:26:02

動画じゃね

798 ：デフォルトの名無しさん：2008/08/04(月) 09:35:12

1画素0.1um四方で100mm*0.1mmの画像を16ビット諧調で作ったらそれだけで2GBになっちゃうからねぇ。
広いメモリ空間はあるに越したことないね。

799 ：デフォルトの名無しさん：2008/08/04(月) 22:19:20

2GBなんてたいしたことねーじゃん
4GBのメモリ1万で買える時代に

800 ：デフォルトの名無しさん：2008/08/04(月) 22:51:21

>>799
そーゆー問題じゃない。
アドレス空間が足りないんだっつってんだろが。
安いPCでも8GBや16GBくらい簡単につめる時代だからこそ問題になってるんだよ。

801 ：デフォルトの名無しさん：2008/08/04(月) 22:57:55

>>800
64bitOSで足りんの？
2GBって64bitOSで足りんわけねーだろがボケ
海水浴場でドザエモンになって二度と
地上に戻ってくるなボケ

802 ：デフォルトの名無しさん：2008/08/04(月) 23:10:59

分野によっては64 bit OSが必須というのは厳しいのかもね

803 ：デフォルトの名無しさん：2008/08/04(月) 23:14:31

>>798
なんというアスペクト比、すげー!!!

804 ：デフォルトの名無しさん：2008/08/04(月) 23:20:31

>>803
短冊形に処理するんですよ。まさか、0.1umの画素で100mm平方なんて扱えませんから。

805 ：デフォルトの名無しさん：2008/08/04(月) 23:37:05

>>801
おまいはメモリ量とアドレス空間の違いが分からんのか・・・。
・・・残念だが俺は親切な人じゃないんで、もうこれ以上は付き合えないよ。
一人で空回りしててください。

806 ：デフォルトの名無しさん：2008/08/04(月) 23:47:20

>>805は64bitOSならメモリ空間十分だろって言ってるんじゃね？
まあ64bitOSとかいいつつAMD64あたりはアドレス48bitで1TBとかだった気がするが。

807 ：デフォルトの名無しさん：2008/08/04(月) 23:50:25

>>805
お前の方が付き合いきれないだろ
仮に4GBx16あったとして64bitOSで何が不足する？
2GBのデータかメモリかしらんが扱おうとして
何が不足する言ってみろなぁ言ってみろ？

808 ：デフォルトの名無しさん：2008/08/05(火) 00:00:25

801(=807?)は酔っ払いなの??
794以降の話の流れが読めてなくない??

809 ：デフォルトの名無しさん：2008/08/05(火) 00:11:44

32bitでは足りない
128bitは今のところオーバースペック
64bitﾏﾝｾｰ

という流れでおｋ？

810 ：デフォルトの名無しさん：2008/08/05(火) 04:23:55

>>801の読解力のなさに噴いた。
さすが801は違うと思った。

811 ：デフォルトの名無しさん：2008/08/07(木) 15:09:40

>801
ttp://128bit.blog41.fc2.com/blog-entry-32.html

812 ：デフォルトの名無しさん：2008/08/07(木) 22:16:34

>>811
いや、801の場合はそういう知識以前の問題だな。
誰一人として64ビットOSでは足りないなんて話してないのに、
いきなり出てきて一体どこに向かって噛み付こうとしてるのか言ってみろなぁ言ってみろ？
って感じだ。

813 ：デフォルトの名無しさん：2008/08/08(金) 21:42:57

FMスクリーンのアルゴリズム
どっかに転がってないでしょか

814 ：デフォルトの名無しさん：2008/08/11(月) 16:59:16

実用的な日本語ＯＣＲソフトの情報はどこかにないでしょうか？
特に枠なしの手書き数字を認識したいのです

815 ：デフォルトの名無しさん：2008/08/11(月) 18:49:20

ソフト板で聞けよ・・・

816 ：デフォルトの名無しさん：2008/08/11(月) 23:09:57

>>814 のような質問をいつも不思議に思うな。

「手書き数字*認識」（* のところは space）でぐぐると一杯出てくる。

817 ：デフォルトの名無しさん：2008/08/19(火) 09:37:27

画像ファイルを連続で切り取り、を支援するソフトウェアってある？
矩形選択、ショートカットキー１つで、ぽんと保存（オリジナルファイル名+α)、
ショートカットキー１つで、次の画像にすぐ移れる。みたいな。

818 ：デフォルトの名無しさん：2008/08/19(火) 10:04:46

>>817
ググる能力ないなら作れ。ここはそういう場所。

819 ：デフォルトの名無しさん：2008/08/19(火) 10:36:12

>>818
ぐぐってみればわかるけど、汎用画像処理ソフトしか出てこないんだよね。
切り取りに特化していない。
絶対だれか研究用に作ってるとは思うんだけど。

820 ：名無し募集中。。。：2008/08/19(火) 10:44:12

目的は違うけど似たようなものは作った事があるから「ある」

>ぐぐってみればわかるけど
突っ込みどころ満載だな
2chなんか来ないで探偵でも雇うといいと思うよ

821 ：デフォルトの名無しさん：2008/08/19(火) 13:39:42

ソフトウェア板かなんかと間違ってるだけなんだろうが…。

822 ：デフォルトの名無しさん：2008/08/19(火) 14:38:49

>>817
いいの無いから自分で作ったわ

823 ：デフォルトの名無しさん：2008/08/19(火) 23:18:56

レジストレーションをやりたくて、調べているのですが

http://navi.cs.kumamoto-u.ac.jp/~koutaki/index_j.html

で、オプティカルフローを使ったレジストレーションの動画を見ると、
連続的にアフィンパラメータを変化させて段々残差がなくなっていく
様子が見られるのですが、どうやってアフィンパラメータを追い込んでいるのか
が、さぱり分かりません。
微分画像をどう使ってるのか教えてく下さい。

824 ：デフォルトの名無しさん：2008/08/19(火) 23:41:24

>>817
IrfanViewで結構手軽にできると思うが。

825 ：デフォルトの名無しさん：2008/08/20(水) 04:42:58

親切にしてるつもりなんだろうが
バカを構うことで板違いの話題引き伸ばすのやめてくれ

826 ：デフォルトの名無しさん：2008/08/20(水) 08:01:47

親切と言うより、過疎っているから保守兼ねてやってるだけ。

827 ：デフォルトの名無しさん：2008/08/20(水) 11:09:12

>>823
http://en.wikipedia.org/wiki/Lucas_Kanade_method
http://vision.eng.shu.ac.uk/mmvlwiki/index.php/Lucas-Kanade_tracker

微分画像はわかりやすいようにのせてるだけじゃないか？

828 ：デフォルトの名無しさん：2008/08/20(水) 23:59:23

>>827
レスありがとうございます
うーんでも、やっぱりよく分からないのは
動画でみると、画像が少しずつ重なっていくところ。
(くちばしのところが最初に一致して、その後角度を調整しているように見える)
これも分かりやすくするためのパフォーマンスなんかなあ・・・
それともＬＫ法のパラメータを少しづつ変えているとかあるのかなあ

829 ：デフォルトの名無しさん：2008/08/21(木) 10:26:24

>>828
先に右に動いたせいで、たまたまくちばしのところが一致しただけでは？

OpenCVのライブラリを使ったソースだけど、
http://opencv.jp/sample/optical_flow.html
描画の部分でループがネストしてるだろ？　どっちかに先に動いておかしくない。

このへんも参考になりそう。
http://www-cv.mech.eng.osaka-u.ac.jp/research/tracking_group/okada/opticalflow/filtering_method.html
http://awabi.jaist.ac.jp:8000/kotani_lab/research/cv/flow/method.html

830 ：デフォルトの名無しさん：2008/08/22(金) 18:56:05

あー、OCRとか作りたい。
実はこの前ムカつくことあったからケータイ用OCR作って出版不況を加速してやろうと
思ったんだよね。要は合法でクールなテロだよ。なんかヒッピー的な感じの。

いちおうアルゴリズムは考えてて、
ノイズレベル見ながら画像をボカして背景色を割り出してそれ考慮して減色して
連続領域をラベリングして文字領域のサイズ正規化して文字判定器に回して
多変量解析して主成分取り出してあらかじめ作っといた近傍主成分ツリーと
マッチングして候補を出して文としての妥当性チェックをするわけだ。な、クールだろ？

ただ問題が一つある。
だるい。

831 ：デフォルトの名無しさん：2008/08/22(金) 20:55:07

プログラムはともかく、なんたらツリーの辞書と文としての妥当性を
判定をするための辞書を作るのが大変そうだな。

832 ：デフォルトの名無しさん：2008/08/22(金) 22:38:01

だるいとか眠いとかカスの代表的ないいわけ

833 ：デフォルトの名無しさん：2008/08/22(金) 22:51:03

作った奴だけが褒められる世界だしな

834 ：デフォルトの名無しさん：2008/08/22(金) 23:43:58

作っても無いのに褒められる世界ってあるの？

835 ：デフォルトの名無しさん：2008/08/22(金) 23:44:51

え？無いと思ってるの？

836 ：デフォルトの名無しさん：2008/08/22(金) 23:54:16

あるのかと聞いている

837 ：デフォルトの名無しさん：2008/08/22(金) 23:55:12

ある

838 ：デフォルトの名無しさん：2008/08/22(金) 23:56:50

板違い

839 ：デフォルトの名無しさん：2008/08/23(土) 00:08:31

で、作っても無いのに褒められる世界の具体的な話は出せないんだろ？

840 ：デフォルトの名無しさん：2008/08/23(土) 00:12:50

無いと思っているのかと聞いている

841 ：デフォルトの名無しさん：2008/08/23(土) 00:16:31

出せないんだろ？具体的な話をよｗｗｗしねよｗｗｗｗ

842 ：デフォルトの名無しさん：2008/08/23(土) 00:18:44

板違い

843 ：デフォルトの名無しさん：2008/08/23(土) 00:22:22

板違いとか言って逃げるのか？このヘタレヤロウが

844 ：デフォルトの名無しさん：2008/08/23(土) 00:22:49

板違い

845 ：名無し募集中。。。：2008/08/23(土) 01:28:47

板違い

846 ：デフォルトの名無しさん：2008/08/23(土) 01:38:52

妄想は広告の裏へ

847 ：デフォルトの名無しさん：2008/08/23(土) 13:08:43

作らなきゃ無意味
誰もほめんよ

848 ：デフォルトの名無しさん：2008/08/23(土) 14:19:21

え？無いと思ってるの？

849 ：デフォルトの名無しさん：2008/08/23(土) 14:59:09

スポーツはなんにも生産してないような

850 ：デフォルトの名無しさん：2008/08/23(土) 15:13:25

ま、そうだね。

851 ：デフォルトの名無しさん：2008/08/23(土) 15:22:26

広告効果

無形有形には関わりない

852 ：デフォルトの名無しさん：2008/08/23(土) 15:30:10

うん。

853 ：デフォルトの名無しさん：2008/08/23(土) 15:33:14

広告ってなんにも生産してないような

854 ：デフォルトの名無しさん：2008/08/23(土) 15:58:28

うん。

855 ：デフォルトの名無しさん：2008/08/23(土) 17:05:50

販売促進効果

少なくとも引きこもってるだけの人間よりは役に立ってるかも

856 ：デフォルトの名無しさん：2008/08/23(土) 17:51:42

画像処理その10

857 ：デフォルトの名無しさん：2008/08/23(土) 18:42:45

>>855
話を理解して無い馬鹿

858 ：デフォルトの名無しさん：2008/08/23(土) 18:49:10

せめて画像処理の分野内でなにも生産していないカスの話をしろ

859 ：デフォルトの名無しさん：2008/08/23(土) 18:55:03

何？悔しかったの？ｗ

860 ：デフォルトの名無しさん：2008/08/23(土) 19:45:06

カスを批判するカスが集まってるカススレ

861 ：デフォルトの名無しさん：2008/08/23(土) 21:00:29

生産物も分からんようではプログラムに向いてないかもな

862 ：デフォルトの名無しさん：2008/08/23(土) 23:10:45

↑話を理解して無い馬鹿

863 ：デフォルトの名無しさん：2008/08/23(土) 23:30:22

話がそれすぎ

864 ：デフォルトの名無しさん：2008/08/23(土) 23:53:05

板違い

865 ：デフォルトの名無しさん：2008/08/24(日) 13:11:04

■■学校を作ろう！■■
VIP発でサイトを作ろうと思うんだ。（詳しくはWikiを見てくれ）
パートスレになるんでパー速（GEP)に移動している。
今スタッフを募集しているから、来てくれないか？

■Wiki
http://www36.atwiki.jp/vipvipschool/
■募集スタッフ
プログラム担当（特にErlang、Perl）
デザイナー（サイト上のアイコン、ロゴなど）
WEBデザイナー（サイトデザイン案に沿って、htmlやCSSを書ける）
他にも宣伝担当なども募集している。
■スレ
http://ex14.vip2ch.com/test/read.cgi/news4gep/1219068297/

866 ：デフォルトの名無しさん：2008/08/24(日) 13:35:21

板違い

867 ：デフォルトの名無しさん：2008/08/24(日) 18:17:39

だってアウトプットがわかんないってことでしょ
致命的じゃん

868 ：デフォルトの名無しさん：2008/08/24(日) 18:22:46

↑話を理解して無い馬鹿

869 ：デフォルトの名無しさん：2008/08/24(日) 19:00:34

>>830
それと同じ内容のペーパーマシンの特許を、
30年以上前にファクシミリメーカーが出願しているのを
オレは特許調査で見かけたよ。リコーだったかな。
もちろん他社も同じことはいくらでも考えてる。
卒論で画像認識をやった学生も、普通に考え付く。

870 ：デフォルトの名無しさん：2008/08/25(月) 01:02:57

だからそういうネタレスなんでしょ

871 ：デフォルトの名無しさん：2008/08/25(月) 01:21:04

てか俺の携帯には既に実装されてる。辞書引きしか出来んけど。
便利な世の中になったもんだ。

872 ：デフォルトの名無しさん：2008/08/26(火) 08:25:06

CDのﾗﾍﾞﾙのような印刷物を写真に撮ると、さらつき感のある画像になり
StretchBitBlt()? だかで縮小すると、さらつきが強調される絵になる。
ところが、Vista のフォルダ表示の中のサムネイルは結構きれいな絵で
出てくる。どんな方法だから、キレイになるって分かりませんか。

873 ：デフォルトの名無しさん：2008/08/26(火) 09:58:50

SetStretchBltModeでHALFTONE指定してないだけとか?
サムネイルみたいな縮小率の高い絵じゃLPFの特性差なんてでないだろうし。

874 ：名無し募集中。。。：2008/08/26(火) 10:57:41

どうでもいいが、「さらつき」って聞きなれない言葉だな。

875 ：デフォルトの名無しさん：2008/08/26(火) 12:13:27

"さらつき"は、"ざらつき"なのか"ちらつき"なのか
今回は前者の間違いだろうけど

876 ：872：2008/08/26(火) 19:11:29

レスをありがとう。「ざらつき」って、カタカナだと「ザラツキ」。
こういうのをなんというのか知らないけど、ぐぐっていたら、そういう
書き方のがあったので、通じると思って書いた。
印刷物を接写すると、印刷のブツブツが撮れて、デカイ画面で見ると
ブツブツが拡大される。これは仕方がないけで、小さい絵のときそれ
がモアレのように出るってのが、なんとも不思議なんですよね。

877 ：デフォルトの名無しさん：2008/08/26(火) 19:40:38

エイリアスノイズや折り返し雑音でググれ

878 ：デフォルトの名無しさん：2008/08/26(火) 20:22:40

Lanczos 3

879 ：876-872：2008/08/26(火) 23:04:21

>>877 さん、>>878 さん、すみません。
>>873 さんの"HALFTONE" を頼りに調べて、SetStretchBltMode() での指定を
COLORONCOLOR から HALFTONE に変えたら、縮小してもキレイな絵が出るよう
になりました。最近の API を見てなかったので、知りませんでした。
ありがとうございました。

880 ：デフォルトの名無しさん：2008/08/27(水) 00:10:13

SetStretchBltModeって結構古いAPIだと思うが…

881 ：879-872：2008/08/27(水) 07:13:51

>>880
Win98 のとき、猫でも・・・の粂井さんのコードで知って以来使っている
ものです。以後、ここはそのマンマでした。

HALFTONE でいけると分かったのですが、ぐぐって説明をみると、今年の
２月頃の書き込みもありますが、概して古いですね。画像の拡大縮小の
最近の定石って、どんなのか、いいサイトがありますか。

882 ：デフォルトの名無しさん：2008/08/28(木) 00:07:54

まるもたん

883 ：デフォルトの名無しさん：2008/08/28(木) 00:21:44

バカの一つ覚え

884 ：881-872：2008/08/28(木) 19:08:28

>>882
「まるも」でぐぐったら、AviUtil の plug in の説明があり、画像の拡大縮小での
>>878 さんの Lanczos 3 が出てきました。「まるも」のソースはちょっと解読に
時間がかかりそうです。しかし他でも JTrim というのがあり、それでリサイズを
試したら、Lanczos 3 の表示がありました。250% 拡大だとモザイクが分かるかなと
いうレベルで、イヤー面白いですね。
蛇足ですが、HALFTONE ってのはやや時間がかかる感じですね。
みなさん、有難うございました。

885 ：デフォルトの名無しさん：2008/08/31(日) 15:23:01

4bitや8bitのbitmapのカラー変換をVB2005でやりたいと考えてるんだけど、
各pixelのパレットインデックス読む
↓
そのパレットのカラーをToArgbする

ここで得られたintegerからアルファ以外のRGB要素だけ取り出したい場合はどうしたらよいですか？

886 ：デフォルトの名無しさん：2008/08/31(日) 15:33:08

ビットシフト

887 ：デフォルトの名無しさん：2008/08/31(日) 15:45:47

ビットマスク

888 ：デフォルトの名無しさん：2008/09/02(火) 01:04:32

論理積

889 ：デフォルトの名無しさん：2008/09/02(火) 07:39:04

念力

890 ：デフォルトの名無しさん：2008/09/02(火) 08:05:23

ネタまがいの遊びが続いているんで、ToArgb てのをぐぐってみた。
Argb ってのが、AARRGGBB だったのネ。argument の略かと思ってた。
ToRgb というメソッドがあるといいのにね。

891 ：デフォルトの名無しさん：2008/09/02(火) 08:30:53

それくらい自分で作れるだろ

892 ：デフォルトの名無しさん：2008/09/02(火) 10:00:24

ヘボグラマの発想はそんなもんですよ

893 ：デフォルトの名無しさん：2008/09/02(火) 16:38:27

夏厨の残りカスでしょ

894 ：デフォルトの名無しさん：2008/09/02(火) 22:21:26

季節の変わり目は荒れるねえ

895 ：デフォルトの名無しさん：2008/09/02(火) 23:43:27

普段からだよ

896 ：デフォルトの名無しさん：2008/09/02(火) 23:47:09

荒れてるか？

897 ：デフォルトの名無しさん：2008/09/03(水) 00:03:23

ん？そうでもない？
荒らし足りなかったか

898 ：デフォルトの名無しさん：2008/09/03(水) 00:30:41

もっと頑張れ

899 ：デフォルトの名無しさん：2008/09/03(水) 00:41:53

今日はもう眠いからそのうちね
応援ありがとう

900 ：デフォルトの名無しさん：2008/09/03(水) 02:18:40

>>899先生の次回作に御期待下さい

901 ：890：2008/09/03(水) 07:42:33

>>885 の質問で昔話を思い出しんで、チラ裏だがマ聞いてくれ。

windows のアイコンは以前は 16色ばかりで稚拙だった。デジカメ写真の一部を
転用して簡単にアイコンに出来ないかとやってみた。減色してアイコン仕様の
ファイルにすればいいんで、マこれは一件落着。

ところが、最初ペイントでやってみたとき、ペイントが用意してくれる256色
パレットは使わない色も含まれる既成品。パレットを工夫すれば 16色でも
ある種の絵はきれいになるって気が付いた。1 bit color でもカラーになる。

以来、ico, cur, bmp ファイルを hex で見るようになって、パレットの部分
の右側の文字表示の欄は、文字を「■■」にしてこれに色をつけて表示する
ようにした。hex 編集を SJIS でやっていたときは、１６桁英数字をこの
「■■」４つで置き換えるんでちょうどすっぽり嵌ってウマーだったのが、
UNICODE になってやたら面倒になって、これを使うのをやめてしまった。
おソマツ。

902 ：デフォルトの名無しさん：2008/09/04(木) 01:44:27

画像処理プログラムそのものの質問じゃないんだけど、
Max(R, G, B) と Min(R, G, B)を入れ替えるのってなんていう処理なの？

あと、２値化処理で閾値と比較するときの輝度って
R, G, Bの平均っていう説とMin(R, G, B)っていう説があってどっちがほんとなんですか？

903 ：デフォルトの名無しさん：2008/09/04(木) 01:50:28

ほんとも嘘もない
より望ましい結果が得られる方を選択するだけの話

904 ：デフォルトの名無しさん：2008/09/04(木) 17:10:09

背景差分法の最も基本的な理論を教えてください！
理論式などあれば嬉しいです！
当方、画像処理については素人です、よろしくお願いします。

905 ：デフォルトの名無しさん：2008/09/04(木) 17:24:00

>>904
2枚の画像をそれぞれ正規化して差分をとるだけ。
各ドットごとに引き算した結果で画像を作って、場合によっては閾値でに二値化。
ググってもわからなかったんだとしたら、画像処理以前に勉強すべきことが山ほどあると思う。

906 ：デフォルトの名無しさん：2008/09/04(木) 17:26:40

自分で素人とか言う人って、俺はやる気は無いよと言ってるのと同じ

907 ：デフォルトの名無しさん：2008/09/04(木) 17:27:50

私は自分自身は客観的に見られるんです、
あなたとは違うんです。

908 ：デフォルトの名無しさん：2008/09/04(木) 22:35:11

>>906
それをここに書いて気持ちがよくなった？

909 ：デフォルトの名無しさん：2008/09/04(木) 22:53:10

>>907
なるほどこう使えばいいのかw

910 ：デフォルトの名無しさん：2008/09/05(金) 12:43:54

>>904みたいなのはぜんぜんOKだけどな
2chじゃないけど一番イラっとくるのはタイトルが「初心者です」の奴

911 ：デフォルトの名無しさん：2008/09/05(金) 14:49:50

>>905で具体的なやりかたがでてるのにそのまま逃亡

912 ：デフォルトの名無しさん：2008/09/05(金) 23:48:26

輪郭検出に近いことをやりたいんだけど、ノウハウでも、参考資料でもいいので教えてください。
フルカラー画像の中に開曲線(ループしてない)が何本かあったとします。
その曲線は背景色と十分色or輝度が違うという条件だけで、背景色自体も場所によって異なるかもしれません。
曲線の太さは1ピクセルとは限りませんし、エッジが鋭くないかもしれません。

この曲線を追跡してピクセルの座標列を求めるアルゴリズムは無いでしょうか。

913 ：デフォルトの名無しさん：2008/09/06(土) 00:08:55

>>912
そんなキモイ複合条件を満たすゆとり用のアルゴリズムは無い。

・背景色自体も場所によって異なるかもしれません→背景色を求める
・曲線の太さは1ピクセルとは限りません→細線化などの処理
・エッジが鋭くないかもしれません→エッジを鋭くする
・輪郭検出に近いこと→エッジを得る
・開曲線→エッジを追いかける

こんなふうにまず要求を分解しろ。しかるのちにぐぐれ。
分解できないほど無知なら本を読めばいい。

914 ：デフォルトの名無しさん：2008/09/06(土) 22:56:50

できればお勧めの本など教えてくれないでしょうか。

915 ：デフォルトの名無しさん：2008/09/09(火) 10:27:13

ある3Dの画像が与えられたときに略対称な面を求める場合
どのように考えればよいのでしょうか？

英語で略対称って何 symmetryっていうんだろう・・・

916 ：デフォルトの名無しさん：2008/09/09(火) 14:04:13

substantially symmetryってどういう意味？

917 ：名無し募集中。。。：2008/09/09(火) 21:47:23

略対称って何？

918 ：デフォルトの名無しさん：2008/09/10(水) 00:35:47

ぐぐっても少ししかひっかからんなあ。
使ってる分野の限られた用語なのか？

919 ：デフォルトの名無しさん：2008/09/10(水) 02:40:32

略対称の検索結果約 6,320 件
www.j-tokkyo.com での略対称の検索結果約 6,120 件

920 ：名無し募集中。。。：2008/09/10(水) 03:03:03

不自然なほど特許だけで使われてるな

921 ：デフォルトの名無しさん：2008/09/10(水) 09:32:16

パターンマッチングに興味を持ち，趣味で画像の勉強をしている初心者で
す。例えば，皆様のような専門性を持っている方は，次のような課題にど
のようにアプローチされますか。私の興味の一つは，このような基本的そ
うな問題に確立されたアルゴリズムが存在するかという点です。
宜しくお願いします。

　　画像A1・・・Anの中の一枚の画像から一部の画像S が切り出されてい
　　る。画像S は回転されたり，拡大又は縮小されたりしている。画像S
　　とその元画像を含む複数の画像A1・・・Anが与えられたとき，画像Ｓ
　　を作成するために使用した元画像及び切り出し領域をできる限り高速
　　に特定するプログラムを作成せよ。

922 ：デフォルトの名無しさん：2008/09/10(水) 12:11:02

>>921
画像処理屋がプログラムができるかどうかを聞かれたら、まず「画像を見せてください」
と尋ねる。

画像が文字か顔か線画か道路の写真か木の写真か....でアプローチ法は全く異なる。
たとえば線画だと分かっても実際の画像の傾向によって処理内容は違ってくる。

923 ：921：2008/09/10(水) 14:41:59

>>922
説明不足ですみません。
図形ではなく，写真（風景）を想定しています。
切り出す部分は風景の任意の一部（建物や，車，銅像，人，
あるいはそれらの一部）です。全ての画像に共通する傾向
は無いと考えてください（汎用性を持たせたいため）。
回転や拡大縮小といった一定の処理が施された写真の断片が
与えられたとき，そのオリジナルの写真を探すことが目的となります。

924 ：名無し募集中。。。：2008/09/10(水) 15:07:22

いわゆるパターンマッチングでしょ
「汎用性」が必要なら正規化相関を使ったサーチが一般的な回答になるんじゃないかな
しかし高速に求めるための工夫は各社それぞれのノウハウで「確立」されているわけじゃないと思う
「出来るだけ早く特定するアルゴリズムは確立されていない。アイディア勝負でまだ間に合う！」
って感じかな

925 ：デフォルトの名無しさん：2008/09/10(水) 17:20:23

既存のパターンマッチングはテンプレートに問題があるね

あと正規化相関は遅すぎて実用に向かない

926 ：デフォルトの名無しさん：2008/09/10(水) 17:25:06

>>923
類似画像検索ではなくて、オリジナルの写真から切り出したものが必ず検索対象になるの？
つまり人物や車の背景部分も同じかどうか。後者だと、イマイチ用途が不明だけど...

927 ：デフォルトの名無しさん：2008/09/10(水) 19:01:27

くどい

928 ：デフォルトの名無しさん：2008/09/10(水) 19:55:52

>>925
相関遅いね、相関

自然画でよーあるのは SHIFT特徴量だとか、コーナー検知する特徴量つかってのマッチングやね。

ググればいろんな特徴量でやった論文がくさるほどでてくるけど、実装したことないからわかんね。

929 ：デフォルトの名無しさん：2008/09/10(水) 20:27:42

SHIFTで検索できないとかわいそうなので、訂正すると"SIFT"ですね。
Scale-Invariant Feature Transformかな。
128次元だったかの特徴量がとれるので、
それをApproximately Nearest Neighbor法とかでデータベースから検索っていう実装なら見た。

930 ：デフォルトの名無しさん：2008/09/10(水) 20:48:50

オリジナルの写真から切り出しているのに正規化相関はないだろｗ

931 ：デフォルトの名無しさん：2008/09/10(水) 21:16:21

切り出しの大きさはどれくらいを想定してるんだろう。
元の風景写真のほんの一部とかだったら効率的な探索は相当難しそうだな。

932 ：デフォルトの名無しさん：2008/09/10(水) 21:41:46

部分切り出しだけでなく、その部分が変形されている場合、特に縮小されたら、
探しようがないでしょうね。
状態によっては人間が見てもマッチングが{難しい|できない}場合があるし。
もう少し条件を絞り込まないと、アプローチのしようがないように思えます。

933 ：デフォルトの名無しさん：2008/09/10(水) 22:38:24

>>932
SIFTならできる。名前に Scale-Invariant の文字があるだろう？

934 ：デフォルトの名無しさん：2008/09/11(木) 00:39:49

>>933
ＳＩＦＴが画像のスケール変化や回転や輝度変化等であまり変わらない
特徴量が記述できるのは分かっているが、条件に制限がないと、
極端な話、部分的に切り出された領域が１ピクセルに縮小されたら
マッチングは無理じゃね？　ということだろ。
ＡＲでよく見かけるような追跡は可能かも知れないが無関係の画像の中から
それを抽出するのは物理的に考えて無理だろう。

935 ：デフォルトの名無しさん：2008/09/11(木) 02:18:54

>>934
そりゃあくまでもロバスト、としか言えんけど、
画像処理という曖昧さを表現せにゃならん分野でそんなこと言って、
だから無理。とか言ってたら先に進まんよ。

936 ：デフォルトの名無しさん：2008/09/11(木) 03:34:04

>>934
たとえばPhotosynthではSIFT使ってあるタグのついた写真をFlickrから持ってきまくって
3次元再構成するみたいなことやってるけど。
まあ、縮小っていっても程度問題でしょ。50%の縮小くらいならマッチングできるでしょ。
2000x2000が1000x1000とかならさ。

937 ：915：2008/09/17(水) 14:11:31

>>920
そうなんですよね・・・

壷があったとしてどこか一部が欠けたり壊れたりしている部分があっても
左右が対称になる軸(面)が見つかるようにできないのかと考えていたのですが・・・

938 ：デフォルトの名無しさん：2008/09/17(水) 16:16:44

>>937
おまえは「略対称」という言葉をどこで知ったの？
本題から逸れて申し訳ないけど、単純に興味があるので。

939 ：名無し募集中。。。：2008/09/17(水) 16:27:45

線対称と違う言葉を使っていると言う事は3次元空間での欠陥認識なんですかね

940 ：デフォルトの名無しさん：2008/09/18(木) 13:40:41

どなたか、H.264について詳しい人いませんか？
エンコードにおいて、ブロックの動き補償ベクトルの探索方法については規格化されていないのに
探索開始位置の決め方が規格化されている意味が分かりません。
分かる方いらっしゃいませんか？利用している書籍は「H.264/AVC教科書(インプレス出版)」です。
公式仕様書では8.4.1.3のセクションです。

941 ：デフォルトの名無しさん：2008/09/18(木) 17:53:32

>>940ですが。
動きベクトル予測の意味を勘違いしました。
大変失礼しましたorz

942 ：デフォルトの名無しさん：2008/09/24(水) 02:55:45

簡単な画像処理アプリを作ることになりました。
どの言語でやろうか迷ってます。
こんなんです↓

tifを読む。（数百枚を一度に処理したい）
↓
透かしを入れる
↓
tifで保存

C,C++,C#は一応使えます。
今のところC#でやろうと思ってます（作るのが簡単なので)が
速度が心配です。
大量処理だとC#は無謀ですかね？

943 ：デフォルトの名無しさん：2008/09/24(水) 03:05:29

サイズにもよるしかけていい時間と処理するマシンの能力にもよるが。
別にC#だからどうってレベルの話でもないだろう、その程度なら。

ピクセル毎の演算を自力で、となるとちょっと辛いかも知れんが。
最近のC#はGPUでどうにかできるんだっけ？

944 ：デフォルトの名無しさん：2008/09/24(水) 03:10:03

C#でもポインタ使えばCの半分くらいは速度出るんじゃないの

945 ：デフォルトの名無しさん：2008/09/24(水) 03:44:50

とりあえず作ってみて(速度に)問題があるようだったら、
画像処理の箇所だけCで作り直せばいい

Cで組む場合にしてもアセンブラは最終手段
汎用ライブラリとして頒布するわけでもないし

946 ：デフォルトの名無しさん：2008/09/24(水) 09:07:46

>>942
どうでもいいが、数百枚を一度に処理するのではなくて1枚ずつ連続して数百枚処理するのだろ?
先ずはC#で作って処理時間を測るのが基本だな。

947 ：デフォルトの名無しさん：2008/09/24(水) 09:11:30

C#はピクセルにアクセスするメソッドがクソ遅いので
処理時間を気にするならやめたほうがいいよ。
バッチ処理なら動いておけばいいだろうけど。

948 ：デフォルトの名無しさん：2008/09/24(水) 09:14:13

>>304
>>310

949 ：デフォルトの名無しさん：2008/09/24(水) 09:36:57

遅いやり方を使わなければいいだろ

950 ：デフォルトの名無しさん：2008/09/24(水) 10:52:16

Bitmapをピクセル単位で操作したときはBitmap.LockBitsでunsafe。
用途にもよるがGraphices系メソッドの手法や考え方に一度しっかりなれることも大切だと思うよ。
透かし処理には向かないかもしれないが発想を転換すれば意外にいろんなことができる。

951 ：デフォルトの名無しさん：2008/09/24(水) 11:56:39

>>947
知らないのにレスしなくていいよ

952 ：デフォルトの名無しさん：2008/09/24(水) 12:20:14

unsafe使うのは避けれないが、Cに近い速度は出るよ。
GUIまわりが楽に作れるのでC#が結局は一番楽だよ。

953 ：デフォルトの名無しさん：2008/09/24(水) 12:35:21

LockBitsは知っているけどバッドノウハウだと思っていた。
C#のピクセルデータへのアクセスはこれを使うのが常識なのか？

954 ：デフォルトの名無しさん：2008/09/24(水) 12:54:18

うぜえなこいつ
おまえは遅いやり方でやってればいいじゃねえか

955 ：デフォルトの名無しさん：2008/09/24(水) 12:54:34

常識か非常識かなんて心の底からどうでも良いよ
アンタの用途にGetPixel/SetPixelの速度が耐えられるかどうかだろ

956 ：デフォルトの名無しさん：2008/09/24(水) 13:02:31

非推奨な仕様だったとしたら質問者にむやみに薦めるのはよくないだろ。
ただこれはMSDNにも例があったので俺が間違っていたよ。

957 ：デフォルトの名無しさん：2008/09/24(水) 13:07:57

単なるいいがかりかよ
氏ねカス

958 ：デフォルトの名無しさん：2008/09/24(水) 13:24:54

（･∀･）ｸｽｸｽ

959 ：デフォルトの名無しさん：2008/09/24(水) 15:19:03

>>942

つ「OpenCV」

960 ：デフォルトの名無しさん：2008/09/24(水) 16:03:12

なんでバッドノウハウとか非推奨だと思ったんだろう。
どうでもいいけど。

961 ：デフォルトの名無しさん：2008/09/24(水) 16:55:10

こういう流れじゃないだろうか・・・？
unsafe → 安全じゃない → 危険 → 使っちゃいけない

962 ：デフォルトの名無しさん：2008/09/24(水) 19:42:13

名前からしてgetPixel/setPixelだろ

963 ：デフォルトの名無しさん：2008/09/24(水) 19:46:18

なにを言ってんだおまえ

964 ：デフォルトの名無しさん：2008/09/24(水) 22:08:41

GetPixel()、SetPixel()を使うとかめみたいな遅さになるだろ
速度重視するならBitmapクラス、BitmapDataクラスを使って
画像データへの先頭ポインタをとる他ないだろ

965 ：デフォルトの名無しさん：2008/09/24(水) 22:30:07

何？今頃来たの？

966 ：942：2008/09/24(水) 23:48:41

ためしにC#とCで作ってみました。
ポインタ使って、for文内でプロパティも使わず、ネイティブコードにして
最大限に速くしたつもりですが
Cのが圧倒的に速かったです。

967 ：デフォルトの名無しさん：2008/09/24(水) 23:52:16

>>966
それは既知。問題はおぬしがそのC#コードの速度を許容できるか否かにすぎない。

968 ：デフォルトの名無しさん：2008/09/24(水) 23:54:48

>>966
何倍？

969 ：デフォルトの名無しさん：2008/09/25(木) 05:40:34

OpenCVでいいだろ
C#より機能そろってるし速いし
GUIだけC#にしたらええやん

970 ：デフォルトの名無しさん：2008/09/25(木) 14:39:56

OpenCV OpenCVって馬鹿の一つ覚えみたいに言ってるやつはなんなのかね。
求めるすかし処理がOpenCVで出来る範囲だったらいいけど、出来なかったらC++/CLIで書いて
ガッチャンコとかするしかないし。
つーかOpenCVだってCでの使用を前提としたライブラリなんだから結局配列を直接いじってなんか出来なきゃめんどくさくてしょうがないぞ。
なんかOpenCVが魔法みたいに思ってる人がたまにいて困る。

971 ：デフォルトの名無しさん：2008/09/25(木) 15:45:43

python.IML
+
python.ctypes + OpenCV

時々 python.numpy

972 ：デフォルトの名無しさん：2008/09/25(木) 16:53:41

C++でフリーで使える高速な補間ズームが出来るコードorライブラリない？
自分の環境で申し訳ないんだけど、目安としては
1GHzのCPUでQVGA→VGAのズームが10ms未満が目標。

ちなみに、StretchDIBitsだと12ms、自作プログラムが40ms掛かったorz

973 ：デフォルトの名無しさん：2008/09/25(木) 17:19:59

MMX/SSEあたり使えばPentiumM/800MHz相当で8ms台がででてるらしいが＠自作コード
つかCPUの種別やメインメモリの構成も指定しないで時間だけ言っても意味ねーだろ。

974 ：デフォルトの名無しさん：2008/09/25(木) 17:24:19

>>970
おまえOpenCVがなにかさえ分かってないだろ。

975 ：デフォルトの名無しさん：2008/09/25(木) 17:26:42

C++でOpenCVを使って画像に対する処理を書いてDLLにしてC#から呼び出せばいいだろ

976 ：デフォルトの名無しさん：2008/09/25(木) 17:34:20

（･∀･）ｸｽｸｽ