Color balance is very green

[jwatte]

I'm capturing video with code that I've stolen from raspividyuv, and removed a bunch of the features I don't want.

I've tried a few different color balance modes, but the color balance is still very greenish:



The same lighting environment (it's an indoors warehouse in California, with matted glass skylights all through the ceiling,) captured with a cell phone camera, looks like this:



I've tried with both MMAL_PARAM_AWBMODE_AUTO and MMAL_PARAM_AWBMODE_INCANDESCENT. It doesn't seem to make much of a difference.

Capturing with the raspivid program does the same thing. I'm using a Raspberry Pi Camera version 1.3.

What could I be doing wrong?

[jwatte]

Also possibly relevant: This is on a Raspberry Pi 2, using the 1.3 camera, starting with a snapshot of raspividyuv from probably 2 years ago.
Also possibly relevant: Running raspividyuv on the board gives greenish quality; running raspivid gives much better quality.
Also, with raspividyuv, using -awb cloudy gives much more balanced white balance than -awb tungsten or -awb incandescent. Which is quite weird -- cloudy is some of the bluest light there is, so it should remove blue!

[jamesh]

I presume you have taken the green protective film off the lens....

[jwatte]

Yes, I have taken the protective film off the lens! In fact, this camera was working great two years ago.
Perhaps this is related to having done a dist-upgrade, and the drivers expecting the version 2 camera now?
I tested with a version 2.1 camera, and it has better color (but not great.)
When I force the camera gains manually, gains of r=1,b=3 make for pretty good color balance.
I'm considering just hard-coding it for now, because for vision, it's better to have a fixed color space anyway.

I'm still interested in what I'm mis-understanding about the AWB values, though. To my thinking saying "it's a cloudy day" should make the camera remove blue and add yellow, and saying "it's under incandescent lighting" should make the camera remove oranage and add blue, but it seems to be doing the exact opposite!

[6by9]

The firmware has independent tunings for the V1 and V2 camera modules. It tries to talk to the different module types in turn on first access until one responds (they're on unique I2C addresses, and generally have an ID register too). All further access and tuning is based on which module responds.

Having to shift to red gain x1, blue gain x3 is a pretty serious skew.

Your first post:

Capturing with the raspivid program does the same thing.

Your second post:

Running raspividyuv on the board gives greenish quality; running raspivid gives much better quality.

So is raspivid better or not? Unless you're changing other things on the command line between the two then there is no difference in the processing being done on the GPU.

You appear to be using VLC to view. What does it reckon the codec format is, and indeed what are you requesting from raspividyuv to then generate an .mp4 file for it to play? My normal suggestion for viewing YUV or RGB files is Vooya. I wouldn't like to guess as to which colour space VLC is interpreting the raw data as (JFIF, BT601 and BT709 do exhibit significant differences in the colour conversion to RGB). Is the preview really that green on the HDMI preview?

[jwatte]

Sorry, the first "raspivid" was meant to say "my custom program, and raspividyuv, have the same problem; raspivid seems perhaps better?"

The screen shot is from VLC, because it was generated from a .h264 file generated on the Raspberry Pi and downloaded to my laptop. I write the raw h264 data to disk (similar to how raspivid/yuv does it) and play it back using "-demux h264" because it doesn't contain the full mp4 framing. The video illustrates the same problem as I see in the preview window on-device: yes, HDMI is approximately as green (it's a different monitor from my laptop, and indeed from your monitor, and I don't have an exact color calibration,) and also in the actual framebuffer data that I do vision on. Which is the actual problem for me; these pictures won't be seen by human beings so as long as I can get good color separation without losing dynamic range, I'm fine.

This is code that worked two years ago, and that I'm now reviving, so unless my memory fails me (and it was green back then, too?) this is some software that's changed in the last two years or so.