07/08/29 00:18:31
>488
これ一枚の絵から復元したの？すげえな
493:デフォルトの名無しさん
07/08/29 00:39:58
>>492
the help of a large collection of other high-resolution face images.
494:デフォルトの名無しさん
07/08/29 01:26:16
概要としては似たようなパーツを探して組み合わせるって感じかしら
495:デフォルトの名無しさん
07/08/29 07:07:58
local特徴とglobal特徴のMAP推定するみたいね
金出先生ってまだ生きてるのね
496:デフォルトの名無しさん
07/08/29 09:05:13
>>488
パネルGが恐いよ
497:デフォルトの名無しさん
07/08/29 10:07:23
>>490
eigenま○こ？
498:デフォルトの名無しさん
07/08/29 10:09:17
ここはレベル低いｽﾚだけど、
時々面白い論文とかページが紹介されるので困るな
499:デフォルトの名無しさん
07/08/29 10:17:08
>>488
似たようなのＣＭＵの金出先生がやってなかった？・・・・
と思ったら第一リファレンスか。そうか
500:デフォルトの名無しさん
07/08/29 10:18:02
しかし金出先生は大量データとか大量カメラとか簡単に追随できないものが多くて困る
501:デフォルトの名無しさん
07/08/29 10:33:36
資金も優秀な学生も使い放題だからなー
502:デフォルトの名無しさん
07/08/29 10:52:45
>>497
３番目くらいまでの固有ベクトルが何に対応しているのかは興味がある。
論文載せたら、わいせつ物頒布罪で学会誌摘発かな。
503:デフォルトの名無しさん
07/08/29 12:36:36
サンプリングが大変だな。
504:デフォルトの名無しさん
07/08/30 12:54:37
擬似かどうかも判定できるようになるのか？
505:デフォルトの名無しさん
07/08/30 20:06:01
エロゲに応用… は難しそうだな
506:デフォルトの名無しさん
07/08/30 20:55:11
最近中国人の論文が増えてる気がする
507:デフォルトの名無しさん
07/08/30 21:04:51
人海戦術は昔からじゃないかな
508:デフォルトの名無しさん
07/08/30 21:39:14
査読付きに受かるのもテクニック次第だからな。
内容なんて関係ねー。
509:デフォルトの名無しさん
07/08/31 07:43:16
俺がrejectしてるから安心しろ
510:デフォルトの名無しさん
07/08/31 09:04:12
画像自体のエフェクトの話じゃなくて済まないんだが、BMPのランレングス圧縮を自力でやってみた。
圧縮、展開、表示とうまくいくのでデータの整合性としては正しいと思うんだけど、圧縮結果の容量
がフォトショップで出力した画像より５～８％程度大きい…。
何で差が出るのか画像の中を見てみたら、例えば
AAAABCDEFGHHIJKKKLMNNNNNNN
↓
AAAA BCDEFGHHIJKKKLM NNNNNNN：フォトショップ
AAAA BCDEFGHHIJ KKK LM NNNNNNN：俺プログラム
みたいにフォトショはKKKなど三つ以上連続している場合も不連続領域に含めている感じだった。
おそらくそれで制御コードの容量の差が結果の大きさの違いになって現れたんじゃないかと。
ただ、機械的にやってるわけではなさそうで、単純に三つ以上連続している場合に不連続領域
を止めてるケースや、不連続の途中で（まだ続けられるのに）切ってることもある。
何が聞きたいかというと、容量的に最小になるアルゴリズムってあるのでしょうか？ ってことです。
フォトショのBMPのランレングス圧縮はでかい画像に適用しても結構早いので、PNGの圧縮みたいに
がんばって探してるふうでもなさそうなんで…。
ご存知の方いませんか？
511:デフォルトの名無しさん
07/08/31 09:44:05
フォトショがどうやっているかは知らないがviterbiトレリスを使えば
最適経路が求まるんじゃない？DPの一種だからそんなに遅くないし。
512:デフォルトの名無しさん
07/08/31 09:47:14
viterbiトレリス、DPでググってみます。どうもありがとう。
513:デフォルトの名無しさん
07/08/31 10:01:09
>510
最も原始的かつ確実なのは、実際に圧縮してみてサイズを比較、
そのご一番小さくなった方法で再圧縮、です。
全体でやってもいいし、全体があまりに巨大なとこきは、サンプルを適当に
取り出してやってもかまいません。
514:510
07/08/31 10:43:14
>>513
総当りをする場合、どこを（繋がるけどあえて）切って、どこを（切れるんだけどあえて）繋げて、
っていう候補の一覧の作り方が難しいんです。強引に書いちゃうこともできるかもしれないけど･･･。
515:デフォルトの名無しさん
07/08/31 11:41:32
>514
よくわからないんだけど、一律のルールで、ある画像を圧縮するときの話なら、
そういう問題はでないから、画像の部分部分でランのルールを変えるという
ことでしょうか。
それなら、単純に４０９６バイト単位とか、８１９２バイト単位とかで、同じことを
やればいいんじゃないでしょうか。境界がランを含むなら拡張してもいいし。
なにか根本的に違うことを考えているのかな・・・
516:510
07/08/31 11:59:44
>>515
＞境界
圧縮の単位は行をまたぐことはしていません。行単位で考えています。
＞一律のルール
一律のルール（例えば３バイト連続でも不連続とみなして切らない）を
行の最後まで適用すると、試してみたところ容量は増えてしまうだけでした。
なので１行の中でも、「この部分は３バイト連続だけど不連続とみなす」
「この部分は２バイトの連続がみつかったから切る」など、一律で無い
決定方法が要りそうです。
517:デフォルトの名無しさん
07/08/31 12:21:33
>516
同一の構造を持ったヘッダで、３個連続を残すとか３個連続は圧縮するとか考えてるんですか？
ヘッダの構造をどうするかを決めるのに全体をそれぞれの形式で圧縮してみるという話ですよ＞513
ヘッダ構造が同じなら、圧縮が利くランは全部圧縮するのが一番小さくなるに決まってます。
518:デフォルトの名無しさん
07/08/31 12:42:53
>>510
こっちはスレ違い。
圧縮の方で書きこんだらどうやるか教えてやる。
519:デフォルトの名無しさん
07/08/31 12:54:57
>>513,515,517
BMPのランレンクスフォーマットを使って10画素くらいの画像で脳内シミュレートしてみれ
自分の言っていることのアホさ加減が分かるだろう
520:デフォルトの名無しさん
07/08/31 14:00:48
3つ以上が出てくる度に
連続領域として処理したときのバイト数と
不連続領域として処理したときのバイト数を比較して
少ない方を選択すればいい
なんでこんなに苦労してるの？
521:デフォルトの名無しさん
07/08/31 15:18:44
組み合わせ最適化問題だから
522:510
07/08/31 16:18:14
>>518
移動します。
ｽﾚﾘﾝｸ(tech板)l50
523:デフォルトの名無しさん
07/08/31 17:10:00
>>522
520で結論出ているが。
524:510
07/08/31 19:41:00
すまん。向こうでもスレ違いといわれて、あまりバタバタするのもどうかと思うので、
ここに報告しときます。
>>520
その方法ではうまく行かないもよう。問題点は三つ
・３が最適な数字かわからないので３４５６…と全部試す必要がある
・現時点の最適解が次回の最適解を無効にしてしまう可能性がある。
・総当りに近いので、変換時間がとてつもなく掛かってしまう。
それでもあえて実装して試したところ、多少は小さくなったんだけど、
フォトショの出力より、まだ２～３％大きいという結果で終わってしまった…。
やはり総当りじゃなくて最短経路検索に近いことを考えないと、
少なくとも速度面で実用にならないっぽいです。
525:デフォルトの名無しさん
07/08/31 19:54:00
RLEだよな？
釣られてる？
526:デフォルトの名無しさん
07/08/31 21:05:07
>>510
ハフマンとか算術とか、他にもいろいろな方法があるから。
と突き放すのもどうかと思うんで暇だしマジレスしてやるが
※考えることを少なくするために、256色bitmapを想定する。つまりデータは8bit。
長さの表現に8bit使用するとすれば、圧縮するとき、圧縮フラグに1bit、長さ表現に8bit、データ表現に8bit使用するので
圧縮前の長さが17bitより多い場合に、圧縮できる。
そこで、3pixel以上連続で同じ色が並んでいるところを見つければ、そこを圧縮できる。
勿論、長さの表現を4～5bitにしてみたり(可変は逆にスペース取るから難しい。)すればさらに縮む可能性もある。
但し、「圧縮したかどうか」を表現するために無圧縮の色1pixelあたり1bit余計に保存する必要があるため、完全に無圧縮だと
この場合1.125倍に膨れてしまう。
24bitカラーの場合圧縮できる可能性はもっと低くなるが、最悪でも1.042倍に膨れる程度である。
527:526
07/08/31 21:07:01
で、3つ以上同じ値が出てくるときに圧縮できる可能性がある事は理解できたか？>>510
528:デフォルトの名無しさん
07/08/31 21:08:42
>>526
529:デフォルトの名無しさん
07/08/31 21:13:29
そういう話じゃなくて、BMPにはRLE形式があるからそれのことだろう。
530:526
07/08/31 21:22:50
>>529
それは知らなかった。
> 容量的に最小になるアルゴリズムってあるのでしょうか
容量を最小にすることだけが目的なら
適切な、完全な総当りをするのがいいんだろうが
俺ならこうする。
最も縮む所から折りたたんでいく。全て折りたたむか、或いはどこを折りたたんでも圧縮できなくなるまで。
531:デフォルトの名無しさん
07/08/31 21:38:28
絶対モードじゃね
532:510
07/08/31 21:45:18
一応書いとくと、>>531指摘の通り、絶対モードを少し工夫することで、
真っ正直に圧縮するより多少容量が改善されるということ。
どうしてもフォトショの容量に勝てないのは、やはり先頭から見ていくだけのやり方では
＞・現時点の最適解が次回の最適解を無効にしてしまう可能性がある。
これがあるからだと思う･･･。
533:デフォルトの名無しさん
07/08/31 22:19:07
実例を考えてみた。RLE8ね。コード化モード＝ランレングス、絶対モード＝バイトコピー。
フォーマットは
URLﾘﾝｸ(homepage2.nifty.com)
で勉強した。
----------------------------------------------------
12画素のカラーインデックスが
01 02 03 04 04 04 05 06 07 08 08 08
の場合。最初の６画素に"|"区切り
00 0c 01 02 03 04 04 04|05 06 07 08 08 08 14bytes 全部絶対モード
01 01 01 02 01 03 03 04|01 05 01 06 01 07 03 08 16bytes 全部コード化モード
00 03 01 02 03 03 04|00 03 05 06 07 03 08 14bytes 3バイト連続する部分を両方コード化モード
00 09 01 02 03 04 04 04|05 06 07 03 08 13bytes 最初の３連続は絶対モード、２番目の３連続はコード化モード
6画素までは3番目が最適だが、12画素だと4番目が最適に逆転。
534:デフォルトの名無しさん
07/08/31 22:23:26
この手の離散組み合わせの最適化って難しいよね。
上のhallucinationでも確率伝播やランダムに変異させて組み合わせ最適解を
近似的に求めてるけど局所解に落ちそうな気がする。
535:デフォルトの名無しさん
07/09/01 04:37:55
不可逆な圧縮しか使ってはいけないのですか？
536:デフォルトの名無しさん
07/09/01 06:11:22
いまどきBMPの高だか10%程度の圧縮率向上にこれだけ苦労する価値はあるのだろうか
537:デフォルトの名無しさん
07/09/01 09:46:03
>>536
実務上は、まったくない。
が、そういうスレでもないしな。
538:デフォルトの名無しさん
07/09/01 10:04:11
adobeのライブラリを追っかければ分かるんじゃない？
539:デフォルトの名無しさん
07/09/01 12:04:15
画像データなんだから、画像データならではの圧縮を考えればいいのに
540:デフォルトの名無しさん
07/09/01 12:10:42
jpeg2000とかか
541:デフォルトの名無しさん
07/09/01 13:17:53
ｐんｇ
542:デフォルトの名無しさん
07/09/01 15:32:38
「行」でやるより「周辺」でやったほうが圧縮率多分いいよね
543:デフォルトの名無しさん
07/09/02 02:19:19
ちょっと画像処理からはずれるかもしれませんが…スレ違いだったらごめんなさい。
boost::gilでJPEG画像の読み込みor書き込みをする際にlibjpegが必要になるのですが、
自分でコンパイルしたファイル(libjpeg.lib)だとうまくいくのに、
GnuWin32 URLﾘﾝｸ(gnuwin32.sourceforge.net)
からダウンロードしたバイナリだと、
jpeg_read_image();
の呼び出し時にエラーが起きます。
test.exe の 0x7c958fea でハンドルされていない例外が
発生しました: 0xC0000005: 場所 0x00000010 に書き込み中に
アクセス違反が発生しました。
どうもjpeg62.dllの内部でエラーが起こっているようなのですが、
いくら検索しても同じような現象が起こっているという例が見つかりません。
対処法がわかる方はいますか？
544:デフォルトの名無しさん
07/09/02 03:11:45
>543
>自分でコンパイルしたファイル(libjpeg.lib)だとうまくいくのに、
で拡張子が .lib だから VC 系じゃないかと思うのだが、GnuWin32 は MinGW で
コンパイルされているわけで。
libjpeg に対して FILE* を受け渡してるんだけど、構造体に互換性あったっけ？
545:デフォルトの名無しさん
07/09/02 03:31:00
>>544
すみません、環境書いてませんでした。
環境は、WinXP + VC8です。
エラーは、>>543の関数内部で
jpeg_read_header();
を呼び出したときにおこっています。
スタティックライブラリだけでなく、DLLの場合でも、
MinGWとVC8間での互換性はないのでしょうか？
一応.defファイルからvc8のリンカを使ってインポートライブラリを
作成してみましたが、同様のエラーが起こりました。
546:デフォルトの名無しさん
07/09/02 03:58:57
>>545
他人のレスは注意深く読もう。ここ読めてる?
＞libjpeg に対して FILE* を受け渡してるんだけど、構造体に互換性あったっけ？
結論から言うと、互換性がない。
547:デフォルトの名無しさん
07/09/02 04:16:33
>>546
わかりました。
ありがとうございます。
548:デフォルトの名無しさん
07/09/04 00:18:09
OpenCVって64ビットWindows用のはありませんか？
６４ビットにしたらDLLが使えなくなったので探してるんですが。
549:デフォルトの名無しさん
07/09/04 00:31:57
わざわざOpenCVスレがあるんだからそっち行け
550:デフォルトの名無しさん
07/09/04 00:37:14
すみません
見落としてました
551:デフォルトの名無しさん
07/09/05 03:37:00
すみません質問させてください
鏡は左右が反転して見えるのに
上下は反転しないのはなぜでしょうか？
552:デフォルトの名無しさん
07/09/05 03:45:12
それはよくある誤解だ。
鏡で反転しているのは左右ではなく、奥行き。
553:デフォルトの名無しさん
07/09/05 04:13:57
>>551
スレ違い
去ね
554:デフォルトの名無しさん
07/09/05 04:25:24
URLﾘﾝｸ(www.google.co.jp)
555:デフォルトの名無しさん
07/09/05 04:26:10
お前ら優し杉
556:デフォルトの名無しさん
07/09/05 04:42:28
URLﾘﾝｸ(www.youtube.suppa.jp)
557:デフォルトの名無しさん
07/09/05 04:52:25
URLﾘﾝｸ(www.youtube.suppa.jp)
558:デフォルトの名無しさん
07/09/06 18:15:10
ホログラムをプログラムしたら
画面から飛び出ますか
559:デフォルトの名無しさん
07/09/06 18:16:49
で、何が望みだ？
エロゲだな。素直に白状しろ。
560:デフォルトの名無しさん
07/09/06 20:37:40
BLです
561:デフォルトの名無しさん
07/09/07 11:53:36
>>479
18,648円に暴騰。投資しとけばよかった。
562:デフォルトの名無しさん
07/09/07 12:04:16
滑らかなグラデーションに適したロスレスの圧縮方法教えて。
ランレングスやスライド辞書では縮まんねえす。
563:デフォルトの名無しさん
07/09/07 12:24:31
動きベクトル
564:デフォルトの名無しさん
07/09/07 12:34:01
隣のピクセル （左とか上とか） との差を取って、それを圧縮するっていうのは？
滑らかなグラデーションなら、隣と差を取るとほぼ一定のパターンが続くんじゃないかな
たしか PNG にはそういうオプションがあったような
565:デフォルトの名無しさん
07/09/07 13:36:13
線形予測でもかなりいけそうな感じがするけど
URLﾘﾝｸ(ssl.ohmsha.co.jp)
566:デフォルトの名無しさん
07/09/07 15:30:03
>>561
俺は>>479の時点で注文したっていうか、その479自身なわけだけど
あの時点でamazon.comの値段と円相場で比較しても、.co.jpの方が
安かったよ。
で、即注文したんだが
配送予定日： 2007/9/20 - 2007/10/6
いまだにこんな状態。
まぁ、ゴンザレスに待たされた時間に比べたらどうってことないが。
567:デフォルトの名無しさん
07/09/07 15:53:39
カメラの自動追尾ってどうやるんですか？
カメラが動いていない状態でのセンシング、トラッキングは出来ましたが、
カメラが動くときのアルゴリズムが思いつきません。
568:デフォルトの名無しさん
07/09/07 16:00:18
金谷先生の本や新聞を調べろ
569:562
07/09/07 17:09:27
どうもありがと。調べてみるす。
570:デフォルトの名無しさん
07/09/07 19:29:44
>>533
今更だけど、3番目と4番目はRLE8の仕様になってないな。WORD境界にそろえとけ、結果が変わるぞ。
あと、PhotoshopのBMP-RLEの圧縮率はよくないと言っておく。
571:デフォルトの名無しさん
07/09/07 20:41:09
便乗で俺も補足しておくけど、自分でコード書かなくても
DIB関係のAPIでRLE圧縮してくれるよ。
572:デフォルトの名無しさん
07/09/08 08:47:38
>>570
で、サイズを最小にするアルゴリズムは？
573:533
07/09/08 09:48:31
>>572
最小になるアルゴリズムは巻き戻ししないといけないと思うが、そこまでやってないし、やる必要も感じない。
処理がシンプルなのがRLEの特徴だから、それを潰す必要はないと思うんでね。
が、少なくとも巻き戻しなしでPhotoshop(当方8.0)の圧縮率は超えられる。
基本的に以下を守ればいいはず
・絶対モードのラン(?)は偶数にする(奇数ではパディングの分だけ損)。
・絶対モード後にコード化モードがあり、かつランが2の場合はコード化したほうがよい。
これに従うと、>>533の例では、絶対モードのランは10がベター(後続データ次第では12)だな。
574:533
07/09/08 09:52:31
スマン
誤: ・絶対モード後にコード化モードがあり、かつランが2の場合はコード化したほうがよい。
正: ・絶対モード後にコード化モードがあり、かつランが2の場合はコード化しないほうがよい。
つまり絶対モードのままだ。
575:デフォルトの名無しさん
07/09/08 10:20:00
オオボケしてる
570=573=574 != 533
だ。
>>533 申し訳ない
576:デフォルトの名無しさん
07/09/09 12:47:41
510
>>574
＞少なくとも巻き戻しなしでPhotoshop(当方8.0)の圧縮率は超えられる
うらやましい。こっちはなんでダメなんだろ。絵によるのか、プログラムが
間違ってるのかも。
>>571
それは知りませんでした…。
577:デフォルトの名無しさん
07/09/09 23:51:10
>>576
俺がライブラリを作った当時は8bit化した自然画やノイズ画像も比較した記憶がある。絵によるとは思えない。
巻き戻しなしでいける、という事は、単純なコスト計算だけでいけるという事を意味している。
板的には面白みのない話だが、つまり、その場その場でどちらのモードが有利か判断すればいいだけだ。
>>533の例を見る限り、仕様を勘違いしてるんじゃないかとも思えなくもない。
自作のプログラムで符号化したものは、Photoshopやペイントブラシで開ける事は確認したか？
余談だが、Adobeほどの所が(MSの腐った仕様とはいえ)、
この程度の圧縮率のままで改良もしてないというのはおかしい気もする。
俺が把握してる限りでは、Photoshop4.0の頃からRLE符号化アルゴリズムは変更されていない。
特許があるのか、まっとうなRLEが開けない糞デコーダでもあるのか…
578:デフォルトの名無しさん
07/09/10 07:29:24
だから520でいったとおりだろ
533がへぼ
579:デフォルトの名無しさん
07/09/10 18:04:54
>>578
533がヘボというのはその通りだが「Photoshopにも勝てないなんて、どんなエンコーダ書いてるんだよ」って理由だし、>>520と>>577は言ってる事違うだろ。
ましてや、裏付けがあるのか思いつきで書いたのか区別できんもんを自慢気に見せられてもなー。
折角だから、サービスな。WindowsBMP-RLE8のコストはこんな感じ。
・絶対(ラン奇数) : +3bytes
・絶対(ラン偶数) : +2
・コード化(ラン1) : +1
・コード化(ラン2) : 0
・コード化(ラン3) : -1
・コード化(ラン4) : -2(つまりコード化モードは -(ラン-2))
サイズを小さくしたいなら、ラン奇数の絶対モードは使わずに+1して偶数にしてしまっても損はない。じつは、これが一番サイズに寄与しやすい。
コード化モードのラン4以上は無条件で採用していいし、ラン2は絶対モードに組み込んだ方が損がない(得もない)。
最小サイズを目指す場合に最適化が必要なのは、絶対モードの途中にコード化ラン3がある場合だけで、デコーダの負荷を考えたとしてもラン4まで。
もっとも、このケースだけなら>>524のように総当りが必要とも思ってなくて、
後に続くのが絶対モードかコード化モードかだけで判断できるはずだが、これは俺も実験してない。5画素先読みするだけでほぼ最小サイズにできると思うので、533が試してくれれば嬉しい。
#他に、前方検索だけで最小化するなら検討すべきだが挙がってないケースもある。レアなうえにたいして小さくもならないんだが。
んで、>>533は間違ってはいるんだが、前方検索を考えるならポイントは外してない。
ここで>>520が>>577と同じだと言うんなら、あれは最適解を都度求めろという意味じゃなくて、こうやって説明しなくても>>533に類する問題の解は明らかだという意味なのか？
そうでなきゃ、問題認識できてない578は533よりヘボだ。
580:デフォルトの名無しさん
07/09/10 18:05:38
ついでに言うとPhotoshopはどーみても組み合わせ最適解なんて求めてない。
・ラン奇数の絶対モードも躊躇なく使う
・ラン4以上はコード化、4未満は絶対モード(行開始時くらいはコード化だろうが調べてない)
みたいな、ごく単純な規則でやってるように見える。
前者はお粗末だし、後者は速い実装にはなるかもしれないが、サイズはお察し。
Adobeのライブラリを追いかけても、Photoshop同等にはなるかも知れないが>>533問題は解決しない。
でだ、>>538と>>578が同一人物かどうかはわからんが、もしそうなら、まぐれ当たりで喜んでるヘボだと思うよ。
#これが>>536でも指してくれてたら諸手を挙げて賛成なんだが。
581:デフォルトの名無しさん
07/09/10 18:19:13
ﾀﾞﾗﾀﾞﾗと長すぎ
582:デフォルトの名無しさん
07/09/10 18:41:56
ｽﾏﾝ、余計な事まで書きすぎた
583:デフォルトの名無しさん
07/09/10 23:53:43
今Win32APIで画像アプリ作ってますが
メモリ管理がかったるいです。
で、C#に移ろうかと思ってますが
速度が遅そうなのが気になってます。
実際どうなんでしょう？
584:デフォルトの名無しさん
07/09/11 00:02:19
>>583
試してから言えば？
585:デフォルトの名無しさん
07/09/11 00:11:51
コアの部分だけネイティブにすればいいんじゃね
586:デフォルトの名無しさん
07/09/11 01:38:07
>>583
そりゃ遅いさ。あと、人間の許容範囲の待ち時間なのかどうかは C++ にしろ C# にしろ処理によるとしかいえんさ。
587:デフォルトの名無しさん
07/09/11 04:29:02
マネージドコードでやろうとすると死ぬほど遅いよ。
結局unsafe。
588:デフォルトの名無しさん
07/09/11 09:40:31
>>583
Ｃ＃が遅いのは最初の、ＩＬを翻訳しながらロードしてるときだけ。
安心したかい？
589:デフォルトの名無しさん
07/09/11 10:51:15
その最初の印象だけで遅いという人はいるがなー
590:デフォルトの名無しさん
07/09/11 12:00:21
減色で遊んでるんだけど、チャンネルの諧調落しやメディアンカット
では256色、8bit内に収めようとした場合、マッハバンドが
抑えられない。（ディザはとりあえず考えないとして）
綺麗な減色を謳ってるソフトを試すと、ディザ無しの256色でも
グラデがそこそこマッハバンドが目立たないように変換されてる。
（自分でやったのとは雲泥の差）
パレットを見ると双方とも大差なさそうなので、ピクセルへのパレット
の割り当てにコツがあるんだろうか？
一応メディアンカットでは、分割場所や分割優先度にピクセルの
使用頻度を加味するなど一工夫加えてみたつもりだが、
パレット抽出を多少ひねった程度では改善できんかった…。
ヒントください。
591:デフォルトの名無しさん
07/09/11 12:24:07
まあ色々がんばれ
おまいさんがどうやっているのか、その書き方だけでは全然わからんが、
とりあえず、他のツールで作った画像のパレットを使って
自分の書いたコードで同じようにピクセルへのパレットの割り当てしてみ
それでマッハバンドが出るか出ないかで問題の切り分けができる
592:デフォルトの名無しさん
07/09/11 13:52:02
>>583
C#でやるなら
URLﾘﾝｸ(junki.lix.jp)
ここが参考になるよ。
コアをC++/CLIで書けばもっとよくなる。
593:デフォルトの名無しさん
07/09/11 13:58:27
>>590
メディアンカットで再起分割したものを初期値としてLBGクラスタリングしているけど、
まあまあの品質いくよ。太ももの微妙なグラデーションでもマッハバンドが目立たない。
これだけでは、まだまだ市販の減色ツールには勝てないけれど。
594:デフォルトの名無しさん
07/09/11 14:13:39
なぜに太もも
595:デフォルトの名無しさん
07/09/11 14:47:15
>>593
どんな感じか画像が見たい(*´Д`)ﾊｧﾊｧ
596:デフォルトの名無しさん
07/09/11 15:21:17
590
>>593
うらやましす。LBGでぐぐってみる、さんくす。
597:デフォルトの名無しさん
07/09/11 21:00:10
>>596
３次元ベクトルで量子化していると思うけれど、いろんな色空間を試してみ。
色空間が異なるだけで、まるで違う結果になるから。
598:デフォルトの名無しさん
07/09/12 06:19:16
凄い初心者な質問で申し訳ないのですが、
白い背景に「あ」と書いてあるjpg画像を数値にするには、
まず
1 あ.jpgを何らかの方法で読み込む
2 あ,jpgの1ピクセル分の色を記憶する、配列[あ.jpg縦のピクセル][あ.jpg横のピクセル]を用意
3 縦軸をy、横軸をx、左上を(0,0)とすると、
for(y=0;y<画像の横のピクセル数;y++){
for(x=0:x<画像の縦のピクセル数;x++){
配列[x][y]=今のピクセルの色の数値(#FFFFFFとか?);
}
}
のようにすればよいのでしょうか?
凄い素人考えなんですけど…
599:デフォルトの名無しさん
07/09/12 06:55:06
>>598
あなたがそれでいいと思うのならそうでしょう。
私には、あなたが言う「jpg画像を数値にする」が一体何をどうしたいのかが判りませんので。
600:デフォルトの名無しさん
07/09/12 07:38:08
えっと、画像の比較をやってみたいんです。
例えば
白い背景に一と書いてあるjpg画像と二と書いてあるjpg画像
を比較する場合、一般的にはどのようにするのかなと思って。
601:デフォルトの名無しさん
07/09/12 08:26:34
>>600
＞一般的にはどのようにする
こんなところで初歩の初歩から質問せず、ちゃんと勉強する。
602:デフォルトの名無しさん
07/09/12 10:40:47
わかりました。
ちなみにおすすめの本はどんなのでしょうか?
603:デフォルトの名無しさん
07/09/12 15:16:00
>>602
まったくわかってないじゃないか
604:デフォルトの名無しさん
07/09/12 15:31:24
ﾜﾛﾀ
605:デフォルトの名無しさん
07/09/12 15:36:21
「この絵と同じパレットになるように減色する」
って機能を持った減色アプリってある？
606:デフォルトの名無しさん
07/09/12 18:08:53
>>605
「この絵」のパレットファイルを出力して、そのパレットファイルで減色する、
でよれけば、optpixにある。
607:デフォルトの名無しさん
07/09/12 18:24:28
減色アプリでは無いがドットツールのEDGE。
256色画像を開いて、減色したい絵を上からペーストする。
色の近いパレットを選択するだけだから結果は大抵ひどいものになるけどな。
608:605
07/09/12 20:33:31
>>606-607
サンクス
optpixってちょっとだけ値段が高いんだな
とりあえず無料のEDGEを試してみたりしてみる
609:598
07/09/14 02:13:02
すいません質問です。
libjpegを使って、jpeg画像を展開してメモリに読み込む事はできるようになったの
ですが、これを白黒に変換するにはどうすればよいでしょうか?
一度メモリに読み込んだ画像を白黒画像に変換するのは難しいような感じがするのですが、
gimpなどスクリプトで使って、先に画像を白黒に変換してからメモリに読み込むのが普通でしょうか?
610:598
07/09/14 02:17:35
すいません、OpenCVを使えばやりたい事が出来そうです。
でも、これってLinuxとWindowsしかサポートしてないのか…
611:デフォルトの名無しさん
07/09/14 03:11:30
クマー
612:デフォルトの名無しさん
07/09/14 04:04:05
>>598
何をしたいのか具体的に書こうという気はないのか?
白黒に変換するロジックさえ自力で書けないならそこもライブラリを使えばよかろう。
LinuxやWindowsでなくてもImageMagickなり使えるライブラリはあるだろ。
613:デフォルトの名無しさん
07/09/14 04:18:23
画像処理の「いろは」から勉強した方がいいかと。
画像処理以前に、自分のOS上でビットマップを表示する方法すら
分かってないようだし。
614:デフォルトの名無しさん
07/09/14 04:31:00
足し算からはじめよう
615:デフォルトの名無しさん
07/09/14 06:12:01
>>600
なんでだよ。じゃあgimpはどうやってやってるんだよ。
616:デフォルトの名無しさん
07/09/14 06:14:52
くまー
617:デフォルトの名無しさん
07/09/14 07:57:59
>>609
> 一度メモリに読み込んだ画像を白黒画像に変換するのは難しいような感じがするのですが、
むしろメモリに読み込めてしまえばあとは何でもありだろ
618:デフォルトの名無しさん
07/09/14 11:23:48
メモリに読み込まずに変換するっていう方が難しいと思うが
619:デフォルトの名無しさん
07/09/14 14:04:42
>>609
プログラムは分かるんだから、光の３原色とか勉強すれば
いいんじゃなの？RGBってのが分かってたら、白黒（っぽい）
変換なんて１秒で思いつくよ。
それともRGBの24bitをグレースケールの8bitに変更したいっ
てことだろうか？？ それにしたって大した処理じゃない。
libjpeg引っ張ってきて画像ファイルをロードできるくらいにプログラムが
分かってるのに、白黒への変換操作が分からないなんて、ものすごく
アンバランスじゃないかな。
どんな人なんだろう…
620:デフォルトの名無しさん
07/09/14 20:37:10
jpegならもう白黒画像のデータを含んでるじゃないか
色情報省くだけだろ
RGB形式やCMYK形式も一応あるが、ここでは考えないということで。
621:デフォルトの名無しさん
07/09/14 21:59:46
足して３で割るんだｗ
２値化なら１２８を閾値にして２つわけろｗ
622:デフォルトの名無しさん
07/09/14 22:30:40
黙れバカモノ
623:デフォルトの名無しさん
07/09/14 23:09:43
いい歳こいた大人が、白だの黒だの…
624:デフォルトの名無しさん
07/09/14 23:34:06
かまわん！
全部赤で塗りたくれ！
625:デフォルトの名無しさん
07/09/15 00:24:26
>>598
利用しやすくなったダイナミックリコンフィギュラブルプロセッサ技術
URLﾘﾝｸ(journal.mycom.co.jp)
626:デフォルトの名無しさん
07/09/15 00:45:18
一瞬「ダイナミック離婚」ってなんだろうと思ってしまった
627:デフォルトの名無しさん
07/09/15 02:40:39
静的離婚もあるのか
628:デフォルトの名無しさん
07/09/15 03:05:06
性的離婚ならありそうだが
629:デフォルトの名無しさん
07/09/15 04:20:03
誰がうまいこと言えと
630:デフォルトの名無しさん
07/09/15 08:06:53
最近顔チェキっていう、
顔の写真から、芸能人にどのくらい似ているかを判断するサービスがありますよね。
あれって、どういう仕組みで動いているんでしょうか?
たとえば、この人の目はキムタクに似ているっていうのだけでも、
まず人の顔の中から目の部分を見つけないといけないですよね。
どうやって目の部分を見つけたしているんでしょうか?
631:デフォルトの名無しさん
07/09/15 08:32:45
顔認識という研究分野があります。
目など各部位を見つけて比較する手法もありますが、顔写真全体にある種のフィルタをかけてそれを比較するだけの手法もあります。それでそこそこ結果はでます。
おそらく顔チェキは低精度の単純な顔認識システムをもちいて、本来ならば誤認となるところを、顔が似ている、という解釈にもっていっているだけでしょう。
簡単なわりには高精度の結果がだせる有名な顔認識の手法としてはPCAを用いたeigenface（固有顔）システムというものがあります。
まずはそれから勉強してみてはいかがでしょう。
＃しかし素人しかこないなここ。
632:デフォルトの名無しさん
07/09/15 08:56:48
OKIのFSEというミドルウェア使ってみるみたいね
DSにものっかるくらいだから軽量なのかねえ
633:630
07/09/15 09:40:28
>>631
有り難うございます。
eigenface（固有顔）システムというのは、
たくさんの顔の写真の平均値?みたいな物を求めて、
たとえば、Aさんの写真－たくさんの顔の写真の平均値が
人の顔の形の範囲内だったらコレはAさんだ!と認識する方法
みたいな感じなのでしょうか?
634:デフォルトの名無しさん
07/09/15 10:29:03
>>633
そこは調べなさい。数学必須です。
635:630
07/09/15 10:40:34
サンプルとしてソースコードって無いんでしょうか?
636:デフォルトの名無しさん
07/09/15 10:56:42
調べろって言ってんだろ
637:デフォルトの名無しさん
07/09/15 11:41:29
>>625
フォーマルメソッドなしで、いきなり思いつきでプログラムしてもいけるってことか
638:デフォルトの名無しさん
07/09/16 10:36:37
>>620
便乗質問なんだけど、jpegを展開する前に色データに加工したいんです。
例えばlibjpegのAPIなら、jpeg_read_scanlinesを呼ぶ前に、色情報のみ
をグレースケール化や色相回転させて、jpeg_read_scanlinesで展開された
結果には、先に行った色変換が反映されている、というような感じです。
＞色情報省くだけだろ
ということは、色情報のみにアクセスするAPIがあるのでしょうか？
展開後のビットマップの大量の面積を処理するより、色にだけ処理
する方が高速化できるんじゃないかという目論見です。
APIリスト眺めてもそれらしいのが分からなかったので、もしあれば
情報お願いします。
639:デフォルトの名無しさん
07/09/16 10:53:54
APIでは用意されてないんじゃないかな
640:デフォルトの名無しさん
07/09/16 11:08:13
>>639
うへぇ、了解です。
データ構造把握は俺にはちょっと無理そうだなあorz
641:デフォルトの名無しさん
07/09/16 11:09:56
libjpeg使ったこと無いけど、
jpeg_read_scanlinesがJPEG展開したあと、ついでに自動で色変換しているだけだと思う。
642:デフォルトの名無しさん
07/09/16 12:02:51
jpeg_decompress_structのout_color_spaceにJ_COLOR_SPACE列挙値適当につっこめばいいような気がするがソースまでは追ってないので知らん。
643:デフォルトの名無しさん
07/09/16 12:16:00
>>642
J_COLOR_SPACE列挙対に用意されてる以外の変換を、
データが膨張する前の展開前の色部分にのみ施したい…
というのがやりたいことなんだが、的外れなこと言ってる？
展開したあとにビットマップ弄るのと類似するやり方だと、
大して高速化は期待できないんですよ。
644:デフォルトの名無しさん
07/09/16 12:49:10
JFIFで言えば、YCrCbにしてDCT変換してハフマンで符号化しているだけだから、
展開するまで色なんか分からないんじゃ・・・８ビットカラーの話ですか？
645:デフォルトの名無しさん
07/09/16 12:52:06
>>644
うわ。やっぱりそうか…ありがとうございます。
646:デフォルトの名無しさん
07/09/16 15:34:01
まあ展開しつつ色変換するのと、全部展開してから全部色変換するのでは、速度的にほとんど変わらんわな
647:デフォルトの名無しさん
07/09/16 16:07:03
>>638
もうおわってるっぽいけど。
>>620 が言っているのは jpeg をグレースケール化する場合 jpeg のアルゴリズム的に展開時
ハフマンデコード→逆zigzagスキャン→逆量子化→逆DCT変換→YCbCr to RGB
だから、グレースケール化するのに色情報を省けってのは
YCbCr to RGB 変換をしないで Y のところだけ使えってことで、つまりそこでの CbCr （色情報）を捨てろってこと。
jpeg ファイル構造にパレット格納領域があって、とかそういう話じゃない。
つーか >>620 の回答は >>609 のレベルに対しては適切なアドバイスじゃないと思うけどな。
648:デフォルトの名無しさん
07/09/16 23:15:24
638
>>647
そもそもなんでそんな発想になったのかというと、以前jpeg2000
（ウエーブレット変換？）の展開途中の状態を無理やりビットマップに
書き出したことがあって、左上（？）だけのカラーが集中した部分と、
そのほかの成分の再帰的な配置が頭の中に残ってたからなんですわ。
そのカラー情報（っぽい）部分の面積が小さいうちにそこだけモノクロ化して
しまえば、展開後の全体がモノクロになりそうだったので（実際試したわけ
じゃない）ひょっとしてjpegの成分復帰中にどこか小領域にカラーが集中して
たらいいなあとろくに仕組みもチンプンカンプンなのに聞いてしまいました。
＞YCbCr to RGB 変換をしないで Y のところだけ使えってことで
なるほどモノクロ化だけなら後でやるのに対して変換時間を
ゼロに出来そうですね。
649:デフォルトの名無しさん
07/09/17 02:15:58
>>648
カラーが集中ってのはなんか変な表現だな。せめて強度が集中？
DCT にしろ wavelet にしろ
左上が近似情報（低周波成分）、右下が詳細情報（高周波成分）になります。
一番左上なら画像全体の平均値です。それを集中と表現しているのかな。
まぁそもそも jpeg の場合は Y チャネルがすでにあるから >>647 で言ったとおり一連の処理を Y チャネルに対してやるだけで勝手にグレースケールだからいいとして、
RGB に対してそれらの処理をやっていると仮定した場合に途中でグレースケール化できるのかどうかを考えてみよう。
左上の近似情報だけをモノクロ化して、と言っているけれど、
そうしたら右下の詳細情報は利用しないのかい？すてちゃうの？
そうしたら違う画像になってしまいますよ。いくら詳細っていってもさ。
ただでさえ lossfull なのにもっと loss しちゃいますよ。それがお望み？
＃というかそもそも DCT 変換、ウェーブレット変換後は周波数ドメインになっているから、周波数ドメインでモノクロ化ってのがピンとこないけど。
空間ドメインでのポイントオペレータ（モノクロ化計算式）は、周波数ドメインだとどうなるんだろう？→ただの定数掛け算、足し算だから周波数成分でもただの定数掛け算、足し算かな？
650:デフォルトの名無しさん
07/09/17 05:07:49
>>649
>まぁそもそも jpeg の場合は Y チャネルがすでにあるから
フォーマット上は、あるとは限らないよ。JFIFならあるけれど。
651:デフォルトの名無しさん
07/09/20 09:12:27
jpgの話題ついでに、ちとスレ違い気味なんだけど、教えてエロいひと。
フォトショなんかでjpgで保存すると、ベースライン（一枚画像）よりも
プログレッシブ（ネットとかで荒い画像から出てくるやつ）のほうが
同じ品質でサイズが小さくなる。
これ、何故でしょうか？ 同じ品質でおまけがつくプログレッシブの
方が大きくなると思うんだけど、圧縮のアルゴリズムとなんか関わ
ってるのかな？
652:デフォルトの名無しさん
07/09/20 12:02:35
詳しくは知らんが、wikipedia にもそう書いてあるね
URLﾘﾝｸ(en.wikipedia.org)
＞Baseline Progressive JPEG encoding usually gives better compression as compared to Baseline Sequential JPEG
653:デフォルトの名無しさん
07/09/20 12:16:02
>>652
その直後に理由として
> due to the ability to use different Huffman tables (see below) tailored for different frequencies
> on each "scan" or "pass" (which includes similar-positioned co-efficients)
って書いてあるやん。
654:デフォルトの名無しさん
07/09/20 15:04:52
各「スキャン」の異なった頻度のために仕立てられた異なった
ハフマンテーブル(以下を見る)を使用するか、または「通る」能力
のため(同様に置かれた係数を含んでいます)
さぱーり
655:デフォルトの名無しさん
07/09/20 19:27:36
画像のスケールに応じたハフマンテーブルを使ってるぽいね
画像全部を符号化せずに
荒いやつを符号化＋もちっと細かいやつを符号化＋細かいやつを符号化
って感じに段階的にやってるんちゃう？
656:デフォルトの名無しさん
07/09/21 05:48:14
画像のチャネルって何ですか?
657:デフォルトの名無しさん
07/09/21 07:22:44
音声のチャネルがたとえば左右とかだったりするわけだけど、
画像のチャネルは普通、RGBとかYGbGrとか色空間の各要素のことを言うと思う
他の意味もあるかも
658:デフォルトの名無しさん
07/09/21 08:00:12
>>657
まあアルファとかあるしな。＞他
659:デフォルトの名無しさん
07/09/21 09:13:55
ありがとうございます。
つまり、
RGBは3チャネル
R,G,Bは各一チャネルづつ
ってことで良いでしょうか?
660:デフォルトの名無しさん
07/09/21 09:26:44
>>659
adobe関連で言うところのチャンネルというのは、様々な種類の情報を保存するグレースケール画像のこと。
それ以上でも以下でもないので注意。
photoshopで言えば、これにカラー情報チャンネルだのアルファチャンネルだのスポットカラーチャンネルだのがあって、
それぞれ与えられた意味が異なるだけで、データとしては単なるグレースケール画像。
661:デフォルトの名無しさん
07/09/21 10:06:17
つーか、単純に channel っつー、訳すなら通信路という言葉があって、
テレビのチャンネルみたいに、
これのこの道、それはその道、とわかれていることを示したい時に
よく使われる言葉に過ぎない。
662:デフォルトの名無しさん
07/09/21 10:20:21
channelの元々の意味は水路。運河canalと語源一緒。
663:デフォルトの名無しさん
07/09/21 12:26:26
>>661>>662
そこまでいくと却って分からん
664:デフォルトの名無しさん
07/09/21 12:39:48
ImageJ知ってる人います？
665:デフォルトの名無しさん
07/09/21 20:38:11
>>664
顕微鏡画像の処理によく使ってるよ
666:デフォルトの名無しさん
07/09/22 14:43:36
顕微鏡画像の処理ですか。なるほど。
ImageJのプラグインについても詳しいですか？
667:デフォルトの名無しさん
07/09/22 15:56:26
小出しに質問して何かいいことありますか？
668:デフォルトの名無しさん
07/09/22 16:30:31
詳しくなければ質問しても意味がない
→質問を書く時間が省ける
ぐらいかなぁ。
669:デフォルトの名無しさん
07/09/22 16:45:57
665じゃないけど詳しいよ
670:デフォルトの名無しさん
07/09/22 18:10:39
>質問を書く時間が省ける
そんな人には
詳しいから回答したいが、回答を書く時間を省きたいから書かない
671:デフォルトの名無しさん
07/09/22 21:12:31
>>667
長いこと構って貰える。スルー。
672:デフォルトの名無しさん
07/09/23 01:58:22
>>670
いいんじゃないか、それで。
でも実際暇人ってのはいるもので
673:デフォルトの名無しさん
07/09/23 02:05:51
暇人だけど詳しくない。
674:デフォルトの名無しさん
07/09/24 00:39:18
>>666
665だけど詳しいよ
675:デフォルトの名無しさん
07/09/24 00:41:01
>>666
665じゃないけど詳しくないよ
676:デフォルトの名無しさん
07/09/24 00:42:35
今後流行りそうな画像処理ビジネスってなにかある？
677:デフォルトの名無しさん
07/09/24 00:43:07
バイオ
678:デフォルトの名無しさん
07/09/24 04:55:37
665だけどバイオなんて流行らないと思う
ネット上の動画の検索とかどうかな
679:デフォルトの名無しさん
07/09/24 09:35:08
665じゃないけど、バイオ分野は流行ってるんじゃないの？大学の予算とかみてもすげー高いし。
画像処理をどう使うのかは知らんけど。
検索系は流行るかもしんないけど、今から追いかけても技術的にはつらそうな気がする。
ビジネス的には分からん。
680:デフォルトの名無しさん
07/09/24 09:55:32
画像検索系は結構行き詰まっている感じがする。
同じような画像の抽出のように、元画像があれば単なる特徴抽出でなんとかなるかもしれないが、
例えば、ブルドックの画像とか、こたつみかんの画像とかということになると、画像から
そこに表現されているものが何かを判断しなければならず、これは相当難しい。
技術的には、何らかのブレイクスルーが必要だろう。
だからそれを何とか出来るなら、ビジネス的にも大ブレイクするのではないだろうか。
681:デフォルトの名無しさん
07/09/24 13:16:02
>>679
バイオ系には予算がついてても、日本ではその多くは
wetな実験、それも「網羅的何とか」とか「何とかオーム」みたいな
力任せな研究の機材や人件費に費やされていて
画像関連のアルゴリズムの話はほとんど聞かない
682:デフォルトの名無しさん
07/09/24 15:28:40
ということはバイオ＋画像はビジネスチャンスというわけか
683:デフォルトの名無しさん
07/09/24 15:41:35
微生物の力で画像探索・・・
684:デフォルトの名無しさん
07/09/24 16:15:47
絶対領域に集まる微生物…
685:デフォルトの名無しさん
07/09/24 18:46:19
そういや粘菌が迷路の最短ルートを探索するって論文あったな。画像処理とはちょっと違うけど。
686:デフォルトの名無しさん
07/09/24 19:32:06
もうすぐ来るといわれる4k2k時代の画像処理ってどうなるんだろ。
ビジネスチャンスの山なのだろうか？
687:デフォルトの名無しさん
07/09/24 19:50:08
解像度が上がるだけで、この板的には何も変わらないんじゃないかな
688:デフォルトの名無しさん
07/09/24 20:11:40
GPGPUみたいに、あるいはmany coreでもいいけど、
並列度の高い計算環境が広く普及して多くの人が並列処理の手法を考える機会を得た結果、
新しい考え方やアルゴリズムが出てくると面白いんだけど期待できないかな
689:デフォルトの名無しさん
07/09/24 20:37:21
てめぇがやれよ
690:デフォルトの名無しさん
07/09/24 21:21:27
おまいは文盲か
691:デフォルトの名無しさん
07/09/24 23:10:55
画像から検索するサイトができて欲しい。
手持ちの画像が使われてるサイトを探す検索エンジン。
サーバーにものすごい投資がいりそうだけど。
692:OpenCVVVV
07/09/25 02:08:49
OpenCVで画像処理の勉強してる初心者です。
OpenCV使ってサブピクセル単位のブロックマッチング
をするようなプログラムソースを公開してるサイトと
か知りません？もしくはなんかよい方法知ってれば教
えてほしい・・・
693:デフォルトの名無しさん
07/09/25 02:13:55
>>691
たしかそういうのあるよ
知ってるのは著作権違反してるサイトを見つけるためのビジネスなんだが
例えば何かのキャラクターの画像を入力してWebを検索すると
その画像が張ってあるサイトが出力されるってかんじの。
694:OpenCVVVV
07/09/25 02:18:47
OpenCVのスレで聞けってかんじですよね。失礼しました
695:デフォルトの名無しさん
07/09/25 03:13:42
>>693
ネット上の画像ファイル自体でなくマッチングに必要な特徴量だけを
抽出して蓄えとくのかな?
696:デフォルトの名無しさん
07/09/25 05:01:18
>>695
まったく同じ画像ってんなら特徴量どころか md5 ぐらいでなんとかなりそうですな
>>692
なにが難しいの？ただ単にプログラミング１年生ってこと？
697:デフォルトの名無しさん
07/09/25 11:31:54
ImageJのプラグインですが、8bit画像対応で書かれたの処理を、
16bit画像対応の処理に変換したいんですが、どのように行えばよいかわかる人いますか？
698:デフォルトの名無しさん
07/09/26 03:01:11
ImageJのことはよくわからんけど
16bit画像を読み込んで8bit画像に変換（減色）して
元からある8bit画像対応で書かれた処理に投げるのじゃ駄目なの？
16bitで全て処理したいなら処理部分で画素参照してる部分を16bit画像に挿げ替えるとか
699:デフォルトの名無しさん
07/09/26 03:42:21
ﾏｼﾞﾚｽｷﾀｺﾚ
700:デフォルトの名無しさん
07/09/26 03:59:04
ありがとうございます。
16を8へ変換すると、階調数変わって、画像そのものが変わるので、やりたくないんですよ。
「16bitで全て処理したいなら処理部分で画素参照してる部分を16bit画像に挿げ替えるとか」
をもう少し詳しく教えていただけませんかね？
701:デフォルトの名無しさん
07/09/26 04:12:56
＿＿_＿＿
（すた☆らき）
￣￣＼|￣
URLﾘﾝｸ(www.freewebs.com)
702:デフォルトの名無しさん
07/09/26 04:45:25
URLﾘﾝｸ(www.freewebs.com)
703:デフォルトの名無しさん
07/09/26 05:39:46
ありがとうございます。
16を8へ変換すると、階調数変わって、画像そのものが変わるので、やりたくないんですよ。
「16bitで全て処理したいなら処理部分で画素参照してる部分を16bit画像に挿げ替えるとか」
をもう少し詳しく教えていただけませんかね？ (スレ変わったのでもう一度書き込みました。すみません。)
704:デフォルトの名無しさん
07/09/26 07:13:38
オープンソースなんだから自分でソースをいじれってことだろ
705:デフォルトの名無しさん
07/09/26 12:28:05
そうですよね･･･。ありがとうございます。
また、困ったら質問すると思いますので、よろしくお願いします。
706:デフォルトの名無しさん
07/09/26 20:13:39
複雑なグラフ構造をかっこよく二次元or三次元に表示できる定番のアルゴリズムって何かありますか？
JavaのJDKのDemoに入っていたような、なんちゃって物理モデルを定義して各点を相互作用させていく
やり方は試したのですが、点が増えると線がこんがらがったり、ぶるぶる震えたり、
点が重なったりしてなかなかうまくいきませんでした。
うまいやりかた教えてください。
707:デフォルトの名無しさん
07/09/26 21:27:38
>>706
グラフはどれくらいのサイズ？
バネみたいなモデルでとりあえず安定しないかい？
708:デフォルトの名無しさん
07/09/27 00:19:58
>>697
import ij.process.*;
ImageProcessor ip8; // 8bits/pixelグレイスケールだとする。つまり ByteProcessor 型
ImageProcessor ip16 = new TypeConverter(ip8, True).convertToShort();
で ip16 が 16bits/pixelグレイスケールになる。つまり ShortProcessor 型
709:デフォルトの名無しさん
07/09/27 01:32:46
>>706
定番かどうかは知らんが、Graphvizとか参考にしてみれば
710:デフォルトの名無しさん
07/09/27 03:13:58
またまたImageJなんですが、プラグインした処理を自分でいろいろと書き換えたいんですが、そのファイルの中身は、classファイルとjarファイルがあります。
普通にファイル開こうとすると開けませんので、ImageJ起動させて、plugin>editeから書き換えようとしたんですが、これも開けませんでした・・・。
といことは、classファイルやjarファイルを他の何かに変換しないといけないって事ですよね？
どうやって変換すればいいんですかね？そして、どーやって書き換えればいーんですかね？
ImageJオープンソースのプラグインの処理の書き換え方を教えて欲しいんですが。初心者ですのでわからなくって。。。
711:デフォルトの名無しさん
07/09/27 03:24:56
>>710
ImageJというよりJavaについての知識が足りない
同じプラグインのソースファイル（ImageJプラグインならjavaファイル)を
ダウンロードするなり貰ってくる必要がある
712:デフォルトの名無しさん
07/09/27 03:38:59
>>710
プログラミング(もしくはjava)初心者ならまともにjavaプログラミング出来るようになってから出直せ
713:デフォルトの名無しさん
07/09/27 04:21:03
Jarの中身を閲覧してデコンパイル(classからJavaソースを生成)できないんですか？
714:デフォルトの名無しさん
07/09/27 04:31:15
残念だが710には無理だな
715:デフォルトの名無しさん
07/09/27 04:34:00
デコンパイルは難しいことなんですか？
716:デフォルトの名無しさん
07/09/27 06:21:40
糞スレageんなカス
717:デフォルトの名無しさん
07/09/27 08:12:08
ここは一問一答スレではありません
718:デフォルトの名無しさん
07/09/27 08:43:59
隣の家の芝はどうして青く見えるんですか？
719:デフォルトの名無しさん
07/09/27 09:19:07
スカリー産卵のせい
720:デフォルトの名無しさん
07/09/27 09:45:38
>>715
Java関係のところで聞いた方がいいと思います
それとメール欄に「sage」と入れてください
それとせっかくだから改造したいプラグインの名前を教えてよ
721:デフォルトの名無しさん
07/09/27 20:16:39
山は死にますか？
722:デフォルトの名無しさん
07/09/27 20:19:24
風はどうですか？
723:デフォルトの名無しさん
07/09/28 00:53:01
海の水はどうしてですか？
724:デフォルトの名無しさん
07/09/28 00:54:54
そんな歌詞はありません
725:デフォルトの名無しさん
07/09/28 03:28:46
友達がこんな無茶ブリを言ってきた。
このプログラムをｊａｖａに直して起動させろと。
そ、そんな無理な！誰か分かる方いますか？
//pget(int x, int y) : 入力画像の指定したx,y座標からピクセルの色を読み出す（0か1）
//pset(int x, int y, int c) : 出力画像の指定したx,y座標に色をセットする（cは0か1）
//width : 画像幅
//height : 画像高さ
int sx, sy; //追跡開始点
int px, py; //追跡点
int vec; //調査点フラグ
int IsFirst; //
//画像内を捜査し有効画素を探す
for(sy=0; sy < height; sy++) {
for(sx=0; sx < width; sx++) {
//有効画素があった場合ループから抜ける
if( pget(sx, sy) != 0 ) {
break;
}
}
}
726:デフォルトの名無しさん
07/09/28 03:29:49
//有効画素が見つかっていた場合、追跡処理に入る
if( sx < width ) {
px = sx;
py = sy;
pset(px, py, 1);
vec = 2; //最初の調査点を左下にセットする
IsFirst = 1;
//追跡開始点と追跡点が同じ座標なるまで輪郭追跡処理
while( px != sx || py != sy || IsFirst == 1 ) {
switch(vec) {
case 0: //左上を調査
if( pget(px-1, py-1) != 0 ) {
pset(px-1, py-1, 1);
px = px-1; py = py-1;
vec = 6;
break;
}
727:デフォルトの名無しさん
07/09/28 03:30:23
case 1: //左を調査
if( pget(px-1, py) != 0 ) {
pset(px-1, py, 1);
px = px-1;
vec = 0;
break;
}
case 2: //左下を調査
if( pget(px-1, py+1) != 0 ) {
pset(px-1, py+1, 1);
px = px-1; py = py+1;
IsFirst = 0;
vec = 0;
break;
}
case 3: //下を調査
if( pget(px, py+1) != 0 ) {
pset(px, py+1, 1);
py = py+1;
IsFirst = 0;
vec = 2;
break;
}
case 4: //右下を調査
if( pget(px+1, py+1) != 0 ) {
pset(px+1, py+1, 1);
px = px+1; py = py+1;
IsFirst = 0;
vec = 2;
break;
}
728:デフォルトの名無しさん
07/09/28 03:31:54
case 5: //右を調査
if( pget(px+1, py) != 0 ) {
pset(px+1, py, 1);
px = px+1;
IsFirst = 0;
vec = 4;
break;
}
else {
//孤立点であった場合
if( IsFirst == 1 ) {
IsFirst = 0;
break;
}
}
case 6: //右上を調査
if( pget(px+1, py-1) != 0 ) {
pset(px+1, py-1, 1);
px = px+1; py = py-1;
vec = 4;
break;
729:デフォルトの名無しさん
07/09/28 03:33:34
}
case 7: //上を調査
if( pget(px, py-1) != 0 ) {
pset(px, py-1, 1);
px = px; py = py-1;
vec = 6;
break;
}
vec = 0;
}
}
}
730:デフォルトの名無しさん
07/09/28 03:34:22
休憩
731:デフォルトの名無しさん
07/09/28 05:37:13
なにがしたいの？
732:デフォルトの名無しさん
07/09/28 06:35:44
どうせならちゃんと貼ってくれ。matlabに直してやるから
733:デフォルトの名無しさん
07/09/28 07:23:32
友達に断るのが吉。
宿題なら宿題スレ行け。
734:デフォルトの名無しさん
07/09/28 08:05:30
そのままじゃ動かないんだっけ？
735:デフォルトの名無しさん
07/09/28 15:26:05
何が無茶なんかよくわからん
736:デフォルトの名無しさん
07/09/28 21:11:29
>>725
友達にそんなことを頼まれることになった経緯を詳しく聞かせてくれ。
そっちの方が興味深い。
737:デフォルトの名無しさん
07/10/03 10:48:31
相変わらずレベル低いなｗ
738:デフォルトの名無しさん
07/10/03 11:09:06
相変わらず暇そうですな
739:デフォルトの名無しさん
07/10/03 17:50:00
neet
740:デフォルトの名無しさん
07/10/06 00:18:23
www.openjpeg.orgが見れないんだがなんか知らない？
741:740
07/10/06 00:45:46
自己解決。とりあえずここでライブラリ落とせた
www.tele.ucl.ac.be/PROJECTS/OPENJPEG/
742:デフォルトの名無しさん
07/10/06 20:35:38
そこに置いてあるやつ使っちゃいけないよ
743:598
07/10/09 13:53:43
画像認識はあまり関係ないけれども、質問してもよろしいでしょうか?
あれから勉強して、卒論としてなかなか面白いソフトウェアを作り上げたんです。
もともとアイデアがあって「実現したいなぁ」と思ったので、
あんな素人同然の質問をしたんですけれども。(画像処理は本当に初めてでした!)
ちなみに自分は経済学部生なんですが、
指導教官(理系の大学院大学を主席で出た)の方針で、
卒論の内容は自分で好きなことを決めて良いことになっています。
それで、出来た物を指導教官に見せたんですが、
「こういうテーマの研究は学会でもみたことないし、ユニークだ」と褒めてもらいました。
で、自分としてはそのアイデアとソフトウェアとソースコードを公開して、
精度を高めるために、いろんな識者の意見を聞きたいなと思うんです。
(経済学部なので、周りは誰も画像処理について知らないので。)
でも、指導教官は「そういうのはちゃんと論文を書いて、学会で発表してからにしないと
アイデアをパクられるぞ」と言うんです。
で、質問なんですけれども、こういう場合、指導教官に従うべきなんでしょうか?
学会ってパクりパクられの殺伐としたところなのでしょうか?
744:デフォルトの名無しさん
07/10/09 13:59:23
>>743
学会が殺伐しているのではなく、世間が殺伐しているから、従うべき。
学会で発表してから、公開した方がいいよ。
745:デフォルトの名無しさん
07/10/09 14:50:51
ボタンを押すことによりキャプチャした画像を
連続でファイルとして保存したいのですが同じ画像が保存されてしまいます。
capDlgVideoFormat( hWndCap );
capDlgVideoSource( hWndCap );
capDlgVideoCompression( hWndCap);
上記のどれかを書けば連続した画像を保存できるのですが毎回ダイアログが
出てきてしまいます。ダイアログを出さずに保存できるような方法が
ありましたらご教授頂きたいです。よろしくお願いします。
環境はvisual c++ 2003.netでVideo for Windowsを使用しています。
746:デフォルトの名無しさん
07/10/09 15:03:36
この新パフォーマンスを見よ
URLﾘﾝｸ(videointroplayer.web.fc2.com)
747:デフォルトの名無しさん
07/10/09 15:19:42
PGM形式のヘッダーなんだけどさ、
P5
# this line is a comment
640 480
255
以下バイナリ
とかってなるじゃん。
輝度最大値のあとにコメント行が来ていいもんなの？
Linuxでman pgmすると、
輝度最大値の情報の前の#で始まる行はコメント扱いだとあるんだけど、
たまに輝度最大値とバイナリの間にコメントが含まれるPGMに出くわす。
ソフトによってはそういう変な画像もちゃんと表示してくれんだけど、
IEが変なHTMLも表示してくれちゃうみたいで好きじゃない。
公式の定義としては、コメントの扱いはどうなってるんでしょう。
748:デフォルトの名無しさん
07/10/09 15:39:31
作った奴も適当だろ
749:デフォルトの名無しさん
07/10/09 15:50:33
URLﾘﾝｸ(www.oricon.co.jp)
750:デフォルトの名無しさん
07/10/09 15:54:37
>>747
仕様から外れたファイルに対応するなんて日常茶目仕事
751:デフォルトの名無しさん
07/10/09 16:13:32
まさか、茶飯事を「ちゃめしごと」って読んでたりする人?
752:デフォルトの名無しさん
07/10/09 16:35:40
茶飯: ちゃめし
永谷園のお茶漬けのごとく簡単にできる飯のこと
これより、茶飯事（ちゃめしごと）は非常に簡単に出来ることを云う。
また、茶飯事をさはんじとと読むと別のいみとなる。この場合は
酒・煙草・2ch・小便のように毎日行っている事を云う。
753:デフォルトの名無しさん
07/10/09 16:39:26
後付けで意味をこじつけても虚しいだけだね。
754:デフォルトの名無しさん
07/10/09 16:52:28
そんなレスは空しいな
755:747
07/10/09 16:54:30
>>750
いや、俺日常はプログラマじゃないし。
756:750
07/10/09 17:00:32
穴があったらはまりたい
757:デフォルトの名無しさん
07/10/09 17:04:49
日本にプログラマは非常に少ない
ITドカタなら羊の群れのごとくいる。
758:デフォルトの名無しさん
07/10/09 17:06:27
>>747
ネットでいろんな manpage みたけど、そんな制限書いてるのは見つけられなかったな。
漏れが見た全てのドキュメントがラスター値より前にならどこにでもコメントを入れて良い
こととしている。
単に
Strings starting with "#" may be comments, the same as with PBM.
とか
Characters from a "#" to the next end-of-line, before the maxval line, are comments and are ignored.
とか
759:デフォルトの名無しさん
07/10/09 17:18:28
>>758
もしかして、英語読めないの? 後者はmaxvalの後のコメントを認めていないのだけれど。
760:デフォルトの名無しさん
07/10/09 17:25:03
スマン・・・寝ぼけていた。
netpbm 系のドキュメントはラスター値より前ならどこでもok、
後者の - えーとどっから持ってきたのか忘れたが - は maxvalue より前派、
となってるわけやね。
761:747
07/10/09 17:33:14
>>758
そうなの。2種類の書き方があるんだわ。
前者はsourceforgeにもあるやつで、後者はLinuxのmanで出てくる。
>the same as with PBM.
とあるんだけど、PBMにはmaxvalが存在しないんで、
"same as"と書いてしまうのは乱暴なんだよね。
maxvalより後ろのコメント行がある場合には対応したくないんだけど、
（間違ってるのは変なPGMを吐く他のソフトだから）
もし公式にそういうコメントの付け方が認められているならば、
ちゃんと自分のコードでも対応しないといけないなー、と思ってね。
762:デフォルトの名無しさん
07/10/09 19:02:24
c++でRGBに変換した画像は、
color_dest=Color::FromArgb(r,0,0);
pen=gcnew Pen(color_dest);
gr->DrawRectangle(pen,X0,Y0,1,1);
のように表示しているんだけど、
YUVの場合はどうしたらいいのでしょうか？
変換式はわかっています。
763:デフォルトの名無しさん
07/10/09 19:02:57
sage。
764:デフォルトの名無しさん
07/10/09 19:17:15
>>759
後者は、maxval lineより前にある#は、行末までコメントだから無視すると書いてあるだけで、
maxval lineより後ろにあってはならないとは書かれていないんじゃ・・・
もちろん普通は、そうとらえないと思うけど。
いずれにしろ、そういうデータが存在する以上、前者の仕様は後者の仕様も含むから、書き込みは
ともかく読み出しは前者の仕様で作ればいいだけの話なんじゃない？
765:デフォルトの名無しさん
07/10/09 19:39:43
>>762
何がしたいのかよく分からん
YUV画像を表示するなら、RGB画像に変換するだけだし
(RGB画像のR値だけ表示する様に)YUV画像のY値だけ表示したいなら、Grayscaleで表示すればいいだけだし
あと、それC++じゃないから
766:デフォルトの名無しさん
07/10/09 20:12:45
>>765
すいません、VCで作っています。
グレースケールということは、変換してでた値をRGB全部に入れればいいのですね。
残りのUVについては値域がｰ128～128になるので0～255に直すために、128を足せばいいのですか？
767:デフォルトの名無しさん
07/10/09 20:16:05
やりたいことは、原画像を与えて、
原 R
G B
Y U
V
のように成分抽出して表示させることです。
768:デフォルトの名無しさん
07/10/09 20:32:31
>>767
Y成分だけ表示
U成分だけ表示
V成分だけ表示
ってやりたいのかな？
表示したい成分以外を固定すればいいんじゃね？
あと、YUVとは何か分かってないみたいだから少し勉強してくれ。
769:デフォルトの名無しさん
07/10/09 20:58:00
とりあえず(en.wikipedia.orgによると)デファクトっぽいnetpbmのドキュメントよりpbmのコメント
(pgmは適宜読み替えて)
・ラスタの区切りの空白文字より前の、"#～<CR>"、"#～<LF>"はコメント
・型破りだが、コメントはトークンの途中に挿入されるかもしれない
・ラスタの直前にコメントを置いた場合はコメント末尾の<LF>は区切りにはならない
(補足)
ラスタの区切りの空白文字は1文字のみ(通常は<LF>)。
つまりpgmだと"Maxval<LF>"の後にはコメントは書けないが、
"Maxval# comment<LF><LF>"と書くのはOK
770:デフォルトの名無しさん
07/10/09 21:01:37
>>768
やりたいことはそのとおりです。
表示したい成分以外を固定とは、どういうことでしょうか？
771:769
07/10/09 21:02:11
例としてはこんなところだろうか
[OK 1]
P2<LF>
# comment<LF>
64 64<LF>
255<LF>
<raster>
[OK 2]
P2<LF>
64 6# comment<LF>
4<LF>
255<LF>
<raster>
[OK 3]
P2<LF>
64 64<LF>
255# comment<LF>
<LF>
<raster>
[NG 1]
P2<LF>
64 64<LF>
255# comment<LF>
<raster>
772:768
07/10/09 21:10:22
>>770
R成分だけ表示
G成分だけ表示
B成分だけ表示
するときはどうしてる？
773:デフォルトの名無しさん
07/10/09 21:22:39
color_dest=Color::FromArgb(r,0,0);
pen=gcnew Pen(color_dest);
gr->DrawRectangle(pen,X0,Y0,1,1);
のようにFromArgbで値を与えて、
それをpenに入れて、
DrawRectangleで始点とペンの大きさを与えて、
描画しています。
774:768
07/10/09 21:56:31
基本的な流れは
1.YUVの値をいじる
↓
2.RGBに変換
↓
3.表示
2と3は分かるよな？
775:デフォルトの名無しさん
07/10/09 22:02:36
いやスレ違いもいいところだが、普通はBitmap::SetPixel()使う。最低でも。
つーかBitmap::LockBits()使えといいたいところだが。
776:762
07/10/09 22:07:02
>>774
YUVに変換すると、値がマイナスになってしまう部分があります。
FromArgbでは値をint型で入れなくてはならないのに不都合が生じてしまいます。
というところで詰まっています。
777:762
07/10/09 22:13:05
>>775
今外出中なのでできませんが、戻り次第調べてみます。
778:768
07/10/09 22:24:52
>>776
そのYUVをRGBに変換すればプラスの値になるだろ？
もしかしてFromArgbの引数にYUVの値を入れようとしてるのか？
779:762
07/10/09 22:36:09
あるのは原画像、
現在原画像からRGB成分を取り出して、
赤緑青で表示させるのは先程のコードでできています。
RGBの値をYUVに変換することも出来ます。
その値の処理の仕方がわかりません。
>>778
引数はrgbの値しか入らないことはわかっています
780:768
07/10/09 22:58:14
YUVのYだけ、Uだけ、Vだけの画像を作る
↓
YUVをRGBに変換してFromArgbに入れる
↓
後は同じ
一体何が分からんのだ
781:デフォルトの名無しさん
07/10/10 01:22:26
比率
782:762
07/10/10 05:47:48
解決いたしました。
>>768さんを始め、
悩ませてしまい申し訳ありませんでした。
783:デフォルトの名無しさん
07/10/11 14:25:54
GIL gil
どっちが正しいの？
784:デフォルトの名無しさん
07/10/11 17:09:03
淫乱テディベア画像をどう処理すればデスクトップの壁紙にできるかについて
785:762
07/10/11 20:52:31
>>784
URLﾘﾝｸ(www.gay.jp)
右クリ→背景に設定
786:デフォルトの名無しさん
07/10/13 01:12:45
画像処理か分からないんですが、
最近HPなどに貼られている画像は
分割されているものが多いと思うのですが
簡単に1枚画に結合できるソフトとかありませんか？
787:デフォルトの名無しさん
07/10/13 01:17:12
XCOPYコマンドで連結
788:デフォルトの名無しさん
07/10/13 01:23:22
スクリーンキャプチャ
789:デフォルトの名無しさん
07/10/13 02:30:15
物体の横幅を計測できるアプリケーションを以下の処理で作ろうと思っています。
①透過照明を用いて、背景を白、物体を黒の２値化画像を撮影。
②その画像にラプラシアンフィルタをかける。
③横に隣接した２ピクセルの符号が反転していれば、その隣接した２ピクセルの間にエッジがあるとする。
④隣接した２ピクセルの線形近似によりゼロクロス点を求め（0.1ピクセル単位で）、その点をエッジとする。
⑤1行ごとに２点のエッジ位置があるので、差を求め、その差に校正値をかけて実寸値を算出。
幅を求めたいだけなのでラプラシアンフィルタは｛ 1, -2, 1 ｝を用いています。
以上の手順で改善すべき点はあるでしょうか？
またサブピクセル処理でゼロクロス法を使っていますが、
他にもっと精度の高い（誤差の少ない）サブピクセル処理があれば教えていただきたいです。
790:デフォルトの名無しさん
07/10/13 04:06:38
LOG
二次補間
791:デフォルトの名無しさん
07/10/13 05:22:04
>>786
１枚の絵にされ、転用されるのを嫌がっている場合もあるんじゃなかろうか。
792:デフォルトの名無しさん
07/10/13 06:30:15
>>791
そこはあえて無視だろ
793:デフォルトの名無しさん
07/10/13 08:03:58
>>786
つ[PrintScreen]
794:786
07/10/13 09:49:21
>>787-788,>>791-793
お返事ありがとうございます！
自分は今、分割されている画像を全部落としてペイントで地道につなげています^^
PrintScreenは確かに簡単ですけど、できたやつはオリジナルとは別物って認識なので…
XCOPYよかったら詳しく教えて下さい～もう寝る時間なのでまた後ほど ﾉｼ
795:デフォルトの名無しさん
07/10/13 10:08:29
>>794
ここはソフ板じゃなくてム板。自分で作るところ。
プログラム書く上でわからないことなら質問して良いと思うけど。
796:786
07/10/13 12:43:40
>>795
ありがとうございます＾－＾
でも氏ね
797:デフォルトの名無しさん
07/10/13 12:46:23
>>796
798:デフォルトの名無しさん
07/10/13 13:51:55
>>796
つURLﾘﾝｸ(www.eml.hiroshima-u.ac.jp)
799:786
07/10/13 13:54:59
>>796
ちょｗｗｗだれだよお前ｗｗｗｗ
>>795
ちょっと自分で調べてみま～す！
800:デフォルトの名無しさん
07/10/13 16:11:19
>>798
馬鹿か。そのレベルじゃねーよ。
ただ画像をつなげるにはどうしたら？ってきいているに過ぎない。
801:デフォルトの名無しさん
07/10/13 16:43:58
>>794
＞PrintScreenは確かに簡単ですけど、できたやつはオリジナルとは別物って認識なので…
ペイントで地道に繋げてもオリジナルとは別物だと思うぞ。
802:デフォルトの名無しさん
07/10/13 17:03:25
デジタルデータにオリジナルも何もあるか
803:デフォルトの名無しさん
07/10/13 17:04:27
そこでステガノグラフィー
804:786
07/10/13 18:40:09
今確認したら
元データ(6分割)：103,783 bit
ペイントで結合：40,911 bit
PrintScreen：40,876 bit
前々から画質落ちてるとは思ってたけど、
半分以下かよ･･･拡大して比較してみたら悲惨だったorz
暇だったのでフリーの結合ソフト探したら普通にあったｗ
それで結合しても58,680 bitでこちらも画質落ちてた…でも結合は一瞬だった＼(^o^)／
と思ったら、画質指定できるみたいだったのでMAXにしたら結合後は256,107 bit
拡大して元画像と比較しても損傷なかったです～
お騒がせしました、また何かあったらよろしくお願いします～～～
805:デフォルトの名無しさん
07/10/13 18:41:40
プログラマじゃないならもう来ないでくれ
806:デフォルトの名無しさん
07/10/13 19:30:14
>>805
SE、コーダ、プロジェクトリーダもお帰り下さい、って言いたげだなあ
807:デフォルトの名無しさん
07/10/13 19:52:21
それにしても、ビット数で画質を比較ってどういうことだろう。
PrintScreenで画質が落ちるって言うのも意味不明だし。
まさか今時、32bitじゃない表示環境で使っているとも思えないし。
そもそも、ビット数って何を比較しているのだろう。
まさか、できあがったjpegファイルのサイズのことなのだろうか。
だとしたら、保存に使ったツールで調整可能だろうし、
そもそもjpegにしなければいいわけで。
人の話を聞かん香具師の考えていることはどうにも判らんな。
808:デフォルトの名無しさん
07/10/13 21:03:03
まさか本当にペイントで結合しているとは
809:デフォルトの名無しさん
07/10/14 02:26:18
たぶんファイルサイズを byte でなく bit と勘違いしてるな
810:デフォルトの名無しさん
07/10/14 02:55:33
それでも理解不能だ。
811:デフォルトの名無しさん
07/10/14 21:52:37
淫乱ティディベアを学会で発表するノートＰＣの壁紙に使いたい
812:デフォルトの名無しさん
07/10/14 23:29:21
>>811
つURLﾘﾝｸ(www.gay.jp)
813:デフォルトの名無しさん
07/10/15 12:21:02
任意の四角形（凹みや捩れも有り）から、(0,0)-(1,1)を対角線とする
長方形への変形転送を考えてるんだけど、ちと相談に乗ってほしいす。
転送元の任意の四角形をsrc , 転送先の長方形をdstとする。
srcとdstのどの角を対応付けるかはあらかじめ決めておく。
転送方法は、dstをyとxでループして、転送先の座標とdstの辺との
位置の比率からsrc内の対応する点を拾ってくれば問題なく出来る。
ここで、src内の１点だけ転送したい場合、転送先のdstを全領域
サーチするのは勿体無いので、それがdstのどこに対応するのか、
計算で求められるか？という問題です。
転送元が任意の四角形だから、アフィン変換では対応できず。
捩れてる場合の交点など、数学的には解が見つからないのは仕方ない
けど、そのときは、プログラムとしては例外的に処理しないなど対応
すれば済むので、それ以外の場合でおおむね動作すればOKなんですが。
src内の１点→dstの対応点、計算で可能でしょうか？
よろしくお願いします。
814:デフォルトの名無しさん
07/10/15 14:14:14
srcの外接長方形を求めて、４頂点に対応するdstの４点を求める。
あとは、dstにやっていたのと同じ計算を逆方向にする。
815:813
07/10/15 14:34:41
>>814
＞srcの外接長方形を求めて、４頂点に対応するdstの４点を求める。
質問は、要するにこれ「４頂点に対応するdstの４点を求める」のやり方です。
（src内ではありませんが、同じことだと思う）
816:デフォルトの名無しさん
07/10/15 14:36:35
そりゃおまいが書いてる
＞転送方法は、dstをyとxでループして、転送先の座標とdstの辺との
＞位置の比率からsrc内の対応する点を拾ってくれば問題なく出来る。
の計算方法次第じゃね？逆関数書けるだろう？
817:813
07/10/15 15:58:06
>>816
for(yが0～1){
for(xが0～1){
dstとsrcの各辺の比率からsrc->dstを決定
}
}
と、おそらく一番単純な考え方だと思うんだけど、
srcの任意の点からだと、逆変換がスマートな式では
思いつかないんですよ。（dstからsrcは簡単なので、
拾ってこれる）
dstは長方形だから、dst内の任意の点は各辺からの距離に
簡単に置き換えられるんです。辺からの距離が分れば、src
の４辺を比率で割って交点からsrcの対応点を求められる。
だけど、src内の任意の点だと、srcの四隅からの距離の
比率を出せないんです。
何か見落としてますかね？
818:デフォルトの名無しさん
07/10/15 16:17:03
＞dstは長方形だから、dst内の任意の点は各辺からの距離に
＞簡単に置き換えられるんです。辺からの距離が分れば、src
＞の４辺を比率で割って交点からsrcの対応点を求められる。
よくわかんないけど、正写像は
dst 内の点を P(xp,yp) 、src の上下2辺を A,B として、対応する src 内の点 Q(xq,yq) は
Q = xp ( yp A + (1-yp)B) ってことだよね。x,y の各項について書けばAを(Ax,Ay), Bを(Bx,By)
として、
xq = xp ( yp Ax + (1-yp)Bx)
yq = xp ( yp Ay + (1-yp)By)
これを P について解くだけだよね。
何か勘違いしてんのか、おれ。
819:813
07/10/15 16:28:45
>>818
それってsrcが任煮の四角形で対応できる？ 検証したわけじゃないけど
srcが平行四辺形までだと思うんだが…。
820:813
07/10/15 16:29:29
任煮＞任意、でした
821:デフォルトの名無しさん
07/10/15 16:30:44
いやだから正射影はこの式であってんのかとか、
基本的な事実出してもらわないと。
この式であってるんなら解けるケースは簡単に解けるんじゃない？
822:821
07/10/15 16:32:48
訂正
誤：正射影⇒正：正変換
823:デフォルトの名無しさん
07/10/15 16:52:28
>>821
上で書いたけどアフィン変換できないと思います。
>>818だと、dstのAB以外の辺がsrcにどう対応するか
考慮されて無いようなので。
824:823==813
07/10/15 17:03:52
うーん、どう説明したもんか、ずらずらソース書くのもなんですし
dstの各頂点がABCD、srcの各頂点がRSTUだとすると、(ABCDの順に時計回りに角が定義されている)
→forループ方向
<=色の転送
A→B <= R→S
を内側のループに書いて、
A→D、B→C と R→U、S→T
を外側のループで回してdstを埋める感じですね。
825:821
07/10/15 17:06:09
あスマンスマン
時計回りに4頂点を A,B,C,D として
Q = xp ( yp A + (1-yp)B) + (1-xp) (yp D + (1-yp)C)
か。
これもやっぱり解けるんじゃない？
826:813
07/10/15 17:37:34
解けそうな気がしてきた。ありがとう
827:デフォルトの名無しさん
07/10/16 05:32:29
フーリエ変換で作られる虚部と実部の画像って白と黒の縞模様みたいのが
ぐにゃ～って現れますよね。それを振幅画像にすると縞模様がなくなると
思うんですけどこの現象って何故起こるんでしょうか？
828:デフォルトの名無しさん
07/10/16 11:21:36
>>827
質問を整理してくれ。
縞模様が現れる理由を聞きたいのか、その縞模様が「ぐにゃぁ～って現れる」理由を聞きたいのか、
それとも逆変換できる理由を聞きたいのか、それ以外なのかよく判らん。
# 「ぐにゃぁ～って現れる」もよく判らんが。
そもそも、変換後の周波数空間の擬似画像の意味はわかっているのか?
829:デフォルトの名無しさん
07/10/16 12:21:34
>>813
BC S T
p ← P dst 上での点 p の座標を p = (s, t) とします。
AD R U
変換元 P は
P = R * (1-s) * (1-t) + S * (1-s) * t + T * s * t + U * s * (1-t) ………………………… (1)
となります。(当然, P が □RSTU 内部の点の場合 0 ≦ s ≦ 1, 0 ≦ t ≦ 1)
多項式を展開して x, y 成分に分けると
Px = Rx + (Ux-Rx) * s + (Sx-Rx) * t + (Rx-Sx+Tx-Ux) * s * t ………………………… (2)
Py = Ry + (Uy-Ry) * s + (Sy-Ry) * t + (Ry-Sy+Ty-Uy) * s * t …………………………… (3)
で、ここで Q = (Rx-Sx+Tx-Ux)/(Ry-Sy+Ty-Uy) と置けば
Px - Q*Py = (Rx - Q*Ry) + ((Ux-Rx) - Q*(Uy-Ry)) * s + ((Sx-Rx)-Q*(Uy-Ry)) * t …… (4)
Py - Px/Q = (Ry - Rx/Q) + ((Uy-Ry) - (Ux-Rx)/Q) * s + ((Sy-Ry)-(Sx-Rx)/Q) * t …… (5)
となり、s, t の連立1次方程式に持ち込めます。
交点上ではQの分子・分母いずれかが 0 になるので、Q の計算か (5) でゼロ割りが
出ます。□RSTUが傾いていない矩形の場合、Q の分子分母ともゼロになるので、
その場合は (2) (3) 式の s * t の項が消えた連立１次方程式を直接解くことができます。
830:デフォルトの名無しさん
07/10/16 17:01:36
>>829
(4),(5)の連立方程式はまずい
とりあえず、0除算は考えないことにすると
(4) = -Q (5)
になって、(4),(5)が線形独立でない
(注: >>829は(4)でtの係数が間違っている)
下記の連立方程式(1),(2)を解く場合
a1 s t + b1 s + c1 t + d1 = 0 ― (1)
a2 s t + b2 s + c2 t + d2 = 0 ― (2)
まず、tで括る
(a1 s + c1) t + (b1 s + d1) = 0 ― (3)
(a2 s + c2) t + (b2 s + d2) = 0 ― (4)
(4) * (a1 s + c1) - (3) * (a2 s + c2)としてtを除去すると
(a1 s + c1) (b2 s + d2) + (a2 s + c2) (b1 s + d1) = 0
これを整理すると、
(a1 b2 + a2 b1) s^2 + (a1 d2 + a2 d1 + b1 c2 + b2 c1) s + (c1 d2 + c2 d1) = 0 ― (5)
(5)を解けば、sが1つないし2つ求まる
これを(3)または(4)に代入してtを求める
831:デフォルトの名無しさん
07/10/16 17:17:09
>>830
何も考えずに書くが、線分がsweepしたような図形への変換と逆変換だよね？
殆ど全ての点で解は1つなわけで、
最後が2次方程式ってのが直観と合わないんだけど。
832:デフォルトの名無しさん
07/10/16 18:21:25
>>827
振幅（複素数の絶対値）はパワースペクトルの平方根なわけで、
たいていの画像では高周波になるにつれて緩やかに減少するね。
もちろんパワースペクトルだけでは情報が失われまくりで画像は再構成できない。
その分の情報量が位相差になるわけだから、虚部と実部は必然的に激しい画像になる。
833:デフォルトの名無しさん
07/10/16 21:41:01
ちょwww激しい画像ﾜﾛﾀ
834:デフォルトの名無しさん
07/10/16 22:21:06
>>833
>激しい画像
そこだけ抜き出すな！ｗ
ﾌｲﾀ
835:デフォルトの名無しさん
07/10/17 01:01:10
>>827
実部画像や虚部画像が白黒の縞なのは周波数ごとに位相が異なることを反映している
振幅画像には位相情報が含まれていない
836:デフォルトの名無しさん
07/10/17 03:19:29
>>828
すみません、自分でも理論を完璧に理解していなかったので質問が
滅茶苦茶になってしまいました。
>>832 >>835
大変わかりやすい回答ありがとうございました。
837:デフォルトの名無しさん
07/10/17 20:00:19
超解像アルゴリズムのいくつかのサンプルプログラムを探してるんですが
どっかないですか？
出来ればＣ言語かＣ＋＋でＭＡＴＬＡＢを使ってない奴で
838:デフォルトの名無しさん
07/10/17 20:28:54
>>837
自分で考えた方が早くね？
839:デフォルトの名無しさん
07/10/18 00:51:24
C++で書いてるやつ
STLとかBoost使ってる？
840:デフォルトの名無しさん
07/10/18 02:12:18
>>837
URLﾘﾝｸ(www.cs.technion.ac.il)
は C++ だね
動かすためのソース全てが載ってるかどうかまでは確認してないけど…
841:デフォルトの名無しさん
07/10/18 02:21:58
動画の連続フレームの超解像をする時に
被写体が移動してるわけだけど
平行移動だけじゃなく回転拡大も加わるのを
どうやって光速に位置合わせするのかわからないから
サンプル探してる
842:デフォルトの名無しさん
07/10/18 03:25:25
光速かよ
843:デフォルトの名無しさん
07/10/18 04:09:14
光速エスパーって三ツ木清隆だったんだな…
844:デフォルトの名無しさん
07/10/19 03:42:54
>841
Lucas-Kanadeのオプティカルフローで計算できる。
フレーム間が微小変形ならすぐ収束する。
URLﾘﾝｸ(www.ri.cmu.edu)
再構成タイプの超解像は面白いが対象が平面静止が条件で
カメラをふらふらさせて撮影というアホみたいなことしないと
いけないから、だったらカメラの光学系をましにしたほうが
いい気がする。
845:デフォルトの名無しさん
07/10/22 18:19:14
>>844
Lucas-Kanadeで精度を上げるには、どのあたりのパラメータをいじれば
良いのでしょうか？
人工的にずらした画像でテストしても、精度が悪く超解像画像がぼけて
しまいます。元画像で0.1ピクセル以上の精度が欲しいのですがいろい
ろいじっても、0.25ピクセルくらいの精度しか出ません。
846:844
07/10/22 22:48:18
私が以前試したのは低解像度画像×20枚から4倍解像度の
人工画像のテストで見えない文字が見える程度になりました。
人工画像なら、ずれ量が既知だと思うけど、そのずれ量を使って
超解像処理は試してみましたか？それで駄目ならレジストレーションの
問題ではなく画像復元アルゴリズムの誤りだと思う。
Lucas-Kanadeのレジストレーションの位置精度は私が知りたいです。
（上のリンクでは濃淡値のRMSで精度を測ってますよね）
精度を上げるとすると変形後の画素補間とかでしょうか。
847:845
07/10/23 01:25:30
>>846
既知のずれ量を使うと納得のいく超解像処理ができました。
画像復元アルゴリズムには誤りはないようです。
現在は、KLT処理の検出結果付近±１ピクセルの範囲をサブピ
クセル単位で照合していますが、処理が重いのでKLTだけでう
まくできないかと質問しました。
>>841ではなく便乗質問です。
848:デフォルトの名無しさん
07/10/24 22:34:52
mean-shiftがどうしても理解できません。
何か良い本ありませんか？
849:デフォルトの名無しさん
07/10/25 22:31:45
天文画像を良くするRegistaxというフリーソフトですが、画質が良くなる理由は、重ねがき（コンポジット）による効果ですか、それともウェーブレットによる効果ですか？
850:デフォルトの名無しさん
07/10/26 19:00:45
教えて下さい。
携帯の写メに映った小さい数字を読み取る方法はないでしょうか？
ＰＣに取り込んでの拡大では読み取れませんでした。
スレチかもしれませんがどうか教えて下さい。
851:デフォルトの名無しさん
07/10/26 19:07:57
スレ違いすぎるよ
852:デフォルトの名無しさん
07/10/26 20:35:59
>>850
超解像処理か。とりあえずその画像をうｐしてみろ。
853:デフォルトの名無しさん
07/10/26 21:15:14
>>851
そうですよね。申し訳ないです。
>>852
超解像処理ですか。
うｐは恥ずかしい写真なので出来ないっす。
自分はまったくの素人なんですが、どこか
処理を頼めるようなところはありますでしょうか？
854:デフォルトの名無しさん
07/10/26 21:27:51
文字がまったくつぶれている（ベタ塗り）のは情報がないから無理だぞ
855:デフォルトの名無しさん
07/10/26 21:28:59
糞釣り死ねよ
856:デフォルトの名無しさん
07/10/26 22:35:23
>>853
自分でプログラム書く気ないならソフ板にでも行けば良いかと
857:デフォルトの名無しさん
07/10/27 08:57:40
>>850
何が写ってるのか知らんけど、その場所に今から行ってみれば？
858:デフォルトの名無しさん
07/10/27 09:01:43
それともひき逃げした車の後姿でも撮ったのか？
859:デフォルトの名無しさん
07/10/27 14:04:45
電光掲示板かも
860:デフォルトの名無しさん
07/10/27 16:41:59
URLﾘﾝｸ(monoist.atmarkit.co.jp)
861:デフォルトの名無しさん
07/10/27 19:19:20
C++で画像処理を扱っている分かりやすいサイトはありませんか？
まずは画像のRGBを配列に取り出して、
いろいろなグレースケール変換をして、
結果を画面に表示したいと思っています。
862:デフォルトの名無しさん
07/10/27 19:28:25
C++と画像処理は切り離して考えるべきではないか
863:デフォルトの名無しさん
07/10/27 19:28:53
>>861
URLﾘﾝｸ(homepage3.nifty.com)
864:８６１
07/10/27 19:37:23
８６２さん、「C++と画像処理は切り離して考えるべきではないか」とはどういうことでしょうか？
８６３さん、ありがとうございます。
ピッタリですね。さっそく読みたいと思います。
865:デフォルトの名無しさん
07/10/27 19:40:40
C++はC++で勉強する
画像処理は画像処理で勉強する
近道しようとすると後々困るということじゃない？そのうち俺みたいになるよ。
866:８６１
07/10/27 19:47:02
８６５さん、
なるほどー、必要な箇所だけ分かればいいと思っていました。
ただ、それだと画像処理の枠から広がらないのでしょうね。
そして、基礎が不安定だとプログラミング自体も遅くなりそうですね。
867:デフォルトの名無しさん
07/10/29 01:33:12
EXCELを使って画像処理について解説した（画像をCSV形式に変換したのを
EXCELに取り込みaverage関数やmedian関数を使ったノイズ除去や数式を
書いてエッジ抽出を行うなど）画像処理の入門書またはWebを探しています。
以前、見かけたような気がするのですが、検索しても以下のものぐらい
しか見つけ切れません。
知っている方がいましたら教えてください。
書籍
・Excelによる画像再構成入門、医療科学社
URLﾘﾝｸ(www.iryokagaku.co.jp)
入門書ではない。。。
Web
URLﾘﾝｸ(www.fit.ac.jp)
量がちょっと少ない。
画像処理(2次元）ではなく信号処理（1次元）に関してはEXCELを
使った入門書はけっこうあるんですけどね。
868:デフォルトの名無しさん
07/10/29 02:05:42
URLﾘﾝｸ(web.dip.jp)
869:デフォルトの名無しさん
07/10/29 02:33:41
>>867
普通の入門書買ってExcelに書き直した方が良いんじゃないか？
画像処理をExcelでやること自体に違和感を覚えるが
870:デフォルトの名無しさん
07/10/29 02:38:32
Excelと画像処理は切り離して考えるべきではないか
871:デフォルトの名無しさん
07/10/29 03:09:53
俺も初心者の頃似たようなこと考えたことあったけど、
Excelだと横がZZだったかIVだったかまでしかとれなくて断念した記憶があるな
872:867
07/10/29 03:12:03
>>869
>画像処理をExcelでやること自体に違和感を覚えるが
実は某所で画像処理の基礎を教えることになったのだが
・Windows環境での実習を入れてくれ （重要だね）
・VCとか開発環境はない （なに～。まぁフリーのソフトでもいれて。。。）
・PCは管理されているのでソフトの追加はできない （えぇ～）
とのことなのです。(--;;
苦肉の策として小さな画像をCSVに変換してEXCELに読み込ませて
平滑化、エッジ処理、アフィン変換などなどをEXCELの関数を使って
書こうかなと思っているのです。
ガチガチのシステムだとマクロも禁止されてそうだし。表示は
グラフの「等高線グラフ」にすれば雰囲気は分かるかな。
873:デフォルトの名無しさん
07/10/29 03:27:09
>>872
画像処理の知識は既にあるってこと？
だったらあとはExcelの勉強だけすればいいじゃん。
874:デフォルトの名無しさん
07/10/29 04:28:06
>>872
Javaは標準ではランタイムしか入ってないんだっけか。Javaがあればアプレットで色々できそうなんだが。
入門レベルだったら自前で資料作るだけでいいんじゃない？
875:デフォルトの名無しさん
07/10/29 04:40:55
>>871
Excelの列数の最大値は256
>>872
代替案としてjsでプログラミングというのはどう?
画像表示はどこかのWebサーバにデータ送信、画像出力で
インターネットに繋がってない場合は、divかtableで1pxのセル並べて背景色変更でw
876:デフォルトの名無しさん
07/10/29 05:07:47
>>867
画像処理とは違うけどセルの背景色を使ってゲーム作ってるサイト
URLﾘﾝｸ(www1.plala.or.jp)
何かの参考にはなるかも。
でも幅の制限があることを除けばExcelは悪くないかもねぇ。
srcとdstそれぞれの濃度値表示・背景色表示を1シートずつ割り当てれば直感的かも…
877:デフォルトの名無しさん
07/10/30 00:02:55
>>872
WSH
878:デフォルトの名無しさん
07/11/01 16:17:50
Retina(l) samplingについての実装例(プログラム)がなかなか見つかりません。
ご存知の方教えてください
879:デフォルトの名無しさん
07/11/02 18:24:43
ゲームなどにおける爆発の効果などを勉強したいのですが、お薦めの本などがありましたら教えてください。
880:bicubic
07/11/04 14:26:45
Cやmatlabで拡大時の補間ってどう打つの？
bicubicとかlanczosとか。
あ～オレってアフォだぁ～
881:デフォルトの名無しさん
07/11/04 18:52:38
>>878-880
死ね役立たず。
人の足引っ張って楽しいかゴミクズ。
今すぐ死ね。
死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。
死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。
死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。
死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。
死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。
死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。
死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。
死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。
死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。
死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。ｖ死ね。死ね。
死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。
死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。
死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。
死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。
死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。
死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。
死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。ね。死ね。
死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。
死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。
死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。死ね。