We found that the problem lies in the digital gain. When you set the analog gain, the digital gain will adjust at the same time, and slowly fall back to normal. So basically there is no problem with the setting of the analog gain.
@wong , thanks, just to understand, if I want to push analog gain to 500 for example and do not want digital gain to auto adjust, what should I do ? Also set digital gain at same value (500) ?
Regards
From the code, this is a bug in the raspberrypi ipa, when using manual settings, the digital gain is not fully manual.
I am going to submit this bug to libcamera
If you want to know the progress of this bug, you can check:
https://bugs.libcamera.org/show_bug.cgi?id=110
@wong many thanks for the link, I will follow the correction and by the way, Happy Chinese new year !
Thank you, and Happy New Year to you too.
@wong, there is a reply on the bug you open on Libcamera bug reports. So in brief, DigitalGain is used automatically when AnalogGain is set to a value exceeding the sensor capacity. Maybe that’s what happen when I push AnalogGain to high level, however it does not explain why the few first frames increase the gain and the next ones decrease the gain ?
Indeed, I have raised this issue in a bug submission.
Hi
I’ve been tinkering with a slightly modified version of Watchever’s example code and just for interest here are some findings on the achieved maximum exposure at requested times close to the maximum limit.
Achieved exposure seems to follow the requested value up to just over 0.97 seconds , then it flattens off and doesn’t go any higher. This seems to correspond to the point where the vertical blanking interval reaches it’s limit of 64455. The achieved exposures and vertical blanking were read from a v4l2-ctl --list-ctrls after setting the exposure with the python code.
Hi @sandyol, maybe you should open a new topic, because the main concern here is the problem on gain that decrease after few frames when it is set to high value. @wong has already opened a bug report on libcamera forum for this purpose and we are expecting an answer.
Hello @wong, there is no feeback on your opened bug regarding gain issue : https://bugs.libcamera.org/show_bug.cgi?id=110.
Do you think it is possible to send a new message to ask for a reply ?
Thanks for your help
Hello @wong you get a reply from libcamera bug repirt. They ask for a piece of code to illustrate the gain issue. Can you provide one in C++ ?
Thanks again
Thank you for your reminder,
I’ll find time to write an example.
@wong , I write the request sample on libcamera bug report, but as not test it.
from qt_gl_preview import *
from picamera2 import *
import time
picam2 = Picamera2()
preview = QtGlPreview(picam2)
preview_config = picam2.preview_configuration()
picam2.configure(preview_config)
picam2.start({"AeEnable": 0, "AnalogueGain": 1.0, "ExposureTime": 500000})
time.sleep(5)
picam2.set_controls({"AnalogueGain": 100.0 })
time.sleep(5)
picam2.set_controls({"AnalogueGain": 200.0 })
time.sleep(5)
picam2.set_controls({"AnalogueGain": 400.0 })
time.sleep(5)
picam2.set_controls({"AnalogueGain": 800.0 })
time.sleep(5)
Thank you so much for your work,
In our further testing, it seems that the IMX477 does not have this problem, which is why we didn’t send the relevant examples, due to some recent work, I haven’t had time to test it further.
Thanks @wong so you mean that problem could come from your sensor and firmware ? I have bought two more arducam IMX462 and would like to know if you plan to add the 1sec exposure in the preinstalled firmware?
Can’t confirm yet, I think there is some problem with the combination of the two (IMX462 and libcamera digital gain) because IMX462 is special.
I’m not quite sure if the 1s version of the firmware has become a production version yet, I need to check with my colleagues.
Hi @wong, any feedback regarding the gain issue ? It would be really helpful to get a solution. Thanks for your help.
Hi @watchever
Sorry, I have been busy recently.
We tested the previous conjecture, we modified libcamera to not execute Agc’s Prepare method when the exposure and gain were set to manual, and the result showed that the flicker was successfully eliminated.
But the strange thing is that the official camera can’t reproduce the flickering problem, I think it has something to do with both the camera and libcamera, we will check further.
Until then, you can tell me the libcamera version and system version you are using, and I can send you a test version
Hi @wong, my kernel version is Raspbian 10 (buster).
And regarding libcamera, running libcamera-still --version displays :
libcamera-apps build: 6145daf735fc-intree-dirty 11-12-2021 (14:29:00)
libcamera build: v0.0.0