Hi again, yes that sounds like an interesting problem.
So firstly, you're correct that the only way to ensure the exposure/gain of the next frame is to stop and re-start the camera. You probably don't need to configure anything again, so I expect this would work:The catch, of course, is that stopping and re-starting the camera is normally quite slow, though it depends a bit on the sensor and so on. But I expect it would normally be "hundreds of milliseconds".
You can send controls while the camera is running. Exposure/gain controls normally have a delay of ~3 frames within the camera system itself (which would normally make it quicker than stopping/re-starting), but unfortunately you also get stuck at the back of the libcamera buffer/request queue, so that can easily add *another* 6 frames or so (depending on how many buffers you have requested).
In many ways you should be able to get the best results from the in-built AGC. You still have the ~3 frame delay inherent in the camera, but you bypass the libcamera queue, so at that level that's as responsive as you'll get. It could be that the algorithm is adapting too slowly for you, but you can simply change that in the JSON camera tuning file. The default "speed" is 0.2, so you could easily push that up. At some point, of course, you would start to get overshoots and oscillation.
The other catch with the in-built AGC is that it uses its idea of what the target exposure should be, and not yours! Though that is also highly configurable in the tuning file, should you want to give it a go.
So firstly, you're correct that the only way to ensure the exposure/gain of the next frame is to stop and re-start the camera. You probably don't need to configure anything again, so I expect this would work:
Code:
camera.stop()camera.controls.AnalogueGain = 1.2345camera.start()You can send controls while the camera is running. Exposure/gain controls normally have a delay of ~3 frames within the camera system itself (which would normally make it quicker than stopping/re-starting), but unfortunately you also get stuck at the back of the libcamera buffer/request queue, so that can easily add *another* 6 frames or so (depending on how many buffers you have requested).
In many ways you should be able to get the best results from the in-built AGC. You still have the ~3 frame delay inherent in the camera, but you bypass the libcamera queue, so at that level that's as responsive as you'll get. It could be that the algorithm is adapting too slowly for you, but you can simply change that in the JSON camera tuning file. The default "speed" is 0.2, so you could easily push that up. At some point, of course, you would start to get overshoots and oscillation.
The other catch with the in-built AGC is that it uses its idea of what the target exposure should be, and not yours! Though that is also highly configurable in the tuning file, should you want to give it a go.
Statistics: Posted by therealdavidp — Wed May 28, 2025 8:11 am