Hey everyone, I’m having some weird image quality issues with an Arducam OX05B1S camera module and hoping someone here has run into this before.
No matter what lighting conditions I’m in, the image has a really strong yellowish tint — like everything is bathed in yellow. On top of that, there’s a very visible checkerboard pattern across the entire image. It’s not subtle at all.
Here’s my setup:
Camera: Arducam OX05B1S
Software I’ve tried: ArduCam USB Camera Viewer (Windows GUI) and also the ArduCAM_USB_Camera_Shield SDK tool
I’m also seeing a bunch of “length mismatch” warnings in the GUI app that I can’t seem to get rid of. I already tried messing with white balance settings through the config file but that didn’t change anything.
Is this a known thing with this sensor? Any pointers would be appreciated.
Thanks for reaching out — what you’re seeing is actually expected behavior given how this sensor works with our current software tools, but let me break down what’s happening.
The OX05B1S is an RGB-IR sensor, meaning it has a non-standard pixel layout that includes both RGB and infrared-sensitive pixels. The checkerboard artifacts you’re seeing are because both the Arducam USB Camera Viewer and the ArduCAM_USB_Camera_Shield SDK apply standard Bayer demosaicing — and this sensor’s pattern is not a standard Bayer pattern. The decoder just doesn’t know how to interpret those IR pixels correctly, so you get that checkerboard look.
The yellowish tint is related to the same root cause: the processing pipeline isn’t separating the IR light influence from the RGB pixel values, which throws off the color balance significantly.
As for the “length mismatch” warnings — those are typically caused by the host system struggling to keep up with processing. RGB-IR data is more CPU-intensive to handle, and some packets can get dropped. Those warnings don’t affect the camera’s basic operation, so you can mostly ignore them for now.
Our team has identified the root cause and is actively working on updated configuration files (cfg files) that will handle the RGB-IR pixel layout correctly. Once those are ready, the out-of-the-box image quality should improve significantly. I don’t have an exact ETA yet, but I’ll update this thread once we have something to share.
Thanks for the explanation — that makes sense. In the meantime, I’ve been digging into this a bit further on my own.
I pulled the latest code from the ArduCAM_USB_Camera_Shield repo on GitHub and tried applying every remosaicing format that Arducam supports to convert the RGB-IR data into a conventional Bayer pattern. I tested all seven:
BGGI
GIRG
RGGI
GRIG
IGGB
GBIG
GIBG
Unfortunately, the checkerboard artifacts persist no matter which one I use. It seems like none of these remosaicing modes correctly map the sensor’s actual pixel layout.
I also went a step further and started looking at the raw Bayer data directly. For each 2×2 Bayer block, here’s what I’m observing:
Top-left and bottom-left pixel values look normal
But the bottom-right pixel value alternates between adjacent 2×2 blocks
The pattern seems to repeat every two 2×2 blocks
This really looks like a non-standard layout, probably related to how the IR component is interleaved.
A couple of questions:
Is there any update on improvements for compensating IR influence on the RGB channels in the processing pipeline?
Is there any detailed documentation on the specific Bayer format or pixel pattern used by the OX05B1S?
Would it be possible to get a formal description or a remosaicing/demosaicing reference for this sensor?
Really appreciate the thorough investigation — that’s great data and confirms exactly what we’ve been seeing on our end too. The fact that none of the seven remosaicing formats resolved the checkerboard tells us that the sensor’s pixel layout doesn’t match any of the currently supported patterns, so you’re dead on about it being a non-standard layout tied to the IR interleaving.
To answer your questions:
The root cause is confirmed and the fix will come in the form of updated cfg files. It’s going to take a bit more time — the team needs to properly characterize the pixel layout and bake that into the configuration. I don’t have a firm date yet but this is being actively worked on.
2 & 3. I’ve sent you a Bayer format reference document via private message — it covers the pixel pattern details for RGB-IR sensors including the OX05B1S. Check your messages, that should help with your own analysis while we finalize the cfg updates.
Your raw data analysis (the alternating bottom-right pixel across 2×2 blocks) is a really useful observation. That alternating pattern is almost certainly the IR pixel interleaving, which is why standard demosaicing falls apart — the decoder is treating those IR values as if they were a regular color channel.
Got it, thanks for sending over that reference doc — I’ll dig into it and see if I can make sense of my raw data with the proper pixel layout in mind.
I’ll sit tight for the updated cfg files. If there’s any beta or early test version I could try out once something is available, I’d be happy to provide feedback. Appreciate the help.