I’m working with an Arducam 5MP OG05B10 Color Global Shutter USB 3.0 Camera (model B0539) and I’m trying to capture raw Bayer data directly from the sensor. Right now I can only seem to get YUY2 frames out of it — YUY2 and MJPG show up when I list the formats via v4l2-ctl / UVC.
What I really need is the RAW image data before the ISP touches it. Is there any way to disable the onboard ISP on this camera? Maybe a “RAW Pass-through” mode that can be enabled by writing to specific registers? I’ve seen some sensors allow bypassing the image processing pipeline if you poke the right registers — wondering if the OG05B10 on this board has something similar.
I took a look at this and unfortunately the short answer is: RAW pass-through / Bayer output is not available on that specific Arducam model.
The reason comes down to how the UVC (USB Video Class) chipset on that camera is designed. The sensor — the OG05B10 — outputs raw Bayer data natively, but between the sensor and the USB interface there’s a bridge chip running firmware that handles the ISP (Image Signal Processing) pipeline internally. That firmware converts the Bayer data into UVC-compliant formats — YUY2 (uncompressed) and MJPG (compressed) — before the data ever hits the USB bus.
This conversion is hard-coded in the firmware. It’s not something gated behind a register you can flip at runtime. The pipeline exists to ensure the camera works with standard UVC drivers out of the box (Windows UVC, Linux uvcvideo, etc.) without needing proprietary decoding on the host side.
So for this particular camera, YUY2 is as close to “raw” as you’re going to get — it’s the uncompressed format with the least processing baked in, but the demosaicing, white balance, and other ISP steps have already been applied by the time the frame reaches your application. There are no exposed registers to bypass the ISP and stream raw Bayer.
Thanks for the detailed explanation — that makes sense about the bridge chip firmware. I was hoping there might be a backdoor through the sensor registers directly.
On that note — do you happen to have the Sensor Initialization Table for the OG05B10? I mean the full register settings / init sequence that the firmware uses to configure the sensor at startup. Even if I can’t get raw Bayer out over USB, I’d like to understand what the sensor configuration looks like. It might help me figure out if there’s any alternative path I haven’t considered.
I understand the desire to dig deeper, but I want to set expectations here — having the sensor init table won’t open up a raw Bayer path on this hardware.
The key issue is architectural, not configurational. The bridge chip sits between the sensor and the USB PHY, and its firmware pipeline is what ingests the sensor’s Bayer output and runs it through demosaicing, color correction, gamma, and format conversion to YUY2/MJPG. That pipeline isn’t something you can disable by tweaking sensor-side registers — the bridge firmware will still receive the Bayer data, process it, and only emit the processed frames over UVC.
Think of it this way: the sensor registers control what the OG05B10 does, but they don’t control what the bridge chip does with the data afterwards. Even if you reconfigured the sensor, the bridge would still apply its ISP pipeline to whatever comes in.
So to summarize: there is no register-based workaround for this model. RAW Bayer output is gated at the firmware/hardware architecture level, not at the sensor configuration level. YUY2 remains the least-processed format you can get from this device. If raw Bayer capture is a hard requirement, you’d need to look at a different class of camera — typically ones that expose the sensor’s parallel/MIPI interface directly rather than going through a UVC bridge.