0

This is very simple code for SIFT,I am getting is very strange descriptors.Are they correct?

descriptor: [ 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;
}
Alexis King
  • 43,109
  • 15
  • 131
  • 205
Vivek
  • 152
  • 1
  • 4
  • 10
  • What is strange about the descriptor? –  Feb 22 '13 at 18:53
  • I wanted to save sift descriptor on file(xml) for training purpose,so i can use it in future,i want the floating point descriptor as i get in case of surf. – Vivek Feb 23 '13 at 08:01
  • The comment in the sift.cpp mentions that the implementation is based on OpenSift implementation. The OpenSift also converts float to integers with 512 as threshold. Though I also am not sure why. – adikshit Apr 09 '14 at 01:52

1 Answers1

0

For some reason unknown to me, the SIFT descriptor implemented in OpenCV converts the final values to uchar (0 - 255) and has always done so since I remember. It is a waste of space, since the resulting values are stored in a float descriptor, and it also hinders matching.

What I do is compile my own version of SIFT where I just leave out the conversion to bytes (in the link), and I get nice floating point values.

Michal Kottman
  • 16,375
  • 3
  • 47
  • 62
  • The conversion to uchar (0-255) is to match the format used by Lowe in his original example binaries. Even if passed around as floats, it is useful to have values constrained to this range so that you have the option of casting the SIFT dimensions to single bytes, making large look-up structures more memory efficient. –  Feb 22 '13 at 18:53
  • @Articuno : Converting it to uchar will make it lose accuracy. Isn't it ? Or am I missing some important point here ? – adikshit Apr 09 '14 at 01:50
  • @adikshit Yes, that's correct. But the memory savings are significant (1 byte instead of 4 bytes). –  Apr 09 '14 at 04:42