OpenCV DirectX 11 Interoperability - c++

I need to read an image in OpenCV, send it to DirectX, do some processing, and then send the output image back to OpenCV. I am completely new to this, and was working with DirectX 11, therefore, I decided to refer this sample which demonstrates OpenCV and DirectX interoperability. There are options for both GPU and CPU modes, but right now, I plan to use only the CPU. The program builds without any errors, but returns the following runtime error everytime:
Exception thrown at 0x0000000000000000 in Direct3D Win32 my_project_name.exe: 0xC0000005: Access violation executing location 0x0000000000000000. occurred
I looked for solutions everywhere but couldn't find any. Since this is a sample, I guess many people might have used this.
Here are the lines where I'm getting an exception.
if (cv::ocl::haveOpenCL())
{
m_oclCtx = cv::directx::ocl::initializeContextFromD3D11Device(m_pD3D11Dev); //this is the line which throws the exception
}
m_oclDevName = cv::ocl::useOpenCL() ?
cv::ocl::Context::getDefault().device(0).name() :
"No OpenCL device";
On hovering the cursor above m_pD3D11Dev, this message is displayed by the intellisense:
m_pD3D11Dev | 0x000001f5a286c618 <No type information available in symbol file for d3d11.dll>
I am guessing that there is some error in my setup or some other linker error since this is a sample code provided by OpenCV(which i am assuming is obviously going to run). Any help or guidance would be appreciated.
I'm using DirectX 11 and OpenCV 3.4.4 to build(x64) this in Visual Studio 19. I also tried building(x64) it in Visual Studio 17, but the results were same.
Thanks in advance.

Related

MATLAB API for C exception using matGetDir: matrix::serialize::EndOfFile at memory location

I try to read a mat file in a c++ Visual Studio 2017 project on Windows 7. I use the MATLAB API for C from Matlab R2017b.
I am able to run the matdgns.c example in Matlab using mex.
It's also possible to run the application in my c++ project and open the mat file using
pmat = matOpen(file, "r");
However, when I try to read the array list using matGetDir
dir = (const char **)matGetDir(pmat, &ndir);
I get an exception:
Exception thrown at 0x000007FEFCF4A06D in project_gTest.exe:
Microsoft C++ exception: matrix::serialize::EndOfFile at memory
location 0x000000000031F1D0.
How can I solve this issue? Am I missing another library?
Thank you!
I received the following answer from Matlab support which "solves" the "issue":
I assume that this Exception which you "get" is basically just a line of text shown in the "Output" Window of Microsoft Visual Studio 2017, right? And this is not actually crashing your application, correct?
If that is indeed the case, please note that MSVS 2017 does in fact show first chance exceptions in "Output". If such an exception is caught and handled, where in this particular case I do expect that the MATLAB libraries handled this, there is no actual issue though. It is perfectly valid to throw exceptions and then handle them. Only unhandled (second chance) exceptions would lead to real problems.
It should normally be perfectly safe to ignore that line which is shown in the Output and it is in fact expected that this Exception is thrown (and caught internally) when working with matGetDir.

OpenCv: Using Yolov3

I used the OpenCV Code from https://docs.opencv.org/3.4.1/da/d9d/tutorial_dnn_yolo.html and made it work on my machine with the yolov2 config/weights. When I try to run the program with yolov3 config/weights (https://pjreddie.com/media/files/yolov3.weights, https://github.com/pjreddie/darknet/blob/master/cfg/yolov3.cfg. both working, when used in ubuntu / not in opencv), it fails on the line
dnn::Net net = readNetFromDarknet(modelConfiguration, modelBinary);
The Exception is:
Unhandled exception at 0xyz in xyz.exe: Microsoft C++ exception: cv::Exception at memory location 0xyz.
The expected behavior would be, that it shows the recognition results, like it does with the yolov2 cfg/weights.
Is yolov3 even usable in opencv?
Thanks,
Michel
Update: Question was answered below. I made a issue in github: https://github.com/opencv/opencv/issues/11310
Update v2: yolov3 is now supported in opencv. -> https://github.com/opencv/opencv/issues/11310 includes an example of the usage
Only Yolo v2 is supported as of 2018/04/11, see the corresponding pull request.

_com_error exception on DirectX Create* methods

I have been trying to get into DirectX programming lately (with C++/Win32), and I encountered some issues.
A friend programmed a very simple random terrain generator that works with Perlin Noise, so I tried to grab his code and make a DirectX 11 renderer for it, but my program throws an "Microsoft C++ Exception", _com_error when I run it.
Even wierder, the program breaks at different lines of code depending on the build type...
On Debug, the program breaks on this chunk of code:
// Load the pixel shader
std::ifstream pixelFile("pixel.cso");
if (!pixelFile)
return false;
std::string pixelContents((std::istreambuf_iterator<char>(pixelFile)),
std::istreambuf_iterator<char>());
pixelFile.close();
if (FAILED(mpDevice->CreatePixelShader(pixelContents.c_str(),
pixelContents.size(),
NULL,
&mpPixelShader)))
return false;
And on Release:
// Create and set the input layout
if (FAILED(mpDevice->CreateInputLayout(layoutDescription,
layoutDescriptionSize,
vertexContents.c_str(),
vertexContents.length(),
&mpVertexLayout)))
return false;
mpPixelShader is a member of type ID3D11PixelShader*, and mpVertexLayout is a member of type ID3D11InputLayout*.
Of course, the first thing I thought when I saw that the error was different was checking for memory corruption, and sure enough I found one in my friend's code after running ApplicationVerifier and setting the _crtDbgFlag, but it is fixed now and I still have this error...
The application ran fine when the rendering initialization function was filled with a modified version of the one found on the MSDN Win32 DirectX Triangle Tutorial too.
The cso file is not a text, it is a binary file. A std::string will not work, the file will contains bytes that are 0.

Gtkmm c++ trouble with strings

I'm writing simple gui application in c++ with, which use gtkmm. I have trouble with gtk functions, which uses std::string type. For example: when i use function Glib::get_real_name(), which returns std::string application crashes with message "Unhandled exception at 0x00007FF97FB8AFF4 (msvcr110d.dll) in app.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.". The same situation happens with other gtk functions, which returns std::string. There is also problem with some functions, which arguments are std::string for example create image from file cannot open proper picture (paths are correct..). There's no problem with functions, which are using ustring, but many built-in gtk functions uses std::string and they dont have ustring alternatives. It's seems to be problem with character encoding, but I dont know how to solve that. I'm using ms visual studio 2012. Have anyone of had this problem before or you know how to solve that?
std::string d = "1m.jpg";
Glib::RefPtr<Gdk::Pixbuf> image = Gdk::Pixbuf::create_from_file(d);
-> here i got this error in terminal:
unhandled exception is signal handler:
domain: g-file-error-quark
code: 17
what : failed to open file '`p\u001f': Invalid Argument
it's seems that 1m.jpg is p\u001f for this app :D

Program crashes with 0xC000000D and no exceptions - how do I debug it?

I have a Visual C++ 9 Win32 application that uses a third-party library. When a function from that library is called with a certain set of parameters the program crashes with "exception code 0xC000000D".
I tried to attach Visual Studio debugger - no exceptions are thrown (neither C++ nor structured like access violations) and terminate() is not called either. Still the program just ends silently.
How does it happen that the program just ends abnormally but without stopping in the debugger? How can I localize the problem?
That's STATUS_INVALID_PARAMETER, use WinDbg to track down who threw it (i.e. attach WinDbg, sxe eh then g.
Other answers and comments to the question helped a lot. Here's what I did.
I notices that if I run the program under Visual Studio debugger it just ends silently, but if I run it without debugger it crashes with a message box (usual Windows message box saying that I lost my unsaved data and everyone is sooo sorry).
So I started the program wihtout debugger, let it crash and then - while the message box was still there - attached the debugger and hit "Break". Here's the call stack:
ntdll.dll!_KiFastSystemCallRet#0()
ntdll.dll!_ZwWaitForMultipleObjects#20() + 0xc bytes
kernel32.dll!_WaitForMultipleObjectsEx#20() - 0x48 bytes
kernel32.dll!_WaitForMultipleObjects#16() + 0x18 bytes
faultrep.dll!StartDWException() + 0x5df bytes
faultrep.dll!ReportFault() + 0x533 bytes
kernel32.dll!_UnhandledExceptionFilter#4() + 0x55c bytes
//SomeThirdPartyLibraryFunctionAddress
//SomeThirdPartyLibraryFunctionAddress
//SomeThirdPartyLibraryFunctionAddress
//SomeThirdPartyLibraryFunctionAddress
//OurCodeInvokingThirdPartyLibraryCode
so obviously that's some problem inside the trird-party library. According to MSDN, UnhandledExceptionFilter() is called in fatal situations and clearly the call is done because of some problem in the library code. So we'll try to work the problem out with the library vendor first.
If you don't have source and debugging information for your 3rd party library, you will not be able to step into it with the debugger. As I see it, your choices are;
Put together a simple test case illustrating the crash and send it onto the library developer
Wrap that library function in your own code that checks for illegal parameters and throw an exception / return an error code when they are passed by your own application
Rewrite the parts of the library that do not work or use an alternative
Very difficult to fix code that is provided as object only
Edit You might also be able to exit more gracefully using __try __finally around your main message loop, something like
int CMyApp::Run()
{
__try
{
int i = CWinApp::Run();
m_Exitok = MAGIC_EXIT_NO;
return i;
}
__finally
{
if (m_Exitok != MAGIC_EXIT_NO)
FaultHandler();
}
}