How to compress opencv ORB descriptors are 32 bytes in 8 bytes using phash?

Try to do a search based on the article
https://habrahabr.ru/post/211773/
is there such a moment
Since our hash is 64битное number requires 32 bytes of descriptor to shrink in 8 bytes and it does not lose much accuracy.
After some tests it was decided to try these 32 bytes are present in the form of a matrix of 16x16-bit. And then this matrix to pass through a perceptual hash PHash. The result was supposed to be just a 64 bit number.

And that's how it is I have no ideas how this matrix to feed in cv::dct from opencv or https://www.phash.org/
Interested in the solution in c++ but it'll do and any other language
In the repository the author of the article (huge respect to him by the way) is not found in the example conversion of the descriptor in the hash https://github.com/valbok/img.chk
June 8th 19 at 17:31

Related questions

More answers about "How to compress opencv ORB descriptors are 32 bytes in 8 bytes using phash?"
1 answer
June 8th 19 at 17:33
Solution
Good day,
> not found in the example conversion descriptor
A handle in the form of 32 bytes, creates a matrix of 16*16 bit
https://github.com/valbok/img.chk/blob/master/core...

Here the phash implementation
https://github.com/valbok/img.chk/blob/master/core...
Thank you!!!
The second thing immediately see, and the first somehow ignored. - Marty93 commented on June 8th 19 at 17:36
turns out we are in any way stretchable matrix of size 32?
After the dct pruning in this case can not throw in twice as much information than could be in the matrix at 16? - Marty93 commented on June 8th 19 at 17:39
> it turns out we will in any case tie matrix of size 32?
I do not quite understand, but the idea that the ORB descriptors is 32 bytes, and awkward to compare, so the idea was to use phash to compress 32 bytes to 8 bytes, and then easier to store in the database, and work.

The whole "magic" makes phash, shrink if two similar descriptor in this way (similar is the number of differing bits is small), then their hashes will also vary slightly.
Unfortunately, the loss in accuracy when compression is inevitable.

So I'd like to work directly with ORB descriptors, store 4 possibity numbers and look for them. - houston.Waelc commented on June 8th 19 at 17:42
This is all understandable.
I'm talking about https://github.com/valbok/img.chk/blob/master/core...
after dct
we take the top left square 8*8 will there be no unnecessary loss of precision? Since dct is calculated from the matrix in which twice the density of information. - Marty93 commented on June 8th 19 at 17:45
And another point.
DCT in opencv can work with the one-dimensional matrix. https://docs.opencv.org/3.4.0/d2/de8/group__core__...
So do we need to artificially introduce additional dimension in the construction of the matrix 16*16 ? Maybe you just like the array to shovel the ORB descriptor and then take 1...65 items? - Marty93 commented on June 8th 19 at 17:48
I'd like to work directly with ORB descriptors, store 4 possibity number

I have no such space on the memory. - Marty93 commented on June 8th 19 at 17:51
> Since dct is calculated from the matrix in which twice the density of information.
www.hackerfactor.com/blog/index.php?/archives/432-...
While the DCT is 32x32, just keep the top-left 8x8. Those represent the lowest frequencies in the picture.

He wrote: "the dct hash is based on the low 2D DCT coefficients starting at the second from lowest, leaving out the first DC term. This excludes completely flat image information (i.e. solid colors) from being included in the hash description."

> the handle and then take 1...65 items?
Unfortunately, I don't know - houston.Waelc commented on June 8th 19 at 17:54
OK , so I should test it. - Marty93 commented on June 8th 19 at 17:57

Find more questions by tags OpenCVC++AlgorithmsHashingMathematics