Unexpected Results using CopyTo Rect with UMat

asked 2016-11-07 04:25:48 -0500

alm gravatar image

updated 2016-11-07 04:28:44 -0500

berak gravatar image

Hi, I am trying to use OpenCV with UMats to move some image processing to GPU and speed it up but I am getting some unexpected results.

I have changed my application to use the UMat class throughout but am getting some strange results when I do the following:

subImg.copyTo(mainImg(Rect(400, 400, 320, 180)));

(In this case mainImg is a UMat of size 1280 x 720 and subImg is a UMat of 320 x 180)

The sub image is copied in but appears in the wrong place, it is correct on the x axis but in the wrong place on the y-axis, except for a strip on the right hand side of the sub image (maybe 2 pixels wide) which appears in the correct position (e.g. the sub image is essentially split in two with a strip from the right hand side correctly placed and the rest of the image placed above it). Strangely if I change the y co-ordinate in the Rect it appears in the correct place when the given y value is below about 160.

If I copy the UMats back into Mats before performing the same operation and then back into a UMat everything works as expected:

Mat t1;
Mat t2;
mainImg.copyTo(t1);
subImg.copyTo(t2);
t2.copyTo(t1(Rect(400, 400, 320, 180)));
UMat out;
t2.copyTo(out);

I'm not sure if it is relevant but I am creating the UMats by first creating a standard Mat from an existing array of image data and then using copyTo to get this into a UMat. I'm not sure if this is the correct procedure but it seems to be working ok, except for this issue.

If anyone has any ideas what could be causing this that would be appreciated.

Thanks!

edit retag flag offensive close merge delete

Comments

1

It's difficult to test with your example. Can you modify this code to reproduce your problem?

#include "opencv2/opencv.hpp"
#include "opencv2/core/ocl.hpp"
using namespace cv;
using namespace std;

int main(int argc, char* argv[])
{
    ocl::setUseOpenCL(true);
    if (!cv::ocl::haveOpenCL() )
    {
        cout << "OpenCL is not available..." << endl;
        return 0;
    }
    if (!ocl::useOpenCL())
        cout << "OpenCL is not activated..." << endl;
    UMat mainImg(720, 1280, CV_8UC1, Scalar(0));
    UMat subImg(180, 320, CV_8UC1, Scalar(255));
    subImg.copyTo(mainImg(Rect(400, 400, 320, 180)));
    imshow("U_Frame",mainImg.getMat(cv::ACCESS_READ));   
    waitKey();
LBerger gravatar imageLBerger ( 2016-11-07 05:59:00 -0500 )edit

OpenCV version platform and compiler are needed too

LBerger gravatar imageLBerger ( 2016-11-07 05:59:47 -0500 )edit

Hi LBerger, thanks for the quick response. I get the same results running your code unmodified as I did previously. Here are the images produced (changing imshow to imwrite):

Unmodified: link text Modified: link text

The second (modified) version I simply replaced UMat with Mat and removed ".getMat(cv::ACCESS_READ". You can see in the first version the white image appears in the wrong place.

This is running on OSX 10.11.4 with Apple LLVM version 7.3.0 (clang-703.0.31).

I will actually be using this on a linux server, I'll test there and see if I get the same results and report back, but I need to set up a few things first.

Cheers for your help.

alm gravatar imagealm ( 2016-11-07 07:35:02 -0500 )edit

Are you really working on your machine or is it a virtual machine? Example on windows with terminal server I cannot use opencl.

May be you should post an issue if you have got good results with Mat and wrong with UMat

LBerger gravatar imageLBerger ( 2016-11-07 07:43:53 -0500 )edit
1

Yes, the tests I'd been doing now were directly on my OSX machine no VM.

So, I've just tried this again running on a linux server running AWS AMI Linux (RHEL based) and it works fine, both your test code and my original application. So this is less of an issue for me personally now, although it will make dev a bit harder.

I'll post this as an issue as the code looks to be fine as it only seems to occur on OSX. It is definitely running on the GPU when I run on OSX as it is far far faster than using a Mat it just produces these strange results.

Apologies for not testing it on a different setup first, I'm relatively new to OpenCV so I just assumed it was me doing something wrong! Also everything else I've done has also been ...(more)

alm gravatar imagealm ( 2016-11-07 09:03:50 -0500 )edit