jenssegers / imagehash

🌄 Perceptual image hashing for PHP

Home Page:https://jenssegers.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Return value of Jenssegers\ImageHash\Hash::toInt() must be of the type int, float returned

opened this issue · comments

Using $hash->toInt() in a image, the returned value is float, not integer

I think this only happens on 32bit systems?

I'm executing it from a Dockerized application over a 64bit Mac.

The container information is:

$ uname --al
Linux php-fpm 4.19.76-linuxkit #1 SMP Tue May 26 11:42:35 UTC 2020 x86_64 GNU/Linux

And is the PHP binary 32bit or 64bit?

Is 64bit, check using this method:

<?php
if (PHP_INT_SIZE==4) {
  echo "32 bits";
}
if (PHP_INT_SIZE==8) {
  echo "64 bits";
}

https://code-boxx.com/check-php-version/

toInt signature should be changed to return string instead. It tries to unwrap BigInteger and that leads to unwrapping it to float becuase that's how PHP deals with big numbers that exceeded int range.

I think you should drop the toInt method and allow access to the BigInteger objet directly, that's what I'm storing in my Doctrine entities with a custom type that unwraps to an unsigned bigint in SQL and it works pretty well.

Any update to this?

This library essentially needs 64bit PHP. As far as I can tell, this issue only occurs on 32-bit builds.

According to Ghost's snippet, I'm running 64bit PHP. I'm running Ubuntu 20.04, with PHP7.4 from ondrej.

PHP integers are signed integers, you can't fit a unsigned big integer generated by this hash inside a signed big integer unless you apply some dark magic like this:
VincentChalnot@2e02b0f#diff-4d0b8a3066462343f5ad1a0fb45696e5b321a742cc322fd3188a36c549a39e81R81
I have open a pull request with my fix but it might not pass as it breaks some backward compatibility:
#66

commented

As a workaround I've replaced
public function toInt(): int
to
public function toInt(): float

and add
ini_set('precision', 30);

The way floats are store in memory doesn't make sense for this type of algorithm, you can't apply bitwise operations on float and expect them to behave the way integers or binary string do.
Also changing the precision of all floating numbers in the PHP engine seems really overkill.

The ideal way would be to never use numbers but instead only binary strings but you can't apply bitwise operator on strings in MySQL < 8. I think it might be supported in Postgres but I'm not sure.

PHP_INT_SIZE=8

$this->toHex()

ffffffaf01010000

hexdec($this->toHex())

18446743725834043392.0

returned 1.8446743725834E+19

@4n70w4 same here, just wonder why the same hex value results different decimal values.
looks like it loses 8 bits, so the hamdistance is not accurated.