Cyan vignetting after rpi-update

[ddahms]

After doing a rpi-update last week, I have a strange cyan color shift around the edges of images from raspistill. I did a fresh install and apt-get update and upgrade, then took a simple photo like this: raspistill -w 640 -h 360 -o before.jpg. Then I did the rpi-update and took a second photo. The attached image shows the difference, before and after the rpi-update. It is not a simple white balance shift--notice how the color of the road changes across the frame. Raspivid does not show the cyan shift. Raspimjpeg shows it on captured images but not on the mjpeg images. Is anyone else seeing this?

raspicam.jpg (38.68 KiB) Viewed 12655 times

[6by9]

Which release did you use for your fresh install? That would enable us to narrow down the time frame for GPU changes that could affect this.
Stills captures should always use the full 5MPix sensor mode. AFAIK that hasn't changed, and nor has the lens shading tuning for it.

[ddahms]

I used the Raspbian Debian Wheezy zip file from http://www.raspberrypi.org/downloads. Then apt-get update and upgrade.

[6by9]

Thanks. So that is the 2014-01-07 release.

apt-get only touches packages.
rpi-update upgrades the kernel and GPU firmware. This is almost certainly a GPU firmware change, but there have been quite a few improvements on the camera side in that period (full FOV preview, high frame rate modes, and support for extra image formats) so it may take a bit of effort to pin down.

[ddahms]

I installed the older firmware updates on github one by one to find the offender. It is the March 18 update "userland: invert texture coordinates to match latest firmware" that causes the weird cyan shading to appear.

[6by9]

Wow, thank you for your efforts there. That saved me a huge job!

OK, it'll be the second change in there "firmware: camera: burst capture performance fix" that'll be causing it. That was fixing the white balance values being recomputed on every capture and causing colour shifts. I need to look into the settings to see if anything else was relying on that statistics pass for the capture.

[Ydo]

Got the same problem when I repleaced the original lens with somthing else Did you use the original lens?
See also my post in "M12 lens adapter for camera module"

[6by9]

I'm asking questions here in the office over this.
The sensor appears to be configured to use a dynamic lens shading algorithm that I wasn't aware had been officially signed off for use. I have a suspicion that it was relying on the numbers from the stats pass that was disabled in the March 18th firmware release to stop the AWB chatter.

Ydo: If you revert your firmware back to https://github.com/raspberrypi/firmware ... c5bdc0505e, does your flaring go away?

[jamesh]

Got the same problem when I repleaced the original lens with somthing else Did you use the original lens?
See also my post in "M12 lens adapter for camera module"

That's always a problem when changing lenses with a fixed lens shading table. However, 6x9 has just discovered (see previous post) that we appear to be using a dynamic lens shading algorithm (this is unexpected), so I would expect that, had we not borked the algorithm, it should compensate for lens changes.

[6by9]

That's always a problem when changing lenses with a fixed lens shading table. However, 6x9 has just discovered (see previous post) that we appear to be using a dynamic lens shading algorithm (this is unexpected), so I would expect that, had we not borked the algorithm, it should compensate for lens changes.

The bad news from that regard is that my fix is likely to be to revert to fixed lens shading tables.

Having just had a conversation with one of the lens shading bods, the settings need to change based on binning mode. So with preview being binned and capture not some munging needs to happen. Running the stats pass gave it the appropriate information for the capture (at the expense of AWB shift, although that may have been affected by DLS too) so it produced a plausible LS grid.
Whether the change required between binned and unbinned is predictable is another question again.

[6by9]

I've had a response from my colleague who wrote the dynamic lens shading algo - it sounds like we may just be running an old version.
I've now got a job to try and pull the latest version across - it may take a little while but in theory should sort the problem.

[Ydo]

6X9 [
Ydo: If you revert your firmware back to https://github.com/raspberrypi/firmware ... c5bdc0505e, does your flaring go away?[/quote]

I am not a firmware engineer and did not change it at all.
I am glad to hear that the shading can be solved. I feared it was embedded in the camera GPU firmware and not accessible.

[gorak9000]

I also have the same cyan vignetting problem. I was going to post a new thread, and then I saw this one already existed!

Any word on a fix for this yet?

[jamesh]

For the moment, go back to an earlier firmware, as stated above.

Not sure how long a fix will be - needs a certain amount of juggling of code in the GPU (yes, this is an issue in the GPU firmware) to get the latest lens shading code.

[captainlazinesss]

Is this problem fixed already? I can't test it here but i have to set up a new wheezy image for a timelapse Pi.
If not, how can i update to the last working firmware? i only know the rpi-update command.

[algorithm]

Is this problem fixed already? I can't test it here but i have to set up a new wheezy image for a timelapse Pi.
If not, how can i update to the last working firmware? i only know the rpi-update command.

User ddahms wrote above that the firmware to blame was from 18 Mar. Then 6by9 linked the last one before that: https://github.com/raspberrypi/firmware ... c5bdc0505e which you can install with rpi-update by using that long hex number as an argument:

Code: Select all

sudo rpi-update 089cfb05ec350505ee84a99d567474c5bdc0505e

[captainlazinesss]

okay i did that and got this:

Code: Select all

pi@raspberrypi ~ $ sudo rpi-update 089cfb05ec350505ee84a99d567474c5bdc0505e
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 *** Performing self-update
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   135  100   135    0     0    238      0 --:--:-- --:--:-- --:--:--   319
100  7026  100  7026    0     0  10170      0 --:--:-- --:--:-- --:--:-- 10170
 *** Relaunching after update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 *** We're running for the first time
 *** Backing up files (this will take a few minutes)
 *** Backing up firmware
 *** Backing up modules 3.10.25+
 *** Downloading specific firmware revision (this will take a few minutes)
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0  221k    0   720    0     0   1229      0  0:03:04 --:--:--  0:03:04  1670
gzip: stdin: not in gzip format
tar: Child died with signal 13
tar: Error is not recoverable: exiting now

its a complete fresh wheezy installation, nothing modified so far.
what i'm doing wrong?

[captainlazinesss]

I solved it:

https://github.com/raspberrypi/firmware/

and

https://github.com/Hexxeh/rpi-firmware/

are using different commit hash numbers.
Only the Hexxeh hash numbers work with rpi-update.

Code: Select all

sudo rpi-update 17e66f4a446069a0dda1802d3105202a00b9b35e

[algorithm]

A-ha! Sorry for false info, glad you figured it out.

[gagle]

I also have this problem with arch linux.

[vacuumMarshmallow]

I installed the older firmware updates on github one by one to find the offender. It is the March 18 update "userland: invert texture coordinates to match latest firmware" that causes the weird cyan shading to appear.

Hello guys,
How can I revert back to pre-March 18 update?
I am getting this same odd cyan around the edges of the image.

Do I manually drop the update into the rPi, and then run apt-get update?

Thank you!

[6by9]

Add -st to the raspistill command line and it will resolve the issue on stills captures. See http://www.raspberrypi.org/forums/viewt ... 43&t=84416

Reverting to the old firmware will only work on a model B, not B+, as support for the new board wasn't added until about May.
Read the rest of this thread for how to do it, but basically

Code: Select all

sudo rpi-update [hash]

where [hash] is the commit from https://github.com/Hexxeh/rpi-firmware/

[vacuumMarshmallow]

Add -st to the raspistill command line and it will resolve the issue on stills captures. See http://www.raspberrypi.org/forums/viewt ... 43&t=84416

Reverting to the old firmware will only work on a model B, not B+, as support for the new board wasn't added until about May.
Read the rest of this thread for how to do it, but basically

Code: Select all

sudo rpi-update [hash]

where [hash] is the commit from https://github.com/Hexxeh/rpi-firmware/

Thank you 6by9!!

Very, very much appreciated!
I am a n00b, and was really lost on this.
I will post up if I hit any glitches.
Thank you!

[vacuumMarshmallow]

Odd.
When I run the -st flag with raspistill I get:

Code: Select all

Invalid command line option (-st)

Here is my full command:

Code: Select all

raspistill -st -n -w 800 -h 600 -q 50 -o photo1.jpg -e jpg

Will keep on testing and update here.

[gorak9000]

Has this ever been fixed? I just did an rpi-update yesterday and still seem to see the cyan vignetting.

Also, the green tint in low light seems to be constant in all photos now, rather than random, but I'd much prefer to not have the green tint ever! Is there any way to achieve this?

Probably should mention I'm using a raspberry pi (1) model B. I'd guess the GPU firmware relating to the camera would be the same on the RPI 2??