HD_Mouse's profile - activity

Excellent!

That depends on your implementation. Did you implement it using random access functions, like the at() function? Or with pointers directly?

I think your issue of reading from 6 webcams is a hardware issue, actually. From my understanding, USB ports all typically go onto the same bus, and unless your computer has multiple buses for usb, the port will easily get clogged from 6 webcams streaming data. Getting two webcams to work can typically be done, but 3 or more would start getting hangly. You are likely getting 3 to work because I'm guessing that your laptop webcam has its own dedicated bus. A workaround (and also a way to test my theory) is to multiplex your cameras by turning the camera on, grabbing the data, then turning it off, then cycling between the other cameras.

To directly answer your questions.

1. I'm not familiar with the cvCreateCameraCapture, and searching for it in the documentation doesn't yield any results. The C interface function for video capture is cvCaptureFromCAM. To close the capture, you can use cvReleaseCapture. It's worth mentioning, that unless you're absolutely constrained to the C, you should consider using the C++ interface, as it is cleaner and more user-friendly.

2. Unfortunately, I don't know of an innate way for OpenCV to and I doubt there is one. I can't help you with this. That said, I think the problem is rooted at what I mentioned above.

Flip takes a 2D array and flips it around a vertical and/or horizontal axis. cvFlip and cv::flip are defined in copy.cpp located under modules/core/src/copy.cpp in the source files. Internally, cvFlip just calls cv::flip. Thie image below is demonstrating the different flips.

Edit: flip() and cv::flip() are the same function, as flip() exists in the "cv" namespace.

Your line

#include "../opencv2/opencv.hpp"

is specifying a relative path for #include to look. If it can't find it there, then it tries to look for it wherever it stores the standard header files (such as: iostream, stdio.h). Assuming you built OpenCV for linux properly, the headers get copied into /usr/include/. You'll likely find opencv.hpp at "/usr/include/opencv2/opencv.hpp". The line isn't working because of the ".." you added to it. It's causing it to look for a file at /usr/opencv2/opencv.hpp".

You can probably fix this by just replacing that line with this:

#include <opencv2/opencv.hpp>

That said, it would be better practice to pull in only headers that are needed, such as:

#include <opencv2/highgui/highgui.hpp>
#include <opencv2/core/core.hpp>

FOURCC supports a very large amount of codecs, but in my experience, aside from the major codecs, whether the codec actually works varies. In my experience, I just try the different codecs until one works. http://www.fourcc.org/codecs.php lists 'CRAM' as one of their supported codecs, but it also says that it is allegedly simialr to 'MSVC'. Another codec listed is 'WHAM'. Maybe give these a try?

I'm going to put on my StephenPuttemans hat and ask, why not use the more modern and easier to use C++ interface?

The C++ interface has a very handy function: at(), which allows for random access of pixel values in a Mat object, the OpenCV image storage structure. Example: if you have a grayscale image (meaning the stored elements are chars), you can access the values like so:

image.at<char>(49,39);

The code above accesses the char element of the object 'image' at row 49, column 39.

That said, the above method is best for random access. The most efficient way to loop over the Mat object is pointer access, and you can access the pointer with the Mat member function ptr(). But dealing with pointers can be hairy, so you can alternatively use MatIterator_ to access the elements. See this tutorial for a better breakdown of the different methods of pixel access.

HOWEVER IF YOU INSIST ON USING THE C INTERFACE, the C interface provides a macro: CV_IMAGE_ELEM(). And you can also use pointer access like before.

For your second question, when you start introducing more cameras, rather than calculating a matrix for each pair, you'll calculate a single matrix that describes the scene geometry between all of them them. For example, with 3 separate poses/cameras, you can calculate the "Trifocal tensor" (The fundamental matrix is a bifocal tensor). Having N-cameras, and you can calculate the "N-Focal tensor." It will describe the geometry between the cameras, but again, only up to a scale. Without external information, you won't get scale. For a whole book on these matrices, read Multiple View Geometry by Hartley and Zisserman. It's practically the bible on this subject.

For your first question, no. The essential matrix itself is up to scale. What you're getting is the epipolar geometry of the scene, which basically describes the relationship of the two cameras to points in the scene. It's all projective though, so all you'll get from the scene is the geometry, but no scale. You can read more on its properties here, but a quick summary is that the essential matrix multiplied by any scale will give you the same generalized scene geometry.

Do you have any other external information aside from just the cameras? Otherwise, you will only ever be able to determine T up to scale. For example, stereo camera setups use the distance between cameras as their baseline, and comparing T to that distance is trivial and an easy way translate that to the rest of the scene. In your case, you'll need a common object of known size/distance from the cameras, and then do the math to calculate the scale of T.

Next time, it will help a lot to also copy and paste the error that you're getting. Otherwise, we have to copy your code to our computers and try running it ourselves, which we shouldn't have to deal with.

1. You're using cout, which are members of the iostream library. You'll need to add iostream to the top.
2. The opencv C++ headers are located under opencv2/. Remove cv.h, highgui.h and add opencv2/core/core.hpp instead. Your example doesn't use anything from highgui, but if you need it in the future, you can replace highgui.h with opencv2/highgui.hpp
3. Make sure you link against opencv when compiling. Adding "-lopencv_core" will compile your code.

Did you try clicking the displayed window and then pressing a key? The focus of your OS may still be with the terminal, so your keystrokes are being intercepted by your terminal, rather than the window created from imshow().

I think this is possible, but your question is rather vague and knowing more about your specific problem would help us give a better answer. A large object from several hundred meters away can still be quite small and may not even be seen from a camera. That said, my approach would be to apply a motion detecting algorithm, such as Optical Flow to detect if an object is falling. You can also filter results by motions that are moving in the 'down' direction of your camera. Another approach is that if the environment is very static, you could use a background subtraction algorithm to watch the scene and pick out moving objects. Both of the above mentioned algorithms are supported in OpenCV.

For hardware solutions, two popular solutions for low cost/power boards would be the Raspberry Pi or the Beaglebone. There's a good comparison of these two boards here, which also includes the Arduino Uno, but OpenCV's processing requirements would crush the AtMega. A quick google search shows some results for OpenCV+Arduino, but as far as I can tell, they're just using Arduino as a platform for controlling camera servos. Personally, I've gotten OpenCV to run on the Raspberry Pi, but it was also early in its development, so there were still issues with the USB driver which would cause the webcam to fail due to inconsistent power. This was a few months ago, so as far as I know, those problems have been fixed. I have yet to actually run OpenCV on the BeagleBone, but I don't see any reason why it wouldn't work.

Have you made any other changes to the code? I tried running the tutorial code with and without equalizeHist(), and even emptied the descriptors and keypoints after running their respective functions and it still worked fine on my machine.

Greetings all,

I frequent the IRC channel on irc.freenode.net at #opencv. The channel is pretty active and I encourage you to stop by if you have the time to ask/answer questions. HOWEVER, we've been dealing with a mildly annoying issue for the past several months. The channel owner, vIkSiT, has been absent for over a year (with the exception of a few months ago, but his appearance was prompted from an email from myself. subsequent emails haven't been answered). I've attempted contacting freenode staff, but as per their policy, they won't transfer op rights to someone, unless that person is directly affiliated with OpenCV. Is there anyone here that is directly involved with OpenCV that could get op rights for #opencv and possibly then transfer it to someone more active in the channel? This would help the channel be more welcoming (we could update the welcome message, for starters), plus we'd then be able to moderate the channel more effectively. I've tried emailing some of the members that list their emails on code.opencv.org, but I have yet to receive a response from them, so as a last effort I'm trying here. Any and all help would be greatly appreciated! Thanks for your time.

If you need/want any help with that, let me know.

Is there anyway to point to the samples that come with OpenCV source? I frequent the OpenCV IRC channel, and we get a lot of people that ask questions that I think could have been solved if they had seen the samples. The sample code isn't exactly hidden, but it isn't immediately obvious if you don't know it's there.

I believe the "VIDIOC_QUERYMENU" error messages are coming from v4l - video 4 linux - driver. I've personally never been able to resolve them, but aside from those error messages on start up the image capturing works fine.

Hm, this might be a bug. The error is reporting that 'get' hasn't actually be defined yet. cv2 is known to have not implemented everything yet, so you can try switching to the cv interface for now, which has VideoWriter working there.

Check out this link for some more info on the pairings. I think the codec that will work on your machine depends on what has been installed on there (more specifically, a library such as gstreamer or ffmpeg). The link above contains some codecs that should work on your machine.

The size of the final output of the video is directly related to the codec used to store that video file in. Codecs can be categorized as compressed and uncompressed, and can be further broken down into lossy and lossless. You can read more about compression formats here. Some popular compressed codecs are H.264 or MPEG-4. Of course, the more compressed the video is, the more likely you'll lose quality with the final video (a lossy codec), so you'll have to experiment with different codecs to see which one is suitable for your needs.

That said, you can affect the type of codec you use in the construction of the VideoWriter object, namely the fourcc parameter. Here is the page for the codecs supported by fourcc. I would recommend starting with some of the popular codecs like MPG4, H264, or MJPG since your project seems to require higher compression rates.

First off, keep in mind that OpenCV is a computer vision library, and what you're asking for is a feature that would be implemented more easily in a GUI framework.

That said, you CAN do this with OpenCV. Using the get function in cv2, you can obtain properties of the video. Properties you'd be interested in are: CV_CAP_PROP_POS_MSEC, and CV_CAP_PROP_POS_AVI_RATIO. You can get the timestamp of the frame in milliseconds from the former, and then the relative position of that frame from the latter. You can also get the length of the entire video in seconds from CV_CAP_PROP_FPS and CV_CAP_PROP_FRAME_COUNT.

For actually displaying the time, you could print it directly onto the frame as text, or even use a trackbar and update its position to reflect the time. Good luck!

Under what circumstances are you expecting that a descriptor can't be computed? compute() only removes a Keypoint if it can't compute a descriptor for it, which is a rather rare occurance.

I had some extra time at work so I whipped up a quick and dirty implementation of my comment above:

Code:

cv::Mat image = cv::imread("image.jpg", 0);

cv::Mat image_thresh;
cv::threshold(image, image_thresh, 125, 255, cv::THRESH_BINARY);

// Loop through the border pixels and if they're black, floodFill from there
cv::Mat mask;
image_thresh.copyTo(mask);
for (int i = 0; i < mask.cols; i++) {
    if (mask.at<char>(0, i) == 0) {
        cv::floodFill(mask, cv::Point(i, 0), 255, 0, 10, 10);
    }   
    if (mask.at<char>(mask.rows-1, i) == 0) {
        cv::floodFill(mask, cv::Point(i, mask.rows-1), 255, 0, 10, 10);
    }
}
for (int i = 0; i < mask.rows; i++) {
    if (mask.at<char>(i, 0) == 0) {
        cv::floodFill(mask, cv::Point(0, i), 255, 0, 10, 10);
    }
    if (mask.at<char>(i, mask.cols-1) == 0) {
        cv::floodFill(mask, cv::Point(mask.cols-1, i), 255, 0, 10, 10);
    }
}


// Compare mask with original.
cv::Mat newImage;
image.copyTo(newImage);
for (int row = 0; row < mask.rows; ++row) {
    for (int col = 0; col < mask.cols; ++col) {
        if (mask.at<char>(row, col) == 0) {
            newImage.at<char>(row, col) = 255;
        }           
    }
}
cv::imshow("filled image", mask);
cv::imshow("Final image", newImage);
cv::imwrite("final.jpg", newImage);
cv::waitKey(0);

return 0;

And the result:

I had some extra time at lunch today, so I punched out a quick and dirty implementation of what I said above.

cv::Mat image = cv::imread("image.jpg", 0);

// Apply threshold to make sure that all values are either 0 or 255
cv::Mat image_thresh;
cv::threshold(image, image_thresh, 125, 255, cv::THRESH_BINARY);

// Loop through the border pixels and if they're black, floodFill from there
cv::Mat mask;
image_thresh.copyTo(mask);
for (int i = 0; i < mask.cols; i++) {
    if (mask.at<char>(i, 0) == 0) {
        cv::floodFill(mask, cv::Point(i, 0), 255, 0, 10, 10);
    }   
    if (mask.at<char>(i, mask.rows-1) == 0) {
        cv::floodFill(mask, cv::Point(i, mask.rows-1), 255, 0, 10, 10);
    }
}
for (int i = 0; i < mask.rows; i++) {
    if (mask.at<char>(0, i) == 0) {
        cv::floodFill(mask, cv::Point(0, i), 255, 0, 10, 10);
    }
    if (mask.at<char>(mask.cols-1, i) == 0) {
        cv::floodFill(mask, cv::Point(mask.cols-1, i), 255, 0, 10, 10);
    }
}


// Compare mask with original.
cv::Mat newImage;
image.copyTo(newImage);
for (int row = 0; row < mask.rows; ++row) {
    for (int col = 0; col < mask.cols; ++col) {
        if (mask.at<char>(row, col) == 0) {
            newImage.at<char>(row, col) = 255;
        }           
    }
}
cv::imshow("filled image", mask);
cv::imshow("Final image", newImage);

cv::waitKey(0);

return 0;

And here is the result: