SIFT opencv2.3.1/2.4.3 都给出非常奇怪的描述符..like 7., 29., 39., 11., 2.3.1 给出非常奇怪的描述符答案

【问题标题】：SIFT opencv2.3.1/2.4.3 both Giving very strange descriptors..like 7., 29., 39., 11., 2.3.1 Giving very strange descriptorsSIFT opencv2.3.1/2.4.3 都给出非常奇怪的描述符..like 7., 29., 39., 11., 2.3.1 给出非常奇怪的描述符
【发布时间】：2013-02-01 04:42:14
【问题描述】：

这是非常简单的 SIFT 代码，我得到的描述符很奇怪。它们正确吗？

描述符：[ 0., 7., 29., 39., 11., 0., 0., 0., 32., 30., 39., 52., 16., 0., 1., 12., 38., 14., 10., 20., 28., 93., 45., 37., 93., 3., 6., 11., 23., 107., 24., 80., 0., 2., 47., 53., 0., 1., 9., 8., 104., 85., 35., 41., 1., 10., 32., 19., 130., 73., 0., 0., 8., 76., 31., 42., 61., 40., 10., 5., 83., 130., 28., 31., 3., 0., 0., 0., 0., 2., 12., 17., 60., 4., 0., 0., 0., 31., 76., 83., 130., 38., 10., 6., 15., 10., 16., 89., 19., 21., 16., 23., 130., 94., 7., 3., 1. ]

#include "stdafx.h"
#include <iostream>
#include <cv.h>
#include <highgui.h>
#include <C:\opencv243\include\opencv2\nonfree\features2d.hpp>
using namespace cv;
using namespace std; 
int main(int argc, const char* argv[])
{
string path="matrices.xml";
   FileStorage fs(path, FileStorage::WRITE);
   cv::siftFeatureDetector detector;
   cv::SiftDescriptorExtractor extractor; 
   cv::Mat descriptors_1;
   std::vector<cv::KeyPoint> keypoints;
   const cv::Mat input=cv::imread("image path",0);
   detector.detect(input, keypoints);
   extractor.compute( input, keypoints, descriptors_1 );
   fs <<"descriptor"<<descriptors_1;
   fs.release();
   return 0;
}

【问题讨论】：

描述符有什么奇怪的地方？
sift.cpp 中的注释提到该实现是基于 OpenSift 实现的。 OpenSift 还将浮点数转换为以 512 作为阈值的整数。虽然我也不知道为什么。

标签： opencv sift feature-descriptor

【解决方案1】：

出于某种我不知道的原因，在 OpenCV converts the final values to uchar (0 - 255) 中实现了 SIFT 描述符，并且从我记事起就一直这样做。这很浪费空间，因为结果值存储在浮点描述符中，而且还阻碍了匹配。

我所做的是编译我自己的 SIFT 版本，我只是省略了到字节的转换（在链接中），我得到了很好的浮点值。

【讨论】：

转换为 uchar (0-255) 是为了匹配 Lowe 在他的原始示例二进制文件中使用的格式。即使作为浮点数传递，将值限制在此范围内也很有用，这样您就可以选择将 SIFT 维度转换为单个字节，从而使大型查找结构更节省内存。
@Articuno ：将其转换为 uchar 会使其失去准确性。不是吗？还是我在这里遗漏了一些重要的点？
@adikshit 是的，没错。但是内存节省很显着（1 个字节而不是 4 个字节）。