Raspberry Pi Camera V2 Color wrong

[tdub415]

Describe the bug Using a fresh install of Raspbian (Buster) and Octoprint. When attaching my raspberry pi camera v2 to either a Pi3+ or Pi4, the color balance seems to be constantly auto-balancing with extremely red results. (Detailed here: https://community.octoprint.org/t/raspberry-pi-cam-color/17717/14)

To reproduce Flash Octopi (or manually Built octoprint on a fresh install of Raspbian (Buster)). Configure pi-camera settings.

Expected behaviour Camera color balance to be consistent with how it behaved in Raspbian (Stretch) build of Octoprint I have running on my Pi3+

Actual behaviour Camera color is far too red, and constantly adjusts the balance significantly depending on how close the objects are to the camera

System Copy and paste the results of the raspinfo command in to this section. Alternatively, copy and paste a pastebin link, or add answers to the following questions: pi@raspberrypi:~ $ raspinfo -bash: raspinfo: command not found

• Which model of Raspberry Pi? e.g. Pi3B+, PiZeroW Issue is present on both Pi3+ and Pi4 with the latest Raspbian (Buster)
• Which OS and version (cat /etc/rpi-issue)? Raspberry Pi reference 2020-02-13 Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 5f884374b6ac6e155330c58caa1fb7249b8badf1, stage4
• Which firmware version (vcgencmd version)? Feb 12 2020 12:37:37 Copyright (c) 2012 Broadcom version c3c8dbdf147686fb0c3f32aece709d0653368810 (clean) (release) (start_x)
• Which kernel version (uname -a)? Linux raspberrypi 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux

[davidplowman]

I'd be interested to see this. Are you able to capture a still image of the problem with the raw data attached? Use something like "raspistill -t 5000 -r -o jpegplusraw.jpg". Also, can you describe roughly what the illumination is. Is it indoors with artificial lighting (what kind)? But also with windows and some daylight entering too? Thanks.

[tdub415]

`pi@raspberrypi:~ $ raspistill -t 5000 -r -o jpegplusraw.jpg mmal: mmal_vc_component_enable: failed to enable component: ENOSPC mmal: camera component couldn't be enabled mmal: main: Failed to create camera component mmal: Failed to run camera app. Please check for firmware updates

pi@raspberrypi:~ $ `

raspistill doesn't seem to work in buster

Illumination is fluorescent tubes in the main room (somewhat blocked by the enclosure) and a LED array shining down on the build plate (IKEA DIODER strips)

[davidplowman]

Hi, thanks for the reply.

So the illumination sounds interesting, LED lights have been known to cause trouble because of the non-natural spectrum, so it's not implausible that it might confuse things - so it would indeed be good to try and get a raw capture. (You don't by any chance have a means of measuring the colour temperature?)

As regards raspistill not working in Buster - I believe it does work for most people so perhaps we should go through the usual check-list. (Apologies if this is like teaching granny to suck eggs...)

• Is the camera enabled in your Raspberry Pi Configuration? (either in the Preferences menu or via "sudo raspi-config").

• What does "sudo vcgencmd get_camera" say? Should be something like "supported=1 detected=1".

• Probably worth double-checking all the cables.

• You said it's a V2 camera, can you confirm it's an official Raspberry Pi module?

Can't think of anything else for the minute... thanks for your help and please let me know how you get on.

[6by9]

Did you stop Octopi using the camera before trying raspistill? You can only have one client to the camera at a time. raspistill works fine on Buster.

[tdub415]

I don't have a way to measure the color temp of the LEDs, but until the buster build for the Pi4, they did not cause an issue with stretch build on the Pi3+. The buster build also produces the issue on the Pi3+.

No worries about going through a basic checklist, it's gonna be the best way to debug the issue. I'm currently using a plugin to manually set the R/B balance, but even with it (which is supposed to set them at a fixed value) I can see some very minor fluctuations like it's starting to try to auto-adjust, but then gets set back to the values I have set in the plugin.

The camera is enabled (had to enable it to get it to be usable in octoprint).

pi@raspberrypi:~ $ sudo vcgencmd get_camera supported=1 detected=1 pi@raspberrypi:~ $

I have tried a few different cables, and ensured that they were all properly seated.

I am 100% certain it is an official module

[tdub415]

Did you stop Octopi using the camera before trying raspistill? You can only have one client to the camera at a time. raspistill works fine on Buster.

Ah ha! no i didn't, let me find the command to stop octorpint using the camera

[pixelfish22]

I'm also experiencing this. Was there any resolution or work-around available?

[tdub415]

I'm also experiencing this. Was there any resolution or work-around available?

I never found a good solution, the only answer I could find was the hardware encoder changed with the pi4 or something, causing the difference in behaviour of the auto white balance.

A workaround I am using was to install the octolapse plugin and use it purely to manually set the color balance. I can still see it trying to auto adjust if I watch closely, but it quickly snaps back to the values I have it forced to.

[davidplowman]

Hi again, as I mentioned previously, I'd like to have a look at this. If someone can post some jpeg+raw captures that exhibit the problem, that would be very helpful. It would also be interesting to know the colour gains that you set manually. Thanks!

[tdub415]

The octolapse camera settings that work for me (after manually dialing it it) are: Brightness 50, Contrast 10, Saturation 0, Red balance 1000, blue balance 2400, power line frequency 50 hz, sharpness 0, color effect: none, color effect cbcr 32896.

I thought I had replied with the raw images previously but I guess i never had (they were too big to upload, so i guess I forgot to upload them to imgur). Here's a couple of older ones, one I too just a bit ago that do not have the color correction, and one with my color correction settings. https://imgur.com/a/TX2EKuP

Hi again, as I mentioned previously, I'd like to have a look at this. If someone can post some jpeg+raw captures that exhibit the problem, that would be very helpful. It would also be interesting to know the colour gains that you set manually. Thanks!

[davidplowman]

Unfortunately there doesn't seem to be any raw data in those jpegs, they would have to be captured with "raspistill -r".

Nonetheless the red/blue balance numbers are quite interesting. Though I'm not familiar with "octolapse", I assume this means you're specifying a red gain of 1.0 and a blue gain of 2.4.

In the camera tuning for the Pi v2 camera we have the following given as the canonical gains for different colour temperatures:

2498K - red_gain = 1.193 blue_gain = 3.040 2811K - red_gain = 1.353 blue_gain = 2.445 3627K - red_gain = 1.408 blue_gain = 2.101

So the blue balance that you give would seem to suggest a colour temperature around 2800K, but the red balance is completely off the charts. Basically the illumination here is massively redder than would be found on Planckian curve that the AWB is tuned to expect.

It will probably have "worked" on older software because that would "fail over" silently to a "grey world" AWB method. That code won't run any more and the replacement doesn't behave the same. You have to choose your poison, really - if you fail over silently like that then there are cases when a genuine pink object would suddenly go grey. Not sure if there's a solution but I'll give it another ponder.

In the meantime, the realistic workarounds you have are probably:

• Set the colour gains manually (as you are).
• Put the AWB into grey world mode (there will be threads on the forums on this, I can't quite remember the runes).
• I don't suppose these lights can be adjusted? Decreasing the relative amount of red (by as much as 35%) would clearly help.

[tdub415]

I'm not sure why the raw data isn't there, I used the command you gave me earlier this year "raspistill -t 5000 -r -o jpegplusraw.jpg" for both the old images and the new.

I have experimented with several different light sources (LED, Flourescent, incandescent, and natural sunlight) and all seem to have the same overly red saturated issue.

I'm not sure what the values of the sliders in octolapse translate to, but the sliders range from 1 to 7999.

I'm also not sure what exactly it is that changed with the formula/calculation of awb/color balance between jessie and buster for the camera port, but the overly red balance issue still only happens on both pi3+ on buster and pi 4 (which to my knowledge doesn't have a jessie build). If i revert to an jessie based image on my pi3+, the picture is correct (but there are other issues with the processor throtteling and stuttering under load that i really need to use the 4 for my setup). I'm fine with my manual workaround, the only thing really keeping me coming back to this issue is when I randomly get an email becasue someone else has the issue and asks a question. Trying to keep as much information out there as I can so that hopefully a solution can be found for anyone who needs it.

[6by9]

Use a file hosting service (eg DropBox or Google Drive) rather than image hosting. Imgur is probably rewriting the file.

[janrutger]

I have the same problem. Pi4B with a new Picam V2. The image is much too red almost purple.

I wonder if it might be a defective chip on the camera because otherwise a lot more people would complain about this. Even with an AWB=grayworld it is anything but color real