Brightness problems with Motion/V4L2

[Aydan]

Hello Forum,

I'm using Raspian Wheezy's Motion with a Pi Camera Module and have problems with the image brightness when light conditions change a lot, e.g. dusk, dawn.
What settings should I use to get rid of that?
This is my motion.conf (strpped down):

Code: Select all

daemon on
setup_mode off
videodevice /dev/video0
v4l2_palette 8
input 8
norm 0
frequency 0
rotate 180
width 1280
height 1024
framerate 2
minimum_frame_time 0
netcam_tolerant_check off
auto_brightness off
brightness 0
contrast 0
saturation 0
hue 0
roundrobin_frames 1
roundrobin_skip 1
switchfilter off
threshold 1500
threshold_tune off
noise_level 32
noise_tune on
despeckle EedDl
smart_mask_speed 0
lightswitch 0
minimum_motion_frames 1
pre_capture 1
post_capture 1
gap 20
max_mpeg_time 0
output_all off
output_normal on
output_motion off
quality 75
ppm off
ffmpeg_cap_new on
ffmpeg_cap_motion off
ffmpeg_timelapse 0
ffmpeg_timelapse_mode daily
ffmpeg_bps 500000
ffmpeg_variable_bitrate 0
ffmpeg_video_codec swf
ffmpeg_deinterlace off
snapshot_interval 60
locate on
text_right %Y-%m-%d\n%T-%q
text_changes off
text_event %Y%m%d%H%M%S
text_double on
target_dir /home/motion/
snapshot_filename snapshots/%Y%m%d/%Y%m%d%H%M%S-snapshot
jpeg_filename events/%Y%m%d/%Y%m%d%H%M%S-%v-%q
movie_filename events/%Y%m%d/%Y%m%d%H%M%S-%v
timelapse_filename timelapse/%Y%m%d-timelapse
webcam_port 8081
webcam_quality 50
webcam_motion off
webcam_maxrate 1
webcam_localhost off
webcam_limit 0
control_port 8080
control_localhost off
control_html_output on
quiet on

Right now i simply restart motion every hour.
I'm sure this has been answered somewhere already, but I couldn't find anything definitive.

Regards
Aydan

[kiteloop]

Same problem here. Restarting does not help. Changing resolutions seems to get the image better, but still too dark/bright. Setting auto brightness to "on" doesn't improve the issue either

[Skeltek]

Problem for me with 'auto brightness' in motion is the brightness being adapted to the movement associated pixels. I am using the NoIR RaspiCam.

For example:
If a part of the screen suddently gets pretty dark, the softare will turn brightness massively up for the whole picture, so the 'movement area' gets the preset brightness average. If the same area gets normal again, the brightness of the whole picture is again massively adjusted, so the 'moving area' gets the preset brightness on average. This results in massive brightness changes overall and leads to the overall picture having various brightness levels at different points in time.
I tried adjusting framerate and shutter speed over the mmalcam_control_params to no improvement. I just cant get it to have a good brightness for the whole picture like for example raspistill does by autoadjusting after startup.

Pictures in the darkhave in general too many totally dark spots. It gets unnoticably better after restarting the raspi or camera, but the dark areas are still unrecognizable.
On the other hand, letting the camera run until dawn results in the whole picture to be completely white. Restarting the raspi or camera will turn everything from completely white to a very overexposed picture.

To sum it up: Restarting the cam in daylight or at night will get you a very underexposed or overexposed picture. Letting it run until night or dawn will make the picture completely white or black.

Turning motion off and testing with raspistill will give (after a quarter second of adjustment) a normal looking perfect picture brightness with neither overly bright nor dark areas.


The auto_brightness seems compleely useless, since it adapts the brightness only for the last area that was evaluated as movement.

Next thing I will test would be reactivating auto_brightness and turning the Noise threshold to ZERO and hope the picture as a whole will constantly be considered movement. Maybe this will result in the whole picture being adjusted to an average brightness.

Its too bad the documentation is so bad. It is not even apparent wether the brightness adjustment is being made on the cam, exposure/shutterspeed or by softwaresteered postadjustment. Usualy I know software which will either automatically do all the meaningfull settings and required autonomous steering for you OR it is documented well enough for the user to be able to do the extra stuff he needs manualy. But 'motion' kind of does half the job and lets the user poke around in the dark without sufficient information to fix the issues himself.
For me the amount of research and work required to fix the issue is about the same which I would need to write all the algorithmsand subroutines myself.

I did something like that on a 3D Simulation software, which resulted in me programming a whole 3D engine fromscratch. I am not willing to do that for a 'standardized' camera software, which should have the minimum autonomous functionality already intergrated by release.

kindly regards, Skeltek