RSS

Monthly Archives: December 2015

Role of size of calibration pattern in camera calibration

When using Camera Calibration Toolbox or OpenCV camera calibration, we are asked to provide the size of width and height of a grid in the the chessboard.  So we measure the length with a ruler (in millimeter or meter) and type the length into the program.

When the measured width and height of a grid are 25 mm and 25 mm, what will happen if we provide the width and height as 2500 mm and 2500 mm (which are wrong and hundred times bigger than the real size) respectively to the program.  The answer is that it does not make any difference to the intrinsic parameter values and this implies the unit of focal length as the output of calibration software above is NOT mm or meter BUT pixels.  (Actually it affects only translation, that is, part of extrinsic parameters of each camera frame, which is unimportant calibration results).  This also implies that if the image size (resolution) is big enough, it is OK to use a small chessboard such as the one printed on a A4 paper sheet.

This also means it is up to scale, that is, when the actually measured width and height are 25 and 50 mm respectively, it is okay to provide such a pair of scaled values (250, 500), (25000, 50000) , (1, 2) or (0.001, 0.002) as long as the ratio of width and height is the same as that of the real size (here 1 : 2).

What if, we provide the width and height value whose ratio is not the same as the measured one?  In other words, if we provide 250 and 750 as the width and height of grid (ratio 1 : 3), the program will not run properly giving complain or very strange intrinsic parameters.  Because with a chessboard of grid ratio 1 : 3, it might be impossible to get such images (of chessboard with ratio 1 : 2) taken by the camera to be calibrated.

 
Leave a comment

Posted by on December 16, 2015 in Computer Vision

 

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

 

The acknowledgement

“This book is dedicated to XXX, without whom it would never have been started, and to YYY, without whom it would never have been finished.”

This is the acknowledgement of a book I took a look at today.  I have seen some acknowledgements with “never have been started” or “never have been finished”.  But not both.   It sounds much more beautiful with both than each.  It does not seem to be likely for me to have something to publish a book about under my name in my life.

 
Leave a comment

Posted by on December 14, 2015 in Misc