Josh123's profile - activity

It appears there was two separate issues. The Bus error was caused by this line of code

if (scaled.at<double>(x, y) > AppUtils::BLACK_CUTOFF)

Because Mat::at returns a reference rather than the actual value, it seems that the comparison did not work the same way on a computer with the ARM arhitecture. I added

double pixel = scaled.at<double>(x, y);

to make sure the value was compared, rather then the address. As for the Assertion failed, it appears that is due to a buggy camera driver (probably).

Sorry for the late reply, I have a cubieboard (an embeded system) which uses the ARMHF architecture (HF stands for hardware float, but it is not too important). The program is running on this embeded system. The offending code is simply a call to cv::resize(), however the error seems to cease on my AMD64 system (a laptop computer) after a reboot. On my embeded system I always get the error "Bus error" when trying to run the program.

After a reboot the application stops crashing and printing that error message, it must be a bug in the camera API. I can probably work around this problem, but what about the bus error on ARMHF?

Edit: I have found out that the error listed in the title also occurs on amd64 machines after attempting to debug the application and terminating it prematurely. All I can assume is buggy OpenCV/V4L code causing this. Once again a reboot fixes the issue until the next debug attempt. Running works fine.

This problem occurs only sometimes: when calling cv::resize my application crashes and prints "Assetion failed (ssize.area > 0)." I use the same size (30, 32) to scale my matrix every time and the src matrix is set by the camera. I have a feeling this is a bug in opencv or the camera API it uses (V4L). Using a different camera temporarily solves the problem. When I run this program on a machine using ARMHF instead of AMD64 the program quits printing "Bus error." The OpenCV version I used to write the application is 2.4.8, the version on the ARMHF machine is 2.3.1. I am using Debian and c++11 if it matters.

The offending code is

cv::resize(videoMat, scaled, scaledSize, 0, 0, CV_INTER_AREA);

Where videoMat is a cv::Mat updated by an instance of cv::VideoCapture, scaled is a cv::Mat to hold the scaled matrix information, and scaledSize is the size I wish to scaled to (30, 32).

Adding another thread did not increase perfromance. This seems to mean that both OpenGL and OpenCV are using the GPU, thus the slow rendering performance. Any suggestions are appreciated. I can't imagine my program requiring the need for OpenCL (the program is rather small), but it seems the only alternative.

CPU usage is under 50% and RAM usage is 25.8%, perhaps the maximum speed allocated for the single thread running the program is too slow. Would adding another thread to pull camera images remedy this problem? A partial fix I am using right now is slowing down the rate of taking images from the camera (waiting 25ms between each), results are somewhat better, but still not good enough.

I've written a pong video game that uses object tracking with a camera to position the paddle of the player. Everything was running smoothly until I begun grabbing input from the camera. Now the game draws very slowly and messes up game play. Is grabbing the images from the camera just slow or is this a combination of opengl and opencv slowing down the program? I am using SDL as well as the highgui module from opencv, is the conflict between the windowing API wrapers causing this issue?