Can't capture raw image on Raspberry Pi 4; libcamera .raw is 130MB for 1280x720

Raspberry Pi Cameras
1

Hi, I’m trying to capture a raw image with my Arducam setup and something seems off. The .raw file that libcamera produces is way too large. For a 1280x720 capture I’m getting a file around 130MB. Is that normal? And how am I supposed to decode a .raw file into something usable?

2

Hey, happy to help. First, the raw file size usually makes sense once you know it’s storing the unpacked sensor data with a fixed bit depth (often 8 or 10/12-bit per pixel plus padding), so it’s no wonder it looks huge compared to a JPEG. But before we go further, can you tell me your exact hardware/software setup? Specifically:

  • Raspberry Pi model and RAM
  • OS version and kernel
  • Which camera module(s) and any camera shield/adapter board you’re using

Also, what exact command are you running and can you paste the output of dmesg | grep arducam?

3

Sure. Setup is:

  • Raspberry Pi 4 Computer Model B, 4GB RAM
  • Raspbian Buster, OS version from 05/07/2021, kernel 5.10
  • Cameras: IMX230 Camera Module, Pivariety IMX298 16MP Motorized Focus Camera Module
  • Shields/boards: USB3.0 UC-593 Rec camera shield, UC-788 Rev.A, UC-788 Rev.B

Commands I tried:

libcamera-raw -o test.raw
libcamera-raw --frames 1 -o test.raw
libcamera-still -t 5000 -o test.jpg -r
./arducamstill -t -0
dmesg | grep arducam

The dmesg | grep arducam output shows probe failed. And test.raw ends up at 123.0MiB. The .raw image is 130MB at 1280 x 720. That’s why I’m confused.

4

Also, is there a command that just takes a single frame? I tried libcamera-raw --frames 1 -o test.raw but the .raw file is still too large. I just want one frame.

5

OK thanks, that helps a lot. A couple things:

  1. libcamera-raw writes the raw Bayer/ISP stream, so the size is expected to be much bigger than a JPEG — that part alone isn’t a bug. A single-frame capture is exactly what --frames 1 is for, so the fact that it’s still 120MB+ is consistent with a raw frame at that resolution.

  2. The real red flag is probe failed in dmesg. That means the kernel driver isn’t binding to the camera at all, so whatever you’re capturing may not be the sensor you think it is.

Let’s separate the problems. Which camera + board combination are you actually testing when you get the probe failure? Can you share a photo of how things are connected?

6

Right now I’m testing the IMX230 Camera Module with the USB3.0 UC-593 Rec camera shield. I attached a photo (IMG_9965.JPG) showing the interfaces. I found two interfaces on the camera shield, but neither of them fits the IMX230 Camera Module. So I can’t even physically connect them properly.

7

That matches what I suspected — if the connector doesn’t match, the sensor will never probe, hence the probe failed. Let’s park the IMX230 for a second and check the 16MP path. Did you install the 16MP camera driver, and which guide did you follow?

8

For the 16MP camera I followed the driver install here: MIPI_Camera/RPI at master · ArduCAM/MIPI_Camera · GitHub
It doesn’t work — the camera isn’t detected at all. Is this driver even the right one for the 16MP camera? I attached image.png and IMG_9029.jpg showing the 16MP hardware.

Same story with the Pivariety IMX298 16MP Motorized Focus Camera Module — driver installed but no detection, and dmesg | grep arducam shows probe failed again.

9

OK, so the 16MP path fails with probe failed too. That guide is the right starting point for that family, but probe failures are almost always physical: ribbon orientation, wrong connector, or the module being on a shield that isn’t wired for that sensor. Since you’re seeing the same symptom on two different modules, I want to check the board you’re testing next. What about the UC-788 Rev.B — what happens there?

10

UC-788 Rev.B definitely doesn’t work. When I ran ./arducamstill -t -0 it just stopped, no capture. I attached IMG_9022.jpg and IMG_9021.jpg showing the UC-788 Rev.B connection and the error.

11

Got it. And to compare, what happens with the Rev.A board? Same command, same camera?

12

Interesting — libcamera-still -t 5000 -o test.jpg -r works fine on UC-788 Rev.A, but it does NOT work on UC-788 Rev.B. I attached IMG_9019.jpg and IMG_9018.jpg comparing the two captures. So Rev.A captures, Rev.B doesn’t.

13

That’s a really useful data point — it confirms the software stack and camera are fine, and the problem follows the board/connection. So now back to the IMX230 + USB3.0 camera shield combo: the blocker there is that the connectors don’t match. To bridge the camera module to that shield you need the correct 22pin to 22pin cable. Do you have one of those on hand?

14

That’s exactly the problem — I don’t have that cable. Can you send me a link to buy the 22pin to 22pin cable? I need the one that connects the IMX230 Camera Module to the USB3.0 camera shield.

15

Right, that cable is the missing piece: it’s what lets you connect the IMX230 Camera Module to the USB3.0 camera shield. One thing to note — this specific 22pin-to-22pin cable isn’t carried in the Amazon store, so you won’t find it there.

You can order it from UCTRONICS here:

16

To wrap up where we landed for anyone following along:

  • The oversized .raw file is expected behavior for a raw Bayer capture at that resolution, not a bug. libcamera-raw --frames 1 -o test.raw is already the single-frame command — the size stays large because it’s raw sensor data.
  • The recurring probe failed (seen with the IMX230 + USB3.0 UC-593 shield, and with the Pivariety IMX298 16MP module) points to a physical connection/connector mismatch rather than software.
  • UC-788 Rev.A captures fine with libcamera-still -t 5000 -o test.jpg -r, while UC-788 Rev.B does not (“./arducamstill -t -0” just stops) — so the fault tracks the board/connection.
  • For the IMX230 on the USB3.0 camera shield, the required part is a 22pin to 22pin camera cable, which isn’t available on Amazon. Order it from UCTRONICS:
    150mm 22pin to 22pin camera cable 0.5mm Pitch interface

Once the correct cable is in place, retest the IMX230 + USB3.0 shield combo and re-check dmesg | grep arducam for probe status.