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 .
Related
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,
I have an application that collects heart rate data and displays in in a GUI. I don't want to change anything about how the application runs, but want to save the data into a .csv file to use with data manipulation programs. The program is called BluetoothGattHeartRate. I am running the sample code found here.
My addition to the code is just
std::fstream theDump;
theDump.open("path/to/file", std::fstream::out);
if (theDump.is_open())
{
theDump.write("ImHere", 6);
}
theDump.close();
inserted into the file called HeartRateService.cpp in the Shared directory in the void HeartRateService::Characteristic_ValueChanged(GattCharacteristic^ sender, GattValueChangedEventArgs^ args) function just before the call to ValueChangeCompleted(heartRateValue);. I'm using Microsoft Visual Studio to edit and run the code, as the tutorial online says. This exact code succeeds in editing the file when run in an independent application, but it fails to open the file (I tested for this) when run in the Gatt sample code.
I don't expect that anyone has dealt with this before, but if by some miracle one of you has figured this out, please let me know how you fixed it.
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 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);
}
I do some image processing work in C++. For this i use CImg.h library which i feel is good for my work.
Here is small piece of code written by me which just reads an image and displays it.
#include "../CImg.h"
#include "iostream"
using namespace std;
using namespace cimg_library;
int main(int argc,char**argv)
{
CImg<unsigned char> img(argv[1]);
img.display();
return 0;
}
When i give lena.pgm as input this code it displays the image. Where as if i give some other image, for example ddnl.pgm which i present in the same directory i get "Segmentation Fault".
When i ran the code using gdb i get the output as follows:
Program received signal SIGSEGV, Segmentation fault.
0x009823a3 in strlen () from /lib/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.9-2.i686 libX11-1.1.4-5.fc10.i386 libXau-1.0.4-1.fc10.i386 libXdmcp-1.0.2-6.fc10.i386 libgcc-4.3.2-7.i386 libstdc++-4.3.2-7.i386 libxcb-1.1.91-5.fc10.i386
Can some one please tell me what the problem is? and how to solve it.
Thank you all
Segfault comes when you are trying to access memrory which you are not allowed to access.
So please check that out in the code.
The code itself looks just fine. I can suggest some ways to go ahead with debugging -
Try removing the display() call. Does the problem still occur? (I'd assume it does).
Try finding out where in the CImg code is the strlen() that causes the segmentation fault (by using a debugger). This may give additional hints.
If it is in the PGM file processing, maybe the provided PGM file is invalid in some way, and the library doesn't do error detection - try opening it in some other viewer, and saving it again (as PGM). If the new one works, comparing the two may reveal something.
Once you have more information, more can be said.
EDIT -
Looking at the extra information you provided, and consulting the code itself, it appears that CImg is failing when trying to check what kind of file you are opening.
The relevant line of code is -
if (!cimg::strcmp(ftype,"pnm")) load_pnm(filename);
This is the first time 'ftype' is used, which brings me to the conclusion that it has an invalid value.
'ftype' is being given a value just a few lines above -
const char *const ftype = cimg::file_type(0,filename);
The file_type() function itself tries to guess what file to open based on its header, probably because opening it based on the extension - failed. There is only one sane way for it to return an invalid value, which would later cause strcmp() to fail - when it fails to identify the file as anything it is familiar with, it returns NULL (0, actually).
So, I reiterate my suggestion that you try to verify that this is indeed a valid file. I can't point you at any tools that are capable of opening/saving PGM files, but I'm guessing a simple Google search would help. Try to open the file and re-save it as PGM.
Another "fun to track down" cause of segmentation faults is compilier mismatches between libraries - this is especially prevalent when using C++ libraries.
Things to check are:
Are you compiling with the same compiler as was used to compile the CImg library?
Are you using the same compiler flags?
Were there any defines that were set when compiling the library that you're not setting now?
Each of these has bitten me in subtle ways before.