Perceptual Hash

[blue-j]

This is stellar work! You are royalty!

I've been studying perceptual hashes and similarity algorithms lately, and this is a fascinating approach. A question - I see this is a metric, and you can compare, and see moments, but I don't see any literal hash generation that is exposed to the user. Ideally, we could generate a sortable hash from this that would allow similarity-based found sets, yes? Is this there, and I am not seeing it, or something on your mind to support in the future?

Thank you so much for all your wonderful work!!
J

[fmw42]

This is stellar work! You are royalty!

I've been studying perceptual hashes and similarity algorithms lately, and this is a fascinating approach. A question - I see this is a metric, and you can compare, and see moments, but I don't see any literal hash generation that is exposed to the user. Ideally, we could generate a sortable hash from this that would allow similarity-based found sets, yes? Is this there, and I am not seeing it, or something on your mind to support in the future?

Thank you so much for all your wonderful work!!
J

Yes, we are still thinking about how best to do that, since it is hard to make a real hash for 42 floats. I have a method that produces a 168 digital numeral hash. But it has not been tested yet. It is conceivable to put that into identify or into a new function that generates that hash. I will have to create a script to test the feasibility for such a hash. It has been our intention to generate a hash for storage in a database, for example, but we have not decided the best approach and are somewhat waiting to hear any feedback, such as this.

[magick]

Try this command:

• convert image.png -moments image.json

Grab the image moments from the image.json file.

[blue-j]

I would bet real cash that you are all very ahead of me on this matter, but I thought in the spirit of collaboration I would share what resources I've come across:

http://hackerlabs.org/blog/2012/07/30/o ... -checking/
http://www.hackerfactor.com/blog/?/arch ... ke-It.html
http://www.hackerfactor.com/blog/index. ... -That.html
http://phash.org/docs/pubs/thesis_zauner.pdf

I find this fascinating! And wow what a wonderful addition to ImageMagick! : )

J

[blue-j]

Spectral hashing algorithm:

http://www.cs.huji.ac.il/~yweiss/SpectralHashing/

http://people.csail.mit.edu/torralba/pu ... ashing.pdf

[fmw42]

Thanks for all the references. I had seen variations on most of these. But some of your references are more detailed than mine.

Please note that we are not restricting ourselves to just the one perceptual hash. Over time I will review some of the others. I just picked the one I though might do the best job. But it was just my opinion and not backed by any comparisons with other algorithms.

We would welcome any contributed code for other perceptual hashes.

P.S. We are working to output the 42 float values for the hash, hopefully, for the next point release. I will make a script that will take the hashes from two (color) images and compute the phash metric. It is basically the sum of squared differences between the two sets.

[blue-j]

Thanks for including me, but unfortunately I'm a beginner in many regards and can't help much other than testing, sharing resources, and trying to become more helpful by studying. (I manage and design the development of software but don't code myself often.)

It's great to hear that this is on your mind! Is it safe to assume that you are trying to make the resulting hashes meaningfully sortable so found sets could be easily ranked in terms of similarity to a input? Wow, this is all so cool.

Thanks again!
J

[fmw42]

Is it safe to assume that you are trying to make the resulting hashes meaningfully sortable so found sets could be easily ranked in terms of similarity to a input?

Yes, that is the idea. The lower the sum squared difference of all the 42 floats, the closer the match.

My tests show some promise towards that end.

[blue-j]

I've just spent the last week studying perceptual hashes and CBIR and such, and have to commend you on your choice of algorithms. Using invariant moments was very wise, in my semi-educated opinion! I'm eager to test this and explore more; please let me know when you release an actual hash creation procedure. Thanks again!

J

[magick]

You can use perceptual hash with the latest release of ImageMagick 6.8.8-7. See http://www.fmwconcepts.com/misc_tests/p ... index.html for a discussion of the perceptual hash algorithm.

[fmw42]

The hash values will be available in IM 6.8.8.8. That is the 42 has float values will be reported by identify and by convert. When using convert you can also write to a .json file. (The unprocessed image moments are currently available in IM 6.8.8.7, but these are not the hash values)

Syntax is as follow:

Code: Select all

identify -verbose -moments someimage

convert someimage -verbose -moments info:

convert someimage -verbose -moments momentsfile.json

It will look like the following:

Code: Select all

im6888beta convert rose: -verbose -moments info:

Code: Select all

Image: rose:
 ...
  Channel moments:
    Red:
      Centroid: 35.3441,22.8691
      Ellipse Semi-Major/Minor axis: 36.8196,23.4724
      Ellipse angle: -13.5743
      Ellipse eccentricity: 0.602082
      Ellipse intensity: 172.809 (0.677681)
      I1: 0.00101591 (0.259058)
      I2: 1.83856e-07 (0.0119553)
      I3: 5.67785e-12 (9.41465e-05)
      I4: 1.6928e-13 (2.80689e-06)
      I5: 1.27149e-25 (3.49587e-11)
      I6: 2.26124e-17 (9.5611e-08)
      I7: -1.06655e-25 (-2.93239e-11)
      I8: 3.44862e-17 (1.45816e-07)
    Green:
      Centroid: 35.7345,24.3549
      Ellipse Semi-Major/Minor axis: 43.978,25.89
      Ellipse angle: -10.7547
      Ellipse eccentricity: 0.641325
      Ellipse intensity: 80.3521 (0.315106)
      I1: 0.0022653 (0.577652)
      I2: 1.20835e-06 (0.0785727)
      I3: 6.50957e-11 (0.00107938)
      I4: 1.31504e-11 (0.000218052)
      I5: -3.38662e-22 (-9.31123e-08)
      I6: -3.81722e-15 (-1.61402e-05)
      I7: 1.82608e-22 (5.02067e-08)
      I8: 6.97124e-15 (2.94761e-05)
    Blue:
      Centroid: 33.9829,23.9157
      Ellipse Semi-Major/Minor axis: 43.6329,25.5614
      Ellipse angle: -12.8749
      Ellipse eccentricity: 0.643562
      Ellipse intensity: 73.9492 (0.289997)
      I1: 0.00246732 (0.629167)
      I2: 1.45562e-06 (0.0946516)
      I3: 4.24471e-10 (0.00703832)
      I4: 1.67336e-10 (0.00277466)
      I5: 4.14544e-20 (1.13976e-05)
      I6: 1.85714e-13 (0.000785244)
      I7: 1.64449e-20 (4.52139e-06)
      I8: 3.95902e-14 (0.000167397)
  Image moments:
    Overall:
      Centroid: 35,23
      Ellipse Semi-Major/Minor axis: 40.7272,24.725
      Ellipse angle: -12.3998
      Ellipse eccentricity: 0.626828
      Ellipse intensity: 107.024 (0.419703)
      I1: 0.00167617 (0.427425)
      I2: 5.98116e-07 (0.0388925)
      I3: 4.58055e-11 (0.000759519)
      I4: 6.65358e-12 (0.000110326)
      I5: 5.70801e-23 (1.56937e-08)
      I6: 3.9014e-15 (1.64961e-05)
      I7: 1.01164e-22 (2.78142e-08)
      I8: 1.67763e-15 (7.09344e-06)
  Channel perceptual hash:
    Red, Hue:
      PH1: 0.586155, 0.0651501
      PH2: 1.92259, 0.643724
      PH3: 4.04093, 1.66702
      PH4: 5.55782, 2.30485
      PH5: 10.4956, 5.2932
      PH6: 6.97909, 2.8081
      PH7: 10.5206, 4.29294
    Green, Chroma:
      PH1: 0.238558, 0.454035
      PH2: 1.1056, 1.83721
      PH3: 2.98275, 2.88605
      PH4: 3.66115, 3.89781
      PH5: 7.03505, 7.563
      PH6: 4.77368, 5.07873
      PH7: 7.31909, 7.36232
    Blue, Luma:
      PH1: 0.201386, 0.360681
      PH2: 1.02442, 1.39199
      PH3: 2.16063, 3.29767
      PH4: 2.56066, 4.41624
      PH5: 4.95438, 10.0023
      PH6: 3.11037, 5.35253
      PH7: 5.34622, 8.27327
...

You can compute the sum of squared differences between two images from the two sets of 42 values shown above. You need both the RGB and HCLp values to make up the 42 values. The order is not important except you must use the corresponding values from the two images.

[blue-j]

forgive my ignorance, but i assumed the perceptual hash would be something like an image-specific signature of alphanumerical characters that would sort along similarities in a found set. otherwise i don't know how CBIR would work with this, when thousands to hundreds of thousands of images are involved. have i misread your post? it seems i have misunderstood your goal?

thanks as always,
J

[fmw42]

For now you would generate and extract the 42 floats (convert image -verbose -moments result.json or identify -verbose -moments image) and store them in a database. Then when you want to search the database, you would retrieve the 42 floats and compute the sum of squared differences of the 42 floats between two images to see if similar. It does not categorize the images into specific groups. It is just a measure whether two images are the same image even if one has more noise, brightness, contrast, compression, scale or rotation.

I have some ideas for converting the 42 floats into on long string of digits. But I have not implemented that test yet.

[snibgo]

Just thinking aloud ...

The 42 hash values for an image represent a point in 42-dimensional space. If I have 10,000 images I can compute the hash values for each, so I have 10,000 points in 42-dimensional space.

This is analogous to having an image of 10,000 pixels in 3-dimensional space. ImageMagick already contains algorithms that can simplify an image into a small subset of colours, using "-colors", "-posterize", etc.

In principle, exactly the same algorithms could be used to simplify the database of 10,000 images. All we need to do is make an image with 42 channels and 10,000 pixels. Populate each pixel accordingly. Then apply "-colors 10" to categorize the database into ten groups, or however many are wanted.

[fmw42]

Perhaps you miss the point about computing the sum squared difference from the 42 values for each image. That gives a simple metric value for the comparison.

Also it just a measure whether two images are the same image even if one has more noise, brightness, contrast, compression, scale or rotation.