Raspistill automatic shutter speed setting fails in low light

[shusheer]

Problem: Whatever algorithm is used for iteratively changing shutter settings for Raspistill fails under very low light settings.

To reproduce: On Raspberry Pi B+ with attached Camera Module, cover the camera with your hand or other black-out material and execute:

raspistill -set -ISO 100 -ev -18 -t 100 -o test.jpg

This should give an output showing the auto shutter speed setting algorithm working to try and increase shutter speed (presumably up to some limit). The -set parameter shows us what is going on, and the -t parameter seems to need to be about ~500 to get a reasonable estimate in low light

Output under moderately low ambient light, algorithm finds suitable shutter speed at ~66msec, which is presumably the maximum shutter open time for 15-fps-video.

mmal: Exposure now 9995, analog gain 256/256, digital gain 256/256 mmal: AWB R=266/256, B=487/256 mmal: Exposure now 33350, analog gain 304/256, digital gain 256/256 mmal: AWB R=266/256, B=487/256 mmal: Exposure now 58330, analog gain 304/256, digital gain 256/256 mmal: AWB R=268/256, B=481/256 mmal: Exposure now 58330, analog gain 304/256, digital gain 256/256 mmal: AWB R=270/256, B=475/256 mmal: Exposure now 64575, analog gain 304/256, digital gain 256/256 mmal: AWB R=271/256, B=469/256 mmal: Exposure now 64575, analog gain 304/256, digital gain 256/256 mmal: AWB R=272/256, B=463/256 mmal: Exposure now 66131, analog gain 304/256, digital gain 256/256 mmal: AWB R=273/256, B=458/256 mmal: Exposure now 65997, analog gain 256/256, digital gain 256/256 mmal: AWB R=274/256, B=453/256

Output under very low light, camera covered, algorithm fails and sets shutter speed to something very low, resulting in entirely black image. Note that the algorithm "knows" enough to know that a low number is impractical, is it is only the last entry that has a low exposure value:

mmal: Exposure now 9995, analog gain 256/256, digital gain 256/256 mmal: AWB R=0/256, B=0/256 mmal: Exposure now 33350, analog gain 304/256, digital gain 256/256 mmal: AWB R=0/256, B=0/256 mmal: Exposure now 58330, analog gain 304/256, digital gain 256/256 mmal: AWB R=0/256, B=0/256 mmal: Exposure now 64575, analog gain 304/256, digital gain 256/256 mmal: AWB R=0/256, B=0/256 mmal: Exposure now 66131, analog gain 304/256, digital gain 256/256 mmal: AWB R=0/256, B=0/256 mmal: Exposure now 179, analog gain 272/256, digital gain 256/256 mmal: AWB R=0/256, B=0/256

Test Environment: Pi B+ uname -a Linux Pi-v1bplus 4.1.11+ #822 PREEMPT Fri Oct 23 16:14:56 BST 2015 armv6l GNU/Linux /opt/vc/bin/vcgencmd version Oct 23 2015 16:28:38 Copyright (c) 2012 Broadcom version c1a8b643677011791abeea1f5dc3a4738349ea55 (clean) (release)

Problem also verified as happening on Pi Compute Module: uname -a Linux Pi-computeB 4.1.7+ #817 PREEMPT Sat Sep 19 15:25:36 BST 2015 armv6l GNU/Linux /opt/vc/bin/vcgencmd version Sep 23 2015 12:21:14 Copyright (c) 2012 Broadcom version c156d00b148c30a3ba28ec376c9c01e95a77d6d5 (clean) (release)

Pure conjecture on what is going on: I wonder if there is some kind of wrap-around after an upper limit on exposure time is set, perhaps in some parameter-sense-checking code, which resets the shutter speed to something very low. Presumably such code should in fact test for limits in a sensible direction, e.g. if requested exposure is over 66,000 (if that is the upper limit) then set to 66,000. If requested exposure is less than 100 (if that is the lower limit) then set to 100. I have read on various forums that the shutter can be held open up to several seconds, but I assume the auto algorithm has some limit due to video speeds or similar. It is because of this assumed limitation on the auto shutter speed that I was using the ev and ISO parameters so as to be able to estimate what much longer shutter speed I might need for such extended exposures. For example, playing with ev -24 and ISO 800, which together with a maximum assumed shutter speed for the algorithm of 66msec should get me to estimates of shutter speed up to 66msec_2^(24/6)_800/100 = shutter speeds of 8.5sec for ev=0 ISO=100.

[shusheer]

Possibly related: When "nearly failing" with very low light and forced shutter values, the AWB R/B values go from "sensible" (~256) to 0. May be completely unrelated, but worth reporting at the same time. For example, here is the -set output from: raspistill -ss 300000 -ev -24 -ISO 100 -awb off -awbg 1.0,1.0 -drc high -n -q 99 -t 1000 -o test.jpg Notice the final line of output with AWB values changed, possibly again hitting some incorrect logic in setting a limit.

mmal: Exposure now 299986, analog gain 256/256, digital gain 256/256 mmal: AWB R=256/256, B=256/256 mmal: Exposure now 299986, analog gain 304/256, digital gain 256/256 mmal: AWB R=256/256, B=256/256 mmal: Exposure now 299986, analog gain 256/256, digital gain 256/256 mmal: AWB R=0/256, B=0/256

[6by9]

I'd need to check things out for myself, but a couple of points / confirmations.

• Yes, maximum shutter speed is 66ms if the auto exposure mode is "auto" or an ISO value has been set. "sport" mode has a shorter max shutter speed at 16ms. "night" mode in theory allows it to go up to the max the sensor can support, or is defined by the permitted frame rate range.
• There is a minimum shutter speed specified as 100us, however shutter speed is always in multiples of the sensor line readout time. It varies based on sensor mode, but is going to be 23.216us in your case.
• Setting EV just shifts the target luma value that the algorithm is aiming for. The raspistill command-line is horrid, but each step is 1/6 of a stop. (Allows to step in either 1/3 or 1/2 stop steps - different customers had different requirements). It's not really realistic to try and predict how it might react to alternative stimuli just by shifting the Y target.
• You can select the mode that supports frame rates between 1/6 and 1 fps, but you have to do that either with -md 3 or by specifying the shutter speed you want. You will also need to request "night" exposure mode and NOT specify a fixed ISO value. The normal sensor mode maxes out at about 800ms. The minimum exposure time will increase to about 140us, and will increase in steps of 140us.
• -t always needs to be 500ms or more. Both AGC and AWB need a number of frames to converge on sensible values. The AWB algorithm can be told to recompute based on the stats of the actual capture frame by adding the --stats flag, but this will slow down the actual capture (it has to feed the full 5MPix image through the hardware an extra time, just to produce those stats).
• Both algorithms can only work with the stats that they get. If you've pushed the scenario to stupid levels then they might make daft guesses, but that may not be avoidable.

I will try to replicate your results, but won't invest that much time in it - from the situation described I don't see it being that useful, and my time would be better spent adding full manual control of analogue and digital gains so that you can do a better job yourself.

[shusheer]

If there were the possibility of full manual control it would suit me (and by the looks of the forum several others) wonderfully. But I appreciate that's possibly a much bigger job than sense-checking limits in existing code.

Very interesting to see the effect of -t 100 vs -t 500 : the auto-exposure when I cover the camera with my hand just about becomes sensible at -t 500 (though lowers shutter speed and pumps up digital gain for some reason). I had been trying to minimise the timeout before taking a picture in order to take pictures in quick succession in a script, but hadn't noted a lower limit for the value before. If there is a lower limit, could that be mentioned in the help, and perhaps checked for when executed? This illegal use of timeout might in fact be the cause of this issue.

[6by9]

If you've specified shutter speed, ISO, and AWB gains, then there is nothing to adapt and you could run with a lower -t value, but if the control loops are active they need some frames to work with.

[Ruffio]

@shusheer has this issue been resolved and should be closed?

[JamesH65]

Closing due to lack of activity. Reopen if you feel this issue is still relevant.

[JamesH65]

Closing due to lack of activity. Please request to be reopened if you feel this issue is still relevant.