Viewing last 25 versions of post by derpy727 in topic Feature suggestions and discussion [READ THE FIRST POST]

derpy727

PS. Ah yes, while I'm at it, there's another funny thing I noticed about the hash algorithm.
 
As you can see, it basically computes the fingerprint for a grayscalized picture, by multiplying r**=0.2126; g**=0.7152; b*=0.0772, the human color perception constants, and summing the results.


 
The first minor nit is that it could be done by opencv itself, by loading images with CV_LOAD_IMAGE_GRAYSCALE, though it has slightly differing constants baked in (see documentation for cvtColor()), and though there might be minor precision advantages in loading 3 uint8 channels first, processing them separately and only then doing the conversion.


 
And secondly, more importantly, CvMat.load() returns color channels in a **different order**. It's BGR, instead of RGB. The current code fails to account for that and so multiplies R by the constant for B, and vice-versa. So it tends to underestimate the importance of red and overestimate the importance of blue by some ~3 times (which also means, that if someone uploads a grayscale version of an already uploaded pic, i.e. one passed through the correct conversion formula, it might not get detected as a duplicate).
No reason given
Edited by derpy727
derpy727

PS. Ah yes, while I'm at it, there's another funny thing I noticed about the hash algorithm.
As you can see, it basically computes the fingerprint for a grayscalized picture, by multiplying r*=0.2126; g*=0.7152; b*=0.0772, the human color perception constants, and summing the results.

The first minor nit is that it could be done by opencv itself, by loading images with CV_LOAD_IMAGE_GRAYSCALE, though it has slightly differing constants baked in (see documentation for cvtColor()), and though there might be minor precision advantages in loading 3 uint8 channels first, processing them separately and only then doing the conversion.

And secondly, more importantly, CvMat.load() returns color channels in a **different order**. It's BGR, instead of RGB. The current code fails to account for that and so multiplies R by the constant for B, and vice-versa. So it tends to underestimate the importance of red and overestimate the importance of blue by some ~3 times.
No reason given
Edited by derpy727