これに外部ライブラリを使用する理由はまったくありません。この種のことを何度も行ってきましたが、次のアルゴリズムは非常にうまく機能します。2 つの画像を比較する場合、サイズは同じですが、そうでない場合はサイズを変更できます。
badness := 0.0
For x, y over the entire image:
r, g, b := color at x,y in image 1
R, G, B := color at x,y in image 2
badness += (r-R)*(r-R) + (g-G)*(g-G) + (b-B)*(b-B)
badness /= (image width) * (image height)
これで、2 つの画像間の正規化された悪い値が得られました。悪い値が低いほど、画像が一致する可能性が高くなります。これはシンプルで効果的です。特定のケースでより良くまたはより速く動作するようにするさまざまなものがありますが、おそらくそのようなものは必要ありません。悪さを正規化する必要さえありませんが、手動でいくつかの可能な一致を調べたい場合は、この方法で単一のしきい値を考え出すことができます。
この質問が注目を集めたので、多くの画像を何度も処理する場合にこれを高速化する方法を追加することにしました。数万の画像を比較する必要があり、典型的な画像のペアが大きく異なることがわかっていたときに、このアプローチを使用しました。また、すべての画像がまったく同じ寸法になることもわかっていました。ダイアログボックスを比較している状況では、典型的な画像はほとんど灰色がかっており、一部の画像のサイズを変更する必要がある場合があります (ただし、それは単に不一致を示しているだけかもしれません)。多くの。
アイデアは、各ノードがノードが表す領域の平均 RGB 値を表す四分木を形成することです。したがって、4x4 画像には、画像の平均 RGB 値に等しい RGB 値を持つルート ノードがあり、その子にはそれぞれの 2x2 領域の平均 RGB 値を表す RGB 値があり、その子は個々のピクセルを表します。(実際には、約 16x16 の領域よりも深くならないことをお勧めします。その時点で、個々のピクセルの比較を開始する必要があります。)
画像の比較を開始する前に、悪いしきい値も決定する必要があります。信頼できる精度でこのしきい値を超える悪さを計算することはないため、これは基本的に、画像に「一致しない」というラベルを付けるしきい値です。
画像 A と画像 B を比較するときは、最初に四分木表現のルート ノードを比較します。単一ピクセル画像の場合と同じように悪さを計算し、悪さがしきい値を超えた場合はすぐに戻り、このレベルでの悪さを報告します。正規化された悪さを使用しており、悪さは差の 2 乗を使用して計算されるため、特定のレベルでの悪さは、より低いレベルでの悪さと同じかそれ以下になります。個々のピクセルのレベルでのしきい値。
nxn 画像でしきい値テストに合格した場合は、次のレベルに落として、2nx2n 画像のように比較します。十分に低くなったら、個々のピクセルを比較します。画像のコーパスによっては、これにより多くの比較をスキップできる場合があります。