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
i...@theidiotcompany.eu
WWW.THEIDIOTCOMPANY.EU
_______________________________________________
Support-list mailing list
Support-list@support.elphel.com
http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com
