Camera pictures are coming out wrong and poor quality — what is going on?

Raspberry Pi Cameras
1

Our camera pictures are coming out like this… What is going on!!!

I’m running an Arducam camera on a Raspberry Pi and the image quality is just plain bad. The colors are washed out / wrong and the overall quality is terrible. It doesn’t look like a normal capture at all.

Attaching a sample of what we’re getting:
thumb1024x768 (2).jpg

Please advise.

2

Sorry to hear you’re hitting this. We’ll have a check here and reply to you soon.

Before we can reproduce it, I need two things from you:

  1. You purchased two different cameras from us. Which one is this exactly — the B0272 or the B0324?
  2. What command did you use to execute/capture the image? If you can, please include a screenshot of the command you ran.

Also, could you please fill out the attached Arducam Technical Support Form so we have all the details in one place? That helps us move faster.

Arducam_Technical_Support_Form.xlsx

3

OK, so we’re testing the 21MP AF camera in a larger quantity now.

Originally we bought one camera and it worked fine. So we bought 20 more as a test batch / POC. Every single one of those 20 cameras has the same image quality issue — poor quality and the colors are off. Same as in the sample I posted earlier.

On top of that, on one of the 20 test cameras the autofocus just failed to work.

A couple questions while we’re at it: which method of capture will give us the best image quality? Right now we’re just using libcamera-still, nothing else.

4

Thanks, that’s helpful — if it’s consistent across all 20 units, that narrows things down a lot.

Can you share your environment so we can try to reproduce locally? Specifically:

  • Which Raspberry Pi board and RAM size
  • The OS and version
  • How the cards/images were set up (were they cloned or fresh installs?)
  • The Arducam code version you pulled (and the git hash if you have it)
  • uname -a output and the camera firmware version from dmesg

With that plus your exact command, we should be able to line it up against our test setup.

5

Sure, here’s the environment:

  • Raspberry Pi 4 Model B Rev 1.5 (pi4 B+, 2GB RAM)
  • 20 testing cameras, all with dd-cloned (bit-for-bit identical) filesystems
  • Raspbian Bullseye 32bit
  • Latest Arducam code from GitHub as of July 13th, 12:00pm UTC (I don’t have the exact git hash recorded)

Kernel:

Linux 74F4GA 5.15.32-v7l+ #1538 SMP Thu Mar 31 19:39:41 BST 2022 armv7l GNU/Linux

OS:

PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
VERSION_ID="11"
VERSION_CODENAME=bullseye
ID=raspbian
ID_LIKE=debian

CPU:

CPU implementer  : 0x41
CPU architecture : 7
CPU variant      : 0x0
CPU part         : 0xd08
CPU revision     : 3

Hardware:

BCM2711, Revision b03115
Serial: 1000000092966ae5
Model: Raspberry Pi 4 Model B Rev 1.5

Camera:

arducam-pivariety firmware version: 0x10001
Registered camera /base/soc/i2c0mux/i2c@1/arducam@0c to Unicam device /dev/media3 and ISP device /dev/media0

Time zone is UTC -4 (eastern USA).

6

Great, thanks. A couple more things so we can mirror your exact setup:

  1. The exact capture command you’re running (full line, including any wrappers).
  2. The contents of your /boot/config.txt (especially any dtoverlay lines).
  3. The libcamera output when you run a capture, plus dmesg -T | grep arducam.

With those three we should be able to see whether this is config, software version, or something on the camera side.

7

Here’s the exact capture command:

/usr/bin/timeout -s SIGINT 8s /usr/local/bin/libcamera-still -t 3000 --vflip --hflip --autofocus -q 90 -n -o test.jpg

We’re using only libcamera-still — not python or any other method. The /usr/bin/timeout wrapper is there because the libcamera binary hangs periodically and doesn’t exit cleanly. Over time that fills up the process list, which leaves the camera busy and makes it more prone to errors.

Tail of /boot/config.txt:

[all]
[pi4]
# Run as fast as firmware / board allows
arm_boost=1
[all]
dtoverlay=arducam
gpu_mem=256
max_usb_current=1

Logs coming in the next post.

8

Perfect, that command and config are exactly what I needed to see.

Go ahead and post the libcamera capture output and the dmesg -T | grep arducam lines. Those will tell us whether the sensor/IPA is loading the way it should on your build.

9

Here’s the libcamera output:

[37:52:58.585956124] [7025]  INFO Camera camera_manager.cpp:293 libcamera v0.0.0+3729-5f595cca
[37:52:58.602698948] [7027]  WARN CameraSensorProperties camera_sensor_properties.cpp:174 No static properties available for 'arducam-pivariety'
[37:52:58.602774763] [7027]  WARN CameraSensorProperties camera_sensor_properties.cpp:176 Please consider updating the camera sensor properties database
[37:52:58.611937760] [7027] ERROR IPAProxy ipa_proxy.cpp:149 Configuration file 'arducam-pivariety.json' not found for IPA module 'raspberrypi'
[37:52:58.967336832] [7027]  WARN RPI raspberrypi.cpp:1274 Mismatch between Unicam and CamHelper for embedded data usage!
[37:52:58.967987592] [7027]  INFO RPI raspberrypi.cpp:1398 Registered camera /base/soc/i2c0mux/i2c@1/arducam@0c to Unicam device /dev/media3 and ISP device /dev/media0
[37:52:58.968643519] [7025]  INFO Camera camera.cpp:1029 configuring streams: (0) 2672x2008-YUV420
[37:52:58.998348105] [7027]  INFO RPI raspberrypi.cpp:763 Sensor: /base/soc/i2c0mux/i2c@1/arducam@0c - Selected sensor format: 2656x2004-SRGGB10_1X10 - Selected unicam format: 2656x2004-pRAA
Stream configuration adjusted
[37:53:02.622032918] [7025]  INFO Camera camera.cpp:1029 configuring streams: (0) 5344x4012-YUV420 (1) 5344x4012-SRGGB10_CSI2P
[37:53:02.685149838] [7027]  INFO RPI raspberrypi.cpp:763 Sensor: /base/soc/i2c0mux/i2c@1/arducam@0c - Selected sensor format: 5344x4012-SRGGB10_1X10 - Selected unicam format: 5344x4012-pRAA
Still capture image received

And dmesg -T | grep arducam:

[Mon Aug  1 13:31:34 2022] arducam: loading out-of-tree module taints kernel.
[Mon Aug  1 13:31:34 2022] arducam-pivariety 10-000c: firmware version: 0x10001
[Mon Aug  1 13:31:35 2022] arducam-pivariety 10-000c: Consider updating driver arducam-pivariety to match on endpoints
10

Thanks — that gives us a clear picture. I notice a couple of things worth digging into:

  • ERROR IPAProxy ipa_proxy.cpp:149 Configuration file 'arducam-pivariety.json' not found for IPA module 'raspberrypi'
  • WARN ... No static properties available for 'arducam-pivariety'
  • WARN ... Mismatch between Unicam and CamHelper for embedded data usage!

Those could all point to a software/version mismatch rather than a hardware fault. Before I go further — what have you already tried on your side? Has anything changed the output at all?

11

So far I’ve tried taking photos both with and without the timeout command — same results either way. So the timeout wrapper isn’t the cause.

My plan is to rebuild the OS from scratch with the latest code, and then compare the software versions on the first camera (the one that worked) against the 20 bad cameras. I should have that data tomorrow.

I’ve attached the pip and apt output for the versions currently installed:

installed-packages-pip
installed-packages

Sample of the current output again:
thumb1024x768 (2).jpg

12

OK, here’s where we stand so far, so we have it captured in the thread:

  • The issue shows up as poor image quality and off colors on the 21MP AF camera (B0272/B0324 family). One original unit works fine, but all 20 units in your test batch show the same problem, and one of those 20 also had autofocus fail.
  • Your setup: Pi 4 Model B Rev 1.5 (2GB), Raspbian Bullseye 32bit, Arducam code pulled around July 13, all 20 cards using dd-cloned identical filesystems.
  • Your capture line is: /usr/bin/timeout -s SIGINT 8s /usr/local/bin/libcamera-still -t 3000 --vflip --hflip --autofocus -q 90 -n -o test.jpg
  • Removing the timeout wrapper made no difference.
  • The logs show the arducam-pivariety.json IPA config file missing, no static sensor properties for arducam-pivariety, and a Unicam/CamHelper embedded-data mismatch.

Given that your filesystems are identical clones yet the results track with the batch of cameras (working unit vs. all 20 new units), this doesn’t look like a per-config issue — it points toward either the software/version stack or the cameras themselves.

So the key next step is your comparison: rebuild the OS with the latest code, then diff the pip/apt/Arducam versions between the working camera and the failing batch. Once you post that version diff and the rebuilt-OS results, we can narrow it down further. We’ll keep watching this thread for tomorrow’s data.