08/01/27 13:05:05
つか、Aの右上半分は真っ白にしか見えないんだけど、どうやったらここの形状を求められるの？
263:デフォルトの名無しさん
08/01/27 13:07:39
デジカメ素材に白飛びもあるという前提なのかね
264:デフォルトの名無しさん
08/01/27 16:41:48
うーん、Bの山って、明度でグラフにすると円錐からは随分離れた傾斜になっているんだけど。
どう見てもAみたいな直線の影ができるように見えない。
# jpgにした所為って可能性はあるけど。
265:デフォルトの名無しさん
08/01/27 19:14:26
800*600の画像があったとします。
逆透視変換のためにその画像を上辺900、下辺800、高さ1000の等脚台形に変換したいのですが、
.N簡単な方法があれば教えていただきたいです。
OpenCVのアフィン変換とかになるんですかねやっぱり
266:265
08/01/27 19:18:39
誤爆しました。
開発環境がC#2008なので、まずC#スレで聞いてきます。
267:254
08/01/27 20:01:25
ﾚｽありがとうございます。
ああ、皆さん、すいません、Aの画像とBの画像は手でつくったので必ずしも
一致するわけではないです。
こんな感じの処理がしたい、というサンプルです。
>>258
卒制ではないです。
うちのデザイナが高さマップをある程度簡単に作れる奴が欲しいと
のたまいやがるのです。
>>261
写真は一枚が多いですね。
しかも屋外の自然光が多い場合もあります。
あとフラッシュの影とかもある場合が多いです。
>>262
>>263
その辺りは別の処理をしてなんとかします。
必ずしも一回の処理で全てをまかなおうとは思っていません。
最悪手で描くことも想定しています。
>>264
一応線形の円グラデなので多分綺麗な円錐になると思います。
268:デフォルトの名無しさん
08/01/27 20:05:46
そもそもAの図は、グラデーションが付くのは右上で
左下は影になるのが普通だと思うが。
影の中に陰はできないよ。
269:デフォルトの名無しさん
08/01/27 20:24:16
URLﾘﾝｸ(www.itmedia.co.jp)
270:デフォルトの名無しさん
08/01/27 20:59:46
そりゃー平均顔を作れれば精度はあがるだろうけど、
どうやってその平均顔を作るための大量データを query の度に得るんだ？
271:デフォルトの名無しさん
08/01/27 21:43:35
>>270
そりゃ研究室のみんなに頼むに決まってるだろ。
後輩とか含めて２０人分ぐらい集まるんじゃね？
272:264
08/01/27 21:48:53
>>267
＞一応線形の円グラデなので多分綺麗な円錐になると思います。
だからなってねぇってばよ。
それはさておき、実際にAからBが得られた訳じゃないということは判った。
273:デフォルトの名無しさん
08/01/27 21:54:15
英国秘密情報部が集めて来ます
274:デフォルトの名無しさん
08/01/27 22:00:33
>>270
もしかしたら出入国管理くらいには使われるかもな
275:デフォルトの名無しさん
08/01/27 22:53:49
>>271
おまえはちゃんとリンク先を読め
>デビッド・ベッカム、クリント・イーストウッド、ショーン・コネリー、ビル・クリントンなどの著名人の写真を照合したところ、本人だと正しく判定されたのは半数のみだった。ところが彼らの平均的なイメージ写真をアップすると、識別度はほぼ100％に上昇したという。
つまり、クエリが平均顔でないといけない。
つまり、出入国の度にいろいろな光源の元やノイズのもとで写真を複数とって
平均顔作って入力とするってことだろ？どんだけぇ～
276:デフォルトの名無しさん
08/01/27 22:58:22
>>275
平均顔なんて１０人ぐらいあれば十分なんだよ。
277:デフォルトの名無しさん
08/01/27 23:02:09
10・・・人？
278:デフォルトの名無しさん
08/01/27 23:03:35
読解力無さ杉ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
279:デフォルトの名無しさん
08/01/27 23:08:12
>>276
ベッカムを10人集めるのは大変だと思うぞ
280:デフォルトの名無しさん
08/01/27 23:12:48
すまん、リンク先読んでなかった
顔認証で簡易鍵とかの用途ならできるんじゃね？
281:デフォルトの名無しさん
08/01/28 07:10:02
>>280
カメラの前で、
「少し右を向いて下さい」
「少し下を向いて下さい」
とかやるのか？ 指紋や掌紋や網膜認証の方が早いし確実な気がする。
普通に考えて、ずっと映像を取得している監視カメラの映像から平均顔を
作成して、それをキーに検索するってことだろうね。
282:デフォルトの名無しさん
08/01/28 07:49:13
>>254
面白い課題だなぁ。B→Aはできるだろうけど…
閃いた
1.手当たり次第にあらゆるBを作る
2. 大量のBから大量のA的画像を作る
3. 大量のA的画像とAと比較して大体似たような感じなら「たぶんこんな形じゃね？」と
そんな冗談を書いてみるテスト
形状が限られているなら…例えば円錐しか存在しないという仮定ができるなら
底辺の円のサイズ（中心と半径）と、影の頂点をユーザがマウスクリックで指定して（3回クリック）
てなツールを作って作業効率向上ができそうだけど、でもそれって画像処理じゃないな…
底円を求める処理と、影の頂点を求める処理を別にして、得られた2つの情報から類推して…とか…
Aの画像なら、黒い部分で三角形ができるから
そのうちの2つの頂点が低円の直径、かつ、円の中心点を通る直線で、残りの1点が影の頂点
と類推できそうな気もするけど、リアルワールドを撮影した場合に実際Aのような画像になるかどうかは判らないし
例えば航空写真を持ち込んできた場合は自動化は無理な気配
283:282
08/01/28 08:14:51
3DCGツールで円錐を作ってレンダリングしてみたが
URLﾘﾝｸ(gamdev.org)
>>254より判りやすいし見てるうちに方法が見出せそうでもあるけれど
実写の画像となったらこんな綺麗な見え方はしないよな…形状も多岐に渡るだろうし
284:デフォルトの名無しさん
08/01/28 08:25:33
パターン認識
285:デフォルトの名無しさん
08/01/28 10:46:10
>>254
この種の問題は "shape from shading" と呼ばれる一大研究分野だよ。
ググればいっぱい論文が見つかると思う。
286:254
08/01/29 02:36:00
ﾚｽありがとうございます！
>>282
残念ながら撮る対象は限定されていないのです。
ソースはデジカメだったり航空写真とかだったりが多いのではないかと思います。
画像はめっさわかりやすいですね！
それをデプスでレンダリングしていただけるとBのような画像になります。
>>285
ググッて見ました。
火星地表面とか宇宙とか・・・ﾃﾗ壮大です。
でも多分これですね。
殆ど英文なのでさっぱりわかりませんが
ちょっくらがんばって読んでみます。
287:デフォルトの名無しさん
08/01/29 10:05:16
>>285
オラも勉強になりました
「陰影からの形状復元」でググると色々出てきますな
これは面白い…
288:デフォルトの名無しさん
08/01/29 11:17:33
URLﾘﾝｸ(d.hatena.ne.jp)
BIAS libの日本語解説がないみたいなので作りました
289:デフォルトの名無しさん
08/01/31 15:44:39
RGB8各ビットのカラー画像を8ビットグレースケール画像に減色する方法って何がありますか？
290:デフォルトの名無しさん
08/01/31 16:44:07
足し算と割り算でおっけ
291:デフォルトの名無しさん
08/01/31 16:45:27
( R + G + B ) / 3
292:デフォルトの名無しさん
08/01/31 16:53:24
URLﾘﾝｸ(ofo.jp)
293:sage
08/01/31 17:32:57
>290
>291
>292
ありがとうございます。参考にしてみます。
294:デフォルトの名無しさん
08/01/31 17:34:12
sage間違えたｗ
295:デフォルトの名無しさん
08/02/07 04:28:18
URLﾘﾝｸ(gigazine.net)
296:デフォルトの名無しさん
08/02/08 18:41:40
おききしたいことがあります。非常に安価な（３～４万くらい）な画像処理
ボード（ライブラリでとりあえず一連の画像処理が可能）
を探しているのですが、ネット上で色々探したのですがみつかりません。
もしあったら教えていただけないでしょうか？よろしくお願いします。
297:デフォルトの名無しさん
08/02/08 18:51:12
自分で作ったら？
298:デフォルトの名無しさん
08/02/08 20:13:55
>>296
FPGAは？
299:デフォルトの名無しさん
08/02/09 10:03:06
ハードはwebカメラとPC、ソフトは適当なライブラリやソフトでも探してきたら？
PCIボードまで付いてるような奴だと専用のドライバが必要だったりして困る
新しいOSになったときにドライバが提供される保証もないし
300:デフォルトの名無しさん
08/02/11 22:02:36
今、RGB値からグレイスケールに変換するプログラムを書いているんだけど、
URLﾘﾝｸ(image-d.isp.jp)
ここ見て書いてるんだけど
RGB -> R'G'B'の変換が時間を食いすぎると思うんだけど
これは仕方ないんでしょうか。
いろいろ検索してみるとRGB -> R'G'B'の変換ははしょっているものがほとんど(ですね
R'G'B'はガンマ補正とのことですが
301:デフォルトの名無しさん
08/02/11 22:04:01
ごめ、途中で送られた。
R'G'B'はガンマ補正とのことですがあるとないとではどのくらい変わりますでしょうか。
自分で感じ取られないならどっちも同じと言われそうですが。
302:デフォルトの名無しさん
08/02/11 22:15:31
まずは実際の画像を変換して見たら
303:デフォルトの名無しさん
08/02/11 22:39:54
>>300
たかだか8bitのRGBなら変換テーブルつくるだけでそこそこの速度出ると思うが。
304:300
08/02/12 00:26:02
>>302
>>303
Thank you.
実際の画像を変換してみても自分の目にはそれほど違いは見られませんでした。
まぁ、こんなもんかな。と思います。
ですが、しかし、RGB->R'G'B'の変換を除いてもそんなに速度は変わりませんでした。
.Net in C#で組んでいるのですがBitmap.(set|get)Pixelが遅いのかな ?
これ以上はC#か.Net固有の問題になるとおもうので当該スレで聞きます。ありがとうございました。
# 変換テーブルと聞いて256 x 256 x 256 x 4 byteの変換テーブルを考えた俺涙目。
# この場合f(x) = x ^ 0.45のテーブルだけでいいんですね。
305:デフォルトの名無しさん
08/02/12 01:29:10
>>304
3*256じゃね？
そんなに時間がかかるとも思えんが。
306:デフォルトの名無しさん
08/02/12 03:21:26
画像処理の技術はどういった業界で生かされるのでしょうか
307:デフォルトの名無しさん
08/02/12 03:36:59
いろんなの
308:デフォルトの名無しさん
08/02/12 07:55:35
>>304
おまえがRGBだと思っている値がすでにR'G'B'な気がしてならない。
通常使われている8ビット画像（sRGBやAdobeRGBとか）では、
各画素の値（0～255）は線形輝度じゃなくてガンマ補正後の値だよ。
309:デフォルトの名無しさん
08/02/12 09:46:00
>>13は留年になったのだろうか
310:デフォルトの名無しさん
08/02/12 12:21:52
>Bitmap.(set|get)Pixelが遅いのかな ?
めちゃくちゃ遅い
その遅さに比べたらRGB->Grayの演算なんて無視可能
バッファリングしろ
311:300
08/02/14 02:12:34
>>308
Thank you.
そうだよね。いちいち変換が必要な形式で保管しておくのは非効率的だよね。
>>310
バッファリングって
URLﾘﾝｸ(junki.lix.jp)
に乗ってることでいいのかな ?
このとおりにやったら(unsafe使わずとも)めちゃくちゃ速くなってわろた。
おかげさまで満足な速度が得られました。
ありがとうございました。
312:デフォルトの名無しさん
08/02/15 03:17:34
イメージベースドレンダリングに興味があるのですが、これって普通、何を使ってやるもんなんでしょうか？
Ｃ＋＋とか?
それともOpenGLとか？
ご存じの方がいればぜひ教えて欲しいです。
313:デフォルトの名無しさん
08/02/15 04:06:58
何でも良いよ。
314:デフォルトの名無しさん
08/02/15 09:58:16
>>313
ありがとうございます。
OpenGLを使う場合、どのようにすればいいんでしょうか？
画像を２方向から貼り付けて、かぶってるところをブレンドするとか？
315:デフォルトの名無しさん
08/02/15 10:47:31
輝度値のみの画像において、
別の縞模様が混在するとき、
縞模様別にグループ分けを行うにはどうすればいいでしょうか？
316:デフォルトの名無しさん
08/02/15 12:08:57
cgal
317:デフォルトの名無しさん
08/02/17 02:14:55
フーリエ変換の話・・・？
318:デフォルトの名無しさん
08/02/17 21:13:03
>>314
SIGGRAPHの論文でも読めばいろいろわかるよ
319:デフォルトの名無しさん
08/02/22 02:35:37
エッジの抽出を行ってみたのですが、もと画像のエッジを強調したようにそれ
を適用したい場合どのような計算を行うのでしょうか?
エッジの抽出はカラー画像をグレースケールに変換して、それをラプラシアン
フィルタで行っております。エッジを抽出したエッジだけの画像があるのです
が、これをもと画像をどのような計算をしたらエッジの強調ができるのかを知
りたいです。
320:デフォルトの名無しさん
08/02/22 02:58:44
>>319
エッジ＋元画像でいいんじゃね
321:319
08/02/22 03:20:01
>>320
ありがとうございます。 私もそう思いやってみたのですが、ものすごい不自然
なできになりました。
やったこととしては、エッジの値を256階調のグレースケールで保存しているた
め、これを足してしまうと各カラーが256を越えてしまうため、適当な値で
(64)で割りました。
その値を、各カラーに足したのですがエッジに当たる部分が強調されるのでは
なく、予期しない色になってしまいました。
322:デフォルトの名無しさん
08/02/22 03:22:42
>>321
単なるバグだな。
もうちょっと考えて作れ。
323:319
08/02/22 03:32:30
考え方としてはあっているのでしょうか？
エッジのみを表示するとエッジが抽出できていることは確認できているので、
それ以降の処理としては値を足しているだけなので、簡単に確認できると思います。
注意深く確認してみます。
324:デフォルトの名無しさん
08/02/22 03:54:43
まぁそりゃー変な色になるだろうなぁ。
(0,10,20) + 230 = (230,240,250)
とされたら大分かんじは違うもんな。
RGB チャネル別々にするとか、
HSV の V の部分にだけ適用するとか(HSI でもいいけど）、
そういうが必要になるんじゃない？
それでも強調の表現として Intensity を高めるのがうまい表現なのか、
とか考える必要がありそうな気もする。
「エッジ辺りは赤っぽくして強調してみました」なんて表現もありうるんだろうし。
なにもぐぐらず書いているので、ぐぐったほうが早いかも。
325:デフォルトの名無しさん
08/02/22 10:05:47
エッジは足すんじゃなく元の画像から引け。
326:デフォルトの名無しさん
08/02/22 12:03:02
エッジ強調とかソフトとかのフィルタを書けたときに、その効果が
見やすい画像ってどんな画像だろう。
327:デフォルトの名無しさん
08/02/22 12:30:32
横入り失礼。
おれも昔にエッジ抽出とか試したことあるんだけど、なかなかうまく行かなかった。
{{ 1 1 1}
{ 1 -8 1}
{ 1 1 1}}
ってなフィルタを作って、それらを全部足して行ったら256越えちゃうの。
おれって阿呆なの？
これをどうやったら256までの値にできるの？
328:デフォルトの名無しさん
08/02/22 12:59:39
つうか、こんな話は画像処理の基礎なんだから
本屋で立ち読みするなり、図書館で本を読むなりする
程度の努力はしようよ…
329:デフォルトの名無しさん
08/02/22 13:03:14
そんなこと言うなら、答えてやればいいのに
330:デフォルトの名無しさん
08/02/22 13:26:57
ソフトよりはエッヂの方が確かに難しいかもな
331:デフォルトの名無しさん
08/02/22 17:05:31
>>327
つ飽和演算
332:デフォルトの名無しさん
08/02/22 17:07:06
すまOTZ。
×>>327
○>>321
333:デフォルトの名無しさん
08/02/22 18:26:19
普通気付くでしょ、阿呆だよ
334:デフォルトの名無しさん
08/02/22 22:08:19
>>327
阿呆だなぁ。超えるのが普通だと思えないとはなぁ。
255 255 255
255 0 255
255 255 255
なら 255 * 8 の値になるだろ？超えるさ。
335:デフォルトの名無しさん
08/02/22 22:29:50
コーシー・シュワルツの不等式置いときますね
-|X||Y| ≦ X・Y ≦ |X||Y|
336:デフォルトの名無しさん
08/02/23 00:18:41
>>334
越えるからどういうふうにしたらいいか聞いてるんじゃないんでないか？
337:デフォルトの名無しさん
08/02/23 00:20:34
適当に正規化すればいいんじゃないの?
338:デフォルトの名無しさん
08/02/23 00:35:21
うむ。そもそも画像ファイルとして表示しなければいけないというわけでもないしね。
どうしても画像ファイル的に表示したい場合 0-255 の範囲に正規化してやればいい
339:デフォルトの名無しさん
08/02/23 05:13:24
内部は全部 double にして、出力時だけ正規化してる
>>326
Lenna みたいなテスト画像だと似たような処理例が見つかる確率が高いのでいいんじゃない?
URLﾘﾝｸ(en.wikipedia.org)
340:デフォルトの名無しさん
08/02/23 17:55:11
>内部は全部 double にして
計算速度、遅そう。
あと、正規化するんなら、アンダーフローもお忘れずに
341:デフォルトの名無しさん
08/02/23 18:11:50
内部はintとかでよくね？
342:デフォルトの名無しさん
08/02/23 18:31:16
用途による。FFTする必要があるなら実数にしなきゃならんし。
343:デフォルトの名無しさん
08/02/23 18:55:48
doubleの演算はfloatより早いよ
344:デフォルトの名無しさん
08/02/23 18:56:37
というのはガセ
345:デフォルトの名無しさん
08/02/23 18:58:05
というのもガセ
346:デフォルトの名無しさん
08/02/23 19:03:22
画像処理で整数型とかどんだけニッチな用途なんだよ
347:デフォルトの名無しさん
08/02/23 19:12:03
画像処理で浮動小数点とかどんだけニッチな用途なんだよ
348:デフォルトの名無しさん
08/02/23 19:38:42
画像処理とかどんだけニッチな用途なんだよ
349:デフォルトの名無しさん
08/02/24 00:20:25
正規化って何？
350:デフォルトの名無しさん
08/02/24 00:40:54
エッジ強調のCのソース無いかな
351:デフォルトの名無しさん
08/02/24 02:35:31
エッヂの強調は誰もが通る道なのか
352:デフォルトの名無しさん
08/02/24 03:24:58
むっつりですまん
353:デフォルトの名無しさん
08/02/24 11:54:40
漏れも通った
20年くらい前に
354:デフォルトの名無しさん
08/02/24 12:09:50
20年前って8ドットで16中2色しか使えない時代じゃん。
355:デフォルトの名無しさん
08/02/24 12:24:25
ハードウェアの制約があっても計算式は制約ないんじゃね？
多くの技術がそういうもんだろ
356:デフォルトの名無しさん
08/02/24 12:30:21
そもそも縁の強調って通ったとか悩むほどのものなのか
357:デフォルトの名無しさん
08/02/24 13:32:34
>>354
TMS9918乙、つーかもう26年前だそれは。
つーかX68kももう20年超えてるのか…。
358:デフォルトの名無しさん
08/02/24 14:45:48
>>356
結構難しいでしょ。
抽出なら簡単だけど、抽出した箇所を厳選(エッジの輪郭抽出とか、ノイズ除去)して
それをもと画像に適用しなくてはならん。
適用するのにもどの範囲を適用するか、適用の強度は、適用後のノイズ除去は。
とか色々な問題が出て来る。 ライブラリ使ったら簡単だし、Windowsでも簡単だけど。
359:デフォルトの名無しさん
08/02/24 17:27:35
多分、ここのやつらはWindowsでしょ。
画像加工の難しさを知らない
360:デフォルトの名無しさん
08/02/24 18:08:04
専用組み込み機器でやってるオレも見てますよ
361:デフォルトの名無しさん
08/02/24 21:00:14
アンシャープマスクじゃ駄目なのか？
362:デフォルトの名無しさん
08/02/24 22:10:24
>>359
OSはあんまり関係ないような
むしろ用途
363:デフォルトの名無しさん
08/02/25 08:27:30
>>361
ソフトは足した後割るだけでいいでしょ
364:319
08/02/25 09:25:18
色々と調べてみたのですが、わからなかったです…。
私がやっているのは、8近ほうの各値(RGB255値)にフィルターの値を積算してそれを全て和算しています。
その値が120よりおおきければ、各値(RGB255値)に2を足しています。
この値を変えてもエッジが強調されているようには見えません。
皆さんはどのような計算をなさっているのでしょうか？
365:デフォルトの名無しさん
08/02/25 09:29:19
1%明るくしたくらいじゃ、強調にならないだろ。常考
366:デフォルトの名無しさん
08/02/25 09:42:53
ラプラシアンフィルタはエッジの抽出であって、強調はできないでしょ。
367:デフォルトの名無しさん
08/02/25 21:24:29
せっかく>>361が教えてくれているというのに皆ガン無視なのな
ラプラシアンでもやることは一緒やん
368:デフォルトの名無しさん
08/02/25 21:26:08
アンシャープマスクってソフトフィルタだろ？
369:デフォルトの名無しさん
08/02/25 21:33:51
ググれカス！がこれほどよく似合う>>368は居まい
370:デフォルトの名無しさん
08/02/25 21:37:36
na\\なんですかそれは
371:デフォルトの名無しさん
08/02/26 03:10:04
>>364
＞その値が120よりおおきければ、各値(RGB255値)に2を足しています。
何のために？
372:デフォルトの名無しさん
08/02/26 08:47:02
>>349
正規化とは変な値を都合のいいように直すことだよ。
たとえば角度の-90度を270度に直すとか。
都合によっては逆に角度270度を-90度に直すのも正規化。
8ビットの画素の値なら
if(x > 255) x = 255; else if(x < 0) x = 0;
このxで描画すればいい。
373:デフォルトの名無しさん
08/02/26 09:32:29
>>372
>if(x > 255) x = 255; else if(x < 0) x = 0;
>このxで描画すればいい。
大学の課題でこれ提出したら減点だな。
画像として表示して何がしたいのかといったら、
エッジとしての強度を目視したいわけで、
256 も 1100 も全部同じ強度として表示するってんじゃぁ、
こまっちんぐだぜ
374:デフォルトの名無しさん
08/02/26 10:04:31
それは気がつきませんでした。
エッジ強度の目視とか
そんなに大きな値を加算しているとは思いませんでした。
375:デフォルトの名無しさん
08/02/26 14:01:55
>>371
その値は0から1000を越えるものまであり、それをRGBの値に足すとおかしな画像になってしまいます。
なので、このばあいは120以上をエッジとするようにして、そのエッジ部分に一律2を足そうと考えました。
この考えは間違っているのでしょうか？
376:デフォルトの名無しさん
08/02/26 14:17:20
ラプラシアンなら負の値も出てくるだろ。
つうか、何で2を足すんだ？
377:デフォルトの名無しさん
08/02/26 14:24:54
>>376
負の値がでたら、絶対値に擦るようにしています。
2を足すのは、エッジの部分に対応するもと画像を強調したいためです。
378:デフォルトの名無しさん
08/02/26 14:25:16
すみません。 足していません。 引いています。
379:デフォルトの名無しさん
08/02/26 14:44:24
だから、1%程度明るくなろうが暗くなろうが目立つわけないだろと。
380:デフォルトの名無しさん
08/02/26 14:46:05
では、どのような加工をしたらいいのでしょうか？
381:デフォルトの名無しさん
08/02/26 14:50:34
少しは頭を使え。手を動かせ。
382:デフォルトの名無しさん
08/02/26 14:59:45
エッジ抽出以前に、画素の量子化とその値についての理解が全然足りないように思える。
383:デフォルトの名無しさん
08/02/26 15:31:10
スレ伸びてると思ったらｗｗｗｗ
久々にﾜﾛﾀｗｗｗｗ
384:デフォルトの名無しさん
08/02/26 18:42:49
まだやってたのか
385:デフォルトの名無しさん
08/02/26 19:08:11
誰も的確な答えを出さないからでしょ
386:デフォルトの名無しさん
08/02/26 19:13:30
ぷっ
387:デフォルトの名無しさん
08/02/26 19:22:51
理解不足しているだろうから、弄っているだｊけ。
断片的な返答から的外れなのは分かるが、どこまで的を外しているか
全体像が掴めないので、誰も的確な返答が出来ない。ｗｗｗ
388:デフォルトの名無しさん
08/02/26 19:26:37
まぁ、回答者の大半も意味が分かってないけどな。
389:デフォルトの名無しさん
08/02/26 19:32:23
問題が何なのかすらわからん俺にとって関係ない話だな
390:デフォルトの名無しさん
08/02/26 20:27:02
必要の無い奴まで書き込むから、こんな風になるんだよ。
391:デフォルトの名無しさん
08/02/26 22:04:19
ソースコードでもうｐしてみれば盛り上がるんじゃね？
392:デフォルトの名無しさん
08/02/26 22:31:07
そのラプラシアンって元画像に合成しても
画像のエッジ強化につかえねーんじゃねーの？
ラプラシアンてどんな値の範囲になるのかしらないけどさ。
393:デフォルトの名無しさん
08/02/26 22:33:53
>>321
65で割れ
394:デフォルトの名無しさん
08/02/26 23:55:23
薄緑だけ濃くしたいんですけど、どんな計算が有効ですか？
395:デフォルトの名無しさん
08/02/27 00:14:46
>>394
if (画素.色 == 薄緑の範疇) 画素.濃く(適当に)
396:デフォルトの名無しさん
08/02/27 00:59:16
>>395
上手く処理できました。ありがとうございます。
397:デフォルトの名無しさん
08/02/27 01:35:29
ﾜﾗﾀ
398:デフォルトの名無しさん
08/02/27 02:40:26
たまたまWindowsの画像を扱ってるコード見たけどひどいな。
ライブラリに展開とかすべてまかせて、それをWindowにはっつけてるだけ。
WindowにはっつけるのもAPI。
画像の加工はライブラリのできる範囲内でやってるし。
399:デフォルトの名無しさん
08/02/27 03:08:43
間違いなくお前の日本語が一番酷い
400:デフォルトの名無しさん
08/02/27 04:01:29
>>398
で？
401:デフォルトの名無しさん
08/02/27 05:02:45
画像処理技術者って、結局『やってみなきゃ解らない』を逃げ場にしている人達のことですか？
402:デフォルトの名無しさん
08/02/27 05:08:02
で？
403:質問です
08/02/27 08:05:51
ここの人は親切だから、つい聞いてしまうんだが、
古いカラーのネガフィルムをスキャンして、データ化しました。中にカビだろうか
緑色のアメーバ状の汚れがあります。これを取るのって、範囲を指定して
緑の要素が強いピクセルのみ緑を弱くするしか方法はないでしょうか。
>>401 氏の発言も考慮の上、お教えください。
404:デフォルトの名無しさん
08/02/27 08:11:12
手でレタッチしたほうがはやいんじゃね
405:デフォルトの名無しさん
08/02/27 08:14:49
>>398
車輪の再発明はお好きですか
406:デフォルトの名無しさん
08/02/27 08:18:40
いつもの写真馬鹿か
407:デフォルトの名無しさん
08/02/27 08:44:30
もう学生の宿題ネタはお腹一杯
408:デフォルトの名無しさん
08/02/27 09:10:24
>>403
緑の汚れが乗っていると言うことは、その為に情報量が落ちていると言うこと。
従って、仮令緑を弱くしても元の画質が完全に再現できるわけではないことに注意。
409:デフォルトの名無しさん
08/02/27 21:21:35
if (画素. == カビ含む) 画素.取る(カビ)
410:デフォルトの名無しさん
08/02/27 22:16:45
カビの無修正画像
411:デフォルトの名無しさん
08/02/27 22:23:49
フィルムからカビを除去して再スキャン
プログラムにまかせるよりも着実な気がする。
412:デフォルトの名無しさん
08/02/27 22:43:30
カビキラーでおｋ
413:デフォルトの名無しさん
08/02/27 22:55:55
>>409
実装して下さい
414:デフォルトの名無しさん
08/02/27 23:28:05
C++嫌い
415:デフォルトの名無しさん
08/02/28 00:03:16
昔、ノイズ除去をやって思ったが、何をノイズと捉えるかが難しい。
「こっち」「そっち」の境界線が曖昧なのと一緒でノイズだと思いはじめたら全部ノイズに思えて来る。
画像上のカビも何をしてカビと特定するかが問題だ。
画像上でそこにあるカビの成分が検出できればもっと簡単かもしれん。
416:デフォルトの名無しさん
08/02/28 00:08:50
どう考えても>411だなぁ。>408の指摘する問題も解決するわけだし。
417:デフォルトの名無しさん
08/02/28 00:18:13
カビを見たい人だっているかもしれないからな
418:デフォルトの名無しさん
08/02/28 00:31:54
このスレ的な話題ではないが、
実際にフィルムをスキャンする仕事をしていたが、カビの除去はできない。
ある程度はできるが、ある程度以上はフィルムに傷がいくからそれ以上は繁殖を抑える加工をして
スキャンして、将来的にカビを綺麗に除去できる技術ができるのを待つだけ。
個人のフィルムならどうでもいいと思うが、仕事として請け負うフィルムは歴史的なものが多いから。
色々な業務用のフィルム画像の補正ソフトを使ってみても、結局ホコリが綺麗に見えなくなるくらいが限界。
あとの変色とかは1ピクセル毎に手作業で修正する。
自動ソフトで頑張る価値はあんまりないと思う。
419:デフォルトの名無しさん
08/02/28 10:01:48
>>403
画像処理 その８で話題になっていた
gimpのプラグインもあるのですぐ試せる
URLﾘﾝｸ(www.greyc.ensicaen.fr)
420:デフォルトの名無しさん
08/02/28 16:38:35
URLﾘﾝｸ(www.itmedia.co.jp)
421:403
08/02/28 19:32:14
皆さん & >>419 さんありがとう。
解があることが分かった。気分は途も半ば。
422:デフォルトの名無しさん
08/02/29 01:32:04
ほこりや傷があった方が味がいいと思う。
423:デフォルトの名無しさん
08/03/01 12:12:00
jpegの量子化テーブルって8以下指定出来るん？
8bitに収まらんと思うんだが。
424:デフォルトの名無しさん
08/03/03 11:13:28
>>423
何が言いたいのかワカランが
量子化テーブルって1-255だろ・・・？
425:デフォルトの名無しさん
08/03/04 00:50:59
元画像とそれを画像処理したものを比較して、元の画像が含まれるかどうやって識別するのがいいのか
回転拡大縮小は無い前提で
426:デフォルトの名無しさん
08/03/04 01:05:58
目視
427:デフォルトの名無しさん
08/03/04 01:07:41
>>425
bool isInclude() { return true; }
他にどうしろと。
428:デフォルトの名無しさん
08/03/04 02:20:55
is includeって酷い関数名だな
429:デフォルトの名無しさん
08/03/04 04:03:23
テンプレートマッチングだかなんとか
430:デフォルトの名無しさん
08/03/04 08:30:43
process(元画像).eq.比較画像
まさかね…
431:デフォルトの名無しさん
08/03/04 10:04:14
>>425
適当に特徴抽出して、その特徴で比較すりゃいいだろ。
432:デフォルトの名無しさん
08/03/04 10:58:13
含まれるという言い方が悪かった
部分的に色合いが変化してたり、ネガポジ反転していても元画像と同じだと判断する方法が欲しかった
やっぱり特徴抽出か
433:デフォルトの名無しさん
08/03/04 10:59:00
>>432
どんな画像処理をしたのか見当がついているなら、特徴を抽出する必要はないけどね。
434:デフォルトの名無しさん
08/03/05 03:11:24
＞部分的に色合いが変化してたり、ネガポジ反転していても元画像と同じだと判断する方法が欲しかった
RGB変化ならエッジ検出でいいんじゃない。
435:デフォルトの名無しさん
08/03/06 23:36:38
>>424
ん？えと、jpeg（てかDCT)の計算式だと0～255の
8x8ブロックの計算結果が-1024～1024になる（可能性がある）んよ。
つまり情報量が3bit増える訳なのね。
それを削除するためにjpeg基準テーブルは8以上を指定しているんだな、と。
つまり3bit以上減らすのが前提だと判断してたのよ、俺は。
でも某jpeg本が「超高画質なら1を指定しる」とか書いてたんで
「あれれれ？それマジ有り？」と思ったので聞いてみた。
知ってる人答え教えてちょ！
436:435=423
08/03/06 23:37:29
ってことで一つヨロシク
437:デフォルトの名無しさん
08/03/06 23:41:39
-1024～1024なら5bit増えてない？
438:デフォルトの名無しさん
08/03/06 23:45:23
5？
439:デフォルトの名無しさん
08/03/06 23:47:51
あ、-1024～1024じゃなく-1024～1023だな。すまん。
ま、内部計算次第だけどさ。
ちなみに0-2047は11bitだぞう。
440:デフォルトの名無しさん
08/03/06 23:48:11
増えてるな。
441:デフォルトの名無しさん
08/03/07 09:05:15
>>435
DCTの結果についてはそのとおり
けど、量子化によって、8bitに収めるわけじゃない
量子化したあと、
ハフマン符号化でその範囲の値を受け入れるだけ
442:デフォルトの名無しさん
08/03/07 21:47:58
>>441
おお、ありがとう！
そうか、ハフマン忘れてたんだ。
いや、本当にありがとう。今度一杯奢るよ。
443:デフォルトの名無しさん
08/03/08 21:04:36
二つの色を比べてどのくらい似ているかを判断したいのですが、どのような方法がありますか。
生の色情報は、RGBのフルカラーで持っています。速度は要求していないので、変換するのは問題ありません。
赤、緑、青のそれぞれの色の差で単純に比較でも良い気はするのですが、65536色では緑に多くビットを割り当てるくらいだし、色の濃さによっては同じ差分でも感じ方が違うと思うので、もう少しましな方法がないかなと思っています。
444:デフォルトの名無しさん
08/03/08 21:13:28
RGBの差に輝度の係数かけてみたら?
445:デフォルトの名無しさん
08/03/08 21:23:01
「似ている」とは何を意味するのかが問題ですな
446:デフォルトの名無しさん
08/03/08 22:04:39
彩度が高いと色相が支配的になるだろうし、
色相によっては明度が違って見えるし、
明度が両極端だと彩度の意味がなくなるし、
……
447:デフォルトの名無しさん
08/03/08 22:19:07
いわゆる特殊な色覚を持っている人が似ていると判断する色と
そうじゃない人が似ていると判断する色は違うからなぁ
448:デフォルトの名無しさん
08/03/08 22:22:03
周波数領域での加工を前提とすると、
FFT前に窓がけしないと、周波数領域の信号レベルの確度が悪くなる
逆FFT後に窓がけしないと、時間領域で接続性が悪い
上の理由から実務上2度窓がけする必要があって、かつ、2度の窓がけ後の結果の
オーバーラップが元信号に戻らないといけない。でも、han窓は１回の窓がけの
結果のオーバーラップで元に戻るように設計されてるから適さない。
449:デフォルトの名無しさん
08/03/08 22:43:01
なぜサウンドプログラミングスレのコピペが
450:デフォルトの名無しさん
08/03/08 23:18:56
>>443
まずyuy2にする。それで輝度と色度に分ける。
人間の眼は輝度＞色度だから色度の重要さを下げる。
音よりは低いが人間の感じる感触は指数に比例しがちだからそれも考慮する。
ってのを考慮すればそこらのフリーソフトよりは精度上がるよ。
それ以上は研究の分野になる。
アナログ<->デジタルはいつの時代も研究さ。
451:デフォルトの名無しさん
08/03/08 23:40:01
研究とか言い出す前に「均等色空間」という言葉くらい出そうぜ。
塗料とか製造業の分野では色の違いは黙ってΔE*abで評価するものだ。
452:443
08/03/09 00:04:22
>>444
RGBのそれぞれの差に、緑を大めに掛けてみるってこと？
>>445
色が近いかどうかって意味。
赤と青はだいぶ色が違うけど、緑と黄緑は色が近いとかって感じ。
>>446
色とかの判断方法は全然知らないのでちょっと調べてみたんですけど、画像関係のアルゴリズムは奥が深そうで・・・。
>>447
まー、一般的な人が似ている色とするってことで。
>>448
よくわからんけど、サウンド関係ってことかな。
>>450,451
YUY2とか、均等色空間とか、聞いたことない単語が出てきたから、明日調べてみる。
453:433
08/03/09 13:36:32
以下のページを参考に、色差を求めることにしました。ΔE*abってやつですかね。
URLﾘﾝｸ(image-d.isp.jp)
URLﾘﾝｸ(www11.tok2.com)
多少、感覚と違う値となることはありますが、似ているのに違う色と判断することがないよう、閾値を大きくすることにしました。20とか。
違う色なのに似ていると誤判定されても多少は許される用途なので。
それにしても、規格が多く、変換に使用する値が複数あったりしてややこしいですね。
454:デフォルトの名無しさん
08/03/09 13:40:32
まあそんなんでいいと思うよ
455:デフォルトの名無しさん
08/03/12 15:45:35
パターンマッチ＋サブピクセル処理をいろいろ調べたいのですが、
いいサイト、本などございませんでしょうか。
本をみたりしていますが、なかなかいいものがなくて。
やりたいことは、撮影位置に移動してきた
丸いものの画像を取ったときのずれ量（XY座標）
を検出したいです。
先生方よろしくお願いします。
456:デフォルトの名無しさん
08/03/13 18:13:55
どこまで調べた？
本のタイトルとか。
あと、それで満足できない理由は何かを教えといて。
457:455
08/03/14 00:37:18
＞４５６
すいません。
あと一日調べ倒してから、
再質問することにします。
458:デフォルトの名無しさん
08/03/14 00:39:34
そういやJPEG XRってどうなってるんだろ
459:デフォルトの名無しさん
08/03/14 02:55:21
DATファイルに格納されている画像を取り出すにはどうすればいいですか？
460:デフォルトの名無しさん
08/03/14 03:16:56
スレ違い
461:デフォルトの名無しさん
08/03/14 15:52:04
ある意味画像処理だなｗ
462:デフォルトの名無しさん
08/03/14 17:01:45
>>459
拡張子をmpgに書き換えてダブルクリック
463:デフォルトの名無しさん
08/03/14 19:39:31
>455
やりたいことから考えると、パターンマッチングよりハフ変換のような気がする。
その「丸いもの」は何？
カメラ視野に入ってきたり出て行ったりするもの？
形や大きさが決まっているならテンプレートマッチングでいいけど。決まっていないならハフかな。
理論が知りたいなら、Forsyth「コンピュータビジョン」あたりが、理論はどうでもよくとりあえずできればいいならOpenCVでいいのでは。
464:455
08/03/15 03:34:20
>463
ご返信ありがとうございます
ハフ変換（円弧）実験してみます。
丸いものは、ちょっと答えられないのですが、すいません。
あと精度を高めるためにサブピクセル処理を調べていますが
いまいち理解ができていないためか、
ハフ変換で円弧検出後、サブピクセル処理をどう実装すればいいか
わかりません。頭悪くてﾄﾎﾎ。
明日、都会までいくので
Forsyth「コンピュータビジョン」
OpenCVの本も買ってみます。
楽しみです。電車の中で読んでみることにします。
ありがとうございます。
制御ソフトとは、また違って画像処理は奥が深く
興味深いです
465:デフォルトの名無しさん
08/03/15 03:42:07
Computer Visionは日本語訳が出てますよ（調べてるだろうけど…）
466:デフォルトの名無しさん
08/03/15 09:10:23
丸いもの……
ディスク? 半導体ウェファー? 月? 鼈?
467:デフォルトの名無しさん
08/03/15 11:00:17
URLﾘﾝｸ(ja.wikipedia.org)
丸いものがいっぱい。
468:デフォルトの名無しさん
08/03/15 12:51:12
Forsyth「コンピュータビジョン」を持ち歩くのか...
469:デフォルトの名無しさん
08/03/15 18:14:49
>464
サブピクセル処理、わからなければ元画像を１０倍に広げてやれば、元の0.1ピクセル処理したのと同等。
あと、フォーサイス＆ポンスの本は理論偏重なのでズバリと書いてあるわけではないし、方向性が違えば全く役に立たない。読んでいて面白いから価値はあるけど。本屋で見てみるべし。
470:デフォルトの名無しさん
08/03/15 21:42:00
>>467
灌漑農業の上空写真か。
まるで圧縮画像のブロックノイズだな
471:デフォルトの名無しさん
08/03/17 21:18:51
画像の回転について質問があるのですが、回転行列を
固定小数点にて表現するときにはどの程度の精度があれば十分なのでしょうか？
自分の考えだとVGAの場合2^10>640であるため符号も込めて10ビットの精度が必要
であると思うのですが如何でしょうか?
472:デフォルトの名無しさん
08/03/17 21:48:27
君に目は無いのか
473:デフォルトの名無しさん
08/03/17 22:51:06
無いんです
474:デフォルトの名無しさん
08/03/18 03:25:33
このスレの住人なら知っていますね、あの糞開発ツールのことを
・自分のプログラムのバグなのかコンパイラのバグなのかわからない
・他の仕事に応用できない糞開発ツールの独自世界を必死に学習している
・テキストエディタで書いたほうが効率的なのに糞UIツールを懸命に使っている
糞だけど、政治的な理由で無理やり使わされているんですよね。
もう、あんな厨の作った糞ツールを我慢して使うのはやめましょう。
・糞開発ツールを部下に押し付ける上司の命令は無視しましょう。
上司は糞開発ツールが使われる実績を作ることであの会社のごきげんをとっているのです。
・あの糞開発ツール提供会社には「おたくの糞開発ツールは話にならない」と突き放しましょう。
バグレポートなどしてはいけません。改善要求などもってのほかです。
あの会社はあなたたちのことをテスター/モルモットとしか思っていません。
・あの会議で「糞開発ツールを使ったら生産性がxx％アップしました」
なんて話が出たら力強く机を叩き、会議室を出ましょう。
あの人たちは糞開発ツールをマンセーすることで立場を確保しているのです。
糞な開発ツールを糞だと言える、そんな当たり前の環境をみんなの力で取り戻しましょう。
475:デフォルトの名無しさん
08/03/18 04:49:43
あれってどれだ
いっぱいありすぎてわからん
476:デフォルトの名無しさん
08/03/18 15:34:41
Javaだろ。
477:デフォルトの名無しさん
08/03/18 16:42:14
Javaってツールなのか？
478:デフォルトの名無しさん
08/03/18 17:50:02
コンピュータ自体がツールです
479:デフォルトの名無しさん
08/03/18 18:15:39
Oracleのツール類だろ。
480:デフォルトの名無しさん
08/03/18 19:41:17
人間はわたしの道具です
481:デフォルトの名無しさん
08/03/18 22:28:54
我が共和国の同士は全て将○様の道具ニダ。
同士でないのは、奴隷ニダ。
482:デフォルトの名無しさん
08/03/20 11:16:20
ｱｰｱ
483:デフォルトの名無しさん
08/03/25 13:20:42
lisp使ってる人っています？
pythonなら沢山いるのかな
ほとんどはc?
484:デフォルトの名無しさん
08/03/26 02:37:08
> lisp使ってる人っています？
> pythonなら沢山いるのかな
どちらも好きだが本格的に使うに至らない
485:デフォルトの名無しさん
08/03/26 02:49:37
簡単な処理ならPython+PILでやるときもある
486:デフォルトの名無しさん
08/03/26 04:46:31
>>483
何か遅いよなぁと思いつつJava
487:デフォルトの名無しさん
08/03/26 21:10:17
URLﾘﾝｸ(www.cliki.net)
lispの画像処理、いろいろあるけど
OpenCVみたいにメジャーなのはどれ？
488:デフォルトの名無しさん
08/04/03 22:12:23
URLﾘﾝｸ(dc.watch.impress.co.jp)
すげえ
489:デフォルトの名無しさん
08/04/03 22:32:58
>488
確かにすげぇ。
ピンボケしても元の情報って落ちてないのか。
落ちてると思い込んでた。
490:デフォルトの名無しさん
08/04/03 22:43:36
>>488
これはデコンボリューションの1種という捉え方であってるのかな…
491:デフォルトの名無しさん
08/04/03 22:46:32
いや、落ちますよ。写真として再現するレベルには足りているようですが。
492:デフォルトの名無しさん
08/04/03 22:57:27
この人は元Stanford大なんだね
研究成果を活かしたベンチャーらしい
だれか興味がある人は元の論文読んでくれ
493:デフォルトの名無しさん
08/04/03 23:05:47
>>488
この"Light Field Camera"ってカメラ自体も特殊なんじゃねーの？
URLﾘﾝｸ(dc.watch.impress.co.jp)
494:デフォルトの名無しさん
08/04/03 23:28:32
URLﾘﾝｸ(graphics.stanford.edu)
URLﾘﾝｸ(graphics.stanford.edu)
URLﾘﾝｸ(graphics.stanford.edu)
センサの手前に挿入するマイクロレンズが肝で、
4次元ライトフィールドをキャプチャできる代わりに解像度が犠牲になります。
本当にありがとうございました。
495:デフォルトの名無しさん
08/04/04 00:41:38
>>494
リンクにある顕微鏡版のはyoutubeにデモがあがってたな
496:デフォルトの名無しさん
08/04/04 07:52:55
あの～、ピンボケの自動補正なんて、すごく地味で超初心者向けな機能なんですけど。
この手法を応用して、もっと別な面白いことに発展したらいいね。
497:デフォルトの名無しさん
08/04/04 08:54:40
つまり、記事を書いた香具師は画像処理の基本も判っていない半可通だと言うことで宜しいか。
498:デフォルトの名無しさん
08/04/04 09:01:18
記事ではマイクロレンズにも言及しているし、仕組みを何も理解せずに書いたわけではないだろう。
ただ、タイトルが「ソフトウェア技術」となっているのは誤解を招きやすい。
499:デフォルトの名無しさん
08/04/04 10:09:20
>>498
発表者がマイクロレンズって言ってたのをそのまま書いただけだろ。
ボディとレンズの間にマイクロレンズがあるって、あとから訂正されてるし。
500:デフォルトの名無しさん
08/04/04 10:33:54
ああ、さっき初めて記事を読んだから気づかなかったけど、>>494の1時間後に訂正されてたのか。
501:488
08/04/04 21:16:52
やっぱりそういう話なのか(´･ω･`)
光学屋には面白いけど、画像処理はそこまで
複雑じゃないよなあ
502:デフォルトの名無しさん
08/04/04 21:33:56
これってあとから被写界深度も変えられるのかな
503:デフォルトの名無しさん
08/04/05 01:00:37
>>501
>>494の2つ目の論文（SIGGRAPH 2005採択）を読んだ上で「そこまで複雑じゃない」と言ってる？
4Dライトフィールドと2D写真の関係を周波数空間で解析する理論のほうもかなり興味深いと思うけどなぁ
504:デフォルトの名無しさん
08/04/11 15:33:18
Ｃ以外を使ってる人って本当にいないのかい？
505:デフォルトの名無しさん
08/04/11 16:01:32
>>504
いくらでもいるだろ。このスレでもアセンブラの話をしてるやつがいた。
ただ、言語の話はスレ違い。
506:デフォルトの名無しさん
08/04/12 07:01:58
c#でもそこそこスピードでたので移行した。
507:デフォルトの名無しさん
08/04/15 17:48:02
himatsubushiってサイトの人は、
昔、VBで書いてた
508: ◆Cgjmdh7/b6
08/04/16 00:24:35
test
509:デフォルトの名無しさん
08/05/01 00:28:36
グレースケールのある程度変化のある背景から明度の差がある
繋がった図形をどうやって抽出すればいい？
背景は基本的に連続的だが規則性はない
抽出するものは例えば中が塗られたいびつな円とかだけど輪郭は、ぼやけてる
抽出条件は基本的に周りより暗いってことだけ
人間がみれば見つけられるが、輪郭強調すると背景のパターンも強調されてしまう
背景は暗い部分もあれば明るい部分もあり、閾値は使えない
510:デフォルトの名無しさん
08/05/01 00:37:26
>> 509
何で背景は暗い部分と明るい部分に分かれるの？
安定した状態にならない理由は？
511:デフォルトの名無しさん
08/05/01 07:50:54
とりあえず１階微分とって観察。
２階微分とって観察してみれば？
512:デフォルトの名無しさん
08/05/01 21:36:44
シェーディング補正とかは使えないのかな？
513:デフォルトの名無しさん
08/05/02 10:09:17
boost.gilの正式版でたけど使ってる人いる？
514:デフォルトの名無しさん
08/05/02 11:46:16
３月にでたBIASのリリース版使ってる人いますか？
深刻なバグあったりしないですか？
うちは挙動がおかしかったので前のバージョンに戻しました
515:デフォルトの名無しさん
08/05/02 11:51:37
なにそれ
516:デフォルトの名無しさん
08/05/02 18:53:26
>509
面積・幅・形状よって適した方法が変わるので、モノは何？
言いたくなければ、近いものでもWebイメージから指定したら？
汎用の回答でいいなら、「Photoshopでアンシャープ後、２値化する。」
517:デフォルトの名無しさん
08/05/03 13:20:46
BIAS
URLﾘﾝｸ(www.mip.informatik.uni-kiel.de)
ver 2.5.0で問題なく動いていたプログラムが
ver 2.6.1にしたとたんセグメントフォルトで落ちるようになった
何かの関数を連続で呼ぶと関係ない配列データの中身を書き換えているぽい
誰か使ってる人いないの？
画像の幾何学処理してくれるlibraryって他にある？
518:デフォルトの名無しさん
08/05/03 18:15:49
例外が発生するバグほどデバッグしやすいものはないと思うが。
デバッガ使えばすぐにどこが悪いか分かるだろう。
519:デフォルトの名無しさん
08/05/05 02:07:10
>>513
使ってるよ
520:デフォルトの名無しさん
08/05/05 10:36:36
BIAS::Vector3<double> v=hoge();
と
BIAS::Vector3<double> v;
v=hoge();
を繰り返し呼ぶと答えが違う
c++の行列計算はもうublas以外信じねえわ
521:デフォルトの名無しさん
08/05/05 23:55:15
>>520
x86では普通
522:デフォルトの名無しさん
08/05/06 00:06:58
どうせ80ビットで計算するならlong double残しといてくれって話だよな
523:デフォルトの名無しさん
08/05/09 12:04:20
VBやVCから使えるDLLで、2枚の画像を半透明合成できるものってあるかなあ・・・
524:デフォルトの名無しさん
08/05/09 13:17:07
今から作れば？
おやつ前にはできるだろ。
525:デフォルトの名無しさん
08/05/09 13:27:29
作れないザコのゴミレス程、存在価値のないものはないなｗ
>>523
mDibでググれ
526:あいちゃん
08/05/09 13:29:30
2枚の画像の半透明合成って、対象の画像を1bitずつ交互に描画していくだけじゃだめなの？
527:デフォルトの名無しさん
08/05/09 13:33:27
半透明のコードぐらいググればすぐ出てくるじゃん。
528:デフォルトの名無しさん
08/05/09 14:33:44
本件に関しては、DLLを探して使い方調べているより自分で作った方が早い
に一票
529:デフォルトの名無しさん
08/05/09 14:36:44
>>524=528
作る技術もないのにエラソーにｗ
530:デフォルトの名無しさん
08/05/09 14:40:23
いくらなんでもそれはスキル低すぎだろ。
DLL作ったことありませんとか、BMPの扱い方が分かりませんのレベルか？
531:あいちゃん
08/05/09 14:42:29
えらそーにしてるのは>>529だと思います！！
532:デフォルトの名無しさん
08/05/09 15:09:34
>>529
10行程度のプログラムに「作る技術」もないだろ
533:デフォルトの名無しさん
08/05/09 16:01:11
煽ればムキになってコードが返ってくる
と思ってるくさい
534:デフォルトの名無しさん
08/05/09 18:08:28
口だけのやつばっかだなｗ
>>532
10行程度なら書いてみな？ 無理だろほーらばかｗ
535:デフォルトの名無しさん
08/05/09 18:23:43
普通にググったらソース出てくるのに。もうアホかと。
536:デフォルトの名無しさん
08/05/09 18:29:08
>>533
大正解
おめでとう
537:523
08/05/09 18:39:14
>>525
ありがとう
538:デフォルトの名無しさん
08/05/09 18:39:45
>>535
ソースがあれば何でもできると思っている基地外発見ｗｗ
539:デフォルトの名無しさん
08/05/09 18:42:02
どんだけスキルないねん。ここム板やで。
540:デフォルトの名無しさん
08/05/09 18:45:32
普通にググったら詳細な説明も出てくるのに。ゆとりか？
541:デフォルトの名無しさん
08/05/09 18:46:59
>>537
おまえのせいで荒れてるのに、不自然なんだよ。
自演してんじゃねー、ボケ。
542:デフォルトの名無しさん
08/05/09 18:47:46
>>537
どういたしまして
543:名無し募集中。。。
08/05/09 21:31:00
あるふぁぶれんど?
544:デフォルトの名無しさん
08/05/09 22:06:40
ちょっと上の方でも出てるので便乗で。
現在様々なブレンドモードに多対応させるため、いろいろ組んでるのですが、
通常のアルファブレンドの部分でどうしてもエッジが黒ずんでしまいます。
合成前のイメージはGDIなどで貼り付けた場合は黒ずまないので補間処理が
間違っている訳ではないみたいなのですが…
byte tb;//前景色(青)
byte t;//背景色
byte ta;//前景のアルファ
(((tb - t) * ta) >> 8) + t
これを各色回してるのですが、どこを間違っているのでしょうか?
545:デフォルトの名無しさん
08/05/09 22:21:15
>>544
それbyteじゃ駄目だろう。
あとαが0～255なのに、256で割ったら駄目だろう。
546:デフォルトの名無しさん
08/05/09 22:33:23
>>545
byteは演算式の中ではintに自動格上げされるから問題ないだろ
547:デフォルトの名無しさん
08/05/09 22:36:33
>>545
回答ありがとうございます。
byteは引き算が入ると自動的にintにアップキャストされるはずですが…
αを256で割るのはどこのページを見ても256で割ってるor8ビットシフトしてる
のであってるのかと思いましたがそうではないのでしょうか?
とりあえず、変数をdoubleにし、255で割ってみましたがだめでした orz
548:デフォルトの名無しさん
08/05/09 22:39:52
元画像が前乗算済みARGBになってたりはしないよな？
GDI+で言うPixelFormat32bppPARGB
549:デフォルトの名無しさん
08/05/09 22:41:10
アルファが正しいかどうか疑うべきだな
550:デフォルトの名無しさん
08/05/09 22:50:25
>>548
それはないです。ちゃんとPixelFormat32bppArgbとなっています。
>>549
αはGDIで合成したときは黒ずまないのであってると思いますが…
一応補間部分の式も載せておきます。
byte c1, c2, c3, c4;//各ピクセルの色
byte c1a, c2a, c3a, c4a;//各ピクセルのα
float px, py;//位置
float pp = px - Math.Floor(px);
float qq = py - Math.Floor(py);
float ip = 1 - pp;
float iq = 1 - qq;
float a = (ip * ((iq * c1a) + (qq * c3a))) + (pp * ((iq * c2a) + (qq * c4a)));
float c = ((ip * ((iq * c1 * c1a) + (qq * c3 * c3a))) + (pp * ((iq * c2 * c2a) + (qq * c4 * c4a)))) / ta;
こんな感じなのですが…
551:デフォルトの名無しさん
08/05/09 23:08:12
>>550
cの計算でα掛けちゃってるのが悪いんじゃないか？
552:デフォルトの名無しさん
08/05/09 23:28:23
>>551
元々cでアルファは掛けてませんでしたが、その頃からすでに黒い線は
出ていたので、αを掛けてる例もあったので試してみましたが… orz
553:デフォルトの名無しさん
08/05/10 00:09:48
んー、どういう画像を元にして、処理後どうやって表示したとき変に見えるのか、とかちゃんと書こうぜ。
554:デフォルトの名無しさん
08/05/10 00:33:26
>>553
画像は32bitARGBな画像で、背景がα=0でないとき、重ねるイメージを0.5px移動や回転など
で1px未満でずれたイメージのエッジ部分が黒ずんで見えます。
0 0.33 0.67 1 (px)
│
└─┐
│←こことか 重ねたイメージ
└─┐
│←こことか
└─┐
背景 │
└─...
上の0 < x < 1の部分が黒(灰色?)っぽくみえます。
555:デフォルトの名無しさん
08/05/10 00:40:23
上の図は画像ではこんな感じです。
0 0.33 0.67 1 (px)
│
├───┐
│//////////│←こんな風に黒っぽく
│//////////│
│//////////│ 重ねたイメージ
│//////////│
│//////////│
└───┼─...
│////
背景 │...
556:デフォルトの名無しさん
08/05/10 00:48:30
お前それ、もしかしてバイリニアの色漏れ・・・・
αと関係ないだろ・・・・・・・・・・・・・・
557:デフォルトの名無しさん
08/05/10 01:39:34
>>556
マジすか orzorzorz
でもなぜ変形後のイメージをGDIで重ねたときは黒っぽくならないんだろ…
558:デフォルトの名無しさん
08/05/10 01:53:08
ＧＤＩ描画でちゃんと補完モードはバイリニアになってるか？
いいから一回描画する画像のαが0のピクセル全部を緑色とかにしてやってみろ。
今度は暗くならず緑色が出てれば間違いなくバイリニア補完での色漏れ。
559:デフォルトの名無しさん
08/05/10 02:10:59
>>558
やってみました。
GDIの補間はバイリニアになってますが、暗くならず、ちゃんと緑になってます。
ただ、自前のバイリニアだと暗くなってます orz
しかも、もっとキモイ事に32bitPNGで保存したときは黒ずみが消えているという…
何をしたWinForm orzorz
560:デフォルトの名無しさん
08/05/10 02:29:44
けっ、どとねと使いか・・・
説明わかりにくいし、状況小出しだし、もうめんどう。
後は自分でがんばりや。
561:デフォルトの名無しさん
08/05/10 03:02:22
先ほど書き出したPNGをPsで見たところ、エッジの部分のαが背景と重ねたイメージが
255なのに対して、少し減っている事がわかりました。
やはりアルファブレンドの処理で何かやらかしていたようです。
>>560
とりあえず原因がつかめたのでどうにかなりそうです。
長々とおつきあいいただきありがとうございました。
//どとねとってどこ行っても嫌われてるのは何でだろう?
562:デフォルトの名無しさん
08/05/10 03:59:36
>>561
補間一つ取っても、どんなアルゴリズムで実装されているのかわからないメソッドなんかがあるから嫌われる。
# なんだよ「『HighQuality』BiCubic」って……
563:デフォルトの名無しさん
08/05/10 11:16:12
>>562
字面通りに捉えれば、BiCubicの高精度版ってだけなんじゃね？
小数点以下の有効桁数の問題なのでは。
564:デフォルトの名無しさん
08/05/10 11:23:07
それにしては違いすぎているから、多分そうじゃない
565:デフォルトの名無しさん
08/05/10 13:11:56
それってﾄﾞﾄﾈﾄじゃなくてGDI+じゃないの？
566:デフォルトの名無しさん
08/05/10 14:41:37
>>565
ﾄﾞﾄﾈﾄのはGDI+のラッパーだからﾄﾞﾄﾈﾄにもあるよ
567:デフォルトの名無しさん
08/05/10 16:38:40
.NET使いのやつには、まず自分の知識不足、理解不足を疑う必要があるのに、WinFormのせいにするような輩が多いからだよ。
まずは自分を疑えと。話しはそれからだ。
568:デフォルトの名無しさん
08/05/10 17:02:31
それはC++でもJavaでもPHPでも同じだと思うけど？
569:デフォルトの名無しさん
08/05/10 19:04:41
>>566
だから>>562は「どとねとってどこ行っても嫌われてるのは何でだろう?」への回答としては不十分だって話だろ
570:デフォルトの名無しさん
08/05/10 21:02:36
VC、VB屋でもDLLだけ欲しがる奴もいるし、
コード張ってくれなきゃ逆切れする奴もいるし、
.net屋だからというのは偏見だと思うな。
571:デフォルトの名無しさん
08/05/10 23:19:53
自分のプライドを守るために卑しむわけです。
572:デフォルトの名無しさん
08/05/11 01:40:54
イラストと写真を判定したいのですが
よい基準ありますか
573:デフォルトの名無しさん
08/05/11 01:47:20
>>567
それ.NET使いに関係なくどの言語・基盤技術上でも底辺プログラマには共通
574:デフォルトの名無しさん
08/05/11 02:48:29
イラストの写真
575:デフォルトの名無しさん
08/05/11 03:21:59
アイドルマスターは実写。
576:デフォルトの名無しさん
08/05/11 05:37:40
>>572
勃起したらイラスト
萎えたら写真
俺の基準
577:デフォルトの名無しさん
08/05/11 06:02:53
>>572
もう釣りにしか見えないけど、自分が絶対断れない立場でこれをやれといわれたら
光の分布をチェックすると思う。方向ならなおよし。
578:デフォルトの名無しさん
08/05/11 07:15:59
>>577
詳しく
写真から3Dモデルを作るくらい難しい？
579:デフォルトの名無しさん
08/05/11 07:57:02
イラストを写真に撮ったのはどうすんの
580:デフォルトの名無しさん
08/05/11 08:22:41
イラストだけならイラスト
額が映っていたり遠近法で歪んで見えると実写だろ
3DCGは？
581:デフォルトの名無しさん
08/05/11 08:50:42
実写に手を加えたものは？
582:デフォルトの名無しさん
08/05/11 09:25:43
属するクラスの選択によって結果が違うだろうな。
両方やって妥当なほうを選択するだろうから
手を加える割合によるんじゃね。
583:デフォルトの名無しさん
08/05/11 10:52:48
完全に汎用なのかどうかにもよるが、画像の特徴抽出をいくつか実装して、
インターネット上に転がっているイラストや写真をどんどん喰わせて出力、
抽出されたパラメータを眺めて相違点を取り出し実装するのが一番現実的
じゃないか？
有意な相違点がなかったら？ それは区別できないってことだ。
584:デフォルトの名無しさん
08/05/11 15:56:53
輪郭線
585:デフォルトの名無しさん
08/05/11 17:09:36
>>579
これらのスレを有効活用してくれ
ｽﾚﾘﾝｸ(erocg板)
ｽﾚﾘﾝｸ(erocg板)
586:デフォルトの名無しさん
08/05/11 18:03:27
>>583
だろうなあ。
今、2割誤判定する方法をふたつ作ったので
こういうのを増やしていってAdaBoostなんかで繋げばいいのかな。
>>584
イラストは縁取りがある判定は一番初めにやったがダメだった。方法がダメなのかもしれないけど、
(1). 微分フィルタでエッジを出す
(2). 暗い色、または鮮やかでない色を抽出
(3). 3近傍内に(1)がある場合、3均衡内に(2)がある割合を求める
ってしたが、縁取りが無いイラストがあったり、あっても縁取りの色がイラストによってまちまちなのと
写真もエッジが出るあたりは暗くなっているので単純に暗い色でやるとうまくいかなかった。
まずは、イラストで縁取りされている輪郭線の色特徴からかな・・・。
587:デフォルトの名無しさん
08/05/11 18:42:55
コンピュータで書かれているイラストなら
色の変化が機械的に整っている。
588:M1
08/05/11 20:50:55
大学院で3次元の画像認識・理解をやろうと思ってるのですが、お奨めの参考書とかありませんか？
ネットで調べると情報は多くあるが内容は少ない。参考書探そうとすると参考とできる書籍自体がない(´･ω･｀)
学部ではOpenCVで画像処理やってました。機械の制御の研究室なので、誰も当てにできないヽ（ ´Д`）ﾉ;
589:デフォルトの名無しさん
08/05/11 21:12:20
コンピュータビジョン (単行本)
David A.Forsyth (著), Jean Ponce (著)
590:デフォルトの名無しさん
08/05/11 21:48:51
>>588
論文嫁
591:デフォルトの名無しさん
08/05/11 21:49:51
2chよりは、論文探してその人にメールした方が確実だな。
592:デフォルトの名無しさん
08/05/12 01:44:46
この分野は進歩が激しいので教科書より論文とかプロシーディングだろうな。
593:デフォルトの名無しさん
08/05/12 08:40:24
>>586
個々の判定方法の出力をうまいことひとつにまとめることが出来るなら、
その出力を利用してどちらかを判定する部分に、学習を行わせるツールを作成するといいよ。
面倒だったら、いくつか初期設定した後、どちらかがはっきりしている
１０００枚くらいの画像を利用して、ＧＡで境界値（または値の分布表）を
収束させると、うまくいくときは楽でいいだろう。ＧＡ部分の作成はたいした手間でもないし。
あとは勝ち残ったアルゴリズムに未知の画像を分類させて、分類に利用する既知の画像を
増やしていくことで、１０万枚くらいまでデータを増やせれば、代表的な画像の判定なら
かなりのところまで精度を上げられると思うよ。それ以上は難しいだろうが。
594:デフォルトの名無しさん
08/05/12 08:42:14
>>588
そういう大学で、大学院があるなら、画像研究をやってる研究室があるだろ。
そこにいって相談するのが一番早い。
ないなら、教授のつてで他大学の研究室を紹介して貰え。
縦割りの大学に将来はないぞ。
595:デフォルトの名無しさん
08/05/12 10:34:01
>>594
自宅警備員が偉そうに大学語るなよ（笑）
596:デフォルトの名無しさん
08/05/12 10:48:01
>>588
cinii辺りで検索してみれば？
597:デフォルトの名無しさん
08/05/12 14:05:34
>>593
その程度で難しいって・・・スキル低いやつだなｗｗ
598:デフォルトの名無しさん
08/05/12 14:29:39
>>597
日本語よく読めよ
599:デフォルトの名無しさん
08/05/12 17:43:56
言い訳ｗｗｗ
知識を無理に披露しようとした>>523かな。乙ｗ
600:デフォルトの名無しさん
08/05/12 18:29:24
>>513
>>519
boost.gil何に使ってます？
601:デフォルトの名無しさん
08/05/12 21:50:24
オカズに使ってます
602:M1
08/05/13 12:28:28
>>589-594
レスthx！やっぱ論文とか他の研究室あたるしかないようだな・・・
>>589
\14,000・・・・
図書館に申請か・・・・・
ﾏﾝﾄﾞｸｻ('A`)
603:デフォルトの名無しさん
08/05/13 18:54:38
ImageMagickで、24bit-BMPを8bit-BMPに変換したいのですが、
どうすればいいか分かる方いらっしゃいましたら教えてくださいm(__)m
604:デフォルトの名無しさん
08/05/13 19:28:50
>>603
URLﾘﾝｸ(www.ss.iij4u.or.jp)
こういう感じ？。
605:デフォルトの名無しさん
08/05/13 22:36:38
何のために減色したいのか知らないけれど、ファイルサイズを気にしているなら小さい画像だと逆効果なので要注意。
8ビットカラーBMPはパレットカラーだからパレットサイズが馬鹿にならない罠。
606:デフォルトの名無しさん
08/05/15 10:06:12
スレ違いの謗りを免れないが、教えてください。
jpeg で圧縮後のサイズを指定できるという書き込みを見かけて、最近また
そういうのができるといいと思い出して、やり方を探しているが分からない。
quality 指定の説明しかない。サイズ指定って出来ないですよね。
607:デフォルトの名無しさん
08/05/15 10:56:48
作るとしたら、DCTを済ませておいて
予め用意しておいた複数の量子化テーブルで圧縮試行を繰り返す、みたいな感じになるのかな・・・
608:デフォルトの名無しさん
08/05/15 11:36:45
ハフマン符号化があるから、処理前にサイズを求めるのは難しいね。
Qualityとファイルサイズの関係はだいたいどの画像も同じような曲線になるから
近似関数を求めておいて、適当なQualityで圧縮してから逆算してみるとか。
単純に二分探索でも良さそうだが。
609:デフォルトの名無しさん
08/05/15 14:16:55
QRコード画像を作りたいけど
どう作ればいいか載ってるサイトか本ありますか？
610:デフォルトの名無しさん
08/05/15 14:28:45
はい。
611:デフォルトの名無しさん
08/05/15 14:41:02
【2次元コード】QRコード総合スレ３【バーコード】
ｽﾚﾘﾝｸ(phs板)
612:606
08/05/15 15:35:57
>>607-608
ありがとうございました。
613:デフォルトの名無しさん
08/05/15 15:54:12
>>606-608
ファイルの話で、どうしても指定サイズ丁度にしたいのなら、
圧縮した後、非圧縮部分を付け加えて指定サイズにするのが簡単だ。
614:612-606
08/05/15 23:23:52
>>613
写真のJpegデータをトリムした後、Exif ヘッダ内に埋め込まれた２つの画像
データも更新して置こうと思っているのだが、小さい縦横の画像のJpegデータ
を作ると、そのサイズが大きくなって、Exif ヘッダに収まらない。（で今は
収まらなければ Exif 形式を諦めている。デジカメではうまく収まるように
よく作っているもんだと感心している。）
615:デフォルトの名無しさん
08/05/16 17:20:31
画像データの余白部分を指定した幅にしたいのですが、
どうすれば、できるのでしょうか。
画像データが複数ありバッチ処理できると良いのですが。
具体的には、
画像データの空白（白色）以外の部分に外接する四角形と
画像データの外周との幅が、指定された値になるよう、
余白部分を切り取ったり、追加したりする機能です。
よろしくお願いします
616:デフォルトの名無しさん
08/05/16 17:28:09
スレ違い
617:デフォルトの名無しさん
08/05/16 18:13:01
Visual C++を使って画像ビューアを作成(bmp・jpegが表示でき、色調・コントラスト機能が実装できるもの)したいのですが、どうしたらよいでしょうか？？初心者なので何から手を付けていいのかもわかりません。環境はVisual studio 2005です。よろしくお願いします。
618:デフォルトの名無しさん
08/05/16 18:17:48
開発環境のスレできけ
619:デフォルトの名無しさん
08/05/16 18:29:15
ImageMagick でいいんじゃね。
620:デフォルトの名無しさん
08/05/16 18:38:15
>>618
スレ違いでしたか、失礼しました。
>>619
ImageMagicとは何でしょうか？
621:デフォルトの名無しさん
08/05/16 18:40:57
ゴミ
622:デフォルトの名無しさん
08/05/16 19:51:55
聞く前にググらないとか有り得ないし100%釣り
623:615
08/05/16 20:52:18
>>616
スレ違いですか。申し訳ありません。
ググるキーワードか、お薦めスレ等を教えて頂けると幸いですが。
よろしくお願いします。
624:デフォルトの名無しさん
08/05/16 21:59:20
>>617
Express EditionならGDI+を使えばJPEG、TIFF、BMP、PNGを
読み込むことができる。
Standard以上でMFCが使用できるならCImageクラスを使用するなど
できますよ。
625:デフォルトの名無しさん
08/05/16 22:57:30
>615
Photoshopでアクション（SelectAll ->領域をshrink->領域反転->削除）を設定し、フォルダごと適用すればいいのでは。
>617
OpenCVのサンプルコードにあったと思う。とりあえずOpenCVインストールして、あとはそちらのスレへ。
626:デフォルトの名無しさん
08/05/16 23:53:42
>>624さん>>625さん、ありがとうございました。
627:615
08/05/17 11:09:43
>>625
レスありがとうございます。
今現在は理解できませんが、勉強いたします。
628:デフォルトの名無しさん
08/05/17 11:38:51
>>625
＞Photoshopでアクション（SelectAll ->領域をshrink->領域反転->削除）を設定し、フォルダごと適用すればいいのでは。
これだとデータを削ることになるジャマイカ。>615の目指すところとは違うと思うぞ。
629:デフォルトの名無しさん
08/05/17 11:57:04
何をしたいのかはっきりしないけど、
Photoshopアクション（カンバスサイズの拡張->上下左右20ピクセル）だと、元画像を削らない。
630:デフォルトの名無しさん
08/05/17 12:05:12
もう一度読むと、何がしたいのかなんとなくわかった。
もともとある程度の白枠があるわけね？
それなら、アクション（位置（０，０）を許容値０で自動選択->削除->カンバスサイズの拡張->上下左右20ピクセル）。
631:デフォルトの名無しさん
08/05/17 13:54:36
板違いもいいとこだ。自分でプログラム書けば簡単だろ。
632:デフォルトの名無しさん
08/05/19 16:22:24
フーリエ記述子から振幅スペクトルと振幅スペクトルの2乗であるパワースペクトルを求めると何の役に立つん？
振幅スペクトルって2次元ベクトルを足して1次元にしてるだけにしか見えないんですがー
633:デフォルトの名無しさん
08/05/19 17:20:11
はじめまして。
すごく初歩的なことをお尋ねします。
CMYKカラーのJpegファイルには、解像度（dpi）情報は含まれていないのでしょうか。
RGBカラーの場合は、取得することができているのですが・・
634:デフォルトの名無しさん
08/05/19 18:23:30
そもそも、RGBカラーのJPEGなんてあったっけ?
635:デフォルトの名無しさん
08/05/19 19:54:25
>>633
とりあえず、そのファイルをうｐしてみろ
636:デフォルトの名無しさん
08/05/19 22:09:40
>632
フーリエ記述子って知らんけど、フーリエ変換からのアナグラムと同じだと考えると、
振幅とパワースペクトルとの違いは位相成分なので、起点が違うんじゃね？
パワースペクトルだけだと形の同一性しか分からないけど、位相まで含めれば向きが特定できるとか。
637:デフォルトの名無しさん
08/05/22 19:43:11
>>600
かなり亀レスだけど研究に使ってる
638:デフォルトの名無しさん
08/05/22 21:45:40
>>634
あるよ。規格上は。
現物のファイルでは見たこと無いな
639:デフォルトの名無しさん
08/05/22 23:40:41
epsの入出力に対応して欲しい＞gil
640:デフォルトの名無しさん
08/05/23 06:32:39
.NET Framework 1.1 の C# で実装しています
Bitmapクラスに画像イメージを作成・編集し
Bitmap.Save にて Tiff フォーマットを指定して保存しています
この時に Tiff が圧縮された状態で保存されてしまうのですが
無圧縮での保存は可能なのでしょうか
よろしくお願い致します
641:640
08/05/23 07:27:32
>>640 です
EncoderValue.CompressionNone
を指定する所までは行ったのですが、実行すると圧縮されている・・・
642:デフォルトの名無しさん
08/05/23 07:40:14
スレ違い
.NETスレに池
643:デフォルトの名無しさん
08/05/23 07:49:35
無圧縮TIFFくらい自分で書けば?
644:デフォルトの名無しさん
08/05/23 17:18:34
>>643 = NEET
645:デフォルトの名無しさん
08/05/23 18:45:59
>>644
まだコード書けないのか。おまえ何でム板にいるんだ？
646:デフォルトの名無しさん
08/05/23 22:14:52
>>644
647:デフォルトの名無しさん
08/05/23 23:20:15
>>646
>>645
648:デフォルトの名無しさん
08/05/24 01:29:24
>>648
649:デフォルトの名無しさん
08/05/24 06:13:08
また、自分でコード書けないいつものバカが暴れてるのか。
650:デフォルトの名無しさん
08/05/24 10:37:07
ぼかしの高速化について質問です。
現在ガウスぼかしの処理を書いてるのですが、640x480範囲5で1枚あたり0.5秒もかかって
しまい、非常に遅いです。一応1次元に落としてはいるのですが、重み付きぼかしの場合、
通常のぼかしのように処理済みのピクセルの結果を流用することができないため、どう
計算量を減らすのかわかりません。
SSEも見様見真似で使ってみましたが、アルファ加重なしで40%高速化、ありではSSEなしと
同じ速度でした。これはたぶん書き方が悪いのだとは思いますが…
なにか参考になるところ、もしくは検索キーワードをいただければうれしいです。
よろしくお願いします。
651:デフォルトの名無しさん
08/05/24 10:48:04
例えば5x5ピクセルを参照して1ピクセルの値を求める場合。
計算上問題がなければ、縦5ピクセルx横1ピクセルの加重平均を横一列分計算して、
次にその結果の横5つを加重平均するようにすれば多少は処理を減らせる。
まあ、それでもぼかしって基本的に参照するピクセルが多くなりがちだからそうそう高速化は。
652:デフォルトの名無しさん
08/05/24 11:07:40
>>650
具体的に、0.5秒かかっているときのカーネルの大きさ（or ガウシアンの標準偏差）はどれくらい？
653:デフォルトの名無しさん
08/05/24 11:10:32
GPU使っちゃダメ？10倍以上速くなると思うけど。
654:デフォルトの名無しさん
08/05/24 11:20:24
質問です。
例えば下のような図があったときに、１～１１のそれぞれ領域を、
隣接する他の領域と異なる色で塗り分けるプログラムを作りたいのですが、
各領域の色を決定するアルゴリズムにはどういうものがありますか？
〈｀ｰ─-､＿ノ＾j
｀> ＜＿＿, ─-､＿_＿_
／ j /￣￣￣Tー‐─┬''⌒ヽー-- ､
r' /､ １ / | ５ | ７ | |９
└---─､ / ｀ ｰ─/ ３ | │ | ｌ |
＼ / / ┌┴─‐─┴┐ / ８ ｌ |
＼ / ２ /ｰ─ ----l ６ |‐┤ ｌ |
Ｖ / ４ └─‐─┘ | ｌ |
し个 ､ / | ﾊ〈
| ｀ ーl─‐┬─----------─┬─ｲ´￣ヽヽヽ
| ／ヽ | | ﾊ 〉 〉 〉
| / | | | / │ / 〈ノ
| | | | | / | /
__/ | __/ |１０ __/ | __/ |１０
(＿＿」 ﾞー-‐' ﾞー-‐'(＿＿_」 人
（＿_）
（＿＿）１１
655:デフォルトの名無しさん
08/05/24 11:24:56
宿題は自分で考えましょう
656:650
08/05/24 11:54:39
>>651
とりあえずそうしているのですが、その結果が0.5秒です orz
>>652
5です。 10だと約1秒でしたので、カーネルサイズと比例関係になっていると思います。
>>653
GPUですか…
DirectXは全くさわったことがないのでそこから始めなければならないんですよね… orz
もしGPUを使うとしたらシェーダは自分で書かなければならないのでしょうか?
657:デフォルトの名無しさん
08/05/24 12:12:57
GPUはCG言語から扱えるのでは
658:デフォルトの名無しさん
08/05/24 12:15:13
CgよかBrookGPUの方がよくね？
いっそCUDAかCAL使うのも手だけど。
659:デフォルトの名無しさん
08/05/24 12:15:32
ageちゃったｽﾏｿ
660:デフォルトの名無しさん
08/05/24 12:29:26
URLﾘﾝｸ(tpot.jpn.ph)
速度比較のお試し程度ならこれで十分じゃない?自分で理解できた方が良いけどさ。
661:650
08/05/24 12:49:23
うーん、できれば古いPCでも動くように作りたかったのですが、計算量はこれ以上減らせる
見込みはないのかな… 周りとの平均をとる以上無理か orz
>>657,658
やっぱり自前でシェーダ書かなければ無理ですよね orz
というか、かなり大きめの画像(HD以上)も扱えるようにしたいのですが、テクスチャ作れますかね?
>>660
ありがとうございます。
見た感じなんかCとはちょっと違いますね。
大きくは違わないけどCのノリで行ったら痛い目見そうだ
662:デフォルトの名無しさん
08/05/24 13:07:29
単に広範囲をぼかすだけなら小さめのガウスぼかしを複数回かける手もある。
クォリティ下げていいなら移動平均にすれば大きくぼかしても負荷ほとんど増えないが。
663:デフォルトの名無しさん
08/05/24 13:18:35
広範囲で極端な精度を求めないならパスカルの三角形を繰り返してやれば
擬似ガウシアンだよな。
664:デフォルトの名無しさん
08/05/24 13:21:08
そのくらい単純な処理の場合、計算量を減らすよりも
キャッシュのヒット率を考えた方が速くなると思うよ。
665:デフォルトの名無しさん
08/05/24 13:24:31
OpenCVのガウスぼかしはCPUにしてはわりと速いと思う
666:650
08/05/24 17:51:01
遅くなってすいません。
>>662
移動平均ということはモーションブラーのようにちょっとずつずらして
いくつも重ねてレンダリングするということでしょうか?
>>663
調べてみましたが、これも良さそうですね。 あんまり見た目も変わらないですし。
>>664
基本的に全部のピクセルを順番に走査するのであまり変わらないような気もしますが…
そこまでキャッシュミスするものなのでしょうか?
>>665
OpenCVですか。 言葉は聞いたことがあるのですが、どんなものなのでしょうか?
ちょっと調べてみます。
667:デフォルトの名無しさん
08/05/24 18:27:49
ぼかしは、計算時間かかるから、0.5秒なら妥当だと思うけど。
ちなみに、ガウシアンカーネルをコンボリューションしているの？FFTしてから掛け算しているの？
一般的に、前者は遅い。
ぼかしくらいで、OpenCV導入することはないと思うけど、OpenCVのブラーはたぶん後者。
３次元でブラー掛けた時、FFT２回分の時間と同じくらいだった気がするので。
668:650
08/05/24 19:13:06
>>667
>>651のように縦横別々に分けて掛けてます。
この方法だとO(2n)になるのでFFTよりは速い(たしかO(nlogn)だったと思うので)のでは
ないかと思うのですが、どうでしょうか?
いろいろ試したところ、通常のぼかしやカーネルの小さいガウスぼかしを重ねがけするのが
結果的にも時間的にもいい感じなのでもうちょっと調べてみます。
669:デフォルトの名無しさん
08/05/24 19:44:02
>>668
その方法ではせいぜいO(n^2)までしか行かない
縦横別々にFFTを使うほうが効率がいい
670:650
08/05/24 20:23:25
>>669
マジっすか orz
手元にFFTの乗った教科書があるのでちょっと見てみます。
…2^nのみじゃないといいなw
671:デフォルトの名無しさん
08/05/24 20:26:42
教科書みるよりOpenCVのソース見たほうが速くない?
用途にもよるけどAvisynthのフィルタもいろいろな処理のソースあるよGPLだけど。
672:デフォルトの名無しさん
08/05/24 20:34:06
FFTはFFTWを使うとして、係数を事前計算しておけばガウス暈しは(周波数空間像の)画素ごとに係数を掛けるだけなんだっけ?
673:デフォルトの名無しさん
08/05/24 20:34:19
畳み込みの勉強をすればいいかも
674:デフォルトの名無しさん
08/05/24 20:58:54
ちょこっと書いてみた所
Window Sizeは5×5
Pentium-4 2.4GHzで640×480、24ビットカラーで70ms
同8ビットグレイスケールで20ms
コンパイラはVS.net 2003 ProのC++でSSEもアセンブラもなし最適化は/G6
実数演算しているので整数演算にすればもう少し速くなると思う。
このくらいの速度はでるという参考にでも。
675:デフォルトの名無しさん
08/05/24 21:05:34
>>650の実行環境すら分からない状態で、0.5秒が遅いという本人の印象だけで
実装アルゴリズムもソースも、言語すら書かれていないというのに、
どうしてこんなに速いだの遅いだの言う話が進むのか。みな超能力者なのか。
とおもたよ。
676:デフォルトの名無しさん
08/05/24 21:07:59
理論的な早さは実行環境によらず語れるじょん？
677:デフォルトの名無しさん
08/05/24 21:17:20
>>675
「遅い」と言われたら、だいたい原因の想像がつくからだよ
678:デフォルトの名無しさん
08/05/24 21:29:29
>>676
速さ、な。
650が現状どの程度計算量を減らす手段をとったのか正しくわからない状態では、
適切な助言はできないだろ。もしかしたら、環境が遅いだけで650は最速に近い
アルゴリズムを実装しているのかもしれないぞ。
いずれにしても、ワークを直接ポインタで操作しているという前提で、汎的な工夫なら、
1.640x480なら、650x490のワークを利用することで境界判定をなくして
2.１次元化して座標からのアドレス計算を減らして
3.平均化も縦横個別に１次元化して(>>651)
4.必要な精度にもよるが適当でいいなら固定小数点化して整数演算に帰着させる
くらいしかないんじゃないかな。
679:650
08/05/24 21:40:10
FFTのソースやら説明を読んでたら頭が爆発しそうになりました。
ろくに数学をやってないのに手を出すべきじゃなかったかもしれません orz
>>674
(ﾟДﾟ)
>>675
ソースが糞だからだと思います。
しかし、自分も糞なので糞が直しても糞にしかなりません。
>>678
現在は2と3をやってます。
1はコピーに時間がかかりそうですが、コピーはしないのでしょうか?
680:デフォルトの名無しさん
08/05/24 23:58:56
FFTは別に理解していなくても、使えればいいよ。
（気持ちに余裕があるときクーリ＆ターキの大発明を理解したらいい。元はガウスだっけ？）
FFTは特にFFTWくらい高速なものになると理解困難。
サイズによってアルゴリズム変化するらしい。
使い方もちょっと特殊。
ま、何も考えずに使いたければ、OpenCVにIPL組み込むことだ。ボカシ命令実行するだけで、すべてやってくれる。
681:デフォルトの名無しさん
08/05/25 01:12:20
8bit インデックスカラー画像を、さらに可逆圧縮する方法は無いでしょうか？
汎用的な圧縮アルゴリズム以外で。
682:デフォルトの名無しさん
08/05/25 01:21:48
誰かエスパーいたら、相手にしてやれよ
683:デフォルトの名無しさん
08/05/25 03:08:35
>>681
自分で考えれば良いんじゃない？
これだけじゃ、これぐらいしか回答できない
PNGにデータを保存すれば良いんじゃない？
可逆圧縮だし、8bitデータも扱えるし
何も意識せず、保存したいならGDI+で良いと思うよ
アルゴリズムも気にする必要もない
684:デフォルトの名無しさん
08/05/25 08:17:15
>>681
BMPで画像サイズが小さいなら、24ビットにした方が小さくなる。
685:デフォルトの名無しさん
08/05/27 09:41:00
お勧めのTIFFからJPEGに変換ツール教えてください。
JavaServletから使いたいです。
686:デフォルトの名無しさん
08/05/27 11:39:52
ImageMagick
Serveletから使えるかはしらね。
687:デフォルトの名無しさん
08/05/27 13:18:56
>>686
いいですね！
688:デフォルトの名無しさん
08/05/28 10:11:21
おまいら、YYフィルタってどうよ？
689:デフォルトの名無しさん
08/05/29 19:00:05
アホクサ20年前のレベルやん
690:デフォルトの名無しさん
08/05/29 23:44:57
>685
普通に、SDKのクラス使えばできる。
java 画像変換でぐぐれ！
691:デフォルトの名無しさん
08/06/01 02:28:32
shape context ってわかる人いますか？
URLﾘﾝｸ(en.wikipedia.org)
概念はわかったけど、このshape context histogramがどう作られてるのか
さぱーりわかりません。
Step 2: Computing the shape context
のところ。
692:デフォルトの名無しさん
08/06/01 16:47:50
vine4.2でImageJをインストールしているんですが、
□□□など文字化けが起こるのですがいい解決方法がありませんか？
693:デフォルトの名無しさん
08/06/01 19:15:22
フォント指定してないからだろ
694:デフォルトの名無しさん
08/06/01 20:35:15
それは一般に豆腐と呼ばれる現象なのでググるとなんかわかるかもね
695:デフォルトの名無しさん
08/06/02 21:01:37
>>691
まるかいてー、角度でわけてー、半径でわけてー、
その半径のわけかたはー、log っぽくてー、
で、点の数をかぞえるー
696:デフォルトの名無しさん
08/06/03 00:46:49
百戦錬磨の職人の皆様、教えてください。
アドビのフォトショップにある フィルタ...変形...渦巻き と同じことをやりたいです。
画像端部はそのままで中心部のみをネジる感じです。
URLﾘﾝｸ(charaku.maxs.jp)
しかしマッピング曲線がよくわかりません。
URLﾘﾝｸ(ja.wikipedia.org)
にある「リチュース」というのを使うのでしょうか？
697:デフォルトの名無しさん
08/06/03 01:12:48
>>696
中心からの距離に比例して回転角度が変わるだけ。
698:デフォルトの名無しさん
08/06/03 01:19:26
マッピング「曲線」とか言ってる時点で根本的な部分で勘違いしている気がする。
699:デフォルトの名無しさん
08/06/03 08:43:47
画像輪郭抽出アルゴリズムの話なんだけど
微分値を拾う方法以外の方法で何か有名な方法ってありますか
有用な方法で思い当たる方法もあったら教えてください
700:デフォルトの名無しさん
08/06/03 09:24:31
領域分割してラベリング後に境界をとったら？
やりかたはたくさんある。
701:デフォルトの名無しさん
08/06/03 10:51:20
>>699
微分にもいろいろあるだろうけど、
ほかにも、ぼかし＋HPFとか、ウェーブレットでHH成分を拾うとか、色相変化をチェックするとか、
702:デフォルトの名無しさん
08/06/03 13:02:43
レベルセットの簡単なtutorialどこかにないですか？
703:デフォルトの名無しさん
08/06/03 13:40:36
そういえば
先日サイエンスに視覚神経がポジ画像ネガ画像を同時に送ってるってのがあったな
あといくつかの他のいわゆるレイヤーを同時に脳に送りつけてるって
この方式は輪郭抽出や画像認識で既に使われてるのかな
704:696
08/06/04 00:25:16
>>697 さん
いや、それがですね、中心距離への比例だと思ってやってたんですよ。
周辺から中心にいくにしたがって回転角をまわしてやるようにつくっても、
フォトショップのような自然な渦巻きにならないのです。
>>698 さん、あえて「曲線」と言わせていただきますが、
再マッピングに曲線式をあてはめると、なんらかの減衰項があるような感じなのです。
昨日からずっと調べてたのですが、クロソイド曲線をつかうのかなぁ？
705:デフォルトの名無しさん
08/06/04 00:36:14
じゃあ２乗とかちょっと微調整やるってかんじじゃないのかな。
自然ってのは自分が思うまで微調整やるしか
706:698
08/06/04 01:08:30
>>704
Photoshopが何をやっているかは、
↓のような画像を渦巻き変形してさらに「極座標を直交座標に」の変換をすれば一目瞭然。
┌──┰──┐
│ ┃ │
│ ┃ │
│ ┃ │
│ │
│ │
│ │
└────┘
回転角度が中心に向かって単純に比例ではなく、
1 - sin(πx/2) に比例していることがわかる（0≦x≦1 は中心からの距離）。
つまり中央付近ではほぼ等速変化だけど、周縁では無変換領域と滑らかにつながるようになっている。
リチュースやクロソイドでは中心付近で回転が加速していくので描画効果としては使い物にならない。
707:デフォルトの名無しさん
08/06/04 09:09:53
もし704が問題なんだったら対数螺旋のような動きにしてみたら如何かな
708:デフォルトの名無しさん
08/06/04 13:41:23
単なる係数と補間精度だけの問題のようなきがする。
709:名無し募集中。。。
08/06/04 18:49:03
>>707
対数螺旋も中央付近で加速していくからフォトショップのようにはならないよ。
696氏はフォトショップの渦巻きフィルタの再現をしたいんでしょ？
フォトショップは中央は一様螺旋で周囲だけ緩和がかかるから>>706が正しい。
710:デフォルトの名無しさん
08/06/04 18:59:38
妥協すれば全て解決。100%コピー目指すなら逆アセしろ。
711:デフォルトの名無しさん
08/06/05 15:10:37
いろんな言語使ってる人いるみたいだけどrubyな人はいないみたいだね
712:デフォルトの名無しさん
08/06/05 16:31:59
エスパー乙
713:デフォルトの名無しさん
08/06/06 00:39:11
>>771
画像処理をしだしてからCばっかりでPerlとかは使わなくなった。
画像解析自体をスクリプト言語でやったりするんやろか
714:デフォルトの名無しさん
08/06/06 00:55:17
多段のフィルタを組み合わせたりするのにLL使うのはいいだろうけど、
画像処理自体に使うのはちょっと‥‥ねぇ
715:デフォルトの名無しさん
08/06/06 01:08:41
exe を走らせるスクリプトとかなら (*´･ω･)(･ω･｀*)ﾈｰ
716:デフォルトの名無しさん
08/06/06 08:55:57
pythonはPILあるけどrubyはそれに相当するものないから使われないってことなのか
717:デフォルトの名無しさん
08/06/06 09:09:15
スクリプト言語は文字列処理が得意なのであって、
画像処理、行列処理、をさせようと思ったら特に意味がない。
718:デフォルトの名無しさん
08/06/06 14:10:18
文字列は配列を切って貼ってする必要があるけど、画像処理はとってきた特徴量を
放り込んでおくだけってイメージ
719:デフォルトの名無しさん
08/06/06 14:21:27
ハァ？
720:デフォルトの名無しさん
08/06/06 16:08:10
>>695
分ける前の半径ってどうやって決めてるん？
曲座標変換が関係してるんかな？
721:デフォルトの名無しさん
08/06/06 17:43:54
あー、半径は自分で適当に設定するのか
722:696
08/06/15 10:37:03
>>697さん、>>698さん、>>705さん、>>707さん、>>708さん、>>710さん
「渦まき」できました！ありがとうございました。
723:デフォルトの名無しさん
08/06/15 10:45:13
どういたしまして
724:デフォルトの名無しさん
08/06/19 02:14:13
MPEG-7のデータセットをgoogleで探していたら
IEEEのサイトに飛ばされることが多いのですが、アカウントをとらないといけないのですか？
725:デフォルトの名無しさん
08/06/19 02:28:34
あ、これかな・・・
URLﾘﾝｸ(www.m4if.org)
726:デフォルトの名無しさん
08/06/22 17:47:13
H.264の実装説明した奴ないですかね？
727:デフォルトの名無しさん
08/06/25 12:06:43
x264のソースを落とした上でmarumoんとこでも読んで来い
728:デフォルトの名無しさん
08/06/26 21:12:02
画像センサや画像処理装置のスレって無い？
729:デフォルトの名無しさん
08/06/26 22:03:13
ハードは板違い
730:デフォルトの名無しさん
08/07/02 12:21:59
>>728
俺も探してるんだが無いね。
できたらCognexのVisionProとかﾘﾝｸｽのHalconだとかの情報も欲しいんだが・・
731:デフォルトの名無しさん
08/07/02 23:52:26
ImageMagick使ってPostScriptの回転・マルチページ化したいんだけどラスターデータみたいなガタガタの画になってしまう…
所詮こんなもんって事？
最終的にはPDFファイルにしたいんだがいきなり頓挫気味です。
732:デフォルトの名無しさん
08/07/03 09:13:39
displayだのconvertだのimportだの無遠慮に使い潰すこのゴミが
733:デフォルトの名無しさん
08/07/04 01:15:23
画像認識で自転車を認識したいのですが、どのように認識させていいのかわかり
ません。
今は自転車の簡単な特徴点をテンプレートととして用意してその点を認識させよ
うとしているのですが
なかなか認識させることができません。（テンプレートは自転車の車輪を想定し
て円状に点を６点取っています。
うまく自転車を認識させる方法がありましたら教えてください。