2020-04-04 13:03:08 -0600 | received badge | ● Notable Question (source) |
2018-11-13 03:02:15 -0600 | received badge | ● Popular Question (source) |
2018-04-16 14:41:38 -0600 | commented question | Undistorting a depth map The improved one looks very similiar to the first image (distortion of the camera was low). That's also what I expected. |
2018-04-16 14:34:31 -0600 | commented question | Undistorting a depth map The improved one looks very similiar to the first image (distortion of the camera was low). That's at least what I expec |
2018-04-16 13:53:42 -0600 | commented question | Undistorting a depth map Okay, it is answered. I used CV_INTER_LINEAR and my depth map has extreme outliers. These outliers seem to dominate over |
2018-04-16 13:36:00 -0600 | asked a question | Undistorting a depth map Undistorting a depth map Hey guys, I am currently trying to undistort a floating point mat (CV_32F) with the distortion |
2018-02-24 01:04:40 -0600 | received badge | ● Enthusiast |
2018-02-23 05:38:45 -0600 | edited question | OpenCV 3.4: Inpainting float mat produces visual artifacts OpenCV 3.4: Inpainting float mat produces visual artifacts Hey guys, I am currently working with the fresh new opencv c |
2018-02-23 05:38:36 -0600 | edited question | OpenCV 3.4: Inpainting float mat produces visual artifacts OpenCV 3.4: Inpainting float mat produces fragments Hey guys, I am currently working with the fresh new opencv core fun |
2018-02-23 05:38:16 -0600 | edited question | OpenCV 3.4: Inpainting float mat produces visual artifacts OpenCV 3.4: Inpainting float mat produces fragments Hey guys, I am currently working with the fresh new opencv core fun |
2018-02-23 05:37:38 -0600 | asked a question | OpenCV 3.4: Inpainting float mat produces visual artifacts OpenCV 3.4: Inpainting float mat produces fragments Hey guys, I am currently working with the fresh new opencv core fun |
2018-02-15 09:50:14 -0600 | commented question | Bug: xphoto::Inpaint crash without exception Sorry, didn't see your answer. Installed opencv 3.4 and it works now. I think it stills bugs, when the images are too sm |
2018-02-14 03:37:43 -0600 | edited question | Bug: xphoto::Inpaint crash without exception Bug: xphoto::Inpaint crash without exception Hey guys, I compiled opencv with contrib module. It works well, however as |
2018-02-14 03:35:10 -0600 | edited question | Bug: xphoto::Inpaint crash without exception Bug: xphoto::Inpaint crash without exception Hey guys, I compiled opencv with contrib module. It works well, however as |
2018-02-14 03:34:29 -0600 | edited question | Bug: xphoto::Inpaint crash without exception Bug: xphoto::Inpaint crash without exception Hey guys, I compiled opencv with contrib module. It works well, however as |
2018-02-14 03:33:06 -0600 | asked a question | Bug: xphoto::Inpaint crash without exception Bug: xphoto::Inpaint crash without exception Hey guys, I compiled opencv with contrib module. It works well, however as |
2017-01-27 10:57:54 -0600 | asked a question | Failed to open FileStorage Hey there, my problem is a little bit confusing. My code fails to open a FileStorage despite having the correct relative or absolute path. I think I isolated the problem down to not "being a problem of usage", but library confusion in the background. On my Ubuntu 16.04 I installed OpenCV 2.4.9 for some random image processing projects. I also installed ROS Kinetic with OpenCV 3.1 for some other stuff. The problem described above only occures, when I try to use my code in a ros environment. When building a project with the same code without ros it works like a charme. So what to do? Is this some kind of linking magic problem? Thanks for your help in advance and best regards, Alex UPDATE: Removed opencv 2.4.9, rebuilt all projects. Still not able to read config. Even worse: Now the other code won't work either. So I guess it has something to do with ros opencv3.1 :[ |
2016-07-27 01:31:06 -0600 | commented question | Mat and imread memory management Point for you. Sometimes I lack the basic skills. :D I got 5.8 gb of rams following the system monitor. The 3.6 Gb would be enough to kill it. |
2016-07-27 01:02:18 -0600 | commented question | Mat and imread memory management @berak: Hm okay, but do 100 images sound too much for a RAM to handle for you (4000 x 3000 px)? And 300 mb expanding to 3 GB? |
2016-07-27 00:59:38 -0600 | received badge | ● Supporter (source) |
2016-07-27 00:58:54 -0600 | commented answer | Mat and imread memory management 1) Good point, I will try this one as soon as I can! 2) The release statement was in fact just there to check, if it changes anything concerning the memory problem. I already removed it. :) 3) This one I will also check and let you know what happens! Not saving them in some way would be a challenging task. I am writing a dynamic stitching process and at different points of the programm old data (first measurement for example) may be accessed. Reading it from the disk then might be not so optimal. Especially as you said: 100 images do not sound too much to me :S However thanks, I will test your advice and give you feedback if it succeeded! |
2016-07-26 12:36:53 -0600 | commented question | Mat and imread memory management |
2016-07-26 05:13:58 -0600 | received badge | ● Editor (source) |
2016-07-26 05:13:11 -0600 | asked a question | Mat and imread memory management Hey there, I am looking for the "best practice" to save a lot of images of type cv::Mat in the cache. Is it okay if I just push_back them in a vector< Mat > and get back as soon as I need them? Reason for my question is, that I tried to load ~150 images (300 Mb) with imread and after 100 the system starts to slow down extremely. After having a look at the monitoring I noticed that the RAM of 5 GB is getting trashed until it breaks down. Code snippet for my image reading below: Thanks in advance for an answer! Lax |
2016-07-07 11:08:11 -0600 | commented question | Why is findHomography() so fast? I want to use Ceres as global refiner. Therefore my algorithm wasn't meant to compare 2 homographies but 10 or more. However as I was testing around in a sequence of images I calculated a Homography by findHomography() and afterwards let my Ceres refinement optimize them. The solution was pretty much the same (just slightly better with Ceres) but as I said at least 10 times slower. No scientific comparison, but it seemed a little suprising to me. |
2016-07-07 10:48:12 -0600 | asked a question | Why is findHomography() so fast? Hey there people, maybe I got a silly question for you, but I am quite interested in the answer and have not found out myself yet: Why is findHomography() so fast? I mean okay, with good inlier/outlier ratio and RANSAC we will find a very good initial solution for a homography. But still with 300< features the final refinement is so fast, I got computation times of less than 10 ms total, while testing with Googles Ceres Solver my Estimations are easily 10 times slower. Is there a smart logic behind the algorithm that reduces the computational costs of homography refinement or is the chance high, my Ceres Code is just bad? Thanks in advance for any good hint! |
2016-01-09 07:26:58 -0600 | commented question | Feature detection and matching for localization (openCV.3) There are multiple strategies to improve your results. 1) Adding some filtering for the matching results. You can think about your own filters, one very common is known as "ratio test". You take your feature and divide your best with your second best match. Bad matches have a ratio below 0.8, because their matches are far away from each other. Another test is known as "symmetry test". Google that, you will find some code for both. 2) You increase your amount of features. Sometimes your features look good, but if you have too few of them, the algorithm can't find just the right match. 3) Building your opencv with the additional packages for sift and surf trying other feature detection and matching algorithms. |
2016-01-09 06:53:37 -0600 | commented question | Bad feature matching I was afraid that is the answer to it. But yesterday I tested a little bit with the amount of image features in relation to image size, realizing this was my biggest issue. My images were full sized with way too few features. As a result I got the warped image below pre resizing. After resizing my results still don't match perfectly, but I guess without bundle adjustment that's the best shot I can get. |
2016-01-07 21:07:00 -0600 | asked a question | Bad feature matching Hello there people, I am currently working with OpenCV 3.1 trying to make some realtime stitching of aerial images possible. However I am just starting and do have my troubles with feature matching. It's just not good enough and I don't really know what may left to do. Workflow: - Loading images - Detecting features with ORB - Extracting features with ORB - Matching with BruteForce (Hamming-(2)) - Ratio test - Symmetry test - Calculating Homography using RANSAC - Warping But still, my matches (without RANSAC) look like that: |