Hey everyone, I’m running into a weird issue with my sensor where there’s a digital gain being applied that I have zero control over. Even when I explicitly set gain to ‘1.0’ or ISO 100, I can see a digital gain is still being tacked on somehow. This is preventing me from getting a constant gain across photos, which is critical for what I’m doing.
Here’s a screenshot showing what I’m seeing:
Has anyone else run into this? Any way to fully disable or lock down digital gain so it’s truly at 1.0?
This is actually expected behavior with the current libcamera stack — digital gain control has been removed as a separately controllable parameter. The ISP digital gain value is now tied to the analog gain value, so you can’t manipulate them independently anymore.
The workaround is to just use the analog gain parameter directly. If you’re targeting ISO 100 equivalent, set analog gain to 1.0.
First, you can verify that digital gain isn’t exposed as a control anymore:
libcamera-still --help | grep gain
You’ll see only analog gain is available. Then try this capture command:
libcamera-still --analoggain 1.0 -o iso100_test.jpg --immediate -n
There’s a good discussion about the digital gain changes over on the Raspberry Pi forum that covers the background on why this was done: https://forums.raspberrypi.com/viewtopic.php?t=346873
Give that a shot and let me know if the gain looks consistent in the output.
Thanks for the suggestion. I gave that a try — both through libcamera-still directly and within our existing libcamera2 application code — but unfortunately the problem is still there.
I took some nighttime test shots and they’re showing way more noise than expected, especially concentrated in the bottom-left area of the frame. The quality is noticeably worse compared to a DSLR shot at ISO 400 taken in the same conditions. And here’s the strange part: even though I’m setting the gain to 1.0, the sensor metadata is still reporting an ISO of 598.
Here are the test images:
Something is still applying gain that I can’t account for. I’d really like to discuss this with someone on the engineering side because the end goal here is to replace DSLR cameras and this inconsistency is a blocker.
Actually, thinking about this more — I’m starting to suspect something changed in libcamera and pivariety that introduced these digital gain artifacts. We ran this exact same sensor about 2 years ago (we called that build “hawkeye”) and back then it could lock the gain to ISO 100 with a full 30-second exposure without any digital gain artifacts at all. Same hardware, completely different behavior.
Here’s a reference photo from that older setup:
Clean, no unexpected gain being applied. Whatever changed between then and now seems to be the culprit.
That’s a really useful data point — the fact that the same hardware behaved correctly ~2 years ago strongly points to a firmware or libcamera stack regression rather than a sensor limitation.
Couple of things to help narrow this down:
Can you check which version of libcamera you’re running now vs. what was on the older “hawkeye” build? libcamera-still --version should give you the current one.
The sensor reporting ISO 598 when analog gain is set to 1.0 is suspicious. There may be a minimum gain floor being enforced somewhere in the pipeline, possibly at the firmware or tuning file level. Can you check which camera tuning file is being loaded? You can run with LIBCAMERA_LOG_LEVELS=Camera:0 to get more verbosity and see what’s happening during initialization.
If possible, try rolling back to the older libcamera/firmware combination that you know worked on “hawkeye” and confirm whether the ISO 598 reporting goes away. That would confirm whether it’s a software regression vs. something else.
For now, the workaround remains setting --analoggain 1.0 explicitly, but clearly that’s not achieving the expected result on your current stack. This needs further investigation on why the gain floor appears to have changed.
