View Full Version : Stereo capture

February 26, 2016, 09:38:18
Hey Imaging Source Team,

we use two of your DFK 42BUC03 for stereo capturing. Actually we apply a software trigger to sync both cameras.
A hardware trigger is scheduled.
Generally it works well, but in same cases we lost some frames. We captured a stereo pair every 2s.
So there are time gaps of 955ms or -625ms (in this case the second camera image was captured before the first camera image)
Have you observed same issues and is there an
alternative. Or is something wrong in the following code for image acquisation (btw. is this handled in one thread):


CImageandAVICaptureDlg* pDlg = (CImageandAVICaptureDlg*)pParam;

time = std::chrono::duration_cast<std::chrono::milliseconds>std::chrono::high_resolution_clock::now().time_sin ce_epoch()).count();
if (pDlg->bCapturing && (time - pDlg->m_refTime) > pDlg->m_captureDelay)
pDlg->m_refTime = time;

pDlg->m_cam1.m_listener.m_bFrameReady = false;
pDlg->m_cam2.m_listener.m_bFrameReady = false;

while (!pDlg->m_cam1.m_listener.m_bFrameReady || pDlg->m_cam2.m_listener.m_bFrameReady)



void acquireImage()
m_img = m_listener.m_img;
m_timeStamp = m_listener.m_timeStamp;


void CListener::frameReady(Grabber& param, smart_ptr<MemBuffer> pBuffer, DWORD FrameNumber)
REFERENCE_TIME GrabberStartTime;
m_mediaSampleDesc = pBuffer->getSampleDesc();

// Compare the sample time of the incomming MemBuffer with the previoulsy
// saved Grabber reference time. If the sample time of the Membuffer is
// less (older) than the saved grabber reference time, the frame in the
// MemBuffer will not be processed.
if (m_mediaSampleDesc.SampleEnd >= m_GrabberRefTime && !m_bFrameReady)
m_bFrameReady = true;
// Get the current grabber reference time. This time needed to check, whether
// the MemBuffers that will come in, are not too old.
param.getGraphStartReferenceTime(GrabberStartTime) ;
m_GrabberRefTime -= GrabberStartTime;

void CListener::DoImageProcessing(smart_ptr<MemBuffer> pBuffer)
m_bImg = true;
m_timeStamp = m_mediaSampleDesc.SampleStart;
m_img.data = pBuffer->getPtr();

I hope you can help me with this problem.
Thanks in advance.
Marc Schulze

Stefan Geissler
February 26, 2016, 11:04:18

The images are dropped by the camera driver, if they have not been copied completely into memory from the USB controller. This can happen at two known situations:
1.) CPU Load is above 80%. I exclude this for your situation.
2.) CPU Load is very lower.

In the second case, the CPU goes into idle states and thus will pause the PCI bus too. In these pauses, the USB 2.0 controller wont be able to save data in memory and therefore picks up no new data from the camera. The camera overwrites its own USB buffer in this pause and this leads to missing data blocks.
There are two known ways of getting rid of this:
- Processor Idle State Manager, which prevents the *Intel* CPU from going into idle states. This can be downloaded from http://www.theimagingsource.com/en_US/support/downloads/details/procidlestateman/
- Use an USB 3.0 PCIe card, since the PCIe bus does not seem to be affected by idle states. (I guess so). If you use an AMD CPU, this is the recommended solution.

By software you could setup a time out. Usually the images are available after the sum of exposure time and frame rate time span in the computer. Give some milliseconds extra for safety. If the image does not arrive within this time, send a second software trigger.

February 29, 2016, 08:33:42
Thank you for this advices Stefan.
I'll try this.

best regards

March 7, 2016, 11:20:58
Hello Stefan,

we observed, that all frames are captured and none was lost, but sometime the USB-Controller is setting a wrong
timestamp and so it could happens, that ,based on this timestamp, the second camera image was captured before the first camera image.

I have an additional question.
Is there captured dark current between setting timestamp and capturing the image?

Stefan Geissler
March 7, 2016, 15:07:33
Hello Marc

Is there captured dark current between setting timestamp and capturing the image?
I do not understand the question, but I think, the answer is no.

First of all, the sensor is running all the time, except it runs triggered.
Secondly, a new exposure time comes in effect in the sensor, after it has finished the current frame.
Third, the sensor is not reset, when setting a new exposure time.
Fourth, the time stamp is set by the camera driver, when it receives the interrupt from the USB controller, that indicates, the frame is in memory.