> Так как dct расчитывается от матрицы в которой уменьшена вдвое плотность информации. 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."
> дескриптор и потом взять 1...65 элементы?
К сожалению, не знаю
> получается мы в любом случае растягиваем матрицу в размер 32?
Не совсем понял, но идея в том, что ORB дескрипторы занимают 32 байта, и неудобно их сравнивать, поэтому была идея использовать phash, чтобы ужимать 32 байта в 8 байт, и после чего удобнее хранить в базе, и работать.
Всю "магию" делает phash, если ужать два похожих дескриптора таким способом, (похожих, это число различающихся бит будет небольшое), то их хеши тоже будут различаться несильно.
К сожалению, потеря в точности при сжатии неизбежна.
Поэтому я бы подумал, как бы работать напрямую с ORB дескрипторами, хранить 4 восьмибайтных числа и искать по ним уже.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
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."
> дескриптор и потом взять 1...65 элементы?
К сожалению, не знаю