Jens's profile - activity

Hi all,

I'll give the answer myself:

The problem is the already mentioned difference between the support vector indices. Within the implementation of the SVMs write and read methods (modules/ml/src/svm.cpp, lines 2022 ff and 2139 ff), the author makes the assumption, that support vector indices are not required in 2-class problems. That is probably correct if a linear kernel is used (i.e., when you have only one support vector). But with other kernels (in my case with an RBF kernel), the support vector indices are definitly required.

I've added a git diff where I commented this questionable conditions out. Now everything works fine! IMHO the lines should be removed.

I posted a bug report on this issue right now.

Btw.: That new users must wait 2 days to answer their own questions sucks!!!

Jens

diff --git a/modules/ml/src/svm.cpp b/modules/ml/src/svm.cpp
index 9318085..b9f1c51 100644
--- a/modules/ml/src/svm.cpp
+++ b/modules/ml/src/svm.cpp
@@ -2066,14 +2066,14 @@ public:
                << "alpha" << "[:";
              fs.writeRaw("d", (const uchar*)&df_alpha[df.ofs], sv_count*sizeof(df_alpha[0]));
              fs << "]";
-            if( class_count > 2 )
-            {
+//            if( class_count > 2 )
+//            {
                  fs << "index" << "[:";
                  fs.writeRaw("i", (const uchar*)&df_index[df.ofs], sv_count*sizeof(df_index[0]));
                  fs << "]";
-            }
-            else
-                CV_Assert( sv_count == sv_total );
+//            }
+//            else
+//                CV_Assert( sv_count == sv_total );
              fs << "}";
          }
          fs << "]";
@@ -2191,12 +2191,12 @@ public:
              df_index.resize(ofs + sv_count);
              df_alpha.resize(ofs + sv_count);
              dfi["alpha"].readRaw("d", (uchar*)&df_alpha[ofs], sv_count*sizeof(df_alpha[0]));
-            if( class_count > 2 )
+//            if( class_count > 2 )
                  dfi["index"].readRaw("i", (uchar*)&df_index[ofs], sv_count*sizeof(df_index[0]));
              decision_func.push_back(df);
          }
-        if( class_count <= 2 )
-            setRangeVector(df_index, sv_total);
+//        if( class_count <= 2 )
+//            setRangeVector(df_index, sv_total);
          if( (int)fn["optimize_linear"] != 0 )
              optimize_linear_svm();
      }

Hi all,

I'm currently working with am SVM in OpenCV 3.0.0. When I train a C_SVC-SVM with RBF kernel I'll get good classification results of about 90-95%. These results are really good, in the problem case I'm working on.

Now I save the SVM to a file (in my case I use YML, but I think it doesn't matter):

classifier->save(filename);

... where classifier is of type cv::Ptr<cv::ml::svm>. The next time I start the program, I'll load the SVM again:

classifier = cv::Algorithm::load<cv::ml::svm &gt;(filename);<="" p="">

... but now I get recognition rates of 0-36% with exactly the same dataset.

I dumped all parameters, the decision function, and all other values to console and compared them manually. Except for the support vector indices of the decision function they do not differ before save, after load, and in comparison to the saved files.

What's going on here? Any ideas?

Cheers, Jens

Hi Guanta,

no problem, I'll fill a bug report, too. However, I am not sure if I'll manage it today.

Concerning the work-arounds: I don't know the number of rows in advance. But I implemented a word-around in a similar manner (using a float array). But I had to implement my own memory management. ;-)

Hi all,

I am currently working with huge matrices and get into trouble when the matix reaches a size of approximately 5GB while using successive push_back()-calls from cv::Mat. At a given point the resident memory shown for my app drops from approximately 5GB to a approximately 0.5GB. This is exactly at the same time, when a resize of the matrix is performed. Now the data within the matrix is corrupted.

Interestingly I can make further push_back() calls without any problems. With the exception, that the memory size of the program is 5GB to low, the memory size increases as if nothing has happend. Then, when the matrix reaches the point where the next resize of the matrix is required, i.e., at approximately 8GB, the resident memory flips back to the right size. But the data remains invalid, of course.

Here are some facts:

• System: Linux (Debian GNU 8)
• OpenCV 3.0.0-rc1
• System memory: 16GB RAM

You should be able to reproduce this behaviour with the following toy code:

int main(int argc, char **argv)
{
  // create a dummy line with random data
  float random_data[153];
  std::random_device rd;
  std::uniform_real_distribution<float> dist(0.0, 1.0);
  for (int i = 0; i < 153 ; i++) random_data[i] = dist(rd);

  // create a matrix with random data
  cv::Mat random_mat(1,153,CV_32F,random_data);

  // create a destination matrix with one row for the beginning
  cv::Mat dest_mat = random_mat.clone();

  // add rows
  double vm, rss;
  for (int i = 0; i < 12000000; i++) {
    dest_mat.push_back(random_mat);
    if ( (i%10000) == 0 ) {
      process_mem_usage(vm, rss);
      printf("%9d: virtual %8.2fM resident %8.2fM\n",i, vm/1024, rss/1024);
    }
  }
  return 0;
}

The method void process_mem_usage(double& vm_usage, double& resident_set) gets the memory stats from /proc/self/stat can be found multiple times on github and stackoverflow.

The critical lines from output are:
7960000: virtual 6069.54M resident 4768.39M
7970000: virtual 6069.54M resident 4774.32M
7980000: virtual 8396.09M resident 684.29M
7990000: virtual 8396.09M resident 689.96M
... where the memory usage drops and:
11940000: virtual 8396.09M resident 2995.32M
11950000: virtual 8396.09M resident 3001.25M
11960000: virtual 11885.91M resident 7086.56M
11970000: virtual 11885.91M resident 7092.23M
... where the memory usage flips back to the expected size.

I hope that helps to find the Bug.

Cheers, Jens