View Full Version : IC Imaging 2.1 -> 3.0
November 23, 2006, 09:25:54
I'am working with "IC Imaging Control 2.1 - ClassLib" and VC71
My application is using callback function ( m_pGrabber->setCallback(callback) ) and
m_pGrabber->setSinkType( FrameGrabberSink(FrameGrabberSink::eGRAB, eRGB24) );
m_pGrabberBuffer = m_pGrabber->newMemBufferCollection(5);
//--- Start capture
and the callback function
void zz_callBackFrame(void *data, DShowLib::Grabber::tMemBufferPtr pBuffer, unsigned long currFrame)
//--- Get current Buffer
m_pTmpBuffer = m_pGrabber->getActiveMemBuffer();
How can i do the same thing with "IC Imaging Control 3.0 - ClassLib" and VC71"
November 23, 2006, 09:58:53
The sinks have changed a little bit in IC 3.0. First of all you have to declare the FramHandlerSink:
The new FrameHandlerSink is created as follows:
m_pSink = DShowLib::FrameHandlerSink::create( DShowLib::eRGB24, 5 );
This creates a sink with 5 buffers in the RGB24 color format.
Then you would have to set the snapmode (eGRAB/eSNAP in 2.1):
m_pSink->setSnapMode( true );
The last step is to assign the new FrameHandlerSink to the Grabberobject:
m_Grabber.setSinkType( m_pSink );
Now the FrameHandlerSink is determined and can be used as usual.
You may also have a look into the "Callback" sample:
// Create the frame handler sink
smart_ptr<FrameHandlerSink> pSink = FrameHandlerSink::create( DShowLib::eRGB24, 5 );
// enable snap mode (formerly tFrameGrabberMode::eSNAP).
pSink->setSnapMode( true );
// Apply the sink to the grabber.
grabber.setSinkType( pSink );
This does exactly what you want to do. It is also recommended to refer to
November 23, 2006, 11:51:07
Thank's, but it's not OK !!
I'am working with "m_pSink->setSnapMode(false);"
I replace the callback by a CListener class but i have some problems in the "CListener::frameReady". The images are not showed in the good order, sometime the same image is showed more than once !
Is this code OK for you ?
in the main program
// Assign the number of buffers to the cListener object.
// Register the pListener object for the frame ready event.
m_pSink = DShowLib::FrameHandlerSink::create( DShowLib::eRGB24, 5);
void CListener::frameReady( Grabber& caller, smart_ptr<MemBuffer> pBuffer, DWORD currFrame)
0, 0, 768L , 576L,
0, 0, 0, 576L,
November 23, 2006, 11:58:29
With IEEE1394 converter it's OK, but with USB2 converter, it's not good !
November 23, 2006, 12:28:30
This program is running OK with "IC Imaging Control 2.1 - ClassLib"
with IEEE1394 or USB2.0 converter.
The same program "IC Imaging Control 3.0 - ClassLib" is running OK with IEEE1394 converter but NOT with USB2.0 converter.
November 29, 2006, 15:10:48
I tested it with the usb-converter and the vc71 callback sample, but I can't
reconstruct this problem. All frames are showed in correct order and there is never showed one image more than once.
Only if the processing in eFRAMEREADY takes too long, some frames are ignored.
Please look at the 'callback' sample again, which shows exacly that.
December 1, 2006, 08:57:50
I would like to know how you determined that the same image has been delivered twice. I also would like to know whether the frame times have been the same. The frame times (start and end) are created by the driver.
Thank you advance.
Powered by vBulletin® Version 4.2.3 Copyright © 2017 vBulletin Solutions, Inc. All rights reserved.