strann's profile - activity

Thanks @matman for an answer!

The overhead was caused by OpenCL code initialization. I added #include<opencv2/core/ocl.hpp> and switched off OpenCL usage before calling merge(InputArrayOfArrays _mv, OutputArray _dst) . Now it works as I expected.

cv::ocl::setUseOpenCL(false)
vector<cv::Mat> images(numcomps);
for (int i = 0; i < numcomps; i++)
    images[i] = cv::Mat(h, w, CV_32SC1, (image->comps + comps[i])->data);
cv::merge(images, imageMat);

thank you, that helped!

Hello,

I used following code snippet to merge a few single channel images into a multichannel Mat:

vector<cv::Mat> images(numcomps);
for (int i = 0; i < numcomps; i++)
    images[i] = cv::Mat(h, w, CV_32SC1, (image->comps + comps[i])->data);
cv::merge(images, imageMat);

On my machine this code execution time is about 500 ms (!!!), regardless of number of elements in vector<cv::Mat> images (i.e. even if numcomps == 1). What can be the reasons behind such an overhead?

If I rewrite code as follows it reduces execution time to 2 ms:

cv::Mat result(h, w, CV_MAKETYPE(CV_32S, numcomps));
vector<cv::Mat> images(numcomps);
for (int i = 0; i < numcomps; i++)
{
    int from_to[] = { 0,i };
    images[i] = cv::Mat(h, w, CV_32SC1, (image->comps + comps[i])->data);
    cv::mixChannels(&images[i], 1, &result, 1, from_to, 1);
}
imageMat = result;

I'm using OpenCV 3.1.0 built with CUDA 7.5 (Ubuntu 14.04, Intel® Core™ i3-4170 CPU @ 3.70GHz × 4, GeForce GTX 960/PCIe/SSE2 ).

Cheers, Kate

When you do imagesArg.push_back(img) you push back a pointer to the local variable Mat img which soon goes out of scope. If you want to save the data you should imagesArg.push_back(img.clone()) instead. Also because img already goes out of scope on the next iteration you don't have to release it

Do the screenshots overlap?

No, OpenCV doesn't support GDAL for writing. I also had problems opening BIL and BSQ formats. To save a 50 channels Mat to a file you might want to use GDAL or LibTIFF.

Hello,

To compute a histogram of a CV_8U image (values between 0 and 255) knowing that the upper boundary in histRange is exclusive, we have

int histSize = 256;
float range[] = { 0, 256 } ;
const float* histRange = { range };
calcHist( &image, 1, 0, Mat(), histogram, 1, &histSize, &histRange );

Now assume I have an CV_32F image with values between (and including) 0 and 255 and I want to build a histogram with histSize = 1000. If the upper boundary of histogram ranges is exclusive then how to specify it properly not to lose the maximum value (255)?

I tried the code below but I'm not sure if I'm right

int histSize = 1000;
float binSize = (255 - 0) / histSize;
float range[] = { 0, 255 + binSize } ;
const float* histRange = { range };
calcHist( &image, 1, 0, Mat(), histogram, 1, &histSize, &histRange );

As far as I know OpenCV doesn't provide methods to retrieve metadata from GeoTiff. Moreover OpenCV can't handle images with band interleaving. So I would suggest loading images with GDAL C++ API or LibTiff and than converting to cv::Mat.

Are you using GDAL C++ API to open images or OpenCV with GDAL support?

Yes, I understand how to do feature matching, thank you. I mean I could first perform directly the whole image detection and after that split the image into a grid and perform detection cell-wise. So I would have like global and local features?

@Mathieu, does it make sense to take into account both features detected in the whole image and features detected in each cell of the grid?

I believe I saw the algorithm in Stitching pipeline in OpenCV 3.1, but back then I didn't guess why splitting an image into a grid. Thank you!

Hello,

I'm working on stitching aerial images taken with an UAV. My approach works fine for some nadir datasets, but fails for others. I believe that one of the reasons is that for some images most of the keypoints found by ORB are concentrated in some parts of an image, but not over the entire image. How can I achieve more uniform distribution of keypoints using ORB?

Now I use following parameters:

Ptr<ORB> orb = ORB::create(3000, 1.0, 1, 31, 0, 2, ORB::HARRIS_SCORE, 31, 20);

What code the program has exited with? Cannot find or open the PDB fileare just warnings which have no influence in the execution of your application. PDB files are the symbols that you can use to debug in the IDE. See http://answers.opencv.org/question/12...

Starting from OpenCV 3.0 features2d module has been reorganized (some feature detectors has been moved to opencv_contrib/xfeatures2d module) and nonfree module has been removed. So to use SURF you should include opencv2/xfeatures2d.hpp instead of opencv2/nonfree/nonfree.hpp. Please refer to example http://docs.opencv.org/ref/master/tut...

Maybe you could build a histogram and count number of non-zero elements (using cv::countNonZero(mat) )?

You can perform band math using element-wise operations like this

    vector<Mat> channels;
    split(imageBGR, channels);
    Mat numeratorMat = channels[2] - channels[0]; // red - blue
    Mat denominatorMat = channels[2] + channels[0]; // red + blue
    Mat ratio;
    cv::divide(denominatorMat, numeratorMat, ratio, 1., 5); // here 5 specifies type of ratio (CV_32FC1)

Then you can do something like

   Mat newHue = (ratio.clone() - 0.5 ) * (-360); // float 32
   Mat newLigthness = Mat::ones(imageBGR.rows, imageBGR.cols, CV_32FC1);
   Mat newSaturation = Mat::ones(imageBGR.rows, imageBGR.cols, CV_32FC1);

   vector<Mat> newChannels;
   newChannels.push_back(newHue);
   newChannels.push_back(newSaturation);
   newChannels.push_back(newLigthness);
   Mat newHSL;
   cv::merge(newChannels, newHSL);

what have you tried so far?

Is there any reason I should not use a macro for fast element access in C++ API (like CV_MAT_ELEM_PTR_FAST in C API)? Here's my implementation

 #define MY_MAT_ELEM_PTR_FAST( mat, row, col, elemtype )  \
(assert( (unsigned)(row) < (unsigned)(mat).rows &&   \
         (unsigned)(col) < (unsigned)(mat).cols ),   \
   (* (elemtype*) ( (mat).data + (mat).step*(row) + (sizeof(elemtype)*(col)) ) ) )

I believe it is, at least in C++ API calcHist() works correctly with negative float values in range

Hello,

Documentation for OpenCV 3.0 states that calcHist() function takes as input images of depths CV_8U or CV_32F. But from source code it seems the function can be used for 16-bit images in OpenCV 3.1. Is it undocumented yet or I shouldn't use it?

else if( depth == CV_16U )
    calcHist_<ushort>(ptrs, deltas, imsize, ihist, dims, ranges, _uniranges, uniform )