画像処理 その４

画像処理 その４

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

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

ほう、こんなスレがあったとは知らなかった

画像ラボって読んでる人いる?
技術系の雑誌だけどさ．有名なの？

>>3
こんなんあったんだ。早く教えてよ。
今月から読んでみよ。

どこで売ってるんだよ。

通販専用？

>>3
あれって半分はIEICEあたりの論文誌に載った画像関係の論文を，技術者向けに簡単な内容に書き換えて半年遅れくらい乗っけてるだけでしょ？
半分は広告だし。
俺も寄稿したことあるし(w

>>4
ちょっと探してみた。
発行元は日本工業出版、URLは　www.nikko-pb.co.jp　。
欲しい人たちは定期購読だね。

Haarのウェーブレットなんですが、長さが２の累乗でない場合はどうするのでしょうか。
FFTみたいに適当に埋めて長さを揃えていいんでしょうか。それとも他になにか
アルゴリズムがあるんでしょうか

>>9
一応コメントしておくと、FFTだってテキトーに埋めていいわけではない。
適当（適切）に埋めるのはOK。

>>10
はい、すみません。FFTでも端を折り返したり、0で埋めたりと、絶対的な方法が
無いようなので適当と言ってしまいました。すみません。

>>10
エッジを伸張すればいいのかな?

補完してあわせれば？

白黒二値画像を少ないパレットのグレースケールに縮小表示する処理を書いてます（プレビューとかに使う）
２〜３年前につたないコードで平均値を割り出して８パレットくらいに
納めるところまでは作ったのですが当時のCPUパワーと自分の技術の問題で
1/2〜6なんていう分母が増加する縮小率にしか対応できませんでした

二値データからの多色画像への高品質縮小を考えた時に何かいい文献
またはDLLみたいな外部ライブラリはあるでしょうか？コンパイラはBCBを使っています
（ImageKitは試してみましたがもう一つ品質に納得がいきませんでした）

あの当時からImagingForWindowsの表示速度にあこがれているんですが
どうやってあの速度を出しているのか・・・・いつかは理解してみたい；；

>>14
ローパスかけて縮小するんじゃダメ？遅いかもしれないけど。

何か市販のライブラリを使った場合だと
２値＞増色(グレスケ)＞ローパスフィルタ＞縮小
ってやるのが一般的なんでしょうか・・やはり

増色過程でメモりと時間を食うのがちょっと辛いところです；；

>>14
普通にCやC++で書いても、AcrobatやImaging程度の速度は出る。

素直に、縮小画像の各ピクセルに対応する元の２値画像の

矩形内のbit1の数/矩形の面積

をグレイスケールの輝度値にするだけでOK。もちろん、分母も分子もdouble値

大昔に整数型演算だけで無理やりやったこともあったが、今は変な工夫はしないで
浮動小数点演算も気にせず使っている。工夫しないといっても、コードチューニング
くらいはするけれど。縮小倍率は浮動小数点で任意倍率でもいいと思う。

Windows GDIのBitBltて結構綺麗に圧縮してくれると思うんだが、
ダメ？　素人なのですまんそ　あいここはプラットフォーム依存ではないね

>>17
やっぱりそのグレイスケールの輝度値への計算がたぶん下手なんですね・・・自分
元画像の指定範囲内のHighBitを馬鹿正直にカウントして
目的パレットテーブルの範囲にはめ込んでますから(´；ω；｀)
（一応横方向にはbyte単位でアクセスしてLowValueならスキップしてる）

この計算ロジックを旨く書き直したいのですが何か参考になる文献 or サイトはあるでしょうか？
>>18
カラー画像ならまだいいのですがモノクロ文章系だと品質に不満がありました

ブラーかけて縮小すると綺麗になる

17ですが一応。

速度を評価したマシンですが、PenIII 1GHzで、A3の文章系、全体表示でテスト。表示品質は見た目
同じ。正確に測るとImagingよりも遅いのかもしれないが、両方とも一瞬なので目測では速度の違いが
分からない。Acrobat 5.0よりは明らかに速い。

といった測定精度です。14が、ずっと遅いCPUでやっていたとしたら、14と違いは無いかもしれないの
でスマソ。

>>20
一種のローパスフィルタだよな

おいおまえら！カメラ買いましたですよ！

>>23
どんなカメラ？

バカチョンカメラ

そういえば、画像処理に適したカメラの要素と具体的な商品を教えてください

elecomのWEBカメラです！ 箱に仕様が細かく書いてあって好感が持てたです！

>>26
参考に汁
http://www.cat-e.be/member/index.php

くだらね

>>28
画像処理スレとサウンドプログラミングスレにだけはそんな人はいないと信じていたのに…
かなしいです…

っつーか、ム板にこんなもんに引っかかるやついるのか？
知識があるから、（ ´_ゝ`）ﾌｰﾝ で終わりだろ。

２値の白黒画像のなかに、白い点が点在しています。
その白い点を複数の矩形で出来るだけ小さい面積で囲いたいのですが、
どうやったら出来るでしょうか？
一番面積が小さい場合は１ｘ１矩形で白い点の数だけになる。
一番面積が大きいけど矩形が１つですむのは、
xmin,xmax,ymin,ymaxって変数用意して、
全部スキャンして１つの最小矩形は作れる。
そこから、どう２つ以上の矩形に分けたらいいのか、、、。
ヒストグラムとって、分割するとかかなぁ。

凹のへこみに小さい点があったりしたらどうすんの？

白い場所の固まりをまず識別して、それを囲う矩形をつくればいい。

白い場所をどうやって識別するかが難しいです。
とりあえず、２つで考えてるのだけど難しい。
白い場所の固まりをどうやったら識別できるんだろう？？？
固まり具合見るとか？わかんないです。
□
□□
はどうしたらいいんだか、、、。
□
と
□□
に分割したいけど、難しい。

電子消費者契約法違反
これで、ぐぐれ、馬鹿ｗ >>28

>>32
その質問だと、答えは自分で書いている通りに
「一番面積が小さい場合は１ｘ１矩形で白い点の数だけになる」で
おしまいだと思うが。何か質問の方を間違ってないか？

「白い点」の定義が無いから誰にも答えられないと思われ

矩形の大きさをある程度大きくしたいならラスタスキャンだな。

>>39
池沼

□
□と□
に分割したいけど、難しい。

面積が最小になるように覆い、かつその個数が最小になるような
複数の矩形を求めたいということなのだろうか・・・
後の方の条件は憶測だけど。

「N個の矩形で面積最小」という条件じゃないの？
N=1の時と、N>=点の個数のときは簡単だけど任意のNだと難しい。
矩形の重なりを許すかどうかでも変わってくるな。

穴の開いた島は分割する必要があるかどうかとかもな。

>>42

その条件(面積最小)ってことは、矩形に黒い点は含まれないから、
・すべての島について
・その島をちょうど覆う矩形の組み合わせで、個数が最小のものを探す
って問題になるね。

なんか、NP完全の匂いがする…

>>14
縮小する際には、拡大してから縮小するという方法もあるよ。

実際にメモリ上に拡大画像を展開するのではなく、ダウンサンプラから
アップサンプラを呼ぶのが普通。
縮小ならアップサンプラは零次ホールド、ダウンサンプラは平均操作が
変なノイズも発生しないし軽くていい。これだと>>17と全く同じ結果になる。

普段見てないスレなので遅くなってしまったが、処理方法の一例として。

Lennaみたいなかわいい標準画像とか版権フリーな画像もっとないですかねー・・・

>>47
現代版麗奈
http://www-2.cs.cmu.edu/~chuck/lennapg/lenna.shtml

>>47 JISの使ったら?

・線分の検出
・台形（遠近感を持つ長方形）の検出
をやりたいのですが、どうやったらいいか分かりません……
ハイコントラスト化してエッジを抽出する必要があるというのはわかったのですが……お願いします。

"Hough"とか"ハフ"でgoogle.

>>49 JISのはカワイイの？そもそもどこに落ちてるんだよう。

それと、昔、フジの深夜番組で今田、東野、板尾の
「棒々グラフ」というのがあったのだが
あれでよく使われていた標準画像っぽいやつはどこのやつか知ってるひといる？
（あべ静江みたいな女がカーネーションもってるやつ）

>>50
1)　エッジ抽出（環境に合わせて適当な方法）
2)　線分近似（Douglas-Peuckerアルゴリズム，hough変換など山ほどあるよ）
3)　4辺で構成されるポリゴンを選択

趣味でやってるならともかく，大学生やエンジニアだと君痛いね．
画像の単純な図形への近似って10年くらい前に終わったような研究だよ．

>>50
とりあえず「新編 画像解析ハンドブック」買ったら？
http://www.amazon.co.jp/exec/obidos/ASIN/4130611194/
去年改訂されたから内容もそんなに古くないと思う

しかし線分抽出だけとっても奥が深いというか万能薬がないのが画像処理

JISは俺もさがしたけどどこでダウンロードできるのかわかんなかった

>>56 ダウンロードじゃなくて買うんだよ。
http://www.webstore.jsa.or.jp/webstore/Com/FlowControl.jsp?lang=jp&bunsyoId=JIS+X+9204%3A2004&dantaiCd=JIS&status=1&pageNo=0

>>52 カーネーションはテレビジョン学会(映像情報メディア学会)の
だった気がする。それともNHKだったかなあ。

フジテレビ反対！！！
ホリエモンまんせー！！！！！！

ああやっぱ映像情報メディア学会だった。
http://www.ite.or.jp/products/testchart_index.html
の肌色チャート。

ところで52の「落ちてる」とかいう表現が気になるんだけど、
標準画像やチャートは出自がはっきりしているから標準足りえるわけ。
どこぞのどう加工されたかわけわからんものをもらってくる
んじゃなくて、ちゃんとJISやITEから買って使うようにね。

>>50
手に入りにいけれどオーム社の「画像認識の基礎」もGOOD。20年近く前の本だけれど。
>>53
学生はともかく、エンジニアだったら何年前の技術でも調べて使う。
画像処理だと30年以上前の技術なんかが、かえって役に立ったりする。

>>62
僕ちゃんいろいろ探したけど、その本は手に入らないです。
似たような内容の本ってないですか？
神田とかに行ったらあるかなぁ。そういう古本専門店ないですか？
（最近、関東に来たのでよくわからない）

>>53
終わってなぁーーーーーーい！！！！！

>>63
「画像認識の基礎」(1)(2)。絶版、再販未定だった。
とにかく記述が細かく、図版が豊富なので初心者にも分かり易い良書だった。

となると、>>54のとおり「新編 画像解析ハンドブック」が次善の策かな？

>>64
終わってないの？
じゃぁ，ブームが終わったに変更・・・

>>62
古い技術を人に聞いてまわるってのが痛いと思ったわけで・・・．
再発明しなくとも，研究成果は形になっていくらでもあるわけだし・・・．

>>67
最近関東にきたって書いてあるから
試験に受かって下宿探してる大学新入生かもね

http://www.tomoeda.org/
↑
ここの画像を標準画像にしようぜ。一般的な標準画像は写真ばかりで
イラストに対する画質の評価はあまり見たことが無い。写真とは異なる
信号特性や問題点があるはずだ

・・・もう何も言うまい・・・

ずいぶん偏った標準画像だな

>>69 たとえばJISの標準画像にはいろいろな場合を想定して
各種画像が取り揃えてある。もちろんイラストも含まれる。
心配するな。

画像認識と生体反応の相関の研究

>>69
画像処理やるんだったらLennaに萌えなきゃ

画像処理というか、CGの基礎「ブレゼンハム」についてなんですが、ここでいいでしょうか。

サイエンス社の「3次元CGの基礎と応用」のP.17の式2.4の誤差判定
e+dy/dx≧0.5、e+dy/dx＜0.5
これの両辺から0.5を引いて2dxをかけるらしいですが、P.18の式2.5の誤差判定が
2dx(e-0.5)≧0、2dx(e-0.5)＜0
になっているのはなぜでしょう？
左辺の2dyはどこにいったんでしょうか？

さらに、このあと2dx(e-0.5)を新しい誤差dとおいてますが、
その後の初期誤差を
d=2dx(e+dy/dx-0.5)
としていて形が変わっているのはどういうことなんでしょうか？

サイエンス社に聞け

「3次元CGの基礎と応用」で検索したら、サポート・ページとかあるが、
もう見たの？

つーか、単なる誤植くさくない?

ttp://www.saiensu.co.jp/books-htm/ISBN4-7819-1080-7.htm

これか？
著者にメールでも送ってみたら？ｗ　大学教授っぽいし、すぐ見つかるでそ。
といっても、誤植っぽいんで、そういうことにしとけばいいと思われ。

新訂版が出てるんですね。
自分のは古いやつなんで、新訂版で直されてるかも。
とりあえず新訂版を確認してみます。

お前らIntelC++Compiler使ってますか?
VC6のコンパイラと比べて１〜２割高速になるよ！
コンパイルオプションとかソースをいじればもっと速くなりそう。

VC7のコンパイラもVC6に比べれば速くなるよ。

bcc32使ってますが何か

intelのライブラリとかamdのライブラリとか

VectorC使ってる人って

速度的にどうよ？

>>84
あほ

c言語で画像処理について勉強したいんだけど
なんかいい参考書があれば紹介してください
ちなみに私が使ってるソフトはvc++.net standardです

推薦図書/必読書のためのスレッド PART 22
http://pc5.2ch.net/test/read.cgi/tech/1106175218/

>>86
C言語による画像処理入門ってのが、ぐぐると出る。これを目当てに本屋に行って
立ち読みしてみる。画像処理ったっていろいろあるから、やりたいことが明確で
ないなら、こういうのいいんじゃないか。
やりたいことがあるなら、その関係の本を探す。画像に関係しそうな言葉で
ぐぐると、いろいろなサイトもある。

>>86 何がやりたいの？

画像処理っていっても幅が広いからなぁ。
どういうことに興味があるのか具体例を挙げた方がいいかと。

いや、まだ何をやりたいかは決めてないです
ただ、基本情報技術者試験を受けたいから
参考書を買ったら画像処理のプログラムが
載ってたから詳しく勉強したいなと思いまして
皆さんにお聞きしたまでです　自分まだ素人なんで多めに見てください

>>91
中古車屋で車をくれといってるようなもんだぞ

ひょっとして直線を引くとかいうやつか？

そうかも

>>91
C言語で学ぶ実践画像処理とかどうかな。
線引いたりフィルタ作ったりとかは書いてたと思う。

>>95
糞本

>>93
あたしの最初のは、イヤラCGとかだったか。MBASICかなんかで。

>>93
丸大ハムとかいうやつか。

>>95
漏れもそれで始めた。

ソース打ち込みがﾒﾝﾄﾞｲけど、それもまた必要か、と思えばなんとか。
個人的にCG-ARTS協会の本とか割と好き。（ダメですかそうですか）

ところで、
ttp://www.amazon.co.jp/exec/obidos/ASIN/479800958X/qid=1109833992/br=1-2/ref=br_lf_b_1/249-3595144-8774755
これってどう？

DirectX（2D）で稲妻の効果の出し方を教えてください

>>97
聞いてないｗ

エロげー作りたいんだけど、画像ってどうやって表示するの？

>>99
おいらもCG-ARTS協会の本は好きかも。
画像処理の結果をカラーでみられるってのが(・∀・)ｲｲ!!

>>99
名前からモデラー臭がプンプンするのがいやだ。

Photoshopの「エッジのポスタリゼーション」て
どんなアルゴリズムなのか分かる人いたら教えてください
実装したいけどアルゴリズムわかりません('A`)

>>105
Adobeが特許を持っているけど、それでも使いたい?

ただの3X3のマスクでフィルターだろ

>>106
特許取れたん？俺の持ってるバージョンのやつは
申請中って書いてる。

自らサブマリンに挑もうと…？


#いや、手漕ぎボートか？

特許持っててもいいから教えてください。
ちょっと変えて使うから。

つーかアメリカでとった特許って
日本で適用されるんだっけ？

各国で出願しますが何か？

http://niitsuma.at.webry.info/
前スレの個人的に興味ある話題のみ
まとめてみた。間違い指摘よろ

ベジエ曲線を描きたいんですけどRのキツイとこでピクセルが固まってしまいます
なんとか8連結で描画できないでしょうか
(今は適当なステップ幅で値を計算して直線でつないでます)
http://v.isp.2ch.net/up/41524cc30866.png

>>114
直線引くときに、始点と終点が1ピクセルしか離れていなかったら、
もう1ステップ先の点を終点に選んでみては？

>>115
ありがとうございます
今ソースが手元にないので家に帰ってからやってみます

スレ違いかもしれないけど教えてください。
ド初心者です。
画像を任意の大きさに拡大縮小するにはどうするのでしょうか？

winならstretchBlt,とかdirextX,
またはOpenGLか？

本当のド初心者なら、IrfanViewで変換してから、定サイズで処理だろ。
俺は「初心者」って単語みたら、このレベル以下（IrfanViewの使い方すら分からない？）だと想定する。

時刻をみると、
http://pc5.2ch.net/test/read.cgi/tech/1068349883/604n
かなあって気がする。

おれどこの時刻見てたんだろ... orz

質問なのですが、
http://www.amazon.co.jp/exec/obidos/ASIN/4789818349/qid=1110456021/sr=1-2/ref=sr_1_10_2/250-0638343-6195423
この本はＣ++ではなくＣだけを使ってプログラミングしようとしている人は対象にはしていないのでしょうか？
よろしくお願いします。

C++だけでなくMFCの知識も必要になる予感

VBモナー

つーかいまどきCだけなんて┐(゜〜゜)┌ハヤンネー

ああああああ俺Cだけ・・・。

今からでもC++やっとけ。
いまどきオブジェクト指向は常識だぞ

オブジェクト指向って何ですか？

>>127
http://pc5.2ch.net/test/read.cgi/tech/1108989422/170

>>123
>>124
どうも

>>129
礼もろくに言えないのか

>>126
あはは　あほだー

>>130は粗チン

>105
自分も作ろうとしていた所。
エッジ抽出してレベル補正、Photoshopの「コピー」フィルタと同じような物を作り、
メディアンカット減色した元画像に乗算合成でできませんか？

あ、エッジ抽出というよりハイパスをレベル補正する感じで

ttp://www.cs.huji.ac.il/~yweiss/Colorization/
信じられない。

>>135
すげーな

>>135
これってなんつーか、現代版彩色写真だな。
ヒントの与え方のノウハウを巧く盛り込んだツールを作れれば、
モノクロ映画のカラー化が現実的なコストでできそうじゃん。
#そのことに意味があるかとか、商業的にどうかとかは兎も角。

>>135
というか、本当にソフトで処理したのか怪しすぎるんだけど。
例えば、上から2番目の奴で、滑り台みたいなのが茶色と肌色で違う色のマークなのに、右ではほとんど同じ色とか

感動した

>>138
疑いすぎ。
画像をよく見れば、あちこちに自動処理っぽい部分があるかと。
一番上の画像の子供の腕がの影の部分が緑っぽいとか、服の黄色と緑の境界が変だったり。

この程度なら動画になってしまえば気付かないだろうけど。

>>140ってレベル低そうだな
まあ本人がそれで満足してるからいいのかもしれないけどね

なぜ必死？

きっと138は画像処理について自信を失ってしまったんだよ

>141
お前のレベルの高さでいいから説明しる

とりあえず実装を目指します。勝手にやっても怒られないよね？

てーかソースコードついてるじゃん。とりあえずコンパイルしてみるか

Matlab codeってコンパイル出来んの？

一瞬グロ画サイトかと思った

>>138
SIGGRAPHでいんちき発表するのかよ、、、

インチキは無いけどハッタリは見かける

>>150
だって、ＣＧはいかに手を抜いてそれらしく見せるじゃんｗ
まじめにやるならレイとレーシングやってれば良いし

画像処理っていかに手を抜いてそれらしく見せるかじゃないのか？ｗ

>>152
素人らしい考えだな

152の言いたい事がわからん・・・

×ＣＧはいかに手を抜いてそれらしく見せるじゃんｗ
○画像処理っていかに手を抜いてそれらしく見せるかじゃんｗ

かな

CGだろうが画像処理だろうがリアルタイムならいかに処理を端折るかってことになるし、それなりの出力が目的なら精度を重視するだろ。

CGと画像処理は全く別物ですが

だよな。

色空間の変換関係ってここでよいのかしら？

>>159
いいんじゃね？

誰か>>135のアルゴリズムをわかりやすく解説してくれる神はいませんか

輪郭だして、明暗付けて塗り絵。
間違ってたらごめんよ。

そこまで掘り下げて調べるつもりはないから、ソースは見てないが
ラベリングさえ綺麗にできたらマーカーの色相と彩度を参照すればいいだけだし。
この程度の事を疑う香具師が何故このスレにいるのかの方が謎だな。
動画はいらんが、静止画は面白そうなんで今度作ってみよ。

境界がはっきりしていない画像にも有効なんだろうか？

何のためにあんな塗り方を（ry

それがユーザーインターフェースという物では(ry

あの塗り方はグラデーションのかけかたを指示するためでしょ。

グラデーションなんかかかってないだろ。このスレ大丈夫か？

表現はマズイが言ってる事はわかるけどなー。

このスレ大丈夫か？

イスラエルって画像処理先進国なんだね。

＞135
よくみたら Nature がある。すげーな。
でも画像でNatureなんか出せるのか？

元の論文(のabstract?)にちゃんと説明あるじゃん。
お前ら英語も読めないのか・・・

ラベリングなんかしてねーよ。
ラベリングしないってのが肝じゃん。

解説ヨロ

大雑把に言うと、近傍の画素においては、「明るさが近い=色が近い」という関係が成り立っているということにして、
近傍における画素の明るさ(l)の近しさを正規化したものを重み(w)として、
「ある画素の色 - その近傍の画素の色の重み付き平均」が最小になるように画素の色を求める。

もともと色がわかっている（指定されている）画素は全体の中のごく少数なわけだけれども、
こういう少数の前提の下に単純な「〜が最小になるような値(のセット)を求める」っていうのは
数値計算の問題として研究されていて既存のアルゴリズムが使える（らしい）。
で、その結果ほんの数個の数式でこういう結果が出るよ、イイ！！っていう論文。

こういう手法では適切な制約条件（この場合、一部画素群への色指定）を与えるられるかどうか肝心なんだけど、
サンプルを見た感じではインタラクティブに指定する端から結果が表示されるなら簡単そうですよね。

>>175
そそ、逆にインタラクティブなツールがないとヒントの色を置くのに試行錯誤できなくて辛いと思った。

175書いた後に気づいたんだけど、
色指定のしやすさはどの手法でも肝心なような気もしてきた。
領域分割にしても単純全面色指定にしても。

>>176
私はGEMを使って実験済み。

行列計算するからMatlabなのか。固有ベクトルの計算は挫折ぎみだったが
また挑戦してみようかなあ

画像処理におけるPDEとかレベルセットとかの解説記事希望

explorer のような、 file や folder を tree view で表示するソフトを自前で
作って使っています。デジカメ写真の folder を表示したとき、決まったicon
だけでは file name も無味乾燥でつまらないので、16x16 の絵に縮めて付けて
います。が、元が写真だと皆似たような絵になります。マンガ的な絵に変換して
縮める手法とかありそうに思うのですが、何をキーに調べればいいか、分からない
でしょうか。

16x16って、漫画的も何も情報量減りすぎて話にならないと思われ。
(複雑でない)漢字一文字がやっとだもの。

>>182
レスをありがとうございます。無駄骨とは思いつつもあるかと思ったもので。

画像処理にはハズレますが、気になったので調べましたら、表示のために
ImageList に add すると、皆 4 bit color にされてしまう感じですね。
しかも、RGB quad は共通のものを使っているような。GetDIBits() に
渡して一旦 8 bit color までは落としていて、ここまではまだ色は着いて
いるんですが、4 bit では、中間色はほとんど灰色になる。dither かける
には面積がせまいし、やっぱり徒労ですかね。

フルカラーのImageList作ればいいだけじゃないの？

>>184
や、お恥ずかしい。ImageList_Create() を見て、flag が TRUE だった。
8 bit color のに変えたら、色が出た。で、ここへ来たら、もうレスがあった。
16x16 じゃ、姿形は見えないが、匂い程度は分かるようになった。お騒がせ。

普通の small icon が貧相になった。

変なものハッケソ
http://www.is.titech.ac.jp/~yoshika0/effect_lines.html

>>161
カラー（3変数）　->　モノクロ（1変数）変換は変換関数が与えられていれば一意に求まる。
その逆は一意に求まらないから，制約条件や評価関数を与えて制約付最適化問題として問題を定式化。

>>187
おまえが発表すればよかったのに。

>>188
ああいうの見るたびに生まれてくるのが遅すぎたと悔やまれるよ。

>>189
それは君が既に発表された技術や研究を見ているからだよ。
昔、難問と言われている算数の問題の解答だけを見て、こんな簡単な問題、とか思わなかった？

俺は生まれた時から地球が丸いと思っていた。
もっと早く生まれてれば火あぶりの刑だったな。

>>190
>>191

志村〜！メール欄！

>>191
さてはお前、太陽じゃなくて地球が回ってる事も知ってたな。

オレは目は回っているが、クビが回っていない。

オレは頭が回らない

それでも地球は回る

オレは舌が・・・

そろそろやめないか？

新ネタきぼんぬ

画像が、合成か、そうでないかを
画像処理で調べる方法ってありますか？

>>199
北朝鮮の写真で色々やってたな
フルオートは難しそうだが

合成にも色々あるんだし、制限無しには不可能だろ
例えば、字幕スーパーのみたいなのとか、宇宙に人間が居る写真みたいなのとか

今回、ふと気になったのが、
テレビが写っている画像なんです。

そのテレビの画面に映っているのはゲーム画面なんですけど、
これが後で、はめ込みされたのかどうか・・・
・・・と、こういうのって、技術的にどうやったら調べられるのかなーと思いました。


まぁ問題の画像ってコレなんですけどね。
ttp://voiddd.com/up/data/1111349011-1111237233-050319_220316.jpg

レベルが低い質問ですが、ズーと file list の表示は、「詳細」を指定して、
小さいアイコンとファイル名で表示してやってきました。先日、いたずらに
winXP で、WEB 形式にして、大きいアイコン表示にして、jpeg ファイルを
クリックしたら、フォルダ名の下に preview の絵が出ました。これが結構
速い。今まで、自前で、libXXXX.dll とか使って表示していましたが、あれは
なんだったんだろうと思いました。OSか、IE関連で持っているルーチンは
使えないんでしょうか。（???.flt というファイルがあり、open, get, put
close 相当の関数名を export しているようですが、圧縮技術の著作権とか
が制約になっているのでしょうか）

復帰？

age

画像の拡大で、いろいろなアルゴリズムがありますが、それぞれの特徴をまとめたサイトなどはないでしょうか？

いろいろってどんな？

>>206
ttp://www2.nsknet.or.jp/~numada/ip05.html
こーいうの？

例えば、IrfanViewというソフトでリサンプルの方法が6個示されていますが、それぞれどのようなアルゴリズムで、どのような特徴があるのかを知りたいのですが。

それぞれ名称書いてあるんだからぐぐってみたら？

あhaあはha

>>206
Interface誌の98年4月号に結構詳しく載ってたよ。（古過ぎ）

ttp://www.cqpub.co.jp/hanbai/books/33/33991.htm
↑の本の目次を見る限りでは、Interface誌でやってた連載そのものなんで
これの3章だけ立ち読みしてきてもいいかも。

っていうか、俺はこの連載のためだけにInterface誌を保管してたから
これ買ってInterfaceは処分するか…

jepg2000は死んだのか？

＞jepg2000

何それ?

jgpe2000
jpge2000
jpeg2000
jegp2000
この中に正解がある

二の舞を避けるために誰も使ってないだけでそ

tek5を使う人はいないのか？

jpeg2000は圧縮にDCTではなくwaveletを使うらしいとしか知らない

ファイル容量の減少に比べて、処理が重すぎる。
結局ストレージの低価格化が、jpeg2000を不要にしたわけか
。

大企業が技術力を提供し合い、最高の圧縮技術を目指したjpeg2000……

しかし、技術馬鹿どもの悪い癖が出てしまい、現実のマシンでの処理時間や、
特許関連の問題への対処、普及のための広報戦略、などの観点が
すっぽり抜け落ちていましたとさ。まる。

音声フォーマットも似たような感じだな

JPEGグループの配布してるJPEGライブラリはフリーなの？
自分のソフトに使って配布しても問題なし？

>>222 条件付でね。

誰かIP7000の使い方に詳しい方おられませんか？

BitBltで画像を表示する時、32X32サイズのを16X16回表示するのと、
512X512サイズのを1回表示するのでは、当然後者の方が速いですが、
32X32サイズのを何回表示するぐらいが、
512X512サイズ1回を表示するスピードと同じぐらいになるんでしょうか。
大体の目安とか法則とかありましたら教えてください。

ええけつしとるのぉ(*´Д`)ﾊｧﾊｧ



うはっｗｗｗおｋｗｗｗ？？

>>225
激しく環境依存かと思いますが。
ご自分で先ず計測してみては如何でしょう。

>>227
分かりました。ありがとうございました。

>>224
あーなつかしぃ．IP5000シリーズ昔使ったことあるけど，7000はしらない．
メーリングリストもこないだ停止になったみたいだね．

つーか，そのボードって日立の中の人以外で使う意味ってあるの？
組み込み用PCで高速処理できるのは分かるけど，カリカリにチューンしたコードとｐｅｎ４の組み合わせの方が圧倒的に速いし．

Modern C++ Design とかいう本
ttp://www.moderncppdesign.com/book/main.html
の考えかたに従って

基画像と基画像のフーリエ変換、の両方をうけつける
画像のアフィン変換は　どうインプリメントするべきなんだろう...


template {template class Image}
class affine_transformed_image : public Image<???>
{
affine_transformed_image(????)
{????}
}

１０分ぐらい悩んでみたけどわからんかった

窓側で撮った写真で窓側は明度が十分なのに反対側は暗いので、暗い部分の明度を
上げる修正を試みていますが、全体の明度を上げると、くすんだ感じになるので、
明度差が拡大するよう操作しています。で、コントラストでぐぐって、方法を
調べていて、コントラストの度合とか、高コントラストという言葉に出会いますが
「コントラスト度」の指標のような話に出会いません。コントラストは目で見て、
どうかを判断するしかないものでしょうか。近接するピクセルの明度差を標準偏差
のように計算するとかないのでしょうか。尚、明度は今、YUV のを使っています。

>>231
言ってることはよく判らんが、私のところでは対象領域の濃度差でコントラストとしている。

>>231
濃度(輝度)ヒストグラムストレッチとか

画像を綺麗に縮小したいのですが、良いアルゴリズムが書いてあるwebサイトとかないでしょうか？

>>234
このスレで紹介されてなかったかな?
画像の種類や縮小率によっても違ってくるので、先ずは画像編集ツールで色々試すことをお勧め。

>>232, >>233
レスを有難うございます。
対象の写真は、右側は明るく、左側が暗い（コントラストも低い）といったものです。

今まで、試した方法は、画像を方眼状に何分割化して、それぞれの明度の平均を
計算して、一番明るい区分の明度との差を暗いところに加算して明度を上げるように
しました。各ピクセルの上げ幅は、四隅の値から補間計算で求めました。
で、このままでは、元の明度差が維持されてコントラストがよくないので、
四隅の平均値から、各ピクセルの予想平均値を補間計算で求めて、この値と実際の
各ピクセルの明度を比較して予想平均値より明るければ、そのまま明度を上げ、
暗ければ、上げ幅を割り引く（＊）ことにしました。
で、分割数と割り引き率をスライダで、変化させて、良さそうな絵を取ることに
していますが、一番コントラストがあると判断できる評価関数ができれば、
それにまかせられないかと思ったわけです。
＊一番大きな明度幅を維持するよう、明度を上げ下げする計算も可能とは思って
いますが、これはお試しの簡易計算です。

>>234
バイリニアで十分だろ

>>234
ISO/JIS-SCIDとISO/JIS-SCID(RGB)の
ドキュメントが意外とまとまってたな。

>>237
縮小にバイリニアはあんまり意味ねーぞ。

>>239
じゃあ何が良いんだよ？

>>239
1/2程度以下に縮小するならそうだけど、少しだけ縮小するならバイリニア使った方がいいよ。もちろん画質とスピード等のトレードオフだけど。

>>241
1/2程度以下に縮小する場合は？

単純に平均を採って端数ピクセルは無視しても大丈夫な気ガス。いや、1/2程度ぐらいだと必要かなぁ。1/3程度以下なら9ピクセル分採れるから大丈夫だろうけど。

質問しようと思ったけど、ぐっとこらえてグーグル検索をする俺。

>>244
えらい

>>244
えろい

>>244
結局質問するんなら最初から質問しとけ。

質問してみようと思い、過去レスをチェックしたらクォリティの低さに頭をかかえてしまった俺。

>>248
とりあえずクオリティの高い質問してみれ。
クオリティの低い回答してやるから。

ttp://www.dei.brain.riken.jp/~emilia/Collaboration/Tino/TiViPE/index.html
これって使えるの？
いろいろ見てるので、もうおなかいっぱい...

>>250
ほー。こんなの作ってる人がいるんだ。面白そう。
この手のＧＵＩって特許が絡んむことが多々あるんで、作ろうとしてる人たちは要注意！

特許なんか全部虫。

>>231
遅レスだけど、ガンマ補正を試してみては？

>>253
は?

激しく評判が悪いようですがJPEG2000関係でちょっとお聞きします
JPEG2000のROIの形状を細かく設定できるようなソフトってありませんかね？
もしくはJPEG2000のROIについて詳しい説明のある書籍など

>>255
ROIって知らなかったので、ぐぐったらいろいろあって、へーと思ったが、
あんなのではだめだったのですね。

JPEG2000を見るのはいっぱいあったけど
作るほうはどうだったかなぁ？

>>256
ただJPEG 2000の形式で出力するだけならいくつかあるんですが
ROIに関しては全然触れられていないのです
誰かおしえてエロイ人！

自分でつくらにゃならんのか･･･

ここはプログラム板だからな
プログラムを作る人のための板なわけで、自分で作れと言われるのは当たり前だが。

あるソース画像と、ソース画像を縮小してさらに若干のノイズが混入した画像があるとし、
その2つの画像が「どれだけ似ているか」を示す評価関数はどのようなアルゴリズムを使えばよいのでしょうか。

FFT

>>261
あ、そうですね。ありがとうございます。

それで納得する260に萌え。

納得するのは早合点でしたか？？？

>>260
正規化相関

psnr

PSNRあげ

000!

000!

OpenCVと
http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/
のテンプレートと組み合わせたことある人っている？

多次元配列のIteratorsとか
Local Minima and Maxima のテンプレートだけでも
使ってみようかとおもうんだけど

>>270
OpenCVオンリーしか使ったこと無い･･･
Vigraの解説キボン

Vigra 画像版ＳＴＬ

>>272
ほとんどCでしかプログラムやらないんで、オブジェクト指向とかSTLとか意味わかんない。
というか、STLに従ってプログラミングして素敵に思えたことがない・・・。

コードの再利用？そんなもん糞くらえ

これからは、Core Imageだと思う。

jpegではいろいろ改良によって高速化が出来るようなのですが、
ビットマップファイルの高速読込アルゴリズムって何かありますか？

>>275
あんたの言うビットマップファイルがWindowsBitmapで無圧縮のもののことを言っているのなら、
読み込み時間の多くをファイルアクセスが占めているのでアルゴリズムで工夫しようがない。

強いて言うならでかいファイルをどうやって効率よくメモリにロードさせるかってAPIの使いこなしか？

そういえば昔は VRAM へ送りこむとかしていたが、いまはもう出来ないのかな。

>>278
いつ頃の、どんな技術のことを言っている?

>>278
Linuxのフレームバッファでだいたい同じ事ができる。

そういうデバドラ書けばいいじゃん

インテルのプロセッサを使っている場合、JPEGのデーコードはインテルの
インテグレーテッド・パフォーマンス・プリミティブが一番高速なのでしょうか？

んなわきゃないだろ

そうそう、IPPはAMDでも最速。

とりあえず、注文してみました

ちょっとお尋ねします。

動画を処理して再生するツールを作っているんですが、
たとえば704x480を640x480に、できるだけ高画質に、
しかし、それ以上に高速に縮小するようなアルゴリズムを
探しています。

３次補間法とか平均画素法とか、いろいろあるみたいですが、
動画再生時に縮小する場合、どんな方法が最適なんでしょうか？

その程度ならバイリニア程度で充分じゃね？

>>287
>>239

>>288
>>241

>>289
>>242

>>290
640/704>1/2

えーと、バイリニアでちょっと試してみます。
みなさん、ありがと。

先ほどから、まずはGDIのBitBltとかStretchBltから試してるんだけど、
この程度の縮小だと、BitBltで十分かなって気もしてきた。まだ詳しく
検証してないけど、動画として見る分には違和感はない。

もともと、DirectDrawのオーバーレイが使えない場合の救済策的な
意味でやってることで。

ただ、BitBltもStretchBltも速度が不安定。自分の環境で、DivXソースの
縮小を伴わないBitBlt転送による再生表示だと、CPU使用率が20%前後。
ところが、縮小BitBltだと20〜100%を不安定に変動する。

やっぱ、自分で1から書くしかないのかな。。。

>>273
>コードの再利用？そんなもん糞くらえ
Modern C++ Design
Andrei Alexandrescu
の第１章だけでも読むことを薦める。
ヒューリスティクスでも綺麗に書けるし再利用できる

OCRの基礎を学びたいのですが、参考になる書籍や論文、WEBページなどの文献がありましたら、教えていただけませんか？

>>286
720x480→640x480
だが、オレはそれ用に、9ドット→8ドット縮小専用にハードコートされたバイリニア縮小ルーチンを作った。
それを80ループさせると、水平1ラインの縮小ができる。
パラメータをイチイチ計算しつつバイリニアするよりは格段に高速。

704→640だったら、11ドット→10ドットの縮小ルーチンを作ればいいのかな。

>>294
OK読んでみる。
”コードの再利用？そんなもん糞食らえ”を早く卒業したい。

画像の縮小について貼っておきますね。
ttp://www.marumo.ne.jp/db2000_c.htm#18

みんな、先週のタモリ倶楽部みたかい？

exifを扱うC++のクラスはありませんか？

画面に6枚のjpg画像を表示したときCPU使用率が30%ぐらいになります。
jpgサイズは640x480でそれを320x240にして表示しています。
CPU使用率を3%以内に抑えれるでしょうか？

言語はVB6
OSはXP Proです。

CPU16個ぐらい積んだマシンで動かせ。

ゆっくり表示すれば、遅いマシンでも抑えれるよ。

ゆっくりと表示出来ないんです。
動画とまではいきませんが、1、2秒で6枚の画像を再表示しています。

パソコンの性能を上げるしかないのでしょうか？
今は、CPU 2.8GHz、メモリ 256MBです。

他のスレで聞け。

ヒント：言語の限界

↑これ流行ってるの?

やってるのは一人です。流行っているわけではありません。

>>304
あらかじめゆっくり読み込んで、すばやく表示。

VBなんていうアフォ言語を使うのが悪い

古いversionのPainterは起動しておくだけでCPU使用率常時100%だよ

表示部分をスレッドにしておいて、スレッドの優先度を最低にするとかは？

http://p4023-ipad41hodogaya.kanagawa.ocn.ne.jp/
ｗｗｗｗｗｗｗｗｗｗｗｗうはっｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗうぇｗｗｗｗおｋｗｗｗっうぇ
っｗｗｗｗｗｗｗうぇｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

>>312
スレッド使ったところで使用率は下がらない
VBよりもっと効率のよい言語を使え

描画のたびに縮小処理してるとか。

フォトショップの自動選択ツールみたいなのが作りたいんですが、どんな方法を調べたらいいですか？

既存のGUIライブラリにはそういうのが付属しているものが多い。
GUIライブラリはいろいろ種類があるから探してみるといい。

>>316
塗りつぶしと同じようにすればいいんじゃね？

>>318
塗りつぶしでいけそうです。ありがとー

ttp://141-187-93.biwa.ne.jp/
ｗｗｗｗｗｗうぇうぇうはっｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗおｋっ
ｗｗｗｗｗｗｗｗｗｗｗｗｗっおｋおｋｗｗｗｗｗｗ
うはっｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗおｋｗおｋっ
ｗｗｗ

最近良く見掛けるこれ何ですか？>>320

ウイルス

ttp://www.hirax.net/dekirukana5/chara/index.html
ここにあるようなフーリエ変換後の画像について質問です。
この画像は真ん中付近が低周波で上下左右が高周波領域となってるみたいですけど、
右の高周波と左の高周波はどう違うのでしょうか。
それと上の高周波と下の高周波の違いもわかりません。
普通にフーリエ変換してパワースペクトルにするとｘ方向の高周波とｙ方向の高周波しか
でないと思うんですけど。

>>323
めっさ適当に答えてみる、４分割してるんじゃね？
画像を４分割して、４つの周波数グラフがあるってこと
ヒエログラフって左上と右下に高周波がおおいのかな

フーリエ変換すると、結果は複素数ででてくるから、それの実部と虚部をそれぞれ表示してるとか。

普通は、わかりやすさの点で、絶対値と位相にわけて考えて、絶対値(大きさ)だけ表示するもんだけどね。

>>324
この画像を細かく拡大して見る限りX軸とY軸に対称みたいなんですが
４分割すれば対称にはならなくなりません？
>>325
実部と虚部を別に表示してもそこのグラフの第一象限と第三象限の二つだけでいいように思います。
私も絶対値と位相にわけて表示するんじゃないかと思ってたんですがググってみると
画像処理ソフトとかMatlabだとかは>>323のページのグラフみたいにするみたいなんです。

うわ！
「ヒエログラフ」はＸ軸とｙ軸に対称じゃないですね！
「漢字」の所ばかりみてました。
４分割にして試してみます。

分割してもだめでした。
というかサンプリング数8でフーリエ変換するとexp(i*1*t)とexp(i*7*t)がサンプリング定理から区別つかないので
周波数４を中心に対称(周波数1の実部=周波数7の実部）になり、フーリエ変換後の画像は画像の中心の点対称
になると思うんですが、>>323の画像はなってませんよねー
もうわかりません。
>>324,>>325ありがとう！！

>>328
点対称にはなっている気がするが。
これに、ルーン文字を加えたら方向性がはっきりして面白いかと。

47氏制作のソフトをパクった作品が第10回学生CGコンテスト佳作受賞

47氏作水粒子に関するサンプルプログラム
http://homepage1.nifty.com/kaneko/water2.htm

インタラクティブ部門佳作「タマ転がし」石上 瑞樹
■受賞のコメント
「今回このような受賞を頂き、大変嬉しくまた光栄な事と思っています。
　非常にシンプルな作品ではありますが、
　その「単純」の中で何かを感じして頂ければ幸いであります。」
http://www.cgarts.or.jp/contest/scg/2004/interactive/fine04.html


47氏ソース中のパラメータを少し変えてだけのものを応募した模様。

両方を初めて見る人であっても、 受賞作品の動画と金子さんの水粒子サンプル・プログラムの
動作画面 を眺めてみれば、一目瞭然同じものであることがわかるはずだ。
参照：ttp://www.hirax.net/diaryweb/

>>323
●◎○△　こういう画素列があったとき、
fft(●◎○△) が ●◎○△ をフーリエ変換してパワースペクトルをとる処理だとすると、

(1)横方向に画像を切ってフーリエ変換して、そのパワースペクトル(か絶対値)をとる
○○○○ fft(○○○○)|　→ ▲▲▲▲　
●●●● fft(●●●●)　→ ▼▼▽▽
◎◎◎◎　　→　 fft(◎◎◎◎)　→　□□××
△△△△ fft(△△△△)　→ ■■■■

(2)縦方向に画像を切ってフーリエ変換して、そのパワースペクトル(か絶対値)をとる
▲▲▲▲ fft(▲▼□■) ＄∪∠★　　　　＄∩Åд
▼▼▽▽ fft(▲▼□■) ∩〇Λ＃　　　　∪〇！＠
□□×× → fft(▲▽×■)　→　Å！＿％　→　 ∠Λ＿Щ
■■■■ fft(▲▽×■) д＠ЩЮ　　　　★＃％Ю

(↑左で縦横をひっくり返したから元にもどした)


(3)四隅が低周波で中央が高周波になるから、4分割して、四隅が中央に来るように並べ替える
＄∩Åд ＄∩ Åд　　　　　＿Щ∠Λ
∪〇！＠　→ ∪〇 ！＠ →　 ％Ю★＃
∠Λ＿Щ Åд＄∩
★＃％Ю ∠Λ ＿Щ ！＠∪〇
★＃ ％Ю


((1)(2)は逆の順番の可能性もあり)

って処理をしてるんだと思うけど・・・

ずれたorz

(1)横方向に画像を切ってフーリエ変換して、そのパワースペクトル(か絶対値)をとる
○○○○　　　　　　fft(○○○○)　　→　　▲▲▲▲　
●●●●　　　　　　fft(●●●●)　　→　　▼▼▽▽
◎◎◎◎　　..→　　fft(◎◎◎◎)　　→　　□□××
△△△△　　　　　　fft(△△△△)　　→　　■■■■

(2)縦方向に画像を切ってフーリエ変換して、そのパワースペクトル(か絶対値)をとる
▲▲▲▲　　　　　　fft(▲▼□■)　　　　　　＄∪∠★　　　　　　＄∩Åд
▼▼▽▽　　　　　　fft(▲▼□■)　　　　　　∩〇Λ＃　　　　　　∪〇！＠
□□××　　..→　　fft(▲▽×■)　　..→　　Å！＿％　　..→　　∠Λ＿Щ
■■■■　　　　　　fft(▲▽×■)　　　　　　д＠ЩЮ　　　　　　★＃％Ю

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　(↑左で縦横をひっくり返したから元にもどした)


(3)四隅が低周波で中央が高周波になるから、4分割して、四隅が中央に来るように並べ替える
＄∩Åд　　　　　　＄∩ Åд　　　　　　＿Щ∠Λ
∪〇！＠　　　　　　∪〇 ！＠　　　　　　％Ю★＃
∠Λ＿Щ　　..→　　　　　　　　　　　→　　Åд＄∩
★＃％Ю　　　　　　∠Λ ＿Щ　　　　　　！＠∪〇
　　　　　　　　　　　　★＃ ％Ю

もっと分かりやすいAA描いて

>>332
Linuxのkitaでみると何がなんだか・・・。
女子高生文字ですか？

二次元フーリエ変換くらい調べろよ。

そういえばOpenCVでRGBヒストグラム作れる?
あるいは各画素毎にRGBの濃度って取り出せます??

取れるに決まってるだろ…。

VC++ で、画像からピクセル値取得→加工→画面に表示というプログラムの作成を考えています。
(VC++ はほぼ未経験です)

検索すると、下記のようなページがあり、そこでは、デバイスコンテキストから
一ピクセルずつ GetPixel し、また一ピクセルずつ SetPixel で書き戻すということをしています。

ttp://homepage3.nifty.com/ishidate/vcpp6_g1/vcpp6_g1.htm

上記のような処理は定石と考えてよいのでしょうか？

VC++ 以外の環境での経験から、1ピクセルごとに読み込みと書き込みを行うのは
処理時間が長くなりそうなイメージがあるのですが、そのようなことはないですか？

もしくは、もっと良い方法などがありましたらご教授いただけないでしょうか。

処理時間は長くなります。
VCのことは知らんが、生データを直接取り出していじる手段が用意されてるはず。
MSDN読んでくれ。

DIBSection相手ならGetPixel/SetPixelでもそう遅くないはずだが。
普通はポインタ経由でhogeるが。

質問です。
libpngを使って、png画像の縮小をすることは可能でしょうか。
知っている方がいたら教えてほしいです。
よろしくお願いします。

質問させてください。

DXライブラリを改造したライブラリを使って(DirectShow利用）
Webカメラの撮った映像を表示するプログラムをしたいのですが、
キャプチャ出来ません。

その理由に、
ビデオキャプチャするデバイスが
Conexant 2388x Video Captureと
Mic Cam
２つが存在し設定でConexant 2388x になっているからだと思うのですが、
（Mic Camしかない別のPCだとキャプチャ出来る）
Mic Camに設定してキャプチャする方法はないでしょうか？

お願いしますm(_ _)m

>>338
軟弱なコード書いてんじゃねぇよ。
座標指定してピクセル値を読み込んで計算なんて行儀ばっかりに気を使ってちゃ何もできねーぜ。
ポインタ演算駆使してメモリ直読みするのが真のプログラマだ。
画像形式がDIBだ？DDBだ？ハァ？ふざけんな。
全部mallocしたメモリにぶち込め。アルファがホシケリャ32bitだな！ガハハ！！！
真のプログラマならQWORD境界でmallocしとけよ！

なんで、QWORDなん？
OWORDとかだめなん？

>>343
まぁ、、、、あんたのいうとおりだよ、、、、。

つか、いくらmallocでメモリ確保しても、結局画像データ取得するわけだが。
mallocしても、うまいこと配列にしておけば、ポインタ演算駆使する必要もないわけだが。

急速にスレの質が実装よりに傾いてまいりました。

>>338
他の環境の経験があるなら、同じ流儀でやればよろしい。検索結果のみに頼らなければならない理由もないだろう。

>>341
何故それをlibpngにやらせようとする?

>>342左巻き
DirectXスレで聞いてくれ。

>>347
訳あって、libpngでpng画像縮小出来るか出来ないか知りたくて。
もし出来ないとしたら、公開されているライブラリで
png画像縮小が可能なものはありますか？
知っておられたら教えてください。

>>348
OSとかコンパイラとかどんな画像を対象としているとかも言わずに教えろかよ。ふざけてんの？

まあImageMagiKとかたいていの環境で使えるけどな。

もしかして: imagemagick

orz

しかも他スレで、ImageMagick使えってちゃんと教えてもらってる
じゃねーか。ライブラリの使い方わからんなら、そう質問しなおせばいいのに。

ガンマ補正はどのように書ければいいのでしょうか

? どゆこと?

ぐぐれよ！とレスするまえに自分でやってみた。
http://e-words.jp/w/E382ACE383B3E3839EE8A39CE6ADA3.html
>γ(ガンマ)値とは、画像の明るさの変化に対する電圧換算値の
>変化の比で、これが1に近づくのが理想だが、素子の特性によ
>り機器によってそれぞれ異なった値となる。このため、元デー
>タに忠実な表示を再現したければ、これらの誤差を修正する
>必要がある。これがガンマ補正である。

この説明書いたやつ、大丈夫か？

>>347
レスありがとうございます。
DirectXスレで聴こうと思います

画像の輝度値の平均や分散をもとに
ルックアップテーブルを作成する方法ってありませんか？

真のプログラマが集うスレはここですか？

首のプログラマが集うスレはどこですか？

>>353
0.0 <= x <= 1.0 (入力)
0.0 <= y <= 1.0 (出力)
y = x^(1/g) (g:ガンマ補正値)
でいける。

>>360
ありがとう

カメラに移った画像から、そのカメラがどちらに
動いたかを検出するにはどうしたらいいでしょうか？

前後の画像を比べるというような漠然としたイメージはあるのですが、
具体的にどういう処理をして比べたらいいか見当がつきません。
ヒントでもなんでもいいので教えてください。<m(＿)m>

>>362
http://www.amazon.co.jp/exec/obidos/ASIN/479800958X/hatena-22/ref%3Dnosim/250-5035116-5121037

>>362
ブロックマッチングしてオプティカルフローを求める。
オプティカルフローの平均とかを求める。

以前このスレで質問した者です。
はふ変換を使ってみたのですが、よく考えたらやりたいのは直線の抽出じゃなくて線分の抽出でした。
しかも、なんか線が太いと誤認識しまくりで似たような線が大量に抽出されてしまいます。
これを代表的な線だけにしたいのですが、はふ空間に何かフィルタをかければいいのしょうか？
アドヴァイスをお願いします。

>>365
細線化

反転色の取得方法を教えてください

color ^ 0xffff

~( color & 0xFFFFFF )

んなもん、画素の持ち方で違うじゃねぇか。

カラースケールの計算方法を教えてください

r + g + b

>>371
color scale でぐぐったら。

>>336
>>337
OpenCV にＦＦＴないぞ
IPPにはあるけどな

templateを駆使する画像ライブラリー
vigraの
画像格納クラス
BasicImageを拡張して

class BasicImageEx : public BasicImage
{
いろいろ
}

を作ったけど
BasicImage
の演算を適用できない

型キャスト' : 'BasicImageEx *' から 'const vigra::BasicImage<PIXELTYPE> &' の変換は存在しますが、アクセスできません。

とか言われる。
何が悪いんだろう

エラーメッセージの通りだと思うが。
見てないからアレだがその演算関数がprivateだからでねーの

グラデーションの描き方を教えてくだすれ

DrawGradation(0,0,640,480,RGB(0,0,255),RGB(255,0,0));

何この環境限定なレス

単にグラデと言ってもディザとか考えるとムズいべ('A`)y-~

Windows、C++でお願いします。

print("????");

あれ、化けた。
print("█▓▒░ ");

>381
::GradientFill()か
CDC::GradientFill()

クオリティが落ちてきたな。

APIの使い方はそれぞれの環境のスレで聞けと。

２点間の距離によって色の混ぜ具合を変えればいいだけなんじゃネーの？

>>377
ペイントソフトでbmp作ってBitBltでもしとけ。

実際ゲームではグラデマスク使ってる

>>377
API に GradientFill() なんてのはある。title bar の色が右から左へ段段
いろが薄くなるとか描ける。

Windowsならどうやる？

>391
>390

>>377 >>391
OSに関わらず、矩形領域を一定間隔毎に色調をずらして
塗りつぶしてやればいいだろうが。
APIは何を使ったらいいのとかそんなレベルから聞くなよ。
そのレベルなら本を買え！それから出直して来い

iplImageと vigra::BasicImageをミックスしたclassの名前
iplvBasicImage
ってつけるのはどう思う？

iplAllocate をベースにしたSTLのカスタムallocatorってどこかにないかな
あるとすごい助かるんだけど

RGB空間からHSI空間に変換
HSI空間で２色間を線型補完
HSI空間からRGB空間に変換

なるほどそういうやりかたもあるな

このへん参考
http://zeta.gis.pasco.co.jp/support/erdas/faq/ii_spectral_r2i/ii_spectral_r2i.html

C++BuilderでJPEG2000を表示するサンプルコードか何かありませんか？

画像をシャープにする方法を教えてください

Sharpness(0,0,640,480,50);

なんかさ〜，グラデーションを描く方法とかシャープ化とか聞くの流行ってるけどさ，いつからここは素人サービスセンターになったわけ？
もっと議論が広がるような質問しろよ．
シャープ化の方法聞くにしても「画像をシャープにする方法を教えてください」なんて素人丸出しな言い方以外に色々あると思うが．

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

シャープったって、微分フィルタかけて元画像と合成する方法とか
ニューラルネットで高周波成分を復元させるとか色々あるべよ('A`)y-~

アンシャープマスクってどのような演算を適用しているのでしょうか？

>>405
LPF
あと死ね

>>405
ピクセル毎に周辺との濃淡の差を一定の比率で増大させる
http://www.nyanko-web.com/rescue/guidance/gfus.html

自前プログラムでjpeg画像のファイル容量を指定容量以下に
したいのですが、何か方法をご存知の方、教えてもらえないですか？
フリーソフトでこの機能を実装してるのがあるので、
方法はあると思うのですが・・・

現在はImageMagickを使って幅と高さを小さくしてるという苦肉の策です・・・

板・スレ違いなら誘導してもらえると助かります

Photoshopの
自動レベル補正と自動カラーバランスと自動コントラストは
それぞれどういうアルゴリズムなのでしょうか？

統計をとって、一番もりあがってるところをまんなかによせる。
統計をとって、データの端っこを値域のはしっこにもってくる。

複数の静止画像(png, jpeg, pgm 等)から動画を生成するにはどうすればよいのでしょうか？

>>411
質問するなら真面目に質問しろ

>>411
画像処理というよりもフォーマットの問題じゃない？

>>408
http://www.ijg.org/
からダウンロードして、cjpegコマンドを使って
optimize(必須) smooth qualityで調整する。
自前の場合はソース読んで頑張れ。

>>411
アニメーションGIF

>>414
そのやり方だと、DCTまでを毎回行うのが無駄だよね。
昔、自分がやったときは、DCT後のデータを残しておいて、
パラメータを変えての試行錯誤は量子化以降だけをやるようにしてたんだけど、それでも結構重かった…

今時のPCだと問題ないのかなぁ…

画像センシングシンポジウム行くヤシいる？
漏れは毎年行ってる。
毎年超楽しみだよ。
会社さぼってマターリできるからね。

>>417
ノ
発表しまつ

内容は内緒

あの、動画の個々のフレームを比較して
シーンチェンジを検出するようなアルゴリズムを
扱ってるようなサイトってありません？

画像の全体／一部の明るさの変化を比較する
のかなとか夢想してるんだけど。。。

まあ、あまり厳密な方法より、検出速度を
重視したいなと。

ありますよ

>>420
どこに？

モーフィングのやり方を教えてください

Morphing(0,0,640,480,0,0,ImageA,ImageB);

>421
ここの上の方

モーフィングのやり方を教えてください

こんなパターン検出器があったら誰か使う？

いろいろなパターンの組合せをif then ぽく記述して
その組合せのパターンをdetectできる

今作ってるのをちょっと拡張するだけでできるんだけど
拡張する価値あるのか微妙なので迷ってる

例えばこんなパターン


[パターン１（学習で生成） ]


　　　　　　　　　　　飛び地[パターン２（学習で生成） ]


飛び地の位置関係もconfig できる

if (飛び地　との距離　> 3) なら検出

みたいな感じ

>>426
特徴パターン同士の比較だと距離が欲しい。検出が1/0でなく0〜1.0で取得できるのを希望。

>> 425
for i=0 to 32
　cls
　circle(128, 106), i * 5
next i
円が大きくなるモーフィング

それだとチラツキ出まくりなので不合格

ΣΣ(ﾟдﾟｌｌｌ)

これでどうでしょう？
10 screen 5
20 set page 0, 1
30 for i = 0 to 32
40 　line(0, 0) - (255, 211), 15, bf
50 　circle(128, 106), i * 5, 1
60 　set page i mod 2, (i + 1) mod 2
70 next i
80 goto 30

それだとPC-88/98で動かないので不合格

>>430
MSX2か

>>425
ちょっと探してみたけど、
ttp://www.kaibundo.jp/syousai/ISBN4-303-73180-3.htm
ttp://www.sun-inet.or.jp/~yaneurao/intensive/ggg/log1.html
ttp://www.google.co.jp/search?hl=ja&q=%E3%83%A2%E3%83%BC%E3%83%95%E3%82%A3%E3%83%B3%E3%82%B0+%E3%83%95%E3%83%AA%E3%83%BC%E3%82%BD%E3%83%95%E3%83%88+%E3%82%BD%E3%83%BC%E3%82%B9&lr=
とか。あとは自力で頑張れ。

フィルターなどで画像を処理したとき、端の部分はどうしたらよいのでしょうか？一つ内側の値をコピーするのがよいのでしょうか？

>>434
1.画像の外側は0にする
2.外は端のピクセルが永遠に続いていることにする
3.右端は左端と繋がっている
4.ミラーイメージが続いている
5.内側のピクセルから適当に求める（線形補間等）

このあたりから用途に応じて適当に選べばいいかと。

>>434
一回り小さな画像に（ｒｙ

色合いを自動的に補正する方法を研究してて
photoshopなんかの自動で色合いを調整する機能なんかを
参考にしてるんだけど
画像によってうまくいったりいかなかったりで安定しない。
何かいい方法ありませんか？

フーリエ変換でローパスフィルタを作成したいのですが、フーリエ変換をかける前に、画像をどのような形に拡大すればよいのでしょうか？

>>438
2^n でしかFFTできないからそういう質問なのかな？
拡大する必要は無いと思うけど・・・

ところで、任意サイズのFFT(基数2以外のFFT)もあるのは知ってるかな？
計算効率は落ちてあんまり使う機会ないけどね。

>>426
コグニトロンみたいなイメージ？

モザイクをかけたい場合、画像にどのような演算を適用すればよいのでしょうか？

縮小→補間なし拡大 でモザイクになるよ。
win32ならStretchBltを駆使すれば簡単。

DCTについて質問です！画像がどのような性質を持っているときに，
DCTによるデータ圧縮効果が大きくなるんでしょうか。

>>442
もう少し詳しく教えてください。拡大した後元の大きさに戻すのはどうするのでしょうか？

元の大きさに戻すために拡大するわけだが。

>>444
適当に縮小して、そのままもとの大きさに拡大するんだよ

>> 443
輝度が均一

>>447さん
すいません。もうすこし詳しく教えていただけませんか？

DCTは圧縮効果を持たないって、
いちおう、突っ込んでおこうか

>>439
横レスごめん
＞ところで、任意サイズのFFT(基数2以外のFFT)もあるのは知ってるかな？

参考資料あったら、ソースかURLか書籍名ｷﾎﾞﾝﾇ

>>450
あー。
数学の教科書的な物は知らないけど，FFTの入ってるほとんどのライブラリの説明書には簡単な説明が書いてあるよ．通常のFFTの原理知ってるならそれでも十分な理解が得られるはず．
GNUのGSLとか，IntelのMKLとか，FFTWの説明書あたり読んでみて．
この辺の説明書で読んだ気がしたんだが・・・．違うかも．

>>451
レスどうも

FFTの理解度はあまり自信ない…黒箱で使ってるだけなんだけど、
2^nの制限がうっとおしいんですよね。

とにかくレスありがとう
教えてもらったので検索かけてみます。

> 2^nの制限がうっとおしいんですよね。

ローパスフィルタとか作る場合は窓関数が必要なのも面倒だね

CxImage　ってだれか触った？

CxImage
ＶＣに慣れてる人にはいいかも

検索キーワード：CG加工 IMA 新しい 画像ソフト ZZZ

フレームごとに必要のないメソードも含む
クラスを生成するのってかなり遅くなるのかな

いいえ

画像センシングけっこういい発表もあった。
さっそくパクらせてもらいまつ

OpenCV の行列演算と　
boost::numeric::ublas
LAPACK(正確にはboost::numeric::bindings::lapack)

速度はあまり変わらないのかな

>>460
よーしらんけど、汎用性じゃなく速度求めるならMKL or IPP + ICCあたり突っ込むのが定石じゃない?

速度求めるつもりだったけど
なが〜い行列演算式をインプリメントするのに疲れて
手抜きしたくなった。

お前ら数値演算にはどんなライブラリ使ってますか?
おいらは画像と絡んでいれば、OpenCVとかIPP。
純粋に計算だけならGSL。
どーよ？

みなさんはどのような企業でどんなお仕事をされてるんでしょうか？
教えてください。

大学で遊んでます。

職場で遊んでます

>>465
>>466
ありがとうございます。

当方、機械系の大学院一回生なのですが、
趣味でレタッチや動画の取り込み、調整、編集をしているうちに
画像処理の仕事に関心が出てきました。
そこで、どういった企業で、どういった仕事があるのか、どういったスキルが
要求されるのか気になっています。

電機メーカーの画像処理チップまわりのソフトウェアやハードウェア開発などが
やりたいなぁ、なんてことを考えているのですが、やはり電気・電子・情報学科の知識が
強い人じゃないと採用してもらえないかなぁ、と不安だったりしますし、
他にもどんな仕事があるかを知りたいとも思います。

所持している資格や役に立ちそうな経験は以下のとおりです。
・基本情報処理技術者(言語はCを選択。C言語プログラム経験はなし)
・TOEIC450点
・画像処理検定2級を秋に受けるので勉強中
・テキストエディタでWeb作成(簡単なJava組み込み)
・お店のWebページ作成のバイト
・Flashでタイピングソフトを作成
　(アクションスクリプトの基本は一通り理解。CGIと連携させNETランキング作成)
・動画の画質調整の際、各種圧縮アルゴリズムや色空間、
　フィルター処理アルゴリズムについて理解

ご意見よろしくお願いしますm(_ _)m

>>467
http://www.seiki-tsushin.com/sensing/
少し遅かったな。

>>468
ありがとうございます！
ちょっと遅かったですね(汗)
よく見たら僕の担当教授が発表してますｗ
そういえば横浜に出張に行くって言ってたなぁ。

>>443
某ｷﾓｦﾀ大3年生ﾊｹｰｿ!...って俺もその学生かOTZ

>>467
板違いな話ですまんけど。
おいら今年就活して画像ばりばり扱うところ(どっかの会社のデジカメ扱う部署)から採用されたんで一言。
多少学科がずれてても，採用して貰えるかもしれんのでまずは会社受けてみることだと思うよ。（おいらも機械系（+少し情報）だよ）

資格関連だけど、人から聞いた話と体験談。
・基本情報 : あんま関係無いらしい。この辺は資格よりも実際に作ったソフトの話をさせられた。資格の欄が埋まっていい気分だったけど。
・TOEIC : 無いと問題外だけど，最低500は越えてないと書くのも恥ずかしいよね。
・専門系 : たぶん，俺らの知ってる範囲は会社入ったらトリビアレベル。新しい事を学べる理解力とか基礎学力があればいいんじゃないの？

> 基本情報処理技術者(言語はCを選択。C言語プログラム経験はなし)
これだけは確実に役に立たないと言える

>>467
内定おめでとうございます！
貴重なご意見、ありがとうございます！

＞この辺は資格よりも実際に作ったソフトの話をさせられた。
困りましたｗ
何か打ちたいプログラムでもないと動けないです（汗）
夏休みに何かのC言語プログラムに挑戦してみたいので、
おもしろそうな処理を検討してみます。

＞・TOEIC : 無いと問題外だけど，最低500は越えてないと書くのも恥ずかしいよね。
はい。500点以上とれない場合は履歴書に書かないつもりです。
毎日英語に奮闘しております！

＞・専門系 : たぶん，俺らの知ってる範囲は会社入ったらトリビアレベル。新しい事を学べる理解力とか基礎学力があればいいんじゃないの？
ですよね･･･。
やはり、ポテンシャルを見極めて採用というスタンスが多いでしょうね。
しかし、うまく伝わるかどうか難しいですし、成績も悪いのでかなり厳しそうです･･･

今からできることは限られていますが、まだ夢を見ても許されそうですので、がんばってみます。

>>472
プログラムしてみます〜。

↑すみません間違えました
×>>467
○>>471

>>467
私の勤めている会社でよければ話聞きますぜ。
就職フェアでお待ちしてますんで。
#いかん、このネタ何度目だろう。

>>475
ほんとですか！？
どんな会社なのかなぁ？

>>463
boost::numeric::ublas

行列Ａと行列Ｂの掛け算が
C=A*B
だけで書ける
速度はOpenCVの1/5ぐらいぽいかんじだけど

>>477
boostってしらんかったよ。
おいらピュアなC言語使いだから・・・。
そろそろC++を使い始めようかな?

http://vasc.ri.cmu.edu/NNFaceDetector/

ここのソースコード
使ってみようと思うんだが
コンパイルが通らない。

Fedora 3 なんだけど、
同じ環境で使ってる人いないですか。

>>学生
素直に機械メーカーに就職しとけって。
俺は機械科卒、制御系ＰＧだったけど、
歳をとるにつれ、数式をプログラムに落とすのが出来なくなってきた。
ちなみに、画像処理もフィードバック制御と似たとこがある。

Ｃ言語を使ったことがないとあるけど、悪いことを言わんから、
やめとけ。

>>480
そうですか･･･
現実はとても厳しいですね。
ソフト関係はやめておきます。

ご助言ありがとうございました。
お仕事がんばってください。

>>479
どの辺がどう通らない?
#って、Fedora3じゃないけど。

>> 歳をとるにつれ、数式をプログラムに落とすのが出来なくなってきた。

年云々に関係なく、画像処理のコードを、全部自前で書くのはつらいと思うけど。
ツールやオープンソース、ネットや本のサンプルとか活用しない。

　画像処理は年とってもプログラムできる数少ないジャンルなので、数学と
プログラムがすきならそっちいった方がいい。

2chを信じて進路を決める馬鹿が居るな…

>2chを信じて進路を決める馬鹿が居るな…
結構本音を語る場合もあるからな。
かといって、それが全員にあてはまるわけでもなし。
まぁ、参考程度に・・・だ。

とにかく、長く続けられるところに行くのが肝心だ。

言い古された表現だが

　ダ　メ　な　や　つ　は　何　を　や　っ　て　も　ダ　メ

>>486
おまえもそのうち、いやでも岐路にたたされるって。
人生なにが起こるかわからん。
おれは機械屋に転職したけど、正しい選択だったよ。

>>484
他人の言うことを聞かない馬鹿が居るな・・・

>>488
信頼できる相手か判断せず、盲目的に指示に従う馬（ｒ

OpenCV で、
CvCapture hoge; がエラーになるのは何でですか?
CvCapture* hoge; なら大丈夫なのに

>>487
自分の過去の選択を正当化したくなる気持ちはわかるが、その返し方はちょっとかっこ悪い。
>>485で「全員にあてはまるわけでもなし」と言っておきながら、自らの主張には「いやでも」ってね・・・。
誰もお前の生き方を否定なんてしてないよ。

スレタイ嫁

人生絵巻とかいうオチか

: undefined reference to `__builtin_vec_delete'
collect2: ld はステータス 1 で終了しました

などと出てしまいます。

facedetector(linux).zip を unzip してできる
facedetecter 下に bin というディレクトリを作り
そこで
gmake -f ../Makefile したところ、
libdetect.a が無いと言われたので
facedetect/i386_linux1/libdetect.a を bin の下にコピーしました。

すると上記のようになりました。

そもそも、i386_linux1 下にバイナリがあるのですが、
例えば rot_test_ext を実行すると、
*** glibc detected *** double free or corruption: 0x080eeca8 ***
と出て abort します。
rot_test は普通に実行できてるみたいです。
B

画像処理は年とってもできるのかな
最近boostとか勉強してると、そうじゃないような気がするときがある

選択した範囲でマスクをつくる　というのをやりたいのですがさっぱりわかりません
画素ひとつごとに1か0を与えて作るらしいのですが･･･　言語はC++です

どなたか教えていただけませんか？　解説しているサイトでもうれしいです

>>496
あなたがどこまで知りたいのかさっぱりわかりません
マスクの目的は？

これはまた難しい質問だなぁ

マスクの目的はマスクでは？

もうちょっと具体的になにしたいのか書け。

正体を知られないようにかぶるもの
バレバレの場合もあるがな

領域内は　M(x,y) = 1
領域外は　M(x,y) = 0
とするマスクをつくって、各変換係数に対し
ビットシフトするというのを作りたいと思ってます

C言語をはじめたばかりであまりわからないのですが、
ビットシフトはなんの役に立つのでしょうか？

またこのネタかよ
やれやれだぜ。

いまどきαチャネル使う罠

Mask＝
vigra::Bimage に適当なfunctorを作って適用
functorはboost::functionで作る

>495
boost と画像処理に何の関係が？
C で書こうが、Perl で書こうが、C++ で書こうが、Java で書こうが画像処理は画像処理だと思う。
本質はアルゴリズムにあるのであってコーディングじゃないんじゃないかな？

使ってもSTLまでだなあ・・・boost使うほど複雑なのやったことねー

アルゴリズムのみが重要ならMatlabで実験すればいい。
Cで書かないといけない場合に最小の手間でコーディングするために
boostとかいろいろな便利なＴｏｏｌが必要になる

>>506
どうもです　試してみます

Cでboostですか……

cでなくてc++

C++ で書かなきゃならないときは、
無茶なチューニングのために面倒な記述をすることが多いので、
そのまま成り行きで結局 stl すらも使わないことが多いなぁ・・・

ちょっと反省してテンプレート使ってみるか。

OpenCVのコードみてると
汚いコードすぎで
気が狂いそうになる

綺麗にかけて、なおかつ高速な方法は
テンプレートだと思ってたけど、そうでもないのかな

クラスの継承とか使った時点で計算時間が遅くなってるのかな
誰か詳しい人教えて

>514
詳しくない人だが、質問の意図がよく分からない。
テンプレートと継承のどちらでも実現できることはテンプレートで実現した方が実行時の速度が高速になる
可能性は高いだろうと思う。
またテンプレートと継承を組み合わせている場合でも、ポインタを経由しない場合については静的に型が
分かるので効率はほとんど落ちないと思う。

>>514
どの辺を読んだの？
参考までに教えて．

hidhaarfeatureの関連

>>517
マニアックな所読んでるね〜。

ダメだ　さっぱりワカラネ
CxImage…
と言うかプログラミング

>>519
乙

OpenCVbeta4とOpenPNLを組合せて使ってる人いる？

OpenPNLがOpenCVbeta3のファイルを使ってるみたいで
OpenCVとOpenPNL両方のヘッダーファイルをincludeすると
コンパイルできない

解決策はないのかな・・・

すいまんせんが、ppxという画像形式について教えてください。
なんでもUnixでは標準的らしいのですが、どこにもファイルフォーマットの仕様が載っていません。
月曜までに32bitカラーの画像をppxで出力せよ、という宿題をもらいました。

> なんでもUnixでは標準的らしいのですが、
それ、たぶん嘘。

PPM(Portable Pix Map)?

MAG形式でいいじゃん('A`)

>>522
Unixで標準といえばこの辺かな。
ppm/pgm/pbm→ヘッダに最低限の情報をテキストで埋め込んだシンプルな画像形式。総称してpnmとも。
　　ppmはフルカラー、pgmはグレイ、pbmはモノクロ画像を扱う。それぞれ、テキスト版とバイナリ版がある。
xpm→Cのインクルードファイルとしても使えるように工夫された純テキストな画像形式。パレットカラー専用。
xbm→やはりCのインクルードファイルとしても使えるがこちらはモノクロ専用。

すまんppmだった。どうりでググっても出てこないわけだ。

ピーター・ポール・アンド・マリーだな。

>>443
突込みがすでにあるけど、圧縮じゃなくて、エネルギーを特定の基底ベクトルに
集中させる効果のことだね。（集中させておいて残りを捨てるから、圧縮になる）

画像の自己相関関数が、画素と画素の距離の遠さに応じて指数関数的に
減少する場合に、離散コサイン変換は、カルーネン・レーベ変換と一致する。

KL変換は、最小二乗法という観点で理論上の最適解だけど、圧縮対象の画像の
統計的な性質が変わると変換のための直交ベクトルが変わるし、計算も非常に
重い。

離散コサイン変換は、画像の内容に関係なく変換のための基底ベクトルとして
コサイン波を決めうちで使っているわけだけど、いわゆる自然画は、その
自己相関関数を調べてみると最初に書いた「自己相関関数が、画素と画素の
距離の遠くなると指数関数的に減少する」という傾向にたいてい従っているので、
結果的に、カルーネン・レーベ変換に近い性能を与えることができる（ことが多い）。


ああ、なんか変な日本語ですまん。
ためしに小さな共分散行列を作ってみてKL変換の基底ベクトルを求めてみて、
それとコサイン波を比べてみるといいよ。

>>522
もう月曜になっちゃったから自己解決したことでFA?

>>529
おお！非常にためになる解説！
自己相関が指数関数的に減少する場合DCTがKL変換と一致するって解釈は画像圧縮の分野じゃ常識なの?
初めて気がついたよ。

>>530
DCTとKLTの関係については、たぶんあんまり知られてないんじゃないかなぁ

この種の理論的な分析は、DCTがJPEGの基本技術として採用されるよりも前の
時代には盛んに議論されたけど、ひとたび規格になってしまうと、急速に業界
関係者の興味の対象からはずれてしまう。規格が決まったなら、大事なのは
実用化であって、いかにしてそれを早く軽く実装するかという方向に研究が移って
しまうから・・・

たいていの解説書は、『高周波成分を落としています』としか説明しないし、
それでいて、「だったら、なぜDFTじゃなくてなぜDCTなの？」　と、いう部分に
まで踏み込んだ解説はあまり見かけない。DCTを使うのはアタリマエという暗黙の
前提のもとに、もっぱら、DCTの高速算法に関する数学的な説明のほうに力を
入れているはず。

KLTを使った画像圧縮は、固有ベクトルを求めるのに
時間かかりすぎるから廃れたんだと思う。

解析的な手順で求まるDCTと違って、反復法でしか
値が求まらない固有ベクトルの計算は不安定(´・ω・`)

「水が飛び散る」という効果を考えているのですが、
距離で減衰させたりしてもいまいちリアル感が出ません。
なにが足りないんでしょうか?

>>532
つーか，基底ベクトルも保存せないかんから，DCTと比べて不利じゃね?
俺の思い違いなのか?

ん？　KTLがすたれたことを嘆いているわけではないぞ？？？
つーか、すたれる以前に、そもそも実用に供されたことは、ほとんどない。

圧縮にはあんま使われないみたいだけど，パタン認識の分野じゃメジャーな方法になってるよ。

>>534
例えば8*8ドット単位なら64次元だから64の基底ベクトルが必要。
でも寄与率の小さい基底を省略するから無問題。

>>533
手本があるのならば、その画像を例示せよ。
自分の脳内ならば、まぁガンバッテね、ぐらいしか言えん。
いいアルゴリズムができたのならば、特許なんてとらずに、
みなさんに公開してほしい、以上。

>>536
固有ベクトルというか、「固有顔」の足しあわせという形式で人間の顔データを
直交展開し、その展開係数の組み合わせによって人間を区別するという話とか？

（顔認識については、オレは完全に素人なので、勘違いだったらすまぬ）

主成分分析と一緒？

KL展開=主成分分析

ここでいいのかな・・教えて君ですいません。
小さな画像をまとめて、一つの画像にしたいのですが、
フリーのソフトとかでするんでしようか？

ここじゃないです

すいません、質問するまでもスレが1000になってたもので・・

誤爆・・スレ立てるまでも・・でした

>>542
ImageMagick

そもそも板違いだという。

>>546有り難うございます。
すいません、失礼しました。

教えてください。

２４ビット true color のビットマップを減色して２５６個のパレットをもつ８ビットのピクセル形式にしています。
パレットのエントリは予め決まっており、現在は NearestColor という方法で減色しています。

オリジナルのピクセルの色に「最も近い色」は、現在

distance2 = (r1-r2)^2 + (g1-g2)^2 + (b1-b2)^2

が最小になるようなパレットエントリを探して決定しています。結果には不満はないのですが、すべてのピクセルについて
distance2 を２５６回求めなければならず処理が遅くて困っています。なにか有効なアルゴリズムみたいなものを
ご存じありませんでしょうか。

メモリ無尽蔵で常にパレットの256色が固定ならあらかじめ24bitフルカラー16M色全ての最適色をテーブル化しとけ

>>549
distance2が0(或いは10程度以下?)になったらそこで打ち切るとか、
一度計算したrgb値はパレット番号とともにリングバッファに放り込んでおくとか。

回答ありがとうございます

> メモリ無尽蔵で常にパレットの256色が固定ならあらかじめ24bitフルカラー16M色全ての最適色をテーブル化しとけ

実際のところ、メモリは無人像ではないですし、パレットは減色したい画像によって変わります。

> distance2が0(或いは10程度以下?)になったらそこで打ち切るとか

０で打ち切るのは今もやっていますが、パレットエントリには微妙なグラデーションも
含まれていて、distance2 が一定以下で打ち切るのはやりたくないです

> 一度計算したrgb値はパレット番号とともにリングバッファに放り込んでおくとか。

これは意味がわかりません。オリジナルの画像のピクセル値は１万色を超える場合も
ありますので前に計算した値を保存しておいても有効ではないですし、探し出すのも
大変です。

色の値は実質 RGB 各一バイトの24ビットの数値です。これをソートして二分探索する
と速そうなのですが、B値に対してR値の誤差が過大評価されてうまくいきません。
distance2 は計算が遅いですが RGB 各値について等価です。

俺ならこんな感じの処理を入れるかな

vector<int> pal_list[16][16][16];
for(int i = 0; i < 256; i++)
pal_list[palette[i].r / 16][palette[i].g / 16][palette[i].b / 16].push_back(i);

for(int r = 0; r < 16; r++)
for(int g = 0; g < 16; g++)
for(int b = 0; b < 16; b++)
if(pal_list[r][g][b].empty()) pal_list[r][g][b].push_back(getNearestColor(r, g, b));

細かいことを言うと、もっと色々処理が加わるわけだが。

>>553
漏れならRGB夫々5bit（←古来より普通な感じ）か6bit(←最近ならこれか?)にする。

パレットエントリって幾つくらい？

そのdistance2が妥当とは思えないんだけど．

かわりのより妥当なものは？

>>549
ヒント： ボロノイ図

3次元ボロノイ図の高速な近傍探索アルゴリズムが存在するのか知らないけど、
とりあえず適当なことを言ってみる。

そうなんだよな。パレットエントリっていうのは、三次元空間に不規則に散らばった点。
任意の１点からみた最近接のエントリ探索と同じ論理

>>556
まじ？
わしも565か666bitでdistance2つかっているけど、代わりの手法があるなら是非知りたい

>>558
ニューラルネットで連想記憶すれば高速に探索できそう。

n次元空間におけるユークリッド距離が最少になるエントリを検索するって、
結局パターン認識とかと同種の問題になるよな。

で、パターン認識とかではどうやってるの？

オレがやってるのは以下の2手法。

・領域分割
RGBそれぞれ、上位4ビットだけを見た、4096(=16×16×16)の色空間ブロックに分解し、
それぞれの領域について、その領域内にあるパレットのリストを持ち、
検索色について、その色が所属するブロックと、隣接するブロックのパレットリストから検索する。

ブロック内に検索対象パレットが存在しない場合の処理はちょっと面倒。
厳密解じゃなくなるけど、領域立方体の頂点になる8点のそれぞれについて、最近傍になるパレットを算出しておき、
その中から探してる。

・キャッシュ
ハッシュで、今までに検索した「色→パレット番号」の履歴を保存しておく。
全ピクセルに持ってたらやってられないので、LRUで使われてないエントリは消していく
正しくは、ハッシュじゃなくて、衝突したら古いのは消してるけど、
65536エントリぐらいあれば、滅多に衝突しないので結構使える。


「オリジナルの画像のピクセル値は１万色を超える場合」ぐらいなら、
1万エントリを記憶できるキャッシュだけで十分な気がする。
640x480でも、30万ピクセルから、30倍は速くできるな。

>>564
549じゃないけど参考になった。トンクス

私は手抜きハッシュです
ハッシュ値は以下で求めてます
(B & 15) + ((G & 15) << 4) + ((R & 15) << 8);
値がダブった場合は上書きしてます。

>>550
VGA(32万画)の場合は相当無駄〜な計算することになるけど。
実に50倍以上。

５４９です。
回答下さったみなさん、ありがとうございます。
ハッシュは、すぐに試せる出来合いのコンテナクラスをつかって 文字列−値 の
ものをつかったので処理速度はともかく、画面で見る限り、かなりテーブルの
コリジョンが起こっているらしく、ノイズがのりました。

ハッシュ値の工夫をして、色データ：エントリ番号 の構造にトライしてみます。

ブロックによる区画化は、すぐに実装出来ないので気長にやってみます。

ありがとうございました。大変勉強になりました。

>>566
手抜きだけど、シンプルで高速そうですね。
コリジョンがどの程度起きるか気になるところだけど、ちょっと感動。

メジャーな方法なんですか?

>>539
遅レスかつ個人的な見解ですまんけど。

識別問題に第k成分まで使ってパラメータ空間を〜なんてやつは眉唾。
SVD使う事には反対しないけど、固有ベクトルの選択方法を誤ると識別性能はがた落ちするよ。
例えば、二次元平面上に二つのクラスがV字上（それぞれの直線上にそれぞれのクラスのデータが存在）に分布してる場合、第一主成分はV字の真ん中を通るベクトルになる。
こいつにデータを射影すると見事に二つのクラスが混合しちゃうわけで。
うまく性能でないから固有ベクトル増やしてマハラノビス〜とか目も当てられない。

５４９です。５６６さんとは違うハッシュ値なんですけど

> コリジョンがどの程度起きるか気になるところだけど、ちょっと感動。

ハッシュ値の発生方法にも依るんだろうけど ５５０ｘ４００ で４３７１９色の場合
１％程度のコリジョンでも、画像上ではかなり目立ちます。これだったらハッシュ法は
採用したくないです。まだ改良の余地があります。

あと、元画像からどの程度最適化されたパレットを得るかにもよりますが、最適化がかなり
よい場合は区画化のほうが有効のような気がしてきました。すくなくても、自分の色の値から
近いところから検索を始められるのはかなり有利なようです。こっちをまずやってみようと
思っています。

>>569
SVMによる判別分析は、事前にカーネルで高次元空間に
写像してから行うのが定説だと思うけど(´・ω・)？

>>568
画像依存ですがヒット率は5割〜8割だった記憶が。(まあ、5割でも単純計算で2倍速ですが。。。)
ビット数を増やせば増やすほどヒット率は上がっていきますが、1次キャッシュに載る程度のほうが速かったのでそんな感じに（＾＾；
自分で考えて実装したものですけど、きっと誰かの車輪の再作成になっていると思います。

コリジョンしたら再度distance2を256回やる羽目になるだけで画質の影響はないんでは?
全部覚えるパターンは拡散誤差を入れると色数が膨大に増えてメモリを食うのでやめた。

>>568
最適な画像ではなく単に速さだけでよいなら、5:5:5の15bitのハッシュ（テーブル）を
用いて32K色 -> パレットエントリへの変換を行い1ピクセル出力した後、出力した色
と出力すべき色の誤差を拡散させて処理を続ける、という誤差拡散で済ませるのが
良いと思います。

フルカラーから32K色へ落とす処理としては、単に各色5bitで量子化するほかに、
パターンディザを用いることも可能です（フルカラーの自然画像に対してはあまり
良くないけど）。

なんか微妙に話題がずれてる

>>574
一瞬、ずれているとオレも思ったが、>>573の提案は、
「前処理としてRGB独立の減色でまず32K色まで落とし、
32K色に対する変換テーブルで、目的のパレットに
変換する」と、いうことだと思う。

そうか？

> フルカラーから32K色へ落とす処理としては....パターンディザを用いることも可能です

とかで、ディザつかってそれからパレットエントリを求めるって倒錯じゃないだろうか

誤差分散やパターンディザは、パレットエントリ決定後の最終処理だと思うが

2枚の画像をアフィン変換により合成する方法を教えて下さい。
参考になるようなWebページがあれば教えて下さい。

>>578
http://google.com/

ヒストグラム作成→色空間分割*255によるパレット生成→誤差分散しながら各画素のパレット番号決定

という流れが普通かなあ（＾＾；
ヒストグラム作成時にある程度間引くのか、現代のメモリ満載PCなら大丈夫と完全ヒストグラムを作るかは選択だと思うけど

今はパレット生成の話はしてないよね？

>>576
倒錯ではあるんだけれども、任意のパレットに対して適切にパターンディザを
行うのはコスト大なので。

代替策としてRGB各5bitへの量子化のときにパターンディザで処理しておくと、
マッハバンドのとことかそれなりにパターンディザっぽい画像が得られる。

それは話が逆。ディザを得るのは目的じゃない。一種の誤差修正なんだから。
パレットエントリを決定する前に、原画を細工してディザを加えるのは全くナンセンス

>>583
「パターンディザ」っていうのは、表現方法の一種として
ディザを得ることを目的とする場合に使われるもんだと思うけど・・・？

それなら最初から話題からずれてるよ

>>583
まあまあまあ・・・

ナンセンスとまでは言えないよ。そりゃまあ、「処理の順序が逆じゃないか！」
と、言いたい気持ちはよく分かるし、オレも、あんまりやりたいとは思わないけど。

ディザや誤差拡散をサポートしていない減色ツール（あるいは減色ハード）や
二値化ツール（二値化回路）を使わざるを得ないときに、オリジナルの画像に
ノイズを載せてから減色することもないではない。

>>584
いや、そういう話をしているわけじゃないんだが。583氏が問題視しているのは、
画像処理のどの局面で交流バイアスを与えるか、と、いう順序の問題のはず。

パターンディザは視覚的効果のために用いられることがある、
っていう基本的なとこが無視されてるような気がしたので。
(そもそも変換誤差最小を目指さないということ)

任意のパレットに対するパターンディザ風の処理を、
>>583の主張するようなやり方で行う(現実的な)手法って、知られてるのかな。

>>587
視覚的効果のために使うって、本当にそんなに使う？

映像上の特殊効果としてカラーの画像の装飾的なパターンを
重ねる場合なら、そもそも減色なんてしないよなぁ・・・

おそらく、

> パターンディザは視覚的効果のために用いられることがある、
> っていう基本的なとこが無視されてるような気がしたので。

ってのは、基本的なことではなくて、周辺領域の話じゃないかな。
基本は、ノイズシェイピングの手段としてのディザだもん。

画像関係のツールやライブラリやLSIを設計していると、ついつい、
深みにはまって、ディザだの誤差拡散だのに、多芸な機能を盛り
込んでしまったりするけど、まあ、はっきり言ってユーザーからは
必要とされてない作り手の遊び。自戒を込めていうんだけどね。

画像処理初心者です。
ある画像について、画質を評価したいのですが、
元画像と圧縮後の画像の比較や、光学系機器通過前と後の比較などといった
複数の画像間で定義されたものではなくて、
一つの画像に対して定義された画質の指標というものはありますでしょうか？
漠とした質問ですみません。

エントロピー

官能試験しかしらない。

549です。

パレットエントリを予め区画化しておいてから、最短距離を求める564氏の領域分割の提案を試しました。
テスト使ったのは、
・画像１ ＝ 色の種類は少ないが微妙なグラデーションが多い人物写真 336ｘ560、 51952色
・画像２ ＝ 色の種類は多いがグラデーションが少なめの街並み写真 512ｘ384、104730色

２５６色への量子化によるパレットエントリの決定
Gervautz-Purgathofer Octree Color Quantization Algorithm（http://www.microsoft.com/msj/archive/S3F1.aspx）

単純な巡回によるエントリ番号の決定では量子化過程も含めて 画像１ で 3723ミリ秒、画像２で 3870ミリ秒
かかります（私のPCでの３回の平均）。

今回は区画を区切ってオリジナルピクセル値が属する区画にエントリが存在するときはその中の最短値を、無い場合は
２５６回巡回するという単純な論理です。

RGBそれぞれ上位４ビットを使って４０９６区画の場合は、画像１は890ミリ秒、画像２は1437ミリ秒と３，４倍の効率化
上位３ビットの５１２区画の場合は、画像１は274ミリ秒、画像２は287ミリ秒と実に１３倍の効率化
上位２ビットの６４区画では、画像1が665ミリ秒、画像２が587ミリ秒と６倍くらいの速さです。

画質は、４０９６区画の場合は単純巡回の場合とほとんど同じですが、画像１では微妙なグラデーションに差があります。
５１２区画ではグラデーションの差が拡大しますが画像２では見分けがつきません。
６４区画では、さらに単純法よりグラデーションの結果が異なりますが、やはり画像２では見分けがつきません。

この方法の成否は、オリジナル画像からのパレットエントリを決定する量子化過程が重要です。その意味でも上記の量子化
は満足すべき結果を与えてくれました。なにより、今回の質問の処理よりものすごく高速です。

以上より、RGBおのおの上位３ビットを採用する512区画にすることにしました。最終的には誤差分散をしているので
得られる画像は単純法と見分けがつきませんし、１０倍以上の速さは体感速度としても十分で大満足です。

みなさん、ありがとうございました。

>>589
解像力を見るなら画素値の差の平均とか、ヒストグラムの形状とか。

>>592
俺(=553)が書いたのは564の方法そのものなんだけど、

＞今回は区画を区切ってオリジナルピクセル値が属する区画に
＞（中略）
＞無い場合は ２５６回巡回するという単純な論理です。
これは前処理で先に計算しておける。（553の後半）
553では端折って区画内の代表点に一番近い色だけにしているが、
実際には区画内の色が一番近くなる可能性のある色全てを求めて
おく必要がある。
これをやってないから
＞４０９６区画の場合は、画像１は890ミリ秒、画像２は1437ミリ秒と３，４倍の効率化
これが遅くなっているんじゃないかな。

あと、564も書いているけど、エントリが存在する区画では、同じ区画内だけでなく
隣接する区画からも色を探さないといけない。
同じ区画内よりも、隣の区画に近い色がある可能性があるため。
これをやれば
＞画質は、４０９６区画の場合は単純巡回の場合とほとんど同じですが、
＞画像１では微妙なグラデーションに差があります。
これも解消されるはず。
ちなみに、この処理も前処理で可能。予め隣接する区画をマージしておくだけ。
本当は計算しないといけない区画は隣接する区画全てではないし、隣接する区画を
計算する必要が全くない場合もあるが、条件分岐等を入れるよりは速くなると思う。
ある程度区画が細かくてパレットが綺麗に分散していれば、ほとんどの区画が
隣接区画全てをマージしても変化無しのはず。

549＝592 です。

> 俺(=553)が書いたのは564の方法そのものなんだけど、

はい、実はあのコードだいたい分かったのですがわたしは C++ ユーザじゃないので
ちょっとその・・・。失礼しました、ありがとうございました。

あとは、おっしゃってる意味は分かります。該当エントリに無い場合はどうするか、
あっても、最短エントリがそこにあるとは限らない、っていうことは理解できます。

今回は、なるべく単純にしたので、無い場合は２５６回にしてしまいました。

区画を細分化すると、エントリが無い場合が多くなり、今回の方法では時間がかかり
ます。逆に大雑把にしていくと、単純巡回に近づいてやはりスピードダウンします。
今回のような方法では、パレットエントリの数と区画の数がコンパラな場合が具合
いいだろう、とだいたい予想がつきますよね。

あっても無くても周囲を見るならはじめから周囲を含む区画にしておく、というのは
ちょっと考えただけでも等価じゃないですね。

あと、パレットエントリを決定する色の量子化がかなりよいものだと、今回の画像１の
ような場合は、RGB三次元空間の中でパレットエントリがかなり局在化します。あらかじめ
格子点の最短距離をもとめておくのはなんか無駄なような気がしていますが、どうなんでしょうか。

失礼しました。もうすこし周囲の区画を見ることをやってみます。

>>595
エントリの無い区画に対して予め計算しておくのが遅くなりそうなら、
初めてそういう区画の処理をしたときに、情報をキャッシュしておくといいかと。
どんな種類の画像でも、似たような色というのは何度も出てくるから、
キャッシュの効果はかなりあるはず。

549＝592=595です。

で、できました！
５９４氏の指示通り、予め該当区画を囲む計２７区画のエントリをマージしておくことにより、

４０９６区画で画像１、画像２とも単純巡回法に比べてちょうど１０倍ほど高速になりました。
画質は単純巡回のときと全く同じです。素晴らしいです。

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

>>596

ご教示ありがとうございます。今回は上に書いたとおり、予めエントリ番号の方をマージしておく
ことにより周囲を見回すことが出来ました。

549=592=595=597です。

数値で記録を残しておきます。自宅PCです。

画像１ ２９３３ ----> ２９６ ミリ秒
画像２ ３０３４ ----> ３０９ ミリ秒

これは色の量子化過程を含んでいるので、純粋に NearestColor の方法
としてはもっと高速化されていると思います。

すみません、あまりにうれしくて、みなさんご存じの

"Lenna" 画像も試してみました。５１２ｘ５１２，１４８２７９色

３９５６ ----> ４８２ ミリ秒 でした。

ほんとうにありがとうございました。ここで質問してよかったです。

その嬉しさのお裾分けに、ソースを公開したらどうだろう。

>>600

承知しました。今晩までお待ち下さい。
ちなみにソースは Delphi です。
C++ ユーザの皆さんもパスカルは擬似コードとしても読めると思います。

549ではないが、LBGクラスタリング使った自作減色プログラムに564+594を適用したら20倍程度速くなったよ
区画処理＋マージ処理＋キャッシュをフル実装。
512×768のエロ画像で検証。ありがと。

549=601です。

ソースとその実行例をわたしのブログにアップしました。

http://blog.livedoor.jp/junki560/archives/28012729.html

その他のOctreeによる色の量子化やイメージ処理用のライブラリは、
示してあるリンクから全ソースがダウンロードできます。

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

ハイビジョン対応キャプチャーボード　PV2　３枚目
http://pc8.2ch.net/test/read.cgi/avi/1121329158/

>>590, >>591, >>593
ありがとうございます！
画素値の差の平均というのは、隣接する画素値についてですかね。
とりあえず、頂いたキーワードで論文など探してみたいと思います。

エントロピー最大の白色ノイズは高画質ですか？
絶対的な画質の指標ってのは難しいね。

>>564 >>549
どうにも速そうなので実装しようと考えて隣接8ブロックだけではまずそうなことに気づきました。
以下が隣接8ブロックではダメな例。

[16,16,16]と[48,31,31]というパレットエントリのみがある場合に[31,31,31]の
パレット番号を探すと自動的に[16,16,16]になる。
([31,31,31]は[16,16,16]の区画でかつ[48,31,31]は隣接区画ではない)

ところがdistance2は
distance2([16,16,16], [31,31,31])=675
distance2([48,31,31], [31,31,31])=289

ちゅうか、隣接26ブロック？

あぁ、確かに隣接だけだと駄目だね。
同じ区画内で最も遠い2点は√3の距離にあるから、
2つ隣まで届いちゃうね。

ま、区画化＋マージはそういうロジックでエントリを見つける。ということで納得すると。

パレットエントリの数が少ないとどっちにしろ単純に計算したほうがいいだろうし

中心の区画からみて立方体じゃなくて球で切り取るとすると、２７区画マージのつぎに
精度を上げるのは何区画にするべきだろうか

√3の距離は頂点方向だから、この方向は頂点を接する一区画で十分だから面方向に
あと一区画ずつ足すと２７＋９ｘ６ ＝ ８１区画ですか？

あーそうでもないか、頂点から√3の距離すべて覆うには８１区画じゃ足りない。
５ｘ５ｘ５ だと完璧だけど無駄なところがあるかも

局所平均をとるときに、３×３より５×５でやったときの方が画像がぼけるのはなんでですか？

それがそのまま答えだと思うが

ツ、釣りだよね.......

1x1 だとなぜぼけないか、考える！

先生、2x2だと何故か移動します。

>>614
ぼけてるのはお前だ

釣りだと思うけど、真面目に答えようと思うと「ぼけとは何ぞや？」という
命題にぶつかってうまく言えないなぁ

実は、かつて
「高周波成分が落ちると、なぜボケるんですか」
と、質問されて返答に困ってしまったことがある・・・

ｳｪｰﾌﾞﾚｯﾄで画像圧縮するソースプログラムくださいませんか。
急用なんです。お願いします。

>>621 宿題は自分でやれ。
>>621 仕事は自分でやれ。
>>621 とにかく自分でやれ。

http://www.cs.kuleuven.ac.be/~wavelets/

http://www.geoffdavis.net/dartmouth/wavelet/wavelet.html

http://www.dip.ee.uct.ac.za/~brendt/srcdist/

>>614
とりあえず1次元で考えて、フィルタカーネルの離散フーリエ変換（≒周波数特性）を計算してみるとよい。
単なる移動平均フィルタの場合、カーネルが長くなるほど高周波成分が早く減少するのがわかる。
「高周波成分が落ちると、なぜボケるんですか」といわれたらそれまでだがｗ

>>626
おまいさんの使ってる言葉が理解できるような人間ならそもそもあんな質問しねーよ。
ちったぁ物考えろ。

OpenCV + IPP + Intel C コンパイラ
が　行列計算でも最速って本当？

>>628
結構早いですが、最速かどうかは知りません

>>628
画像処理に特化せず、科学技術計算関連だったらMKL+ICCの方がいいと思うよ。

>>620
「かつて」ということなので今はその命題をクリアしてるのでしょうが、
ボケという現象を、顕微鏡の対物レンズのNAと分解能の関係からナイスに説明できませんでしょうかネ。

いきなり顕微鏡なんて持ち出さずに、
普通のカメラの被写界深度と錯乱円の関係でも考えてみたほうがいいんじゃない？

原図より高周波成分が落ちることを、ボケる、と定義する

>>631
「かつて」の真意を読み違えているな

「電話の声はモワモワして聞きとりづらいダロ」
というのは、どーかナ。

bmpで縦軸を中心に反転表示させたいのですが無理です。
どなたかできるようにしてもらえますか？

○|￣|＿　⇒　＿|￣|○

こんな感じにさせたいのですが･･･

すいません追加です。
http://kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/img/783.txt
できていないプログラムです。
※無限ループ入りますorz

forのある行に対応するコメント書いてみろ

ひゃぁ〜、久し振りにグローバル変数を関数の戻り値の代わりに使うプログラムを見たよ。

>>636
横着せずに、一旦メモリ上に読み込んでから反転処理をし、その後ファイルに書き出した方がいいぞ。
それから、言語の勉強もしような。

線に強弱が付いた(=場所によって太さが違う)ベジェ曲線を描画したいのですが、
これという手法があったら教えていただけないでしょうか

まあがんばれ

>>640
それ俺も知りたい

>>640
習字で書くような力強さのある字なのか、
それともある法則で書ければよいのか。

>>642-643
お付き合いありがとうございます。
強弱の値自体は機械的なのですが、それでもどちらかというと習字っぽい方が理想です。

ここの猛者の前では恥ずかしいのですが、一応今迄やって失敗したやり方を書いておきます。

(a)強弱の値に大きさが比例した円を、ベジェに沿って敷き詰める
(b)ベジェを直線で近似し、各直線を元に強弱に応じた台形っぽいのを作り、台形を塗りつぶしで描画する

(a)はベジェのパラメータのデルタが上手く取れず、最悪に備えて無駄がもの凄い生じてしまうか、
あるいは無駄を出さないように円間の距離を一々測ったりで重くなってしまいました。

(b)はつなぎ目がどうも上手くいきませんで・・・
また、ちゃんと前の線とつながるような台形を作ろうと思うとやっぱり重く

(a)(b)とも何かを参考にした訳ではないので、もの凄い無駄をしているんだろうなと思います。
改めてよろしくお願いします。もちろん(a)(b)は無視してください。

とおりかがりのもんですが。
●曲線の法線から、その半径の距離だけ離れた点を求める。
●その点に対してベジェ曲線で補完する。　
●こうしてできた閉領域を塗る。
という案はどうですか？

眠い頭に浮かんだいい加減な方法。検証無し。

ベジエ曲線上の各点P(i)に対して、法線方向にP(i)での太さだけ進んだ点をP'(i)とし、P(i)からP'(i)とは逆方向にP(i)での太さだけ進んだ点をP''(i)とする。
点列P'(i)に対して最小二乗法などを適用して適当な曲線にする。P''(i)も同様。
これら2本の曲線に囲まれた範囲を塗りつぶす。

太さの変化や曲線の変化が激しいところでも誤差を保障するのは面倒。
素直に各点で円を塗りつぶしたほうが速いかも。

というかP'(i), P''(i), P''(i+1), P'(i+1)を結ぶ台形でいい気もする。
正確さにこだわるなら別だけど。

>>644
(b)の線で高速化を考えるのが良いかと

(b)はAutoCADのポリラインそのもので、AutoCADでは台形の連続でも継ぎ目を補間しつつ、
高速に描画しているので、速くする方法があるんでない？
どう高速化するかまでは知らんけど、AutoCADのプログラマとの知恵比べということで。

>>640
細かいことだけど、ベジェじゃなくてベジエ（ベズィエ）ですよ〜

>>649
Googleで検索してみますた

ベジェ の検索結果 約 30,500 件
ベジエ の検索結果 約 10,500 件
ベズィエ の検索結果 約 31 件

ベジェ優勢のもより・・・どーでもいいけど

俺は会話でも「ジェ」を一体化せずにちゃんと「べ・ジ・エ」と3音で発音してるぜ！

英語読みだとベイズイェイじゃねーとか言われるので、外国語をカタカナに開くときの表記に文句つけるのはやめといたほうがいーぞ

ラルクアンシェルと発音して笑われる>652がいるのはこのスレですか。

発音や表記の問題はすれ違い

発音スレはここですか？

どーでもいいことだけど，P(i)うんぬんの
　　　　　　　(i)
がまんこに見える。

きみきも〜

使用前
( | )
使用後
((i))

がまんこ　って何？　かえる？

>>653
普通はラルカンシェルだよな。

キミルソン・キムジョギル親子について

がまんこ　の使用前を脱がさないで
画像認識するにはどうすればいいでしょうか？

つまらねえ方向に脱線するのうぜえ！夏の害虫どもコロスゾ！！

>>663
コロスゾなんてネット上で煽っても意味ねーじゃん。（ﾌﾟｹﾞﾗ
うぜぇならごちゃごちゃ言わずにネタふりゃいいじゃん。

申し訳ないです、昨日は修羅場で家に帰れずじまいで。

皆さんのレスを一通り試させて頂きました。
曲線補完の方法は勉強不足のため、まだどうも上手い具合に行ってません。
どうも太さの比率にムラが・・・。今度の休みに資料を集めて再挑戦してみます。すいません。

とはいえ、直線で近似したあと、>>645-647の方法(台形仕上げ)を使わせて頂いたところ
私の低スペックPCでも一瞬で綺麗な線を描画することができました。
印刷目的じゃ無いならば、もうこれで御の字のようです。

AutoCADの方には適いませんが、これからカリカリにチューニングしてみます。
皆さんレスありがとうございました。

今見たら646は645そのものだった……orz。やはり眠い頭で書くもんじゃないな。

windowsでlibjpegを使ってjpegを操作したいのですが、
jpgsrc.v6b.tar.gzをダウンロードし、Cygwinでconfigureを実行後、make→make install
としたのですが、その後いったいどうすればいいのかわかりません。

jpeglib.hをincludeするだけじゃだめなのでしょうか？
makeしたファイルたちをどこに保存しておくのかもよくわからないのですが
どなたかご教授御願いします

>>667
その質問は画像処理とは殆ど関連性がないのでcygwinスレへでもどうぞ。
つーか、libjpegを使ったサンプルとか使い方を書いたページくらい検索すれば出てきそうだが。

>>667
cygwin使わなくてもいいんだけどね。makeしたらライブラリが出来る。
それを組み込まんことには始まらんよ。
しかし、プログラム書いて実際に使うまでの説明が長いからしない（ﾏﾃ

jpegなんて劣化フォーマット仕事じゃ使わんけど、
libjpeg自体を使うのはlibpngに較べれば楽じゃない?
まぁ初心者はImageMagickでも使っておけってことで。

あるいはファイル入出力だけでもVCLつかっとけ、かな？

>>670
libtiffも使い勝手悪い。
lib〜は画像フォーマット理解して使うなら容易いが、
素人が使うにはきちんと勉強しないといけないよ。>667

画像をいろいろ操作したいのに、画像を読み込むところで立ち往生していても
仕方ないのでとりあえずjpegはあきらめbmpを扱うことにしました。

Windows上でWin95とか切っていいなら素直にGDI+使っとけ。

opencv のコードって GPL ライセンスのソフトに組み込んで配布して問題ないの？

Intel オープンソースライセンス (Intel Open Source License)
http://gnu.open-mirror.com/licenses/license-list.ja.html
は問題ないみたいなんだけど...。

ここらへんややこしすぎ、独自ライセンスは勘弁して。

CxImageとかFreeImage使えば次のように簡単に読み込める。

CxImage image;
image.Load("test.jpg",CXIMAGE_FORMAT_JPG);

中国サイバーテロ!!?
http://gazoubbs.com/publicity/img/1122394400/6.gif

個別訪問を行いたいと思っております。

★拠点
【お盆】中国バカーVS日本ビパー part111+【仏降臨】
http://ex11.2ch.net/test/read.cgi/news4vip/1122479952/

民間の反日系中国ウエッブサイトへの抗議をしてくださる、お持ちの知識・技術を活用してくださる　等

・　・　・　・
日　中　友　好　　目的　での、ご参加をお待ちしております。

3DCG の実装について勉強したいのですが、お勧めの教本があったら教えて下さい。
目標は、フレームバッファを直接叩いて自力でポリゴンモデルを表示する所までです。
これ↓は良さそうなのですが、ちょっと範囲が広い（３・５・６・１５章だけで
十分そう）ので、もっとライトな奴は無いでしょうか?

http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?&ISBN=4-274-06405-0

>>678
基本としては、アスキーの応用グラフィックス
ttp://www.amazon.co.jp/exec/obidos/ASIN/4871481999
を薦めたいところだが、今でも入手できるのかなぁ…

>>679
どうもありがとうございます。他のオンラインブックストアでも品切れでした。
取り敢えずはウェブで勉強して、時間がある時に書店巡りしてみます。

>>678
ttp://www.amazon.co.jp/exec/obidos/ASIN/4781910807/
これなんかはかなりライトだけど、実装の参考にするには
ちょっとキツいかな。最小限の数式しか書いてないからね。
概要を知るには、いい感じだが。

ＮｘＭの長方形のテクスチャを、角度ｘ長さのテクスチャとみなして、
それを半径がＲの円に綺麗にマップしたいなと考えています。

円の中心付近は、元テクスチャーの多くの色を平均化する必要があり、
円の外側付近では逆に色を補間してやる必要がありそうです。

なんだか、ＭＩＰＭＡＰとか異方性フィルタとかって関係ありそうな気がしますが、
あんまり良くわかってません。
こういう場合のやり方の定番ってあるんでしょうか？

>>682
それは自分でレンダラを書くという話？

GUIを用いた静止画像・動画像処理を勉強するためのお勧めの本とかありますか？

GUIと画像処理は分けて考えた方がよいとおもうけどな。
GUIまわりは開発環境で全然変わってくるから、普通のプログラミング入門書を使えばよいと思うけど。

>>683
レンダラ書くんだったらソース読むべきじゃないかな。

蟻の行進はどうやって実現したらいいんですか。
いろいろ考えているのですが、わからないのです。

>>687
まずは状況説明をきちんと汁

ひとりごとなので、気にしないでください。

WinExec("mplayer.exe 蟻の行進.wmv");

>>687
群体シムやりたいなら、boidsとか調べてみたら？
まぁ、蟻の行進の場合は線に沿って歩くだけだから
あまりそういう手法は必要なさそうだが。

グラフィック選択中の表示だろ？

>>687
素人考えですが、こんな感じでプログラム作るとおもしろいかも。

i は蟻の行列の先頭からの順番を表す
i番目の蟻の位置を　p(i) で表す
i と　i-1 の距離を d(i) = | p(i) - p(i-1) | とかする
i番目の蟻の速度 v(i) を　d(i) の関数で表す
1時刻先の位置 p'(i) := p(i) + v(i) とかで求める
関数 v(i) を非線形な奴 ( v(i) = d(i)^2 ) にするとおもしろそう
あと，なんかの拍子に止まるようにするとか

>>692
そーいう質問だったのね（ｗ

画像処理ライブラリーvigraの
vigra::BORDER_TREATMENT_WRAP
まわりにバグある気がするんだけど、誰か使ってる人いる？

>>695
詳しく。

vigra::Kernel2D<float> average3x3;
average3x3.initExplicitly(vigra::Diff2D(-1,-1), vigra::Diff2D(1,1)) = 1.0/9.0;
average3x3.setBorderTreatment( vigra::BORDER_TREATMENT_WRAP);
vigra::convolveImage(srcImageRange(image1), destImage(image2), kernel2d(average3x3));
コンパイルは通るけど落ちる.

average3x3.setBorderTreatment( vigra::BORDER_TREATMENT_WRAP);
しないとちゃんと動く

>>692
点線のラバーバンドってこと?
あれって、蟻なのか……

>>698
見てみたらgimpだとmarching antsと表現されている。marching antsでぐぐってみるといくつか引っかかるので英語だと普通に使うのかもしれん。

>>699
PhotoShopとか初代MacPaintなんかでは、
破線がウニウニ動いていたからmarching antsなわけで、
Windows の Paint のような単なるマウスで伸び縮みする
破線は rubber band でいいような。

PhotoShopでは枠のところを region にして、
何種類かの白黒斜め線テクスチャでアニメートさせて
塗りつぶしてるみたい。

あまりに良く見かけるので、OSの標準APIか何かだと思ってたよ

>>687
質問しておきながらしばらく書き込みできずに申し訳ありませんでした。
ここのスレの皆様ならどのような方法で蟻の行進を実現しているのか気になり
質問させていただきました。
ご返答いただきました皆様、深く御礼申し上げます。

>>700
>PhotoShopでは枠のところを region にして、
>何種類かの白黒斜め線テクスチャでアニメートさせて
>塗りつぶしてるみたい。

なんという貴重なご意見・・・どこで仕入れたのですか？？

>>700
ちなみにもちろん後者の正当な蟻の行進の実装を目指しております。

連続投稿大変申し訳ありません。

テクスチャ方式を考えてみたのですが、もしそのテクスチャの斜め線と平行に
範囲選択をした場合、その平行面は黒なり白なりの一色になってしまうことは
ないんですかね・・・・。

フォトショップでもそうならなかったっけ？

PS7で試してみた。斜めに選択範囲を作成すると、
テクスチャと線の角度が平行になった場合、線全体が白と黒の交互に点滅する。

>>705-706

こんなに早くご回答頂きまして誠にありがとうございます！
私はPSを持っていませんでして、すぐに試すことができない
状況でした。本当に感謝いたします。

やはりそういう結果だったのですね。ならばその方式で実装を
考えたいと思います。

なんとか実装できました暁には、こちらに稚拙なソースコードに
なるかと思いますが、ご報告をいたしたいと思います。

>>702
デベロッパユニバーシティだったり

>>704
実際、手元の PhotoshopLE で、ひし形の選択領域を作ってみたら
分かるけど、ご想像の通りのことが起こるよ。斜めの境界線は、
白と黒の点滅になる。

それを避けようと思うなら、選択領域の形に応じて動的に縞模様を
作る必要があるだろうけど、まあ、そこまでしなくても・・・

「境界線」がわかれば、あとはラインスタイルを変えつつ線をひくだけでできるね。

「領域」から「境界線」を抽出するのはちと面倒だけど。

画像処理ライブラリーvigraのメーリングリスト
に登録したのに反応がいまだまったくない。
誰か登録できた人いる？
ＭＬにメール流れてないだけかな

実は登録してるのが711だけというオチ。

C言語　JAVAで
読み込んだ画像に任意の文字列を挿入して出力する方法を
教えてください

>>713
質問があいまいすぎます

>>713

img = LoadImage("./image.bmp");
img.string(100,100,"ぬるぽ");

>>715
言葉足らずの質問に返信ありがとございます

ちょっとそんな便利な関数がWinにはつかえるんですね

cvIntegralの中で
sum[-1] = 0;
sqsum[-1] = 0;
定義されてない配列要素に値が代入されてる気がする
大丈夫なんだろうか

cvsumpixels.cpp
の前半あたりが、疑問のところ

cvIntegralを知らずにカキコ。
operator[]が定義されてるんじゃねーの？

vigra本当に誰も使ってないの？
かなり深いところまで使ってしまったので
後戻りできないのだけど・・・

viagra?

初歩的な質問ですみません、以下のＵＲＬに載っている問題なのですが
良く分からないので教えていただけないでしょうか？
ttp://www.cgarts.or.jp/exam/result/extant/2005-1/2nd.pdf

分からないのは第９問の問ｃです。
モザイク効果を施した絵を選ぶ問題で、正解は「オ」となっているのですが、
私にはモザイク模様が見えません。

モザイクって、ニュースで車のナンバーとかを隠すのに使われる奴ですよね。
それとも、もっと別の高度なモザイクの手法があるのでしょうか？
よろしくお願いします。

>>722
印刷用のPostScriptファイルからPDFに変換した際に画像の解像度が低下して、
原画像とモザイク処理後の見分けが付かなくなってしまったのだと思う。
PDFを作った担当者がAcrobat Distillerの最適化オプションについて無知だったんだろうね。

OpenCV beta5でてるね
beta4で開発したライブラリから、そのまま置き換えられるかな

>>723

明快なご説明ありがとうございます。
なるほど、ＰＤＦ作成時のミスでしたか。
世の中には私の知らないモザイク処理があるのかと焦ってしまいました。
問題の方が間違ってるって事もあるんですね。

それぞれの分野ごとにいろんな行列計算ライブラリーがあるの
なんとかならないのかなあ

> なんとかならないのかなあ

他力本願じゃどうにもならんわな

ちょっと聞きたいんだけど

カラー画像のC言語でのクラスタリング（特徴空間内で距離が近いデータをまとめグループ化するための手法）
に詳しいサイトとか書籍ってないかな？

ほい('A`)ノ ttp://ocw.u-tokyo.ac.jp/course-list/engineering/applied-acoustics-2005/lecture-notes/D3-VectorQuantization.pdf

>>729
不親切なやつだな(w
クラスタリングとVQは違うだろ・・・
紙一重だけど。

Visual CでBMP形式からRGB形式かHSL形式に変換するプログラムが必要なんですが何かいい方法教えてください。

>>731
つ[google.com]

>>728
Cマガ2000年７月号にソースがのっとる。ただし、そのままでは遅すぎて使い物にならない。
結局説明だけ参考にコード書き直して何とか使える速度を出した。

最近
>>600
前後の手法を参考にさらに高速化して、100万ピクセル程度なら２〜３秒でクラスタリングで
きるようになった。

>>731
BMPファイルを読み込んで、RGB形式かHSL形式に変換して
ファイルに書き出すといいよ。

DelphiでDLLを作って、Visual Cのバイナリから呼び出すといいよ。

初心者巣スレでこちら向きの質問だと指摘されました。
質問です。

メタセコイアで使用している色設定のコントロールのようなものを
自前で作成したいのですが、カーソル位置からRGBにどのようにして
変換しているのかわかりません。
あのような色空間はどのような基準で描画すればいいのでしょうか？
カーソル位置からRGBにどのようにして変換すればいいのでしょうか？

>>736
みたまんま、HSV経由でRGBにすればいいじゃん。

>>736
ほほぉ、あっちのレスは無視かね。

・「あのような色空間」とはなんぞや
・何を描画したいのか
・クリックした座標の取り扱いはできるのか
・色変換に関してどの程度知識があるのか

色空間なんて単語が出てくるから誘導したけど、
それ以前に色について何にも判ってないんじゃないのか

ハァ・・・。
おまいらメタセコイアも知らないで画像処理板にいるわけ?
やれやれ。自己解決したんでもう用は無いよ。
ばいばい

めちゃセコイや

ハァ・・・。
>>739は板とスレの違いも知らないで2chにいるわけ?
やれやれ。池沼だってわかったんでもう用は無いよ。
ばいばい

メタセコと画像処理は遠からず近からず。

厨房の法則

オレ様基準 ＝ 世界基準

典型例 ＞ ７３９

知らないなら黙ってればいいのに

>>743
おまえみたいな奴いるよな。
知らないこと聞かれると精神障害起こす奴。
自分で自分の事を頭良いって勘違いしてて、ばれそうになるとムキになるんだよな(w

>>745
ムキになってますよ

「自己解決した」とか、「もう用はない。ばいばい」と言っておきながら、
こんなにも必死に粘着するのはなぜだ？

このスレの過去ログを読めば明らかだが、このスレで扱う画像処理と
３Dソフトであるメタセコイアの間には、ほとんど関係がない。

ちなみに
★初心者にVisual C++を教えるスレ★ Part20
http://pc8.2ch.net/test/read.cgi/tech/1120222322/898

に対する解答は、すでに、あのスレの901に出ている。

いずれにせよ、もし736=739だとしたら、736は重症のバカだし、
その後必死になって粘着荒らしをしているのも736だとしたら、
これはもうダメかも知れないね。ガス室に行ったほうがいい。

infoweb の規制が解除されたから嫌味の一発も書いてやろうかと
思っていたんだが、みんな一斉に・・・

まあ、736は自己解決できたと言っているんだから、もう放っておけば
いいのでは？　解決できたにしては妙な粘着振りだけど、まあ、夏だし、
不機嫌になることもあるだろうさ。

この板によく出る
なりすまし「自己解決しました」宣言君じゃないの？

736以降のメタセコア厨が同一人物かどうかも怪しい(w
放置が一番。

>>751
そんな事言ったら君がメタセコ珍獣っぽくなるよ

>>739って誰がどう見ても騙りだろ。
マジレスして煽ってる人って何がしたいの？

またVIPPERの罠にはまったか

vigraバージョンアップ

オリジナルの７３６です。
なんか、僕の書き込みが元でご迷惑をおかけしているようですね。
本当に申し訳ありません。

>>756
謝るくらいならきちんとフォローしろ。
事の起こりはあんたがまともにレスしないからだろうが。

他の画像処理ライブラリーには日本語解説あまりないのに
OpenCVの日本語解説ばっかり沢山あるのは
Intelの陰謀？

>>758
Open CVの資料がたくさんあるのはインテルのせいかもしれんが、
他のライブラリの資料があんまりないことについてまでインテルの
せいにするのは、たぶん激しく間違っていると思うな。

類似画像検索についてやってんですけど、フラクタル画像圧縮を利用してますが、自分でプログラム書こうとするとわけわかりません。

１．画像ファイル読み込み
２．画像ファイルを２次元のピクセル配列にする
３．RangeブロックとDomainブロックに分割
４．Rangeの１ピクセルとDomainの４ピクセル（正方形）を比較
５．比較を全て対して行う

多分かなり意味不明だと思うのですが、理解できるかたがいればどんな感じで書けばいいか教えてくださるとありがたいです。
厳しければ１．２．だけでもかなり嬉しいです。
開発環境はCです。

宜しくお願いします。

>>760
君・・・やろうとしてる事とスキルの落差が激しすぎるね・・・。

せめて開発環境くらい明示しないと答えられないが、とりあえずOpenCV等のフリーな既存のライブラリを使う訓練をすることをお勧めする。

MATLABでコード書いてたことの多かったおいらは
OpenCVよりもvigraの方が好みだった
ドキュメントはOpenCVのほうが充実してるけどね

>>761
自分でやろうと決めたわけではなく･･･卒研で先生に強引に･･･自分のスキルないのはわかってるのに･･･

>>760
ImageMagickでppm形式かRGB形式に変換。あとは幅*高さの配列にずらずら読み込み。

>>763
まさか漏れの知り合いじゃないよな？ｗ
似たような人がいるんで(卒研で追い込まれてる)

>>765
内容がほとんど同じだったら知り合いだったりして･･･これやってる人そんないないし･･･

そもそも、フラクタル画像圧縮って俺は5年ぶりくらいに聞いた言葉。

>>766
あんま詳しいことは知らないけど、なにやら
画像処理やってるようなこといってたからなぁ。
OSはLinuxだったりするのかな

まぁ頑張って。

>>760
１，２なぞ、先輩でも捕まえて１，２時間聞けばすむだろ。
言語も触ったことの無いようなレベルなんだろうな。
研究室なら質問しながら、何処をどうすればいいか聞きながらやるしか。

私信はすれ違い

研究室フォー

>>764
おそらく、ファイルアクセスの仕方もわからないと思われ。

fopenなんか使わずにmmapしようぜ！

invalid operands to binary +
ていうエラーはなんのエラーですか？

>>774
二項演算子「+」のエラー。
オペランドが無効だとさ。

a+=b;だとすると
aとbの型が合ってないということですか？

そう思うなら修正してみればいいじゃない。

修正してみた。
ダメだった･･･

変数の型はなんなのさ?
ポインタだったりしてない？

aがdoubleで、bがabs(絶対値)。
doubleの絶対値はfabsっていうことはわかったんだけど…
absの中がだめなんだろうか?
形としては、
double a;
unsigned char str[i][j];
(中略)
a+=fabs(str[]使った式);

って感じなんだけど…わかりにくいですね。
誰か理解できれば教えてください。
失礼しました。

>>780
肝腎なところを省略するな。
つーか、スレ違いだから続けたいなら初心者スレで。

申し訳ない。
プログラムの中身が画像関係だったもので、つい。

終了します。

画像をテキストの数字の列で出力する方法ないの？
OpenCVからできるとうれしいんだけど

>>783
何をしたいのかな?
例えばxbmやxpmとかpnm(pbm/pgm/ppm)とかは画像ファイルそのものがテキストだけど。
#pnmに関してはバイナリ版とテキスト版があるので注意。

質問の仕方が下手なやつが多いな･･･。
意図的にやってるのか？

質問の仕方がうまいやつは検索のしかたもうまいので自己解決。

>>786
それ結構あたってるよね。

大抵の問題は他人にちゃんと説明できた時点で８割は解決してる。

Linux で，MPEG などの動画像からフレーム毎の静止画を生成するにはどうすれ
ば良いのでしょうか？

>>789
>>785

読点を，とする奴に用はないな

>>791 なんで?

論文気取りの学生臭いな

>>793
3時ぴったりに書き込みかよ。

ん？

研究室の標準設定ファイルでデフォルトが　，．　になってるよ

ここは研究室なのかそーなのか

オプティカルフローのプログラムが載っている書籍やＨＰがあったら教えていただけませんか？

"オプティカルフロー ソース"で検索したら
『フルスクラッチによるグラフィックスプログラミング入門』
って本がヒットしたよ。

ちょっとググってみたけど、そこそこ評判いいみたいだから
俺は買ってみようと思うが。
ただ、入門書らしいので、もっと専門的なのが欲しい俺には
物足りないかもしれないが…

あとは、OpenCVにオプティカルフローも入ってるよ。


これ書いてる間に↑の本、Amazonで在庫切れになったorz

その本、半年前に買ったけど、なかなか面白かった。線一本引くにも、いろいろな
ノウハウがあるもんだね。Windows の GDI を使っていると気がつかないことが
その本を読むとコード付きで理解できる。アンチエリアスを自力で実装するとか。

ま、しかし、ゲーム作る以外に実用性はあまり無いけど、基礎の考え方のレビュー
にはなってるし、オレには目新しくて面白かった。

>>799
たったいま、紀伊国屋の在庫を調べたところ、かなりの支店に
まだ在庫があるぞ。

アマゾンと違って高い本を買っても送料（380円）を別に取られるけど、
支店によっては、ウェブで取りおきを頼んでおいて、後日
受け取りに行くこともできる。（受け取りに行く運賃のほうが高い？）

>>799
大阪日本橋ジョーシンテクノランドにて生存確認
Gems4の近くに置いてた

送料無料のオンライン書店をいくつか調べてみたけど、品切れのところが多いね。
http://www.7andy.jp/books/detail?accd=31471940
http://books.rakuten.co.jp/RBOOKS/0001747678/
http://www.cbook24.com/bm_detail.asp?sku=479800958X
https://market.bookservice.co.jp/emp-bin/eh_writer.exe/top/main/detail.html?1727592
予想以上に売れ行きが良くて、重版が間に合わなくなっちゃったのかな。

フルスクラッチという言葉にアレルギーあるから買えないや
実写の洋爺さんが表紙の本はなかなか良かったぞ

>>799
俺も持ってるぞ。
直線検出のところで自分の大学の廊下部分が出てきてびっくりしたｗ
広く浅くの本だけどかなり面白いよ。

ありがとうございました。自分で組むにも時間がかかり過ぎそうだし、研究の手段にそんなに時間もかけられないので、本を買って利用したいと思います。

>>806
それならOpenCVを利用すればいいのでは？

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

その本、昨日から使いはじめたんだけどド素人すぎて44ページ目で躓きました

>>809
どっちがド素人なんだ？本か？おまえさんか？

>>810
自分が、ですね('A`)

プログラム板だし車輪の再発明（再開発）には反対だな。

車輪の再発明なんてしょっちゅうやん。
なに言うてはるの。アホとちゃいますか。

アルゴリズムを覚えるのは再発明を防ぐ意味で重要
円の描き方を10個以上知らない奴は買っとけ
ちなみに再開発（＝リファクタリング）はいくらでもやってよし
どうせ10回書き直したら9回は改悪だろうけどな

発明と開発は違うからね。車輪は日々再開発され続けていて、それぞれの用途に適合した
よりよい車輪がどんどん生まれている。まさか千年前の木製の車輪で高速道路を走ったり、
ダンプカーの重量を支えようなんてことは誰も言わない。

>>815
具体的に。

こんにちは。アドバイスお願いします。
libpngライブラリを使ってVCでPNGを保存するプログラムを書いています。
α値つき24bitの32bitRGBAのPNGを保存したいのですが、うまくいきません。
color_typeをRGB_ALPHAにして、RGBAの順にデータを保存しています。
ちなみに、photoshopだと問題なく表示されます。
windowsのビューワや、PAINTなんかだとRGBがずれたような画像になってしまうんです。(涙）
どなたか教えてください！
libpngを使ってVCでPNGを保存するプログラムを書いてるんですが、
α値つき24bitの32bitRGBAのPNGを保存したいのですが、うまくいきません。
いろいろな方のHP等を参考にして書いてるのですが、？です。
ちなみに、photoshopだと問題なく表示されます。
windowsのビューワや、PAINTなんかだとぐっちゃぐちゃの画像になってしまうんです。(涙）
原因って何が考えられますか・・・？

>>817
マルチは氏ね

817です。すみません・・・マルチってなんですか？

817です。今調べて、意味がわかりました。
いろんな掲示板に同じ質問を書くのはマナー違反なのですね。
考えたら確かに失礼でした。ごめんなさい。

アルファブレンディングは表示デバイス依存な予感。
MSDNでしらべれ。

>>817
同じことを繰り返して書いている理由がわからないが。。
画像のヘッダ情報はどのように書いているのかな？と。
lib何とかを使えばデータの出力は簡単なんだけど、
大抵の人はそこで躓いているような気がする。
しかも、サンプルソースは使えないものが多いし。
画像情報はIrfanとかでチェキしてみると吉だよ。

817です。お返事いただきありがとうございます。
以下の様に記述しています。
widht:画像幅、height:画像高さ、m_BmpImageは座標(0,0）からRGBAの順で並べた
画像配列です。
今から、irfanを見てみます。

FILE *fp;
png_structp png_ptr;
png_infop info_ptr;
unsigned char **image;
image = (png_bytepp)malloc(height* sizeof(png_bytep));
for (j = 0; j < height; j++)
image[j] = (png_bytep)malloc(width*4 * sizeof(png_byte));
for (j = 0; j < height; j++) {
　　　　for (i = 0; i < width*4; i++) {
image[j][i] = m_BmpImage[j*width*4+i];
}
}
fp = fopen("test.png", "wb");
png_ptr = png_create_write_struct(PNG_LIBPNG_VER_STRING, NULL, NULL, NULL);
info_ptr = png_create_info_struct(png_ptr);
png_init_io(png_ptr, fp);
png_set_IHDR(png_ptr, info_ptr, width, height,
　　　　　　 8, PNG_COLOR_TYPE_RGB_ALPHA, PNG_INTERLACE_NONE,
PNG_COMPRESSION_TYPE_BASE, PNG_FILTER_TYPE_BASE);
png_write_info(png_ptr, info_ptr);
png_write_image(png_ptr, image);
png_write_end(png_ptr, info_ptr);
png_destroy_write_struct(&png_ptr, &info_ptr);
fclose(fp);

>>813
再発明と再開発がソフトウェア開発を遅らす一つの原因ジャン。
勉強として自宅でやるのはかまわんけど、現場でやられるとたまらん罠。
再発明・再開発やりたがる潔癖症and/or自分を過大評価してる勘違いand/or要領の悪い奴とは仕事したくないな〜。

>>824
そうだね

なんかさ、最近、ソフトウェアはこうあるべきだ、と言っている人間のこだわりが
妙に馬鹿げて見えてくるんだよ。
机上の効率なんて、もはや興味は無い。

>>824
>再発明・再開発やりたがる潔癖症and/or自分を過大評価してる勘違いand/or要領の悪い奴>とは仕事したくないな〜。
全て自分でやりたがる奴は嫌だなぁ。しかも大したこと出来なかったりすると。。
年末から２月に掛けて怖い時期が続く。。

コードの再利用レベルの話と発明レベルの話は分けて考えないといけないと思う。
発明レベルの話なら既存の発明の追体験は結構重要なことだ。
普通のソフトの開発工程に発明の要素が入り込む余地はまずない、
あるとしたら設計段階やパイロットシステムなどで済ませておくべきこと。
「車輪の再発明」の比喩は面白いがソフト開発論にもちいると誤解を招きやすいと思う。

>>828
いや、発明の追体験は構わないが、再発明は無駄だろ。
「車輪の再発明」って言うときは、既に発明されているものがあるのを知らずに
苦労して「新しい物を発明したぞ」って同じ物を作り出すことを戒める言葉だし。

だから、再発明っていうのは、自ら進んで行うものではなくて、
結果として、後から自らの行いが再発明であることに気づくものだね。

昔、整数演算のみで直線を描く高速なプログラムについて試行錯誤したことがあるんだが、
最終的に出来たアルゴリズムが、実際には Bresenham の改悪版なんだと気づいた時には
すごくショックだったよ。

それ以来、いざというときのために、世に出てるアルゴリズムについては
できるだけ予習するように努めてるんだが
最近の論文なんかは特許が絡んでるのが多くて、糧にしにくいんだよなぁ…

>>824
開発と発明は全然違うぜ。

それとも、あなた、Fortran時代の画像処理ライブラリをそのまま使ってます？
そりゃ、違うでしょ？

どうでもいいけど、
「ソフトウエア開発とはかくあるべき」という話題は、
画像処理スレッドで扱うべき話題ではないので、
続けるなら、よそでやろう。

時間やコストの節約のため既存の画像処理ライブラリを使うのは大賛成

ただ、開発する能力が無くて既存のライブラリをブラックボックスで使うだけというやつも混じって
いるようだな。きっと、ライブラリにその機能が無いのでできませんと言い訳しているんだろうな。

>>830みたいな勘違いヤローがチームの足引っ張るんだよなぁ。
うざいなぁ。得意げなところが痛いし・・・。

>>833
あなたも彼と似たり寄ったりのようですね(^^)

開発で使用するライブラリは要件定義や設計段階で何を使うかとか買うか作るかといった方針は
決めるものだと思うのだが。以前外注したシステムに勝手に配布条件に問題のあるライブラリが
使われてて納品寸前に大改修をしたことがあるよ。

>>833
で、Fortranライブラリをリンクしているんですね？　再発明禁止なら。

得意げに、再発明はいけないと言っているやつが、「新発明」をやったためしはない。

つーかさ、オレも含め、ほとんどの労働者プログラマのやっていることって、ほとんど
全部、とっくの昔に他人が完成させた仕事の焼き直しだせ。いきがって発明家や
科学者を気取っちゃいかんし、オリジナリティなんてクソ食らえだと思うんだが。

そりゃ、手作業でくだらん最適化(ループでもなんでもないところ）にうつつを抜かして
納期を遅らせまくったあげく、職人の良心を語るやつにも、ものすごく困らされることは
あるが、なんか、極端は相通ずるものがあるね。

そんな労働者ばかりがこの板見てるわけでもないだろ。

そもそもの発端の『フルスクラッチによるグラフィックスプログラミング入門』という
本の最初に書いてあるけど、ブラックボックスの内容を理解しないでそれ以上のコードは
書けない。だから、新発明を目指す人も再開発や再発明を恐れることは必要ないし、どん
どんやるべきだろう。

個人的には、再発明だろうがなんだろうが、仕事と趣味と研究とちゃんとわきまえて
プログラミングしてね、ってことだ。

つーことで、画像処理の話にもどろーぜ

>>838
世の中労働者が大半なんですけど。

>>840

世の中に画像処理スレ見るような労働者なんか１％もいないだろ。

>>808

　特殊な画像処理はともかく、基本的な設計の定石やパターンを
知らずに、独自に作って仕様変更やバグが頻発して火を吹いてい
た所があった。当然ソースはスパゲティ、本人は体調崩して回り
の連中が火消しをしてた。

　普通に考えて、トヨタとか日産のエンジニアとか、エンジン作
るまえに、他のエンジンを分解してそれなりの機構をマスターして
から、新エンジンの開発に取りかかるのに。　どうして、プログ
ラマーは一部をのぞき、そういう事をせずにいきなりつくるのか？




　

>>842

普通のプログラマはちゃんとやってるから心配無用

いや普通の職業プログラマはそんなことやってる時間なんてとれないだろう。
俺のまわりじゃまさに>>842の言うとおりの状況だよ。

もちろんその結果、結局開発が遅れるんだから
最初に勉強会の時間を設けるとかして欲しいけど。
会社はそんなこと絶対してくれない。

まあまぁ・・・　痛いほど気持ちは分かるけど、スレ違いの話題が
長引くのは避けたいので、ここらへんで・・・　お願い。

んじゃ、話題変更がてら初歩的な質問を。

RGBからHSLに変換する方法について。
厳密なロジックと簡便な代替ロジックがあるならそれも。
自分で当たりをつけて作ってみたけどどうも腑に落ちなくて。

>>847
OS再インストールして「お気に入り」から消えたが、カラー変換とかでぐぐる
といろいろの変換を並べて説明しているページがあった。
半年前かそこらここでわたしも関連して細かいこと教えてもらった。
わたしは HSV とかもいろいろ使っている。

>>847
どの辺が腑に落ちないの?

厳密なロジックつーたら変換式をfloatで実装すればいいし、精度より速度が欲しい場合は固定小数点演算ですましてる。

>>835
GPL?

>>850
GNU関連のライブラリって大抵”ライブラリGPL”だから問題にならないと思うけど。

LGPLは静的リンク、動的リンクどちらも感染するってGNUのエロい人がいってました。

WinDVDのTrimensionＤＮMに感化されてフレーム間補間エンコーダ
作ってみました。TrimensionＤＮMはどうやってるか分からんけど
リアルタイムでやってるのはすごいね。これは単純にSSDで
対応付けしてるだけです（でも死ぬほど遅いです）。

ttp://xtp0001.s3.x-beat.com/cgi-bin/up/source/Sonata_16423.rar

>>852
まじ？

動的リンクが感染するなら、
そこらの圧縮解凍アプリはみんなLGPLとかGPLになってしまうのだが。
同梱が前提の話なのか？

>>854
Richard Stallmanとそのシンパがそう言ってるだけで汚染しないと考えるのが一般的
まだあっちでも激しく議論中

>>855
そこらのってどこらのだよ

>>855
> そこらの圧縮解凍アプリはみんなLGPLとかGPLになってしまうのだが。
なんで?
zlib も bzip2 も GPL でも LGPL でもないはずだが...

OpenCV beta5使ってる人います？
beta4から移行できるか不安だ

>>858
7-zip

ライブラリGPLってGNU Lesser General Public Licenseのこと？

http://www.javaworld.jp/beginners/-/11250-4.html
によると、

●利点：GPLと同じく、このライセンスが適用されたプログラムについては、その
派生プログラムにも同じライセンスが適用される。したがって、他のプログラム中
に独占的に取り込まれてしまうことがない。また、静的／動的を問わず、リンク
するプログラムは、このライセンスの適用範囲外になる
　
●欠点：BSDライセンスと比べて条項が複雑なので、利用者にとって理解
しにくい。オリジナル版の著作権が、派生プログラムの著作権に対して制約を
課せられるか否かといったことに関して、判例が出ていない

だって。

http://e-words.jp/w/LGPL.html

LGPLでは動的な(実行時)リンクに限り、GPL/LGPLに従わないソフトウェアでの利用も許容している。

>>862
>>861の内容と異なるなと思って、
とりあえず日本語訳を見つけてざっと読んでみたんだけど・・・
http://www.opensource.jp/lesser/lgpl.ja.html

分からない。orz

動的リンクか静的リンクかは本質的な問題じゃない。

>>864
じゃあなにが問題なのさ
動的リンクもGPL/LGPLにせにゃならんということか？

＞あなたは受け取る人がライブラリに変更を加えてそれを再コンパイルしたのちに
＞そういったコードをライブラリと再リンクできるよう、彼らに完全なオブジェクトファイルを提供しなければなりません

肝はここ

え、なに。
それが肝なの？
それじゃ、ライブラリに変更加えなければGPL/LGPLにしなくてもいいとかいうわけ？

画像処理スレなんですけど・・

LGPLな画像処理ライブラリを扱う場合には参考になるかもね。
ところで、LGPLな画像処理ライブラリってある？

>>867
>>866のは前文で、本文の6節のa)に対応している。

LGPLのライブラリがリンクされたソフトを手に入れた。
↓
そこで使われているLGPLのライブラリを改造した。
↓
再リンクしようと思ったらソフトのオブジェクトファイルが無いから再リンクできないぞゴルァ。

ということが無いように、ということ。

動的リンクの場合(6節のb))は問題無し。

ただ、6節によるとLGPLとリンクしたプログラムはリバースエンジニアリングを許可しないといけないので完全に好きなライセンスを適用できるというわけでもない。

#さらにややこしい言葉の問題として、リンクしたプログラムはLGPLに従わなければならない。
#しかしそれはソースを公開しなければならない等を定めた4節等に従わなければならないという意味ではなく、6節などの条件に従わなければならないという意味となる。
#6節ではリバースエンジニアリングなどを許可しなければならないなどの条件を満せば好きなライセンスでリンクしたプログラムを配布していいと書かれている。

#スレ違いスマソ。

再配布とか再リンクを誰でも出来るようなライセンスと形態（.h, .obj、.lib同梱?)
だったら有償ソフトとして販売しても、別の誰かが無料で再配布できたりしない？

こんな感じでどうとでも解釈できるんですよ、LGPLは

>>859
WinでもLinでも移行して今まで作ってたプログラムの再コンパイルしたけど問題なさげ。
インスコとコンパイル位しかまだやってないから詳しいことはまだわからない。

GPL関連で盛り上がってるけど、このスレってWin以外の環境の人多いの？

【殺しの】ライセンス【道で拾った】
http://pc8.2ch.net/test/read.cgi/tech/1045006087/l50

>>873
ライセンスはOSに依存しないんジャマイカ？
例えばTortoiseSVNはWindowsで動くけどGPL。
#スレ違いゴメン

要するに、
商用ソフトにGPL/LGPLライブラリを使うのは自殺するものだってことか？

>>876
保守で稼ぐなんてな〜このスレ関連のアプリじゃ無理か〜

だから使ってることを隠す。
でも、たまにバレてソース公開や無償化に追いやられるソフトが出てくるね。

GPLつかったら有料はNGだっけ？
ソース公開はしなきゃだけど。

有料はOK

でも再配布できるので、誰かが無料で公開しても大丈夫なんだよ。
だから、保守で稼ぐ〜なんて発言が飛び出したりしてくる。

>>871
LGPLの場合再リンクできるようにオブジェクトファイルを入れておけばプログラム本体は再配布不可でもいい。

デジカメについて来た ACDSee というのに、画像修正のメニューとして
「露出」というのがあり、暗い画像を明るくしてくれるようですが、
調節のスライダに、「黒」、「白」、「ガンマ」というのがあります。
「白」は HSL 変換で明度を上げているのかなあと想像していますが、
「黒」というのは何をしているか、分かりませんか。
似た処理を自作の画像修正アプリに取りこんで、部分適用とかして
みたいと思っています。

そのソフトは知らないけど、俺の勝手な想像だと
白はヒストグラムの右側の調節で、黒は左側の
調節じゃないの？

ttp://www.kitamura.co.jp/express/dckihon/0510/05_102.html
ここのSection 3でやってること。

Windows用の画像ライブラリであるLeadToolのContrastのアルゴリズムが判らん。
「濃度128を基準に」って書いてあるのに濃度128の画素の変化を調べたら
コントラストを+すると値が増加するし、-すると減少する。
どうやら64付近が基準になっているような気もするのだが、入力を横軸に出力を縦軸にした
グラフを作るとコントラスト+1000から-1000まで段階的に変化させた交点が一つにならん。
そのグラフから、-1000〜0まではy切片が32〜0まで変化して0〜+1000まではx切片が
0〜32まで変化するのは判ったけど。

大抵の画像編集ツールだと-100%とかで全面濃度128になったり+100%で128を閾値に
二値化した状態になったりするんだけどなぁ。
#勿論、グラフにすれば(128, 128)で交叉するわけで。

Contrastでしょ？ Ｂｒｉｇｈｔｎｅｓｓじゃなくて？
普通に、+100%で2倍、-100%で1/2倍になるんじゃない？

>>886
あー、それが128との差分の2倍/.5倍というなら判る。その理屈だと、-∞で128のみになるし、+∞で二値化するわけだから。
そう単純なもんじゃないから困ってるのよ。

>>884
どうもありがとうございます。
補正前後の画像の相対するピクセルの元の明度を横軸に明度の変化値を縦軸に
グラフを描いてみれば分かるってことですね。やってみます。

MSDNを見てたときのこと。

LoadImage
ttp://www.microsoft.com/japan/msdn/library/ja/jpwinui/html/_win32_loadimage.asp
>LR_LOADMAP3DCOLORS
> 8bpp より濃い色のビットマップをロードする場合は、このオプションを使わないでください。
　~~~~~~~~~~~~~~~~
　　　　　　　　　　　　　　 　　　　　　　　_, ,_
8bppより濃い色ってどんなやねん！( ﾟдﾟ) と訳者に突っ込みたい。

まぁ一見日本語になってるだけマシだろ。

これかな。
＞Do not use this option if you are loading a bitmap with a color depth greater than 8bpp.
迷訳だな。

Do not use this option if you are loading a bitmap with a color depth greater than 8bpp.

フィルタ畳み込み部分をMMXを使って実装しようと
思っているのですが劇的に早くなるものなのでしょうか？

ttp://www.mpeg.co.jp/libraries/mpeg_labo/winPC_12.html

ここによると（記事が古いけど）10-15%程度しか早くならないと
書いてありますけどどうなんでしょう

お世話様です。ＰＣのホームページでオリジナルの地図がある画面を携帯に送り、画像保存しておきたいんですが、
地図画面の保存が上手くいってないせいか、携帯におくっても見れませんでした。
携帯から直接アクセスしてもページが大きすぎて中断となってしまいました。
いったいど〜すれば良いのでしょうか？写真画像ですと普通に保存すればJPEGになるものが
多いので、携帯に画像保存ができるのですが・・・・・？ちなみにＰＣで保存した時の形式名は「GIFｲﾒｰｼﾞ」
となっておりました。
機械おんちなんで何卒アドバイスお願いします。
　

>>894
はいはいﾜﾛｽﾜﾛｽ

>>894
gifからjpegに変換すればいい。PC初心者板辺りで聞けば教えてくれるんでないかい?

>>896
ちょｗｗｗおまｗｗｗﾃﾗﾔｻｼｽｗｗｗｗ

輪郭抽出がカラーで出来ない理由って何だ？

＞８９８
カラーエッジのこと？
ttp://www.linx.jp/image/products/halcon/index_halcon_7.0.html

>>898
カラーでできないなんて初耳

>>893
速くなるんじゃない?
おいら、アセンブラ使えないんで、ベクトル化してくれるようにソース工夫してintel C++ compilerに放り込んでる。

>>799-806
社員宣伝、乙。

アセンブラは実はよく分かってないけどwebを参考に
SSEのpsadbwというbyte単位の絶対値演算処理を一気に
16個やるのをSSDで作ってみた。随分速くなった。
フィルタ畳み込みとなると積和演算pmaddwdを使うのだろうけど
これはWORD単位で画像データを設定しないといけないぽい。
SSEでフィルタ処理やるのなら画像データ自体を
16bit/pixelで画像幅とアドレスを16byteでアライメントするのが
常識なんでしょうか。そうなると今使っている画像クラス自体を
改造せんといかんなあ。

intelのコンパイラはうまくソースを書けばこういうのもSSEを駆使して
最適化してくれるのでしょうかね。上のように画像のデータ構造自体が
問題な気がします。

>>901
いまは市販コンパイラもベクトル化するんだ。。
し、知らなかった・・・　（＾＾；

>>902
なに寝ぼけたこと書いているんだか。

何もかもが他人の陰謀に思えて仕方がないというなら、それは精神病だぞ。
しばらく仕事を休んで静養しろ。

>>903
> 16bit/pixelで画像幅とアドレスを16byteでアライメントするのが
> 常識なんでしょうか。

常識。
2byte, 4byte, 8byte(?)でアライメントしとくべき。
Windowsのビットマップもそーなってるでしょ？
そうしとくと画像のコピーとかも速くできるよ。

>>903
一般的には、ゼロとアンパックしてワードデータにする。

>906, 907
なるほど、ありがとうございます。
なんとか作れそうです。
g(x)g(y)のタイプのファイルはだいぶ速くなりそうです。

でも今回の選挙みると思ったより陰謀だらけなのが分かる
intel MSあたりなんて、もっと過激なことしてそうだよ

ヒマな陰謀論者ってアフォくせー

ベクトル量子化のCBの作り方で有効なのってLBGアルゴリズムでよろしいんでしょうか？

>>911
よろしいんでない？
減色では、速度面が多少心配なので再帰分割などで粗いCBを作ってから適用しているけど。

>>911
適応ベクトル量子化でいいならもっと素敵なアルゴリズムがあるよ。

>>912
>>913
ありがとうございます。

このとき初期CBはランダムの方がいいのかそれとも出現頻度上位のベクトルを
初期CBとしてつかったほうがいいのでしょうか？

あと、CBにLBGアルゴリズムを適用するとした時、
ABCDE・・・という連続した画像（連続したものなのでほぼ同じ画像）に対して
VQを施すことを考えた場合、まずAのCBを作成して、それをBCDE・・・にも適用することを
考えるべきなのか、それとも、AのCBを作成して、次のBではAのCBを初期CBとして
用いて新たなCBを作ってそれをCの初期CBとして・・・を繰り返すべきなのでしょうか？

少し乱雑な文章ですがどうかよろしくお願いいたします。

それを実験するのも勉強のうち

少し追加させていただきます　すみません

あと、CBにLBGアルゴリズムを適用するとした時、
ABCDE・・・という連続した画像（連続したものなのでほぼ同じ画像）に対して
VQを施すことを考えた場合、まずAのCBを作成して、それをBCDE・・・にも適用することを
考えるべきなのか、それとも、AのCBを作成して、次のBではAのCBを初期CBとして
用いて新たなCBを作ってそれをCの初期CBとして・・・を繰り返すべきなのでしょうか？

とかきましたが、目的はCBを毎回作成するのでは時間がかかるのでできるだけ時間をかけずに
符号化したいということです。ですので画像ごとにCBを作るのではなく、同じような画像なら
CBを固定にしたいということです。で、できるだけ良いCBを作りたいので
AでLBGを使って生成したCBをBで初期CB・・・・とするというお話をさせていただきました

設計方針をお聞きで切ればなと考えております

考えてみたのですが
最終的にAのCBを作っていってそれをFまで前のCBを初期CBとしてCBを作ったとすると
最終的な画像に対してのCBであって全画像に対してのCBではないですね・・・

もしかして動画をVQで圧縮するような用途を考えているのかな?
AでCBを作る。
AをAのCBで量子化。
BをAのCBで量子化。　量子化誤差が大きいとき、BでCBをつくり、BをBのCBで量子化。
CをBのCBで量子化。　量子化誤差が大きいとき、CでCBをつくり、CをCのCBで量子化。
が基本なのかな?
計算量が大きくなりすぎるかな?うえの人が言うように適応型のVQを使うのも手かも。

>>918
ありがとうございます。


動画に似ていて、画像を連続で表示させる場合を想定しています（GIFのような感じ）

で、ひとつのCBだけで連続した画像すべてをまかないたいのです。
このとき初期CBとしてどのようなものを使ったらいいのかなと考えております。
単純にAの上位ベクトルだけをもっていくのか
それとも全画像のベクトルを集めてから上位ベクトルを使って初期CBにするのか
ということです
初期CBの作り方で結構かわってくるのではと考えたためです
参考書を見てもLBGは乗っていても初期CBは初期CBとしかのっていなかったので
みなさんの知識を拝借できればと思いました　よろしくお願いします

北海道へ行きたいのに沖縄へ向かってる方向音痴？

ＭＦＣでアプリケーションをつくりAVIファイルを再生しようとしたのですができません。
「圧縮解除プログラムvids::mjpgが見つからないため再生できません。」とでました。
ほかのファイルは再生できるのに自分で撮影したAVIファイルは再生できないのです。
わかる方解決法ありましたらお願いします。

>>920
ありがとうございます。もしよろしかったらどこがおかしいか教えていただけないでしょうか？

motionJPEGのcodecがないだけじゃね？

>>922
そのようでした。ありがとうございました。
codecなんですが、http://www.jpg.com/video.htmのものを使ったところ
体験版のせいか再生するときに文字が出ていました。
フリーで文字とかでないやつなんであるんでしょうか？

ttp://www.filesearch.ru/cgi-bin/s?q=mcjpg30.zip&t=f&d=&x=6&y=15


MotionJPEGはDirectShowについてくるはずなんだけどなぁ。
メーカーごとに互換性ないらしいからそのせいかもしれないけど。

>>919
LBGで局所解を避けたいつー話だったら、色々試してみるしかないよ。
ところで、LBGに拘ってるのは何故?
ベクトル量子化のアルゴリズムはたくさんあるよ。

>>926
ありがとうございます
LBGしか知らないためにいってるのと、VQの処理時間のほとんどを占めているのが
CB作成時間なので、CBを固定できたら処理時間短縮が目指せるのではと考えたためです

初期CBに何を使ったらいいのかと毎日考えております。
それによってLBGの処理時間もかなりかわってくると考えております
何かいいアドバイスあったら是非ご教授お願いします

上のほうで挙げてたフレーム補間ソフトですがSSEを使って高速化してみました。

ttp://evolution-next.sakura.ne.jp/snup/src/upfile0172.zip_aNlJYlc6CPaJyjDWWhWt/upfile0172.zip

例によってSSDで対応付け＋モーフィングだけなので前景と背景の境界が変になります。
（動きベクトルが連続と仮定しているから）
元の２枚のフレーム：
ttp://49uper.com:8080/html/img-s/80196.bmp
ttp://49uper.com:8080/html/img-s/80197.bmp
中間フレーム：
ttp://49uper.com:8080/html/img-s/80198.bmp

なにかうまい対策はないでしょうか？一応エッジ輪郭を使って局所的に前景・背景を
分離してＳＳＤをやる予定ですが・・・

＞921
↑はMFC＋DirectShow(DirectShowSDKのサンプルをいじったもの)ですが
普通にMJPEGも再生・変換できるようです。

傾き補正のアルゴリズムを解説してるWebとか書籍はないでしょうか？
自作の画像処理ツールに傾き補正を仕込みたいけど、どうやってやればいいのやら。
対象となる画像はグレイスケールか二値画像。

最初は四隅を検出して位置関係を調べて、何か数学計算で角度を出せるかと思ったけど、
台形とかな画像だと四隅の位置関係が等距離とは限らないし。

ＶＢとかＶＣのサンプルコードがあれば嬉しいけど、せめてアルゴリズムだけでも知りたいです。

直線を引いてもらって、それが水平/垂直になるように
画像を回転させるだけで良いんじゃ？手動なら。

特徴のある角とか辺とかをパターン認識して回転させれば？
重心を求めて、そこを中心とすればもっと良いかも。

あと、カメラ画像だと、
スケール補正とか、3次元->2次元歪み補正とか要りそうだけど。

>>929
画像取り込み時の±５度くらいの傾きを補正するとする。ある程度長い水平あるいは
垂直部分がある画像では、

　輪郭・芯線抽出
　長めの水平・垂直に近い線分(±５度)を集める
　角度でクラスタリング
　最大クラスタの傾きを採用して回転

ただし、地図では斜めの線だらけで無理。テキスト画像のように長い線の無い画像
でも上記の方法では無理。市販のOCRでは傾き補正やっているのでできることは確か。

汎用でやるならユーザーに２点を指定させるしかないのでは

一般的な画像評価はＳＮ比を使うと思うのですが
画像評価ツールのようなものはあるのでしょうか？
あったら教えていただけないでしょうか。お願いします。

>>929
変換部分のアルゴリズムは分かるが、正確に計算するには
画角の情報が必要だよ。

>>934
フリーソフトでpsnrbmpというのがあるけど。

>>936
ありがとうです。ちょっと使ってみます。何か他にもあったら色々試してみたいので教えてくれるとうれしいでｓ。

動画を扱っています。
蛍光灯下だと、動画が波打ってしまうのですが、
それらを抑える処理ってどうやるのでしょうか？

>>938
・蛍光灯を消す。
・蛍光灯をインバータタイプにする。
・残光型のモニタにする。
・モニタのフレッシュレートを変えてみる。

>>934
http://www.ece.uvic.ca/~mdadams/jasper/
にあるJasPerのimgcmpコマンドで画像比較は可能。
Cygwinでも利用可能。

複数の画像を一気に処理するツールなので、自動でやりたい。
ＯＣＲとかスキャナのソフトで自動傾き補正をしてるけど、あんな感じのを実装したい。
一定角度以上なら自動調整、それ以下なら放置にしたいが、それはまた別の話なので。

うーん、図形の特徴を画像認識するしかないんでしょうか。
重心検出は手持ちの本に載っていたのでいいとして、特徴検出は何をどう検出してどう使えばいいのか。
自分のスキルでは手に余りそう(´・ω・｀)

>>938
富士川をわたる

ここにあるソフトの様に、色毎にベクトルを抽出する
方法を探しています。
良い方法はありますか？

http://www.kurabo.co.jp/el/ks/kskl_01.html

>>943
領域分割＋輪郭追跡

色分割はリージョングローイングかクラスタリング

>>941
ハフ変換を使って直線の検出をしてから
傾き補正すればできるかも
それでもかなり難しそうですね・・・

http://potrace.sourceforge.net/
http://autotrace.sourceforge.net/

564氏の領域分割を実装しようとしてます。
607 から 613 に書かれている事について質問です。
"同じ区画内で最も遠い2点は√3の距離" とはどういった事でしょうか？

>>947
立方体の対角の距離

画像評価の方法について質問があります。
元画像と非可逆符号化を行った後の画像とを比べたいのですが、（画質が多少は劣化するので）
評価方法としてはSN比以外になにかいいものがあるのでしょうか？

>>948
947です。
５ｘ５ｘ５だと完璧、という理由が理解できました。
無駄な区画が多そうな気がしますが・・。

>>949
PSNRとか
http://www.cqpub.co.jp/interface/toku/2002/200201/toku1_4.htm

>>951
> >>949
> PSNRとか
> http://www.cqpub.co.jp/interface/toku/2002/200201/toku1_4.htm
ありがとうございます。
SN比とPSNRの差はどういったところなのでしょうか？

色々調べてみたのですがSN比の計算式が乗っていなくて違いがわからずこまっております
よかったら教えてください。

>>952
http://www.f-kmr.com/PDF/dsp_evaluation.pdf
ここにはMSEものってるな。
まあ、画像の劣化は主観的なものが強いのでどれがいいとは
一般には言えないと思ってる。
圧縮ではPSNRが一般的かな？程度の話。

>>953
ありがとうございます。
私もちょうどそこを何とか発見してみていたところです。
客観的な尺度としてはSNRなどを用いて
主観的評価として多数の人間からアンケートをとって評価するというという方法で
画質劣化の評価はできるのでしょうか？
アンケートをするべきかどうかなやんでいて・・・。

>>954
> 主観的評価として多数の人間からアンケートをとって評価するというという方法で
> 画質劣化の評価はできるのでしょうか？

評価は可能。実際ここ2年は客観指数と主観評価を実施している。
しかし、アンケート実施者の話し方で結果は変わるので、
評価結果の有効性には疑問がある。

大量の画像でSNRなどを求め、手法による数値の差異が
統計的に有意であることを立証した後、
主観評価で、妥当性を確認って感じ。

まあ、予算(と時間)があればって程度かな？
被験者選びや主観評価の手法への突っ込みがあると、応対が面倒だよ。

>>955
なるほど。ありがとうございます。
まずは、SNRなどで客観的数値を求め、そのあとにアンケートを用いてSNRと比べ、差異がそこまで
ないことを示すことで主観的な手法であるアンケートの有効性を立証するということですね。

被験者選びは　同性や同年代の人が多ければそれだけ偏ったりするということですよね？
主観評価の手法の突っ込みというのは具体的にはどういったものなのでしょう？
画像を見せて、大変気になる（５）〜まったく気にならない（１）のように点数化する手法などに
対するつっこみということでしょうか？

大変助かりました、ありがとうございます。

>>955
> >>954
956です
> 大量の画像でSNRなどを求め、手法による数値の差異が
> 統計的に有意であることを立証した後、
> 主観評価で、妥当性を確認って感じ。
これはSNRなどの手法が有意であるかを立証して、そのあとで主観評価で妥当性を確認
ということなのでしょうか？

何度も読み返すと956で言った、アンケートの有意性ではないようなきがしたので

>>957
> これはSNRなどの手法が有意であるかを立証して、そのあとで主観評価で妥当性を確認
> ということなのでしょうか？

そうです。個人的にアンケートは有意とは言いにくいです。
後、主観評価手法への突っ込みとは、
・画像表示環境(モニタのキャリブレーション手法、照明の状態等)
・被験者の母集団の選択理由、能力指標(画像処理の経験の有無)などの妥当性
・被験者間の隔離方法
・アンケートの項目の妥当性 等々
心理実験は面倒ですから、数値評価の補助程度と考えてます。

輪郭がくっきりでのっぺりなのが素人目には良く見え、
ちょっと慣れている目には、ノイズっぽくてもディテールまで再現してるのが良く見える
って気がする。

>>958
>>959
ありがとうございます。
客観的評価としてのSNRはこれまでの研究からも妥当性は証明しなくてもすむと思います。
しかし、主観的評価であるアンケートについては確かに難しそうですね。
画質評価を考えるだけで研究になりそうですね・・・。
主観的評価は、客観的評価の補佐的な役割でやっていくのが妥当そうですね。

>>928
フレーム補間ソフト、もう一度くれませんか？

>>944
943です。
情報ありがとうです。
リージョングローイングはCマガ2001/4号によると、塗り潰しの技法っぽいのですが、
ラスター・ベクター変換に利用できるのでしょうか？

>>961
フレーム補間ソフトの置き場。
ttp://g0307.hp.infoseek.co.jp/

>>962
リージョングローイングは領域分割方法です。似た色の領域を取り出して
輪郭追跡を行なえばよさそうな気がします。

>>963
めっちゃｻﾝｸｽ

　　 　 l'´￣`l￣￣￣￣￣￣￣￣￣￣￣｀l
　　　　|　　　|　u　　　　　　　　　　　　　 　 |
　　　　|　　　|　　　　　. 　 ＼　　 '／　 　　 |　　はああああー
　　 　 |　 :J |　　 　　　　 ‐ｰ　 くー　　　:　|
...　　　|　　　|　　 J　　´ﾟ　 ,ｒ "_,,>､ ﾟ' 　　 |　　ヤパーリ、ryokoたんの穴は
. 　　　|　　　| 　 　 　 .　　 ト‐＝‐ｧ'　　　　|
. 　 　 |　　　|　　　　　　 　 ` ｀二´' J 　　 |　　　シマリがいいYO〜！！
..　　　|　　　|　　　 　 　 　 　 　 　 　 　 　 |
　　　 |　　＼ 　 　 　 　 　 　 　 ＿＿ 　 　ﾄ、
　　　ミ 　　　＼　　,.ミ'´￣￣｀`　　　 ｀ヽ､| |
((　　ﾐ　　　ミ　 ＼'　　　　　　　　 ､ 　　　ヽ|　　　　　　　　　　力
　　 ミ、　　ﾐ　　　 ＼ 　 　 　 　 　 i.　　 　 ﾞ、　　　　　　　　　　　勹
　　　|　　 ミ、　,'　　　　　　　　　　　　　　　 l
　 　 Ｌ.＿__|＿ l　　　　　　　　　　　　　　　　l　{　　　 -─-　､
　　　 　 |　　　 l　　　 -、　　　　　　 　 ヽ　　　,. '´　　　　　　　ヽ
　　　　　| 　 　 ! 　 　 　 ヽ　　　　　　　　 ヽ ,.'　　　　　　　　,、　 ヽ
　　　　./´￣`V　　　　　　,ヽ､　　　 　 　 　 ,'　,'　 ;　,.　 ,:　, ハ :,　, i
　　　 /　、　　|　　　　　 /　 ､`ｰ　　　　　ノ!　;　: ; /_'／./_/　 Li_l　 !
　　 ./ 　 i　　 | 　 　 　 /　　 ヽ　　 ヽ 〃 /　 |　;:｢ ＿___...　　　　ﾘjリ
　　 !.　　　　　!　　 　 /　　　　 ヽ　　 {{　/ （｀|　il|　＿_..　　　｀￣lﾉ i　Σ
　　 ｀ー‐ゝ、 '　　　 /　　　　　　ヽ___,.-‐'"⌒ﾞ|　!|　°,,,　　,　￣/,: ハ
　　　　　　　`ー--‐'　　　　　,. -‐'"´　　　　　ﾘi从＿　　 、　'''ノ_:_ﾉ　ヽ
　　　力　　　　　　　　　 ／"ー─------＜二／　　´ヽ､-＜r"／,ｰ､ 丿
　　　　　勹　　　　　　{ 〈　　　　　　　　　　　　　　　 )､ Y　 ｀ゝ(_/_/./'
　　　　　　　　　　　　　} `ー----------─一--‐'´

レイヤーの合成をしたいのですが、不透明な場合の計算式しか見つかりません。
http://www.bea.hi-ho.ne.jp/gaku-iwa/color/conjn.html
透明度付きで合成するにはどうしたらよいのでしょうか？

通常の場合、
結果画像=元画像*透過率+合成画像*(1-透過率)
となる。
その他の場合も同様に。

>>967
結果画像の透過率も求めたいです。

はぁ?

結果画像=元画像*透過率+合成画像-合成画像 * 透過率
透過率*(元画像 - 合成画像) = 結果画像 - 合成画像
∴透過率 = (結果画像 - 合成画像) / (元画像 - 合成画像)

>>970
それは結果画像の透過率じゃないような。
半透明な画像同士を合成すると結果も半透明になるから、
それの透過率と色を計算したいです。

なにがしたいのかいまいちわからん
半透明な画像とは？具体例を挙げてみ

(画像2,透過率2)の上に(画像1,透過率1)を乗っけた画像(結果画像,結果透過率)を求めるのだったら、

結果透過率＝透過率1×透過率2
結果画像＝(画像1×(1-透過率1)＋画像2×(1-透過率2)×(透過率1)) /(1-結果透過率)

かな

回答ありがとうございます。

>>972
Photoshopのレイヤーの合成とか。
レイヤーが何枚かあって、下から順に合成していくときは967の式で出来るけど、
先に上のレイヤーを合成したいときは、結果画像の透過率も分からないと
それより下のレイヤーと出来ないです。

>>973
その式で計算したら上手くいきました。ありがとうございます。
あと描画モードが通常以外の場合はどうすればいいでしょうか。

>>974
少しは貴様の体の上に乗っかっている南瓜を使ってみたらどうだ?

>>974
下から順に合成していかないと、非線形な合成をしている場合、つじつまが
あわなくなるぞ。全部加算合成？　だったから、中学校の掛け算の問題だ。

> あと描画モードが通常以外の場合はどうすればいいでしょうか。

下から順にやる以外に方法はない。なぜなら、掛け算や足し算と
違って、非線形演算には交換法則や結合法則が成り立たないから。

もちろん、「このソフトでは上から順に計算していく。それが仕様だ。
フォトシップとの互換性は考えない」と、いうことなら、それはそれで
構わないぞ。

>>976-978
原理的に不可能な部分は同じにならなくても問題ないです。
Photoshopでも「下のレイヤーと結合コマンド」で
順番を変えて結合すれば結果は異なります。

>>979
仕様が変わってしまってもいいということなら、もはや、あなたがいいと
考えるとおりに、どんな方法で実装してもいいんじゃない？
暴走しない限り、どんな計算をしようとも、「これが俺のやり方だ！」と、
割り切ってしまえばいいじゃないか。

ただ、グラフィックツールを使う立場の人間にとっては、フォトショップの
ように、下から順に非線形合成をし、合成結果のもとの画像との加重平均をとる
という計算を繰り返すのが、たぶん、最も理解しやすい結果になるとは思うけどね。

半透明なレイヤーを上に追加して、下にある「すでに計算結果の確定している」
レイヤーにさらなる味付けや重ね描きをするというのが、たぶん、もっとも
受け入れやすい仕様じゃない？　もちろん、そうでなきゃいかんと法律で決まって
いるわけでもないし、自分のやりたいようにやっても、全く問題はない。