I'm trying to get the algorithm provided in this repository to work on windows. After countless issues, I'm only left with one unrecognized function cvLoadImage which is apprently depricated. I was instructed to work with the c++ API instead but the problem is that I will have to rewrite other parts of the code as well and I might end up breaking it.
#include <opencv2/imgcodecs/imgcodecs_c.h>
returned the below error on Visual Studio:
"This header with legacy C API declarations has been removed from OpenCV. Legacy contants are available from legacy/constants_c.h file."
I imported all files provided in the opencv folder named constants_c.h, but none contained the function definition.
Indeed, that is the old OpenCV C API. You will need to port the old C functions to the c++ OpenCV API, e.g.:
cvNamedWindow -> cv::namedWindow
cvRectangle -> cv::rectangle
cvPoint -> cv::Point
etc.
The code you're using is actually a mix of the old C API and the newer c++ API.
It's just a matter of going through all the C API calls in that repo and manually port them to the c++ API. As you can see above, most of the time that is fairly intuitive. When in doubt search the OpenCV documentation.
Additionally you should look into YOLOv2 for Pedestrian detection.
Update:
There are multiple forks of this repository and it looks like Berak already has already removed the C API calls. His changes were merged, so you should to pull the latest changes and rebuild:
cd C4-Real-time-pedestrian-detection
git pull
cmake . -DCMAKE_CXX_FLAGS="-std=c++11"
make -j8
I've tested the above on my machine:
Regarding my setup, I ran into this error first:
cvdef.h:656:4: error: "OpenCV 4.x+ requires enabled C++11 support"
which is why I've passed the -std=c++11 compiler flag to cmake.
This may be because I'm an older version of OSX (10.11.6) with Xcode 7.0 (about 3 years old now). The current machine has 8 cores, hence make -j8.
Feel free to change these two options as necessary on your machine.
Related
I am trying to get luasocket working in the lua scripting environment of Bizhawk, but so far without luck. I downloaded the vc8 version of luasocket here, made sure I have vc8 installed, and checked the lua version that came with bizhawk: 5.1
But, when I start the script I get the following error:
LuaInterface.LuaScriptException: error loading module 'socket.core' from file './libs/socket\core.dll':
Das angegebene Modul wurde nicht gefunden. (the given module was not found)
The lua code:
package.path = package.path..';./libs/lua/?.lua'
package.cpath = package.cpath..';./libs/?.dll'
local socket = require("socket")
The file system structure:
libs
> lua
> socket
ftp.lua http.lua smtp.lua tp.lua url.lua
ltn12.lua
mime.lua
socket.lua
> socket
core.dll
> mime
core.dll
It seems to find the files, because when I had the file structure wrong it gave me actual file-not-found errors.
My best guess is that there is some kind if incompatibility between the lua that is shipped with Bizhawk and the external luasocket library binaries, but I am out of ideas.
This guy's set it up: https://github.com/antogerva/emuHostUDP (dearchive to emuhawk.exe base directory). His example seems to work, but it might not contain everything you need. Like HTTP for example.
Since project is complex and the luasockets examples are awful, here's a one-liner for testing http:
print(require("socket.http").request{ url = "http://www.google.com" });
Following his model, I applied the following method: contents of lua dir to root; lua5.1.dll to root. Note that we will not be using the core.dlls from luasockets. This is because BizHawk now has them integrated; and this was necessary to work around a bug with luasockets in bizhawk.
More specifically, we have
/emuhawk.exe
/Lua (untouched)
/Socket/ftp.lua,http.lua,etc.
/ltn12.lua,socket.lua,mime.lua
/lua5.1.dll
/mytest.lua
(with files from http://files.luaforge.net/releases/luasocket/luasocket/luasocket-2.0.2/luasocket-2.0.2-lua-5.1.2-Win32-vc8.zip)
I can't say why precisely all of this is necessary, but I think it's miraculous that it works, given that we have a customized lua.
When using lua, if you find a directory structure that works, it's best not to wrestle with it any further.
Update:
(may be out of date) As soon as you do something nontrivial you may find bizhawk crashes. It seems this is due to a conflict with luasocket's "protection" system. Inspect http.lua and observe the code at the end which sends a function through socket.protect to wrap it. Remove the socket.protect wrapper and it should solve this problem.
I suspect that it's because of the dependence on lua51.dll. luasocket core.dll library is linked against lua51.dll (most likely; you can ran depends or similar tool to find out for sure), which is probably not present and this prevents socket.core from being loaded.
Even if you find lua51.dll, it's not likely to work if Bizhawk is statically compiled with lua51.dll as this will lead to two interpreters loaded into the same process, which is a recipe for seg faults.
There are three main options, but they all depend on how Bizhawk project is structured:
Bizhawk is compiled against lua51.dll (and this dll is present as a standalone file). In this case you need to make sure that the socket/core.dll you are using is compiled against the same library and it should work (as long as the run-times are the same and lua51.sll is available in PATH).
Bizhawk is statically compiled with lua51.dll. The simplest option is also statically compile luasocket libraries into the executable.
If option 2 is not available, then you need to use a proxy library and export Lua symbols from the Bizhawk executable as described in this SO answer: https://stackoverflow.com/a/28310666/1442917
If none of this helps you to solve the problem, you'll need to get depends for your Windows platform and run it in the "profiling" mode, which will tell you the exact error that happens when that DLL is loaded.
Hello everyone;
i had opencv 2.2 on my vs2010, and i wanted to update so i went to opencv site and:
i've downloaded OpenCV for Windows (ver 2.4.6)
i've extracted it to c:\opencv2.4
i've set the Environment Variable as doc said here: http://docs.opencv.org/doc/tutorials/introduction/windows_install/windows_install.html#windowssetpathandenviromentvariable
( i didnt know what is "PATH EDITOR" so i've just changed Environment variables)
i made property sprite sheets as opencv doc said here: http://docs.opencv.org/doc/tutorials/introduction/windows_visual_studio_Opencv/windows_visual_studio_Opencv.html#windows-visual-studio-how-to
5.but Doc Was Old, and there was no "include" folder in OpenCV2.4/opencv/build/x64/vc10 so I did set include Directory to OpenCV2.4/opencv/build/include in My property sprite sheet.
everything seems true and VS detect include libraries But
VS2010 throw following error when i want to Build the solution:
1>LINK : fatal error LNK1104: cannot open file 'opencv_core231d.lib'
Strange thing is there is no "opencv_core231d.lib" File in c:\opencv2.4 at all!!!
:(
what is the problem?
This is a Linker error, so make sure you are trying to link the correct libraries.
I would suggest to use CMake, which definitely simplifies configuring projects, specially those having dependencies like OpenCV (you can take a look to the OpenCV documentation, or any blog explaining the steps: http://marcosnietoblog.wordpress.com/2011/11/19/opencv-for-windows-easy-installation-using-cmake/ )
By the way, I use to have several versions of opencv on the same folder:
C:\OpenCV\opencv2.4.3
C:\OpenCV\opencv2.4.6
...
So I can easily switch within CMake setting the OpenCV_DIR.
opencv_core231d.lib is a debug version, all the *d.lib and *d.dll files in openCV are with debug symbols.
It is likely that the pre-built release you downloaded doesn't contain debug ones.
either download te source and build both debug and release. Or, if you don't care how opencv works internally, just change the linker flags to use the same lib names with the d
edit. or of course if you donwloaded opencv 2.4.6 the file would be opencv_core246d.lib
I have a code base which compiles fine in all other NEON compilers, ndk-build, RVDS, etc, but under Xcode I get the error "bad instruction" for every NEON instruction I call. It basically seems like NEON is not detected.
I am attempting to build a static library, I went to New Project, selected Cocoa Touch Static Library, then added my existing files.
Everything I'm reading indicates that NEON should be already enabled. I removed all references to armv6, and am targeting iOS 5.1
Also the code in question is all contained as routines defined in ".s" files -- pure assembly. I am not using the intrinsics method calls.
It seems like the compiler is barfing on the whole file...
Unknown pseudo-op: .cpu
It lists all of the other settings, like .fpu, etc
Here are my current settings:
(source: wasteonline.net)
(source: wasteonline.net)
(source: wasteonline.net)
After the as tool I mentioned in my last answer turned out to be choking on my syntax as well, I realized there must be something else going on.
I followed the guidelines on the bottom of this post http://www.shervinemami.info/armAssembly.html#template
The changes I needed to make were:
converted my instructions to all lower case
use the naming directives to be compatible with mach-o (solved linker problems)
Try to use GCC4.2. I solved a very similar problem switching to the old, good GCC.
In Build Settings -> Compiler for C/C++/Objective-C, select GCC
Actually, if you check the LLVM ARM status page, you'll see that it cannot yet parse .S files.
I'm working on porting a library onto AIX. It works on Solaris, Windows and Linux but AIX is giving me headaches. I'm at a point where it builds and runs but I have an issue with some of the libraries it's linking in. Ideally I want to be able to ship a library that just requires the c runtime to be available with no other dependencies. At the moment I'm having a problem with libpthread which I can see is a symlink to an AIX specific threading library.
My issue is this:
If I don't link pthread (I don't seem to need to on Solaris for the same code base) then I get undefined symbols. That's fine I am using pthreads. If I link it in then it works fine, except that any calling application also has to link to pthreads. I don't really understand is why does my calling app, which has no dependency on pthread, need to link against it just because it's calling a library which links to the shared object?
I'm on AIX 6.1 using gcc 4.2.4.
I'd be OK with shipping a library that requires pthreads to be present on the library path (ideally we'd get a static version) but I'm a bit unhappy about shipping a library that places linker rqeuirements on the client.
Any ideas on what I might be doing wrong?
I defeinitely seem to be going in circles. I removed the -shared flag on the linker to resolve an earlier problem and that, of course, makes the library static. So the behaviour is just normal behaviour in that if you depend on a dynamic library from a static one you have to link both into your app. So I've put the shared flag back and now half of my functions are no longer accessible. It does explain the problem I was seeing though.
Has anyone used Bluetooth on Mac OS X with Lazarus or FreePascal? There is a bluetooth unit, but it currently only supports Linux.
Information about existing unit:
http://wiki.freepascal.org/Bluetooth
I plan to enhance this to support Mac OS, but it would be nice to know if anyone has written any code to use BlueTooth on Mac OS already to avoid duplicated work.
On the other hand, if you have used XCode to access Bluetooth, what libraries did you use? I am sure I can discover this with the XCode profiler by opening some Bluetooth applications.
Note: Mac OS X doesn't appear to use the BlueZ library that Linux has, so I don't think the solution is as easy as changing the library path. Instead, it has IOBluetooth "Framework", located at /System/Library/Frameworks/IOBluetooth.framework.
Having a look, it looks like:
kaikei.ocn.ntt.com:IOBluetooth.framework $ file *
CodeResources: XML document text
Headers: directory
IOBluetooth: Mach-O universal binary with 3 architectures
IOBluetooth (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
IOBluetooth (for architecture i386): Mach-O dynamically linked shared library i386
IOBluetooth (for architecture ppc7400): Mach-O dynamically linked shared library ppc
Resources: directory
Versions: directory
On the other hand, I think if anyone had done this already, I would probably be able to find it on Google.... On the off chance I am wrong, please reply and let me know.
Clarification: I have created bindings for normal shared libraries before (f.e. sqlite3), but not for a "framework". If nobody has created bindings or otherwise used the MacOS Bluetooth framework from FreePascal, advice on how to use framework functions from FreePascal in general woule be appreciated. (And normally the functions I am porting are C based, not Obj-C, so I am not sure how to declare Obj-C methods in FPK, although I am sure I will be able to find some samples if I keep searching).
The main svn repository for translated Mac OS X framework C headers is http://svn.freepascal.org/svn/macosxintf/trunk
From time to time, FPC releases are synchronised with the latest versions hosted there. Note that the files in that repository (in the MPPInterfaces subdirectory) are in a generic format that can be automatically translated into either FPC, GPC or CodeWarrior Pascal versions.
To generate the FPC versions, use "make fpcpinterfaces", and find the results in the Build/FPCPinterfaces folder.
To translate new headers, execute something like this from inside a checked out copy of the macosxintf repository:
./Scripts/Convert.pl /System/Library/Frameworks/IOBluetooth.framework/Headers/IOBluetooth.h FORCE MPPInterfaces
Afterwards, you'll still have to edit the resulting file to add/remove units and clean up some other things not handled by the automatic translation process. Once finished, you may want to submit a bug report at bugs.freepascal.org with the finished units.
(note: because I'm unregistered, I can only add in one url per post, so the next url's are a bit mangled to get around that restriction)
You can also subscribe to the Mac Pascal list (lists.sonic.net/mailman/listinfo/mac-pascal) and ask there whether someone already translated those headers.
The Bluetooth framework indeed also contains some Objective-C headers. Objective-Pascal support is only available in the latest FPC svn versions, as described on the FPC wiki (google FPC_PasCocoa). You need this support in order to interface with Objective-C.
Translating Objective-C is probably easiest using the script elsewhere in FPC's svn (svn.freepascal.org/svn/fpc/trunk/packages/cocoaint/utils/)
You may want to ask for help on the above-mentioned Mac Pascal list, as all people maintaining the aforementioned translations and translation tools are subscribed there.