OpenCV dll: shared library VI is not executable

[murrdpirate]

I'm trying to incorporate some opencv functions into LabVIEW.  To start, I created a very simple threshold function and turned it into a dll.  When I import the dll and header file, LabVIEW seems to recognize the threshold function, but then the report says this:

VI Not Executable
The VI is not executable because of one of the following reasons:
1. The shared library or a dependent file is not installed. To make the VI executable, you must install the shared library and all support files on the computer on which you run the VI.
2. A required custom control might be empty or cannot be found. To make the VI executable, update the custom control manually.
3. The VI contains a parameter with an unsupported data type. To make the VI executable, you must replace the empty cluster that the wizard generates with a control or indicator that uses supported data types.
    Threshold.vi

I've attached my .cpp and .h files used to create the .dll file.

[rolfk]

Your C code makes use of OpenCV functionality. So you should make sure OpenCV is installed on your computer and accessible from LabVIEW. As far as I know OpenCV is supposed to be installed private to an application so you should put it in the LabVIEW directory or in one of the directories that are in the Windows search path. That said, trying to use OpenCV from LabVIEW is a very non-trivial exercise that has been already tried by many on this forum, and in a really extensive way only mastered by one as far as I know. You can find the result here, but it's not free (and IMHO rightly so, this is a huge effort)!

[murrdpirate]

Yeah I definitely have OpenCV installed and I can use it with visual c++.  I had to tell Labview where the opencv header files are (as well as Labview's vision header files).  Maybe I have to direct it to the opencv/IMAQ .lib files files?  Although I thought .lib files were added to .exe/.dll files when you compile.

[rolfk]

LabVIEWs call Library Node does not use header files nor library files but only shared library files. As such it simply will attempt to load the shared library you specify in the Library Path and that will fail if the DLL depends on other DLLs (which the OpenCV DLLs do heavily) that might be not in the Windows shared library search path.

Now your comments let me believe that you happen to use the Import Shared Library Wizard instead. This Wizard is likely overwhelmed by several issues in the header files, so it is likely not a good idea to even attempt to use it.

By the way IMAQ_Image may be a NI-Vision datatype, it for sure is not something you can directly interface to any LabVIEW datatype. Here is already one of the challenges of interfacing image libraries to LabVIEW.

[murrdpirate]

Yep, I was using the Import Shared Library Wizard, which asked me to provide the location for dependent header files.  Should I use the Call Library function node VI instead?

I don't think my DLL depends on other DLLs.  I only specified opencv's LIB files when I created my visual c++ project.  I could be wrong on that...I know that opencv has a coressponding DLL for every LIB file, but my impression is that you could either use LIB or DLL.  Labview shouldn't have any issues with a DLL that depends on LIB files, since LIB files should be incorporated into the DLL, right?

Thanks for the help.

[rolfk]

A lib file often is just an import library, containing the dynamic bindings to load and link to the shared library at runtime. While size of the lib can be an indication, there is no simple way to see if a lib file is simply an import library for a shared library or a static library containing all (or some) of the code. Even a static lib can depend on code that needs to be imported by another import library too.

[murrdpirate]

You are absolutely correct, I didn't notice before, but in opencv there is one folder simple called "lib" and another called "staticlib."  And the LIB files in the staticlib folder are at least 10 times bigger.  Unfortunately I'm having compiling errors when I link to these LIBs instead of the import LIBs...apparently there are known issues with these (at least with the opencv precompiled binaries for windows).  But I'll try to square that away and update this post.  Hopefully that was the problem.  Thanks again, rolfk.

[murrdpirate]

I decided to try to make a simple DLL that would just load an image from my hard drive and threshold it, that way I could eliminate the conversion from IMAQ_Image to opencv's IplImage in case that was the problem.  I accidentally left the non static library folder as my linked directory, but tried the import DLL VI rather than the wizard and this time it told me that the dll was 64 bit.  Changed that and it worked!  Also added back in the conversion from IMAQ_Image stuff and that worked too!