grtwa's profile - activity

Thank you. I rebuild OpenCV 2.4.9 with TBB 4.2, but the memory leaks still exist.

I build OpenCV 2.4.9 with TBB 4.1, and call cvtColor in the following two pieces of code. Both of them report memory leaks. How can I avoid the memory leaks? Many thanks.

void main()

{ _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

cv::Mat colorImage(320,480,CV_8UC3);
cv::Mat grayImage;
cv::cvtColor(colorImage,grayImage,CV_BGR2GRAY);

}

void main()

{ _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

cv::Mat colorImage(320,480,CV_8UC3);
cv::Mat grayImage(320,480,CV_8UC1);
cv::cvtColor(colorImage,grayImage,CV_BGR2GRAY);

colorImage.release();
grayImage.release();

}

Thanks, I need deal with some degenerate case. Before using SVD, I intended to use QR. But DECOMP_QR seems to equate with DECOMP_SVD in OpenCV2.4.5.

I have solved this problem by convert the compiling platform to x64. On x86 platform, only 2G physical memory can be used.

have done, thanks :)

Sorry, I have not 50 points to accept my own answer.

OpenCV is correct. Similar with vlfeat,"c_rot" and "r_rot" have been normalized by "hist_width", so the sigma is "d/2".

@StevenPuttemans, "New users must wait 2 days before answering their own question." I will post an answer later. Thank you for reminding.

@Moster, I did not try because I think automatic variables are created on the heap. Any way, problem is gone :)

For the LK, strong corner are the best points. I think FAST is good enough for tracking.

Thank you. I have solved this problem by convert the compiling platform to x64. On x86 platform, only 2G physical memory can be used. It's my fault, not OpenCV :)

I use the function "cv::solve(src1, src2, dst, DECOMP_SVD)" to solve a least-squares problem (i.e., src1 * dst = src2). The size of src1 is 29030 * 7809 and the size of src2 is 29030 * 122. Both types of src1 and src2 are CV_32FC1. OpenCV crashes at the 1370 line of "lapack.cpp" and the code of this line is "buffer.allocate(bufsize)". "buffer" is a "AutoBuffer< uchar >" and "bufsize" is 1151016404. Is this problem caused by out-of-memory? My physical memory is 8G and operating system is 64bit Win7.

Mat A(29030,7809,CV_32FC1);
Mat b(29030,122,CV_32FC1);
for(i=0;i<29030;i++)
{
    for(j=0;j<7809;j++)
        A.at<float>(i,j)=float(i*7809+j);

    for(j=0;j<122;j++)
        b.at<float>(i,j)=float(i*122+j);
}

Mat x;
solve(A,b,x,DECOMP_SVD);

Which app you downloaded? Can you modify its source code?

As far as I know, there is no open source code. Maybe you can classify them by shape and I think it is not a good idea to classify by key points and descriptors.

I see. Similar with vlfeat,"c_rot" and "r_rot" have been normalized by "hist_width", so the sigma is "d/2". Thanks for Guanta and StevenPuttemans' help.

Sorry, it is not exact. I think 32x32 means (2xwidth+1)x(2xwidth+1), so width is 15.5 and Sigma is 7.75.

In David G. Lowe's paper, the Sigma of Gaussian weighting function is one half the width of the descriptor window. If the descriptor window is 32x32 pixels with 4x4 subregions, I think the Sigma should be 8 rather than 2. But in sift.cpp, the code is "float exp_scale = -1.f/(d * d * 0.5f)", which means the Sigma is 2. Is there anything wrong?

I also suffered this problem. Everything went well when compiling without CUDA,but I need to use CUDA. Any help is greatly appreciated.