Key observations:
-
The issue has been observed on a large number of cameras. We have nearly 200 ZED 2i units deployed, so this does not appear to be a failure of a single camera.
-
I have observed this issue using both SDK 4.x and zed-open-capture.
-
A previous employee discussed this with Stereolabs support and was reportedly told that the camera must be power-cycled when the issue occurs.
-
Power-cycling is not an acceptable solution for our application because we cannot experience random interruptions during operation.
-
The issue has only been observed outdoors in bright sunlight. I have not yet been able to reproduce it indoors.
-
The camera may operate normally for extended periods (for example, more than an hour) before the issue occurs or it can occur within seconds of turning on.
-
In at least one case, the issue appeared immediately after the camera was turned toward the sun while being moved/stored.
-
The corrupted image is not simply overexposed. Bright regions become white, but many highlight transitions and reflective surfaces develop strong magenta/purple coloration.
-
The issue can affect large portions of the image and produces unusable data for computer vision.
Current configuration:
-
Using zed-open-capture.
-
Camera hardware AEC/AGC disabled.
-
Running a custom software exposure/gain control loop.
-
Camera white balance control disabled.
-
Disabling white balance may have reduced the frequency of the issue but has not eliminated it.
Additional observations:
-
The open-capture source appears to indicate an OV580 ISP/bridge and OV4689 image sensors.
-
The project includes logging of OV580 ISP registers and OV4689 exposure/gain registers, suggesting there may be ISP state related to this issue.
-
Because the problem has been observed with both the SDK and open-capture, I suspect the issue may exist below the application layer.
Questions:
-
Is this a known issue with the OV580/OV4689 image pipeline used in the ZED 2i?
-
What internal camera state is becoming corrupted when this occurs?
-
Is there a documented recovery method that does not require a USB power cycle?
-
Are there specific ISP, AEC/AGC, AWB, or OV580 configuration registers that should be disabled or initialized differently to prevent this condition?
-
Has Stereolabs identified the root cause or a mitigation for deployments operating continuously in bright outdoor environments?
Any guidance would be appreciated.
