問題タブ [phash]

現在、ルビー ( https://github.com/toy/pHash/blob/master/lib/phash.rb )と組み合わせて、phash ( http://www.phash.org ) を使用しています。

説明されている例を使用すると、機能します。

しかし、ハッシュだけを抽出したいのですが、その方法がわかりません

私は OSX を使用しており、 pHash gemをインストールしました。

gem を使用すると、次のエラーが発生しますCould not open library 'libpHash.dylib'。

ドキュメントで、著者は言う

のような環境変数を使用して、pHash ライブラリへのパスを明示的に指定できますPHASH_LIB=/opt/local/lib/libpHash.dylib。

問題は、Ruby プログラムのコンテキストでこの環境変数を実際に呼び出す方法がわからないことです。gem は で呼び出されrequire 'phash'ますが、ENV 変数はどこで指定できますか?

ノードのphash-imageをインストールしようとしていますが、次のエラーが発生します:

どうすればこれを修正できますか? 私はos x 10.10.3を使用しており、自作でphashをインストールしています

MacPorts を使用して pHash ライブラリをインストールしましたが、サンプル ソース コードをコンパイルしようとすると、次のエラーが発生します。

ライブラリの場所をソースコードに伝えるにはどうすればよいですか? （私が見つけたものから、それらは /opt/local にインストールされています）

ImageHashライブラリを使用して、画像の知覚ハッシュを生成しています。ライブラリは、異なるサイズ (64、128、256) のハッシュを生成できると主張していますが、128 ハッシュを取得する方法がわかりません。

ハッシュ サイズは、ライブラリが画像を再スケーリングするときの画像サイズによって決まります。次に例を示します。

ここで、デフォルト値は 8 です (8x8 画像 = 64 ピクセル -> グレースケール -> 64 ビット)。

しかし、128 ビットのハッシュはどのように作成されるのでしょうか?

次に、ここで説明したように、pHash のデフォルト サイズは 32 ですが、後で左上の 8x8 セクションの DCT のみが計算されるため、64 ビットになります。DCT は次の方法で計算されますscipy.fftpack。

ハッシュサイズはどのように変更できますか?
どちらの値を使用しても、計算は常に左上の 8x8 に基づくため、常に 64 になります。

奇妙なことに、8 サイズの pHash (最初から画像のサイズを変更) から始めると、56 ビットの最終ハッシュが得られます (つまり、7x8 画像のハッシュの計算: 理由がわかりません)。これはDCT計算で発生しますが、私はそれについて少し知っています。

次のように C# からメソッドを呼び出しています。

そして、ここに私がライブラリから呼び出しているメソッドがあります

ulongから配列を読み取るにはどうすればよいIntPtrですか?

類似画像検索問題

• 何百万もの画像がpHashされ、Elasticsearch に保存されています。
• フォーマットは "11001101...11" (長さ 64) ですが、変更できます (変更しないほうがよいでしょう)。

対象画像のハッシュ "100111..10" が与えられた場合、ハミング距離 8 以内で Elasticsearch インデックス内のすべての類似画像ハッシュを見つけたいと考えています。

もちろん、クエリは 8 より大きい距離の画像を返すことができ、Elasticsearch または外部のスクリプトは結果セットをフィルタリングできます。ただし、合計検索時間は 1 秒程度以内にする必要があります。

現在のマッピング

images各ドキュメントには、画像ハッシュを含むネストされたフィールドがあります。

私たちの貧弱な解決策

事実: Elasticsearch ファジー クエリは、最大 2 のレーベンシュタイン距離のみをサポートします。

カスタム トークナイザーを使用して、64 ビット文字列を 16 ビットの 4 つのグループに分割し、4 つのファジー クエリで 4 つのグループ検索を実行しました。

アナライザ：

次に、新しいフィールド マッピング:

次にクエリを実行します。

画像自体ではなく、一致する画像を持つドキュメントを返すことに注意してください。

問題は、他のドメイン固有のフィルターを追加して初期セットを減らした後でも、このクエリが何十万もの結果を返すことです。スクリプトは、ハミング距離を再計算する作業が多すぎるため、クエリに数分かかる場合があります。

予想どおり、3 と 4 に増やすminimum_should_matchと、検索する必要がある画像のサブセットのみが返されますが、結果のセットは小さくて高速です。== 3 では必要な画像の 95% 未満が返されますが、== 2minimum_should_matchの場合と同様に 100% (または 99.9%) が必要minimum_should_matchです。

n-gram で同様のアプローチを試みましたが、結果が多すぎるという同様の方法ではまだあまり成功していません。

他のデータ構造とクエリの解決策はありますか?

編集：

minimum_should_match評価プロセスにバグがあり、 == 2 が 100% の結果を返すことに気付きました。ただし、その後の処理時間は平均5秒かかります。スクリプトを最適化する価値があるかどうかを確認します。