[Elphel-support] auto exposure on multi sensor setup & binning question.

Wed Jun 14 10:00:53 PDT 2017

Jorick,

Yes binning/decimation is broken - we do not use it ourselves (for the reasons I explained before) so I did not notice when I broke it - it did work initially. I'll look into it, but it may take some time.

Andrey

---- On Tue, 13 Jun 2017 03:34:30 -0700 Jorick Astrego<jorick at theidiotcompany.eu> wrote ---- 

 On 05/31/2017 05:53 PM, Elphel Support wrote:

   > 
 > Hi,
 > Currently we are testing a panoramic NC393 camera and are having problems with the auto exposure on multiple image sensors. 
 > 
 > When there is half shadow, half bright light in the collective images. The image is dark on the shadow part. Does autoexposure apply globally or should every sensor apply it's own autoexposure settings?

 Jorick, with the limited dynamic range of the small format sensors it is a challenge to capture maximal data from the image, and there is no universal fits-all set of autoexposure parameters. We probably need to create some tutorial about it.

 The overall strategy is to keep maximal data from each channel - EXIF data in each image contains acquisition settings so it is possible  to match individual channels after acquisition - that just may require more than 8-bit of the intensity for the intermediate data.

 Each channel operates it autoexposure independently, so the output may not match in raw form - it needs post-processing. For example channels can be  combined in a single 16-bit per color panorama and then high-pass filter (with low cutoff frequency ~ 1/2000 pix) applied to reduce difference between bright and dark parts of the panorama.

  Thanks for the explanation, the problem we have with post processing is that for this phase of the project we are doing realtime image analytics with cuda on a MJPEG stream. 

 We will be doing some raw capturing but we're looking to trigger this on demand. 

 Maybe we could set the exposure parameters with an algorithm that does the analytics , but I don't know if that will respond fast enough and this will take up processing power. We will have to mess about with it some more ;-)

   > What would be a way to get a more balanced exposure?

 There are multiple parameters that control autoexposure, the main are window, level and fraction. The daemons (1 per each of the 4 channels) builds histograms for all pixels inside the selected rectangular area, and then calculates required exposure so the specified fraction of all pixels have values below the specified level.

 Default settings are for images where there are no very bright objects (like the Sun) in the field of view, so if the camera is pointed there the picture will become all dark. If you change the fraction to say 95%, then up to 5% of the pixels are allowed to be above the level - that level does not have to be very high, so exceeding it do not mean necessarily overexposure. Camvc program allows you to adjust this pair (fraction/level) graphically. You can turn off autoexposure, set it manually to the desired level and then move slider for the fraction - level value will be adjusted to match it.

 Ok understood, we will do some more testing.

   > Second question, is binning supported and do we have to do any aditional steps for this? We'd like to reduce the resolution while still using the whole sensor. When I set it to 1/2 Horizontally and 1/2 Vertically, the output gets corrupted.

 Binning is supported, it should all be the same as in the 353 camera. Can you please describe precisely how you've got corrupted images, we will try to reproduce (and address) the problem.

 On the other hand, binning and decimation are not r3eally good in any of the color mosaic sensors as these modes reduce resolution more than twice. Because of the Bayer mosaic (1 row):
 R1 G1 R2 G2 R3 G3 R4 G4

 R1 will be merged with R2, R3 - with R4 and similar G1 with G2:
 R1+R2, G1+G2, R3+R4, G3+G4, ...

  For the realtime anlytics the resolution is too high, currently we scale it down while processing. I was in the understanding that by binning you would have all the light but half the resolution (I tried 1/2 binning)
 So I just set horizontal and vertical to "1/2" and got the corrupted image. When I set them back to the original setting the image remains corrupted. I haven't had time to check if it stores the image uncorrupted yet.

 This could be due to the outdated firmware, so we'll start with upgrading that.

 I could probably also modify the streamer to output a lower resolution. h264/h265 support would be even better. The idea is to run the analytics and streaming and only grab the interesting frames in raw from the circular buffer.

 How difficult would a color space conversion to YUV be on the elphel? We're streaming so much the same color (green ;-) and this would save bandwith, it would also be easier to change the brightness on parts of the image.

  > 
 > 
 > 
 > Also we have a problem in the Camogm recording application, we use fast recording (without partition).
 > When I press record, I get a warning about a buffer underrun. If click away the message, recording starts and the buffers stay full.
 > When I forget to OK the warning, the elphel becomes unresponsive on the http interface after a while and it looks if the recording task hangs. 
 > 
 > A reboot doesn't work as it never reboots, we had to power off the camera to get it going again. After reboot the recording is lost from what I see.

 What firmware version do you have ? There were many changes in camogm earlier this year.

  We've received the latest firmware and we'll do some testing next week. Thanks for the quick response!

 Andrey

 Regards,
 Jorick Astrego

   Met vriendelijke groet,
With kind regards,

Jorick Astrego

     THE IDIOT COMPANY  
     Staalsteden 4-3A
 7547 TA Enschede 
 The Netherlands     +31 (0)53 20 30 275
 info at theidiotcompany.eu
 WWW.THEIDIOTCOMPANY.EU   

 _______________________________________________ 
Support-list mailing list 
Support-list at support.elphel.com 
http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20170614/e391c9d0/attachment-0001.html>