問題タブ [orb]

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 の ORB 機能エクストラクタを使用していますが、ORB 記述子が保存されている奇妙な (少なくとも私にとっては) 方法に気付きました (基本的に、私の質問に関係のない変更を加えた BRIEF-32 です)。ご存じの方もいらっしゃると思いますが、ORB は変更された FAST-9 (円の半径 = 9 ピクセル。キーポイントの方向も格納します) を使用して抽出されたキーポイントを取得し、変更された BRIEF-32 記述子を使用して、キーポイントが表す機能を格納します。

BRIEF (ORB バージョン) は次のように機能します。31x31 ピクセルのパッチ (フィーチャを表す) を取得し、ランダムな 5x5 ピクセルのテスト ポイントの束を作成します。次に、それらのポイントのペアを取得し、それらの強度を評価して、ペアの最初のポイントの強度が 2 番目のポイントの強度より大きいか小さいかに基づいてバイナリ決定 (0 または 1) を行います。次に、これらすべてのビットを取得し、基本的な合計式を使用して、長さ n のバイナリ文字列を作成します (BRIEFT-32 の場合、32 バイト * 8 = 256 ビット長のバイナリ文字列があります)。

SUM(2 ^(i-1) *bit_pair_test)

ここで、bit_pair_test は、テスト ポイントのペアのテストから計算したビット値です。最終結果は次のようになります (一連のバイナリ テスト (...,0,1,0,1,1) の場合):

(2 ⁰ *1) + (2 ¹ *1) + (2 ² *0) + (2 ³ *1) + (2 ⁴ *0) + ...

OpenCV の ORB がこれらのビット文字列を格納する方法は、私にとって謎です。各行が 1 つのキーポイントの 1 つの記述子である画像全体の記述子を含むマトリックスを見ると、各記述子には 32 個の 8 ビットの数値が含まれていることがわかります。情報を保存します。256 ビットを 32 バイトに分割する理由がわかりません。公式ドキュメント ( http://docs.opencv.org/trunk/doc/py_tutorials/py_feature2d/py_brief/py_brief.html ) は、OpenCV がそのような記述子をバイト単位で格納するとのみ述べていますが、なぜそれを行うのかについては説明していません。これらのいくつかの組み合わせが答えになる可能性を排除することなく、3 つの可能性を検討しました。

• 見えない収納テクニック
• その長さのバイナリ文字列 (この場合は 256 ビット) のハミング距離を計算する際のパフォーマンスの問題
• マッチング プロセスの最適化 - マッチングは基本的に、1 つの画像のキーポイントの記述子を 2 番目の画像のキーポイントの記述子と比較します。バイナリ文字列があるため、ここではハミング距離が当然の選択です。どういうわけか、これらの 32 個の部分文字列のそれぞれが、2 番目の画像の他のキーポイントの記述子の対応する部分と比較される可能性があります (位置 0 の部分文字列 (キーポイント X、画像 1) と位置 0 の部分文字列 ( keypoint Y, image 2). 最後に、OpenCV は次のように言うかもしれません:「わかりました。すべての部分文字列の約 26 が両方の記述子で同じであるため、記述子の一致率は 80% であり、勝者がいます。」しかし、私はそれを確認する証拠を見つけることができませんでした.

PS: ORB に関する論文はこちらで、BRIEF に関する論文はこちらで読むことができます。

この 2 日間、openCV の ORB に関数を追加する方法を見つけようとしました。

パラメータを追加して現在の関数を変更する方法を理解しましたが、新しい関数を追加できないようです。

私の最終的な目標は、オーブ機能検出器を用意して、パブリック関数を呼び出せるようにすることです。

cv::Ptr p = new cv::OrbFeatureDetector() p->compute(~~) ;

次のような追加の関数を呼び出せるようにしたいと思います: p->doSomething();

これは、追加のファイル、名前空間などを作成することなく実行できますか?

または、従来のセッター/ゲッターのアプローチに固執する必要がありますか? -違いがある場合は、C++を使用して作業しています。

私は、さまざまな検出器/記述子の組み合わせをいじる小さな実験を行っていました。

私のコードは、特徴の検出に ORB_GPU 検出器を使用し、記述子の計算に SURF_GPU 記述子を使用します。BruteForceMatcher_GPU を使用して記述子を照合し、knnMatch メソッドを使用して一致を取得しています。問題は、多くの不要な一致を取得していることです。コードは、両方の画像で見つけることができるすべての機能に文字通り一致しています。私はこの行動にかなり混乱しています。以下は私のコードです（GPUバージョン）

図に見られるように、コードは何に対してもランダムな一致を与えています。通常のCPU機能を使用して同じことを試してみましたが、かなり正確です。CPUバージョンのコードは以下です

どんな助けでも大歓迎です。

このコードを使用して、ORB 特徴検出器を使用して 2 つの画像間の一致を見つけています。

私の問題は、一致をフィルター処理して、写真内の位置が似ている場合にのみ一致するようにする方法が見つからないことです。位置的に非常に離れていても、1 つのキーポイントに対して常に複数の一致が得られます。

それらをより適切にフィルタリングする方法はありますか？

ビデオのフレームに ORB OpenCV アルゴリズムを実行しようとしていますが、CPU バージョンが GPU バージョンよりもはるかに高速に実行されることに気付きました。コードは次のとおりです。

これを 3000 フレーム、解像度 720x480 のビデオで実行すると、GPU 時間は 54 秒、CPU 時間は 24 秒になります。他のビデオ (HD 以外) でも同様の結果が得られます。パソコンのスペック:

• i7-4770K CPU 3.50 GHz

• NVIDIA GeForce GTX 650

• 16GBのRAM

SURF などの他の機能検出/記述アルゴリズムは、私のマシンに GPU を実装すると高速に実行されます。

自分のマシンで ORB の 2 つの実装を比較した人はいますか?

CORBA サーバーが同時に処理できるクライアント要求の数を知りたいです。

1. サーバーは新しいクライアント要求ごとに新しいスレッドを作成しますか?
2. スレッドプールはありますか?
3. デフォルトのスレッド プール サイズは?
4. 最大サイズに達するとどうなりますか? 新しいスレッドはキューで待機しますか?
5. プール内の非アクティブなスレッド (クライアントに既に使用されているスレッド) のアイドル時間は?
6. これらのパラメータ (プール サイズとアイドル時間) を構成できますか?

私は多くの調査を行いましたが、Sun/Oracle の公式 CORBA 実装 (JDK) に関するこれらの質問に対する本当の答えは見つかりませんでした。Oracle ドキュメント (リンク) では、次のように表示 されます。

=> このパラメーターが実際に何であるかはわかりません。また、このパラメーターはすべての JVM と互換性があるわけではなく、デフォルト値は「1」です。

RMIには、デフォルトのスレッドプールサイズを変更するための「 sun.rmi.transport.tcp.maxConnectionThreads 」パラメーターがあることを知っています（これはすでに「無制限」です）。非アクティブなスレッドのアイドル時間は 1 分です... RMI は CORBA に触発されているため、Sun/Oracle はそれらの両方に同じパラメーターを設定するのでしょうか?

ありがとう