Replies: 2 comments 5 replies
-
The biggest problem is that the the hash algorithm is incredibly easy to change, if you resize before you turn to grayscale is different than turning grayscale before you resize. For example webp files there is a simple option that changes how it converts yuv/cbcr to RGB which then screws up the exact values when it resizes and converts to grayscale. Even if ImageHash doesn't change, to keep the hash the same it depends on the version of PIL for resize and grayscale conversion and the version of libwebp or libjpeg or whichever library loads the image and if the library has a direct conversion to RGB or if PIL has to do it itself (PIL always converts images into RGB(A) images) |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Metron has now added pHash for its covers. My current thinking is:
hash
to ComicIssue (knowing the hash type will be required so maybe a JSON field?{"type": "phash", "hash": "hexhash"}
Possibly support multiple hash types? Another option could be a string (array):p_hexhash
ora_hexhash
etc.)I'm wondering if the hash from the API should be ignored? If the list of possible issues does not match, maybe download the image and hash it ourselves to double check?
I'm also wondering if saving the hash of the local (to issue) or remote (to image cache) would be of any use?
When I comes to the hashing, should it be switched to the imagehash or implement the same in CTs? I notice that it requires a few deps that for CTs use case aren't really required?
Beta Was this translation helpful? Give feedback.
All reactions