Exposure control goes into oscillation during video recordin

[szhorvat]

I'm trying to use the Pi camera (NoIR version) to record a video in relatively low light. Under these conditions, sometimes the automatic exposure control goes into oscillations: the video gets overly bright, then very dark, then bright, then dark again, etc. The effect is extreme and makes the video unusable.

Why does this happen and how can I prevent this?

More details:

When recording a still image, everything seems to work fine. I use the option --exposure verylong, set exposure compensation using the -ev option to correct for over/under exposure, and make sure that the timeout (-t) is long enough to allow for a long shutter speed. Then I get good and consistent results.

Now I'm trying to record video under the same conditions. To allow for a long enough shutter speed, I set the framerate to -fps 2 (the documented minimum). I leave the other settings at default, except for --exposure. If I don't use the --exposure option, the picture will be too dark, essentially black, as the light level drops. If I set it to --exposure verylong, then exposure control will often go into oscillations: it brightens up, overshoots, overexposes, then darkens too much, then keeps repeating this. If I set it to --exposure night, then I get good results in some lighting conditions, but as the light level drops, it starts oscillating again.

My scene is dim but relatively evenly lit (i.e. relatively low contrast). It's not the typical very high contrast night scene with visible light sources in the frame.

Update: Are exposure decisions (and metering) done by a software component? Is it at all possible to modify this piece of software, and if yes, how much effort would it take (I guess it's very low level code)?

[szhorvat]

Has anyone else encountered similar problems, i.e. oscillations in the exposure that do not die off? It looks like the auto-exposure control is not well tuned ...

[Noggin01]

I have had similar issues, but the oscillation does tend to die off usually. I've been watching your thread to see if anyone gives a solutions. I'm running the software available from the package in this thread: http://www.raspberrypi.org/forums/viewt ... 43&t=63276

Edit: One thing I have done that has helped significantly is reduced the backlighting of my scene. I'm watching my living room from work and there is a large window on the other side of the room. From around noon to 5 o'clock, there is a LOT of sunlight coming in through that window. I've drawn the curtains closed and it has helped. However, I still often have a normally-lit scene which suddenly goes dark and triggers and motion capture and will occasionally oscillate.

[jamesh]

Lots of back lighting is always going to be a pain. And as mentioned above, the tuning hasn't had a huge amount of time spent on it (you can spend man years!). Enough to get a decent image, plus a little bit more, but dealing with this sort of edge case stuff is very time consuming, and there isn't much time!

[szhorvat]

Lots of back lighting is always going to be a pain. And as mentioned above, the tuning hasn't had a huge amount of time spent on it (you can spend man years!). Enough to get a decent image, plus a little bit more, but dealing with this sort of edge case stuff is very time consuming, and there isn't much time!

Jamesh, in my case there is no backlighting. As I said, the scene is not high contrast, and lit from the front. The only thing that's special in my case is the very low framerate.

One of the nice things about the RPi is that it's open and hackable.

Can I change how exposure control works? Do users have access to this? Is it done in software by an open source component, or is it in inaccessible hardware (or closed source code)? I would be willing to try to fix it, even if it is not easy, provided that there is at least some documentation/examples to get started.

[jamesh]

Lots of back lighting is always going to be a pain. And as mentioned above, the tuning hasn't had a huge amount of time spent on it (you can spend man years!). Enough to get a decent image, plus a little bit more, but dealing with this sort of edge case stuff is very time consuming, and there isn't much time!

Jamesh, in my case there is no backlighting. As I said, the scene is not high contrast, and lit from the front. The only thing that's special in my case is the very low framerate.

One of the nice things about the RPi is that it's open and hackable.

Can I change how exposure control works? Do users have access to this? Is it done in software by an open source component, or is it in inaccessible hardware (or closed source code)? I would be willing to try to fix it, even if it is not easy, provided that there is at least some documentation/examples to get started.

The code is closed source I am afraid. And horribly complicated (tuning files are about 70k lines long). Low framerate is interesting. How low? Do you get the same at normal framerates? I'll ask around to see if that might cause oscillations.

Have you tried different exposure modes or fixed gains?

[szhorvat]

The code is closed source I am afraid. And horribly complicated (tuning files are about 70k lines long). Low framerate is interesting. How low? Do you get the same at normal framerates? I'll ask around to see if that might cause oscillations.

Have you tried different exposure modes or fixed gains?

Very low framerates, down to 2-3 fps (since 2 is the minimum). The reason why I wanted to use low framerates is that this is at nighttime, with relatively low (but not vey low) illumination, and I wanted to allow for longer shutter speeds.

I used an incandescent bulb (nightlamp) to illuminate the scene. (Since this is a NoIR camera, the light from this type of lamp does look brighter to the camera than to my eyes.) Strangely, using a fainter light source makes the oscillations go away (but also makes the picture much too dark).

I tried both --exposure night and --exposure verylong. The latter is very prone to oscillations (so I gave up on it quickly), the former less so (but it still oscillates in this case). With the other exposure modes I tried the images look too dark.

I didn't want to fix the shutter speed and ISO manually because when morning comes the camera should be able to adapt to the new lighting condition.

Tomorrow I can post some samples taken with different settings so you can judge the situation and maybe give some advice.

A workaround I'm trying now is using still capture with time lapse mode at 0.5-1 fps instead. There are two problems I still need to solve to make this usable. 1. Get real-time, hardware accelerated encoding for the images. I'm trying to use the rpi-encode-yuv tool from here in conjunction with raspiyuv. I couldn't yet match up the output of raspiyuv with the desired input of rpi-encode-yuv yet though, so it produces image shifts and generally garbage output. But I'm hopeful. 2. raspistill (not sure about raspiyuv) tends to skip frames in time lapse mode when the shutter speeds become very slow.

[6by9]

verylong hasn't been touched really so I'm not surprised it has issues.
night should generally behave itself.

Max exposure time for preview is now 770ms (still capture can go to 1s), so you could try asking for 1fps although I doubt it would help much.

[CraigV]

Back when the extended resolutions and frame rates were announced, I tried 1 fps HD video on my critter cam. In the low light hours just after dawn, it seemed to work fine, but as soon as sunlight beams reached the gulley, the exposure feedback loop appeared to become unstable. It did not become stable again until just before nightfall. It works fine all day at 2 fps, but regularly fails when I try 1 fps and the scene has some strong contrast.

I recently tried it again to see if it was fixed, but the same problem occurred. My solution has been to not use 1 fps, but it would be really nice to have it work. Needless to say, however, I am grateful for all the hard work that has made the Pi and its camera work as well as it does!

Added note: I tried adding -awb off -awbg 1.5,1.2 to my command line but the oscillation persisted at 1 fps.