Raspberry Pi Cam V2
The color of my camera feed on my new Raspberry Pi 4 with a fresh install of Octopi keeps changing its red balance.
Verified that the camera still works properly on my Pi3+, tried various awb settings to no avail
**I don't seem to have a webcamd.log in the var/log folder
Pi3+
Pi4
Additional information about your setup Both the Pi3+ and Pi4 are running the same current version of octoprint, have the same plugins, and the same raspberry pi camera settings (and it's the same physical camera, I was in the process of swapping out the 3+ with a 4, because i'm repurposing the 3+ for another project)
syslog.log (642.4 KB)
finally got the syslog to transfer
Looks similar to this post/thread, except in your situation it works fine in pi3.
If it changes while you're looking at it, disconnect/reconnect the ribbon cable at both ends. It could be that one of the connections isn't 100% and you're losing a color.
I get the same result. When I plug it in to the pi3+ the colors are correct. When I plug it in to the pi4, they are too red. As the bed moves closer and farther, the intensity of the red changes. When parts are closer to the lens it get much deeper of a red, and when they are further back, it adjusts back down, but never to normal color levels.
Continue to troubleshoot. We haven't ruled out that this is connector-related. What if the ribbon connector on the Pi3B+ was tight and the Pi4B is loose? As things bounce around, the connection makes/breaks. Physically hold the ribbon cable stable on the Pi4B side of things and see if the abrupt color changes don't happen; if so then it's that connector.
In other words: create a thesis like "what if it's the cable connector?", create a litmus test like "determine if the problem goes away if I hold the ribbon", test that and see what you get.
This could be a power thing. The expected power might not be there for the camera which might red-shift the output. (I dunno, it's just a theory, right?) But obviously, you're powering the both Pi computers from different adapters.
I have determined that it appears to be a software issue, not a hardware issue. I created another fresh install on a different SD card to put in my pi3+ to test, and the fresh install on the pi3+ is now showing the same red color behavior as the pi4. The only difference between these cards, and the software running on my pi3+ normally, is I maunally configured and installed octoprint on it, rather than using octopi. I guess I'm going to try doing that tonight on the Pi4 and see if it works normally then.
1 Like
Fresh install and setup of octoprint via raspbian is doing the red shifted behavior as well. I'm begining to wonder if it's some software compatibility issue with Raspbian Buster, since my pi3+ is using Raspbian Jessie, but don't know a good way to test that, since I think the pi4 requires Buster, and is incompatible with Jessie (the pi3+ card doesn't boot in the pi4).
Have now also tried copying the mjpg-steamer folder from correctly working pi3+ over to the pi4, image still showing too much red, and fluctuating between red intensity as objects move closer and farther from camera
If it's a consistent red-shift then you might consider using the OctoLapse plugin which I understand allows you to control all this. Search the forum, someone else was just talking about this. You might search for "Pi NoIR blue filter".
I have configured octolapse (just for the manual red/blue controls) and managed to at least shift the colors to a more normal level, but I can still see minor fluctuations in the intensity, as though the pi is trying to color correct the image even though I've told it to use set values. It seems there is something else somewhere in the software that's trying actively to auto-calibrate the color balance.
It could be changing dynamically due to power problems or connection problems (or a faulty webcam board).
I have no way to test that, but I suspect it's not, since it works flawlessly with the Pi3+ and my Jessie based setup. The issue only seems to happen with the Buster based build, on both devices, and I don't know of a way to use the jessie based build on the pi4 to confirm.
In my own situation, I had the following rig:
- Raspberry Pi 3B with 1GB RAM
- Kivy 1.10.1
- ffpyplayer (much less laggy than gstreamer)
- Python 2.7
All this would cheerfully display animated GIF files within the Kivy interface that I'd written for the TFT screen. But Kivy would throw exceptions whenever certain memory-intensive activities would occur so the platform had to be upgraded:
- Raspbery Pi 4B with 4GB RAM
- Python 3.7.3 (since the updated Kivy is no longer Python 2 compatible)
- Kivy 1.11.1 (since I wanted at least one of the bug fixes)
- gstreamer (since ffpyplayer isn't compatible with Pi4B's GLES3 window provider, noting that gstreamer has a memory leak)
So you have to pick your battles. Sometimes in this world you can't have everything. It would be nice to run Jessie on the Pi4B but you can't. Don't grind on something like that, it'll drive you crazy. Focus on what you can test or try.
Think differently. Offload the camera to another dedicated Pi. Feel free to put Jessie on that one if you want.
Any further solution on this.
Upgraded my Pi3 from Jessie to Buster and now have a red camera image.
Thanks