1

Currently trying to display a stream from an uEye camera using OpenCV. For this purpose I have Visual Studio 2013 and OpenCV 2.4.9 (64bit) at my disposal. Since things are not yet close to a release I'm using the debug libraries that are shipped with OpenCV (compiled with Visual Studio 2012).

I was trying to memcpy the image data that is returned by the camera to a cv::Mat object. After getting some weird error about a NULL pointer (string name of cvNamedWindow) I decide to check if I can actually run a very basic piece of code - read a PNG image and show it in a window. Well, it's not working... My mistake is probably still in the memcpy that I use but if you read below you will see that I have also tested a case where no camera is involved.

  • No matter if I give the absolute path of my image or simply point at the file where the EXE is I get an assertion failure from cv::imshow that either the height and/or width are not > 0. One other thing struck me here - the window name was all messed up - weird symbols, blank spaces etc. Nothing to do with what I have assigned as a name: "camOutput"
  • Further I decided to test things by manually creating a matrix of type CV_8U3 and filling it with black pixels. OpenCV showed the image yet the name of the window was again messed up. This time I was able to read the following, which seems to be some part of a command:

n in DOS mode.$

O_o I have never ever seen such weird behaviour especially when it comes to imshow, imread or namedWindow. Futher I can also not explain why imread returns an empty matrix no matter what I feed it. Tried PNG, JPEG and BMP - always the same crash.

EDIT: I have created an empty C++ project and transferred all my settings from the previous one. Now it's working. Even the memcpy for my uEye camera is fine and I can display the output in an OpenCV window. I have no idea what the problem was with my previous project. Will have to analyze further since the issue might reoccur. I will however leave this questioned opened because of that.

rbaleksandar
  • 8,713
  • 7
  • 76
  • 161
  • 1
    You can not safely use opencv compiled with a different compiler than the compiler you are using for your application. This creates more than 1 heap and other CRT incompatibilities. Although I believe opencv does ship a vc12 binary folder in some of its official packages. That is for Visual Studio 2013. vc11 is Visual Studio 2012. – drescherjm Dec 13 '14 at 14:46
  • 1
    So I have to build the whole OpenCV with the Visual C++ compiler shipped with VS 2013? -_- – rbaleksandar Dec 13 '14 at 14:48
  • If you do not have the vc12 folder yes. – drescherjm Dec 13 '14 at 14:49
  • Here is more about the compiler versions: http://stackoverflow.com/a/21730219/487892 – drescherjm Dec 13 '14 at 14:50
  • I do have the vc12 folder and I'm using the libs found in ../build/x64/vc12 – rbaleksandar Dec 13 '14 at 14:55
  • So this is not the issue. I can't help with the real issue. Sorry. – drescherjm Dec 13 '14 at 14:55
  • Np. Thanks for trying though. :) – rbaleksandar Dec 13 '14 at 14:58
  • are you building a 64bit configuration ? do you strictly use debug libs with the debug build and release ones with the release build ? your errors are all typical for a linking problem – berak Dec 13 '14 at 15:37
  • Good point. It is also not safe to mix debug and release in the same application. This too will create more than 1 independent heap. – drescherjm Dec 13 '14 at 15:40
  • I have picked all 64bit opencv libs that I need (ending on "d" for "debug version"). Configuration of the whole project is strickly 64bit. Otherwise I would have not been able to link my uEye libraries too. These are made in such an idiotic manner that you can install the 32bit uEye libs only on an 32bit system thus I was forced to do an all 64bit project. – rbaleksandar Dec 13 '14 at 16:01
  • Okay, I created a new clean project, copied all my settings from the old to the new one and at least for now the basics are working - imread is fine, names of the namedWindow is also what I want it to be. Problem might reoccur so I'll keep my question opened since I still don't know where the problem was. – rbaleksandar Dec 13 '14 at 16:45

0 Answers0