How to check for openCV on Ubuntu 9.10 - linux

How can I confirm if openCV is properly installed in my computer ? Is there any quick command line for it ? I am on Ubuntu 9.10

A proper answer to my own question !
pkg-config --modversion opencv

With OpenCV 2.4.x:
You can use "CV_VERSION" or "CV_MAJOR_VERSION", "CV_MINOR_VERSION", "CV_SUBMINOR_VERSION" from a C/C++ simple program.
Example of 'main.c':
#include <stdio.h>
#include <cv.h>
int main(void)
{
printf("%s\r\n", CV_VERSION);
printf("%u.%u.%u\r\n", CV_MAJOR_VERSION, CV_MINOR_VERSION, CV_SUBMINOR_VERSION);
}
Here is the compilation line:
g++ `pkg-config --cflags opencv` main.c `pkg-config --libs opencv` -o main

Here's an easy way to check. Assuming you installed using the default configuration.
In /usr/local/lib you should have the following libraries
libcvaux.so -> libcvaux.so.2.0
libcvaux.so.2.0 -> libcvaux.so.2.0.0
libcvaux.so.2.0.0
libcv.so -> libcv.so.2.0
libcv.so.2.0 -> libcv.so.2.0.0
libcv.so.2.0.0
libcxcore.so -> libcxcore.so.2.0
libcxcore.so.2.0 -> libcxcore.so.2.0.0
libcxcore.so.2.0.0
libhighgui.so -> libhighgui.so.2.0
libhighgui.so.2.0 -> libhighgui.so.2.0.0
libhighgui.so.2.0.0
libml.so -> libml.so.2.0
libml.so.2.0 -> libml.so.2.0.0
libml.so.2.0.0
And in /usr/local/include/opencv you should have the following header files.
cvaux.h, cvcompat.h, cv.hpp, cvver.h, cvwimage.h, cxcore.hpp, cxflann.h,
cxmisc.h, cxtypes.h, highgui.hpp, cvaux.hpp, cv.h, cvtypes.h, cvvidsurv.hpp,
cxcore.h, cxerror.h, cxmat.hpp, cxoperations.hpp, highgui.h, ml.h
I'm assuming that you using the latest version which is 2.0.

Here is c++ version
// https://www.solarianprogrammer.com/2014/04/21/opencv-beaglebone- black-ubuntu/
// Test to check the OpenCV version
// Build on Linux with:
// g++ test_1.cpp -o test_1 -lopencv_core
#include <opencv2/opencv.hpp>
#include <iostream>
int main() {
std::cout << "Hello, OpenCV version "<< CV_VERSION << std::endl;
return 0;
}

Open your terminal and type this command:
python3 -c "import cv2; print(cv2.__version__)"
This works on my system

I found this to be the simplest way:
/usr/bin/opencv_version

You could use dpkg.
$ dpkg -l | grep libopencv
Or if you use python version:
$ python
>>>> import cv2

Related

OpenMPI runtime error : Hello World

I'm able to successfully compile my code when I execute the make command. However, when I run the code as:
mpirun -np 4 test
The error generated is:
-------------------------------------------------------
Primary job terminated normally, but 1 process returned
a non-zero exit code.. Per user-direction, the job has been aborted.
-------------------------------------------------------
--------------------------------------------------------------------------
mpirun detected that one or more processes exited with non-zero status, thus causing
the job to be terminated. The first process to do so was:
Process name: [[63067,1],2]
Exit code: 1
--------------------------------------------------------------------------
I have no multiple mpi installations so I don't expect there to be a problem.
I've been having trouble with my Hello World OpenMPI program. My main file is :
#include <iostream>
#include "mpi.h"
using namespace std;
int main(int argc, const char * argv[]) {
MPI_Init(NULL, NULL);
int size, rank;
MPI_Comm_size(MPI_COMM_WORLD, &size);
MPI_Comm_rank(MPI_COMM_WORLD, &rank);
cout << "The number of spawned processes are " << size << "And this is the process " << rank;
MPI_Finalize();
return 0;
}
My makefile is:
# Compiler
CXX = mpic++
# Compiler flags
CFLAGS = -Wall -lm
# Header and Library Paths
INCLUDE = -I/usr/local/include -I/usr/local/lib -I..
LIBRARY_INCLUDE = -L/usr/local/lib
LIBRARIES = -l mpi
# the build target executable
TARGET = test
all: $(TARGET)
$(TARGET): main.cpp
$(CXX) $(CFLAGS) -o $(TARGET) main.cpp $(INCLUDE) $(LIBRARY_INCLUDE) $(LIBRARIES)
clean:
rm $(TARGET)
The output of: mpic++ --version is:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 8.1.0 (clang-802.0.42)
Target: x86_64-apple-darwin16.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
And that for mpirun --version is:
mpirun (Open MPI) 2.1.1
Report bugs to http://www.open-mpi.org/community/help/
What could be causing the issue?
This is now resolved. It turns out that I have to execute with
mpirun -np 4 ./test
Ref: users-request#lists.open-mpi.org

opencv videocapture can't open MJPEG stream

the Opencv 2.4.9: VideoCapture cann't open the MJPG-streamer:
VideoCapture cap;
cap.open("http://127.0.0.1:8080/?action=stream&type=.mjpg");
if (!cap.isOpened()) // if not success, exit program
{
cout << "Cannot open the video cam" << endl;
return -1;
}
I can see the video use gst-launch. and I have searched a lot,like this and tried the fifo like this,but still cann't open it.
then I want to debug into opencv,compile opencv with CMAKE_BUILD_TYPE=DEBUG, but my GDB just cann't step into the open function.any idea?
my makefile:
OpencvDebugLibDir=/home/ry/lib
CFLAGS = -g -I$(OpencvDebugLibDir)/include/opencv -I$(OpencvDebugLibDir)
LIBS = $(OpencvDebugLibDir)/lib/*.so
target : main.cpp
g++ $(CFLAGS) $(LIBS) -o $# $<
by the way, I am in opensue13.1, with the same code,I can open the video in win 7.
thank you.
Update
now I can step into some function like:imshow,waitKey, but I can not step into others like:imread,namedWindow,it shows:
29 image = cv::imread(name);
(gdb) s
std::allocator<char>::allocator (this=0x7fffffffdc7f)
at /usr/src/debug/gcc-4.8.1-20130909/obj-x86_64-suse-linux/x86_64-suse-linux/libstdc++-v3/include/bits/allocator.h:113
113 allocator() throw() { }
test4.cpp:
#include <stdio.h>
#include <opencv2/opencv.hpp>
using namespace cv;
int main(int argc, char** argv )
{
Mat image;
image = imread( "LinuxLogo.jpg", 1 );
if ( !image.data )
{
printf("No image data \n");
return -1;
}
namedWindow("Display Image", CV_WINDOW_AUTOSIZE );
imshow("Display Image", image);
waitKey(0);
return 0;
}
my makefile:
OpencvDebugLibDir=/home/ry/lib
CFLAGS=-g -I$(OpencvDebugLibDir)/include/opencv -I$(OpencvDebugLibDir)
LIBS=$(OpencvDebugLibDir)/lib
test4:test4.cpp
g++ $(CFLAGS) -o $# $< -L$(LIBS) -lopencv_highgui -lopencv_core -Wl,-rpath=/home/ry/lib/lib
run gdb:
gdb test4 -d /home/ry/learn/opencv/install/OpenCV/opencv-2.4.9/modules/core/src -d /home/ry/learn/opencv/install/OpenCV/opencv-2.4.9/modules/highgui/src
opencv videocapture can't open MJPEG stream,because I don't compile opencv with FFMPEG support.
detail:
when cmake the opencv:
cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local -D BUILD_SHARED_LIBS=ON -D WITH_TBB=ON -D WITH_OPENMP=ON -D WITH_OPENCL=ON -D WITH_CUDA=ON -D WITH_GTK=ON -D BUILD_NEW_PYTHON_SUPPORT=ON -D WITH_V4L=ON -D INSTALL_C_EXAMPLES=OFF -D INSTALL_PYTHON_EXAMPLES=OFF -D BUILD_EXAMPLES=OFF -D WITH_QT=ON -D WITH_OPENGL=ON -D BUILD_JPEG=ON -D BUILD_PNG=ON -D BUILD_JASPER=ON -D BUILD_ZLIB=ON -D WITH_JPEG=ON -D WITH_PNG=ON -D WITH_JASPER=ON -D WITH_ZLIB=ON -D WITH_OPENEXR=OFF ..
you get something like:
FFMPEG: NO
-- codec: NO
-- format: NO
-- util: NO
-- swscale: NO
-- gentoo-style: NO
so the cmake don't find the FFMPEG. I should install libffmpeg-devel in my machine(Opensuse 13.1),then the pkg-config can find FFMPEG,you can check with this:
pkg-config --list-all | grep libavcodec
then run the above cmake command again, I get:
FFMPEG: YES
-- codec: YES (ver 55.69.100)
-- format: YES (ver 55.48.100)
-- util: YES (ver 52.92.100)
-- swscale: YES (ver 2.6.100)
-- gentoo-style: YES
make,and I get the opencv videocapture able to open MJPG_Streamer.
PS:to find the reason,I compile a debug version opencv,and step into the VideoCapture's open function,and in the construction function of icvInitFFMPEG() in " opencv-2.4.9/modules/highgui/src/cap.cpp ":
#elif defined HAVE_FFMPEG
icvCreateFileCapture_FFMPEG_p = (CvCreateFileCapture_Plugin)cvCreateFileCapture_FFMPEG;
icvReleaseCapture_FFMPEG_p = (CvReleaseCapture_Plugin)cvReleaseCapture_FFMPEG;
icvGrabFrame_FFMPEG_p = (CvGrabFrame_Plugin)cvGrabFrame_FFMPEG;
icvRetrieveFrame_FFMPEG_p = (CvRetrieveFrame_Plugin)cvRetrieveFrame_FFMPEG;
icvSetCaptureProperty_FFMPEG_p = (CvSetCaptureProperty_Plugin)cvSetCaptureProperty_FFMPEG;
icvGetCaptureProperty_FFMPEG_p = (CvGetCaptureProperty_Plugin)cvGetCaptureProperty_FFMPEG;
icvCreateVideoWriter_FFMPEG_p = (CvCreateVideoWriter_Plugin)cvCreateVideoWriter_FFMPEG;
icvReleaseVideoWriter_FFMPEG_p = (CvReleaseVideoWriter_Plugin)cvReleaseVideoWriter_FFMPEG;
icvWriteFrame_FFMPEG_p = (CvWriteFrame_Plugin)cvWriteFrame_FFMPEG;
#endif
it just step over these code,so I know because I don't have the HAVE_FFMPEG defined in compiling process.

Link error undefined reference to `dgels_' in Lapack

I followed this below webpage to install ATLAS + Lapack in linux :
http://math-atlas.sourceforge.net/atlas_install/node6.html
bunzip2 -c atlas3.10.1.tar.bz2 | tar xfm - # create SRCdir
mv ATLAS ATLAS3.10.1 # get unique dir name
cd ATLAS3.10.1 # enter SRCdir
mkdir Linux_C2D64SSE3 # create BLDdir
cd Linux_C2D64SSE3 # enter BLDdir
../configure -b 64 -D c -DPentiumCPS=2400 \ # configure command
--prefix=/home/whaley/lib/atlas \ # install dir
--with-netlib-lapack-tarfile=/home/whaley/dload/lapack-3.4.2.tgz
make build # tune & build lib
make check # sanity check correct answer
make ptcheck # sanity check parallel
make time # check if lib is fast
make install # copy libs to install dir
After that , I try to run an sample in
http://www.netlib.org/lapack/lapacke.html
the sample code :
#include <stdio.h>
#include <lapacke.h>
int main (int argc, const char * argv[])
{
double a[5*3] = {1,2,3,4,5,1,3,5,2,4,1,4,2,5,3};
double b[5*2] = {-10,12,14,16,18,-3,14,12,16,16};
lapack_int info,m,n,lda,ldb,nrhs;
int i,j;
m = 5;
n = 3;
nrhs = 2;
lda = 5;
ldb = 5;
info = LAPACKE_dgels(LAPACK_COL_MAJOR,'N',m,n,nrhs,a,lda,b,ldb);
for(i=0;i<n;i++)
{
for(j=0;j<nrhs;j++)
{
printf("%lf ",b[i+ldb*j]);
}
printf("\n");
}
return(info);
}
I have found out the build library has no iblapacke.a , so I build this library by myslef
cd lapack-3.4.2
cp make.inc.example make.inc
cd lapacke
make
Then , finally I have the iblapacke.a now , so I compile the sample above by :
g++ test3.cpp liblapacke.a -o test3.exe
I get the following errors :
liblapacke.a(lapacke_dgels_work.o): In function `LAPACKE_dgels_work':
lapacke_dgels_work.c:(.text+0x1dd): undefined reference to `dgels_'
lapacke_dgels_work.c:(.text+0x2b7): undefined reference to `dgels_'
After I google , I have found :
http://www.netlib.org/lapack/explore-html/d7/d3b/group__double_g_esolve.html
Functions/Subroutines
subroutine dgels (TRANS, M, N, NRHS, A, LDA, B, LDB, WORK, LWORK, INFO)
DGELS solves overdetermined or underdetermined systems for GE matrices
There is a function dgels , without underline , and in
http://shtools.ipgp.fr/www/faq.html#l4
I think the underline is added for accident ,
nm -A liblapacke.a |grep "dgels_"
liblapacke.a:lapacke_dgels.o: U LAPACKE_dgels_work
liblapacke.a:lapacke_dgels_work.o: U LAPACKE_dge_trans
liblapacke.a:lapacke_dgels_work.o:0000000000000000 T LAPACKE_dgels_work
liblapacke.a:lapacke_dgels_work.o: U LAPACKE_xerbla
liblapacke.a:lapacke_dgels_work.o: U dgels_
liblapacke.a:lapacke_dgels_work.o: U free
liblapacke.a:lapacke_dgels_work.o: U malloc
I think I should try to not avoid underline like build "dgels" not to "dgels" while build liblapack.a ,means I should change something build Lapack and ATLAS ,
just don't know how to do it ....Any suggestion is appreciated !!
Update : http://software.intel.com/sites/products/documentation/doclib/mkl_sa/11/mkl_lapack_examples/c_bindings.htm
I have no idea if related , -Ddgels=dgels_ is added , the same link error !!
see:
http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=12&t=3336
for example:
gcc LinearEquation.c -Ilapack-3.5.0/lapacke/include/ -Llapack-3.5.0 -llapacke -llapack -lrefblas -lgfortran -o LinearEquation
the order of lapacke > lapack > refblas is important... also if you don't want to use the double step gcc gfortran, use -lgfortran
I had the exact same problem. You need to do it as follows:
gcc(or g++) -c -O3 -I ../include -o test.o test.c
and then
gfortran test.o ../liblapacke.a ../liblapack.a ../blas.a -o test.exe
You can then run it like so:
./test.exe
Basically, you need to follow the gcc compile with a gfortran compile. The -c option in the first command forces gcc to skip the linker. gfortran is then used to link the libraries.
You can learn more by looking at the makefile for the examples provided with LAPACKE.
I had the same problem (using g++), but fixed my problems by adding a -lblas and -lgfortran.
To resolve the issue, here are the steps I have done.
sudo apt-get install libblas-dev liblapack-dev gfortran
linking a -lblas and -lgfortran when it runs

Why is there a difference using std::thread::hardware_concurrency() and boost::thread::hardware_concurrency()?

The description of the problem itself is pretty simple. I'm testing the differences of std::thread library in C++11 and boost::thread library.
The output of these:
#include <iostream>
#include <thread>
#include <boost/thread.hpp>
int main() {
std::cout << std::thread::hardware_concurrency() << std::endl;
std::cout << boost::thread::hardware_concurrency() << std::endl;
return 0;
}
gives me different results:
0
4
Why is that?
PS: The version of the gcc package is 4.6.2-1.fc16 (x86_64). I'm using
g++ test.cc -Wall -std=c++0x -lboost_thread-mt -lpthread
After reviewing /usr/include/c++/4.6.2/thread
it can be seen that the implementation is actually:
// Returns a value that hints at the number of hardware thread contexts.
static unsigned int
hardware_concurrency()
{ return 0; }
So problem solved. It's just another feature that hasn't been implemented in gcc 4.6.2
The method employed by your compiler installation of boost is supported for your target, whereas your installation of boost compiler does not support this feature for your target.
TFM says:
The number of hardware threads available on the current system (e.g. number of CPUs or cores or hyperthreading units), or 0 if this information is not available.
EDIT: scratch that, reverse it.
EDIT2: This feature is present on the trunk, but absent in 4.6.2:
~/tmp/gcc-4.6.2/libstdc++-v3/src> wc -l thread.cc
104 thread.cc
~/tmp/gcc-4.6.2/libstdc++-v3/src> grep concurrency thread.cc | wc -l
0
~/tmp/gcc-4.6.2/libstdc++-v3> grep -C 2 VERIFY testsuite/30_threads/thread/members/hardware_concurrency.cc
// Current implementation punts on this.
VERIFY( std::thread::hardware_concurrency() == 0 );
return 0;

Why I'm not getting "Multiple definition" error from the g++?

I tried to link my executable program with 2 static libraries using g++. The 2 static libraries have the same function name. I'm expecting a "multiple definition" linking error from the linker, but I did not received. Can anyone help to explain why is this so?
staticLibA.h
#ifndef _STATIC_LIBA_HEADER
#define _STATIC_LIBA_HEADER
int hello(void);
#endif
staticLibA.cpp
#include "staticLibA.h"
int hello(void)
{
printf("\nI'm in staticLibA\n");
return 0;
}
output:
g++ -c -Wall -fPIC -m32 -o staticLibA.o staticLibA.cpp
ar -cvq ../libstaticLibA.a staticLibA.o
a - staticLibA.o
staticLibB.h
#ifndef _STATIC_LIBB_HEADER
#define _STATIC_LIBB_HEADER
int hello(void);
#endif
staticLibB.cpp
#include "staticLibB.h"
int hello(void)
{
printf("\nI'm in staticLibB\n");
return 0;
}
output:
g++ -c -Wall -fPIC -m32 -o staticLibB.o staticLibB.cpp
ar -cvq ../libstaticLibB.a staticLibB.o
a - staticLibB.o
main.cpp
extern int hello(void);
int main(void)
{
hello();
return 0;
}
output:
g++ -c -o main.o main.cpp
g++ -o multipleLibsTest main.o -L. -lstaticLibA -lstaticLibB -lstaticLibC -ldl -lpthread -lrt
The linker does not look at staticLibB, because by the time staticLibA is linked, there are no unfulfilled dependencies.
That's an easy one. An object is only pulled out of a library if the symbol referenced hasn't already been defined. Only one of the hellos are pulled (from A). You'd get errors if you linked with the .o files.
When the linker tries to link main.o into multipleLibsTest and sees that hello() is unresolved, it starts searching the libraries in the order given on the command line. It will find the definition of hello() in staticLibA and will terminate the search.
It will not look in staticLibB or staticLibC at all.
If staticLibB.o contained another symbol not in staticLibA and that was pulled into the final executable, you then get a multiple definition of hello error, as individual .o files are pulled out of the library and two of them would have hello(). Reversing the order of staticLibA and staticLibB on the link command line would then make that error go away.

Resources