問題タブ [keypoint]

BRISK を OpenCV での機能の検出と説明に使用すると、パフォーマンスの問題が発生します。

基本的に、この画像から取得したすべての記述子を一致させようとします。

特徴の検出と説明のために LSH アルゴリズムと BRISK を備えた flann ベースのマッチャーを使用して、画像のデータベースから取得したすべての記述子に対して。

私の画像データベースは 242 枚の画像で構成されています。この 242 枚の画像には、上記の「複雑な」画像クエリで別々に取得された各オブジェクトに対応する 3 つの画像があります。

BRISK 検出に使用されるパラメーターは次のとおりです (デフォルトの opencv パラメーター): しきい値: 30、オクターブ: 4、パターン スケール: 1.0。

ベスト マッチ手法 (イメージ クエリの各記述子は、データベース記述子のセット内の最も近い近傍に関連付けられています) を使用したフラン マッチングの後、私のアルゴリズムは、一致のパーセンテージで並べ替えられたデータベース イメージのリストを出力しました。最初の 4 つの結果は次のとおりです。

1. データベース内のボルトに対応する画像: 4 つの一致 / 15 の検出されたキーポイント => 一致率: 26.7%。
2. データベース内のボトルに対応する画像には 4 つの一致 / 15 の検出されたキーポイントがあります => 一致率: 26.7%。
3. データベース内のボルトに対応する画像には、10 件の一致 / 59 件のキーポイントが検出されています => 一致率: 16.9%。
4. 画像クエリに存在しないオブジェクトに対応する画像: 1 つの一致 / 16 の検出されたキーポイント => 一致率: 16.7%。

ORB を機能の検出と説明として使用して、この結果を比較しました。使用されるパラメーターは次のとおりです: フィーチャの数: 2000、スケール係数: 1.2、ピラミッド レベルの数: 8。

ここに私が得る結果があります：

1. データベース内のボルトに対応する画像: 576 一致 / 752 検出されたキーポイント => 一致率: 76.6%。
2. データベース内のボトルに対応する画像には、111 件の一致 / 189 件のキーポイントが検出されています => 一致率: 58.7%。
3. データベース内のペンに対応する画像には、124 の一致 / 293 の検出されたキーポイントがあります => 一致率: 42.3%。
4. 画像クエリに存在しないオブジェクトに対応する画像: 2 つの一致 / 66 の検出されたキーポイント => 一致率: 3%。

ご覧のとおり、結果は ORB ではるかに優れています。まず、データベース内の各画像でより多くのキーポイントが検出され、良好なオブジェクトの一致率が大幅に向上します。さらに、適切なオブジェクトの一致率と不適切なオブジェクトの一致率の差はより顕著です。

なぜ BRISK 検出器が ORB 検出器よりもはるかに少ないキーポイントを検出するのか疑問に思っています。BRISK 検出器でより多くのキーポイントを検出する方法を見つけるために、さまざまなテストを行いました (しきい値を下げ、オクターブ数を下げます)。確かにもう少し多くのキーポイントを検出できますが、ORB 検出器との違いは依然として非常に重要です。BRISK 検出器がこのような動作をする理由がわかりましたか?

私の OpenCV バージョンは 2.4.8 ですが、次のステートメントに従って、2.4.4 および 2.4.9 バージョンで BRISK 検出部分を試しました。

http://code.opencv.org/issues/2491およびBRISK 機能検出器は、改善なしでゼロのキーポイントを検出します。

また、ORB 検出器と BRISK 記述を組み合わせようとしました。マッチング結果は、最初の方法 (完全な BRISK) よりも優れていますが、2 番目の方法 (完全な ORB) よりも劣っています。

1. データベース内のボルトに対応する画像: 529 一致 / 708 検出されたキーポイント => 一致率: 74.7%。
2. データベース内のボトルに対応する画像には 69 の一致 / 134 の検出されたキーポイントがあります => 一致率: 51.5%。
3. データベース内のペンに対応する画像には、93 / 247 個のキーポイントが検出されています => 一致率: 37.6%。
4. 画像クエリに存在しないオブジェクトに対応する画像: 5 つの一致 / 50 の検出されたキーポイント => 一致率: 10%。

各画像で検出されたキーポイントの数は、方法 2 と方法 3 で同じではないことに注意してください。実際に、このコードをテスト画像 (ここではボルトの画像) で実行すると、次のようになります。

BRISK は、記述子で検出されたすべてのキーポイントを計算していないようです (ORB 検出器によって検出された 752 個のキーポイント => BRISK 記述子によって計算された 708 個の記述子)。

ただし、ORB によって検出されたすべてのキーポイントが BRISK 記述子で計算されていない場合でも。これらの結果から、BRISK は ORB よりもキーポイントを記述するのに適していないように見えますか? 間違っていたら訂正してください。

私の結果を理解するのに役立つ要素がある場合、または OpenCV で BRISK に関する問題を既に経験している場合は、お知らせください。どんな助けでも大歓迎です:)。

OpenCV KeyPoint のドキュメントによるとresponse、すべてのキーポイントに次のフィールドがあります。

float response: 最も強いキーポイントが選択された応答。

しかし、反応が大きいほど良いか悪いかわかりませんでしたか? キーポイントを並べ替えて、ベスト 20 だけを選びたいと思います。

キーポイントの検出、記述、およびマッチングのプロセスを研究し、実験を行うために数か月を費やしました。前回は、拡張現実の背後にある概念、正確には「マーカーレス」認識と姿勢推定にも興味を持っていました。

幸いなことに、この設定では以前の概念がまだ広く使用されていることがわかりました。基本的な拡張現実を作成するための一般的なパイプラインは次のとおりです。必要な各アルゴリズムの詳細は省略します。

ビデオをキャプチャしている間、すべてのフレームで...

1. いくつかのキーポイントを取得し、それらの記述子を作成します
2. これらのポイントと、以前に保存した「マーカー」(写真など) 内のポイントとの一致を見つけます。
3. 一致が十分であれば、可視オブジェクトのポーズを推定し、それで遊ぶ

つまり、たとえば、この学生 (?) プロジェクトで使用される非常に単純化された手順です。

ここで質問です。個人的な調査中に、「オプティカル フロー」と呼ばれる別の方法も発見しました。まだ研究の初期段階ですが、まずは以前の方法とどのくらい違うのか知りたいです。具体的には：

• その背後にある主なコンセプトは何ですか? 前に大まかに説明したアルゴリズムの「サブセット」を使用しますか?
• 計算コスト、パフォーマンス、安定性、精度の面での主な違いは何ですか? （これはあまりにも一般化された質問になる可能性があることを私は知っています）
• 商用ARツールでより多く使用されているのはどれですか? (ジュナイオ、レイヤー、...)

ご協力いただきありがとうございます。

私は画像処理とロボット工学のセルフプロジェクトに取り組んでおり、代わりにロボットが通常のように色を検出してオブジェクトを選び出し、ボード上の穴 (異なるポリゴンに似ている) を検出しようとします。セットアップをよりよく理解するために、次の画像をご覧ください。

ご覧のとおり、これらの穴を検出し、その形状を調べてから、ロボットを使用してオブジェクトを穴にはめ込む必要があります。深度画像を取得するためにkinect深度カメラを使用しています。写真を以下に示します。

カメラで穴を検出する方法を考えていませんでした。最初はマスキングを使用して、深度測定に基づいて背景部分と前景部分の一部を削除しましたが、これはうまくいきませんでした。穴はボードと合体します...範囲内のようなものです（完全に白くなります）。adaptiveThresholdそれから私は機能に出くわしました

浸食、膨張、およびガウスぼかしを使用したノイズ除去。下の写真に示すように、より良い方法で穴を検出しました。次に、cvCanny エッジ検出器を使用してエッジを取得しましたが、これまでのところ、下の図に示すようにうまくいきませんでした。その後、SIFT、SURF、ORB、GoodFeaturesToTrack からさまざまな機能検出器を試したところ、ORB が最高であることがわかりました。時間と検出された機能。この後、クエリ画像の相対的なカメラ ポーズを取得しようとしました。そのキーポイントを見つけ、それらのキーポイントを一致させて、findHomography関数に適切な一致を与えるようにしました。結果は、図のように次のようになります。

最後に、2 つの画像間の相対的なカメラ ポーズを取得し、solvePnP 関数から取得した回転および並進ベクトルを使用してロボットをその位置に移動します。

キーポイントの検出とマッチングのために検出された穴の品質を改善できる他の方法はありますか?

輪郭検出と approxPolyDP も試しましたが、近似形状はあまり良くありません。

しきい値とキャニー関数の入力パラメーターを微調整しようとしましたが、これは私が得ることができる最高のものです

また、カメラのポーズを正しくするための私のアプローチは正しいですか?

更新: 何を試しても、再現性のある優れた機能をマップすることができませんでした。次に、深度画像は解像度が低く、マスキングや距離の取得などにのみ使用されることをオンラインで読みました。そのため、エッジが乱雑な低解像度の画像のために、機能が適切ではないことがわかりました。そこで、RGB 画像の特徴を検出し、深度画像を使用してそれらの特徴の距離のみを取得することを考えました。私が得た機能の品質は、文字通りチャートから外れていました.ボード上のネジも検出しました!! GoodFeaturesToTrack キーポイント検出を使用して検出されたキーポイントは次のとおりです。. ポイントの距離がうまく出ず、距離をとっていくうちにまたハードルにぶつかりました。考えられる原因を検索したところ、カメラ間のオフセットが原因で、RGB 画像と深度画像にオフセットがあることがしばらくしてわかりました。これは、最初の 2 つの画像から確認できます。次に、このオフセットを補正する方法についてネットを検索しましたが、有効な解決策が見つかりませんでした。

あなたの誰かがオフセットを補うのを手伝ってくれるなら、それは素晴らしいことです!

更新: goodFeaturesToTrack 関数をうまく利用できませんでした。この関数は、Point2f タイプのコーナーを提供します。記述子を計算する場合は、キーポイントが必要です。以下のコード スニペットを使用して Point2f を Keypoint に変換すると、スケールと回転の不変性が失われます。

特徴マッチングの恐ろしい結果を以下に示します。

今すぐさまざまな機能のマッチングを開始する必要があります。さらに更新を投稿します。誰かがオフセットの問題を取り除くのを手伝ってくれると本当に助かります.

まず第一に、私はコンピュータービジョンの分野に不慣れで、現在問題に直面していると言わざるを得ません.opencv（Javaラッパー）で解決しようとしましたが成功しませんでした.

基本的に、カメラで撮影したモデルのパーツの写真 (さまざまな角度、解像度、回転など) があり、モデル内のそのパーツの位置を見つける必要があります。

例の写真:

モデル画像:

質問の 1 つは、どこから始めればよいか、どのアルゴリズムを使用すればよいかということです。

私の最初の試みは、SURF を検出器、記述子として、BF をマッチャーとして KeyPoint マッチングを使用することでした。10 枚中約 2 枚の写真で機能しました。デフォルトのパラメーターを使用し、他の検出器を試しましたが、改善はありませんでした。(おそらく、正しいパラメータの問題かもしれません。しかし、正しいアルゴリズムと組み合わされた正しいパラメータを見つけるにはどうすればよいでしょうか?...) 2 つの例:

私の2番目の試みは、色を使用してモデル内の特定の要素を区別し、構造をモデル自体と比較することでした（モデルの写真に加えて、モデルのxml表現も持っています..）。現在、画像から赤色を抽出し、h、s、v の値を手動で調整して、約 4 枚の写真で最適な検出を行いましたが、他の写真では失敗しました。

2 つの例:

また、幾何学的構造を検出するために、エッジ検出 (canny、gray、historym Equalization を使用) を使用しようとしました。私が想像できるいくつかの結果については、それはうまくいくと思いますが、他の写真に同じキャニーパラメーターを使用すると「失敗」します。2 つの例:

私が言ったように、私はコンピュータービジョンに慣れていないので、いくつかのアルゴリズムを試してみました. 私は、アルゴリズムとテクニックのどの組み合わせが最適なのか、さらにどのパラメーターを使用する必要があるのか​​ わからないという問題に直面しています。手動でテストすることは不可能のようです。

前もって感謝します

ゲモラ