Open jonemo opened 2 years ago
Huh. Do you know why db4 does that?
Sorry, I am the wrong person to ask this question. I used imagehash
precisely because I have no clue about any of these algorithms. (And that was a year ago, now I know even less.)
The two wavelet shapes: http://wavelets.pybytes.com/wavelet/db4/ http://wavelets.pybytes.com/wavelet/haar/ (nothing obvious there)
The whash function calls this: https://pywavelets.readthedocs.io/en/latest/ref/2d-dwt-and-idwt.html#d-multilevel-decomposition-using-wavedec2 with default mode ('symmetric')
Maybe have a look at the input and output of this call https://github.com/JohannesBuchner/imagehash/blob/master/imagehash/__init__.py#L385
In any case, given how differently the various methods work, no, hash_size
does not necessarily have to have a consistent meaning across all methods.
I am surprised that the size of the hash computed is not equal to the
hash_size
parameter available for all hashing methods. Specifically,imagehash.whash(img, hash_size=16, mode="db4")
yields a hash of size 22 x 22.While the readme does not make any explicit promises about the hash size, the naming of parameters makes this outcome quite unexpected. Of course, me being surprised is not an issue in itself and unless this is a bug, it would be unreasonable to break backward compatibility with a change in API or behavior. However, maybe it's worth adding clarification that
hash_size
does not always match hash size in the documentation/readme?The readme currently covers
hash_size
in this paragraph:Sample code:
Output:
Example image: