Is there a way of slowing down the rate at which nvarguscamerasrc adjusts exposure and gain? When filming after dark we find that our videos look as if there is a flashing light source present. Printing debug messages from the set_exposure and set_gain methods in the camera driver shows that these settings are often being adjusted many times per second. Therefore it seems that the flashing behaviour is probably caused by the auto-adjustment responding to car headlights and other lights in the image. Ideally I’d like to be able to dampen the feedback response to smooth out these changes.
Any suggestions welcomed. At the moment the only option I can think of is to bypass the ISP and do the exposure and gain control ourselves but I’d rather avoid that if possible.
if you slowing down the calculation, for example, 3-frames at once, you should expect the global scene luminance turbulence.
due to AE algorithm measure the scene brightness and calculate the appropriate settings for every capture frames. it eventually sending the controls to low-level sensor driver for register programming.
your issue seems like AE cannot converge for the extremely scenario, suggest you should debug into your low-level sensor drivers, please check if the steps of gain/exposure were too large. you may dump those gain/exposure settings and draw the curves to monitor the behavior for confirmation.
thanks
Hi @JerryChang. Thank you for your reply and sorry for the slow response - I’ve been doing more testing and trying to get a better understanding of the device tree settings.
I don’t think the steps in gain and exposure are too large. If they were, I’d expect to see the values oscillate at every step, whereas in fact the auto-adjustment increases the value several times before decreasing it again. Our gain step corresponds to 0.3dB, which is the smallest that the sensor is capable of.
I will attach figures showing how the gain changes over time. During the period shown, the auto-adjustment had fixed the exposure at 33,330 us, which is the maximum for our frame rate of 30 fps. The first figure shows the full 5 minute recording period and the second is zoomed in on a 5s period.
please help to narrow down the issue,
could you please enable “AE lock”, also limit the “Gain range” in the Argus application for verification.
suggest you should also share a short video to demonstrate the issue reproduce steps.
thanks
Yes, I’ll set it up to record tonight with the settings as you suggest and will report back tomorrow (UK time). I’ll attach a video demonstrating the problem. It is a 20s segment from the video that was used to generate the figures attached above.
I think I might have found the cause of the problem. Our sensor has conversion gain switching with HCG and LCG modes. Our understanding was that HCG should be used in low light and LCG in bright light and so we were using HCG mode at high gains and LCG mode at low gains. However I have now done an experiment using HCG at low gains and LCG at high gains and the light levels in the video are much more stable. The gain and exposure values are varying more than they did previously but at a lower rate. I will attach plots.
Could you confirm that using HCG at low gain and LCG at high gain is correct?
since your sensor works with LCG (Low Conversion Gain) and HCG (High Conversion Gain) controls, may I know did it controlled per-frame?
could you please also confirm the difference between LCG and HCG modes, for example, is HCG simply double the gain over LCG.
please refer to L4T Multimedia API Reference, you should check Argus::Range.
you may treat LCG/HCG controls by creating a capture request via Argus API as gains by referring to “Argus::Range GainRange”.
thanks
Hi JerryChang. Thanks very much for your reply. I’m afraid I don’t know much about the LCG/HCG modes. The datasheet says: “The conversion gain switching from LCG to HCG Mode is recommended less than gain setting 8.3 dB.” so we swap between the two modes at a gain of 28 (which is approximately 8.3 dB). The datasheet also says that the conversion efficiency ratio (which I think might be the ratio of HCG to LCG) is typically 2.6 (min: 2.3, max: 2.8).
I don’t fully understand your suggestion regarding the Argus API but I will go and look at the documentation and see if I can work it out.
Hi
I’m not sure if I’ve understood your instructions correctly. I’ve called ISourceSettings::getGainRange() to query the gain range and this reports min=0, max=238, which corresponds to the min_gain_val and max_gain_val set in the dtsi file, as expected.
Currently we are using HCG for gains between 0 and 27 (where 28 is approximately 8.3 dB), and LCG for gains between 28 and 238. This seems to match the sensor datasheet which says: “The conversion gain switching from LCG to HCG Mode is recommended less than gain setting 8.3 dB.”. This gives us stable lighting levels when used with auto-adjustment of exposure and gain.
Previously we were using LCG for low gains and HCG for high gains (as in your example) because we had read that HCG should be used in low light conditions. However, this seemed to cause the rapid flickering of light levels that we were seeing when used in conjunction with auto-adjustment of exposure and gain.
okay, I’ve check your attach video (sonycsi_20200206_194502_3_20_to_3_40.avi) again from comment #6.
I think that noticeable global scene luminance varies from 0:11~0:19 should caused by a warning light from an ambulance, or a police vehicle.
you may analysis gain/exposure settings again to confirm that related to sudden scene changes.
thanks
Hi Jerry. The video that you refer to (sonycsi_20200206_194502_3_20_to_3_40.avi) is the video that I uploaded to demonstrate that the problem had been fixed. The other video (sonycsi_20200205_194503_3_20_to_3_40.avi) was the one demonstrating the problem. I think it must be that we needed to switch the way we were using LCG and HCG. I will accept my post from yesterday as the answer.
Thank you for your help. Much appreciated.
