I am writing a program that uses OpenCV and involves intrinsic and distortion parameters. These parameters are loaded from .xml files saved on disc. I use the following commands in my opening declarations to load the files:
CvMat *intrinsic = (CvMat*)cvLoad("Intrinsics.xml");
CvMat *distortion = (CvMat*)cvLoad("Distortion.xml");
This works fine as long as the files are in the program's working directory. When they are not, the program crashes without any indication of the nature of the error. I have made the mistake of not having the xml files located correctly multiple times before, and I would like to make this easier to troubleshoot in the future.
I would like to create a guard against the files failing to load. Perhaps if they are not present my program could display an error message and exit gracefully. I saw the method suggested here, and it should work for me, but I was wondering if there was a cleaner way to do it without including another header.
For example, the OpenCV function cvQueryFrame returns 0 if it does not return a frame. I use the code
frame = cvQueryFrame(capture);
if(!frame)
{
printf("ERROR: Could not get frame from webcam.");
exit(-1);
}
to exit the program if cvQueryFrame fails to return a frame. I would like to do something similar with my matrix loading commands. Is this possible, and if so, how should I do it?
I checked the OpenCV documentation and could not find a description of cvLoad's behaviour when it cannot find the file specified so I am not sure how to proceed.
I am writing this project in C++ and running it on Windows 7.
It works. Go ahead and try it yourself:
CvMat *distortion = (CvMat*)cvLoad("Distortion.xml");
if (!distortion)
{
printf("!!! cvLoad failed");
exit(-1);
}
Related
I am writing a Qt program using matlab dll, the matlab function is very simple, However I encountered some exception caused by initializing problem. So I have changed my part of code as below.
void DicomViewer::on_pushButton_clicked()
{
if(libMyAddInitialize()){
mwArray dicomArray2=Mat2mwArray(dicomMat1);
//c_matlab(1,dicomArray2,Mat2mwArray(dicomMat1));
mwArry2Mat(dicomArray2).copyTo(dicomMat2);
dicomImgShow(TEMPDICOM2);
libMyAddTerminate();
}
}
This part of the code provides a button to change my cv::Mat data. I am using two functions Mat2mwArrayandmwArray2Mat to convert Mat between mwArray. Funciton dicomImgShow is to show the Mat to My program. That I think code is not the key problem.
My Key problem is The button function only work in my local disk (C:/ and D:/). I put it into my U disk and it failed. I also tried to run it in admin mode, but failed again. So I wonder what's wrong in my program.
Thanks for anyone who come to help .
The Point Cloud library comes with an executable pcl_hdl_viewer_simple that I can run (./pcl_hdl_viewer_simple) without any extra arguments to get live data from a Velodyne LIDAR HDL32.
The source code for this program is supposed to be hdl_viewer_simple.cpp. A simplified version of the code is given on this page which cannot be compiled readily and requires a tiny bit of tweaking to make it compile.
My problem is that the executable that I build myself for both the versions are not able to run. I always get the smart pointer error "Assertion px!=0" error. I am not sure if I am not executing the program in the correct way or what. The executable is supposed to be executed like
./hdl_viewer_simple -calibrationFile hdl32calib.xml -pcapFile file.pcap
in case of playing from previously recorded PCAP files or just ./hdl_viewer_simple if wanting to get live data from the real sensor. However, I always get the assertion failed error.
Has anyone been able to run the executables? I do not want to use the ROS drivers
"Assertion px!=0" is occurring because your pointer is not initialized.
Now that being said, you could initialize it inside your routines, in case the pointer is NULL, especially for data input.
in here, you can try updating the line 83 like this :
CloudConstPtr cloud(new Cloud); //initializing your pointer
and hopefully, it will work.
Cheers,
This is driving me up the wall..
I've got a very simple SDL2 program.
It has a array of 3 SDL_Texture pointers.
These textures are filled as follows:
SDL_Texture *myarray[15];
SDL_Surface *surface;
for(int i=0;i<3;i++)
{
char filename[] = "X.bmp";
filename[0] = i + '0';
surface = SDL_LoadBMP(filename);
myarray[i] = SDL_CreateTextureFromSurface(myrenderer,surface);
SDL_FreeSurface(surface);
}
This works, no errors.
In the main loop (which is just a standard event loop waiting for SDL_QUIT, keystrokes and a user-event which a SDL_Timer puts in the event queue every second) I just do (for the timer triggered event):
idx = (idx+1) % 3; // idx is global var initially 0.
SDL_RenderClear(myrenderer);
SDL_RenderCopy(myrenderer, myarray[idx], NULL, NULL);
SDL_RendererPresent(myrenderer);
This works fine for 0.bmp and 1.bmp, but the 3rd image (2.bmp) simply shows as a black field.
This is structural.
If I alternate the first 2 images they are both fine.
If I alternate the 2nd and 3rd image the 3rd image doesn't show.
If I use more than 3 images then 3 and upwards show as black.
Loading order doesn't matter. It starts going wrong with the 3rd image loaded from disk.
All images are properly formatted BMP's.
I even saved 2.bmp back to disk under a different name by using SDL_SaveBMP() after it was loaded to make sure it got loaded in memory OK. The new file is bit for bit identical to the original.
This program, without modifications and the same bmp files, works fine on OSX (XCode5) and Windows (VC++ 2012 Express).
The problem only shows on the Raspberry PI.
I have placed explicit error checks on every call that can leave a result/error-code (not shown in the samples above for brevity) but all of them show "no error".
I have used the latest stable source set of www.libsdl.org and compiled as instructed (configure, make, make install, etc.).
Anybody got any idea what could be going on ?
P.S.
Keyboard input doesn't seem to work either on my PI, but I haven't delved into that yet.
Answering myself as I finally figured it out myself...
I finally went back to the README-raspberrypi.txt that came with the SDL2 sources.
I didn't read it carefully enough the first time around...
Problem 1: I'am running on a FULL-HD display. The PI's default GPU memory is 64MB which is not enough for large displays and double-buffering. As suggested in the README I increased this to 128MB and this solved the black image problem.
Problem 2: Text input wasn't working because my user-account was not in the input group. I had added the default "pi" account to the input group initially, but when I later started using another account I forgot to add that user to the group.
In short: Caught by my own (too) quick skimming of the documentation.
I have this short C++ program which takes snapshot images from a camera in a loop and displays them:
void GenericPGRTest::execute()
{
// connect camera
Camera *cam = Camera::Connect();
// query resolution and create view window
const Resolution res = cam->GetResolution();
cv::namedWindow("View");
c = 0;
// keep taking snapshots until escape hit
while (c != 27)
{
const uchar *buf = cam->SnapshotMono();
// create image from buffer and display it
cv::Mat image(res.height, res.width, CV_8UC1, (void*)buf);
cv::imshow("Camera", image);
c = cv::waitKey(1000);
}
}
This uses a class (Camera) for camera control I created using the Point Grey SDK and functions from the OpenCV library to display the images. I'm not necessarily looking for answers relating to the usage of either of these libraries, but rather some insight on how to debug a bizarre problem in general. The problem is that the application freezes (not crashes) on the cam->SnapshotMono() line. Of course, I ran through the function with a debugger. Here is the contents:
const uchar* Camera::SnapshotMono()
{
cam_.StartCapture();
// get a frame
Image image;
cam_.RetrieveBuffer(&image);
cam_.StopCapture();
grey_buffer_.DeepCopy(&image);
return grey_buffer_.GetData();
}
Now, every time I step through the function in the debugger, everything works OK. But the first time I do a "step over" instead of "step into" SnapshotMono(), bam, the program freezes. When I pause it at that time, I notice that it's stuck inside SnapshotMono() at the RetrieveBuffer() line. I know it's a blocking call so it theoretically can freeze (no idea why but it's possible), but why does it block when running normally and not when being debugged? This is one of the weirdest kinds of behaviour under debugging I've seen so far. Any idea why this could happen?
For those familiar with FlyCapture, the code above doesn't break as is, but rather only when I use StartCapture() in callback mode, then terminate it with StopCapture() before it.
Compiled with MSVC2010, OpenCV 2.4.5 and PGR FlyCapture 2.4R10.
Wild guess ... but may it be that StartCapture already starts the process that
ends up with having the buffer in ìmage, and if you step you leave it some
time until you get to RetrieveBuffer. That's not the case if you run it all at once ...
I'm trying to adapt a code in order to add a sound capture feature (on a live stream), with the help of ffmpeg and directshow.
When i try to play with ffplay the AVIsynth file, everything works perfectly i've got the audio and video. But when i open this input file by code i only find the video stream.
The Avs file :
V = DirectShowSource("Decklink_HDMI.grf", fps=10, framecount=1000000000, seek=false, audio=false)
A = DirectShowSource("Decklink_Audio.grf", fps=1, framecount=1000000000, video=false)
AudioDub(V, A)
The opening code :
ffmpeg::AVInputFormat * ifmt;
ifmt = ffmpeg::av_find_input_format("avs");
// Open input file
if(ffmpeg::avformat_open_input(&pFormatCtx, filename.toStdString().c_str(), ifmt, NULL) != 0)
When i make a variable lookout on gdb just after the opening.
i'm looking at nb_streams in pFormatCtx->nb_streams and it's at 1
The only stream i can find in pFormatCtx->stream is a video one. And that's why i'm not able to capture the sound.
So i'm asking if i'm doing something wrong with my opening or if i miss something.
Ps : I know the code shown is short but the problem appears at this very step !
Thank you
Kurt
-- EDIT --
I've also noticed that when I dump the AVFormatContext the video stream got a 456x32 size.
And i can find this very same size of the window displayed when i try to launch a corrupted script with ffplay.
The original video format when i play the correct script with ffplay is of 1920x1080
I think my problem is maybe deeper than the simple fact of not being able to get the audio stream.
I'm trying to find out how to know the error message that is displayed on this 456x32 windows
-- EDIT2 --
I Find out what is written on this image and my problem is solved, badly placed avs script an old one was is place.
I'm ashamed.
My bad,
A badly placed avs file was my problem.
Anyway ffmpeg is a bit painful in his way of showing error, being forced to make a snapshot without any error msg or exception raised (or maybe did i failled).