Open denisnazarov opened 9 years ago
The original file was an uncompressed iphone jpeg.
After further investigation, I realized that blockhash doesn't consider the orientation in the metadata (after stripping metadata to upload to s3, it was sideways), therefore it was hashing it sideways, giving a completely different value. This wasn't obvious as most OS X seems to render iphone photos in the correct orientation in viewers.
Do you suggest of any way for accounting for orientation?
Feel free to close this issue. :+1:
Very interesting! As a general note, you should also pay attention to #2 and the improved version in the m4-improv branch which we'll likely merge into master soon, but which will be a breaking change. It doesn't solve this particular issue though, but it seems to me that we should take orientation into consideration. Most likely the best way would simply be to ignore orientation metadata if we can. @artfwo what do you think?
The orientation tag should be taken into account, as the reverse case (matching data/different orientation) is less likely to happen.
I included this in the RFC draft update: https://github.com/commonsmachinery/blockhash-rfc/blob/m4/draft-commonsmachinery-urn-blockhash-00.txt#L195-L196
Hello, wanted to document a drastic different hamming distance between two identical images of different compression.
Using the hamming distance function in blockhash-js, it returns a value of 120.
The images: https://s3.amazonaws.com/denisnazarov/blockhash/compressed.jpg https://s3.amazonaws.com/denisnazarov/blockhash/original.jpg
Has this implementation been tested with high resolution images? I can add some failing tests.