4

私は、産業問題のための画像処理ベースのソリューションを実装することを考えています。

画像は赤い長方形で構成されています。その中に、円のマトリックスが表示されます。要件は、次の制約の下で円の数を数えることです。(実際のアプリケーション:ボトルケーシング内のボトルの数を数えます。不足しているボトルはありますか?)

  1. 操作にかかる時間は非常に短くする必要があります。
  2. 赤い長方形も検出する必要があります。私の目的はパッケージ内のアイテムを数えることであり、カメラをトリガーするメカニズム(センサー)はありません。したがって、カメラは写真を継続的にキャプチャする必要がありますが、プログラムには不要な画像を破棄する方法が必要です。
  3. 処理はリアルタイムである必要があります。
  4. 画像キャプチャに「ノイズ」がある可能性があります。円の代わりに楕円が表示される場合があります。

私の質問は次のとおりです、

  1. 与えられたシナリオに一致する最良のエッジ検出アルゴリズムは何ですか?
  2. エッジ検出以外に使用できるメカニズムはありますか?
  3. 私が使用する言語とシステムのパフォーマンスの間に大きな影響はありますか?
4

6 に答える 6

8

ああ、あなたは今、ボトルが固定された場所にあると私たちに言いました!

それは信じられないほど簡単な問題です。

あなたがしなければならないのは、12のスポットのそれぞれを見て、そこに黒い領域があるかどうかを確認することです. これほど簡単なことはありません。

エッジや形状の検出をまったく行う必要はありません。

それはとても簡単です。

次に、ボックスが回転する可能性があり、物が揺れる可能性があることを指摘しました。ボックスが少し (または、毎回 0 から 360 まで、かなり) 回転する可能性があることは、非常に簡単に対処できます。ボトルが「スロット」に入っているという事実 (揺れていても) は、問題の性質を大きく変えます。主な問題 (これは簡単です) は、新しい赤い四角形 (クレート) がカメラの下の中央に配置されるまで待機することです。元の質問の文で、文字通り、具体的に「マトリックス」を意味していることに気付きました。無秩序なごちゃまぜの円を見つけるのとは対照的に、それはすべてを完全に変えます。ブロブが 12 点のうちの 1 つで「オン」になっているかどうかを調べることは、「画像内の円を識別する」こととはまったく異なる問題です。おそらく、質問を締めくくるために画像を投稿できます。


最後に、以下のケニーが最善の解決策を特定したと思います:ブロブ分析.


「ボトルケーシング内のボトルの数を数える」...

個々のボトルは「スロット」に収まりますか? つまり、各ボトルに 1 つずつ、4x3 = 12 の穴があります。

つまり、12 個の穴のそれぞれにボトルがあるかどうかを「判断するだけ」で済みます。

あれは正しいですか?

もしそうなら、あなたの問題は「どこでも」ボトルの山というより一般的な問題よりも信じられないほど簡単です.

簡単に言えば、ボトルはどこから見えるのでしょうか。上面、側面、底面、または? 常にトップ/ボトムが表示されますか、それとも混在していますか (つまり、トップからテールにパックされています)。これらの問題は、非常に大きな違いを生みます。

于 2010-11-06T20:05:42.517 に答える
3

この場合、Surf/Sift = やり過ぎです。確かにそれは必要ありません。

リアルタイム速度 (800x600 画像で約 20fps+) が必要な場合は、Cuda を使用して、 sobelなどの標準フィルター スキームを使用してエッジ検出を実装し、2 値化 +画像クロージャーを実装して、円のエッジが分離されないようにすることをお勧めします。

最も難しい部分は、円をフィッティングすることです。これは、エッジを取得し、イメージ クロージャ (モルフォロジー) を使用してそれらが接続されていることを確認するステップに既に達していることを前提としています。この時点で、次のように進めます。

  1. ブロブ分析/接続コンポーネントを実行して、接触していない円をセグメント化します。円が接触できる場合、次のステップはトリッキーになります
  2. 接続されたコンポーネント/ブロブごとに、リアルタイムで実行できるRANSACを使用して円または長方形を当てはめます(リアルタイムで実行するのが非常に難しいと私が信じているハフ変換とは対照的です)。

ステップ 2 は、円を形成する接続コンポーネントを個別にセグメント化できない場合、はるかに困難になるため、その条件を保証する方法についてさらに検討する必要があります。

幸運を。

編集

もう少し考えてみると、円連結成分が接触する場合はRANSACが最適な気がします。RANSAC は、仮想的に円を連結成分の一部のみに適合させる必要があります (大部分が外れ値の点の場合に適切に機能するため)。これは、適合した円が連結成分全体を包含するかどうかを確認する追加のチェックを追加できることを意味します。コンポーネントを再実行し、そうでない場合は、除外された接続コンポーネントの部分で RANSAC を再実行します。すすぎ、必要な回数だけ繰り返します。

また、私は円と言っていますが、RANSAC を使用して円の代わりに楕円を簡単に適合させることができます。

また、CUDA が適切な選択であると言うときは、ソーベル フィルター + 二値化 + 画像のクロージングを実装するのに CUDA が適切な選択であることを意味します。コネクテッド コンポーネントと RANSAC はおそらく CPU に任せるのが一番ですが、GPU が CPU よりもこれらの 2 つにどの程度の利点をもたらすかはわかりませんが、それらを CUDA にプッシュしてみることができます。

于 2010-10-05T16:51:34.510 に答える
2
  • 円については、ハフ変換を試してください。
  • 他のメカニズム:dunno
  • コンパイルされた言語はおそらくより高速になります。
于 2010-10-05T11:30:50.773 に答える
1
  1. 色の合計+境界を検出する凸包。ほとんどの場合、長方形の4つの角が必要ですが、辺ではありませんか?
  2. 動きがなく、セカンドカメラがなく、選択肢が少ない-わずかな入力(色ヒストグラム、色分布行列)に対する多くの数学手法。ダンノ。
  3. Java ==高いメモリ消費量、Lisp ==高い脳消費量、C++==メモリ/CPU/速度/脳の使用が最適です。
于 2010-10-05T11:34:13.557 に答える
1

SIFTは、円形のオブジェクトに対して非常に優れた応答を示すはずですが、特許を取得しています。GLOHも同様のアルゴリズムですが、すぐに利用できる実装があるかどうかはわかりません。

実際、さらに調査を行うと、SURFは SIFT の改良版であり、かなりの数の実装が利用可能です。wikipedia ページのリンクを確認してください。

于 2010-10-05T11:39:29.690 に答える
1

コントラストが良好な場合、ブロブ分析がジョブのアルゴリズムです。

于 2010-11-06T20:34:04.833 に答える