RSS

Category Archives: OpenCV

OpenCV-related tips

  1. To get the same results from PC and Android platforms with the same source codes.
    1. For matrix inverse function, that is inv(), there are many options namely DECOMP_SVD, DECOMP_EIG, DECOMP_LU and DECOMP_CHOLESKY.
      If you want the inversion result of PC and that of Android to be the same, you should use either DECOMP_SVD or DECOMP_EIG.
      However the results of DECOMP_SVD and DECOMP_EIG are also different for the same input.  For my work, DECOMP_SVD seems to give better result than DECOMP_EIG.
      For the issue of speed, I checked the processing times for DECOMP_LU, DECOMP_SVD and DECOMP_EIG and found there is no such a difference in their running times.
    2. For arc-tangent, there is a OpenCV function fastAtan2().
      If you want the arc-tangent return values of PC and Android to be the same, you should use fastAtan2() instead of atan2() of “math.h”
      For the issue of speed, I checked the speeds of atan2() and fastAtan2() and got strange results. In Debug mode, fastAtan2() is faster than atan2() as the name implies.  In Release mode, however, atan2() is much faster than fastAtan2() and it took almost 0 millisecond for processing atan2().  (I might have done something wrong)
    3. For random number generation, there are functions rand() and srand() of “stdlib.h”.  OpenCV also provides random number generator class cv::RNG.
      Sometimes you have to compare the (intermediate) results of PC and Android version of the same source codes so that you should remove the randomness in your codes. In other words, if you want for the sequences of generated random numbers from PC and Android to be fixed and the same, you should use cv::RNG with a fixed seed such as RNG(1234567) instead of rand() of “stdlib.h”.  Even if you give a fixed seed to srand() such as in srand(1234567), it will give you different fixed random sequences for PC and Android. In fact, this will give the same random sequence every run for PC.  And it will do so for Android.  However, the sequences for PC and Android will not be the same.  To get the same fixed random sequence with the same source codes, you should use cv::RNG as in the following example.

      cv::RNG rng = RNG(12378213);
      float randomF = rng.uniform(5.f, 45.f);
      int randomI = rng.uniform(5, 45);
      double randomD = rng.uniform((double)5, (double)45);
      

      In addition, there are some OpenCV functions such as cv::solvePnPRansac() which use random number generator internally.  If you want such a random function to give the fixed and same results in every run, you should give a fixed seed such as in following.

      theRNG().state = 1234567;
      cv::solvePnPRansac(blah, blah, blah, ...);
      
  2. About reading gray image file.
    There are many options for the funtion cv::imread(), namely
    IMREAD_UNCHANGED =-1,
    IMREAD_GRAYSCALE =0,
    IMREAD_COLOR =1,
    IMREAD_ANYDEPTH =2,
    IMREAD_ANYCOLOR =4
    and the default is IMREAD_COLOR.
    If you read a gray image file with the default option IMREAD_COLOR, the resulted Mat (say matCOLOR) has 3 channels as a color image.  If you split matCOLOR into 3 channels(red, green and blue) with the function cv::split(), the resulted blue, green and red matrices (say matBlueFromCOLOR, matGreenFromCOLOR and matRedFromCOLOR respectively)  are all identical.  If you convert matCOLOR to a gray image (say matGrayFromCOLOR) using cv::cvtColor(CV_BGR2GRAY), matGrayFromCOLOR is also identical to the blue, green and red matrices.
    If you read the gray image file with the option  IMREAD_GRAYSCALE or IMREAD_UNCHANGED, the resulted Mat (say matGRAYSCALE or matUNCHANGED respectively) is also identical to the converted Mat matGrayFromCOLOR.
    In short, for a gray image file, the following Mats are all identical.
    matBlueFromCOLOR, matGreenFromCOLOR, matRedFromCOLOR,
    matGRAYSCALE, matUNCHANGED, matGrayFromCOLOR
 
Leave a comment

Posted by on December 16, 2015 in OpenCV

 
Link

head pose estimation

 
Link

OpenCV feature tracker

 
Leave a comment

Posted by on April 21, 2014 in Computer Vision, OpenCV

 

image data access in OpenCV 2 or later.

Scrapped from : http://tech.groups.yahoo.com/group/OpenCV/message/84478

Since 2009 with the launch of OpenCV 2, you can count with the new C++ interface, much better than the C style older version. I suggest two ways you can access pixels values. My notes are based on the book OpenCV 2 Computer Vision Application Programming Cookbook, by Robert Laganière.
1. Direct access to pixels values:
     // Test for gray level image
    if (image.channels() == 1) {
        image.at<uchar>(j, i) = …;           // j runs on rows, i runs on cols
    } else if (image.channels() == 3)   // color image
       image.at<cv::Vec3b>(j, i)[0] = …;
       image.at<cv::Vec3b>(j, i)[1] = …;
       image.at<cv::Vec3b>(j, i)[2] = …;
   }
   The image was created as: cv::Mat image = cv::imread(“img.???”);
2. Scanning image with pointer:
    uchar *pixel;
     cv::Mat image = cv::imread(“img.???”);
     . . .
    for (int j = 0; j < nRow; j++) {
          // Get the address of row j
          pixel = image.ptr<uchar>(j);
          for (int i = 0; i < nCol; i++) {
                // process each pixel
               pixel[i] = …;
               …
          }
     }
choose one method and good job!
 
1 Comment

Posted by on November 23, 2011 in OpenCV

 

Problems with solvePnP

scrapped from : http://tech.groups.yahoo.com/group/OpenCV/message/72678

Re: Problems with solvePnP

I have tried using both “cvFindExtrinsicCameraParams2()” from the C interface
and “solvePnP()” from the C++ interface, because I wasn’t sure of the
difference. I found out that they are exactly the same (it would be good if this
was mentioned in the documentation!), but if you use floating-point values for
the outputs of solvePnP instead of doubles, then it gives extremely large or
extremely small results, just like you guys noticed.

Can someone please update the official C++ documentation to say that
cv::solvePnP() is the C++ equivalent to cvFindExtrinsicCameraParams2(), and that
the rotation & translation outputs should be doubles instead of floats?
(Assuming this is not considered a bug).

The outputs I get on OpenCV 2.0.0 with VS2008 on 32-bit WinXP is shown below.
Notice that the results are all identical between tests (give or take 0.0001%)
except for the last test of solvePnP() with floats.

###### Using <double> cvFindExtrinsicCameraParams2(): ####
Rotation Axis: 0.717367, 0.954479, 0.198497.
Angle: 1.21039 radians (69.3503 deg).
Translation Vector: 324.518, 52.6191, 591.712

###### Using <double> cv::solvePnP(): #####################
Rotation Axis: 0.717367, 0.954479, 0.198497.
Angle: 1.21039 radians (69.3503 deg).
Translation Vector: 324.518, 52.6191, 591.712

###### Using <float> cvFindExtrinsicCameraParams2(): ######
Rotation Axis: 0.717366, 0.954479, 0.198497.
Angle: 1.21039 radians (69.3503 deg).
Translation Vector: 324.518, 52.6191, 591.712

###### Using <float> cv::solvePnP(): ######################
Rotation Axis: -2.1e-032, 1.804, 2.6e+008.
Angle: 2.6e+008 radians (1.5e+010 deg).
Translation Vector: -1.09e-010, 3.81691, -2.82e-039

Cheers,
Shervin Emami.

 
Leave a comment

Posted by on July 23, 2010 in Computer Vision, OpenCV, Programming

 

Tags:

openCV video capture properties

OpenCV 1.0

#define CV_CAP_PROP_POS_MSEC       0
#define CV_CAP_PROP_POS_FRAMES     1
#define CV_CAP_PROP_POS_AVI_RATIO  2
#define CV_CAP_PROP_FRAME_WIDTH    3
#define CV_CAP_PROP_FRAME_HEIGHT   4
#define CV_CAP_PROP_FPS            5
#define CV_CAP_PROP_FOURCC         6
#define CV_CAP_PROP_FRAME_COUNT    7
#define CV_CAP_PROP_FORMAT         8
#define CV_CAP_PROP_MODE           9
#define CV_CAP_PROP_BRIGHTNESS    10
#define CV_CAP_PROP_CONTRAST      11
#define CV_CAP_PROP_SATURATION    12
#define CV_CAP_PROP_HUE           13
#define CV_CAP_PROP_GAIN          14
#define CV_CAP_PROP_CONVERT_RGB   15

OpenCV 2.0 (three more options than 1.0)

#define CV_CAP_PROP_POS_MSEC       0
#define CV_CAP_PROP_POS_FRAMES     1
#define CV_CAP_PROP_POS_AVI_RATIO  2
#define CV_CAP_PROP_FRAME_WIDTH    3
#define CV_CAP_PROP_FRAME_HEIGHT   4
#define CV_CAP_PROP_FPS            5
#define CV_CAP_PROP_FOURCC         6
#define CV_CAP_PROP_FRAME_COUNT    7
#define CV_CAP_PROP_FORMAT         8
#define CV_CAP_PROP_MODE           9
#define CV_CAP_PROP_BRIGHTNESS    10
#define CV_CAP_PROP_CONTRAST      11
#define CV_CAP_PROP_SATURATION    12
#define CV_CAP_PROP_HUE           13
#define CV_CAP_PROP_GAIN          14
#define CV_CAP_PROP_EXPOSURE      15
#define CV_CAP_PROP_CONVERT_RGB   16
#define CV_CAP_PROP_WHITE_BALANCE 17
#define CV_CAP_PROP_RECTIFICATION 18

 
Leave a comment

Posted by on July 20, 2010 in OpenCV, Programming

 

Tags: , ,

Free SIFT / SURF alternatives

Scrapped from http://tech.groups.yahoo.com/group/OpenCV/message/72592

I’ve tested the SIFT/SURF alternatives mentioned in a post by Gary last year and found them lacking.

FAST detector for keypoints – does not characterize keypoints (it’s fast, though)

Self-similarity features for keypoints (code by Rainer Lienhart) is IMHO patented by Shechtman & Irani as US patent (application), see e.g. http://www.faqs.org/patents/app/20100104158 (IMHO the US patent office allows to put in patents up to one year after publication)

Fast Keypoint Recognition using Random Ferns – similar speed and accuracy as SIFT/SURF, but needs far too much memory. I’ve measured 500M per object recognized even after optimizing the parameters in find_obj_ferns.cpp to reduce memory requirements. IMHO it does not make sense to train one fern classifier on multiple keypoints from the same object so this memory footprint would be incurred for each object to be recognized. E.g. to recognize 76 magazine pages like here (video done by myself), you’d need a whooping 34TB of main memory – not feasible.

http://www.youtube.com/user/SeewaldSolutions#p/f/3/1QceIPixocw

Given that cvSURF works reasonably well on small devices (I made it to about 1 fps on a recent Android model), which have nowhere that much memory, I currently don’t see any _feasible_ alternatives to SIFT/SURF for large-scale object recognition in OpenCV. Any idea/pointers? What can I do to fix this?

 
Leave a comment

Posted by on July 20, 2010 in Computer Vision, OpenCV

 

Tags: , , ,