画像処理 その７
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2006/05/29(月) 09:56:00・初学者の質問に対してやさしく(的を外れた)解答を与える
・その道の玄人も大歓迎
前スレ
画像処理 その６
http://pc8.2ch.net/test/read.cgi/tech/1140510670/
過去スレッド
画像処理 その５
http://pc8.2ch.net/test/read.cgi/tech/1127705848/
画像処理 その４
http://pc8.2ch.net/test/read.cgi/tech/1107854973/
画像処理 その３
http://pc5.2ch.net/test/read.cgi/tech/1090897159/
画像処理 その２
http://pc5.2ch.net/test/read.cgi/tech/1054545005/
画像処理
http://pc5.2ch.net/tech/kako/992/992671330.html
0002デフォルトの名無しさん
2006/05/29(月) 10:14:02乙
0003デフォルトの名無しさん
2006/05/29(月) 10:33:400004デフォルトの名無しさん
2006/05/29(月) 12:46:100005デフォルトの名無しさん
2006/05/31(水) 10:20:590006デフォルトの名無しさん
2006/06/01(木) 00:12:170007デフォルトの名無しさん
2006/06/01(木) 13:46:06公式からダウンロードしてImageMagick（ImageMagick-6.2.7-8-Q8-windows-dll.exe）をインストールしたら
Demoプログラムは動くんですが、自分でソースを作って
#include <Magick++.h>をしても読み込めませんでした。
includeとlibにImageMagickのincludeとlibを入れてみたんですが
error LNK2019が出てしまいます。
どうすれば使えるようになるのでしょうか？
0008デフォルトの名無しさん
2006/06/01(木) 16:08:15ImageMagickというのは知らないので、はずしてるかもしれないけど、
エラー番号からするとＷｉｎＭａｉｎ（）かｍａｉｎ（）がない、もしくは、
ｌｉｂのパスが通っているだけでライブラリーが指定されてないように思えますが。
0009デフォルトの名無しさん
2006/06/01(木) 17:29:56とりあえず↓のサイトを見ながらプログラムを作って、
ttp://image-d.isp.jp/commentary/color_cformula/Luv.html
出てきた結果が、正しいかどうか確認したいんですが
なにか良い方法はないでしょうか？
理想は、↓サイトのように、あるRGB値を入力して
Luv値を返してくれるようなトコがあれば嬉しいのですが・・・。
ttp://www.eonet.ne.jp/~s-inoue/CO6_henkan/index-a.html
とりあえずphotoshop7.0が大学の端末に入っているので
それ使ってもいいです。よろしくお願いします。
0010デフォルトの名無しさん
2006/06/01(木) 19:10:15ここオススメ。
Color Calculator使えば一発でいろんな色空間での数値が表示される。
Mathから変換公式も見られる。
001110
2006/06/01(木) 20:00:31わざわざ実装乙ｗ な気分にさせられてしまうかもしれないが、そこは許してね。
0012デフォルトの名無しさん
2006/06/01(木) 23:08:35ttp://image-d.isp.jp/commentary/color_cformula/Luv.html
知ってると思うけど RGB 単独では「色」を表す事はできなくて、
カラープロファイルの情報と結びつける必要がある。
このページは RGB を D65 決め打ちで取り扱ってるから注意が必要。
Windows 標準の sRGB 空間にあるRGB値をこの式で変換しても意味は無いよ。
変換式を実装するより先に色空間やガンマの理解が要るんだが。
その辺りは大丈夫なのか？
0013デフォルトの名無しさん
2006/06/02(金) 00:12:22漏れは犬なので知らんけど。
0014デフォルトの名無しさん
2006/06/02(金) 10:34:39有料ではLeadToolがあるけど色に関しては色々怪しいし座標変換は使い難いし。
寧ろ知ってたら教えて欲しいくらい。
#LeadTool程度以下なら何セットか買いたい。
00159
2006/06/02(金) 12:53:02自分の知識の未熟さが確認できました。もっと勉強します。
>>10
うおぉ便利なサイトですね。有効利用させて頂きます！
0016デフォルトの名無しさん
2006/06/03(土) 11:06:53資料ってどこから入手していますか？
0017デフォルトの名無しさん
2006/06/04(日) 15:29:37256^3色カラーの変換式（？）ってどういった式になるのでしょうか？
ぐぐったけれど上手く見つけられませんでした。よろしくおながいします。
0018デフォルトの名無しさん
2006/06/04(日) 15:42:350019デフォルトの名無しさん
2006/06/04(日) 20:10:350020デフォルトの名無しさん
2006/06/04(日) 20:25:550021デフォルトの名無しさん
2006/06/04(日) 21:08:560022デフォルトの名無しさん
2006/06/04(日) 21:13:080023デフォルトの名無しさん
2006/06/04(日) 21:37:040024デフォルトの名無しさん
2006/06/04(日) 21:43:360025デフォルトの名無しさん
2006/06/04(日) 22:39:29本当に困ってます。
0026デフォルトの名無しさん
2006/06/04(日) 23:08:130027デフォルトの名無しさん
2006/06/04(日) 23:11:59スーパーブロックの構造とかフレームの構造とか
そうゆうの乗ってる資料ありませんか？
プログラム組むのに一々ファイルバイナリで数百ダンプして解析するの嫌なんですよ
0028デフォルトの名無しさん
2006/06/04(日) 23:19:18あとAVIファイルの構造自体がわからんとかそういう冗談はなしにしてくれ。
0029デフォルトの名無しさん
2006/06/04(日) 23:35:35どうしよう...
0030デフォルトの名無しさん
2006/06/05(月) 00:02:570031デフォルトの名無しさん
2006/06/05(月) 05:55:30まあ悪いことは言わんから適当なライブラリ使っとけ。
0032デフォルトの名無しさん
2006/06/11(日) 23:23:20便利なライブラリとかさ…
0033デフォルトの名無しさん
2006/06/12(月) 09:39:00言いだしっぺのオマイがテンプレの叩き台を出すべき
0034デフォルトの名無しさん
2006/06/12(月) 10:44:09ttp://www.jpeg.org/
ttp://www.codeguru.com/Cpp/G-M/
0035デフォルトの名無しさん
2006/06/12(月) 18:12:200036デフォルトの名無しさん
2006/06/13(火) 01:31:23じゃ、とりあえず一個OpenCVとかどうかな
Open Source Computer Vision Library
http://www.intel.com/technology/computing/opencv/index.htm
SourceForge.net: Open Computer Vision Library
http://sourceforge.net/projects/opencvlibrary/
0037デフォルトの名無しさん
2006/06/14(水) 00:28:350038デフォルトの名無しさん
2006/06/16(金) 18:55:29Delphi6で画像ビューアみたいなものを作っているのですが
画像処理の知識を持っておらず、拡大縮小の処理は
公開されているコンポーネントを使用しています
拡大縮小後の画像の質はかなり良いと思うのですが、
1100x1400 → 990x1260の縮小処理を
BiCubicで行う場合、1.5秒程かかります
スペックは Celeron700MHz メモリ64MB VRAM共有 です
お聞きしたいのはこの拡大縮小の処理時間のことで、
このスペックで上記の処理を行い1.5秒という結果は遅いのでしょうか？
0039デフォルトの名無しさん
2006/06/16(金) 20:32:30どんなアルゴリズム使った拡大縮小なのか言わないおまいさんに
正確な答えを返せる奴はエスパー
0040デフォルトの名無しさん
2006/06/16(金) 21:02:15そのハードで他ソフトの同一処理と比較すべき
0041デフォルトの名無しさん
2006/06/16(金) 21:11:56盛大にスワップかましてるんじゃないか？
0042デフォルトの名無しさん
2006/06/16(金) 21:34:34一応 バイキュービックと書いてあるぞ。
でもまあ、そのスペック＆解像度だと、かなり遅いかもね。
41が言っているようなスワップ等は発生していないと言う前提で。
たぶんもっと早くなる可能性があるのなら、自分で書いてみようかなと
考えているんだろうけれど、仕事じゃないなら書いてから考えてみよう。
0043デフォルトの名無しさん
2006/06/16(金) 21:41:00エロ画像なら念心念心と唱えながら実行すれば
0.5秒切れると思うけどねがんばれよ
0044デフォルトの名無しさん
2006/06/16(金) 21:49:350045デフォルトの名無しさん
2006/06/17(土) 00:10:05読みやすい、という表現が非常に主観的ではあるのですが、一般にという話です。
0046デフォルトの名無しさん
2006/06/17(土) 00:21:41もっともギンギンにコントラスト強いのが読みやすいかといえばまぁそれはそれで別の問題だが。
0047デフォルトの名無しさん
2006/06/17(土) 00:26:52確かにそういうのが欲しいシチュエーションはあるよね。
自分で調べたことは無いけど。
色彩心理学とかカラーコーディネーターの分野の方にあるかも。
0048デフォルトの名無しさん
2006/06/17(土) 00:40:49w3cのアルゴリズムでそこそこ無難な色が得られるけど、
任意の背景色になるとむずかしいよねー。
w3cのアルゴリズムは、たとえばこのへんから
ttp://www.infoaxia.com/tools/cca/index.html
0049デフォルトの名無しさん
2006/06/17(土) 00:58:26白いアウトラインに黒文字。
0050デフォルトの名無しさん
2006/06/17(土) 01:44:32任意の背景色が単色ならいろいろ考えられるけれど、
自然画像のように、色々な色が混在している場合の汎用と言えば縁取りしかない。
縁取り色と中の色にはいろいろな組み合わせがあるだろうが、
49の言っているように白黒が多い。
なお、出力するデバイス（ＴＶなのかＰＣモニタなのかなど）によって、適切な
色や輝度は異なります。
0051デフォルトの名無しさん
2006/06/20(火) 01:25:00使われていますか？
二枚の画像を精度良く一致させる方法をご存知でしたら
教えてください。
0052デフォルトの名無しさん
2006/06/20(火) 20:13:110053デフォルトの名無しさん
2006/06/20(火) 20:30:57plamoバイナリ配ってる人か、前に行ったことあるな
0054デフォルトの名無しさん
2006/06/22(木) 22:13:37図書館なりなんなり行けば？学生さん。
調べるって方法は人に聞くだけじゃないんだよ。
0055デフォルトの名無しさん
2006/06/23(金) 05:15:000056デフォルトの名無しさん
2006/06/23(金) 11:12:540057デフォルトの名無しさん
2006/06/23(金) 13:05:33完全に他者の善意に頼ってるのに、
質問をして必ず解答が返ってくると考えるほうが変だが。
005851
2006/06/23(金) 14:44:23オプティカルフローは多くの研究成果があるけど、
実際のcodecには使われていないのは、なにか問題があるのかと
思い質問しました。ブロックマッチングが無難ということでしょうか。
0059デフォルトの名無しさん
2006/06/23(金) 15:53:00なら書き込みすらしなければいいのに
0060デフォルトの名無しさん
2006/06/23(金) 19:33:090061デフォルトの名無しさん
2006/06/23(金) 20:02:52補間するということなら、やはり演算負荷が問題
ではないかと２次元レベルの洩れが半端にレスしてみる
0062デフォルトの名無しさん
2006/06/23(金) 20:20:19オプティカルフローは、コーデックと言うよりカメラ側の動き検出に利用されているのを
よく見かけます。
雑感ですが、勾配法では点そのものの明るさが代わらないことを前提にしますし、
フレームの移動にはよさそうですが、何がどうなるかわからない動画の動き補償には
ＣＰ（コーディングのＣＰも含めて）的にもブロックマッチングのほうが無難な結果を
得られるのではないかと思います。
006351
2006/06/23(金) 21:28:09ありがとうございます。オプティカルフローはせっかく面白い理論なのに
実際使うとなると、ブロックマッチングの方が無難というのは残念です。
オプティカルフローが実用レベルで役立っている例は少ないのかな。
0064デフォルトの名無しさん
2006/06/24(土) 00:48:43勾配法もブロックマッチングもオプティカルフローの推定方法じゃないのかね？
006562
2006/06/24(土) 01:25:21仰るとおりですが、58の質問をみると、58は勾配法の意味で
使用していると判断しました。
0066デフォルトの名無しさん
2006/06/24(土) 02:58:29格子点のオプティカルフローを基に参照画像をメッシュtoメッシュで変形させるような
動き補償も最近のGPUなら可能なような気がするな・・・
0067デフォルトの名無しさん
2006/06/24(土) 12:52:110068デフォルトの名無しさん
2006/06/24(土) 22:11:57動き補償は motion compensation の一般的な訳語ですよ。
比較元の画像と動き予測(motion estimation)の結果から、
対象画像を再構築する処理を差します。
>>66
一般的な動画映像では、移動量が連続ではなく離散的なので、
通常のオプティカルフロー解析でメッシュ変形のような動き補償をしても、
効果が少ないというか、単なるブロック単位での動き補償と比べて差分(誤差)が小さくならないと思う。
ちなみに、MPEG2のエンコードで、動き予測の前処理としてオプティカルフロー解析を使ったことはあります
(解析結果の勾配を動きベクトルの初期値として、その近傍を探索する)
が、イマイチ良い結果が出なかったかな。
MPEG の動き予測・動き補償は「対象画像から似てる部分を参照することで、データ量を削減する」のが
目的であって、「実際の動きがどうなのか」はどうでも良いし。
(見た目上の動きとはまったく無関係な部分を参照しようが、データ量が削減できれば正義)
006951
2006/06/25(日) 09:11:40BMだと動きベクトルの滑らかさを考えるのが難しいので、
オプティカルフローを考えてました。
一応、メッシュ＋オプティカルフローでやってみたのですが、
正則化パラメータがうまく設定されれば、それなりにうまくいくようです。
ただ、パラメータ設定が難しいため、BMの結果をメッシュで近似した方が
簡単で良いような気がします。
0070デフォルトの名無しさん
2006/06/25(日) 10:30:00最適解でっちあげろよ
0071デフォルトの名無しさん
2006/06/25(日) 20:09:53得ないのではと再び半端レスしてみる
0072デフォルトの名無しさん
2006/06/26(月) 13:59:52モノクロ動画の背景を消したいのですが、１コマ前の画像から今の画像を引けば動いてるものだけになりますよね？
そこで
for(i=1;i<Y;i++){for(j=1;j<X;j++){
dif[i][j]=buf[i][j]-now[i][j];
dif[i][j]=abs(dif[i][j]);
buf[i][j]=now[i][j];
}}
buf・・・前の画像
now・・・今の画像
dif・・・差の画像
とやったのですが、どうも白と黒が反転したような変な画像になります。
どうしたらいいのでしょうか？
0073デフォルトの名無しさん
2006/06/26(月) 14:11:34＞１コマ前の画像から今の画像を引けば動いてるものだけになりますよね？
なりません。
007472
2006/06/26(月) 14:17:420075デフォルトの名無しさん
2006/06/26(月) 14:59:310076デフォルトの名無しさん
2006/06/26(月) 15:26:07カエルはどうだかわかりませんが、人間はシーン間の差分の絶対値を
一般的な景色として認識してはいないからです。
変な画像にならないようにするには、差分の絶対値ではなく
そのものの色（輝度値）を表示しなくてはなりません。
0077デフォルトの名無しさん
2006/06/29(木) 11:38:10差が一定の値以上になった画像のみ取り出すようにしてはどうでしょうか。
> dif[i][j]=buf[i][j]-now[i][j];
> dif[i][j]=abs(dif[i][j]);
の部分を次のように変えます。ただし、kはその「一定の値」で、0以上とします。
> dif[i][j] = abs(now[i][j] - buff[i][j]) > k ? now[i][j] : 0
このようにすれば、前のフレームとの違いがでた部分だけ抜き出され、
そうでない部分は0の黒身になります。kは原理的には０でいいと思いますが、
動画によっては実際には経験的に得た値にしないとダメじゃないかと
想像します。
0078デフォルトの名無しさん
2006/06/29(木) 20:36:24画像処理で元の色合いに変換させることは出来ますか
0079デフォルトの名無しさん
2006/06/29(木) 20:47:190080デフォルトの名無しさん
2006/06/29(木) 20:58:05普通、裏に白を重ねてやったとしても
コントラスト不足になるはずだけど
008180
2006/06/29(木) 21:03:12008280
2006/06/29(木) 21:20:29ケチョンケチョンに言われそうだがｗ
0083デフォルトの名無しさん
2006/06/30(金) 00:37:20ユニット使わずに、ソフト処理で同等の画質を
得たいというのならそれは虫の良い話
枚数が少なくてユニット買うのがもったいないなら
カメラ屋に持ってくべし
0084デフォルトの名無しさん
2006/07/01(土) 16:31:45透視投影変換？があるようですが、これをＭＦＣのＣＤＣや
ＧＤＩを使って行う方法を教えてください。
何かサンプルがあると助かります。
0085デフォルトの名無しさん
2006/07/01(土) 19:05:273D画像にしてからMFCなりGDIを使うんじゃないのか?
0086デフォルトの名無しさん
2006/07/01(土) 19:07:410087デフォルトの名無しさん
2006/07/01(土) 23:29:152D を 3D に変換するの?
逆じゃなくて?
0088デフォルトの名無しさん
2006/07/02(日) 00:17:310089デフォルトの名無しさん
2006/07/02(日) 00:20:00処理はどうやって行うの？
0090デフォルトの名無しさん
2006/07/02(日) 00:29:44img.MakeNaked();
0091デフォルトの名無しさん
2006/07/02(日) 01:44:450092デフォルトの名無しさん
2006/07/02(日) 08:26:58ご名答です。
たとえば、
ＭＦＣだとイメージとしては、
デバイスコンテキストを作成して、
メモリ上で描画された元の平面画像を、
パース変換して、実ビューに描画したいのです。
パース変換する場合は、画像ファイルをビット単位で、
変換する作業を行わなければならないのでしょうか。。
0093デフォルトの名無しさん
2006/07/02(日) 08:40:020094デフォルトの名無しさん
2006/07/02(日) 08:42:01よくわからないのですが、
遠近でもいいのかもしれません。
平面を手前や奥に傾けれれば。。
0095デフォルトの名無しさん
2006/07/02(日) 08:54:340096デフォルトの名無しさん
2006/07/02(日) 09:03:57つまり、StretchBltみたいなAPIで
そういう変換ができないかってことか。
Direct3Dでテクスチャ貼り付けとか？
まあ、自分で変換するのが楽かもな。
0097デフォルトの名無しさん
2006/07/02(日) 16:01:27不可避なんでしょうか？
0098デフォルトの名無しさん
2006/07/02(日) 16:13:38009997
2006/07/02(日) 16:25:13元ネタがPLAYBOY誌と云う事なんですが、著作権問題はどうなってるんでしょう？
>>98
フリーで配布してるやつ(ShrinkDVDとか)って、そこら辺を無視してると
云う事なんでしょうか？
0100デフォルトの名無しさん
2006/07/02(日) 16:37:39Lennaに関しては、Playboyのコメントがあったはず。ぐぐれば判りますよ。
0101デフォルトの名無しさん
2006/07/02(日) 16:53:57テスト素材として使っても良いよ、ということになってるらすぃ。
■ このスレッドは過去ログ倉庫に格納されています