You could just use threads to run your algorithms but don't expect faster performance because:
- OpenCV has a lot of internal parallelization;
- To go at full speed using threads you need a well designed threading architecture (like producer/consumers) and may be this is out of your scope;
Below is simple example, here I'm comparing sequential vs parallel implementation using a stream from a webcam as input.
I'm showing how to apply 2 different algorithms over same frame, using 2 sequential calls and simple threading. The example below suffering of poor threading implementation because thread construction will introduce big overhead.
On my computer, results show that the sequential way is faster than simple threading, it depends on background computer load, sequential might be up to 2 time faster.
EDIT: Added measure of treading overhead.. Look at my timing (win7/64, intel i3 2x2.53Ghz):
- webcam @320x240, OCV 2.4.10:
- Debug ver within MS VisualStudio 2013:
Parallel:16.3ms Sequential:12.8ms Overhead:3.5ms
- Release ver within MS VisualStudio 2013:
Parallel:8.1ms Sequential:4.3ms Overhead:4.9ms
- Release ver from command line:
Parallel:3.6ms Sequential:2.7ms Overhead:0.6ms
- webcam @640x480, OCV 2.4.10:
Parallel:11.65ms Sequential:11.48ms Overhead:0.67ms
- webcam @640x480, OCV 3.0.0:
Parallel:8.67ms Sequential:8.37ms Overhead:0.69ms
EDIT2: Considering tuannhtn answer, looks interesting to investigate a bit over different results
For sure advanced parallel programming in IPP improves overall performance but really on Intel i3 I can't see any improvement between sequential and parallel approach. I suppose that difference is due to different processor architecture.
Core Duo 2x2.4 and Intel i3 2x2.53 have 2 cores but CoreDuo doesn't have Hyper-Threading and SmartCache.
When Hyper-Threading is available, some operations share the execution resources automatically in parallel (I/O, cache, bus interface..) on more logical processor. Hyper-Threading and SmartCache make more efficient use of available execution resources boosting sequential approach.
On CoreDuo load balancing on is demanded to developer than parallel approach gets better result.
This can explains why parallel approach is better on CoreDuo but is close to sequential approach on Intel i3. Looking at performance with video 640x480:
- CoreDuo/Ocv3.0.0/Win7/64:
Parallel:8.66ms Sequential:13.47ms Overhead:0.6ms
- i3/Ocv3.0.0/Win//64:
Parallel:8.67ms Sequential:8.37ms Overhead:0.69ms
the code:
#include <thread>
#include <opencv2/opencv.hpp>
using namespace cv;
// here we use canny
void Algo1(const cv::Mat &src, cv::Mat *dst)
{
cvtColor(src, *dst, CV_BGR2GRAY);
GaussianBlur(*dst, *dst, Size(7, 7), 1.5, 1.5);
Canny(*dst, *dst, 0, 30, 3);
}
// here we use morphology gradient
void Algo2(const cv::Mat &src, cv::Mat *dst)
{
int morph_size = 1;
cv::Size sz(2 * morph_size + 1, 2 * morph_size + 1);
cv::Point anchor(morph_size, morph_size);
Mat element = getStructuringElement(MORPH_RECT, sz, anchor);
morphologyEx(src, *dst, MORPH_GRADIENT, element);
}
// empty function to measure overhead
void Test()
{
return;
}
int main()
{
VideoCapture cap ...
(more)
What do you mean by simultaneously? If you mean to process the same frame in two different and independent ways, then it is as easy as doing this:
You can also run the algorithms in a parallel way rather than in a sequencial way. I think the key to your problem is avoiding reading from the camera twice.
Thanks for your comment, So, it is no possible to handle the usb camera from 2 different process in the same time? if not, Any idea how to run the algorithms in a parallel way?
I'm not sure you can't do it, but why would you want to? Accesing the camera from two different processes will probably lead to grabbing different frames, and I guess you want to compare the algorithms of something like that. Maybe if you detail more your scenario we can approach better solutions