Also, this article outlines a nice idea of finding "similar" images "simply" by comparing the colour histograms of five areas of the image. This doesn't necessarily find images with the same motives, but it finds images with the same colour composition ("blue sky", "yellow sand"). The linked code is more in Python, but I think the general concepts translate to Perl too, potentially using PDL.

> but Image::Seek looks promising,

yep, indeed.

The first thing which came to mind after reading the title is wavelets, and Image::Seek is such an implementation.

Cheers Rolf

_{(addicted to the Perl Programming Language and ☆☆☆☆ :)}

From what I can tell, it almost looks as if the Stonehenge post and Image::Seek are using the same algorithm. I'm looking specifically at haar.cpp from Image::Seek. Anyway, Image::Seek is a really good starting point. I think what I am going to do is make some minor modifications to the source to fit my needs. I will post my results once finished.

Thanks for pointing me in the right direction!.

> it almost looks as if the Stonehenge post and Image::Seek are using the same algorithm

I don't think so... wavelets are fare more sophisticated and reliable.

But it seems like the results of Merlyn's algorithm were already sufficient for you and you only need a good lookup strategy for your SQL-query.

For this approach you are calculating if sum of distances of 48 vectors are below a threshold. (BTW: could you please fix your OP by adding code-tags?)

succesive narowing

So start by only looking up the set of images were the first vectors distance is below the threshold.

Then you need to look up the images were 2. distance < threshold - 1. distance and so on.

grid approach

Grouping and indexing the vectors in a grid where the cells have the widths of the threshold should speed up the look up considerably.

Then two vectors can only have a smaller distance if they are in the same or neighboring cells!

Prefiltering over the 48 vecors like this would narrow the set of possible results considerably well, to allow a more detailed comparison.

I don't know the inner optimization of your DB server sufficiently well to formulate an optimal SQL query for this, but this would be off topic anyway and I hope you get the idea mow. :)

Cheers Rolf

_{(addicted to the Perl Programming Language and ☆☆☆☆ :)}

If you only have 48 images to compare against, or 480 for that matter, you could indeed just loop through them all, calculating a total-difference statistic, sort them by that, and take the one with the lowest total difference.

The problem arises when you have more like 48 million images in your database, at which point looping through all of them becomes prohibitive.

The solution I can think of is going to be more SQL than Perl, though you could use Perl to build the SQL you want. The idea would be to develop a query that looks for images with some of their statistics being very similar to the ones for the current image. Since you can set up the database to pre-emptively index these fields, you can thus avoid the need to do all the difference calculations for every image in the database every time.

As I understand the author merlin defines a match as follows:

 =13=    my $FUZZ = 5; # permitted average deviation in the vector ele
+ments
   
...   

=66=      BUCKET: for my $bucket (@buckets) {
=67=        my $error = 0;
=68=        INDEX: for my $index (0..$#vector) {
=69=          $error += abs($bucket->[0][$index] - $vector[$index]);
=70=          next BUCKET if $error > $FUZZ * @vector;
=71=        }
...
[download]

IMHO the above set of matches is a subset of all matches where

$pattern_sum += @pattern_vector;
$upper_bound  = $pattern_sum + $FUZZ * @pattern_vector;
$lower_bound  = $pattern_sum + $FUZZ * @pattern_vector;

BUCKET: for my $bucket (@buckets) {
   my $bucket_sum += @{$bucket->[0]};
   next BUCKET 
       if ($bucket_sum > $upper_bound || $bucket_sum < $lower_bound);
   # found, do something
}
[download]

Depending on the randomness the matches will be roughly doubled, i.e. with $FUZZ=5, and a vector with 48 elements each an 8-bit integer, the number of possible different sums of the vector values is 48*255+1=12_241. The original method gives 48*5=240 as maximal allowed sum of the absolute differences. Thus the set of all possible sums is reduced by a factor of 12_241/240=51. When we use an interval of +/- 5, then 48*5*2=480, and the reduction is only 25. This means 1_000 images found out of a total of 25_000 images.

But if we calculate the sum of the vector, we can store it as an integer field in the database and use SQL comparisons.

The query result could still be refined using the original method, or something better like e.g. cosine similarity, which should be fast enough for ~1_000 vectors.