2019-05-01 10:30:12 -0600 | received badge | ● Notable Question (source) |
2017-07-31 03:59:07 -0600 | received badge | ● Popular Question (source) |
2016-07-20 07:37:01 -0600 | asked a question | OpenCV 3.0.0+IPP segmentation fault Hi, there is some issue which haunts me for quite a while now. I'm running a multithreaded algorithm, which loads an image in each thread and performs a sobel filter on it, before doing some other stuff which I coded by myself. I compiled the 3.0.0 source with IPP enabled. On rare occasions (Voodoo: mostly when I run the program the first time I powered my computer?) the application crashes in cvtColor(), which I run before applying the sobel filter on it. Debugger says it crashes in CV_IPP_CHECK(), in detail in useIPP() in which again cv::TLSData<cv::coretlsdata>::get() is called. Whatever cv::TLSData<cv::coretlsdata> is, it's pointer seems to be NULL on that occasion. Most of the time this is not happening again afterwards and the program is running quite fine. Can someone maybe explain to me what cv::TLSData is? Might this be some initialization issue? Is this call threadsafe? Windows 7, VS2008. Thank you in advance. |
2013-11-12 07:10:15 -0600 | asked a question | SGBM double matching? Hi there, is SGBM actually doing a double match to check for the disp12MaxDiff parameter, I mean is it doing a Left-Right match and Right-Left match to check for disparity consistency? I need to know, because otherwise I would check for it from the outside. Thanks! |
2013-10-17 09:14:13 -0600 | commented question | features2d: Keypoint matching very slow Reducing the size would be a possibility, but actually I want to maximize the number of obtained keypoints. I used the distance ratio and knn match with k=2 to drop ambigous points, I dind't use cross matching of the matcher if this is what you mean, since it needs k=1 to be set in the knn match afaik. But at the moment I'm satisfied with the first results, it's not superfast but fast enough and gives quiet good results. |
2013-10-04 05:50:25 -0600 | commented question | features2d: Keypoint matching very slow Well thank you for the link, I think I'm a little bit wiser now, answers my questions. I actually could break down the computation time of the binary descriptors by using FLANN with LSH indices. BRISK this way also gave me some good matches for images with much perspective change in a reasonable time. |
2013-10-04 03:23:20 -0600 | received badge | ● Editor (source) |
2013-10-04 03:21:25 -0600 | asked a question | features2d: Keypoint matching very slow Hello! I'm using OpenCV features2d to match a pair of high resolution images for stereo reconstruction. What I do looks as follows:
Basically this works fine for me. I retrieve between 60000 and 120000 initial keypoints from the images. BUT: Some combinations of Detector/Extractor/Matcher need a lot of time to finish. For the time measurements here I measured detecting/extracting/matching. Surf/Surf/FLANN takes about 82 seconds. This amount of time is reasonable for my needs. It gives me about 100k initial keypoints. My parameters here are as follows. 6 octaves, 2 layers per octave, hessian thres. 50, extended descriptors Surf/Freak/BFMatcher needs 9m 50s which is quite a long time, with more than 9 min spent for matching. Surf has the same config as before. Is there a way to speed this up? Should FLANN with LSH give a speedup here? Does the time BFMatcher needs solely depend on the total number of descriptors, or does the quality of the descriptors have an influence on this? http://answers.opencv.org/question/924/lsh-matching-very-slow/ Looking at these time emasurements for 1.000.000 ORB descriptors I wonder. Are ORB descriptors faster to match than FREAK ones? Have they been matched on the GPU? If you have some additional advice for me I would appreciate it. I need as much good matches as I can get :). Thanks |