画像処理 その６

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

前スレ
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

>>1
スレ立て乙です。

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

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

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

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

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

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

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

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

イコライズフィルタを
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

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

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

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

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

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

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

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

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

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

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

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

>>18
>>15

Brightness と Luminance の違いについて。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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);

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

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

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

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

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

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

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

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

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

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

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

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

ウィンドウ(論理座標)とビューポート(物理座標)との間で
座標変換を行う処理を実装したのですが
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() を用いて変換しています。

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

原因追求のため [式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] をそのまま使うのではなく
画像処理特有の工夫みたいなものがあるのでしょうか？

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

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

ここまで読んだ。

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

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

>>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
として、整数で計算だな。

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

あれから、色々と検証したのですが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さん
最適化した式をありがとうございます。
しかし、まだ最適化以前の問題ですので・・・今後、参考にさせていただきます。

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

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

つ【努力】

-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

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

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

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

では成り立ちません。

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

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

47はスルーですか？

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

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

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

>>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の値は説明つかないが。

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

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

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

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

いろいろとすみません。非常に助かっています。
>>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] とで誤差は発生しません。

(>>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 方向のウィンドウからビューポートへの
変換処理を行っています。

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

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

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

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

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

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

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

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

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


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

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

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


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

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

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

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

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

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

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

揚げ足とり好きだね。

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

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

アニヲタうざ

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

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

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

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

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

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

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

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

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

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

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

>>88

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

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

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

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

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

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

>>91

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

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

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

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

いいよ

>>92

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

円で検出していいの？

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

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

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

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

>>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
あれ、こんな高かったっけ。もっと安く買った記憶が・・・。

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

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

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

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

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

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

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

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

>>117
CreateDIBSection

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

直接の解答ではないし
推測だらけだが
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

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

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

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

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

はい

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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);
}
}
}

ざっと書くとこんな感じ

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

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

誤爆ですｗ

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

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

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

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

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

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

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

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

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

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

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

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

　　　　　　,.ｨ , - ､.＿　　 　 、
.　　　 　 ,ｲ/ 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;';';'/:.:.:.:.:.:.:.:.:.|.　＼:::::＼:::::　ヽ　 ::::::!′　:::| 　 .:/
.　　　　　　 ｌ |:.:.:.:.:.:.:∨:.:.:.:.:.:.:.:.:.:.:.! 　 /ヽ:::　`:::　　　　::::　　....::....／　

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

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

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

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

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

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

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

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

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

教える価値がない

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

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

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

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

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

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

>>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;';';'/:.:.:.:.:.:.:.:.:.|.　＼:::::＼:::::　ヽ　 ::::::!′　:::| 　 .:/

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

なります。

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

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

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

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

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

ｷﾀｺﾚ
恩を仇

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

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

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

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

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

VCが壊れたorz

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;

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;
}

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

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

VCがどうした？

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

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

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

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

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

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

>>224
何か問題でも？

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

最適化スレ逝け

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

まあがんがれ。

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

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

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

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命令に挑戦しましょう。

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

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

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

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

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

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

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

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

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

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

ま、地道にがんがれ。

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

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

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

sage

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

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

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

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

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

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

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

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

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

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

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

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

>>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。
αがピクセル単位じゃなければ割といいんじゃない？
合成が加算になるのもポイント高いかもよ？

って、実は試してないんだｗ
構文木出力にバグがあったり、手でまとめるときにミスしてたらゴメンｗ
「知識の無い奴」なんて言ったんだから、責任もって検算か反証してくれるよねｗ

でもさ、先に計算しておくって・・・
1+2と1+2+3と1+2+3+4と、とか、全部用意しとかないと意味無いと思うんだけど、
そういうもん？

さすがに現在使ってるレイヤくらいはわかってるだろ

なるほど　ゴミレスすまんかった

>>247
計算コストが変わらない気がするんだがｗ

変なのがいついちゃったな･･･

>>274
複数枚のαブレンドを展開したら大体そんな式になるけど、
その式でa2が変化したら、その下にみんな影響するだろ

数字が12345から01234とずれてるので後のに倣うが、
a2が変化した時に計算しなおさなくて済むのは01の段
だけじゃないか。

共通部分が多少使えても34の部分をあらかじめ計算しておけるの
とはニュアンスが違う。若干計算が工夫できるだけで、その式自体
が2以降の合成はやり直しだって証明してる。

>>247だった

あれから更新タイミングを工夫したり、範囲を工夫したら実用速度になりました
これでやっと先に進めます
ありがとうございました

>>247宛てではありませんｗ

変なのがようやく去るな･･･

>>244
下のやつ面白いね。
セガが作ってるメガドライブのエミュで使われてるやつかな。

最近のcodecはglobal動き補償というのをやってるみたいだけど
具体的にどうやっているかわかる方いますか？
カメラの動きを推定してるのかな
ttp://en.wikipedia.org/wiki/Motion_compensation

>>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 を合成したもの。
こんなこと言って上下逆にしたのは謝る。

＞ブレンドレートがピクセルごとじゃなくてレイヤ毎なら
まずこれがありえねー

それはともかく、a2変えたらx3,x4の合成は計算しなおしだろ。
単に式に共通部分があるってだけで、x3,x4を事前にx0,x1のように
固定値に出来るわけじゃない。

その、知識が無いのにあらかじめ計算できない？って言ってみた俺が来ましたよ。
イヤミではなく本当に知識不足だから、穏便によろしく。

> ブレンドレートがピクセルごとじゃなくてレイヤ毎なら
まずこれがわかんねー

>>259
> a2変えたらx3,x4の合成は計算しなおしだろ

式の共通部分で、変更に関与しない部分は予め計算しておけるって話。
今のやり方が>>258の上の方の式を毎回計算してるなら、
ある程度まとまった項を保持しておいて必要に応じて再計算すれば
平均で2倍くらいは速くなりそうな予感。

つまり、A0やらA1の計算はa1には関係無いでしょってことで。
先にA1を計算して保持しとけばa1が変わったときのA2の計算も
A2 = (1 - a0 - a1*(1 - a0) - a2*(1 - a0 - a1*(1 - a0)))
ではなく
(A1 - a1*A1)
で終了。

何か根本的な誤解があったらすまん。

まあいいや、オレの負け
式の変形のところは解説してもらわなくても理解してるよ。

その考えでプログラム組んで順番にαブレンドするより
速くなったら報告してくれ。

(A1 - a1*A1)←これ自体が順番にαブレンドした時のシチュエーションに近い
と思うがどうか？

＞何か根本的な誤解があったらすまん。

オレの言いたいことはレイヤーが

下1234 5 6789上

ってあったとき、５を変更したら1234は計算済みのものが
１プレーンにまとめておけるけど、 6789 はそうできない
ってこと。 1234 と 6789 の計算軽減量が同じじゃないって
ことは分かるよね？

そのくらい出来ないと（話はそれるが）、6789の計算を軽減するために
保持しておかなきゃいけないバッファ量とか考えてもコストが軽くなる
見込みは薄いと思う。

6789も出来るだろ

わからん、まじでわからん

A0 = (1 - 0)
A1 = (A0 - a0*A0)
A2 = (A1 - a1*A1)
A3 = (A2 - a2*A2)

この式で下のレイヤー（例えばa0）が変更された時A2,A3を
固定値で持っておけるとは思えないんだけど。

>ブレンドレートがピクセルごとじゃなくてレイヤ毎なら、計算量は極端に小さいだろ？

そもそも、レイヤ毎のレートならそんな計算は事前に計算しとくのが当然
合成が先にできるかどうかは全然別の話だろ

>>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' を何も考えずに合成したらうまくいくんじゃないかと。


この書き込みの前半と後半で言ってることはほぼ同じ意味な気がする。
自信がないからあとでもうちょっと考えてみます。

ブラウザ上でカメラ画像を表示（ローカルの）したいんだけど、できるかな？
やりたいことは、パスワード代わりに顔認証。
ボタンをポチっとおすと静止画がキャプチャされて、Ajax でもなんでもいいけど、静止画がサーバに送られてそこで認証する。
ライブラリは OpenCV しかわからないので、できればそれを使いたい。
Javascript でやるの？それとも Flash？
それとも、ブラウザ上はあきらめて、なんらかの方法でローカルのプログラムを起動させてそいつで別個にさせるべき？
それが楽だとは思うけど、うまいことブラウザと連動させられるのかどうか。
あれ、この質問、画像処理が本質じゃないな・・・。

＞1' 6 7' を何も考えずに合成したらうまくいくんじゃないかと。
7が無理でしょ。

＞a0 * 定数 + 定数
＞の形に変形するくらいはできるかと。

これを7891011と繰り返さないと駄目じゃん、と言っている。

おれ間違ってるか？　そこまで自信たっぷりに言い切られる
と考え込んじゃうんだけど。

グラフィックのハードの設計とかいろいろ仕事でかかわって
半透明ブレンドの手法は勉強したけど、どんな場合でも
結局半透明は変更したものより上のレイヤーは順に描き
なおしが唯一の解だったよ。少なくともそれ以外の手法
をやってるものにはお目にかかったことが無い

加算だけなら1' 6 7'に出来るけどね。

知識のない奴が思いつきで言ってるんだから勘弁してやれ

>>268
そうなんだ。了解・納得しました。

>>267
ブラウザでカメラ画像を取り込めたらセキュリティ問題ですｗ
何を使っても不可能です
カメラ画像をアップロードする専用ソフトを作りなさい
それからスレ違い

>>267
ヒント：JMF

>>267
ヒント： Java + J/Direct

>>267追伸
少しはググれ。OpenCVをあきらめたほうが楽。

>>272=270か？
いいかげん適当なこと言うのやめれｗ

JDirectはあくまでローカルアプリとして開発されたソフトからのアクセスは許可するがアプレットからは許可しない
どうしてもブラウザに出さないといけないのならIEに限定して認証されたActiveXを作るのが一番楽です
Mozilla系になるとプラグインを作らないといけない
ActiveXはVCやVBで作成できますが、認証されたWindows環境のみという選択をすればどのみちローカルアプリ
を動かすのと変わりません
それなら画像を撮影して画像をアップロードする形でアプリからブラウザを開いたほうがいい
これならブラウザの種類の点で融通が利く

OpenCVの顔認識って，パスワード代わりに使えるほど信頼していいのか？

寝起きとか認証されませんｗ

はがした顔面を貼り付けても認証されました

本人の写真でお面作ったら認証されました

春だな

>>275
それカメラの意味ないじゃん。

いくつか論点のブレがあると思う。

１）レイヤ毎、ピクセル毎
>117 以降、>218-219 も含めて、レイヤ毎を前提としているように思える。
また、ピクセル毎の場合でも、遅くなりそうな気がするが、事前計算そのものはできると思う。
一応、>245 で「αがピクセル単位じゃなければ割といいんじゃない？」と断ったことを指摘しておく。

２）レイヤの上下
スマン。俺が悪い。>245 で勝手に逆にした。
結果的に、数字の小さいほうが下で、大きいほうが上というのは 245 しか使ってないから、>247 に合わせてくれるとありがたい。

３）編集中のレイヤ
どのレイヤを編集するかを選択した時点での事前計算についての主張なので、常に任意の an が変更される場合については、俺の主張は適用できない。
n を決定したときに、後述のように事前計算できる部分が著しく増えるというのが主張。

続く

続き

４）下の合成
編集中のレイヤより下は、
>　α*上の画像 + (1 - α)*下の画像
の普通のアルファブレンドで１枚にしておく。
これは、>245 で変形したものを用いる前の段階。

５）上の合成
ここが >245 での指摘で、
>　α*上の画像 + (1 - α)*下の画像
を
α*上の画像 + (1 - α)*（α'*上の画像' + (1 - α')）
のように展開していくと、>245 のように、「各レイヤ画像 * 修正ブレンド率」の加算になるという主張。
編集中のレイヤより上の部分は加算しておくことができる。

で、俺の主張は、
・編集中のレイヤより下のレイヤをアルファブレンドしたもの
・編集中のレイヤ
・編集中のレイヤより上のレイヤを >245 の方法で加算したもの
の３枚を >245 のブレンド率で加算するだけで、レイヤを再統合した画像が得られるというもの。

しばらく暴れてるから、もう少しお前ら付き合ってくれ。

顔認証だと、パスワードを顔に貼り付けながらうろうろしてるようなもんだからな。
顔をIDにすればいいんじゃね？とはスラドから。

>283
昔のCマガにそれと同じ方法のってたな

>>283
何個 >245 って書いて間違えてるんだ俺は orz

>>285
暴れる理由が無くなった
Cマガの記事がでてきて、それでこのアルファブレンド事前解決問題が解決するなら、>245 は「知識の無い奴」だったってことだな

>>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は計算できると思う。

なんか式の最後、
+(1-α11)*(1-α10)*(1-α9)*(1-α8)*(1-α7)*p6
ってなってるが、
+(1-α11)*(1-α10)*(1-α9)*(1-α8)*(1-α7)*A6
の間違い。

理解できた。逝ってきます

ちょっと上にあったカラーライゼーションなんだけど
ソース見たけど専用ライブラリつかっててわけがわからない
階調にあわせてRGBの増分を変化させればいいっちゅうのはわかるんだけど
エッジ境界の処理ってどうなってんでしょ
どこまでを着色範囲にするかの判定基準のことです
ttp://www.cs.huji.ac.il/~yweiss/Colorization/
これね
これとまったく同じじゃなくてもいいので、着色する範囲という意味での領域検出に
向いてるのではと思われる代替アルゴリズムなんかあったら教えて

>>290
コード書いて検証しないとアレなんだけれども、すぐ思いついたナイーブなやり方。

近傍ピクセル間での明度の近さを「流れやすさ（滑らかさ） Q ただし 最大1.0」として、
・色が指定されたからピクセルから、近傍ピクセル（とそのまた近傍）に色を塗ってゆく。
　このとき色と供に、Σ 経路のQ をスコアとして記録しておく（最大のヤツね）。
・色指定付きの全てのピクセルから全てのピクセルに対して色を塗った後、
　各ピクセルについて、スコアが最大の色をそのピクセルの色とする。

具体的なQの定義の仕方とか、最適化とかについてはいろいろためしてみないとわからないし、
ほとんど等しい明るさはもう無条件に塗るとか最適化の余地は多々有るけれども。

>>291
ΣはΠの間違いデスタ。Σでもいいかもしれないけど。

layered なシステムの話だけれども、予め計算しておけるジャンルは意外と
少ないよ。特にレイヤーの枚数が多い＆変更されるレイヤーが任意の場合は、
逆に遅くなる（最終合成する時間だけを考えれば速いだろうけれど）。
初代ペンティアム時代に実装したことがあるんだけれど、当時のテストでは、
変化領域をちゃんと記録して、それに、z-buffer風味で不透明（透明度０％）
打ち切りを実装するのが一番現実的で（平均的に）高速だったよ。
場合によっては、単に変化領域記録だけでストレートに合成した方が速い
用途だってあった。
用途が限定されている場合は、また別だろうけれども、汎用部品として実装する人は、
このへんも検討してみるといいよ。

>>290
隣との輝度差を伝播速度として、
他の色とぶつかるまで色を伝播させて行けばいいかもしれない。

二次のコスト関数ってかいてあるから違うことしてるかもしれないけど。

小さな輝度差の連続よりも大きな輝度差の方がコスト高になるように
輝度差の二乗とかを積算して伝播してゆけばいいのかな。

>>290
ちゃんとアルゴリズムも書いてある。他の手法への参照もある。
つ ttp://www.cs.huji.ac.il/~alevin/papers/colorization-siggraph04.pdf



100ms君は去ってしまったな。よかった。

>>296
よくわからん

>>297
英語を読む気がないだけ？数式がわからん？

両方

英語はまあなんとか読めるかな
数式がわかりません

式(1)のJ(U)を最小化する最適化問題を解こうってわけ。


さらに数式は増えるけど、
セグメンテーションだけでいいならこっちの方がいい。
ttp://www.cs.huji.ac.il/~yweiss/iccv99.pdf

もっとわからない

じゃあ最適化問題のお勉強してから>>296読み直すといいよ。

ttp://junki.main.jp/fromflickr/060306.htm

ここで紹介されているHDRって、どんな論理なんだろ？

> 露出過剰で暗いところがはっきりしているものと、
> 露出不足で明るいところがはっきりしているものを、
> ソフトウェアで重ね合わせる

単純に半々で重ねるだけでいいのかな？


ttp://flickr.com/photos/andidfl/109843664/in/pool-hdr/
だとしたらこれみたいに、影が複数できちゃうのはしょうがないのかもしれない。

>>305
ドアハンドルの周囲にハロー（halo）があらわれてるから、
黒っぽい領域（の周囲）では露出過剰の方の方を多くブレンドするように
なっているんじゃない？

>>304
ぱっとしかみてないけど、
http://www.debevec.org/Research/HDR/debevec-siggraph97.pdf
の Figure 2 で理解した気になれた。

これと似たようなものかな。
ttp://www.sony-krc.co.jp/research_dis_3.html

これらなんか、すごいね

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/

どんな論理かわからないけど、ここは過剰のやつ、ここは不足のヤツ、って具合に
重ねあわす配分をいろいろ変えてるようだね。

>>309
真ん中のは普通に撮影したように見えてしまう。

>>308
むろん、似たようなものではあるけど、>>304 とは違うっぽい。
>>308 は高性能のカメラ、普通のディスプレイを使う、
>>304 は普通のカメラ、普通のディスプレイを使う。

>>309
CGに見えるよな

>>311
なるほど。
>>308は、普通のカメラじゃ複数の写真を撮らなきゃいけないから
カメラが頑張って広ダイナミックレンジで撮影して一枚ですませようってことか。
露出を変えながら何枚も撮影してズレないのかな？

>>312
真ん中のは普通に撮影したように見えてしまう。

> 露出を変えながら何枚も撮影してズレないのかな？

PhotoMatrix は多少のずれを補正してくれるらしい。
明治記念館のヤツは、子供の手がぶれてるし、そのことがタイトルになってるね

> 真ん中のは普通に撮影したように見えてしまう。

そうぉ？ 明治記念館のヤツでしょ。異様に陰影がなくて、ディテールが明瞭過ぎるでしょ？

そのうちに HDR モード付きのデジカメがあらわれるよ。シャッター１回で二枚撮れる。
そして、付属のソフトで処理するような。

だから、関係者は注目！

たんに、CCD のダイナミックレンジを拡大して１枚で済ますことが出来るかもね。

> シャッター１回で二枚撮れる。

適正露出のも加えて３枚が理想。
こんなふうに

ttp://flickr.com/photos/thewolf/107354879/in/pool-hdr/

同時に３種類の状態の素子におんなじ写体を取らせる方法ってどうやるのかな？
分光して素子を別々にするの・・・それともタイムスライスで１つの素子で処理するのかな？

そろそろスレ違いの話題に移りかけてないかな。

カメラ小僧どっかいけ

フジのハニカムにそんなのがあったな

>>320おいおい、デバイスがあって初めて一般販売できるものができるんだよ。
HWの話が少しもできない奴は実務では要らんぞい。情報だろうと電気だろうと大学で習ってるだろうに。

>>322
ヒント：画像処理

ヒント：画像処理には入出力装置概論も含まれる

画像処理っていうとやっぱ２次的操作という意味になると思うわけですよ
わざわざレースクイーンのパンツを鮮明に撮るカメラ技術を議論しても意味ないのですよ
多くの人はその恩恵にあづかることもないのですから
ステレオ写真とか連続写真とかまず存在しないソースを持ち出されても困るわけです
せめてソースとして個人が所有してるものをム板でいかにクオリティを高めるかというスレ
ではないでしょうかね

>>325
HDR の主要なマーケットを見抜いている325って・・・

>>323のタイプと>>325の間の溝は埋まらないことは分かったけど、
別にかまわないオレガイル。別の話にしようや

ようやくこのスレに恩返しができるときが来たぜ

>>318
フジのSRハニカムCCDがそれだね

小さいHDR用素子と、大きいLDR用素子を併用して
普通のカメラの4倍ののDレンジを誇るそーです。
でも8bppのJPEGで出力したら意味ねーじゃんと思いました。
つーかせっかくならOpenEXRとかで吐いてほしかった。
あとSR CCDは作れば作るほど赤字だそうです。

http://www.hdrsoft.com/examples.html
を見るとわかると思うんだけど、
トーンマッピング(HDR->LDR変換)の時に、
わざと周囲の平均との差分を取ってディテールだけ強調してるんですね。

Tone mappingに必要なコードはこれ。
http://www.mpii.mpg.de/resources/tmo/

HDRI生成にはこれ。
http://www.debevec.org/FiatLux/mkhdr/

な。あとlucille/syoyoさんとこも押さえとこう。

あ、>>323≠>>324。

確かにカメラの話はスレ違いだと思うよ。
大学の講義で「画像処理」にそういう話がはいってるとか
そんなことはどうでも良くて、ただ、

>>325
> 多くの人はその恩恵にあづかることもないのですから

多くの人がその恩恵にあずかることになると思うのだが。

やれやれ
窮屈なスレだ

デブ、痩せろ。

>>332

スレ違い。

>>304
HDR現象ってつまり明るさのダイナミックレンジの圧縮だね。

>>312
>CGに見えるよな

一般的なCG技術の限界の一つが、HDR現象がおきてしまうこと。
むしろダイナミックレンジが狭いディスプレイに合わせてＣＧを作ると
ダイナミックレンジの圧縮をせざるを得ない。

つまり、CGっぽさの正体の一つがダイナミックレンジの圧縮じゃないかと思う。

最近、GPU界でトレンドのHDRレンダリングは、
ダイナミックレンジの圧縮を使わずに表現する技術。
しかし、レンジの狭いディスプレイにそのまま写すと当然、白飛び黒潰れする。
そこで、人の目がまぶしさや暗さに一定時間で慣れてくる特性を再現して
自然に見せている。

>>332
がんがる。今64キロ。

>>334
後半とのつながりがわかんね。
今はダイナミックレンジの圧縮をしない方向だけど前はよくやられてて
コレと似た結果になるからCGみたいに見えるってこと？

>>335
以前は主照明を弱くして環境光を付与するなどして、
照らされているところが白飛びしないように、
日陰の部分が黒つぶれしないようにシーンを造っていた。
RGB各8ビット程度で計算していたので、
こうしておかないと「後処理で〜」とかもできなかった。

今は浮動小数点数など使えてCG計算過程でのダイナミックレンジが
広がったので）本来あるべきとおりのライティングでシーンを構成し、
広いダイナミックレンジでレンダリングして、後処理で視覚特性に
あわせたレンジ圧縮処理を行うことができる。

ワンダと巨像のあれは嘘んこHDRだから気をつけろよ

嘘でもそれなりに見栄えがあればOKなギョーカイだからOK!

平面写真を立体認識するフィルタを見つけたんだが興味なさそうだからいいか

立体画像を平面認識するフィルタを開発しますた。

>>339
ｋｗｓｋ

>>339
ｷﾀｺﾚ!

>>339
キボン

>>339の人気に嫉妬

>>341-343 ああしかし、それでも あなたの恋は実らない

ショボーン(´・ω・`)

このスレにコテがいないのはなんで？
居たらいたでうざそうだけど。

さあ。
むしろなんでそんなこと聞くの？

他のスレも見てるんだけどさ、必ずへんなコテがいるじゃん。
ここはなんか他のスレと雰囲気が違うんだよね。
なんでだろ〜と思ってさ。

IDが出ないからコテも偽者だらけになるしね。

トリップ付けないコテハンなんかいないだろ、ふつう

じゃあなんで？

>>347>>349>>352
お前鬱陶しいからコテつけてくれよ

画像検索から画像ひろってきて研究に使ってはやっぱりいけないのですかね？
有名人の公開している画像でもまぁ同じですかね？

スレ違い

だめに決まってるだろ･･･。
つーか、分野ごとに標準画像的なものがあるでしょーが。
それらを使わない/使えない理由でもあるの？

標準画像でも大抵金払わないと使えないけどね。
JISとかISOとかITEとか。

私的に研究に使う分にはOKでしょ。公式に発表するときにはダメだろうけど。

アマチュアですか。

プロですか。

1967年4月生まれ いま16歳

MZ1500を思い出すな。

写真くらい自分で撮れよ

でも
http://vasc.ri.cmu.edu/idb/html/face/frontal_images/
とかってどうなんでしょう？有名人だからいいのでしょうか？
あと画像検索系のはウェブに散らばってる画像を無論使うわけで、
それはどうなんでしょう？気をつけているのかな。
>>358
その公式ってのは論文に貼り付けしなきゃいいってことなのでしょうか？
画像はウェブから拾ってきて実験しました。って書くことになるから意味なし？

>>356
足りないんです。

>>363
5000 サンプルぐらいほしいんです。
5000 positive, 3000 negative でやっとまともな結果になると論文に。

統計データを載せるだけなら別に問題ないぞ
写真そのものを添付しないならね

>>366
そうなんですか。勉強になります。
では集めてみようかしら。

364のリンク先のとこにPlease give appropriate acknowledgements when you use these test sets.
ってあるから、論文書くときはとりあえず謝辞には入れるんだろうし、それなら
あらかじめお礼もかねて断りのメールを一本入れておくのが無難だろうな。

素材屋に相談した方が早そう。権利関係もはっきりしてるし。

>>365
うちの大学でもデータ収集してる人たちが居たなぁ。
粗品でボールペン貰ったよ。

こういうサンプルデータって金で買うと結構高いんだよね。
研究室で音声認識もやってるんだけど、CD-ROM6枚ぐらいで数十万とかしたしな。

昔から顔認識やってるとこはそんな感じだね。日本女子大のとこ
なんかデータが女の子の写真ばっかりのときがあった。

おっぱいの素材ならいっぱいあるとかいってみるテスト

もし、認識して個体識別できたらすごいね ＞ おっぱいの素材

これがおっぱい認証の始まりでした。

おっぱいの素材ってシリコーンの有無か？

>>368
そのリンク先が、そんなもの公開して法に抵触しないのか。って意味じゃないのか？

>>375
もっとスケスケにして乳癌の認識ならやってる人たちいるぞ

>>375
俺、おっぱい認証できるぜ。

セキュリティールームに入るのにおっぱい認証いいな

お前ら本当に最低だな･･･。

男が認証するのは見たくないな。

でも、ちんこ認証はきもちいいぞ。

著しく質が落ちてるスレはここですか？

いいえ、ここは著しく品が落ちているスレです

でもカメラのことはすれ違いで怒られるんだよね。

このスレでの話題に対する評価:
おっぱい＞ちんこ＞カメラ

おっぱいチンカメ、と覚えましょう。

なんなの、この流れ。

ここで>>339降臨
↓

ここで書きこみ。スレの住人は俺の書き込みに、く・ぎ・づ・け、だな。

顔の話に戻してみます。

>>267とは別の話しで一度撮った画像から顔の向きを知りたいです。
そこでOpenCVの顔検出を使いたいんだけどあれってどこまでできるのでしょうか。
どこまでとは顔の範囲，向いてる方向，目と口の配置，目線の方向とか。
例えば，

一二三
八人四　人　：対象人物
七六五　数字：カメラ

のように周りから複数台のカメラで撮影した写真から顔を検出して
どのカメラが正面に近いか判定するのは可能でしょうか。

ちなみにカメラの位置と人がいないときの背景画像はあらかじめ持っていて
差分を取れば人の領域は検出できますが人物に関する情報はありません。

カメラ小僧どっかいけ

カメラ小僧じゃないってのｗ
顔検出って普通に画像処理の話。

>>391
その程度なら顔検出なんかするより、

・人の頭は一番上にある
・顔は左右対称 or 顔は後頭部より複雑 or なにかそういう仮定

とかのヒューリスティックな知識を適当にアルゴリズム化した方が
はるかに良さそうな結果が得られそうに思うけど。

>>394
なるほど。
ただ，まずはどのカメラに写っているのかわからないので
検出しないと話が進まないっぽいのです。

しかもカメラには全身を写したいので顔は小さめで，
XGAで撮影すると顔の領域が80*100くらいになります。

> 顔は左右対称 or 顔は後頭部より複雑
これらもまず顔が見つからないと…。

人が寝そべってたり動いてて不安定な姿勢をとっていたりにも対応したいので
あまりヒューリスティックにはしたくないです。

画像処理のためのカメラの技術はスレ違いだって、前のほうで言ってたよ。

> 顔検出って普通に画像処理の話

そんなに普通なら、普通に処理するといいね

普通に画像認識の話だろ。
なんか変な粘着が居るが、カメラに嫌な思い出でもあるのか？

どうせなら１枚の写真でやろうぜ

OpenCVってのがどんなもんかしらないけど横顔で認識させたら
エラーになるだけだろ
単純に３枚なら３枚やってみて一枚でも認識できればOkってことにすればいいんじゃまいか？

>>400
ちょっと意味がわからないです。

>>391の例で言うと
人が２の方向を向いてれば１，２，３のカメラ画像から
もしくは２だけから顔が検出されてOKかと予想はしてるんですが，

さっきいくつかの実際に使う画像＋OpenCVサンプルで試してみたところ，
微妙に横向きでも両目が見えるくらいなら検出されるみたいです。
でも右腕の辺りから顔がでたり，誤認識を確認しました。(´・ω・`)
カメラが遠いのである程度これは覚悟済みです。

そこで8台のコンセンサスをとれば誤認識の可能性を減らせるかなと。
だからある程度正面方向からのズレも知りたいんです。

3台のカメラがほぼ同じ方向を向いた顔を見つけたけど
全く逆側のカメラからも顔が出てきて，その大きさが全然違うとか言う場合に
対応できるようになるはず。

だから顔の有無だけでなく，
向きや目の位置などを得られるのかどうかが知りたいです。

それだけ写真があれば方向を得られる情報が含まれているはYESだけど
OpenCVが対応してるはおそらくNoです

>>402
じゃあOpenCVの顔検出ってどういう出力になってるの？
逆さ向けたり横向けたりすると検出されないってことは
顔のパーツを見つけてるんだと思ってたけど。

標準だと顔のパーツごとじゃなくって、顔全体で探索してるよ。
\OpenCV\data\haarcascadesにカスケードファイルが幾つかあるけど、正面顔と体全体の学習結果しか無いね。
画像集めて学習させたらパーツ毎の探索もできるんだろうけど･･･。
データ収集も計算も大変だよね〜。

>>391
OpenCVの顔検出の出力は矩形領域として結果が返されるでしょ？
面積が一番でかい奴が一番近いとかじゃだめかね？
つーか、それだけカメラがあるなら多眼距離計測もできるっしょ。

顔認識ルーチンはサンプルが付属してるから実際にカメラ繋げて試せばいいじゃん。

>>404
そこで >>354 の話がでてくるわけですね

むしろここで>>339が登場

またまた、ここで書きこみ。スレの住人は俺の書き込みに、く・ぎ・づ・け、だな。

てか認証に使うとか言ってたやつだよね？
認証なら正面向かせろｗ

>>409
投稿人が違うと読み取ったが、いかがか。

>>409-410
そう，また別件です。
こっちは検出で、認証は使わないです。てかOpenCVに個別の顔の認識は無かったような…。
てかみなさん，顔検出と認識とをごっちゃにされると話がややこしいです。
画像認識って意味ではあってるんですけどね。


>>404
このファイル、実体がよくわかっていませんでした。
パーツに区切られてるってわけではないのですね。
じゃあ向きを知る手がかりは信頼性の低めな顔の有無だけってことですか…。

>>405
単純にそれでもいいかもしれません。ただカメラ画像で試したときは
エラーがでたので（手が顔にされた），それが心配です。
同時に行う別の処理でおおまかな体の形状を出してるので，
頭の位置や大きさと比べてありえないものをはじくっていう手もありますね。

この手の方法はあまりスマートでないので融通が利かないのではと心配ですが，
その線で考えてみます。

photoshopなんかで選択したときにうにょうにょ動いてるラインってどうやって書いたらいいんですかね？

宿題やって下さい。お願いします。

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)

>>412
「(x-y) % 10 が 0〜5なら黒」とかそんな感じでない？
アニメーションは0〜5の部分をシフト

>>414
それはわかるんだけどそれだと１点ずつ計算して描画しないといけないわけで
PSetでやるとむちゃくちゃ遅い

>>415
そういうのはGUI環境ごとに或いはGUIライブラリごとにその目的の関数が用意されていたりする。
画像処理なんてレベルの話じゃないから該当環境スレで聞き直したほうがいい。

普通のWindowsGDIだけど専用の関数なんてないですけどね
普通にやってるソフトはいっぱいありますがね

windows なら
・　LineDDA を使う
・　ExtCreatePen　lpStyle　を使う

>>418
ああ、なるほど、わかりました

もう一個質問です
画像を拡大表示してて１っ箇所だけ修正してその部分の拡大画像を再描画するような処理があるんですが
補完処理してるとちょっよ見た目がずれます
全体を描画すれば防げるけど、遅いですからね
ずれないようにする計算方法とかあるんですか？

>>419　補間でズレるという事は　なにか間違ってるんでしょ。　

そんなふうに自分がバカだって一生懸命アピールされたって、こっちはウザイだけ
自分で考えるのが嫌なら、お願いしますと頭を下げて、その間違ってる補間式を公開したらどう？

>>420
うるせーな
あなたには答えていただかなくてけっこうです

>>421 あのさ、この手のスレで答えてるのはオレなんだよ。　もちろんオレは一人じゃないけどね。

さすがのオレでも、あんたのパソコンの画面が見える訳じゃない。
聞きたいなら必要な情報を出しなさいとオレの言い方で教えてやってるんじゃないか。

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は別人ｗ

>>423　それはアドレスを計算してるわけだよね？　それをそのまま埋めてるなら補間というより単に拡大してるだけになるが
　 ズレるなら x の初期値が問題なのだろう

初期値は０だし信頼できる値です
そういう意味のズレるではないのです
例えば３０倍で拡大した画像100x100があったとして
これの(11,11)-(20,220)を取り出して拡大すると
1Pixelが30Pixelに均一になるのが望ましいわけですが
29だったり31だったりする場所が出てくるわけですよ

３０倍というか中途半端な倍率のときとかね

あ、普通に左上から毎回計算すればいいだけかｗ

初期値が0だからそうなるわだし、
左上から計算しなくても、その計算式から初期値を計算すればいいだろう
というか、そういう質問なら算数スレで聞いた方がいいぞ

画像を扱うのはまったくの始めてなので、
トンチンカンな質問かもしれませんがお許しください。

あるビットマップの色を、453色の決まった色に
変換して表示しようとしています。

そこで、画像の各ドットのRGB値の色を、453色のRGB値化された
色情報の配列から近い色を探して変換したいのですが、
この「近い色」を探す方法がよくわかりません。

最初、単にRGB値を32bitのint型に変換して（&H0000FFの青なら255）、
最も近い値を探して変換してみたのですが
これがほとんど役に立たないほど違った色になってしまいます。
ちなみに、453色の配列自体は、DMCという刺繍糸で使う色であり
特にかたよった色の集合ではないと思います。

通常こういった処理は、どう行うのでしょうか？

>>429
簡単に説明すると、RGBそれぞれを0から255という辺に持つ立方体として考えて、
それぞれの色をこの座標系に入れて、二色間の距離を出してやるといいよ。

つまり、(r1-r2)*(r1-r2)+(g1-g2)*(g1-g2)+(b1-b2)*(b1-b2)　の平方根
距離の大小を比べるだけなら、平方根はださなくてもいいけどね。

>>430
たぶん、>>429はそれをやったんじゃないかと。
減色は語り尽くされた話題だから細かい説明は適当に検索してもらうとして、
原理的には目的に見合った表色系に変換して、その空間で「近い」色に変換。
プログラムでRGBが必要ならまた元に戻せば良い。
HSVとかHLSとかL*a*b*とか、まあ、扱いやすそうな表色系を探してみてください。
変換式（近似式の場合もあるが）もあちこちにあるので、そんなに難しくないでしょう。
ただし、刺繍糸の特性に合ったものというのはないんじゃないかな？

>>430,431
レスありがとうございます。

>>431
いえ、430さんの方法ではやってないです。
RGB値を距離ととらえて、2色の距離で差異を出すという
考え方は思いつきもしなかったです。
根が文系はもんで・・・

質問する前に、いろいろ検索していてRGBをL*a*b*に変換し、
それから近似値を・・・と思ったのですが、この場合も430さんのとおり、
L*a*b*値に変換してから、2色距離を求める方法でいいのでしょうか？

元が写真とかなら近似値だけじゃなく誤差拡散なども入れたら？

カメラ小僧どっかいけ

>433
刺繍のデザイン用のソフトを作ろうとしているので
写真にかぎらずイラストっぽいものも多く扱うと思います。
むしろ写真は少ないかな？
写真から刺繍のデザイン作ろうとすると、
まともに見えるようにするには、はてしなく大きな布（キャンバス）が必要なので・・・

と、いうことで。
とりあえずRGB値のまま距離換算で近似値求めて変換処理を行ってみました。

まあまあいい感じに色の変換できました。
ちょっと不満足な変換になる場合もありますが・・・
これはおそらく刺繍糸の色自体が、それほど明るく派手色が少なく、
落ち着いた色が多いことによるものだと思います。

まずは１ステップアップできたので、L*a*b*や他の色系統での
近似値を求めた変換もチャレンジしてみます。

ありがとうございました。感謝です！

>>435
DMCの刺繍糸って453色も入手できたっけ?
実質はもっと少ないと思うし、糸の特性上どうしても明度の幅が狭くて
彩度も低めな気がするので、その辺りを巧くフィードバックさせるようなU/Iが肝になるかもね。
#実際、たった1画素っつーか1目のために(似た色があるのに)違う色を使うってのもナンセンスだしね。

>>436
私の買っている刺繍糸の通販サイトだと450色近くは品揃えがありますね。
　ttp://www.craftmax.net/category/shishu/
とか。

ただ、実際クロスステッチとかやってると、一つのデザインで32色以上あると
結構糸取り替えるのに死ねるので、あらかじめ画像は減色しておくように
なると思います。
もしくは、私の作ってるアプリ内で減色させるか。

＞#実際、たった1画素っつーか1目のために(似た色があるのに)違う色を
＞使うってのもナンセンスだしね。
確かにこれはよく起こると思います。
ただ、色（糸）の削除や別色への置き換え機能を設けるつもりなので、
そのあたりのインターフェイスが使いよければ・・・と思ってます。

>>437
ほほぉ。なんだか結構面白そうなアプリケーションになりそうですな。
問題はユーザターゲットで、画像馴れした人なら「事前に適当に減色してついでに
色調も調整しておいてください」でいいだろうけどそうでないとねぇw
究極は、減色、色調調整、サイズ変更、歪補正くらいできると便利って話になったりして。

つい話題に乗っかって妄想書いたけど、楽しみながら作ってくださいな。
#毛糸の編み込みで似たようなプログラムを作ろうとしたことがあるので妙に親近感がw
##あっちは目の形がX型じゃなくてV型になるけど。

PCで写真から切り絵の下絵を作って作品にしてる人がニュースになってたな
切り抜かなくていいじゃん、と心のどこかでつっこみを入れてしまった。

>>438
実は優秀な「KG-Chart for Cross Stitch」ってのが
フリーでもうあるんですよｗ

ただ、フリーの前バージョンが100x100までだったので、
自分でもうちょっと大きいサイズまでできるの作っちゃおう！
と息巻いて作り始めたら、KG-Chartがバージョンアップして
500x500に対応しちゃったけどね・・・
と、いうわけで今は新しく出た、VB2005の習熟用として作ってる次第。
やっぱVBだとbitmapクラス使って変換処理とかやってると
遅いけど。。。

そろそろスレ違いなので名無しに戻りますです。

人間に見える色を数値化したのがHSVだから
HSVに変換して平均差の小さい色に統一すればいいと思うけど

>>428
ちなみにその計算式書いてみてもらえますか？

>>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 が反対かもしれないよ

>>441
429です。

HSVですか。
なるほど〜ちょっと調べてみたのですが、これなら
糸の色に近いものに近似化できそうです。
VB2005で作ってるので、ColorクラスにH、S、Bを返すメソッドが
あったので、これを使えば簡単そう！

ありがとうございます。早速やってみます！

やってみました。
一応、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だけなのでしょうか？？

似ているという場合、人間がどれだけ敏感であるかの重みをかける必要がある
明るさについて色より敏感である事は判ってるけど
どの程度かというのは難しい。
だから HSV より RGBのままの比較の方が良い結果になるのかもしれない

一番敏感な明るさ
　 0.2990*R + 0.5870*G + 0.1140*B　式を使って、 RGB方式で重みを工夫してみてはどう？

>>445
APIのドキュメントにはHSV の H は　0〜360.0、SとVは 0〜1.0 の値を返す、
なんてかかれてませんか？

これだと色選択の際に H の差異が支配的になってしまって、
S と V は殆どこうりょされないことになります。
距離を計算する際に、H を　360.0 で割ってから用いれば S V と同じ
影響力になります。

漏れの考えでは多少色が違っても明るさ等を合せたほうが良いと思うので、
H は 360 よりもっと大きな数で割って、Vは2倍くらいにして用いても良いと思ういます。
色々試してみてください。

>>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

>>446-448
なるほど・・・

言われてみれば、HSVにしてもLabにしても
各要素の最小値・最大値が異なるのでしたね。
気づけよ！って感じです（´･ω･`）

RGB、HSV、Labの３方法でいろいろ係数を掛けて
一番具合のよい方法を探索してみますです。

・・・っと、その前にいろいろサイト回って色について
もう少し勉強してきます。

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

>>449
一点、基本的だけど文系の方だと見落としているかもしれないので、
注意しておくと、色相 H とかは輪になってます。
0〜360度ということは、 359度と1度との間の距離は2度ですよね？
これは単に引き算ではうまくいかないのもわかりますね？
書き込みが簡略化した式ならいいのですが、、。
ちなみに、こういうのを mod 360の上で、とか言います。

つまり180度以上差があったら360からその差の値を引けばOK？

>>450
ぬお。おっしゃるとおりですね。

まったく気づかず、そのまま引いてました。。。
指摘ありがとうございます！

ちなみに、Lab方式でかなりいい感じに近づいてきてます。
一応、どの方式でも変換＆あるていど係数もいじれるような方式で実装中。

なんか光が見えてきました。
感謝！！

>>４５１

この場合角度だから sin/cos成分に直して距離を出すのも方法かもしれないね

おもしろいこと言うなぁ・・・角度とか

角度って普通に言うよ。

角度　 A ,B の距離を

√( (sin(A)-sin(B))^2 +(cos(A)-cos(B)^2 )

で定義するなら、

どうせ遠いのはどうでも良いわけだから、近い2点についてなら
角度で距離を見ても sin,cos で見ても大差ないよね。

>>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)が小さいならほぼ比例する

>>458
そのときの「小さい」はどのくらいでしょうか。

>>459
例えば↓ページの y = sin(x) のグラフを見て下さい。
x = 0 近辺では、ほぼ直線になってますよね。

ttp://w3e.kanazawa-it.ac.jp/math/category/sankakusansuu/sankakukansuu-no-gurafu.html

この「ほぼ直線」になってる範囲が>>458の「ほぼ比例する」範囲になります。
どれくらいを「ほぼ直線」と看做すかは、応用次第です。

極座標化は　複素数でいえば対数化する事に相当するから

算数スレですか？

画像処理において算数が関係しないことなど無い
算数が出来れば画像処理が出来るのであれば
人間並みの制度の処理が聞くまでも無く出来るということだ
そういう人はスレから去るべきだ
ここは算数を勉強するスレなのだ

二次微分とか正直なぜそうなるのはさっぱりわからん
資料があればやりたいことは出来るからまあそれでいい
意味がわかる人は資料を作る人にでもなってなさいってことだ

>>463 目的と手段が逆転してるわな。

角度とか？ Hue での距離がなんで角度なんだ？
円環で表してるのは便宜的表現にすぎないのに。

>>460
いや、それはわかってるけど>>444の場合どうだろうって話。
A-Bって小さいとは限らないんじゃないの？
sinを普通に使ってもいいんじゃないの？

>>466
便宜上表現にすぎないからなおさらでは？
よくわからんのだが。

「HSV色空間での距離の定義」が問題になってるんだね。
先行研究に何かないかね?
例えば、H社が車両色識別装置(高速道路とかに設置されてるらしい)とか売ってるけど、この辺をどう扱ってるのか気になる。

刺繍用の色混色のアルゴが作れたら
それだけでひとつの表色系になってしまう気がする
もう誰か作ったんじゃないのかな

ヒント：median block

>>469
限られた色・限られたパタンで画像を表現するのは刺繍だけでなく印刷もそうで、色の配置や重なり具合の制約まで考慮された方法が山ほどあるみたいです。

>>467
　たぶん、差が小さいもの同士を塊化したいのだから、遠いものはもう遠いで、いいじゃないという事では？

ただ、輝度が極端に暗いなら色相の差に意味はないわけで、と考えると、色相差^2 で評価するのはそもそも失敗かもね

TextSS　の64bit化おながいします

もしくは64bitにネイティブ対応した置換ソフトないですか？

>>473
スレ違い。マルチ乙。
あと氏ね。

すごいマルチだなｗ
俺の巡回しているスレ全てに貼られている。
まさかここは無いだろうと思っていたのに…

新手のウイルスにでもひっかかってんじゃねーのかな

アンシャープマスクのレベル補正って何者？

>>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=

シャープフィルタのサンプル教えれ

>>454
角度って・・・いつの時代のネタだよ！
思い出してｺｰﾋｰ噴いたじゃまいかｗｗｗ

お互いふるいねぇ・・・・角度とか

smartOCRてどっかの研究室のグループが作ってるの？

個人だろ

こういう最先端技術関係は専門で勉強した人が知りうる知識を終結して作ったものより
独学でむちゃくちゃな論理でやったもののが優れてる場合が多いからね

smartOCRのせいでコンシューマー向けOCR業界終わったよ。
将来性のある部署に異動したい。

でもLite版て認識率悪いし
Pro版は18万もして高いよ

認識率が良いというのは利用者にとっては１００％であるということであって
９９％だろうと８０％だろうと１個でもご認識が入れば同じ量の人間による検閲の必要性が出てくるわけで
どっちも認識率は悪いという評価になる
同じ悪いなら安いほうがいいに決まってる

んなこたーない

>>487
99％と80％では、検閲の必要性は同じでも、修正量が大きく違うわけだが。
そしてそれがそのまま効率に繋がる

量とかいう以前に、80%だと普通に全部タイプした方が早い予感。

ソフトメーカーのくせに個人もつくれる規模のソフトを何も知らない顧客に高値で売りつける精神が腐っとる

そりゃその気になりゃなんだって個人で作れるだろ

フリーソフトの次はオープンソースのOCRが来る予感。

e.typistなんか2万円以下で買えるのに
smarocrなんて定価が38万だよ？

ボッタクリすぎ

ライブラリのほうもアホみたいな値段だな。
まあ、それくらいの付加価値があると自分達は思ってんでしょ。

ターゲットがソフトハウスならライブラリ数十万って普通だろ

価格にあわない価値なら、買わなきゃいいだけだろ・・・

>497
ちょっとちがう。
「使わなければ」が正解。買う価値ない等と言いつつ使うやつがいるから、
不正コピーが減らない。
もっとも 494 みたいに、ＡとＢの価格を比較してボッタクリなどと言うやつはバカ。
ＣとＤの商店で、ＡとＡの価格を比較した時以外は、ほとんど無意味な概念＞ボッタクリ

文字認識は顔認識とかに比べてめんどくせーよな。
文字の切り出しからめんどくさい。
形にもっていくまで手間かかりすぎ。

Liteは認識率悪いよ
無料だからしょうがないけど

認識率はe.Typistの方が高いし
smartOCRのProより安い

質の悪いサービスを高い価格で提供していることをぼったくりという

smartOCRは敵が多そうだなｗ

変だね。ぼった栗なら、相手しなければいいだけ。
e.Typist で代替きくなら、無問題。なんでいちいちコメントするのかね？

JW-CADでCADメーカーが大損害を受けたのと同じで
フリーソフトでそこそこ使えるのが出現すると、今まで通りの商売ができなくなるからな〜

そうか？フリーのそこそこ使えるOSがあるのにWindowsは大損害受けてないぞ

千億単位で大損害受けてるよ。兆単位で儲けているけど。

CADメーカーがクソだったってだけじゃないか

> フリーソフトでそこそこ使えるのが出現すると、今まで通りの商売ができなくなるからな〜

それは、価格にあった価値がないからだな。
フリーソフトに負けるのは、負けた方がぼったくりだからだね。500 によると。

お金つぎこんでもフリーに負けるようじゃ
ワロス

OpenCVを入れてみたんですが、
cvCaptureFromCAM()を呼ぶと永遠に帰ってこなくて困ってます。
環境は
fedora core 5.
キャプチャボード(Bt878)*２
カメラは全部刺したり全部抜いたりしても変化無し。

エラーすら帰ってこないのでお手上げです。
解決法ご存じの方いましたら御教授下さい、

OpenCV エラーかえってこねーよな。
Yahoo Groups にいったほうがいいとおもう。英語だが。

opencvはマニュアルの整備がなされてなくて大変
結局ソース見てる
疲れる('A`)

>>509
その関数ってLinuxでも使えるの？
漏れもOpenCV使ってるんだがその関数は使えないものとｵﾓﾃﾀﾖ。
つかキャプチャボードからの場合はVideo4linuxとか使えないんだっけ？
あっちのほうが楽な気がする。

>>512
グハ…
勿論素のv4l使えば画像は取れるんですが、
configure時にv4lとv4l2にyesとか表示されるから
そのラッパとしてOpenCVを使えばもっと楽だと思ったんですが。。

IEEE1394関連を抜いてやり直してみてダメだったら、自前で取得する事にします。
#動画回りも使えんかったらOpenCV使うのやめよう…

素人が横槍入れて悪いんですが…
自分は普段Linuxで画像関係扱うのでV4L使ってるんですけど、
WindowsでV4Lみたいなのってあるんですか？

DirectShowかVideoForWindowsかな

linuxにあるものは大抵windowsにもある
windowsにあるものは大抵linuxにはない

>>516
たとえば？

DirectX,
APIレベルでのハード画像合成
動画コーデック
ゲームｗｗｗｗ

>>518
OpenGLでいいじゃんか

OpenGLはもともとCADに準拠した目的で設計されてその仕様はほとんど変化してない
拡張という形でグラフィックカードメーカー独自の仕様もあるにはあるが所詮は独自仕様でしかない
まあ所詮ＣＡＤだからワイヤーフレームがメインでテクスチャはおまけ機能なのだよ
ピクセル処理なんて到底向いてない

また根拠の無い話を

まぁ、OpenGLも2.0で変わるのかもしれないが、現状ではそうだな。
http://www.watch.impress.co.jp/game/docs/20060329/3dps3.htm

>>519
OpenGL は両方にあるじゃんか。

smartOCRを作っている会社は不審な点が多い
買わない方がいい、と忠告しておく

>>524
>>485みたいなひと？ｗ

性能良ければ、どこがつくっててもいいんじゃないの？

>>485は白旗を揚げて降参している
>>486だろ

個人情報保護法の施行で販売者の身元は必ずしも公の場にさらす必要はない
もちろん契約する場合は必要だが

潰れそうな会社なのか、それとも個人がシェアウェアみたく売っているのか、
消費税は取るのか、メール以外のサポート方法はないのか、全然分からん

読取革命体験版よりはるかに認識率が悪かったんだけど

なら無視すりゃいいじゃんか、変なヤツ大杉

んなのシランがな。

線形補間法で一番綺麗なのってどんな手法？

>>532
日本語として成り立っていない

>>532
とりあえず、一番綺麗なものを評価するプログラムを提示してくれたまえ

>>532
日本語として成り立っていない

フリーソフトがシェアを奪うジャンルのソフトは
つまりプロが作るまでもないってことでしょ。

セキュリティソフトは商用を機能制限して
一応無料で使えるようにしているものが多いけど。

フリー作家もふだんはプロとしてやってる人間なのにな
フリーだからとかプロだからとかそんなくだらない話したいの？

セキュリティソフトは感染者が少しでも少ないほうが
正規ユーザーの利益になるからです。
正規ライセンスの中に他の感染者からの攻撃の軽減という機能も含まれてるわけです
馬鹿

sobelフィルタなどで重みをかける例を
webサイトに乗っている例題などを見ると、
「端のピクセルは無視する」とあるのですが、
無視しない全画素に処理を施すにはどうしたら良いのでしょうか？
アルゴリズムが記載されているところがあれば、教えて下さい。
（ 端だけの処理の為に全画素にif/elseで分岐するわけないだろうし、、、）

端の処理が何ピクセルかを先に取得して、その分ループを分ければいいと思うが

>>540

どういうことでしょうか？

画像が100x100だったら、102x102にして考えるってことだろ。はじは、隣のピクセルと同じ色だと仮定して。

外野だけど納得した

いや、ちょっと違う・・・
端のピクセルは同じ色だと仮定する別処理ループ、中のピクセルは通常処理でループっていう話。
端判定を全画素に行わないために処理を分けるってだけ。

>> 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;

省略
}
}

分岐するということでしょうか（この場合コストがかかりすぎますよね？）？
本当にわかりません。

>>545
102x102のバッファにデータを移し替えて、1から101でループすればいいだけじゃん。

カレントピクセルを挟む差分なんだから、端なんか取ったって無意味だろ

>> 546

ありがとうござざいます。
一回バッファーに入れるんですねありがとうございます。

>>545
if 文いらなくするために 102x102 に拡張したのに。
でもコピー自体コストかかるべ。

>>544さん は
ループ内に if 文を書かなくていいように
端っこの処理をまずやって、
端を含まない2重ループをその後にやればいいといっている。

端の処理は
１．そもそもしない
２．外の画素は端の画素と同じ値と仮定して延長
３．外の画素にだけマスクはあてない
４．外の画素はなんらかの補完処理によって作成（２の発展）
といまちょっと考えただけでこれぐらいは思いついた。考えた？

余分なバッファにコピーしない場合は
int i = 0;
処理A;
for (i = 1; i < 101; i++){
処理B;
}
処理C; //i == 101
っつー風に書く。これを縦横の組み合わせで9通り。
もちろん9通り馬鹿正直にかかずにマクロやtemplateで実装する。

馬鹿ばっかりなので天才の俺様が教えてあげよう
一時微分３ｘ３というのはなんのためにあるかというと
同じ比率ｆで変化させる平坦化させるなどの意味があるわけだ
-1,0,1
-2,0,2
-1,0,1
これがsobelの関数になるわけだがこれにはある規則性がある
なにかというと
中心の係数＝周囲の係数の合計値
である
例えば左が書けた場合を考えよう
0,1
0,2
0,1
合計は３だ
各画素値に係数を乗じたものを合計して係数の合計値で割ったものが中心の純粋な画素値になる
他の関数でも同じことだ
わかったか？

合計は４ですたorz

>> 550

for (i = 1; i < 99; i++) {じゃないの？

あのな
周辺を除外したらエッジがはいらねーだろ
塗りつぶすときとかどうすんだ
あと大きめの画像を用意するってなんだ
いらないエッジはいりまくるだろ
へたしたら額縁みたいになるぞ
お前らもう少し頭使えなｗｗｗｗ

>>554
じゃお前が結論だせよ。アルゴリズムかけよ。

>>554の模範解答
　　　　　↓

>>551に書いてるだろ？頭悪すぎて理解できないか？ｗｗｗｗｗｗ

誤字脱字だらけで読む気が失せるんだけど。
つーか、誤字の訂正もできないほど無神経なのか。

ノイマンかトーラス拡張する。

int sobel1[9] = {-1,0,1,-2,0,2,,-1,0,1};
int sobel2 = sobel1 rotate 90

for(y=0;y<height;y++){

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;

if px,pyが範囲内なら){

rsum += image.red(px,py) * sobel[sp];
rsum += image.red(px,py) * sobe2[sp];
count += sobel[sp];

}

}
}

rsum /= 2;;
rsum /= count;

dest.setred(x,y,rsum);

}
}

>>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 がたくさん入っていやなんですけど、
なプログラミングレベルの話だべ？

で、結論（馬鹿ばっかりなので天才の俺様が教えてあげよう)
　　　　　↓

陵辱痴漢地獄

http://www.scanr.com/what.aspx
これどうやっているのかだれか推測してください。
このソフト欲しいなぁ。

二軸の直線成分を見つけてアフィン変換掛けてるだけ

だったらいいなぁ

>>567
リコーのデジカメにそういう機能あるね。
元々はプレゼンのスライドなんかを撮るための機能だけど、
CDのジャケット等四角い物なら何でも使えるから意外と便利らしい。

四角い物にしか使えないので、ハフ変換等で枠を検出してから
パース変換するだけかと。

>>564
その場合２５５じゃなくて１２７ね
sobelでエッジだしたあとに利用するときそのままじゃじゃまな要素が多いから
閾値で切り落としたりするときに消える

>>569
うまいこと白地に変換するのってどうやるんでしょうか？
スキャナとかにもよくある機能ですが。

まず背景色をこれ。と決めるんだろうけど、それを決めるのも
単純な方法だとうまくいかない場合がありそう。
ただ一番白に近いのを背景色とするとか（ＣＤケースの光の反射部分が一番白くなる）、
枠内の白に近い色の平均値を背景色とするとか（白に近いってなんぞや）。
けっこうめんどくさいのかなやっぱり。

>>570
255*1 + 255*2 + 255*1 / 4 = 255 じゃね？

>>571
四角で整形したあとに原色処理で色をグルーピングする

>>572
sobelを基本から勉強しる

>>571
そこのサイトの場合は、白い背景限定みたいだから
そこからホワイトバランスを調節しているだけかと。

意外と皆、基礎がわかってないんだねw

>>575
そういう基礎を復習したいのですがオススメの本ないですか？

海外ならRosenfeld本、日本ならあぐい本あたり？

ホワイトバランスかけてアフィン変換だろ？

>>577
ありがとうございました
検索してみます。

ウィナーフィルタがさっぱりわからんぽん(´Д｀;)

>>580
http://www.kougendo.co.jp/newsite/img/wintergift/sousage-image.jpg

論文になってるアルゴリズムを自分で実装した場合は特許とか著作権の問題はないと思っていい？

著作権は大体大丈夫だが特許はダメ

最近は、論文として発表する前に予め特許申請する場合が多いらしいよね

特許法には、
第29条　産業上利用することができる発明をした者は、次に掲げる発
明を除き、その発明について特許を受けることができる。(以下略)

第30条　特許を受ける権利を有する者が試験を行い、刊行物に発表し、
電気通信回線を通じて発表し、又は特許庁長官が指定する学術団体が
開催する研究集会において文書をもつて発表することにより、第29条
第１項各号の一に該当するに至つた発明は、その該当するに至つた日
から６月以内にその者がした特許出願に係る発明についての同条第１
項及び第２項の規定の適用については、同条第１項各号の一に該当す
るに至らなかつたものとみなす。

という罠もあるしな

つまり発表後６ヶ月以内に特許出願しなかったら特許は取れないということ？

画像処理初めてで色を取得して一番多い色を表示するってのを作りたいんだけど、
色の取得はGetPixelとかWinAPI使わないとできないの？

>>587
どこの画像を調べようとしてるのか知らんけど

画像ファイルから計算すれば、
GDI周りのAPIは関係ないんじゃね？

>>587
初めてならGetPixelでいいんじゃない？
画像の読み込みも表示もそのままできるし。

ただ、ピクセル毎にGetPixelを呼んでいたら遅くなるので、
普通は配列に画像を入れて直接アクセスする。
処理が終わってから、配列からBITMAPを作って表示。

ちなみに、一番多い色を調べるというのはやることが単純な
わりには面倒な問題。
24bitカラーは1677万色あるので、全ての色に対してカウンタを
DWORDで用意すると、それだけで64MBもメモリを食ってしまう。
まぁ、いまどきのPCなら64MBくらい平気で使えるが…

カラー画像をモノクロに変換する…という処理の方がもっと簡単で
画像処理らしくていいと思う。

>>589
いや、普通はDIBSectionだろ。
GDI経由でいじることもポインタ経由で配列のようにいじるのも自由自在。
ついでにDIBSection相手ならDDBに比べればGetPixel/SetPixelも遅くない。

まー、今からならGDI+とかすすめとくが。画像ファイルのI/O圧倒的に楽だし。

なんで高が画像処理でOS依存し捲くりのプログラムを作ろうとするかね。
適当なライブラリさえ用意すればOSに殆ど依存しないで書けるだろうに。
つーことで、画像フォーマットはテキストエディタでも確認可能なpnm(Ascii)お勧め。

>589
いや、画素数以上はいらんだろ＞カウンタ数
多少時間がかかってもいいなら、連想記憶配列でいいんじゃね？楽で。

>>588-589
言語だけでできるのか。
なんとなく配列とかそこら辺までは分かるけど、画像って当然ヘッダー部があるよね？
fopen()でファイルの先頭から配列に詰め込んでいったら色と関係ないものまで入ってきそう。
jpg,png,bmpとかヘッダーの形式全然違うよね？

>GDI+
分からんです･･･

>カラー画像をモノクロに変換する
そうだね、最初はその辺を目指してみる。
高度な画像処理でいきなり潰れても困るし。

>>593
文盲ですか?

＞適当なライブラリさえ用意すればOSに殆ど依存しないで
＞画像フォーマットはテキストエディタでも確認可能なpnm(Ascii)お勧め

>>594 ごめん

>ライブラリ
探してみたけど、なかなかよさそうなのが無くて。
jpgやpng読み込みに対応してるフリーなのをひとつ見つけたけど、
内部でWinAPI使ってたんでOSに依存するんじゃないかな･･と。

>pnm
jpgやpng等の画像に対して処理をしたいので、他形式だときついです
pnm形式への変換にも時間かかりそうだし

何バイトから何バイトまで○○情報、とかヘッダ部の記述が分かればなんとか書けそうなんだけど、
検索してもなぜかrawとかbmpばかりで他フォーマットを解説してるサイトが見つからない

jpgやpngの読込なんて、下手な画像処理より難易度高いと思うんだがｗ

>>595
jpgやpngを読み込みたいという目的があるならそれを先に書け。
純粋に画像処理を試したいという目的だと思ったからpnmを勧めたんだ。
ライブラリがないというが、ImageMagickならOSに依存せずにどちらも問題なく読めるぞ。
勿論、本家libjpegやlibpngを使ったってどってことはない。

一応書いておくが、ヘッダ部とデータ部を判別できたとしても、pngとjpegは全く違う
圧縮アルゴリズムで圧縮されているのでライブラリなしじゃ到底無理だぞ。

色数とるだけなら、JpegやPngもBmpに直してそっから取りゃいいだろ

jpgやpngを読み込み、処理し、出力するプログラム
をライブラリやapi無しで書ける人はここに一体何人いるのだろうか、、、。

なんだこの48kHz。

>>596-598
そうでしたか、すまん。
レスを見るとどうやら俺はもっと根本的なところからやった方がよさそうだ。
今まで何するにもライブラリを避けて通ってきたから画像処理も言語だけでできると思ってたけど、
今回はゲーム用ライブラリを使わないとかそういうレベルじゃないみたいだな･･
貰ったレスを頭の端に置きつつ画像処理本でも買ってまともな発言できるくらいまで少し本格的に勉強してみる
色々とありがとう

画像処理が盛んな国内企業ってどこがありますか
東芝とか？

NHK

>>602
ソフト・オン・デマンド
北都

ソフトオンデマンドのデジモってレベルセットかな

画像処理は基本的に広告関係だろ
Photoshop使ってポチポチやってるだけだけどｗ

それは、このスレで言う画像処理には含まれないだろ

上で出てたので気になったんだけど
画像処理用のライブラリでお勧めってどんなのがある？

ほとんどImageMagickしか使ったこと無いな。

>>608
ImageMagickでいいじゃん。
libpngとかlibtiffなんかの本家のライブラリは結構めんどいよ。

読み込みとか保存操作やビット操作のオーバーヘッドを簡略化したいのならwxWidgetsがお勧め

このスレで書いてる人達はカメラを使う場合、IEEE接続とUSB2.0接続のどっち使ってます？
画像処理を専門にする人達にはどっちの方が主流なんですかねぇ？

( ﾟдﾟ)ﾎﾟｶｰﾝ

IEEE1394とCameraLinkは使ったことあるよ。あとNTSC, RS-170ね
1394はCPU負荷高くなるんだけどカメラのシャッタースピードや
ゲインを1394を使って変更できるので楽と言えば楽。
でも、ﾌﾚｰﾑｸﾞﾗﾊﾞと画像処理は近いけど違うって言えば違う分野

susie-pluginを使ってjpegやpngを読んで、DIBから配列に入れなおしたりしたっけ
Y = 0.299R + 0.587G + 0.114B がモノクロ変換の計算式な

それモノクロじゃなくてグレースケールなｗ
ところで指定した複数の点を通る曲線を描く計算式探してるんだけど
カーティナルスプラインってGDI+のAPIまでは見つかったんだがそれで検索しても
計算式が見つからない
もしかして正式名称が別にあるのか？

と書いたら見つかった

PDFから画像への変換にghostscript使ってるんだが遅い
良いライブラリとか回避策ないの？

回避策としては、
AdobeReaderから、画像ファイルを吐くプリンタに印刷するとか

画像処理じゃねーな・・・スマソｗ

>>617
http://poppler.freedesktop.org/
だけど、これを使っているevinceは重いので、
速いかどうかは、、、

ものには限度があることを知るべき

>>618-620
ｻﾝｸｽ

Acrobat買ってAdobeが公開しているAPI使って変換するのが
真っ当なやりかただとおもう。

.NetのDrawing2D.Matrixというクラスがあって名前のとおりただのベタな２次元配列なわけだけど
こいつのRotateメソッドがむちゃくちゃ早い
この速さを.Net使わずに実現したいんだが中身がなにやってるのか調べ方がわからない
誰かその辺詳しい人いませんかね
DirectXにそんなベタデータを汎用的な環境でアクセラレートする機能はなかったと思うんだけど
MMXであそこまで早くなるもん？
どれくらい早いかはPaint.Netっていうフリーのソース付のペイントソフトがあるので回転ツールで
けっこう大き目の画像をぐるぐる回してみればわかる

回転でそんな驚くようなアルゴリズムはありえないだろ
普通にソース側の座標をＤＤＡで計算してるだけだと思うけどなあ

>>623の書くコードが糞なだけだろ。

おれも回転のアルゴリズムはバリエーションしらんが・・・

>>624-626
騙されるな、>623は「早い」としか言及していないぞ。
きっと、速度が速いのではなく手っ取り早いとでも言いたいのじゃないか?

>>624
>>625
実際にスピード見てみたか？
DirectXでっポリゴンまわすのとスピードが変わらんよ
知ってる限りＭＭＸ使った９０度回転ですらこれより遅い
もちろんペイントソフトでレイヤーがある上に覆い焼きとか特殊なブレンドがあるから
DirectXでないのはたしかだが

>>628　GPUよりCPUの方が速いんだから、まともに書けばDirectXより速くてあたりまえだろ
この処理の殆どはメモリアクセスにかかる時間だから
90度回転より遅くなるのは描画側の領域が大きくなるせいってだけ

回転である事のメモリアクセス以外の負荷はＤＤＡを使えば殆どメモリアクセスに隠れてしまう

さっきからＤＤＡと言ってるが検索しても出てこない用語ですｗ

>>GPUよりCPUの方が速いんだから
さすがにそれはないだろｗ

GPUがCPUに対して演算性能が高いというのは、その高い並列処理能力でカバーしてるからの話。
その演算性能というのも、浮動小数点演算でそれもせいぜい32bit(24bit)

回転しながらフィルターをかけるような演算を含まない、単純な回転はメモリー転送速度の速さだけが限界を決める

>>630
デジタル微分解析　を足したらでるんじゃない？
基本的に回転は直線の描画と同じだよ。

どうでもいいから俺に7800GTXよこせ

いまさら、7800なんて・・・

この野郎俺が少し遠慮したのが分からんのか

回転って、srcをスキャンするのとdstをスキャンするのとどっちが速度が上がるんだろ？

( ﾟдﾟ)ﾎﾟｶｰﾝ

ループ内は
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++の部分、条件代入を使って

（省略されました続きを読むにはここをクリックしてください)
　　　　　　　　　　　　　　　　　　 　￣￣

ワッフルワッフル！

>>639
おもしれえ変数名のつけ方だな
sum__cとsum_cはどう意味が違うんだ？

ためしにPaint.Netっての落としてみたけど、特別速いとも思わないが…
[Layers]-[Rotate / Zoom]でグリグリ回してみたが、これじゃなくて？

描画の途中でも角度が更新されると途中で打ち切って新しい角度で
描画を再スタートするから反応はいいけどね。

しかし、この[Rotate / Zoom]のインターフェースはいいね。使いやすい。
最近のレタッチソフト全然使ってないけど、みんなこんな感じなの？

>>642
俺はsum__sとsum_yの関係が気になった。

慌てて書いて編集途中で投稿したんだろ
if(sum_c += c >= LIM ){ x++ ; sum_c -= LIM;}
if(sum_s += s >= LIM ){ y++ ; sum_s -= LIM;}

オレの場合は回転する画像は拡大された画像（回転後に綺麗に見えるように）だから
固定小数点だと　少し厄介なんだよな

SSEならx,yに変移を一度に加算出来る。
それをCVTPS2PI　でPMADD　で一気にアドレスが求まるなら・・・・・・いいんだけどなあ

>>643
なぜかそれ遅い
ツールに黒い矢印があるでしょ、それで右ドラッグで回転できるんだがこれが描画打ち切ってる
とかの次元じゃなくシームレスに回転しやがります
この速度は老舗のPhotoShopよりも早い
そっちで見てみて
ちなみのこのソフトはＭＳ社員がプライベートで作ったものらしい

>>647
そっちも試してみたが、こっちは操作中はポイントサンプリングだし
こんなもんだろう。C言語だけで書いてもこの程度は出る。

>>648
最大画面でサンプリングが１００％の状態で画面いっぱいの領域をまわしてみ

つまり、操作中は、皆が書いてる方法で高速に描画しておいて
操作が止まった途端にフィルタをかけた精密な方法で描画しなおしているという事だよ

>>623
まあどうでもいいことだが、GDI+使えば同じことできるし、生で叩ける分.NETより速いぞ多分。

>>650
そんなことはしてない

>>652
？　□を画面に描いて、それを回転させて、マウス（右でも左でも）を押し続けてごらん

フィルタってアンチエイリアスのことか
ためしに上に半透明レイヤーでもかぶせればわかるが
回転中もブレンド計算されてるからね
うちの画面サイズだと1000x1000が表示できるんだが
ぐりぐり回りますよ
このサイズをいくら単純なアルゴリズムでやったってマウスに連動して回転させるなんて
私はそんなアルゴリズム知らない

だから >>639の書いてるようなスタイルで実際に書いてごらんよ。　そしたら判るでしょ

>>654
知らないから聞いてるのは判ってるし、みんなが答えてくれてるのに
どうして教えてくれてる人のレスを全部無視して、凄い凄いばかり言うわけ？

こういう処理はメモリへのアクセスがネックになるから
アンチエイリアスをかけない回転は　LD+ST のコストだけど
ブレンド処理は　LD+LD+STとなって、回転より重い。
実際、上にレイヤーを追加すると途端に回転も重くなるでしょ？

で、アンチエイリアスをかけると、途端に回転処理はアドレス計算と重み計算のコストが増大して重くなる

もう馬鹿はスルー汁。
こんな奴は初心者でも何でもない。

やってみたけど別に早くない

>>658
どんなコードを書いたの？　一番内側のループを晒してみて

if( x1 >= 0 && x1 < SrcWidth && y1 >= 0 && y1 < SrcHeight ) {
dst[x2 + y2*DstWidth]=src[x1+y1*SrcWidth];
}else{
dst[x2 + y2*DstWidth]]=0;
}

>>660
１、条件文を外に追い出したら多少速くなるよ
２、掛算の部分は y2への加算に置き換えるべきだよ
３、dstはポインタにして >>639のように連続して処理すると少し早くなるよ
４、ところで、それ回転じゃないよね？

回転後の収まるべき画像サイズを計算して配列を容易してその座標空間において
y2,x2のループが外側にあります
y2ループでスキャンすべきソースの原点を計算します
x2ループはX,Yのそれぞれの増分を原点に加算するだけ
現在参照すべきソース座標がx1,y1に入っております

条件文は外にはだせません
y2置き換えても対して早くないです
dstポインタにしましたが遅いです
回転です

一番簡単な回転のアルゴリズム（アンチエイリアスをしない場合）

まず、方眼紙を用意してね。

方眼紙の1cmの目が1ドットとするよ。
2枚の方眼紙を重ねて、上の紙の5mmの中心の部分のドットの色をそのまま採用するという方法でのアルゴリズムを考えるよ。

判りやすくする為に、 x,yを浮動小数点としよう 1cm単位に表現するよ
回転変換 x' := c*x+s*y +x0 y' :=-s*x+c*y +y0
まず、下の紙の描画領域が　ピッタリ収まるサイズを求める

で SrcWidth SrcHeight から、 DstWidth SrcWidth を求めたら

次に、どの点で下の矩形が上の矩形と接するかを求める
左右の壁と接する点までのＹ座標２つによって３つに別ける

ここまでいい？

それぞれ計算式をたててみて・・・というか計算出来るものとしてすすめるよ

x,y を浮動少数と言ったのは説明のためで、実装では固定少数（かＤＤＡ）を使うよ

で、符号と、>>664の左右のどちらが先に来るかでによって８つに別けよう
時計回りに最初の手続きは　右側が先に来る。
　この手続きの最初のループはその右側と接触するy座標までだ。
　次のループは左の接点まで、
　最後のループは終点までだ

x座標の範囲は、この間、下の方眼の輪郭が、上の5mmと交わる座標となる
その座標は一番上で始点、終点を調整すれば足し算だけで計算出来るね？

一番内側のループは、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のように累計レジスタを用意して小数点以下が溢れると整数部を増やす仕掛けで実現する

　固定小数点だと最大サイズか、細かさのどちらかを犠牲にしなければいけない

と説明書いてたけど、コード書いた方が速いなあ・・・・でも書いたら負けかな

>>1をちゃんと読んでないだけで負け

十分的が外れてる件についてｗ

>>660
具体的に、一番内側のループが
{
*dst ++ = src[ (x1>>16) + ay1 ];
x1 += c;
y1 += s;
if(y1>0x10000){ ay1+=SrcWidth ; y1-=0x10000;}
}
てな感じになれば早くなるよ
さらに早くしたいならif 文は アセンブラで 16bit加算で CF を見て CMOV　して加算

ボトルネックは本当にそこなのかと問い詰めたい

少なくとも>>660のコードのボトルネックは
【条件分岐がループに入っている】事だよ。　しかも４つも。

さらに掛け算が入ってる事も影響するし
>>660には書かれていないが、x1,y1の更新も何か変なこと（例えばテーブルを引くとか）をしてるのではないかと想像

P6に限ればこんな条件の分岐が4つ+ループの分岐くらい問題にならない。
他のボトルネックが埋まってから初めて考えればいい。

671に同意でこのループだけででタイム計ったら実は全体の何割も無いのではないか?

残念だけど、ループも分岐なので、分岐が５つとなり、ＢＴＢが１個不足する

ループの分岐は逆流なのでテーブルは消費するものの、実質必要ない。
内側も660は真をメインにしているので、テーブルは実質必要ない。

つまり、分岐にかかるのは条件を判定するコストのみ。
このコストも、どう考えても「遅い」と嘆くような量じゃない。
だから他の要因を先に潰すべき。

繰り返しになるがCで書いているならループにかかるタイムは問題じゃないと思う。

てかよーーーーーーーーく考えろよ

1000x10000がマウスに連動して回るということは
単純に1000x1000をループでコピーするだけで出来ると思ってるのか？
実際は描画にかかるコストも入ってくるし何倍も付加がかかるぞ
1000x1000を普通にbitbltしてどれくらいのfpsが出ると思ってるんだ？

>675
そんなＣＰＵの分岐予測なんて問題を取り扱う以前に、
上の方で誰かが書いているが、座標で取り扱わずポインタにしなさい。
それだけで、相当速くなるから。
おそらく、アフィン変換をやるときに、転送先座標、x2, y2 から逆関数で、x1, y1 を
見つけて、そのデータがあれば、x2, y2 に代入、なければ ０を代入している部分だと
思うが、アドレスにするだけで同じアルゴリズムでもクリッピングに必要な条件判定が
２個で済むし、そもそも配列のアドレス計算が不要になる。
y2*DstWidthやy1*SrcWidthなんて、このループ内では定数なんだから、単純に、
*dest++ = *src;
となって、圧倒的に速いと思うよ。まあ、がんがれ。

もうしょうがない。 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とするよ

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;

■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番目のループここまで

■３番目のループは元絵　底から右側面にかけてのスキャン

もう殆ど同じだから判るよね？　

判らないならここまでを動かしてみて、考えてみればいい。

他の角度についても同じ。　とりあえず動かしてみながら修正すればいい

trunc は切捨て関数
round は丸め
ＳＨＲ　は >> と同じで右シフト

inc(dp) は dp++

>>677 分岐なんて問題じゃないから取り扱うなと主張してるんだよorz
>>678 コードを晒したので負け組

>>683
画像処理のように繰り返し数が多い場合、
一番内側のループでの分岐は問題だよ。
たとえ予測が働いても分岐1個でレイテンシ１が追加されるんだから
整数命令何個分にもなる

だいたい else を実行する時はアドレス計算が必要ないのに、毎回計算されているのも問題

>>678-681の方法は　この条件判断を外に追い出したもの。
その為に、4*2+2=10個の手続きを作る必要がある。

>>680　ちょっとコメント間違い

　 for x:=trunc(xL) to trunc(xR)-1 do begin　//違うのはここ

とあるけど、ここも同じ

もう２箇所間違ってた
×　xR :=xL+ src.Width *rc;
×　xR :=xL + src.Width / rc

○　xR :=xL+ src.Width / c;

言い訳・・・・除算は少しだけ遅いから 予め逆数を作って試してたんで

if文は、for文の外に出して関数ポインタを使おうね、ってことだね

関数ポインタも間接的な分岐扱いだろ

内側のループで分岐させずに、分岐した後でループしろってことだろ

関数ポインタも理解できない奴がいるとは。。

つまり >>679-680の　1番目と2番目の違いは1行だけだから
これを関数ポインタにしてコールバックさせようという事？

>683
スマンリンク間違い >672-673 が正解。

>684
683が言いたいのは、分岐よりも配列のアドレス計算の方がボトルネックに
なってんじゃねーのという事だと思われ。
ただ、>672-673 のやりとりが誤解を死ぬほど招きそうな言い回しなので、
分岐なんかたいしたことない、ばかりが強調されている。

もちろん最適化するときは、もっとも内側のループから、キャッシュをはみ出さない
範囲で外側に処理を移すことは当たり前の手法なので、普通のプログラマなら
みんなやっているし理解していると思いたい。

ここまでの流れを整理しましょう

まず、.NetのMatrix.Rotateは尋常じゃなく早いDirectXを使わずにここまでできるのか？
これが質問です。

回答者Ａ：お前のソースが遅いだけだろ、俺様のスマートな方法でやれ
これに対して私は、回転を高速化しても描画も含む速度において.Netのスピードは達成できませんでした
と解答しました

回答者Ｂ：いやＡの方法よりこっちのほうがはやいぜーー
これに対して私は目下閉口中ｗ

回答者Ｃ：いや別のボトルネックがあるだけだろ
これに対して私は最初からそういってるので目下閉口中ｗ

そろそろまともな会話しませんか？ｗ

スレ違い、と思う。

都合が悪くなるとすぐそれだ

> 回転を高速化しても描画も含む速度において.Netのスピードは達成できませんでしたと解答しました

ポインタにしても遅かったって言ってるだけだろ。
自主的には一度もループの話をしていないが、
ポインタを使っても遅いというのに描画のタイムが入っているというのは主観だ。

それにボトルネックが他にあると最初から言っているんだろ(どこで)
タイム取って分かったボトルネックを議題にするだけじゃないか。


固定値α付きで実際にやってみたが、
予想通り分岐入れっぱなし、添え字の計算しっぱなし、浮動小数点使いまくりの
糞コード書いてもPaint.NETと同等以上。

出来ないなら素直にMatrix.Rotateつかっとけ。

釣りというより池沼としか思えん。

基地外は放置しろって。

ーーーーRotateはここで終わりーーーー

終わった話題でしかも長文書くのでｽﾏｿ

>>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とか使ってくれれば良いのに。。

画像の回転処理だと、
http://anton.treskunov.net/Software/doc/fast_and_high_quality_true_color_bitmap_rotation_function.html
のが速そうだけど実際にベンチは取ってない。shear処理を繰り返す方法が何故通常の方法より速度が出るのかは
良く分かってないでつ。

shear処理って何？

─┌───────┐─
││ 　 　 　／＼ 　　 ││ 外側のループを３つにわける
││ 　xL／----＼xR│↓
↓│ 　／ 　 　　　 ＼│RY　1番目　RYまで
LY│／ 　 　 　 　　 ／│　　　2番目　ＲＹ〜LYまで
　 │＼ 　 　　 　 ／ 　│　　　３番目　ＬＹ〜縦幅
　 │　 ＼ 　　 ／ 　　 │
　 │ 　　＼／ 　 　 　│
　 └───────┘
　　→内側のループのスキャン方向　

　　0〜xLまでは余白
　　xL〜xRまでは回転処理
　　xR〜横幅まで余白

＞これに対して私は、回転を高速化しても描画も含む速度において.Netのスピードは達成できませんでした

RDTSC（面倒ならQueryPerformanceCounter）で
１　回転処理　bitmap作成を含む全部の処理
２　描画時間　windowsAPIの実行時間

を調べて比率を見てごらんよ。

今簡単に書いてみたけど　ほぼ同じ程度のコストだよ

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で解説してたのもどっかにあったけど忘れますた。

>>701
graphics gems１巻

けど、shearing３回で回転する方式って本当に速い？
解説読んだけど、結構計算量も多そうで、いまいち試す気が起こらない

Paint.netで、画像範囲選択してツールの右矢印選んで、右ドラッグで回転させてみたけど、
リアルタイムの処理はサンプリング点が１つだけの処理っぽい汚さだから別にこれくらいの
速度は普通に出せるね。（まぁさんざん既出ですが…）

>> 705
週末にベンチ取ってみる。

623は多分Matrix.Rotateの速度を計って勘違いしてるんだと思う。Paint.Netは
画像処理にはGDI+使ってるにすぎない、OOPでうまく纏めて作ったソフトでしか
ないのに、思い込んでしまってる623には周りの指摘が通じない。

>>706
PentiumM 系列のCPUは、コード実行中のメモリアクセスパターンについて
なんと12個ものシーケンスを検出して「この先この辺読むかな」と予測して
自動的にプリフェッチしてくれる。

大きなメモリを扱う画像処理などではプリフェッチの効果は絶大なので、
昔のベクトル演算の様にこういうコードの質を判断するのは結構難しい。

>>704-705 ありがとう。
斜めに変形を繰り返せば結果として回転するって事か
でもデータの移動がそれだけ増えるんだから、今の
メモリアクセス＜ＣＰＵ速度なパソコンでは速いとは思えないな

回転元の画像がキャッシュに収まるならプリフェッチ云々は意味がないし
キャッシュに入らないような大きな画像を扱う場合は、
プリフェッチが入る時間が取れないから無意味だろうし

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

ここまでの流れを整理しましょう

まず、.NetのMatrix.Rotateは尋常じゃなく早いDirectXを使わずにここまでできるのか？
これが質問です。

回答者Ａ：お前のソースが遅いだけだろ、俺様のスマートな方法でやれ
質問者：試した試したと言いながら、まったく理解せず


回答者Ｂ：そもそも 速いと言ってる Paint.NETの回転はちっとも速くないぞ。オレのコードが早い。
質問者：全く理解せず。　こんな速いアルゴリズムを知らないという。

回答者一同：アングリ。　知らないっていうからこんだけ教えてやってるのに、何言ってやがんだ


質問者：別のボトルネックがあるんではないか？
回答者：だから、回転の負荷なんて、単なるメモリコピーとそう変らんから、妄想は止めろ

そもそも　.NetのDrawing2D.Matrixというクラスはベタな２次元配列ではないぞ


そろそろまともな会話しませんか？ｗ

>>711
そんなことしたら、src>dstなんだから、メモリアクセスエラー出るだけだろ

まあ、この程度の負荷ならせいぜい違っても倍
ループ中にAPIコールでも入れてなければ大騒ぎするほど大差はないだろ

OPENGLが頭を過ぎりました

Glideが頭を掠めました

滑空だけにか

しかしPaint.NETは良く出来てるなあ
荒い表示とアンチエイリアス後がピタリと一致しやがる

アンチエイリアスもなかなかの性能だ。
このアンチエイリアスのアルゴリズムの方が知りたいなあ

作者乙

ﾌﾟｯ

>712
まず、.NetのMatrix.Rotateは尋常じゃなく早いDirectXを使わずにここまでできるのか？
これが質問です。

回答：できます。

――　完　――

>>711
if文を入れた場合と単純コピーを比較しても速度はほとんど変わらない

単純に考えすぎでは？Paint.Netで行われるトータルコストを考えると
まず背景はタイル画像がある
その上に切り抜かれた背景がある
切り取った回転画像がある
合計３枚の画像になるわけだ
これらを合成し３枚目は回転した状態で合成する
そして描画時に一定の拡大率で画像を拡大縮小して描画する

中間層を回転するならな。

下のタイルは >>702のように場合別けしてれば負荷にはならない
上にかぶせれば、透過処理は回転より負荷が大きいから実際に重くなるだろ

>>721

うん単純メモリーコピーはソースがキャッシュに入ってるなら
20〜30サイクル/1ワード程度だと思う
この間に全部の処理が入ってほかにRAMをアクセスしないなら全部隠れてしまう。
もっとも予測分岐が一つ外れると、20サイクルくらいのペナルティは支払う事になるから
分岐は無い方がいいね

でもまあ >>711のように多数の変数がループ内にあるとメモリアクセスが余分に生じて
この速度は出ないと思うけどね

とりあえず、遅いとか速いとかじゃ判らないよ。
RDTSC使って、1ピクセルあたりどれくらいのクロックなのか書いてくれ


BCB
__int64 RDTSC(void){
__asm DW 0x310F
}

MSC
__int64 RDTSC(void){
__asm RDTSC;
}


Delphi

function RDTSC: int64;
asm
DW $310F
end;

帰り値が無いという警告は無視

アセンブラで一番内側のループを書いてみた。
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;

呼び出し方は
　 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割程度の改善にしかならなかった

HSVについてなんですが、H:0.0%, S:100%, V:99%だと、ほとんど青の原色になりますよね。
しかしペインターのHSVだと、同じ物がほぼ白色になるみたいです。
ペインターのHSVは少し特殊なんでしょうか。もしそうでしたら、計算式のヒントなど頂けないでしょうか。

>>729
おまいさんは、何か勘違いをしている

ttp://tomato.sakura.ne.jp/~hiropon/lecture/color.html

失礼、青と書きましたが、これは赤の間違いです

>>730
申し訳ない、何度も読んでも分かりません・・・・
その図を見てもやはり、S:100%, V:99%なら最も鮮やかで明るい色にこそなれ、
ペインターの様に白にはならないですよね

PainterはHSVって表示しているが、実はそれは一般的に言うHLSで、
しかもH=0がBlueでB-R-Gの順に回転するのだ。

PhotoshopだとHSBと表示しているが、これも中身はHLSだ。

>>732
なるほど！いやはやHSVの所ばかり見てました、すいません。
回答ありがとうございました。

低レベル且つ微妙にスレ違いな質問。

Cでbitmapを読み込む定石ってないの？
標準ライブラリ+APIで。
(画像処理しようにも出来ないよ〜。)

Win32APIならLoadImage()にLR_CREATEDIBSECTIONつけて返ってきたハンドルにGetObjectしてポインタ拾う

>>673
どうもありがとうございます。
なんとかヤれそうです。

>>734
>>735の方法で読みこみはできるが、bitmap(WindowsDIBだと思うが)の読み込みコードもかけないのならば
その後もできないと思う
8、24bitのみ、OS2フォーマット除外ならベタで書いてもたいしたことない
TIFFに比べれば自由度がない分簡単

訂正
○734
×637

またしくじった…。

訂正
○735
×673

携帯で書いたのでｽﾏｿ。

>>737さんもありがとうございます。

ペンタブレットの筆圧ってどうやったらとれます？
Windowsで

>>741
スレ違いだ。
ぐぐれ、wintab

>>737
へーきへーき。DIBの読み込みなんか自力で書けなくても
画像処理は書けるよ。他人の作ったフォーマットにあわせて
コード書くのはなんかまた違うんだよね、プログラムのカテ
ゴリとして。

Delphiプログラマの漏れなんか、
DIBなんか全然知らないが画像処理は書けるしな。

ふーん

へー

まいやはっはー

まいあふー

まいアホー

あのー
画像エフェクトって言えばいいのか、そういったもののアルゴリズムが
辞典的に乗っている書籍とかありますか？
あるなら、おしえてケロ。

ケロケロ。

ゲーロ　ゲロゲロ　ゲロ　ゲーロ！

どんぐりガエル

ttp://www.amazon.com/gp/product/0201180758 かな。
まだ ttp://www.amazon.com/gp/product/013168728X は出版されてないんだね。

どっかに画像をパステル調に変換するソースないですか？
こんなふうに

ttp://www.tomonori.com/program/sharaku/images/sketch/Pastel.jpg

それをパステル調と言い張っていいのなら、斜め方向にランダムに暈しているだけじゃないか?

ケロケロ。

暈すというより延ばしてるね
単純減色してから角度にばらつきを持たせて延ばしてる感じ

>>755
ttp://www.tomonori.com/program/sharaku/sketch.html
＞パステルは全く違うアルゴリズムで、昔作って公開した印象派倶楽部と同じ原理です。
＞ぼかした上に、さらにノイズ乗せてますので画像としては思い切りつぶれていますが。

オリジナル画像もあるんだから、差分取れば何やっているのかほぼ分かるね。

馬鹿な意見ばっかりでかわいそうなので、天才の俺様が教えてあげよう
と思ったが
それＳＨＡＲＡＫＵのサンプルだろ
勝手にリンクしてんじゃねーよ、ついでに言えばパクろうとしてんじゃねーよ
それ同等のものは一般的にはないある共通の手法というものがあるが
教えたくなくなったｗ

>>760
日本語の勉強をし直すことをお勧めしておきます。

＞勝手にリンクしてんじゃねーよ
なんで? リンクされたくないならそう断るべきでは?
#だからと言って、リンクしてはいけないと言う法もないが。

＞教えたくなくなった
知らないならわざわざ嘘吐いてまで書く必要はないし、
本当に知っていて教えたくなくなったのならやはり書く必要はないよ。

つーか、本人乙。

逆切れ妄想かよｗ

だって意味わからんのですよ
なにか加工したいものがあるなら素直にＳＨＡＲＡＫＵ使えばいいじゃない
勉強としてそういう加工まずは十分に勉強してるもんだろうし
いきなりパステル調なんてＳＨＡＲＡＫＵオリジナルの名称持ち出して
これやりたんだけどってどうよｗ
自分のソフトに組み込みたいとか考えてるんなら教えないよ
勉強目的で聞いてるんならいきなりパステル調なんて言い出さない程度まで勉強してからおいで

あーおもしれーｗｗ

本当にいるんだな、こういう奴。

＞パステル調なんてＳＨＡＲＡＫＵオリジナルの名称

最近レベルが落ちてきたな。
俺は何の貢献もしてないからでかいこといえないけど･･･

パステルパステルパステルパステルパステルパステルパステルパステル

>>767
前からこんなもんですが

レベルあげてーーーーーーーーーーーーーーーーーーーーーーーーー

まずお前がレベル上げろ

俺「はぁぁーーーーー！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！１」
息子「ぴゅぴゅぴゅっ！」

少し前の回転の高速化みたいな、低レベル談義の方が俺は好きだけどね。
レベル上げられても、専門化するばかりで興味ない分野には入れないし

プログラム板で高レベルな話ってのは、職業話をするって意味だからな

>>774
ム板は別にブルーカラーな話題だけじゃないよ。
コンピュータサイエンスの話題もぜんぜんOK。
アルゴリズムの理論的な話題もぜんぜんOK。

つまり実装から乖離する＝高レベルな話題になると、当然専門性が上がって参加者が減り、
それでも参加者が残るのが、職業話という事さ。

しょうがないので天才の俺様がネタ振りしてやる
http://www.art-science.org/journal/v1n3/artsci-v1n3p147a.pdf

で、回転ネタは、どう収束したんだ？

すいませーん。
Windowsでプログラムの勉強もかねてデジカメの画像をいじって遊んで
みたい、と思っているんですが、デジカメの中の画像をいじって遊ぶ
にはどうしたらよいんでしょうか？

とりあえず、jpgをBMPにしろ、話はそれからだ、とかどこかで読んだの
でBMPファイルにしたんですが、この先のお話聞かせてくださーい。

画像をいじれるようになったら、この間妹と温泉で撮った写真をいろい
ろいじって遊んでみようと思います。

>>779
まず、ぐぐる。
次に、ぐぐる。
ひたすら、ぐぐる。
最後に、ぐぐる。

これで出来る、

>>779
まずうｐしる。話はそれからだ。

>>781
そうだなｗ

>>779
ちなみに画像ソフトの話はスレ違い

>>782
自分で妹の写真をエフェクトしたいんだろ
俺は応援してるよ

pictbearあたりがいいんじゃまいか？

スレ的にはまずlibexifのインストールからかなあ。

>>777
こんなへぼいんじゃなくて
もっとちゃんとしたのを生成できる論文あるよ

たとえばこんなん
http://www.cs.rutgers.edu/~decarlo/readings/winkenbach-sg96.pdf

女性の研究者でカラー画像のやっている人がいたんだけど
名前忘れた

読めねーよ

おっかしいな
あれきれいだったんだけど

違うのしか見つけられない
http://citeseer.ist.psu.edu/444837.html
http://www.cs.mcgill.ca/~cs767/papers/winkenbach.pdf

siggraphだったかしらん？

エロ画像判定アルゴリズムってあります？

楽してエロ画像集めようなんてそうはいかないぜ！

>>790
違う、エロ画像を消すんだ！

エロ画像を定義でききるのか！
単に裸だけじゃないぞ、エロは。
チョコレートやホイップくり−ムで包まれていたりすんだぜ女の子が。

こんな感じか？
ttp://www.san-x.co.jp/newcha/new44.html

>> 793

ちがうやい。もっとべたべただよ。
ウエット＆メッシーで検索してくれくれ。
研究室に籠って画像処理に興じているとエロ＝裸となるのかな？

エロ話で盛り上がっている中、話に横槍を入れるのはあれですが、、、
質問が有ります。
fftによって画像処理をしたいのですが、縦横のピクセル値が２の冪であることが
望ましいと様々なところで語られていますが、画像はいつもそんなサイズでは有りません。
720x480のサイズの画像をfftによって処理する方法って有りますか？
あるなら方法だとか、そういった手法を教えて下さい。
書籍、サイトなど参照出来るものを教えてくれるとありがたいのですが。

http://www.google.co.jp/

>>795
窓関数

>>795
　サイズが２のベキでもピッタリのサイズでＦＦＴすれば右端と左端が接続されてるとして処理されてしまうわけで
　これが好ましいわけ？

　そうじゃないなら、単に空白を埋めたらいいだけでしょ？

　なお、２のべき乗でなくても、ＦＦＴは可能。　題名忘れたけど黄色い薄い本に詳細が書いてあるよ。

>>795
ヒント： FFTをやめてDFTを使う

>>795
http://www.fftw.org/
ここのライブラリを参考にしてみるんだ

>>795の言うように1024*512のとかで窓関数使うか、>>798のように基数2以外のFFTを使う方法しかしらんな〜

２のべき乗以外のＦＦＴは　混合基数 FFT 　Winograd　を検索キーワードにすれば出るだろう

cztなんてのもあるらしいよー
それを使うと窓サイズが素数でも2のべき乗オーダーでFFT
できるらしい

あう、間違えた
×2のべき乗オーダー
○2のべき乗のFFTと同じオーダー


ついでに、cztは Chirp-Z 変換の略です

http://www.smartread.biz/

スマートリーディング業務終了のお知らせ

m9(^Д^)ﾌﾟｷﾞｬｰ

世知辛い世の中ですな

天罰だろ

うわぁ・・・

アメリカではこういうことやってまさにこんな風に失敗したほうが経営者としては信用されるらしいね
同じ失敗をしないから
しかしここは日本

スマートリーディングは経営なんて言えるもんじゃなかったよ
持ち逃げして作っただけ
最低

>>803
それ何の略？

orzってのもあるな。

Professional Edition 買ったやつは、サポートも無くおっぽり出されて買い損？

>>810
ｋｗｓｋ

>>813
>>524

>>524は、予言者

というか、預言者か。

ただのinsider

もともとOCRの会社に勤めてた奴が独立したとかそんなんかね

ソースお持ち帰りで独立か

画像認識アルゴリズムを議論するスレはこちらでよろしかったですか？

ttp://www.vector.co.jp/soft/winnt/writing/se383682.html
記念ダウンロード

>>820
GJ!

3色パンみたいに3つの円がくっついた絵について、3つの円の重心を決める
（絵は2値として）
てのやりたいと思ったら、まずどうしたらいいでしょう？　
ﾋﾝﾄか参考資料教えていただけると嬉しいです。
画像処理はズブの素人です・・・・・

円の中心点３つの中心じゃないのか？

チョコレート、クリーム、あんこ
では、あんこ、が一番重いと思うな、僕は。
なので、あんこ側に有りますよ。
重心は。

すみません、やりたいのは「それぞれの重心を決める」です。
重なり具合は画像によっていろいろです。
2つとか4つのもあります。

あんこは単価が高いので、少ししか入ってないんじゃないでしょうか。

ようするに面か線かで複数の円があるんだよね？

面なら輪郭をとって、線にして、

交点が無い部分で最小２乗で中心と半径求めては
その円を消去してゆくという感じでどう？

二値なら黒の重心を求めるとすると、黒点の総数を数えておいて、ｘ方向で半分なるところ
とy方向で半分になるところが重心。この方法なら、図形の形に依存しない。

領域分割でポスト配置問題と言うのがある

重なって輪郭途切れてるなら一般化ハフ変換がピッタリじゃない？

ﾊﾌｯﾊﾌとか言うｺﾋﾟﾍﾟを思い出すなぁ

ﾊﾌｯﾊﾌ

そう考えるとﾊﾌﾏﾝって
うわっエロっ

Hough変換はハフ変換だったのか。
いままでずっとホウ変換って読んでたYO！

タフマン？

逆にするともっとｴﾛｲかも
ﾏﾝﾊﾌ・・・

皆どうもありがとうです。ぐだぐだやってみます。
一般化ハフ変換について詳しい本かサイトあったら教えてくださいまし。

ﾊﾌﾊﾌ

オレの提案はどうなんだよ
検索キーワード 最小２乗法による円弧推定

エロさが足りない

>>837　　ありがとうございます。もちろん挑戦するです。
「最小2乗で円」は「おお」っていうサイトありましたが、
「一般化ハフ変換」は、なんかようわからんかったのです。

ハフ変換は研究者のオナニーで役に立たないよ。
実用的な応用例を見たことがない。

正弦波を直線近似して高速化するやつと、GPUPUでやる奴を見てみたけど、
やっぱり遅いしね。っていうか前者、こんなので特許取っててうんざり。

4kデモでnoonのカールが12?バイトsinコードを書いてたよね

今は遅くて役に立たなくても、
将来ハードの性能が上がればウハウハよ。

JPEG圧縮でファイルサイズがMAXになる画像って一意に決まりますか？
決まるなら、まず画像を自作したいのですが・・・
圧縮方法次第なら、適当に大きくなりそうなサンプル写真拾います。

日本語でおｋ

>844
PIをJPEG圧縮するのはどうか？

ホワイトノイズでいいんじゃね？

>>844
１ドットごとの白黒のチェック模様って試したらどうかな？

ぱっと見スゲー苦手そうじゃね

ＪＰＥＧの画質に依存するのでは。
ジグザグスキャンで圧縮効率が悪くなりそうな配列だといいだろうな。
16x16ブロックで最大になるものを敷き詰めればよさそうだ。

jpegは広い周波数帯域を持つ画像に弱い
だから市松模様なんて簡単すぎる

ホワイトノイズだってば！

市松模様は（ベタ塗りの他では）最も圧縮される画像の一種かもね。

>>850
それも色相・彩度・明度の各チャンネルで独立したホワイトノイズだな。

量子化後の周波数領域において一様分布にしたがって値をとれば、
エントロピー最大⇒圧縮率最悪

どういう画像になるかは知らんが、
1. 乱数配列生成
2. 逆量子化
3. 逆DCT
とすれば求める画像が得られると思う

画像関係は専門じゃないので何かあれば補足よろ

JPEGの圧縮の貢献はジグザグスキャンの
8x8ブロック→64個のデータ列のハフマン符号化
で稼いでいるから、64個のデータ列で０が連続
しないような配列生成→2→3とすればいいと思う。

どんな圧縮でもエントロピーを超えられないから
zip最高圧縮で圧縮したデータを画像にすりゃいいんだよｗ
ホワイトノイズとも言うがｗ

実際には数理上のエントロピーは超えてるけどな
いったん圧縮されてエントロピーが確定したデータはそれ以上圧縮できない
このエントロピーをいかに下にもっていくかで圧縮性能が違ってくるだかなんだが
スレ違いですね

>856
いや、それ可逆の話なんじゃ・・・

圧縮できない最悪の状態を作るのは、単独・単純な手法だと良くやられてるんですが、
JPEGで同じようなテストデータを作るのは面白そう

おお、色々レスもらってた。
とりあえず、レスもらった奴を試してみます。

PNGのCRCをC/C++で計算するソースきぼんぬ

え、pngの仕様書の付録でコード書いてなかった？

マルチか

CRCって、PNGだと特別な計算方法になるのか？

>>844
みんなが言ってる様にホワイトノイズなんじゃないかな？一意には定まらないけど･･･。
MT法辺りの良質な乱数アルゴリズムで一様分布乱数作って正規乱数に変換すればいいよ。

ノイズをノイズとして認識してノイズとして合成できたらいいのにな
それは音声でも絶対役立つんだが

>>861
どこにあるの？

>>866 RFC

>>867
日本語訳のページが軒並み潰れててどうにもならない

ふーん。

>>865
MPEG4後継コーデックではすでにフィルムグレインの分離・合成は常識。

>>868
英語のページ見ればよい

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()を呼べばいいのかな？

>>872
crc()

ナルホド。でも戻り値がunsigned longになってるけど？CRCは4バイトだよね？

最近のVCだとlongもintも4バイト

そーす

ぐぐるなりMSDN見るなりしやがれ

>>868
ttp://www.archive.org/web/web.php

この辺に残ってそう

いわゆる歪みエフェクト(swirl、meshwarpなど)
のアルゴリズムというものは、自らが考えているの
でしょうか？あるいはそういった文献があるのでしょうか、
上にかいたswirl、meshwarpはソースがあったので
それを見て理解はできたのですが、
そういった歪みエフェクトのアルゴリズムが網羅されている
文献、あるいはサイトなどがあれば教えていただけると
幸いなのですが、、、よろしくお願いします。

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' の算出方法がわからんのです。
これの見た目も、上記のケースと同じ（もしくは同等）の結果になるはずなんだけど、
僕の頭では算出方法が導けません。

何も考えずに即レスするけど、
A3’ = 1 - (1-A1)*(1-A3)
R3' = 電車なくなるのであとで

この話題は３ヶ月ごとに現れるのはどうして？

自分を二人画像の中に違和感無く
いれるソフトってありますか？
合成処理のできるソフトならできるのでしょうか？
詳しい方よろしくおねがいします。

スレ違い

s/ソフト/アルゴリズム/g
これならすれ違いにならない(・∀・)
質問者の求める答えにもならないだろうけどw

>>883の要求レベルすごいな、、。