981コメント239KB

画像処理その14

■ このスレッドは過去ログ倉庫に格納されています

0001デフォルトの名無しさん

2013/06/02(日) 19:51:03.12

画像処理プログラミングについて質問、議論を行うスレッドです
・画像処理について素人同士で大激論
・初学者の質問に対してやさしく(的を外れた)解答を与える
・その道の玄人も大歓迎

前スレ
画像処理その13
http://toro.2ch.net/test/read.cgi/tech/1301896601/

0153デフォルトの名無しさん

2013/11/28(木) 05:28:49.59

>>152
spider

0154デフォルトの名無しさん

2013/11/28(木) 20:18:24.89

失敗だぁ

0155デフォルトの名無しさん

2013/11/28(木) 23:46:29.72

spiderなんて20年前のfortranライブラリだろ。ちょっと探したけどダウンロードサイトないし。
C++でないかなぁ。ImageMagicとか使ったことある人いたら感想教えて

0156デフォルトの名無しさん

2013/11/29(金) 00:23:35.93

使ったことないしきっとゲロ遅いけどGDI+

0157デフォルトの名無しさん

2013/11/29(金) 00:30:15.11

ほーGDI+でアフィン変換なんて出来たんだ
昔jpgとpng読むのに使ったきりだった

0158デフォルトの名無しさん

2013/11/29(金) 01:06:40.16

GDI+なら信頼出来るというのか

0159デフォルトの名無しさん

2013/11/29(金) 05:27:03.69

ImageMagickはDLLでもアプリでも使っているけど、
フォーマット変換やテストデータ作成やデモ画面作成にしか使ってないなぁ。
アフィン変換やランツォシュ補間もあるなら使ってみるかな。

0160デフォルトの名無しさん

2013/11/29(金) 22:34:48.05

信頼できないなら自分で書けボケッ
使えるのか使えないのかまず検証しろッ

0161デフォルトの名無しさん

2013/11/30(土) 00:32:27.82

自分で書いた教科書的なバイリニア補間のアフィン変換はMATLABの結果とほぼ一致したけど、OpenCVのは一致しなかったよ。
見た目にはわからないけど、数値的には画素値がひと桁台だけどかなり違った。バイキュービックはMATLABとOpenCVだけの比較だけど同様に異なる。
とりあえずOpenCVは速度重視で精度を犠牲にしてるのはわかった。

もっと高度な補間方式も実装したいけど、教科書的な実装でいいんかね？信頼性が高い実装があるならそれを利用したい。

0162デフォルトの名無しさん

2013/11/30(土) 00:58:07.18

速度重視というより実装がめちゃくちゃなんだよ
意味を成してないアルゴリズムがある

0163デフォルトの名無しさん

2013/11/30(土) 14:01:51.78

boost.GILはadobeが作ってたからいいものじゃないかな
まあ基準があってそこからの精度を重視したいなら自分で書くのがいいよ
画像処理ライブラリの需要は速度にあるから速度を優先しているものが多いし

0164デフォルトの名無しさん

2013/12/02(月) 13:37:27.40

GDI+で縮小したらなぜかカメラによってはドット欠けが発生した（等倍画像には無し）
縮小方法選べるけど遅くなりそうだし、面倒だから検証してないｗ

0165デフォルトの名無しさん

2013/12/02(月) 23:54:14.02

今輪郭追跡のプログラムを書いているんですが，
以下の領域の輪郭を正しく追跡できません．
何か良い方法はありませんでしょうか？

■■■■■■
■■□□□■
■□■□□■
■□■□□■
■■■■■■

■：背景
□：領域

メル欄のページを参考にしました

よろしくお願いします．

0166デフォルトの名無しさん

2013/12/03(火) 00:00:51.31

OpenCVを商用ソフトでも使いたがるやつ多すぎ
マゾいな

0167デフォルトの名無しさん

2013/12/03(火) 01:02:39.98

>>165
まずアルゴリズムや方法論の前に、どうゆう結果が欲しいのか・・・。
そこを明確にしたほうが、分かりやすくなると思います。

例えば >>165 の

■■■■■■　
■■□□□■
■□■□□■
■□■□□■
■■■■■■

とか

□■□■□■
■□■□■□
□■□■□■
■□■□■□
□■□■□■

という画像の場合、輪郭線はどのようになってほしいですか？

0168デフォルトの名無しさん

2013/12/03(火) 08:38:14.55

コーナーで左折するか右折するかの基準を決めて、どちかで通す

0169デフォルトの名無しさん

2013/12/03(火) 08:44:20.78

結果は

□□□□□□
□□■■■□
□■□■■□
□■□■■□
□□□□□□

と

■□■□■□
□■□■□■
■□■□■□
□■□■□■
■□■□■□

が良いですね

0170デフォルトの名無しさん

2013/12/03(火) 09:55:44.10

なんちゃそりゃ。

0171デフォルトの名無しさん

2013/12/03(火) 10:48:40.43

>>168
時計回りか反時計回りか
二股に分かれるところで左折するか右折するか
の基準を決めて、どちらかで通す。
Potraceでやっとった。ついでにアルゴリズムもパク

0172165

2013/12/03(火) 15:37:54.15

使用した方法では，スタート地点に戻ってきた時点で探索を終了してます．
８連結で以下のような結果がほしいです．

>>165の例は，左上から走査して，
①→②→③→②→①と来て，スタート地点に戻ってしまうため
④⑤⑥⑦⑧⑨を通らずに終わってしまいます．

■■■■■■　
■■①④⑨■
■②■⑤⑧■
■③■⑥⑦■
■■■■■■

0173165

2013/12/03(火) 15:40:27.56

>>167では
①→②→③→④→⑤→④→⑥→⑦→⑧
→⑨→⑩→⑪→⑫→⑬→⑭→②→①
という順で追跡できています．

①■⑭■⑫■
■②■⑬■⑪
③■□■⑩■
■④■⑦■⑨
⑤■⑥■⑧■

□：輪郭線に含まれない領域
■：背景
①～：輪郭線

よろしくお願いします．

0174デフォルトの名無しさん

2013/12/03(火) 16:12:49.87

終了条件を
開始点に戻ってきた　から
開始点に戻ってきて、次の候補点を挙げた場合に報告済みだった
に変えればよさそうだよもん

0175デフォルトの名無しさん

2013/12/03(火) 16:55:15.47

■の輪郭線は
　→
↑■↓
　←
じゃないんだ。いろいろな問題がおきそう旦那。

0176デフォルトの名無しさん

2013/12/03(火) 18:17:24.47

>>169
bit演算だけでできるレベルじゃん。

0177デフォルトの名無しさん

2013/12/04(水) 02:03:16.39

>>173
もう１つ確認なのですが。
追跡結果としてほしい情報は、輪郭線を表す２値画像ですか？
それとも、追跡した画素の履歴ですか？

例えば >>165 ↓の場合

□□□□□□
□□①④⑨□
□②□⑤⑧□
□③□⑥⑦□
□□□□□□

輪郭追跡の結果として

□□□□□□
□□■■■□
□■□■■□
□■□■■□
□□□□□□

と

①→②→③→②→①
④→⑤→⑥→⑦→⑧→⑨→④

では、どちらの情報が欲しいです？

0178デフォルトの名無しさん

2013/12/04(水) 10:19:39.33

「抽出」とかではなく「追跡」と呼んでいるから後者側なのかなと思うけど

■□■□■□
□■□■□■
■□■□■□
□■□■□■
■□■□■□

この場合って，何が「正解」なんだろうか？
斜めに繋がっている箇所が20箇所あるけど
その全ての繋がりが１回以上（最大２回までか？）含まれる
ループ経路を求めるということ？

0179デフォルトの名無しさん

2013/12/04(水) 11:28:09.36

どうでもいいが

■□■□■□
□■□■□■
■□□□■□
□■□■□■
■□■□■□

が正解らしい

0180デフォルトの名無しさん

2013/12/04(水) 11:30:53.58

ああ白黒逆か

■□■□■□
□■□■□■
■□■■■□
□■□■□■
■□■□■□

ってことじゃね

0181デフォルトの名無しさん

2013/12/05(木) 01:25:18.89

なんかもう画像処理とか統計・分析とか、如何に数学できるやつの独壇場か思い知らされた
その道の専門分野勉強しようと思っても数学できないと理解不能
高速フーリエ変換とか意味わからん、数式はGoogleに落ちてるがプログラムにおこせない

0182デフォルトの名無しさん

2013/12/05(木) 02:14:32.92

プログラムを拾ってきて、数式と見比べてみるのが理解の早道

0183デフォルトの名無しさん

2013/12/05(木) 04:39:21.16

>>181
つフーリエの冒険

0184デフォルトの名無しさん

2013/12/05(木) 05:59:53.59

FFTなんてfftwでも使えばいいだけじゃん。
数式の意味を理解する必要すらないよ。
数学ができないことよりも応用力のないほうが問題なんじゃね?

0185デフォルトの名無しさん

2013/12/05(木) 08:38:19.34

数学は教養だから、できないとまず入門書が読めないからな
ただ、実装したいだけなら線形代数と解析学の基礎だけ勉強すれば
論文で示される数式からコードに起こすことくらいはできるよ
実装は理論より高速に動作する数値計算のコードが書けることが重要だし

0186デフォルトの名無しさん

2013/12/05(木) 10:16:03.52

>>183
ネットショップで検索すると20年くらい前の版がたくさん出てるくのですが、大丈夫ですか？
（数式だから、変化することは無いでしょうがｗ）

0187デフォルトの名無しさん

2013/12/05(木) 11:21:24.86

>>181
もし本当に必要と思うならマセマでも勉強すれば

0188デフォルトの名無しさん

2013/12/05(木) 23:31:51.28

こんど仕事で画像解析やることになるんですが
OpneCVのようなライブラリ使う奴は低能みたいな空気があるのがいまいち理解できないんですが
数学の知識と大学等で専門的に学んでないとライブラリ無しじゃ何もできないですよね
目的は画像解析じゃなくてその先で手段にこだわる必要性ってあるんすかね？
FFTなんて自力で計算できる人なんてIT業界でもそんな多くないでしょうに・・・

0189デフォルトの名無しさん

2013/12/05(木) 23:35:14.95

OpenCVが糞ライブラリだからだよ
てか枯れてない分野をライブラリ化する意味があんまないし

0190デフォルトの名無しさん

2013/12/05(木) 23:39:07.41

ライブラリ使う奴は低能みたいな空気を出してライバルを牽制しつつ
自分はライブラリ使って出し抜くんだろ

そのくらい理解しとけ

0191デフォルトの名無しさん

2013/12/05(木) 23:55:29.44

ライブラリ使って出し抜く（笑）

0192デフォルトの名無しさん

2013/12/06(金) 00:02:13.22

低能かどうかはともかく
誰が書いても同じものをわざわざ書くというのは

よほどお暇なんですね
それともエンバグの練習をなされているのですか？

とコメントせざるを得ない

0193デフォルトの名無しさん

2013/12/06(金) 00:37:11.48

OpenCVで精度が出るならそれで済ませるよ。
つーか、OpenCVでプロトタイプを作るってのは普通。

＞FFTなんて自力で計算できる人
アルゴリズム本読んでもできないなら、絶望的な応用力のなさだ。

0194デフォルトの名無しさん

2013/12/06(金) 00:59:39.70

bmpの回転操作についてお聞きしたいのですが
１０回転させた後、undoしたい場合
（１）－１０回転させる
（２）１０度回転させる際に、完全なイメージを保存しておき、それと差し替える

（２）は簡単で確実undo出来るのですが、（１）の場合どうしても誤差が発生して
しまします。（Bilinear,Bicubic補完を行っても）

ラスタを扱う有名なアプリはどのようにしているかご存知の方いらっしゃいますか？

0195デフォルトの名無しさん

2013/12/06(金) 01:26:08.77

画像処理が主のアプリでundoするのに(1)はありえんわ。

0196デフォルトの名無しさん

2013/12/06(金) 01:36:49.17

っあ、すいません　度　が抜けてました
ご理解頂けてるとは思いますが。

0197デフォルトの名無しさん

2013/12/06(金) 01:46:47.50

(1)で完全に元に戻すような逆回転処理を書くことはそんなに難しくないかもしれないけど、そもそも回転してはみ出た部分をどうするのかとか、
そんなことをする意味があるのかってことで、(1)で元に戻らなくても普通は困らないと思うよ。Photoshopとかでも元に戻らない。
(1)で元に戻って欲しいのなら、どうして(1)を使いたいのかの理由を考えてみるべきだと思う。

0198デフォルトの名無しさん

2013/12/06(金) 01:51:28.53

アクションをバッファして処理の手続き数だけ戻せばいいだけだろ
画像処理とか関係ないだろwww

0199デフォルトの名無しさん

2013/12/06(金) 02:57:21.33

>Photoshopとかでも元に戻らない。

Undoしても元に戻らないアプリにみんな大金払ってるのか。

0200デフォルトの名無しさん

2013/12/06(金) 08:27:11.18

10回転してもイメージは変わらないのでは？
と思った

0201デフォルトの名無しさん

2013/12/06(金) 09:01:34.12

誤差ってなんだよ？
差し替えてんだから誤差になりようがないだろ

0202デフォルトの名無しさん

2013/12/06(金) 10:47:57.46

関係ありませんが丁寧語の質問って釣りに見えますよね？わたしだけ？

0203デフォルトの名無しさん

2013/12/06(金) 13:49:53.13

>>188
「俺には技術はないがアイディアがある」って人は、技術のある人は技術的知見に基づいたもっと良いアイディアを出せるかもって想像もしてみないのかね。
―― matz

0204デフォルトの名無しさん

2013/12/06(金) 16:20:54.13

変換後の画像をいちいちキューイングして undo 時は、画像そのもを差し替える
順変換/逆変換がある前提で undo時は　現画像に逆変換を通して元の画像(っぽい)ものに戻す

順変換と逆変換が完全可逆かどうかだな

0205デフォルトの名無しさん

2013/12/06(金) 16:41:07.82

早口言葉ですね。

0206デフォルトの名無しさん

2013/12/06(金) 18:58:27.01

まず完全に戻らないならundoではない
最大undo回数を設定に持っておいて
その個数分は描画アクションが完了する毎にスナップショットを保持するのが一般的な実装

0207デフォルトの名無しさん

2013/12/06(金) 20:09:09.57

ViEWの藤吉先生の講演聞いてた人がいたら要約頼む

0208デフォルトの名無しさん

2013/12/06(金) 20:57:04.96

>>188
・SURFとかSIFTの計算を自力でやってる人は少数派だと思うけど。
・工学分野だと「50億枚の画像を俺の手法を俺が実装したら20分で処理できた俺TUEEE」
　と言いたくなる（察しろ）場面があるのでOpenCV実装をナイーブに使ってると
　アホみたいに遅い場合俺TUEE実装だと数十倍数百倍というのは一つのウリになる。
　（とはいえOpenCVもどんどん更新されてるしGPGPUやMPIやらなんやらに対応してきてるので
　　そんなに差をつけるのは難しいんじゃねというのが僕の感想）。

画像解析のその先が問題なんだから、というのは大筋同意。
そのためのOpenCVでもあるしな。

0209デフォルトの名無しさん

2013/12/06(金) 21:06:16.35

OpenCVって世にあることの一部しかやってないから
どんなこともできるってライブラリじゃないし
だいたい自分で高速カーブレットを考えろとか言われたらFFTの中身知ってるほうが絶対有利だし、逆問題みたいに先行研究があるほうが珍しいことをやろうとしたときどうすんのさ。

0210デフォルトの名無しさん

2013/12/06(金) 22:06:55.28

>>209
SURFやSIFTを超えたいとかそういう研究するならOpenCVに頼りっきりじゃダメだろうね、確かに。

0211デフォルトの名無しさん

2013/12/06(金) 22:18:43.22

そういうのは研究室や研究所の高学歴エリートがやってるんでしょ？
私のような下々のPGには機会も予算も回ってきません
そんなのよりもエンドユーザーに喜んでもらえるソフトウェア作りたいですね私は

0212デフォルトの名無しさん

2013/12/06(金) 22:36:58.08

会社としては中小規模でもやるよ
IT系市場って業務系が極端にでかいから他の分野を専門にしてる会社は小さい

0213デフォルトの名無しさん

2013/12/06(金) 22:43:30.50

>>198
質問の意味がわからないなら黙っとけよｗ

0214デフォルトの名無しさん

2013/12/06(金) 22:43:43.31

業務系の会社が片手間に画像処理をやっているケースもなくはないな。

0215デフォルトの名無しさん

2013/12/07(土) 00:56:55.78

>>211
だったら絡んでくるなよ

0216デフォルトの名無しさん

2013/12/07(土) 01:31:48.14

医用画像とかだと色々あるで

0217デフォルトの名無しさん

2013/12/07(土) 06:41:38.92

画像処理に関しては、難しいものから簡単なものまで特許が多いんだよねえ。
特許が成立してるせいで製品に実装できないケースも多々あるので、
画像処理プログラム開発の仕事をしたい学生さんは、それなりの覚悟が注意かも

0218デフォルトの名無しさん

2013/12/07(土) 11:05:52.58

・画像特徴を前提として何かやりたい⇒OpenCVのSURFとか使ってればいい
・画像特徴の高速抽出や新手法の実装をしたい⇒OpenCVに頼りきりはありえない

そんだけ。画像解析はそれなりに伝統があるので「既存の部品」でそれなりの
事ができるようになっているが、既存の部品ではどうにもならないところも
まだたくさんある。やりたい事がやれてるかが大事であってどっちの立場を
とるかは大事じゃない。

0219デフォルトの名無しさん

2013/12/07(土) 11:20:23.18

猿でも思いつけそうなソフトウェア特許を撲滅しましょう

0220デフォルトの名無しさん

2013/12/07(土) 11:47:03.61

>>217
あー、それ思いました
日本語OCRもパナなんかのメーカーが特許持っててオープンソースないですもんね

0221デフォルトの名無しさん

2013/12/07(土) 11:48:31.89

特許なんてどれも子供の思いつきレベルだろ。

0222デフォルトの名無しさん

2013/12/07(土) 12:35:10.33

ドクター中松のイメージだね

0223デフォルトの名無しさん

2013/12/07(土) 13:00:47.07

>画像特徴を前提として何かやりたい⇒OpenCVのSURFとか使ってればいい
ありえねぇ。特徴を前提にやるなら結局どんな特徴量をつくるかも入るだろ
別は無理。

0224デフォルトの名無しさん

2013/12/07(土) 13:33:57.41

画像特徴を新しく設計したらそれが提案に値するすんばらしい特性を
持ってる事まで言わないと「しょっぼいオレオレ特徴なんかじゃなく信頼できる
SIFTを使わないのは何故ですか」とサド区で突っ込まれたときに何も言い返せない事を
わかってない学生かよ。

0225デフォルトの名無しさん

2013/12/07(土) 13:35:08.75

えぇっ！？

0226デフォルトの名無しさん

2013/12/07(土) 13:52:39.64

SIFTとか今時使ってるやつがそもそもいるの？
あんな糞遅くてたいした特徴量も出せないものを

0227デフォルトの名無しさん

2013/12/07(土) 13:57:57.60

じゃあみなさんフルスクラッチしてるんですね

0228デフォルトの名無しさん

2013/12/07(土) 13:58:29.23

これがゆとりか：224

0229デフォルトの名無しさん

2013/12/07(土) 14:00:49.68

>>227
GUIはライブラリ使ってる

0230デフォルトの名無しさん

2013/12/07(土) 14:01:22.38

古いアルゴリズムってお話にならないじゃん
SIFT（笑）

0231デフォルトの名無しさん

2013/12/07(土) 22:25:50.84

どんなテクスチャから特徴取りたいかによってdetector/descriptorは変えるべきだし用途も考えずアレは素晴らしいアレは糞だと言うのはよくない。

0232デフォルトの名無しさん

2013/12/07(土) 22:42:30.24

画像処理て進んでるの？とうにやりつくされてるかと思った。

0233デフォルトの名無しさん

2013/12/07(土) 22:45:30.26

１０年以上経つのにSIFTより性能高い特徴量出てこないしな

0234デフォルトの名無しさん

2013/12/07(土) 22:53:44.15

SHIFTて知らなかった。
擾乱には強いの？

0235デフォルトの名無しさん

2013/12/07(土) 22:59:28.87

テクスチャ？テクストンの話？

0236デフォルトの名無しさん

2013/12/07(土) 23:06:40.81

外部をカメラでとったときのいろいろなノイズ、パターン認識には難しかったはず

0237デフォルトの名無しさん

2013/12/07(土) 23:10:31.55

画像処理の論文は理想的な画像でやってるのばっかだから

0238デフォルトの名無しさん

2013/12/07(土) 23:34:33.22

俺の写真ではダメってことか。

0239デフォルトの名無しさん

2013/12/08(日) 00:08:40.68

理想的な画像ってなんだよｈｗ

0240デフォルトの名無しさん

2013/12/08(日) 01:30:08.98

OpenCVスレの前スレ
http://toro.2ch.net/test/read.cgi/tech/1329040627/
の700あたりでも話題になってたけど、結局、OpenCVとか既存のライブラリを使うことが意味あるかどうかってのの議論は、
人によって全然前提条件が違うから、決め付けで「そんなのありえない」だの「いや価値がある」だの言ってもしょうがないって感じだなあ。
大学で特許関係あんまり気にせずアプリケーションを作れるような状況なのか、それとも企業としてライセンス料を気にしなくちゃいけない状況なのか、
いままでのアルゴリズムでは実現できなかった性能を持ったやつを作りたいのか、ニコニコ動画で一発芸的に動画を公開できればいいのか、
人それぞれだし。
企業として金になるプロダクトが作れないという観点でOpenCVとかに価値がないって言うのは、それはまあ一つの価値観としては成り立つと思うけど、
ニコニコ動画に動画をあげるのに有効活用できるから価値があるというのも同様に尊重すべき意見だし。
プロの価値観が正しくて市井の日曜プログラマーの価値観は無意味ってこたーないよね。
ただ、齟齬が大きいから、前提をはっきりさせてから意見を表明しないと。

0241デフォルトの名無しさん

2013/12/08(日) 02:19:05.29

lenaを人として認識出来てもキモオタは人じゃないから

0242デフォルトの名無しさん

2013/12/08(日) 06:48:09.62

たくさんの画像セットで実験してみて一番良い結果が出るものを載せます

0243デフォルトの名無しさん

2013/12/08(日) 08:08:56.38

極端かも知れんがエッジが検出できれば認識は簡単という感じだったよーな
擾乱に対してはあまり進歩がないということね

0244デフォルトの名無しさん

2013/12/08(日) 08:21:57.27

前に対応点探索にはNRDCが有効て書き込んだんだがみんな知らないの？

0245デフォルトの名無しさん

2013/12/08(日) 10:59:41.18

>>243
ここ10年の進歩を知らないなら素人もいいところ

0246デフォルトの名無しさん

2013/12/08(日) 11:53:04.88

Natural Resources Defense Council

0247デフォルトの名無しさん

2013/12/08(日) 11:55:58.81

>>245
最近の話をしらないから聞いてるのだが

0248デフォルトの名無しさん

2013/12/08(日) 11:56:42.95

>>245
訂正　最近の進歩を教えて

0249デフォルトの名無しさん

2013/12/08(日) 13:35:27.30

>>246
Non - Rigid Dense Correspondence with Applications for Image Enhancement

0250デフォルトの名無しさん

2013/12/08(日) 13:56:57.95

境界線から良い特徴量つくれてるアルゴリズムって今のとこないだろ

0251デフォルトの名無しさん

2013/12/08(日) 15:04:47.67

ちなみにPhotoshopの自動選択ツールの性能ってどうなんですかね
みなさんからすればAdobeレベル低すぎwww俺ならもっと精密な特徴量作れるわwww
って感じですか？

0252デフォルトの名無しさん

2013/12/08(日) 19:05:14.80

何の話だ

■ このスレッドは過去ログ倉庫に格納されています

画像処理 その14

画像処理その14