We’re building a product with a 12MP IMX708 module from Arducam, and are running into some (rare) pixel corruption artifacts in the datastream. I’m hoping people here have some suggestions on how to debug this, or at least what component or setting could cause this particular corruption.
Our setup is an IMX708 module built into a specific sensor. It is normally connected using a 20-30-ish cm flatcable to our Linux board, which is a custom mainboard with a Toradex Verdin IMX8MP SoM, running the Toradex TorizonCore Linux distro. In some experimental setups, the flatcable is replaced with a 150-ish cm HDMI cable with two HDMI-to-flatcable adapters. A bit of Python software is streaming and processing full-resolution RAW images continuously (using low-level v4l code, not libcamera).
We’ve seen that, very rarely, while streaming images, they become corrupted, with repetive pixel-levels artifacts appearing. Once this happens, all images in the stream become corrupted (but the stream still shows live images). If we restart the python code (reopening the v4l device and restarting the stream, but IIUC this does not powercycle the camera module) the issue disappears and images are again ok.
This is how the image looks when it is corrupted:
I’ll post more images below, but I can only post one image per post, so they’ll go in subsequent replies…
About the images:
- Most of the image is white, showing a white backlight background panel. In front of it is a strand of wire (two different sizes) which has some gradients. The right part is black, this is beside the background panel without backlight.
- Both images are taken from different setups, so not before/after breakage. Both have a different size strand of wire in them, so the size difference is not part of the issue.
- They are RAW captures encoded in grayscale. The pixel pattern of this camera is RGGB, which is why the white area of the image shows darker dots: these are the red pixels, which are apparently less intense in our backlight spectrum.
- I screenshotted these at 200% zoom, so it is a bit easier to distinguish the individual pixels in here. In the corrupted image it looks like pixels are stretched/blurred horizontally, but that is actually three pixels with a gradient, see below.
Noise
One particular suspect would be electrical and static noise. We operate in an environment with motors running and the issue seems to occur mostly in a setup with longer cabling, which makes us think about noise as a culprit.
However, if there would be noise on the CSI lines, then that should only corrupt the frame in which the noise occurs, right? Or is there something in CSI that could somehow alter state (of the receiver, or maybe the sending camera?).
One other theory is there is noise on the I2C lines and that somehow changes a setting, but 1) there should not be periodic I2C traffic at all, 2) why would this manifest in the same way every time? Any suggestions on what settings the camera has that could cause output like this?
Receiver corruption
One other theory is that the camera still sends uncorrupted images, but the corruption happens somewhere on the receiving end (in the IMX8MP ISI module, in v4l code or in our processing code). This seems unlikely, since there is hardly any processing going on: The CSI receiver passes data to the ISI module, which writes the data straight into the userspace buffers. There is no debayering, dewarping, or any other processing going on here with this buffer.
Corruption pattern
What is weird is that the corruption seems to repeat every four columns somehow, even though the base pixel pattern is a 2x2 RGGB block.
Does this pattern look familiar to anyone?
Looking at the white part, it looks a bit like there is some pixel ordering issue, since the expected pattern is one gray pixel for R and three white/light gray pxiels for GGB in every 2x2 block (and it looks like 2 gray plus 6 white in every 4x2 block now). However, looking at the black part, that has quite light pixels every four colums, while the expected image is really only very dark pixels.
Help needed
I realize that finding the cause of this issue (in terms of electrical or software issues) will need debugging on our end, but I’m hoping someone recognizes this kind of artifacts and has pointers on what might be happening to produce them (which would provide a starting point for us finding out if that actually happens and why).
