I am using remap function to undistort openCV image in C++ as following
remap(srcImg, dstImg, map1, map2, INTER_LINEAR, BORDER_CONSTANT);
It takes a lot of time.
Is there is a way I can increase its speed? I tried using Intel remap but did not know how to using with openCV image.
Related
I am trying to make a feature matching algorithm with OpenCV on CUDA.
I am using the ORB features.
The main problem I have is that I am able to well compute the ORB keypoints but the descriptors are always empty. I tried all the ways but without success. I tried with the last version of opencv (3.4.0) and the 3.2.0 version.
This is the simplified version of my code:
cv::Ptr<cv::cuda::ORB> orb_gpu = cv::cuda::ORB::create(5000);
std::vector<cv::KeyPoint> keypoints;
cv::cuda::GpuMat descriptors;
cv::cuda::GpuMat img_gpu(curr_frame);
orb_gpu->detect(img_gpu, keypoints);
orb_gpu->compute(img_gpu, keypoints, descriptors);
cv::Mat desc_cpu;
descriptors.upload(desc_cpu);
The problem is with the direction of memory copy. You are calling upload instead of download function to copy descriptors from device to host. The following line is the culprit:
descriptors.upload(desc_cpu);
Replace it with:
descriptors.download(desc_cpu);
upload copies from host to device whereas download copies from device to host.
I have tested and verified the example with OpenCV 3.4 compiled with CUDA 8 on Ubuntu 14.04.
Recently started playing around with OpenCV, trying that SURF algorithm, that is really slow on CPU, and does not work with color images on GPU (has an assertion that checks for type==CV_8UC1), and converting images to grayscale gives some pretty bad results.
I'm wondering if there is a colored implementation on gpu in OpenCV, somewhere else, or if there is some kinda tricky workaround like doing the algorithm on all 3 channels and then magically merging them?
Thanks.
There's no special handling of color images in OpenCV's non-GPU version of SURF; the code shows that it just calls cvtColor(img, img, COLOR_BGR2GRAY) if it gets an image with more than one channel.
You might try converting the image to HSV and using one or more of the H, S, and/or V channels. More discussion at this question.
I want to call cv::findCountours on some cv::UMat (OpenCL activated) and get the results into std::vector<std::vector<cv::Point>>.
std::vector<std::vector<cv::Point>> contours;
cv::findContours(frame_umat, contours, cv::RETR_LIST, cv::ContourApproximationModes::CHAIN_APPROX_SIMPLE);
Will OpenCV still able to optimise it using OpenCL even if I am using std::vector? Is there any advantage of using a special container like for example cv::UMat as a container(not an image)?
By tracing OpenCV cv::findContours function, I realized that it is not optimised using OpenCL at all (not CUDA also). The only implementation it has is SSE2 as far as I found in OpenCV 3.1
I'm upgrading to OpenCV 3 and using the UMat T_API OpenCL container instead of Mat.
It appears that drawing functions like rectangle(Mat img, ...) don't have a UMat overload. I would like to work in the UMat world as much as possible for drawing on frames without having to convert UMat back to Mat for drawing and displaying.
Can anyone give me the most efficient way to draw a rectangle on a UMat? Or do I have to convert back to Mat to draw on and display?
Unfortunately, there is no way to draw something on UMat without transferring data from GPU memory.
You may use following scheme to do drawings:
cv::Mat draw_img = img.getMat(cv::ACCESS_WRITE);
cv::rectangle(draw_img, ...);
draw_img.release();
Please note that getMat(cv::ACCESS_WRITE) requires synchronization. So in order to get maximum benefits of GPU processing, it will be better to avoid drawing operations or group it into one block.
Has anyone managed to get the Brox dense optical flow algorithm in OpenCV working?
Here is some code:
{
// Load images
cv::Mat PreviousFrameGrayFloat; // Has an image in format CV_32FC1
cv::Mat CurrentFrameGrayFloat; // Has an image in format CV_32FC1
// Upload images to GPU
cv::gpu::GpuMat PreviousFrameGPU(PreviousFrameGrayFloat);
cv::gpu::GpuMat CurrentFrameGPU(CurrentFrameGrayFloat);
// Prepare receiving variables
cv::gpu::GpuMat FlowXGPU;
cv::gpu::GpuMat FlowYGPU;
// Create optical flow object
cv::gpu::BroxOpticalFlow OpticalFlowGPU = cv::gpu::BroxOpticalFlow(0.197f, 0.8f, 50.0f, 10, 77, 10);
// Perform optical flow
OpticalFlowGPU(PreviousFrameGPU, CurrentFrameGPU, FlowXGPU, FlowYGPU); // EXCEPTION
// Exception in opencv_core244d!cv::GlBuffer::unbind
// Download flow from GPU
cv::Mat FlowX;
cv::Mat FlowY;
FlowXGPU.download(FlowX);
FlowYGPU.download(FlowY);
}
I get an exception, as commented above, when I try and use the cv::gpu::BroxOpticalFlow object, I have the same problem with cv::gpu::PyrLKOpticalFlow but only the dense version not the sparse one, and cv::gpu::FarnebackOpticalFlow works fine...
Weird.
Entire exception is:
Exception at 0x7c812fd3, code: 0xe06d7363: C++ exception, flags=0x1 (execution cannot be continued) in opencv_core244d!cv::GlBuffer::unbind
I'm using a debug build with debug libraries, using OpenCV 2.4.4 however the code also raises an exception in OpenCV 2.4.3.
When I use OpenCV 2.4.3 I get this exception:
Exception at 0x7c812fd3, code: 0xe06d7363: C++ exception, flags=0x1 (execution cannot be continued) in opencv_core243d!cv::SparseMat::erase
OpenGL is required, but there may also be a problem with your scale parameter (50.0f). It seems too large. As I understand, this should be less than 1. If it is a large number, the algorithm fills up GPU memory quickly. Plus, it may not make sense to use an expanding (upside-down?) image pyramid. Not perfectly sure though.
After experimenting with other versions of OpenCV and following the information contained here: http://stuartjames.info/Journal/opencv-brox-optical-flow-sample-possible-fix.aspx
It looks like I need to recompile OpenCV with OpenGL.
It seems that you can test whether your install of OpenCV has OpenGL by running the command: cv::gpu::setGlDevice(0); if this fails with a weird exception like the one above then you need to recompile.
OpenGL is required as the newer optical flow algorithms in OpenCV map data to OpenGL textures to (I assume) speed up operations, or maybe to just make the code simpler.
So, after all this, the solution is to recompile OpenCV with OpenGL. This can be achieved by ticking the WITH_OPENGL box when using CMake to configure the build.
If you want to use the GPU version of the video reader make sure you also tick WITH_NVCUVID this is included with CUDA but not included unless you request it...
-- EDIT --
After the comments from paul I've corrected the scale factor in my code from the question.
Here is the complete code I'm testing, for nkint:
{
// Load images
cv::Mat PreviousFrameGray = cv::imread("Input1.png", 0);
cv::Mat CurrentFrameGray = cv::imread("Input2.png", 0);
cv::Mat PreviousFrameGrayFloat; // Has an image in format CV_32FC1
cv::Mat CurrentFrameGrayFloat; // Has an image in format CV_32FC1
PreviousFrameGray.convertTo(PreviousFrameGrayFloat, CV_32FC1, 1.0/255.0);
CurrentFrameGray.convertTo(CurrentFrameGrayFloat, CV_32FC1, 1.0/255.0);
// Upload images to GPU
cv::gpu::GpuMat PreviousFrameGPU(PreviousFrameGrayFloat);
cv::gpu::GpuMat CurrentFrameGPU(CurrentFrameGrayFloat);
// Prepare receiving variables
cv::gpu::GpuMat FlowXGPU;
cv::gpu::GpuMat FlowYGPU;
// Create optical flow object
cv::gpu::BroxOpticalFlow OpticalFlowGPU = cv::gpu::BroxOpticalFlow(0.197f, 50.0f, 0.8f, 10, 77, 10);
// Perform optical flow
OpticalFlowGPU(PreviousFrameGPU, CurrentFrameGPU, FlowXGPU, FlowYGPU);
// Download flow from GPU
cv::Mat FlowX;
cv::Mat FlowY;
FlowXGPU.download(FlowX);
FlowYGPU.download(FlowY);
// Use FlowX and FlowY in further processing
//...
}