LiamEdgeley
Posts: 13
Joined: Thu Jul 17, 2014 5:26 am

Drifting White Balance During Timelapse

Thu Jul 17, 2014 5:47 am

I've been using silvanmelchior's RPi Cam Web Interface for a project involving multiple Pi's that simultaneously stream images to viewers over the web and record a time-lapse image every 15 seconds.

Unfortunately I'm experiencing some issues with the colour balance on my cameras changing over time. This picture shows the preview image from two of my Pi Cam's - The one on the right has been timelapsing since 3am, the other was rebooted shortly after 6am (approx 20 minutes before these images were taken).

Image

I was hoping this was just affecting the preview images, but it's also happening to the saved time-lapse pictures:
Image Image

These cameras both have their white balance set to auto, but I believe the same thing happens if I choose a fixed white balance e.g. Sun - I'll test that later today. Apart from that, any ideas what else I could investigate?

elatllat
Posts: 1337
Joined: Sat Dec 17, 2011 5:05 pm

Re: Drifting White Balance During Timelapse

Thu Jul 17, 2014 5:44 pm

I get the same thing, so until the bug is corrected to honer a forced white balance, we must correct white balance after.
SBC with 32GB RAM: https://hardkernel.com

FAQ : https://raspberrypi.stackexchange.com

Unanswered: https://www.raspberrypi.org/forums/search.php?search_id=unanswered

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 13546
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Drifting White Balance During Timelapse

Thu Jul 17, 2014 6:05 pm

The AWB modes just change the expected colour temperature of the scene, they do not fix the white balance. The only way to fix the white balance is by setting AWB mode to off, and then supplying your own gains (-awbg option in raspistill).

Could you post an image from when you start the Pi off, and one from several hours later please? The white balance gains are stored in the EXIF Makernote, so we can see whether the values have changed drastically, or is it something funny and you've managed to get the gains locked off and not changing over that period.
Software Engineer at Raspberry Pi Ltd. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

elatllat
Posts: 1337
Joined: Sat Dec 17, 2011 5:05 pm

Re: Drifting White Balance During Timelapse

Thu Jul 17, 2014 6:33 pm

should "-awb off" be this green?

Code: Select all

OUT=~/Downloads/picam/picam_$(date +%Y%m%dT%H%M%S).jpg;ssh pi@$IP /usr/bin/nice /opt/vc/bin/raspistill -o image.jpg --rotation 180 --quality 10 -awb off -h 240 -w 426; scp pi@$IP:~/image.jpg $OUT; exiftool $OUT;

image.jpg                                                                                                                100%   44KB  44.4KB/s   00:00    

ExifTool Version Number         : 9.42
File Name                       : picam_20140717T142829.jpg
Directory                       : ~/Downloads/picam
File Size                       : 44 kB
File Modification Date/Time     : 2014:07:17 14:29:08-04:00
File Access Date/Time           : 2014:07:17 14:29:08-04:00
File Inode Change Date/Time     : 2014:07:17 14:29:08-04:00
File Permissions                : rw-r--r--
File Type                       : JPEG
MIME Type                       : image/jpeg
Exif Byte Order                 : Big-endian (Motorola, MM)
Make                            : RaspberryPi
Camera Model Name               : RP_OV5647
X Resolution                    : 72
Y Resolution                    : 72
Resolution Unit                 : inches
Modify Date                     : 2014:07:17 14:29:06
Y Cb Cr Positioning             : Centered
Exposure Time                   : 1/5587
F Number                        : 2.9
Exposure Program                : Aperture-priority AE
ISO                             : 800
Exif Version                    : 0220
Date/Time Original              : 2014:07:17 14:29:06
Create Date                     : 2014:07:17 14:29:06
Components Configuration        : Y, Cb, Cr, -
Shutter Speed Value             : 1/5587
Aperture Value                  : 2.9
Brightness Value                : 0.9
Max Aperture Value              : 2.9
Metering Mode                   : Center-weighted average
Flash                           : No Flash
Focal Length                    : 3.6 mm
Maker Note Unknown Text         : (Binary data 304 bytes, use -b option to extract)
Flashpix Version                : 0100
Color Space                     : sRGB
Exif Image Width                : 426
Exif Image Height               : 240
Interoperability Index          : R98 - DCF basic file (sRGB)
Exposure Mode                   : Auto
White Balance                   : Auto
Compression                     : JPEG (old-style)
Thumbnail Offset                : 1022
Thumbnail Length                : 24576
Image Width                     : 426
Image Height                    : 240
Encoding Process                : Baseline DCT, Huffman coding
Bits Per Sample                 : 8
Color Components                : 3
Y Cb Cr Sub Sampling            : YCbCr4:2:0 (2 2)
Aperture                        : 2.9
Image Size                      : 426x240
Shutter Speed                   : 1/5587
Thumbnail Image                 : (Binary data 24576 bytes, use -b option to extract)
Focal Length                    : 3.6 mm
Light Value                     : 12.5
no version number listed:

Code: Select all

/opt/vc/bin/raspistill --help
Runs camera for specific time, and take JPG capture at end if requested

usage: raspistill [options]

Image parameter commands

-?, --help	: This help information
-w, --width	: Set image width <size>
-h, --height	: Set image height <size>
-q, --quality	: Set jpeg quality <0 to 100>
-r, --raw	: Add raw bayer data to jpeg metadata
-o, --output	: Output filename <filename> (to write to stdout, use '-o -'). If not specified, no file is saved
-l, --latest	: Link latest complete image to filename <filename>
-v, --verbose	: Output verbose information during run
-t, --timeout	: Time (in ms) before takes picture and shuts down (if not specified, set to 5s)
-th, --thumb	: Set thumbnail parameters (x:y:quality) or none
-d, --demo	: Run a demo mode (cycle through range of camera options, no capture)
-e, --encoding	: Encoding to use for output file (jpg, bmp, gif, png)
-x, --exif	: EXIF tag to apply to captures (format as 'key=value') or none
-tl, --timelapse	: Timelapse mode. Takes a picture every <t>ms
-fp, --fullpreview	: Run the preview using the still capture resolution (may reduce preview fps)
-k, --keypress	: Wait between captures for a ENTER, X then ENTER to exit
-s, --signal	: Wait between captures for a SIGUSR1 from another process
-g, --gl	: Draw preview to texture instead of using video render component
-gc, --glcapture	: Capture the GL frame-buffer instead of the camera image

Preview parameter commands

-p, --preview	: Preview window settings <'x,y,w,h'>
-f, --fullscreen	: Fullscreen preview mode
-op, --opacity	: Preview window opacity (0-255)
-n, --nopreview	: Do not display a preview window

Image parameter commands

-sh, --sharpness	: Set image sharpness (-100 to 100)
-co, --contrast	: Set image contrast (-100 to 100)
-br, --brightness	: Set image brightness (0 to 100)
-sa, --saturation	: Set image saturation (-100 to 100)
-ISO, --ISO	: Set capture ISO
-vs, --vstab	: Turn on video stabilisation
-ev, --ev	: Set EV compensation
-ex, --exposure	: Set exposure mode (see Notes)
-awb, --awb	: Set AWB mode (see Notes)
-ifx, --imxfx	: Set image effect (see Notes)
-cfx, --colfx	: Set colour effect (U:V)
-mm, --metering	: Set metering mode (see Notes)
-rot, --rotation	: Set image rotation (0-359)
-hf, --hflip	: Set horizontal flip
-vf, --vflip	: Set vertical flip
-roi, --roi	: Set region of interest (x,y,w,d as normalised coordinates [0.0-1.0])
-ss, --shutter	: Set shutter speed in microseconds
-awbg, --awbgains	: Set AWB gains - AWB mode must be off


Notes

Exposure mode options :
auto,night,nightpreview,backlight,spotlight,sports,snow,beach,verylong,fixedfps,antishake,fireworks

AWB mode options :
off,auto,sun,cloud,shade,tungsten,fluorescent,incandescent,flash,horizon

Image Effect mode options :
none,negative,solarise,sketch,denoise,emboss,oilpaint,hatch,gpen,pastel,watercolour,film,blur,saturation,colourswap,washedout,posterise,colourpoint,colourbalance,cartoon

Metering Mode options :
average,spot,backlit,matrix

Preview parameter commands

-gs, --glscene	: GL scene square,teapot,mirror,yuv,sobel
-gw, --glwin	: GL window settings <'x,y,w,h'>
The "-awb off" is listed as valid but it's still listed as "Auto" in the exif data when used.
Attachments
picam_20140717T142829.jpg
picam_20140717T142829.jpg (44.39 KiB) Viewed 14916 times
SBC with 32GB RAM: https://hardkernel.com

FAQ : https://raspberrypi.stackexchange.com

Unanswered: https://www.raspberrypi.org/forums/search.php?search_id=unanswered

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 31838
Joined: Sat Jul 30, 2011 7:41 pm

Re: Drifting White Balance During Timelapse

Thu Jul 17, 2014 7:46 pm

Have you set the WB gain value - if not then I guess it has selected some defaults, probably zero's.
Principal Software Engineer at Raspberry Pi Ltd.
Working in the Applications Team.

LiamEdgeley
Posts: 13
Joined: Thu Jul 17, 2014 5:26 am

Re: Drifting White Balance During Timelapse

Thu Jul 17, 2014 7:51 pm

Ok, here are four images from the "Studio" PiCam, taken at 3am (first image after the camera was restarted), 4am, 5am and 6am.

Image
Image
Image
Image

Admittedly this time period contains sunrise so you'd expect some change in WB along the way. The issue is that the WB of a camera that's been lapsing away since 3am is vastly different from one that's just been turned on.

elatllat
Posts: 1337
Joined: Sat Dec 17, 2011 5:05 pm

Re: Drifting White Balance During Timelapse

Thu Jul 17, 2014 8:01 pm

jamesh wrote:Have you set the WB gain value - if not then I guess it has selected some defaults, probably zero's.
As shown "awbg" was not used in the example as I was asking about the defaults.
in the interest of sane defaults should it not default to
"-awbg 1.0,1.0"
or maybe
"-awbg 1.5,1.2"
as that seems a little better
instead of
"-awbg 0.0,0.0"
?

Summary:
1) Please correct white balance drift.
2) Please use a sane default for -awbg.
3) Please set the exif white balance value properly.
SBC with 32GB RAM: https://hardkernel.com

FAQ : https://raspberrypi.stackexchange.com

Unanswered: https://www.raspberrypi.org/forums/search.php?search_id=unanswered

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 13546
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Drifting White Balance During Timelapse

Thu Jul 17, 2014 8:15 pm

From those images, in the Makernote I find the magic text:
  • ev=-1 mlux=-1 exp=999777 ag=2048 focus=255 gain_r=1.187 gain_b=1.503 greenness=-9 ccm=6146,-1764,-280,-396,4676,-180,908,-1924,5120,0,0,0
  • ev=-1 mlux=-1 exp=999777 ag=2048 focus=255 gain_r=1.187 gain_b=1.503 greenness=-9 ccm=6146,-1764,-280,-396,4676,-180,908,-1924,5120,0,0,0
  • ev=-1 mlux=-1 exp=24323 ag=384 focus=255 gain_r=1.187 gain_b=1.503 greenness=-9 ccm=8624,-3790,-732,-1552,6226,-576,476,-4038,7668,0,0,0
  • ev=-1 mlux=-1 exp=3172 ag=256 focus=255 gain_r=1.187 gain_b=1.503 greenness=-9 ccm=8624,-3790,-732,-1552,6226,-576,476,-4038,7668,0,0,0
So AGC is doing the right thing, but something appears to have locked the AWB gains. It's not one of the supported apps, so I have no idea what would be doing that or why. The only parameter that should be able to do that is MMAL_PARAMETER_AWB_MODE, so you should be able to check for that being set, or add a call to mmal_port_parameter_get_uint32(<camera->control>, MMAL_PARAMETER_AWB_MODE); at regular intervals and see what mode has been set. If it comes back as 0 (MMAL_PARAM_AWBMODE_OFF), then it is your app at fault.

(The system does automatically lock AWB and AGC at a couple of points around captures, but it should always automatically unlock them again afterwards. If the AWB mode comes back as not MMAL_PARAM_AWBMODE_OFF, then I may need to dig about to check that out, but to do so I need a reproducible test case, and at the moment I can't get RPi Cam Web Interface to run)
Software Engineer at Raspberry Pi Ltd. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

LiamEdgeley
Posts: 13
Joined: Thu Jul 17, 2014 5:26 am

Re: Drifting White Balance During Timelapse

Thu Jul 17, 2014 8:21 pm

elatllat wrote: Summary:
1) Please correct white balance drift.
2) Please use a sane default for -awbg.
3) Please set the exif white balance value properly.
1) I'm not sure if the WB drift occurs in raspistill - I haven't had time to test that yet - The error may well be with raspimjpeg, in which case it's a bit much to ask james of 6by9 to fix someone else's code!

2) Zero seems like a sane default to me - if it was left at something that looks "OK" most of the time, you'd find users who don't really know what they're doing setting AWB off and then complaining about how their images don't look quite right. The zero default forces the user to actually know what they're doing before messing around with gain values. (As an aside, raspimjpeg doesn't currently have a parameter in the config files for AWB gain values. I think my C programming is probably too rusty for me to make a patch to add it in, sadly.)

3) I agree that having correct info in the EXIF will help debugging, but a bald "please do X" is a little demanding of people who are working on this in their spare time. How about: "When you guys are working on the next version of raspistill, is there any chance you could have a look at fixing the way AWB off gets recorded in the EXIF data, please? It'd make debugging a heck of a lot easier. Cheers!" instead?

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 13546
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Drifting White Balance During Timelapse

Thu Jul 17, 2014 8:42 pm

1) Liam is right - if you can't reproduce it in one of the supported apps (raspistill, raspivid, or raspiyuv), then you really ought to be talking to the app developer. As it happens I am trying to get RPi cam web interface running to look at another issue so I may have a look at the code briefly, but it's not the issue I'm interested in.

2) Manually setting white balance gains is totally dependent on the scene and illumination. There are no sane defaults, same as for shutter speed and sensor gain. If you use awb off, then you MUST do the work yourself to determine sensible values for yourself.

3) You do realise that the EXIF WhiteBalance tag does only denote auto or manual. It does not indicate which white balance mode is selected. (http://awaresystems.be/imaging/tiff/tif ... lance.html for reference).
To be honest that would be one of the lowest priority tasks I can think of. If you're doing manual stuff with awb off then you need to know what you're doing - end of discussion.
Software Engineer at Raspberry Pi Ltd. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

elatllat
Posts: 1337
Joined: Sat Dec 17, 2011 5:05 pm

Re: Drifting White Balance During Timelapse

Fri Jul 18, 2014 4:13 am

It seems that the white balance drift is related to how long the camera has been on (can be set with "-t").
If awb is not set to off Images will shift from green to red as the t lengthens.
If awb is set to off white balance remains stable across t values.

Code: Select all

for T in 5 20 80 ; do 
raspistill -o off_"$T".jpg --rotation 180 --quality 10 -awb off -awbg 1.5,1.2 --exposure night --brightness 75 -h 500 -w 100  -t "$T"000;
raspistill -o on_"$T".jpg --rotation 180 --quality 10 --exposure night --awb shade --brightness 75 -h 500 -w 100 -t "$T"000;
done
Attachments
on_80.jpg
on_80.jpg (29.99 KiB) Viewed 14782 times
on_20.jpg
on_20.jpg (28.98 KiB) Viewed 14782 times
on_5.jpg
on_5.jpg (28 KiB) Viewed 14782 times
SBC with 32GB RAM: https://hardkernel.com

FAQ : https://raspberrypi.stackexchange.com

Unanswered: https://www.raspberrypi.org/forums/search.php?search_id=unanswered

LiamEdgeley
Posts: 13
Joined: Thu Jul 17, 2014 5:26 am

Re: Drifting White Balance During Timelapse

Fri Jul 18, 2014 6:02 am

That's interesting - I don't see significant shifts in WB until a couple of hours have elapsed when I set a timelapse running through RPi Cam Web Interface. I'm away with work this weekend, but on Sunday evening I will try a raspistill timelapse and a RPi Cam Web Interface timelapse side by side and see if I can duplicate this.

On a related note, I'm trying a quick and dirty hack out today - I've put a line in my crontab (to run every minute) to echo "wb auto" into raspimjpeg's command FIFO buffer. I'm hoping that will force it to re-evaluate it's White Balance every minute, which will stop the drift. A sticking plaster I know, but if it works, it'll do as a temporary bodge.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 13546
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Drifting White Balance During Timelapse

Fri Jul 18, 2014 8:46 pm

Er, automatic white balance would be a control loop that has to settle on a value somehow determined to be optimal. There is an accelerated phase with the first few frames, but it will adapt. I wouldn't have expected it to take that long, but I also wouldn't have expected you to select "shade" mode, or turn the brightness down for no obvious reason. What was wrong with awb mode "auto" or leaving the brightness alone for a simpler test?

Which release are you running? If it's not a recent firmware then you're not going to get much assistance. I realise that compromises things a little as RPi Cam Web Interface has issues with recent firmware releases, but that is being investigated. It's not one of the apps directly supported by the Foundation or Broadcom, so there's only so much effort we can spend on it.
Software Engineer at Raspberry Pi Ltd. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 31838
Joined: Sat Jul 30, 2011 7:41 pm

Re: Drifting White Balance During Timelapse

Fri Jul 18, 2014 8:54 pm

Hi 6x9, an unrelated question that are bound to see as opposed to other methods!

You didn't pick up my sunblock at the BBQ did you? Or did anyone else? I left it on the table! And it was the one thing I was ordered not to forget!
Principal Software Engineer at Raspberry Pi Ltd.
Working in the Applications Team.

elatllat
Posts: 1337
Joined: Sat Dec 17, 2011 5:05 pm

Re: Drifting White Balance During Timelapse

Fri Jul 18, 2014 11:15 pm

6by9 wrote:...Which release are you running?...
The white balance issue is present in the latest "production" version of what was once labeled the "official" raspberrypi OS.

Code: Select all

md5sum /opt/vc/bin/raspistill
43406ddd880c90408fd16dd27c05d5c5  /opt/vc/bin/raspistill

cat /etc/issue
Raspbian GNU/Linux 7 \n \l

uname -srvo
Linux 3.12.22+ #691 PREEMPT Wed Jun 18 18:29:58 BST 2014 GNU/Linux
related:
https://github.com/raspberrypi/userland/issues/118
SBC with 32GB RAM: https://hardkernel.com

FAQ : https://raspberrypi.stackexchange.com

Unanswered: https://www.raspberrypi.org/forums/search.php?search_id=unanswered

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 13546
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Drifting White Balance During Timelapse

Sat Jul 19, 2014 7:58 am

Er, totally unrelated. Why would AWB changing on captures due to using sun/tungsten mode when the user was apparently wanting a totally fixed AWB setup be related to AWB converging slowly?

We appear to have two issues being half described here:
  • AWB gains not changing in RPi Cam Web - unknown firmware revision.
  • AWB apparently converging slowly over the first 10 seconds when on shade mode - latest firmware
Please be clear in your posts which you are commenting on - I'm not a mind reader, and I only have limited time looking at Pi related issues.
Software Engineer at Raspberry Pi Ltd. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

LiamEdgeley
Posts: 13
Joined: Thu Jul 17, 2014 5:26 am

Re: Drifting White Balance During Timelapse

Mon Jul 21, 2014 12:43 pm

6by9 wrote: We appear to have two issues being half described here:
  • AWB gains not changing in RPi Cam Web - unknown firmware revision.
  • AWB apparently converging slowly over the first 10 seconds when on shade mode - latest firmware
Please be clear in your posts which you are commenting on - I'm not a mind reader, and I only have limited time looking at Pi related issues.
I can help add some more description to the first issue on the list.

The issue with AWB gains not changing in RPi Cam Web Interface happens with firmware 8660fe5152f6353dec61422808835dbcb49fc8b2 - I am unable to test this with a more recent firmware as RPi Cam Web Interface doesn't work with any more-recent firmware.

Interestingly the quick-and-dirty hack I put together on Friday (to continually sent "wb auto" into RPi Cam Web's command FIFO) didn't work - AWB gains appear to remain fixed (I say "appear" as I don't know how to extract the actual AWB gains from the EXIF data). To my mind this suggests that there's something pretty broken with RPi Cam Web. I have another horrible bodge-fix in mind; The AWB gains are definitely recalculated when the camera is stopped and restarted within the RPi Cam Web interface, so I could try making a cron job to repeatedly do that. Yeurgh!

I left two timelapses running side-by-side this morning before leaving for work, one using raspistill and the other using RPi Cam Web Interface. I'll post back this evening with something definitive as to whether this issue is specific to RPi Cam Web or affects raspistill too.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 13546
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Drifting White Balance During Timelapse

Mon Jul 21, 2014 3:41 pm

1) Yes, we have a firmware bug. The GPU had locked AWB for the capture, and was then failing to unlock it again.
I'll sort out a patch and get it released in the next cycle.

2) Odd ball showing up on the adding of EXIF data at VGA. Something to look into, but not a major issue. It works fine at 5MPix.
Making it a less obscure test with:

Code: Select all

for T in 5 20 80 ; do
raspistill -o off_"$T".jpg  -awb off -awbg 1.5,1.2 -h 1944 -w 2592  -t "$T"000;
raspistill -o on_"$T".jpg  --awb auto -h 1944 -w 2592 -t "$T"000;
done
Dumping the Makernote debug string out with

Code: Select all

strings -f *.jpg | grep 'gain'
and I get
off_5.jpg: ev=-1 mlux=-1 exp=91483 ag=640 focus=255 gain_r=1.500 gain_b=1.199 greenness=9 ccm=7768,-3174,-486,-1078,5472,-294,272,-2638,6468,0,0,0 md=0 tg=261 261 oth=0 0 b=0 f=261 261 fi=0 ISP Build Date: Jul 17 2014, 17:39:16 VC_BUILD_ID_VERSION: 6c3160824ec59074ffb980b76a0593c0370dfbf1 (tainted) VC_BUILD_ID_USER: xxx VC_BUILD_ID_BRANCH: dev
off_20.jpg: ev=-1 mlux=-1 exp=32978 ag=368 focus=255 gain_r=1.500 gain_b=1.199 greenness=9 ccm=7768,-3174,-486,-1078,5472,-294,272,-2638,6468,0,0,0 md=0 tg=265 265 oth=0 0 b=0 f=265 265 fi=0 ISP Build Date: Jul 17 2014, 17:39:16 VC_BUILD_ID_VERSION: 6c3160824ec59074ffb980b76a0593c0370dfbf1 (tainted) VC_BUILD_ID_USER: xxx VC_BUILD_ID_BRANCH: dev
off_80.jpg: ev=-1 mlux=-1 exp=31221 ag=256 focus=255 gain_r=1.500 gain_b=1.199 greenness=9 ccm=7768,-3174,-486,-1078,5472,-294,272,-2638,6468,0,0,0 md=0 tg=257 257 oth=0 0 b=0 f=257 257 fi=0 ISP Build Date: Jul 17 2014, 17:39:16 VC_BUILD_ID_VERSION: 6c3160824ec59074ffb980b76a0593c0370dfbf1 (tainted) VC_BUILD_ID_USER: xxx VC_BUILD_ID_BRANCH: dev
on_5.jpg: ev=-1 mlux=-1 exp=32978 ag=352 focus=255 gain_r=1.425 gain_b=1.648 greenness=56 ccm=8332,-3578,-652,-1390,5972,-482,410,-3564,7260,0,0,0 md=0 tg=259 259 oth=0 0 b=0 f=259 259 fi=0 ISP Build Date: Jul 17 2014, 17:39:16 VC_BUILD_ID_VERSION: 6c3160824ec59074ffb980b76a0593c0370dfbf1 (tainted) VC_BUILD_ID_USER: xxx VC_BUILD_ID_BRANCH: dev
on_20.jpg: ev=-1 mlux=-1 exp=32978 ag=352 focus=255 gain_r=1.457 gain_b=1.605 greenness=57 ccm=8254,-3522,-630,-1348,5904,-456,392,-3440,7152,0,0,0 md=0 tg=260 260 oth=0 0 b=0 f=260 260 fi=0 ISP Build Date: Jul 17 2014, 17:39:16 VC_BUILD_ID_VERSION: 6c3160824ec59074ffb980b76a0593c0370dfbf1 (tainted) VC_BUILD_ID_USER: xxx VC_BUILD_ID_BRANCH: dev
on_80.jpg: ev=-1 mlux=-1 exp=31221 ag=256 focus=255 gain_r=1.425 gain_b=1.648 greenness=56 ccm=8332,-3578,-652,-1390,5972,-482,410,-3564,7260,0,0,0 md=0 tg=255 255 oth=0 0 b=0 f=255 255 fi=0 ISP Build Date: Jul 17 2014, 17:39:16 VC_BUILD_ID_VERSION: 6c3160824ec59074ffb980b76a0593c0370dfbf1 (tainted) VC_BUILD_ID_USER: xxx VC_BUILD_ID_BRANCH: dev
So all 3 images with AWB off have gain_r 1.500, gain_b 1.199, almost exactly as you asked for.
The 3 images with AWB on have have very similar gains at about gain_r 1.45, gain_b 1.64.

If I do switch back to AWB mode shade, then I get:
on_5.jpg: ev=-1 mlux=-1 exp=58456 ag=384 focus=255 gain_r=1.824 gain_b=1.003
on_20.jpg: ev=-1 mlux=-1 exp=60929 ag=384 focus=255 gain_r=1.812 gain_b=1.082
on_80.jpg: ev=-1 mlux=-1 exp=54584 ag=384 focus=255 gain_r=1.796 gain_b=1.105
Again I would say those were the same within the realm of experimental error and control loops. No real issue to investigate.
Software Engineer at Raspberry Pi Ltd. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

LiamEdgeley
Posts: 13
Joined: Thu Jul 17, 2014 5:26 am

Re: Drifting White Balance During Timelapse

Mon Jul 21, 2014 4:10 pm

6by9 wrote:1) Yes, we have a firmware bug. The GPU had locked AWB for the capture, and was then failing to unlock it again.
I'll sort out a patch and get it released in the next cycle.
Huge thanks for working on this, 6by9. Here's hoping we (Ha! as if I'm helping!) can get to the bottom of the issues running RPi Web Cam Interface on recent firmware - I don't think I could bear the irony of being unable to upgrade to the firmware that fixes my WB issues because RPi Web Cam Interface refuses to run on it!

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 31838
Joined: Sat Jul 30, 2011 7:41 pm

Re: Drifting White Balance During Timelapse

Mon Jul 21, 2014 4:29 pm

LiamEdgeley wrote:
6by9 wrote:1) Yes, we have a firmware bug. The GPU had locked AWB for the capture, and was then failing to unlock it again.
I'll sort out a patch and get it released in the next cycle.
Huge thanks for working on this, 6by9. Here's hoping we (Ha! as if I'm helping!) can get to the bottom of the issues running RPi Web Cam Interface on recent firmware - I don't think I could bear the irony of being unable to upgrade to the firmware that fixes my WB issues because RPi Web Cam Interface refuses to run on it!
You need to talk to the RPi Web Cam people - they cannot afford to lag too far behind the firmware...
Principal Software Engineer at Raspberry Pi Ltd.
Working in the Applications Team.

LiamEdgeley
Posts: 13
Joined: Thu Jul 17, 2014 5:26 am

Re: Drifting White Balance During Timelapse

Mon Jul 21, 2014 4:37 pm

jamesh wrote:You need to talk to the RPi Web Cam people - they cannot afford to lag too far behind the firmware...
Oh absolutely - I wasn't in any way trying to imply that RPi Web Cam Interface's incompatibility problems are your responsibility. I'm just grateful for the work that you guys have been doing on the firmware.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 13546
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Drifting White Balance During Timelapse

Mon Jul 21, 2014 5:10 pm

I've just been running RPi Cam Web Interface on the latest firmware whilst trying to track the issues down the alleged lockup as part of http://www.raspberrypi.org/forums/viewt ... 43&t=80463. I can't get it to fail. :D

I'd say it was worth a punt to see what happens with the latest code based on a clean Raspbian install and then rpi-update. If it fails, then please throw the config in my direction so I can look into it.
Software Engineer at Raspberry Pi Ltd. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

LiamEdgeley
Posts: 13
Joined: Thu Jul 17, 2014 5:26 am

Re: Drifting White Balance During Timelapse

Mon Jul 21, 2014 5:55 pm

6by9 wrote:I'd say it was worth a punt to see what happens with the latest code based on a clean Raspbian install and then rpi-update. If it fails, then please throw the config in my direction so I can look into it.
By "latest code", do you mean the last release from silvanmelchior's branch or BoehserWolf's fork? Either way I'll dig out a spare SD card and give it a whirl.

Edit: Just had a go:
  • Downloaded latest Rasbian image
  • Ran an apt-get update then apt-get upgrade then rpi-update
  • Finally git cloned from silvanmelchior's branch of RPi Cam Web Interface.
  • Rebooted, with trepidation...
  • ...and it works!
It's been time lapsing away for the last 30 minutes. I have no idea why it's suddenly working on latest firmware again, but I'm very pleased :)

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 13546
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Drifting White Balance During Timelapse

Mon Jul 21, 2014 7:56 pm

LiamEdgeley wrote:By "latest code", do you mean the last release from silvanmelchior's branch or BoehserWolf's fork? Either way I'll dig out a spare SD card and give it a whirl.
Silvanmelchior's github. I was just following the instructions on http://www.raspberrypi.org/forums/viewt ... 63#p570085 and it all just seemed to work.

BoehserWolf's repo should just be an updating to pick up the features of the later userland tree. I was using this when building my own binary, but my testing today was with Silvanmelchior's version.

edit: Sorry, thinking about it I wasn't following those instructions. I just did a git clone, and then as root ./RPi_Cam_Web_Interface_Installer.sh install, before rebooting. It was my other SD card I was following the instructions on, but that didn't want to install Apache.
Software Engineer at Raspberry Pi Ltd. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

LiamEdgeley
Posts: 13
Joined: Thu Jul 17, 2014 5:26 am

Re: Drifting White Balance During Timelapse

Mon Jul 21, 2014 9:40 pm

Well, I have now tried rpi-updating to latest firmware on all four of my RPi Web Cams, and so far they are all happily lapsing away!
Image

I've also managed to get my bodge fix for the white balance issue working, which should tide me over until 6by9's firmware fix makes it into the wild. The bodge is actually a modification of my first idea (repeatedly commanding raspimjpeg to change wb) - it turns out the camera is quite sensible and only changes wb if the new wb setting is different to the one currently in use. So I have made a simple script called "togglewb.sh" that is called regularly by a cron job:

Code: Select all

STATUS=`cat /var/www/status_mjpeg.txt`
#check that the camera is timelasping - if it isn't, changing the white balance will kill raspimjpeg!
if [ $STATUS = 'timelapse' ]; then
        echo -n "wb sun" > /var/www/FIFO
        # a brief sleep as issuing commands too quickly also kills raspimjpeg!
        sleep 1s
        echo -n "wb auto" > /var/www/FIFO
fi
So far <touches wood> this seems to be working - timelapses are staying up, and wb gain values are changing over time. There are minor differences between the four cameras, but I think that's due to variations from board to board, and the slightly different angles of each pi meaning they see different reflections from my double glazing! I'm going to leave these four running overnight and see if any issues rear their head, but otherwise it looks like this one is licked. Thanks for all your help!

Return to “Camera board”