StereoPi Forum

Hello,

I'm having an issues with my StereoPi that I acquired a few months ago. I finally got around to setting things up and I'm getting a strange problem with one of the camera inputs.

My setup;
StereoPi
CMS3+ lite
SD Card
SLP Install

On the right side camera input (if looking out like the camera perspective), the right side camera is displaying red or magenta in areas of high brightness. To make sure it wasn't a cable or camera issue, I've tried all different cables (and lengths) and cameras from Waveshare and the official Raspberry Pi 2.0 camera. The right side camera port also seems to be slightly more blurry on all three of the cameras.

Is this something that I can adjust in software or is something defective and the board needs to be exchanged?

Thanks for any help!

A

Hi Atfphoto,
Both cameras transmitting their data in a digital format. I.e. blur effect can not be caused by the ribbon cable or the camera connector. In my experience, 80% of blur can be removed by cleaning the optics (as it has some fingerprints after touching it).

We got this "magenta" effect only with the very specific cameras from Soho Enterprise (and 220-degree FOV). What's going on under the hood:
1. One camera is a "master". This is the left camera in your case. This camera does all brightness/contrast/AWB settings.
2. The second camera is a slave. I.e. it uses the settings from the first camera, implements them, and make a shot.
I.e. under very specific conditions (like overlight) this mechanism works not so good.

Can you please conduct one simple experiment. Try to install the latest Raspberry Pi OS (Buster), but our dt-blob.bin in the /boot partition (unzip it before this!), and make a shot using, for example, "raspistill -3d sbs -w 1920 -h 1080 -o 1.jpg", under the same overlight conditions.
Why am I asking for this: several months ago the Raspberry Pi Foundation implemented a new AWB algorithm. Our SLP image uses the old Raspberry Pi OS (Stretch) with the old AWP algo. New Buster has a new AWB, and this can solve your issue. If it works for you, we'll try to suggest an approach for the update of the SLP kernel to the latest one (it's a tricky thing).

Hello!

Thanks for the reply! I'll give your solutions a try tomorrow.

I didn't think the blur effect would be an issue with software unless there was heavy compression being applied for some reason.

The cameras I am using are SainSmart IMX219 camera module 8MP sensor 200 degree FoV.

https://www.amazon.com/gp/product/B07WR ... UTF8&psc=1

However I still saw the effect in a standard Raspberry Pi camera module but not nearly as pronounced.

I'll let you know how the test goes after tomorrow.

Thanks again,

A

I am interested to know the result of your test too.

I also saw the color derive with other camera models when I did the stereomaton. In the rush of the project, we added a custom color balance after the process of raspistill and it worked well except for blown out parts. I did not pay attention to this on tests I did afterwards, but I remember to have seen it with the soho cameras. I guess that the algorithm inside the closed-source part of the chip was fooled by so much black in the image.

Hello,

I had a chance today to load up the Raspberry Pi OS (minimal), installed all updates, etc. and gave it a few tests.

Unfortunately this didn't solve the issue with the SainSmart 200 degree FOV cameras _or_ the official Raspberry Pi v2.1 cameras.

After I installed the new version of the OS and got everything updated, I ran the test you mentioned below:

raspistill -3d sbs -w 1920 -h 1080 -o newtest.jpg

The first result showed the same effect as before using the SainSmart cameras:


SainSmart Cameras 200 Degree FOV with Raspberry Pi OS:
Out of curiosity, I moved the cameras closer to the window to see what it would do with the change in dynamic range.

Close to window:
Away from window:
Against window:
At this point I decided to try the official Raspberry Pi v2.1 cameras with the Raspberry Pi OS and got some strange results. In the first image, it seemed fine but then I noticed some magenta but this time it's in left camera.

Raspberry Pi v2.1 cameras w/ Raspberry Pi OS:
On the second test, I changed the perspective and white balanced with a quick flash of my hand. You can definitely see the magenta back in the right camera, similar to the SainSmart camera.
On the third test, I placed it up against the window and the results are quite a bit different between the two cameras. Any thoughts?

Oh and sorry about the Pi cameras not being quite level. Ha!

Thanks!

A

(Another from the window with the SainSmart 200 degree)
Test Setup

Hi Aftphoto,
Thank you for your detailed troubleshooting!
I can suggest we have a parameter sync issue (i.e. implementing master camera settings to the slave camera settings).
If so, I will recheck this and ask RPF engineers to fix that.
To confirm this hypothesis, can you please do one more test, and do a software switch of the cameras. To do this, add the "-cs 1" option to your capturing code. I.e. for your "raspistill -3d sbs -w 1920 -h 1080 -o newtest.jpg" try to run "raspistill -cs 1 -3d sbs -w 1920 -h 1080 -o newtest.jpg"
In this case, your magenta color effect should "jump" to another camera.

As an idea, you can also play with the metering mode (-mm, details can be found here). It may help you with the backlit conditions you are working with.

Same issue here with HQ Camera and SLP v0.2.3
I figured it out during a long exposure test, which explains the burnt picture.

Julsboo, is the same camera stays "magenta" if you turn on the "swap camera" option in the Admin panel?
p.s. I will try to repeat this bug on my setup, and formulate a bug-report to the RPF. I will also try to find an option affecting on this magenta effect (AWB, color balance etc.)
UPD> I posted this issue description at the appropriate thread at the RPF forum.

If I turn on the "swap camera" option it isn't the same camera which has the issue
The issue swap too

First row swap off
Second row swap on

Hello!

I ran a few tests yesterday as requested. Let me show you the results for the camera switch request;

"To confirm this hypothesis, can you please do one more test, and do a software switch of the cameras. To do this, add the "-cs 1" option to your capturing code. I.e. for your "raspistill -3d sbs -w 1920 -h 1080 -o newtest.jpg" try to run "raspistill -cs 1 -3d sbs -w 1920 -h 1080 -o newtest.jpg"
In this case, your magenta color effect should "jump" to another camera."

The same setup as before for the first set;

StereoPi
SainSmart 200 degree FoV - SONY IMX219 - CMOS 1/4 Inch - 3280x2464 - Focal length 0.87mm - Aperture (F):2
CMS3+ lite
SD Card
Raspberry Pi OS 4.17 with the device tree blob


The first test showed similar results.

In the first frame, Magenta in the right image and purple spots or purple haze in the highlights.

Capture Command: raspistill -mm matrix -ag 1 -dg 1 -ev 0 -drc high -3d sbs -q 100 -r -set -w 1920 -h 1080 -o newsettings22.jpg
.
. .
.
.
The second frame of the first test the magenta moved to the left, BUT the purple spots and haze in the highlights did not change.

Capture Command: raspistill -cs 1 -mm matrix -ag 1 -dg 1 -ev 0 -drc high -3d sbs -q 100 -r -set -w 1920 -h 1080 -o newsettings23.jpg
.
. .
.
.
The next test first image shows a similar problem with the magenta but somehow the purple spots are barely visible:

Capture Command: raspistill -3d sbs -mm matrix -ag 1 -dg 1 -ev 0 -drc high -q 100 -r -set -w 5184 -h 1952 -o photo2.jpg
.
. .
.
.
The second frame shows the magenta has moved to the left. No change in barely visible spots on right.

Capture Command: raspistill -cs 1 -3d sbs -mm matrix -ag 1 -dg 1 -ev 0 -drc high -q 100 -r -set -w 5184 -h 1952 -o photo3.jpg
.
.
.
.
.
In this next test I tried some adjustments to the command line parameters for raspistill. By modifying the meter mode (-mm) and setting it to spot instead of matrix. The results were far better than any of the other images so far. The magenta was still in the right image, but it was much reduced.

Capture Command: raspistill -3d sbs -mm spot -ag 1 -dg 1 -ev 0 -drc high -q 100 -r -set -w 5184 -h 1952 -o photo8.jpg
.
. .
.
.
The second frame of this test shows the magenta move to the left side, but no visible blow outs in the right.

raspistill -cs 1 -3d sbs -mm spot -ag 1 -dg 1 -ev 0 -drc high -q 100 -r -set -w 5184 -h 1952 -o photo9.jpg
.
. .
.
.
In this next test I tried some adjustments to the command line parameters for raspistill and used -mm matrix for these two images. The magenta was heavy in the right image and the purple haze is pronounced in the highlights.

Capture Command: raspistill -3d sbs -mm matrix -ag 1 -dg 1 -ev 0 -drc high -q 100 -r -set -w 5184 -h 1952 -o photo10.jpg
.
. .
.
.
The second frame of this test shows the magenta move to the left side, but the purple haze remains in the highlights on the right.

Capture Command: raspistill -cs 1 -3d sbs -mm matrix -ag 1 -dg 1 -ev 0 -drc high -q 100 -r -set -w 5184 -h 1952 -o photo11.jpg
.
. .
.
.
At this point, I decided to try another completely different set of the cameras. The images below all use the same model that I acquired of the SainSmart from the same vendor.
.
.
.

With the cameras swapped out, I noticed that the new set of cameras has far less of a magenta cast issue. It's still there but it's not as pronounced as the other camera set. I have _no_ idea why this true. In this test I tried some adjustments to the command line parameters for raspistill and used -mm average for these two images. The magenta was much lighter in the right image but the purple haze is still pronounced in the highlights.

Capture Command: raspistill -3d sbs -mm average -ag 1 -dg 1 -ev 0 -drc high -q 100 -r -set -w 5184 -h 1952 -o photo12.jpg
.
. .
.
.
The second frame of this test shows the magenta move to the left side, but the purple haze remains in the highlights on the right.

Capture Command: raspistill -cs 1 -3d sbs -mm average -ag 1 -dg 1 -ev 0 -drc high -q 100 -r -set -w 5184 -h 1952 -o photo13.jpg
.
. .
.

So it seems that there are two issues:

1. A magenta cast is covering the image in the camera that is receiving settings from the host camera.

2. In the right camera, the highlights are blown out and change to purple dots or a purple haze regardless of using the -cs (camera selection) command.

Hope this helps and I labeled everything correctly.

A

P.S. I wish I could clean the windows on the outside. Ha!

Hello,

One more image. This image was a test when I was playing around with the parameters for the analog and digital gain.
I had cranked the digital gain up all the way to see what the effect was on the image.

raspistill -3d sbs -mm spot -ag 1 -dg 12 -ev 0 -drc high -q 100 -r -set -w 5184 -h 1952 -o photo21.jpg

You can really see the magenta in the image on the right.

.
.
.
Thanks!

A

Atpfoto, thank you for this extended testing!!!!
I plan to get this magenta effect with one camera, to localize the raspistill parameter, which is not synchronized correctly between two sensors. My experience says, that localizing the problem helps Raspberry Pi engineers to fix this quickly.

Hello!

You are so welcome! I hope it's useful in tracking down the issue.

Let me know if you need any more test images.

Thanks!

A

Hello,

I had to put aside the stereopi last year because of the magenta issue.

Is this something that was fixed in the new version of the stereopi? I can’t find much for info on it.

Thanks!

A

Hi Atfphoto,
Looks like this issue is not solved yet in the Raspbian kernel. I'll do some tests with the latest kernel available to check this.
I have one workaround right now for HQ cameras. It is possible to get two images independently (using two raspistill processes in parallel), but with the hardware sync of both cameras. I described this HQ feature in our last update.

p.s. Atfphoto, I did one bad thing and asked the RPF Software development department head about this issue. As a result, we got an answer in this thread: https://www.raspberrypi.org/forums/view ... 0#p1842048
Could you try this way? This might work...

Hello!

Wow! Thanks for checking in with them. I’ll definitely take a look and see what they say.

Also I’ll try what you had mentioned with the HQ cameras.

Thanks!

A

Hello,

Had change to pull the stereopi back out today and gave the command a try to switch back to the old AWB.

Unfortunately, no change in the image in regards to the magenta cast in the second image.

Is this something that also affects the new StereoPi? How is anyone using the StereoPi with the magenta casts?

Anyhow.. back in the drawer it goes for now.

Here are the commands I used for capturing and the two results.

sudo vcdbg set awb_mode 0
sudo vcdbg set awb_mode 1

raspistill -3d sbs -mm average -ex auto -q 100 -r -set -w 5184 -h 1952 -o AWB_0.jpg
raspistill -3d sbs -mm average -ex auto -q 100 -r -set -w 5184 -h 1952 -o AWB_1.jpg

Thanks!

A

Aftphoto, thank you for your tests!
Could you please do the last test - check the same thing using the latest stock Raspbian and our dt-blob.bin?

In my own experience, this effect appears only in some special conditions. Like image should have both extremely dark areas (corners on the fisheye photos) and extremely light (sun or sky). I'll ask RPF again to fix this.

Guys, looks like RPF is not planning to fix this issue (as 6by9 told here).
My investigation shows that magenta cast can be fixed by after-processing. We need to increase G to the maximum for any RGB point, where R and B > 249 and G>207. I checked this approach with all photos in this thread, and it works fine.

Example:

Before: After: The row I used with ImageMagick is:
I know this is a bandage and a workaround, but we can use this for post-processing images taken with IMX219 and IMX477 sensors.