I was wondering if there is any good method to make SGBM process faster, by taking the info from the previous video frame.
I think that it can be made faster by searching correspondences only near the distance of the disparity of previous frame. The problem I see in this is when from one frame to the next, the block passes from an object to background of viceversa. I think, in case to be possible, is an interesting improve to be made, and I have looked for it but I didn't find it.
You have told what is the problem, if the scene is in motion.
I managed to wrote some algorithm that take in consideration the critical zone around the objects' borders, they were a little more accurate but very slower than SGBM.
Maybe you can simply set the maximum and the minimum value of disparity in a reasonable range of what you find in the previous frame instead of "safe values". In my experience wuth OpenCV, stereoBM is faster but not so good as SGBM, and SGBM is better optimized than any other algorithm written by oneself (always in my experience).
Maybe you can have some better (faster) result using the CUDA algorithm (SGBM processed in GPU). My group and I are working on that.
Related
I looked up some tutorials on accessing pixel values in C++ with OpenCV. For an example of modifying every pixel value, using .ptr is faster than using .at
I realize that how you calculate the new value for assignment also influence your performance, but I wonder if using .ptr is alway faster than .at?
Even if what I do is comparing a pixel with its neighbor pixels?
I'm writing a code to find out if a pixel were maximum/minimum around its 8 neighbor pixels and other 18 more pixels from two different Gaussian-blurred (different sigma) images. (Yes, for SIFT) I'm currently using .at to access pixel value, and I can tell the code takes some time to run (Cuz there are many images need to go through the same process). I wonder if using .ptr will make performance better or not.
The documentation says that the pointers method is the fastest in every case. The other methods are only safer.
It also says that the .at() method is the most time consuming, this should explain your lack in performances
I want to compute the disparity map in Windows platform. I have used several codes on the internet, but I can't compute precision disparity map. I have used Opencv SGBM algorithm, but the disparity map was very noisy. could any one introduce an efficient code?
Thanks in advance for you
Well, stereo vision is always a decision between speed and accuracy. You can't have both. SGM or SGBM are already doing a pretty good compromise here. If you want very high precision you can move towards true global algorithms such as belief propagation, but expect several minutes computation time for processing a single camera frame.
If you want fast processing, you can use block matching. But here you will get poor performance on low texture surfaces and effects like foreground fattening.
The only way to speed things up is to switch to a hardware that is capable of massively parallel processing. There exist some great FPGA-based solutions for stereo vision like this one:
https://nerian.com/products/sp1-stereo-vision/
Also using a (high-end) graphics card would be an option. There exist several research papers with proposed implementations and there might be some code available somewhere.
I am trying to implement a sphere sphere collision. I understand the math behind it. However, I am still looking around tutorials to see if there are better and faster approaches. I came across nehe's collision detection tutorial ( http://nehe.gamedev.net/tutorial/collision_detection/17005/ ). In this tutorial, if I understood correctly, he is trying to check if two spheres collides within a frame, and he tries not to miss it, by first checking if their paths intersect. And then tries to simulate it in a way.
My approach was to check every frame, whether spheres are colliding and be done with it. I didnt consider checking intersection paths etc. Now I am kinda confused how to approach to the problem.
My question is, is it really necessary trying to be that safe and check if we missed the collision by one frame ?
When writing collision detection algorithms, it is important to recognize objects are moving at discrete time steps, unlike the real world. In a typical modern game, objects will be moving with a time step of 0.016 seconds per frame (often with smaller fixed or variable time steps).
It is possible that two spheres moving with very high velocities could pass through each other during a single frame and not be within each other's bounding spheres after integration is performed. This problem is called Tunneling and there are multiple ways, each with varying levels of complexity and cost, to approach the problem. Some options are swept volumes and Minkowski Addition.
Choosing the right algorithm depends on your application. How precise does the collision need to be? Is it vital to your application or can you get away with some false negatives/positives. Typically, the more precise the collision detection, the more you pay in performance.
Similar question here
I am currently brainstorming strategies on how to compute the distance in a 2D array, of all points from sets of points with specific attributes. A good example (and one of my likely uses) would be a landscape with pools of water on it. The idea would be to calculate the distance of all points in this landscape from water.
These are the criteria that I would like to abide to and their reasoning:
1) Execution speed is my greatest concern. The terrain is dynamic and the code will need to be run in a semi continuous manner. What I mean by that is that there are be periods of terrain updates which will require constant updates.
2) Memory overhead is not a major concern of mine. This will be run as the primary application.
3) It must be able to update dynamically. See #1 for the reasons behind this. These updates can be localized.
4) Multi-threading is a possibility. I am already make extensive use of multi-threading as my simulation is very CPU intensive. I'd prefer to avoid it since it would speed up development but I can do it if necessary.
I have come up with the following possible approach and am looking for feedback and/or alternative suggestions.
1) Iterate through the entire array and make a collection positions in a container class corresponding to points are next to those with the particular property. Assign a value of 1 to these points and 0 to the points with the property.
2) Use the positions to look up those points adjacent to them that are the next distance away, place them in a second container class.
3) Repeat this process till no points are left unsigned.
4) Save the list of points directly one unit away for future updates.
The idea is to basically flow outward from distance 0, and save computation by continually narrowing the list of points in the loop.
1) The only other way of doing this well, which I can think of, would be with the Cartesian distance formula, but your way seems like it would have less CPU time (since the Cartesian way must calculate to every point on each point).
2) Or, if I understand your desire correctly, you could iterate through once, saving all of the points with your special attribute in a container (point to them), and then iterate through one more time, only using the distance formula from each iteration to each of the saved points (then repeat). Please comment and ask about it if this explanation is unclear. It's late, and I am quite tired.
If you want to run this comparison in the background, you have no choice but to multi-thread the whole program. However, whether or not to multi-thread the functionality of this process is up to you. If you go with the second option I provided, I think you will have cut down enough CPU usage to forgo multi-threading the process in question. The more I think about it, the more I like the second option.
I'm trying to implement effective fluid solver on the GPU using WebGL and GLSL shader programming.
I've found interesting article:
http://http.developer.nvidia.com/GPUGems/gpugems_ch38.html
See: 38.3.2 Slab Operations
I'm wondering if this technique of enforcing boundary conditions is possible with ping-pong rendering?
If I render only lines, what about an interior of the texture?
I've always assumed that the whole input texture must be copied to temporary texture (ofc boundary is updated during that process), as they are swapped after that operation.
This is interesting especially considering the fact, that Example 38-5. The Boundary Condition Fragment Program (visualization: http://i.stack.imgur.com/M4Hih.jpg) shows scheme that IMHO requires ping-pong technique.
What do you think? Do I misunderstand something?
Generally I've found that texture write is extremely costly and that's why I would like to limit it somehow. Unfortunately, the ping-pong technique enforces a lot of texture writes.
I've actually implemented the technique described in that chapter using FrameBuffer objects as the render to texture method (but in desktop OpenGL since WebGL didn't exist at the time), so it's definitely possible. Unfortunately I don't believe I have the code any more, but if you tag any future questions you have with [webgl] I'll see if I can provide some help.
You will need to ping-pong several times per frame (the article mentions five steps, but I seem to recall the exact number depends on the quality of the simulation you want and on your exact boundary conditions). Using FBOs is quite a bit more efficient than it was when this was written (the author mentions using a GeForce FX 5950, which was a while ago), so I wouldn't worry about the overhead he mentions in the article. As long as you aren't bringing data back to the CPU, you shouldn't find too high a cost for switching between texture and the framebuffer.
You will have some leakage if your boundaries are only a pixel thick, but that may or may not be acceptable depending on how you render your results and the velocity of your fluid. Making the boundaries thicker may help, and there are papers that have been written since this one that explore different ways of confining the fluid within boundaries (I also recall a few on more efficient diffusion/pressure solvers that you might check out after you have this version working...you'll find some interesting follow ups if you search for papers that cite the GPU gems article on google scholar).
Addendum: I'm not sure I entirely understand your question about boundaries. The key is that you must run a shader at each pixel of what you want to be a boundary, but it doesn't really matter how that pixel gets there, whether it's drawn with lines, points, or triangles (as long as its inputs are correct).
In the very general case (which might not apply if you only have a limited number of boundary primitives), you will likely have to draw a framebuffer-covering quad, since the interactions with the velocity and pressure fields are more complicated (any surrounding pixel could be another boundary pixel, instead of having simply defined edges). See section 38.5.4 (Arbitrary Boundaries) for some explanation of how to do it. If something isn't a boundary, you won't touch the vector field, and if it is, instead of hardcoding which directions you want to look in to sum vector values, you'll probably end up testing the surrounding pixels and only summing the ones that aren't boundaries so that you can enforce the boundary conditions.