1001コメント334KB

画像処理その６

レス数が1000を超えています。これ以上書き込みはできません。

0001デフォルトの名無しさん

2006/02/21(火) 17:31:10

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

前スレ
http://pc8.2ch.net/test/read.cgi/tech/1127705848/
過去スレッド
画像処理その４
http://pc8.2ch.net/test/read.cgi/tech/1107854973/
画像処理その３
http://pc5.2ch.net/test/read.cgi/tech/1090897159/
画像処理その２
http://pc5.2ch.net/test/read.cgi/tech/1054545005/
画像処理
http://pc5.2ch.net/tech/kako/992/992671330.html

0002デフォルトの名無しさん

2006/02/21(火) 18:00:16

>>1
スレ立て乙です。

0003デフォルトの名無しさん

2006/02/21(火) 19:16:50

名前がどうとかいう話はどうなったんだ？
またphotoshopで、とかきそうだなぁ・・・orz

0004デフォルトの名無しさん

2006/02/21(火) 19:18:11

画像処理に役立つURLのリンクがテンプレにほしいなあ

0005デフォルトの名無しさん

2006/02/21(火) 20:39:46

>>前スレ999
たぶんその説明では納得しないしおそらくどんな説明をしても理解不能なので
ハイハイ何度も全画素走査乙、と放置するのが吉。

0006デフォルトの名無しさん

2006/02/21(火) 21:04:12

と思う。ぐらいで熟考していないorしたことがないんだったら、
その問題について熟考している質問者の期待には応えられなさそうだな

0007デフォルトの名無しさん

2006/02/21(火) 21:20:33

ラベリングが完了しているのに、「外枠も内枠も得られていない」という
こと自体漏れには理解不可能だな・・・

どうやってラベリングしてるんだ？

0008デフォルトの名無しさん

2006/02/21(火) 22:29:42

コピペプログラマでごめんなさい。

0009デフォルトの名無しさん

2006/02/22(水) 00:31:29

前スレ990見る限り、単純な輪郭抽出でいいんじゃねーの？
ラスタ順に見ていって、変化点抽出ですむんじゃないのか？？

0010デフォルトの名無しさん

2006/02/22(水) 03:25:39

イコライズフィルタを
ttp://www.mis.med.akita-u.ac.jp/~kata/image/equalize.html
ここを参照して作ってるのですが、一応輝度のみは出来たのだけど、
カラーが上手く行きません。
RGBモードとYUVモード(ここではYUY2)どちらでやってもフォトショのようになりません。
一応、RGBそれぞれの成分でやってみたけど、PSと一致しないので、YUVに一度変換してるのかと思って、
YUY2モードに変換してからやってみましたが、やはり色差成分が上手く行きません。
色々、累積度数やヒストグラムを出力してグラフにしたり試したんですが・・。
見づらいかもしれませんが、抜粋してみました。どうかご教授よろしくお願いします。

ttp://ranobe.sakuratan.com/up/src/up89689.txt

0011デフォルトの名無しさん

2006/02/22(水) 03:59:20

>>7
ラベリングの過程で座標自体はわかるのはわかる
結果的に得られた複数の点を線にくっつけないといけないでしょ
トータルの計算量のことをいってるわけ
一時記憶した点を再参照することが計算に含まれないわけじゃなく
それは結局再走査してることと変わらない
仮に一回走査して境界をすべて拾い出してどうやって個別の線に分離するんですか？
各境界線の点情報はメモリ上では順番に並んでないといけません

ラベリングには左上から走査して、接点が見つかったら再走査して合体作業をして
すべての領域が埋まるまで繰り返すというのを組んだことがあります
他にアルゴリズムがあって、食い違ってるなら適切なラベリングアルゴリズムを
教えてください

例えば
「＾＾＾」　　　「＾＾＾」
｜■｜－｜■｜
ーー　　　　－－
２個の四角い有効領域があってそれぞれに空洞領域を持っています
２個の遊興領域は真ん中の線で繋がっています
ほしい結果は
有効領域２個と線の外枠情報を順次配列で１個
内枠２個の線情報を順次配列で２個
内か外かの区別もわかるようにする

0012デフォルトの名無しさん

2006/02/22(水) 04:07:24

>>10
原色情報にわけるからじゃないですか？
３原色の合計値でやってみては？

0013デフォルトの名無しさん

2006/02/22(水) 07:26:11

>>10
全ての絵でうまく行くわけではなそうだが、コンなのもある。参考までに。
ttp://www.geocities.co.jp/Milkyway/4171/graphics/002-7.html

0014デフォルトの名無しさん

2006/02/22(水) 09:15:02

>>11
ワンパスのラベリングアルゴリズムはあるよ
論文へのポインタもプログラムもある。

001510

2006/02/22(水) 10:04:36

>>12, >>13
レスありがとうございます。
上のURLは一度見たことあるんですが、ここは明度(輝度？)しか弄ってないようで。(ソースも見ました)
色成分に関してはフォトショと大分違う結果が出てしまいました。明度のみでも。

3原色の合計値とはどんなでしょう？
R<<16+G<<8+B だと、ヒストグラムの配列を作る時に膨大になってしまい、アクセスだけで落ちてしまいます。。
unsigned long histgramY[16777216]; って時点でおかしいとは思いますが。
合計値でヒストグラムをまず作るという段階でつまずいてしまってます・・・。

0016デフォルトの名無しさん

2006/02/22(水) 10:43:22

たんに R+G+B じゃないの

0017デフォルトの名無しさん

2006/02/22(水) 11:31:05

>>15
ハッシュマップを使えば最高でも画素数分の領域で済む
スピードは遅いけどね

0018デフォルトの名無しさん

2006/02/22(水) 17:32:16

HSL の L 部分だけイコライズするとか

0019デフォルトの名無しさん

2006/02/22(水) 17:44:32

>>18
>>15

0020デフォルトの名無しさん

2006/02/22(水) 17:51:35

Brightness と Luminance の違いについて。

0021デフォルトの名無しさん

2006/02/22(水) 17:53:17

> 色成分に関してはフォトショと大分違う結果が出てしまいました

一般的な正解じゃなくて、フォトショと同じことをしたいと。

002210

2006/02/22(水) 18:56:49

どれが一般的か分からなくて申し訳ないですが、
一応、フォトショやJTrimで確認したような結果を出力したいんです。(ほぼ同じ結果でした)
やってみたのは、輝度のみとRGBそれぞれの成分での均一化です。
書店でちょっと見てきましたが、ヒストグラム平坦化とは少し違うのかな。。
取りあえず、>>15にあるようなRGB合計値での均一化を模索中です。ハッシュマップも調査中。。

0023デフォルトの名無しさん

2006/02/22(水) 20:26:01

ヒストグラムを多次元正規分布とかパラメトリックな分布関数で
近似するとかどうかな

0024デフォルトの名無しさん

2006/02/22(水) 21:24:43

実際、使用前使用後の分布をみてみたらいいんじゃないの？

0025デフォルトの名無しさん

2006/02/23(木) 01:49:32

こういうのどうよ
いったんグレースケール化してイコライズしてグレースケールの元画像との差分を取る
元カラー画像のＲＧＢに均等に差分を付加する

0026デフォルトの名無しさん

2006/02/23(木) 02:14:53

おたずねしたいのですが、
3次元画像の細線化処理で高速なアルゴリズムってどんなのがありますか？

鳥脇先生の方法を実装してみたものの、比較対象が欲しい。
このあたりってあんまり研究されてないのかな。

0027デフォルトの名無しさん

2006/02/23(木) 12:32:16

画像がフルカラーであるか、モノクロームであるかを判定する高速な
近似アルゴリズムを教えてください。

今実装しているのは、
「画像中の明度（rgbの適当な加重平均）差最大のピクセル対の色をc0、c1として、
　他の全てのピクセルの色が概ねc0,c1を通る直線上にあればモノクローム」
というものです。

適当にピクセルを間引いて実行すればこれでも十分高速なのですが、
基本的に2パス必要なところが気になって・・・

0028デフォルトの名無しさん

2006/02/23(木) 12:45:19

普通にrgbが全部そろってないのがモノクロで判断したほうがはやそうですがｗ

0029デフォルトの名無しさん

2006/02/23(木) 13:01:31

>>28
写真などで言う「モノクローム」、つまり色は付いていても単純な階調表現
画像なら「モノクローム」と判定しなきゃならないんです。

0030デフォルトの名無しさん

2006/02/23(木) 13:04:43

>>28
>>27が言っているのは、例えば、レントゲン画像をフルカラーでとりこんでおいた画像を判別したってことじゃないかな。
レントゲンの画像って青みがかってるけど、意味あるのは明るさだけじゃん。

0031デフォルトの名無しさん

2006/02/23(木) 13:05:24

>>11
バグってるかも知れないけど、擬似コード

003231

2006/02/23(木) 13:06:12

struct span {
　int x0, int x1, int color;
　span_list connected_spans;
};
int color = 0;
span_list output_span;
span_list prev_spans;
for (int y = 1; y < height-1; y++) {
　span_list spans;
　span* s = 0;
　for (int x = 1; x < width-1; x++) {// spanに分割
　　if (pixel[x][y] != pixel[x-1][y]) {
　　　if (s) { s->x1 = x; spans.add(s); };
　　　s = new span(x, x, y, color++);
　　}
　}
　if (s) { s->x1 = x; spans.add(s); };
　foreach(span* ps in prev_spans) {// 連結を調べる
　　foreach(span* s in spans)
　　if (ps と s が接していて、ps.color == s.color (mod 2) の場合) {
　　　s->connected_spans.add(ps);
　　} else {
　　　output_span.add(ps);
　　}
　}
　prev_spans = spans;
}
output_span.add_list(prev_spans);

0033デフォルトの名無しさん

2006/02/23(木) 13:15:58

>>27
やっぱり相関係数調べるくらいかなあ

003431

2006/02/23(木) 13:26:58

んで、output_span に得られた出力スパン（接続スパン付き）について点列に変換して行く。
その前に連結されたspanのcolorを統一しておけば、
「左右のスパンが同じ色 -> 内側の領域」とわかる。

点列への変換は、連結を調べつつ(21行目～)でやっても良い。
そうすると完全な1パスになる。

0035デフォルトの名無しさん

2006/02/23(木) 13:27:03

>>30 ってことはサーモグラフィーなんかもモノクロになるのか。

0036デフォルトの名無しさん

2006/02/23(木) 13:33:46

>>35
それはそれでまた面倒な話だな
色相を見ることになるわけ？

0037デフォルトの名無しさん

2006/02/23(木) 13:54:56

そういうのは画像処理っていうよりＧＡかＮＮでやったほうがいいぞ
ヒストグラムとって分布をある程度のビット列に変換してＮＮを通して学習させる

0038デフォルトの名無しさん

2006/02/23(木) 13:58:25

>>31
おお、ありがとう
解読してみますｗ

0039デフォルトの名無しさん

2006/02/23(木) 16:26:30

文末にｗつけるやつは氏ねｗ

004010

2006/02/23(木) 17:14:02

色々なレスありがとうございます。
へたれなプログラマなので、まだまだ実際にコードを書くのに時間かかりそうですが、
書かれてる事を試してみます。ちなみに、一応PSなどのイコライズ前後の分布等はグラフなどで比較はしてました。

0041デフォルトの名無しさん

2006/02/23(木) 17:17:24

>>35 >>36
あれは分かり易くする為に色を付けてるだけ
もとの画像はモノクロだったはず

0042デフォルトの名無しさん

2006/02/23(木) 17:36:38

モノクロっつーか、単に1次元のデータを濃淡にするか色相にするかってだけだし。

0043デフォルトの名無しさん

2006/02/24(金) 14:23:00

画像処理と関係があることだと思うので、どうかお助けを・・・

ウィンドウ(論理座標)とビューポート(物理座標)との間で
座標変換を行う処理を実装したのですが
Win32APIでサポートされているデバイスコンテキストを用いた
座標変換の処理結果と微妙に異なるのです。

設定値は int で保持、計算は int で行っていて
・ウィンドウ領域　 - 始点 (WX1, WY1), 終点 (WX2, WY2)
・ビューポート領域 - 始点 (VX1, VY1), 終点 (VX2, VY2)
という設定で、ウィンドウ領域の点 P(PX, PY) を
ビューポート領域の点 Q(QX, QY) に変換するために

[式A] QX = (PX - WX1) * (VX2 - VX1) / (WX2 - WX1) + WX1
↓誤差を少なくするため
[式B] QX = ((PX - WX1) * (VX2 - VX1) + (WX2 - WX1) * WX1) / (WX2 - WX1)

※ API では hDc は初期済のデバイスコンテキストで
マッピングモード: SetMapMode(hDc, MM_ANISOTROPIC)
ウィンドウ設定: SetWindowExtEx(hDc, WX2 - WX1, WY2 - WY1, NULL)
ウィンドウ原点: SetWindowOrgEx(hDc, WX1, WY1, NULL)
ビューポート設定: SetViewportExtEx(hDc, VX2 - VX1, VY2 - VY1, NULL)
ビューポート原点: SetViewportOrgEx(hDc, VX1, VY1, NULL)
で各設定を行い LPtoDP() を用いて変換しています。

を使っています。
(続く...)

004443

2006/02/24(金) 14:23:38

原因追求のため [式B] を double で行って、誤差の発生している数値の
一例は下記のようになります。
※ 式B(int) と API で結果が異なるものを「×」としています。

・結果が負の場合
×: [式B(double)] = -41.53, [式B(int)] = -41, [API] = -42
○: [式B(double)] = -37.52, [式B(int)] = -37, [API] = -37 [※1]
○: [式B(double)] = -33.50, [式B(int)] = -33, [API] = -33 [※1]
○: [式B(double)] = -29.48, [式B(int)] = -29, [API] = -29

・結果が正の場合
○: [式B(double)] = 25.46, [式B(int)] = 25, [API] = 25
×: [式B(double)] = 29.48, [式B(int)] = 29, [API] = 30 [※2]
×: [式B(double)] = 33.50, [式B(int)] = 33, [API] = 34
×: [式B(double)] = 37.52, [式B(int)] = 37, [API] = 38

※1 [式B(double)] の値が四捨五入対象なのに [API] ではされていないケース。
※2 [式B(double)] の値が四捨五入対象ではないのに [API] ではされているケース。

傾向としては、APIの方では [式B(double)] の値を四捨五入しているように
感じられますが、※1, 2 のような例外もあります。
そのため、[式B] を double で行い四捨五入後に整数化しても
API と同じ結果を得ることができません。

そこで、お聞きしたいのですが、座標変換を行う場合は
数学的に導いた [式B] をそのまま使うのではなく
画像処理特有の工夫みたいなものがあるのでしょうか？

結果としては、ほぼ同じなので問題ないとは思うのですが
今後の勉強のために何かアドバイスがありましたら
よろしくお願いします。

0045デフォルトの名無しさん

2006/02/24(金) 17:00:10

>>43
＞画像処理と関係があることだと思うので、どうかお助けを・・・

ここまで読んだ。

0046デフォルトの名無しさん

2006/02/24(金) 17:22:28

>>43
俺は式Aを使ってるよ。
アルゴリズムの本で呼んだ記憶がある。
APIのマッピングと多少の違いはあってもいいんじゃないの？
というか、APIと比較しようなんて考えもしなかった。

0047デフォルトの名無しさん

2006/02/24(金) 18:49:10

>>44
APIがどうやってるかは知らないけど、座標の場合って整数化するときは
floor使わないと0付近がまずいことになると思う。

0048デフォルトの名無しさん

2006/02/24(金) 23:02:13

>>42
式Aは
QX = (PX - WX1) * (VX2 - VX1) / (WX2 - WX1) + VX1
でしょ。で、式Bは
QX = ((PX - WX1) * (VX2 - VX1) + (WX2 - WX1) * VX1) / (WX2 - WX1)

ここからさらに式変形すると、
QX = ((PX * (VX2 - VX1) - WX1 * (VX2 - VX1) + (WX2 - WX1) * VX1) / (WX2 - WX1)
= (PX * (VX2 - VX1) - WX1 * VX2 + WX1 * VX1 + WX2 * VX1 - WX1 * VX1) / (WX2 - WX1)
= (PX * (VX2 - VX1) - WX1 * VX2 + WX2 * VX1) / (WX2 - WX1)
となる。
で、a b cを
a = VX2-VX1
b = WX2*VX1 - WX1*VX2
c = WX2-WX1
と、あらかじめ計算しておき、個々のPXについては
QX=(PX * a + b) / c
として、整数で計算だな。

004943

2006/02/24(金) 23:44:19

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

あれから、色々と検証したのですがAPIのLPtoDP関数と
同等の関数(int版, double版の2つ)を作成して
それぞれの関数を10万回実行したときの時間を計測したのですが
LPtoDP と自作同等関数 (int版) がほぼ同じ時間だったので
APIも内部は整数で計算していると思われます。
（double版は倍以上の時間がかかっていたため）

結局、整数で計算して四捨五入するようにしたのですが
やはり>>44の※1, ※2のようなケース(小数部0.5前後)で
APIと結果が異なってしまいます。

四捨五入は>>48さんの式をお借りして

// 余り算出
int nMod = (PX * a + b) % c;
// 余りが、割る数 c の半分以上の場合を四捨五入対象とする
if (abs(nMod) >= abs(c >> 1))
{
　// 四捨五入 (割られる数、割る数の符号チェックの方が確実？)
　if (QX > 0) { QX++; } else { QX--; }
}

以上のような処理で行っています。
ここまでやっても、APIと異なるので何か特別な方法があるような気がして
ならないのです。
どうか、よいお知恵をお貸しください。

>>48さん
最適化した式をありがとうございます。
しかし、まだ最適化以前の問題ですので・・・今後、参考にさせていただきます。

0050デフォルトの名無しさん

2006/02/24(金) 23:45:51

>>49
そこまで気にするなら、デバッガでAPIの中まで追っかければいいじゃない。
#そしてそこまで行くとスレ違いな罠。

005143

2006/02/25(土) 00:03:54

>>50
APIの中までデバッグで追うことって可能なのですか？
VC7.0を使っているのですが、API関数の中までは入れないので・・・

0052デフォルトの名無しさん

2006/02/25(土) 00:06:03

つ【努力】

0053デフォルトの名無しさん

2006/02/25(土) 00:09:43

-41.53 = -42.00 + 0.47 = -42
-37.52 = -38.00 + 0.48 = -38
-33.50 = -34.00 + 0.50 = -33
-29.48 = -30.00 + 0.52 = -29

25.46 = 25.00 + 0.46 = 25
29.48 = 29.00 + 0.48 = 29
33.50 = 33.00 + 0.50 = 34
37.52 = 37.00 + 0.52 = 38

0054デフォルトの名無しさん

2006/02/25(土) 00:57:51

>>51
混合表示にしたら入れない?
#だからスレ違い。

005543

2006/02/25(土) 01:06:30

>>53
それも考えたのですが

＞ ○: [式B(double)] = -37.52, [式B(int)] = -37, [API] = -37
＞ ×: [式B(double)] = 29.48, [式B(int)] = 29, [API] = 30

では成り立ちません。

>>54
どうもです。試しています。

0056デフォルトの名無しさん

2006/02/25(土) 01:21:21

割り算の処理になんかあるのかな。
-41.53とか割った後の数じゃなく、割る数と割られる数教えてくれる？

0057デフォルトの名無しさん

2006/02/25(土) 02:31:19

47はスルーですか？

四捨五入だとか切り捨てという考えで少数→整数変換すると
-0.99999～0.99999まで0に変換されるから、0をまたいだところで
距離が狂うよ。

Ｃ言語でdoubleをintにキャストした場合や、intで除算をすると
少数部分が切り捨てられる。

これを防ぐために、整数化する際にはfloorを使うことが重要。
整数の除算も同様の措置が必要。(余りを見れば簡単)

0058デフォルトの名無しさん

2006/02/25(土) 03:41:35

>>49
四捨五入ずれてない？

例えば4/3の場合、
int nMod = 4 % 3; //ここでnModは1
// 余りが、割る数 3 の半分以上の場合を四捨五入対象とする
if (abs(nMod) >= abs(3 >> 1)) //ここで3 >> 1は1だから条件は真になってしまう。

a/bで四捨五入する場合、(a+b/2)/b でいいんじゃないか？

#それでもAPIの値は説明つかないが。

0059デフォルトの名無しさん

2006/02/25(土) 03:42:06

C言語の場合、負の数を含む整数除算をやったときに、余りの符号が
どうなるかは処理系依存。

なので、(-1)÷3　が、「0 余り -1」になるか、「-1 余り +2」になるかは、
何とも言えない。保証されているのは、「余りの絶対値は、割る数の
絶対値よりも小さい」ということだけ。

キャストの (int) についても、絶対値を小さくする方向に切り捨てるのか、
それとも floor 関数のように「引き数を越えない最大の整数値」にする
のかは、処理系依存。

0060デフォルトの名無しさん

2006/02/25(土) 03:47:46

いまどき使う人はいないと思うけど、Cのビットフィールドの符号拡張も
処理系依存。１ビットの整数値は０と１を意味するかと思ったら、
unsigned をつけてないと、０とマイナス１になるというコンパイラが
実際にあった。

006143

2006/02/25(土) 12:02:24

いろいろとすみません。非常に助かっています。
>>56
>>58の四捨五入方法にしてデータをまとめてみました。（x方向のみ）

ウィンドウ: WX1 = -50, WX2 = 50 (幅: 100)
ビューポート: VX1 = -67, VX2 = 67 (幅: 134)

位置: PX → QX への座標変換は
　[式A] QX = ((PX - WX1) * (VX2 - VX1) + (WX2 - WX1) * VX1) / (WX2 - WX1) において
　分子: a = (PX - WX1) * (VX2 - VX1) + (WX2 - WX1) * VX1
　分母: b = WX2 - WX1
として、四捨五入を行う以下の整数除算により行う。
　[式B] QX = K * (2 * a + b) / (2 * b)
　※ 係数 K は (a > 0 かつ b > 0) の場合 1、それ以外で -1 とする。
　　　また、a, b は絶対値を用いる。
　　　(上記式では、負数の場合も正方向へ四捨五入するためこのようにしました)
問題のあるデータは・・・

PX = -28 のとき QX = (-1) * (2 * abs(-3752) + 100) / (2*100) = 38.02
QX の結果 API = -37, [式B] = -38, [式A(double)] = -37.52
※ 四捨五入対象なのに API ではされていない。

PX = -25 のとき QX = (-1) * (2 * abs(-3350) + 100) / (2*100) = 34.00
QX の結果 API = -33, [式B] = -34, [式A(double)] = -33.50
※ 四捨五入対象なのに API ではされていない。

PX = 22 のとき QX = 1 * (2 * abs(2948) + 100) / (2*100) = 29.98
QX の結果 API = 30, [式B] = 29, [式A(double)] = 29.48
※ 四捨五入対象ではないのに API ではされている。

以上のように [式A(double)] の結果の小数部が 0.5 前後のデータでAPI と誤差が発生しています。
他のデータでは、四捨五入が正の数ではプラス方向へ、負の数ではマイナス方向へ正しく行われて API、[式B] とで誤差は発生しません。

006243

2006/02/25(土) 12:12:54

(>>61の続き)

>>57
今問題があるデータが小数部0.5付近のものだったため
>>47の問題まで至ってないということで触れませんでした。

参考までにソースと計算結果のデータを置いておきます
http://syobon.com/mini/src/mini16643.zip.html
パスワード: tr050
・Main.cpp - テスト用プログラムと座標変換クラスのソース。
・tab.txt - 上記プログラムで出力した結果ファイル。
元座標(x, y)
API結果(x, y)
[式B]の結果(x, y)
[式A(double)]の結果を整数化(x, y)
[式A(double)]の結果(x, y)
以上、10項目をtab区切りで出力したものです。

TransクラスのCvtXPosW2V()で x 方向のウィンドウからビューポートへの
変換処理を行っています。

006326

2006/02/26(日) 01:29:27

華麗にスルーされた。ヽ(`Д´)ノウワァン
3次元画像関係でエロい人はここにはいないのか。残念。

0064デフォルトの名無しさん

2006/02/26(日) 02:15:01

>>63
それって、ようするにボクセルに対して画像処理するってこと？
そういう分野もあるのか。医療用？

0065デフォルトの名無しさん

2006/02/26(日) 02:34:43

>>62
xpだとAPIから取得される値が違うみたい。

Main.cppをbccでコンパイルしてできたexeをxpと2000で実行してみた。
ttp://syobon.com/mini/src/mini16688.lzh.html

xpの場合はAPIから取得できる値と[式B]の結果がほぼ一致していた。

0066デフォルトの名無しさん

2006/02/26(日) 02:44:42

ドロネー図を作成するアルゴリズムを教えてください

0067デフォルトの名無しさん

2006/02/26(日) 03:33:15

ドロネー図とかボロノイ図は、計算幾何学とかの分野だから
このスレの話題とはちょっと違う気がする。

0068デフォルトの名無しさん

2006/02/26(日) 05:48:13

>>66
　　 /: /: : : : :｀.: : : : : : : : :/´￣＼ : : : : : ヽ:::ノ　>>1
.　　!: : : :iflllli､: : : : : : : : : : : : : : : :ヽ: : : : : :.!
　　|: : : :llllｆ　l: : : : : : : : : : :.iflllli､: : : : : ＜iiii| きみ　　　　　　　　けいじばん
　　|: : : :|llll　|: : : : : : : : : : .llllf　l: : : : : : : : :.|　君にちょうどいい　掲示板　があるよ！
　　|: : : :.!lllll!' : : : : : : : : : : |llll　|: : : : : : : : :i
　 /: : : : :　　　 ○　　　 : : .!lllll!' : : : : : : : :.i　がくせい　なかまたち　　じょし
￣|: : :" 　,,,,,,,,,,,,,|____　　　　: : : : : : : :.＜iii/ 　　学生　の　仲間達　　（女子もいるよ！）がたくさん
.／!.:　　　|:::::／　　　￣''''''''l ヽ: : : : :-─/─　
　　ヽ　　ヽ/　　　　　　　ﾉ　　 : : :ヽ／　　　　　　　　　　　そくびっぷ　けいじばん
　　　＼　　＼,,_　　　 _,,,／　　　 : ／＼　　　　それがニュー速　 VIP　　掲示板
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 http://ex11.2ch.net/news4vip/

006943

2006/02/26(日) 08:59:01

>>65
貴重な情報をありがとうございます。
画像処理とはかけ離れた内容になってしまったので
今後は自分なりにもう少し調査してみようと思います。

アドバイスを頂いたみなさん。本当にありがとうございました。

0070デフォルトの名無しさん

2006/02/26(日) 14:06:08

>>64
主に医療用。
今回はちょっと違う用途で使いたい。

007126

2006/02/26(日) 15:47:31

あ，でも2値画像は医療では使わないかな。
2次元の2値シルエット画像と同じで，形状の情報を表します。

さっき名古屋の人たちが全く同じ細線化アルゴリズムを実装してるのを発見 orz
ttp://mist.suenaga.m.is.nagoya-u.ac.jp/trac/

なんで去年見つけられなかったのかと思ったら，
開発時期がちょうどかぶってた。泣きたい。
ここの人に聞いてみます。お邪魔しますた。

007259

2006/02/26(日) 23:12:14

>>69
> アドバイスを頂いたみなさん。本当にありがとうございました。

特に役に立つ助言をしなかったオレが言うべきことではないんだが・・・

あほな突込みをするけど、アドバイスを「いただく」のは、アドバイスを「もらう」側。
アドバイスを「くれる」人についての敬意を表現するときは、
『アドバイスを下さった皆さん』というほうが望ましい日本語だと思うぞ。

0073デフォルトの名無しさん

2006/02/26(日) 23:53:14

つまり、
> アドバイスを頂いたみなさん。本当にありがとうございました。
↓
# アドバイスをしていただいたみなさん。本当にありがとうございました。
だな

0074デフォルトの名無しさん

2006/02/27(月) 00:34:06

「アドバイスをしていただいたみなさん。」なら、なんとなくいいような気がするんだけど、
突き詰めて考えるとまだ変な気がしてくる。考えてたら余計気になってきた…。

0075デフォルトの名無しさん

2006/02/27(月) 00:37:10

揚げ足とり好きだね。

0076デフォルトの名無しさん

2006/02/27(月) 00:37:19

こうか？
# みなさん、アドバイスをしていただいて本当にありがとうございました。

0077デフォルトの名無しさん

2006/02/27(月) 02:36:21

どうみても精子です。
本当にありがとうございました。

0078デフォルトの名無しさん

2006/02/27(月) 13:32:09

アニヲタうざ

0079デフォルトの名無しさん

2006/02/27(月) 14:21:39

>>66
OpenCVに逐次的にドロネー図/ボロノイ図を計算するルーチンがあった気がする。
ソース見てみたら？

0080デフォルトの名無しさん

2006/02/27(月) 15:26:44

なんだか寒いんで暖房入れときますね。

　　　　　　＿＿＿＿　.　.|　|
　　　　／＼二＿＿_＼..　|　|
　　　　|＼／∥　　　'''.| 　|　|
　　　　|　|　 ∥┌┐　.|　 |　|　
　　　　|　|　 ∥└┘　.|┌|=.|ヽ＿＿
　　　　|　|　 ∥　　　　.|二|　|回＿凵
　　　　|　|　 ∥　　　　.|└|=.|/
　　　　|ﾐ.|　 ∥　　　　.| 　|　|
　.　　 .|ﾐ.|　 ∥　　　　.| 　|　|
　　　 |　|　 ∥　　　　.| 　|　|
　　　　＼|＿∥＿＿__.| 　|　|

0081デフォルトの名無しさん

2006/02/27(月) 23:34:36

>>66
ttp://www.ics.kagoshima-u.ac.jp/~fuchida/edu/algorithm/voronoi-diagram/all-search-method.html

0082デフォルトの名無しさん

2006/02/28(火) 00:08:53

Adobe Generic Image Library
http://opensource.adobe.com/group__asl__gil.html

0083デフォルトの名無しさん

2006/02/28(火) 04:25:12

プログラミング初心者なんだけど
WindowsのCursolファイル(.cur)の仕様？
みたいなのってないの？

0084デフォルトの名無しさん

2006/02/28(火) 07:08:52

>>83
仕様っていうほど込み入ってはいない。ICOCURSORHDR, ICOCURSORDESC, DIB,
mask が並んでいるだけ。MSDN のサンプルを見れば操作方法も分かろう。
mask のビットが反転の反転なんてあって戸惑うことはあるが。
因みに .ani の方は imageEdit とかのサンプルにある。

0085デフォルトの名無しさん

2006/02/28(火) 12:33:41

ImageMagickの質問をしたいんですがここって場違い？

0086デフォルトの名無しさん

2006/02/28(火) 13:34:53

>>85
ちょっと場違いかな。

0087デフォルトの名無しさん

2006/02/28(火) 13:52:34

画像をぼかすのに
平滑法、ガウス、Summed Area Table(範囲総和テーブル)
以外の方法を知っている人がいたら教えて下さい。
ブラー（blur）とか、ぼかしで調べても、
殆ど平滑法しか見当たらないので、よろしくお願いします。

0088デフォルトの名無しさん

2006/02/28(火) 14:00:09

>>87
いわゆる「ぼかし」ならそれらで何か問題でも？
違うぼかし方をさせたいとか。

0089デフォルトの名無しさん

2006/02/28(火) 14:41:08

>>88

いわゆる「ぼかし」なら問題がないんですが、、、ご指摘の通り違うぼかし方をしたいんです。
ある種の、質感が欲しいのです。端的に言ってしまえば、auviというソフトがあるのですが、
そのソフトのblur(ぼかし方)が知りたいのです。残念ながらこのソフトはmacのmax/mspというソフトの
拡張書類で、他のソフト、他のハードでも使えません。勿論、このぼかしのアルゴリズムが作者自信に
よるかもしれませんが、上記以外に「ぼかし」のアルゴリズムが有るのかという事を知りたかったのです。
そして、違うソフト上で個人的に使いのです。

変な文章になってしまいましたが、誰か引き続きアドバイスよろしくお願いします。

0090デフォルトの名無しさん

2006/02/28(火) 14:52:36

LIBTIFF使ってOld-JPEG圧縮なTIFFを読み取りたいのですがTiffOpenする時に
"huffman table too big"と怒られてしまいます。
なんとか画素データ取り込む方法ないでしょうか？
LIBTIFFでOld-JPEG圧縮なTIFFを読み取るにはjpeg-6bが必要なのですが
jpeg-6bのjdhuff.cへのパッチを当ててもうまく行きません。

↓のようなメーリングリストで色々議論されてるけど英語読めん；
ttp://www.asmail.be/msg0055112106.html

どなたかご存知の方いますか？

0091デフォルトの名無しさん

2006/02/28(火) 16:39:45

>>89
auviがどんなものか知らないなから答えになってないけど。

空間フィルタと周波数フィルタを同時にかける方法があるみたいだよ。
http://homepages.inf.ed.ac.uk/rbf/CVonline/LOCAL_COPIES/MANDUCHI1/Bilateral_Filtering.html

0092デフォルトの名無しさん

2006/02/28(火) 17:09:51

>>91

返答、ありがとうございます。このブラーは、実用速度があるのか怪しいです。
でも、一応試してみたいと思います。そういえば、fftでもブラーできますね。ただ、速度の面でかなり問題がありましたが、、、。
で、いろいろと調べてみたら
ttp://homepage1.nifty.com/open-prog/article/article01.html
にある。Blurring widh Self Feedback Blendingという方法を発見しました。
ですが、Blurring widh Self Feedback Blendingで検索しても
何も引っかかりませんでした。この方法が詳しく書かれている（理論だとか）
サイトか何かを知りませんでしょうか？質問ばかりですみませんが。

0093デフォルトの名無しさん

2006/02/28(火) 17:20:19

widh -> with
でもだめだなー。

0094デフォルトの名無しさん

2006/02/28(火) 17:28:05

>>92
>Blurring with Self Feedback Blending
参考も何も、そのページに書いてあるまま実装したらいいじゃないの?

0095デフォルトの名無しさん

2006/02/28(火) 17:41:19

培養細菌の数を調べるのに手作業でやってるのを見て画像処理出来ないかな？と思った。
画像内の円弧から中心点を求めてカウント、円の大きさ別に振り分ける。
どうすりゃいいのかサパーリわからんからやりたい人やってくれ。
完成したら公的機関に高く売ってやって。

0096デフォルトの名無しさん

2006/02/28(火) 17:56:30

いいよ

0097デフォルトの名無しさん

2006/02/28(火) 18:04:54

>>92

1,2,4,8ピクセルとずらして50%ブレンドすることで、、、
ってありますが、そこに書かれている通りすると、画像が右下への方向が出来ます。
( 勿論、ずらす方向を変えても、ブラーはかかりましたが。 )
Blurring with Self Feedback Blending が元々そいったものなのか、
どうか知りたいのです。なので、出典が知りたかったのです。

0098デフォルトの名無しさん

2006/02/28(火) 20:00:38

ユーザが描いた曲線にフィットするベジエ曲線を得るにはどうすればいいんでしょうか

0099デフォルトの名無しさん

2006/02/28(火) 23:02:44

以前やったときはこの辺を元にした。多分もっといい文献あるだろうけどそんときはこれで十分だったから調べてない。
http://cajun.cs.nott.ac.uk/compsci/epo/papers/volume6/issue3/ohno.pdf

0100デフォルトの名無しさん

2006/02/28(火) 23:34:41

>>95
スレ違いのような気もするが、NIH ImageとかSion ImageとかImageJとかの？

0101デフォルトの名無しさん

2006/03/01(水) 01:14:49

>>98
ユーザーが書いたベジェ曲線をそのまま使えばいいお

0102デフォルトの名無しさん

2006/03/01(水) 04:03:11

>95
画像をキャプチャーする部分と、それを解析する部分に分けて考えましょう。
前者はスレ違いなので、パス。
後者は、単に細菌数を調べたいだけなら、面積を出力するのが一番簡単でしょう。
輝度なり色相なり、適当な指標を用いて、画像のピクセル数を数えれば、
ややこしい処理はいっさいなしで、必要十分なのではないでしょうか。

0103デフォルトの名無しさん

2006/03/01(水) 04:11:09

>>95
昔、モル数を調べるときは、
>>102 のように画像処理のようなことをしていたので、
この方法でよいなら、できると言える

0104デフォルトの名無しさん

2006/03/01(水) 11:33:43

>>95
大きさや個数のわからない円が描かれてる画像から
円を取り出すのはそう難しくないだろうね。

実際の画像をうｐしてくれるとわかりやすいんだけど、
みんな同じ大きさの円形ってことでいいのかな。
大きさがまちまちだったり2匹重なったりノイズがひどかったりしないの？
あと、何匹くらい数えるの？

見た目上の面積がかならず一定なら
>>102で大丈夫だと思う。
>>103のは細長い分子のモル数を数えるとき水面に垂らせばみんな縦に並んで
一様に広がるから面積とモル数が比例するとかそんな話だと思うけど、

って書きながらググったらあるじゃねーか！
ttp://www.microbio.co.jp/documents/pdf/DMCS%20Methodology.pdf
ttp://www.ario.co.jp/

0105デフォルトの名無しさん

2006/03/01(水) 19:58:16

こんな大掛かりな物を用意しなくても
簡単なカメラとソフトウェアだけで出来れば格段に安くなるんじゃないかな。

でも104と同じく重なっている場合の処理とかどうするのよ。
細らせて数を得るところまでは想像つくけど
面積を出す為にどこまで太らせるかは一番近い画像を吐くまで総当たり?

0106デフォルトの名無しさん

2006/03/01(水) 21:53:29

フィルタかけてエッジを抽出して、ハフ変換(Hough変換)で円弧を検出。

参考
ttp://homepage3.nifty.com/ishidate/vcpp6_g15/vcpp6_g15.htm

0107デフォルトの名無しさん

2006/03/01(水) 22:04:32

>>106
厨がまた出た。
ﾌﾟギャーって笑うぞ？

0108デフォルトの名無しさん

2006/03/01(水) 23:09:37

画像処理について勉強したいのですが、おすすめの教材が
ありましたら教えて頂けないでしょうか？

0109デフォルトの名無しさん

2006/03/01(水) 23:54:31

円で検出していいの？

0110デフォルトの名無しさん

2006/03/02(木) 01:17:08

>>108
「画像処理」を「数学」に置き換えれば自分の質問がどれだけ（ｒｙ

ttp://www.microsoft.com/japan/msdn/academic/Articles/Algorithm/03/
ttp://www.microsoft.com/japan/msdn/academic/Articles/Algorithm/04/
これでも読んで、自分が何をしたいか確認してきて。

0111デフォルトの名無しさん

2006/03/02(木) 04:48:08

前スレあたりに出てたフルスクラッチによる云々って本は
軽く流して見ただけだが、入門には良さそうな感じだったよ。

俺は逆に内容は難しくていいから、バイブル的存在の本があったら教えて欲しい。
この1冊に画像処理の歴史10年が詰まっているみたいな本って無い？

0112デフォルトの名無しさん

2006/03/02(木) 05:13:36

>>111
Digital Image Processing あたりが王道じゃね。
http://www.amazon.co.jp/exec/obidos/ASIN/0130946508/qid=1141243826/sr=8-2/ref=sr_8_xs_ap_i2_xgl14/250-0188646-7989806
あれ、こんな高かったっけ。もっと安く買った記憶が・・・。

0113デフォルトの名無しさん

2006/03/02(木) 08:43:08

お、ありがとう。値段は許容範囲内。

011498

2006/03/02(木) 14:44:38

>>99
遅くなったけどサンクス

>>101
ユーザがマウスで自由に描画した曲線なので

0115デフォルトの名無しさん

2006/03/02(木) 19:01:43

particle filterまたはcondensationとか呼ばれてる手法に興味あるんだけど、このスレッドには取り扱ってる人いる？

0116デフォルトの名無しさん

2006/03/03(金) 13:59:32

取り扱ったことないから調べてみてるけど、
なんだかものすごく一般的で、解説がわけわかんない。
ttp://www.ieice.org/jpn/books/kaishikiji/2005/200512.pdf

ロボットの位置推定や物体の追跡に使われてるね。

0117デフォルトの名無しさん

2006/03/03(金) 20:25:34

photoshopのような複数のレイヤーがあって、半透明や除算などやってものを作りたいんですが
BitBltじゃできないし、独自に演算してみたら遅くなってどうもうまくいきません
Win98でも動いてるのでDrectXのようなものを使ってる様子もないですが
どうやってやってるんでしょうか？

0118デフォルトの名無しさん

2006/03/03(金) 20:31:31

これはひどい文章だな。なにをいってるかわからない

0119デフォルトの名無しさん

2006/03/03(金) 20:35:56

>>117
CreateDIBSection

0120デフォルトの名無しさん

2006/03/03(金) 20:40:40

>>119
そのレベルで直接演算してみましたピクセル単位で演算です
はっきりいって遅いです
なんだかの形でハードウェアが介在してるんだと思うんですが
私の知る限りBitBltだけじゃそこまでできませんし
知らないＡＰＩがあるんでしょうか？

0121デフォルトの名無しさん

2006/03/03(金) 20:43:53

極力演算を最適化してSIMD化してみたか？

0122デフォルトの名無しさん

2006/03/03(金) 20:52:36

xlat命令使うとそこそこ速かった希ガス

0123デフォルトの名無しさん

2006/03/03(金) 21:29:39

>>117
1. 変化があった部分だけ計算し直すようにする。
2. 表示する縮尺、表示すべき部分のみ計算するようにする
3. 高速に処理できるように考慮してコーディングする

0124デフォルトの名無しさん

2006/03/03(金) 21:45:15

AlphaBlendってＡＰＩを見つけたんですがこれは使えない？

0125デフォルトの名無しさん

2006/03/03(金) 21:49:31

2D のα付き合成をHW支援で加速してくれるAPIは
Windowsには存在しないから、安心して自分で書くべし。

コーディングに自信が無いなら、OpenGLでもDirect3Dでも使えば
HW 支援が受けられる・・・けど演算の自由度は下がるかな。

0126デフォルトの名無しさん

2006/03/03(金) 22:18:59

あせんぶっらを書く気力がありませんorz

0127デフォルトの名無しさん

2006/03/03(金) 22:19:36

>>117
ラスタオペレーションコード

0128デフォルトの名無しさん

2006/03/03(金) 23:00:37

>>116
IEICEに入ってるんでこれは読んだことあります。
一応、理論的な背景は理解してるつもりです。
が、実装するに至っては尤度の求め方で結果が大きく左右されるんで、詳しい人の意見が欲しいなぁ～と思って。
カラーヒストグラムとか輪郭形状から尤度を求める方法はいくつか見てるんですけど、それ以外のいい方法があれば論文への参照でいいんで教えてもらいたいのです。

0129デフォルトの名無しさん

2006/03/04(土) 08:29:37

2D画像の濃淡から、なめらかな「曲面」を表現したいんですけど、ベジェ曲線から勉強したほうがいいんですか？
そのへんで、いい本とかAPIをおせて。

0130デフォルトの名無しさん

2006/03/04(土) 09:52:02

>>117
欲するスピードと精度の問題。
今日び遅いなんてよっぽどスピードと精度を求めているかコンピュータが古い。

まさかDebugオプションのままコンパイルしてないよな。

0131デフォルトの名無しさん

2006/03/04(土) 15:00:45

MMX使っても最高で８倍（理論値）、実際にはたいしてかわらないという情報を発見しました
1024x748をべたにアルファブレンドすると５秒はかかります
MMXでしぼりあげたところで数百ミリいけばいいほうでしょうけど、それでも遅いです
たとえばレイヤー１０枚あったとして、リアルタイムに表示するには全部で１００ミリ
一枚あたり１０ミリ秒以下にしたい
実際Photoshopはそれ以上のスピードで描画してます
単純にMMXだけだとはとても思えないのですが？

0132デフォルトの名無しさん

2006/03/04(土) 15:10:08

計算回数はうまくすれば1～2回だし、ブレンドはビデオカードに計算任せたら？

0133デフォルトの名無しさん

2006/03/04(土) 15:24:04

５秒ってどんな遅い石のっけてんだよ。

0134デフォルトの名無しさん

2006/03/04(土) 15:24:55

はっきり言うと、コーディングが下手すぎるだけかと。

0135デフォルトの名無しさん

2006/03/04(土) 15:36:18

逆にどうコーディングするとそんなに遅くなるのかが知りたい
C++/Cでとりあえず書いた段階で10msだろ

0136デフォルトの名無しさん

2006/03/04(土) 15:37:22

計算速度が最遅のRubyで書いてもそんなに遅くはない

0137116

2006/03/04(土) 15:48:50

>>128
ググって>>116を見つけただけで、残念ながら門外漢です。

0138デフォルトの名無しさん

2006/03/04(土) 16:06:12

直接の解答ではないし
推測だらけだが
ttp://d.hatena.ne.jp/ryoko_komachi/searchdiary?word=Photoshop%a4%ce%a5%e1%a5%e2%a5%ea%c0%e1%cc%f3%b5%bb%bd%d1%a4%f2%bf%e4%c2%ac%a4%b9%a4%eb

0139デフォルトの名無しさん

2006/03/04(土) 16:16:43

基本的にレイヤーが何枚あろうが編集中（＝変化する可能性のある）レイヤーは一枚なんだから、
それ以外のレイヤーはある程度事前結合できるよな。

0140デフォルトの名無しさん

2006/03/04(土) 16:21:38

>>139
例えば下から２番目の透明度を変更すると全部書き換えです
photoshopはそこまでやっても早いです

0141デフォルトの名無しさん

2006/03/04(土) 16:24:02

3Dゲームなんてどうなってると思ってるんだ

0142デフォルトの名無しさん

2006/03/04(土) 16:48:23

>>140
その例の話だけど
まさか下から二番目より上のレイヤを全部合成し直さなきゃいけないと思ってる？

0143デフォルトの名無しさん

2006/03/04(土) 17:41:45

はい

0144デフォルトの名無しさん

2006/03/04(土) 17:56:05

>>143
レイヤとかどう扱うか全く知らないんだけど、
重なってる順に合成しないとまずいってことかな。
>>139の言ってるのは例えば5枚レイヤがあって3枚目を編集してるなら
1,2と4,5の合成はあらかじめやっておく、って風にできないの？ってことでは。

0145デフォルトの名無しさん

2006/03/04(土) 18:20:16

その場合１，２はできますけど、３，４，５は再計算しないといけませんね
３の透明度が変更されると、４の合成につかうベースの色が変わってきます

0146デフォルトの名無しさん

2006/03/04(土) 19:15:03

>>138-139
それ以前の問題かと。1024*748(768の間違い?)で5秒って時点で
MSXでも使っているのかと疑う。

0147デフォルトの名無しさん

2006/03/04(土) 20:00:20

ソース見せろ。
そんな糞パフォーマンスなんだから隠す必要も無いだろ？

0148デフォルトの名無しさん

2006/03/04(土) 20:04:04

>>138のは全部目を通しました、なるほどと思いましたよ
しかし、肝心の部分についてはうやむやで謎のままですね

>>146
MMXを使って1024x768の画像を処理するのと、>>138のようにミップマップを使うという
ものでは圧倒的に>>138のほうが早いです
だから現状のコードにけちつけても無意味だと思います

肝心な部分ってのは半透明ブレンドと微妙な倍率が出てきたときの拡大縮小にかかるコストですね
その辺に深く触れてない

0149デフォルトの名無しさん

2006/03/04(土) 20:06:43

>>147
RGBRGB配列になったデータが２枚あります
大きさと形が違うので順次処理はやってません
x,yで小さいほうのサイズで捜査してx,yをアドレスに変換RGB値のブレンドを計算
退避用のメモリへ書き込むというステップです

0150デフォルトの名無しさん

2006/03/04(土) 20:15:35

あ、ちがう
大きいほうのサイズで走査して上位レイヤーがいない座標だとそのままデータをコピーです

0151デフォルトの名無しさん

2006/03/04(土) 21:15:18

ためしに1024*768の画像2枚をαブレンドするプログラムを書いてみた。
コード上で最適化を一切していない状態で、Pentium4 2.4CGHzで実行したら
約24.2fps程度。1回あたり41ms程度。

どうやったら5秒もかかるんだ。

0152デフォルトの名無しさん

2006/03/04(土) 21:25:24

だってミニマップを使っていいのに考慮していなかった時点で浅はかでしょ。
>>148の発言から精度を殆ど無視していい事が分かったので、どう頑張っても5秒かからない。
例え回答者が考慮していなかった事情があったとしても説明しようとしない。質問がなってない。

それにミニマップはリアルタイム用の処理だから、最終画像に落とす時点で必ず5秒待たされるよ。

0153デフォルトの名無しさん

2006/03/04(土) 21:49:46

>>151
それは任意サイズや多角形マスクも考慮してやってますか？

0154デフォルトの名無しさん

2006/03/04(土) 22:09:03

>>152
ミニマップが有効なのはぴったり規定サイズのときだけですけどね

0155デフォルトの名無しさん

2006/03/04(土) 22:15:40

>>153
任意サイズやマスクのせいで遅いなら、見るべきはαの処理じゃないよね。
拡大縮小アルゴリズムとマスク処理は何を使ってどう書いているの。

0156デフォルトの名無しさん

2006/03/04(土) 22:38:08

いやだからアルゴリズム違いを突き詰めたってたいしてかわらんでしょ

0157デフォルトの名無しさん

2006/03/04(土) 23:06:00

埒が開かないな。
もっともっと細かくどの部分にどれだけの時間がかかるか調べたら？
5秒もあればボトルネックをはっきり特定できるでしょ。

0158デフォルトの名無しさん

2006/03/04(土) 23:11:52

ボトルネックというか求める速度は単純にもろもろ判定処理を除いた41msですら遅いです
それこそ1msとかのレベルじゃないと拡大やマスクやGDI描画にかかるコストの総和になってくるので
どこがネックかといえば拡大とブレンドですね
これをなんとかして2msくらいまでおさえたい

0159デフォルトの名無しさん

2006/03/04(土) 23:41:29

つーか使用しているマシンスペックは？
それと現時点で各処理にどのくらいかかっているか、
とかもっと具体的に書かないとこれ以上アドバイスしようが無いと思う。

0160デフォルトの名無しさん

2006/03/04(土) 23:51:40

Photoshopが1msで処理してるって信じてるなんてアホちゃう

0161デフォルトの名無しさん

2006/03/04(土) 23:53:57

私の求めてるのはちまちました速度アップではありません
そんなものは気が向いたらやります
>>138のように劇的なものを求めてるだけです
>>138のだけではすべてがそろいません
アルファブレンドされた１０枚の壁紙サイズの合成画像をマスク処理もやってです拡大縮小もです
操作が行われてから100msでください
操作とは倍率変更、透過率変更、色変更、移動などがあります
すべての操作において100msです
アルゴリズムの工夫だけでは不可能です
>>138のような手法がほしいです
>>138だけでは全体像が見えないです

0162デフォルトの名無しさん

2006/03/04(土) 23:54:37

要求する仕様と現状のソースと速度の測定環境晒してみ

0163デフォルトの名無しさん

2006/03/05(日) 00:00:41

wxWidgetsなんでさらしても多分理解してもらえませんｗ
内部でなにをやってるかは全部把握してるので私はわかりますが
今やってるのが元のサイズのままでアルファブレンドで画像を作ります
これは変更があったときだけ
W_PAINTにこの画像を拡大縮小してBitBltです
拡大縮小は早いですよかなりね
ブレンド方法は>>149に書いたとおり
ブレンドとマスクは同時にやってます
これが更新時だけですが５秒近いです

0164デフォルトの名無しさん

2006/03/05(日) 00:11:50

wxWidgetsのスレ池やアホか。スレ違いじゃ

0165デフォルトの名無しさん

2006/03/05(日) 00:15:15

ぜんぜんスレ違いじゃありません
wxWidgetsはWindowsネイティブをラップしてるだけで内部はまったく同じです
アルファブレンドをMFCやSDIやBCCで実装するのにそれぞれのスレにいかないといけないんですか？

0166デフォルトの名無しさん

2006/03/05(日) 00:18:45

なら別にwxWidgetつかってようがなんだろうが理解されないってことはないな。
お前脳味噌腐ってる？

0167デフォルトの名無しさん

2006/03/05(日) 00:21:59

例えば拡大縮小は
wxImage::Scale(w,h)
って書くだけです
画素情報は
wxImage::GetRed(x,y)
です
unsingned char * wxImage::GetData()
もあります
こんな羅列書いて理解できますか？

0168デフォルトの名無しさん

2006/03/05(日) 00:25:23

問題を切り分けられるようになってからおいでください

0169デフォルトの名無しさん

2006/03/05(日) 00:25:52

そんなAPI経由でアルファブレンド処理してるんだとしたらその時点で阿呆スギ

0170デフォルトの名無しさん

2006/03/05(日) 00:28:54

いま適当にJavaでXGAサイズで10枚、アルファブレンドしてついでに
アフィン変換してみたけど、100msなんて余裕だな。

0171デフォルトの名無しさん

2006/03/05(日) 00:30:02

for(i=0;i<layers;i++){
for(x=0;x<dest.GetWidth();x++){
　　　for(y=0;y<dest.GetHeight();y++){
image = layer[i];
mask = layermask[i];
　　　　　if(!INRECT(mask,x,y))continue;
if(!INRECT(image,x,y)continue;
if(mask.GetRed(x,y){
　　　　　　 int r = dest.GetRed(x,y) ...................
　　　　　　　int g
　　　　　　　int b
dest.SetRGB(x,y,r,g,b);
}
}
}

ざっと書くとこんな感じ

0172デフォルトの名無しさん

2006/03/05(日) 00:31:14

>>170
専用クラスですか？

0173デフォルトの名無しさん

2006/03/05(日) 00:32:14

てかVGAってちっちぇーよｗ

0174デフォルトの名無しさん

2006/03/05(日) 00:32:50

誤爆ですｗ

0175デフォルトの名無しさん

2006/03/05(日) 00:37:46

>>171
ふつーはな、単なるunsigned char[]あたりに画像展開してそこで全部の処理を済ませてから最後の表示だけAPIでやる。
まぁ、WindowsならDIBSectionとか使うが。

0176デフォルトの名無しさん

2006/03/05(日) 00:52:28

やっぱwxWidgetsが遅いんじゃねーの。スレ違いだって

0177デフォルトの名無しさん

2006/03/05(日) 01:00:48

>>175
GetDataメソッドでポインタはとれるよ
内容は[RGBRGBRGB]ね
ふつーははわかるがそうすることで劇的に早くなるとは思えないわけですが
せいぜい２倍とかじゃないですかね？足りませんよ？

0178デフォルトの名無しさん

2006/03/05(日) 01:02:47

>>176
GetRed毎に座標をポインタに計算してunsigned char をreturnしてるだけです

0179デフォルトの名無しさん

2006/03/05(日) 01:04:17

1ピクセルごとにINRECTとか間抜けなことやるな。
事前に矩形の重ね判定やって必要な部分だけループ回せ。

0180デフォルトの名無しさん

2006/03/05(日) 01:06:00

>>179
そうすれば１０枚100msいけますか？

0181デフォルトの名無しさん

2006/03/05(日) 01:09:12

171の内容、どっからつっこんでいいかわからん......
とりあえずレイヤ一枚に対していちいちウィンドウシステム側の
バッファをワークエリア代わりにするのやめれ。

0182デフォルトの名無しさん

2006/03/05(日) 01:10:22

ワークエリア専用クラスですｗ

0183デフォルトの名無しさん

2006/03/05(日) 01:11:08

素直にGetRed()、SetRGB()辺りが遅いんじゃないかと思われ。

0184デフォルトの名無しさん

2006/03/05(日) 01:12:10

>>183
それはわかってるけど100msはいかないでしょ？

0185デフォルトの名無しさん

2006/03/05(日) 01:13:25

>>183
釣りじゃないとするとそうとしか考えられないよね。
処理速度上げたいっていうなら自分でメモリ確保して、ポインタでループまわしたらいいのに。

0186デフォルトの名無しさん

2006/03/05(日) 01:13:54

wxWidgetsが速いとか遅いとかいう以前に使う奴に最適化に関する知識が０なのが原因だろう。

0187デフォルトの名無しさん

2006/03/05(日) 01:16:16

　　　　　　,.ｨ , - ､.＿　　　、
.　　　　 ,ｲ/ l/　　　　￣￣｀ヽ!__
　　　ﾄ/ |'　{　　　　　　　　　　｀ヽ.　　　　　　　　　　　 ,ﾍ
　　Ｎ│ ヽ. `　　　　　　　　　　ヽ　　　　　 /ヽ　/　 ∨
　　 N.ヽ.ヽ、　　　　　　 ,　　　　　 }　　　　l＼/　　`′
.　　ヽヽ.＼　　　　　　 ,.ｨｲﾊ　　　　　 |　　＿|
　　ヾニｰ　__　_　-=_彡ｿﾉ u_＼ヽ、　 |　　＼　　　レイヤーが数百枚だとか
.　　　￣ﾞr=<‐ﾓﾐ､ﾆr;＝=ｪ;ｭ＜_ゞ-=7´ヽ　　　>　　　CPUが486とかいうオチの
.　　　　　 l 　￣ﾘーh ｀ｰ‐‐'　l‐''´冫)'./　∠__　　釣りだったんだよ！
　　　　　　ﾞiｰ- ｲ'__　ヽ､..＿__ノ　　ﾄr‐'　　　　/　　　
　　　　　　　l　　 `＿__,.、　　 u　./│　　　　/＿　
.　　　　　　ヽ.　 }z‐r--|　　　／　ﾄ,　　　　　 |　 ,、
　　　　　　　 >､`ｰ-- '　　.／　／　|ヽ　　　　　l／　ヽ　　 ,ﾍ
　　　　　　_,.／| ヽ`ｰ--‐ _´.. ‐''´ 　 ./　＼､　　　　　　　＼/　ヽ/
-‐ '''" ￣ /　 :| 　 ,ゝ=＜　　　　　　/　　　 |　`'''‐-　､.._
　　　　　/　　 !.／l;';';';';';';＼　　　 ./　　　　│ 　＿
　　　 _,＞ '´|l. ﾐ:ゝ､;';';_/,´＼　 ./|._ , --､　|　i´!⌒!l　 r:,＝i 　　
.　　　 | 　　 |:.l.　/';';';';';|=　　ヽ/:.|　.|l⌒ｌｌﾆ._ | ﾞｰ=':|　|. L._｣　））
　　　 l.　　 |:.:.l./';';';';';';'!　　 /:.:.| i´|.ｰ‐' | /　|　　 |.　!　　 l
.　　　　 l.　　 |:.:.:.!';';';';';';';'|　　/:.:.:.:!.|"'|.　　 l'　 │-==:|.　!　==l　　 ,. -‐;
　　　　　l　　 |:.:.:.:l;';';';';';';';|　/:.:.:.:.:| i＝!ｰ=;: l　　 |　　 l.　|　　 |　/ 　 //
　　　　 l　　|:.:.:.:.:l;';';';';';';'|/:.:.:.:.:.:.!│　l　　 l、　:|　　 |　}　＿|,.{::　　7　））
　　　　 l　 |:.:.:.:.:.:l;';';';';'/:.:.:.:.:.:.:.:|　|__,.ヽ､__,. ヽ._｣ｰ=:::ﾚ'　 ::::::|;　　 7
.　　　　　　l　|:.:.:.:.:.:.l;';';'/:.:.:.:.:.:.:.:.:.|.　＼:::::＼:::::　ヽ　 ::::::!′　:::| 　 .:/
.　　　　　　ｌ |:.:.:.:.:.:.:∨:.:.:.:.:.:.:.:.:.:.:.! 　 /ヽ:::　`:::　　　　::::　　....::....／　

0188デフォルトの名無しさん

2006/03/05(日) 01:16:55

xのループを外側に持ってくるやつとは話したくないなあ。

0189デフォルトの名無しさん

2006/03/05(日) 01:17:17

>>186
論点は100msオーダーを出す方法ですよ
最適化うんぬんは関係ありません
速度把握するために組んだコードなので最適化されてなくて当然です
まず組んでみて最適化したときの速度を予測します
いきなり最適化からはいるとデバッグ作業で何倍も時間を使います
そこで私なりに予測した結果この方法で100msオーダーは出せないという結論になったから
ここで質問してるわけです
経緯を説明するとこんな感じです

0190デフォルトの名無しさん

2006/03/05(日) 01:18:58

>>188
ぜんぜん話題がそれるけど、画像処理は走査線を意識してやる人が多いからxが内側でコーディングする人の方が多いよ

0191デフォルトの名無しさん

2006/03/05(日) 01:20:40

>>188
ああ、今書いたから外側になってるわｗ

0192デフォルトの名無しさん

2006/03/05(日) 01:27:20

どこが遅いのか把握できてないのに駄々をこねる厨がいるスレはここですか？

0193デフォルトの名無しさん

2006/03/05(日) 01:27:31

だってCPUも書いてないから比較のしようがないじゃん。いい加減消えろよ

0194デフォルトの名無しさん

2006/03/05(日) 01:32:25

ゆとり教育の弊害が画像処理スレッドにも・・・

0195デフォルトの名無しさん

2006/03/05(日) 01:32:30

Javaで100ms余裕だと言った人は結局どこへ？
その最適化したほうほうで100ms余裕だというのなら私にはそれをためす価値が出てくるわけですよ
使ってる平均的なものならね
多少高くでも１Gｈｚあたりでどうなるかくらい想像がつくでしょ
1GHxで100msです！！
えーっとCeleronにしといてｗ

0196デフォルトの名無しさん

2006/03/05(日) 01:35:07

JavaってなんだかんだいってもOpenGL実装しちゃってますからね
その辺詳しく

0197デフォルトの名無しさん

2006/03/05(日) 01:35:22

教える価値がない

0198デフォルトの名無しさん

2006/03/05(日) 01:36:42

>>197
なんだロジックを否定したいがためだけにここにいたんですか？ｗ

0199デフォルトの名無しさん

2006/03/05(日) 01:39:45

もういなくなるから安心しろ

0200デフォルトの名無しさん

2006/03/05(日) 01:42:21

語尾にｗ付き出したし釣り or 宿題確定な気がするが。

MMX以外の今まで言われたことをこなしてから出直してこい。

0201デフォルトの名無しさん

2006/03/05(日) 01:43:34

250x250程度の2枚の画像を回転させながら130枚くらい合成するのにCeleronM1.4GHｚで1秒弱程度。
DIBSectionを直接アクセスするけど、特に最適化なし。
多分、もまいのコードは遅すぎだと思われ。

0202デフォルトの名無しさん

2006/03/05(日) 01:57:01

>>201
ありがとう
そこまで実測値だしてくれると説得力がありますね
糸口が見つかりました

0203デフォルトの名無しさん

2006/03/05(日) 02:00:19

>>202
　　　　　　,.ｨ , - ､.＿　　　、
.　　　　 ,ｲ/ l/　　　　￣￣｀ヽ!__
　　　ﾄ/ |'　{　　　　　　　　　　｀ヽ.　　　　　　　　　　　 ,ﾍ
　　Ｎ│ ヽ. `　　　　　　　　　　ヽ　　　　　 /ヽ　/　 ∨
　　 N.ヽ.ヽ、　　　　　　 ,　　　　　 }　　　　l＼/　　`′
.　　ヽヽ.＼　　　　　　 ,.ｨｲﾊ　　　　　 |　　＿|　　
　　ヾニｰ　__　_　-=_彡ｿﾉ u_＼ヽ、　 |　　＼　　　当たり前のことをやってから
.　　　￣ﾞr=<‐ﾓﾐ､ﾆr;＝=ｪ;ｭ＜_ゞ-=7´ヽ　　　>　　　でかい口叩きやがれ！！
.　　　　　 l 　￣ﾘーh ｀ｰ‐‐'　l‐''´冫)'./　∠__　　　相手してくれた全員に
　　　　　　ﾞiｰ- ｲ'__　ヽ､..＿__ノ　　ﾄr‐'　　　　/　　　誤れ！！！！
　　　　　　　l　　 `＿__,.、　　 u　./│　　　　/＿　
.　　　　　　ヽ.　 }z‐r--|　　　／　ﾄ,　　　　　 |　 ,、
　　　　　　　 >､`ｰ-- '　　.／　／　|ヽ　　　　　l／　ヽ　　 ,ﾍ
　　　　　　_,.／| ヽ`ｰ--‐ _´.. ‐''´ 　 ./　＼､　　　　　　　＼/　ヽ/
-‐ '''" ￣ /　 :| 　 ,ゝ=＜　　　　　　/　　　 |　`'''‐-　､.._
　　　　　/　　 !.／l;';';';';';';＼　　　 ./　　　　│ 　＿
　　　 _,＞ '´|l. ﾐ:ゝ､;';';_/,´＼　 ./|._ , --､　|　i´!⌒!l　 r:,＝i 　　
.　　　 | 　　 |:.l.　/';';';';';|=　　ヽ/:.|　.|l⌒ｌｌﾆ._ | ﾞｰ=':|　|. L._｣　））
　　　 l.　　 |:.:.l./';';';';';';'!　　 /:.:.| i´|.ｰ‐' | /　|　　 |.　!　　 l
.　　　　 l.　　 |:.:.:.!';';';';';';';'|　　/:.:.:.:!.|"'|.　　 l'　 │-==:|.　!　==l　　 ,. -‐;
　　　　　l　　 |:.:.:.:l;';';';';';';';|　/:.:.:.:.:| i＝!ｰ=;: l　　 |　　 l.　|　　 |　/ 　 //
　　　　 l　　|:.:.:.:.:l;';';';';';';'|/:.:.:.:.:.:.!│　l　　 l、　:|　　 |　}　＿|,.{::　　7　））
　　　　 l　 |:.:.:.:.:.:l;';';';';'/:.:.:.:.:.:.:.:|　|__,.ヽ､__,. ヽ._｣ｰ=:::ﾚ'　 ::::::|;　　 7
.　　　　　　l　|:.:.:.:.:.:.l;';';'/:.:.:.:.:.:.:.:.:.|.　＼:::::＼:::::　ヽ　 ::::::!′　:::| 　 .:/

0204デフォルトの名無しさん

2006/03/05(日) 02:03:39

64x64のグレイ画像を10段ほどのフィルタリング処理して結果をリファレンスと比較するってループを
ざっと千万回ほど繰り返すと流石に数十分掛かるけどこれってアルゴリズムを見直せば速くなりますか?w

0205デフォルトの名無しさん

2006/03/05(日) 02:04:57

なります。

0206デフォルトの名無しさん

2006/03/05(日) 02:05:16

たいして実績もないのに便乗して言ってただけだから
具体的数字をだせと何度言ってもけむにまくばっかりだし
誤る？！必要性がないｗ

0207デフォルトの名無しさん

2006/03/05(日) 02:05:16

wxWidgetsがどんなもんか知らんけど、Get???(x,y)内部で入力範囲を検査したり、インライン関数になってなかったりするんじゃない？
そうだとしたら、直接アクセスするのと比べてかな～り遅くなるべ。

0208デフォルトの名無しさん

2006/03/05(日) 02:07:36

調べたらアルファブレンド事態の計算式を工夫する方法があったよ
a + (a -b) x apha
こっちのがでかいんじゃないかね？

0209デフォルトの名無しさん

2006/03/05(日) 02:09:26

>>206
>>201　=　>>203　だし。
>>201のコードの内容は、>>171が出た後にみんなが言ってるぐらいしかやってないんだよね。
当たり前のことをやってからでかい口きけと。

0210デフォルトの名無しさん

2006/03/05(日) 02:10:12

最初から言えばいいじゃんｗ

0211デフォルトの名無しさん

2006/03/05(日) 02:11:15

ｷﾀｺﾚ
恩を仇

0212デフォルトの名無しさん

2006/03/05(日) 02:14:51

>>189
5秒もかかるからなんとかしてくれって話じゃなかったの？
ヘタな釣りだな。釣られたけど。

0213デフォルトの名無しさん

2006/03/05(日) 02:18:23

>>212
100msは目標ですよ。
機能性文盲ですか？

0214デフォルトの名無しさん

2006/03/05(日) 02:19:35

今から組んでみるからまってくれｗ

0215デフォルトの名無しさん

2006/03/05(日) 02:25:05

改めてスレを見直して吹いた
ピクセルにアクセスするのにGetなんとか使ってる癖に>>131でMMXとか書いてるよｗｗｗ
ほんとになんも知らないんだな
チキショウ！釣りだといってくれｗｗハライテー

0216デフォルトの名無しさん

2006/03/05(日) 02:30:23

>>204
繰り返しの回数減らせばいいんじゃね。

0217デフォルトの名無しさん

2006/03/05(日) 02:49:31

VCが壊れたorz

0218デフォルトの名無しさん

2006/03/05(日) 02:52:44

int x,y,w,h;
grr_layer layer = m_layerlist[idx];
x = y = 0;
w = dest.GetWidth();
h = dest.GetHeight();
if(x < layer.m_x){
x=layer.m_x;
w = w - x;
}
if(y < layer.m_y){
y=layer.m_y;
h = h - y;
}
if(x + w > layer.m_x + layer.m_image.GetWidth())w = layer.m_x + layer.m_image.GetWidth() - x;
if(y + h > layer.m_y + layer.m_image.GetHeight())h = layer.m_y + layer.m_image.GetHeight() - y;

unsigned char *ptr_dest = dest.GetData();
unsigned char *ptr_image = layer.m_image.GetData();
unsigned char *ptr_mask = layer.m_mask.GetData();

ptr_dest += y * dest.GetWidth() * 3 + x * 3;
int ix = x - layer.m_x;
int iy = y - layer.m_y;
ptr_image += iy * layer.m_image.GetWidth() * 3 + ix * 3;
ptr_mask += iy * layer.m_image.GetWidth() * 3 + iy * 3;

int span_dest = dest.GetWidth() - (x + w) + x;
int span_image = layer.m_image.GetWidth() - (x + w) + x;
span_dest*=3;
span_image*=3;

0219デフォルトの名無しさん

2006/03/05(日) 02:53:17

int i,j,k;
for(i=y;i<=y+h;i++){
for(j=x;x+w;j++){
if(*ptr_mask){
for(k=0;k<3;k++){
int v = ptr_image[k] + (ptr_dest[k] - ptr_image[k]) * alpha;
}
}
ptr_dest+=3;
ptr_image+=3;
ptr_mask+=3;
}
ptr_dest += span_dest;
ptr_image += span_image;
ptr_mask += span_image;
}

これでいいだろｗ
コンパイラがいかれたｗ

0220デフォルトの名無しさん

2006/03/05(日) 02:57:22

>>219
厨の相手乙。素直なコードだとおもた。

VCがどうした？

0221デフォルトの名無しさん

2006/03/05(日) 03:01:06

>>220
厨が書いたコードですが何か？ｗ

0222デフォルトの名無しさん

2006/03/05(日) 03:02:54

>>189
いまさらだけど君ながらの予測がおかしいでFAじゃね？

ちまちました最適化のひとつが速度を2倍に上げるとわかったら
そんな方法を10個並べればktkr！っていうのが基本だから、
何かひとつのブレイクスルーですっきり速度100倍なんて期待しない方がいいよ。

0223デフォルトの名無しさん

2006/03/05(日) 03:03:41

>>221
で、100ms秒切った？

0224デフォルトの名無しさん

2006/03/05(日) 03:07:38

>>222
速度が倍になる最適化10個並べたら1024倍高速になるぞ。

0225デフォルトの名無しさん

2006/03/05(日) 03:11:45

1024倍までは無理でも5秒が50msになったら100倍だな。

0226デフォルトの名無しさん

2006/03/05(日) 03:13:23

>>224
何か問題でも？

0227デフォルトの名無しさん

2006/03/05(日) 03:18:38

>>223
ソースバグいっぱいあったけど
切った切ったｗ

0228デフォルトの名無しさん

2006/03/05(日) 03:19:53

最適化スレ逝け

0229デフォルトの名無しさん

2006/03/05(日) 03:20:59

もうちょっといろいろ負荷かけてみますｗ

0230デフォルトの名無しさん

2006/03/05(日) 03:25:53

まあがんがれ。

描画にも20msかかるとか。
ttp://diarynote.jp/d/35749/20051213.html
いや、全く違う話ならｽﾏｿ。

0231デフォルトの名無しさん

2006/03/05(日) 03:28:24

やっぱ１０枚くらいかさねると１秒くらいかかるｗ

0232デフォルトの名無しさん

2006/03/05(日) 03:31:24

>>230
はなからwxBitmapにすることもできるのでその辺はなんとかなります

0233デフォルトの名無しさん

2006/03/05(日) 03:55:28

for(i=y;i<=y+h;i++){　＊A
　for(j=x;x+w;j++){　＊A
　　if(*ptr_mask){
　　　for(k=0;k<3;k++){　＊B
　　　　int v = ptr_image[k] + (ptr_dest[k] - ptr_image[k]) * alpha;
　　　}
　　}
　　ptr_dest+=3;
　　ptr_image+=3;
　　ptr_mask+=3;
　　}
　ptr_dest += span_dest;
　ptr_image += span_image;
　ptr_mask += span_image;
}

＊A　初期値、終了条件、増分の演算をポインタで行いましょう。
＊B　ループを展開しましょう
･･･この程度のことはコンパイラがやるんで、これ以上の最適化はSIMD命令に挑戦しましょう。

0234・∀・）っ-○●◎- ◆Pu/ODYSSEY

2006/03/05(日) 04:44:29

wx使ってるのはクロスプラットフォームにしたいから？
それともVC++やBCB製品版が高いから？

0235デフォルトの名無しさん

2006/03/05(日) 12:42:49

>>231
くどいようで巣漫画、どこで時間を浪費してるか細かく推測しろ。
せめてループの中か外か。2枚を10枚にするときに他に増えてる処理とか。
「よくわからんが、このやり方じゃ遅いよママン！」では話にならんｗ

もうひとつ。
wxWidgetsや他のでもいいけど同様の処理をしてるプログラムを
くまなく探した？

0236デフォルトの名無しさん

2006/03/05(日) 13:32:59

>>234
高いからってのもあるし、クロスにしたいってのもある
クロスを維持したままアセンブラ入れるとなるとこれは日と手間ですねｗ
あとwxWidgetsはほとんどの画像形式をたった２行でRGB配列に変換できるし
メモリ管理を気にしないですむからMFCより画像処理は優秀だよ
もとからRGB配列で管理してるからCreateDIBより高速だしね

>>235
アルファブレンドが高速になったからこんどは拡大縮小や更新範囲がネックになってきた
かなり手をいれないといけないｗ
一応さがしたというか、wxWidgetsはグラフィック処理の特別なアルゴリズム実装はほとんど持ってない
完成品でグラフィック系のものは見つからなかったね
もともとドキュメント資料がほとんど皆無だしねｗ

0237デフォルトの名無しさん

2006/03/05(日) 14:29:46

>>236
いや、wxWidgetに関係なく速く動いてるソースを持ってきて、
あとは特有の処理が必要な部分だけ書きなおせばいいでしょ。
完成品でなくてもその部分だけで十分だし。

wxWidgetが内部で何してるか把握してるんだから
速度の見積もりも含めて簡単だよｗ
がんがれ。

0238デフォルトの名無しさん

2006/03/05(日) 22:33:57

いくらなんでも、こりゃ釣りじゃないの？
高速化なんて、まずアルゴリズムを考えて、あとは地道にやって行くしか
ないことは、普通のプログラマなら誰でも知ってるだろ。

ただ、もし本気で言っているなら、あなたに高速化は無理だ。
計測→高速化、を繰り返して地道にツブしていくのが本質だから。

αブレンドなんて、処理自体は単純だし、枯れてるわけだから、
ソフトウェアでそれを行うためのアルゴリズムに画期的なものがあるわけじゃない。
例えば、ＭＭＸで最高８倍だからムダなんて事はない。
もちろん問題によっては（細かい領域を毎回関数を呼び出して転送し、その中だけ
ＭＭＸで記述しているような場合）EMMSによるオーバーヘッドが多すぎて
役に立たないだろうけれど、1024x768の領域の転送なら十分役に立つよ。
試しに、PIII-1G でMMXのコードを書いてみた。パイプラインは特に考慮しないで、
1024x768(32bit BMP) １枚のブレンドに最悪（転送のない部分がない状態）で
10ms くらいだよ。通常は透明な部分があるので、5ms-7msくらいだろう。

ま、地道にがんがれ。

0239デフォルトの名無しさん

2006/03/05(日) 23:06:59

これまでのスレで画像処理すげーと思ったやつ。
他に何かないですか？
ttp://www.cs.huji.ac.il/~yweiss/Colorization/
ttp://www.cse.ucsc.edu/~milanfar/SR/sr-examples.htm

0240デフォルトの名無しさん

2006/03/06(月) 00:09:00

MMXもDNowもできれば使いたくないな

0241・∀・）っ-○●◎- ◆Pu/ODYSSEY

2006/03/06(月) 00:12:29

EMMSっていちいち関数抜けるたびにやる必要ないよ。
x87のオペレーション使う前にMMステートが確実にクリアされてればいい。
MS C/C++コンパイラならコンパイル時に警告してくれるしね。

0242デフォルトの名無しさん

2006/03/06(月) 02:11:45

sage

0243デフォルトの名無しさん

2006/03/06(月) 02:15:10

まあ、MMX使うほど速度にシビアな処理で、インライン展開されない関数呼び出しとかやる奴は無条件ではったおしていいと思うが。

0244デフォルトの名無しさん

2006/03/06(月) 03:20:25

>>239
俺はこれも感動した。
ttp://autotrace.sourceforge.net/
ttp://potrace.sourceforge.net/

ただ、potraceのサンプルのepsファイルをDLしても
上手く開けなかったが…

このスレで見たわけじゃないけど、俺は↓も結構好き。
ttp://scale2x.sourceforge.net/
ttp://www.hiend3d.com/hq2x.html
どちらも、色数少なめの低解像度画像をリアルタイムで
綺麗に拡大するアルゴリズム。

何か面白い使い道ないか考え中。
ちなみに、写真に適用してみたら全然駄目だった。

0245デフォルトの名無しさん

2006/03/06(月) 07:45:41

＞ttp://www.hiend3d.com/hq2x.html
これはなかなかオって思ったけど、2倍とか切りの良い数字意外に適用できるのか？
サンプル画像には1.1倍や微妙に回転などが残念ながら見当たらなかった。

あと、フォトショが速いって言ってる上の奴だけど、前提が
間違ってるんじゃない？　フォトショは全画面更新するケース
ではかなり遅いよ。場合によっちゃ目に見えるくらい。

編集中はストレスにならないように更新したペンの周囲だけ
計算してるだろうから、レイヤーが重なりまくっててもそう
負担にならないだけだろ。ペンのサイズを極端に大きくすれば
更新しているティアリング（横に切れる奴）が見える場合もある。

それとレイヤーが12345(5が上)の場合、3を更新したとき12は
あらかじめ計算できるけど45もあらかじめやっとけって言うのは
知識の無い奴の言ってることなのか？　45が計算し直しなのは
そちらが正しい。

あらかじめ45を計算できる手法があったら俺も知りたいもんだ。
4が不透明な場合以外は計算し直しになるだろ。

0246デフォルトの名無しさん

2006/03/06(月) 09:15:28

>>245
Scale2xもhq2xも整数倍の拡大のみ。
ちなみにScale2xの方は色数を増やさず、元の色のまま変換する。

Scale2xはソースを見るまでもなく、Algorithmってページを見れば
30秒で理解できるような簡単な処理。

0247デフォルトの名無しさん

2006/03/06(月) 10:14:52

>>245
> あらかじめ45を計算できる手法があったら俺も知りたいもんだ。
なんかできそうだぞ。

　α*上の画像 + (1 - α)*下の画像
の dest を１つずつ下のレイヤにしていけばいいわけだろ？
で、構文木を再帰で生成させて出力したのを観察して、手でまとめたのが下。
　x0*a0
+ x1*a1*(1 - a0)
+ x2*a2*(1 - a0 - a1*(1 - a0))
+ x3*a3*(1 - a0 - a1*(1 - a0) - a2*(1 - a0 - a1*(1 - a0)))
+ x4* (1 - a0 - a1*(1 - a0) - a2*(1 - a0 - a1*(1 - a0)) - a3*(1 - a0 - a1*(1 - a0) - a2*(1 - a0 - a1*(1 - a0))))

x4 は、12 を合成したもの。
で、3 を編集中に変更があるのは、a3 と x3。
αがピクセル単位じゃなければ割といいんじゃない？
合成が加算になるのもポイント高いかもよ？

って、実は試してないんだｗ
構文木出力にバグがあったり、手でまとめるときにミスしてたらゴメンｗ
「知識の無い奴」なんて言ったんだから、責任もって検算か反証してくれるよねｗ

0248デフォルトの名無しさん

2006/03/06(月) 10:36:33

でもさ、先に計算しておくって・・・
1+2と1+2+3と1+2+3+4と、とか、全部用意しとかないと意味無いと思うんだけど、
そういうもん？

0249デフォルトの名無しさん

2006/03/06(月) 12:06:52

さすがに現在使ってるレイヤくらいはわかってるだろ

0250デフォルトの名無しさん

2006/03/06(月) 12:12:49

なるほど　ゴミレスすまんかった

0251デフォルトの名無しさん

2006/03/06(月) 14:29:22

>>247
計算コストが変わらない気がするんだがｗ

0252デフォルトの名無しさん

2006/03/06(月) 14:36:50

変なのがいついちゃったな･･･

0253デフォルトの名無しさん

2006/03/06(月) 18:09:53

>>274
複数枚のαブレンドを展開したら大体そんな式になるけど、
その式でa2が変化したら、その下にみんな影響するだろ

数字が12345から01234とずれてるので後のに倣うが、
a2が変化した時に計算しなおさなくて済むのは01の段
だけじゃないか。

共通部分が多少使えても34の部分をあらかじめ計算しておけるの
とはニュアンスが違う。若干計算が工夫できるだけで、その式自体
が2以降の合成はやり直しだって証明してる。

0254デフォルトの名無しさん

2006/03/06(月) 18:40:30

>>247だった

0255デフォルトの名無しさん

2006/03/06(月) 19:03:40

あれから更新タイミングを工夫したり、範囲を工夫したら実用速度になりました
これでやっと先に進めます
ありがとうございました

>>247宛てではありませんｗ

0256デフォルトの名無しさん

2006/03/06(月) 19:37:39

変なのがようやく去るな･･･

0257デフォルトの名無しさん

2006/03/06(月) 20:14:18

>>244
下のやつ面白いね。
セガが作ってるメガドライブのエミュで使われてるやつかな。

最近のcodecはglobal動き補償というのをやってるみたいだけど
具体的にどうやっているかわかる方いますか？
カメラの動きを推定してるのかな
ttp://en.wikipedia.org/wiki/Motion_compensation

0258デフォルトの名無しさん

2006/03/06(月) 22:44:37

>>253
>>>274
> 複数枚のαブレンドを展開したら大体そんな式になるけど、
> その式でa2が変化したら、その下にみんな影響するだろ
ブレンドレートがピクセルごとじゃなくてレイヤ毎なら、計算量は極端に小さいだろ？

> 数字が12345から01234とずれてるので後のに倣うが、
（略）
> が2以降の合成はやり直しだって証明してる。
おまえさ、
　x0*a0
+ x1*a1*(1 - a0)
+ x2*a2*(1 - a0 - a1*(1 - a0))
+ x3*a3*(1 - a0 - a1*(1 - a0) - a2*(1 - a0 - a1*(1 - a0)))
+ x4* (1 - a0 - a1*(1 - a0) - a2*(1 - a0 - a1*(1 - a0)) - a3*(1 - a0 - a1*(1 - a0) - a2*(1 - a0 - a1*(1 - a0))))
の an の隣の括弧全体をを An と書き換えたとき、
A0 = (1 - 0)
A1 = (A0 - a0*A0)
A2 = (A1 - a1*A1)
A3 = (A2 - a2*A2)
になることわかってる？
だいたい、a2 を変更するなら、x3 x4 を合成してそれを一番下と扱えよ。

あと、
> x4 は、12 を合成したもの。
こんなこと言って上下逆にしたのは謝る。

0259デフォルトの名無しさん

2006/03/07(火) 00:02:57

＞ブレンドレートがピクセルごとじゃなくてレイヤ毎なら
まずこれがありえねー

それはともかく、a2変えたらx3,x4の合成は計算しなおしだろ。
単に式に共通部分があるってだけで、x3,x4を事前にx0,x1のように
固定値に出来るわけじゃない。

0260デフォルトの名無しさん

2006/03/07(火) 01:16:27

その、知識が無いのにあらかじめ計算できない？って言ってみた俺が来ましたよ。
イヤミではなく本当に知識不足だから、穏便によろしく。

> ブレンドレートがピクセルごとじゃなくてレイヤ毎なら
まずこれがわかんねー

>>259
> a2変えたらx3,x4の合成は計算しなおしだろ

式の共通部分で、変更に関与しない部分は予め計算しておけるって話。
今のやり方が>>258の上の方の式を毎回計算してるなら、
ある程度まとまった項を保持しておいて必要に応じて再計算すれば
平均で2倍くらいは速くなりそうな予感。

0261デフォルトの名無しさん

2006/03/07(火) 01:27:14

つまり、A0やらA1の計算はa1には関係無いでしょってことで。
先にA1を計算して保持しとけばa1が変わったときのA2の計算も
A2 = (1 - a0 - a1*(1 - a0) - a2*(1 - a0 - a1*(1 - a0)))
ではなく
(A1 - a1*A1)
で終了。

何か根本的な誤解があったらすまん。

0262デフォルトの名無しさん

2006/03/07(火) 08:00:21

まあいいや、オレの負け
式の変形のところは解説してもらわなくても理解してるよ。

その考えでプログラム組んで順番にαブレンドするより
速くなったら報告してくれ。

(A1 - a1*A1)←これ自体が順番にαブレンドした時のシチュエーションに近い
と思うがどうか？

＞何か根本的な誤解があったらすまん。

オレの言いたいことはレイヤーが

下1234 5 6789上

ってあったとき、５を変更したら1234は計算済みのものが
１プレーンにまとめておけるけど、 6789 はそうできない
ってこと。 1234 と 6789 の計算軽減量が同じじゃないって
ことは分かるよね？

そのくらい出来ないと（話はそれるが）、6789の計算を軽減するために
保持しておかなきゃいけないバッファ量とか考えてもコストが軽くなる
見込みは薄いと思う。

0263デフォルトの名無しさん

2006/03/07(火) 08:10:46

6789も出来るだろ

0264デフォルトの名無しさん

2006/03/07(火) 08:37:51

わからん、まじでわからん

A0 = (1 - 0)
A1 = (A0 - a0*A0)
A2 = (A1 - a1*A1)
A3 = (A2 - a2*A2)

この式で下のレイヤー（例えばa0）が変更された時A2,A3を
固定値で持っておけるとは思えないんだけど。

0265デフォルトの名無しさん

2006/03/07(火) 09:18:39

>ブレンドレートがピクセルごとじゃなくてレイヤ毎なら、計算量は極端に小さいだろ？

そもそも、レイヤ毎のレートならそんな計算は事前に計算しとくのが当然
合成が先にできるかどうかは全然別の話だろ

0266デフォルトの名無しさん

2006/03/07(火) 11:43:52

>>262
a0が変更されるときのA2とA3だけど、固定値にはたぶんならない。
ならなくても、普通にA0から順にたどって計算するんじゃなくて
a0 * 定数 + 定数
の形に変形するくらいはできるかと。

俺が
> α*上の画像 + (1 - α)*下の画像
からわかってないまま想像してたのは、
1 2 3 4 5 6 7 8 9 10 11とレイヤーがあるとき
何も考えずに12345，7891011を各々合成して1'，7'としておいて、
1' 6 7' を何も考えずに合成したらうまくいくんじゃないかと。

この書き込みの前半と後半で言ってることはほぼ同じ意味な気がする。
自信がないからあとでもうちょっと考えてみます。

0267デフォルトの名無しさん

2006/03/07(火) 13:09:07

ブラウザ上でカメラ画像を表示（ローカルの）したいんだけど、できるかな？
やりたいことは、パスワード代わりに顔認証。
ボタンをポチっとおすと静止画がキャプチャされて、Ajax でもなんでもいいけど、静止画がサーバに送られてそこで認証する。
ライブラリは OpenCV しかわからないので、できればそれを使いたい。
Javascript でやるの？それとも Flash？
それとも、ブラウザ上はあきらめて、なんらかの方法でローカルのプログラムを起動させてそいつで別個にさせるべき？
それが楽だとは思うけど、うまいことブラウザと連動させられるのかどうか。
あれ、この質問、画像処理が本質じゃないな・・・。

0268デフォルトの名無しさん

2006/03/07(火) 13:16:20

＞1' 6 7' を何も考えずに合成したらうまくいくんじゃないかと。
7が無理でしょ。

＞a0 * 定数 + 定数
＞の形に変形するくらいはできるかと。

これを7891011と繰り返さないと駄目じゃん、と言っている。

おれ間違ってるか？　そこまで自信たっぷりに言い切られる
と考え込んじゃうんだけど。

グラフィックのハードの設計とかいろいろ仕事でかかわって
半透明ブレンドの手法は勉強したけど、どんな場合でも
結局半透明は変更したものより上のレイヤーは順に描き
なおしが唯一の解だったよ。少なくともそれ以外の手法
をやってるものにはお目にかかったことが無い

加算だけなら1' 6 7'に出来るけどね。

0269デフォルトの名無しさん

2006/03/07(火) 13:41:32

知識のない奴が思いつきで言ってるんだから勘弁してやれ

0270デフォルトの名無しさん

2006/03/07(火) 14:46:44

>>268
そうなんだ。了解・納得しました。

0271デフォルトの名無しさん

2006/03/07(火) 15:39:16

>>267
ブラウザでカメラ画像を取り込めたらセキュリティ問題ですｗ
何を使っても不可能です
カメラ画像をアップロードする専用ソフトを作りなさい
それからスレ違い

0272デフォルトの名無しさん

2006/03/07(火) 15:46:16

>>267
ヒント：JMF

0273デフォルトの名無しさん

2006/03/07(火) 15:47:29

>>267
ヒント： Java + J/Direct

0274272

2006/03/07(火) 15:47:49

>>267追伸
少しはググれ。OpenCVをあきらめたほうが楽。

0275デフォルトの名無しさん

2006/03/07(火) 16:33:16

>>272=270か？
いいかげん適当なこと言うのやめれｗ

JDirectはあくまでローカルアプリとして開発されたソフトからのアクセスは許可するがアプレットからは許可しない
どうしてもブラウザに出さないといけないのならIEに限定して認証されたActiveXを作るのが一番楽です
Mozilla系になるとプラグインを作らないといけない
ActiveXはVCやVBで作成できますが、認証されたWindows環境のみという選択をすればどのみちローカルアプリ
を動かすのと変わりません
それなら画像を撮影して画像をアップロードする形でアプリからブラウザを開いたほうがいい
これならブラウザの種類の点で融通が利く

0276デフォルトの名無しさん

2006/03/07(火) 17:10:18

OpenCVの顔認識って，パスワード代わりに使えるほど信頼していいのか？

0277デフォルトの名無しさん

2006/03/07(火) 17:14:40

寝起きとか認証されませんｗ

0278デフォルトの名無しさん

2006/03/07(火) 17:51:57

はがした顔面を貼り付けても認証されました

0279デフォルトの名無しさん

2006/03/07(火) 17:54:06

本人の写真でお面作ったら認証されました

0280デフォルトの名無しさん

2006/03/07(火) 18:04:51

春だな

0281デフォルトの名無しさん

2006/03/07(火) 18:10:28

>>275
それカメラの意味ないじゃん。

0282247

2006/03/07(火) 18:11:40

いくつか論点のブレがあると思う。

１）レイヤ毎、ピクセル毎
>117 以降、>218-219 も含めて、レイヤ毎を前提としているように思える。
また、ピクセル毎の場合でも、遅くなりそうな気がするが、事前計算そのものはできると思う。
一応、>245 で「αがピクセル単位じゃなければ割といいんじゃない？」と断ったことを指摘しておく。

２）レイヤの上下
スマン。俺が悪い。>245 で勝手に逆にした。
結果的に、数字の小さいほうが下で、大きいほうが上というのは 245 しか使ってないから、>247 に合わせてくれるとありがたい。

３）編集中のレイヤ
どのレイヤを編集するかを選択した時点での事前計算についての主張なので、常に任意の an が変更される場合については、俺の主張は適用できない。
n を決定したときに、後述のように事前計算できる部分が著しく増えるというのが主張。

続く

0283247

2006/03/07(火) 18:11:57

続き

４）下の合成
編集中のレイヤより下は、
>　α*上の画像 + (1 - α)*下の画像
の普通のアルファブレンドで１枚にしておく。
これは、>245 で変形したものを用いる前の段階。

５）上の合成
ここが >245 での指摘で、
>　α*上の画像 + (1 - α)*下の画像
を
α*上の画像 + (1 - α)*（α'*上の画像' + (1 - α')）
のように展開していくと、>245 のように、「各レイヤ画像 * 修正ブレンド率」の加算になるという主張。
編集中のレイヤより上の部分は加算しておくことができる。

で、俺の主張は、
・編集中のレイヤより下のレイヤをアルファブレンドしたもの
・編集中のレイヤ
・編集中のレイヤより上のレイヤを >245 の方法で加算したもの
の３枚を >245 のブレンド率で加算するだけで、レイヤを再統合した画像が得られるというもの。

しばらく暴れてるから、もう少しお前ら付き合ってくれ。

0284デフォルトの名無しさん

2006/03/07(火) 18:12:20

顔認証だと、パスワードを顔に貼り付けながらうろうろしてるようなもんだからな。
顔をIDにすればいいんじゃね？とはスラドから。

0285デフォルトの名無しさん

2006/03/07(火) 18:15:56

>283
昔のCマガにそれと同じ方法のってたな

0286247

2006/03/07(火) 18:41:18

>>283
何個 >245 って書いて間違えてるんだ俺は orz

>>285
暴れる理由が無くなった
Cマガの記事がでてきて、それでこのアルファブレンド事前解決問題が解決するなら、>245 は「知識の無い奴」だったってことだな

0287デフォルトの名無しさん

2006/03/07(火) 19:03:39

>>286
俺も自分なりに考えてみたら同じ結論になった。

1 2 3 4 5 6 7 8 9 10 11とレイヤーがあるとき
A11=A6*7a+7bで計算できるような1' 6 7a 7b があるか考えてみた。
α*上の画像 + (1 - α)*下の画像って事は、
A11=α11*a11+(1-α11)*A10
A10=α10*a10+(1-α10)*A9
A9=α9*a9+(1-α9)*A8
A8=α8*a8+(1-α8)*A7
A7=α7*a7+(1-α7)*A6
つまり、
A11=α11*a11+(1-α11)*(α10*a10+(1-α10)*(α9*a9+(1-α9)*(α8*a8+(1-α8)*(α7*a7+(1-α7)*A6))))
=α11*a11
+(1-α11)*(α10*a10)
+(1-α11)*(1-α10)*(α9*a9)
+(1-α11)*(1-α10)*(1-α9)*(α8*a8)
+(1-α11)*(1-α10)*(1-α9)*(1-α8)*(α7*a7)
+(1-α11)*(1-α10)*(1-α9)*(1-α8)*(1-α7)*p6

7a=(1-α7)*(1-α8)*(1-α9)*(1-α10)*(1-α11)
7b=A6を0とした時の6から11の合成

あらかじめ6が編集されると分かっているなら、7a、7bは計算できると思う。

0288287

2006/03/07(火) 19:06:34

なんか式の最後、
+(1-α11)*(1-α10)*(1-α9)*(1-α8)*(1-α7)*p6
ってなってるが、
+(1-α11)*(1-α10)*(1-α9)*(1-α8)*(1-α7)*A6
の間違い。

0289デフォルトの名無しさん

2006/03/07(火) 22:54:19

理解できた。逝ってきます

0290デフォルトの名無しさん

2006/03/07(火) 23:09:38

ちょっと上にあったカラーライゼーションなんだけど
ソース見たけど専用ライブラリつかっててわけがわからない
階調にあわせてRGBの増分を変化させればいいっちゅうのはわかるんだけど
エッジ境界の処理ってどうなってんでしょ
どこまでを着色範囲にするかの判定基準のことです
ttp://www.cs.huji.ac.il/~yweiss/Colorization/
これね
これとまったく同じじゃなくてもいいので、着色する範囲という意味での領域検出に
向いてるのではと思われる代替アルゴリズムなんかあったら教えて

0291デフォルトの名無しさん

2006/03/07(火) 23:32:07

>>290
コード書いて検証しないとアレなんだけれども、すぐ思いついたナイーブなやり方。

近傍ピクセル間での明度の近さを「流れやすさ（滑らかさ） Q ただし最大1.0」として、
・色が指定されたからピクセルから、近傍ピクセル（とそのまた近傍）に色を塗ってゆく。
　このとき色と供に、Σ 経路のQ をスコアとして記録しておく（最大のヤツね）。
・色指定付きの全てのピクセルから全てのピクセルに対して色を塗った後、
　各ピクセルについて、スコアが最大の色をそのピクセルの色とする。

具体的なQの定義の仕方とか、最適化とかについてはいろいろためしてみないとわからないし、
ほとんど等しい明るさはもう無条件に塗るとか最適化の余地は多々有るけれども。

0292291

2006/03/07(火) 23:33:22

>>291
ΣはΠの間違いデスタ。Σでもいいかもしれないけど。

0293デフォルトの名無しさん

2006/03/08(水) 06:06:52

layered なシステムの話だけれども、予め計算しておけるジャンルは意外と
少ないよ。特にレイヤーの枚数が多い＆変更されるレイヤーが任意の場合は、
逆に遅くなる（最終合成する時間だけを考えれば速いだろうけれど）。
初代ペンティアム時代に実装したことがあるんだけれど、当時のテストでは、
変化領域をちゃんと記録して、それに、z-buffer風味で不透明（透明度０％）
打ち切りを実装するのが一番現実的で（平均的に）高速だったよ。
場合によっては、単に変化領域記録だけでストレートに合成した方が速い
用途だってあった。
用途が限定されている場合は、また別だろうけれども、汎用部品として実装する人は、
このへんも検討してみるといいよ。

0294デフォルトの名無しさん

2006/03/08(水) 11:07:21

>>290
隣との輝度差を伝播速度として、
他の色とぶつかるまで色を伝播させて行けばいいかもしれない。

二次のコスト関数ってかいてあるから違うことしてるかもしれないけど。

0295デフォルトの名無しさん

2006/03/08(水) 11:46:12

小さな輝度差の連続よりも大きな輝度差の方がコスト高になるように
輝度差の二乗とかを積算して伝播してゆけばいいのかな。

0296デフォルトの名無しさん

2006/03/08(水) 14:16:33

>>290
ちゃんとアルゴリズムも書いてある。他の手法への参照もある。
つ ttp://www.cs.huji.ac.il/~alevin/papers/colorization-siggraph04.pdf

100ms君は去ってしまったな。よかった。

0297デフォルトの名無しさん

2006/03/08(水) 17:32:03

>>296
よくわからん

0298デフォルトの名無しさん

2006/03/08(水) 18:52:41

>>297
英語を読む気がないだけ？数式がわからん？

0299デフォルトの名無しさん

2006/03/08(水) 18:59:21

両方

0300デフォルトの名無しさん

2006/03/08(水) 19:01:34

英語はまあなんとか読めるかな
数式がわかりません

0301デフォルトの名無しさん

2006/03/08(水) 19:34:05

式(1)のJ(U)を最小化する最適化問題を解こうってわけ。

さらに数式は増えるけど、
セグメンテーションだけでいいならこっちの方がいい。
ttp://www.cs.huji.ac.il/~yweiss/iccv99.pdf

0302デフォルトの名無しさん

2006/03/08(水) 22:38:24

もっとわからない

0303デフォルトの名無しさん

2006/03/08(水) 23:59:15

じゃあ最適化問題のお勉強してから>>296読み直すといいよ。

0304デフォルトの名無しさん

2006/03/09(木) 12:36:16

ttp://junki.main.jp/fromflickr/060306.htm

ここで紹介されているHDRって、どんな論理なんだろ？

0305デフォルトの名無しさん

2006/03/09(木) 13:53:28

> 露出過剰で暗いところがはっきりしているものと、
> 露出不足で明るいところがはっきりしているものを、
> ソフトウェアで重ね合わせる

単純に半々で重ねるだけでいいのかな？

ttp://flickr.com/photos/andidfl/109843664/in/pool-hdr/
だとしたらこれみたいに、影が複数できちゃうのはしょうがないのかもしれない。

0306デフォルトの名無しさん

2006/03/09(木) 13:58:54

>>305
ドアハンドルの周囲にハロー（halo）があらわれてるから、
黒っぽい領域（の周囲）では露出過剰の方の方を多くブレンドするように
なっているんじゃない？

0307デフォルトの名無しさん

2006/03/09(木) 13:59:18

>>304
ぱっとしかみてないけど、
http://www.debevec.org/Research/HDR/debevec-siggraph97.pdf
の Figure 2 で理解した気になれた。

0308デフォルトの名無しさん

2006/03/09(木) 14:05:29

これと似たようなものかな。
ttp://www.sony-krc.co.jp/research_dis_3.html

0309デフォルトの名無しさん

2006/03/09(木) 14:54:56

これらなんか、すごいね

ttp://flickr.com/photos/worker101/108410634/in/pool-hdr/
ttp://flickr.com/photos/altus/108078326/in/pool-hdr/
ttp://flickr.com/photos/smearedblue/107123356/in/pool-hdr/

どんな論理かわからないけど、ここは過剰のやつ、ここは不足のヤツ、って具合に
重ねあわす配分をいろいろ変えてるようだね。

0310デフォルトの名無しさん

2006/03/09(木) 15:39:17

>>309
真ん中のは普通に撮影したように見えてしまう。

0311デフォルトの名無しさん

2006/03/09(木) 15:51:10

>>308
むろん、似たようなものではあるけど、>>304 とは違うっぽい。
>>308 は高性能のカメラ、普通のディスプレイを使う、
>>304 は普通のカメラ、普通のディスプレイを使う。

0312デフォルトの名無しさん

2006/03/09(木) 15:53:29

>>309
CGに見えるよな

0313デフォルトの名無しさん

2006/03/09(木) 17:19:46

>>311
なるほど。
>>308は、普通のカメラじゃ複数の写真を撮らなきゃいけないから
カメラが頑張って広ダイナミックレンジで撮影して一枚ですませようってことか。
露出を変えながら何枚も撮影してズレないのかな？

>>312
真ん中のは普通に撮影したように見えてしまう。

0314デフォルトの名無しさん

2006/03/09(木) 18:03:42

> 露出を変えながら何枚も撮影してズレないのかな？

PhotoMatrix は多少のずれを補正してくれるらしい。
明治記念館のヤツは、子供の手がぶれてるし、そのことがタイトルになってるね

> 真ん中のは普通に撮影したように見えてしまう。

そうぉ？明治記念館のヤツでしょ。異様に陰影がなくて、ディテールが明瞭過ぎるでしょ？

0315デフォルトの名無しさん

2006/03/09(木) 18:17:53

そのうちに HDR モード付きのデジカメがあらわれるよ。シャッター１回で二枚撮れる。
そして、付属のソフトで処理するような。

だから、関係者は注目！

0316デフォルトの名無しさん

2006/03/09(木) 18:21:42

たんに、CCD のダイナミックレンジを拡大して１枚で済ますことが出来るかもね。

0317デフォルトの名無しさん

2006/03/09(木) 18:28:12

> シャッター１回で二枚撮れる。

適正露出のも加えて３枚が理想。
こんなふうに

ttp://flickr.com/photos/thewolf/107354879/in/pool-hdr/

0318デフォルトの名無しさん

2006/03/09(木) 19:04:37

同時に３種類の状態の素子におんなじ写体を取らせる方法ってどうやるのかな？
分光して素子を別々にするの・・・それともタイムスライスで１つの素子で処理するのかな？

0319デフォルトの名無しさん

2006/03/09(木) 19:20:56

そろそろスレ違いの話題に移りかけてないかな。

0320デフォルトの名無しさん

2006/03/09(木) 19:23:50

カメラ小僧どっかいけ

0321デフォルトの名無しさん

2006/03/09(木) 19:26:30

フジのハニカムにそんなのがあったな

0322デフォルトの名無しさん

2006/03/09(木) 20:18:54

>>320おいおい、デバイスがあって初めて一般販売できるものができるんだよ。
HWの話が少しもできない奴は実務では要らんぞい。情報だろうと電気だろうと大学で習ってるだろうに。

0323デフォルトの名無しさん

2006/03/09(木) 22:20:25

>>322
ヒント：画像処理

0324デフォルトの名無しさん

2006/03/09(木) 22:28:15

ヒント：画像処理には入出力装置概論も含まれる

0325デフォルトの名無しさん

2006/03/09(木) 23:06:52

画像処理っていうとやっぱ２次的操作という意味になると思うわけですよ
わざわざレースクイーンのパンツを鮮明に撮るカメラ技術を議論しても意味ないのですよ
多くの人はその恩恵にあづかることもないのですから
ステレオ写真とか連続写真とかまず存在しないソースを持ち出されても困るわけです
せめてソースとして個人が所有してるものをム板でいかにクオリティを高めるかというスレ
ではないでしょうかね

0326デフォルトの名無しさん

2006/03/09(木) 23:14:23

>>325
HDR の主要なマーケットを見抜いている325って・・・

0327デフォルトの名無しさん

2006/03/09(木) 23:20:17

>>323のタイプと>>325の間の溝は埋まらないことは分かったけど、
別にかまわないオレガイル。別の話にしようや

0328デフォルトの名無しさん

2006/03/09(木) 23:22:13

ようやくこのスレに恩返しができるときが来たぜ

>>318
フジのSRハニカムCCDがそれだね

小さいHDR用素子と、大きいLDR用素子を併用して
普通のカメラの4倍ののDレンジを誇るそーです。
でも8bppのJPEGで出力したら意味ねーじゃんと思いました。
つーかせっかくならOpenEXRとかで吐いてほしかった。
あとSR CCDは作れば作るほど赤字だそうです。

http://www.hdrsoft.com/examples.html
を見るとわかると思うんだけど、
トーンマッピング(HDR->LDR変換)の時に、
わざと周囲の平均との差分を取ってディテールだけ強調してるんですね。

0329デフォルトの名無しさん

2006/03/09(木) 23:41:02

Tone mappingに必要なコードはこれ。
http://www.mpii.mpg.de/resources/tmo/

HDRI生成にはこれ。
http://www.debevec.org/FiatLux/mkhdr/

な。あとlucille/syoyoさんとこも押さえとこう。

0330デフォルトの名無しさん

2006/03/10(金) 00:52:26

あ、>>323≠>>324。

確かにカメラの話はスレ違いだと思うよ。
大学の講義で「画像処理」にそういう話がはいってるとか
そんなことはどうでも良くて、ただ、

>>325
> 多くの人はその恩恵にあづかることもないのですから

多くの人がその恩恵にあずかることになると思うのだが。

0331デフォルトの名無しさん

2006/03/10(金) 01:00:44

やれやれ
窮屈なスレだ

0332デフォルトの名無しさん

2006/03/10(金) 03:18:37

デブ、痩せろ。

0333デフォルトの名無しさん

2006/03/10(金) 09:47:10

>>332

スレ違い。

0334デフォルトの名無しさん

2006/03/10(金) 10:02:14

>>304
HDR現象ってつまり明るさのダイナミックレンジの圧縮だね。

>>312
>CGに見えるよな

一般的なCG技術の限界の一つが、HDR現象がおきてしまうこと。
むしろダイナミックレンジが狭いディスプレイに合わせてＣＧを作ると
ダイナミックレンジの圧縮をせざるを得ない。

つまり、CGっぽさの正体の一つがダイナミックレンジの圧縮じゃないかと思う。

最近、GPU界でトレンドのHDRレンダリングは、
ダイナミックレンジの圧縮を使わずに表現する技術。
しかし、レンジの狭いディスプレイにそのまま写すと当然、白飛び黒潰れする。
そこで、人の目がまぶしさや暗さに一定時間で慣れてくる特性を再現して
自然に見せている。

0335デフォルトの名無しさん

2006/03/10(金) 10:55:45

>>332
がんがる。今64キロ。

>>334
後半とのつながりがわかんね。
今はダイナミックレンジの圧縮をしない方向だけど前はよくやられてて
コレと似た結果になるからCGみたいに見えるってこと？

0336デフォルトの名無しさん

2006/03/10(金) 11:30:01

>>335
以前は主照明を弱くして環境光を付与するなどして、
照らされているところが白飛びしないように、
日陰の部分が黒つぶれしないようにシーンを造っていた。
RGB各8ビット程度で計算していたので、
こうしておかないと「後処理で～」とかもできなかった。

今は浮動小数点数など使えてCG計算過程でのダイナミックレンジが
広がったので）本来あるべきとおりのライティングでシーンを構成し、
広いダイナミックレンジでレンダリングして、後処理で視覚特性に
あわせたレンジ圧縮処理を行うことができる。

0337デフォルトの名無しさん

2006/03/10(金) 15:08:06

ワンダと巨像のあれは嘘んこHDRだから気をつけろよ

0338デフォルトの名無しさん

2006/03/10(金) 15:20:54

嘘でもそれなりに見栄えがあればOKなギョーカイだからOK!

0339デフォルトの名無しさん

2006/03/10(金) 15:38:48

平面写真を立体認識するフィルタを見つけたんだが興味なさそうだからいいか

0340デフォルトの名無しさん

2006/03/10(金) 15:48:20

立体画像を平面認識するフィルタを開発しますた。

0341デフォルトの名無しさん

2006/03/10(金) 16:19:12

>>339
ｋｗｓｋ

0342デフォルトの名無しさん

2006/03/10(金) 20:23:19

>>339
ｷﾀｺﾚ!

0343デフォルトの名無しさん

2006/03/10(金) 22:34:49

>>339
キボン

0344デフォルトの名無しさん

2006/03/11(土) 03:03:16

>>339の人気に嫉妬

0345デフォルトの名無しさん

2006/03/11(土) 09:12:43

>>341-343 ああしかし、それでもあなたの恋は実らない

0346デフォルトの名無しさん

2006/03/11(土) 22:04:26

ショボーン(´・ω・`)

0347デフォルトの名無しさん

2006/03/11(土) 23:01:17

このスレにコテがいないのはなんで？
居たらいたでうざそうだけど。

0348デフォルトの名無しさん

2006/03/11(土) 23:21:29

さあ。
むしろなんでそんなこと聞くの？

0349デフォルトの名無しさん

2006/03/12(日) 00:22:52

他のスレも見てるんだけどさ、必ずへんなコテがいるじゃん。
ここはなんか他のスレと雰囲気が違うんだよね。
なんでだろ～と思ってさ。

0350デフォルトの名無しさん

2006/03/12(日) 01:45:41

IDが出ないからコテも偽者だらけになるしね。

0351デフォルトの名無しさん

2006/03/12(日) 11:42:49

トリップ付けないコテハンなんかいないだろ、ふつう

0352デフォルトの名無しさん

2006/03/12(日) 11:53:39

じゃあなんで？

0353デフォルトの名無しさん

2006/03/12(日) 13:05:25

>>347 >>349 >>352
お前鬱陶しいからコテつけてくれよ

0354デフォルトの名無しさん

2006/03/12(日) 18:04:56

画像検索から画像ひろってきて研究に使ってはやっぱりいけないのですかね？
有名人の公開している画像でもまぁ同じですかね？

0355デフォルトの名無しさん

2006/03/12(日) 18:05:40

スレ違い

0356デフォルトの名無しさん

2006/03/12(日) 20:19:06

だめに決まってるだろ･･･。
つーか、分野ごとに標準画像的なものがあるでしょーが。
それらを使わない/使えない理由でもあるの？

0357デフォルトの名無しさん

2006/03/12(日) 22:19:53

標準画像でも大抵金払わないと使えないけどね。
JISとかISOとかITEとか。

0358デフォルトの名無しさん

2006/03/12(日) 22:22:45

私的に研究に使う分にはOKでしょ。公式に発表するときにはダメだろうけど。

0359デフォルトの名無しさん

2006/03/12(日) 22:24:32

アマチュアですか。

0360デフォルトの名無しさん

2006/03/12(日) 22:29:47

プロですか。

0361デフォルトの名無しさん

2006/03/12(日) 22:36:56

1967年4月生まれいま16歳

0362デフォルトの名無しさん

2006/03/12(日) 22:38:15

MZ1500を思い出すな。

0363デフォルトの名無しさん

2006/03/12(日) 22:56:51

写真くらい自分で撮れよ

0364デフォルトの名無しさん

2006/03/12(日) 22:59:08

でも
http://vasc.ri.cmu.edu/idb/html/face/frontal_images/
とかってどうなんでしょう？有名人だからいいのでしょうか？
あと画像検索系のはウェブに散らばってる画像を無論使うわけで、
それはどうなんでしょう？気をつけているのかな。
>>358
その公式ってのは論文に貼り付けしなきゃいいってことなのでしょうか？
画像はウェブから拾ってきて実験しました。って書くことになるから意味なし？

>>356
足りないんです。

0365デフォルトの名無しさん

2006/03/12(日) 23:02:10

>>363
5000 サンプルぐらいほしいんです。
5000 positive, 3000 negative でやっとまともな結果になると論文に。

0366デフォルトの名無しさん

2006/03/12(日) 23:08:43

統計データを載せるだけなら別に問題ないぞ
写真そのものを添付しないならね

0367デフォルトの名無しさん

2006/03/12(日) 23:23:08

>>366
そうなんですか。勉強になります。
では集めてみようかしら。

0368デフォルトの名無しさん

2006/03/12(日) 23:23:18

364のリンク先のとこにPlease give appropriate acknowledgements when you use these test sets.
ってあるから、論文書くときはとりあえず謝辞には入れるんだろうし、それなら
あらかじめお礼もかねて断りのメールを一本入れておくのが無難だろうな。

0369デフォルトの名無しさん

2006/03/12(日) 23:34:01

素材屋に相談した方が早そう。権利関係もはっきりしてるし。

0370デフォルトの名無しさん

2006/03/13(月) 00:03:09

>>365
うちの大学でもデータ収集してる人たちが居たなぁ。
粗品でボールペン貰ったよ。

0371デフォルトの名無しさん

2006/03/13(月) 00:05:59

こういうサンプルデータって金で買うと結構高いんだよね。
研究室で音声認識もやってるんだけど、CD-ROM6枚ぐらいで数十万とかしたしな。

0372デフォルトの名無しさん

2006/03/13(月) 00:08:44

昔から顔認識やってるとこはそんな感じだね。日本女子大のとこ
なんかデータが女の子の写真ばっかりのときがあった。

0373デフォルトの名無しさん

2006/03/13(月) 00:13:55

おっぱいの素材ならいっぱいあるとかいってみるテスト

0374デフォルトの名無しさん

2006/03/13(月) 01:19:55

もし、認識して個体識別できたらすごいね＞おっぱいの素材

0375デフォルトの名無しさん

2006/03/13(月) 02:02:31

これがおっぱい認証の始まりでした。

0376デフォルトの名無しさん

2006/03/13(月) 02:13:28

おっぱいの素材ってシリコーンの有無か？

0377デフォルトの名無しさん

2006/03/13(月) 02:31:04

>>368
そのリンク先が、そんなもの公開して法に抵触しないのか。って意味じゃないのか？

0378デフォルトの名無しさん

2006/03/13(月) 02:32:49

>>375
もっとスケスケにして乳癌の認識ならやってる人たちいるぞ

0379デフォルトの名無しさん

2006/03/13(月) 17:19:26

>>375
俺、おっぱい認証できるぜ。

0380デフォルトの名無しさん

2006/03/13(月) 19:29:03

セキュリティールームに入るのにおっぱい認証いいな

0381デフォルトの名無しさん

2006/03/13(月) 19:51:00

お前ら本当に最低だな･･･。

0382デフォルトの名無しさん

2006/03/13(月) 20:39:17

男が認証するのは見たくないな。

0383デフォルトの名無しさん

2006/03/13(月) 22:25:45

でも、ちんこ認証はきもちいいぞ。

0384デフォルトの名無しさん

2006/03/13(月) 23:08:17

著しく質が落ちてるスレはここですか？

0385デフォルトの名無しさん

2006/03/13(月) 23:13:30

いいえ、ここは著しく品が落ちているスレです

0386デフォルトの名無しさん

2006/03/13(月) 23:15:15

でもカメラのことはすれ違いで怒られるんだよね。

0387デフォルトの名無しさん

2006/03/13(月) 23:21:46

このスレでの話題に対する評価:
おっぱい＞ちんこ＞カメラ

おっぱいチンカメ、と覚えましょう。

0388デフォルトの名無しさん

2006/03/13(月) 23:59:16

なんなの、この流れ。

0389デフォルトの名無しさん

2006/03/14(火) 00:59:48

ここで>>339降臨
↓

0390デフォルトの名無しさん

2006/03/14(火) 03:18:55

ここで書きこみ。スレの住人は俺の書き込みに、く・ぎ・づ・け、だな。

0391デフォルトの名無しさん

2006/03/14(火) 14:55:45

顔の話に戻してみます。

>>267とは別の話しで一度撮った画像から顔の向きを知りたいです。
そこでOpenCVの顔検出を使いたいんだけどあれってどこまでできるのでしょうか。
どこまでとは顔の範囲，向いてる方向，目と口の配置，目線の方向とか。
例えば，

一二三
八人四　人　：対象人物
七六五　数字：カメラ

のように周りから複数台のカメラで撮影した写真から顔を検出して
どのカメラが正面に近いか判定するのは可能でしょうか。

ちなみにカメラの位置と人がいないときの背景画像はあらかじめ持っていて
差分を取れば人の領域は検出できますが人物に関する情報はありません。

0392デフォルトの名無しさん

2006/03/14(火) 15:07:44

カメラ小僧どっかいけ

0393デフォルトの名無しさん

2006/03/14(火) 15:16:49

カメラ小僧じゃないってのｗ
顔検出って普通に画像処理の話。

0394デフォルトの名無しさん

2006/03/14(火) 15:39:20

>>391
その程度なら顔検出なんかするより、

・人の頭は一番上にある
・顔は左右対称 or 顔は後頭部より複雑 or なにかそういう仮定

とかのヒューリスティックな知識を適当にアルゴリズム化した方が
はるかに良さそうな結果が得られそうに思うけど。

0395デフォルトの名無しさん

2006/03/14(火) 16:04:24

>>394
なるほど。
ただ，まずはどのカメラに写っているのかわからないので
検出しないと話が進まないっぽいのです。

しかもカメラには全身を写したいので顔は小さめで，
XGAで撮影すると顔の領域が80*100くらいになります。

> 顔は左右対称 or 顔は後頭部より複雑
これらもまず顔が見つからないと…。

人が寝そべってたり動いてて不安定な姿勢をとっていたりにも対応したいので
あまりヒューリスティックにはしたくないです。

0396デフォルトの名無しさん

2006/03/14(火) 16:42:23

画像処理のためのカメラの技術はスレ違いだって、前のほうで言ってたよ。

0397デフォルトの名無しさん

2006/03/14(火) 16:44:40

> 顔検出って普通に画像処理の話

そんなに普通なら、普通に処理するといいね

0398デフォルトの名無しさん

2006/03/14(火) 16:50:23

普通に画像認識の話だろ。
なんか変な粘着が居るが、カメラに嫌な思い出でもあるのか？

0399デフォルトの名無しさん

2006/03/14(火) 17:38:42

どうせなら１枚の写真でやろうぜ

0400デフォルトの名無しさん

2006/03/14(火) 17:42:15

OpenCVってのがどんなもんかしらないけど横顔で認識させたら
エラーになるだけだろ
単純に３枚なら３枚やってみて一枚でも認識できればOkってことにすればいいんじゃまいか？

0401デフォルトの名無しさん

2006/03/14(火) 17:58:34

>>400
ちょっと意味がわからないです。

>>391の例で言うと
人が２の方向を向いてれば１，２，３のカメラ画像から
もしくは２だけから顔が検出されてOKかと予想はしてるんですが，

さっきいくつかの実際に使う画像＋OpenCVサンプルで試してみたところ，
微妙に横向きでも両目が見えるくらいなら検出されるみたいです。
でも右腕の辺りから顔がでたり，誤認識を確認しました。(´・ω・`)
カメラが遠いのである程度これは覚悟済みです。

そこで8台のコンセンサスをとれば誤認識の可能性を減らせるかなと。
だからある程度正面方向からのズレも知りたいんです。

3台のカメラがほぼ同じ方向を向いた顔を見つけたけど
全く逆側のカメラからも顔が出てきて，その大きさが全然違うとか言う場合に
対応できるようになるはず。

だから顔の有無だけでなく，
向きや目の位置などを得られるのかどうかが知りたいです。

0402デフォルトの名無しさん

2006/03/14(火) 18:05:24

それだけ写真があれば方向を得られる情報が含まれているはYESだけど
OpenCVが対応してるはおそらくNoです

0403デフォルトの名無しさん

2006/03/14(火) 18:19:26

>>402
じゃあOpenCVの顔検出ってどういう出力になってるの？
逆さ向けたり横向けたりすると検出されないってことは
顔のパーツを見つけてるんだと思ってたけど。

0404デフォルトの名無しさん

2006/03/14(火) 19:07:53

標準だと顔のパーツごとじゃなくって、顔全体で探索してるよ。
\OpenCV\data\haarcascadesにカスケードファイルが幾つかあるけど、正面顔と体全体の学習結果しか無いね。
画像集めて学習させたらパーツ毎の探索もできるんだろうけど･･･。
データ収集も計算も大変だよね～。

0405デフォルトの名無しさん

2006/03/14(火) 19:12:42

>>391
OpenCVの顔検出の出力は矩形領域として結果が返されるでしょ？
面積が一番でかい奴が一番近いとかじゃだめかね？
つーか、それだけカメラがあるなら多眼距離計測もできるっしょ。

顔認識ルーチンはサンプルが付属してるから実際にカメラ繋げて試せばいいじゃん。

0406デフォルトの名無しさん

2006/03/14(火) 19:41:22

>>404
そこで >>354 の話がでてくるわけですね

0407デフォルトの名無しさん

2006/03/14(火) 19:46:06

むしろここで>>339が登場

0408デフォルトの名無しさん

2006/03/14(火) 19:54:16

またまた、ここで書きこみ。スレの住人は俺の書き込みに、く・ぎ・づ・け、だな。

0409デフォルトの名無しさん

2006/03/14(火) 19:56:08

てか認証に使うとか言ってたやつだよね？
認証なら正面向かせろｗ

0410デフォルトの名無しさん

2006/03/14(火) 20:05:10

>>409
投稿人が違うと読み取ったが、いかがか。

0411401

2006/03/15(水) 00:48:13

>>409-410
そう，また別件です。
こっちは検出で、認証は使わないです。てかOpenCVに個別の顔の認識は無かったような…。
てかみなさん，顔検出と認識とをごっちゃにされると話がややこしいです。
画像認識って意味ではあってるんですけどね。

>>404
このファイル、実体がよくわかっていませんでした。
パーツに区切られてるってわけではないのですね。
じゃあ向きを知る手がかりは信頼性の低めな顔の有無だけってことですか…。

>>405
単純にそれでもいいかもしれません。ただカメラ画像で試したときは
エラーがでたので（手が顔にされた），それが心配です。
同時に行う別の処理でおおまかな体の形状を出してるので，
頭の位置や大きさと比べてありえないものをはじくっていう手もありますね。

この手の方法はあまりスマートでないので融通が利かないのではと心配ですが，
その線で考えてみます。

0412デフォルトの名無しさん

2006/03/15(水) 04:51:38

photoshopなんかで選択したときにうにょうにょ動いてるラインってどうやって書いたらいいんですかね？

0413デフォルトの名無しさん

2006/03/15(水) 05:10:28

宿題やって下さい。お願いします。

Convert TIF image into YCbCr. Use the 2-D discrete wavelet programs in
MATLAB to compute the transforms of the planes at a variety of scales
between 1 and 3. Display these results.

1. Perform the following operations on the intensity plane of the image and
reconstruct the entire color image.

(a)
Zero the approximation coefficients of the generated transforms and record
your observations regarding subsequently reconstructed images. That is, compute
the inverse transforms of the decompositions after the approximation coefficients
have been zeroed and record the impact on the transform modifications.

(b)
Repeat the process in (a) but zero the horizontal, vertical, diagonal detail
coefficients instead. After that, zero both the horizontal and vertical detail
coefficients.

2. Perform the following operations on the color planes of the image and
reconstruct the entire color image.

(a)
Zero the approximation coefficients of the generated transforms and record
your observations regarding subsequently reconstructed images

(b)
Follow same steps in part 1.(b)

0414デフォルトの名無しさん

2006/03/15(水) 05:11:16

>>412
「(x-y) % 10 が 0～5なら黒」とかそんな感じでない？
アニメーションは0～5の部分をシフト

0415デフォルトの名無しさん

2006/03/15(水) 06:11:14

>>414
それはわかるんだけどそれだと１点ずつ計算して描画しないといけないわけで
PSetでやるとむちゃくちゃ遅い

0416デフォルトの名無しさん

2006/03/15(水) 06:34:07

>>415
そういうのはGUI環境ごとに或いはGUIライブラリごとにその目的の関数が用意されていたりする。
画像処理なんてレベルの話じゃないから該当環境スレで聞き直したほうがいい。

0417デフォルトの名無しさん

2006/03/15(水) 07:01:29

普通のWindowsGDIだけど専用の関数なんてないですけどね
普通にやってるソフトはいっぱいありますがね

0418デフォルトの名無しさん

2006/03/15(水) 07:23:44

windows なら
・　LineDDA を使う
・　ExtCreatePen　lpStyle　を使う

0419デフォルトの名無しさん

2006/03/15(水) 08:00:31

>>418
ああ、なるほど、わかりました

もう一個質問です
画像を拡大表示してて１っ箇所だけ修正してその部分の拡大画像を再描画するような処理があるんですが
補完処理してるとちょっよ見た目がずれます
全体を描画すれば防げるけど、遅いですからね
ずれないようにする計算方法とかあるんですか？

0420デフォルトの名無しさん

2006/03/15(水) 08:12:58

>>419　補間でズレるという事は　なにか間違ってるんでしょ。　

そんなふうに自分がバカだって一生懸命アピールされたって、こっちはウザイだけ
自分で考えるのが嫌なら、お願いしますと頭を下げて、その間違ってる補間式を公開したらどう？

0421デフォルトの名無しさん

2006/03/15(水) 08:16:35

>>420
うるせーな
あなたには答えていただかなくてけっこうです

0422デフォルトの名無しさん

2006/03/15(水) 08:23:24

>>421 あのさ、この手のスレで答えてるのはオレなんだよ。　もちろんオレは一人じゃないけどね。

さすがのオレでも、あんたのパソコンの画面が見える訳じゃない。
聞きたいなら必要な情報を出しなさいとオレの言い方で教えてやってるんじゃないか。

0423デフォルトの名無しさん

2006/03/15(水) 08:46:08

long x_delta = (old_width<<16) / width;

-line loop
unsigned char* src_pixel = &src_line[(x>>16)*3];
x += x_delta;
-line loop end

フレームワークの中身みたらこんな計算しております
>>421は別人ｗ

0424デフォルトの名無しさん

2006/03/15(水) 09:23:23

>>423　それはアドレスを計算してるわけだよね？　それをそのまま埋めてるなら補間というより単に拡大してるだけになるが
　ズレるなら x の初期値が問題なのだろう

0425デフォルトの名無しさん

2006/03/15(水) 11:20:08

初期値は０だし信頼できる値です
そういう意味のズレるではないのです
例えば３０倍で拡大した画像100x100があったとして
これの(11,11)-(20,220)を取り出して拡大すると
1Pixelが30Pixelに均一になるのが望ましいわけですが
29だったり31だったりする場所が出てくるわけですよ

0426デフォルトの名無しさん

2006/03/15(水) 11:24:24

３０倍というか中途半端な倍率のときとかね

0427デフォルトの名無しさん

2006/03/15(水) 11:30:10

あ、普通に左上から毎回計算すればいいだけかｗ

0428デフォルトの名無しさん

2006/03/15(水) 12:37:38

初期値が0だからそうなるわだし、
左上から計算しなくても、その計算式から初期値を計算すればいいだろう
というか、そういう質問なら算数スレで聞いた方がいいぞ

0429デフォルトの名無しさん

2006/03/15(水) 12:42:32

画像を扱うのはまったくの始めてなので、
トンチンカンな質問かもしれませんがお許しください。

あるビットマップの色を、453色の決まった色に
変換して表示しようとしています。

そこで、画像の各ドットのRGB値の色を、453色のRGB値化された
色情報の配列から近い色を探して変換したいのですが、
この「近い色」を探す方法がよくわかりません。

最初、単にRGB値を32bitのint型に変換して（&H0000FFの青なら255）、
最も近い値を探して変換してみたのですが
これがほとんど役に立たないほど違った色になってしまいます。
ちなみに、453色の配列自体は、DMCという刺繍糸で使う色であり
特にかたよった色の集合ではないと思います。

通常こういった処理は、どう行うのでしょうか？

0430デフォルトの名無しさん

2006/03/15(水) 12:47:04

>>429
簡単に説明すると、RGBそれぞれを0から255という辺に持つ立方体として考えて、
それぞれの色をこの座標系に入れて、二色間の距離を出してやるといいよ。

つまり、(r1-r2)*(r1-r2)+(g1-g2)*(g1-g2)+(b1-b2)*(b1-b2)　の平方根
距離の大小を比べるだけなら、平方根はださなくてもいいけどね。

0431デフォルトの名無しさん

2006/03/15(水) 12:54:38

>>430
たぶん、>>429はそれをやったんじゃないかと。
減色は語り尽くされた話題だから細かい説明は適当に検索してもらうとして、
原理的には目的に見合った表色系に変換して、その空間で「近い」色に変換。
プログラムでRGBが必要ならまた元に戻せば良い。
HSVとかHLSとかL*a*b*とか、まあ、扱いやすそうな表色系を探してみてください。
変換式（近似式の場合もあるが）もあちこちにあるので、そんなに難しくないでしょう。
ただし、刺繍糸の特性に合ったものというのはないんじゃないかな？

0432429

2006/03/15(水) 13:03:14

>>430,431
レスありがとうございます。

>>431
いえ、430さんの方法ではやってないです。
RGB値を距離ととらえて、2色の距離で差異を出すという
考え方は思いつきもしなかったです。
根が文系はもんで・・・

質問する前に、いろいろ検索していてRGBをL*a*b*に変換し、
それから近似値を・・・と思ったのですが、この場合も430さんのとおり、
L*a*b*値に変換してから、2色距離を求める方法でいいのでしょうか？

0433デフォルトの名無しさん

2006/03/15(水) 13:17:50

元が写真とかなら近似値だけじゃなく誤差拡散なども入れたら？

0434デフォルトの名無しさん

2006/03/15(水) 13:22:29

カメラ小僧どっかいけ

0435429

2006/03/15(水) 14:15:29

>433
刺繍のデザイン用のソフトを作ろうとしているので
写真にかぎらずイラストっぽいものも多く扱うと思います。
むしろ写真は少ないかな？
写真から刺繍のデザイン作ろうとすると、
まともに見えるようにするには、はてしなく大きな布（キャンバス）が必要なので・・・

と、いうことで。
とりあえずRGB値のまま距離換算で近似値求めて変換処理を行ってみました。

まあまあいい感じに色の変換できました。
ちょっと不満足な変換になる場合もありますが・・・
これはおそらく刺繍糸の色自体が、それほど明るく派手色が少なく、
落ち着いた色が多いことによるものだと思います。

まずは１ステップアップできたので、L*a*b*や他の色系統での
近似値を求めた変換もチャレンジしてみます。

ありがとうございました。感謝です！

0436デフォルトの名無しさん

2006/03/15(水) 14:33:41

>>435
DMCの刺繍糸って453色も入手できたっけ?
実質はもっと少ないと思うし、糸の特性上どうしても明度の幅が狭くて
彩度も低めな気がするので、その辺りを巧くフィードバックさせるようなU/Iが肝になるかもね。
#実際、たった1画素っつーか1目のために(似た色があるのに)違う色を使うってのもナンセンスだしね。

0437429

2006/03/15(水) 14:52:36

>>436
私の買っている刺繍糸の通販サイトだと450色近くは品揃えがありますね。
　ttp://www.craftmax.net/category/shishu/
とか。

ただ、実際クロスステッチとかやってると、一つのデザインで32色以上あると
結構糸取り替えるのに死ねるので、あらかじめ画像は減色しておくように
なると思います。
もしくは、私の作ってるアプリ内で減色させるか。

＞#実際、たった1画素っつーか1目のために(似た色があるのに)違う色を
＞使うってのもナンセンスだしね。
確かにこれはよく起こると思います。
ただ、色（糸）の削除や別色への置き換え機能を設けるつもりなので、
そのあたりのインターフェイスが使いよければ・・・と思ってます。

0438436

2006/03/15(水) 15:05:29

>>437
ほほぉ。なんだか結構面白そうなアプリケーションになりそうですな。
問題はユーザターゲットで、画像馴れした人なら「事前に適当に減色してついでに
色調も調整しておいてください」でいいだろうけどそうでないとねぇw
究極は、減色、色調調整、サイズ変更、歪補正くらいできると便利って話になったりして。

つい話題に乗っかって妄想書いたけど、楽しみながら作ってくださいな。
#毛糸の編み込みで似たようなプログラムを作ろうとしたことがあるので妙に親近感がw
##あっちは目の形がX型じゃなくてV型になるけど。

0439デフォルトの名無しさん

2006/03/15(水) 15:15:18

PCで写真から切り絵の下絵を作って作品にしてる人がニュースになってたな
切り抜かなくていいじゃん、と心のどこかでつっこみを入れてしまった。

0440429

2006/03/15(水) 15:35:58

>>438
実は優秀な「KG-Chart for Cross Stitch」ってのが
フリーでもうあるんですよｗ

ただ、フリーの前バージョンが100x100までだったので、
自分でもうちょっと大きいサイズまでできるの作っちゃおう！
と息巻いて作り始めたら、KG-Chartがバージョンアップして
500x500に対応しちゃったけどね・・・
と、いうわけで今は新しく出た、VB2005の習熟用として作ってる次第。
やっぱVBだとbitmapクラス使って変換処理とかやってると
遅いけど。。。

そろそろスレ違いなので名無しに戻りますです。

0441デフォルトの名無しさん

2006/03/15(水) 19:07:09

人間に見える色を数値化したのがHSVだから
HSVに変換して平均差の小さい色に統一すればいいと思うけど

0442デフォルトの名無しさん

2006/03/15(水) 19:59:57

>>428
ちなみにその計算式書いてみてもらえますか？

0443デフォルトの名無しさん

2006/03/15(水) 21:21:53

>>442
一番単純な方法はDDAを使って

x = -width/2;
x3=0;
-line loop
unsigned char* src_pixel = &src_line[x3];
x += old_width;
while(x> 0) { x -= width ; x3 += 3; };
-line loop end

width old_width が反対かもしれないよ

0444デフォルトの名無しさん

2006/03/16(木) 10:12:45

>>441
429です。

HSVですか。
なるほど～ちょっと調べてみたのですが、これなら
糸の色に近いものに近似化できそうです。
VB2005で作ってるので、ColorクラスにH、S、Bを返すメソッドが
あったので、これを使えば簡単そう！

ありがとうございます。早速やってみます！

0445444

2006/03/16(木) 11:46:26

やってみました。
一応、HSVとL*a*bと、二通りに変換して近似色を求めてみました。

う～ん・・・RGB値でやったのが一番近い色でした。
というより、HSVとL*a*bは、違う色といっていい感じ。

変換式が間違ってる可能性もありますが、
それは単にバグとして、色と色の差の求め方が違うのでしょうか？
どちらも、RGBから、HSB・Labの各値を求めて、以下の計算式で
色の差を出して、その差の一番小さいものを近似色としています。

HSV(B)方式：diff = (H1-H2)^2 + (S1-S2)^2 + (B1-B2)^2
Lab方式：diff = (L1-L2)^2 + (a1-a2)^2 + (b1-b2)^2

430さんのレスを参考に、座標系に置き換えて距離を出してるのですが、
それが有効なのはRGBだけなのでしょうか？？

0446デフォルトの名無しさん

2006/03/16(木) 12:25:40

似ているという場合、人間がどれだけ敏感であるかの重みをかける必要がある
明るさについて色より敏感である事は判ってるけど
どの程度かというのは難しい。
だから HSV より RGBのままの比較の方が良い結果になるのかもしれない

一番敏感な明るさ
　 0.2990*R + 0.5870*G + 0.1140*B　式を使って、 RGB方式で重みを工夫してみてはどう？

0447デフォルトの名無しさん

2006/03/16(木) 12:26:13

>>445
APIのドキュメントにはHSV の H は　0～360.0、SとVは 0～1.0 の値を返す、
なんてかかれてませんか？

これだと色選択の際に H の差異が支配的になってしまって、
S と V は殆どこうりょされないことになります。
距離を計算する際に、H を　360.0 で割ってから用いれば S V と同じ
影響力になります。

漏れの考えでは多少色が違っても明るさ等を合せたほうが良いと思うので、
H は 360 よりもっと大きな数で割って、Vは2倍くらいにして用いても良いと思ういます。
色々試してみてください。

0448436

2006/03/16(木) 12:31:06

>>445
その式を見れば判るように、RGBと違ってHSVの場合は色相の変化と明度彩度の変化と言う
違う次元の数値を同列に比較することになる。
#Hの範囲は0度-360度、SとV(B)の範囲は0%-100%。
従って、適当に係数を掛けないとHueの変化が大きくなってしまう傾向がある。
Labに関しては本来一番いい近似が得られる手段だと思うのだけど、
Lに係数掛けたらどうなるだろう。

参考資料:
ttp://www.sikiken.co.jp/color/index.html
ttp://konicaminolta.jp/entertainment/colorknowledge/index.html
ttp://image-d.isp.jp/index.html

って、出遅れたよw

0449444

2006/03/16(木) 12:41:26

>>446-448
なるほど・・・

言われてみれば、HSVにしてもLabにしても
各要素の最小値・最大値が異なるのでしたね。
気づけよ！って感じです（´･ω･`）

RGB、HSV、Labの３方法でいろいろ係数を掛けて
一番具合のよい方法を探索してみますです。

・・・っと、その前にいろいろサイト回って色について
もう少し勉強してきます。

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

0450デフォルトの名無しさん

2006/03/16(木) 12:52:03

>>449
一点、基本的だけど文系の方だと見落としているかもしれないので、
注意しておくと、色相 H とかは輪になってます。
0～360度ということは、 359度と1度との間の距離は2度ですよね？
これは単に引き算ではうまくいかないのもわかりますね？
書き込みが簡略化した式ならいいのですが、、。
ちなみに、こういうのを mod 360の上で、とか言います。

0451デフォルトの名無しさん

2006/03/16(木) 13:21:43

つまり180度以上差があったら360からその差の値を引けばOK？

0452444

2006/03/16(木) 13:26:28

>>450
ぬお。おっしゃるとおりですね。

まったく気づかず、そのまま引いてました。。。
指摘ありがとうございます！

ちなみに、Lab方式でかなりいい感じに近づいてきてます。
一応、どの方式でも変換＆あるていど係数もいじれるような方式で実装中。

なんか光が見えてきました。
感謝！！

0453デフォルトの名無しさん

2006/03/16(木) 13:30:07

>>４５１

この場合角度だから sin/cos成分に直して距離を出すのも方法かもしれないね

0454デフォルトの名無しさん

2006/03/17(金) 16:57:20

おもしろいこと言うなぁ・・・角度とか

0455デフォルトの名無しさん

2006/03/17(金) 17:04:19

角度って普通に言うよ。

0456デフォルトの名無しさん

2006/03/17(金) 17:11:32

角度　 A ,B の距離を

√( (sin(A)-sin(B))^2 +(cos(A)-cos(B)^2 )

で定義するなら、

0457デフォルトの名無しさん

2006/03/17(金) 17:56:30

どうせ遠いのはどうでも良いわけだから、近い2点についてなら
角度で距離を見ても sin,cos で見ても大差ないよね。

0458デフォルトの名無しさん

2006/03/17(金) 18:18:09

>>457 の説明

√( (sin(A)-sin(B))^2 +(cos(A)-cos(B))^2)
=√( sin(A)^2+cos(A)^2+sin(B)^2 +cos(B)^2 -2*sin(A)*sin(B)-2*cos(A)*cos(B) )
=√( 2 - 2*sin(A)*sin(B)-2*cos(A)*cos(B) )
=√( 2 - 2*cos(A-B) )

=2*√( ( 1 - cos(A-B) )/2 )
=abs(2*sin( (A-B)/2 ))

つまり(A-B)が小さいならほぼ比例する

0459デフォルトの名無しさん

2006/03/17(金) 18:39:19

>>458
そのときの「小さい」はどのくらいでしょうか。

0460デフォルトの名無しさん

2006/03/17(金) 18:46:28

>>459
例えば↓ページの y = sin(x) のグラフを見て下さい。
x = 0 近辺では、ほぼ直線になってますよね。

ttp://w3e.kanazawa-it.ac.jp/math/category/sankakusansuu/sankakukansuu-no-gurafu.html

この「ほぼ直線」になってる範囲が>>458の「ほぼ比例する」範囲になります。
どれくらいを「ほぼ直線」と看做すかは、応用次第です。

0461デフォルトの名無しさん

2006/03/17(金) 18:53:38

極座標化は　複素数でいえば対数化する事に相当するから

0462デフォルトの名無しさん

2006/03/17(金) 20:36:33

算数スレですか？

0463デフォルトの名無しさん

2006/03/17(金) 22:14:37

画像処理において算数が関係しないことなど無い
算数が出来れば画像処理が出来るのであれば
人間並みの制度の処理が聞くまでも無く出来るということだ
そういう人はスレから去るべきだ
ここは算数を勉強するスレなのだ

0464デフォルトの名無しさん

2006/03/17(金) 22:21:00

二次微分とか正直なぜそうなるのはさっぱりわからん
資料があればやりたいことは出来るからまあそれでいい
意味がわかる人は資料を作る人にでもなってなさいってことだ

0465デフォルトの名無しさん

2006/03/17(金) 22:38:35

>>463 目的と手段が逆転してるわな。

0466デフォルトの名無しさん

2006/03/17(金) 22:41:18

角度とか？ Hue での距離がなんで角度なんだ？
円環で表してるのは便宜的表現にすぎないのに。

0467デフォルトの名無しさん

2006/03/17(金) 23:05:48

>>460
いや、それはわかってるけど>>444の場合どうだろうって話。
A-Bって小さいとは限らないんじゃないの？
sinを普通に使ってもいいんじゃないの？

>>466
便宜上表現にすぎないからなおさらでは？
よくわからんのだが。

0468デフォルトの名無しさん

2006/03/17(金) 23:37:31

「HSV色空間での距離の定義」が問題になってるんだね。
先行研究に何かないかね?
例えば、H社が車両色識別装置(高速道路とかに設置されてるらしい)とか売ってるけど、この辺をどう扱ってるのか気になる。

0469デフォルトの名無しさん

2006/03/18(土) 04:48:56

刺繍用の色混色のアルゴが作れたら
それだけでひとつの表色系になってしまう気がする
もう誰か作ったんじゃないのかな

0470デフォルトの名無しさん

2006/03/18(土) 06:05:02

ヒント：median block

0471デフォルトの名無しさん

2006/03/18(土) 11:22:19

>>469
限られた色・限られたパタンで画像を表現するのは刺繍だけでなく印刷もそうで、色の配置や重なり具合の制約まで考慮された方法が山ほどあるみたいです。

0472デフォルトの名無しさん

2006/03/18(土) 11:54:49

>>467
　たぶん、差が小さいもの同士を塊化したいのだから、遠いものはもう遠いで、いいじゃないという事では？

ただ、輝度が極端に暗いなら色相の差に意味はないわけで、と考えると、色相差^2 で評価するのはそもそも失敗かもね

0473http://www.vector.co.jp/soft/win95/util/se072729.html

2006/03/18(土) 18:38:09

TextSS　の64bit化おながいします

もしくは64bitにネイティブ対応した置換ソフトないですか？

0474デフォルトの名無しさん

2006/03/18(土) 19:24:25

>>473
スレ違い。マルチ乙。
あと氏ね。

0475デフォルトの名無しさん

2006/03/18(土) 20:34:50

すごいマルチだなｗ
俺の巡回しているスレ全てに貼られている。
まさかここは無いだろうと思っていたのに…

0476デフォルトの名無しさん

2006/03/18(土) 21:57:45

新手のウイルスにでもひっかかってんじゃねーのかな

0477デフォルトの名無しさん

2006/03/19(日) 00:14:41

アンシャープマスクのレベル補正って何者？

0478デフォルトの名無しさん

2006/03/20(月) 11:42:02

>>477
ttp://www.google.com/search?num=50&hl=ja&safe=off&q=%E3%82%A2%E3%83%B3%E3%82%B7%E3%83%A3%E3%83%BC%E3%83%97%E3%83%9E%E3%82%B9%E3%82%AF+%E3%83%AC%E3%83%99%E3%83%AB%E8%A3%9C%E6%AD%A3&lr=

0479デフォルトの名無しさん

2006/03/26(日) 00:10:59

シャープフィルタのサンプル教えれ

0480デフォルトの名無しさん

2006/03/27(月) 16:39:22

>>454
角度って・・・いつの時代のネタだよ！
思い出してｺｰﾋｰ噴いたじゃまいかｗｗｗ

0481デフォルトの名無しさん

2006/03/27(月) 17:50:12

お互いふるいねぇ・・・・角度とか

0482デフォルトの名無しさん

2006/03/28(火) 10:40:40

smartOCRてどっかの研究室のグループが作ってるの？

0483デフォルトの名無しさん

2006/03/28(火) 11:58:52

個人だろ

0484デフォルトの名無しさん

2006/03/28(火) 12:05:19

こういう最先端技術関係は専門で勉強した人が知りうる知識を終結して作ったものより
独学でむちゃくちゃな論理でやったもののが優れてる場合が多いからね

0485デフォルトの名無しさん

2006/03/28(火) 12:29:31

smartOCRのせいでコンシューマー向けOCR業界終わったよ。
将来性のある部署に異動したい。

0486デフォルトの名無しさん

2006/03/28(火) 12:52:15

でもLite版て認識率悪いし
Pro版は18万もして高いよ

0487デフォルトの名無しさん

2006/03/28(火) 14:01:10

認識率が良いというのは利用者にとっては１００％であるということであって
９９％だろうと８０％だろうと１個でもご認識が入れば同じ量の人間による検閲の必要性が出てくるわけで
どっちも認識率は悪いという評価になる
同じ悪いなら安いほうがいいに決まってる

0488デフォルトの名無しさん

2006/03/28(火) 14:19:15

んなこたーない

0489デフォルトの名無しさん

2006/03/28(火) 14:30:44

>>487
99％と80％では、検閲の必要性は同じでも、修正量が大きく違うわけだが。
そしてそれがそのまま効率に繋がる

0490デフォルトの名無しさん

2006/03/28(火) 14:57:05

量とかいう以前に、80%だと普通に全部タイプした方が早い予感。

0491デフォルトの名無しさん

2006/03/28(火) 15:13:54

ソフトメーカーのくせに個人もつくれる規模のソフトを何も知らない顧客に高値で売りつける精神が腐っとる

0492デフォルトの名無しさん

2006/03/28(火) 15:20:06

そりゃその気になりゃなんだって個人で作れるだろ

0493デフォルトの名無しさん

2006/03/28(火) 15:37:45

フリーソフトの次はオープンソースのOCRが来る予感。

0494デフォルトの名無しさん

2006/03/28(火) 15:54:03

e.typistなんか2万円以下で買えるのに
smarocrなんて定価が38万だよ？

ボッタクリすぎ

0495デフォルトの名無しさん

2006/03/28(火) 16:10:40

ライブラリのほうもアホみたいな値段だな。
まあ、それくらいの付加価値があると自分達は思ってんでしょ。

0496デフォルトの名無しさん

2006/03/28(火) 16:18:45

ターゲットがソフトハウスならライブラリ数十万って普通だろ

0497デフォルトの名無しさん

2006/03/28(火) 16:41:39

価格にあわない価値なら、買わなきゃいいだけだろ・・・

0498デフォルトの名無しさん

2006/03/28(火) 17:36:14

>497
ちょっとちがう。
「使わなければ」が正解。買う価値ない等と言いつつ使うやつがいるから、
不正コピーが減らない。
もっとも 494 みたいに、ＡとＢの価格を比較してボッタクリなどと言うやつはバカ。
ＣとＤの商店で、ＡとＡの価格を比較した時以外は、ほとんど無意味な概念＞ボッタクリ

0499デフォルトの名無しさん

2006/03/28(火) 18:01:32

文字認識は顔認識とかに比べてめんどくせーよな。
文字の切り出しからめんどくさい。
形にもっていくまで手間かかりすぎ。

0500デフォルトの名無しさん

2006/03/28(火) 18:06:54

Liteは認識率悪いよ
無料だからしょうがないけど

認識率はe.Typistの方が高いし
smartOCRのProより安い

質の悪いサービスを高い価格で提供していることをぼったくりという

0501デフォルトの名無しさん

2006/03/28(火) 18:10:04

smartOCRは敵が多そうだなｗ

0502デフォルトの名無しさん

2006/03/28(火) 18:17:32

変だね。ぼった栗なら、相手しなければいいだけ。
e.Typist で代替きくなら、無問題。なんでいちいちコメントするのかね？

0503デフォルトの名無しさん

2006/03/28(火) 18:30:49

JW-CADでCADメーカーが大損害を受けたのと同じで
フリーソフトでそこそこ使えるのが出現すると、今まで通りの商売ができなくなるからな～

0504デフォルトの名無しさん

2006/03/28(火) 18:35:57

そうか？フリーのそこそこ使えるOSがあるのにWindowsは大損害受けてないぞ

0505デフォルトの名無しさん

2006/03/28(火) 18:45:44

千億単位で大損害受けてるよ。兆単位で儲けているけど。

0506デフォルトの名無しさん

2006/03/28(火) 18:49:38

CADメーカーがクソだったってだけじゃないか

0507デフォルトの名無しさん

2006/03/28(火) 21:11:46

> フリーソフトでそこそこ使えるのが出現すると、今まで通りの商売ができなくなるからな～

それは、価格にあった価値がないからだな。
フリーソフトに負けるのは、負けた方がぼったくりだからだね。500 によると。

0508デフォルトの名無しさん

2006/03/28(火) 21:37:37

お金つぎこんでもフリーに負けるようじゃ
ワロス

0509デフォルトの名無しさん

2006/03/29(水) 17:34:52

OpenCVを入れてみたんですが、
cvCaptureFromCAM()を呼ぶと永遠に帰ってこなくて困ってます。
環境は
fedora core 5.
キャプチャボード(Bt878)*２
カメラは全部刺したり全部抜いたりしても変化無し。

エラーすら帰ってこないのでお手上げです。
解決法ご存じの方いましたら御教授下さい、

0510デフォルトの名無しさん

2006/03/29(水) 18:06:49

OpenCV エラーかえってこねーよな。
Yahoo Groups にいったほうがいいとおもう。英語だが。

0511デフォルトの名無しさん

2006/03/29(水) 22:13:31

opencvはマニュアルの整備がなされてなくて大変
結局ソース見てる
疲れる('A`)

0512デフォルトの名無しさん

2006/03/30(木) 06:44:36

>>509
その関数ってLinuxでも使えるの？
漏れもOpenCV使ってるんだがその関数は使えないものとｵﾓﾃﾀﾖ。
つかキャプチャボードからの場合はVideo4linuxとか使えないんだっけ？
あっちのほうが楽な気がする。

0513デフォルトの名無しさん

2006/03/30(木) 10:26:37

>>512
グハ…
勿論素のv4l使えば画像は取れるんですが、
configure時にv4lとv4l2にyesとか表示されるから
そのラッパとしてOpenCVを使えばもっと楽だと思ったんですが。。

IEEE1394関連を抜いてやり直してみてダメだったら、自前で取得する事にします。
#動画回りも使えんかったらOpenCV使うのやめよう…

0514デフォルトの名無しさん

2006/03/30(木) 22:05:20

素人が横槍入れて悪いんですが…
自分は普段Linuxで画像関係扱うのでV4L使ってるんですけど、
WindowsでV4Lみたいなのってあるんですか？

0515デフォルトの名無しさん

2006/03/30(木) 22:11:13

DirectShowかVideoForWindowsかな

0516デフォルトの名無しさん

2006/03/30(木) 23:24:36

linuxにあるものは大抵windowsにもある
windowsにあるものは大抵linuxにはない

0517デフォルトの名無しさん

2006/03/30(木) 23:32:35

>>516
たとえば？

0518デフォルトの名無しさん

2006/03/30(木) 23:38:27

DirectX,
APIレベルでのハード画像合成
動画コーデック
ゲームｗｗｗｗ

0519デフォルトの名無しさん

2006/03/31(金) 00:06:09

>>518
OpenGLでいいじゃんか

0520デフォルトの名無しさん

2006/03/31(金) 03:32:48

OpenGLはもともとCADに準拠した目的で設計されてその仕様はほとんど変化してない
拡張という形でグラフィックカードメーカー独自の仕様もあるにはあるが所詮は独自仕様でしかない
まあ所詮ＣＡＤだからワイヤーフレームがメインでテクスチャはおまけ機能なのだよ
ピクセル処理なんて到底向いてない

0521デフォルトの名無しさん

2006/03/31(金) 03:42:47

また根拠の無い話を

0522デフォルトの名無しさん

2006/03/31(金) 04:03:26

まぁ、OpenGLも2.0で変わるのかもしれないが、現状ではそうだな。
http://www.watch.impress.co.jp/game/docs/20060329/3dps3.htm

0523デフォルトの名無しさん

2006/03/31(金) 05:44:18

>>519
OpenGL は両方にあるじゃんか。

0524デフォルトの名無しさん

2006/03/31(金) 08:24:57

smartOCRを作っている会社は不審な点が多い
買わない方がいい、と忠告しておく

0525デフォルトの名無しさん

2006/03/31(金) 08:47:44

>>524
>>485みたいなひと？ｗ

0526デフォルトの名無しさん

2006/03/31(金) 09:24:08

性能良ければ、どこがつくっててもいいんじゃないの？

0527デフォルトの名無しさん

2006/03/31(金) 13:09:43

>>485は白旗を揚げて降参している
>>486だろ

0528デフォルトの名無しさん

2006/03/31(金) 16:30:33

個人情報保護法の施行で販売者の身元は必ずしも公の場にさらす必要はない
もちろん契約する場合は必要だが

0529デフォルトの名無しさん

2006/03/31(金) 19:36:18

潰れそうな会社なのか、それとも個人がシェアウェアみたく売っているのか、
消費税は取るのか、メール以外のサポート方法はないのか、全然分からん

読取革命体験版よりはるかに認識率が悪かったんだけど

0530デフォルトの名無しさん

2006/03/31(金) 21:44:56

なら無視すりゃいいじゃんか、変なヤツ大杉

0531デフォルトの名無しさん

2006/03/32(土) 00:47:43

んなのシランがな。

0532デフォルトの名無しさん

2006/04/02(日) 15:05:54

線形補間法で一番綺麗なのってどんな手法？

0533デフォルトの名無しさん

2006/04/02(日) 16:04:26

>>532
日本語として成り立っていない

0534デフォルトの名無しさん

2006/04/02(日) 17:24:41

>>532
とりあえず、一番綺麗なものを評価するプログラムを提示してくれたまえ

0535デフォルトの名無しさん

2006/04/02(日) 19:20:58

>>532
日本語として成り立っていない

0536デフォルトの名無しさん

2006/04/03(月) 06:56:23

フリーソフトがシェアを奪うジャンルのソフトは
つまりプロが作るまでもないってことでしょ。

セキュリティソフトは商用を機能制限して
一応無料で使えるようにしているものが多いけど。

0537デフォルトの名無しさん

2006/04/03(月) 08:16:10

フリー作家もふだんはプロとしてやってる人間なのにな
フリーだからとかプロだからとかそんなくだらない話したいの？

0538デフォルトの名無しさん

2006/04/03(月) 12:10:58

セキュリティソフトは感染者が少しでも少ないほうが
正規ユーザーの利益になるからです。
正規ライセンスの中に他の感染者からの攻撃の軽減という機能も含まれてるわけです
馬鹿

0539デフォルトの名無しさん

2006/04/05(水) 16:43:03

sobelフィルタなどで重みをかける例を
webサイトに乗っている例題などを見ると、
「端のピクセルは無視する」とあるのですが、
無視しない全画素に処理を施すにはどうしたら良いのでしょうか？
アルゴリズムが記載されているところがあれば、教えて下さい。
（端だけの処理の為に全画素にif/elseで分岐するわけないだろうし、、、）

0540デフォルトの名無しさん

2006/04/05(水) 16:55:51

端の処理が何ピクセルかを先に取得して、その分ループを分ければいいと思うが

0541?f?t?H???g?I`?1/4?3?μ?3?n

2006/04/05(水) 17:12:42

>>540

どういうことでしょうか？

0542デフォルトの名無しさん

2006/04/05(水) 17:35:46

画像が100x100だったら、102x102にして考えるってことだろ。はじは、隣のピクセルと同じ色だと仮定して。

0543デフォルトの名無しさん

2006/04/05(水) 17:37:54

外野だけど納得した

0544デフォルトの名無しさん

2006/04/05(水) 17:43:10

いや、ちょっと違う・・・
端のピクセルは同じ色だと仮定する別処理ループ、中のピクセルは通常処理でループっていう話。
端判定を全画素に行わないために処理を分けるってだけ。

0545?f?t?H???g?I`?1/4?3??E^?3?n

2006/04/05(水) 17:46:37

>> 542

102x102よいうことは、
全画素にif/elseで下のように

for(i=-1;i=101;i++) {
for(j=-1;j=101;j++) {
if(i==-1) i=0;
if(i==100) i=99;
if(j==-1) j=0;
if(j==100) j=99;

省略
}
}

分岐するということでしょうか（この場合コストがかかりすぎますよね？）？
本当にわかりません。

0546デフォルトの名無しさん

2006/04/05(水) 18:03:10

>>545
102x102のバッファにデータを移し替えて、1から101でループすればいいだけじゃん。

0547デフォルトの名無しさん

2006/04/05(水) 18:19:49

カレントピクセルを挟む差分なんだから、端なんか取ったって無意味だろ

0548?f?t?H???g?I`?1/4?3??E^?3?n

2006/04/05(水) 18:28:11

>> 546

ありがとうござざいます。
一回バッファーに入れるんですねありがとうございます。

0549デフォルトの名無しさん

2006/04/05(水) 18:31:45

>>545
if 文いらなくするために 102x102 に拡張したのに。
でもコピー自体コストかかるべ。

>>544さんは
ループ内に if 文を書かなくていいように
端っこの処理をまずやって、
端を含まない2重ループをその後にやればいいといっている。

端の処理は
１．そもそもしない
２．外の画素は端の画素と同じ値と仮定して延長
３．外の画素にだけマスクはあてない
４．外の画素はなんらかの補完処理によって作成（２の発展）
といまちょっと考えただけでこれぐらいは思いついた。考えた？

0550デフォルトの名無しさん

2006/04/05(水) 18:40:02

余分なバッファにコピーしない場合は
int i = 0;
処理A;
for (i = 1; i < 101; i++){
処理B;
}
処理C; //i == 101
っつー風に書く。これを縦横の組み合わせで9通り。
もちろん9通り馬鹿正直にかかずにマクロやtemplateで実装する。

0551デフォルトの名無しさん

2006/04/05(水) 18:46:07

馬鹿ばっかりなので天才の俺様が教えてあげよう
一時微分３ｘ３というのはなんのためにあるかというと
同じ比率ｆで変化させる平坦化させるなどの意味があるわけだ
-1,0,1
-2,0,2
-1,0,1
これがsobelの関数になるわけだがこれにはある規則性がある
なにかというと
中心の係数＝周囲の係数の合計値
である
例えば左が書けた場合を考えよう
0,1
0,2
0,1
合計は３だ
各画素値に係数を乗じたものを合計して係数の合計値で割ったものが中心の純粋な画素値になる
他の関数でも同じことだ
わかったか？

0552デフォルトの名無しさん

2006/04/05(水) 18:52:53

合計は４ですたorz

0553?f?t?H???g?I`?1/4?3??E^?3?n

2006/04/05(水) 19:55:22

>> 550

for (i = 1; i < 99; i++) {じゃないの？

0554デフォルトの名無しさん

2006/04/05(水) 20:23:43

あのな
周辺を除外したらエッジがはいらねーだろ
塗りつぶすときとかどうすんだ
あと大きめの画像を用意するってなんだ
いらないエッジはいりまくるだろ
へたしたら額縁みたいになるぞ
お前らもう少し頭使えなｗｗｗｗ

0555デフォルトの名無しさん

2006/04/05(水) 20:27:55

>>554
じゃお前が結論だせよ。アルゴリズムかけよ。

0556デフォルトの名無しさん

2006/04/05(水) 20:29:03

>>554の模範解答
　　　　　↓

0557デフォルトの名無しさん

2006/04/05(水) 20:39:16

>>551に書いてるだろ？頭悪すぎて理解できないか？ｗｗｗｗｗｗ

0558デフォルトの名無しさん

2006/04/05(水) 21:45:24

誤字脱字だらけで読む気が失せるんだけど。
つーか、誤字の訂正もできないほど無神経なのか。

0559デフォルトの名無しさん

2006/04/05(水) 22:15:40

ノイマンかトーラス拡張する。

0560デフォルトの名無しさん

2006/04/05(水) 22:21:25

int sobel1[9] = {-1,0,1,-2,0,2,,-1,0,1};
int sobel2 = sobel1 rotate 90

for(y=0;y<height;y++){

0561デフォルトの名無しさん

2006/04/05(水) 22:24:58

for8x=0;x<width;x++){

nt redsum = 0;
int count = 0;
;
for(i=-1,i<1;i++){
fo(j=-1;j<1;j++){

int sp = (j + 1) * 3 + i
int px = y * width + x + i;
int py =( y + j) * width + x;

0562デフォルトの名無しさん

2006/04/05(水) 22:27:24

if px,pyが範囲内なら){

rsum += image.red(px,py) * sobel[sp];
rsum += image.red(px,py) * sobe2[sp];
count += sobel[sp];

}

0563デフォルトの名無しさん

2006/04/05(水) 22:28:43

}
}

rsum /= 2;;
rsum /= count;

dest.setred(x,y,rsum);

}
}

0564デフォルトの名無しさん

2006/04/06(木) 06:24:41

>>563
count が 0 になるとき多数じゃね？あと誤字脱字キモス。

>>551
係数の合計値で割る？
255 255 255
255 255 255
255 255 255
に
-1 0 1
-2 0 2
-1 0 1
をあてると０になるわけだけど（変化がなかったの意）、
0 1
0 2
0 1
をあてて４で割るというその方式を採用すると、255 になんね？
そこがエッジってことになんね？かなり意味が違ってくると思う。

ってか質問主のきいている意図は for 文内に if がたくさん入っていやなんですけど、
なプログラミングレベルの話だべ？

0565デフォルトの名無しさん

2006/04/06(木) 09:14:24

で、結論（馬鹿ばっかりなので天才の俺様が教えてあげよう)
　　　　　↓

0566陵辱痴漢地獄

2006/04/06(木) 09:32:20

陵辱痴漢地獄

0567デフォルトの名無しさん

2006/04/06(木) 11:27:51

http://www.scanr.com/what.aspx
これどうやっているのかだれか推測してください。
このソフト欲しいなぁ。

0568デフォルトの名無しさん

2006/04/06(木) 11:36:50

二軸の直線成分を見つけてアフィン変換掛けてるだけ

だったらいいなぁ

0569デフォルトの名無しさん

2006/04/06(木) 13:07:04

>>567
リコーのデジカメにそういう機能あるね。
元々はプレゼンのスライドなんかを撮るための機能だけど、
CDのジャケット等四角い物なら何でも使えるから意外と便利らしい。

四角い物にしか使えないので、ハフ変換等で枠を検出してから
パース変換するだけかと。

0570デフォルトの名無しさん

2006/04/06(木) 14:56:29

>>564
その場合２５５じゃなくて１２７ね
sobelでエッジだしたあとに利用するときそのままじゃじゃまな要素が多いから
閾値で切り落としたりするときに消える

0571デフォルトの名無しさん

2006/04/06(木) 15:08:02

>>569
うまいこと白地に変換するのってどうやるんでしょうか？
スキャナとかにもよくある機能ですが。

まず背景色をこれ。と決めるんだろうけど、それを決めるのも
単純な方法だとうまくいかない場合がありそう。
ただ一番白に近いのを背景色とするとか（ＣＤケースの光の反射部分が一番白くなる）、
枠内の白に近い色の平均値を背景色とするとか（白に近いってなんぞや）。
けっこうめんどくさいのかなやっぱり。

0572デフォルトの名無しさん

2006/04/06(木) 15:09:27

>>570
255*1 + 255*2 + 255*1 / 4 = 255 じゃね？

0573デフォルトの名無しさん

2006/04/06(木) 15:30:38

>>571
四角で整形したあとに原色処理で色をグルーピングする

>>572
sobelを基本から勉強しる

0574デフォルトの名無しさん

2006/04/06(木) 16:30:26

>>571
そこのサイトの場合は、白い背景限定みたいだから
そこからホワイトバランスを調節しているだけかと。

0575デフォルトの名無しさん

2006/04/06(木) 19:07:59

意外と皆、基礎がわかってないんだねw

0576デフォルトの名無しさん

2006/04/06(木) 19:09:40

>>575
そういう基礎を復習したいのですがオススメの本ないですか？

0577デフォルトの名無しさん

2006/04/06(木) 20:48:42

海外ならRosenfeld本、日本ならあぐい本あたり？

0578デフォルトの名無しさん

2006/04/06(木) 20:51:49

ホワイトバランスかけてアフィン変換だろ？

0579デフォルトの名無しさん

2006/04/07(金) 00:33:44

>>577
ありがとうございました
検索してみます。

0580デフォルトの名無しさん

2006/04/08(土) 06:01:34

ウィナーフィルタがさっぱりわからんぽん(´Д｀;)

0581デフォルトの名無しさん

2006/04/08(土) 06:39:45

>>580
http://www.kougendo.co.jp/newsite/img/wintergift/sousage-image.jpg

0582デフォルトの名無しさん

2006/04/08(土) 08:44:16

論文になってるアルゴリズムを自分で実装した場合は特許とか著作権の問題はないと思っていい？

0583デフォルトの名無しさん

2006/04/08(土) 09:28:14

著作権は大体大丈夫だが特許はダメ

0584デフォルトの名無しさん

2006/04/08(土) 12:56:50

最近は、論文として発表する前に予め特許申請する場合が多いらしいよね

0585デフォルトの名無しさん

2006/04/08(土) 13:07:12

特許法には、
第29条　産業上利用することができる発明をした者は、次に掲げる発
明を除き、その発明について特許を受けることができる。(以下略)

第30条　特許を受ける権利を有する者が試験を行い、刊行物に発表し、
電気通信回線を通じて発表し、又は特許庁長官が指定する学術団体が
開催する研究集会において文書をもつて発表することにより、第29条
第１項各号の一に該当するに至つた発明は、その該当するに至つた日
から６月以内にその者がした特許出願に係る発明についての同条第１
項及び第２項の規定の適用については、同条第１項各号の一に該当す
るに至らなかつたものとみなす。

という罠もあるしな

0586デフォルトの名無しさん

2006/04/08(土) 17:11:15

つまり発表後６ヶ月以内に特許出願しなかったら特許は取れないということ？

0587デフォルトの名無しさん

2006/04/10(月) 11:55:27

画像処理初めてで色を取得して一番多い色を表示するってのを作りたいんだけど、
色の取得はGetPixelとかWinAPI使わないとできないの？

0588デフォルトの名無しさん

2006/04/10(月) 12:22:19

>>587
どこの画像を調べようとしてるのか知らんけど

画像ファイルから計算すれば、
GDI周りのAPIは関係ないんじゃね？

0589デフォルトの名無しさん

2006/04/10(月) 12:28:55

>>587
初めてならGetPixelでいいんじゃない？
画像の読み込みも表示もそのままできるし。

ただ、ピクセル毎にGetPixelを呼んでいたら遅くなるので、
普通は配列に画像を入れて直接アクセスする。
処理が終わってから、配列からBITMAPを作って表示。

ちなみに、一番多い色を調べるというのはやることが単純な
わりには面倒な問題。
24bitカラーは1677万色あるので、全ての色に対してカウンタを
DWORDで用意すると、それだけで64MBもメモリを食ってしまう。
まぁ、いまどきのPCなら64MBくらい平気で使えるが…

カラー画像をモノクロに変換する…という処理の方がもっと簡単で
画像処理らしくていいと思う。

0590デフォルトの名無しさん

2006/04/10(月) 12:39:13

>>589
いや、普通はDIBSectionだろ。
GDI経由でいじることもポインタ経由で配列のようにいじるのも自由自在。
ついでにDIBSection相手ならDDBに比べればGetPixel/SetPixelも遅くない。

まー、今からならGDI+とかすすめとくが。画像ファイルのI/O圧倒的に楽だし。

0591デフォルトの名無しさん

2006/04/10(月) 14:47:27

なんで高が画像処理でOS依存し捲くりのプログラムを作ろうとするかね。
適当なライブラリさえ用意すればOSに殆ど依存しないで書けるだろうに。
つーことで、画像フォーマットはテキストエディタでも確認可能なpnm(Ascii)お勧め。

0592デフォルトの名無しさん

2006/04/10(月) 15:10:12

>589
いや、画素数以上はいらんだろ＞カウンタ数
多少時間がかかってもいいなら、連想記憶配列でいいんじゃね？楽で。

0593587

2006/04/10(月) 15:19:33

>>588-589
言語だけでできるのか。
なんとなく配列とかそこら辺までは分かるけど、画像って当然ヘッダー部があるよね？
fopen()でファイルの先頭から配列に詰め込んでいったら色と関係ないものまで入ってきそう。
jpg,png,bmpとかヘッダーの形式全然違うよね？

>GDI+
分からんです･･･

>カラー画像をモノクロに変換する
そうだね、最初はその辺を目指してみる。
高度な画像処理でいきなり潰れても困るし。

0594デフォルトの名無しさん

2006/04/10(月) 15:21:35

>>593
文盲ですか?

＞適当なライブラリさえ用意すればOSに殆ど依存しないで
＞画像フォーマットはテキストエディタでも確認可能なpnm(Ascii)お勧め

0595デフォルトの名無しさん

2006/04/10(月) 16:25:43

>>594 ごめん

>ライブラリ
探してみたけど、なかなかよさそうなのが無くて。
jpgやpng読み込みに対応してるフリーなのをひとつ見つけたけど、
内部でWinAPI使ってたんでOSに依存するんじゃないかな･･と。

>pnm
jpgやpng等の画像に対して処理をしたいので、他形式だときついです
pnm形式への変換にも時間かかりそうだし

何バイトから何バイトまで○○情報、とかヘッダ部の記述が分かればなんとか書けそうなんだけど、
検索してもなぜかrawとかbmpばかりで他フォーマットを解説してるサイトが見つからない

0596デフォルトの名無しさん

2006/04/10(月) 16:44:02

jpgやpngの読込なんて、下手な画像処理より難易度高いと思うんだがｗ

0597デフォルトの名無しさん

2006/04/10(月) 16:52:21

>>595
jpgやpngを読み込みたいという目的があるならそれを先に書け。
純粋に画像処理を試したいという目的だと思ったからpnmを勧めたんだ。
ライブラリがないというが、ImageMagickならOSに依存せずにどちらも問題なく読めるぞ。
勿論、本家libjpegやlibpngを使ったってどってことはない。

一応書いておくが、ヘッダ部とデータ部を判別できたとしても、pngとjpegは全く違う
圧縮アルゴリズムで圧縮されているのでライブラリなしじゃ到底無理だぞ。

0598デフォルトの名無しさん

2006/04/10(月) 16:53:43

色数とるだけなら、JpegやPngもBmpに直してそっから取りゃいいだろ

0599?1/4?3?μ?T???v?????O??48kHz

2006/04/10(月) 17:14:01

jpgやpngを読み込み、処理し、出力するプログラム
をライブラリやapi無しで書ける人はここに一体何人いるのだろうか、、、。

0600デフォルトの名無しさん

2006/04/10(月) 17:19:12

なんだこの48kHz。

0601587

2006/04/10(月) 17:34:11

>>596-598
そうでしたか、すまん。
レスを見るとどうやら俺はもっと根本的なところからやった方がよさそうだ。
今まで何するにもライブラリを避けて通ってきたから画像処理も言語だけでできると思ってたけど、
今回はゲーム用ライブラリを使わないとかそういうレベルじゃないみたいだな･･
貰ったレスを頭の端に置きつつ画像処理本でも買ってまともな発言できるくらいまで少し本格的に勉強してみる
色々とありがとう

0602デフォルトの名無しさん

2006/04/10(月) 18:53:44

画像処理が盛んな国内企業ってどこがありますか
東芝とか？

0603デフォルトの名無しさん

2006/04/10(月) 19:16:54

NHK

0604デフォルトの名無しさん

2006/04/10(月) 19:38:23

>>602
ソフト・オン・デマンド
北都

0605デフォルトの名無しさん

2006/04/10(月) 19:49:25

ソフトオンデマンドのデジモってレベルセットかな

0606デフォルトの名無しさん

2006/04/10(月) 20:19:13

画像処理は基本的に広告関係だろ
Photoshop使ってポチポチやってるだけだけどｗ

0607デフォルトの名無しさん

2006/04/10(月) 20:30:31

それは、このスレで言う画像処理には含まれないだろ

0608デフォルトの名無しさん

2006/04/10(月) 22:44:52

上で出てたので気になったんだけど
画像処理用のライブラリでお勧めってどんなのがある？

ほとんどImageMagickしか使ったこと無いな。

0609デフォルトの名無しさん

2006/04/10(月) 23:20:08

>>608
ImageMagickでいいじゃん。
libpngとかlibtiffなんかの本家のライブラリは結構めんどいよ。

0610デフォルトの名無しさん

2006/04/10(月) 23:31:32

読み込みとか保存操作やビット操作のオーバーヘッドを簡略化したいのならwxWidgetsがお勧め

0611デフォルトの名無しさん

2006/04/11(火) 03:07:39

このスレで書いてる人達はカメラを使う場合、IEEE接続とUSB2.0接続のどっち使ってます？
画像処理を専門にする人達にはどっちの方が主流なんですかねぇ？

0612デフォルトの名無しさん

2006/04/11(火) 03:11:47

( ﾟдﾟ)ﾎﾟｶｰﾝ

0613名無し募集中。。。

2006/04/11(火) 03:41:35

IEEE1394とCameraLinkは使ったことあるよ。あとNTSC, RS-170ね
1394はCPU負荷高くなるんだけどカメラのシャッタースピードや
ゲインを1394を使って変更できるので楽と言えば楽。
でも、ﾌﾚｰﾑｸﾞﾗﾊﾞと画像処理は近いけど違うって言えば違う分野

0614名無し募集中。。。

2006/04/11(火) 03:48:59

susie-pluginを使ってjpegやpngを読んで、DIBから配列に入れなおしたりしたっけ
Y = 0.299R + 0.587G + 0.114B がモノクロ変換の計算式な

0615デフォルトの名無しさん

2006/04/11(火) 04:18:21

それモノクロじゃなくてグレースケールなｗ
ところで指定した複数の点を通る曲線を描く計算式探してるんだけど
カーティナルスプラインってGDI+のAPIまでは見つかったんだがそれで検索しても
計算式が見つからない
もしかして正式名称が別にあるのか？

0616デフォルトの名無しさん

2006/04/11(火) 04:26:00

と書いたら見つかった

0617デフォルトの名無しさん

2006/04/11(火) 07:26:37

PDFから画像への変換にghostscript使ってるんだが遅い
良いライブラリとか回避策ないの？

0618デフォルトの名無しさん

2006/04/11(火) 12:19:41

回避策としては、
AdobeReaderから、画像ファイルを吐くプリンタに印刷するとか

画像処理じゃねーな・・・スマソｗ

0619デフォルトの名無しさん

2006/04/11(火) 19:23:37

>>617
http://poppler.freedesktop.org/
だけど、これを使っているevinceは重いので、
速いかどうかは、、、

0620デフォルトの名無しさん

2006/04/11(火) 19:36:53

ものには限度があることを知るべき

0621デフォルトの名無しさん

2006/04/11(火) 19:52:39

>>618-620
ｻﾝｸｽ

0622デフォルトの名無しさん

2006/04/11(火) 19:55:19

Acrobat買ってAdobeが公開しているAPI使って変換するのが
真っ当なやりかただとおもう。

0623デフォルトの名無しさん

2006/04/12(水) 06:59:10

.NetのDrawing2D.Matrixというクラスがあって名前のとおりただのベタな２次元配列なわけだけど
こいつのRotateメソッドがむちゃくちゃ早い
この速さを.Net使わずに実現したいんだが中身がなにやってるのか調べ方がわからない
誰かその辺詳しい人いませんかね
DirectXにそんなベタデータを汎用的な環境でアクセラレートする機能はなかったと思うんだけど
MMXであそこまで早くなるもん？
どれくらい早いかはPaint.Netっていうフリーのソース付のペイントソフトがあるので回転ツールで
けっこう大き目の画像をぐるぐる回してみればわかる

0624デフォルトの名無しさん

2006/04/12(水) 07:25:18

回転でそんな驚くようなアルゴリズムはありえないだろ
普通にソース側の座標をＤＤＡで計算してるだけだと思うけどなあ

0625デフォルトの名無しさん

2006/04/12(水) 07:26:40

>>623の書くコードが糞なだけだろ。

0626デフォルトの名無しさん

2006/04/12(水) 07:29:15

おれも回転のアルゴリズムはバリエーションしらんが・・・

0627デフォルトの名無しさん

2006/04/12(水) 08:37:34

>>624-626
騙されるな、>623は「早い」としか言及していないぞ。
きっと、速度が速いのではなく手っ取り早いとでも言いたいのじゃないか?

0628デフォルトの名無しさん

2006/04/12(水) 08:43:11

>>624
>>625
実際にスピード見てみたか？
DirectXでっポリゴンまわすのとスピードが変わらんよ
知ってる限りＭＭＸ使った９０度回転ですらこれより遅い
もちろんペイントソフトでレイヤーがある上に覆い焼きとか特殊なブレンドがあるから
DirectXでないのはたしかだが

0629デフォルトの名無しさん

2006/04/12(水) 08:57:21

>>628　GPUよりCPUの方が速いんだから、まともに書けばDirectXより速くてあたりまえだろ
この処理の殆どはメモリアクセスにかかる時間だから
90度回転より遅くなるのは描画側の領域が大きくなるせいってだけ

回転である事のメモリアクセス以外の負荷はＤＤＡを使えば殆どメモリアクセスに隠れてしまう

0630デフォルトの名無しさん

2006/04/12(水) 08:59:45

さっきからＤＤＡと言ってるが検索しても出てこない用語ですｗ

0631デフォルトの名無しさん

2006/04/12(水) 09:01:01

>>GPUよりCPUの方が速いんだから
さすがにそれはないだろｗ

0632デフォルトの名無しさん

2006/04/12(水) 09:47:06

GPUがCPUに対して演算性能が高いというのは、その高い並列処理能力でカバーしてるからの話。
その演算性能というのも、浮動小数点演算でそれもせいぜい32bit(24bit)

回転しながらフィルターをかけるような演算を含まない、単純な回転はメモリー転送速度の速さだけが限界を決める

0633デフォルトの名無しさん

2006/04/12(水) 09:50:14

>>630
デジタル微分解析　を足したらでるんじゃない？
基本的に回転は直線の描画と同じだよ。

0634デフォルトの名無しさん

2006/04/12(水) 09:52:47

どうでもいいから俺に7800GTXよこせ

0635デフォルトの名無しさん

2006/04/12(水) 09:54:44

いまさら、7800なんて・・・

0636デフォルトの名無しさん

2006/04/12(水) 09:56:05

この野郎俺が少し遠慮したのが分からんのか

0637デフォルトの名無しさん

2006/04/12(水) 10:34:12

回転って、srcをスキャンするのとdstをスキャンするのとどっちが速度が上がるんだろ？

0638デフォルトの名無しさん

2006/04/12(水) 10:37:08

( ﾟдﾟ)ﾎﾟｶｰﾝ

0639デフォルトの名無しさん

2006/04/12(水) 12:23:08

ループ内は
if(sum__c += c >= LIM ){ x++ ; sum_c -= LIM;}
if(sum__s += s >= LIM ){ y++ ; sum_y -= LIM;}
*p++ = VRAM[ y] [x ]
となるわけだけど、

if(sum__c += c >= LIM ){ s++ ; sum_c -= LIM;}
if(sum__s += s >= LIM ){ s+=WIDTH ; sum_y -= LIM;}
*p++ = *s;
とすれば少し

さらに、　アセンブラで書けば
　LIMを UnsignedIntMax+1として CFを使えば
sum__c +=c if(CF ) s++ ;

と簡単になる。さらに s++の部分、条件代入を使って

0640デフォルトの名無しさん

2006/04/12(水) 12:39:17

（省略されました続きを読むにはここをクリックしてください)
　　　　　　　　　　　　　　　　　　　￣￣

0641デフォルトの名無しさん

2006/04/12(水) 13:02:10

ワッフルワッフル！

0642デフォルトの名無しさん

2006/04/12(水) 13:50:52

>>639
おもしれえ変数名のつけ方だな
sum__cとsum_cはどう意味が違うんだ？

0643デフォルトの名無しさん

2006/04/12(水) 14:04:47

ためしにPaint.Netっての落としてみたけど、特別速いとも思わないが…
[Layers]-[Rotate / Zoom]でグリグリ回してみたが、これじゃなくて？

描画の途中でも角度が更新されると途中で打ち切って新しい角度で
描画を再スタートするから反応はいいけどね。

しかし、この[Rotate / Zoom]のインターフェースはいいね。使いやすい。
最近のレタッチソフト全然使ってないけど、みんなこんな感じなの？

0644デフォルトの名無しさん

2006/04/12(水) 14:08:46

>>642
俺はsum__sとsum_yの関係が気になった。

0645デフォルトの名無しさん

2006/04/12(水) 14:26:32

慌てて書いて編集途中で投稿したんだろ
if(sum_c += c >= LIM ){ x++ ; sum_c -= LIM;}
if(sum_s += s >= LIM ){ y++ ; sum_s -= LIM;}

0646デフォルトの名無しさん

2006/04/12(水) 15:40:29

オレの場合は回転する画像は拡大された画像（回転後に綺麗に見えるように）だから
固定小数点だと　少し厄介なんだよな

SSEならx,yに変移を一度に加算出来る。
それをCVTPS2PI　でPMADD　で一気にアドレスが求まるなら・・・・・・いいんだけどなあ

0647デフォルトの名無しさん

2006/04/12(水) 17:33:14

>>643
なぜかそれ遅い
ツールに黒い矢印があるでしょ、それで右ドラッグで回転できるんだがこれが描画打ち切ってる
とかの次元じゃなくシームレスに回転しやがります
この速度は老舗のPhotoShopよりも早い
そっちで見てみて
ちなみのこのソフトはＭＳ社員がプライベートで作ったものらしい

0648デフォルトの名無しさん

2006/04/12(水) 17:56:05

>>647
そっちも試してみたが、こっちは操作中はポイントサンプリングだし
こんなもんだろう。C言語だけで書いてもこの程度は出る。

0649デフォルトの名無しさん

2006/04/12(水) 17:57:55

>>648
最大画面でサンプリングが１００％の状態で画面いっぱいの領域をまわしてみ

0650デフォルトの名無しさん

2006/04/12(水) 18:05:42

つまり、操作中は、皆が書いてる方法で高速に描画しておいて
操作が止まった途端にフィルタをかけた精密な方法で描画しなおしているという事だよ

0651デフォルトの名無しさん

2006/04/12(水) 18:06:11

>>623
まあどうでもいいことだが、GDI+使えば同じことできるし、生で叩ける分.NETより速いぞ多分。

0652デフォルトの名無しさん

2006/04/12(水) 18:12:45

>>650
そんなことはしてない

0653デフォルトの名無しさん

2006/04/12(水) 18:14:38

>>652
？　□を画面に描いて、それを回転させて、マウス（右でも左でも）を押し続けてごらん

0654デフォルトの名無しさん

2006/04/12(水) 18:20:57

フィルタってアンチエイリアスのことか
ためしに上に半透明レイヤーでもかぶせればわかるが
回転中もブレンド計算されてるからね
うちの画面サイズだと1000x1000が表示できるんだが
ぐりぐり回りますよ
このサイズをいくら単純なアルゴリズムでやったってマウスに連動して回転させるなんて
私はそんなアルゴリズム知らない

0655デフォルトの名無しさん

2006/04/12(水) 18:23:46

だから >>639の書いてるようなスタイルで実際に書いてごらんよ。　そしたら判るでしょ

0656デフォルトの名無しさん

2006/04/12(水) 18:46:25

>>654
知らないから聞いてるのは判ってるし、みんなが答えてくれてるのに
どうして教えてくれてる人のレスを全部無視して、凄い凄いばかり言うわけ？

こういう処理はメモリへのアクセスがネックになるから
アンチエイリアスをかけない回転は　LD+ST のコストだけど
ブレンド処理は　LD+LD+STとなって、回転より重い。
実際、上にレイヤーを追加すると途端に回転も重くなるでしょ？

で、アンチエイリアスをかけると、途端に回転処理はアドレス計算と重み計算のコストが増大して重くなる

0657デフォルトの名無しさん

2006/04/13(木) 04:07:28

もう馬鹿はスルー汁。
こんな奴は初心者でも何でもない。

0658デフォルトの名無しさん

2006/04/13(木) 06:03:24

やってみたけど別に早くない

0659デフォルトの名無しさん

2006/04/13(木) 10:18:36

>>658
どんなコードを書いたの？　一番内側のループを晒してみて

0660デフォルトの名無しさん

2006/04/13(木) 10:30:08

if( x1 >= 0 && x1 < SrcWidth && y1 >= 0 && y1 < SrcHeight ) {
dst[x2 + y2*DstWidth]=src[x1+y1*SrcWidth];
}else{
dst[x2 + y2*DstWidth]]=0;
}

0661デフォルトの名無しさん

2006/04/13(木) 10:33:30

>>660
１、条件文を外に追い出したら多少速くなるよ
２、掛算の部分は y2への加算に置き換えるべきだよ
３、dstはポインタにして >>639のように連続して処理すると少し早くなるよ
４、ところで、それ回転じゃないよね？

0662デフォルトの名無しさん

2006/04/13(木) 10:44:34

回転後の収まるべき画像サイズを計算して配列を容易してその座標空間において
y2,x2のループが外側にあります
y2ループでスキャンすべきソースの原点を計算します
x2ループはX,Yのそれぞれの増分を原点に加算するだけ
現在参照すべきソース座標がx1,y1に入っております

条件文は外にはだせません
y2置き換えても対して早くないです
dstポインタにしましたが遅いです
回転です

0663デフォルトの名無しさん

2006/04/13(木) 10:48:29

一番簡単な回転のアルゴリズム（アンチエイリアスをしない場合）

まず、方眼紙を用意してね。

方眼紙の1cmの目が1ドットとするよ。
2枚の方眼紙を重ねて、上の紙の5mmの中心の部分のドットの色をそのまま採用するという方法でのアルゴリズムを考えるよ。

判りやすくする為に、 x,yを浮動小数点としよう 1cm単位に表現するよ
回転変換 x' := c*x+s*y +x0 y' :=-s*x+c*y +y0
まず、下の紙の描画領域が　ピッタリ収まるサイズを求める

0664デフォルトの名無しさん

2006/04/13(木) 10:53:19

で SrcWidth SrcHeight から、 DstWidth SrcWidth を求めたら

次に、どの点で下の矩形が上の矩形と接するかを求める
左右の壁と接する点までのＹ座標２つによって３つに別ける

ここまでいい？

それぞれ計算式をたててみて・・・というか計算出来るものとしてすすめるよ

0665デフォルトの名無しさん

2006/04/13(木) 11:06:07

x,y を浮動少数と言ったのは説明のためで、実装では固定少数（かＤＤＡ）を使うよ

で、符号と、>>664の左右のどちらが先に来るかでによって８つに別けよう
時計回りに最初の手続きは　右側が先に来る。
　この手続きの最初のループはその右側と接触するy座標までだ。
　次のループは左の接点まで、
　最後のループは終点までだ

x座標の範囲は、この間、下の方眼の輪郭が、上の5mmと交わる座標となる
その座標は一番上で始点、終点を調整すれば足し算だけで計算出来るね？

0666デフォルトの名無しさん

2006/04/13(木) 11:19:05

一番内側のループは、x方向に1単位にスキャンすることになる

下の座標にたいしての上の座標の変換　回転変換 x' := c*x+s*y +x0 y' :=-s*x+c*y +y0 の
逆変換を求めればいいわけだけど
これは結局x,yに対して c , -s のステップになる。

だから、このループの内側は、単なる加算で実現出来る

　浮動小数点を整数演算に出来れば、整数演算は巧くゆけば1サイクルに複数実行されるので高速だ

整数演算化する方法は２つ、固定小数点化するのとＤＤＡ
　固定小数点はs,cを2^16倍して、32bitレジスタの上位16ビットを座標に割り当てる
　DDAは>>639のように累計レジスタを用意して小数点以下が溢れると整数部を増やす仕掛けで実現する

　固定小数点だと最大サイズか、細かさのどちらかを犠牲にしなければいけない

0667デフォルトの名無しさん

2006/04/13(木) 11:24:41

と説明書いてたけど、コード書いた方が速いなあ・・・・でも書いたら負けかな

0668デフォルトの名無しさん

2006/04/13(木) 11:29:23

>>1をちゃんと読んでないだけで負け

0669デフォルトの名無しさん

2006/04/13(木) 11:31:54

十分的が外れてる件についてｗ

0670デフォルトの名無しさん

2006/04/13(木) 11:42:58

>>660
具体的に、一番内側のループが
{
*dst ++ = src[ (x1>>16) + ay1 ];
x1 += c;
y1 += s;
if(y1>0x10000){ ay1+=SrcWidth ; y1-=0x10000;}
}
てな感じになれば早くなるよ
さらに早くしたいならif 文はアセンブラで 16bit加算で CF を見て CMOV　して加算

0671デフォルトの名無しさん

2006/04/13(木) 15:54:29

ボトルネックは本当にそこなのかと問い詰めたい

0672デフォルトの名無しさん

2006/04/13(木) 16:00:02

少なくとも>>660のコードのボトルネックは
【条件分岐がループに入っている】事だよ。　しかも４つも。

さらに掛け算が入ってる事も影響するし
>>660には書かれていないが、x1,y1の更新も何か変なこと（例えばテーブルを引くとか）をしてるのではないかと想像

0673デフォルトの名無しさん

2006/04/13(木) 20:10:38

P6に限ればこんな条件の分岐が4つ+ループの分岐くらい問題にならない。
他のボトルネックが埋まってから初めて考えればいい。

671に同意でこのループだけででタイム計ったら実は全体の何割も無いのではないか?

0674デフォルトの名無しさん

2006/04/13(木) 20:21:16

残念だけど、ループも分岐なので、分岐が５つとなり、ＢＴＢが１個不足する

0675673

2006/04/13(木) 20:38:57

ループの分岐は逆流なのでテーブルは消費するものの、実質必要ない。
内側も660は真をメインにしているので、テーブルは実質必要ない。

つまり、分岐にかかるのは条件を判定するコストのみ。
このコストも、どう考えても「遅い」と嘆くような量じゃない。
だから他の要因を先に潰すべき。

繰り返しになるがCで書いているならループにかかるタイムは問題じゃないと思う。

0676デフォルトの名無しさん

2006/04/13(木) 20:54:32

てかよーーーーーーーーく考えろよ

1000x10000がマウスに連動して回るということは
単純に1000x1000をループでコピーするだけで出来ると思ってるのか？
実際は描画にかかるコストも入ってくるし何倍も付加がかかるぞ
1000x1000を普通にbitbltしてどれくらいのfpsが出ると思ってるんだ？

0677デフォルトの名無しさん

2006/04/13(木) 20:58:33

>675
そんなＣＰＵの分岐予測なんて問題を取り扱う以前に、
上の方で誰かが書いているが、座標で取り扱わずポインタにしなさい。
それだけで、相当速くなるから。
おそらく、アフィン変換をやるときに、転送先座標、x2, y2 から逆関数で、x1, y1 を
見つけて、そのデータがあれば、x2, y2 に代入、なければ０を代入している部分だと
思うが、アドレスにするだけで同じアルゴリズムでもクリッピングに必要な条件判定が
２個で済むし、そもそも配列のアドレス計算が不要になる。
y2*DstWidthやy1*SrcWidthなんて、このループ内では定数なんだから、単純に、
*dest++ = *src;
となって、圧倒的に速いと思うよ。まあ、がんがれ。

0678デフォルトの名無しさん

2006/04/13(木) 21:16:27

もうしょうがない。 pascalスタイルでもう少し詳しく書くよ

c:=cos(deg*PI/180); //回転角をcos/sinに変換
s:=sin(deg*PI/180);
c,s　の符号とゼロかどうかで６つに分岐する
　最初の c>0 s>0 について

xs:=src.Width*c+src.Height*s;//回転結果が収まるxサイズ
RY:=src.Width * s;
LY:=src.Height * c;
ys:=RY + LY;//回転結果が収まるyサイズ

//　ここで xs,ysの領域を確保するよね

if RY<LY then ・・・　else と２つに分岐する。　ここでは RY<LYとするよ

0679デフォルトの名無しさん

2006/04/13(木) 21:25:31

ts:= round(s*$10000); //サイン・コサインを16bit固定小数点とする
tc:= round(c*$10000);

■最初のループは元絵　左側面から天井にかけてのスキャンＲＹまでね

xL:=src.Height*s; //天井での元絵との接点座標
xR:=xL; //ホントは0.5オフセットを入れた方がいいかもしれないね。そこらへんはもっと考えてね。
sy0:=0; //

for i:=0 to trunc(RY)-1 do begin //これがy方向の最初のループ
dp:=dst.ScanLine[i]; //描く側のポインタを設定して

for x:=0 to trunc(xL)-1 do begin dp^:=0;inc(dp);end; //左側の余白

sy:=round(sy0*$10000) ; //ここもsy0を整数化すれば単なる代入ですむよ
sx:= 0 ; //初期値はtc/2の方がいいかもしれないね。これも考えてね

　 for x:=trunc(xL) to trunc(xR)-1 do begin
　　 dp^ := src[sy SHR 16][sx SHR 16]; //ここらへんはアセンブラで書けばもっと短く出来るよ
　　 inc(dp);
　　 sx :=sx+tc;
　　 sy :=sy-ts;
　 end;
for x:=trunc(xR) to w-1 do begin dp^:=0;inc(dp);end;//右側の余白
sy0 :=sy0+ 1/c ;//このあたり、逆数は計算しておくこと。　まあ外のループだからそれほどシビアじゃない
xR :=xR + c/s ;
xL :=xL - s/c ;
end;

0680デフォルトの名無しさん

2006/04/13(木) 21:30:45

■2番目のループは元絵　左側面から右側面にかけてのスキャン

xR:=xL+ src.Width *rc; //　xRの位置を計算しておこう

for i:=trunc(RY) to trunc(LY)-1 do begin
　 dp:=dst.ScanLine[i];
　for x:=0 to trunc(xL)-1 do begin dp^:=0;inc(dp);end;　//左側の余白

後は同じだよ
sy:=round(sy0*$10000) ; //ここも上と同じ
sx:= 0 ; //

　 for x:=trunc(xL) to trunc(xR)-1 do begin　//違うのはここ
　　 dp^ := src[sy SHR 16][sx SHR 16]; //後同じ
　　 inc(dp);
　　 sx :=sx+tc;
　　 sy :=sy-ts;
　 end;

　for x:=trunc(xR) to w-1 do begin dp^:=0;inc(dp);end;//右側の余白
　sy0 :=sy0+ 1/c ;
　xL :=xL - s/c ;
　xR :=xL + src.Width / rc ;　//ここが違う。　左側に回転してみた幅だけ長くなるわけ

end; //2番目のループここまで

0681デフォルトの名無しさん

2006/04/13(木) 21:33:31

■３番目のループは元絵　底から右側面にかけてのスキャン

もう殆ど同じだから判るよね？　

判らないならここまでを動かしてみて、考えてみればいい。

他の角度についても同じ。　とりあえず動かしてみながら修正すればいい

0682デフォルトの名無しさん

2006/04/13(木) 21:36:20

trunc は切捨て関数
round は丸め
ＳＨＲ　は >> と同じで右シフト

inc(dp) は dp++

0683673

2006/04/13(木) 21:51:15

>>677 分岐なんて問題じゃないから取り扱うなと主張してるんだよorz
>>678 コードを晒したので負け組

0684デフォルトの名無しさん

2006/04/13(木) 22:02:54

>>683
画像処理のように繰り返し数が多い場合、
一番内側のループでの分岐は問題だよ。
たとえ予測が働いても分岐1個でレイテンシ１が追加されるんだから
整数命令何個分にもなる

だいたい else を実行する時はアドレス計算が必要ないのに、毎回計算されているのも問題

>>678-681の方法は　この条件判断を外に追い出したもの。
その為に、4*2+2=10個の手続きを作る必要がある。

0685デフォルトの名無しさん

2006/04/13(木) 22:18:48

>>680　ちょっとコメント間違い

　 for x:=trunc(xL) to trunc(xR)-1 do begin　//違うのはここ

とあるけど、ここも同じ

0686デフォルトの名無しさん

2006/04/13(木) 22:26:58

もう２箇所間違ってた
×　xR :=xL+ src.Width *rc;
×　xR :=xL + src.Width / rc

○　xR :=xL+ src.Width / c;

言い訳・・・・除算は少しだけ遅いから予め逆数を作って試してたんで

0687デフォルトの名無しさん

2006/04/13(木) 22:47:46

if文は、for文の外に出して関数ポインタを使おうね、ってことだね

0688デフォルトの名無しさん

2006/04/13(木) 23:01:39

関数ポインタも間接的な分岐扱いだろ

0689デフォルトの名無しさん

2006/04/13(木) 23:06:12

内側のループで分岐させずに、分岐した後でループしろってことだろ

0690デフォルトの名無しさん

2006/04/13(木) 23:32:04

関数ポインタも理解できない奴がいるとは。。

0691デフォルトの名無しさん

2006/04/13(木) 23:34:21

つまり >>679-680の　1番目と2番目の違いは1行だけだから
これを関数ポインタにしてコールバックさせようという事？

0692677

2006/04/14(金) 00:34:56

>683
スマンリンク間違い >672-673 が正解。

>684
683が言いたいのは、分岐よりも配列のアドレス計算の方がボトルネックに
なってんじゃねーのという事だと思われ。
ただ、>672-673 のやりとりが誤解を死ぬほど招きそうな言い回しなので、
分岐なんかたいしたことない、ばかりが強調されている。

もちろん最適化するときは、もっとも内側のループから、キャッシュをはみ出さない
範囲で外側に処理を移すことは当たり前の手法なので、普通のプログラマなら
みんなやっているし理解していると思いたい。

0693デフォルトの名無しさん

2006/04/14(金) 02:36:56

ここまでの流れを整理しましょう

まず、.NetのMatrix.Rotateは尋常じゃなく早いDirectXを使わずにここまでできるのか？
これが質問です。

回答者Ａ：お前のソースが遅いだけだろ、俺様のスマートな方法でやれ
これに対して私は、回転を高速化しても描画も含む速度において.Netのスピードは達成できませんでした
と解答しました

回答者Ｂ：いやＡの方法よりこっちのほうがはやいぜーー
これに対して私は目下閉口中ｗ

回答者Ｃ：いや別のボトルネックがあるだけだろ
これに対して私は最初からそういってるので目下閉口中ｗ

そろそろまともな会話しませんか？ｗ

0694デフォルトの名無しさん

2006/04/14(金) 03:52:13

スレ違い、と思う。

0695デフォルトの名無しさん

2006/04/14(金) 04:22:20

都合が悪くなるとすぐそれだ

0696673

2006/04/14(金) 04:22:49

> 回転を高速化しても描画も含む速度において.Netのスピードは達成できませんでしたと解答しました

ポインタにしても遅かったって言ってるだけだろ。
自主的には一度もループの話をしていないが、
ポインタを使っても遅いというのに描画のタイムが入っているというのは主観だ。

それにボトルネックが他にあると最初から言っているんだろ(どこで)
タイム取って分かったボトルネックを議題にするだけじゃないか。

固定値α付きで実際にやってみたが、
予想通り分岐入れっぱなし、添え字の計算しっぱなし、浮動小数点使いまくりの
糞コード書いてもPaint.NETと同等以上。

出来ないなら素直にMatrix.Rotateつかっとけ。

釣りというより池沼としか思えん。

0697デフォルトの名無しさん

2006/04/14(金) 04:27:59

基地外は放置しろって。

0698デフォルトの名無しさん

2006/04/14(金) 04:40:13

ーーーーRotateはここで終わりーーーー

0699デフォルトの名無しさん

2006/04/14(金) 06:11:36

終わった話題でしかも長文書くのでｽﾏｿ

>>623
> .NetのDrawing2D.Matrixというクラスがあって名前のとおりただのベタな２次元配列なわけだけど
> こいつのRotateメソッドがむちゃくちゃ早い
> この速さを.Net使わずに実現したいんだが中身がなにやってるのか調べ方がわからない
> 誰かその辺詳しい人いませんかね
> DirectXにそんなベタデータを汎用的な環境でアクセラレートする機能はなかったと思うんだけど
> MMXであそこまで早くなるもん？
> どれくらい早いかはPaint.Netっていうフリーのソース付のペイントソフトがあるので回転ツールで
> けっこう大き目の画像をぐるぐる回してみればわかる

MSDN見てみたけど.NETのSystem.Drawing.Drawing2D.Matrix型は単に3x3行列だよ。
それのRotateメソッドで回転行列作る負荷と、画像処理で数MBの配列舐めるのでは
負荷が全然違う。GDI+で画像を回転させて描画するには、Graphics.RotateTransform メソッド
で変換行列に回転適用してから描画するのが普通のやり方っぽい。

GDI+やPaint.NETはそこそこよく出来てるけど、機能満載しまくったライブラリやソフトの場合は
処理速度や一部分の出来を極めるのが主眼では無いので、（細部に凝ると全体が疎かになる）
あんまり期待しない方が良い。

ところで、AGGっていうC++のライブラリがあって（処理速度は普通）、それはGDI+との速度比較を
行っていて軒並みGDI+より上回っているんだけど、C++のテンプレートベースだから使いにくいんだよね。
GDI+にインターフェースを合わせたAGGのラッパーライブラリ（AGGPlus）もあるけど、画像の読み書きに
独自の？lib使ってて（ソース無し）好きじゃない。FreeImageとか使ってくれれば良いのに。。

0700699

2006/04/14(金) 06:30:00

画像の回転処理だと、
http://anton.treskunov.net/Software/doc/fast_and_high_quality_true_color_bitmap_rotation_function.html
のが速そうだけど実際にベンチは取ってない。shear処理を繰り返す方法が何故通常の方法より速度が出るのかは
良く分かってないでつ。

0701デフォルトの名無しさん

2006/04/14(金) 07:22:10

shear処理って何？

0702デフォルトの名無しさん

2006/04/14(金) 07:39:52

─┌───────┐─
││ 　　　／＼　　 ││ 外側のループを３つにわける
││ 　xL／----＼xR│↓
↓│ 　／　　　　＼│RY　1番目　RYまで
LY│／　　　　　／│　　　2番目　ＲＹ～LYまで
　 │＼　　　　／　│　　　３番目　ＬＹ～縦幅
　 │　＼　　／　　 │
　 │ 　　＼／　　　│
　 └───────┘
　　→内側のループのスキャン方向　

　　0～xLまでは余白
　　xL～xRまでは回転処理
　　xR～横幅まで余白

0703デフォルトの名無しさん

2006/04/14(金) 08:10:28

＞これに対して私は、回転を高速化しても描画も含む速度において.Netのスピードは達成できませんでした

RDTSC（面倒ならQueryPerformanceCounter）で
１　回転処理　bitmap作成を含む全部の処理
２　描画時間　windowsAPIの実行時間

を調べて比率を見てごらんよ。

今簡単に書いてみたけど　ほぼ同じ程度のコストだよ

0704699

2006/04/14(金) 08:52:03

shear処理っていうのは剪断変形（せんだんへんけい）の事。
shearの英語の意味は、剪み（はさみ）を入れる、というような事らしい。
http://ja.wikipedia.org/wiki/%E5%89%AA%E6%96%AD
http://hp.vector.co.jp/authors/VA020045/virtualight/vlight_3_12.html

shear処理だと行または列、独立して処理出来るのでsampling処理の重複が減って
速いのかもしれない。（列処理はメモリアクセスが行飛びになるので遅いだろうけど）

回転matrixをshear3回に変形する事については、
http://web.archive.org/web/20040627185405/http://splorg.org/people/tobin/projects/israel/projects/paeth/rotation_by_shearing.html
http://www.faqs.org/faqs/graphics/algorithms-faq/
Subject 3.01: How do I rotate a bitmap?
とかで解説されてる。AAで解説してたのもどっかにあったけど忘れますた。

0705デフォルトの名無しさん

2006/04/14(金) 08:59:07

>>701
graphics gems１巻

けど、shearing３回で回転する方式って本当に速い？
解説読んだけど、結構計算量も多そうで、いまいち試す気が起こらない

0706699

2006/04/14(金) 09:07:42

Paint.netで、画像範囲選択してツールの右矢印選んで、右ドラッグで回転させてみたけど、
リアルタイムの処理はサンプリング点が１つだけの処理っぽい汚さだから別にこれくらいの
速度は普通に出せるね。（まぁさんざん既出ですが…）

>> 705
週末にベンチ取ってみる。

0707699

2006/04/14(金) 09:39:21

623は多分Matrix.Rotateの速度を計って勘違いしてるんだと思う。Paint.Netは
画像処理にはGDI+使ってるにすぎない、OOPでうまく纏めて作ったソフトでしか
ないのに、思い込んでしまってる623には周りの指摘が通じない。

0708デフォルトの名無しさん

2006/04/14(金) 11:06:55

>>706
PentiumM 系列のCPUは、コード実行中のメモリアクセスパターンについて
なんと12個ものシーケンスを検出して「この先この辺読むかな」と予測して
自動的にプリフェッチしてくれる。

大きなメモリを扱う画像処理などではプリフェッチの効果は絶大なので、
昔のベクトル演算の様にこういうコードの質を判断するのは結構難しい。

0709デフォルトの名無しさん

2006/04/14(金) 11:09:38

>>704-705 ありがとう。
斜めに変形を繰り返せば結果として回転するって事か
でもデータの移動がそれだけ増えるんだから、今の
メモリアクセス＜ＣＰＵ速度なパソコンでは速いとは思えないな

0710デフォルトの名無しさん

2006/04/14(金) 11:13:03

回転元の画像がキャッシュに収まるならプリフェッチ云々は意味がないし
キャッシュに入らないような大きな画像を扱う場合は、
プリフェッチが入る時間が取れないから無意味だろうし

0711デフォルトの名無しさん

2006/04/14(金) 11:26:53

if( x1 >= 0 && x1 < SrcWidth && y1 >= 0 && y1 < SrcHeight ) {
dst[x2 + y2*DstWidth]=src[x1+y1*SrcWidth];
}else{
dst[x2 + y2*DstWidth]]=0;
}
↑の条件文をコメントアウトしif (true)みたくしてどれくらい速度が変わるか、
またはif文自体をコメントアウトして速度が変わるのか測定すれば
すぐに分かることなんだが？>>660

0712デフォルトの名無しさん

2006/04/14(金) 11:34:25

ここまでの流れを整理しましょう

まず、.NetのMatrix.Rotateは尋常じゃなく早いDirectXを使わずにここまでできるのか？
これが質問です。

回答者Ａ：お前のソースが遅いだけだろ、俺様のスマートな方法でやれ
質問者：試した試したと言いながら、まったく理解せず

回答者Ｂ：そもそも速いと言ってる Paint.NETの回転はちっとも速くないぞ。オレのコードが早い。
質問者：全く理解せず。　こんな速いアルゴリズムを知らないという。

回答者一同：アングリ。　知らないっていうからこんだけ教えてやってるのに、何言ってやがんだ

質問者：別のボトルネックがあるんではないか？
回答者：だから、回転の負荷なんて、単なるメモリコピーとそう変らんから、妄想は止めろ

そもそも　.NetのDrawing2D.Matrixというクラスはベタな２次元配列ではないぞ

そろそろまともな会話しませんか？ｗ

0713デフォルトの名無しさん

2006/04/14(金) 11:48:17

>>711
そんなことしたら、src>dstなんだから、メモリアクセスエラー出るだけだろ

まあ、この程度の負荷ならせいぜい違っても倍
ループ中にAPIコールでも入れてなければ大騒ぎするほど大差はないだろ

0714デフォルトの名無しさん

2006/04/14(金) 11:57:50

OPENGLが頭を過ぎりました

0715デフォルトの名無しさん

2006/04/14(金) 15:48:16

Glideが頭を掠めました

0716デフォルトの名無しさん

2006/04/14(金) 16:06:55

滑空だけにか

0717デフォルトの名無しさん

2006/04/14(金) 18:07:19

しかしPaint.NETは良く出来てるなあ
荒い表示とアンチエイリアス後がピタリと一致しやがる

アンチエイリアスもなかなかの性能だ。
このアンチエイリアスのアルゴリズムの方が知りたいなあ

0718デフォルトの名無しさん

2006/04/14(金) 18:10:47

作者乙

0719673

2006/04/14(金) 18:24:40

ﾌﾟｯ

0720デフォルトの名無しさん

2006/04/14(金) 19:23:01

>712
まず、.NetのMatrix.Rotateは尋常じゃなく早いDirectXを使わずにここまでできるのか？
これが質問です。

回答：できます。

――　完　――

0721デフォルトの名無しさん

2006/04/14(金) 19:39:53

>>711
if文を入れた場合と単純コピーを比較しても速度はほとんど変わらない

0722デフォルトの名無しさん

2006/04/14(金) 19:54:01

単純に考えすぎでは？Paint.Netで行われるトータルコストを考えると
まず背景はタイル画像がある
その上に切り抜かれた背景がある
切り取った回転画像がある
合計３枚の画像になるわけだ
これらを合成し３枚目は回転した状態で合成する
そして描画時に一定の拡大率で画像を拡大縮小して描画する

0723デフォルトの名無しさん

2006/04/14(金) 20:28:11

中間層を回転するならな。

0724デフォルトの名無しさん

2006/04/14(金) 20:44:02

下のタイルは >>702のように場合別けしてれば負荷にはならない
上にかぶせれば、透過処理は回転より負荷が大きいから実際に重くなるだろ

0725デフォルトの名無しさん

2006/04/14(金) 21:08:29

>>721

うん単純メモリーコピーはソースがキャッシュに入ってるなら
20～30サイクル/1ワード程度だと思う
この間に全部の処理が入ってほかにRAMをアクセスしないなら全部隠れてしまう。
もっとも予測分岐が一つ外れると、20サイクルくらいのペナルティは支払う事になるから
分岐は無い方がいいね

でもまあ >>711のように多数の変数がループ内にあるとメモリアクセスが余分に生じて
この速度は出ないと思うけどね

0726デフォルトの名無しさん

2006/04/14(金) 21:41:34

とりあえず、遅いとか速いとかじゃ判らないよ。
RDTSC使って、1ピクセルあたりどれくらいのクロックなのか書いてくれ

BCB
__int64 RDTSC(void){
__asm DW 0x310F
}

MSC
__int64 RDTSC(void){
__asm RDTSC;
}

Delphi

function RDTSC: int64;
asm
DW $310F
end;

帰り値が無いという警告は無視

0727デフォルトの名無しさん

2006/04/14(金) 22:49:00

アセンブラで一番内側のループを書いてみた。
procedure RotLoop1( dstp,srcp:PInteger;ofsX,ofsY,cnt:integer;ts,tc:DWORD);pascal;
label Lp,ed;
asm
　 mov ESI,srcp;
　 mov EDI,dstp;
　 mov ecx,cnt;
　 test ecx,ecx
　 jz ed
　 mov ebx,0
　 mov edx,0
Lp:
　 mov EAX,[ESI]
　 mov [EDI],EAX;
　 add EDI,4
　 xor eax,eax
　 add ebx,[tc];
　 cmovC eax,[ofsX];
　 add ESI,eax
　 xor eax,eax
　 add edx,[ts];
　 cmovC eax,[ofsY]
　 add ESI,eax
　 dec ECX
　 JNZ lp
ed:
end;

0728デフォルトの名無しさん

2006/04/14(金) 22:55:07

呼び出し方は
　 for x:=trunc(xL) to trunc(xR)-1 do begin
　　 dp^ := src[sy SHR 16][sx SHR 16];
　　 inc(dp);
　　 sx :=sx+tc;
　　 sy :=sy-ts;
　 end;
の部分を
RotLoop1(dp ,@(src.data[ round(sy0)]),4,-4*src.width,trunc(xR)-trunc(xL),ts,tc);
　inc(dp,trunc(xR)-trunc(xL));
と置き換える

古いＰＣでも動くように cmovC は以下の３行に置き換えてもいい
　 setC al
　 neg eax
　 and eax,[ofsY]

長くなるが、実行サイクルはcmovcをsetcに置き換えても変らなかった

アセンブラを使わない前は34～38cyc/ピクセル
使うと 29～33ｃｙｃ/ピクセル

1割程度の改善にしかならなかった

0729デフォルトの名無しさん

2006/04/15(土) 14:35:57

HSVについてなんですが、H:0.0%, S:100%, V:99%だと、ほとんど青の原色になりますよね。
しかしペインターのHSVだと、同じ物がほぼ白色になるみたいです。
ペインターのHSVは少し特殊なんでしょうか。もしそうでしたら、計算式のヒントなど頂けないでしょうか。

0730デフォルトの名無しさん

2006/04/15(土) 15:31:53

>>729
おまいさんは、何か勘違いをしている

ttp://tomato.sakura.ne.jp/~hiropon/lecture/color.html

0731729

2006/04/15(土) 17:05:03

失礼、青と書きましたが、これは赤の間違いです

>>730
申し訳ない、何度も読んでも分かりません・・・・
その図を見てもやはり、S:100%, V:99%なら最も鮮やかで明るい色にこそなれ、
ペインターの様に白にはならないですよね

0732デフォルトの名無しさん

2006/04/15(土) 17:15:24

PainterはHSVって表示しているが、実はそれは一般的に言うHLSで、
しかもH=0がBlueでB-R-Gの順に回転するのだ。

PhotoshopだとHSBと表示しているが、これも中身はHLSだ。

0733デフォルトの名無しさん

2006/04/15(土) 17:27:42

>>732
なるほど！いやはやHSVの所ばかり見てました、すいません。
回答ありがとうございました。

0734デフォルトの名無しさん

2006/04/18(火) 22:44:38

低レベル且つ微妙にスレ違いな質問。

Cでbitmapを読み込む定石ってないの？
標準ライブラリ+APIで。
(画像処理しようにも出来ないよ～。)

0735デフォルトの名無しさん

2006/04/18(火) 23:21:16

Win32APIならLoadImage()にLR_CREATEDIBSECTIONつけて返ってきたハンドルにGetObjectしてポインタ拾う

0736デフォルトの名無しさん

2006/04/18(火) 23:33:19

>>673
どうもありがとうございます。
なんとかヤれそうです。

0737デフォルトの名無しさん

2006/04/18(火) 23:35:14

>>734
>>735の方法で読みこみはできるが、bitmap(WindowsDIBだと思うが)の読み込みコードもかけないのならば
その後もできないと思う
8、24bitのみ、OS2フォーマット除外ならベタで書いてもたいしたことない
TIFFに比べれば自由度がない分簡単

0738736

2006/04/18(火) 23:36:04

訂正
○734
×637

0739736

2006/04/18(火) 23:42:16

またしくじった…。

訂正
○735
×673

携帯で書いたのでｽﾏｿ。

0740736

2006/04/18(火) 23:44:56

>>737さんもありがとうございます。

0741デフォルトの名無しさん

2006/04/19(水) 08:15:00

ペンタブレットの筆圧ってどうやったらとれます？
Windowsで

0742デフォルトの名無しさん

2006/04/19(水) 08:17:34

>>741
スレ違いだ。
ぐぐれ、wintab

0743デフォルトの名無しさん

2006/04/20(木) 20:21:26

>>737
へーきへーき。DIBの読み込みなんか自力で書けなくても
画像処理は書けるよ。他人の作ったフォーマットにあわせて
コード書くのはなんかまた違うんだよね、プログラムのカテ
ゴリとして。

0744デフォルトの名無しさん

2006/04/20(木) 22:08:41

Delphiプログラマの漏れなんか、
DIBなんか全然知らないが画像処理は書けるしな。

0745デフォルトの名無しさん

2006/04/20(木) 23:42:27

ふーん

0746デフォルトの名無しさん

2006/04/21(金) 00:16:05

へー

0747デフォルトの名無しさん

2006/04/21(金) 01:16:32

まいやはっはー

0748デフォルトの名無しさん

2006/04/21(金) 10:45:20

まいあふー

0749デフォルトの名無しさん

2006/04/21(金) 13:42:21

まいアホー

0750?1/4?3?μ?T???v?????O??48kHz

2006/04/21(金) 23:22:32

あのー
画像エフェクトって言えばいいのか、そういったもののアルゴリズムが
辞典的に乗っている書籍とかありますか？
あるなら、おしえてケロ。

0751デフォルトの名無しさん

2006/04/21(金) 23:26:03

ケロケロ。

0752デフォルトの名無しさん

2006/04/21(金) 23:35:29

ゲーロ　ゲロゲロ　ゲロ　ゲーロ！

0753デフォルトの名無しさん

2006/04/22(土) 09:28:40

どんぐりガエル

0754デフォルトの名無しさん

2006/04/22(土) 13:23:30

ttp://www.amazon.com/gp/product/0201180758 かな。
まだ ttp://www.amazon.com/gp/product/013168728X は出版されてないんだね。

0755デフォルトの名無しさん

2006/04/22(土) 16:22:06

どっかに画像をパステル調に変換するソースないですか？
こんなふうに

ttp://www.tomonori.com/program/sharaku/images/sketch/Pastel.jpg

0756デフォルトの名無しさん

2006/04/22(土) 17:41:01

それをパステル調と言い張っていいのなら、斜め方向にランダムに暈しているだけじゃないか?

0757かに博士

2006/04/22(土) 17:53:33

ケロケロ。

0758デフォルトの名無しさん

2006/04/22(土) 19:04:17

暈すというより延ばしてるね
単純減色してから角度にばらつきを持たせて延ばしてる感じ

0759デフォルトの名無しさん

2006/04/22(土) 19:31:03

>>755
ttp://www.tomonori.com/program/sharaku/sketch.html
＞パステルは全く違うアルゴリズムで、昔作って公開した印象派倶楽部と同じ原理です。
＞ぼかした上に、さらにノイズ乗せてますので画像としては思い切りつぶれていますが。

オリジナル画像もあるんだから、差分取れば何やっているのかほぼ分かるね。

0760デフォルトの名無しさん

2006/04/22(土) 19:33:49

馬鹿な意見ばっかりでかわいそうなので、天才の俺様が教えてあげよう
と思ったが
それＳＨＡＲＡＫＵのサンプルだろ
勝手にリンクしてんじゃねーよ、ついでに言えばパクろうとしてんじゃねーよ
それ同等のものは一般的にはないある共通の手法というものがあるが
教えたくなくなったｗ

0761デフォルトの名無しさん

2006/04/22(土) 20:09:37

>>760
日本語の勉強をし直すことをお勧めしておきます。

＞勝手にリンクしてんじゃねーよ
なんで? リンクされたくないならそう断るべきでは?
#だからと言って、リンクしてはいけないと言う法もないが。

＞教えたくなくなった
知らないならわざわざ嘘吐いてまで書く必要はないし、
本当に知っていて教えたくなくなったのならやはり書く必要はないよ。

つーか、本人乙。

0762デフォルトの名無しさん

2006/04/22(土) 22:31:40

逆切れ妄想かよｗ

0763デフォルトの名無しさん

2006/04/22(土) 22:37:02

だって意味わからんのですよ
なにか加工したいものがあるなら素直にＳＨＡＲＡＫＵ使えばいいじゃない
勉強としてそういう加工まずは十分に勉強してるもんだろうし
いきなりパステル調なんてＳＨＡＲＡＫＵオリジナルの名称持ち出して
これやりたんだけどってどうよｗ
自分のソフトに組み込みたいとか考えてるんなら教えないよ
勉強目的で聞いてるんならいきなりパステル調なんて言い出さない程度まで勉強してからおいで

0764デフォルトの名無しさん

2006/04/22(土) 23:10:24

あーおもしれーｗｗ

0765デフォルトの名無しさん

2006/04/23(日) 00:35:06

本当にいるんだな、こういう奴。

0766デフォルトの名無しさん

2006/04/23(日) 01:26:04

＞パステル調なんてＳＨＡＲＡＫＵオリジナルの名称

0767デフォルトの名無しさん

2006/04/23(日) 01:34:56

最近レベルが落ちてきたな。
俺は何の貢献もしてないからでかいこといえないけど･･･

0768デフォルトの名無しさん

2006/04/23(日) 07:31:56

パステルパステルパステルパステルパステルパステルパステルパステル

0769デフォルトの名無しさん

2006/04/23(日) 07:57:17

>>767
前からこんなもんですが

0770?f?t?H???g?I`?1/4?3?μ?3?n

2006/04/23(日) 10:06:47

レベルあげてーーーーーーーーーーーーーーーーーーーーーーーーー

0771デフォルトの名無しさん

2006/04/23(日) 10:20:11

まずお前がレベル上げろ

0772デフォルトの名無しさん

2006/04/23(日) 10:22:32

俺「はぁぁーーーーー！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！１」
息子「ぴゅぴゅぴゅっ！」

0773デフォルトの名無しさん

2006/04/23(日) 10:24:24

少し前の回転の高速化みたいな、低レベル談義の方が俺は好きだけどね。
レベル上げられても、専門化するばかりで興味ない分野には入れないし

0774デフォルトの名無しさん

2006/04/23(日) 10:27:37

プログラム板で高レベルな話ってのは、職業話をするって意味だからな

0775デフォルトの名無しさん

2006/04/23(日) 10:37:15

>>774
ム板は別にブルーカラーな話題だけじゃないよ。
コンピュータサイエンスの話題もぜんぜんOK。
アルゴリズムの理論的な話題もぜんぜんOK。

0776デフォルトの名無しさん

2006/04/23(日) 10:47:31

つまり実装から乖離する＝高レベルな話題になると、当然専門性が上がって参加者が減り、
それでも参加者が残るのが、職業話という事さ。

0777デフォルトの名無しさん

2006/04/23(日) 11:17:37

しょうがないので天才の俺様がネタ振りしてやる
http://www.art-science.org/journal/v1n3/artsci-v1n3p147a.pdf

0778デフォルトの名無しさん

2006/04/23(日) 11:48:49

で、回転ネタは、どう収束したんだ？

0779デフォルトの名無しさん

2006/04/23(日) 13:28:47

すいませーん。
Windowsでプログラムの勉強もかねてデジカメの画像をいじって遊んで
みたい、と思っているんですが、デジカメの中の画像をいじって遊ぶ
にはどうしたらよいんでしょうか？

とりあえず、jpgをBMPにしろ、話はそれからだ、とかどこかで読んだの
でBMPファイルにしたんですが、この先のお話聞かせてくださーい。

画像をいじれるようになったら、この間妹と温泉で撮った写真をいろい
ろいじって遊んでみようと思います。

0780デフォルトの名無しさん

2006/04/23(日) 13:33:13

>>779
まず、ぐぐる。
次に、ぐぐる。
ひたすら、ぐぐる。
最後に、ぐぐる。

これで出来る、

0781デフォルトの名無しさん

2006/04/23(日) 13:42:17

>>779
まずうｐしる。話はそれからだ。

0782デフォルトの名無しさん

2006/04/23(日) 14:18:43

>>781
そうだなｗ

>>779
ちなみに画像ソフトの話はスレ違い

0783デフォルトの名無しさん

2006/04/23(日) 18:24:32

>>782
自分で妹の写真をエフェクトしたいんだろ
俺は応援してるよ

0784デフォルトの名無しさん

2006/04/23(日) 18:51:28

pictbearあたりがいいんじゃまいか？

0785デフォルトの名無しさん

2006/04/23(日) 20:24:11

スレ的にはまずlibexifのインストールからかなあ。

0786デフォルトの名無しさん

2006/04/24(月) 07:58:00

>>777
こんなへぼいんじゃなくて
もっとちゃんとしたのを生成できる論文あるよ

たとえばこんなん
http://www.cs.rutgers.edu/~decarlo/readings/winkenbach-sg96.pdf

女性の研究者でカラー画像のやっている人がいたんだけど
名前忘れた

0787デフォルトの名無しさん

2006/04/24(月) 08:05:39

読めねーよ

0788デフォルトの名無しさん

2006/04/24(月) 08:15:43

おっかしいな
あれきれいだったんだけど

違うのしか見つけられない
http://citeseer.ist.psu.edu/444837.html
http://www.cs.mcgill.ca/~cs767/papers/winkenbach.pdf

siggraphだったかしらん？

0789デフォルトの名無しさん

2006/04/24(月) 13:43:04

エロ画像判定アルゴリズムってあります？

0790デフォルトの名無しさん

2006/04/24(月) 13:57:31

楽してエロ画像集めようなんてそうはいかないぜ！

0791デフォルトの名無しさん

2006/04/24(月) 14:15:21

>>790
違う、エロ画像を消すんだ！

0792& ◆h9Bn.Lr5Ro

2006/04/24(月) 15:33:09

エロ画像を定義でききるのか！
単に裸だけじゃないぞ、エロは。
チョコレートやホイップくり－ムで包まれていたりすんだぜ女の子が。

0793デフォルトの名無しさん

2006/04/24(月) 18:02:06

こんな感じか？
ttp://www.san-x.co.jp/newcha/new44.html

0794?1/4?3?μ?3?n???O`?W??

2006/04/24(月) 19:00:35

>> 793

ちがうやい。もっとべたべただよ。
ウエット＆メッシーで検索してくれくれ。
研究室に籠って画像処理に興じているとエロ＝裸となるのかな？

0795デフォルトの名無しさん

2006/04/24(月) 20:11:18

エロ話で盛り上がっている中、話に横槍を入れるのはあれですが、、、
質問が有ります。
fftによって画像処理をしたいのですが、縦横のピクセル値が２の冪であることが
望ましいと様々なところで語られていますが、画像はいつもそんなサイズでは有りません。
720x480のサイズの画像をfftによって処理する方法って有りますか？
あるなら方法だとか、そういった手法を教えて下さい。
書籍、サイトなど参照出来るものを教えてくれるとありがたいのですが。

0796デフォルトの名無しさん

2006/04/24(月) 20:15:01

http://www.google.co.jp/

0797デフォルトの名無しさん

2006/04/24(月) 20:39:02

>>795
窓関数

0798デフォルトの名無しさん

2006/04/24(月) 20:47:31

>>795
　サイズが２のベキでもピッタリのサイズでＦＦＴすれば右端と左端が接続されてるとして処理されてしまうわけで
　これが好ましいわけ？

　そうじゃないなら、単に空白を埋めたらいいだけでしょ？

　なお、２のべき乗でなくても、ＦＦＴは可能。　題名忘れたけど黄色い薄い本に詳細が書いてあるよ。

0799デフォルトの名無しさん

2006/04/24(月) 21:28:33

>>795
ヒント： FFTをやめてDFTを使う

0800デフォルトの名無しさん

2006/04/24(月) 21:31:12

>>795
http://www.fftw.org/
ここのライブラリを参考にしてみるんだ

0801デフォルトの名無しさん

2006/04/24(月) 21:34:01

>>795の言うように1024*512のとかで窓関数使うか、>>798のように基数2以外のFFTを使う方法しかしらんな～

0802デフォルトの名無しさん

2006/04/24(月) 22:02:36

２のべき乗以外のＦＦＴは　混合基数 FFT 　Winograd　を検索キーワードにすれば出るだろう

0803デフォルトの名無しさん

2006/04/25(火) 07:29:29

cztなんてのもあるらしいよー
それを使うと窓サイズが素数でも2のべき乗オーダーでFFT
できるらしい

0804デフォルトの名無しさん

2006/04/25(火) 07:31:46

あう、間違えた
×2のべき乗オーダー
○2のべき乗のFFTと同じオーダー

ついでに、cztは Chirp-Z 変換の略です

0805デフォルトの名無しさん

2006/04/25(火) 19:40:50

http://www.smartread.biz/

スマートリーディング業務終了のお知らせ

m9(^Д^)ﾌﾟｷﾞｬｰ

0806デフォルトの名無しさん

2006/04/25(火) 19:49:27

世知辛い世の中ですな

0807デフォルトの名無しさん

2006/04/25(火) 20:10:57

天罰だろ

0808デフォルトの名無しさん

2006/04/25(火) 21:00:10

うわぁ・・・

0809デフォルトの名無しさん

2006/04/25(火) 21:27:41

アメリカではこういうことやってまさにこんな風に失敗したほうが経営者としては信用されるらしいね
同じ失敗をしないから
しかしここは日本

0810デフォルトの名無しさん

2006/04/25(火) 21:57:20

スマートリーディングは経営なんて言えるもんじゃなかったよ
持ち逃げして作っただけ
最低

0811デフォルトの名無しさん

2006/04/25(火) 21:59:12

>>803
それ何の略？

0812デフォルトの名無しさん

2006/04/25(火) 22:01:40

orzってのもあるな。

0813デフォルトの名無しさん

2006/04/25(火) 22:06:44

Professional Edition 買ったやつは、サポートも無くおっぽり出されて買い損？

>>810
ｋｗｓｋ

0814デフォルトの名無しさん

2006/04/25(火) 23:49:26

>>813
>>524

0815デフォルトの名無しさん

2006/04/26(水) 00:49:25

>>524は、予言者

というか、預言者か。

0816デフォルトの名無しさん

2006/04/26(水) 03:33:42

ただのinsider

0817デフォルトの名無しさん

2006/04/26(水) 09:03:50

もともとOCRの会社に勤めてた奴が独立したとかそんなんかね

0818デフォルトの名無しさん

2006/04/26(水) 11:36:34

ソースお持ち帰りで独立か

0819デフォルトの名無しさん

2006/04/26(水) 12:16:11

画像認識アルゴリズムを議論するスレはこちらでよろしかったですか？

0820デフォルトの名無しさん

2006/04/26(水) 12:31:03

ttp://www.vector.co.jp/soft/winnt/writing/se383682.html
記念ダウンロード

0821デフォルトの名無しさん

2006/04/26(水) 13:20:12

>>820
GJ!

0822デフォルトの名無しさん

2006/04/26(水) 15:31:44

3色パンみたいに3つの円がくっついた絵について、3つの円の重心を決める
（絵は2値として）
てのやりたいと思ったら、まずどうしたらいいでしょう？　
ﾋﾝﾄか参考資料教えていただけると嬉しいです。
画像処理はズブの素人です・・・・・

0823デフォルトの名無しさん

2006/04/26(水) 15:42:28

円の中心点３つの中心じゃないのか？

0824デフォルトの名無しさん

2006/04/26(水) 15:43:07

チョコレート、クリーム、あんこ
では、あんこ、が一番重いと思うな、僕は。
なので、あんこ側に有りますよ。
重心は。

0825デフォルトの名無しさん

2006/04/26(水) 16:16:16

すみません、やりたいのは「それぞれの重心を決める」です。
重なり具合は画像によっていろいろです。
2つとか4つのもあります。

あんこは単価が高いので、少ししか入ってないんじゃないでしょうか。

0826デフォルトの名無しさん

2006/04/26(水) 18:59:57

ようするに面か線かで複数の円があるんだよね？

面なら輪郭をとって、線にして、

交点が無い部分で最小２乗で中心と半径求めては
その円を消去してゆくという感じでどう？

0827デフォルトの名無しさん

2006/04/26(水) 19:03:17

二値なら黒の重心を求めるとすると、黒点の総数を数えておいて、ｘ方向で半分なるところ
とy方向で半分になるところが重心。この方法なら、図形の形に依存しない。

0828デフォルトの名無しさん

2006/04/26(水) 19:12:25

領域分割でポスト配置問題と言うのがある

0829デフォルトの名無しさん

2006/04/26(水) 20:40:39

重なって輪郭途切れてるなら一般化ハフ変換がピッタリじゃない？

0830デフォルトの名無しさん

2006/04/26(水) 22:16:56

ﾊﾌｯﾊﾌとか言うｺﾋﾟﾍﾟを思い出すなぁ

0831デフォルトの名無しさん

2006/04/27(木) 00:23:08

ﾊﾌｯﾊﾌ

0832デフォルトの名無しさん

2006/04/27(木) 00:45:40

そう考えるとﾊﾌﾏﾝって
うわっエロっ

0833デフォルトの名無しさん

2006/04/27(木) 00:47:36

Hough変換はハフ変換だったのか。
いままでずっとホウ変換って読んでたYO！

0834デフォルトの名無しさん

2006/04/27(木) 01:36:08

タフマン？

0835デフォルトの名無しさん

2006/04/27(木) 07:56:49

逆にするともっとｴﾛｲかも
ﾏﾝﾊﾌ・・・

0836825

2006/04/27(木) 11:26:10

皆どうもありがとうです。ぐだぐだやってみます。
一般化ハフ変換について詳しい本かサイトあったら教えてくださいまし。

ﾊﾌﾊﾌ

0837826

2006/04/27(木) 11:35:52

オレの提案はどうなんだよ
検索キーワード最小２乗法による円弧推定

0838デフォルトの名無しさん

2006/04/27(木) 11:45:29

エロさが足りない

0839825

2006/04/27(木) 12:02:19

>>837　　ありがとうございます。もちろん挑戦するです。
「最小2乗で円」は「おお」っていうサイトありましたが、
「一般化ハフ変換」は、なんかようわからんかったのです。

0840デフォルトの名無しさん

2006/04/27(木) 19:44:27

ハフ変換は研究者のオナニーで役に立たないよ。
実用的な応用例を見たことがない。

0841デフォルトの名無しさん

2006/04/27(木) 20:08:54

正弦波を直線近似して高速化するやつと、GPUPUでやる奴を見てみたけど、
やっぱり遅いしね。っていうか前者、こんなので特許取っててうんざり。

0842デフォルトの名無しさん

2006/04/27(木) 21:27:41

4kデモでnoonのカールが12?バイトsinコードを書いてたよね

0843デフォルトの名無しさん

2006/04/30(日) 19:54:48

今は遅くて役に立たなくても、
将来ハードの性能が上がればウハウハよ。

0844デフォルトの名無しさん

2006/05/01(月) 21:32:45

JPEG圧縮でファイルサイズがMAXになる画像って一意に決まりますか？
決まるなら、まず画像を自作したいのですが・・・
圧縮方法次第なら、適当に大きくなりそうなサンプル写真拾います。

0845デフォルトの名無しさん

2006/05/01(月) 21:38:17

日本語でおｋ

0846デフォルトの名無しさん

2006/05/03(水) 12:23:51

>844
PIをJPEG圧縮するのはどうか？

0847デフォルトの名無しさん

2006/05/04(木) 10:27:41

ホワイトノイズでいいんじゃね？

0848デフォルトの名無しさん

2006/05/05(金) 23:02:04

>>844
１ドットごとの白黒のチェック模様って試したらどうかな？

ぱっと見スゲー苦手そうじゃね

0849デフォルトの名無しさん

2006/05/05(金) 23:58:43

ＪＰＥＧの画質に依存するのでは。
ジグザグスキャンで圧縮効率が悪くなりそうな配列だといいだろうな。
16x16ブロックで最大になるものを敷き詰めればよさそうだ。

0850デフォルトの名無しさん

2006/05/06(土) 00:08:07

jpegは広い周波数帯域を持つ画像に弱い
だから市松模様なんて簡単すぎる

ホワイトノイズだってば！

0851デフォルトの名無しさん

2006/05/06(土) 01:02:59

市松模様は（ベタ塗りの他では）最も圧縮される画像の一種かもね。

0852デフォルトの名無しさん

2006/05/06(土) 01:54:39

>>850
それも色相・彩度・明度の各チャンネルで独立したホワイトノイズだな。

0853デフォルトの名無しさん

2006/05/06(土) 03:50:46

量子化後の周波数領域において一様分布にしたがって値をとれば、
エントロピー最大⇒圧縮率最悪

どういう画像になるかは知らんが、
1. 乱数配列生成
2. 逆量子化
3. 逆DCT
とすれば求める画像が得られると思う

画像関係は専門じゃないので何かあれば補足よろ

0854デフォルトの名無しさん

2006/05/06(土) 13:18:34

JPEGの圧縮の貢献はジグザグスキャンの
8x8ブロック→64個のデータ列のハフマン符号化
で稼いでいるから、64個のデータ列で０が連続
しないような配列生成→2→3とすればいいと思う。

0855デフォルトの名無しさん

2006/05/06(土) 14:33:02

どんな圧縮でもエントロピーを超えられないから
zip最高圧縮で圧縮したデータを画像にすりゃいいんだよｗ
ホワイトノイズとも言うがｗ

0856デフォルトの名無しさん

2006/05/06(土) 14:37:56

実際には数理上のエントロピーは超えてるけどな
いったん圧縮されてエントロピーが確定したデータはそれ以上圧縮できない
このエントロピーをいかに下にもっていくかで圧縮性能が違ってくるだかなんだが
スレ違いですね

0857デフォルトの名無しさん

2006/05/06(土) 18:29:28

>856
いや、それ可逆の話なんじゃ・・・

0858デフォルトの名無しさん

2006/05/06(土) 21:58:55

圧縮できない最悪の状態を作るのは、単独・単純な手法だと良くやられてるんですが、
JPEGで同じようなテストデータを作るのは面白そう

0859844

2006/05/06(土) 22:19:53

おお、色々レスもらってた。
とりあえず、レスもらった奴を試してみます。

0860デフォルトの名無しさん

2006/05/07(日) 00:22:06

PNGのCRCをC/C++で計算するソースきぼんぬ

0861デフォルトの名無しさん

2006/05/07(日) 00:39:13

え、pngの仕様書の付録でコード書いてなかった？

0862デフォルトの名無しさん

2006/05/07(日) 00:41:44

マルチか

0863デフォルトの名無しさん

2006/05/07(日) 00:53:35

CRCって、PNGだと特別な計算方法になるのか？

0864デフォルトの名無しさん

2006/05/07(日) 01:11:20

>>844
みんなが言ってる様にホワイトノイズなんじゃないかな？一意には定まらないけど･･･。
MT法辺りの良質な乱数アルゴリズムで一様分布乱数作って正規乱数に変換すればいいよ。

0865デフォルトの名無しさん

2006/05/07(日) 01:20:02

ノイズをノイズとして認識してノイズとして合成できたらいいのにな
それは音声でも絶対役立つんだが

0866デフォルトの名無しさん

2006/05/07(日) 01:20:46

>>861
どこにあるの？

0867デフォルトの名無しさん

2006/05/07(日) 01:24:10

>>866 RFC

0868デフォルトの名無しさん

2006/05/07(日) 01:31:10

>>867
日本語訳のページが軒並み潰れててどうにもならない

0869デフォルトの名無しさん

2006/05/07(日) 01:38:29

ふーん。

0870デフォルトの名無しさん

2006/05/07(日) 03:07:44

>>865
MPEG4後継コーデックではすでにフィルムグレインの分離・合成は常識。

0871デフォルトの名無しさん

2006/05/07(日) 03:53:04

>>868
英語のページ見ればよい

0872デフォルトの名無しさん

2006/05/07(日) 18:48:24

unsigned long crc_table[256];
int crc_table_computed = 0;

void make_crc_table(void) {
unsigned long c;
int n, k;
for (n = 0; n < 256; n++) {c = (unsigned long) n;
for (k = 0; k < 8; k++) {if (c & 1){c = 0xedb88320L ^ (c >> 1);}else{c = c >> 1;}}
crc_table[n] = c;
}
crc_table_computed = 1;
}

unsigned long update_crc(unsigned long crc, unsigned char *buf,int len){
unsigned long c = crc;
int n;
if (!crc_table_computed)make_crc_table();
for (n = 0; n < len; n++) {c = crc_table[(c ^ buf[n]) & 0xff] ^ (c >> 8);}
return c;
　}

unsigned long crc(unsigned char *buf, int len)
{ return update_crc(0xffffffffL, buf, len) ^ 0xffffffffL; }

見つけたけど使い方がわからん。まずmake_crc_table()を呼べばいいのかな？

0873デフォルトの名無しさん

2006/05/07(日) 19:03:48

>>872
crc()

0874デフォルトの名無しさん

2006/05/07(日) 19:18:17

ナルホド。でも戻り値がunsigned longになってるけど？CRCは4バイトだよね？

0875デフォルトの名無しさん

2006/05/07(日) 19:27:42

最近のVCだとlongもintも4バイト

0876デフォルトの名無しさん

2006/05/07(日) 19:31:21

そーす

0877デフォルトの名無しさん

2006/05/07(日) 19:33:26

ぐぐるなりMSDN見るなりしやがれ

0878デフォルトの名無しさん

2006/05/08(月) 11:22:24

>>868
ttp://www.archive.org/web/web.php

この辺に残ってそう

0879デフォルトの名無しさん

2006/05/09(火) 18:24:36

いわゆる歪みエフェクト(swirl、meshwarpなど)
のアルゴリズムというものは、自らが考えているの
でしょうか？あるいはそういった文献があるのでしょうか、
上にかいたswirl、meshwarpはソースがあったので
それを見て理解はできたのですが、
そういった歪みエフェクトのアルゴリズムが網羅されている
文献、あるいはサイトなどがあれば教えていただけると
幸いなのですが、、、よろしくお願いします。

0880デフォルトの名無しさん

2006/05/10(水) 21:03:44

PhotoshopやGIMP等のﾚｲﾔ結合処理を教えてください。
なんだろう、簡単だと思っていたのに全然解決できない…。

例えばﾚｲﾔ※1 と背景※2 を結合する場合

　// 左から、A R G B
　※1 0.2 1.0 0.8 0.4
　※2 1.0 1.0 1.0 1.0

これの見た目は 1.0 1.0 0.9 0.7 になるはず。
背景は不透明度100%なので、単純なαﾌﾞﾚﾝﾄﾞでいける。
で、この間に1枚のﾚｲﾔ※3 を差し込んでみる。

　※1 0.2 1.0 0.8 0.4
　※3 0.4 1.0 1.0 1.0 < 不透明度80%の白いﾚｲﾔを挿入
　※2 1.0 1.0 1.0 1.0

これも最初の例と同じ結果になる。
単純に ※3と※2 をαﾌﾞﾚﾝﾄﾞし、さらに ※1と※2' をαﾌﾞﾚﾝﾄﾞすればいい。

で、問題は ※1と※3 の二つのﾚｲﾔを結合した時、
※3' の算出方法がわからんのです。
これの見た目も、上記のケースと同じ（もしくは同等）の結果になるはずなんだけど、
僕の頭では算出方法が導けません。

0881デフォルトの名無しさん

2006/05/10(水) 23:53:56

何も考えずに即レスするけど、
A3’ = 1 - (1-A1)*(1-A3)
R3' = 電車なくなるのであとで

0882デフォルトの名無しさん

2006/05/11(木) 00:05:27

この話題は３ヶ月ごとに現れるのはどうして？

0883デフォルトの名無しさん

2006/05/11(木) 01:13:02

自分を二人画像の中に違和感無く
いれるソフトってありますか？
合成処理のできるソフトならできるのでしょうか？
詳しい方よろしくおねがいします。

0884デフォルトの名無しさん

2006/05/11(木) 01:23:53

スレ違い

0885デフォルトの名無しさん

2006/05/11(木) 18:53:20

s/ソフト/アルゴリズム/g
これならすれ違いにならない(・∀・)
質問者の求める答えにもならないだろうけどw

0886デフォルトの名無しさん

2006/05/11(木) 19:28:08

>>883の要求レベルすごいな、、。

0887デフォルトの名無しさん

2006/05/11(木) 19:54:28

>>883
１　合成する
２　「僕たち双子です」と字幕を入れる

0888880

2006/05/11(木) 20:15:33

>>881
つ！続きおねがいします！！！

0889デフォルトの名無しさん

2006/05/11(木) 20:19:57

>>888
今ちょっと眠くて・・・

0890デフォルトの名無しさん

2006/05/11(木) 22:33:37

いや、だって、>>883　って、自分を画像の中に入れろって言うんだろ？
マトリックスみたいだな。

0891883

2006/05/11(木) 23:35:42

説明下手ですいません。
違和感無く1つの景色に同じ二人がいる、、
んですがこれはなんのソフトでやってるんすか？

カメラを固定させ
1つの景色を2つに分け
右左で方ずつ自分入りで撮り
合成ですか？
そういうソフトありましたよね。
マックでもそんなソフトありますか？
フォとショップエレメントでもできる？

0892デフォルトの名無しさん

2006/05/11(木) 23:35:50

しかも二人だ。増殖するのか?

0893デフォルトの名無しさん

2006/05/11(木) 23:39:31

>>883が双子じゃない時点で無理

0894デフォルトの名無しさん

2006/05/11(木) 23:40:22

>>891
スレ違いといわれているのが理解できないのかな?
寧ろ鼬害ではあるが。

0895デフォルトの名無しさん

2006/05/11(木) 23:47:06

>>883『頭の体操』を読むべし

0896デフォルトの名無しさん

2006/05/12(金) 02:18:51

>>883 >>891
頼むからマック板にでも行って聞いてくれ。
ここは君の質問とは関係ないとこだから。

0897883

2006/05/12(金) 02:34:21

あっなるほどね
プログラム板なのね。
検索してきたもんで。
でもこんなに不親切だとは思わなかったよパトラッシュ。

0898デフォルトの名無しさん

2006/05/12(金) 02:38:51

　　　,.-─-、
　　 /　/_wゝ-∠l
　　　ヾ___ノ,.　-　>
　　 /|／（ヽY__ノﾐ＜荒らしに親切にする義理は無い
　　.{　　　rｲ　　ノ

0899デフォルトの名無しさん

2006/05/12(金) 09:27:28

>>897
すげえな、自分の間違いを謝罪するわけでもなく逆切れｗ

0900ままサル

2006/05/12(金) 11:12:27

>>14
すみません。どこを見たらよいか教えていただけませんか。

0901デフォルトの名無しさん

2006/05/12(金) 20:07:15

合成するときに、単純に色だけを見比べたらまったく同じに見えるものでも
重ねるとくっきり境目がわかるのはなんでだろうね
ある種のパターンのようなものを脳が拾っているのだろうけど
そういうの研究してる人とかいるのだろうか

0902デフォルトの名無しさん

2006/05/12(金) 22:11:20

知覚心理学・生理学とかだろ

0903デフォルトの名無しさん

2006/05/12(金) 22:34:42

>>901
わかった、それはクオリアだ

0904デフォルトの名無しさん

2006/05/13(土) 00:29:49

>>901
自分で考えてそれが何故か見当も付かない（仮説も無い）のだとすると、
ちょっと説明のしようもない・・・

0905デフォルトの名無しさん

2006/05/13(土) 00:49:41

テレビのキャプチャーがぞうに見られる四角い網目状の模様がいい例なのですが
全体としてはちゃんと画像として認識できるし、模様にはっきりとした色差があるわけでもない
拡大して見ると模様は見えなくなるからね

0906デフォルトの名無しさん

2006/05/13(土) 01:23:33

四角い網目状ってブロックノイズのこと？
あれは数値的には明らかに不連続になってるが。

っていうか901がどの部分のことを言っているのか、
あれだけじゃわからんなぁ。
輪郭のことを言っているのか、ライティングのことを
言っているのか…

0907デフォルトの名無しさん

2006/05/13(土) 01:50:08

アナログTVのキャプチャで細かい網目模様が入るのは、
キャプチャ回路中の3次元Y/C分離の設計ミス。

0908デフォルトの名無しさん

2006/05/13(土) 04:24:17

>>901は音で言えば音程の変化は分かりやすいが
単音の音程は分かりにくい(これが分かるのが絶対音感)
ということじゃない？色で言えば絶対色覚・相対色覚。

0909デフォルトの名無しさん

2006/05/13(土) 10:32:42

あれでしょなんとかバンド効果。
本来の濃淡値変化が階段状に変化してても人間の目からは（アンシャープマスクをかけたかのように）強調されて変化してるように見えるってやつ

0910デフォルトの名無しさん

2006/05/13(土) 13:04:32

>>909
漏れもそれ（マッハバンド）のことかと思ったんだけど、よく読むとそうではなくて
「アイコラ作ってて、色を完璧に合わせたのに境目が視認できるのはなぜ」っていう疑問っぽい。

0911デフォルトの名無しさん

2006/05/13(土) 13:16:44

オイコラバンド効果っていうんだよ

0912デフォルトの名無しさん

2006/05/13(土) 13:17:41

そりゃ本来あるべき変化が平坦になってしまってるからって話じゃないか？

0913デフォルトの名無しさん

2006/05/13(土) 14:05:18

アイコラﾜﾛﾀ

0914デフォルトの名無しさん

2006/05/13(土) 21:18:13

>>880
俺も最初にやったとき、とまどった記憶がある。

※3の意味はA=0.4なので60%は後ろの色が透けて見え、40%は※3自身の色になるということ。
(不透明度80%というのはとりあえず置いておこう)
同様に※1は80%が後ろの色が透けて見え、20%は※1自身の色になる。
さて、※1と※3を合わせると何%後ろの色が透けて見え、何%が※3の色で、何%が※1の色でしょうか。

と考えていけば分かるはず。

0915デフォルトの名無しさん

2006/05/14(日) 03:08:30

GIMP-1.2.5(Linux)、100%塗りの統合でも、
最下層に不透明レイヤ(background)を置いてるときと
そうでないときで統合結果、ビミョ～に違う。

0916デフォルトの名無しさん

2006/05/14(日) 07:28:15

へぇへぇ

0917デフォルトの名無しさん

2006/05/14(日) 07:39:38

915>>スレ違い

0918デフォルトの名無しさん

2006/05/14(日) 10:34:34

>>915氏ね

0919デフォルトの名無しさん

2006/05/14(日) 14:47:30

>>915の人気に嫉妬

0920デフォルトの名無しさん

2006/05/17(水) 22:17:29

>>914　よく嫁
※3'のARGB値は結局どうなるのか、どう導けばｲｲのかを聞いてる様子。

俺も知りたい。

0921デフォルトの名無しさん

2006/05/17(水) 23:16:06

計算してると終電の時間になったり眠くなったりするのでMUPAD導入してみた。

結合したプレーンのα値を a4 = 1 - (1-a1)(1-a3) とすると、R要素 r4 は
r4 = (a1*r1 + a3*r3 - a1*a3*r3) / (a1+a3-a1*a3) ただし a1 != 1 and a3 != 1 のとき。

検算（テスト）はしてない。

0922デフォルトの名無しさん

2006/05/17(水) 23:17:29

>>920
スンマセン、こんなもんでいかがでしょう。

※1、※3、それ以降のレイヤーを統合すると、その内訳は次のようになる。

※1 ※3
-+- 0.2 ※1の色の割合(0.2) }
| }= 不透明
+- 0.8 -+- 0.4 ※3の色の割合(0.8*0.4=0.32) }
|
+- 0.6 以降の色の割合(0.8*0.6=0.48) = 透明

不透明度は>>881の通り。
A3' = 1-0.48 = 0.2+0.32 = 0.52

問題は色の方だけど、最終的にすべてのレイヤーを統合すると赤(R)なら

R(全レイヤー統合後) = 0.2*R1+0.32*R3+0.48*R(以降を統合した値)
= R3'*A3' + (1-A3')*R(以降を統合した値)

(0.2*R1+0.32*R3)の部分にはすでに不透明度A3'が乗じてある形になっている。
分離するならば

R3'=(0.2*R1+0.32*R3)/A3' (ただしA3'!=0)
=(A1*R1+(1-A1)*A3*R3)/A3'

G3'とB3'も同様。

0923デフォルトの名無しさん

2006/05/17(水) 23:17:53

どっちかのα値が1.0のときは、後ろが1.0ならそこを背景と見て前景を重ねればOK。
手前が1.0なら手前の色でOK。

0924デフォルトの名無しさん

2006/05/17(水) 23:18:40

>920
結局元記事は、何らかのレイヤー構造を持った画面があって、そのうちＡを持った２枚の
レイヤーを取り出して合成した時、合成する前と見た目を同じにするにはどうしたらいいか？
という事だと思うが、それはそのアプリケーションがどんなアルゴリズムで最終画面を
作り出しているのかによる。

そのアルゴリズムを無視できる、普遍的な解法もあるにはあるが、元の質問の意図からは、
少しはずれると思う。

0925デフォルトの名無しさん

2006/05/17(水) 23:21:59

>>922
かぶりました。
漏れの方は分母が (1-A3') になってるな・・・

0926922=914

2006/05/17(水) 23:26:08

うは、少し後れを取った。
微妙に違うのは……誰か確かめてくださいorz

0927デフォルトの名無しさん

2006/05/17(水) 23:32:04

922の方があってるっぽいな・・・

0928デフォルトの名無しさん

2006/05/18(木) 07:40:41

全部が半透明の時の最終的なα値がわからないということではないのか？

0929デフォルトの名無しさん

2006/05/19(金) 21:18:44

JPEG2000で質問なんですが
タイルをまたいでコードブロックを符号化する必要があるのか無いのか分かる人はいないでしょうか。

Image→tile分割→DWTにてsub band分割と進む中で、
なぜReference Grid上のタイルの座標がsub bandの計算にずっと
はいってきて、Princict上で、左上詰で座標を取らないのでしょうか。
または、入出力のメモリを同じにできるように座標を調整してもいないし・・・

全てのタイルの同じ分解レベルの画像をコンポーネント単位でもう一度全体を並べなおしてから、
コードブロック単位に連続して符号化する必要は無いと思うのですが。

0930デフォルトの名無しさん

2006/05/19(金) 21:25:27

９２９による改良を期待しよう

0931デフォルトの名無しさん

2006/05/20(土) 09:14:16

15444-1なら、ない。15444-2のタイル境界部分を重複させる拡張を使うなら、ある。
と思うぞ。

0932デフォルトの名無しさん

2006/05/20(土) 10:50:38

>>931
まだ、読んでいるのがPart１の途中なので、「ない」で良いみたいですね。
ありがとうございました。

0933デフォルトの名無しさん

2006/05/20(土) 18:47:00

ISO/IEC 15444-1:2002 JPEG 2000 Part 1では、
そもそも「すべてのタイル」に「同一の解像度レベル」が存在するとは限らない。
タイルごと（CODマーカー）、タイルコンポーネントごと（COCマーカー）で
デコンポジションレベルが変更できるから。

0934デフォルトの名無しさん

2006/05/23(火) 04:23:23

電子透かしを作っています．

現画像をFFTして，それに埋め込み画像の階調値に小さい値εを掛けたものを足してIFFTするところまではよいのですが，
このIFFTした値は複素数で，これを画像として書き出すと整数になってしまうため復号の際に周波数領域に直したときにかなりの誤差が出てしまいました．

どのようにすれば暗号化した画像を書き出すさいに実数も保存できるのでしょうか？というよりも一般的な電子透かしの手法としてどこか間違っているのでしょうか？

0935デフォルトの名無しさん

2006/05/23(火) 04:48:47

>>934
電子透かしの手法そのものが特許やなんやで飯の種になってる訳だから
「どうやったらいいんですか？」と、ここで聞かれてもなあ。

0936デフォルトの名無しさん

2006/05/23(火) 07:28:44

もしかして934レベルでも特許なの?

0937デフォルトの名無しさん

2006/05/23(火) 08:14:55

レベルって・・・

0938デフォルトの名無しさん

2006/05/23(火) 10:37:01

テレビ局では画面すみにロゴを半透明合成してる。

0939デフォルトの名無しさん

2006/05/23(火) 14:55:30

>>936
ホイ。
ttp://www.google.co.jp/search?hl=ja&q=%E9%80%8F%E3%81%8B%E3%81%97%E3%80%80%E7%89%B9%E8%A8%B1%E3%80%80%EF%BC%A6%EF%BC%A6%EF%BC%B4&lr=

0940デフォルトの名無しさん

2006/05/23(火) 21:54:46

うーん、ｽﾚ違いかもだけど、質問～！

Exif2.2の仕様書(pdf版)のありか、おせーて。
あるいは、だれかｸﾚｸﾚ。

ぐぐルと、その昔は英語版のみ無料でpdf配布してたらしいけど、
もうDLできないんだＹＯ。。。

例えば、以下のページとか。
http://www.cipa.jp/exifprint/contents_j/05format_j.html

ちなみに2.1は以下のページからDLでけますた。
http://it.jeita.or.jp/document/publica/standard/index.html

0941デフォルトの名無しさん

2006/05/23(火) 22:04:10

2.2は何が変わったの？

0942デフォルトの名無しさん

2006/05/23(火) 23:19:36

DIBの高さパラメータに負数を指定すると、ビット列の並びが画像そのまま(左上＞右下)になり
処理が分かりやすくなるため、今までそれでやってきました。

ところが今日知人に「負数指定は一般的ではない、良く覚えてないが転送が遅くなるかも」
みたいなことを言われました。早速ネットでソース(情報の)を探したのですが見つかりません。

いや、負数指定は一般的でないというソースだけはありました。
どうなんでしょう、画像データの並びを後ろから持つというのは、何かメリットがあるんでしょうか？

0943デフォルトの名無しさん

2006/05/23(火) 23:28:26

>>942
データ並びが左下原点になること自体はグラフとの親和性が高くて便利なときもあるが、
先頭から表示しようとするとしたから表示する羽目になるし、余りメリットは感じない。

0944942

2006/05/23(火) 23:59:43

>>943
ですよねー。いやお墨付き頂けて良かったです。何気に不安で。
転送(winだとbitblt系)が遅くなる、みたいのも、いくら検索しても出てきませんし、勘違いかな。

なんだってbmp形式は逆に取るようになったんでしょうねぇ。
グラフの例外的メリットも覚えておきます。レスありがとうございました。

0945デフォルトの名無しさん

2006/05/24(水) 01:10:44

みなさん質問があります。

細線化のことで今度発表があるんですけど、細線化の重要性を教えてもらえないでしょうか？

0946デフォルトの名無しさん

2006/05/24(水) 01:19:29

ボトムアップの方が効率が良いと聞いた事がある。

0947デフォルトの名無しさん

2006/05/24(水) 03:02:32

>942
以下BMPとDIBとDDBをごっちゃにしてBMPと記述しますが、話の概要には関係ない
ので（区別した方がわかりにくい）、故意にそうしてあります。

BMP は、AT互換機の歴史的な経緯からああいう（ボトムアップな）構造になっています。
ボトムアップでなければ遅いというのはその当時のハードウェアの話です。
そういう制限もない昨今、ボトムアップでは直感的に分かりにくいということで、トップダウン
な一般的構造をもったBMPが作られました。
しかし、それまでのBMPとの互換性も維持しなければならないので、高さに負の値を
入れることにしました。
古い時代には、この表記に対応していないアプリケーションやライブラリも多々
あったので、特に理由がない限り、負の値は避けられました。
で、今に至っています。
そもそも、自分のアプリケーション内部では、特に理由がない限り、トップダウンで
取り扱うでしょうから、読み書き時にコンバートするわけですし。

なお、BMPを出力しなければならないアプリケーションは、正の値を与えて
ボトムアップで出力するのが一般的です。

0948デフォルトの名無しさん

2006/05/24(水) 09:25:50

>>940
英語版でいいなら、ホレ
つ ttp://www.exif.org/specifications.html

0949デフォルトの名無しさん

2006/05/24(水) 17:44:33

>>883
パノラマ合成

0950デフォルトの名無しさん

2006/05/24(水) 19:24:21

>>947 元々MSとIBMが共同開発したOS/2のグラフィックサブシステムGPIの座標系が
IBM汎用機のグラフィックサブシステムの座標系を引き継いで左下原点だったからだよね。
で、OS/2向けに作ったBMPを元にWindowsBMPを作ったと思った。

0951943

2006/05/24(水) 20:11:55

面倒だから経過は端折ったけど、>950で>947。
まぁ、遅かったかどうかは知らないけど。

0952942

2006/05/25(木) 00:17:47

ははー、転送が遅くなるってのも満更嘘じゃ無かったのですね。過去の話とはいえ。
なるほど、当時のシステムに合わせて、ですか。
「高さに負の値」は、むしろ有り難く使って良い感じなんですね。export時にのみ注意と。

いやはや、中々聞ける話じゃありません。
これほどの詳細、ありがとうございました。感謝です。

0953デフォルトの名無しさん

2006/05/25(木) 02:14:59

Petzold 本に書いてあるよ

0954936

2006/05/25(木) 11:10:42

>>937
少々の編集に耐えるように作ろうとしたらFFTくらい使うでしょ。
2、3透かしの実装を考えてたのに、特許取られてるんだろうな。ウゼー。

0955デフォルトの名無しさん

2006/05/27(土) 03:49:59

画像処理でよく使われる lena.ppm とかってどこからもってくるの？
よく使われる画像データベースとかあるの？

0956デフォルトの名無しさん

2006/05/27(土) 03:57:59

>>955
"Lenna"でぐぐれ。

0957デフォルトの名無しさん

2006/05/27(土) 05:28:55

>>955
みんなエロ本からスキャンして使っているんだよ。

0958デフォルトの名無しさん

2006/05/27(土) 07:06:36

>>956
Lenna だけじゃなくてさ。

0959デフォルトの名無しさん

2006/05/27(土) 07:16:54

>>955
ここ。
http://sipi.usc.edu/database/
ちなみに Lenna でも Lena でもどちらでもいいし、
Lena のほうがメジャー。

0960デフォルトの名無しさん

2006/05/27(土) 07:34:07

>>958
Lennaで日本語サイト限定でぐぐっただけでも、すぐに見つかったが。
むしろ日本語限定でぐぐった方が見つかりやすいかもしれんｗ

The Lenna Storyへのリンク結構あるしね。
そこからUSC SIPI Image Databaseへのリンクがある。

0961デフォルトの名無しさん

2006/05/27(土) 11:07:29

そこまで言うならリンクはれｗｗｗｗｗ

0962デフォルトの名無しさん

2006/05/27(土) 13:58:01

ﾜﾗﾀ

0963デフォルトの名無しさん

2006/05/27(土) 14:10:34

>>961
>>959

0964デフォルトの名無しさん

2006/05/27(土) 14:48:42

>>960

0965デフォルトの名無しさん

2006/05/27(土) 23:21:19

zlib.dll を使って png画像を吐くプログラム作ったんだけど、どうも一部のヴューアで表示されない。
具体的に言うと、IrfanViewでは表示されるけど、Vix では表示されない。
データが間違っているんだろうけれど、どこが間違っているのかバイナリ眺めてもさっぱり分からない。
本家のページから pngcheck をダウンロードしてきたんだけど、

File: xxx.png (215 bytes)
chunk IHDR at offset 0x0000c, length 13
8 x 14 image, 24-bit RGB, non-interlaced
chunk IDAT at offset 0x00025, length 158
zlib: deflated, 32K window, superfast compression
zlib line filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth):
0 0 0 0 0 0 0 0 0 0 0 0 0 0 (14 out of 14)
chunk IEND at offset 0x000cf, length 0
No errors detected in xxx.png (36.0% compression).

エラーなしと表示されてしまいます。どこか間違っているはずなのに。。。
どなたか、もっと正確なチェッカーご存知ないですか？

0966デフォルトの名無しさん

2006/05/27(土) 23:31:48

>>965
http://www.w3.org/TR/PNG/

0967デフォルトの名無しさん

2006/05/27(土) 23:39:48

つーかzlib使うならlibpng使えばいいだろ

0968デフォルトの名無しさん

2006/05/27(土) 23:51:29

自己解決しました。
圧縮前のデータをファイルに書き出してみたら、データの後ろにゴミがいっぱいついてました。

>>966
見当たらなかったんですが、チェッカーがそこにあるんですか？
それとも、仕様書読めっていうことでしょうか

>>967
libpngは使い方がよく分かりませんでした。
サンプルプログラムも何でか忘れましたが、ビルドできませんでした。

0969デフォルトの名無しさん

2006/05/27(土) 23:58:34

自分でPNG吐くコード書く手間よりlibpngの使い方調べるほうが圧倒的に楽だと思うんだが。

0970デフォルトの名無しさん

2006/05/27(土) 23:59:44

車輪の再発明は楽しいよね
俺もよくやる

0971デフォルトの名無しさん

2006/05/28(日) 00:07:25

pngの仕様見たらやったことあることばっかりだったんで
libpngの方はsetjmpとか使い方を知らない命令もあったりしたんで
zlibを使ったほうがさくっと書けるかなと判断しました。
そんなに高度なことをやらせる予定もなく、pngが出力さえ出来れば十分でしたから。
結果、さくっと書けなかったわけですが……。

0972デフォルトの名無しさん

2006/05/28(日) 00:19:52

ちなみにWindowsでWin95/NT4.0あたりを切り捨てていいならGDI+を使ってしまうのが一番楽なPNG生成方法。

0973デフォルトの名無しさん

2006/05/28(日) 00:47:38

俺は手を抜くときはD3DX使ってる＞PNG出力

0974デフォルトの名無しさん

2006/05/28(日) 01:46:12

更に手を抜いて.NET Frameworkってのはどうよ

0975デフォルトの名無しさん

2006/05/28(日) 03:22:44

>>974
もれもパフォーマンス気にしなくて良いならそれを選ぶ

0976デフォルトの名無しさん

2006/05/28(日) 03:53:47

漏れはパフォーマンス気にしなくていいならppm出力しておいてImageMagickのconvertだなぁ。

0977デフォルトの名無しさん

2006/05/28(日) 09:59:48

DTP板の質問スレでppmって言ったら、いっぱいあるから分からんと怒られた。
それはそーだと思い「すいません、P6です。」と言ったら
ますます分からんとキレられた。しょぼん。

0978デフォルトの名無しさん

NGNG

>>980次スレ立てて

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

前スレ
画像処理その６
http://pc8.2ch.net/test/read.cgi/tech/1140510670/

過去スレッド
画像処理その５
http://pc8.2ch.net/test/read.cgi/tech/1127705848/
画像処理その４
http://pc8.2ch.net/test/read.cgi/tech/1107854973/
画像処理その３
http://pc5.2ch.net/test/read.cgi/tech/1090897159/
画像処理その２
http://pc5.2ch.net/test/read.cgi/tech/1054545005/
画像処理
http://pc5.2ch.net/tech/kako/992/992671330.html

0979デフォルトの名無しさん

2006/05/29(月) 09:43:28

↓よろしくね

0980デフォルトの名無しさん

2006/05/29(月) 09:57:39

>>978-979
ノ
画像処理その７
http://pc8.2ch.net/test/read.cgi/tech/1148864160/

0981デフォルトの名無しさん

2006/06/01(木) 19:08:38

埋めちゃうよ？

0982デフォルトの名無しさん

2006/06/01(木) 19:50:22

うめ

0983デフォルトの名無しさん

2006/06/01(木) 20:49:51

うめー、これちょううめー。

0984デフォルトの名無しさん

2006/06/02(金) 16:15:25

おうめ街道

0985デフォルトの名無しさん

2006/06/02(金) 17:51:57

最近青梅街道は高機能舗装で再整備してるね。
3日前に通ったんだけど随分静かになってた。

0986デフォルトの名無しさん

2006/06/02(金) 18:47:14

紀州南高梅・・・のつぶれ梅

0987デフォルトの名無しさん

2006/06/03(土) 01:26:07

DVの仕様書ってどこにあるのですか？

0988デフォルトの名無しさん

2006/06/03(土) 02:30:29

次スレで聞いてちょうだい記念埋め

0989デフォルトの名無しさん

2006/06/03(土) 10:05:14

おーめこー

0990デフォルトの名無しさん

2006/06/03(土) 13:15:52

埋まる世間も鬼ばかり

0991デフォルトの名無しさん

2006/06/03(土) 15:29:53

しゃどうまる

0992デフォルトの名無しさん

2006/06/03(土) 18:00:09

オキシダイズドシルバー！！

いぶし銀
いや、英辞郎でまじで

0993デフォルトの名無しさん

2006/06/03(土) 21:10:21

うめぬるぽ

0994デフォルトの名無しさん

2006/06/04(日) 00:20:55

やっぱり自分で作るのよりも店で食べた方が美味しい
バジル買ってきてペースト作っても貧乏人の俺には松の実やその他香料なんて・・・

0995デフォルトの名無しさん

2006/06/04(日) 00:22:14

ぶべら

0996デフォルトの名無しさん

2006/06/04(日) 11:34:23

ここらでしめ996う

0997デフォルトの名無しさん

2006/06/04(日) 11:34:56

997

0998デフォルトの名無しさん

2006/06/04(日) 11:35:35

9×9=8 1

0999デフォルトの名無しさん

2006/06/04(日) 11:36:33

ちほくふるさと銀河鉄道999

1000デフォルトの名無しさん

2006/06/04(日) 11:37:06

从‘ 。‘ 从＜1000。

次スレ
画像処理その７
http://pc8.2ch.net/test/read.cgi/tech/1148864160/

1001１００１

Over 1000Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

レス数が1000を超えています。これ以上書き込みはできません。

画像処理 その６

画像処理その６