Replies: 2 comments 4 replies
-
|
Hi, we're aware that the setting of per-frame controls isn't working as we would like and are looking into it. The first thing I want to fix is that we can't deal with big per-frame changes in exposure, and this is what causes the digital gain to move. Sorting that out will stop these unexpected changes and things will be completely predictable. But there is some work to be done down in libcamera itself as well, so we'll keep folks posted. |
Beta Was this translation helpful? Give feedback.
-
|
Yes there is a strange behavior when we manually change the exposure. It is not a problem of AGC because we are in AeEnable=false. Here is a trace when we go from exposure 751 to exposure 6514 AeLocked: False Exposure: 571 Analog: 1.0 Digital: 4.0 The library receives frames from the sensor with exposure 571 and thinks it is useful to apply a digital gain of 4 to compensate. In the end we obtain the achievable value of 6485 with a digital gain close to 1. In my opinion this behavior with AeEnable=false does not make much sense. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, this is what we are going to address. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
As the exact value is not obtained it would be nice to have a way to know if the library considers that the requested value is approximately obtained. |
Beta Was this translation helpful? Give feedback.
-
|
Below is a trace with the following scenario : Start wit AGC on Stable exposure 3142 Setting AeEnable=False and Exposure_Time 628 AeLocked: True Exposure: 3142 Analog: 1.0 Digital: 1.0061006546020508 Comment: Setting AeEnable=False Exposure_Time=6284 AeLocked: True Exposure: 600 Analog: 1.0 Digital: 1.0466666221618652 Comment: Returning in auto Setting AeEnable=True and Exposure_Time=0 AeLocked: True Exposure: 6257 Analog: 1.0 Digital: 1.0042922496795654 Comment: |
Beta Was this translation helpful? Give feedback.
-
|
That sounds promising! Thank you for looking into that! In case you are interested, I wrote a little post in the Kinograph-forum about the new picamera2-lib. Included are also a few test scans comparing the old picamera/Broadcom-stack with the new picamera2/libcamera-stack. |
Beta Was this translation helpful? Give feedback.
-
The digital gain of the new picamera2/libcamera combo is not accessable by the user. Instead, the AGC-function uses a digital gain different from 1.0 to approximate exposure times which were requested by the user but are not realizable directly, due to hardware constraints.
While this approach is perfect for taking single images in broad contexts, it spoils the fun in a lot of other applications, mainly applications aimed more toward scientific or engineering cases. To give some examples: serious HDR-work needs precise and repeatable exposure values. Using the Raspberry Pi foundation cameras in DIY spectrometers you can calibrate these things only if you can be sure to get exactly the same exposure value today and tomorrow.
Now, theoretically, if the product of exposure time and digital gain stays constant, the actual exposure value should be the same - according to my experiments, this however not the case. For example, the 10%-quantile of images with the same exposure value changes:
If you want comparable exposures, you will need to wait until the digital gain has settled to a value close to 1.0. Only then images are similarily exposed. From my experiments, it can take up to 5 consecutive requests until the AGC has settled to something close to digital gain = 1.0.
Note in this regard that for arbitrary exposure times it is not guaranteed that the digital gain settles to exactly 1.0. This will only happen if the requested exposure time is exactly realizable by the sensor hardware. For example,
2400is such an exposure time, but2456is not.So here's now my suggestion: can we not treat digital gain like the AWB-gains? That is, make it setable. If set by the user - do not change it ever (which effectively kills the AGC-algorithm). If you want to enable the AGC again, simply set the digital gain back to 0.
Such a behaviour would mimic closely how the AWB-algorithm is performing, so it's simple to memorize, and it would enable users which depend on repetable exposure values to achieve this much faster than currently possible.
One worked out example: I have a film scanner project using the HQ camera in the full resolution mode (10 fps). From each movie frame, a sequence of five different exposures are taken (color-reversal films have a huge dynamic range). I need to wait 0.5 seconds after a frame-advanve for mechanical vibrations to die out, and than 0.5 seconds (five consecutive frames @10FPS) for each exposure. This results in a total of 0.5 (mechanical wait) + 5 * 0.5 (each exposure) = 3.0 secs/frame. So digitizing one second of a 24 fps movie takes 1,2 minutes. This a rather slow process for a longer movie and the scanning time is mostly spent for the digital gain/AGC to settle in it's final stage. If the digital gain would be setable, I think one could reduce the waiting time to 1-2 frames = 0.1-0.2 sec (@10FPS). This would in my use case at least half the time required for scanning a certain scene. And, as elaborated a little bit above, for some other use cases out there, an image corresponding to exactly the requested exposure value would be helpful as well.
Beta Was this translation helpful? Give feedback.
All reactions