Camera gain settings not applied: turn off auto gain first

An explicit gain written from your own code is the setting most likely to be ignored: the write succeeds, the read-back even agrees, and the next frames look exactly like the ones before. This guide is for integrators driving area scan cameras or smart cameras through a GenICam-based SDK over GigE or USB3. It shows why auto gain overwrites your value, the write order that makes the setting stick, how much gain a defect image tolerates before column noise appears, and how to recover after another application has reconfigured the camera.

Why does the camera ignore the gain value you set in code?

Because GainAuto is still enabled: an auto mode owns the gain register and rewrites it for every frame, so an explicit Gain value written underneath the auto loop is overwritten or never reaches the sensor at all.

The camera exposes two separate features. GainAuto selects Off, Once or Continuous; Gain holds the explicit value, in dB on nearly every area scan camera. While GainAuto runs Continuous, the internal brightness loop steers gain toward its target on every frame, and your value competes with the loop and loses. The signature is distinctive: the write returns success, a read-back right afterwards may even show your number, and the image statistics stay flat anyway. ExposureAuto does the same to ExposureTime, which is why gain and exposure failures usually arrive together.

Fix it in one line before anything else: set GainAuto to Off, then write Gain. Check the exact enumeration strings the camera reports — some firmware lists '0' instead of 'Off' — and see GenICam enumeration invalid value: check symbolics before you set when a legal-looking value is refused. For parameters you change while the line runs, runtime camera parameter control: exposure and white balance live applies the same read-modify-write discipline. Smart cameras hide the pair behind their own parameter pages, and the rule there is identical: take the auto mode off before pinning a value.

In what order should gain and exposure settings be written?

Turn every auto mode Off before you write any explicit value, and finish the whole block before the first frame is acquired: ExposureAuto Off, GainAuto Off, ExposureMode Timed, ExposureTime, then Gain, then binning.

1. ExposureAuto to Off and GainAuto to Off, using the symbolics the camera reports.
2. ExposureMode to Timed, then ExposureTime in microseconds; 1000 is 1 ms.
3. Gain in dB, inside the range and increment the camera reports.
4. BinningHorizontalMode and BinningVerticalMode to Sum, then BinningHorizontal and BinningVertical to 2.
5. Read GainAuto and Gain back, then start the stream.

Writing parameters mid-stream works on most cameras but lands between frames, which shows up as one odd image in a batch. Set manual exposure before streaming: initialization order explains why the whole block belongs before the first grab. One more trap: startup defaults can quietly re-enable auto modes after a reconnect — the same failure described in auto exposure upper limit not applied: check startup settings — so treat the Off writes as part of every connect, not a one-time setup.

Why did settings stop applying after you ran the vendor viewer?

The viewer wrote its own values into the camera's volatile registers and left them there: everything your code did not rewrite stays as the viewer set it until a power cycle. Power-cycle the camera, or load your saved user set at connect, and the symptom clears.

Camera registers reset at power-up, which is why unplug-and-replug feels like a fix: it restores the defaults your code was written against. The deterministic alternative is to write the full parameter block on every connect so the code is the source of truth, or to store your parameters in a user set and load it at startup, as in save camera settings across power cycles with a user set. When a session has left unknown values behind, reset camera settings programmatically before capture returns them to a known state.

Two clients on one camera also explains the reverse symptom, brightness that creeps between shifts; camera image brightness drifts over time: turn every auto mode off follows that trail.

How much gain is too much for an inspection image?

Treat anything past roughly 12 dB as a sign the lighting is too weak: every 6 dB of gain doubles the signal but doubles the noise by the same factor, so 12 dB already multiplies both by 4.

Gain multiplies everything in front of the converter: photon signal, read noise and the sensor's fixed pattern all scale identically, so the signal-to-noise ratio never improves. The legitimate job of gain is lifting a weak signal into the converter's range; beyond that it buys nothing but noise.

Practical inspection runs at or below about 10 dB. Industrial camera image quality settings: exposure, gain, balance walks the same trade-off from the image-quality side.

What causes vertical stripes and one-sided shading at higher gain?

Column fixed-pattern noise: every sensor column has a slightly different amplifier offset, invisible at 0 dB and multiplied by exactly the same factor as the signal, so at 24 dB (15.8x) an offset worth one dark level becomes a stripe nearly 16 levels tall.

The same mechanism explains a result that surprises people: the image can look cleaner at maximum gain than at a middle value, because the true signal grows with gain too and the pattern's relative contrast falls on a bright scene. That is a workaround, not a fix. More light at moderate gain beats maximum gain every time.

A dark half-image has two candidates. If the shading follows the light — re-aim the light and the boundary moves — it is illumination falloff across the field. If a vertical boundary stays on the same pixel columns no matter what you do to the light, the sensor reads out in two halves and the halves differ slightly; rotating the camera 180 degrees is a second test. Binning changes the picture as well: 2x2 Sum raises signal 4x without extra exposure, but it sums the column offsets along with everything else and costs resolution — 4x4 binning vs 2x2: sensor readout decides your frame rate covers the readout side.

Should you raise gain or exposure time first?

Raise exposure first and gain last: exposure buys signal with no noise penalty until motion blur or the cycle-time budget stops you, and blur in millimetres equals part speed in mm/s times exposure in milliseconds divided by 1000 — at 100 mm/s and 4 ms that is 0.4 mm.

Worked example. A belt moves a part at 100 mm/s, the smallest feature to resolve is 0.5 mm, and a uniformly lit frame at 0 dB and 1 ms averages 55 DN on an 8-bit camera; the target mean is 220 DN.

• Factor needed: 220 / 55 = 4.0x.
• Exposure only: raise 1 ms to 4 ms. Blur = 100 × 4 / 1000 = 0.4 mm, under the 0.5 mm feature; brightness 4.0x with noise unchanged. This is the answer whenever the budget allows it.
• Gain only: 20 × log10(4.0) = 12.04 dB, so 12 dB. Blur stays 0.1 mm, but noise and column offsets multiply by 3.98.
• Exposure capped at 2 ms by the cycle time: take 2x from exposure and 6 dB from gain, since 10^(6/20) = 1.995 ≈ 2.0x. Total factor 2 × 2.0 = 4.0; mean = 55 × 3.99 ≈ 219 DN; blur = 100 × 2 / 1000 = 0.2 mm.

Keep exposure below the frame period or the frame rate falls with it. On a moving belt, exposures beyond a millisecond or so favor a global shutter, because a rolling shutter exposes rows in sequence and skews moving parts. The MV-CH120-11UC pairs 12 MP resolution with a global shutter on USB3.

How do you verify the gain change actually took effect?

Grab two flat-field frames, one at 0 dB and one at 6 dB, and divide their mean pixel values: the ratio must be about 2.0, because 10^(6/20) = 1.995. A ratio near 1.0 means the write never reached the gain stage.

The test takes a minute. Aim the camera at a uniformly lit target, mask a fixed region, and record the mean of that region for each setting. Accept a ratio within 5 percent of the linear factor; sensor non-linearity and the black-level offset account for the rest. Read GainAuto again after ten frames as well — an auto loop that re-enables itself mid-run is exactly what this test catches, even when every read-back agrees.

On color cameras, auto modes weigh pixels by channel, which auto exposure and auto gain on color cameras: which pixels count explains; run the ratio test per channel when the target is colored.

What should you check before blaming the camera hardware?

Four checks separate software from hardware: GainAuto still reads Off after ten frames, the symptom survives a power cycle with your code first, the stripe pattern sits on the same pixel columns on a second camera of the same model, and the shading moves when you re-aim the light.

Work down this list before raising an RMA:

• GainAuto reads Off after ten streamed frames; a re-enabled auto mode is the most common cause.
• Gain sits inside the range and increment the camera reports; outside values are clamped or refused.
• The two-frame mean ratio matches the linear factor; that is proof the value reached the gain stage.
• Stripes hold fixed pixel columns through lighting changes; sensor fixed pattern, cured with more light, not a new camera.
• Shading follows the light; re-aim, diffuse or add a second light instead of touching gain.

When the checks point at the camera, pick one whose gain you will never need past a few dB. Mono sensors keep pattern structure predictable, and USB3 or GigE both carry the parameter block without ceremony. The MV-CS200-10UM is a 20 MP mono camera on USB3.0 with a 1" sensor in C-mount.

On GigE, the MV-CU020-90GC is a 2.5 MP color camera with a global shutter and a C-mount, covering the same checks on a networked line.

If the fault turns out to be the light rather than the camera, say so on the contact page with your setting order attached, or shortlist replacements in the camera finder; the cameras topic page collects the other camera-side fixes.