mkc's profile - activity

Thank you so much for these comments! It saved my time to debug what's wrong with my training!

train_features.rows = 4544, train_features.cols = 2916
train_labels.rows = 4544, train_labels.cols = 1
test_features.rows = 1156, test_features.cols = 2916
test_labels.rows = 1156, test_labels.cols = 1
Training Bayes: trainset: [2916 x 4544] testset: [2916 x 1156]

I am following OpenCV 3 Blueprints' Chapter 5 Object Detection for Industrial Applications by Steven Puttenams

https://www.packtpub.com/application-...

The training was successfully completed and I computed the F1 score to be approximately 0.86 as validated on the training dataset of 523 images (just to test if the training was okay).

Ex.

[root@cobalt workspace]# opencv_traincascade -vec npimages.vec -data output_lbp2/ -numPos 444 -numNeg 888 -bg negatives.txt -numStages 20 -featureType LBP -precalcValBufSize 2048 -precalcIdxBufSize 2048 -w 24 -h 24

However, my main problem is plotting the Precision-Recall Curve (PRC) curve, as suggested in Chapter 5, we could use the ff. to output the score:

detector.detectMultiScale(equalize, objects, levels, scores, 1.05, 1, 0, Size(), Size(), true);

But the score I'm getting have very small variations:

FILENAME    NUM_RECT    X   Y   WIDTH   HEIGHT  SCORE
/home/cobalt/Data/IMG_20160610_170847.jpg   1   190 287 68  68  -1.08848
/home/cobalt/Data/IMG_20160610_170925.jpg   1   186 294 68  68  -1.06534
/home/cobalt/Data/IMG_20160610_170957.jpg   1   189 286 68  68  -1.06534
/home/cobalt/Data/IMG_20160610_171038.jpg   1   191 289 67  67  -0.998512
    ... ... ..  ..  ..  ...
/home/cobalt/Data/IMG_20160610_205103.jpg   1   190 291 68  68  1.82761
/home/cobalt/Data/IMG_20160610_205106.jpg   1   190 291 68  68  1.82761
/home/cobalt/Data/IMG_20160610_205122.jpg   1   194 297 68  68  1.82761

And this gives rather small values for precision-recall:

Ex. coordinates.txt

0.00761905  0.00761905  -1.09
0.00763359  0.00761905  -1.08
0.00763359  0.00761905  -1.07
0.00766284  0.00761905  -1.06
0.00766284  0.00761905  -1.05
0.00766284  0.00761905  -1.04
... ..  ...
0.00952381  0.00761905  1.77
0.00952381  0.00761905  1.78
0.00952381  0.00761905  1.79
0.00952381  0.00761905  1.8
0.00952381  0.00761905  1.81
0.00952381  0.00761905  1.82

With the values above, I cannot get a decent PRC curve. I'm not quite sure what's the problem here.... Though, I can compute the Precision-Recall values using the detect_simple.cpp as I modified it here:

https://gist.github.com/melvincabatuan/45a0de3624e99a5c34d308d4a0b99b45

Ex. Output:

The number of true positives (TP) are: TP = 628.
The number of false positives (FP) are: FP = 185.
The number of false negatives (FN) are: FN = 7.
Precision = 0.772448.
Recall = 0.988976.
F1 Score = 0.867403.

@wuling Thanks for the comment. I had the wrong idea that it has something to do with the OpenCV version.

Nevermind, I modified COLORMAP_JET including its namespace cv and it worked fine:

applyColorMap(src(cv::Range(0, bitmapInfo.height), cv::Range(0, bitmapInfo.width)), output, cv::COLORMAP_JET);

Apparently, this is written in the documentation:

cv::ColormapTypes {
cv::COLORMAP_AUTUMN = 0,
cv::COLORMAP_BONE = 1,
cv::COLORMAP_JET = 2,
cv::COLORMAP_WINTER = 3,
cv::COLORMAP_RAINBOW = 4,
cv::COLORMAP_OCEAN = 5,
cv::COLORMAP_SUMMER = 6,
cv::COLORMAP_SPRING = 7,
cv::COLORMAP_COOL = 8,
cv::COLORMAP_HSV = 9,
cv::COLORMAP_PINK = 10,
cv::COLORMAP_HOT = 11,
cv::COLORMAP_PARULA = 12

}

I encountered the following error while trying to display a JET Colormap for my image:

applyColorMap(src(cv::Range(0, bitmapInfo.height), cv::Range(0, bitmapInfo.width)), output, COLORMAP_JET);

Error:

jni/ImageProcessing.cpp:93:98: error: 'COLORMAP_JET' was not declared in this scope
  applyColorMap(src(cv::Range(0, bitmapInfo.height), cv::Range(0, bitmapInfo.width)), output, COLORMAP_JET);

This is probably a trivial question but if we are using OpenCV3.0, then why are we using 'opencv2' in the include files instead of opencv3?

#include "opencv2/core.hpp"
#include "opencv2/core/utility.hpp"
#include "opencv2/imgproc.hpp"
#include "opencv2/video/background_segm.hpp"
#include "opencv2/videoio.hpp"
#include "opencv2/highgui.hpp"

I have implemented object detection in Android NDK using jni and stevehavelka's assetbridge where the cascade is loaded as follows:

Ex.

if (cat_face_cascade.empty()){
   sprintf( cat_face_cascade_path, "%s/%s", getenv("ASSETDIR"), "lbpcascade_frontalcatface.xml");     

  /* Load the face cascades */
   if( !cat_face_cascade.load(cat_face_cascade_path) ){ 
       LOGE("Error loading cat face cascade"); 
       abort(); 
   };

Full code here:

Cat-detector-Android-jni

However, I want to #include the xml cascade as a c/cpp header file to get rid of the parsing (not sure if this will help speed-up the frame rate, but i would like to try it anyway). Is there an OpenCV implementation somewhere similar to this idea?

Ex.

#ifndef CATDETECT_H
#define CATDETECT_H
/* ...
 * ...
 */

 const int HEIGHT = 24;
 const int WIDTH = 24;

 // etc.

#endif /* CATDETECT_H */

For optimization purposes, I'm avoiding the usage of floating numbers, while maintaining a good enough precision. Thus, I want to use 32 bit depth unsigned integer along with Mat data structure. However, from the basic_structures.html documentation, I didn't find CV_32U. Is there a reason why OpenCV does not support it for Mat data structure?

A complete list of matrix types contains the following values:

CV_8U - 8-bit unsigned integers ( 0..255 )
CV_8S - 8-bit signed integers ( -128..127 )
CV_16U - 16-bit unsigned integers ( 0..65535 )
CV_16S - 16-bit signed integers ( -32768..32767 )
CV_32S - 32-bit signed integers ( -2147483648..2147483647 )
CV_32F - 32-bit floating-point numbers ( -FLT_MAX..FLT_MAX, INF, NAN )
CV_64F - 64-bit floating-point numbers ( -DBL_MAX..DBL_MAX, INF, NAN )

Comprehensive Survey on Distance/Similarity Measures

@Guanta Thanks for the comment. Can you elaborate why you think cosine distance might be a "good enough approximation" of color difference or distance? It does have the speed potential as reported in EVALUATION OF SIMILARITY MEASUREMENT FOR IMAGE RETRIEVAL...

Currently, a standard way of comparing colors is using "Delta E" metric in CIELab [Color-difference] which is based on Euclidean distance in CIELab color space.

However, for certain applications using the distance metric intensively "Delta E" metric could be a bit slow (e.g. RGB2Lab conversion is necessary, floating point operations can be costly, etc.).

Is there a "good enough approximation" of color difference or distance?

Ex.

• Weighted Manhattan distance (L1 distance) (in RGB) (as suggested here)

• Hue Manhattan distance (L1 distance) (in HSV) (as suggested here)

• Any other suggestions?

@LBerger Thanks for the comment. I will try it later, but for now, since I'm applying it to Android NDK, I find creating my own SuperpixelSEEDS class and compiling it with JNI easier.

@StevenPuttemans Thanks for the comment. Mittal et al. context-based proposals to a sliding window shape based detector might be useful in this case. I will try it later. Although, I will drop the skin-based proposals due to the hand-body color similarity.

As stated in the paper's abstract, the author " rely on the OpenCV implementations of k-Nearest Neighbor, Random Forests, and Support Vector Machines classifiers." "I (the author) used the train_auto function of OpenCV, which splits the training set into a certain number of subsets, and perform cross-validation to optimize the parameters, by repeated training and testing using each time one of the subsets as testing set and the others as training set." Parameters used after optimization: C = 10 and epsilon = 0.01.

I was initially expecting 98 % (1.77% error) from the OpenCV-Mnist-Report I read... Well anyway, I already edited it: Training-auto (with feature vector normalization) raised the accuracy to almost 80 %!

Problems:

1. Detect the hand over the human body (Note: color is very similar).
2. Localize the position of the touch
3. Track the movement as the hand moves along the body.

Here's a sample input image frame:

I have tried a few possible solutions:

1. Contour detection (It doesn't work! Or maybe I miss a few additional tricks?)

2. Color Segmentation (It doesn't work! Similarity of color between the hand and skin is a big problem)

3. Keypoints (e.g. SIFT, SURF, ORB, AKAZE)? (It might work! However, the hand movement itself is non-rigid thus, the comparison might end up inconsistent.

4. Object Detection (e.g. Haar or LBP) (It might work! But then again, the non-rigidity of hand movement might cause a serious problem.)

5. Background Subtraction/ Motion segmentation (It might work; but if the belly is bulky, then, there will be motion all over the region. Furthermore, the examiner's arm or body will be in motion as well....)

6. More Machine Learning (RT, SVM, KNN, MLP etc.) (It might work? )

Does anyone (else) have experienced similar problems that involve the above issues? Thanks in advance.