ららら一人旅

超お久しぶりです

Thu, 24 Feb 2022 02:04:36 +0900

このブログがあることを忘れていました。

5年くらい？放置していましたね･･･。

数か月前に仕事やめて忙しかったですが最近生活も落ち着いてきたのでまたコツコツ書こうかと。

ちなみにその時ちょっと面白かったブログがあったので貼っておきます。

【退職】実はクビ寸前だったかもしれないと気付いた話無事退職届が受理された安心した矢先、上司が書いていた所見がひどい内容だったのと、そう書かれた理由について過去の僕のとった行動を振り返りながら考察したことを書いています。chorsk-zatta.com

退職するときに周りになんか言われるのだるいですよねぇ。

続・外部パラメータの最小化アプローチ

Mon, 11 Apr 2016 01:37:45 +0900

つい先ほど、回転行列の最適化に成功しました～。

長かった・・・。

次は並進ベクトルの最適化なんですが、これもまたうまくいかない。

うーむ。

あ、参考資料は以下です。

非常に詳しく書いてあって、大変助かります。

誤字がちょこちょこあるので、じっくり読むのが良いです。

　3次元復元のためのバンドル調整の実装と評価： ttp://www.iim.cs.tut.ac.jp/~kanatani/papers/budjust.pdf

ま、回転行列よりは手こずらないと思いますけどね・・・。

外部パラメータの最小化アプローチ

Sun, 03 Apr 2016 22:59:15 +0900

まだまだ外部パラメータの最小化について調査中です。

調査していて、

何で論文によって最小化のアプローチがこんなにも違うのか？

と思ってしまった。

今は画像座標 (u,v) を独立で最小化しているのですが、ある論文では (u,v) を一括していたりするので・・・。

とりあえず、 (u,v) を一括して最小化する方向でコーディング中です・・・。

さてはて、どうなることやら。

アフィン変形対応完了！　が・・・

Thu, 24 Mar 2016 22:38:20 +0900

アフィン変形対応は何とか完了しました。

が、しかし！

今更になって外部パラメータの推定がおかしいことに気づいた。

原因を追究中・・・。これは根気のいる作業ですねぇ。

なーんかなー。

射影行列を最適化すると、Z軸に関わる部分だけおかしくなるんだよなー。

なんでだろうなー。

こんな感じで、1週間くらい迷走してます。

アフィン変形に対応したテンプレートマッチング

Wed, 16 Mar 2016 00:06:23 +0900

ちょっとお久しぶり。

ホモグラフィ行列の方は一旦落ち着いたんで、テンプレートマッチングについてお勉強中です。
(単に手詰まりなだけですけど)

テンプレートマッチングって、例えば工場ラインでカメラが上に付いていて物を発見する程度であれば

2時限的な回転がかかるくらいで高速かつ精度良く出来るわけですが・・・。

カメラが自由に動き回る状況では、スケールやら3次元的な回転がかかってくるわけです。

今それを苦心しながらコーディング中・・・。

結構めんどくさいなぁ。

ホモグラフィ行列推定について

Sun, 06 Mar 2016 00:58:57 +0900

この頃はもっぱらホモグラフィ行列に関してお勉強中です。

というのも、ロバストな特徴点追跡を実行するためには色んな条件をクリアしなければなりません。

以下のようなものも考えたり検証したりしましたが、

　①特徴量を使う　→　単体ではトラッキングではなく単なるマッチング(密な追跡が出来ない)

　②KLTトラッカーを使う　→　輝度差やノイズに弱い。
　　　　　　　　　　　　　　　　　　本来追跡失敗してても追跡を続けてしまう。

　③テンプレートマッチングを使う　→　処理は高速だけど、やっぱり回転に弱い・・・。

との見解に至ったわけです。

対して、ホモグラフィの推定は特徴量マッチングとKLTトラッカーを併用できるわけです。

ある程度は出来てきたものの、ホモグラフィ行列が結構振れるなぁ・・・。

変形量を制限する方法でもあるのかな・・・？

PROSAC その後

Mon, 29 Feb 2016 00:05:51 +0900

先日解析したPROSACをホモグラフィ推定に使用できるようにコーディングしてました。

ぶっちゃけ、期待したほどではない感じです。

もうちょっと高精度且つ高速になるのかなー、と思ったけどそうでもない。

まぁまだパラメータチューニングが出来ていないだけだと思ってます。

それでもRANSACよりも精度が上がったし、効果は間違いなくある。

ただサンプリングの性質上、全体的にある程度高品質なマッチング結果がないと高速化されないようで・・・。

ORBに高精度を求められてもな～。

Cascaded FAST 高速化

Wed, 24 Feb 2016 23:12:55 +0900

PROSACも一旦落ち着いたところで、特徴点抽出の高速化を図ってます。

「Cascaded FAST」とは何ぞや？の方は以下を御参照下さい。

ttps://www.google.co.jp/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjGx-f0ypDLAhWHj5QKHdooDuwQFggcMAA&url=http%3A%2F%2Fwww.vision.cs.chubu.ac.jp%2Fflabresearcharchive%2Fbachelor%2FB12%2FPaper%2Fhasegawa.pdf&usg=AFQjCNHHuNLFc2gIiJLQBuedmhDWiI3YqA&sig2=kFOe2udOhkZ3cBWDwQFvWg

現在は4枚のピラミッドイメージを構成し、それぞれから特徴点抽出を行っています。

2週間前くらいからちょこちょこ高速化を図って、160ms → 45ms くらいまでになりました。

これ以上は可読性を犠牲にしそうで嫌だなぁ・・・。

ここら辺で手打ちかな。

まだ続く？

PROSAC解析完了 & テスト

Sun, 21 Feb 2016 18:05:55 +0900

ようやくPROSACの解析が完了しました。

で、早速テストしてみました。

テスト内容は単純なもの。

y=x に従って200点を生成し、そこへ一定範囲の乱数で800点生成したものをあわせます。

プロット結果は以下のもの。

ここから2点を選択、直線の式のパラメータ(傾き、切片)を計算します。

計算されたパラメータから直線と全ての点の距離を計算し、一定以内の距離ならインライヤとします。

この処理を繰り返し、インライヤの数が最も多いパラメータを最終パラメータとして出力します。

とまぁ良くありがちなものですね。

以下に結果を載せます。

縦軸が処理回数、横軸がテスト回数となります。

尚、最大処理回数は1000回とし、テスト回数は100回としました。

また、RANSACの打ち切り判定は暫定インライヤ数が200を超えた場合としています。

ちょこちょこ1000になっているのは、推定に失敗した場合です。

なんだかよく分からないので拡大します。

ふむふむ。

ぱっと見た感じは

　　　RANSAC ：ときどきPROSACの処理より早いが、安定性に欠け、推定の失敗も見られる。
　　　PROSAC ：処理回数が安定しており、(今回のテストでは)推定の失敗がない。

ってところかな。

これはなかなか期待できそう・・・。

あ、ちなみに平均処理回数は

　　　RANSAC ： 18.49回 (1000回の場合を除く)
　　　PROSAC ： 5.01回

となました。

テンションあがってきた！

PROSAC解析中3

Thu, 18 Feb 2016 20:16:06 +0900

結構分かってきました、PROSAC。

①まず高品質の対応点(特徴量のマッチング具合が良いもの)を降順にソート。
　　　　　　　　　　　　↓
②高品質な点集合のみからランダムサンプリングし、評価を実行。
　　　　　　　　　　　　↓
③統計的に安全な基準を満たしながら評価(予定)回数を小さくしていく。
　　　　　　　　　　　　↓
④もし統計上のサンプリング平均回数を上回っているなら低品質の点集合からも
　　ランダムサンプリングする。
　　　　　　　　　　　　↓
⑤評価回数が予定数を上回る、もしくは設定されている何らかの基準(例えばインライヤ数)を
　上回るパラメータが見つかったら終了、それ以外なら②に戻る

すごく雑に説明ですけど、こんな感じです(よね？)

高品質なものを重点的に使えばいい結果がでるのは直感的に分かりやすいですし、

何より最悪でもRANSACと同じ処理負荷ということなので良いですね。

よく出来てると感心します。

・・・仕事あるのに夜更かししてしまった・・・。