Kellerspeicher's profile - activity

Your linker is called with an unknown option or most common one with a wrong syntax. Usually cmake and later make knows how to pass such paths. I guess there is some thing happening with it, e.g. a not escaped backslash is ignored. Even if using Windows it is often better to use slash instead if backslash in paths. In the meantime even Microsoft has realized that it makes no sense to use backslash if the hole rest of the IT world has used slash long before DOS was made and until today.

What do you mean by "same error"? Which one?

cmake is just making the makefile for make to compile. And make install will copy the libraries to the install location. I added a recipe to the answer.

It is difficult to evaluate such things from a single code fragment without a "Minimal, Complete, and Verifiable example". If your program runs with one thread and didn't run with more, you have interference in between. Taking a copy is one way to prevent these. By the way, if you plan to transfer by TCP why worrying about local copy time effort?

What do you mean by essentially read only? If it is not completely read only you have changes and these might interfere with your threads. That is why I pointed to the typical problem of pointers or references to vector elements if reallocation occurs. Read only shall be forced by const declaration e.g. in your first line const Mat& I. If you "read it somewhere else too" both usages shall be const. Otherwise you do not know what changes take place without being obvious.

If I is a reference to an entry of the vector<> you will always get trouble if the vector<> is reallocating e.g. if getting bigger. I do not think that this has got something to do with the thread safety of the Mat methods. If you protect your vector<> by mutex and take a deep copy of Mat (e.g. by clone() or copyTo()) it works like a charm. I use something very similar to distribute the processing of video frames to a bunch of threads without problems.

The answer is in the question: "Can't create lib files with CMake". You can never make libraries with cmake. CMale is a tool for creating Makefiles to tell make how to create the libraries.

Usually libraries are installed in ${CMAKE_INSTALL_PREFIX}/lib so if you call cmake e.g. with -D CMAKE_INSTALL_PREFIX=../inst the libs, includes and all you need are installed in a directory inst beside your build directory.

You can also use -D OPENCV_LIB_INSTALL_PATH=mylib which is appended to CMAKE_INSTALL_PREFIX and will install to ../inst/mylib instead of ../inst/lib. So you first select the overall location using CMAKE_INSTALL_PREFIX and then append the directory for the libraries with OPENCV_LIB_INSTALL_PATH.

As an example if we want to build in a subdirectory build of the source tree root and want to install in inst beside, the recipe is:

# Go to openCV source directory
cd opencv-3.0.0
# Create a build directory (can be anywhere with any name)
mkdir build
# Go to the build directory
cd build
# Create the makefiles (referencing the source directory .. )
cmake -D CMAKE_INSTALL_PREFIX=../inst -D CMAKE_BUILD_TYPE=RELEASE ..
# Run make to compile and link the sources
make
# Copy the libraries, binaries, includes to ${CMAKE_INSTALL_PREFIX}
make install
# Go to your install directory
cd ../inst

Compiling takes a lot of time and can be done parallel using several cores of your CPU by make -j8.

There are good examples for face detection and I am not sure if Canny on colour will make sense. But if you want to try:

// Transform Blue, Green, Red to Hue, Saturation, Value
cv::Mat hsv;
cv::cvtColor( frame, hsv, cv::COLOR_BGR2HSV );
// Split the three channels
std::vector< cv::Mat > hsvChannels;
cv::split( hsv, hsvChannels );
// Blur the hue channel
cv::Mat blured;
cv::blur( hsvChannels[0], blured, cv::Size(3,3) );
// Canny the hue channel
cv::Mat canny;
cv::Canny( blured, canny, 100, 300, 3 );

For a good face detection example e.g. look here.

• ceil( sqrt(2) ) == 2 so there is no need for ? :.
• sqrt() is an expensive function and not needed twice.
• be careful with operator order better use brackets or unambiguous order

Your should (not tested) get the same with:

int w = cvCeil( sqrt( ( double )( images.size() ) ) );
int h = cvCeil( ( double )( images.size() ) / w );
int size = images.size() <= 2 ? 300 : 2 * 300 / w;

But you will not get the same result as your original code e.g. images.size() == 7 results in w == 3 not w == 4. Having such a limited number of cases (12) the fastest and most flexible method are lookup tables:

static const int wl[] = { 0,1,2,2,2,3,3,3,3,3,4,4,4 };
static conat int hl[] = { 0,1,1,2,2,2,2,3,3,3,3,3,3 };
static const int sl[] = { 0,300,300,200,150 };
int w = wl[n];
int h = hl[n];
int size = sl[w];

But take care of being consistent. Lookup tables do also offer many ways to create faults.

Experimenting with FLANN as included in openCV 3.1 (December, 2015) I found the old version 1.6.10 (May 2011). Is there a special reason not to use the latest 1.8.4 (January 2013)? Looking at the changelog the authors provided a lot of fixes and enhancements. Is there a reason to keep this old version? Looking at the changelog of openCV the 1.6 of FLANN was included in 2.3.1 (August, 2011) and improved by Pierre-Emmanuel Viel in 3.0 alpha (August, 2014). Are those enhancements so extensive that it is better not upgraded?

Yes thanks. Looks like plenty of effort just to clean a read buffer. But it would be a workaround.

As an answer to the question "Skipping frames in VideoCapture" Will Stewart presented grap() for skipping frames. But how many frames to I have to skip until I reach the current one?

In a loop the frames of a camera are processed using a very time consuming function. In the meantime the camera is providing further frames. Thus if the loop is doing the next vcap.read() it gets an old buffered frame. That delays the output even further than it is already delayed by the processing anyway. How to skip all of theses frames. I am looking for something like vcap.flush_read_buffer() except for the latest frame.

Some sort of non blocking grap() would also do the job while(vcap.grap()); and then vcap.retrieve() the last successful graped frame. Or a function providing a flag if frames are buffered while(vcap.buffered()) vcap.grap(). Any of these would be better that nothing.

Doing multi-threading (like harsha proposed) would surely do the job. But it is like taking a sledgehammer to crack a nut. Especially on an embedded system this won't feel good. Processing as many frames of a camera as possible but these just in time, should be possible on a system designed "with a strong focus on real-time applications."

Any further idea?