We have a IMX530 camera system from Framos, and have been using it with both the AGX Xavier Devkit (with drivers from framos) and the Boson from CTI, and after upgrading to jetpack 5, the auto-exposure is extremely bad under certain circumstances (this happens on both boards). Attached is a video demoing the behavior:
Notes:
As shown, the issue only happens when at the 3840x2160 mode
In the video, it always breaks above zero exposure compensation, but this is not true in general. The darker the scene, the lower the number it breaks at. Additionally, if you darken a scene enough it will break (without changing exposure compensation)
Do you suspect the issue is with Framos’ driver–should we reach out to them?
We have many IMX530s, and it repros on all 2 I’ve tried. I believe we have a few others around (not sure what) that I could try on, but we do need it to work on the IMX530s.
This is L4T 35.3.1
Is it possible this is fixed in 35.4.1?
I cannot check with the bosons (as CTI has not released their 35.4.1 based BSP) but I could check with the AGX Xavier.
I do have some other camera modules that I can test with, but I did more testing and have figured out what’s going, and I believe the issue to be on framos’ side.
It seems that Argus’ autoexposure has some logic to get the maximum exposure time for a given framerate out of the camera, and it correctly negotiates this to 33.333ms for a 30fps stream. However, for some reason, when Argus sets the camera to 33.333ms, the camera configures itself to an entirely different (and drastically lower) exposure time, while still reporting to Argus that it’s at a 33.333ms exposure time. This causes the frame to be massively underexposed, and since Argus believes (falesly) that the camera is using the maximum exposure time, it bumps the ISO up as much as it can to get a properly exposed frame. This results in the grainy, dark frame that you see in my videos. This theory is further confirmed by if you set the exposure compensation way down (I had to set it all the way down to -10 or so, which we can do in our software but is not exposed in the argus test app), argus would eventually decide that it did not need the maximum capture time, and you could even get it to oscilliate between the second longest capture time and (what Argus thinks is) the longest capture time, with wild flashing results. But if you reduce it further it will solidly decide it doesn’t need to use the longest capture time, and autoexposure will be correct again and you can increase the exposure compensation back to a normal range (of course, until Argus decides it needs the maximum capture time).
So, the fix for this issue was just manually setting in Argus a maximum capture time slightly under 33.333 (I’ve set it to 33 and it works fine, it’s possible I could go a bit higher), and then it works flawlessly. Since it seems Argus is properly working here, I’m assuming the issue is with framos and we will be forwarding this issue to them.