大きな画像の中の小さな画像の位置を見つける必要があります。小さい画像は大きい画像のサブセットです。また、たとえば画像が異なるJPEG圧縮で生成された場合、ピクセル値がわずかに異なる可能性があることも要件です。CPUを使用してバイトを比較することでソリューションを実装しましたが、現在、プロセスを高速化する可能性を検討しています。どういうわけかOpenGLES、つまりiPhone GPUを利用できますか?
注:画像はグレースケールです。
大きな画像の中の小さな画像の位置を見つける必要があります。小さい画像は大きい画像のサブセットです。また、たとえば画像が異なるJPEG圧縮で生成された場合、ピクセル値がわずかに異なる可能性があることも要件です。CPUを使用してバイトを比較することでソリューションを実装しましたが、現在、プロセスを高速化する可能性を検討しています。どういうわけかOpenGLES、つまりiPhone GPUを利用できますか?
注:画像はグレースケールです。
@Ivan、これはビデオ圧縮のかなり標準的な問題です(前のフレームで現在のマクロブロックの位置を見つける)。絶対差の合計(SAD)、二乗差の合計(SSD)、またはアダマール変換された差の合計(SATD)など、ピクセルの差のメトリックを使用できます。あなたはビデオを圧縮しようとしているのではなく、透かしのようなものを探していると思います。多くの場合、最急降下法を使用して極小値(最適一致)を見つけることができます。これは、画像(小さな画像)を同じもののわずかにオフセットされたバージョン(位置が一致している)と比較するという経験的観察に基づいています。正確には見つかりませんでした)は、別の画像のランダムな部分と比較するよりも近いメトリックを生成します。したがって、すべての可能なオフセット/位置(ビデオエンコーディングのモーションベクトル)のスペースをかなり粗くサンプリングすることから始めることができます。次に、最良の結果を中心にローカル最適化を実行します。ローカル最適化は、一致をいくつかの隣接する一致と比較し、現在の一致よりも優れている場合はそれらの最良のものに移動することによって機能します。繰り返します。これはブルートフォース(可能なすべての位置をチェックする)よりもはるかに高速ですが、すべての場合に機能するとは限りません(一致するものの性質によって異なります)。残念ながら、このタイプのアルゴリズムは、各ステップが前のステップに依存しているため、GPUにうまく変換されません。それでも価値があるかもしれません。たとえば、256x256イメージの位置に隣接する16個をチェックすると、GPUに送信するのに十分な並列計算であり、OpenGL-ESで絶対に実行できます。ただし、これらすべてに対する答えは、ブルートフォース攻撃を行っているのか、ローカル最小化タイプの検索を行っているのかによって異なります。