PDA

View Full Version : IC_SetFrameReadyCallback



dllau
May 12, 2009, 21:34:52
I'm using Qt Creator (MinGW) to access the IC dll through the C wrapper loaded explicitly, but using the following code, I cannot successfully set the callback handler. What am I doing wrong?

void callback(HGRABBER hGrabber, unsigned char* pData, unsigned long frameNumber, void*);
void callback(HGRABBER hGrabber, unsigned char* pData, unsigned long frameNumber, void* userDataPtr)
{
QMessageBox::information(0, QString("EOS Controller"), QString("Inside camera callback function."), QMessageBox::Close);
}
...
narrowFOVGrabber = myICShowDeviceSelectionDialog(narrowFOVGrabber);
if (myICIsDevValid(narrowFOVGrabber)){
if (myICSetFrameReadyCallback(narrowFOVGrabber, callback, NULL) == IC_ERROR) {
QMessageBox::critical(0, QString("EOS Controller"), QString("Cannot set narrow FOV callback function."), QMessageBox::Close);
}
}

Stefan Geissler
May 13, 2009, 09:40:09
Hi,

There is a sample code in "ansi.c", that was provided with the DLL:


typedef struct SSICGrab SICGrab;
struct SSICGrab{

HGRABBER hGrabber;
int iDeviceCount;
int iHeight;
int iWidth;
int iBitsPerPixel;
unsigned char *pucImageData;
COLORFORMAT ColorFormat;
int iProcessing;
};

// Testfuction
void CallbackTest();
// the Callbackfunction
void callback(HGRABBER hGrabber, unsigned char* pData, unsigned long frameNumber, void*);

void callback(HGRABBER hGrabber, unsigned char* pData, unsigned long frameNumber, void* Data)
{
SICGrab *psICGrabCB;
psICGrabCB = (SICGrab *)Data;
printf("callback called \n");
if(!psICGrabCB->iProcessing)
{
psICGrabCB->iProcessing = 1;
printf("callback processing \n");
Sleep(1000);
psICGrabCB->iProcessing = 0;
}
}


//////////////////////////////////////////////////////////////////////////
/*!
*/
void CallbackTest()
{
int error = 0;
int iResult = 0;

SICGrab *psICGrab;

psICGrab = (SICGrab*)calloc(1,sizeof(SICGrab));
psICGrab->hGrabber = IC_ShowDeviceSelectionDialog(NULL); //Open a device
if(psICGrab->hGrabber)
{
iResult = IC_SetFrameReadyCallback (psICGrab->hGrabber, *callback, psICGrab);
IC_SetContinuousMode(psICGrab->hGrabber,0); // Call the callback for each incoming frame automatically.
IC_StartLive(psICGrab->hGrabber,1);
}

while (!kbhit()) //wait.....
{
}


//if still open -> sto and release grabber
if(psICGrab->hGrabber)
{
IC_StopLive(psICGrab->hGrabber);
IC_CloseVideoCaptureDevice(psICGrab->hGrabber);
IC_ReleaseGrabber(&psICGrab->hGrabber);
}
}


I guess, you did not call "IC_SetContinuousMode(psICGrab->hGrabber,0);". This sample is a little bit complex, because it uses the "SSICGrab" structure, that contains some more information, to be passed to the callback. This is not realy necessary, but may be helpful.

dllau
May 13, 2009, 14:57:03
That didn't help since, as in the example, set continuous mode doesn't come until after the callback is set. So here is what I did, I decided to enable live video without display to see if I could initiate some response from the camera and to determine if maybe the callback was being sent, and just returning the error flag by mistake. Regardless, here is the list of exceptions thrown when I try to enable live video:

Exception DEBUG: in d:\development\ic 3.0\ core\tisudshl\grabber.cpp at line 937:

Error = startLive failed:
VideoCaptureDevice: DMx 41BF02
VideoFormat: Y800 (1280x960)
In file: "d:\development\ic 3.0\core\tisudshl\grabberpimpl.cpp" at line : 580

Error = Failed to connect the first filter. Maybe the device is already in use by another program.
In file: "d:\development\ic 3.0\core\tisudshl\grabberpimpl.cpp" at line : 468

Error = Failed to connect the pins. Due to: No combination of intermediate filters could be found to make the connection.
In file: "d:\development\ic 3.0\core\dshowlib\filtergraph.cpp" at line : 394

Now when the above happens and while the error message is still on screen, I run DemoApp and select the same device and run live video just fine.

Any thoughts?

Stefan Geissler
May 13, 2009, 15:35:15
Well, this error message is something complete different! This has no relation to the callback call, except, without a running camera, of course no frames are delivered!

This start live message has different reasons. First of all it means, the Y800 of the camera can not be converted to another format, which can be the RGB24 color format, which is default in the sink or the color format (bit depth) of your screen.

Thus I would like you to change the bit depth of your screen and try again.

In my database I found another hint:
Set in the registry the SIDSpeed of the FireWire board to 3 and restart. This may be done, if the camera runs with low frame rates but not with 15 fps. It was a problem in Windows XP SP3.

Does the camera run in IC Capture?

dllau
May 13, 2009, 15:48:22
In my code prior to starting live video, I use the setFormat function to specify Y800 is the format. I also check to make sure that function returns without error (i.e. == IC_ERROR). I also check to make sure the device is valid and that a signal is detected. Also in the select camera dialog, I am setting the frame rate down to 3.750001 fps because the 7.5 and 15.0 settings do not work in IC Capture where 3.75 fps does. So yes, IC Capture works fine as along as I reduce the frame rate. Something of note is that I am working on an Apple Mac Book Pro in Boot camp using a Sonnet firewire 400 to 800 converted. When I run on a Dell T5400, I am able to get the full 15 fps from the camera, but I haven't tested any of my code on that Dell.

dllau
May 13, 2009, 15:52:33
One more thing of note is that in the application output (since I am in debug mode), I receive the following message from UDSHL.dll:

d:\development\ic 3.0\core\dshowlib\filtergraph.cpp(301): Graph returned S_FALSE, so not yet started...

dllau
May 13, 2009, 15:56:36
Some progress here is that when I set the startLive view iShow parameter to 1 (show the video), video does pop up and fill my screen. I never assigned a window handle, so the video is not contained in a window. Also, I do not receive any exception and the startLive() returns without error. So my problem is limited to having iShow parameter set to 0.

Stefan Geissler
May 13, 2009, 15:57:49
Hi,

interresting. Could you please test your code on the DELL too?

Also IC Capture uses different formats in the sink, while the Sample Demoapp uses rgb24. Thus I would like you to check RGB24 too. Simply comment the line, where you set the color format, it is RGB24 by default.

dllau
May 13, 2009, 16:08:28
Commenting out the setFormat command seems to work fine where I get video when iShow is set to 1.

Separately, I now see that the exception is thrown regardless of the state of iShow if I have a frame rate of 7.5 or 15 fps. So its happening whenever IC capture would have otherwise alerted me to the fact that the firewire port could not support that high of a frame rate. Perhaps, I should use prepareLive as a way of predetermining this without an exception being thrown?

Now with regards to having iShow equal to 0 and the frame rate set to 3.15, I do not get an exception thrown and the startLive returns without error, but I still get the message:

d:\development\...\filtergraph.cpp(301): Graph returned S_FALSE, so not yet started...

Stefan Geissler
May 13, 2009, 16:11:38
Please ignore the message. It is usual spamming of the library.

dllau
May 13, 2009, 16:16:36
Is it possible that, having a 3.75 fps, the camera and SDK are working just fine except that the callback function has not been set, and hence I have no feedback mechanism to otherwise determine if video is being fed to the CPU?

Stefan Geissler
May 13, 2009, 16:20:45
Well, I think, the limitation is either your bootcamp or the SIDSpeed problem of the FireWire board.

However, the callback should work, regardless of the frame rate.

dllau
May 13, 2009, 16:23:35
Well here is a question. Should I use the setCallback command as:

setFrameReadyCallback(grabber, callback, NULL);

or

setFrameReadyCallback(grabber, *callback, NULL);

?

Stefan Geissler
May 13, 2009, 16:30:51
Hi,

setFrameReadyCallback(grabber, *callback, NULL);

as shown in the sample above. Otherwise your compiler should complain.

dllau
May 13, 2009, 16:32:46
I would have thought so too, but it seems to compile regardless.

Stefan Geissler
May 13, 2009, 16:35:09
Fine. I have no experiences with the mingw compiler. Sorry for that.

dllau
May 14, 2009, 20:48:36
I just recompiled all of my code using Qt Creator with mingw on a Dell T5400, with the same result. I can get video to the screen, but it won't accept my callback function. It will accept up to 15 fps without throwing any exceptions/crashing.

This being the case, I can't help but wonder if anyone has been able to get the ansic sample to run after having been compiled using mingw. If so, what exact command should I use to compile the code? If not, then what C/C++ compiler should I be using aside from Visual Studio?

Stefan Geissler
May 15, 2009, 08:16:49
Can you please send me your code? You may answer on my last email to you.

dllau
May 17, 2009, 00:09:45
Please resend...

Stefan Geissler
May 18, 2009, 09:16:08
Please resend..
I would like to, but I do not know, who "dllau" is.

dllau
May 18, 2009, 13:17:58
dllau (at) engr (dot) uky (dot) edu

dllau
May 21, 2009, 18:04:44
Dear Stefan;

I wanted to thank you for your assistance fixing my code. I can now say that everything is working correctly. So just to review the changes that I had to make such that viewers of this forum will not make the same mistakes when using the mingw compiler. The first thing I had to do was modify the tisgrabber.h file's callback declaration as:

typedef void __cdecl (*FRAME_READY_CALLBACK)(HGRABBER hGrabber, unsigned char* pData, unsigned long frameNumber, void* );

I also had to declare my callback function as:

void __cdecl callback(HGRABBER hGrabber, unsigned char* pData, unsigned long frameNumber, void* userDataPtr)

Separately, the issue I was having with the setFrameReadyCallback routine was that I was expecting the function to return 1 (IC_SUCCESS) on success or 0 (IC_ERROR) if not successful. I now know that the function returns 0 (IC_ERROR) on success or -1 (NO_FRAMER_GRABBER) on failure. I noticed that this same set of returns values is used by setContinuousMode. I'm also glad to know that the cont flag of setContinuousMode should be set to 0 if we continuous mode on and 1 if we want it off. By using cont=1, my callback function was not called repeated with each frame grab and only on the snap picture.

Sincerely,
Dan