Best practice when camera exposure must be changed between each grab?

[another_novice]

Hi all,

I'm acquiring two images in fairly quick succession from a GigE camera. In an initialization state I use 'Open' then 'Configure Grab'. Then, in my acquire state I read in the exposure required via a property node and use a 'Grab'. Then I loop around and do a second 'Grab'. The first image has a long exposure, the second image needs a shorter exposure.

Mostly this works well but occasionally my second image is too bright (meaning the exposure is too long.) Is this a problem with how I'm acquiring the image? (Is 'Grab' the best vi to use?) Or, do I need to give the camera more time to make the change? (Add in a delay?)

All thoughts must appreciated.

[udka]

-Can you please provide which camera you are using exactly?
-What is the exposure time you are using for first image and second image?
-Did you try in NI MAX and confirm the same behavior?
-Are you triggering by external or internal?
-Can you also tell what are the values for ExposureMode, Exposure Auto for the same if it has ?
-May be providing code and screenshot will help debug more!!!

[SamiBenF]

The problem is that you never really know when your new exposure is received and when it is applied.

Moreover when you call the grab, you do not really acquire an image (the acquisition process in your case seems to be continuous), you just read an image in the computer memory.

So your Grab/change exposure time/grab sequence does not include the "real" acquisition process (exposing the camera sensor to generate an image).

There are many possibilities, most of them require triggering. For most of them I would recommend the use the "low level" Vis instead the "Configure Grab/Grab" ones :

 1-  For every image, stop acquisition, set exposure then start acquisition and get the image.

 2- One technique you could try, is to use software trigger to control the image acquisition process :

    - configure the camera to trigger mode and Software trigger as the trigger source

    - for each image :

           - set the exposure time,

           - if needed, add a short delay

           - use a property node to generate a sw trigger

           - read the image.

 3- Most of cameras include a pulse width trigger mode : the width of the exposure pulse defines the exposure time for the image. So, if you're able to generate a pulse train with alternate pulse widths (long pulse for the first image, short pulse for the second one), it is probably the most efficient way as you can use the camera at maximum frame rate if your trigger pulse train is well defined.

 4- Some cameras have special features dedicated to the task you want to implement : for instance if you use a Sony camera, you may check if it includes a feature called bulk mode.

Photonfocus cameras have a powerful I/O controller that you can use to create sophisticated tasks. However, this will probably require a good understanding if the hardware and maybe some tricky programming.

Hope this helps,

Sami

[weigsvader]

Hey guys,

i dunno what is your desired Framerate, but i attached a vi which shows basic functionallity u are looking for. After setting a Value to the Camera the VI enters a while loop and reads back the set Value in each iteration. If the desired Value doesnt match the actual one, the loop continues. When the camera adjusted the Values, they match and the loop breaks. Afterwards another picture is taken.

As my Webcam on the Laptop doesent support Exposure Time as configureable Value, my example shows the general use of this read-back by saturation. In my expierience the node doesnt affect the Framerate in a critical way its more the dx Grab.vi.

If u want to try this example.vi check out the supported methods and the corresponding values to the methods for your specific camera in the MAX. Otherwise the chance of getting an Error is pretty high.

I would recommend as my preposter to go for the basic.vi palette too....

hf cheers chris

[BlueCheese]

I don't think that example does what you think it does. The read-back value of a GenICam feature will typically always be whatever you just wrote. It is not the Genicam model to have a write to a feature not "stick", regardless of whether the action takes effect immediately or not.

[FM82]

---

BlueCheese ha scritto:

I don't think that example does what you think it does. The read-back value of a GenICam feature will typically always be whatever you just wrote. It is not the Genicam model to have a write to a feature not "stick", regardless of whether the action takes effect immediately or not.

---

You are right. I have found the same behaviour you described on an Imaging Source camera. Cycling by reading the exposure value, after setting it, mean exit from the loop on the first cycle.

[weigsvader]

Answering to your Quote:

---

I don't think that example does what you think it does. The read-back value of a GenICam feature will typically always be whatever you just wrote. It is not the Genicam model to have a write to a feature not "stick", regardless of whether the action takes effect immediately or not.

---

I understood your statement the following way - correct me if iam wrong:

If u write a value to the cam, and read it back aftwards, you have no knowledge about what the real value of the parameter is.

In my 3-4 cameraprojects i experienced an absolutly different behaviour..

To prove my opinion i changed my attached example.vi a little bit. Now the saturation switches between Min and Max, respective b/w and colored (remember this is an camera attribute not an aquisition).

If u run the vi und can see, that all image taken are following the behaviour of my read-back implementation - 1 image b/w, 1 colored.

I implemented on some different camera types/projects automated sharpness adjustments etc., these wouldnt run the way the they does, if the behaviour u discribed where right.

If u were right and the written value doesnt correspond with the one which is read back, i have a following question to you.

Where the value you get from the read node comes from, and what part of hardware/software produced it?

looking forward to hear from u.

cheers chris

[BlueCheese]

How many loop cycles does your camera actually read back the old value? If it always reads back the new value, the code would still work as written---the loop would just exit immediately.

I should mention that this behavior is potentially camera-specific. If you are using a webcam or other DirectShow-interfaced device, it is certainly possible the driver or camera hardware could have different behavior if you read back the value right away after setting it. I have never actually seen any camera behave the way you suggest and it would certainly mess with the way the UI in applications like MAX work, so I'm a bit skeptical for this behavior to be all that common. The way caching works through GenICam on industrial cameras (GigE Vision, USB3 vision) would also make this behavior hard to implement.

Finally, keep in mind that there is not necessarily any synchronization between the image acquisition pipeline and the camera attribute settings. Even if you see the value "stick" after some time, you have no real guarantee that the next image acquired will actually have the new setting, as it is entirely possible it was exposed or acquired before this time. It really is camera-dependent as to how deep that pipeline is. Most industrial cameras have functionality to record the camera settings (usually the major ones like exposure time) as meta-data inside the image stream itself (ChunkData) so you can see the exact image that the new setting took place.

Eric

[FM82]

---

Finally, keep in mind that there is not necessarily any synchronization between the image acquisition pipeline and the camera attribute settings. 

---

Absolutely true!

[FM82]

Finally i managed to work with another GigE camera. I can confirm what said before. To properly set exposure (but i think any other setting) you need to stop live acquisition, made modifications and only then start again live. I hope it will help someone in the future!

Bye, Francesco.