I’ve been migrating our system from Buster OS to Bookworm OS and I’m running into an issue with raw image capture. We’re using rpicam-raw to capture frames from both UC-599 and UC-788 based cameras, but the images I’m getting don’t look like true raw data. There’s a noticeable softness compared to what we used to get on Buster — it almost looks like some kind of pixel averaging or debayering is being applied before the file is written. Anyone else seeing this?
That’s interesting. Can you share a bit more about how you’re comparing the two? Are you using the same camera module for both tests, and what software stack were you using on Buster for the raw capture? Also, what does the output file look like — what extension and approximate file size are you getting from rpicam-raw on Bookworm?
Yeah, I did a side-by-side using the exact same UC-599 camera hardware:
- On Buster OS with the Arducam library — images come out sharp, looks like proper raw data.
- On Bookworm OS with rpicam-raw — images are noticeably softer. It really does look like some debayering or averaging is happening.
The files do get a .raw extension and the sizes seem reasonable, but when I open them up and inspect the pixel data, something’s off. I also tried the same Bookworm + rpicam-raw setup with a UC-788 camera and got the same result — doesn’t seem to produce genuine raw output either.
So at this point, it seems like our application only works properly with UC-599 cameras. The UC-788 isn’t giving us usable raw frames no matter what we try.
Thanks for the detailed comparison. This might come down to differences in the rendering pipeline between the two environments rather than a problem with the raw capture itself.
The Arducam library you were using on Buster and rpicam-raw on Bookworm don’t necessarily handle the Bayer data the same way — even if both are producing .raw files, the downstream processing or the way the raw frame is packed/written can differ, which would explain the sharpness discrepancy you’re seeing when you view the images.
Can you confirm the exact rpicam-raw command you’re using? The official Raspberry Pi documentation has some flags worth checking: https://www.raspberrypi.com/documentation/computers/camera_software.html#rpicam-raw — particularly around the Bayer output format options. There’s also the --rawfull flag that might be relevant depending on what you’re expecting from the sensor.
I can’t share actual sample images unfortunately — the content is sensitive. But here’s more about our setup:
- Hardware: Raspberry Pi Compute Module on a custom board (not a standard Pi — it’s our own dedicated hardware).
- Cameras: UC-599 (the older units, these work fine) and UC-788 (newer units we tried to switch to, but they don’t work).
- OS: Buster is our working baseline. Bookworm is where we’re trying to migrate.
- Software: On Buster, we use a QT-based application that talks to the camera through the Arducam library to pull raw frames. I’ve attached the project file via PM if that helps.
The rpicam-raw output on Bookworm just doesn’t match what we get from the Arducam library on Buster, even with the same UC-599 camera connected. Our whole pipeline expects the raw Bayer pattern the way the Arducam library delivers it, and whatever rpicam-raw is producing — it’s different enough to break things.
That extra context helps a lot. So the core issue isn’t just a viewing difference — your entire application pipeline on Buster is built around the specific raw format that the Arducam library outputs, and rpicam-raw on Bookworm doesn’t produce an identical byte layout, hence the downstream processing falls apart.
We’ve actually been able to reproduce a subtle difference between Buster (Arducam library) and Bookworm (rpicam-raw) captures from the same UC-599 sensor. It’s subtle enough that it hadn’t come up before, but it’s real — the rendering and raw packing pipelines just aren’t identical between those two stacks.
Now, regarding the UC-788 on Buster — that’s the real gap. Have you tried running the UC-788 with your existing Buster + Arducam library setup at all? I’d like to test that combination on our side. I’ve sent you a private message — if you can upload your Buster OS image somewhere and share the link, I can try booting it with a UC-788 here and see exactly what happens. That’ll tell us whether a compatibility path exists without having to source discontinued UC-599s.
Just to summarize where we are for anyone following along:
- The UC-599 works on both Buster (Arducam library) and Bookworm (rpicam-raw), but the raw output format differs between the two pipelines — enough to break applications that depend on the exact byte layout.
- The UC-788 doesn’t produce usable raw output on Bookworm with rpicam-raw.
- The real question now is whether the UC-788 can work with the customer’s existing Buster + Arducam library stack. That’s what we’re testing next by running their actual Buster image against UC-788 hardware.
If the UC-788 simply isn’t compatible with the Arducam library on Buster, then the options narrow considerably — either a software adaptation layer on the Bookworm side to match the old raw format, or sourcing UC-599 units. We’re actively pursuing the compatibility test to narrow this down.