Quote:
Originally Posted by faust1706
I think I talked to you Saturday about your system. Really cool work. You said something that was really odd to me: you were getting ~15-20 fps. It didn't seem right, and looking at your code I now know why (or have a very good guess).
You are using 2 namespaces that have identical functions, such as erode, dilate, and threshold, cv and cv::gpu.
I'll use the function generateThreshold as a running example. You are passing in Mats, not GpuMat. Meaning when you call cvtColor on ImageIn, it will use the cpu based cvtColor. Same goes for threshold, split, erode and dilate.
There isn't a gpu equivalent of findcontours that I am aware of. There are gpu edge detectors such as sobel and laplacian, however.
|
Sorry for the slow response, just saw this.
The short version of the answer is that you've managed to find dead code. The functions you list were written up and tested on the CPU and we found they didn't improve our detection accuracy, so we scrapped them. They're still in the code but they aren't used.
The detection code we do use is cascadeDetect(). There's a GPU and CPU version - we use the GPU version if a GPU is detected at startup (see the top of main()) and if not we fallback to a CPU. This lets us run the code on a normal laptop for testing and then only have to debug the GPU specific stuff on a Jetson.
When we switched from Haar to LBP cascades I did expect a decent performance bump based on what I'd read. The training speed did increase dramatically but the runtime performance didn't change too much. But after some quick testing, we saw similar performance with the bare-bones OpenCV cascade demo code. My guess is that Haar is either more GPU friendly or just not as well optimized. I'd be happy to find a simple fix if one if out there, though.