PDA

View Full Version : Exposure settings / timing issue



florixyz
January 23, 2014, 15:46:02
Hello,

how do the USB cameras (DFK 42BUC03) handle the timing of VCD Property settings, trigger, and exposure?
My situation:
- I set the exposure value
- I call a software trigger
- When receiving the next image, in the ImageAvailable event,
I set another exposure value and wait for a hardware trigger
- ...

Now in some cases the exposure value has not been set when the hardware trigger arrives. I assume the hardware trigger arrives just while the ImageAvailable event is processing, as it cannot arrive while the camera is still transmitting (in that case it would be ignored, right?).

Now the question: can I set the second exposure value directly (or 1-2 ms) after pushing the software trigger? Or will this then be applied during exposure of the current image? Or in other words: When I change the exposure while an image is being exposed or transmitted, does that (potentially) affect that image, or only the next?

Thanks!

Stefan Geissler
January 24, 2014, 11:37:43
Hello

As far as I know, you can send the exposure time and other camera parameters at any point of time. Unfortunately, the exposure time will be passed to the sensor, even if it is in process of exposing. I tested this with IC Capture: Set exposure time to 4 seconds. Perform a software trigger and immediately set a lower exposure time. You will receive an image, that is darker than expected.

I am not sure, whether this is a feature or a bug.

Therefore, try to make sure to set exposure time, if the sensor does not expose. I know, this is said easier than to be done.

florixyz
January 24, 2014, 15:23:52
Thanks!

Well, my exposure times are ~0.001, so the problem is not that big that I would overwrite during exposure if I add a long enough sleep or set the exposure in the next image available event. However, randomly (it seems), the camera misses the exposure settings.
I dug into this issue and found that the exposure setting only seems to be sent to the camera after(!) the ImageAvailable event method has returned. Now if this method takes a long time (to save an image when the disk is currently slow), the exposure is not set, but the next image exposed by the camera (external trigger), transferred to the host (during this the exposure setting is updated), and the received by ImageAvailable.
So it seems that all the camera communication is synchronuosly running in the same thread. While this is not an issue, because one can avoid to do time consuming stuff in the event callback, it would be nice to have a) a buffer of events (so no incoming image is discarded) and b) asynchronuos setting of the parameters etc. by a separate thread. Or at least make a note in the documentation about this behaviour, and possible extend the examples which save the image directly in the callback to making use of a buffer

Best regards,
Florian

Stefan Geissler
January 24, 2014, 15:31:01
Florian,

I would like you to have a look at
http://www.imagingcontrol.com/en_US/support/documentation/dotnet/prop_descICImagingControl_ImageAvailableExecutionM ode.htm
and
http://www.imagingcontrol.com/en_US/support/documentation/dotnet/enum_descrefenum_EventExecutionMode.htm

Maybe this solves your issue.

florixyz
January 27, 2014, 08:47:26
Thanks Stefan!

That's a useful setting. It did change the behaviour, but I don't know if it's better.
I think the problem now is a different one. I'm capturing many images at about 20 fps with an external trigger. Approx. every 100th image is missing (USB transmission error?), or sometimes I get corruptions in the image (pink lines etc.). The image is not dropped during saving to disk, it simply never gets into the ringbuffer and no ImageAvailable Event is triggered.
One question here: Could there be a situation when the image gets written to the ringbuffer, but no ImageAvailable event is called? I.e. the event is called for index 0, then an image is written to index 1, and then to 2, and then the event is called for 2 -- given that I'm using MultiThreaded or AsyncInvoke as Execution Modes?

I'm using the PISM, but still these problems occur. Intel core i3 CPU, samsung laptop with usb 2.0 ports, usb 2.0 cable from a usb 2.0 harddrive.

Also, do you think using a PC with USB 3.0 (to connect the USB 2.0) camera would reduce or remove the problem?

Best,
Florian

Stefan Geissler
January 27, 2014, 09:51:30
Florian

An USB 3.0 port could reduce the problem. However, I did not try the 42BUC03 on an USB 3.0 port on my own.
If the PISM does not have an effect on Windows 7 or 8, then you have some more hardware issue. Please check, whether other devices, e.g. bluetooth, modems etc are connected to the same USB controller. Sometimes, they generate traffic and then the camera is interrupted.

florixyz
January 27, 2014, 16:42:14
No other devices are connected.

Do you have an answer to this:


One question here: Could there be a situation when the image gets written to the ringbuffer, but no ImageAvailable event is called? I.e. the event is called for index 0, then an image is written to index 1, and then to 2, and then the event is called for 2 -- given that I'm using MultiThreaded or AsyncInvoke as Execution Modes?

Stefan Geissler
January 28, 2014, 08:33:14
Florian


Could there be a situation when the image gets written to the ringbuffer, but no ImageAvailable event is called? I.e. the event is called for index 0, then an image is written to index 1, and then to 2, and then the event is called for 2 -- given that I'm using MultiThreaded or AsyncInvoke as Execution Modes?

Yes. This happens, if the ImageAvailable call did not return in the time, a new frame is delivered from the camera. This happens in multi threading environment.

Please see the C++ "Callback" sample for this, it demonstrates this effect.
http://www.imagingcontrol.com/en_US/support/documentation/class/Callback.htm

Also a Sleep(250) is used to simulate a time expensive processing operation. Therefore, the GrabberListener::frameReady method is not called for all captured buffers.

But all images are saved in the ring buffer.


The .NET component is based on the C++ Classlibrary.

ahmed.mlj
April 1, 2014, 13:20:16
Hi,
I am trying to generate different images with different exposure values, I am still confused with the buffer manipulation.
i tried this code and used opencv to show frames, but still haing problems:
noisy images with fringes ,
only one exposure value is presented in both images.




double exposure_value_0,exposure_value_1;
exposure_value_0=0.02;//seconds
exposure_value_1=1/6;//seconds

Set_Exposure_Auto(m_pGrabberLeft, false);
Set_Gain_Auto(m_pGrabberLeft, false);
smart_ptr<MemBuffer> pBuffer1=NULL;
smart_ptr<MemBuffer> pBuffer2=NULL;
while(1)
{

if( !pSinkL->getFrameCount())// if no frames restart Live mode
m_pGrabberLeft->startLive(false);
//---------- first frame with first exposure value
SetExposureAbsolute(m_pGrabberLeft,exposure_value_ 0);
pBuffer1= pSinkL->getLastAcqMemBuffer();
//pBuffer1->lock();
memcpy( (unsigned char *)mFrame1.data,pBuffer1->getPtr(),h*w*3 ); //4 =32 ,3=24
//pBuffer1->unlock();
//pBuffer1=NULL;

//Show image with opencv
//rotate image2
warpAffine( mFrame1, mFrame1, mRot, mFrame1.size() );
cv::flip(mFrame1,mFrame1,1);
imshow("image1",mFrame1);
//---------- Seccond frame with another exposure value
SetExposureAbsolute(m_pGrabberLeft,exposure_value_ 1);
pBuffer2= pSinkL->getLastAcqMemBuffer();
//pBuffer2->lock();
memcpy((unsigned char *)mFrame2.data,pBuffer2->getPtr(),h*w*3 ); //4 =32 ,3=24
//pBuffer2->unlock();
//pBuffer2=NULL;

//Show image with opencv
//rotate image2
warpAffine( mFrame2, mFrame2, mRot, mFrame2.size() );
cv::flip(mFrame2,mFrame2,1);
imshow("image2",mFrame2);

c =waitKey(1);// for real-time
if( c == 27 || c == 'q' || c == 'Q' )
break;


//}
}


Any idea please.

Stefan Geissler
April 1, 2014, 13:28:18
maybe it is a good idea to call snapImages() so you receive an image at all?

SetExposureAbsolute(m_pGrabberLeft,exposure_value_ 0);
pSinkL->snapImages(2);
pBuffer1= pSinkL->getLastAcqMemBuffer();

2 images, because the new exposure value is set after a frame is delivered.