New AWB algorithm in test firmware

[jamesh]

Hello all,

As part of our transition to the brave new 3D world of KMS, we are moving the AWB algorithm off the quad processors. These quads are used by the new 3D driver from ARM space, and allowing the camera AWB (firmware space) to use them as well is not very efficient for either party.

So, we now have a baysian statistical AWB algorithm that runs entirely on the VPU. This can be tested out by running `sudo rpi-update' which will update your firmware to the latest test version.

We would be grateful if people could try out this new AWB algorithm. There will be some differences, but it should match up fairly closely with the existing version. If you find a major difference we would be very interested in seeing comparison images, preferably in RAW format. (e.g. raspistill --raw option)

You can easily switch between AWB algorithms as follows:

Code: Select all

vcdbg set awb_mode [0|1]".  0 for old algorithm, 1 for our new algorithm. Defaults to our new one.

Thanks all.

Camera Team.

[jamesh]

Bring this to top again as its important and have had no comments so far!! Which I pressume is a good thing!

[bensimmo]

I've not use the camera much, but do have the v1 of both types
Unfortunately I can't send them back up in the rocket for a while,.so will have to be normal testing.

I'm assuming if I use picamera python module, it'll just work?

[jamesh]

I've not use the camera much, but do have the v1 of both types
Unfortunately I can't send them back up in the rocket for a while,.so will have to be normal testing.

I'm assuming if I use picamera python module, it'll just work?

Its all in the firmware, so yes, it should just work. Or at least, that's the plan!

[ddahms]

I gave it a try. I have a v1 camera. On a sunny midday scene, I see no difference between mode 0 and 1. On a dusk scene, mode 0 has an overall reddish tint like it always did while mode 1 is less reddish, which is an improvement.

There is one minor side effect: in mode 1, the version of Raspistill that I compiled to incorporate a custom lens shading table by following this post hangs. It creates the empty temp output file with the tilde suffix and hangs.

[nevilley]

Ran apt upgrade on 10 Pi zero W running motion over the weekend.
Those that use the Pi NOIR cam now have a purple haze. Those running under IR light are unusable.

I don't know why but running "vcdbg set awb_mode 0 " appears to kill the wifi !
For headless PIs this is a problem.

As these are security cams I have had to reload the SD cards from a backup to undo the upgrade.

[roelfraspi]

Upgraded firmware. There is a problem with AWB off and AWBG that only effects the thumbnails right. Pictures stay the same color and have only brightness changed..

[nevilley]

I don't use thumbnails.

This is the "purple haze" problem reported elsewhere.
I'm using the 8Mp NOIR pi cams with no filters with Pi zero W and the motion s/w package..

Examples of before and after the recent update can be seen here on a camera that is lit only with IR leds.
http://www.nevilley.org.uk/RPi/snap1.jpg
http://www.nevilley.org.uk/RPi/snap2.jpg

I have already reverted to a previous backup of the system to make it work again on 2 of the 3 affected systems.
The 3rd system uses daylight so despite having the purple haze it is still useable.

[jamesh]

I don't use thumbnails.

This is the "purple haze" problem reported elsewhere.
I'm using the 8Mp NOIR pi cams with no filters with Pi zero W and the motion s/w package..

Examples of before and after the recent update can be seen here on a camera that is lit only with IR leds.
http://www.nevilley.org.uk/RPi/snap1.jpg
http://www.nevilley.org.uk/RPi/snap2.jpg

I have already reverted to a previous backup of the system to make it work again on 2 of the 3 affected systems.
The 3rd system uses daylight so despite having the purple haze it is still useable.

This was fixed some time ago. You need to set -awb greyworld on the raspistill/vid command line.

See https://github.com/raspberrypi/firmware/issues/1167

There are also fixes for the awb off problem above, use rpi-update to get that as its not made it into the main release yet.

[jamesh]

Ran apt upgrade on 10 Pi zero W running motion over the weekend.
Those that use the Pi NOIR cam now have a purple haze. Those running under IR light are unusable.

I don't know why but running "vcdbg set awb_mode 0 " appears to kill the wifi !
For headless PIs this is a problem.

As these are security cams I have had to reload the SD cards from a backup to undo the upgrade.

Nothing to do with the purple side of things, but you should always check new software works on an offline/test system before updating live and important systems. That would be standard practice.

[nevilley]

Which is why I had backups.
I've been in IT since 1975 and "restore from your latest back-up" was my favourite support reply.

[nevilley]

This was fixed some time ago. You need to set -awb greyworld on the raspistill/vid command line.

But as I wrote.
I'm running motion, not raspistill.

running "vcdbg set awb_mode 0" kills the wifi. This is bad as the pi zeros are headless.

[jamesh]

This was fixed some time ago. You need to set -awb greyworld on the raspistill/vid command line.

But as I wrote.
I'm running motion, not raspistill.

running "vcdbg set awb_mode 0" kills the wifi. This is bad as the pi zeros are headless.

So how does motion access the camera? You'll need to tell that process to use the greyworld AWB algorithm.

[jamesh]

Which is why I had backups.
I've been in IT since 1975 and "restore from your latest back-up" was my favourite support reply.

How about never update a running and critical system unless you tested the update first on a non-critical system? That would be my favourite.

[nevilley]

How about never update a running and critical system unless you tested the update first on a non-critical system? That would be my favourite.

How about "Just let the customers do the beta testing" or "if it ain't broke don't fix it".

If you would like an experienced QA manager I can come out of retirement.

Meanwhile, I'll wait for a permanent fix to be released.

[jamesh]

How about never update a running and critical system unless you tested the update first on a non-critical system? That would be my favourite.

How about "Just let the customers do the beta testing" or "if it ain't broke don't fix it".

If you would like an experienced QA manager I can come out of retirement.

Meanwhile, I'll wait for a permanent fix to be released.

"if it ain't broke don't fix it"

The AWB algorithm was changed because it needed to be taken off the QUAD processors on the GPU, as the use of the new Mesa driver means they are no longer available for use by the GPU - the Mesa driver is entirely ARM space, and a system to ensure safe sharing of the quads between ARM and GPU would cause performance issues (locking across a communications boundary - vchiq - is too slow). So, we needed a algorithm that could run entirely on the vector unit, so it needed to be less CPU hungry. Hence the change.

"Just let the customers do the beta testing"

Indeed , we do not have a test department (The entire trading team is about 40 people, about half engineers in HW and SW), so we prerelease stuff that get through internal testing to beta testers. The AWB change was announced a while back, and tested. The purple hue on the NoIR was reported and was fixed by adding the greyworld option to Raspistill. We are not responsible for other people's software e.g. Motion. They will need to update whatever needs updating.

[bensimmo]

That is true, this was tested by whoever wanted too. it's the first two post in this section.
But this was the change. It tried it, i didn't see a problem for what I do (I did forget to report back, but I've been changing jobs. I'm moving to the dark side of education by actually becoming a teacher, rather than the fun side of education as support staff.)

[Pi_DD]

Request for a clarification......

RESOLVED, the answer is AWB mode 0 still works if needed on latest Stretch and Buster

I have a camera that uses both visible light LEDs and I.R LEDs and is managed using Motion/Motioneye.

Had the “purple haze problem” and fixed it with the AWB=0 workaround.

I note that the latest kernel update, today, now includes the new “greyworld” option.

Before I apply it to the relevant Pi, does the AWB=0 workaround still work on this update?

Reluctant to update if it does not until I have found out how to handle AWB modifications via Motion/Motioneye for the two forms of lighting.

Thanks

[ProDigit]

I just want to caution people using the command:

Code: Select all

sudo rpi-update

It could brick your Pi installation, and you'll need to reinstall the OS again.
Happened to me a few weeks ago.

Don't use it, unless you know what you're doing, and have no other alternative!

[jamesh]

I just want to caution people using the command:

Code: Select all

sudo rpi-update

It could brick your Pi installation, and you'll need to reinstall the OS again.
Happened to me a few weeks ago.

Don't use it, unless you know what you're doing, and have no other alternative!

Indeed, and there is a big message when you run it saying exactly that.

[roelfraspi]

I don't use thumbnails.

This is the "purple haze" problem reported elsewhere.
I'm using the 8Mp NOIR pi cams with no filters with Pi zero W and the motion s/w package..

Examples of before and after the recent update can be seen here on a camera that is lit only with IR leds.
http://www.nevilley.org.uk/RPi/snap1.jpg
http://www.nevilley.org.uk/RPi/snap2.jpg

I have already reverted to a previous backup of the system to make it work again on 2 of the 3 affected systems.
The 3rd system uses daylight so despite having the purple haze it is still useable.

This was fixed some time ago. You need to set -awb greyworld on the raspistill/vid command line.

See https://github.com/raspberrypi/firmware/issues/1167

There are also fixes for the awb off problem above, use rpi-update to get that as its not made it into the main release yet.

I just upgraded again and tried taking photos and setting white balance myself it still does not work. Only the embedded thumbnails reflect the choosen WB setting the image does not. Greyworld is no workaround for setting a manual white balance. It might be quite satisfactory for security cams and all that but I am using the Pi Cam for photography.

[6by9]

Bug in capturing images with manual gains noted, and fix being prepared.

[roelfraspi]

Bug in capturing images with manual gains noted, and fix being prepared.

Thank you.

[mattoni]

Same issue here. I 'm using Pi Noir Camera v2 and Buster just updated. I'm also using an IR light. I have purple video.
I tried :
sudo vcdbg set awb_mode 0
but i have strange behaviour. Most of the time the video is black and white (as it should be) but time to time it turns to purple again.

[mattoni]

By the way...how can i set "greyworld" if i'm using PiCamera libraries?